Sophos Cloud Optix
The “heartbleed” bug in OpenSSL has caused a right kerfuffle.
I shan’t re-visit the bug in detail (here’s a full explanation), but this is typically what happens:
- Malicious person makes an encrypted (TLS) connection to your server.
- Malicious person sends what’s called a heartbeat request, instead of real data, to tell your server to keep the connection alive.
- Malicious person sends a only few bytes in the request, but claims he sent you 65535 bytes.
The heartbeat system is supposed to work by copying the incoming request data into a reply packet, and sending it back so the other end can see that the connection is working correctly.
But buggy versions of OpenSSL reply like this:
- Copy 65535 bytes into the reply, starting at the bytes of data in the incoming request, but overflowing the input buffer.
- Send back all 65535 bytes, including the original request data plus whatever happens to be nearby in RAM on your server.
→ The value 65535 is the biggest number (hexadecimal 0xFFFF) you can represent in 16 bits, or two bytes, which is the size allocated for the request length field in the TLS heartbeat protocol. Remember the old 64KB limit? Here it is, all over again.
This is a buffer overflow, but not the sort you’re probably used to.
Instead of sending too much data, to trick the other end into crashing and executing your data as code, you send too little data and trick the other end into making up for the missing data by leaking some of its own.
And ever since news of the bug went public, intrepid (inquisitive? insatiable? incorrigible?) researchers have been hammering on web servers all over the world, sending “heartbleed” packets and monitoring, 64KB at a time, just how interesting that leaked data seems to be.
As you can imagine, a lot of it is very dull, but you can keep on “heartbleeding” a vulnerable server until exciting data fragments turn up.
Indeed, researchers claim to have found all sorts of stuff they shouldn’t have seen, such as usernames, passwords, server encryption keys, and more.
So although your passwords probably weren’t exposed because of this bug, they possibly were, in just the same way that although you didn’t win the lottery this week, someone did.
That means that some writers are urging you to change all your passwords, just in case.
The argument is, “Why not?”
After all, if you swiped your credit card in a payment machine that you later felt uneasy about, you’d probably consider cancelling the card and asking your bank for a new one, without waiting to see if fraudulent transactions appeared.
Changing your online passwords is trivial in comparison, the argument goes, so it makes even more sense from a proactive point of view.
However, there is one important reason why you might not want to rush out and change all your passwords on all your services right this minute, and it’s a sort-of Catch-22.
If you need to change your password on a server that is at risk due to heartbleed, then the new password you choose may be at risk due to heartbleed.
And it’s fair to say that there are a lot more people ready to heartbleed your new password right now than there were a week, a month or a year ago when you set the old password up.
We suggest you wait until you know that a site is not vulnerable, for example because it makes a clear statement to that effect, or use a public testing service that connects to a website to estimate whether it’s safe or not first.
→ Note that remotely testing a website for “heartbleed” (or testing an email server, or any application than accepts TLS or HTTPS connections) can’t give a complete answer. The servers operated by a company that uses Microsoft IIS, for example, won’t be vulnerable. But if the company also outsources the operation of mirror servers to a third party, those mirrors might be affected. So you could be at risk some of the time, but not all of it, depending on which server is chosen each time you visit.
In short: by all means get ready to change all your passwords.
But avoid changing them until you have a good reason to think that the services protected by those passwords do not have the heartbleed vulnerability.
Also, consider adopting Two Factor Authentication (2FA) wherever you can.
2FA systems generally use a sequence of one-time codes to make stolen passwords much less useful to cybercrooks.
Here’s why…
Listen now:
Listen later:
But your Passwords are only at risk, if you have ever used that service within the time the server was vulnerable to heartbleed. As if you dont enter your password and send it via SSL to the server it will not show up in the RAM buffer of the SSL- lib. With heartbleed you only can gain data that is/was in process by openSSL recently.
So if you didnt used that service for the last 2 years your password is still safe as more than 2 years ago this bug didnt existed yet, and since youve never used the service in its vulnerable time. your password was never in the SSL-RAM-Buffers.
*Probably wasn’t.
It’s extremely unlikely, but if that bit or RAM didn’t get written over, it *might* still be in there, Chances of that are infinitesimally small though 😉
Small, but not infitesimally small.
Some people are reporting that by setting up a test server and hammering away it it with heatbeats, they’ve seen interesting things turn up…including a copy of the text of the server’s public key PEM file.
(The server needs to read the PEM text into memory at some point to decode it into binary to use for encryption. There are techniques to keep it shrouded most of the time, but OpenSSL doesn’t seem to use any of them.)
The text “—–BEGIN RSA PRIVATE KEY—–“…
…is bit of a giveaway 🙂
True, but if you haven’t used an account for 2 years it is well past due for a password change anyway. Just make sure the site isn’t vulnerable and has issued new SSL certs before you do it.
“Changing your online passwords is trivial in comparison, the argument goes” I have approx 300 passwords in Lastpass. I don’t know whose argument that is, don’t know which sites *were* vulnerable and will have to check which websites *are* (no longer) vulnerable. So the person using that argument should think again.
That will mean that I will have to change all the 500 passwords in Sticky Password manager I have .. uh oh 🙂
Using LastPass run their Security CHeck and they’ll check all your stored passwords and let you know which ones are for sites with updated certs and should now be changed. A real nice feature they added in response to HB.
Here is an update to my previous comment: If you are a paid Lastpass customer, Lastpass has just added new content to their ‘Security check’ to check for HeartBleed affected/mitigated sites.
I still feel your pain about the idea that it’s kind of easy to change all your passwords, just because 🙂
The irony is that “just doing it” could cause you to expose a new password when the old one was actually still safe.
Its also available to free users
There are two reasons I like to follow Paul Ducklin. 1. He manages to make things easy for me to understand. 2. Where else could you get a writer who uses “shan’t” or “kerfuffle”?
There’s another reason to follow Duck: he probably knows more about computer security than anyone else on Planet Earth. This is, after all, the man who invented the EICAR test virus.
To be strictly correct: I wrote the original what-why-how document to go with the EICAR test file, as you will see if you visit the EICAR website.
But the overall “project” (see my description) to create a test file, which was to avoid the hassle of every vendor having a different pseudovirus, was a team effort. From memory, most of the coding was done by a chap called Frans Veldman, based on an idea by another chap called Padgett Peterson.
So the EICAR test file was not so much invented by anyone as born of necessity in a co-operative effort.
Is changing passwords the best advice we can give? We have long known passwords are dead as a viable security technology. Rather than tell everyone to change their passwords – why not suggest upgrading to two-step verification or two-factor authentication instead? It’s almost as easy, and takes just about as long as changing your password to set up on most sites.
It may not 100% solve the issue, but it significantly reduces the issue
(Great podcasts by the way Paul).
I already have 2-step authentication in Gmail, so I’m wondering if I still need to change my Gmail password? And will have have to re-do the setups on all the devices and software that have been given tokens or one-time passwords when I set up 2-step authentication in the first place?
Hmmm…tricky question to answer 🙂 There’s some discussion of the issues here:
http://nakedsecurity.sophos.com/2014/04/12/heartbleed-would-2fa-have-helped/
If you’re using the sort of 2FA offered by the Google Authenticator software, then it relies on a single cryptographic secret (a “seed”) stored both by Google any your mobile device. If someone knows the seed (think of it as a master password) for your account they can program their own copy of Google Authenticator to generate your 2FA codes.
It’s reasonable to assume that those seeds are *not* stored on the web servers themselves and would never be in memory where OpenSSL could accidentally find them, but only Google can say that for sure.
So you have three choices:
1. Assume it doesn’t matter.
2. Ask Google support.
3. Re-establish your 2FA anyway.
As explained in the abovementioned article, if you are using SMS-based 2FA you are almost certainly OK because the SMS login codes are almost certainly not a “seeded” cryptographic sequence, but just random numbers. You just have to send the right digits back each time.
I’m looking for a quick way to check the Sophos UTM (OpenSSL module) version. Does UTM have the heartbleed vulnerability.
It did have a buggy version of OpenSSL, but there are patches out…details here:
http://www.sophos.com/en-us/support/knowledgebase/120854.aspx
Please update your information regarding Canadian banks. I have 2FA authentication on all my online banking, especially if I only have a credit card with a financial institution. I’m surprised you wouldn’t know this.
The only Canadian bank I can find that offers 2FA for consumers is HSBC and from what I can tell the tokens are of exceptionally low quality and break easily. This blog sums things up pretty well: http://robertmccarter.com/canadian-banking-password-policies/ . Scotia, RBC, TD and CIBC offer what they call “multi factor”, which is a load of crap. Knowledge questions are just as easily phished or keylogged as passwords. It appears RBC offers proper 2FA to business customers.
Another concern I have about logging into sites is the request to login through a social media site. I won’t link anything to FB for example. In light of this new virus, why would I use a possibly infected site to login to another one?
If I understand correctly, “Heartbleed” only affects applications that use TLS. (If I’ve got that wrong, please ignore the rest of this comment.) Web sites sites accessed via “https://…” will not be using TLS. So if you only ever access facebook, Gmail, etc using HTTPS, and don’t use IMAP or POP3 with TLS to access your email, what’s the problem?
That’s not right JeremyB, web sites accessed via “https://” do generally use TLS now. TLS is a replacement for the older SSL technology. Heartbleed did affect web servers such as Apache and Nginx.
You can think of TLS as “the more recent versions of the SSL protocol” – a sort of SSL++, if you like.
So there was SSL 1, 2 and 3. But insted of SSL 4, we got TLS 1, then TLS 1.1 and TLS 1.2.
The name/version switch was because TLS 1 was derived from, and similar to, SSL 3 but not directly backward compatible with it.
These days, I suspect that most browsers will ask for, and most servers will oblige with, a TLS connection when you visit an HTTPS address.
Think of it like this: the S in HTTPS stands for “secure,” and “secure” means “uses SSL or TLS, whichever it is that both ends agree upon.”
And think of the product “OpenSSL” as “OpenSSL/TLS.”
“But avoid changing them until you have a good reason to think that the services protected by those passwords do not have the heartbleed vulnerability”
I don’t buy it. I know what Paul means, but could potentially mean NOT changing your password for a site that WAS patched, meaning someone MIGHT still have your password so can get in. It’s hard to know which is the greater risk- not changing thereby leaving your old password in place, or changing and risking having your new credentials.
There were half a million affected sites! I’m not checking all of them. I’m going to change my passwords now, then maybe do it once a week for a while. Yes, there’s a risk that my new passwords will get intercepted from an unpatched server, but there was a 2-year window when my details might have been captured- that’s a long time if you can automate collection.
My point is this: if a site is vulnerable now, it was almost certainly vulnerable last week, probably last month, possibly last year. So don’t bother changing your password yet; wait until the site is patched, which should be Real Soon Now, and then change it.
Your point, I think, is: change now, but don’t treat it as a real change of password, just change it as a sort of “moving target” precaution. Then change it properly once the site is really is sorted out.
Depends whether you think the risk of your password being grabbed now, thanks to the “heartbleeding frenzy” that seems to be happening, is higher than before.
I have no data to back this up…but if you’re willing to assume the NSA definitely had your password already, it seems that by changing now these are your only outcomes:
1. Pwned by NSA -> Pwned by NSA again.
2. Pwned by NSA -> Pwned by NSA again, plus by Honest Jim and H4XXOR42.
3. Pwned by NSA -> Pwned by Honest Jim and H4XXOR42.
4. Pwned by NSA -> Unpwned.
One outcome is better (4). One is the same (1). One is no better (3), and one is definitely worse (2).
So I guess you are gambling, amongst other things, that the probability of outcome 4 is > 50%.
Do you feel lucky? Well, do you 🙂
I like the Clint Eastwood quote–nice touch!