Object serialization in Java language
To understand everything concerning this type of vulnerabilities, and for those who have little programming experience, first, you need to know is: what is object serialization.
Object serialization is nothing more than the conversion of an object into a format (p.e. a byte stream) which then can be stored or transmitted , likewise, there must be an inverse process to convert this data back to an object or retrieve the object, this process is called deserialization.
Who know Java programming know we can do this through the following code:
What the previous code does is to serialize a Java object and then save it in a file using the “writeObject” method, this will generate a binary file that contains the binary representation of the object (as a binary stream), the only requirement is that the object must implement the Serializable interface.
To deserialize the object of the previous example, we can do it through the following code:
Object serialization in Java language has two important behaviors, that we must consider when programming, as well as to understand its operation and application:
- Only the data and structure of the objects are serialized, not code.
- If the class contains code, it must at least reside at the deserialization point.
I’m not going to give a detailed explanation of how it works internally, because it’s not necessary, however, if you want more information about this Java language feature, there is a lot of resources on the Internet that can help you .
Exploiting Java object serialization vulnerabilities
At first glance there seems to be no problem or danger with object serialization as this feature only converts the data and the structure of the objects (not code), however, there is a problem with it, this is found in the JRE libraries, as well as in third-party libraries (packages), the problem is because some events, which are specific to internal objects of JRE, make use of a language instrumentation feature called «Reflection». This feature allows the dynamic execution of Java code, which can be very insecure because if in some way we include or trick those classes that contain the events, we could get arbitrary code execution on the side where the deserialization takes place.
This type of vulnerabilities is not new, but recently and thanks to the works (articles, conferences, and others) of @frohoff and @gebl that created several «Gadgets» or snippets of code that achieve the arbitrary command execution on the system, have allowed to popularize and force the affected companies to take serious measures on the subject.
The AnnotationInvocationHandler class is necessary to automatically execute the payload, since the method that performs its deserialization (readObject), invokes the entrySet method of the proxy object in which a chain of classes (Transformer) is configured performing the dynamic execution of the payload.
These Gadgets can be created using some classes in third-party libraries (eg common-collections) and it’s even possible to use the own libraries of the JRE, currently, there are tools that allow us generating different payloads (ysoserial ).
The following is the Java code used to create the previous Gadget:
In this way, after sending the serialized Gadget to the deserialization endpoint and once the call to readObject is performed on the byte stream, it will automatically execute our payload that commonly contains a call to Runtime.getRuntime().exec() method, which will execute the command that we specify.
Given the emergence of a high number of vulnerabilities of this type, after a long time (about 20 years) Oracle decided to implement some countermeasures in its JDK (Java SE 8 CPU Update 121) in order to mitigate this problem, then they introduce a new security feature: serialization filters , Black List y White List, with the purpose of preventing developers from making use of some classes considered unsafe. This measures certainly does not end with this kind of attacks, although it can be reduced with the use of good practices by programmers. However, in my opinion, the most effective solution can be better oriented in avoiding that the developers perform dynamic execution of methods using «Reflection«, this should not be a functionality enabled by default, of course, a change like this is quite strong and can affect some libraries already developed, which would have to be updated or re-implemented.
The case of Oracle WebLogic Server
As almost everyone already knows, Weblogic is a container of Java applications, unfortunately Weblogic uses for its control a proprietary protocol called T3, in this protocol a handshake is initially performed, and then a request is made where a list of serialized Java objects are attached, these objects allow executing the administrative functions provided by the service. The severity lies in the fact that, without having to authenticate, it is possible to send malicious serialized objects and achieve remote code execution.
Currently, there are five important vulnerabilities that use object serialization and affect multiple versions of WebLogic, they are the following:
As a small contribution to the security community, I’ve developed three Metasploit modules that take advantage of some of these vulnerabilities, other vulnerabilities already are included in the Metasploit framework.
- CVE-2015-4852: Through object serialization, it achieves RCE – weblogic_serialize_rawobject .
- CVE-2016-3510: Through a MarshalledObject object it achieves RCE – weblogic_serialize_marshaledobject .
- CVE-2017-3248: Through serialization of an UnicastRef object it creates an inverse connection using JRMP from the server in which the payload is sent achieving RCE – weblogic_serialize_unicastref .
Currently these modules have not been added to the Metasploit main repository because the release cycle has not been completed, however, you can try them out and use by manually adding them to the framework. In the references section, you can take a look at the pull requests, discussions, files and code.