For close to 10 months, a critical vulnerability in a library found in most Java rollouts has been twisting in the wind, unpatched, and until this week without proof-of-concept exploits that people paid attention to.
Two researchers with NTT Com Security changed that dynamic last week when they released PoCs that leverage the bug in the Apache Commons Collections library. The exploits figure to put a prominent face on the vulnerability, which is being patched by Apache Commons, since they target massive middleware platforms including Oracle WebLogic, IBM WebSphere, Red Hat’s JBoss, Jenkins integration server and the OpenNMS, an open source system and network management platform that relies on Java.
Researchers Gabriel Lawrence and Chris Frohoff did the original research on the unserialize vulnerability in the Commons Collections library, and in January presented it at AppSecCali 2015. Lawrence and Frohoff’s vulnerability can be used to remotely attack the library using a single maliciously crafted packet to run code on the underlying operating system. Stephen Breen and Justin Kennedy of NTT Com Security built from the original work to develop the exploits dropped last week.
While Apache Commons has told Breen and Kennedy that a patch is being developed, there had been debate within the bowels of the Java community as to who should patch the bug: Apache Commons? Affected vendors? Oracle? Breen and Kennedy said Oracle was notified in July but no one had disclosed the issue to the Apache Commons team until recently. Jenkins has already mitigated the issue on its platform.
“My reasoning [for disclosure] was that I found out about this on a Monday and developed exploits for five products by Wednesday,” Breen said. “Given that simple piece of knowledge that’s been available in public for nine months without anyone doing anything about this, we didn’t feel it was worth keeping secret.”
Breen said the vulnerability is relatively easy to exploit.
“We talked to lots of Java researchers and none of us had heard of [the vulnerability]. It was presented at the conference and made available online, but no one picked it up,” Breen said. “One thing it could be is that people using the library may not think they’re affected. If I told you that Apache Commons has an unserialize vulnerability, it probably wouldn’t mean much. But if I tell you JBoss, Jenkins and WebSphere have pre-authentication, remote code execution vulnerabilities, that means a lot more to people. The way it was originally presented, it was an unserialize vulnerability in Commons.”
Serialization is a process the library in this case uses to convert user input to a static binary form that can be stored or sent over a network. Unserialization, Breen and Kennedy explain in a blog post, is the opposite and is the process by which the static data is converted to something the user can do. The vulnerability arises because the library does not properly sanitize user-provided input, and an attacker can append malicious code to input that is accepted and executed.
“It allows you to do anything on the underlying operating system,” Breen said. “This library is used in a lot of places, and it’s a common practice for Java developers to deserialize things like this for a long time. The big impact would be on companies’ internal networks. Most of the services we attacked, for the most part, won’t be accessible from the Internet. But hundreds of other products use Java serialization and some that are exposed to the Internet could be vulnerable.”
Once a patch is available, the researchers caution, it will still be difficult to update. Similar to Shellshock and its massive interdependencies, given that the Commons Collections library is customized to run on particular apps, each one would have to likely be found and updated manually.
“Shellshock was a bug in Bash and you could easily update Bash and fix it, but no one said the bug was in Apache and hundreds of other products that use Bash,” Jenkins said. “The problem here is that this will be difficult to update.”
They also figure it will be difficult to detect.
“For different application servers, the attack scenario is different,” Breen said. “You would just send a [crafted] packet and it runs in memory. Nothing touches the disk making it extremely unlikely it would be caught by an IDS or IPS because it’s encoded in a Java object. It’s unlikely to be seen there.
“It’s a pretty bad one for sure.”
