Heartbleed Exploit in OpenSSL – How Should You Respond?

What is the fault?

It has been discovered that a coding error in OpenSSL enables attackers to examine memory on remote servers, or devices.

Specificly: “A missing bounds check in the handling of the TLS heartbeat extension can be used to reveal … memory to a connected client or server.”

– Openssl.org

For those of you without a programming background, here is a good summary of the fault’s impact in business and user terms:

“We have tested some of our own services from attacker’s perspective. We attacked ourselves from outside, without leaving a trace. Without using any privileged information or credentials we were able steal from ourselves the secret keys used for our X.509 certificates, user names and passwords, instant messages, emails and business critical documents and communication.”

– Heartbleed.com

What is the Impact?

OpenSSL is a well respected, solid implementation of a broad set of cryptographic functions, and I have sometimes refer to it as “The crypto-child of a Swiss Army knife and a chainsaw”. OpenSSL is embedded in TONS of software solutions, including the dominant web servers that run on Linux and Unix operating systems – not to mention appliances and devices (Raspberry PI anyone).

The fact that the vulnerability enables the examination of memory provides an attacker with a way of snooping details and bits of traffic off your server — and that is big deal.

Additionally, because the attack can be used to recover and private keys that the server uses, those keys will also need to be retired and rotated.

Bottom line: Heartbleed lays bare and unprotected the contest of the server or device’s memory.

This in-turn enables attacks on keys, or other important things in the memory of the server.
The stolen keys (or other critical information) can be used in other attacks.

And more bad news…

“Exploitation of this bug leaves no traces of anything abnormal happening to the logs.”
– Heartbleed.com

As a result there is no data on the server than can be used to determine if you have or have not been compromised.

You will need to patch, but you can not assume the secrecy of key material that has been on these servers. As a result you will need to reissue keys and certificates after the patch has been applied.

Step 1: Identify the real scope…

What about services other than HTTPS, like SSH, VPNs, email servers using TLS?
Are COTS applications OK?
What about those “appliances” we have?
Oh, and what about Internet of Things (IoT) or Operational Technology devices?

All services that run on Linux or Unix based operating systems, and utilize SSL/TLS session encryption or authentication, should be evaluated. The presence of any one exploitable service on a server or device, impacts all the keys processed or stored on that device.

OpenSSL may be embedded in a number of  your COTS applications, appliances, or devices.

Also, many tools and applications may have used OpenSSL in the past. Anything that utilizes SSL/TLS should be checked to see if it uses one of the impacted versions of OpenSSL now, or any time back to 2012 when the fault originated.

Bottom line: Linux and Unix servers are the place to start, but you will need to examine any service, device or application that uses SSL/TLS encryption or authentication.

Step 2: Apply the Patch, Update COTS, …

Update OpenSSL as quickly as possible. At this time I am not aware of available attack code, but certainly the hacker community is working on this. Organizations should feel a sense of urgency to get the update applied, but should not risk the quality of their operations by circumventing good service management and change control practices.

Attack code is already available (https://gist.github.com/takeshixx/10107280)! Keep in mind that hackers will not just use the exploit to view memory, but to immediately use that information to gain full control of the box. Imagine, for example, an attacker being able to observe administrators logging into the box and capturing their passwords! So, expect this attack code to be combined into compound multi-step attacks shortly.

Keep in mind that “update OpenSSL as quickly as possible” may require updates to COST applications, “appliance” solutions, and infrastructure components that use Linux. There may be many uses that are not obvious at first blush…

Step 3: Reissue Certificates, BUT FIRST regenerate your key pairs!

The existence of this fault on a server undermines any confidence in the confidentially of keys that have been used on that server. Issuing a new certificate is necessary, but not sufficient. Many organizations perform “lazy” certificate rotations, and do not create new keys! This is a bad practice. Because this attack enables the recovery of the private key itself, certificate rotation alone will not protect you! New private keys must be generated.

Thanks and attribution

This analysis is based on public information on the Heartbleed (http://heartbleed.com/) web site.

Also, thanks to Ramon Krikken for spirited discussions that contributed significant value and content to this analysis.

Cheers, Erik