CloudBleed: check if you visited sites affected by CloudFlare's security issue

Martin Brinkmann
Feb 26, 2017
Security
|
36

CloudBleed is the unofficial name for a security issue discovered on February 17th, 2017 that affected CloudFlare's reverse proxies.

CloudFlare is a large provider that is used by more than 5.5 million Internet properties according to the company's website. It offers CDN and DDOS protection, optimization technologies for websites, dedicated SSL and a lot more.

The basic service is offered for free, but webmasters and organizations may upgrade to a paid plan for additional features and better protection.

The security issue at hand caused the servers to "run past the end of a buffer" which returned memory that contained private information. Among other things, it might have included HTTP cookies, authentication tokens, HTTP Post bodies, and other sensitive data.

The issue was disclosed by Google's Project Zero, and has since been fixed by CloudFlare.

Cloudbleed

cloudflare security issue cloudbleed

The main issue for Internet users is that their authentication cookies or data may have leaked. Search engines may have cached the data, and attackers may have exploited the issue as well to gather the data.

Since there is no record whether individual user data was leaked or not, some experts suggests that users change passwords on all sites and services that use CloudFlare. This is a difficult thing for most users however, as it is quite time consuming to find out whether services and sites use CloudFlare.

The Firefox add-on and Chrome Extension CloudBleed changes that. Designed by the NoSquint Plus author, it is parsing the browsing history of the browser to reveal any site or service that uses CloudFlare.

This enables you to go quickly through the listing to identify sites that you have an account on.

The extensions work identical in both browsers. Simply install it in your browser of choice, and click on the icon that it adds to the main toolbar of the browser.

The page that loads includes a short explanation, and a search button that you need to click on. The extension goes through the browsing history then, and checks whether sites in the history were affected by the issue.

Some sites may appear multiple times in the listing. An option to filter sites by domain, or subdomain, would have been useful.

The author notes that all processing is done on the local system. All that is left afterwards is to go through the list to identify the sites with accounts.

Closing Words

CloudBleed is a handy browser extension for Google Chrome and Firefox. You may use it to reveal sites affected by CloudFlare's recent security issue quickly, provided that you did not delete the browsing history in the meantime.

Now You: Have you changed account passwords of affected sites?

Summary
CloudBleed: check if you visited sites affected by CloudFlare's security issue
Article Name
CloudBleed: check if you visited sites affected by CloudFlare's security issue
Description
CloudBleed is a new browser extension for Google Chrome and Mozilla Firefox that reveals sites affected by CloudFlare's recent security issue.
Author
Publisher
Ghacks Technology News
Logo
Advertisement

Previous Post: «
Next Post: «

Comments

  1. Owl said on March 1, 2017 at 10:56 am
    Reply

    A person posting on AskWoody suggested checking whitelisted cookies in CCleaner. Sounds like good lateral thinking.

    1. Hy said on March 1, 2017 at 6:37 pm
      Reply

      Thanks for posting this. Great tip! I don’t have many whitelisted cookies in CCleaner, but I did find one which, using the “Detect Cloudflare” add-on Tom mentioned above, was from a site which the add-on said used Cloudflare. I checked the list in the Cloudbleed add-on mentioned in the article but it wasn’t in there, so just in case someone else reading this uses the service, it was Virtru, the email encryption service.

      1. Hy said on March 1, 2017 at 8:09 pm
        Reply

        I asked Virtru support about this and received this reply:

        “While http://www.virtru.com, our “marketing” site, does pull a couple resources from Cloudflare, our functional products are hosted elsewhere. Any sensitive or customer-related data, as well as anything related to our development and engineering, is hosted on secure.virtru.com which does not connect to Cloudflare at all. You’ll see that if you navigate to Virtru.com/secure-reader, the Detect Cloudflare extension won’t pick anything up.

        I’ve also alerted our marketing team to the use of Cloudflare for our main website, so they’ll be double-checking our credentials for that page.

        Thanks!”

  2. b said on February 28, 2017 at 9:04 pm
    Reply

    @Tom Hawack
    Thanks for taking your time to answer me. appreciate

  3. Clairvaux said on February 28, 2017 at 5:39 pm
    Reply

    Strange. I, too, left a comment several hours ago, with a link, and it has not been published. It never happened to me. Normally, there’s no moderation. Just a delay to allow editing by user.

    Edit : my former comment appeared just by the time I wrote this, and pressed the button ! “Awaiting moderation”, though.

  4. Clairvaux said on February 28, 2017 at 10:30 am
    Reply

    Thoughts on Cloud Bleed by Troy Hunt, one of the most qualified people in the world to talk on the subject :

    https://www.troyhunt.com/pragmatic-thoughts-on-cloudbleed

  5. Tom Hawack said on February 27, 2017 at 10:59 am
    Reply

    Another approach is to detect if the page you’re visiting uses CloudFlare. I’ve just discovered ‘Detect Cloudflare’, a Firefox add-on that does just that :

    “Adds an icon to the toolbar which indicates whether the current page uses Cloudflare. If it does, the icon changes color. Detection is performed by analyzing the response headers of all requests.”

    I’ve tested it on a site I know that does use CloudFlare, Archive.is, and indeed ‘Detect Cloudflare”s toolbar button shows the page as using CloudFlare. Good to know if the page you’re on has been fed by CloudFlare. Maybe not an add-on I’ll keep for always but for now, with the CloudBleed issue, it seems to be a valuable approach.

    Did I mention “CloudFlare”? :)

    1. b said on February 28, 2017 at 1:16 pm
      Reply

      @Tom Hawack
      checked ‘Detect Cloudflare’. the maker states it to be his first ever and to use it at own risk. no user reviews so far. are you still satisied with how it works?

      1. Tom Hawack said on February 28, 2017 at 3:06 pm
        Reply

        Still waiting. Be lucky if I get published before the end of the year.
        How to understand a game where you ignore the rules? That’s a game in itself provided the rules don’t change from one day to another. My first answer included no address, just plain text, then WHY is it delayed? This is a true pain. Could we know once and for all WHAT in a comment calls for moderation? URLs I know, OK, but latest fun is considering an edited comment as suspicious. We’re in 2017 and the moderation algorithm is craps.

      2. Tom Hawack said on February 28, 2017 at 2:44 pm
        Reply

        I’ve replied but, once again, delayed …

      3. Tom Hawack said on February 28, 2017 at 2:24 pm
        Reply

        I’ve just checked Archive.is with testers provided on https://github.com/pirate/sites-using-cloudflare/wiki/List-Search-Tools and all state Archive.is as using Cloudflare. Odd.

      4. Tom Hawack said on February 28, 2017 at 1:42 pm
        Reply

        @b, Well, yes. I started using this ‘Detect Cloudflare’ at it’s version 0.2 and updated it this morning (CET) to version 0.3.

        No issues when the main issue would be the reliability of the detection (“performed by analyzing the response headers of all requests”).

        I had checked several sites found on a list of domains said to use CloudFlare, Archive.is being one of them, and ‘Dtect Cloudflare’ ver. 0.2 spotted accordingly. Once version 0.3 installed I tested again 4-5 sites, all detected except Archive.is . Now, has Archive.is abandonned CloudFlare or is it that ‘Detect Cloudflare” ver. 0.3 failed, I don’t know.

        I’ve removed ‘Detect Cloudflare’. Not because of what I describe above but because the add-on from my point of view was intended to be used temporarily, mainly to check domains for which I had an account. I’ve checked and modified only 1 login. Not being an expert together with the fact that the CloudBleed issue is resolved and stays pertinent only for those who had private data exchange with domains at the time of the issue, I have no reason to keep on detecting CloudFlare.

        For the little story : ‘Detect Cloudflare’ includes 2 icon sizes for its toolbar buttons, 48px and 96px (of course re-dimensioned for he user’s FF layout). I was wondering if the developer isn’t in a professional context given 48px (and 96 moreover!) toolbar button icons is something I’ve never seen, heard about. Who on Earth could have 96px toolbar buttons’ icons?! With a screen of what dimensions, CinemaScope?

        Anyway…

  6. X said on February 26, 2017 at 7:32 pm
    Reply

    About 4.3 millions domains secured by Cloudfare were possibly affected between 2016-09-22 and 2017-02-18, not just a mere days ago.
    See list @ https://github.com/pirate/sites-using-cloudflare/
    Bloody lousy programming if I ever saw such!

    1. Tom Hawack said on February 26, 2017 at 9:52 pm
      Reply

      Well… I’ve discovered the so-called CloudBleed issue with this article and was surprised that according to the CloudBlood Firefox add-on only 1270 domains were concerned. Moving from hundreds to millions changes the scale. I’ve just visited the CloudFlare/CloudBlood dedicated Github page you mention and I’m hardly starting to understand that the cat is more a lion than a cat.

      That’s what happens when a content delivery network is damaged : the consequences are far more important then when a domain only is concerned. The lucky strike for those in search of fast information profit. CDNs are not only a problem for privacy they are as well for security when theirs is compromised whatever they may on their side protect those who transit their data via a CDN. This is not good. CDN or not how many sites have it all on their own servers nowadays? Not many. You enter a Web site and you enter as well (unless you’re using tools such as uBlockO) a plethora of called sites, dometimes 15, 20, I’ve seen 24! of which ad providers, trackers … and legitimate data providers. If you haven’t blocked your cookies to the visited site only you can end up having visited one place only and discover 3, 4, 6, 8 other cookies …

      What I mean is that we face at the same time a trend to have CDNs monopolize content and sites calling an increasing number of places among which those CDNs … this is getting mad. Why can a Web site not have all its data on its own servers? Some do, but less and less. I can understand ONE CDN for a site’s data, but not a dozen calls (of which always a majority for ads and trackers, mainly a small family, with always the same faces). This is insane.

      1. Tom Hawack said on February 27, 2017 at 3:07 pm
        Reply

        @ams, the most relevant part of your quick comment is “Two, at a minimum, else google may not rank your site as highly.”. And if 4, 6, 8 CDNs were required to have a higher ranking people would follow? So this is how it goes nowadays, people taking into consideration a company’s desiderata in order to be “ranked”? Not all follow these pseudo imperatives. Some people still think freely.

        Calls for heavy data, audio/video of course, but absolutely no need for 1- ads ads ads trackers trackers trackers of course but also 2- data which can be kept on the domain’s servers. Take this example : a site which makes the user download Google Fonts (fonts.googleapis.com, blocked here) for the sake of one title : 1, not 2, 3 but one title … don’t tell me this is not motivated by anything else then by the quest of a satisfying relationship with a master of the Web. Insane. And many more examples available. Sites want to be ranked, for their image, ego, but mainly for the income via ads. It’s become an infernal machine. Don’t answer pragmatism because come times where pragmatism blinds.

        The Web nowadays is totally insane.

      2. ams said on February 27, 2017 at 9:46 am
        Reply

        “site have all its data on its own servers”

        That approach doesn’t scale, and isn’t economically feasible.

        Set aside the e-commerce aspect. Imagine, for instance, if every would-be blogger were required to own/maintain his or her own co-located hardware (“own server” albeit racked in a datacenter). Few bloggers could tolerate that barrier to entry.

        Redundancy, for failover protection and/or load balancing and/or to reduce latency in serving differing geolocations (visitor traffic patterns shift continually, throughout timezones, as the world turns)

        CDN
        content delivery network
        has become a necessary aspect of the modern web

        As for “but not dozens of calls”, existence (or not) of CDNs doesn’t change that.

        “I can understand ONE CDN for a site’s data”
        Should read up n revise your “understanding. Two, at a minimum, else google may not rank your site as highly. Like, google demands that if a webmaster (an entity) is “serious”, entity will follow the practice of serving static content from a given IP address PLUS media resource files and or dynamic content from separate IP addresses ~~ and I mean “different netranges” (vs hosted on one physical server and assigned separate IP for each virtual host).

  7. Paddleless said on February 26, 2017 at 7:21 pm
    Reply

    There is information about sites that use Cloudflare, and therefore could be affected, at https://github.com/pirate/sites-using-cloudflare. I changed six passwords after looking through the Alexa Top 10000 list there. I then downloaded the zip file and found three more using:
    cat ./Downloads/sites-using-cloudflare-master/sorted_unique_cf.txt |egrep -x “site1.com|site2.com|site3.com|site4.com”
    where Downloads was the folder I’d extracted the zip file to, and site1.com, site2.com, etc. were the sites where I have accounts.

  8. Ray said on February 26, 2017 at 7:10 pm
    Reply

    Well, this wouldn’t work for me since I disable history in all my browsers! :)

    If a site is affected, I’m guessing the site would reset the password for you and notify you to change your password on next login.

    1. Ray said on February 27, 2017 at 6:41 pm
      Reply

      Tom – I’m referring to the browser extension mentioned by Martin in the article that requires looking at your browser history in order to determine if Cloudbleed is a potential issue.

      I know what Cloudflare is.

    2. BobbyPhoenix said on February 26, 2017 at 7:54 pm
      Reply

      This is my thinking too. At least it should be standard practice for all sites that are affected. Reset accounts, notify the user, and force the user to update/change their credentials at next login. I clear my history frequently, so checking my history won’t do much.

    3. Tom Hawack said on February 26, 2017 at 7:30 pm
      Reply

      The issue wasn’t related to history but to data transmitted to sites using Cloudflare as a content provider, data which included login credentials. History is concerned only by the Firefox CloudBlood add-on which will inspect a user’s history to let him know if visited sites are on its list of domains using CloudFlare as a content provider. From there on it’s up to the user to decide consequently if he considers changing logins for such sites is pertinent. History here is only a tool for the add-on.

  9. trek100 said on February 26, 2017 at 6:32 pm
    Reply

    Or you can **check online**
    by entering the URL(s) of your most critical sites
    (ie: Facebook.com), here:
    https://github.com/pirate/sites-using-cloudflare/wiki/List-Search-Tools

    As for the addon in this article (“CloudBleed”),
    I will _NOT_ install it.

    Reason: the addon author name is
    Baris Derin
    who also created 2 other
    (actually excellent and useful)
    FF addons:

    – “YouTube Flash Video Player” and
    – “Theme Font & Size Changer”

    Problem is the author
    creates “fake” new updates to these 2 FF addons
    _almost every day_.
    His “update” releases have actually _nothing new_.

    But…
    at the end of the update, a new tab opens in FF,
    asking for a money donation.
    Almost every day!

    I have donated in the past to good addon authors,
    but this method of fake, DAILY updates
    just to request money is not acceptable
    and should be looked at by addons.mozilla.com.

    Too bad, this FF addons author is actually very capable,
    but he resorts to this trick
    thinking that people don’t notice…

    1. ams said on February 27, 2017 at 9:24 am
      Reply

      Good of you to call out the extension author’s “bogus updates” tactic. Thanks for the info.

    2. Curtis K said on February 27, 2017 at 9:12 am
      Reply

      The extension/add-on are reviewed by a volunteer not actual staff.

  10. Clairvaux said on February 26, 2017 at 5:45 pm
    Reply

    Having read around a bit, it appears the leak is shallow, but very wide. There are few chances it might be used against you, however there were so much data leaked, and it’s so difficult to know how that pertains to you exactly, that the only remedy seems to be to change all passwords.

    Of course I’m not going to do that, because I’ve got hundreds. Maybe change the most important ones.

  11. kalmly said on February 26, 2017 at 3:50 pm
    Reply

    Thank you Martin!

  12. Bhawani Garg said on February 26, 2017 at 3:34 pm
    Reply

    Here is a web-based tool to check if your site is affected by it or not: https://talepicker.com/cloudbleed/

  13. Clairvaux said on February 26, 2017 at 1:16 pm
    Reply

    What is the risk ?

    I see “authentication cookies”. Is this what allows “keep me logged in” ? Would that be enough for an attacker to get access ?

    1. Joe said on February 26, 2017 at 5:37 pm
      Reply

      If you use 2-factor authentication to get onto the site (when you attempt to log in, you get a text message with a code that you have to enter after you’ve entered your username and password, for example), it should be okay.

      If it were just authentication cookies and it’s a site that automatically logs you out after x minutes (like most banks do these days) the cookie wouldn’t allow them to get in.

      HOWEVER — it’s not just authentication cookies. Usernames and passwords were leaked also. Here’s a quote from the guy who reported it:

      “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,” Tavis Ormandy wrote in an advisory. “We’re talking full https requests, client IP addresses, full responses, cookies, passwords, keys, data, everything.”

    2. Tom Hawack said on February 26, 2017 at 1:37 pm
      Reply

      Anyone can access whatever account provided he’s got the credentials included in an authentication cookie and that these aren’t tied to what do they call it, double authentication?

      1. Tom Hawack said on February 26, 2017 at 2:08 pm
        Reply

        “The security issue at hand caused the servers to “run past the end of a buffer” which returned memory that contained private information. Among other things, it might have included HTTP cookies, authentication tokens, HTTP Post bodies, and other sensitive data.”

        HTTP cookies, that eliminates in principle secures logins.
        Private information that might have included HTTP cookies, gathered as I see it during the login process.

        I guess that because of the way this data leak performed the risk was when a user logged in. If his credentials are now those which existed at the time of the issue then those credentials may then have been stolen, hence this list to remind possible stolen credentials at the time of the issue in order to modify them now.

      2. Clairvaux said on February 26, 2017 at 1:42 pm
        Reply

        So this would occur on low-risk sites such as forums, maybe some middle-risk sites such as e-merchants (Amazon comes to mind, but is has further blocks ahead, I think), but not, I gather, on high-risk sites such as banks. Is that correct ?

  14. Tom Hawack said on February 26, 2017 at 12:19 pm
    Reply

    One might as well download the .xpi file, unzip it and find 1286 entries in chrome\content\domains.txt
    If you don’t have too many sites you login on having a look at the list can be a quicker direct approach.

    1. Hy said on February 26, 2017 at 12:32 pm
      Reply

      Hi, Tom, great suggestion! I’m doing it now. Thanks!

      1. Tom Hawack said on February 26, 2017 at 12:50 pm
        Reply

        I forgot to mention that the list has 19 duplicate entries which leads to 1270 domains … (original list has 1289 entries, not 1286 as I mentioned above).

        Some domains are surprising to be included in a list where you’d expect to find places suitable for providing a log-in, i.e. adf.ly … don’t really understand how anyone can have an account on adf.ly

        pastebin.com is in the lot : pastebin aficionados (to the point of having an account) : take care!

        Other surprises, for instance good old Forbes appears only on its Russian site, forbes.ru

        This is an interesting occupation for a Sunday morning between coffee and toats.

  15. Inolvidable said on February 26, 2017 at 11:57 am
    Reply

    Wow! I missed some important sites when I changed passwords of those ones potentially affected.

    Thank you very much Martin!!

Leave a Reply

Check the box to consent to your data being stored in line with the guidelines set out in our privacy policy

We love comments and welcome thoughtful and civilized discussion. Rudeness and personal attacks will not be tolerated. Please stay on-topic.
Please note that your comment may not appear immediately after you post it.