23

In response to Google and Cloudflare's recent disclosures of the Cloudbleed vulnerability, some sources like TNW are recommending that people change passwords for sites and services that use CloudFlare. This seems to me a reasonable precaution.

Others are recommending that people change all passwords, even for services that don't use Cloudflare. Based on what we know so far—admittedly early in the investigation—this seems an overreaction.

As far as I can tell the rationale goes like this:

  • You probably reuse your passwords, you big n00b. A compromise of your Cloudbleed-affected password will compromise your other accounts.
  • You should change your passwords sometimes anyway. Stop whining. It's good for you.
  • Searching through a list off affected sites is really hard. It's so much easier to just change all of your passwords.

I won't change all my passwords lightly. There are over 400 sites in my password manager, and I don't reuse passwords. Looking up a few hundreds sites in a list, whether on Github or Does It Use Cloudflare, doesn't sound hard compared to the tedious time-suck of changing them all.

So far it sounds like Cloudbleed occasionally caused the information from one Cloudflare-supported page to leak into the output of another Cloudflare-supported page.

So am I missing something? Are there good, science-based reasons to change all passwords for all sites and services, given what we know so far (February 25, 2017)? Or is this a panic response?

Andy Giesler
  • 351
  • 1
  • 7

4 Answers4

10

While Miao is right for the case of passwords, this vulnerability also makes oauth tokens compromised. If a Cloudflare-dependent site uses Oauth, you should make an extra step resetting your oauth dependent sessions across the web.

Community
  • 1
Rápli András
  • 2,124
  • 11
  • 24
6

There is no reason to change any other password. The only scenario I can think of where it may be required is the following:

An attacker learns a password to your mail service. Then, he/she uses the compromised mail service to reset a password of a non CloudFlare service.

Since I couldn't find a mail service that depends on CloudFlare so this scenario is not likely at all, I am certain this is a panic response.

MiaoHatola
  • 2,284
  • 1
  • 14
  • 22
4

I honestly do not think that people are as badly affected as some may try to make you believe. The probability that exactly your accounts are affected is near zero.

To be affected, several things must have happened at the same time:

  1. You were surfing on one of the affected sites.
  2. An attacker was at the same time trying to gather private data by issuing as much erroneous requests as his connection and cloudflare allows him to do
  3. The attacker landet on the same reverse proxy instances that your requests were previously served by

All three things must have happened at pretty much the same time. At point 2., the attacker may have gathered private data from some users, but the likelihood that you were one of them is pretty low.

The reason why it must have happened at the same time is quite simple. The proxy instances don't have unlimited memory and thus the memory gets reused very often. So even if the proxy memory contained some sensitive data from your request, one of the following requests of other users would have overwritten this data due to reuse of the same memory.

I would assume that the proxy instance you and the attacker were using at this time were also dependent on your and the attackers geographic location. I never hosted anything with the help of cloudflare and never studied how their load balancing works, but I'd assume they always try to give you a proxy instance that gives best performance for the particular geographic location. Based on that assumption, I'd guess the attackers were limited to the proxies in the same location.

Also, as only a few requests would have contained your passwords (only the login requests maybe), most leaked sensitive data would only have included session tokens and stuff like that. So the likelihood of your passwords being leaked drops even more.

Next point: As of now, it is assumed cloudbleed was not exploited before the hole was discovered and closed. It is assumed that the leaked data mostly resides in search engine caches (and probably everything else in the internet that does caching). But the number of requests with leaked data these search engines did is pretty low compared to the requests needed by an attacker to gain enough sensitive data and actually get YOUR data.

Alexander Block
  • 141
  • 2
  • "The attacker landed on the same reverse proxy instances that your requests were previously served by"—this point is invalid, I believe. It is equivalent to "even if the attacker got someone's info, that's probably not you." Well, _someone's_ data _will_ be compromised, and there's no telling if it's you or not, so we have to protect against this chance. Besides, the attacker is not singular, and possibly every server was scraped. – katrmr Feb 26 '17 at 21:57
  • If the attackers request is not served by the same instance, how would it be able to leak any unitialized/freed memory from requests served by other instances? It can technically only leak data from the same instance. And of course someone's data is compromised, but as said: The likelihood that it's your data is near zero. It's bad of course, but it's not as bad as it sounds like. It's not bad enough to panic and change all your passwords, just bad enough to change your most sensitive ones. – Alexander Block Feb 28 '17 at 07:42
  • You assume that there's some specific 'attacker' and a specific target who must collide on one server so that the attack can occur. That's not the case here. There are an unknown number of bots who consumed data from Cloudflare servers, affecting unknown users of Cloudflare client sites. The chance of a specific attacker being served by the same server as you is irrelevant because there might've been dozens of different bots on each server. You have to assume that *some* bots definitely have data from the server that you were on. – katrmr Feb 28 '17 at 16:13
  • Furthermore, the second part of your argument is: "of course someone's data is compromised, but the likelihood that it's your data is near zero." That's not how infosec works. If there's a leak of passwords that may include yours, the severity of losing those passwords may be critical even if the attacker comes across them with a chance of 1/1000000. So you gauge the importance of the affected sites for you, not the chance of the leak. The only part where probability comes in play here is the number of leaked requests that is indeed pretty small, which is reassuring. – katrmr Feb 28 '17 at 16:26
1

There are some steps to take:

  1. Clear your browser data and cookies
  2. log out from all website to deactivate your session
  3. The website who affected by the the cloud-bleed vulnerability should notify all users to change their password. You will be forced to change your password.
  4. Set up the two-factor authentication as soon as possible
GAD3R
  • 2,211
  • 3
  • 15
  • 38