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