Java Deserialization Problem with Apache Commons Collection

The Deserialization problem is one of the most widespread security vulnerabilities to occur in the last couple of years. This blog provides a brief explanation of the Java Deserialization vulnerability with Apache Commons Collection API.

Introduction

Image credits : Serialization - Deserialization

The process of converting a memory object into a stream of bytes in order to store it into the filesystem or transfer it to another remote system is Serialization. Deserialization is the reverse process that converts the serialized stream of bytes back to an object in the memory of the machine. All the major programming languages provide these functionalities and most of them are inherently unsafe. Recent findings have demonstrated that the Java applications and frameworks that allow Remote Command Execution are popular for deserialization attacks. The main class for these attacks is InvokerTransformer which is present in the Apache Commons Collection library. This class gained attention mainly because of the popularity of the Apache Commons Collection (ACC) library. Any application, server or framework that depends on the Apache Commons Collection was potentially vulnerable. Some of the affected systems were JBoss, WebLogic, WebSphere and Jenkins.

How InvokerTransformer class allows an attacker to exploit the system?

The goal of the InvokerTransformer class is to transform objects in a collection by invoking a method using reflection. Attackers abuse this transformation functionality and manage to invoke any method they want. It invokes the Runtime. exec() that executes arbitrary commands on the target system.
In order to achieve this, attackers craft a method sequence to abuse InvokerTransformer and make it invoke arbitrary dangerous methods, such as the Runtime. exec().Each method in this sequence is called a “gadget” and the malicious sequence of these method calls is known as a “gadget chain”.In the case of Apache Commons Collections, the InvokerTransformer is a gadget in the malicious gadget chain.

The attacking mechanism can be summarized in the following steps:

1) A vulnerable application accepts user-supplied serialized objects.
2) Attacker creates a malicious gadget chain, serializes it into a stream of bytes and sends it to the application.
3) The vulnerable application reads the received stream of bytes and tries to construct the object. This operation is called “deserialization”.
4) During deserialization, the gadget chain is executed, resulting in a compromised system.

Variations of Java Deserialization attacks

There are three variations of the Java deserialization attacks
1) Blind deserialization attacks: It aims to extract data from the target system in environments where the system is behind a network firewall that blocks outgoing connections or when strict Security Manager policies are in place.
2) Asynchronous (or stored) deserialization attacks:  It stores gadget chains in a database or a message queue. Then these gadget chains will be executed when the target system reads data from the database or the message queue and deserializes them.
3) Deferred-execution deserialization attacks: It doesn't execute the gadget chains during deserialization, but rather after deserialization has completed. This is usually achieved with the finalize() method during garbage-collection.

Only two criteria are required for a Java deserialization vulnerability to be introduced into the system:

1) The software must accept and deserialize serialized data from a location where an attacker has access.
2) “Unsafe” classes or gadgets must exist in the classpath of the application.

Conclusion

This concludes that it is not enough for an application to just use a “vulnerable” version of the Apache Commons Collection in order to be vulnerable. It must also deserialize data from unsafe locations too. That's why the Apache Foundation claimed that the InvokerTransformer and other such classes that implement a certain functionality cannot be blamed for this vulnerability. It is the combination of both the above criteria that introduces the vulnerability. The InvokerTransformer itself is not vulnerable.