Showing posts with label REST. Show all posts
Showing posts with label REST. Show all posts

Thursday, 20 March 2014

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.

Sunday, 22 December 2013

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:
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.

Tuesday, 6 August 2013

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:

WP_20130804_002