Security heartache: OpenSSL Heartbleed

On April 7th, a major vulnerability in OpenSSL, the most prevalent software used for encryption and other purposes on the web and the internet was discovered. Here are details about what it is, how it affects everyone, and what needs to be done.

SSL, known as the secure socket layer, is the preferred protocol used for encryption. OpenSSL is its most common and open-source implementation. Websites that use encryption, payment gateways, VPNs, apps — including mobile apps, all use SSL and a large majority of them use OpenSSL. The two most common web servers Apache and Nginx, which comprise more than 60% of web servers on the internet use OpenSSL when they use the HTTPS (that is the encrypted version) version of HTTP. Most operating systems use OpenSSL for various modules, so these modules are also affected.

What is Heartbleed Vulnerability?

This vulnerability was discovered by three researchers — Neel Mehta from Google and two others. What this vulnerability does is allow a malicious user to steal sensitive information such as private keys, passwords, etc. The vulnerability is present in a module of OpenSSL called TLS heartbeat extension which is used to generate heartbeat messages. Hence the name Heartbleed for this vulnerability. This heartbeat handshake is usually done during the negotiation time of the SSL protocol and much before HTTPS takes over, in case SSL is used under HTTPS. Thus, the vulnerability is not present in layer 7 but rather at layer 4. As such, signatures to block this vulnerability if any – and none are available as per this time as per our information — have to be in the IDS / IPS and not in the WAF.

Which versions of OpenSSL are affected by this vulnerability?

This vulnerability affects OpenSSL versions 1.0.1 to 1.0.1f and version 1.0.2-beta, 1.0.2-beta1. Earlier versions such as the 0.9.x versions or 1.0.0 are not affected. In fact, the heartbeat feature was introduced by OpenSSL in 1.0.1 itself and was not available in earlier versions. However, earlier versions may be vulnerable to other vulnerabilities such as the BEAST vulnerability so be careful to check for those, if you intend to go back to an earlier version to fix this vulnerability.

Which software is affected and which is not?

The vulnerability is in a module called the TLS heartbeat extension of OpenSSL. As such, software using OpenSSL which uses this extension is affected. This includes web servers using HTTPS such as Apache, Nginx, VPNs such as OpenVPN, lots of Cisco software, and software of many other vendors. One software that is not affected is OpenSSH. OpenSSH, even though using OpenSSL, does not use the TLS heartbeat extension, and hence it is not affected. Mobile applications that use OpenSSL are also affected.

How critical is Heartbleed?

Heartbleed is a critical vulnerability. To get into a bit more detail, the Heartbleed vulnerability allows a malicious user using a client to get 64K of memory from the server. Now, this memory can potentially contain sensitive data such as private keys. Once one gets the private keys, the server can be impersonated. Thus Heartbleed needs to be fixed or taken care of immediately.

While Heartbleed existed in the OpenSSL software for about two years back, it was discovered only recently. The disclosure was made public on April 7th along with a version of OpenSSL ( 1.0.1.g) that has the fix. So, it is not really known if it has been exploited. Further, if exploited, Heartbleed leaves no trace in the logs, etc. unless one logs every SSL/TLS transaction which is hardly practical. So, really we do not know if it has been exploited in the past, but if you have a server running a vulnerable version of OpenSSL and it was accessed anytime from April 7th, one cannot assume that you were not compromised.

What are the fixes?

OpenSSL has released a version of OpenSSL called 1.0.1g which has fixed the vulnerability. This was released on 7th April. So, the best option is to upgrade from a vulnerable version to 1.0.1g. The other option is to recompile from the source the version of OpenSSL which you are using currently but with the flag –DOPENSSL_NO_HEARTBEATs. This will disable heartbeats and so circumvent the vulnerability.

Further, it is important to regenerate all keys generated from a vulnerable version.

In case one is using an OS such as Ubuntu, versions of Ubuntu from 12.04 are vulnerable. Ubuntu has an upgrade available.

The version of OpenSSL that fixes this ( Ubuntu will automatically upgrade to this version; go to http://askubuntu.com/questions/444702/how-to-patch-the-heartbleed-bug-cve-2014-0160-in-openssl) is called 1.0.1-4ubuntu5.12

How to test for this vulnerability and how does one test the fix?

One way to test for the vulnerability is by going to this site and entering the name of the site which needs to be tested.

http://filippo.io/Heartbleed/

Indusface Web Application Scanning uses its application scanning capability to check for this vulnerability and has done so for most of its customers.

Are there any other workarounds other than upgrading OpenSSL etc?

Here is an immediate workaround in case you are running a website:

In case you don’t have time to upgrade to a new version of Apache/Nginx which has a newer version of OpenSSL, one way is to install a different Apache server as a reverse proxy. Disable HTTPS from your current Apache/Nginx. And let all traffic go to your newer Apache/Nginx which should not be vulnerable and then let the newer Apache/Nginx work as a reverse proxy and let all traffic go unencrypted to your older web server. The newer reverse proxy can be deployed in your DMZ itself so there are no other security issues. The reverse proxy can also be used to deploy a WAF which can help secure your website from other vulnerabilities. You can contact Indusface for more details of such a quick solution.

You can start with the AppTrana Free Forever Website Security Scan to find out how it works.

Nandini Tandon

Nandini is the co-founder and Chief People Officer at Indusface. She is responsible for the evolution of Indusface’s culture as an organization that empowers its people through sound professional development. Nandini is dedicated to driving organizational development strategies that support the company’s global growth, talent management, rewards and recognition for its employees worldwide.

This post was last modified on January 2, 2024 11:29

Share
Nandini Tandon
Published by
Nandini Tandon

Recent Posts

Top 10 Best Practices for Attack Surface Reduction

Explore crucial tactics like Asset Inventory, Patch Management, Access Control & Authentication, and additional best… Read More

4 days ago

10 Important Data Privacy Questions You Should be Asking Now

Delve into the data privacy questions including consent protocols, data minimization strategies, user rights management,… Read More

6 days ago

11 Best Practices to Secure your Nodejs API

Secure Node.js APIs using best practices: Employ proper HTTP methods, robust authentication, and API-specific security… Read More

1 week ago