Tuesday, 24 January 2017

0day writeup: XXE in uber.com



Hello everyone,
Today I’d love to share an interesting XXE in a popular product of Code42.com company, which could give access to backups of all users in a given company.
Back in May 2016, I was looking through Uber’s bugbounty, and faced following HTTP application:





Bruteforcing was surely not an option; there were no CVEs published of this vendor (you’ll discover later, why). After accessing https://backup.uberinternal.com:4285/api/serverEnv API it became clear that Uber was using last version of a product (5.2.0). The only option to break the service and get a bounty for pwning application was to find a 0day.
I quickly accessed Code42’s publicly available documentation, extracted all documented API methods and started bruteforcing them, trying to find which of such methods can be accessed without authentication. Likely, there was one API call, which can be accessed by any external user: https://www.crashplan.com/apidocviewer/#SsoAuthLoginResponse


Documentation clearly stated, that /api/SsoAuthLoginResponse accepts GET parameter SAMLResponse, which value is a base64-encoded string, and is meant to contain XML authentication data. I quickly constructed a trivial xml with external entities pointed to my VPS using non-standard port (since ports 80 and 443 were filtered by firewall), and got a response:


Despite exploitation string is pretty straightforward, I will not publish final HTTP request here.
It became clear, that server is vulnerable to XXE Out-of-Band (OOB) attack. Since application was using Java, I knew I could read directories, and hence I immediately launched xxe-ftp server to extract data. Greetz to guys at OnSec for coding xxe-ftp server! If you don’t know about XXE OOB exploitation, please read their research at http://lab.onsec.ru/2014/06/xxe-oob-exploitation-at-java-17.html
For those who don’t like clicking on external links, I am providing a quick description. This is how xxe-ftp server works: attacker's host has launched script, which works as HTTP server to retrieve OOB payload on port 8088, and a FTP server which accepts connections on port 8077:





As a proof-of-concept for Uber, I retrieved the contents of /home/ directory of the server, which was a nice impact illustration to my report at Hackerone:



Uber security guys were excited with this vulnerability: they contacted vendor and confirmed that this vulnerability was a 0day. What’s more, Uber team was engaged enough to ask me to elaborate the vulnerability.
I like to show impact of a given vulnerability, so you don’t have to ask me twice. Given permission to show further exploitation, I quickly found the folder, where backup logs were stored. Here is a screenshot of one of local files on the server, containing information about recently backup’ed user:


It was clear that I can read backup files of a little more than all domain accounts of a company, who has Code42 service at their perimeter.
In order to understand the impact of this 0day in the World, I searched for port 4285 in Shodan, and found that one of globally known security firms have this application installed on their perimeter:


May 6th, 2016 – Report sent to Uber through Hackerone
May 23rd, 2016 – Code42 company have updated their software, and vulnerability was patched in latest version (5.2.0.1)
Jun 28th, 2016 – Got $9000 bounty from Uber
Aug 24th, 2016 – Code42 asked to wait until update is installed on all their clients
Jan 24th, 2017 – Code42 notified that writeup will be published, no reaction.

This is a shortcut of our conversation in August 2016 (denial of responsibility):
With regards to the blog post, we would prefer this is not written until our latest version of the product has been installed by all of our customers. This has been fixed in the latest release of the product, however, not all customers have it installed. We would prefer that you wait until that time to write about what you have found.

3 comments: