19 ms·

List of Sites Affected by Cloudflare's HTTPS Traffic Leak

914 points by emilong 10y ago

Cyphase 10y ago
You missed the "possibly" in the header. And the disclaimer right at the top: This list contains all domains that use cloudflare DNS, not just the cloudflare SSL proxy (the affected service that leaked data). It's a broad sweeping list that includes everything. Just because a domain is on the list does not mean the site is compromised.
- eli 10y ago
  Affected sites leaked data from random other CF customers. So any site using CF regardless of settings could have leaked private data out there.
  - r1ch 10y ago
    Sites using Cloudflare in DNS only mode won't have sent any requests that could be leaked.
    - wallacoloo 10y ago
      Indeed, and it's pretty annoying having my site in that list despite not using CloudFlare's reverse proxy service. If my website handled user logins or sensitive data no doubt I'd have customers contacting me or shying away from my site now. This list needs more vetting.
      - gkop 10y ago
        Do you have a concrete suggestion for the list maintainer to better vet the list? Can you prove that your site did not use the reverse proxy service at any point while the vulnerability was live?
        wallacoloo 10y ago
        > Can you prove that your site did not use the reverse proxy service at any point while the vulnerability was live? This is a scenario where it's impossible to prove innocence. Even if somebody provided you with the logs of their DNS server to show that the website never pointed to CloudFlare, I doubt these logs were stored in a way that their authenticity could be proved. In any case, the onus of proof should almost always be on the accuser, not the accused. Since you pressure me for a suggestion: my suggestion would have been to only list websites that were using the reverse proxy service (as opposed to DNS) at the time the data was captured. This can be done by inspecting the http response headers, or maybe even just checking the DNS records against known CloudFlare servers (as opposed to checking the DNS provider). But since you point out the transience of this, this method, as well as the method used to gather the list as-is are fundamentally flawed. I think a better way would be to locate DNS dumps throughout the vulnerability period & apply the above method to those.
        gkop 10y ago
        Thanks for answering! Your last idea is a good idea but more work for the list editor. I'm not sure the motivations of the list editor, but if he or she is just an impartial volunteer (important assumption), it seems like it's really Cloudflare's responsibility to deliver a comprehensive report of affected sites, so that we don't have to guess?
jandy 10y ago
I'm confused by the "not affected" remarks. I thought the issue was any site which passes data through cloudflare could be leaked by requests to a different site, due to their data being in memory. Have I misunderstood?
- deleted 10y ago
  [deleted]
- noahm 10y ago
  The update from 1password indicated that there was application layer encryption happening in addition to the TLS encryption, so a breach of the TLS protection did not expose any sensitive data. Presumably other sites are in similar situations. But don't take my word for it, go change all your passwords.
  - orthecreedence 10y ago
    > Presumably other sites are in similar situations. Not to my understanding. 1password uses client-side encryption, using keys generated from your master password. This means that any data transmitted over the wire is already encrypted, whether over SSL or not. Most other sites do not do this, at all, in any way. If you use a website that use'd CloudFlare's SSL termination, change your passwords, cancel your credit card (if you sent it to that site in the past few months, eg Uber/Lyft). > go change all your passwords. Yes, correct =].
    - markonen 10y ago
      If you'd seriously cancel your credit cards over this, I'd love to hear how you model that threat relative to all the other risks inherent in using a credit card anywhere (not just online).
  - runelind 10y ago
    1Password said that even though they were not affected, they will still move away from Cloudflare due to bad optics.
  - 10y ago
janwillemb 10y ago
Thanks for posting and curating this list.
actuator 10y ago
I wrote this(1) script to check for any affected sites from local Chrome history. It checks for the header `cf-ray` in the response headers from the domain. It is not an exhaustive list but I was able to find few important ones like my bank site. 1: https://gist.github.com/kamaljoshi/2cce5f6d35cd28de8f6dbb27d586f064 https://gist.github.com/kamaljoshi/2cce5f6d35cd28de8f6dbb27d...
- avian 10y ago
  Here's a script for checking domains of saved logins in Firefox against the list of sites using Cloudflare: https://gist.github.com/avian2/30db0d579732287d758c21ba8ded9393 https://gist.github.com/avian2/30db0d579732287d758c21ba8ded9...
  - blablabla123 10y ago
    I guess the bottom line is to change all passwords to be sure...
- poorman 10y ago
  I wish 1Password had a feature where you could put in a list of domains like this or a "Auto Change Possibly Compromised Passwords" feature.
  - erichurkman 10y ago
    Isn't this what Watchtower is supposed to be for? I have no idea if AgileBits is going to add this list to Watchtower, though.
    - AGKyle 10y ago
      Disclaimer: I work for AgileBits, makers of 1Password I am helping comb through a list of sites to see which of those has suggested password updates. I think we've had very few sites suggest updating the password though. Have you all seen any sites explicitly state users should update? If so I'd love a list so we can get them in Watchtower. Kyle
pmontra 10y ago
I have hundreds of passwords in my password manager. That's going to take a week, considering I also have to work.
- chrisbolt 10y ago
  Is your password manager 1Password? https://blog.agilebits.com/2017/02/23/three-layers-of-encryption-keeps-you-safe-when-ssltls-fails/ https://blog.agilebits.com/2017/02/23/three-layers-of-encryp...
  - danieldk 10y ago
    Even if your password manager is not compromised, the credentials of so many sites is potentially leaked that you should probably still update a substantial number of passwords. I hope 1Password's Watchtower service will soon give hints.
    - deleted 10y ago
      [deleted]
    - AGKyle 10y ago
      Disclaimer: I work for AgileBits, makers of 1Password. I am combing through site lists trying to find sites that are impacted. However, I am only updating based on sites that have suggested that they be updated. Very few are suggesting password updates right now. But, there are a few that are in Watchtower now. Lists like the one this link to are useful, but they don't actually say if a site was indeed impacted. In the end we may just treat this like Heartbleed and suggest they all get updated but for now, we're trying to only suggest it where necessary. If you're aware of any that have suggested password changes please let me know and I'll get them added immediately :) Kyle AgileBits
  - m3Lith 10y ago
    Even if it is, what does it have do to with all those hundreds of sites?
  - pmontra 10y ago
deleted 10y ago
[deleted]
nikisweeting 10y ago
Aww man I submitted my list hours ago but I guess it never made it past the New page. https://github.com/pirate/sites-using-cloudflare https://github.com/pirate/sites-using-cloudflare Original post: https://news.ycombinator.com/item?id=13720199 https://news.ycombinator.com/item?id=13720199
- dikaiosune 10y ago
  Hey! Super useful, thanks. Quick question: news.ycombinator.com (as an example) is listed in the README as a potentially affected site, but I don't see it in the raw dump that I've downloaded. Am I crazy?
  - edaemon 10y ago
    I suspect the raw dump is a list of sites that use the CloudFlare DNS servers, but HN uses a CNAME setup on their own authoritative DNS servers so it wouldn't appear in that list.
  - nikisweeting 10y ago
    I fixed the uploaded list, it now appears in the text file.
Splines 10y ago
If I have an account on an affected site, but did not interact with the site (via my browser or through some other site with an API call) during the time period when the vuln was live, am I still at risk?
- tkeith 10y ago
  It seems very unlikely that you would be at risk, but there's some remote possibility that your past request data was in memory for some reason
StavrosK 10y ago
I would like to point out that, if most sites used two-factor authentication, this leak would be at most a minor inconvenience. Maybe we should push for that more. Just days ago I talked to Namecheap about its horrible SMS-only 2FA and asked them to implement something actually secure, maybe contact your favorite site if they don't have 2FA yet.
- codeulike 10y ago
  Can you explain how 2FA would have helped?
  - et-al 10y ago
    Unless the web site was paranoid enough to encrypt your password client-side before sending it to the server, it's possible the password was leaked. With 2FA, your password and a one-time code were leaked and cached somewhere, but in order to log in as you today, an intruder would need to know a new code. And they wouldn't, unless you happened to set up your time-based one-time password (TOTP, e.g. Google Authenticator) during this timeframe as almost_usual mentioned. The reason here is because it's possible the secret key was leaked, so now someone can generate the same numbers your app is generating. xuki mentions that 2FA doesn't protect you against stolen bearer tokens, which is another issue. The usefulness of a stolen token depends if it's expired or not. If you haven't, force a signout of all your sessions to invalidate old tokens (and change your passwords).
    - infinite8s 10y ago
      What is the timeframe where setting up TOTP is vulnerable? I haven't been able to find an indication of how long this bug has been in production.
      - et-al 10y ago
        Cloudflare shares a timeline on their blog post: The three features implicated were rolled out as follows. The earliest date memory could have leaked is 2016-09-22. 2016-09-22 Automatic HTTP Rewrites enabled 2017-01-30 Server-Side Excludes migrated to new parser 2017-02-13 Email Obfuscation partially migrated to new parser 2017-02-18 Google reports problem to Cloudflare and leak is stopped The greatest potential impact occurred for four days starting on February 13 because Automatic HTTP Rewrites wasn’t widely used and Server-Side Excludes only activate for malicious IP addresses. https://blog.cloudflare.com/incident-report-on-memory-leak-caused-by-cloudflare-parser-bug/ https://blog.cloudflare.com/incident-report-on-memory-leak-c...
dikaiosune 10y ago
I've been tinkering with a Python notebook for a few minutes to try to quickly assess how much of my LastPass vault is affected: https://gist.github.com/dikaiosune/0ca7829884b3b3f790418f0f108fd38f https://gist.github.com/dikaiosune/0ca7829884b3b3f790418f0f1... Improvements welcome. One interesting thing: the raw dump that's linked from the list's README doesn't seem to include a couple of notable domains from the README itself, like news.ycombinator.com or reddit.com. I may be mangling the dump or incorrectly downloading it in some way. EDIT: disclaimer, be responsible, audit how the dump is generated, etc etc etc
edaemon 10y ago
This list doesn't appear to include sites that use a CNAME setup with CloudFlare -- i.e. sites on the Business or Enterprise plans that retain their authoritative DNS and use CNAMEs to point domains to a CloudFlare proxy. There probably aren't many but with something this serious it could be important. I'm not sure how one would go about finding the sites that use the CNAME option. If it helps, they use a pattern like: www.example.com --> www.example.com.cdn.cloudflare.net Hacker News is one such site, but it's listed in the "notable" section (it's not in the raw dump).
amq 10y ago
The title is misleading (for now). It is just a list of all sites using CF, compromised or not.
- jononor 10y ago
  All sites are compromised. Anything which was in memory, which could be any site, would be spewed out. Regardless of which site was used as the trigger.
  - amq 10y ago
    A quote from the page: > This list contains all domains that use cloudflare DNS, not just the cloudflare proxy (the affected service that leaked data).
cromulent 10y ago
"List of Sites possibly affected" Sites using Cloudflare, really. However, Cloudflare say that only sites using three page rules were affected - email obfuscation, Server-side Excludes and Automatic HTTPS Rewrites. [1] Is this over-estimating the impact, perhaps? [1] https://blog.cloudflare.com/incident-report-on-memory-leak-caused-by-cloudflare-parser-bug/ https://blog.cloudflare.com/incident-report-on-memory-leak-c...
- cstejerean 10y ago
  No! And this is why cloudfare's poor write up continues to confuse people. Sites with those features triggered the bug. Once the bug was trigerred the response would include data from ANY other cloudfare customer that happened to be in memory at the time. Meaning a request for a page with one of those features could include data from Uber or one of the many other customers that didn't use those features. So the potential impact is every single one of the sites using CloudFare. Not over-estimated at all.
  - cromulent 10y ago
    Ah, that makes sense. Thanks for clearing it up for me.
  - tyingq 10y ago
    The email Cloudflare is sending out to their customers has a pretty "no big deal" tone as well: http://pastebin.com/pUnKJE3J http://pastebin.com/pUnKJE3J I assume there's a separate email for sites where they happened to find Google cache data, but...
- deleted 10y ago
  [deleted]
- gnud 10y ago
  As I understand the issue, the leaked data might be from any other site using Cloudflare caching. But only requests to sites using the features you mention, will have leaked data.
- 10y ago
pulls 10y ago
For what it's worth, as part of work on the effects of DNS on Tor's anonymity [1] we visited Alexa top-1M in April 2016, recording all DNS requests made by Tor Browser for each site. We found that 6.4% of primary domains (the sites on the Alexa list) were behind a Cloudflare IPv4-address. However, for 25.8% of all sites, at least one domain on the site used Cloudflare. That's a big chunk of the Internet. [1]: https://nymity.ch/tor-dns/ https://nymity.ch/tor-dns/
Wrhector 10y ago
This list seems to be missing any sites that are using custom nameservers, which would be common on top sites using the enterprise plans. A better way to detect if the proxy is being used would be to resolve the IP and see if it lies in Cloudflare's subnets.
jschpp 10y ago
That list isn't that useful... First of all, there is a LOT of pages hosted by CloudFlare @taviso acknowledged that in the original bug report. (https://bugs.chromium.org/p/project-zero/issues/detail?id=1139#c5 https://bugs.chromium.org/p/project-zero/issues/detail?id=11...) Furthermore, you can't say which sites were hit by this bug and simply listing all CloudFlare sites is more or less fearmongering. If you are a verified victim of this bug CloudFlare will contact you. Lastly, if you want to be sure to mitigate effects of the attack just do it... If you want to be absolutely sure that your session keys etc will remain uncompromised simply repeal all active session cookies.
- sfwwolvw 10y ago
  > If you are a verified victim of this bug CloudFlare will contact you. Where do you have that info from?
  - jgrahamc 10y ago
    We are in the process of contacting customer who we are able had information cached by a search engine.
    - wheelerwj 10y ago
      this doesn't even begin to cover the possible scope of the leak does it?
    - troydavis 10y ago
      @jgrahamc: If this problem doesn't justify emailing all proxy service customers, what problem would?
      - jgrahamc 10y ago
        We are emailing them all, but we are starting with those that we know had data cached by a search engine.
crottypeter 10y ago
Today I learned that uber does not have a change password option once you are logged in. You have to log out and pretend you forgot the password. Bad UX if you don't know.
- spb 10y ago
  Holy crap, really? I've been drawing up [profiles for the user account systems of a bunch of websites for the past few years][1], and I think I've only seen that once before (on a Washington State website, no less). [1]: https://github.com/opws/domainprofiles https://github.com/opws/domainprofiles
  - ams6110 10y ago
    Fairly common pattern on non-tech-oriented sites, in my experience.
- dmix 10y ago
  The downside of mobile first or mobile only for that matter. Normal web flows are downplayed. Not that this is excusable for a company of this size.
  - crottypeter 10y ago
    There is no logged-in access to password reset in the (android) mobile app either.
iKenshu 10y ago
What if I sign in with facebook or other? Should I change muy password con facebook or what?
- Crosseye_Jack 10y ago
  TL;DR? You should be ok... Long Version. That (most likely) would of used oauth. So instead of sending your FB password to the site to log you into FB with. You give your FB password (if your not signed in) to FB and then facebook give the site using "sign in with Facebook" a token they can use with facebook to get account info / do actions on your FB account. Now depending on which "sign in with" system you used then often the code handed back to the site (via a callback URL handled by the client) is a single use code. So once the site using "sign in with" has used the code with FB they get another set of tokens they will use with Facebook directly. After the initial "sign in with" process the Facebook tokens are most likely never handed to clients (because they often need to be mixed with a site secret during requests to the likes of Facebook). So you _should_ be ok if you used a decent "sign in with" system like facebooks as the only thing that would of been handed back to the client and then sent from the client to the site is that single use code. The communication with the site and facebook would of used an API endpoint. Now... If you used another sites (not facebook) "sign in with" system and their API is also behind Cloudflare it could well be that some API keys could be in a cache somewhere. If those requests were signed with secrets you should be fine because without the sites secrets to lets say create a hmac signature for the request then while there might be some personally identifiable information in caches somewhere the signatures should of already expired meaning that they can't be used in say a replay attack and the data cached can't be used to create fresh requests. BUT this all depends on everyone doing things right, which may not be the case. But either way, oauth tokens are often not revoked when you change your password. I.e. you might change your FB password and then still be able to auto login on somesmallsite.org because the tokens shared between FB and somesmallsite.whatever haven't changed.
  - iKenshu 10y ago
    Thanks for this answer, its perfect!
  - 10y ago
jasonlingx 10y ago
Do I need to change my cloudflare password?
vasundhar 10y ago
Unfortunately this seem to include news.ycombinator.com
- shakna 10y ago
  > This list contains all domains that use cloudflare DNS, not just the cloudflare SSL proxy (the affected service that leaked data). It's a broad sweeping list that includes everything. Just because a domain is on the list does not mean the site is compromised. In this case, HN , IIRC, does not use the proxy. Checking the certs, CloudFlare reissue using DigiCert, I think, whereas HN is using a Comodo cert.
  - dsl 10y ago
    You can upload your own cert to CloudFlare. Hacker News does hit the CF proxy and was affected. $ host news.ycombinator.com news.ycombinator.com is an alias for news.ycombinator.com.cdn.cloudflare.net. news.ycombinator.com.cdn.cloudflare.net has address 104.20.44.44 news.ycombinator.com.cdn.cloudflare.net has address 104.20.43.44
pbhjpbhj 10y ago
Do browsers still leak history info (eg http://zyan.scripts.mit.edu/sniffly/ http://zyan.scripts.mit.edu/sniffly/) is it possible to have a page show visitors if they are likely to be affected?
koolba 10y ago
That's a wide impact. While any hijacked account is bad, some of these are really bad. For example, https://coinbase.com https://coinbase.com is on that list! If they haven't immediately invalidated every single HTTP session after hearing this news this is going to be bad. Ditto for forcing password resets. A hijacked account that can irrevocably send digital currency to an anonymous bad guy's account would be target number one for using data like this.
- pyre 10y ago
  I also noticed the domain waveapps.com, which is for Wave Accounting.
  - rwilsonperkin 10y ago
    We're investigating
  - rmaurin 10y ago
    Cloudfare has advised that Wave data has not been affected/leaked. We've got engineering and security teams investigating, and we'll keep on it until we're ultra confident in the conclusion. Nonetheless, good practice for everyone to rotate all passwords today, for any services. Good security hygiene any time, and especially now.
    - petters 10y ago
      How can they know that? A broken web page could have been queried many, many times the last weeks and couldn't one of the responses contain Wave data?
      - rmaurin 10y ago
        Not 100% sure what their methodology is yet, and we're taking a cautious approach. At minimum, in the data that they've found in the wild, no Wave data was among it.
- alyssenko 10y ago
yeukhon 10y ago
Would Internet Archive able to "cache" the leaks?
djph0826 10y ago
Volusion.com
base698 10y ago
Has Cloudflare fixed the issues? Should I update passwords now or wait?
- spiffytech 10y ago
  Yes, they've fixed the issue, so it's safe to change your passwords now. But expect some websites to prompt you to change your passwords again once they disclose the breach.
beachstartup 10y ago
this is another data point that supports my personal, hare-brained theory that the expectation of privacy on the internet is simply naive, a fool's errand. it never existed, and never will. this is despite (or maybe because) of my best efforts to secure systems as a major part of my job.
luckystartup 10y ago
Oh crap. I've entered my banking password into Transferwise quite a few times. Welp, time to change all my passwords.
- pc86 10y ago
  > Welp, time to stop using the same password for multiple services. > Welp, time to start using a password manager. FTFY
  - deleted 10y ago
    [deleted]
  - luckystartup 10y ago
    Yes, definitely a good suggestion. I already use Lastpass, which makes regenerating all my passwords a little easier.
  - doubleunplussed 10y ago
    OP isn't saying they used the same password for transferwise as for their bank. Transferwise allows you to log into your internet banking and authorize a transaction through their site. You actually give them your internet banking password, regardless of how you log into their site. Which is pretty strange in itself, to trust a 3rd party with your internet banking password, but that's how it works.
    - philsnow 10y ago
      This is the main reason I've never used Mint.
    - snowwrestler 10y ago
      Folks should review their banks' policies before doing this. For example Bank of America won't hold customers liable for fraudulent transfers or bill pay transactions through their website, but sharing your online ID and password seems to void that protection. https://www.bankofamerica.com/onlinebanking/online-banking-security-guarantee.go https://www.bankofamerica.com/onlinebanking/online-banking-s...
jitbit 10y ago
Webmasters and App-devs running on CloudFlare. You (at least) have to "force-logout" your users that have a "remember me" cookie set. At least change the cookie name so the token stops working. For example, in ASP.NET - change the "forms-auth" name in the web.config file
- cortesoft 10y ago
  If you do that, then an attacker could just use the same token with a different cookie name and access someones account. You NEED to invalidate the token.
- leni536 10y ago
  > At least change the cookie name This is bad advice, you should invalidate the tokens, that's it.
arca_vorago 10y ago
Apparently root case was: /* generated code */ if ( ++p == pe ) goto _test_eof; "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. This is known as a buffer overrun. Had the check been done using >= instead of == jumping over the buffer end would have been caught." Detailed timeline: "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" Seems like a pretty good response by cloudflare to me.
- kevinchen 10y ago
  It's a good postmortem (describes WHAT happened), but it doesn't really communicate the impact to Cloudflare customers or their end users (describe WHY people should care).
arikrak 10y ago
It would be more useful if there was a way to see sites that actually were using the Cloudflare features that caused this bug. A large number of sites use Cloudflare, but few should have been affected by this bug: > When the parser was used in combination with three Cloudflare features—e-mail obfuscation, server-side excludes, 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-potpourri-of-secret-customer-data/ https://arstechnica.com/security/2017/02/serious-cloudflare-...
- cknight 10y ago
  As has been mentioned elsewhere on HN, those 3 features were capable of triggering the bug. Once triggered, potentially any Cloudflare-enabled site could have been affected.
- toyg 10y ago
  You only needed one service triggering the involved module in the CF proxy, and all traffic going through it would be affected, regardless of which feature each account had enabled. This over three months. I think even CF struggled to find all affected sites - which is proven by the amount of stuff still in google cache, after 7 days of purging. Unless they keep three months of logs listing all sites that used each and every proxy, you cannot be 100% certain of which traffic was affected.
r1ch 10y ago
Just got this classy spam from dyn.com. Wonder if they're going through this list emailing every domain contact. > As you may be aware, Cloudflare incurred a security breach where user data from 3,400 websites was leaked and cached by search engines as a result of a bug. Sites affected included major ones like Uber, Fitbit, and OKCupid. > Cloudflare has admitted that the breach occurred, but Ormandy and other security researchers believe the company is underplaying the severity of the incident … > This incident sheds light and underlines the vulnerability of Cloudflare's network. Right now you could be at continued risk for security and network problems. Here at Dyn, we would like to extend a helpful hand in the event that your network infrastructure has been impacted by today's security breach or if the latest news has you rethinking your relationship with Cloudflare. > Let me know if you would be interested in having a conversation about Dyn's DNS & Internet performance solutions. > I look forward to hearing back from you.
- IgorPartola 10y ago
  It's clever but feels at least a 3/10 shitty. Dyn is an old company and back in the day they provided free subdomains while nobody else did. I haven't used them recently because their pricing seems so high. How do others feel about them?
  - OraclesDyn388 10y ago
    With Oracle announcing they're buying Dyn, I'm "voting with my wallet" and moving off them. I'm small potatoes compared to Netflix or other big dogs that use them.
  - r1ch 10y ago
    I still have a lifetime standard DNS subscription with them from back in the day when they were dyndns.org and you could physically mail them cash. The DNS hosting has been very solid (except for the day Mirai took them offline) but the standard query limits are way too low for any moderately trafficked website. All the managed DNS providers I looked at seem to have very restrictive query limits without a "enterprise - contact us" plan, one of the reasons why I decided to just do DNS-only on Cloudflare.
AdmiralAsshat 10y ago
Authy is on the list. It would be really nice if they confirmed whether they are vulnerable or not, considering they hold all of my 2FA tokens. Otherwise I'll have to re-key the database.
- infinite8s 10y ago
  Wouldn't you rather just do that as a precaution? Then you won't be constantly worried that they might have had their data leaked.
vmarsy 10y ago
Something I have a hard time understanding, is how Cloudfare's cache generator page had access to sensitive information ? Were the 2 things running on the same process? If they were not, there's no way that the buffer overrun could read an other process memory, right? it would have failed with a segfault type of error. If so, shouldn't Cloudfare consider running the sensitive stuff on a different process, so that no matter how buggy their caching engine is, it would never inadvertently read sensitive information?
- cjslep 10y ago
  SSL connections were terminating at the proxy, so the proxy used plain HTTP to the web service backends.
  - cjslep 10y ago
    Unsure about the random downvotes. It's CloudFlare's "Flexible SSL" offering. Granted, sibling non-speculative comments elaborate more thoroughly for the "non-flexible" cases.
  - jpetersonmn 10y ago
    Are you sure about this? Just because they terminate ssl on the proxy doesn't mean the traffic between the proxy and the web service backends was plain HTTP. That's certainly not how we do things.
- dugmartin 10y ago
  My guess given their widespread use of Go is that each parser was a goroutine which uses the same process heap as other goroutines parsing other page requests.
  - ecnahc515 10y ago
    Have you read their incident response? If you had, you would know they weren't using Go for this and it was actually an issue an a parser generated by ragel (C++) which was then used as an nginx module.
ig1 10y ago
Worth noting this statement by Cloudflare CTO: "I am not changing any of my passwords. I think the probability that somebody saw something is so low it's not something I am concerned about." http://www.bbc.co.uk/news/technology-39077611 http://www.bbc.co.uk/news/technology-39077611
- new299 10y ago
  That seems like a reasonably unwise thing to say. It would be absolutely reasonable for someone to change there passwords after breach. By citing a personal view point they're seeking to downplay the issue while providing little useful advice.
- p49k 10y ago
  That kind of statement reminds me of this guy: https://www.wired.com/2010/05/lifelock-identity-theft/ https://www.wired.com/2010/05/lifelock-identity-theft/
- devy 10y ago
  That seems a lot like something a company which was just implicated in a gigantic leak would say: damage control.
- MarkMc 10y ago
  That statement must have given Cloudfare's lawyer an aneurysm. Seems to me that management's attempt to downplay the problem exposes the company to as much risk as the original technical mistake.
- mbesto 10y ago
  *Article says COO, but Twitter says CTO. Strange. And he's fairly active on these forums. That seems like such an odd thing to say given how important security is/should be at CF...curious if jgrahamc would further clarify his position here.
  - fencepost 10y ago
    Agreed on the importance of security, but if his credentials from outside their network are able to be used in any significant way to impact their services or systems then they're doing something tragically wrong. For that matter if his credentials can be used anywhere to impact their services it's a failure.
RidleyL 10y ago
I wrote a python script to help check your LastPass database for any potentially affected sites. https://github.com/RidleyLarsen/cloudbleed_check_lastpass https://github.com/RidleyLarsen/cloudbleed_check_lastpass
JaggedJax 10y ago
In an email from Cloudflare sent out this morning they said: > In our review of these third party caches, we discovered data that had been exposed from approximately 150 of Cloudflare's customers across our Free, Pro, Business, and Enterprise plans. We have reached out to these customers directly to provide them with a copy of the data that was exposed, help them understand its impact, and help them mitigate that impact. Does this jive at all with the Google or Cloudflare disclosures? They are claiming that across all caches they only found and wiped data from ~150 domains, can that be true?
- mistercow 10y ago
  Every single thing Cloudflare has said about impact has sounded very suspiciously optimistic to me. For example, they claim that they would know if an attacker had been intentionally exploiting this bug, but I've seen no details to justify their confidence. So no, I don't think we can assume that the scope was as limited as they're making out. Edit: As my coworker points out, as of 2013, they only kept 4 hours of access logs (source: https://blog.cloudflare.com/what-cloudflare-logs/ https://blog.cloudflare.com/what-cloudflare-logs/). So basically their existing attack detection infrastructure (built without knowledge of this bug) may not have found anything suspicious, but it appears that that's the extent of what they can say about the last few months. They can claim that they found no evidence within the last week (one hopes that they stopped discarding logs when they found out about the attack), but if they want to convince us that they know this wasn't being exploited as late as two weeks ago, they need to provide specific evidence.
- dsl 10y ago
  CloudFlare has no idea of knowing what was in uninitialized memory that was leaked. This is just spin.
danjoc 10y ago
Is there a "standard" in the works for changing a password? Stuff like this is happening rather too frequently for my taste. I need a tool I can use to update all my passwords everywhere automatically and store the new ones in my password manager.
- dingdongding 10y ago
  I agree. This is about time password managers and "changing password" should be standardized. Password Managers should now be supported across the board. Not just browsers.
- jbkly7 10y ago
  LastPass has auto-password change: https://blog.lastpass.com/2015/05/auto-password-change-now-available-in-the-lastpass-security-challenge.html/ https://blog.lastpass.com/2015/05/auto-password-change-now-a...
  - soundoflight 10y ago
    Dashlane has that feature too.
paradite 10y ago
Couldn't find a practical description of who is affected anywhere. Is it just the customers who have Cloudflare HTTPS proxy service being affected, or anyone using Cloudflare DNS is affected?
- dsl 10y ago
  Anyone who passes HTTP or HTTPS traffic via CloudFlare might have had that data leaked into other users sessions.
tonyztan 10y ago
Just received an email from Glidera, a Bitcoin exchange. This is the first service to ask me to reset my password. I wonder why Uber, NameCheap, FitBit, and many others have yet to warn their users? Is Cloudflare downplaying this? > Hi [Username], > A bug was recently discovered with Cloudflare, which Glidera and many other websites use for DoS protection and other services. Due to the nature of the bug, we recommend as a precaution that you change your Glidera security credentials: > Change your password > Change your two-factor authentication > You should similarly change your security credentials for other websites that use Cloudflare (see the link below for a list of possibly affected sites). If you are using the same password for multiple sites, you should change this immediately so that you have a unique password for each site. And you should enable two-factor authentication for every site that supports it. > The Cloudflare bug has now been fixed, but it caused sensitive data like passwords to be leaked during a very small percentage of HTTP requests. The peak period of leakage is thought to have occurred between Feb 13 and Feb 18 when about 0.00003% of HTTP requests were affected. Although the rate of leakage was low, the information that might have been leaked could be very sensitive, so it’s important that you take appropriate precautions to protect yourself. > The actual leaks are thought to have only started about 6 months ago, so two-factor authentication generated before that time are probably safe, but we recommend changing them anyway because the vulnerability potentially existed for years. > Please note that this bug does NOT mean that Glidera itself has been hacked or breached, but since individual security credentials may have been leaked some individual accounts could be vulnerable and everyone should change their credentials as a safeguard. > Here are some links for further reading on the Cloudflare bug: > TechCrunch article: https://techcrunch.com/2017/02/23/major-cloudflare-bug-leaked-sensitive-data-from-customers-websites/ https://techcrunch.com/2017/02/23/major-cloudflare-bug-leake... > List of sites possibly affected by the bug: https://github.com/pirate/sites-using-cloudflare/blob/master/README.md https://github.com/pirate/sites-using-cloudflare/blob/master... > If you have any questions or concerns in response to this email, please contact support at: support@glidera.io
- SnaKeZ 10y ago
  Namecheap: https://blog.namecheap.com/cloudflare-security-incident/ https://blog.namecheap.com/cloudflare-security-incident/
nodesocket 10y ago
This is ridiculous and somewhat irresponsible. This is just a list of domains using CloudFlare. The leak was only active under a set of very specific cases (email obfuscation, server-side excludes and automatic https rewrites). I question Pirates (https://github.com/pirate https://github.com/pirate) motives for even doing this? Karma? Reputation?
- kijin 10y ago
  Only a few hundred sites were leaking, sure, but the leaked info could have come from any domain that was being proxied by the same edge server. So we would do better to assume that any domain that uses Cloudflare could have had their passwords and other sensitive info exposed via leaky neighbors.
  - nodesocket 10y ago
    Thanks for clarifying. You are absolutely right.
grogenaut 10y ago
I ginned up this little tool tonight to help people out instead of grepping. https://bleed.cloud/index.html https://bleed.cloud/index.html Sorry for the index.html, trying to figure out how to get index file to work on cloudfront. You can also run the python script on the website anonymously on your computer to dig sites out of your email, which is a good indicator that you have an account with them.
kiallmacinnes 10y ago
And, I've found several of my domains on this list.. Some of which don't host web content etc and only use cloudflare for DNS. The list is currently ~4.3mil entries, which honestly feels like a rather low figure. I have no data to back up my gut feeling though ;) Anyway, I'm OK with them being on this list, as I believe understanding the scope of the problem is important to figuring out how we prevent these kinda problems in the future.. (For example, answering this question requires understanding who uses CloudFlare: Why are so many sites concentrated on a single infrastructure?)
cloudvrfy 10y ago
I wrote a simple website[1] to show if user have visited the websites included in the list automatically without browser plug-ins. It uses :visited CSS pseudo-class to highlight the site user have visited before. It is not 100% accurate, but it can be a fun way to quickly show people that they may visit sites on the list. [1]https://cloudbleed.github.io/ https://cloudbleed.github.io/
- simooooo 10y ago
  Amazing that this hack still exists
- salemh 10y ago
  I want to share this with my more non-techy persons, but, on Chrome, turning of uOrigin, their are no names of companies listed. I can hover over every block for the name, but.. is this an error, or intentional to just have a large heart-block with no labels?
  - cloudvrfy 10y ago
    Could you suggest how the names of companies should be shown so we can improve the website? Appreciate your reply :)
    - salemh 10y ago
      Just a right-side text that highlights once you mouse-over would be great. It may be too much to display all of names, but having it populate gives some idea of where you need to go. Perhaps just every "red"/affected site could be populated on the right side :) Appreciate the layout outside of naming labels however, nice work.
em0ney 10y ago
The list of websites once again reminds me of what avenue Q immortalised in song: the internet is for porn

914 points by emilong 10y ago

You missed the "possibly" in the header. And the disclaimer right at the top: This list contains all domains that use cloudflare DNS, not just the cloudflare SSL proxy (the affected service that leaked data). It's a broad sweeping list that includes everything. Just because a domain is on the list does not mean the site is compromised.

eli 10y ago
Affected sites leaked data from random other CF customers. So any site using CF regardless of settings could have leaked private data out there.
- r1ch 10y ago
  Sites using Cloudflare in DNS only mode won't have sent any requests that could be leaked.
  - wallacoloo 10y ago
    Indeed, and it's pretty annoying having my site in that list despite not using CloudFlare's reverse proxy service. If my website handled user logins or sensitive data no doubt I'd have customers contacting me or shying away from my site now. This list needs more vetting.
    - gkop 10y ago
      Do you have a concrete suggestion for the list maintainer to better vet the list? Can you prove that your site did not use the reverse proxy service at any point while the vulnerability was live?
      - wallacoloo 10y ago
        > Can you prove that your site did not use the reverse proxy service at any point while the vulnerability was live? This is a scenario where it's impossible to prove innocence. Even if somebody provided you with the logs of their DNS server to show that the website never pointed to CloudFlare, I doubt these logs were stored in a way that their authenticity could be proved. In any case, the onus of proof should almost always be on the accuser, not the accused. Since you pressure me for a suggestion: my suggestion would have been to only list websites that were using the reverse proxy service (as opposed to DNS) at the time the data was captured. This can be done by inspecting the http response headers, or maybe even just checking the DNS records against known CloudFlare servers (as opposed to checking the DNS provider). But since you point out the transience of this, this method, as well as the method used to gather the list as-is are fundamentally flawed. I think a better way would be to locate DNS dumps throughout the vulnerability period & apply the above method to those.
        gkop 10y ago
        Thanks for answering! Your last idea is a good idea but more work for the list editor. I'm not sure the motivations of the list editor, but if he or she is just an impartial volunteer (important assumption), it seems like it's really Cloudflare's responsibility to deliver a comprehensive report of affected sites, so that we don't have to guess?

jandy 10y ago

I'm confused by the "not affected" remarks. I thought the issue was any site which passes data through cloudflare could be leaked by requests to a different site, due to their data being in memory. Have I misunderstood?

deleted 10y ago
[deleted]
noahm 10y ago
The update from 1password indicated that there was application layer encryption happening in addition to the TLS encryption, so a breach of the TLS protection did not expose any sensitive data. Presumably other sites are in similar situations. But don't take my word for it, go change all your passwords.
- orthecreedence 10y ago
  > Presumably other sites are in similar situations. Not to my understanding. 1password uses client-side encryption, using keys generated from your master password. This means that any data transmitted over the wire is already encrypted, whether over SSL or not. Most other sites do not do this, at all, in any way. If you use a website that use'd CloudFlare's SSL termination, change your passwords, cancel your credit card (if you sent it to that site in the past few months, eg Uber/Lyft). > go change all your passwords. Yes, correct =].
  - markonen 10y ago
    If you'd seriously cancel your credit cards over this, I'd love to hear how you model that threat relative to all the other risks inherent in using a credit card anywhere (not just online).
- runelind 10y ago
  1Password said that even though they were not affected, they will still move away from Cloudflare due to bad optics.
- 10y ago

janwillemb 10y ago

Thanks for posting and curating this list.

actuator 10y ago

I wrote this(1) script to check for any affected sites from local Chrome history. It checks for the header `cf-ray` in the response headers from the domain. It is not an exhaustive list but I was able to find few important ones like my bank site. 1: https://gist.github.com/kamaljoshi/2cce5f6d35cd28de8f6dbb27d586f064 https://gist.github.com/kamaljoshi/2cce5f6d35cd28de8f6dbb27d...

avian 10y ago
Here's a script for checking domains of saved logins in Firefox against the list of sites using Cloudflare: https://gist.github.com/avian2/30db0d579732287d758c21ba8ded9393 https://gist.github.com/avian2/30db0d579732287d758c21ba8ded9...
- blablabla123 10y ago
  I guess the bottom line is to change all passwords to be sure...
poorman 10y ago
I wish 1Password had a feature where you could put in a list of domains like this or a "Auto Change Possibly Compromised Passwords" feature.
- erichurkman 10y ago
  Isn't this what Watchtower is supposed to be for? I have no idea if AgileBits is going to add this list to Watchtower, though.
  - AGKyle 10y ago
    Disclaimer: I work for AgileBits, makers of 1Password I am helping comb through a list of sites to see which of those has suggested password updates. I think we've had very few sites suggest updating the password though. Have you all seen any sites explicitly state users should update? If so I'd love a list so we can get them in Watchtower. Kyle

pmontra 10y ago

I have hundreds of passwords in my password manager. That's going to take a week, considering I also have to work.

chrisbolt 10y ago
Is your password manager 1Password? https://blog.agilebits.com/2017/02/23/three-layers-of-encryption-keeps-you-safe-when-ssltls-fails/ https://blog.agilebits.com/2017/02/23/three-layers-of-encryp...
- danieldk 10y ago
  Even if your password manager is not compromised, the credentials of so many sites is potentially leaked that you should probably still update a substantial number of passwords. I hope 1Password's Watchtower service will soon give hints.
  - deleted 10y ago
    [deleted]
  - AGKyle 10y ago
    Disclaimer: I work for AgileBits, makers of 1Password. I am combing through site lists trying to find sites that are impacted. However, I am only updating based on sites that have suggested that they be updated. Very few are suggesting password updates right now. But, there are a few that are in Watchtower now. Lists like the one this link to are useful, but they don't actually say if a site was indeed impacted. In the end we may just treat this like Heartbleed and suggest they all get updated but for now, we're trying to only suggest it where necessary. If you're aware of any that have suggested password changes please let me know and I'll get them added immediately :) Kyle AgileBits
- m3Lith 10y ago
  Even if it is, what does it have do to with all those hundreds of sites?
- pmontra 10y ago

deleted 10y ago

[deleted]

nikisweeting 10y ago

Aww man I submitted my list hours ago but I guess it never made it past the New page. https://github.com/pirate/sites-using-cloudflare https://github.com/pirate/sites-using-cloudflare Original post: https://news.ycombinator.com/item?id=13720199 https://news.ycombinator.com/item?id=13720199

dikaiosune 10y ago
Hey! Super useful, thanks. Quick question: news.ycombinator.com (as an example) is listed in the README as a potentially affected site, but I don't see it in the raw dump that I've downloaded. Am I crazy?
- edaemon 10y ago
  I suspect the raw dump is a list of sites that use the CloudFlare DNS servers, but HN uses a CNAME setup on their own authoritative DNS servers so it wouldn't appear in that list.
- nikisweeting 10y ago
  I fixed the uploaded list, it now appears in the text file.

Splines 10y ago

If I have an account on an affected site, but did not interact with the site (via my browser or through some other site with an API call) during the time period when the vuln was live, am I still at risk?

tkeith 10y ago
It seems very unlikely that you would be at risk, but there's some remote possibility that your past request data was in memory for some reason

StavrosK 10y ago

I would like to point out that, if most sites used two-factor authentication, this leak would be at most a minor inconvenience. Maybe we should push for that more. Just days ago I talked to Namecheap about its horrible SMS-only 2FA and asked them to implement something actually secure, maybe contact your favorite site if they don't have 2FA yet.

codeulike 10y ago
Can you explain how 2FA would have helped?
- et-al 10y ago
  Unless the web site was paranoid enough to encrypt your password client-side before sending it to the server, it's possible the password was leaked. With 2FA, your password and a one-time code were leaked and cached somewhere, but in order to log in as you today, an intruder would need to know a new code. And they wouldn't, unless you happened to set up your time-based one-time password (TOTP, e.g. Google Authenticator) during this timeframe as almost_usual mentioned. The reason here is because it's possible the secret key was leaked, so now someone can generate the same numbers your app is generating. xuki mentions that 2FA doesn't protect you against stolen bearer tokens, which is another issue. The usefulness of a stolen token depends if it's expired or not. If you haven't, force a signout of all your sessions to invalidate old tokens (and change your passwords).
  - infinite8s 10y ago
    What is the timeframe where setting up TOTP is vulnerable? I haven't been able to find an indication of how long this bug has been in production.
    - et-al 10y ago
      Cloudflare shares a timeline on their blog post: The three features implicated were rolled out as follows. The earliest date memory could have leaked is 2016-09-22. 2016-09-22 Automatic HTTP Rewrites enabled 2017-01-30 Server-Side Excludes migrated to new parser 2017-02-13 Email Obfuscation partially migrated to new parser 2017-02-18 Google reports problem to Cloudflare and leak is stopped The greatest potential impact occurred for four days starting on February 13 because Automatic HTTP Rewrites wasn’t widely used and Server-Side Excludes only activate for malicious IP addresses. https://blog.cloudflare.com/incident-report-on-memory-leak-caused-by-cloudflare-parser-bug/ https://blog.cloudflare.com/incident-report-on-memory-leak-c...

dikaiosune 10y ago

I've been tinkering with a Python notebook for a few minutes to try to quickly assess how much of my LastPass vault is affected: https://gist.github.com/dikaiosune/0ca7829884b3b3f790418f0f108fd38f https://gist.github.com/dikaiosune/0ca7829884b3b3f790418f0f1... Improvements welcome. One interesting thing: the raw dump that's linked from the list's README doesn't seem to include a couple of notable domains from the README itself, like news.ycombinator.com or reddit.com. I may be mangling the dump or incorrectly downloading it in some way. EDIT: disclaimer, be responsible, audit how the dump is generated, etc etc etc

edaemon 10y ago

This list doesn't appear to include sites that use a CNAME setup with CloudFlare -- i.e. sites on the Business or Enterprise plans that retain their authoritative DNS and use CNAMEs to point domains to a CloudFlare proxy. There probably aren't many but with something this serious it could be important. I'm not sure how one would go about finding the sites that use the CNAME option. If it helps, they use a pattern like: www.example.com --> www.example.com.cdn.cloudflare.net Hacker News is one such site, but it's listed in the "notable" section (it's not in the raw dump).

amq 10y ago

The title is misleading (for now). It is just a list of all sites using CF, compromised or not.

jononor 10y ago
All sites are compromised. Anything which was in memory, which could be any site, would be spewed out. Regardless of which site was used as the trigger.
- amq 10y ago
  A quote from the page: > This list contains all domains that use cloudflare DNS, not just the cloudflare proxy (the affected service that leaked data).

cromulent 10y ago

"List of Sites possibly affected" Sites using Cloudflare, really. However, Cloudflare say that only sites using three page rules were affected - email obfuscation, Server-side Excludes and Automatic HTTPS Rewrites. [1] Is this over-estimating the impact, perhaps? [1] https://blog.cloudflare.com/incident-report-on-memory-leak-caused-by-cloudflare-parser-bug/ https://blog.cloudflare.com/incident-report-on-memory-leak-c...

cstejerean 10y ago
No! And this is why cloudfare's poor write up continues to confuse people. Sites with those features triggered the bug. Once the bug was trigerred the response would include data from ANY other cloudfare customer that happened to be in memory at the time. Meaning a request for a page with one of those features could include data from Uber or one of the many other customers that didn't use those features. So the potential impact is every single one of the sites using CloudFare. Not over-estimated at all.
- cromulent 10y ago
  Ah, that makes sense. Thanks for clearing it up for me.
- tyingq 10y ago
  The email Cloudflare is sending out to their customers has a pretty "no big deal" tone as well: http://pastebin.com/pUnKJE3J http://pastebin.com/pUnKJE3J I assume there's a separate email for sites where they happened to find Google cache data, but...
deleted 10y ago
[deleted]
gnud 10y ago
As I understand the issue, the leaked data might be from any other site using Cloudflare caching. But only requests to sites using the features you mention, will have leaked data.
10y ago

pulls 10y ago

For what it's worth, as part of work on the effects of DNS on Tor's anonymity [1] we visited Alexa top-1M in April 2016, recording all DNS requests made by Tor Browser for each site. We found that 6.4% of primary domains (the sites on the Alexa list) were behind a Cloudflare IPv4-address. However, for 25.8% of all sites, at least one domain on the site used Cloudflare. That's a big chunk of the Internet. [1]: https://nymity.ch/tor-dns/ https://nymity.ch/tor-dns/

Wrhector 10y ago

This list seems to be missing any sites that are using custom nameservers, which would be common on top sites using the enterprise plans. A better way to detect if the proxy is being used would be to resolve the IP and see if it lies in Cloudflare's subnets.

jschpp 10y ago

That list isn't that useful... First of all, there is a LOT of pages hosted by CloudFlare @taviso acknowledged that in the original bug report. (https://bugs.chromium.org/p/project-zero/issues/detail?id=1139#c5 https://bugs.chromium.org/p/project-zero/issues/detail?id=11...) Furthermore, you can't say which sites were hit by this bug and simply listing all CloudFlare sites is more or less fearmongering. If you are a verified victim of this bug CloudFlare will contact you. Lastly, if you want to be sure to mitigate effects of the attack just do it... If you want to be absolutely sure that your session keys etc will remain uncompromised simply repeal all active session cookies.

sfwwolvw 10y ago
> If you are a verified victim of this bug CloudFlare will contact you. Where do you have that info from?
- jgrahamc 10y ago
  We are in the process of contacting customer who we are able had information cached by a search engine.
  - wheelerwj 10y ago
    this doesn't even begin to cover the possible scope of the leak does it?
  - troydavis 10y ago
    @jgrahamc: If this problem doesn't justify emailing all proxy service customers, what problem would?
    - jgrahamc 10y ago
      We are emailing them all, but we are starting with those that we know had data cached by a search engine.

crottypeter 10y ago

Today I learned that uber does not have a change password option once you are logged in. You have to log out and pretend you forgot the password. Bad UX if you don't know.

spb 10y ago
Holy crap, really? I've been drawing up [profiles for the user account systems of a bunch of websites for the past few years][1], and I think I've only seen that once before (on a Washington State website, no less). [1]: https://github.com/opws/domainprofiles https://github.com/opws/domainprofiles
- ams6110 10y ago
  Fairly common pattern on non-tech-oriented sites, in my experience.
dmix 10y ago
The downside of mobile first or mobile only for that matter. Normal web flows are downplayed. Not that this is excusable for a company of this size.
- crottypeter 10y ago
  There is no logged-in access to password reset in the (android) mobile app either.

iKenshu 10y ago

What if I sign in with facebook or other? Should I change muy password con facebook or what?

Crosseye_Jack 10y ago
TL;DR? You should be ok... Long Version. That (most likely) would of used oauth. So instead of sending your FB password to the site to log you into FB with. You give your FB password (if your not signed in) to FB and then facebook give the site using "sign in with Facebook" a token they can use with facebook to get account info / do actions on your FB account. Now depending on which "sign in with" system you used then often the code handed back to the site (via a callback URL handled by the client) is a single use code. So once the site using "sign in with" has used the code with FB they get another set of tokens they will use with Facebook directly. After the initial "sign in with" process the Facebook tokens are most likely never handed to clients (because they often need to be mixed with a site secret during requests to the likes of Facebook). So you _should_ be ok if you used a decent "sign in with" system like facebooks as the only thing that would of been handed back to the client and then sent from the client to the site is that single use code. The communication with the site and facebook would of used an API endpoint. Now... If you used another sites (not facebook) "sign in with" system and their API is also behind Cloudflare it could well be that some API keys could be in a cache somewhere. If those requests were signed with secrets you should be fine because without the sites secrets to lets say create a hmac signature for the request then while there might be some personally identifiable information in caches somewhere the signatures should of already expired meaning that they can't be used in say a replay attack and the data cached can't be used to create fresh requests. BUT this all depends on everyone doing things right, which may not be the case. But either way, oauth tokens are often not revoked when you change your password. I.e. you might change your FB password and then still be able to auto login on somesmallsite.org because the tokens shared between FB and somesmallsite.whatever haven't changed.
- iKenshu 10y ago
  Thanks for this answer, its perfect!
- 10y ago

jasonlingx 10y ago

Do I need to change my cloudflare password?

vasundhar 10y ago

Unfortunately this seem to include news.ycombinator.com

shakna 10y ago
> This list contains all domains that use cloudflare DNS, not just the cloudflare SSL proxy (the affected service that leaked data). It's a broad sweeping list that includes everything. Just because a domain is on the list does not mean the site is compromised. In this case, HN , IIRC, does not use the proxy. Checking the certs, CloudFlare reissue using DigiCert, I think, whereas HN is using a Comodo cert.
- dsl 10y ago
  You can upload your own cert to CloudFlare. Hacker News does hit the CF proxy and was affected. $ host news.ycombinator.com news.ycombinator.com is an alias for news.ycombinator.com.cdn.cloudflare.net. news.ycombinator.com.cdn.cloudflare.net has address 104.20.44.44 news.ycombinator.com.cdn.cloudflare.net has address 104.20.43.44

pbhjpbhj 10y ago

Do browsers still leak history info (eg http://zyan.scripts.mit.edu/sniffly/ http://zyan.scripts.mit.edu/sniffly/) is it possible to have a page show visitors if they are likely to be affected?

koolba 10y ago

That's a wide impact. While any hijacked account is bad, some of these are really bad. For example, https://coinbase.com https://coinbase.com is on that list! If they haven't immediately invalidated every single HTTP session after hearing this news this is going to be bad. Ditto for forcing password resets. A hijacked account that can irrevocably send digital currency to an anonymous bad guy's account would be target number one for using data like this.

pyre 10y ago
I also noticed the domain waveapps.com, which is for Wave Accounting.
- rwilsonperkin 10y ago
  We're investigating
- rmaurin 10y ago
  Cloudfare has advised that Wave data has not been affected/leaked. We've got engineering and security teams investigating, and we'll keep on it until we're ultra confident in the conclusion. Nonetheless, good practice for everyone to rotate all passwords today, for any services. Good security hygiene any time, and especially now.
  - petters 10y ago
    How can they know that? A broken web page could have been queried many, many times the last weeks and couldn't one of the responses contain Wave data?
    - rmaurin 10y ago
      Not 100% sure what their methodology is yet, and we're taking a cautious approach. At minimum, in the data that they've found in the wild, no Wave data was among it.
alyssenko 10y ago

yeukhon 10y ago

Would Internet Archive able to "cache" the leaks?

djph0826 10y ago

Volusion.com

base698 10y ago

Has Cloudflare fixed the issues? Should I update passwords now or wait?

spiffytech 10y ago
Yes, they've fixed the issue, so it's safe to change your passwords now. But expect some websites to prompt you to change your passwords again once they disclose the breach.

beachstartup 10y ago

this is another data point that supports my personal, hare-brained theory that the expectation of privacy on the internet is simply naive, a fool's errand. it never existed, and never will. this is despite (or maybe because) of my best efforts to secure systems as a major part of my job.

luckystartup 10y ago

Oh crap. I've entered my banking password into Transferwise quite a few times. Welp, time to change all my passwords.

pc86 10y ago
> Welp, time to stop using the same password for multiple services. > Welp, time to start using a password manager. FTFY
- deleted 10y ago
  [deleted]
- luckystartup 10y ago
  Yes, definitely a good suggestion. I already use Lastpass, which makes regenerating all my passwords a little easier.
- doubleunplussed 10y ago
  OP isn't saying they used the same password for transferwise as for their bank. Transferwise allows you to log into your internet banking and authorize a transaction through their site. You actually give them your internet banking password, regardless of how you log into their site. Which is pretty strange in itself, to trust a 3rd party with your internet banking password, but that's how it works.
  - philsnow 10y ago
    This is the main reason I've never used Mint.
  - snowwrestler 10y ago
    Folks should review their banks' policies before doing this. For example Bank of America won't hold customers liable for fraudulent transfers or bill pay transactions through their website, but sharing your online ID and password seems to void that protection. https://www.bankofamerica.com/onlinebanking/online-banking-security-guarantee.go https://www.bankofamerica.com/onlinebanking/online-banking-s...

jitbit 10y ago

Webmasters and App-devs running on CloudFlare. You (at least) have to "force-logout" your users that have a "remember me" cookie set. At least change the cookie name so the token stops working. For example, in ASP.NET - change the "forms-auth" name in the web.config file

cortesoft 10y ago
If you do that, then an attacker could just use the same token with a different cookie name and access someones account. You NEED to invalidate the token.
leni536 10y ago
> At least change the cookie name This is bad advice, you should invalidate the tokens, that's it.

arca_vorago 10y ago

Apparently root case was: /* generated code */ if ( ++p == pe ) goto _test_eof; "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. This is known as a buffer overrun. Had the check been done using >= instead of == jumping over the buffer end would have been caught." Detailed timeline: "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" Seems like a pretty good response by cloudflare to me.

kevinchen 10y ago
It's a good postmortem (describes WHAT happened), but it doesn't really communicate the impact to Cloudflare customers or their end users (describe WHY people should care).

arikrak 10y ago

It would be more useful if there was a way to see sites that actually were using the Cloudflare features that caused this bug. A large number of sites use Cloudflare, but few should have been affected by this bug: > When the parser was used in combination with three Cloudflare features—e-mail obfuscation, server-side excludes, 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-potpourri-of-secret-customer-data/ https://arstechnica.com/security/2017/02/serious-cloudflare-...

cknight 10y ago
As has been mentioned elsewhere on HN, those 3 features were capable of triggering the bug. Once triggered, potentially any Cloudflare-enabled site could have been affected.
toyg 10y ago
You only needed one service triggering the involved module in the CF proxy, and all traffic going through it would be affected, regardless of which feature each account had enabled. This over three months. I think even CF struggled to find all affected sites - which is proven by the amount of stuff still in google cache, after 7 days of purging. Unless they keep three months of logs listing all sites that used each and every proxy, you cannot be 100% certain of which traffic was affected.

r1ch 10y ago

Just got this classy spam from dyn.com. Wonder if they're going through this list emailing every domain contact. > As you may be aware, Cloudflare incurred a security breach where user data from 3,400 websites was leaked and cached by search engines as a result of a bug. Sites affected included major ones like Uber, Fitbit, and OKCupid. > Cloudflare has admitted that the breach occurred, but Ormandy and other security researchers believe the company is underplaying the severity of the incident … > This incident sheds light and underlines the vulnerability of Cloudflare's network. Right now you could be at continued risk for security and network problems. Here at Dyn, we would like to extend a helpful hand in the event that your network infrastructure has been impacted by today's security breach or if the latest news has you rethinking your relationship with Cloudflare. > Let me know if you would be interested in having a conversation about Dyn's DNS & Internet performance solutions. > I look forward to hearing back from you.

IgorPartola 10y ago
It's clever but feels at least a 3/10 shitty. Dyn is an old company and back in the day they provided free subdomains while nobody else did. I haven't used them recently because their pricing seems so high. How do others feel about them?
- OraclesDyn388 10y ago
  With Oracle announcing they're buying Dyn, I'm "voting with my wallet" and moving off them. I'm small potatoes compared to Netflix or other big dogs that use them.
- r1ch 10y ago
  I still have a lifetime standard DNS subscription with them from back in the day when they were dyndns.org and you could physically mail them cash. The DNS hosting has been very solid (except for the day Mirai took them offline) but the standard query limits are way too low for any moderately trafficked website. All the managed DNS providers I looked at seem to have very restrictive query limits without a "enterprise - contact us" plan, one of the reasons why I decided to just do DNS-only on Cloudflare.

AdmiralAsshat 10y ago

Authy is on the list. It would be really nice if they confirmed whether they are vulnerable or not, considering they hold all of my 2FA tokens. Otherwise I'll have to re-key the database.

infinite8s 10y ago
Wouldn't you rather just do that as a precaution? Then you won't be constantly worried that they might have had their data leaked.

vmarsy 10y ago

Something I have a hard time understanding, is how Cloudfare's cache generator page had access to sensitive information ? Were the 2 things running on the same process? If they were not, there's no way that the buffer overrun could read an other process memory, right? it would have failed with a segfault type of error. If so, shouldn't Cloudfare consider running the sensitive stuff on a different process, so that no matter how buggy their caching engine is, it would never inadvertently read sensitive information?

cjslep 10y ago
SSL connections were terminating at the proxy, so the proxy used plain HTTP to the web service backends.
- cjslep 10y ago
  Unsure about the random downvotes. It's CloudFlare's "Flexible SSL" offering. Granted, sibling non-speculative comments elaborate more thoroughly for the "non-flexible" cases.
- jpetersonmn 10y ago
  Are you sure about this? Just because they terminate ssl on the proxy doesn't mean the traffic between the proxy and the web service backends was plain HTTP. That's certainly not how we do things.
dugmartin 10y ago
My guess given their widespread use of Go is that each parser was a goroutine which uses the same process heap as other goroutines parsing other page requests.
- ecnahc515 10y ago
  Have you read their incident response? If you had, you would know they weren't using Go for this and it was actually an issue an a parser generated by ragel (C++) which was then used as an nginx module.

ig1 10y ago

Worth noting this statement by Cloudflare CTO: "I am not changing any of my passwords. I think the probability that somebody saw something is so low it's not something I am concerned about." http://www.bbc.co.uk/news/technology-39077611 http://www.bbc.co.uk/news/technology-39077611

new299 10y ago
That seems like a reasonably unwise thing to say. It would be absolutely reasonable for someone to change there passwords after breach. By citing a personal view point they're seeking to downplay the issue while providing little useful advice.
p49k 10y ago
That kind of statement reminds me of this guy: https://www.wired.com/2010/05/lifelock-identity-theft/ https://www.wired.com/2010/05/lifelock-identity-theft/
devy 10y ago
That seems a lot like something a company which was just implicated in a gigantic leak would say: damage control.
MarkMc 10y ago
That statement must have given Cloudfare's lawyer an aneurysm. Seems to me that management's attempt to downplay the problem exposes the company to as much risk as the original technical mistake.
mbesto 10y ago
*Article says COO, but Twitter says CTO. Strange. And he's fairly active on these forums. That seems like such an odd thing to say given how important security is/should be at CF...curious if jgrahamc would further clarify his position here.
- fencepost 10y ago
  Agreed on the importance of security, but if his credentials from outside their network are able to be used in any significant way to impact their services or systems then they're doing something tragically wrong. For that matter if his credentials can be used anywhere to impact their services it's a failure.

RidleyL 10y ago

I wrote a python script to help check your LastPass database for any potentially affected sites. https://github.com/RidleyLarsen/cloudbleed_check_lastpass https://github.com/RidleyLarsen/cloudbleed_check_lastpass

JaggedJax 10y ago

In an email from Cloudflare sent out this morning they said: > In our review of these third party caches, we discovered data that had been exposed from approximately 150 of Cloudflare's customers across our Free, Pro, Business, and Enterprise plans. We have reached out to these customers directly to provide them with a copy of the data that was exposed, help them understand its impact, and help them mitigate that impact. Does this jive at all with the Google or Cloudflare disclosures? They are claiming that across all caches they only found and wiped data from ~150 domains, can that be true?

mistercow 10y ago
Every single thing Cloudflare has said about impact has sounded very suspiciously optimistic to me. For example, they claim that they would know if an attacker had been intentionally exploiting this bug, but I've seen no details to justify their confidence. So no, I don't think we can assume that the scope was as limited as they're making out. Edit: As my coworker points out, as of 2013, they only kept 4 hours of access logs (source: https://blog.cloudflare.com/what-cloudflare-logs/ https://blog.cloudflare.com/what-cloudflare-logs/). So basically their existing attack detection infrastructure (built without knowledge of this bug) may not have found anything suspicious, but it appears that that's the extent of what they can say about the last few months. They can claim that they found no evidence within the last week (one hopes that they stopped discarding logs when they found out about the attack), but if they want to convince us that they know this wasn't being exploited as late as two weeks ago, they need to provide specific evidence.
dsl 10y ago
CloudFlare has no idea of knowing what was in uninitialized memory that was leaked. This is just spin.

danjoc 10y ago

Is there a "standard" in the works for changing a password? Stuff like this is happening rather too frequently for my taste. I need a tool I can use to update all my passwords everywhere automatically and store the new ones in my password manager.

dingdongding 10y ago
I agree. This is about time password managers and "changing password" should be standardized. Password Managers should now be supported across the board. Not just browsers.
jbkly7 10y ago
LastPass has auto-password change: https://blog.lastpass.com/2015/05/auto-password-change-now-available-in-the-lastpass-security-challenge.html/ https://blog.lastpass.com/2015/05/auto-password-change-now-a...
- soundoflight 10y ago
  Dashlane has that feature too.

paradite 10y ago

Couldn't find a practical description of who is affected anywhere. Is it just the customers who have Cloudflare HTTPS proxy service being affected, or anyone using Cloudflare DNS is affected?

dsl 10y ago
Anyone who passes HTTP or HTTPS traffic via CloudFlare might have had that data leaked into other users sessions.

tonyztan 10y ago

Just received an email from Glidera, a Bitcoin exchange. This is the first service to ask me to reset my password. I wonder why Uber, NameCheap, FitBit, and many others have yet to warn their users? Is Cloudflare downplaying this? > Hi [Username], > A bug was recently discovered with Cloudflare, which Glidera and many other websites use for DoS protection and other services. Due to the nature of the bug, we recommend as a precaution that you change your Glidera security credentials: > Change your password > Change your two-factor authentication > You should similarly change your security credentials for other websites that use Cloudflare (see the link below for a list of possibly affected sites). If you are using the same password for multiple sites, you should change this immediately so that you have a unique password for each site. And you should enable two-factor authentication for every site that supports it. > The Cloudflare bug has now been fixed, but it caused sensitive data like passwords to be leaked during a very small percentage of HTTP requests. The peak period of leakage is thought to have occurred between Feb 13 and Feb 18 when about 0.00003% of HTTP requests were affected. Although the rate of leakage was low, the information that might have been leaked could be very sensitive, so it’s important that you take appropriate precautions to protect yourself. > The actual leaks are thought to have only started about 6 months ago, so two-factor authentication generated before that time are probably safe, but we recommend changing them anyway because the vulnerability potentially existed for years. > Please note that this bug does NOT mean that Glidera itself has been hacked or breached, but since individual security credentials may have been leaked some individual accounts could be vulnerable and everyone should change their credentials as a safeguard. > Here are some links for further reading on the Cloudflare bug: > TechCrunch article: https://techcrunch.com/2017/02/23/major-cloudflare-bug-leaked-sensitive-data-from-customers-websites/ https://techcrunch.com/2017/02/23/major-cloudflare-bug-leake... > List of sites possibly affected by the bug: https://github.com/pirate/sites-using-cloudflare/blob/master/README.md https://github.com/pirate/sites-using-cloudflare/blob/master... > If you have any questions or concerns in response to this email, please contact support at: support@glidera.io

SnaKeZ 10y ago
Namecheap: https://blog.namecheap.com/cloudflare-security-incident/ https://blog.namecheap.com/cloudflare-security-incident/

nodesocket 10y ago

This is ridiculous and somewhat irresponsible. This is just a list of domains using CloudFlare. The leak was only active under a set of very specific cases (email obfuscation, server-side excludes and automatic https rewrites). I question Pirates (https://github.com/pirate https://github.com/pirate) motives for even doing this? Karma? Reputation?

kijin 10y ago
Only a few hundred sites were leaking, sure, but the leaked info could have come from any domain that was being proxied by the same edge server. So we would do better to assume that any domain that uses Cloudflare could have had their passwords and other sensitive info exposed via leaky neighbors.
- nodesocket 10y ago
  Thanks for clarifying. You are absolutely right.

grogenaut 10y ago

I ginned up this little tool tonight to help people out instead of grepping. https://bleed.cloud/index.html https://bleed.cloud/index.html Sorry for the index.html, trying to figure out how to get index file to work on cloudfront. You can also run the python script on the website anonymously on your computer to dig sites out of your email, which is a good indicator that you have an account with them.

kiallmacinnes 10y ago

And, I've found several of my domains on this list.. Some of which don't host web content etc and only use cloudflare for DNS. The list is currently ~4.3mil entries, which honestly feels like a rather low figure. I have no data to back up my gut feeling though ;) Anyway, I'm OK with them being on this list, as I believe understanding the scope of the problem is important to figuring out how we prevent these kinda problems in the future.. (For example, answering this question requires understanding who uses CloudFlare: Why are so many sites concentrated on a single infrastructure?)

cloudvrfy 10y ago

I wrote a simple website[1] to show if user have visited the websites included in the list automatically without browser plug-ins. It uses :visited CSS pseudo-class to highlight the site user have visited before. It is not 100% accurate, but it can be a fun way to quickly show people that they may visit sites on the list. [1]https://cloudbleed.github.io/ https://cloudbleed.github.io/

simooooo 10y ago
Amazing that this hack still exists
salemh 10y ago
I want to share this with my more non-techy persons, but, on Chrome, turning of uOrigin, their are no names of companies listed. I can hover over every block for the name, but.. is this an error, or intentional to just have a large heart-block with no labels?
- cloudvrfy 10y ago
  Could you suggest how the names of companies should be shown so we can improve the website? Appreciate your reply :)
  - salemh 10y ago
    Just a right-side text that highlights once you mouse-over would be great. It may be too much to display all of names, but having it populate gives some idea of where you need to go. Perhaps just every "red"/affected site could be populated on the right side :) Appreciate the layout outside of naming labels however, nice work.

em0ney 10y ago

The list of websites once again reminds me of what avenue Q immortalised in song: the internet is for porn