511–520 of 1001 posts
So, I clicked on that - and I get a 500 error from NGINX.
My guess is that a lot of services are going to be overwhelmed by the sheer volume of password reset requests, thus preventing users from resetting their passwords.
This is probably a good moment to recall the article I published a while ago about how CloudFlare is actively putting the web at risk: http://cryto.net/~joepie91/blog/2016/07/14/cloudflare-we-hav... This is precisely why. The only thing that surprises me about this, is that it was an accidental disclosure rather than a breach. Other than that, this was completely to be expected . EDIT: Also, this can't be repeated en…
Lots of services are going to crumple under the weight of frantic password-reset requests.
From Twitter: "@taviso their post-mortem indicates this would've been exploitable only 4 days prior to your initial contact. Is that info invalid?" - https://twitter.com/pmoust/status/834916647873961984 "@pmoust Yes, they worded it confusingly. It was exploitable for months, we have the cached data." - https://twitter.com/taviso/status/834918182640996353
From my blog on this: The three features implicated were rolled out as follows. The earliest date memory could have leaked is 2016-09-22. 2016-09-22 Automatic HTTP Rewrites enabled 2017-01-30 Server-Side Excludes migrated to new parser 2017-02-13 Email Obfuscation partially migrated to new parser 2017-02-18 Google reports problem to Cloudflare and leak is stopped
Earlier quoted context omitted.
This assumes that the Bad Guys hadn't noticed the bug before Tavis, and hadn't started intensively mining Cloudflare for data.
Intensive mining indeed, if it's true that it requires 3.3M requests to get a page leak. With a fixed 100Mbps connection and assuming 2kB per HTTP request-response, you can hope to get one leak every 11 minutes and 6.6GB of traffic, which is a constant 5k requests/s. Maybe if Google reassigns all its SHAterred ressources to doing that... ... and then I realize that we were talking about cloudflare and my mining bot a…
Cloudflare is serving up more than 100Mbps; the attacker only has to zero in on what's fruitful, which yields something far higher than the 1 per 3.3M Cloudflare sees serving millions of innocuous requests.
Earlier quoted context omitted.
In case you're wondering how this could be worse than Heartbleed: Yes, apparently the allocation patterns inside Cloudflare mean TLS keys aren't exposed to this vulnerability. But Heartbleed happened at the TLS layer. To get secrets from Heartbleed, you had to make a particular TLS request that nobody normally makes. Cloudbleed is a bug in Cloudflare's HTML parser, and the secrets it discloses are mixed in with, appa…
It shouldn't be too difficult to feed an instrumented copy of the parser some fraction of their cached pages (after all, that's what they're for.. right?) and calculate a percentage of how many triggered e.g. valgrind, or just some magic string tacked on the end of the input appearing in the output or similar I prefer CloudScare to Cloudbleed :)
Oh, my god. Read the whole event log. If you were behind Cloudflare and it was proxying sensitive data (the contents of HTTP POSTs, &c), they've potentially been spraying it into caches all across the Internet; it was so bad that Tavis found it by accident just looking through Google search results. The crazy thing here is that the Project Zero people were joking last night about a disclosure that was going to keep e…
Can someone tell me the implications of this in laymen terms? For instance what does it mean "sprayed into caches"? what cache? dns cache? browser cache? if the latter, does it mean you are safe if the person who owns that cache is an innocent non technical iser?
Many of these caches are available online, to anyone who wants to look at them.
This bug meant that any time a page was sent through Cloudflare, the requester might receive the page plus some sensitive personal information, or credentials that could be used to log in to a stranger's account. Some of these credentials might let a bad actor pretend to be a service like Uber or Fitbit.
This very sensitive information might end up saved in a public cache, where anyone could find it and use it to do harm.
Earlier quoted context omitted.
It's about payoff * probability. Let's say I (an idiot, but knowledgeable enough) stumble upon a serious vulnerability in Google. Option 1: I could try to sell that on a darknet market for a decent amount of money. State actors, hacker groups, lots of people want to pay for such things to exploit. But, I might not get paid very much, I might get screwed over, I might go to jail, who the heck knows, I'm playing with a…
> I might go to jail Is selling exploits illegal? If so is selling them to google also illegal?
Telling them about exploits in other services in exchange for money might be, depending on context.
Your parent was talking about the former case.
1. Recognition on our Hall of Fame.
2. A limited edition CloudFlare bug hunter t-shirt. CloudFlare employees don't even have this shirt. It's only for you all. Wear it with pride: you're part of an exclusive group.
3. 12 months of CloudFlare's Pro or 1 month of Business service on us.
4. Monetary compensation is not currently offered under this program.
Guessing they're gonna reconsider #4 at this point.