How customer collaboration during a pentest can lead to finding a Remote Code Execution (RCE)

I was asked to share a blog post about a Remote Code Execution vulnerability that I identified in a past pentest. Although I don’t think it’s anything too technically advanced, I do think that the process offers some good insights on the way we test at Cobalt, which is a collaborative approach with the Cobalt Core pentest team and the customer.

We started the test, and right from the beginning, one of my colleagues on this assignment started identifying Insecure Direct Object Reference (IDOR) vulnerabilities on multiple functionalities. I started to test for Cross-Site Scripting (XSS) vulnerabilities and noticed that the application was removing <script> and </script> tags from the payloads tested. However, since it wasn’t removing them recursively it was possible to use the payload:

</sc</script>ript><sc<script>ript>confirm(document.domain </sc</script>ript>

Which after the removal would then become:

</script><script>confirm(document.domain)</script>

This was a self-XSS since it was triggered only on the user’s personal edit signature form. With the IDORs previously discovered by my colleague, it was possible to trigger this Stored XSS on all users by rewriting their signatures.

Towards the end of the engagement I was reviewing my initial scans and nmap reported this:

I browsed the application and it seemed like a promising old Atlassian Bamboo application that shouldn’t be publicly available.

Since this asset wasn’t in scope, I double checked with the customer to see if it would add value to them if we included this asset in our testing. After a positive response from the customer, I started a Burp Active Scan and the extension Active Scan++ revealed a vulnerable Struts2 version.

To make sure that the vulnerability wasn’t a false positive, I used the following request:

After some quick research about this vulnerability, it revealed that “the Jakarta Multipart parser in Apache Struts 2 2.3.x before 2.3.32 and 2.5.x before 2.5.10.1 has incorrect exception handling and error-message generation during file-upload attempts, which allows remote attackers to execute arbitrary commands via a crafted Content-Type, Content-Disposition, or Content-Length HTTP header, as exploited in the wild in March 2017 with a Content-Type header containing a #cmd= string.”.

Searching for the available exploit:

Using the exploit:

Overall, this turned out to be a great pentest and I believe that what made it work so well was the collaboration aspect. The way that the researchers can communicate with each other isn’t something new but the ability to communicate with the customer during an engagement is huge. Having them there to provide additional information and validation for digging into specific findings is an added value to a pentest engagement without a doubt.