Live data from Hacker News

How we got read access on Google’s production servers

blog.detectify.com

101–110 of 197 posts

Re: How we got read access on Google’s production servers

#101
post #15

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 t…

That vulnerability does not sell for 10x on "the black market".

* It fits into nobody's existing operational framework (no crime syndicate has a UI with a button labeled "read files off Google's prod servers")

* A single patch run by a single organization kills it entirely

* The odds of anyone, having extended access and pivoted into Google's data center, keeping that access is zero.

I'm not an authority on how much the black market values dumb web vulnerabilities but my guess on a black market price tag for this bug is "significantly less than Google paid".

Later: I asked a friend. "An XXE in a single property? Worthless. And at Google? Worth money to Google. Worth nothing to anybody else."

Re: How we got read access on Google’s production servers

#102
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.

Re: How we got read access on Google’s production servers

#103
post #97

Earlier quoted context omitted.

Yes golly you must be right, i bet google just uses rsync to copy the passwords of billions of user accounts to thousands upon thousands of machines all over the world, in plain text! It's probably in /var/lib/every_user_password_in_plain_text.txt!

Nope but if you have root in production servers you can just peruse the RAM. Nice throwaway. LOL.

This isn't a root exploit. It serves up files that are readable by the serving process, such as /etc/passwd. You are aware, I hope because it's been this way for 20+ years, that despite the name there are no passwords in /etc/passwd, right? It's not considered a sensitive file.

  % ls -l /etc/passwd
  -rw-r--r-- 1 root root 2028 Dec  2 13:05 /etc/passwd

Re: How we got read access on Google’s production servers

#104
post #2

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

On that subject, https://news.ycombinator.com/item?id=7572414

Re: How we got read access on Google’s production servers

#105
post #97

Earlier quoted context omitted.

Yes golly you must be right, i bet google just uses rsync to copy the passwords of billions of user accounts to thousands upon thousands of machines all over the world, in plain text! It's probably in /var/lib/every_user_password_in_plain_text.txt!

Nope but if you have root in production servers you can just peruse the RAM. Nice throwaway. LOL.

They didn't have root, they had whatever user the XML parser was running as.

Re: How we got read access on Google’s production servers

#106
post #98

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.

It's shocking to me that baking "db creds" into a binary or configuration file is still so common that anyone would expect it to be true on a randomly selected server. Is this still the industry standard?

Re: How we got read access on Google’s production servers

#107
post #12

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.

Hi! In fact, that's exactly what we do at Detectify. Just check out https://detectify.com!

Re: How we got read access on Google’s production servers

#108
post #97

Earlier quoted context omitted.

Nope but if you have root in production servers you can just peruse the RAM. Nice throwaway. LOL.

This isn't a root exploit. It serves up files that are readable by the serving process, such as /etc/passwd. You are aware, I hope because it's been this way for 20+ years, that despite the name there are no passwords in /etc/passwd, right? It's not considered a sensitive file. % ls -l /etc/passwd -rw-r--r-- 1 root root 2028 Dec 2 13:05 /etc/passwd

The severity of this bug depends on the privileges and the setup of whatever user ran that service then.

Re: How we got read access on Google’s production servers

#109

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/

While they are probably good at doing this manually, their automated tool finds very little. And they were kind of assholes on support :(

Sorry to hear that you are disappointed. Few results can be a good thing though, it might just mean that your site has very few issues! Feel free to mail us again and thanks for the feedback :)

Re: How we got read access on Google’s production servers

#110

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/

While they are probably good at doing this manually, their automated tool finds very little. And they were kind of assholes on support :(

Nice try, Tinfoil.
Post reply on HN