If Shakespeare were alive today (and blogging), he might have written about the latest vulnerability to sweep the Internet by pointing out:
Hath not the cloud interfaces, code, logic, data? Accessed with the same protocols, exploited with the same weapons, subject to the same vulnerabilities, mitigated by the same solutions, patched by the same methods as other software? If you exploit it, does it not bleed?
Or maybe he wouldn’t have. But he should have, given the trend of vulnerabilities to “bleed” data when exploited.
Remember Heartbleed1? It ultimately exploited protocols and logic in systems across the Internet in order to gain access to sensitive data. Cloudbleed2 may only affect a single system—that of content delivery network provider Cloudflare—but it’s affecting large numbers of sites across the Internet because of the significant sites it hosts, including Uber, OK Cupid, and Fitbit, among thousands of others. El Reg has an excellent breakdown of the actual vulnerability3 (a buffer overflow), if you’re interested in the gory details.
Whether a vulnerability is leaking private keys or conversations, personal data or identities, the reality is that most software used to make what we simply call “the Internet” work is often vulnerable. Whether part of the unseen systems that make up a cloud service or executing within the confines of data center grade hardware, software is ultimately what makes the digital world run.
In the case of Cloudbleed, security blogger Ryan Lackey notes, “the most sensitive information leaked is authentication information and credentials. A compromise of this data can have lasting and ongoing consequences until credentials are revoked and replaced.”4
It’s important to note that the advantage of this vulnerability being part of a cloud service is that it has already been patched. For everyone. Unlike Heartbleed, which as recently as January 2017 was still an issue for nearly 200,000 unpatched servers5, cloud service providers can mitigate threats for everyone at the same time.
So, you can breathe easy. Or can you?
Sadly, the answer is no. The vulnerability has been actively exploited for at least weeks, perhaps longer, which puts organizations and individuals in a tough spot. For individuals, they should immediately change passwords at any potentially affected site. A Github user has started compiling a list6, but it is not exhaustive. Translation: if the app or service is important to you, change your password now. Don’t waste time trying to figure out if it was or wasn’t impacted. Just change them now. If you aren’t using two-factor authentication options, seriously consider doing so, or at least turning on notifications of logins so you aren’t caught unawares.
Organizations need to consider the type of data potentially leaked to chart a course forward. Credentials were leaked. API keys were leaked. Keys were leaked. Cookies were leaked. Full requests and responses were leaked, with headers and data and everything else in it. This is not going to be easy to address. If you are a Cloudflare customer, you should be in full risk assessment mode right now.
Given the breadth of data leaked by Cloudbleed, we don’t have a comprehensive “here is everything you need to do” yet because details of what data was leaked into the wild are still being uncovered. As of right now, you’re going to need to:
Maybe you’re thinking, “Well, I don’t use Cloudflare, so it doesn’t affect me.”
It most certainly does. You have employees who are consumers of many of the services—Uber, Fitbit—that we know may have been compromised. And we know from survey upon survey that employees often “reuse” passwords and credentials not just across sites, but across corporate-consumer lines. My Uber account has a personal and a corporate identity, and if I’m a typical employee (note to my manager, I’m not, really), I may have reused my corporate credentials for my Uber account.
Attackers know this. They count on this. So you need to consider very carefully what your next steps might be. Perhaps you can roll out credential resets with less urgency, but you should definitely consider rolling them out for employees, even if you aren’t a Cloudflare customer.
If you haven’t put multi-factor authentication (MFA) into place, you should plan on it. Having MFA in place means you don’t have to panic every time a provider is compromised. You can reset credentials in a rational fashion. Basically, MFA affords you some peace of mind during a potential identity compromise, the same way a Web Application Firewall (WAF) does with application vulnerabilities. You still need to deal with the underlying issue, you just have gap insurance that gives you the time to deal with it without blowing a gasket (or three).
Finally, make sure your limitation of liability in all service provider contracts covers the brand impact of a breach and any required disclosure costs. By default, these contracts typically don’t. Given the frequency of disclosures, however, it’s well worth fighting for. (Having that liability number defined is important, anyway. It’s used in many discussions from budgeting, to board presentations, to debates with business leaders about what not to do.)
This is not going to be the last time something bleeds credentials or sensitive data. Software is vulnerable, and it’s software that powers the Internet (that means the cloud, too).
And when you’ve got this under control, sit down with your IT leaders and put together a response plan for dealing with these kinds of potential data leaks in the future. Because the digital economy runs on software, and when software is exploited these days, it bleeds data.
MODIFIED: Jan 12, 2018