Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

How we got read access on Google’s production servers

blog.detectify.com

Post reply on HN
Print view View original

141–150 of 197 posts

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

#141

Post by cdelsolar »

mixmax wrote: 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.

Hmm a pretty cheap road trip for just ten dollars, and I'm also not sure why they thought it necessary to include an extra significant figure for cents.

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

#142

Post by thrownaway2424 »

dreamdu5t wrote: post #128
thrownaway2424 wrote: post #106

Earlier quoted context omitted.

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?

How else would you do it? If you use a configuration "service" the credentials to access the service must be baked in.

Well, I can think of a couple of ways off the top of my head, that I'm sure will be shouted down for being simplistic:

1) ident protocol, or something similar. On the internet, it's a disaster, but for machines all owned by the same organization, it makes sense.

2) ssl client certificate. this can be hardened in various ways like having the certs expire every ten minutes etc.

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

#143

Post by cheald »

arethuza wrote: post #25
bambax wrote: post #14

Earlier quoted context omitted.

> every time I write code to parse some XML Why would you write code to parse XML? Use an existing parser to parse. Use XSLT to modify/transform (including generate JSON/CSV/other).

I think cheald probably means writing code to invoke a parser to parse XML. Presumably if you had written your own parser (generally, not a great idea) the resulting behaviour would not be "scary, twisted"... [at least to the person writing the parser].

Yes, indeed. :)

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

#145

Post by flylib »

tptacek wrote: post #101
4ad wrote: 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…

"dumb web vulnerabilities" that have huge implications could fetch a pretty penny for sure

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

#146

Post by flylib »

pbhjpbhj wrote: post #114
flylib wrote: post #84

Earlier quoted context omitted.

- the buyer is very unlikely to be able to track you the buyer will probably be easily able to track you, if they are paying 100k for hacks on the black market, they would have the resources to find you easily

Yet they're getting the cracks from you .. which suggests you're good enough to be able to hide yourself away. Use anonymising proxies to connect to a machine that you Tor off to a BTC wallet that only takes in washed coins, or something. Even being able to spend 100k on [potential?] server cracks doesn't seem enough resources to be able to take down Tor? If they try and trace you just send a spike!!1111one

true, but any small mistake in the process on your part can come back to hurt you, look at how silk road got taken down

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

#147

Post by jrockway »

gamegoblin wrote: post #138
Peaker wrote: post #121

Earlier quoted context omitted.

Or, if you use existing parsers in a language like Haskell, you know parsing is supposed to be a pure function. If parsing suddenly requires IO effects, you can be suspicious and try to figure out what is going on.

Even with haskell, someone could sneak in a performUnsafeIO call if you aren't careful. Of course this is trivial to detect with compiler flags etc.

More likely, they'll just write bindings to libxml2.

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

#148

Post by schrodinger »

enscr wrote: 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.

Check out Burp Suite as a good tool to run: http://www.portswigger.net/burp/

Owasp is also a good resource for learning: https://www.owasp.org/index.php/Main_Page

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

#149

Post by pmcjones »

cdelsolar wrote: post #141
mixmax wrote: 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.

Hmm a pretty cheap road trip for just ten dollars, and I'm also not sure why they thought it necessary to include an extra significant figure for cents.

Some countries reverse the role of period and comma in numbers. The author meant ten thousand.

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

#150

Post by claudius »

nateabele wrote: post #78
claudius wrote: post #61

Earlier quoted context omitted.

> loading external entities pointed in an XML automatically? what kind of joke is that? Your browser does much the same when parsing (X)HTML. LaTeX naturally includes ‘external’ resources when building an output file. There are tons of examples like that, loading external entities per se is not wrong, it’s mostly just wrong under these specific circumstances.

I think the important difference here is that with browsers, the behavior is well-known and well-understood, there are a very small number of them, and you're unlikely to run one in a production environment -- barring, say, something like PhantomJS, which still has all the foregoing in its favor. This compared to XML parsers, for which there are often multiple per language , each of which may be implemented to wildly…

My point was that it is not an unreasonable thing to have some sort of #include directive in a data format, and certainly not in a markup language.

The problem here was the same as in the rest of the software industry: programmers are far from ‘engineers’ in their desire to understand their tools, use the right tools and build bug-free code. Instead, most people hack for fun with tools they hardly understand and then somehow manage to complain if they shoot off their feet while doing so.

Hacking for fun and shooting off extremities is of course perfectly fine, but the blame for the latter lies in the programmer (and possibly their education), not the tools.

Post reply on HN