Disclaimer: This post is for research and educational purposes only. I do not take any responsibility, in regards to the actions taken by readers of this article. Never attempt to hack a device for which you do not have the required permissions to do so.
The Heartbleed Bug is a serious vulnerability in the popular OpenSSL cryptographic software library. This flaw allows protected information to be stolen. Additionally, the bug allows anyone on the internet to read the memory of the systems protected by the vulnerable versions of the OpenSSL software. This compromises the secret keys used to identify the service providers and to encrypt the traffic, the names and passwords of the users and the actual content. Also it allows attackers to eavesdrop on communications, steal data directly from the services and users and to impersonate services and users.
As of July 11, 2019, Shodan reported that 91,063 devices were vulnerable. The U.S. was first with 21,258 (23%), the top 10 countries had 56,537 (62%), and the remaining countries had 34,526 (38%).
A bit about TLS/SSL
To check whether two computers are communicating with one another one of the computers will send an encrypted piece of data, called a heartbeat request, to the other. The second computer will reply back with the exact same encrypted piece of data, proving that the connection is still in place.
For example, if you’re YouTube video is paused, but you haven’t done anything in a while to load more information, your web browser may send a signal to the YouTube servers saying, “This is a 60 KB message you’re about to get. Repeat it all back to me.” When YouTube servers receive that message, they allocate a memory buffer — a region of physical memory where it can store information — that’s 60 KB long, based on the reported length of the heartbeat request. Next, it stores the encrypted data from the request into that memory buffer, then reads the data back out of it and sends it back to your web browser.
What was the flaw?
The Heartbleed vulnerability arose because OpenSSL’s implementation of the heartbeat functionality was missing a crucial safeguard: the computer that received the heartbeat request never checked to make sure the request was actually as long as it claimed to be. So if a request said it was 60 KB long but was actually only 30 KB, the receiving computer would set aside 60 KB of memory buffer, then store the 30 KB it actually received, then send back that 30 KB plus data from 30 KB of memory. That extra 30 KB of data is information that the attacker has now extracted from the web server
The coding mistake that caused Heartbleed can be traced to a single line of code:
memcpy(bp, pl, payload);
memcpy() is the command that copies data. bp is the place it’s copying it to, pl is where it’s being copied from, and payload is the length of the data being copied. The problem is that there’s never any attempt to check if the amount of data in pl is equal to the value given of payload. Whats funny is that OpenSSL is open source software. Anyone could look at the code, and presumably hundreds did, but nobody noticed the fairly basic code error.
How to fix it?
The way to fix the Heartbleed vulnerability is to upgrade to the latest version of OpenSSL. If you’re curious about the code that implements the fix, you can look at it:
* Read type and payload length first */
if (1 + 2 + 16 > s->s3->relent)
/* silently discard */
hbtype = *p++;
if (1 + 2 + payload + 16 > s->s3->rrec.length)
/* silently discard per RFC 6520 sec. 4 */
pl = p;
The first part of this code makes sure that the heartbeat request isn’t 0 KB, which can cause problems. The second part makes sure the request is actually as long as it says it is.