Unpatched Vulnerability Alert - WebLogic Zero Day
The news today is full of a new deserialization vulnerability in Oracle WebLogic. This affects all current versions of the product (the POC is against 10.3, but 12.x versions are also affected). The vulnerability affects the wls9_async_response package (which is not included by default in all builds), so the workaround is to either ACL the Z/_async/* and /wls-wsat/* paths, or delete wls9_async_response.war. A successful attack gets the attacker remote code exec on the vulnerable server.
The root cause here seems to be that the affected WAR components ingest and process all serialized data, and have a blocklist of "bad" content. What this means to me is that we're likely to see a number of similar vulnerabilities / attacks crop up over the next while, until Oracle changes this approach.
Indications are that this is in the "tens of thousands" of affected sites, not hundreds or thousands or millions (not yet at least).
The vulnerability is posted as CNVD-2018-07811 (China National Vulnerability Database) at http://www.cnvd.org.cn/flaw/show/CNVD-2018-07811. We don't have a CVE yet.
This bug was originally disclosed by the China Minsheng Banking Co. There's a good write-up by the KnownSec 404 Team with a bit more detail here: https://medium.com/@knownseczoomeye/knownsec-404-team-oracle-weblogic-deserialization-rce-vulnerability-0day-alert-90dd9a79ae93
This comes just one week after Oracle's "Patch Everything" Critical Patch Update (CPU) last week. The next CPU isn't due for 3 months, so it'll be interesting to see what the out-of-band response patch or patches (if any) to this might be.
Stay tuned - we'll udpate this story as we get more information - in particular if we see attacks in the wild we'll post IoC's as we get them.
======= Update 1 =======
Thanks to our reader who commented below!
The matching CVE number for this is CVE-2018-2628, which was identified as patched last year (Oracle's CPU - Critical Patch Updates found here https://www.oracle.com/technetwork/security-advisory/cpuapr2018-3678067.html ). However the POC mentioned was against a patched server, so I guess the patch isn't complete - nor can it be given Oracle's approach against this issue.
======= Update 2 =======
POC posts are at:
https://twitter.com/jas502n/status/1121120045617176576
https://twitter.com/jas502n/status/1120911506785230848
POC code is here (we have not tested this, so use this at your own risk):
https://github.com/jas502n/CVE-2018-2628
======== Update 3 ==============
Thanks to one of our readers ("anonymous" in the comment section :-) ) who gave us the heads-up that Oracle gave this a new CVE and has released a patch for it.
https://www.oracle.com/technetwork/security-advisory/alert-cve-2019-2725-5466295.html
https://blogs.oracle.com/security/security-alert-cve-2019-2725-released
Note though that the underlying vulnerability for all of these problems is how the associated attacks are detected - with a blocklist of "known badness" for deserialization. What this means is that while this specific case has been patched for, we should look for similar, perhaps even nearly-identical issues to continue to crop up on this product. Even with the patch out, for this reason I'd still suggest that WebLogic admins disable or ACL the affected WAR components if at all possible. If not, be sure that your server is virtualized and you have an image backup, you might need it
Service Accounts Redux - Collecting Service Accounts with PowerShell
Back in 2015 I wrote up a "find the service accounts" story - https://isc.sans.edu/forums/diary/Windows+Service+Accounts+Why+Theyre+Evil+and+Why+Pentesters+Love+them/20029/ (yes, it really has been that long). The approach I wrote up then used WMIC. Those scripts saw a lot of use back in the day, but don't reflect the fastest or most efficient way to collect this information - I thought today was a good day to cover how to do this much quicker in PowerShell.
Why would you need to do this? In a penetration test or an internal security assessment, you normally want to enumerate any services that don't use the built-in Microsoft Service Accounts. This is because actual service accounts almost never see a password change, and almost always are given local administrator or domain administrator rights. Mainly because if you're going to be a software vendor that's dumb enough to still use Windows XP era service accounts, you might as well go all the way and make those accounts Domain Admin for any malware that wants to collect those passwords (stay tuned, we'll be doing this tomorrow!). Microsoft's current recommended approach is to use the various built-in service accounts for services. These don't have passwords, and can't be used for lateral movement to other workstations or servers.
That being said, let's pretend to be malware and collect those service accounts across an AD domain!
|
$targets =get-adcomputer -filter * -Property DNSHostName foreach ($targethost in $targets) { |
A few things to discuss.
First of all, $i, $count, and the "write-host" line are there just so that if you have several thousand hosts to enumerate, you can ensure that your script isn't hung, and how far along it might be at any given time.
The "Test-connection" check is there so that you don't wait several seconds trying to connect up to remote hosts that might not be up.
Also, this can only enumerate hosts that are actually up and accept a connection - you likely want to run this script during the day. If you start your script and see that it's going to take longer than a business day to complete (for a larger domain for instance), you might want to pause it towards the end of the business day, and restart it the next morning after everyone is back at their desks.
OK - so now that the script has run, what have we found? What we have is the list of **all** services that are installed on all hosts in the domain, along with the account that's used to start the service.
This is great for system admins looking for one thing or another, but for most security purposes you don't want the ones that are using the built-in service accounts. To filter those out, you want to remove any service that is started by these accounts:
- NT AUTHORITY\LocalService
- LocalSystem
- NT AUTHORITY\NetworkService
- or an empty field
To do this, add these lines to the bottom of your script
|
$filtlist = @("LocalService", "LocalSystem", "NetworkService", "NT AUTHORITY\LocalService", "NT AUTHORITY\NetworkService", "NT AUTHORITY\NETWORK SERVICE", "NT AUTHORITY\LOCAL SERVICE") $TargetServices | export-csv bad-services.csv |
Things to note in this bit of code? the "contains" and "notcontains" operators are case-insensitive, so you upper / lower case doesn't matter in your filter.
So, what can we do with this list if we're attacking a domain? We can use the domain admin and local admin lists that we sleuthed yesterday, and see which of these service passwords are domain admins!
Let's take that list of $TargetServices, and list the offending accounts:
|
$TargetSVCAccounts = $TargetServices.startname | Sort-Object -Unique AD\biztalkhost |
In a different domain it's common to also see service accounts that are local to the machine being enumerated, often those will have local admin rights, and often you'll find that those same (local admin) service userid and password are used on all workstations and often on all servers - which gets you almost the same access as domain admin rights (oops).
Normally the lists that come out of these scripts are short enough that I can compare them by eye to the list of local and domain admins we collected in yesterday's story. But if you have one of those unfortunate domains where dozens or hundreds of people have domain or local admin rights, you might want to add a bit more code:
|
$SVCDomAdmins = @() Foreach ($Acct in $TargetSVCAccounts) { $SVCDomAdmins | Sort-Object -Unique | export-csv Service-DomainAdmins.csv |
To find Service Accounts that are local admins, it's the exact same code, but replace line 2 with "$Admins += $localadmins.AdminID.toupper()"
If you have a minute today, try this on your domain - use our comment form to let us know if you find anything interesting!
What will we do with this list of accounts next? Stay tuned for the next installment tomorrow :-)
===============
Rob VandenBrink
Compugen
Comments