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.

Slides for DefCon presentation on "RESTing On Your Laurels will Get YOu Pwned"

Here are the slides for the DefCon talk Me, Abe and Alvaro presented at DefCon 21

Using XMLDecoder to execute server-side Java Code on an Restlet application (i.e. Remote Command Execution)

At the DefCon REST Presentation we did last week (see slides here), after the Neo4J CSRF payload to start processes (calc and nc) on the server demo, we also showed how dangerous the Java’s XmlDecoder can be.

(tldr: scroll to the end of the article to see how to create an XML file that will trigger an reverse-shell from an REST server into an attacker's box)

I have to say that I was quite surprised that it was possible to execute Java code (and start processes) from XML files!

Abraham and Alvaro deserve all the credit for connecting the dots between XMLDecoder and REST.

Basically what happens is that the Java’s JDK has a feature called Long Term Persistence which can be used like this:

Neo4J CSRF payload to start processes (calc and nc) on the server

The first demo that we showed at the DefCon REST Presentation was how to use CSRF to exploit the Neo4J remote code execution feature (provided by groovy).

The reason CSRF was used, is because by default, the REST API that allows the web UI to pass a groovy script, is only available on localhost.

Abe and Alvaro's concern (and the reason we showed this in action) is that a considerable number of Neo4J admins fail to read the guidance provided here: http://docs.neo4j.org/chunked/stable/security-server.html

Back in London from DefCon and ALL research materials are now available on GitHub

The DefCon presentation on REST Security and Exploitation went great :)

The slides and demos worked out ok, there was a good crowd, and there was lots of great iterations/reactions from the attendees:

Can you join us for lunch?

With this simple words me and OWASP's Joanna had a great lunch with two complete strangers (to us) at DefCon 21.

We were going into a local restaurant at Rio's hotel when they (a couple on first trip to DefCon) asked us to join them. They said that they wanted to meet new people and we looked decent enough :)

They were both from LA. He was was the director of a local web development company and she was a lawyer.

The conversation was wide ranging, and it was great to hear how he used to work for a financial company (doing financial analysis for tech acquisitions), but quit due to the lack-of-values and wrong-motivations in that world (i.e he left the dark-side).

What he has found is that our community (software development, hackers, web app security) is a much more value-based world/society, with a lot more of 'good people'

Day 5 - DefCon 2013 - roundup of what happened

Since my Day 1 post, a lot has happened and I'm finally on the way home.

After all the adrenaline, my brain is starting to shutdown so here is a brain dump of the highlights of DefCon 21:

Email (outlook.com, gmail) should be stored on a git repository, with hashes used to detect account hijack

On the topic of being secure (and minimising account compromise) while using hostile networks (see Day 1 - made it to Vegas, start of ASP.NET MVC research  and Trying to keep secure while at BlackHat and DefCon 2013) I started using outlook.com, and was wondering how can I detect if that account is hijacked (for example by somebody who has a root SSL cert and is sitting on the same wireless network that I'm in (currently at Starbucks using the Mirage WIFI))

So what happens if somebody sends an email from this account:

How could I detect it?

Day 1 - made it to Vegas, start of ASP.NET MVC research

So after an 18h flight (with stopover in Toronto) I made it to Las Vegas. It was a really productive flight and I was finally able to spend some time focus on really learning how the ASP.NET MVC actually works.

I read a large section of Professional ASP.NET MVC 4 book (by Wrox) which is a great way to quickly learn what can be done with MVC 4. Although still very light on security, that book is actually one of the best ones (of all ASP.NET MVC books I have) on 'mentioning' security. Unfortunately, on the ModelBinding vulnerabilities (aka over-posting), there is very little to alert the reader for the dangers of MVC's ModelBinding.