Remotely Exploitable Java Zero Day Exploits Through Deserialization

This is not so much a "zero-day" vulnerability, since the topic was discussed back in January, albeit with little fanfare.

That it did not receive much attention until last week, doesn't mean it's really a sudden exploit discovered being used maliciously in the wild.

This was a tech talk intended to broach the subject of dangerous, but standard features of the Java serialization API, providing a demonstration of proof of concept attack vectors.

The truth is that this is not actually a bug. The code works as the design of the OPTIONAL THIRD PARTY library intends. The problem is that this is code that people carelessly deploy, accidentally exposing themselves to attack, failing to understand the full scope and capabilities of their servers and the features they've accidentally included by default.

The TL;DR

Java Deserialization can be used to construct arbitrary Java objects, which combined with popular libraries such as Apache Commons Collections, Spring or Groovy can result in arbitrary code execution on the server providing deserialization.

Java app servers often provide automatic deserialization of Java objects passed as cookies, or provide protocol or admin ports (typically built on RMI or JMX) that can be used to trigger exploits. This includes Jenkins' remote CLI service; Cloudbees have provided a security vulnerability warning about this.

There's no trivial way of protecting against this attack other than deleting some classes from various libraries; however, given their ubiquity in other application servers this may provide nearly impossible to do.