Last updated at Wed, 12 Apr 2023 23:38:21 GMT

TL;DR

This week a vulnerability was disclosed, which could result in sensitive data being leaked from websites using Cloudflare's proxy services. The vulnerability - referred to as "Cloudbleed" - does not affect Rapid7's solutions/services.

This is a serious security issue, but it's not a catastrophe. Out of an abundance of caution, we recommend you reset your passwords, starting with your most important accounts (especially admin accounts). A reasonable dose of skepticism and prudence will go a long way in effectively responding to this issue.

What's the story on this Cloudflare vulnerability?

On February 18, 2017 Tavis Ormandy, a vulnerability researcher with Google's Project Zero, uncovered sensitive data leaking from websites using Cloudflare's proxy services, which are used for their content delivery network (CDN) and distributed denial-of-service (DDoS) mitigation services. Cloudflare provides a variety of services to a lot of websites - a few million, in fact. Tavis notified Cloudflare immediately. A few features in Cloudflare's proxy services had been using a flawed HTML parser that leaked uninitialized memory from Cloudflare's edge servers in some of their HTTP responses. Vulnerable features in Cloudflare's service were disabled within hours of receiving Tavis' disclosure, and their services were fully patched with all vulnerable features fully re-enabled within three days. Cloudflare has a detailed write-up about Cloudbleed's underlying issue and their response to it - check it out!

This Cloudflare memory leak issue is certainly serious, and it's great to see that Cloudflare is acting responsibly and rapidly after receiving a disclosure of Google's findings on a Friday night. Most companies require several weeks to respond to vulnerability disclosures, but Cloudflare mitigated the vulnerability within hours and appears to have done the majority of the work required to fully remediate the issue in well under a week, starting on a weekend, which itself is impressive.

Why should I care?

Your information may have been leaked. Any vendor's website using Cloudflare's proxy service could have exposed your passwords, session cookies, keys, tokens, and other sensitive data. If your organization used this Cloudflare proxy service between September 22, 2016 and February 18, 2017, your data and your customers' data could have been leaked and cached by search engines. As Ryan Lackey notes, “Regardless, unless it can be shown conclusively that your data was NOT compromised, it would be prudent to act as if it were.”

Who is affected by the Cloudflare vulnerability?

Before Tavis' disclosure, data had been leaking for months. It's too soon to know the full scope of the data that was leaked and the sites and services that were affected (although we're off to a decent start). There is currently a fair amount of confusion and misalignment on the status of various services. For example, Tavis claims to have recovered cached 1Password API data, while 1Password claims users' password data could not be exposed by this bug.

How bad is it, really?

One of the most important things to consider right now is that understanding the full impact of this Cloudflare bug will take some time; it's too soon to know exactly how deep this goes. However, if we're using Heartbleed as our de facto “security bug severity measuring stick”, it looks at this point like the Cloudflare bug is not as disastrous.

For starters, the Cloudflare bug was centralized in one place (i.e. Cloudflare's proxy service). While search engines like Google, Bing, and Yahoo cached leaked data from Cloudflare, they were quick to purge these caches with Cloudflare's help. Cloudflare stopped the bleeding and worked with Google and others to mop up the remaining mess very quickly. As of now, the scope of affected data seems relatively limited. According to Cloudflare, “The greatest period of impact was from February 13 and February 18 with around 1 in every 3,300,000 HTTP requests through Cloudflare potentially resulting in memory leakage.”

On the other hand, Heartbleed existed for two years before it was disclosed. It also needed to be patched everywhere it existed - it was decentralized - and there are still systems vulnerable to Heartbleed today. There are known instances of attackers using Heartbleed to steal millions of records, months after a patch was released. At this point in time, there's no evidence of attackers exploiting Cloudbleed.

Think about the “best case scenario” for users protecting themselves against the Cloudflare vulnerability vs. Heartbleed. To protect against Cloudbleed, users need to follow a few steps (which we've outlined below). To protect themselves from Heartbleed, users had to follow all of these same steps, reroll SSL/TLS certificates, and patch OpenSSL on all of their vulnerable systems.

What do I do now?

There are several steps you can take to protect yourself:

  1. Log out and log back into your accounts to inactivate your accounts' sessions, especially for sites/services that are known to have been impacted by this (e.g. Uber).
  2. Clear your browser cookies and cache.
  3. This is a great time to change your passwords, keys, and other potentially affected credentials - something you should be doing regularly anyway! While there was some talk of password manager data being exposed, this shouldn't scare you away from using these tools. For the vast majority of us, it is the most practical way to ensure we're using strong, unique passwords on every site with the ability to more easily update those passwords on a regular basis.
  4. Set up two-factor authentication on every one of your accounts that supports it, especially your password manager.
  5. If your website or services used services affected by the Cloudflare vulnerability during the time window mentioned above, force your users to reset all of their authentication credentials (passwords, OAuth tokens, API keys, etc.). Also reset credentials used for system and service accounts.
  6. Keep an eye out for notifications from your vendors, check their websites and blogs, and proactively contact them - especially those that handle your critical and sensitive data - about whether or not they were affected by this bug and how you can continue using their services securely if they were.
  7. If you're not sure if you're using an affected site or service, check out this tool: Does it use Cloudflare?

Big thanks to my teammate Katie Ledoux for writing this post with me!