Cloudflare is a huge internet infrastructure company (5.5 million websites), which means that you likely use them every day that you’re online, without ever realizing it. Depending on what metric you use, as much as 25% of the Alexa Top 10000 sites is using Cloudflare for some part of their public facing infrastructure.
What Cloudflare ProvidesBroadly, they provide two services:
Massively fast and distributed DNS services Denial of Service attack mitigation (and some related security features around re-writing your web pages on the fly to protect them from scraping and other harmful acts.)It’s in this second set of services that Cloudflare announced a huge security issue yesterday. Some of their HTML re-writing features had bugs which returned more data than they should have.
Cloudflare Security IssuesSo what happened? In a nutshell: users that browsed some sites on Cloudflare’s network (SiteA, for example) may have also received portions of requests from other websites (SiteB, SiteC, etc.) that were stored on the same caching servers.
You may be thinking: “That sounds bad, but not that bad” so what if a portion of SiteB’s headline ended up in SiteA’s response? Compared to attacks like Heartbleed (which leaked private keys) or the many data breaches which happen every week, this seems almost benign.
“Request” is the technical name for an interaction with a HTTP server, so it’s tempting to think of this as just two web pages jumbled together: bad, but less catastrophic. However, an HTTP POST (form submit) of your email and password to a site in the Cloudflare network is also considered a “request” and may have been leaked.
Google, Bing, Baidu and the entire contingent of other web-scrapers that exist on the Internet are also “users” who make “requests” to these sites. The difference is that they keep this data around and show it to whoever requests it. While efforts are furiously underway at these companies to purge their caches of this data it’s out there and really difficult to tell where it all resides.
HTTP Requests are aggressively cached all over the internet. From your regional ISP to corporate proxies to your browser. So some of this data is going to be in the wild somewhere for a long time.
What happened here is a unique type of security issue for which there exists no standard operating procedure. Every sysadmin knows how to update a TLS/SSL cert (which is a fix for Heartbleed, for example). Even sorting out exactly what might have been put at risk requires consulting with web developers, running tests, and thinking of scenarios that were fairly unthinkable previously.
Nobody gamed out a response plan that started with: “Let’s assume that everything that passed through our website for the last 6 months was publicly accessible.”
There are many services that rely upon the use of obscure API keys for their security. Now, suddenly every one of those keys need revoked as access to an API key instantly lets you gain access to the features of the service.
Similarly OAuth (which is in general a security win) exposes access and renewal tokens, which once compromised are a huge support nightmare to roll.
What to Check for your SiteHow to tell if your site leaked data:
You were using Cloudflare between Sept 9th, 2016 and February 18th, 2017. You were using Cloudflare’s HTTP/HTTPS termination (proxying requests through Cloudflare, not just using them for DNS) What to Check as an IndividualWhat to do as an individual: you should consider everything that uses Cloudflare as potentially compromised.
Security researchers are collaboratively compiling a list of sites at https://github.com/pirate/sites-using-cloudflare review the list, change your password and rotate any API keys you have within affected sites. It’s likely that individually affected sites will also be issuing security guidance as the day progresses.