Java deserialization vulnerability CVE-2015-4852 more widespread than expected

Vulnerability CVE-2015-4852 has been detected in widely used Apache Commons Collections library. The vulnerable library in question is in use in various software, such as WebLogic. The problem is not, however, limited solely to Apache commons-collections library, but instead its root cause lies in the serialization mechanism of JAVA classes.

Along with serializable JAVA classes it is possible to deliver malicious objects into a system through the vulnerable service. These can then be used to execute commands in the system, meaning that any applications can be run. It therefore makes it possible to run system level applications/commands.

Typical places wherein serializable classes are used in Java are:

1. HTTP requests, parameters,  state information, cookies etc.
2. RMI (Remote Method Invocation), 100% based on serialization
3. RMI over HTTP – also 100% based on serialization
4. JMX (Java Management Extensions) 100% based on serialization

In some cases both problematic serialization practices can be found. Classes are serialized using the commons-collections library and also directly (root cause). Updating Apache Commons Collections library fixes some of the problems, but not all.

Due to the problem’s scope and several places where the root cause is in use (Java class serialization), fixing the problem is not possible merely by updating the commons collections library. The following recommended solutions for fixing the problem exist:

1. Updating Apache Commons Collections from version 3.2.1 to 3.2.2

2. Complete isolation of unused application end-point URLs from the external network using Apache or load balancer product (whitelist for permitted addresses)

3. Complete isolation of dangerous application parameters from the external network using Apache or LB product (whitelist for permitted parameters)

4. Performing steps 2 and 3 also within the internal network as strictly as possible. Problems can be caused within the internal network also by, for example, using CSRF model attacks. Note: Restricting access to internal network does not fully protect from the vulnerability, because the attack is also possible through a link delivered via e-mail.

It also needs to be taken into account that the same vulnerability may be open in all such Java services that make use of Java’s serialization features. In such cases the first fix is to update Commons Collections to version 3.2.2, if this library is in use. In addition, in these applications it is sensible to check separately, how each application uses the serializing classes and how interfaces handling them have been implemented and where can they be accessed from. Services visible in application servers’ default installations can also cause problems and should be checked (for example, JBoss / Weblogic). The vulnerable Commons Collections version can also come from the application server’s class path (for example, Jboss EAP 6.0 – 6.3). On the whole, the vulnerability is especially widespread and more applications, frameworks and libraries open to it will likely be discovered.

We have researched and developed several ways and methods for detecting vulnerable applications here at Nixu. If you are interested of learing more about the topics or help to detect your own Web services we are pleased to offer help.

The author Teemu Kääriäinen is working as a senior identity and access management specialist in Nixu IAM unit.