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.”
