There are many Struts 2 developers familiar with the Struts 2 development mode on which more verbose logs are produced and handy resource reloading is done on a request basis to avoid restarting the server every time we change a property, validator and so on. What it is not so well known (actually it doesn’t even appear in the Struts 2 devmode site) is that it enables a OGNL injection backdoor allowing the developers to check their Value Stacks with ease and from a handy OGNL console or request parameter.

OGNL is an expression language for getting and setting properties of Java objects, plus other extras such as list projection, selection, lambda expressions and method invocation. So if attackers can provide the OGNL engine with arbitrary OGNL expressions, they will be able to execute arbitrary code on the application server and/or access and modify any value stored in the Struts 2 value stack. Struts 2 provided an addition layer of protection by disabling static method invocation so that methods like java.

Continuing my previous post where I mentioned that the XStream RCE issue issue also affected SpringMVC RESTful WebServices using the XStream SpringOXM wrapper, I wanted to share a POC server. The code is quite simple and can be found in the XStreamServer GitHub Repo. It contains a WebService defined by the ContactController: @Controller @RequestMapping("/contacts") public class ContactController { @Autowired private ContactRepository contactRepository; @RequestMapping( value = "/{id}", method = RequestMethod.GET ) @ResponseStatus(HttpStatus.

When researching SpringMVC RESTful APIs and their XXE vulnerabilities I found that XStream was not vulnerable to XXE because it ignored the <DOCTYPE /> blocks. Curious about it I decided to took a deeper look at XStream and found out that its not just a simple marshalling library as JAXB but a much more powerful serializing library capable of serializing to an XML representation really complex types and not just POJOs.

This post is about an old RCE vulnerability in applications deserializing streams from untrusted sources and having Spring on their classpaths. I wrote an exploit for it some time ago to learn about this kind of serializing vulnerabilities and decided to make it public since I recently read an study by WhiteSource Software saying that this vulneravility is in the top 5 vulnerabilities that are more prevalent due to a lack of Open Source component update.

Recently I saw Timothy Morgan (@ecbftw) presentation on OWASP AppSec USA’13 (Video) where he explained a clever trick to exploit a XXE or SSRF vulnerability fooling the server to fetch a file for us using the jar:// protocol. The trick is to serve the file but keep the connection opened, so our file is effectively uploaded to the victim server and stored on a temporary location until we close the connection.