Open SSL TLS/DTLS Heartbeat Read Overrun Vulnerability

April 9, 2013

Executive Summary

On April 7th 2014 OpenSSL and a team of security engineers published advisories regarding a severe vulnerability that “allows anyone  on the Internet to read the memory of systems protected  by vulnerable versions of the OpenSSL   software [1].    They have dubbed this vulnerability “Heartbleed” as it refers to a memory leak in a heartbeat function used by OpenSSL.  SSL  and  TLS  are  cryptographic   protocols designed to  secure communications  over the internet by way of certificates and asymmetric cryptography.  This is implemented in conjunction with Certificate Authorities (CA) and Public Key Infrastructure (PKI). Collectively this forms the basis upon which trust is established on the Internet.   For the non-technical  person, these services are commonly associated with the acronym ‘HTTPS’ which enables secure online commerce and authentication.

The Herjavec  Group Security  Operation  Center is fully protected  and not susceptible  to this attack.  THG is working with our vendors and customer systems to ensure our managed customers are well protected. It is highly recommended  that customers perform an external security assessment to ensure systems have not been missed and left exposed  to this or any other critical threat. THG is happy to assist anyone requiring assistance. Please reach out to your respective account manager or contact us at sales@herjavecgroup.com.

There are several different versions  of SSL and unfortunately OpenSSL  stands as one of the most commonly implemented  versions  on the Internet  today.  OpenSSL  is bundled with many different  operating  systems, embedded  systems, networked appliances, chat servers, VPNs, e-mail  servers and client software making  this vulnerability extremely  wide reaching and dangerous.    OpenSSL is deployed with open source web servers such as Apache and NGINX which account for over 50% of active sites on the internet [2].

In this bulletin we will examine the threat in more detail and offer mitigation  and detection strategies allowing organizations to take a holistic approach to combating the issue.  Unfortunately the steps to resolve and fully secure your environment are not routine,  but should nonetheless be treated as mission  critical to ensure safety for your users and information systems.

In this bulletin we will examine the threat in more detail and offer mitigation  and detection strategies allowing organizations to take a holistic approach to combating the issue.  Unfortunately the steps to resolve and fully secure your environment are not routine,  but should nonetheless be treated as mission  critical to ensure safety for your users and information systems.

Threat Overview

In late 2013 a CVE ID was submitted and created on Mitre identifying TLS and DTLS implementations  in OpenSSL

1.0.1 (excluding  version  G) that fail to perform correct memory bounds checking in the handling of the TLS heartbeat extension [3].   Although the vulnerability was identified by Neel Mehta in late 2013, the actual commit date of the vulnerable OpenSSL  code is two years old [4].    This is a large window of time in which vulnerable systems have been exposed. Although researchers do not believe attacks are common in the wild, proof-of- concept exploit code is now widely available and there is evidence that attacks have been conducted  as far back as 3 months [5].

Software Vulnerability

The Heartbleed  attack relies on what is considered a relatively simple programming  error that when exploited allows attackers  to read up to 64 KB of memory.  Specifically the dtls1_process_heartbeat function contains values which are assigned in memory without performing correct error bounds checking.  This allows an attacker to craft conversations with an OpenSSL Client or Server that reads outside of properly allocated memory. Due to the fact that OpenSSL handles account, certificate,  and key information,  reading in to memory can reveal extremely sensitive data. However, one of the discoverers of the vulnerability recently tweeted in an apparent attempt to allay concerns  stating “heap allocation patterns make private key exposure  unlikely for #heartbleed #dontpanic” [6].    Although  correct, this is highly dependent  on how committed  an attacker  is in their efforts. Prolonged and recurring exploitation of this vulnerability against a system radically increases the likelihood of exposing private key information.

The heartbeat  function does serve a legitimate  purpose in that it allows both parties  in a communication channel to maintain a session while no longer actively exchanging data.

There are multiple  proof-of-concepts  available in the wild demonstrating  exploitation techniques  against this vulnerability.  A popular implementation can be found here.

Researchers have classified the type of information being leaked into four categories:

Vulnerable OpenSSL Versions

• OpenSSL 1.0.1 through 1.0.1f (inclusive) are vulnerable
• OpenSSL 1.0.1g is NOT vulnerable
• OpenSSL 1.0.0 branch is NOT vulnerable
• OpenSSL 0.9.8 branch is NOT vulnerable

Vulnerable Linux and BSD Distributions

• Debian Wheezy (stable), OpenSSL 1.0.1e-2+deb7u4
• CentOS 6.5, OpenSSL 1.0.1e-15
• Fedora 18, OpenSSL 1.0.1e-4
• OpenBSD 5.3 (OpenSSL 1.0.1c 10 May 2012) and 5.4 (OpenSSL 1.0.1c 10 May 2012)
• FreeBSD 10.0 - OpenSSL 1.0.1e 11 Feb 2013
• OpenSUSE 12.2 (OpenSSL 1.0.1c)
• Red Hat Enterprise Linux 6.5 (OpenSSL 1.0.1e)
• Ubuntu 12.04 LTS, 13.04 and 13.10
• Gentoo Linux
• Slackware 14.0, 14.1 and current
• NetBSD, versions 6.1 - 6.1.3 ja 6.0 - 6.0.4
• DragonflyBSD 3.6
• Mandriva Business Server 1

Vulnerable Software

Please note that as vendors become  aware and evaluate their products new information may come to light and more systems may be classified as vulnerable.  As this list is static and far from complete, concerned individuals should reach out to individual vendors for official confirmation or take measures to fingerprint and assess their environment for existence of vulnerable OpenSSL services.

• Cisco AnyConnect Secure Mobility Client for iOS
• Cisco Desktop Collaboration Experience DX650
• Cisco Unified 7800 series IP Phones
• Cisco Unified 8961 IP Phone
• Cisco Unified 9951 IP Phone
• Cisco Unified 9971 IP Phone
• Cisco TelePresence Video Communication Server (VCS)
• Cisco IOS XECisco UCS B-Series (Blade) Servers
• Cisco UCS C-Series (Stand alone Rack) Servers
• Cisco Unified Communication Manager (UCM) 10.0
• FortiGate FortiOS 5.0.5 ja 5.0.6
• Junos OS 13.3R1
• Juniper Odyssey client 5.6r5 and newer
• Juniper SSL VPN (IVEOS) 7.4r1 and newer
• Juniper SSL VPN (IVEOS) 8.0r1 and newer
• Juniper UAC 4.4r1 and newer
• Juniper UAC 5.0r1 and newer
• Juniper Junos Pulse (Desktop) 5.0r1 and newer
• Juniper Junos Pulse (Desktop) 4.0r5 and newer
• Juniper Network Connect (windows) versions 7.4R5 - 7.4R9.1 & 8.0R1 to 8.0R3.1
• Juniper Junos Pulse (Mobile) on Android 4.2R1 and newer
• Juniper Junos Pulse (Mobile) on iOS 4.2R1
• F5 BIG-IP LTM versions 11.5.0 - 11.5.1
• F5 BIG-IP AAM versions 11.5.0 - 11.5.1
• F5 BIG-IP AFM versions 11.5.0 - 11.5.1
• F5 BIG-IP Analytics versions 11.5.0 - 11.5.1
• F5 BIG-IP APM versions 11.5.0 - 11.5.1
• F5 BIG-IP ASM versions 11.5.0 - 11.5.1
• F5 BIG-IP GTM versions 11.5.0 - 11.5.1
• F5 BIG-IP Link Controller 11.5.0 - 11.5.1
• F5 BIG-IP PEM versions 11.5.0 - 11.5.1
• F5 BIG-IP PSM versions 11.5.0 - 11.5.1
• F5 BIG-IP Edge Clients for Apple iOS versions 2.0.0 - 2.0.1 ja 1.0.5
• F5 BIG-IP Edge Clients for Linux versions 7080 - 7101
• F5 BIG-IP Edge Clients for MAC OS X versions 7080 - 7101 ja 6035 - 7071
• F5 BIG-IP Edge Clients for Windows versions 7080 - 7101 ja 6035 - 7071
• OpenVPN 2.3-rc2-I001 - 2.3.2-I003
• Aruba ArubaOS versions 6.3.x, 6.4.x
• Aruba ClearPass versions 6.1.x, 6.2.x, 6.3.x
• Viscosity before version 1.4.8
• WatchGuard XTM ja XCS before version 11.8.3 CSP
• Blue Coat Content Analysis System versions 1.1.1.1 - 1.1.5.1
• Blue Coat Malware Analysis Appliance version 1.1.1
• Blue Coat ProxyAV versions 3.5.1.1 - 3.5.1.6
• Blue Coat ProxySG versions 6.5.1.1 - 6.5.3.5
• Blue Coat SSL Visibility 3.7.0
• Jolla

 The Carnegie  Mellon VNDB has created and is actively maintaining  a Vendor  Information  listing  that tracks vulnerabilities.  Please review the following here.

Indicators of Compromise

Unfortunately, exploitation of this vulnerability does not record log evidence that can be used as an indicator of attack.   However,  IDS/IPS systems  may be able to detect malicious heartbeat request/response communications  based on the record type (and size) contained  within the protocol.  As described  in the software vulnerability section above, detection is possible by comparing the size of a request against its reply.

To elaborate,  systems  with packet  inspection  capabilities  (IDS/IPS,  Analytics,  Proxy) can look for request  and response packets containing matches to specific hexadecimal values for different TLS versions. One must also factor in the size of the packet in order to reduce false positives  and avoid simply identifying  legitimate heartbeat communication.   An example signature match is provided below:

TLS V1.0
Request: 18 03 01 00 03 01 40 00
Response: 18 03 01 40 00

TLS V1.1
Request: 18 03 02 00 03 01 40 00
Response: 18 03 02 40 00

TLS V1.2
Request: 18 03 03 00 03 01 40 00
Response: 18 03 03 40 00

The last two bytes in the response  packets  indicate  an expected cumulative  packet return size of 64KB as described in the disclosed CVE. This is indicative of a possible  attack.  However, 04 00 can be replaced with lower numbers.

Additionally, botnet  behavior on the subnet  193.104.110.0/24 has been observed probing  numerous  systems with TLS Heartbeat requests.

High Value Targets

Due to the widespread implementation and use of OpenSSL THG considers this vulnerability to be of extremely high severity that spans across all industries and verticals.

THG has tested our environment and it is not susceptible to the HeartBleed SSL Bug.  We are working diligently with product vendors to ensure that our customer  systems are also protected.  As always, THG stands ready to assist you in performing an external security assessment  of your environment to identify Heartbleed and any other insecurity that may pose a risk.

Mitigation and Detection

Impact Assessment

Your first step is to perform a system inventory and document assets that may by running vulnerable versions of OpenSSL.  To quickly  scan a large environment  you may want to use the following  NMAP script to detect whether your systems are vulnerable: https://svn.nmap.org/nmap/scripts/ssl-heartbleed.nse

Alternatively, there are a number of websites that you can use to check  if your systems  are exposed. A popular site at the moment  is: http://filippo.io/Heartbleed/

The simplest option of course would be to issue the command  “openssl version –a” to check if your  system  is running a vulnerable version.

Patching

The OpenSSL team has released  version 1.0.1g which contains a code fix for the Heartbleed  vulnerability. Administrators  should  patch  systems  immediately.   Versions 0.9.x and 1.0.0 are not vulnerable and thus it is also possible to downgrade. If patching   is not possible then OpenSSL should be recompiled with the switch “– DOPENSSL_NO_HEARTBEATS”.

Recovery

Unfortunately, any organization that has vulnerable systems must take additional steps after patching in order to maintain trust and confidence in secure online communication.  System administrators should re- key existing SSL certificates after patching.   This will effectively issue a new certificate and your old certificate will be revoked automatically. Please note that you may experience delays when dealing with Certificate Authorities as they are attempting to reissue hundreds of thousands of certificates.

Lastly, a warning should be issued to your user base and a password reset program put into place to ensure that all users reset their password as soon as possible.

Detection

The majority  of vendors  has either released  or is currently  working  on signatures  to detect the Heartbleed vulnerability. THG has confirmed the following vendors have detection mechanisms available:

• RSA
• McAfee
• Palo Alto Networks
• Fortinet
• Trend Micro
• Tenable
• Citrix
• Cisco

For those who use LUA/Snort/Suricata the following rules will detect Heartbleed [7,8]:

Appendix

1. “The Heartbleed Bug”. Codenomicon,  April 7 2014. Web. April 9 2014. Click Here
2. "April 2014 Web Server Survey”.  Netcraft.  April 2 204. Web. April 9 2014. Click Here
3. “OpenSSL Security Advisory”. OpenSSL.  April 7 2014. Web. April 9 2014. Click Here
4. “OpenSSL GitHub Repository”. OpenSSL.  2012. Web. April 9 2014. Click Here
5. “Wild at Heart: Were Intelligence Agencies Using Heartbleed in November 2013?”.  Electronic  Frontier Foundation.  April 10 2014. Web. April 10 2014. Click Here
6. “Neel Mehta”.  Twitter.  April 8 2014. Web. April 9 2014. Click Here
7. “Daily Ruleset Update Summary”. Emerging Threats Snort Ruleset.  April 9 2014. Web. April 9 2014. Click Here
8. “Detecting OpenSSL Heartbleed with Suricata”. Inliniac.  April 8 2014. Web. April 9 2014. Click Here