What is Heartbleed?
Heartbleed is the name that was given to a bug in OpenSSL. Do you remember Abhi’s article? This is one of the many implementations for securing Internet communications. The name Heartbleed comes from the OpenSSL functionality that causes the bug, Heartbeat. What this does, basically, is some kind of periodic “ping” between a server and a client, asking if the connection is still alive. Let me explain this with a little more depth.
How does Heartbeat work?
The objective of Heartbeat is to keep the SSL session alive after the negotiation of a handshake. Whatcha talkin' bout Willis?! Before a secure SSL session is established between a server and a client, they must negotiate a symmetric key (with which the communications will be encrypted). This key is sent with a handshake. The handshake is set up by the server, using the PKI and certificates. So the server sends its public key to the client, and then the symmetric key (which is client-generated) is shared securely according to whatever schema the server is using. After that, the server and the client use the same key for communications.
You can read the procedure, without many difficult words, here.
Obviously this key can’t be used for ages, because that weakens it. So rather than disposing of it every five minutes and having to renegotiate everything again, OpenSSL allows the client to send signals to the server, letting it know that he’s still using the session. When the client no longer sends these requests, the server forgets the key.
All this is a little more simple than it seems, and in SSLv3 it works like this:
- The client sends a 4 bytes TLS1_HB_REQUEST to the server. This request consists of 3 blocks: the type of request (2 bytes, the value is TLS1_HB_REQUEST), the length (1 byte, the value is 1 byte too) and the payload data (1 byte, and the value is 1 byte of random data).
- The server gets the request and saves payload data to memory.
- The server sends a 4 bytes TLS1_HB_RESPONSE to the client. This request consists of 3 blocks: the type of request (2 bytes, the value is TLS1_HB_RESPONSE), the length (1 byte, the value is 1 byte too) and the payload data (1 byte, and the value is 1 byte of data pulled from the memory, where it had saved it).
You see, it’s simple. To put it in everyday terms, we can imagine this:
Client: Hey there, server. Say these 10 words to me: alpha, bravo, vulnerable, server, subtle, undetectable, invisible, efficient, pwned, confidential.
Server: Sure, I just wrote them down in my notepad. Reading 10 words: alpha, bravo, vulnerable, server, subtle, undetectable, invisible, efficient, pwned, confidential.
How does Heartbleed work?
The vulnerability resides in the fact that OpenSSL doesn’t check if the length block corresponds to the actual length of the payload data block. So if the client sends a request in which the length is set to a value of 65535 bytes, and the value of the payload data block is 1 byte of random data, the server will send back a response with this byte, AND an extra of (more or less) 64K directly pulled from its memory.
Image from The Register. Check the article for the full details of the vuln.
To follow our previous analogy, we could imagine this:
Client: Hey there, server. Say these 10 words to me: alpha.
Server: Sure, I just wrote them down in my notepad. Reading 10 words: alpha, tomorrow, put, thousand, dollars, in, bank, account, 72937824, password.
Voil! The client just had access to the server’s “notepad”: the memory.
The OpenSSL versions that are affected by this bug are 1.0.1 and 1.0.2-beta, including 1.0.1f and 1.0.2-beta1.
Are 64K of data so much?
No, not really. In fact when you pull them from memory you get a LOT of garbage… but this is not a problem: you can do as many of these requests as you want. In fact, millions of computers from all around the world are making them all the time, so it is highly unlikely that a server logs this (well, now that the vulnerability has been disclosed, some do it; maybe you’re interested in setting up a honeypot). You have more options here.
Therefore, an attacker can do hundreds of thousands of requests to get different data from memory, and he will! This is because the memory addresses where things are stored are changing all the time (it’s funny because this was first done to avoid exploits), so each time a request is made, the attacker will get a different pull from memory.
What can an attacker obtain by exploiting this?
Pretty much everything. Not only can an attacker obtain the private keys of the server certificates, with which he would be able to impersonate the server (this means either changing links, requests, etc. during a MITM attack after the secure session is established –unlike SSLstrip attacks, which are done before; again, check Abhi’s article– or just creating a phishing/malicious
site that is secure, with a valid certificate) orsnoop on client-server communications, but also any login details of currently logged users and their actions, e-mails contents, banking ops, apps code,… all the “juicy” stuff.
What servers are affected?
Well… someone tested the top 10000 sites on April 8th. Check the list for yourself, but sites like StackOverflow, Flickr, Yahoo!, PHP.net, DuckDuckGo, HideMyAss, etc. were in the vulnerable list. Shodan can be used to find vulnerable servers that also “let the world know” about their vulnerability. According to this survey, about 2/3
of the(indexed) servers use OpenSSL.Obviously, not all of them have the vulnerable version, but since the vulnerability has been in thelatest versions of OpenSSL for about 2 years now… you can draw your own conclusions and estimates. If you want the official list of some popular affected sites, here it is.
But not only servers are affected. Also other hardware products. Also Android and Blackberry have vulnerabilities in certain versions of their OS.
It is highly likely that national infrastructures are also affected by the bug. However, you probably don’t even need Heartbleed to pwn these systems. Here’s to you, evil geniuses.
What you should do
If you’re a user
The first thing you need to do is check if a service you’re using is still vulnerable to this. While you can do it here, I highly recommend looking for an announcement in the service’s website (do not trust e-mails claiming that the vulnerability has been patched and providing a link to change your password - phishers have found a goldmine with this; check for announcements in the website itself, and if it has been solved, change the passwords from the website, as you normally would). Change all passwords only if the vulnerability has been patched. If it has not, you may want to contact the webmaster. Change passwords after the issue has been solved. Be careful if you’re doing this from a smartphone and you haven’t been issued an update yet if your OS or any apps you use are affected!
If you’re a webmaster
First, check if your services are vulnerable. You can do this in many ways:
- Script yourself. Check here.
- Check the processes.
lsof -n | grep ssl | grep DEL
If you are vulnerable, update OpenSSL (a patch has been issued). You can also do some kind of DIY patch with iptables:
iptables -t filter -A INPUT -p tcp --dport 443 -m u32 --u32 \ "52=0x18030000:0x1803FFFF" -j DROP
After you have patched the vulnerability in all affected services, you have to change all the keys, passwords, certificates and private keys, and basically any key that has anything to do with your server (yes, including disk encryption and service administration keys). If you published software with certificate pinning, reissue certificates.
When did this happen?
The Heartbeat feature was included in OpenSSL in 2012, and the author is Robin Seggelmann. The vulnerability was first internally disclosed on March 21st by Neel Mehta, a Google security researcher. Google patched their servers. OpenSSL wasn’t officially notified about the bug until April 1st (not a good prank). On April 2nd, someone at Codenomicon discovered the bug separately. Then on April 5th, OpenSSL published this and then took it down (someone mirror it!). Finally on April 7th, OpenSSL publishes the patch and a series of advisories, and the guys at Codenomicon publish the bug’s website.
You can check the full timeline here.
However, in 2 years, probably someone else discovered it before.
tl;dr
Ok, then try xkcd.
