Despite disclosure of the highly publicized Heartbleed OpenSSL vulnerability three years ago, some companies have yet to remediate this vulnerability. Why?
It’s hard to believe that it’s already been three years since the Heartbleed vulnerability (CVE-2014-0160) was announced, and five years since it was accidentally added to OpenSSL’s line of heartbeat code. While the Heartbleed exploit was an accidental product of the underfunded and understaffed OpenSSL team, it turned out to be what some have called a “catastrophic flaw” or “one of the biggest flaws in the Internet’s history.”
Even harder to believe is that three years later, many servers and devices are still affected by the Heartbleed vulnerability. According to a January 2017 report by Shodan, about 200,000 devices and servers are still vulnerable to this OpenSSL vulnerability.
Despite the seriousness of the Heartbleed vulnerability, the Heartbleed Bug website mentions one silver lining: that this well-publicized vulnerability would motivate companies to maintain their software and become vigilant against future attacks. However, in the intervening three years many companies have yet to remediate the vulnerability, either because they rely on outdated software or are unaware of the issue in their code.
While larger corporations and affected companies remember the Heartbleed bug as one of the largest flaws in the Internet’s history, other companies may not have understood how it might impact them or weren’t seeking out that type of vulnerability information. It’s hard to know you have a problem when you don’t know where to look or if it even exists!
While I originally found understanding a serious OpenSSL vulnerability like Heartbleed daunting, I learned a lot while writing this post. Below is a basic overview based on my research.
OpenSSL (a.k.a. TLS) is a security and encryption technology used by many (many) developers. It allows encryption to occur when information is being passed between a computer and its server. This means that if you create a username and password, it is sent to and stored on the server. While your private information is being sent to the server, OpenSSL essentially disguises (or encrypts) it. As a result, your password remains secure.
One aspect of OpenSSL (and other security technologies) that ensures the server and computer are always connected is called ‘heartbeat.’ This heartbeat is added to code to keep tabs on how connected the server is to the computer. It sends a request to the server periodically for some basic information to be sent back. This informs the computer that the server is listening and the connection is successful.
An example: The computer asks the server to send the word ‘bird’ back in four characters (because that’s how many letters are in the word bird). If the server is successfully connected and operating correctly, it sends the computer the word ‘bird.’ These small tests allow the connection between the computer and server to remain strong.
As you may surmise, the Heartbleed vulnerability was found in the heartbeat’s line of code. The accident that occurred was that there was (basically) no character limit on the amount of information the server sent back during the heartbeat tests. This was disastrous, because a hacker could use the heartbeat request to ask the server for the word ‘bird’ in 500 characters (far more than the four characters necessary to spell bird). The server then sends the word ‘bird’ as well as the last 496 characters the server held in recent memory. Essentially, if you recently typed in your password to your email or Facebook account, it would be sent in the message from the server. (Visual learners should check out this xkcd comic.)
Some people believed that the bug was not a huge deal because you could only get 64 kilobytes from the Heartbleed method. But hackers could execute this attack easily and repeatedly—making it simple to exploit. Not only that, the Heartbleed bug is completely untraceable.
Remediating the vulnerability seems fairly simple. The patch essentially ignores Heartbeat Request messages that ask for more data than their payload needs. According to the Wikipedia article:
Version 1.0.1g of OpenSSL adds some bounds checks to prevent the buffer over-read. For example, the following test was introduced to determine whether a heartbeat request would trigger Heartbleed; it silently discards malicious requests.
if (1 + 2 + payload + 16 > s->s3->rrec.length) return 0; /* silently discard per RFC 6520 sec. 4 */
With this basic understanding of the Heartbleed vulnerability, it is baffling that about 200,000 devices and servers are still affected by this flaw. The number of affected devices is decreasing over time: “[The] 11 percent [vulnerable to Heartbleed] is a number that is likely to dip into the single digits.” If you are not sure whether a website (or your own website) is affected by this OpenSSL vulnerability, you can do a quick Heartbleed test to check if you have any vulnerabilities.