# Cloudflare and passwords



## imnohbody (Feb 24, 2017)

From September to about a week ago, there was an exploit that allowed private information transmitted via the Cloudflare proxy service network to be seen by others, including login info.

FA uses Cloudflare, so it might be a good idea for everyone to change their passwords, just in case they may have been compromised.

(Yes, I know... "Who cares what a bunch of furry freaks are doing?" Consider, though, how often people reuse passwords over multiple sites because it's less hassle than messing around with a PW manager or remembering a buttload of different passwords.)

More information about the issue can be found here, including a ~21MB text file with a complete list of domains that may have been affected by the exploit, and Cloudflare's own discussion of the issue can be found here.


----------



## jayhusky (Feb 24, 2017)

I went through a list of them this morning and found the following:


*Affected*
Wikifur.com
sofurry.com
sofurryfiles.com
weasyl.com
weasyldev.com
furaffinity.net
techfurmeet.org
anthrocon.org
furtherconfusion.com (also .net and .org variants)
furrynetwork.com



*Not Affected*
Inkbunny, Califur, Confuzzled, Scotiacon, MidwestFurfest


----------



## GreenReaper (Feb 24, 2017)

Furry Network does run on CloudFlare. I don't know if they use that particular feature, but it may affect all servers used by that node.
You can tell because if you ping beta.furrynetwork.com it will resolve to an IP address in CloudFlare's zone - just search for the address.

Lists may not be complete. But you're right that Inkbunny is not impacted; we run our own CDN (and don't send cookies/login/site interactions to it anyway - it's strictly for public content, site images/backgrounds, etc). This kind of situation is a big part of why we do that.


----------



## jayhusky (Feb 24, 2017)

GreenReaper said:


> Furry Network does run on CloudFlare. I don't know if they use that particular feature, but it may affect all servers used by that node.


My apologies. will edit to show this.

I rechecked and found it on the list.


----------



## Wakboth (Feb 24, 2017)

Yeah, I think if FA is on the list of potentially compromised sites, an announcement telling users to change their passwords would be a good idea.


----------



## GreenReaper (Feb 24, 2017)

Fur Affinity has said they were not at risk, based on not using specific features mentioned in CLoudFlare's advisory. I don't think this is necessarily correct.

CloudFlare were careful in the wording of their advisory to say that e.g. private SSL keys stored by them were not impacted, and that only certain features triggered the bug.

But they also included this tidbit:
"Because Cloudflare operates a large, shared infrastructure an HTTP request to a Cloudflare web site that was vulnerable to this problem could reveal information about an unrelated other Cloudflare site."

My reading of this is that data would not be exposed _via_ furaffinity.net, but data _previously sent_ from/to furaffinity.net might be exposed via a page which  was served for a site using the flawed features. Computers tend not to bother clearing up memory once they're done using it; that takes time and it's assumed that it'll be done when it's reused. In this case, it wasn't, so anything left over could be revealed. And it isn't necessarily memory used for the same thing - it could be something completely different.

To be honest, I doubt that much data will be exposed by this, nothing like last year. But it is a reminder of the dangers in using shared hardware.


----------



## Wakboth (Feb 24, 2017)

GreenReaper said:


> To be honest, I doubt that much data will be exposed by this, nothing like last year. But it is a reminder of the dangers in using shared hardware.


Yeah, but better safe than sorry.


----------



## Dragoneer (Feb 24, 2017)

GreenReaper said:


> Fur Affinity has said they were not at risk, based on not using specific features mentioned in Cloudflare's advisory. I don't think this is necessarily correct.


There are over 4.2 million sites in the list which were provided. FA does not use any of the security features which lead to the issue. Cloudflare has verified that, to all their knowledge, we are not one of the sites impacted by this.

I understand your concern, and security is something that we should always put as a priority. FA did not use the features which were specifically cited as being involved in this incident.


----------



## Resua (Feb 24, 2017)

To be lazy and quote my qualifications from another post...



> I have been involved in both IT and network security for over a decade and a half. I have written up dozens of security breaches, including some for major credit card processors, health insurance companies, and credit unions.



This isn't an 'attack' like most people would think.  It was a data exposure issue, and it would not have been possible to target any particular site with it.  It would be the equivalent of taking a thimble, dipping it in the ocean, and then saying you knew before you collected the water which atoms of it had touched a whale this morning.  The data returned was 100% random.  Essentially, anyone who 'exploited' it would have gotten untargeted data.  And most who were exposed to it most likely had no idea what it was, refreshed the page, and went along their day when it worked that time.  Which is why it took a few months to find it.

This has nothing to do with a bad config by FA, etc.  And the specific code that was faulty (if you read the cloudflare technical details posting) would have required a certain combination of features to be enabled. 

The huge posted list you keep seeing around has nothing to do with the scary named 'cloudbleed' overflow issue.  Those are just EVERY site that uses cloudflare DNS.  You couldn't execute code, and sample any particular sites data willingly.  Only random chunks from sites that had the specific features enabled.

To boil it down:  Change your passwords everywhere anyway, but it's unlikely FA was exposed by this.  The issue is now patched, completely, throughout the world, and is nothing like the heartbleed issue which is still found in devices everywhere.  This bug is squashed.


----------



## GreenReaper (Feb 24, 2017)

_In reply to a post raising concerns over RAID5 which disappeared after this reply..._

It's accurate - though it may be updated soon, as our lease is coming up for renewal. The main server is likely to be replaced with this (+2x120 or 2x240GB SSDs).
Our database is well-indexed and relatively compact. Average CPU usage rarely ventures above four cores, although image processing and backup compression can use more.

We consider RAID5 acceptable given that only four drives are involved. LeaseWeb replaces hardware promptly upon request, and hardware RAID can rebuild within half a day.
It is not a backup; image data is replicated nightly to our secondary server; and most files transfer much sooner, upon initial access in Europe.

I'd be glad to discuss our configuration further in a PM, but it's a bit off-topic for this thread (which appears to have moved to a different venue).



Resua said:


> You couldn't execute code, and sample any particular sites data willingly.  Only random chunks from sites that had the specific features enabled.



As I understand it, the random chunks could have been from any site using CloudFlare to receive or deliver data. They would only have been exposed in output given to clients of sites using the specific features.

It would be nice to imagine that only sites using feature X were impacted by a bug in feature X, but reuse of uninitialized memory does not work that way. That is why CloudFlare said that if they found any leaks relating to the domains in the future, they'd let the owners know - if they _knew_ sites not using those features would not have had their data leaked, they'd have said that instead. I agree that the overall risk is small.


----------



## quoting_mungo (Feb 25, 2017)

Cloudflare did state (check the comments of their blog post) that DNS-only customers were not effected, so clearly there's SOME set of features that needs to be enabled in order to place a site into the adjacent memory that could potentially leak.


----------



## GreenReaper (Feb 25, 2017)

That's true - but that's because DNS is a separate and less-intrusive operation which doesn't involve handling data sent to/from you, and it's usually done on separate machines. Most people use CloudFlare for more than just handling their DNS resolution; and most of these other operations appear to have been implemented as in-process modules for the nginx server software.

Imagine CloudFlare is operating one of those snail-mail and package handling services - the sort where you can have a look at it beforehand and see if you want it forwarded. DNS would be the part where they update your address in various directories. Most of the time this will be to point to them, although they can make some domain names go to other addresses if you have specific requirements. On the DNS portion of the CloudFlare control panel, this is identified by going through the orange cloud, rather than going around a grey cloud. If it goes through the cloud, it gets sent to them, and opened up on their end.

Opening your mail, examining it, and then either responding directly or sealing it back up securely (maybe…) and sending it to you is the main part of their operations, and how they are able to provide features such as caching, filtering out bots, applying page rules, etc. It's why they need a copy of your SSL certificate and private key if you want a custom or EV cert: they have to act as your server in order to open the mail.

It's also why some people are nervous about using their service, because you don't know what's happening inside their warehouses or who's looking at the mail - in theory, they could serve a particular customer of yours anthrax on purpose. (Indeed, they might not even know, because they operate offices in multiple countries, each of which has its own form of legal interception and local staff who might be compromised.)

While copying out your mail in order to send it on to you, or you to others (the service works both ways, because otherwise they'd know your return address), they left a copy on the desk, because it was quicker than clearing it off. That's not normally a problem, because most instructions to their operatives are set precisely - the people they hired to do the work are _really_ dumb, so you have to tell them everything.

Unfortunately, the checklist for "obfuscate people's email addresses" didn't say to stop if they missed the end of the normal place to stop due to an error… so once they'd finished with the address, they started copying bits of _other people's_ leftover letters which had been left on the desk.

In this case, the same operative handles letters for a lot of people, all who've asked for different things to be done to them, so in terms of exposure it doesn't matter whether or not you were using that particular page-modification feature. If your letter was on their desk only so that it could be copied on without revealing your address, it's _still_ at risk of exposure; _your_ mail just won't end up containing _other_ people's letters.

It would be possible to have just one person doing one thing for one person - or at least, have them use a different desk for each operation, and only put a copy of your letter on the desk if that was being done. But that takes more time, and requires more people and desks, so it's more expensive than doing it all with one person on one desk. Most people don't want to pay for it unless they have to. Unfortunately, when accidents happen, that means you really don't really know who was impacted, because by now the letters are long gone - in fact, you only found out because some got pasted up on noticeboards and copied by other people.


----------



## Fallowfox (Feb 26, 2017)

I am surprised that anybody would use the same password on multiple platforms. You can just write all your login details in a real notepad and keep it in a drawer. Nobody can hack a book.


----------



## SSJ3Mewtwo (Feb 26, 2017)

Fallowfox said:


> I am surprised that anybody would use the same password on multiple platforms. You can just write all your login details in a real notepad and keep it in a drawer. Nobody can hack a book.



Bad advice.  A book can be stolen.

If you're going to say you keep it locked up:  Locks can be picked.  Most commercial locks are very quick and very easy to pick.

The best all-around option is to set your browser to not save your passwords, and use a password manager like Keepass.


----------



## Sergei Sóhomo (Feb 26, 2017)

SSJ3Mewtwo said:


> Bad advice.  A book can be stolen.
> 
> If you're going to say you keep it locked up:  Locks can be picked.  Most commercial locks are very quick and very easy to pick.
> 
> The best all-around option is to set your browser to not save your passwords, and use a password manager like Keepass.



I can actually vouch for a program like this, though I'd recommend Last Pass.


----------



## Fallowfox (Feb 26, 2017)

SSJ3Mewtwo said:


> Bad advice.  A book can be stolen.
> 
> If you're going to say you keep it locked up:  Locks can be picked.  Most commercial locks are very quick and very easy to pick.
> 
> The best all-around option is to set your browser to not save your passwords, and use a password manager like Keepass.



If somebody burgles me I think they'd be more interested in my laptop than my twitter account.


----------



## SSJ3Mewtwo (Feb 26, 2017)

If someone bungles you they'll grab the stuff that's readily grabable,  and if they feel they have the time before needing to book it, they'll search further for anything else, including popping open drawers and searching common hiding spots, or they'll just throw a ton of stuff in a bag and sort it later.

Can ya tell I watched a lot of the Discovery Channel show 'It Takes A Thief'?

Seriously, no, writing your passwords down on paper is a bad idea.  It's a big reason why it's forbidden in many organizations.


----------

