from Hacker News

How we got read access on Google’s production servers

by detectify on 4/11/14, 9:23 AM with 192 comments

tl;dr: How we got $10.000. We were able to upload an XML file to Google. The XML parser was vulnerable to XXE. We got full read access to their production servers, including the /etc/passwd.

  • by mixmax on 4/11/14, 10:18 AM

    In large production environments it's almost impossible to avoid bugs - and some of them are going to be nasty. What sets great and security conscious companies apart from the rest is how they deal with them.

    This is an examplary response from google. They respond promptly (with humor no less) and thank the guys that found the bug. Then they proceeded to pay out a bounty of $10.000.

    Well done google.

  • by msantos on 4/11/14, 11:06 AM

    A few webcrawlers[1] out there follow HTTP redirect headers and ignore the change in schemas (this method is different of OP's but achieves the same goal).

    So anyone can create a trap link such as

        <a href="file:///etc/passwd">gold</a>
    Or

       <a href="trap.html">trap</a>
    once trap.html is requested the server issues a header "Location: file:///etc/passwd"

    Then it's just a matter of seat and wait for the result to show up wherever that spider shows its indexed results.

    [1] https://github.com/scrapy/scrapy/issues/457

  • by numair on 4/11/14, 9:45 AM

    ... And this is why you want to discontinue products and services your engineers can't be motivated to maintain. Amazing.

    This should scare anyone who has ever left an old side project running; I could see a lot of companies doing a product/service portfolio review based on this as a case study.

  • by halflings on 4/11/14, 1:32 PM

    I hope it doesn't get unnoticed that the guys who discovered this vulnerability created a really great product, Detectify :

    https://detectify.com/

    They also discovered vulnerabilities in many big websites (dropbox, facebook, mega, ...). Their blog also has many great write-ups : http://blog.detectify.com/

  • by raverbashing on 4/11/14, 11:46 AM

    This is another reason not to use XML, plain and simple

    It's too much hidden power in the hands of those who don't know what they're doing (loading external entities pointed in an XML automatically? what kind of joke is that?)

  • by chmars on 4/11/14, 2:03 PM

    The guys behind this report have an interesting pricing model: Pay what you want!

    https://detectify.com/pricing

    The pricing models has apparently worked so far. Are any active users of Detectify here and can share their experience?

  • by raesene3 on 4/11/14, 9:58 AM

    Interesting to see this hit big companies like google. The problem, I think, stems from the idea that most people treat XML parsers as a "black box" and don't enquire too closely as to all the functionality that they support.

    Reading the spec. which led to the implementations, can often reveal interesting things, like support for external entities..

  • by cheald on 4/11/14, 9:55 AM

    XML legitimately scares me. The number of scary, twisted things it can do make me shudder every time I write code to parse some XML from anywhere - it just feels like a giant timebomb waiting to happen.

  • by njharman on 4/11/14, 2:51 PM

    take away: XML should not be used (at least as user input). It is too powerful, too big. It is much too hard and expensive to test and validate.

    Input from potentially malicious users should be in the simplest, least powerful of formats. No logic, no programability, strictly data.

    I'm putting "using XML for user input" in same bucket as "rolling your own crypto/security system". That is you're gonna do it wrong, so don't do it.

  • by NicoJuicy on 4/11/14, 10:31 AM

    Offtopic: the reply was generated with Google's internal meme generator, i read about it here : https://plus.google.com/+ColinMcMillen/posts/D7gfxe4bU7o

    Actually digged it when i read it a few years ago and awesome knowing that it was probably used for this reply :)

  • by NicoJuicy on 4/11/14, 9:48 AM

    A job well done. This is actually impressive and quite interesting to see after what you are searching for (afterwards it seems logical :))

  • by enscr on 4/11/14, 10:31 AM

    Is there a startup that can help automate custom attacks on websites? Like guide the webmaster to look for holes in their setup. I'm guessing some security expert can do a good job educating new businesses on how to prepare for the big bad world.

  • by plq on 4/11/14, 1:11 PM

    For those who'd like to know more about xml-related attack vectors, here's a nice summary: https://pypi.python.org/pypi/defusedxml

  • by dantiberian on 4/11/14, 10:58 AM

    Very cool hack. Is $10,000 around the top end of what Google will pay out? This seems like quite a serious bug as far as they go.

  • by mwcampbell on 4/13/14, 1:55 AM

    I'm surprised nobody has mentioned containers, e.g. Docker, as a way of limiting the damage from this kind of bug. In a container whose only purpose is to run the application, /etc/passwd should be as uninteresting as:

        root:x:0:0:root:/:/bin/sh
    bin:x:1:1:bin:/dev/null:/sbin/nologin
    nobody:x:99:99:nobody:/dev/null:/sbin/nologin
    app:x:100:100:app:/app:/bin/sh

  • by kirab on 4/11/14, 2:39 PM

    I think they couldn’t read /etc/shadow, so it’s not that bad at first. But then they could surely access some configuration file of the application itself, probably containing DB creds and of course more information which helps to find more vulns.

  • by yummybear on 4/11/14, 5:25 PM

    You should be aware that pixilating or blurring screenshots are likely not sufficient to ensure that the contents are unrecoverable.

  • by peterkelly on 4/11/14, 1:28 PM

    I never understood why internal or external entities were included in XML. Can anyone explain what useful purpose they serve?

  • by antocv on 4/11/14, 10:16 AM

    So, when you have read access to googles prod servers, what else would be fun to do besides reading /etc/passwd ?

    Getting the source?

  • by ajsharp on 4/11/14, 6:01 PM

    Cheers to google for properly compensating these guys for their findings.

  • by h1ccup on 4/11/14, 10:33 AM

    Well done. I had to deal with some similar issues with my own project, and they weren't legacy code either. This should push me to go through some of my code again.

  • by pearjuice on 4/11/14, 7:12 PM

    That must have been be a nasty call from Sergey to NSA head quarters earlier this week.

    "Sir, I am sorry to inform you that another backdoor has been found. We will introduce two more as agreed upon in our service level agreement."

  • by sebban_ on 4/11/14, 2:36 PM

    Awesome work! The bounty is a bit low though.

  • by blueskin_ on 4/11/14, 12:17 PM

    I wonder how many of the blurred entries were NSA.

  • by 4ad on 4/11/14, 10:47 AM

    Just $10k?

    This sells for at least 10 times more on the black market. Why would one rationally chose to "sell" this to google instead of the black market.

    Some people don't break the law because they are afraid to get caught, but I like to believe that most people don't break the law because of the moral aspect. To me at least, selling this on the black market poses no moral questions, so, leaving aside "I'm afraid to get caught", why would one not sell this on the black market? Simple economic analysis.

    Very serious question.