Live data from Hacker News

How we got read access on Google’s production servers

blog.detectify.com

91–100 of 197 posts

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

#92

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

Exactly the same as #includes and #defines in C - they let you organize your code in multiple files, be more concise, and shoot yourself in the foot, repeatedly.

They were useful for document editing use cases - remember this was before SOAP and xml serialization, and sgml tooling that already supported this stuff existed. You can see the record of the decision here: http://www.w3.org/XML/9712-reports.html#ID5

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

#93
post #88
post #8

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

I'd say logins and passwords of millions of Google accounts would be the most valuable asset for a blackhat.

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!

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

#94
post #87
post #9

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.

I am really glad about how they responded. Whenever Tinfoil has found vulnerabilities in companies like United Airlines[0], for example, those companies mostly respond with anger rather than graciousness. [0] https://www.tinfoilsecurity.com/blog/132969897

Exactly. I just saw that the local bank my parents use is still vulnerable to the Heartbleed Bug. But you know what? I don't want to go down there and talk to them because I'm quite certain they'll call the police because I "hacked into their systems".

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

#96
post #63
post #8

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

With the kind of monitoring that Google has in place your access will last a very short time.

What kind of monitoring would you deploy that would raise an alert for a process opening and reading readable files?

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

#97
post #88

Earlier quoted context omitted.

I'd say logins and passwords of millions of Google accounts would be the most valuable asset for a blackhat.

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.

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

#99
post #87

Earlier quoted context omitted.

I am really glad about how they responded. Whenever Tinfoil has found vulnerabilities in companies like United Airlines[0], for example, those companies mostly respond with anger rather than graciousness. [0] https://www.tinfoilsecurity.com/blog/132969897

Exactly. I just saw that the local bank my parents use is still vulnerable to the Heartbleed Bug. But you know what? I don't want to go down there and talk to them because I'm quite certain they'll call the police because I "hacked into their systems".

To be fair, there are some that respond more graciously than others, but it's entirely unclear.

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

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

Or have policy of replying with humor and bounties. So the rest of the world happily finds your vulnerabilities for you.

Works for small, old, etc products as the value of breech will probably be less than value of bounty + cred.

Post reply on HN