Defending against Java Deserialization Vulnerabilities

During a recent OWASP Meetup in San Francisco, I gave a presentation on Java Deserialization vulnerabilities focused on defense techniques for identifying and fixing this class of bugs.

While most of the content is based on the work of several Java Security aficionados (@cschneider4711, @e_rnst, @matthias_kaiser,  @pwntester, @frohoff and many others), this presentation contains a couple of new things:

  • Technical details (and exploit) of a serialization bug via JSF view state affecting Sun Java Web Console
  • New features introduced in SerialKiller 

Sun Java Web Console serialized object injection via JSF view state

Since it appears that there're no publicly disclosed details on Java serialization vulnerabilities triggered via JSF ViewState, I thought it would be a good idea to illustrate a bug I discovered in 2010. From slides 12 to 17, you can read more about this issue affecting Sun Java Web Console (which was the default web admin console for Solaris). I've also released an exploit (download here) that uses Hashtable collisions to trigger DoS. RCE is also possible via Apache Common Collections.

Interestingly enough, old versions of javax.faces.ViewState (client-side and with no signature) can be abused in multiple ways:

SerialKiller v0.4

I've released a new version of SerialKiller with new features and improvements:
  • Basic logging support, using Java's native logging
  • Profiling mode. While look-ahead whitelisting provides a robust protection to modern applications, it requires complete enumeration of all Java classes exchanged by the application. With this feature, it is possible to setup SK in "non-blocking" mode in order to enumerate all classes within client-server requests. A step-by-step tutorial on how to whitelist classes is available in the documentation page
  • Signatures parity with Ysoserial. I've created default blacklisting signatures for all exploits (as of 09/07) included in this popular payloads generator tool

Fixing Java Serialization Bugs with SerialKiller

On Friday, FoxGloveSecurity published a rather inaccurate and misleading blog post on five software vulnerabilities affecting WebLogic, WebSphere, JBoss, Jenkins and OpenNMS. By incorrectly attributing the vulnerability to the Apache Commons Collection library, the blog post generated misinformation on the root cause and possible fixes (e.g. this news.softpedia article).

If you're still unsure on what is the actual issue, Charles Miller published a short blog post illustrating the problem.

Probably thinking that the Apache project wasn't interested in fixing the bug, FoxGloveSecurity's post also contains working exploits for all products.

In fact, even though proof of concept code was released OVER 9 MONTHS AGO, none of the products mentioned in the title of this post have been patched, along with many more. In fact no patch is available for the Java library containing the vulnerability.

As it turned out, some vendors were not aware and others were already working on a patch in their products but haven't released it yet.

Summing up, we're now dealing with five pre-authentication remote code execution vulnerabilities affecting major products. Luckily, the specific services affected by those vulnerabilities are generally not exposed over the Internet thus reducing the overall risk.

Inspired by this story, I started thinking on how I could fix the problem in a systematic way. It didn't take me long to discover this article on using method override to create a look-ahead deserialization filter. While the article explains a potential solution, it didn't provide an easy-to-use library that can be used to protect Java applications.

Introducing SerialKiller

SerialKiller is an easy-to-use look-ahead Java deserialization library to secure applications from untrusted input. You drop the jar in your classpath, use SerialKiller instead of the standard and configure it to allow/block specific classes.

The library, together with a simple tutorial, is available on Github:

At the moment, it supports the following features:

  • Hot-Reload for the config file, so that you don't need to restart your application after changing SerialKiller's config
  • Whitelisting.  If you can quickly identify a list of trusted classes, this is the best way to secure your application. For instance, you could allow classes belonging to your application package only
  • Blacklisting. The default config file already includes a few known attack payloads (thanks to YSoSerial). This can be used to block the exploits released by FoxGloveSecurity

If you want to contribute, ping me on Twitter or using Github.

Unofficial security patch for Ubiquiti Networks mFi Controller 2.1.11

On September 3, 2015 SecuriTeam disclosed a vulnerability in the Ubiquiti Networks mFi Controller, a software to configure and control automation devices such as power outlets, light/motion/temperature sensors, etc. To understand the capabilities of the machine-to-machine platform, please have a look at the vendor page.
The security flaw allows an attacker to retrieve the current admin password due to a bypass in the authentication mechanism used by the mFi Controller Server.
Just few hours after the public release of the SSD Advisory – Ubiquiti Networks mFi Controller Server Authentication Bypass, the page was removed to accommodate the vendor's request since a patch was not available for download. According to the advisory and Noam Rathaus's tweet, the vendor was aware of this critical vulnerability since the beginning of July 2015.

Digital Self-Defense

Considering that the advisory published on 09/03/2015 contained a technical description of the vulnerability, including a reliable exploit, it is reasonable to assume that the security flaw can be easily abused by unsophisticated attackers. While the information was removed from the SecuriTeam website and /r/netsec, a quick search on Google is sufficient to find the exploit for this bug.
Despite the public exposure, Ubiquiti has yet to publish a patch.
After waiting patiently for a few weeks, I created my own patch. Using mFiPatchMe, you will be able to easily patch your controller and leave it running without worries.
You can download the Unofficial Security Patch for Ubiquiti Networks mFi Controller 2.1.11 from here:
Disclaimer: This is NOT an official patch provided by Ubiquiti Networks