Página 1 de 2 12 ÚltimoÚltimo
Resultados 1 a 10 de 20
  1. #1
    WHT-BR Top Member
    Data de Ingresso
    Dec 2010
    Posts
    18,489

    [EN] Major Cloudflare bug leaked sensitive data from customers’ websites

    Three of Cloudflare’s features (email obfuscation, Server-side Excludes and Automatic HTTPS Rewrites) were not properly implemented causing chunks of data to become exposed.

    Kate Conger
    Feb 24, 2017

    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.

    https://techcrunch.com/2017/02/23/ma...mers-websites/

  2. #2
    WHT-BR Top Member
    Data de Ingresso
    Dec 2010
    Posts
    18,489

    Incident report on memory leak caused by Cloudflare parser bug

    John Graham-Cumming
    23 Feb 2017

    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.

    ...

    Detailed Timeline

    We are very grateful to our colleagues at Google for contacting us about the problem and working closely with us through its resolution. All of which occurred without any reports that outside parties had identified the issue or exploited it.

    All times are UTC.

    Código:
    2017-02-18 0011 Tweet from Tavis Ormandy asking for Cloudflare contact information
    2017-02-18 0032 Cloudflare receives details of bug from Google
    2017-02-18 0040 Cross functional team assembles in San Francisco
    2017-02-18 0119 Email Obfuscation disabled worldwide
    2017-02-18 0122 London team joins
    2017-02-18 0424 Automatic HTTPS Rewrites disabled worldwide
    2017-02-18 0722 Patch implementing kill switch for cf-html parser deployed worldwide
    
    2017-02-20 2159 SAFE_CHAR fix deployed globally
    
    2017-02-21 1803 Automatic HTTPS Rewrites, Server-Side Excludes 
                            and Email Obfuscation re-enabled worldwide
    https://blog.cloudflare.com/incident...re-parser-bug/

  3. #3
    WHT-BR Top Member
    Data de Ingresso
    Dec 2010
    Posts
    18,489
    “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.”


    Ormandy contends that Cloudflare’s final blog post on the matter “severely downplays the risk to customers.”

    Última edição por 5ms; 24-02-2017 às 07:48.

  4. #4
    WHT-BR Top Member
    Data de Ingresso
    Dec 2010
    Posts
    18,489

    Cloudbleed: Big web brands leaked crypto keys, personal secrets

    Iain Thomson
    24 Feb 2017

    Big-name websites leaked people's private session keys and personal information into strangers' browsers, due to a Cloudflare bug uncovered by Google researchers.

    As we'll see, a single character – '>' rather than '=' – in Cloudflare's software source code sparked the security blunder.

    Cloudflare helps companies spread their websites and online services across the internet. Due to a programming blunder, for several months Cloudflare's systems slipped random chunks of server memory into webpages, under certain circumstances. That means if you visited a website powered by Cloudflare, you may have ended up getting chunks of someone else's web traffic hidden in your browser page.

    For example, Cloudflare hosts Uber, OK Cupid, and Fitbit, among thousands of others. It was discovered that visiting any site hosted by Cloudflare would sometimes cough up sensitive information from strangers' Uber, OK Cupid, and Fitbit sessions. Think of it as sitting down at a restaurant, supposedly at a clean table, and in addition to being handed a menu, you're also handed the contents of the previous diner's wallet or purse.

    This leak was triggered when webpages had a particular combination of unbalanced HTML tags, which confused Cloudflare's proxy servers and caused them to spit out data belonging to other people – even if that data was protected by HTTPS.



    Leaked ... Some unlucky punter's Fitbit session slips into another a random visitor's web browser. Click to enlarge (Source: Google Project Zero)

    Normally, this injected information would have gone unnoticed, hidden away in the webpage source, but the leak was noticed by security researchers – and the escaped data made its way into the Google cache and the hands of other bots trawling the web.
    Timeline

    The blunder was first spotted by Tavis Ormandy, the British bug hunter at Google's Project Zero security team, when he was working on a side project last week. He found large chunks of data including session and API keys, cookies and passwords in cached pages crawled by the Google search engine. These keys can be used to log into services as someone else.

    "The examples we're finding are so bad, I cancelled some weekend plans to go into the office on Sunday to help build some tools to clean up," he said today in an advisory explaining the issue.

    "I've informed Cloudflare what I'm working on. 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."

    Ormandy said that the Google team worked quickly to clear any private information and that Cloudflare assembled a team to deal with it. He provisionally identified the source of the leaks as Cloudflare's ScrapeShield application, which is designed to stop bots copying information from websites wholesale, but it turns out the problems ran deeper than that.

    Cloudflare have been leaking customer HTTPS sessions for months. Uber, 1Password, FitBit, OKCupid, etc. https://t.co/wjwE4M3Pbk
    — Tavis Ormandy (@taviso) February 23, 2017

    On Thursday afternoon, Cloudflare published a highly detailed incident report into the issue: it happens that Cloudflare's Email Obfuscation, Server-Side Excludes and Automatic HTTPS Rewrites functions were the culprits.

    The problem occurred when the company decided to develop a new HTML parser for its edge servers. The parser was written using Ragel, and turned into machine-generated C code. This code suffered from a buffer overflow vulnerability triggered by unbalanced HTML tags on pages. This is the broken pointer-checking source that is supposed to stop the program from overwriting its memory:

    What happens is that elsewhere p becomes greater than pe, thus it avoids the length check, allowing the buffer to overflow with extra information. This eventually leads to the above web session leaks.

    "The root cause of the bug was that reaching the end of a buffer was checked using the equality operator and a pointer was able to step past the end of the buffer," said Cloudflare's head of engineering John Graham-Cumming in the biz's incident report.

    "Had the check been done using >= instead of == jumping over the buffer end would have been caught."

    According to Graham-Cumming, for data to leak, the final buffer had to finish with a malformed script or img tag, be less than 4KB in length (otherwise Nginx would crash), and be running the three functions.

    The new cf-html parser was added to Cloudflare's Automatic HTTP Rewrites function on September 22, 2016, to its Server-Side Excludes app on January 30 this year, and partially added to the biz's Email Obfuscation feature on February 13. It was only in the Email Obfuscation case that significant memory leakage appears to have happened, which tipped off Ormandy.

    Cloudflare does have a kill switch for the more recent of its functions and shut down Email Obfuscation within 47 minutes of hearing from Ormandy. It did the same for Automatic HTTPS Rewrites a little over three hours later. Server-Side Excludes couldn't be killed, but the company says it developed a patch within three hours.

    Cloudflare says SAFE_CHAR logging shows that the period of greatest leakage occurred between February 13 and 18, and even then that around 1 in every 3,300,000 HTTP requests through Cloudflare leaked data across 3,438 unique domains. It says that it held off disclosing the issue until it was sure that search engines had cleared their caches.

    In posts on Hacker News, Ormandy pointed out that the 3,438 figure only covers direct queries, and that any information that passed through Cloudflare's hands was vulnerable to leakage.

    He has also noted that the top award for Cloudflare's bug bounty program is a t-shirt. Maybe the web giant will reconsider that in the future.

    https://www.theregister.co.uk/2017/0...personal_data/

  5. #5
    WHT-BR Top Member
    Data de Ingresso
    Dec 2010
    Posts
    18,489
    Comment 26 by m...@tjhorner.com, Today (6 hours ago)

    Is it really not? Google account OAuth tokens stored by third-party apps that use Cloudflare could have been exposed. It's weird, too, since it also deauthed every app I was signed into, including Google Apps Script. It seems that something on your end went through every request you had in that data sample (and Google's cache), invalidated tokens if it found any, then prompted the user to sign in again.

    Like David, I'm just speculating, as I couldn't find anything related to this in my G Suite console as well.




    Comment 29 by raptormi...@gmail.com, Today (6 hours ago)

    Hi Tavis, could you tell us why a lot of people had to re-authenticate their Google accounts on their devices all of the sudden? It may not have been related, but Google definitely did something that had us all re-authenticate.



    Project Member Comment 30 by taviso@google.com, Today (5 hours ago)

    I couldn't tell you, this is not the correct place to ask.

    This is not a discussion forum, I'm closing additional comments.

    https://bugs.chromium.org/p/project-...detail?id=1139

  6. #6
    WHT-BR Top Member
    Data de Ingresso
    Nov 2010
    Posts
    1,669
    https://tecnoblog.net/209479/cloudfl...lha-vazamento/

    Sobre o google, levei um susto quando o app informava que minha conta foi alterada...

    https://tecnoblog.net/209480/google-...ectados-falha/
    oGigante.com*• Revenda de Hospedagem Cloud Linux + WHMCS Grátis
    VWhost.com.br • Revenda de Hospedagem Linux Cpanel + CloudFlare
    Zocka.com.br • Hospedagem de Sites Cpanel + Construtor de Sites

  7. #7
    WHT-BR Top Member
    Data de Ingresso
    Dec 2010
    Posts
    18,489
    Citação Postado originalmente por chuvadenovembro Ver Post
    Sobre o google, levei um susto quando o app informava que minha conta foi alterada...
    O procedimento do Google poderá ocorrer em muitos outros sites.

    As medidas de redução de danos tentam desviar o foco da enormidade da coisa: são os visitantes que estão correndo os maiores riscos. Google, Bing, Yahoo! podem remover as páginas armazenadas, mas a Cloudflare tem indicado sites que sequer usam a Cloudflare e deixado de indicar outros. Mais importante é que os 400 bilhões de bots não irão remover coisa alguma e, oportunisticamente, já circula FUD envolvendo Baidu e governo chinês. Para os clientes da Cloudflare, medidas como a que o Google tomou (não confirma ter relação com o desastre) "resolvem" o problema. Mas internautas podem sequer saber que acessaram sites via Cloudflare e seus dados, incluindo senha, estão comprometidos.

  8. #8
    WHT-BR Top Member
    Data de Ingresso
    Dec 2010
    Posts
    18,489

  9. #9
    WHT-BR Top Member
    Data de Ingresso
    Dec 2010
    Posts
    18,489

    Vultr.com - Important Security Notice

    Received: from mail1.vultr.com (mail1.vultr.com [108.61.150.28])
    Date: Fri, 24 Feb 2017 11:49:28 -0500


    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...re-parser-bug/
    https://bugs.chromium.org/p/project-...detail?id=1139


    Regards,

    The Vultr Team

  10. #10
    WHT-BR Top Member
    Data de Ingresso
    Dec 2010
    Posts
    18,489
    "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."

    A mesma cretinice de sempre. Não existe prova negativa.
    Última edição por 5ms; 24-02-2017 às 14:49.

Permissões de Postagem

  • Você não pode iniciar novos tópicos
  • Você não pode enviar respostas
  • Você não pode enviar anexos
  • Você não pode editar suas mensagens
  •