How Bad Was CloudBleed? 1.2 Million Leaks Bad (Forbes)

Google CloudFlare CloudBleed bug nightmare

The CloudBleed bug could have leaked secrets from major web companies, like Uber and OKCupid, Google researchers claim. (Image credit: Google).

Over the last few days, CloudFlare has been assessing the damage of the now-infamous CloudBleed bug that leaked memory from web servers across the internet. The numbers indicate a startling amount of data leakage, a sign that the vulnerability really was as nasty as Google researcher Tavis Ormandy predicted when he first discovered it. But it appears the actual impact has so far been minimal.

But first, those epic leak stats from CloudFlare: between September 22 2016, when the vulnerable code was introduced, and 18 February 2017 it’s estimated the bug was triggered 1,242,071 times. Initially, when the vulnerable HTML parser was introduced in September, the number of sites affected was 180. But that went up to 6,457 when CloudFlare issued an update on 13 February so that the parser was more widely used.

Looking at search engine caches with Google, Microsoft Bing and Yahoo, CloudFlare was able to get some idea about the kinds of information leaked. The most concerning find was that in half of all leaks, it’s likely there was a cookie. Such cookies could be used to gain access to a user account of an affected website. Together, the tech companies had to purge 80,000 cached pages where customer information had been leaked when the likes of Google indexed the sites and then triggered the bug.

Big numbers, low impact?

Those numbers are huge. But as for real-world account hacks, there’s no evidence of any yet, according to CloudFlare CEO Matthew Prince, who spoke to FORBES from the firm’s London offices Wednesday. First, each of the 1.2 million leaks would not have resulted in sensitive data being exposed; that’s because the returned info was random. Furthermore, since POST requests (typically where a user provides information to the site) were more likely to contain sensitive data like passwords, CloudFlare estimated the exposure of the most private information was closer to 12,420, rather than 1.2 million.

And so far, no user passwords, credit card information, health records or customer encryption keys are known to have leaked. “We got lucky,” Prince said. “This could have been exceptionally bad.” It’s worth noting the estimates are based on the small amount of logs CloudFlare keeps: one per cent of all traffic passing through the company’s content delivery network.

Crucially, there’s no evidence a malicious hacker found the bug before Google did, or even between the two-day period in which CloudFlare remediated the issue on its own servers. Prince said logs had not recorded any unusual spikes in traffic that would have shown a hacker was attempting to force servers to cough up useful information; remember that when CloudBleed triggered with every HTTP request that came in, it returned only random memory, so anyone hoping to steal people’s passwords would have to keep trying until they got lucky.

There remains, though, some misunderstanding of the bug and its overall impact, said Prince. While true that only 6,457 websites had the requisite settings to have leaked information, any of the 6 million sites on the CloudFlare network could have been affected. Indeed, the bigger the site the more likely they’d have information exposed; as CloudFlare customers share infrastructure, anyone visiting a CloudFlare server during a period in which it was vulnerable would have had information returned from whatever data was passing around the network. It’d be far more likely that data was from a popular site getting a massive number of requests flowing around the CloudFlare network.

For instance, a company the size of a customer like Uber would receive somewhere between 50 billion and 100 billion requests a month, and so could have leaked somewhere between 5,962 and 11,427 times, CloudFlare said. (Uber previously said it had determined minimal exposure with just a handful of user session tokens). Though the impact was likely minimal, the fact that companies with non-vulnerable sites were still exposed highlighted a real downside in centralizing so much of the web, admitted Prince.

CloudFlare CloudBleed leaks per customer popularity

CloudFlare’s breakdown of estimated number of CloudBleed leaks, depending on the popularity of the site. The more visitors to a site, the more likely it was they leaked.

Far from wiping its hands clean of the issue, CloudFlare is continuing to investigate its error. It’s employed Veracode, a firm headed up by former hacker Chris Wyospal, to review CloudFlare code, in particular anything that could lead to a similarly massive leak.

Prince, meanwhile, understands if people are angry. “I think they have every right to be pissed… I’d be pissed.”

Got a tip? Email at or for PGP mail. Get me on Signal on +447837496820 or on Jabber for encrypted chat.

Source: SANS ISC SecNewsFeed @ March 1, 2017 at 10:30AM