Few things are better than a good ethical hacking challenge and what could be more fun than finding a target that can be used against itself? Find out how the Detectify team hacked their way to read access to Google’s production servers.
To stay on top on the latest security alerts we often spend time on bug bounties and CTFs. When we were discussing the challenge for the weekend, Mathias got an interesting idea: What target can we use against itself?
Of course. The Google search engine!
What would be better than to scan Google for bugs other than by using the search engine itself? What kind of software tends to contain the most vulnerabilities?
- Old and deprecated software
- Unknown and hardly accessible software
- Proprietary software that only a few people have access to
- Alpha/Beta releases and otherwise new technologies (software in early stages of it’s lifetime)
For you bounty hunters, here’s a tip:
By combining one thing with another, we started Google dorking for acquisitions and products to antique systems without any noticeable amount of users.
One system caught our eyes. The Google Toolbar button gallery. We looked at each other and jokingly said “this looks vuln!”, not knowing how right we were.
Not two minutes later we noticed that the gallery provides users with the ability to customize their toolbar with new buttons. If you’re a developer, you’re also able to create your own buttons by uploading XML files containing various meta data (styling and such).
Fredrik read through the API specifications, and crafted his own button containing fishy XML entities. The plan was to conduct an XXE attack as he noticed the title and description fields were printed out when searching for the buttons.
The root cause of XXE vulnerabilities are naive XML parsers that blindly interpret the DTD of the user supplied XML documents. By doing so, you risk having your parser doing a bunch of nasty things. Some issues include: local file access, SSRF and remote file includes, Denial of Service and possible remote code execution. If you want to know how to patch these issues, check out the OWASP page on how to secure XML parsers in various languages and platforms.
Nevertheless. The file got uploaded… and behold! First try:
Second try (for verification purposes):
Boom goes the dynamite.
What you see here is the /etc/passwd and the /etc/hosts of one of Google’s production servers. Our payloads served as a proof of concept to prove the impact. We could just as well have tried to access any other file on their server, or moved on to SSRF exploitation in order to access internal systems. Too say the least, that’s pretty bad.
We contacted Google straight away while popping open some celebration beers. After 20 minutes we got a reply from Thai on the Google Security Team. They were impressed. We exchanged a few emails on the details back and forth during the coming days. In our correspondence we asked how much the vulnerability was worth. This is what we received as reply:
The bottles (or whatever it is that falls out), turned out to be worth $10.000, enough to cover a road trip through Europe.
tl;dr: We uploaded a malicious XML to one of Google’s servers. Turned out to be a major XXE issue. Google financed an awesome road trip for the team.
Thanks for reading.
Written by: Fredrik
Co-Author: Mathias
If Google can get hacked, are you sure your service is secure? Detectify is an automated security monitoring service that tests your website for over 700 vulnerabilities. Sign up for a free trial and check your site’s security»