Cloudflare DNS != Cloudflare Proxy

[33b5e5]

"It's a broad sweeping list that includes everything. Just because a domain is on the list does not mean the site is compromised."

You already know this, so what exactly is the purpose of this overly broad list?

Cloudflare's DNS service is basically free. It's massively popular. Centralization of DNS may be worth debating, but it's an aside. Here you're just lumping all of these customers, many of them totally unaffected, into a pile vaguely labeled "potentially affected". It's very likely only a small subset of these customers are using the SSL proxy service.

Please just stop posting this inaccurate list. Bring it back when you have a list of domains that are actually impacted. Checking the response headers seems like a much better approach.

[pirate]

Yes I'm well aware these two are not the same. Good luck checking the response headers of 4,000,000+ cloudflare sites though, it basically amounts to a DoS attempt.

We're working on a go script that checks to see if the A/CNAME's resolve to IP's in cloudflare's range, that seems like the logical next step.
Unfortunately that data will become rapidly out of date. Time really was of the essence when compiling this initial list as customers may move off cloudflare after hearing about this leak. It needed to be done as close as possible to the announcement time, we can work on narrowing it down after the fact.

[pirate]

Also keep in mind, not only SSL proxy customers are affected, all proxy customers had possible data leaks.

[pirate]

Check out: http://doma.io/2017/02/24/list-of-affected-cloudbleed-domains.html for a list of confirmed affected domains. I'll make a second txt file in this repo if we have a major breakthrough in discovering more confirmed domains, but otherwise this list is probably the best we've got right now. It's unfortunate, but I'd rather have an overly broad one than an overly narrow one.

[33b5e5]

Proxy customers are probably a small subset of DNS customers.

Point taken on the difficulty of checking response headers. I also understand the issue of timeliness, but to me it still seems irresponsible to lump all Cloudflare customers into the same pile, suggesting they are all vulnerable.

People are linking to this list without enough context or experience to make these distinctions. I think it would be more helpful to just pull the DNS customer list and only publish the confirmed affected domains.

[pirate]

I was assuming earlier that only devs are landing here, I guess that's not a good assumption to make anymore since the link has spread fairly far.
I agree that it's less than ideal to publish this full list to the public, maybe producing an easy website to search the this particular list may not be the best idea just yet (#37).

The problem is that the scope is of this leak is truly massive, and there is almost no way to get a definitive list of compromised domains (unless you're cloudflare). Any list made will either be dangerously incomplete, or overly broad, and when time was of the essence and money was on the line, I decided to err on the broad side.

[caleuanhopkins]

Regardless, there's plenty of plenty coming here who don't use Cloudflare for their sites but have accounts with sensitive data on sites listed here. It's useful to be aware of the extent of this leak.

[Zenexer]

Headers can be spoofed. The best way to verify without putting too much strain on Cloudflare would be to check the A/AAAA records against Cloudflare's advertised routes. It's easy enough to do this for a small set of domains that we've created based on NS records; however, if we wanted to scan all known domains (and potentially public subdomains) to accommodate #42, it'd take a lot more work.

[leeDav]

DNS-only customers are not affected.

From CF's blog, the only way sites can be affected are by;

The final buffer containing data had to finish with a malformed script or img tag
The buffer had to be less than 4k in length (otherwise NGINX would crash)
The customer had to either have Email Obfuscation enabled (because it uses both the old and new parsers as we transition),
… or Automatic HTTPS Rewrites/Server Side Excludes (which use the new parser) in combination with another Cloudflare feature that uses the old parser. … and Server-Side Excludes only execute if the client IP has a poor reputation (i.e. it does not work for most visitors).

[Zenexer]

@leeDav You're half-right. Yes, DNS-only customers aren't affected. However, the information you gave after that is what enables a leak. The catch is that leak isn't just for the directly affected site; it's also for other requests to other sites taking place around the same time. If my site triggers the bug, even if your site doesn't, your users' data could appear on my site.

Here's a cached leak. Scroll down to the bottom. Notice the leak is for www.bizpacreview.com, but the site triggering the bug is fujiyoutube.com. The former was most likely not directly affected, yet its user's data is still being leaked.

[leeDav]

Ah, I see, apologies. My understanding was that only sites that use those services (Email obfuscation, HTTPS rewrites, Server-side excludes) could leak data about each other.

Thanks for clearing that up 👍

[Gunstick]

There are 161 websites affected. Not thousands. Please close this useless project.

[kulttuuri]

Cloudflare's latest email mentions "In our review of these third party caches, we discovered exposed data on 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."

[simonkberg]

Cloudflare has contacted customers who they know have had their data saved by third party caches, this does not mean that other sites are unaffected. Travis Ormandy who uncovered and reported this bug even stated that Cludflare "severely downplays the risk to customers".

Multiple instances of leaked data has been uncovered in the wild since the disclosure: http://doma.io/2017/02/24/list-of-affected-cloudbleed-domains.html

[Zenexer]

Based on the data I've been able to gather--which I admit is incomplete--I find it extremely unlikely that only 150 websites were impacted. Extrapolating the data suggests that any Cloudflare-proxied website receiving decent traffic almost certainly had data leaked. The most common sensitive user data I saw was session cookies and the likes.

The most reasonable course of action for affected sites, at this point, is probably to invalidate all session cookies, CSRF tokens, and other security-related data likes to find its way into headers. This has relatively little impact on users and fenders most of the sensitive user data harmless.

However, special consideration will need to be given to cases in which merely associating an individual with a website could prove harmful, as IDs often appeared that could associate users with social profiles, locations, advertising IDs, and more. Sometimes detailed demographics data was present, including age and gender.

It's also worth noting that if you run a sensitive website, you're also affected I'd you used JavaScript libraries hosted by cdnjs. Referrer, origin, IP address, and location information could be used by oppressive governments (for example) to link users to sensitive sites.

An interesting discovery related to this: if I'm interpreting this leaked data correctly Clodflare's own cdnjs appears to have Strict SSL disabled, with the actual JS hosted at Linode. This means any entity between Linode and the CloudFlare PoP--say, a meddlesome ISP or government--could, and still can, inject arbitrary JavaScript into any website using scripts hosted by cdnjs. This has the potential to be much more of an issue than the "bleed" issue on which we've been focusing. Granted, I could be interpreting these internal headers incorrectly, but they seem pretty clear to me.

Edit: Changed Full SSL to Strict SSL. This doesn't affect the status of the issue.

[caleuanhopkins]

The most reasonable course of action for affected sites, at this point, is probably to invalidate all session cookies, CSRF tokens, and other security-related data likes to find its way into headers.

So next question is if we do this, how do we prove this for our domains to be removed from the list? I assume that's the overall goal of this project is to inform owners their site could be affected, for the owners to take action and then "secured" sites are removed from the list?

[Phineas]

@caleuanhopkins They still might've been affected during the breach, so I think we'll be keeping them on the list until we can prove that domains are 100% secure. But for now, I guess we could do something like adding tags next to now secured domains.

[caleuanhopkins]

@Phineas as someone with several domains in the list, tagging "clean" domains would be appreciated as this domain is the number 1 trending repo in the daily view of popular repos on Github (https://github.com/trending) so this list is getting quite a bit of exposure. In turn, this is highlighting a large number of domains as targets for possible exploit. Happy to do whatever is advised to achieve the tag against my domains if that's the course of action that is agreed upon

[lodicolo]

Several of you commented on different ways to check if a domain uses the CloudFlare proxy, but to my understanding of a site was using the CloudFlare proxy at any point during the timeframe of the vulnerability would result in potential leakage, correct?

If that is indeed the case that would mean the list, despite having 4 million domains on it, isn't even complete (I know of at least one website that was using the CloudFlare proxy but removed it during the vulnerability).

[coderobe]

@lodicolo Your assumption is correct. And yes, this list is incomplete.

[coderobe]

@caleuanhopkins If, at any point in time during the bug, a domain was proxied through cloudflare, it may have leaked data via other (unrelated) domains. We do not remove domains from the list that have used CF as a proxy during the affected time period. We may add a link to a blog post on said domain, explaining what happened.

[nikitasius]

Seriosly, make a work, check http/https connection of each domain and update the list.

[Zenexer]

@nikitasius Sadly, it's not that simple, but we're doing our best. If you'd like to help, feel free to contribute.

[nikitasius]

@Zenexer , my point of view is simple: if you do job, to it well and clear. This job done probably well (parsing), but not as clear as it should be.

Text

This is a (work-in-progress) list of domains possibly affected by the CloudBleed HTTPS traffic leak. Original vuln thread by Google Project Zero.

Not enough clear. Write possibly with HUGE LETTERS, precise what it's a DNS hosting, 'cause more and more people use this repo for kind of trash plugins for browsers without understanding how does it work and such crap affect the site/admin reputations. I understand how does it work, i know to determinate who was affected and how not, not 99% or users who read this readme.md didn't.
Need more information for guests and anonymous users.

I have ~30 domains, parked on CF.

[coderobe]

@nikitasius like @Zenexer said, if you feel like the readme does not describe this repo well enough, you're free to send us a pull-request regarding this.

Regarding your "point of view": We're all just volunteers that manage this list for free. You can't just demand something to be done.

[caleuanhopkins]

I appreciate the work and the fact you guys are volunteering to maintain this and I'd like to think everyone involved in thankful for all the work you guys are doing. I would also be highly appreciated if a procedure as agreed upon for marking "cleaned" sites on this as right there is not an obvious way to determine from the list which sites owners are aware of the leak and have taken action and those who have not. The tagging system proposed seems ideally and I'm more than to contribute my help with this if needed

[ghost]

@33b5e5

Please just stop posting this inaccurate list. Bring it back when you have a list of domains that are actually impacted.

Please note that the list may be intended for CloudBleed awareness, but ppl could be using it for other purposes.

I'm using it to do an ethical check on organizations. For me the broadness of the list is not an issue.. I have a script that checks this list (among others) whether an organization I'm researching is doing something unethical. If the org appears on this list, then I run this command to see if it's using CloudFlare to DoS attack Tor users:

firejail --net=vnet0 --dns="$(ip address show dev vnet0 | awk '/inet\>/{gsub(/[/].*/,""); print $2 }')" lynx -dump -nolist 'http://change.org' | grep -i ray.id

That example is for change.org.

If no ray id appears in that output, then the site probably not DoS attacking Tor users, but I still check the HTTP headers, and if there is a Ray Id there I still regard the organization as privacy-hostile for centralizing the web and sharing all their traffic with CF.

@Zenexer

The best way to verify without putting too much strain on Cloudflare would be to check the A/AAAA records against Cloudflare's advertised routes.

It's unclear why exactly straining CloudFlare would be something to avoid. They are not transparent (e.g. they don't publish a list the way Tor exit nodes are published). So they use the transparency of the Tor network against the Tor community yet hide the extent of their wrongdoing. It would be a good service to benefit the security of the community to map out all sites relationship to CF, even if it were to strain CF servers. Although if you're talking in the context of legality, then there could be a valid point there. It would have to be done in a way that cannot be challenged legally.

[pirate]

@libBletchley this list is not ideal for what you're doing. For your purposes you're best off going to crimeflare.com where the list is kept more up-to-date. If you want people who are specifically proxied through Cloudflare you could try scraping any certificate transparency logs you can get your hands on, they're often full of shared CF SSL certs that give you 10-50 CF domains a pop.

[ghost]

@pirate

For your purposes you're best off going to crimeflare.com where the list is kept more up-to-date.

Thanks. I knew about crimeflare but didn't realize they had a list.

The 2nd domain I checked (change.org) was unlisted. When I used the crimeflare search tool, it replied "Search aborted — these are not CloudFlare-user nameservers. " So apparently it was wrong for me to assume that all proxied services are also using CF DNS. And if I understand correctly crimeflare is also making that assumption. Anyway, this also suggests crimeflare's list can only supplement your list (note that your list does include change.org, and change.org happens to be proxied through CF as well, with Tor exits blacklisted).

Maybe I'm misunderstanding your suggestion w/the cert transparency logs, but if I'm given 50 or so arbitrary CF domains when I'm looking for one (or set of) organizations in particular, I'm not sure how that helps. It seems I'd be better off just looking for Ray Ids in the header and body of a site's landing page over Tor. Unless you're suggesting I have a web crawler running and feeding a growing database continuously -- which may be interesting if I'm freed up for that effort.

One thing your list does for me: if I have a company name but don't know their domain, I can grep for the company name and get likely candidates for the domain name, and at the same time know if CloudFlare checks need to be done. Grep is quicker than doing the more labor intensive web searches.

OTOH, foodsaver.com is not on either list, and yet it's proxied through CF. So maybe I should scrap the lists, and find some other way to resolve company name to domain name, and do the cf ray id check for every site.

[ghost]

@33b5e5

it still seems irresponsible to lump all Cloudflare customers into the same pile, suggesting they are all vulnerable.

I found that funny, because CloudFlare customers are lumping all Tor visitors into the same pile and treating them as malicious (although many of them do so unwittingly, but still hard to inspire sympathy for anyone doing business with CF).

[Zenexer]

@libBletchley

1. Two wrongs don't make a right. You're still bound by standard laws and ethics in your pursuit of justice.
2. You're implying guilt by association.
3. There are resources floating around that are much better suited for your purposes. There are security research companies that sell access to lists of almost all known domain names and their associated nameservers for nominal fees, or you can attempt to obtain the zonefiles for each TLD on your own.

[ghost]

@Zenexer

Two wrongs don't make a right.

This only applies when two actions are "wrong". You've not established that the second action is wrong to begin with.

CloudFlare is an unethical vigilante extremist organization. Consequently, feeding that company is unethical. Actions that mitigate feeding CloudFlare supporters are not only not wrong, there is in fact an ethical duty not to feed CF supporters.

You're still bound by standard laws and ethics in your pursuit of justice.

Not sure what you mean by "standard" laws. I'm bound by the laws of the countries I operate in. And I'm not bound by any "standard" ethics. I'm not a member of any organized religion, so I'm bound only by my own ethics.

You're implying guilt by association.

To be precise it's guilt by sponsorship of a malicious entity. You could try to water-down that relationship and say that it is an "association" of sorts, but to then jump to the conclusion that it's an association fallacy is wrong. Patronizing a company is sponsoring it. You've created a new fallacy by saying that because there's an association in place, CloudFlare's supporters are therefore off the hook for wrongdoing.

There are resources floating around that are much better suited for your purposes. There are security research companies that sell access to lists

I appreciate the suggestion, but buying a commercial product is a bit out of scope for micro-scale non-commercial activism. Perhaps if I ran a donation-driven non-profit org to decentralize the web then it would be interesting.

[Zenexer]

@libBletchley I have nothing against you expressing your opinion, but you're doing so in a dormant issue for a project that essentially serves as an archive; it's not actively updated, as it is meant to preserve a snapshot of a subset of sites using Cloudflare at a specific point in time.