You would think that after several years, a well-known security vulnerability should no longer be found in production systems. It may, therefore, come as a surprise that famous Internet security issues such as the Heartbleed vulnerability linger on for many years after they have been fixed. Don’t believe us? See this Shodan report.
There are many reasons why old bugs die hard. Read on to learn more about Heartbleed and about some of the reasons why this bug and many others remain unfixed in so many systems.
The Story of Heartbleed
As with many serious security vulnerabilities, Heartbleed was not discovered right away. This security flaw was introduced into the 1.0.1 version of OpenSSL library back in 2012 together with the Heartbeat extension. Vulnerable versions of OpenSSL were OpenSSL 1.0.1 through 1.0.1f.
The vulnerability was exposed two years later (in April 2014) by security researchers from Google and an independent security firm called Codenomicon, and subsequently classified as CVE-2014-0160. For two years, the bug was a secret and we will probably never know if anyone ever took advantage of it then.
Heartbleed was fixed by developers of the OpenSSL software very quickly – within a week there was a release of OpenSSL 1.0.1g and all it required was just a software update for all affected servers. However, this was just one proof of how difficult it may be to update widely spread software – most implementations of TLS on the Internet used the OpenSSL library (luckily, not Microsoft), including Apache, nginx, as well as some devices from companies such as Cisco and Apple. The vulnerability also affected such sites as Yahoo.
How Heartbleed Works
To understand Heartbleed, we must first understand Heartbeat.
Heartbeat is an extension of the OpenSSL library. The OpenSSL library is an open-source project for implementing Transport Layer Security and Secure Sockets Layer (SSL/TLS) as well as DTLS. This library is used by most other software that requires TLS for secure communications, for example, web servers, mail servers, and more.
The Heartbeat extension was introduced to check if the TLS connection is still available. It’s a very simple mechanism: the client sends a special message called a heartbeat message to the server. This message contains data and specified its size. In response, the server is expected to send the same heartbeat request with the same data and the same data size. This mechanism was proposed in RFC 6520.
However, the developers made an error and did not introduce a check whether the size of the data specified in the Heartbeat message represents the actual amount of data. It turns out that in the original Heartbeat implementation, the client could declare any data size and the server would treat it as valid.
The vulnerability appears if the declared size exceeds the real data size. In such a case, the server sends back the message with extra information:
- Client request: 1 byte of real data, declared size: 200 bytes.
- Server response: 200 bytes of data (1 original byte + 199 bytes from adjacent memory), size: 200 bytes.
Similar to such vulnerabilities as buffer overflow, the attacker receives random memory content, which may, by pure chance, include personal information and/or sensitive information such as secret keys including private keys and symmetric encryption keys, SSL certificates, credit card numbers, etc.
Reasons Why Old Bugs Persist
The persistence of the Heartbleed bug is a good opportunity to analyze why old bugs are so hard to get rid of. Here are some common reasons:
- Vulnerable software is used in a hardware device. This is most probably the primary reason behind the number of results in the Shodan report mentioned at the start of this article. Many IoT devices use OpenSSL for TLS handling and such devices introduced between 2012 and 2014 would be vulnerable to Heartbleed. Some of them may not have firmware updates at all and in the case of others, the owners of the devices might choose not to do such updates.
- A company uses a customized version of vulnerable software. In the case of Heartbleed, OpenSSL is an open-source library and some companies might have modified it for their purposes. In such cases, a direct patch is not possible – the company must then reintroduce their custom code into the new version of the library. This is often the reason why web open-source software such as WordPress is not immediately updated by companies even if critical new bugs are found.
- Simple negligence – small companies might simply not even be aware that the software that they use needs a security update because not all software has auto-updates. If, for example, they hired an external company to set up a web server and then nobody administers it, they would not know anything about securing it.
- Risk assessment – some companies may decide that the risk of being hacked and the potential repercussions are not worth the trouble to apply a security update. It may be that, for example, the web asset has near-zero business importance, is not in any way connected to other assets, and carries no sensitive data at all.
- Work overload and priorities – if the company has a lot of software vulnerabilities to handle and a limited team to fix them, prioritization is necessary and some bugs may be put off for a long time just because they are not considered blockers. This is a reality that many web development companies face – new security bugs often exceed those that are fixed in a given timeframe.
All in all, the Heartbleed bug is an excellent example of why security scanning is just the tip of the iceberg and it must be paired with vulnerability management to guarantee IT security, whether it’s in the case of network security (such as with Heartbleed) of web security.
Get the latest content on web security
in your inbox each week.
THE AUTHOR
Principal Cybersecurity Writer
