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

111–120 of 197 posts

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

#111

Post by ori_b »

jebblue wrote: post #81
raverbashing wrote: post #48

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?)

XML made it for more manageable to create machine to machine API's. I can say we surely would not want go back to the 80's and 90's when dong that stuff was a nightmare.

Yes, it was a drunken, stumbling step forward. Let's take another one, and move to something simpler, which solves the problem better.

To quote Phil Wadler's paper about XML, where he established some of the principles that influenced Xquery: "So the essence of XML is this: the problem it solves is not hard, and it does not solve the problem well."[1]

I suggest reading the entire paper; It shows a number of shortcomings, but it's also rather enlightening about how XML actually is structured, and how its semantics are defined. (ie, in spite of that quote, it's not just XML bashing)

[1]http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.109...

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

#112

Post by borski »

ibu wrote: post #110
detectifyuser wrote: post #90

Earlier quoted context omitted.

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.

Er...CTO of Tinfoil here. We respect the Detectify guys a lot. Not sure what you were trying to get at, but there's no conspiracy here. We don't engage in subversive competitive tactics.

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

#113

Post by carl689 »

borski wrote: post #87
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.

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

While I know plenty of companies do not respond how I feel they should to vulnerabilities, reading that story I don't see any cited anger from United Airlines.

Am I missing part of the story?

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

#114

Post by pbhjpbhj »

flylib wrote: post #84
pbhjpbhj wrote: post #80

Earlier quoted context omitted.

I can see that working in meatspace but here we're talking about selling an idea on the web - the buyer is very unlikely to be able to track you so they're unlikely to front the money. Suppose you found a bug, couldn't cash it in with Google because of where you live and so were selling it on. The buyer won't release the funds, would you really give up the goods? Even with an escrow, proving the transfer and performi…

- 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

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

#115

Post by borski »

carl689 wrote: post #113
borski wrote: 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

While I know plenty of companies do not respond how I feel they should to vulnerabilities, reading that story I don't see any cited anger from United Airlines. Am I missing part of the story?

You're right; the anger was mostly behind the scenes. It turns out it's also /incredibly/ hard to disclose a vulnerability to most companies. Companies like Google or that have bug bounty / disclosure programs are to be lauded. :)

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

#116

Post by fennecfoxen »

thrownaway2424 wrote: post #106
kirab wrote: 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?

Sadly but truly!

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

#117

Post by ephemeralgomi »

thrownaway2424 wrote: post #103
muyuu wrote: 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

I'm kind of sad that this is a throwaway account because you're posting good responses, that are technically competent and are actually specific to the bug discussed in the article, to people who are either less informed or are talking about their vague general understanding of vulnerabilities rather than reading the article and actually discussing its contents.

Your posts are exactly the kind of thing I _want_ to read on HN. Is there a particular reason why you feel you can't post this under a general-use account?

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

#118

Post by alternize »

chmars wrote: post #83

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?

I tried them on a client project today, and they found some (minor) form post issues. the scan used roughly 1.5hr, which results in "incurred cost" of $4.75 (for their cloud ressources needed), and they suggest a 5x "gratitude" factor which I gladly paid.

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

#119

Post by AJ007 »

borski wrote: post #99
TallGuyShort wrote: post #94

Earlier quoted context omitted.

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.

If you are a bank, and you haven't fix one of the worst and widest reaching security holes in years by now.. well. Criminal negligence would be an appropriate description.

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

#120

Post by blauwbilgorgel »

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…

If you donate to charity, Google will match your donation. You can buy a smile on your face for the rest of your life, knowing your exploit build a school in Africa.

If you manage to sell this on the black market, that money is worth half when turned into "legit" money that you can spend. If we leave aside "I'm afraid to get caught" do we mean "caught by the justice system"? What would happen if you sell your exploit to some cybermob and a few days later, some monkey on a typewriter, finds your exact exploit and publishes it online? Not your problem it is worthless now and some mob feels you sold them crappy gear?

As for the moral aspect. Think of anyone you hold in high regard, or have a loving relationship with. Selling an exploit that will be used for harm, might mean harm to those you hold dear.

Then there is this simmering thing in your subconsciousness. Some know how to put out that fire. Others wake up in a sweat years later, after a dream where their exploit is used to find and execute a political dissident. That is: You may very well come to regret a "bad" deed in the future, when your situations and responsibilities change. You won't lie on your death bed and think: "I wish I hadn't build that school, but taken the money and put a down-payment on my new bathroom."

Post reply on HN