The Heart Still Bleeds
In 2014, CVE-2014-0160 happened, more commonly known as Heartbleed.
The vulnerability was exposed independently by a team of security engineers (Riku, Antti and Matti) at Codenomicon (acquired by Synopsys) and Neel Mehta of Google Security.
An attack of this kind is getting rarer by the day, but there are several thousands, if not hundreds of thousands of devices that are still vulnerable to this attack.
The scarier part is that it is, pardon the pun, silent, but deadly. It is not undetectable, as there are honeypots that are most likely deployed for this purpose, but it does require effort investigate.
To top it all off, it is one of the simpler exploits to do. If one fire up the Metasploit framework, it can be done in a couple of minutes. Here is the whole process, done from a Kali virtual machine against another virtual machine.
The Heartbleed
msfconsole
use auxiliary/scanner/ssl/openssl_heartbleed
set RHOSTS [victim’s IP address]
set RPORTS [victim’s port]
set VERBOSE true
run
The most common port to attack would be port 443, but other ports where the OpenSSL technology might be deployed can also be attacked as well.
After the script runs, something that may very well look like digital garbage will be thrown at you. You most likely got a 64 kilobytes chunk of data from one heartbeat that was revealed from memory. What does it look like? Here is a screenshot.
Why 64kb? Why the name Heartbleed? It all comes down to the Heartbeat extension featured in the TLS protocol. It is basically a nifty way of keeping the communication going between two entities without renegotiating the connection too often.
This tech was introduced into OpenSSL, but a bug was present. This enabled attackers to send an altered and malicious heartbeat with a small payload. Where the response from the server should have been limited to what it asked for through the heartbeat. A common representation for this is that a client ask a server for a short word, for example Alice. In a more technical and accurate wording, as presented by The Register because of a missing bounds check before a memcpy() call that uses non-sanitized user input as the length parameter. Thus, whatever that is in memory at the time of the heartbeat query to the server, is sent back to the client. It could in theory be anything, thus saying that it looks like garbage is often not too far fetched.
Send me this five-character word, if you are present: “Alice”.
The server would thus respond with the word “Alice”. Similarly, if one asked:
Send me this 300-character word, if you are present: “Alice”.
In this case, the server would have responded with “Alice”, in addition to the next 295 characters. From those leaked characters, up to 64kb, one could possibly find the password and personal information of Bob, and where he kept his picture of Lena on the server.
What the client is requesting is information from memory, and information from memory it gets, for as many requests as the client wants.
Heartbleed is not the most common thing to find anymore with big businesses with sufficient budgets to employ experts, thus the most of those devices that are still affected are most likely to be owned by those who cannot afford to know or those who simply would never even care to know.
Our responsibility
While being careful to call it a trend, many junior developers, something I consider myself as well, has been known to be relatively sloppy with security. When there are so many new technologies to explore, frameworks like React and Angular and the countless of packages sent to NPM every day, such a situation is not only understandable, it is expected.
Incomplete auditing of the code for bugs, despite being open source, caused Heartbleed.
One. Little. Mistake.
Regardless if one is a developer, entrepreneur or security specialist, the products we develop are affecting people; individuals with vulnerable sockets into their life known as services we provide.
For further reading I would recommend the following:
Rapid7
Bruce Schneider (Anything from Schneider is good)
Heartbleed.com