Recent WebLogic exploits (and why they keep coming)

Recent WebLogic exploits (and why they keep coming)

Published on: Category: Oracle

My previous blog was about how to harden your WebLogic and Oracle Fusion Middleware instances. I received quite a few questions on that blog post on the manner and place in which these exploits occur. I would like to share some insights.

There has been a lot of talk on WebLogic security recently. Security exploits are graded using the CVSS scale (1-10) and every other month a new exploit targeting WebLogic is published with a near perfect score. That means a vulnerability that gives access to the network without authentication, allowing full control of the process and perhaps the underlying machine.

In the following I will provide insight on how these all stem from one problem and tips for administrators and security experts on how to deal with it.

Unsafe deserialization

In essence, the hack revolves around the principle of ‘unsafe deserialization’. Serialization is the art of flattening program objects for transport. Deserialization is returning a string of bytes back to a functioning object.

Compare Java objects to IKEA

A good metaphor for this process would be to compare java objects to IKEA furniture. The serialization process goes as follows. In the store, you see a chair, for example, the ‘Börk’. You write the article number down and head to the warehouse. There you pick up the brown flat packs for ‘Börk’ and you head home. You unpack the boxes, take out the manual and reconstruct your ‘Börk’. The takeaway is that you don’t know what is in the box you picked up in the warehouse until you open it up at home.

Compare Java objects to IKEA

Basic premise

Now imagine some insidious culprit replaced the contents of your flat pack with a ‘Blarg’ table. Surely you would figure this out after the first few steps in putting all the parts together: “Hey, I thought I was building a chair”. But maybe step one of the instructions told you to ‘unlock your front door for safety’ and you did that, just as asked. This is the basic premise of ‘unsafe deserialization’.

Populating variables

Every Java object that can be flattened has to implement the Serializable interface so that Java knows it can turn it into a flat pack. Whenever your object arrives at location, Java recreates it and during this process, as defined in the interface, it calls upon the ‘readObject’ function to help populate variables. This method runs once before any other code has a chance to examine the object. It’s like the quick start leaflet that came with your flat pack. Luckily, your Java application server only accepts leaflets for objects it is already familiar with.

Accept flat packs

But as some heroes figured out (see this video), one could construct a chain of objects that has unintended side effects in the process of deserialization, for example, allowing for execution of shell code.

If you have an interface in which you can feed a serialized object, it will happily accept these doctored flat packs. Even if you write code that checks the object type, the moment Java recreates the object the chain is triggered.

         FileInputStream fileIn = new FileInputStream("./badobject.ser");
         ObjectInputStream in = new ObjectInputStream(fileIn);
         Object suspect = in.readObject();  // CHAIN RUNS HERE
         if (!String.class.isInstance(suspect)) {

                               System.out.print("Never mind, already broken");

A number of ways were found to be able to do so using classes in commonly used libraries. In 2015 they found 4 and kept on searching. Now they are at 30. The libraries with which they managed this trick are used in most Java applications. For example they have chains using Apache Commons Collections, Spring, Wicket and JSON-lib.

Let’s reflect

1. You don’t actually need to use these libraries in your code, they just need to be in the class path of your virtual machine.
2. It could be that you didn’t even deliberately included these libraries in your class path, but your build tool (or another jar) decided it was a dependency.
3. A possibility could be that chainable classes weren’t even in your application. Here you will find an incomplete list of third party libraries loaded by WebLogic. A number of these can also be found in the mentioned 30 libraries.
4. Preventing or limiting deserialization in any way breaks compatibility. This problem cannot be fully patched, as according to the code this is a correct use of java.
5. Any interface that deserializes java objects is thus an attack vector.

Interfaces to deserializing

Such an interface found in almost every WebLogic installation is the Admin Console Port (7001 by default), mentioned in the majority of high CVSS exploits. Another was the WLS WSAT URL (CVE-2017-10271) that I hope everyone fixed earlier this year. Probably, most of the more exotic Oracle products that have received less scrutiny from the public have vulnerable interfaces as well.

Limits by WebLogic

OWASP advises to whitelist specific classes in your interfaces when programming, but this can’t be done in WebLogic, as this would break existing programs. The approach Oracle has chosen seems to be to buffer the deserialization process and browse the incoming bytes for the names of known vulnerable objects, then blacklist these and block deserialization. To continue on our metaphor it would be disallowing people to buy a ‘Blarg’ in a flat pack. 

You can find the blacklist in the WebLogic code (as demonstrated by in the class:

Game of whack-a-mole

Oracle’s approach is a game of whack-a-mole. Oracle blocks one class, someone manages to tinker a new way in which the chain evades the blocked objects and voila, your WebLogic instance is vulnerable again. This happened to the Oracle April Critical Security Update – as one of our customers pointed out, this fixed CVE-2018-2628 and as the details were released someone casually mentioned how to bypass this fix by swapping a single class.

Two ways to solve this would be to either come up with an optional whitelisting concept or a separate, safe set of methods to inspect objects before instantiating them, but both will break compatibility on these interfaces.

The brave can try an external fix like this one (place the contrast-rO0.jar in your DOMAIN/ lib Directories). This is in no way supported by Oracle. Until this is figured out, you cannot trust in just Oracle patching.

How to mitigate

To conclude, short and simple: this vulnerability will remain. It is a certainty that more exploits will be found. But they will all be variations on the same concept. 
To mitigate all of them, I would refer to my former article on hardening.


  • Always place a HTTP Proxy between your WebLogic instance and the internet or user network.
  •  Do not allow direct access to Port 7001 from the LAN. Use whitelisted machines.
  • Keep up to date with the quarterly Oracle CPUs, do not miss any of them.
  • Limit file permissions for the WebLogic process owner.

Monitoring for intrusions

Note that the WebLogic blacklist throws a specific exception when it encounters a blacklisted class ‘Unauthorized deserialization attempt’. You should take precautions when you come across this specific log message.

Given the explanation above, you should now understand that a) your system is always vulnerable and b) this error shows someone found an interface that can deserialize objects and is actively attempting an intrusion.

More information?

For more information, please contact Qualogy by phone on +31 (0)70 319 50 00 or by e-mail:

Mark Otting
About the author Mark Otting

Mark is an administrator with more then 10 years of experience in Weblogic server, the Oracle Service Bus and Oracle SOA Suite. Coming from a background as a developer and having a broad spectrum of technical interests, he is often found in the role of linking pin and troubleshooter between departments. His specialties include optimising, system administration, both on the technical as on the governing aspects.

More posts by Mark Otting