This is a rant. It’s a long one. I’ve not proof-read it much, there’ll be mistakes.
Opening
So, unless you’ve been hiding under a rock of late, you’ve heard about Heartbleed. Heartbleed is a bug in one of the core programs used in the open-source world to keep secret those things you need, like credit card details. This particular bug is important, because it can leak information that shouldn’t be leaked, like credit card details. Just click the link above, it gives a really good basic idea as to how it works. It mainly affects those things protected by SSL.
So, now that everyone knows what it is, why is it important? The information leaked can be anything that the computer (hence -forth called “server”) responsible for keeping the website involved on the internet has in it’s memory. That can include, requests for websites, file transfers, emails, ssl certiticates, ssl keys, credit card numbers and passwords.
Passwords, memory and maths
Now that last one, that’s the one the media, and certain people, have been shouting about. This bug has the small potential to leak passwords. However, this is totally not as serious as it sounds. Passwords are only kept in plain text for a short time – normally, as long as it takes to hash them (one-way-encrypt), and check them against a database. So, your passwords aren’t sitting out in the open, for anyone to steal. Additionally, you have to have entered your password within a second (or two at the latest) of someone using this bug to pull information from a server. As problematic as this bug is, it’s limited. It lets you get 64 kilobytes of information from the server memory. That sounds a lot, till you remember that modern servers have up to 16,777,216 kilobytes, or 262,144 blocks of 64KB. Even servers a few years old (and in server terms, that can be really quite old) have 4,194,304 kilobytes, or 65,536 blocks of 64KB. So, someone has to have managed to use this bug, to grab exactly that block at the right time, to get your password. Also, trust me, we would notice if someone started reading that much information out of our servers constantly. It would be obvious something was wrong. Additionally, not every server is vulnerable to this weakness. Those running IIS, or an older (but still patched) version of operating systems used to host websites remain safe. It’s something like 2/3rds of sites, and crucially, only those 2/3rds of servers setup for SSL.
So, why all the “RESET ALL YOUR PASSWORDS!” screaming? There is a small chance of grabbing an SSL key. Now, due to the way this bug works, this is more likely than other things to have happened. Why is the key important? It’s the set of random numbers that says you ‘own’ a certificate. So in theory, it can be exposed. Why is this a problem? With the key, you can pretend to be the person for whom it was created — if you got google.com’s key, you could pretend to be google.com. Now, this *still* isn’t that easy to use, you basically have to perform a Man In The Middle attack, which is hard, and complex, and will only get you really limited information, depending where you can do it.
No, this is not as serious as it sounds
So, why have I been tweeting lots saying you shouldn’t rush out to reset all your passwords? Three reasons. The first; the likelihood of anyone actually getting your password is really, really really small. Remember, there’s that (at best) 65,536 places your password could be, and only 2 seconds to find it before it vanishes. Per affected website. Add that to the fact that these bugs are hard to find, and using them to get information is hard. Using them to get useful information is also hard – all the bug comes back with is a load of data you have to run through conversion routines to get anything out of. Additionally, due to the way this data is stored, there’s no guarantee it’ll be easy to match your password to your username, which is crucial if you don’t want to have to guess usernames.
My second reason is one of worry about the affect telling those who aren’t used to strong password security will have. You’re going to be telling people to dump every single one of their current passwords and start again. It’s already really bad – the top 2 passwords of last year were “123456” and “password”. So, though I have no studies on this, I would bet, with hard cash, that forcing those not using good passwords to reset their passwords with fear, will weaken passwords as a whole. I suspect that we’ll find a lot more weak passwords, and a lot more passwords shared amongst websites in the next few batches of password leaks.
Finally, my third reason. Evidence. We’ve had no evidence of large scale, source-less password leaks recently. Hackers, especially some of the nicer ones have a habit of dumping their finds publicly, and a large-scale capture of passwords would show up in activity around the internet. Additionally, passwords aren’t the only thing heartbleed can expose. It can expose credit card numbers. And the credit card companies do not like sites to whom they’re traced back a hack. In fact, they have a habit of forcing said companies to go through a rigorous, lengthy, and painful auditing process, to find out exactly *how* the passwords leaked. The security community would have heard of these audits turning up nothing, of credit card data vanishing out in any significant quantity, or even the audits would have thrown up the bug.
Media
So, this password thing. It’s being pushed by the media, and by the guys who created the ‘heartbleed’ website as a much bigger impacting issue than it really is. Now that the bug is out in the open, script-kiddies will start using the heartbleed website, as will advanced state agencies. I’ve heard some rumours of people seeing internet-wide scans originating from state agencies, shortly after the bug was announced. So, it’s important that it’s patched quickly, it’s a big problem for the tech community, but with the low chance of password exposure, it’s not that important. So, why are the media saying “CHANGE ALL YOUR PASSWORDS”. Two reasons mainly, first is that’s a far better headline than “There was a bug. We’ve fixed it.” The second, is that that’s the response we, the hosting & security community, have ingrained as ‘the’ response to any sort of compromise. Yahoo got hacked? Change your passwords. last.fm got hacked? Change your passwords. So, when they hear about this hack, which they do not understand, they fall back on the thing they know, and since this bug affects ~60-70% of ssl protected servers, they think “ALL” instead of just a limited set.
Responsible Disclosure – how not to do it
In my opinion, the heartbleed release is a perfect example of how NOT to do responsible disclosure, no matter what certain lucky parties claim. First, create a website with inflammatory content. Then, get those who have insider access to patch. But crucially, don’t inform operating systems before you make it public. Don’t let anyone know in the security teams of Ubuntu, Debian, RedHat or SUSE. You know, just the people who actually have to *create* and *deploy* the patch to the millions of affected servers. Don’t let big publishers or sites know (Yahoo, BBC, Facebook). Instead, publish your site, and wait for the shitstorm to hit, as the media companies take this up, shout about it, and make customers scared. Now, in a boon, the debian OpenSSL team got a patch out for this bug, 30 minutes after they had a bug report. But they didn’t have a bug report when heartbleed went public. No, the bug was reported hours later, after the viral-news effect had got around to someone who knew where and how to report a bug in debian’s bug tracking system.
Other, big bugs
You know, there’s a package that runs a good 22% of the internet. In the past week, they published a really critical bug, one that allows remote authenticated access to their sites. This package? WordPress. The bug will allow an attacker to gain administrative-level access to any wordpress site. In actual damage terms, this bug will cause me far, far, far more grief, and likely our customers, than the heartbleed ever will. Heartbleed was patched out in our network in the space of a few hours, with some minor services taking maybe a day or so. If we’re not running a vulnerable version of WordPress on our network, this time next year, I’ll eat my hat. If some clever black-hat hasn’t written an automatic compromise bot, to exploit this within the next few months, I’d be very surprised.
Another package that had a critical security patch in the past week? Just an addon to wordpress, that a good proportion of wordpress sites also use; Jetpack. They found that they had another remote-access, post, and privilege escalation bug in their code. Again, this single bug will cause us far more trouble in the long term, simply because people won’t upgrade.
Other, easier ways of loosing your password
Every now and then, someone’s website gets hacked, crap gets uploaded. We trace it back to their computer, using their login details. What happened? Though we’ve never been able to say with 100% certainty, they were probably infected with a keylogging virus, that saw them typing in their (s)ftp login details, and which automatically used said details to deface their site. That has become less common in the last year, but it was almost a weekly occurrence only last year. How did the keylogger get installed? Simple, our customers either didn’t have anti-virus, weren’t maintaining it, or actively ignored it’s alerts. They click on links in emails they’re not expecting, open files in emails they’re not expecting, and get infected. Just this week, something has been quite determined to infect me – sending me ‘delivery notes’, asking me to ‘print a zip file’. The ‘zip’ file was a Microsoft Excel .xls file, and likely not an xls file, but something quite nasty.
Internet cafes. Ever used one to pick up your email? There’s a good chance that someone knows your email account password — those computers often have keyloggers installed, or have someone on the same network watching the net traffic, or intercepting it. Use that same password on paypal? Oh well, say goodbye to your money. Ever used a public wifi connection? You know, one of those unencrypted ones on your iPhone? Your iPhone logs into your email accounts without encryption? Say goodbye to your username and password.
In closing
Is heartbeat serious? For webhosts, yes. For users, in the brief period after heartbleed.com went live, till our servers were patched? Yes. Now? Not really. It could have been a lot better, and it could have been a lot worse. Hopefully, this will give the OpenSSL guys more resources to stop any future bug like this slipping through the net. Do you need to reset your passwords? Only if you connected to a vulnerable https:// site, in the brief period that the bug was around. Better would just to watch your bank statements, something you should be doing anyway. Use 2-factor authentication if you can. Use a password manager, my favourite is Keepass, with it’s database stored on Dropbox, and a key file stored elsewhere. Use separate passwords for every site, and don’t try to remember them, just auto-generate them using keepass’s algorithms.
Nice rant, there! 😉
Excellent comment on the issue. The knee jerk response by the media was worse than the problem itself – with big-name trusted brands like the BBC writing articles titled ‘change all your passwords’ etc.
The only issue was right at the end, you qualified the problem as ‘a brief period’. Yes, the public knowledge period was brief, but the flaw went unnoticed in the wild for two years. It took so long to be found because it was a passive glitch that left no trace of any issue.
@Optmaximal: I think that was in reference to the brief periods that unencrypted queries where residing in the server’s memory.
*were, not ‘where’, sorry.
I’ve re-read it. My last response was wrong.
Nice and I mostly agree with you especially the panic & media reporting. Websites should however update their SSL certs if they are in a position of responsibility and were vulnerable it’s cheap and is probably for the best. There is a tiny risk they could have been compromised especially post apache restart. I particular like this approach from Cloudflare which was “prove us wrong but we think this isn’t so bad”: https://www.cloudflarechallenge.com/heartbleed. Yes they got proven wrong, a few people recovered the private keys. On the other hand those people performed determined attacks against the platform to do so; attacks that broke the server leading to an apache restart that cloudflare thinks aided the eventual compromise.
The only other thing is this:
“However, this is totally not as serious as it sounds. Passwords are only kept in plain text for a short time – normally, as long as it takes to hash them (one-way-encrypt), and check them against a database”
You’re right, but it’s a bit of an ideal world scenario. It depends on the technology underlying the system (PHP, Java, whether or not it’s PHP & Zend, whether or not they rolled their own auth systems and input validators). For example many input validators in Zend keep a copy of the input they were validating (e.g. password, credit card number) so say dumbass website x only allows certain characters in their password. They instantiate an input filter on the form element to check this; that validator will have the password as submitted and held in ram even after the form is done with unless good practices are followed. Now assuming enough people are logging into the site you simply need one thing on your hands to hit paydirt… time, perhaps a lot of it. Though the form may be sanitised unless the validators are nulled or the form is the memory holding that password remains. This is all good coding practice especially were any secure or personally identifiable information is held. However we all know from bitter experience that good coding practice is not always followed.
So, it’s a minority of sites we hope that will have such failings in their code but that is not to say such sites do not exist. However a minority of that minority will be sites of any note and worth of such concerted effort to break into (for the lulz). As we can see from the cloudflare experiment you need a lot of requests crafted in this way to hit the big time and steal the ssl keys, and that appeared to rely on apache being graceful’d or restarted.
In conclusion, yes over reported and misreported. The attack was surprisingly easy to perform, however the site you targeted needed more than a failing in OpenSSL in order for other sensitive information to be stolen. Private keys however, they were up for grabs in limited scenarios. Interestingly though assuming the density of attack required leads to the stuttering of the apache server a sysadmin restarting it in an attempt to fix the problem could be aiding the attackers. Still I find it good that a number of firms have renewed their SSL.
For myself, I’ve changed the odd password, Yahoo/Flickr in particular. There is nothing wrong with a bit of paranoia, mass hysteria though? That’s always bad.
Oh and just to add, totally agree with you re: “Responsible Disclosure – how not to do it”. It’s the worst example of disclosure I’ve seen in years, it was disclosure for publicity and fame not security. When a colleague showed me it at work my responses were:
“Hahaha, no that’s just a joke fuck off.”
“Is it April 1st?”
“No it can’t be as bad as they are reporting, if it was why would you take the time to make a pretty little website about it?”
SSH to server, run some tests, “Oh, well the bug does exist but there’s no way I’m going to see if it’s truly exploitable.”
Then I found the small notes on openssl.org saying that yes, in fact, the bug was real. OpenSSL’s website I trust, some random site on the internet with a catchy name; sorry no.