Auteur Sujet: Pas d'attaque, fuite massive d'information de Cloudflare y compris des clefs  (Lu 2042 fois)

0 Membres et 1 Invité sur ce sujet

corrector

  • Invité
Major Cloudflare bug leaked sensitive data from customers’ websites

Cloudflare revealed a serious bug in its software today that caused sensitive data like passwords, cookies, authentication tokens to spill in plaintext from its customers’ websites. The announcement is a major blow for the content delivery network, which offers enhanced security and performance for more than 5 million websites.

This could have allowed anyone who noticed the error to collect a variety of very personal information that is typically encrypted or obscured.

Remediation was complicated by an additional wrinkle. Some of that data was automatically cached by search engines, making it particularly difficult to clean up the aftermath as Cloudflare had to approach Google, Bing, Yahoo and other search engines and ask them to manually scrub the data.

The leak may have been active as early as Sept. 22, 2016, almost five months before a security researcher at Google’s Project Zero discovered it and reported it to Cloudflare.

However, the most severe leakage occurred between Feb. 13 and Feb. 18, when around 1 in every 3,300,000 HTTP requests to Cloudflare sites would have caused data to be exposed. Attackers could have accessed the data in real-time, or later through search engine caches.

Cloudflare notes in its announcement of the issue that even at its peak, data only leaked in about 0.00003% of requests. It doesn’t sound like much, but Cloudflare’s massive customer base includes categories like dating websites and password managers, which host particularly sensitive data.

“At the peak, we were doing 120,000 leakages of a piece of information, for one request, per day,” Cloudflare chief technology officer  John Graham-Cumming told TechCrunch. He emphasized that not all of those leakages would have contained secret information. “It’s random stuff in there because it’s random memory,” he said.

The bug occurred in an HTML parser that Cloudflare uses to increase website performance — it preps sites for distribution in Google’s publishing platform AMP and upgrades HTTP links to HTTPS. Three of Cloudflare’s features (email obfuscation, Server-side Excludes and Automatic HTTPS Rewrites) were not properly implemented with the parser, causing random chunks of data to become exposed.

Ultimately, even Cloudflare itself was affected by the bug. “One obvious piece of information that had leaked was a private key used to secure connections between Cloudflare machines,” Graham-Cumming wrote in Cloudflare’s announcement. The encryption key allowed the company’s own machines to communicate with each other securely, and was implemented in 2013 in response to concerns about government surveillance.

Graham-Cumming emphasized that Cloudflare discovered no evidence that hackers had discovered or exploited the bug, noting that Cloudflare would have seen unusual activity on their network if an attacker were trying to access data from particular websites.

“It was a bug in the thing that understands HTML,” Graham-Cumming explained. “We understand the modifications to web pages on the fly and they pass through us. In order to do that, we have the web pages in memory on the computer. It was possible to keep going past the end of the web page into memory you shouldn’t be looking at.”

Cloudflare’s teams in San Francisco and London handed off shifts to one another, working around the clock to fix the bug once it was reported. They had stopped the most severe issue within seven hours. It took six days for the company to completely repair the bug and to work with search engines to scrub the data.

Tavis Ormandy, an engineer at Google, first noticed the bug, which he jokingly called “Cloudbleed” in reference to the Heartbleed vulnerability. He said in a blog post that he encountered unexpected data during a project and wondered at first if there was a bug in his own code. Upon further testing, he realized the leak was coming from Cloudflare.

“We fetched a few live samples, and we observed encryption keys, cookies, passwords, chunks of POST data and even HTTPS requests for other major Cloudflare-hosted sites from other users,” Ormandy wrote. “This situation was unusual, [personally-identifiable information] was actively being downloaded by crawlers and users during normal usage, they just didn’t understand what they were seeing.” Ormandy added that he later destroyed the samples because of the sensitive information they contained, but he posted redacted screenshots of some of the information leaked from Uber, Fitbit and OkCupid.

Beyond the samples Ormandy collected, it’s not clear what other information may have leaked. “It’s very hard to say, because this information is transient,” Graham-Cumming said. But Ormandy says his samples revealed highly sensitive data.

“We keep finding more sensitive data that we need to cleanup. I didn’t realize how much of the internet was sitting behind a Cloudflare CDN until this incident,” Ormandy wrote. “I’m finding private messages from major dating sites, full messages from a well-known chat service, online password manager data, frames from adult video sites, hotel bookings. We’re talking full HTTPS requests, client IP addresses, full responses, cookies, passwords, keys, data, everything.”

Although Cloudflare worked with Ormandy to address the issue, he contends that the company’s final blog post on the matter “severely downplays the risk to customers.” Ormandy also expressed frustration that Cloudflare didn’t move faster in the remediation process.

But Graham-Cumming says it wouldn’t have been possible for Cloudflare to work any more quickly than it did. Graham-Cumming also says that Ormandy called Cloudflare’s disclosure “completely acceptable” when he reviewed a copy.

“This is subject to a 90 day disclosure. We were disclosing after six days,” Graham-Cumming said. “He’s saying he’s frustrated but I’m a little bemused at why he’s frustrated with six days rather than 90. We would have disclosed even earlier, but because some of this info had been cached, we thought we had a duty to clean that up before it became public. There was a danger that info would persist in search engines like Google.”

Graham-Cumming said that Cloudflare customers like Uber and OkCupid weren’t directly notified of the data leaks because of the security risks involved in the situation. “There was no backdoor communication outside of Cloudflare — only with Google and other search engines,” he said.

Source : https://techcrunch.com/2017/02/23/major-cloudflare-bug-leaked-sensitive-data-from-customers-websites/

Résumé (je n'ai pas eu le temps de tout lire et comprendre) : sans la moindre attaque informatique, les proxy ont publié des informations confidentielles (y compris des clefs privées appartenant à Cloudflare) sur le Web y compris le cache Google.

corrector

  • Invité
Pas d'attaque, fuite massive d'information de Cloudflare y compris des clefs
« Réponse #1 le: 24 février 2017 à 22:09:44 »
Incident report on memory leak caused by Cloudflare parser bug
23 Feb 2017 by John Graham-Cumming.

Last Friday, Tavis Ormandy from Google’s Project Zero contacted Cloudflare to report a security problem with our edge servers. He was seeing corrupted web pages being returned by some HTTP requests run through Cloudflare.

It turned out that in some unusual circumstances, which I’ll detail below, our edge servers were running past the end of a buffer and returning memory that contained private information such as HTTP cookies, authentication tokens, HTTP POST bodies, and other sensitive data. And some of that data had been cached by search engines.

For the avoidance of doubt, Cloudflare customer SSL private keys were not leaked. Cloudflare has always terminated SSL connections through an isolated instance of NGINX that was not affected by this bug.

We quickly identified the problem and turned off three minor Cloudflare features (email obfuscation, Server-side Excludes and Automatic HTTPS Rewrites) that were all using the same HTML parser chain that was causing the leakage. At that point it was no longer possible for memory to be returned in an HTTP response.
Because of the seriousness of such a bug, a cross-functional team from software engineering, infosec and operations formed in San Francisco and London to fully understand the underlying cause, to understand the effect of the memory leakage, and to work with Google and other search engines to remove any cached HTTP responses.

Having a global team meant that, at 12 hour intervals, work was handed over between offices enabling staff to work on the problem 24 hours a day. The team has worked continuously to ensure that this bug and its consequences are fully dealt with. One of the advantages of being a service is that bugs can go from reported to fixed in minutes to hours instead of months. The industry standard time allowed to deploy a fix for a bug like this is usually three months; we were completely finished globally in under 7 hours with an initial mitigation in 47 minutes.

The bug was serious because the leaked memory could contain private information and because it had been cached by search engines. We have also not discovered any evidence of malicious exploits of the bug or other reports of its existence.

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 (that’s about 0.00003% of requests).
We are grateful that it was found by one of the world’s top security research teams and reported to us.
This blog post is rather long but, as is our tradition, we prefer to be open and technically detailed about problems that occur with our service.

(...)

Source : https://blog.cloudflare.com/incident-report-on-memory-leak-caused-by-cloudflare-parser-bug/

thenico

  • Expert.
  • Abonné OVH
  • *
  • Messages: 1 009
  • FTTH >500 Mb/s (13)
Pas d'attaque, fuite massive d'information de Cloudflare y compris des clefs
« Réponse #2 le: 25 février 2017 à 01:47:44 »
Contrairement à l'insistance du message de CloudFlare, un leak des clefs privée n'auraient pas été trop grave car on sait désormais comment traiter le problème (utilisation de PFS pour les rendres inutiles à ceux qui stockent les communications chiffrés et depuis le bug OpenSSL Debian, les sysadmins ont appris à changer les certificats).
(Let's encrypt aide aussi avec les clefs à durée de vie courte).
En clair, un leak des clé privée: chiant mais pas trop grave.

Par contre, les données perso disséminé dans des caches un peu partout sur Internet, ce n'est pas maitrisable.
Même après l'épuration chez Google, on pouvait continuer à trouver des exemples dans le Google Cache.
Donc les spiders privées doivent avoir une belle mine de données exploitables et peut-être commercialisable.

CloudFlare a vraiment fait un #epic fail!

corrector

  • Invité
Pas d'attaque, fuite massive d'information de Cloudflare y compris des clefs
« Réponse #3 le: 25 février 2017 à 08:44:05 »
Pas trop grave si tu es au courant.

La clé privée permet quand même de réussir un MITM indétectable.

thenico

  • Expert.
  • Abonné OVH
  • *
  • Messages: 1 009
  • FTTH >500 Mb/s (13)
Pas d'attaque, fuite massive d'information de Cloudflare y compris des clefs
« Réponse #4 le: 25 février 2017 à 10:04:32 »
La clé privée permet quand même de réussir un MITM indétectable.

Oui mais entre un MITM possible et un leak d'information privé très probable, quel est le pire ?

Anonyme

  • Invité
Pas d'attaque, fuite massive d'information de Cloudflare y compris des clefs
« Réponse #5 le: 25 février 2017 à 10:21:24 »
Dear Valued Client,

As you may know, Vultr utilizes Cloudflare's CDN product to enhance the speed of our website around the globe and protect against various malicious attacks on our site.

Cloudflare recently revealed a security vulnerability that may have resulted in private data from sites whose data is behind the Cloudflare CDN. According to Cloudflare’s security team, 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. While Cloudflare patched the discovered issue quickly, it was possible sensitive data was leaked to third party search engines that cache data such as Google.com.

Cloudflare has worked with the security team from Google to search cached data for any relevant Vultr links and has confirmed no data was found. Based on this we have no reason to believe any Vultr customer information has been compromised via this Cloudflare bug.

This is a good opportunity to remind you of best security practices to secure your account:

* Enable 2 factor authentication for your main vultr.com account login.
* Change your control panel password every 90 days (or less).
* Always change your Instance’s default password after initial deploy.
* If you utilize the API service, ensure your API IP ACLs are configured correctly.
* Routinely scan your computer for malware, spyware, browser extensions, and Virii that could compromise or leak private information.

We will continue to closely monitor the situation and stay in close contact with Cloudflare should there be any change in the facts we have received thus far. Your account security is our top priority here at Vultr.

Additional Background Information:

https://blog.cloudflare.com/incident-report-on-memory-leak-caused-by-cloudflare-parser-bug/
https://bugs.chromium.org/p/project-zero/issues/detail?id=1139


Regards,

The Vultr Team

corrector

  • Invité
Pas d'attaque, fuite massive d'information de Cloudflare y compris des clefs
« Réponse #6 le: 25 février 2017 à 11:00:46 »
Oui mais entre un MITM possible et un leak d'information privé très probable, quel est le pire ?
Je dirais que les deux sont graves, tout dépend du type de site et de la quantité d'information leakée!