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."
How we got read access on Google’s production servers
151–160 of 197 posts
Re: How we got read access on Google’s production servers
#152Earlier 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
And yet it was worth 10k to google.
Re: How we got read access on Google’s production servers
#153Earlier 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.
We're not talking about a malicious XML library here, though. We're talking about a misunderstanding regarding what happens during legitimate parsing of XML.
Re: How we got read access on Google’s production servers
#154Earlier 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.
It's probably cryptographically hashed. There is no reason to keep a raw password in RAM beyond the stack frame of the function that receives it from the client - at any point after that, just store & compare the hash.
Re: How we got read access on Google’s production servers
#155In 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.
Where _is_ Google's response?
if you read the article, it summarizes it.
Re: How we got read access on Google’s production servers
#156Earlier quoted context omitted.
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
No, they can't. Read the inverse of my bulleted list to see what makes money:
* Bugs that fit readily into operational frameworks (ie: it would be reasonable to have a UI with a button invoking that bug and/or any of the 15 other bugs like it)
* Bugs that can't be killed with a single patch cycle by a single entity
* Bugs that provide long-term access, or access that is unlikely to get your entire syndicate caught
Example of a potentially lucrative web bug: bug in Wordpress.
Example of a bug unlikely to be lucrative: "read any Facebook server file".
I know that sounds crazy and backwards, but I don't think it is.
Re: How we got read access on Google’s production servers
#157The 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 like the price but they found nothing, honestly, and we're not very nice when I emailed them for support.
why weren't you nice when you emailed them?
Re: How we got read access on Google’s production servers
#158Earlier 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".
There should be a security equivalent to hiring a lawyer to write strongly-worded letters for you.
Maybe someone could set up a firm where individuals could hand them a vuln report, and then the firm would contact the vulnerable company on the individual's behalf. The firm would do the long, boring dance of "we suspect you're vulnerable to X, though we haven't tested it, but we'd like to do a free vulnerability test on you, so please sign this liability waiver", both protecting the individual from liability, and taking time the individual doesn't have. In return, if the company gives rewards, the firm could take a percentage.
Re: How we got read access on Google’s production servers
#159Earlier quoted context omitted.
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.
We're not talking about a malicious XML library here, though. We're talking about a misunderstanding regarding what happens during legitimate parsing of XML.
I was just responding to you about pure functions. You can make a Haskell function with a pure type signature that includes a call to unsafePerformIO.
Re: How we got read access on Google’s production servers
#160The 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.
So they tell you how much they spent on cloud resources and even suggest a gratitude factor? That is actually a great way of getting paid (enough) even if you do not enforce any fixed pricing, cool! :)