Zivaro Blog

Handling the Heartbleed OpenSSL Vulnerability

Undoubtedly, you have heard about the Heartbleed security vulnerability that came to light on April 7, 2014. Heartbleed is the name given by the security researchers at Google and Codenomicon who discovered this weakness in the software code of the OpenSSL software. OpenSSL is an open source implementation of the Secure Sockets Layer (SSL) protocol […]

Undoubtedly, you have heard about the Heartbleed security vulnerability that came to light on April 7, 2014. Heartbleed is the name given by the security researchers at Google and Codenomicon who discovered this weakness in the software code of the OpenSSL software. OpenSSL is an open source implementation of the Secure Sockets Layer (SSL) protocol (now more popularly referred to a Transport Layer Security, or TLS). The issue is related to the heartbeat part of the OpenSSL communications between the client’s web browser and the secure web server. The attacker could send a heartbeat message with an illegal large length and the OpenSSL software would not check the length value and inadvertently respond with the contents of its memory. This memory could contain usernames and passwords and potentially even the private key of the secure web server.

Source: securityintelligence.comIt is difficult to estimate, but anywhere between one-fourth and two-thirds of all web sites use OpenSSL. The issue here is that systems running weak versions of the OpenSSL software could have been exposing usernames and passwords for years. This would compromise the integrity of these accounts. The other issue is that if the private key of the web server is exposed, that the entire site is compromised, even if the OpenSSL software is repaired.

The following sections of this article will give you information about determining if your organization is at risk and how you can go about recovering from this security vulnerability.

Affected Software

Information about this vulnerability are documented in the Mitre Common Vulnerabilities and Exposures page and have been given the id CVE-2014-0160. The OpenSSL site lists the security vulnerability and the affected software versions.

If your organization is using OpenSSL versions 1.0.1 or 1.0.2-beta (including 1.0.1f and 1.0.2-beta1) then your system is affected by this vulnerability.

If you are using an Ubuntu system and want to check the version of OpenSSL you are running, simply type this command on the system:

user@ubuntu:~$ sudo openssl version -a

You will also want to check the build version and release date. You want the build date to be equal to or later than April 7, 2014. If you the output of this command reveals an earlier release date, then your system is vulnerable.

user@ubuntu:~$ sudo openssl version -b

Another technique for detecting if any of your systems are vulnerable is to proactively scan your web servers. It is considered a best practice to be performing regular scans of your site. You can be sure that attackers are performing regular scans of your web sites. If you are using Nessus, then be sure you are using plugin ID 73412 to be able to detect the OpenSSL Heartbleed vulnerability.

We should also mention that OpenSSL software may be embedded in other systems that use Transport Layer Security (TLS) (formerly SSL) communications. This could be e-mail systems, VPN software, voice systems, chat or instant messaging software, and many other systems that use SSL to secure client-server, system-to-system, or machine-to-machine communications.

An example of this is the list of products from Cisco Systems that leverage OpenSSL for TLS or Datagram Transport Layer Security (DTLS). This link contains a long list of Cisco products that are affected by the Heartbleed vulnerability. If you are using a Cisco ASA firewall, then you will also need to upgrade this software and specifically the AnyConnect SSL VPN software.

There are many other vendor’s products that are vulnerable. Some vendors, like Cisco, have been quick to communicate about the issue and to correct their software. Some vendors may be a little slower. Be sure to investigate if all the IT vendors your business relies on that may be vulnerable to the Heartbleed vulnerability are expedition is patching their software.

Remediation

There are several ways to remediate this vulnerability while you proceed to patch your software in your infrastructure. There could be security controls at your Internet perimeter that can help mitigate this vulnerability.

IPS Signatures

An organization could use an Intrusion Prevention System (IPS) to inspect the SSL heartbeat messages for the large lengths that don’t match. Organizations should make sure you have recently updated IPS signatures. Some IPS vendors just released IPS signatures at the end of last week or over the weekend.

Cisco IPS signatures in release S785 and newer can help detect and prevent against the Heartbleed vulnerability.

If you have a Palo Alto Networks Firewall you can monitor the following IPS vulnerability Signature IDs 36416, 36417, 36418, 40039.

Application Delivery Controller (ADC)

Many organizations use Server Load Balancers (SLBs) or Application Delivery Controllers (ADCs) in front of the web servers. These ADCs could be an enterprises first line of defense in protecting a vulnerable web-tier. These ADCs could have embedded Web Application Firewall (WAF) capabilities, and they can also help mitigate the issues related to SSL heartbeat messages. However, these same SLB/ADC systems could be terminating the SSL communications and themselves could be using OpenSSL. Therefore, these systems need to be patched and secured.

Patching Your OpenSSL Software

You should upgrade to OpenSSL version 1.0.1g or newer. Here is the site that contains the updated OpenSSL code to download.

If you are on an Ubuntu system, this is pretty easy. Just run the apt-get command and update your packages. And then we will want to use the apt-get utility to upgrade the OpenSSL software.

user@ubuntu:~$ sudo apt-get update
user@ubuntu:~$ sudo apt-get upgrade openssl

Another option is to recompile OpenSSL code using the ‘-DOPENSSL_NO_HEARTBEATS’ flag to prevent the Heartbleed vulnerability from functioning.

There may be many other pieces of software in your environment that need to be upgraded. Here is a list of the other elements in an enterprise IT infrastructure that may need their software/firmware upgraded:

  • Router/switch software
  • Mobile client software, mobile applications
  • Firewalls
  • Server Load Balancers (SLB), Application Delivery Controllers (ADCs)
  • Wireless access points and controllers
  • Unified communications, IP Phone systems, video systems, collaboration software

 

As more vendors determine if their products are using OpenSSL, organizations should look for announcements from the vendor’s products they use in the IT environment. As more announcements are made and vendor’s products are patched, enterprises should be applying those patches. Following are some examples of popular products and announcements from those vendors showing how they are handling things quickly and professionally.

As an example, if you have a Splunk Enterprise deployment you would want to upgrade to 6.0.3.

Citrix software such as XenMobile App Controller or Receiver for Linux may need to be updated. However, many Citrix products are not vulnerable to Heartbleed.

Several NetApp products are vulnerable to the OpenSSL vulnerability so you will want to upgrade these products.

VMware uses OpenSSL in many products. This page has information on those affected VMware products and where you can get more information on updating.

Infoblox DDI and NetMRI products are not vulnerable, but their Customer Support Portal has now been patched.

Clean Up

There are several things that you need to do to after the software is patched. Following are the list of post-compromise steps that you should follow to recover from this exposure.

Generate New Keys

It is possible that the OpenSSL Heartbleed vulnerability exposed the private key that was being used for the encryption of the SSL sessions. Your organization will likely need to re-generate your RSA key and get new certificates for your TLS site. You will need to revoke the current certificate, generate a new Certificate Signing Request (CSR), then create a new SSL Certificate with your Certificate Authority (CA), and then apply that updated certificate to your SSL/TLS service.

Please don’t assume that after you have patched the software that your exposure has been limited. It is a best practice to assume the worst and go about creating new keys and certificates.

Change Your Passwords

The Heartbleed OpenSSL vulnerability most certainly can expose usernames and passwords from a web service. Therefore, it is vitally important to change any usernames and passwords for the affected sites.

As previously mentioned, many popular Internet web sites use OpenSSL so the list of sites that you and your users must change your passwords is long. Here is a partial list of the more popular web sites that have patched their OpenSSL systems and generated new keys.

  • Amazon Web Services (AWS)
  • Box
  • Dropbox
  • Facebook
  • Flickr
  • Github
  • Google, Gmail
  • Instagram
  • Minecraft
  • Netflix
  • Pinterest
  • Tumblr
  • Yahoo!
  • YouTube
  • Wikimedia/Wikipedia

 

This page has a pretty comprehensive list of popular sites and if you need to change your password.

Notify Users and Customers

If you operate a web site that used a vulnerable OpenSSL implementation then you need to notify your users and have them change their passwords after you have patched your site and changed the key. It is recommended not to have users start to change their passwords until after the web service has been secured.

Further Action

In the near future, more information will become available about this vulnerability. Therefore, it is important to keep up on information revealed about other similar vulnerabilities in other software that may be coming out in the coming days, weeks, and months. As security researchers and vendors work to improve the security of their products and services we should be patient and make sure that we are doing our part to keep our systems patched, keep our users aware of the risks, and communicate about the issues and how to protect, detect, and correct the problems quickly.

3900 E Mexico Avenue, Suite 1000,
Denver, CO 80210