Do you deserialize Java objects? Jenkins zero day and vunls in WebLogic, WebSphere, JBoss, OpenNMS and Appache commons

Last week the What Do WebLogic, WebSphere, JBoss, Jenkins, OpenNMS, and Your Application Have in Common? vulnerability research was published and it included a number of quite worrying exploits on Java apps, more specifically on apps that use the Apache commons library (update: it looks like this is not a vuln in Apache commons, but in how it is used).

This is following up the Java Deserialization research published earlier this year on Marshalling Pickles and Exploiting Deserialization Vulnerabilities in Java (which is a variation of the XStream/XMLDecoder vulns/research I was involved in 2013)

It also looks like the Jenkins issue mentioned in the latest research doc is a zero-day on Jenkins: Mitigating unauthenticated remote code execution 0-day in Jenkins CLI

Since this is a vulnerability that allows RCE (Remote Code Execution), it is really important to understand the internal/external exposure to java deserialization, Jenkins and apache commons usage.

Updated presentation of 'RESTing On Your Laurels will Get YOu Pwned' (RSA version)

At the last RSA conference, Abe and Alvaro presented an updated version of the RESTing On Your Laurels will Get YOu Pwned presentation (originally delivered by me and Abe at DefCon 2013).

Here is the description

Public REST APIs have become mainstream. Now, almost every company that wants to expose services or an application programming interface does it using a publicly exposed REST API. This talk will give participants the skills they need to identify and understand REST vulnerabilities. The findings are a result of reviewing production REST applications as well as researching popular REST frameworks.   

By Abraham Kang, Alvaro Muñoz and Dinis Cruz

In addition to the original demos we did, Alvaro added a nice Metasploit PoC which really should drive home the problem with XStream and XMLDecoder.

3 Patterns for deserialising Xml into Objects (1 good and 2 very dangerous (XStream and XMLDecoder)) and a bunch of questions on how to handle them

When me and Abe where at DefCon working on the final version of the slides for the RESTing On Your Laurels will Get YOu Pwned  presentation, we come up with a nice way to talk about the different approaches that can be taken when converting XML into Objects (the examples here are in Java, but this also applies to other languages/APIs).

XStream "Remote Code Execution" exploit on code from "Standard way to serialize and deserialize Objects with XStream" article

At the DefCon 2013 I co-presented (with Abraham and Alvaro) the "RESTing On Your Laurels will Get YOu Pwned", which showed a number of PoCs on how REST interfaces and APIs can create a number a security vulnerabilities:

Since that time, I have blogged about a couple of the demos created:

• XmlDecoder JDK class: Using XMLDecoder to execute server-side Java Code on an Restlet application (i.e. Remote Command Execution)
• Groovy on Admin Interfaces: Neo4J CSRF payload to start processes (calc and nc) on the server 

We also showed a PoC using the XStream API (which had been reported to the XStream developers) which so far has not made it into a blog post (the PoCs presented at DecCon are here and here).

Since a quick search for 'XStream Vulnerabilities' only shows a couple examples (Spring Source OXM Remote OS Command Injection when XStream and IBM JRE are used, JAVA RESTful Services | Fuzzing Down the Rabbit Hole: Part One  and this git commit), I think it is fair to say that this is issue is still quite unknown.