Fwd: Serious Cloudflare bug exposed a potpourri of secret customer data
(h/t to Richard Forno) After you're done reading the Ars Technica article excerpted and linked below, you may also want to read: Cloudflare Reverse Proxies Are Dumping Uninitialized Memory https://news.ycombinator.com/item?id=13718752 and, as background: CloudFlare, We Have A Problem http://cryto.net/~joepie91/blog/2016/07/14/cloudflare-we-have-a-problem/ and then perhaps consider this comment from the Ycombinator thread: Where would you even start to address this? Everything you've been serving is potentially compromised, API keys, sessions, personal information, user passwords, the works. You've got no idea what has been leaked. Should you reset all your user passwords, cycle all or your keys, notify all your customers that there data may have been stolen? My second thought after relief was the realization that even as a consumer I'm affected by this, my password manager has > 100 entries what percentage of them are using CloudFlare? Should I change all my passwords? ---rsk ----- Forwarded message from Richard Forno <rforno@infowarrior.org> -----
From: Richard Forno <rforno@infowarrior.org> Date: Fri, 24 Feb 2017 07:30:21 -0500 To: Infowarrior List <infowarrior@attrition.org> Subject: [Infowarrior] - Serious Cloudflare bug exposed a potpourri of secret customer data
Serious Cloudflare bug exposed a potpourri of secret customer data
Service used by 5.5 million websites may have leaked passwords and authentication tokens.
Dan Goodin - 2/23/2017, 8:35 PM
Cloudflare, a service that helps optimize the security and performance of more than 5.5 million websites, warned customers today that a recently fixed software bug exposed a range of sensitive information that could have included passwords, and cookies and tokens used to authenticate users.
A combination of factors made the bug particularly severe. First, the leakage may have been active since September 22, nearly five months before it was discovered, although the greatest period of impact was from February 13 and February 18. Second, some of the highly sensitive data that was leaked was cached by Google and other search engines. The result was that for the entire time the bug was active, hackers had the ability to access the data in real-time, by making Web requests to affected websites, and to access some of the leaked data later by crafting queries on search engines.
"The bug was serious because the leaked memory could contain private information and because it had been cached by search engines," Cloudflare CTO John Graham-Cumming wrote in a blog post published Thursday. "We are disclosing this problem now as we are satisfied that search engine caches have now been cleared of sensitive information. We have also not discovered any evidence of malicious exploits of the bug or other reports of its existence."
The leakage was the result of a bug in an HTML parser chain Cloudflare uses to modify Web pages as they pass through the service's edge servers. The parser performs a variety of tasks, such as inserting Google Analytics tags, converting HTTP links to the more secure HTTPS variety, obfuscating email addresses, and excluding parts of a page from malicious Web bots. When the parser was used in combination with three Cloudflare features???e-mail obfuscation, server-side Cusexcludes, and Automatic HTTPS Rewrites???it caused Cloudflare edge servers to leak pseudo random memory contents into certain HTTP responses. < - >
https://arstechnica.com/security/2017/02/serious-cloudflare-bug-exposed-a-po...
Useful information on potentially compromised sites due to this: https://github.com/pirate/sites-using-cloudflare Mike On 24 Feb 2017, at 10:31 pm, Rich Kulawiec <rsk@gsp.org<mailto:rsk@gsp.org>> wrote: (h/t to Richard Forno) After you're done reading the Ars Technica article excerpted and linked below, you may also want to read: Cloudflare Reverse Proxies Are Dumping Uninitialized Memory https://news.ycombinator.com/item?id=13718752 and, as background: CloudFlare, We Have A Problem http://cryto.net/~joepie91/blog/2016/07/14/cloudflare-we-have-a-problem/ and then perhaps consider this comment from the Ycombinator thread: Where would you even start to address this? Everything you've been serving is potentially compromised, API keys, sessions, personal information, user passwords, the works. You've got no idea what has been leaked. Should you reset all your user passwords, cycle all or your keys, notify all your customers that there data may have been stolen? My second thought after relief was the realization that even as a consumer I'm affected by this, my password manager has > 100 entries what percentage of them are using CloudFlare? Should I change all my passwords? ---rsk ----- Forwarded message from Richard Forno <rforno@infowarrior.org<mailto:rforno@infowarrior.org>> ----- From: Richard Forno <rforno@infowarrior.org<mailto:rforno@infowarrior.org>> Date: Fri, 24 Feb 2017 07:30:21 -0500 To: Infowarrior List <infowarrior@attrition.org<mailto:infowarrior@attrition.org>> Subject: [Infowarrior] - Serious Cloudflare bug exposed a potpourri of secret customer data Serious Cloudflare bug exposed a potpourri of secret customer data Service used by 5.5 million websites may have leaked passwords and authentication tokens. Dan Goodin - 2/23/2017, 8:35 PM Cloudflare, a service that helps optimize the security and performance of more than 5.5 million websites, warned customers today that a recently fixed software bug exposed a range of sensitive information that could have included passwords, and cookies and tokens used to authenticate users. A combination of factors made the bug particularly severe. First, the leakage may have been active since September 22, nearly five months before it was discovered, although the greatest period of impact was from February 13 and February 18. Second, some of the highly sensitive data that was leaked was cached by Google and other search engines. The result was that for the entire time the bug was active, hackers had the ability to access the data in real-time, by making Web requests to affected websites, and to access some of the leaked data later by crafting queries on search engines. "The bug was serious because the leaked memory could contain private information and because it had been cached by search engines," Cloudflare CTO John Graham-Cumming wrote in a blog post published Thursday. "We are disclosing this problem now as we are satisfied that search engine caches have now been cleared of sensitive information. We have also not discovered any evidence of malicious exploits of the bug or other reports of its existence." The leakage was the result of a bug in an HTML parser chain Cloudflare uses to modify Web pages as they pass through the service's edge servers. The parser performs a variety of tasks, such as inserting Google Analytics tags, converting HTTP links to the more secure HTTPS variety, obfuscating email addresses, and excluding parts of a page from malicious Web bots. When the parser was used in combination with three Cloudflare features???e-mail obfuscation, server-side Cusexcludes, and Automatic HTTPS Rewrites???it caused Cloudflare edge servers to leak pseudo random memory contents into certain HTTP responses. < - > https://arstechnica.com/security/2017/02/serious-cloudflare-bug-exposed-a-po... This email and any attachment to it are confidential. Unless you are the intended recipient, you may not use, copy or disclose either the message or any information contained in the message. If you are not the intended recipient, you should delete this email and notify the sender immediately. Any views or opinions expressed in this email are those of the sender only, unless otherwise stated. All copyright in any sep2 material in this email is reserved. All emails, incoming and outgoing, may be recorded by sep2 and monitored for legitimate business purposes. sep2 exclude all liability for any loss or damage arising or resulting from the receipt, use or transmission of this email to the fullest extent permitted by law. sep2 limited is Registered in England number 09988870, registered office sep2 limited, Swale Suite, 2nd Floor, 5 York Place, Leeds LS1 2DR
On Sat, Feb 25, 2017 at 07:21:48AM +0000, Mike Goodwin wrote:
Useful information on potentially compromised sites due to this:
"This list contains all domains that use Cloudflare DNS" That's only marginally more useful than saying "any domain matching /^.*$/"; plenty of domains use Cloudflare's DNS without using the proxy service (and it is, barely, possible to use the proxy service which had the bug without using the DNS service). - Matt -- A byte walks into a bar and orders a pint. Bartender asks him "What's wrong?" The byte says "Parity error." Bartender nods and says "Yeah, I thought you looked a bit off."
On Thu, Mar 2, 2017 at 5:15 PM, Matt Palmer <mpalmer@hezmatt.org> wrote:
On Sat, Feb 25, 2017 at 07:21:48AM +0000, Mike Goodwin wrote:
Useful information on potentially compromised sites due to this: https://github.com/pirate/sites-using-cloudflare "This list contains all domains that use Cloudflare DNS"
That's only marginally more useful than saying "any domain matching /^.*$/";
Iirc; It's quite easy to use the Proxy service without the DNS service, as long as you are using a Paid CF account for the domain and not a free account. Also; Querying after the fact is not very scientific, Because there may be domains that _Were_ using CF proxy service During the incident which no longer use CF DNS or Proxy servers, for whatever reason. If you're going to scrape DNS records to decide, should probably be scraping A records for www, and then checking Reverse DNS or matching against possible CF IP addresses, not NS records.
- Matt -- -JH
participants (4)
-
Jimmy Hess -
Matt Palmer -
Mike Goodwin -
Rich Kulawiec