PrimeFaces CVE-2017-1000486 exploit – old but good!

Hi! I published on my GitHub repository an exploit for PrimeFaces CVE-2017-1000486 based on an existent one created by pimps (the original one is here).

CVE-2017-1000486 is a RCE issue in many versions of PrimeFaces disclosed by Minded Security in 2016 and described here.

It is an old issue, but we continue to find many applications vulnerable to it, for many reasons:

  • EL injection issues often are tricky to exploit and published attack vectors may not work also if the backend is vulnerable
  • Tracing and updating Java libraries is not always a simple task and usually those libraries are updated by the companies only when a issue has been actively discovered
  • List of vulnerable PrimeFaces versions that you can find in public resources are not accurate and miss some vulnerable versions
  • List of vulnerable paths that you can find in public resources are definitively not accurate. I often read that the issues can be exploited only in /javax.faces.resource/dynamiccontent.properties.xhtml or /javax.faces.resource/dynamiccontent.properties.jsf and often the issues is mitigated simply restricting access to those paths, but the issue can be exploited in all the dynamic resources of PrimeFaces (examples http://MYURL/MYAPP/javax.faces.resource/main/css/perfect-scrollbar.css.xhtml, http://MYURL/MYAPP/javax.faces.resource/main/css/perfect-scrollbar.css.jsf, http://MYURL/MYAPP/javax.faces.resource/main/css/perfect-scrollbar.css).

The modified version of the exploit has the following improvements:

  • IBM WebSphere exploitation (and potentially others…): in the past during a PT we tried the exploit on some PrimeFaces applications deployed on IBM WebSphere application servers but we found a strange behavior/bug in the behavior of the PrimeFaces library that limits the methods that can be called from the EL expression on those environments. I’m not even sure that the issue is only on WebSphere application server, it can be present also with other configurations. My solution is terrible and read the output of the command char by char by repeating the read operation for each char, but I didn’t find a better solution and it worked. With this option you must choose how many chars of the output you want to read and the payload in the request increases in size for each additional char. Pay attention: for the same strange EL behaviour/bug, I could not call the Runtime.getRuntime method directly; I had to use Runtime.getDeclaredMethods()[0].invoke() and consequently the payload could require some tuning on the [0] array position.
  • Check options: I added two check options that can be used to verify the presence of the issue. The first one was supplied by Minded Security in their article and adds a HTTP header, but sometimes it fails. I added a new simpler payload that has a higher detection rate.
  • Simple response obfuscation: if you want you can apply a simple obfuscation to the output of the command (Base64 of reverse string). I added this option because sometimes WAF could block responses that contain for example the content of the /etc/passwd of other common files usually exfiltrated through RCE. The exploit automatically applies the reverse transformation before printing the output to the attacker

The exploit is available here:

Cheers!