By Dr. Samir Kelekar, Senior Consultant, Indusface

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 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 webservers Apache and Nginx, that 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 heart beat 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, 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 going back to an earlier version to fix this vulnerability.

Which softwares are affected and which are not?

The vulnerability is in a module called the TLS heartbeat extension of OpenSSL. As such, softwares using OpenSSL which use this extension are affected. This includes web servers using https such as Apache, Nginx, VPNs such as Openvpn, lots of Cisco softwares and softwares 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 since 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 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’s IndusGuard Web 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.

Founder & Chief Marketing Officer, Indusface

Venky has played multiple roles within Indusface for the past 6 years. Prior to this, as the CTO @indusface, Venky built the product/service offering and technology team from scratch, and grew it from ideation to getting initial customers with a proven/validated business model poised for scale. Before joining Indusface, Venky had 10+ years of experience in security industry and had held various mgmt/leadership roles in Product Development, Professional Services and Sales @Entrust.