Why The Java Deserialization Bug Is A Big Deal
A recent blog post by FoxGlove Security that described remotely executable exploits against several major middleware products including WebSphere, WebLogic, and JBoss has focused attention on what some say is an extremely dangerous but wholly underrated class of vulnerabilities.
The so-called Java deserialization vulnerability affects virtually all apps that accept serialized Java objects and gives attackers a way to gain complete remote control of an app server. Security researchers believe that potentially millions of applications -- both commercial and internally developed-- are susceptible to the issue, which is not easily mitigated.
Though researchers have been aware of the vulnerability for some time, few have paid much attention to it because there have been no working public exploits against applications until now. But FoxGlove’s demonstration of how the flaw can be exploited using a tool released about nine months ago has heightened concerns around the issue.
“It’s a big deal because many enterprise applications are vulnerable,” says Jeff Williams, chief technology officer at Contrast Security, which released a free tool for addressing the issue.
The vulnerability allows attackers to completely take over the server on which the application is hosted and create all sorts of havoc.
“They could steal or corrupt any data accessible from that server, steal the application's code, change the application, or even use that server as a launching point for further attacks now that they are inside the data center,” Williams says.
Here’s what you need to know:
What is the vulnerability called?
That depends on whom you ask. Some of have called it the Java Deserialize vulnerability, others have it as Java Unserialize flaw, while some simply call it the Java Object Serialize flaw.
What exactly is the vulnerability all about?
The vulnerability exists in the manner in which many Java apps handle a process known as object deserialization. As Williams describes, serialization is a technique that many programming languages use to transfer complex data structures over the network and between computers.
It’s a process in which a Java object is essentially broken down into a series of bytes to make it easier to transport and then reassembled back into an object at the other end. The disassembling process from an object into a sequence of bits is called serialization, while the reassembly from the bits back to an object is called deserialization or unserialization.
The problem lies in the fact that many apps that accept serialized objects do not validate or check untrusted input before deserializing it. This gives attackers an opening to insert a malicious object into a data stream and have it execute on the app server.
“In this attack, special objects are serialized that cause the standard Java deserialization engine to run code of the attacker’s choosing,” Williams says. “It’s not exactly a problem in Java, or in any particular libraries. It’s just a powerful functionality that organizations shouldn’t expose to untrusted users.”
What exactly did FoxGlove do?
FoxGlove showed how the vulnerability could be exploited in WebSphere, WebLogic, JBoss, Jenkins, and OpenNMS.
Each of these applications includes a Java library called “commons-collections” that provides a method that leads to remote code execution when data is being deserialized, says Stephen Breen, principal consultant and developer of the attacks against the five middleware apps. Ideally, when data is being deserialized, no code should execute during the process.
Breen generated the payloads for his exploits using a tool called “ysoserial” released about 10 months ago by security researchers Chris Frohoff and Gabriel Lawrence at AppSec California 2015. In a presentation titledMarshalling Pickles, the two researchers demonstrated proof of concept code for exploiting Java object unserialization vulnerabilities and showed four different ways they could do it using the ysoserial tool.
“The bug is on both sides in my opinion; but others may disagree,” Breen says. “The commons-collections [library] should not provide a method that leads to remote command execution simply by deserializing untrusted data” he said. “This is unsafe due to the history of the way serialized objects have been used in Java.”
At the same time, app vendors and ad developers should not be unserializing untrusted data. “There could be other libraries besides the commons collection that allow for exploitable scenarios, and it’s generally not a good idea.”
What are the implications for enterprises?
Williams says the first thing enterprises need to do is find all the places where they are using deserialization on untrusted data, and harden it against the threat. “Searching [the] code is only a partial solution, because frameworks and libraries that they are including in their applications might also create this exposure.”
He pointed to a tool released by Contrast Security called Runtime Application Self-Protection (RASP) that adds code to the deserialization engine that prevents it from being exploited.
Removing commons collections from app servers running the library will not help entirely because other libraries could have a similar problem, Breen said. “It may be a good mitigation, but does not address the core problem.”