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

Dinis Cruz dinis.cruz at owasp.org
Tue Aug 6 23:41:27 UTC 2013

Yeah XXE is an interesting angle, Alvaro had already discovered that is was
possible <https://twitter.com/pwntester/status/364849431025168384> to
trigger it via XMLDecode, but I run out of time to add it to the demos.

In terms of exploiting this, how would you do it on the Restlet (and other
REST) API?. We don't get the XML back, so how would you use XXE to get/see
the file contents?

Note that Abe and Alvaro did the main research here (and Abe is the one
that created the slides), so they are the ones that deserve the credit (I
just created some of the PoCs)

Btw, I've uploaded the presentation to
there are a couple slides on XXE on it.


Dinis Cruz

Blog: http://diniscruz.blogspot.com
Twitter: http://twitter.com/DinisCruz
Web: http://www.owasp.org/index.php/O2

On 6 August 2013 14:51, Christian Schneider <mail at christian-schneider.net>wrote:

> Hi Dinis,
> nice blog post and DefCon talk ;).
> I guess that for Oracle its obvious to use JAXB or other techniques when
> it comes to XML/object mapping scenarios where the XML is not trusted,
> instead of using the XMLDecoder. In Java XMLDecoder is treated more like an
> object serialisation with an XML-spin on it (instead of binary formats). So
> I can imagine some applications using this for accessing config or other
> data storage that should be probably human-readable, but only used
> application-internal and not exposed to the outside. For all other
> object/XML marshalling stuff JAXB or similar techniques should be used, not
> XMLDecoder.
> But as you already pointed out, this is quite missing in the docs and some
> frameworks also might use XMLDecoder for processing untrusted XML, causing
> the attack scenarios you mentioned in your nice talk at DefCon. So as
> always in security: its a matter of knowing what technique to use for what
> purpose and what better to avoid.
> Just to add one more to the list of your blog post:
> I've quickly tested a XXE (Xml eXternal Entity) attack against the XML
> file. Guess what: works too ;).
> <?xml version="1.0" encoding="UTF-8"?>
> <!DOCTYPE java [ <!ENTITY c SYSTEM "file:///etc/passwd">]>
> <java version="1.7.0_10" class="java.beans.XMLDecoder">
>  <string>&c;</string>
> </java>
> When unmarshalled using XMLDecoder it reads the file.
> Just to let you know that this is another attack scenario, though the
> remote code exec is worse...
> Best regards,
> Christian
> --
> Christian Schneider
> Software Developer, Whitehat Hacker & Trainer
> Phone: 0178 3081340
> Twitter: @cschneider4711
> Email: mail at Christian-Schneider.net
> Web Application Security Blog: www.Christian-Schneider.net
> On Aug 6, 2013, at 2:38 PM, Dinis Cruz <dinis.cruz at owasp.org> wrote:
> Hi, where you aware that XmlDecoder could be used this way:
> http://blog.diniscruz.com/2013/08/using-xmldecoder-to-execute-server-side.html (see
> examples at the end)
> Me and Abe presented that last week at DefCon and the awareness was very
> low.
> I'm also sure that there are other dangerous/exploitable uses of
> XmlDecoder on other REST or web apis.
> Finally what about fixing/mitigating this? It looks like Java Sandboxing
> using the Security manager is one option, but even that will not be safe,
> since the attacker will be able to attack the application assets.
> Any other ideas?
> Dinis Cruz
>  _______________________________________________
> Java-project mailing list
> Java-project at lists.owasp.org
> https://lists.owasp.org/mailman/listinfo/java-project
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.owasp.org/pipermail/owasp-leaders/attachments/20130807/e2316c39/attachment-0001.html>

More information about the OWASP-Leaders mailing list