New on LowEndTalk? Please Register and read our Community Rules.
All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
Comments
https://github.com/pirate/sites-using-cloudflare/blob/master/README.md
What list are you looking at?
https://github.com/pirate/sites-using-cloudflare/archive/master.zip
@Hybrid that list is probably all the sites that use Cloudflare DNS, but only the sites that used the reverse proxy are (potentially) affected.
FWIW, Cloudflare emailed all its customer-sites and claimed that they only found evidence of ~150 customer-sites' data being compromised:
Of course, the absence of evidence does not imply evidence of absence.
Vultr:
Doubly so in this case, to the point of that evidence being completely useless for impact assessment... they've only looked at very limited short-term caches (Google and friends replace the data after a few days), and so they don't know about all the other scraper caches that retain data for months or years.
So from a practical POV, there's absolutely no way to assess impact, other than "we know that at least these people are fucked".
@joepie91 is absolutely right. The FSB and N.Z.S.I.S. have been scraping data for years but Cloudflare hasn't checked their databases. We must be vigilant about changing passwords.
I grabbed the home page of ~300 million hosts in Nov/Dec. Wonder if it's worth a look. I suppose matching 'X-Real-IP' would be a start.
I'm afraid it's worse than some think.
From what I know cloudflare offers the ssl/tls frontend behind which everything is UNencrypted - at a minimum in their own network but very probably also towards the target server at their customer (The first one is sure, for the latter one I lack concrete experience with cloudflare. Maybe a provider here can tell us to be sure).
So all passwords and other confidential data are at risk.
To understand the risk fully, also keep in mind that most OSs and software still uses the old unix approach of hashing password only at the server side.
Someone here proposed to change passwords every 90 days. That shows good will and concern but doesn't solve the problem. In a scenario where network packets are transferred in milliseconds and where transferring megabyte or even gigabyte of data within seconds that time frame is by far too large.
In view of the considerable danger the cloudflare incident has created I have asked my current client for permission to publish a somewhat more primitive version of an algorithm I designed and use with current projects:
1 server side: create the password base hash and inform the client about the salt used. This roughly equates to a normal OS password file where hashes of the users passwords are stored.
2 client side: Using the provided salt create the same hash.
3 When connecting/logging in (client): get current GMT(!!) date and hour:minute in a certain format (like "YYYYMMDDhhmm") plus the server FQDN -> example: "www.lowendtalk.com201702241149" and hash that string using the prehashed base password as key.
4 (server) do the same. In case authentication fails and current time seconds is less than 3, repeat with minute value one lower.
Note: You can use a very cheap hash, say md5, as this second hash just is what normally is sent totally unencrypted anyway. This is only to automagically change passwords every minute plus have "passwords" that are guaranteed to be different for every server (you would be amazed how many users out there still use only one or maybe two passwords for everything)
Note 2: This simplified version has the advantage that it can be simply coded even in most scripting languages. All you need is time functionality and any hashing; even primitive hashing will do the trick.
Clarification: Do use the hash itself only, i.e. without the cipher and salt prefix! Those are known to both the server and client but are not transmitted (such making the transferred hash worthless for any attackers). If this is not clear just have a look at how server password hashes look like (example: cipher prefix$salt$hash - you only use the last part).
And btw: in case you are using cloudflare, just forget about ssl/tls.
JFC.
??
The fact that Cloudflare-to-client is unencrypted. That was glossed over a bit, but I believe you are 100% correct- they made sure to tell us all of their interprocess communcation is, but when I can't trust them to malloc(X+1) and not hop over it, welp..
Nah, only if you use Flexible SSL.
OK, thanks.
As you might know I put my brain into the fridge while I eat so it doesn't get dirty. Hence I needed some help in understanding "JFC".
As for the unencrypted cf->customer: ssl/tls is still very (computing) expensive so I guess quite many cf customers actually like what cloudflare does as it saves them cycles while they still can look "secure" .
@tr1cky
Thanks. So, at least a part, namely the flexissl customers, are pretty much fucked now.
Is there a known way to find out whether a given server behind CF uses flexissl (so that we can avoid the like the cheapshot plague they are)?
Every site that uses ssl through CF is f*cked, because they strip the ssl off (you will notice that they use their own certs), then re-add the ssl to connect to the backend server.
This means that at the point where this bug has impact (=in memory of the cache), the data is unencrypted.
I don't think ssl use that much cpu cycles i enabled ssl server-wide on all my site a few year's back the server load did not increase not that much.
There's no way to find out. I'm also using flexible SSL on all sites that normally don't need SSL (e.g. a wordpress site where you can't register).
That's wrong. ssl/tls, depending on ciphers chosen and cpu, has a ratio of between 1:10 to 1:100 as compared to non-ssl connections.
This isn't about load but about requests per second. In extreme cases the ratio can become 1:1000 and worse, e.g. with an event driven server and small packets.
We thankfully don't use CF on our Billing System or our VPS Panel only the main site.
-Snip- poor reading my on my part - misread that as vps panel using cloudflare
I really wish Vultr supported something besides Google Auth. Google Authenticator is known-broken as irretrievably lose all your configured accounts if you ever lose or replace your phone.
Their only other option is Yubikey...grrr. I really would just prefer plain ol' SMS.
They support Authy.
Not if you root your phone, or save a set of keys offline. I've used offline keys when I've smashed a screen before.
Authy is pretty solid. I mean, there is no way to have it retrievable and not also theoretically exploited in some way, even if that way seems far fetched today. But I'd still say retrievable 2FA + password is infinitely better than just password, so authy plays a good role.
Whoa, wait, that's not known-broke: it's the whole point. The second factor in two-factor authentication is supposed to be something that you and only you physically possess. If 2FA tokens were backed up online behind a password it wouldn't be true two-factor authentication.
The same goes for SMS codes where phone company customer service reps can be socially engineered into forwarding your number or sending out a new SIM. Rather topically, CloudFlare itself (via the CEO's Google Apps account) was the victim of a hack thanks to just that a few years back: https://blog.cloudflare.com/the-four-critical-security-flaws-that-resulte/
Convenience is, generally, the enemy of security. That said risk tolerance is ultimately a personal choice and if you're okay with something more akin to 1.5A, or you'll only otherwise use a password, there are apps that let you sync your two-factor tokens between devices like Jarland's recommendation, Authy. I use that one myself for accounts where security isn't life or death and it's pretty great.
Don't get @jarland going...
It's a solved problem.
While generally true this is not always the case - large financial corps save memory and CPU shadowing operations, allowing to play back entire transaction partly or fully for weeks, if not months, in this case having a full dump of all outgoing data would also allow assessment.
"Practical" depends on knowledge of their backend workings; which you don't have.
Announcement from my side of the ocean...
https://www.digitalocean.com/company/blog/digitalocean-your-data-and-the-cloudflare-vulnerability/