8 Common Pitfalls of Heartbleed Identification and Remediation (CVE-2014-0160)

Unfortunately, one of the biggest vulnerabilities disclosed this year, Heartbleed, has been inefficiently addressed and for some, already forgotten about. Plenty of details about the vulnerability already exist including our FAQ and releases covering the vulnerability for Trustkeeper, Trustwave WAF and our other products. In this post, however, I will focus on correcting some misconceptions related to Heartbleed.

The reason for this somewhat dated discussion is recent reports showing that approximately half of the services vulnerable to Heartbleed have yet to be patched. Be it negligence, apathy or perhaps miscommunication, such a report shows that a considerable amount of administrators are not taking the responsibility of managing Internet-facing services as seriously as I would like. Below I correct eight misconceptions related to Heartbleed that I suspect may be to blame for the lack of patching and/or identification of the Heartbleed vulnerability.

1. Web servers are not the only services affected. Any service that utilizes the vulnerable version of OpenSSL with TLS heartbeat for encrypted communication could be affected. This would include SSH, email and many other protocols. Upgrades to address this do not always stop with updating Apache, or a web server.
2. Don't forget STARTTLS. Some "plaintext" protocols may be affected because they support an option to switch to TLS or secure communication. When that switch is made, the service may use an insecure version of the OpenSSL library. Most Proofs of Concept (PoC) code available supports STARTTLS for SMTP, POP and IMAP. Did you know XMPP, FTP, LDAP and many other protocols support STARTTLS as well?
3. HeartBleed affects more than TLS version 1.1. The many PoCs available are valid, but incomplete. The majority of these PoCs were hard coded to only attempt TLS version 1.1. A vulnerable service that only supported TLS version 1.0 would not respond using those PoCs to exploit and would result in a false negative.
4. The vulnerability can lead to more than the leaking of passwords and secret keys. This vulnerability gives an attacker access to a portion of the server's memory stack. This means that a surprising amount of data is exposed to whomever is initiating the attack. Depending on the target, it may include email contents, credit card information from customers, or effectively any bit of data the server exchanges.
5. CVSS scores the vulnerability as a medium risk, but depending, it could be much more dangerous. If passwords or secret keys are exposed in the memory dump. Then that would allow an attacker to potentially compromise the host, which would make this a critical vulnerability.
6. Applications, not just servers, are affected. Although rare, some applications that are compiled to utilize the vulnerable versions of OpenSSL are also vulnerable to this attack. It requires having the vulnerable client communicate with a malicious server, so it is much lower risk. But, if you have an application that uses these libraries, they too could be vulnerable to Heartbleed. It is important to update the OpenSSL libraries in the app in your next release cycle (or as soon as is reasonable.)
7. It takes more than "apt-get update openssl" to fix. If you or your admin team have only upgraded the OpenSSL libraries on a server to addresses this problem, you may need to perform some additional work. Many services that utilize OpenSSL build-in the libraries during compile time. If you had a vulnerable Apache HTTP server for example and only upgraded the OpenSSL libraries on the server, you may still have a vulnerable Apache HTTP server running. You would need to re-compile the Apache HTTP server as well, so it can build itself using the secure version of the OpenSSL libraries. That is unless you had the fore-sight to use dynamic loading of these libraries, which would allow OpenSSL to be upgraded and Apache or any other service to use these upgraded libraries immediately.
8. Not all Heartbleed tests are created equal. Relying on a free web-based tool or an early proof-of-concept is not enough. A free tool might be good to check a website, for instance our free HTTPS-only test available here, or to start a conversation internally, but they are limited. For example, free tools may only check HTTPS, have limited STARTTLS support, or attempt to talk to the wrong TLS version. True vulnerability scanning services, such as our own Trustwave Vulnerability Management, ensures tests are accurate and comprehensively cover vulnerabilities when they are released.

I hope this brief explanation helps you understand some of the nuances of Heartbleed. Remember, there is a fix for this vulnerability so there is no excuse to continue being vulnerable. When severe vulnerabilities are reported, it requires everyone to address the security flaw individually, and it reflects poorly on the overall safety and security of the Internet when vulnerabilities like this are not addressed quickly everywhere. Until such a day comes when all providers (big and small) are able to quickly address severe vulnerabilities when they are disclosed, the Internet will continue to be a place where malicious actors thrive.