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.”

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.

Erik T. Heidt
IoT Agenda Manager, Research Director 4 years at Gartner 23 years IT Industry

Erik Heidt is the Research Agenda Manager for Gartner for Technical Professionals (GTP). Mr. Heidt covers Internet of Things (IoT) architecture, IoT strategy as well as security and risk management within the IoT context. Mr. Heidt focuses on developing and delivering research related to the architecture, development and operation of IoT for both users and suppliers. Mr. Heidt has more than 24 years of IT industry experience, with a significant focus on information security and risk management. Read Full Bio

Thoughts on Heartbleed Exploit in OpenSSL – How Should You Respond?

Erik, the point you make about first generating new key pairs and then issuing new certificates is so important. I’m finding too many response teams thinking it may only be adequate to issue new certificates. With successful private key extraction exploits demonstrated by CloudFlare challenge, there can be no question about whether to rekey or not. It’s a must. Thanks for setting the record straight early on in the response cycle.

Categories

Meta

Comments or opinions expressed on this blog are those of the individual contributors only, and do not necessarily represent the views of Gartner, Inc. or its management. Readers may copy and redistribute blog postings on other blogs, or otherwise for private, non-commercial or journalistic purposes, with attribution to Gartner. This content may not be used for any other purposes in any other formats or media. The content on this blog is provided on an "as-is" basis. Gartner shall not be liable for any damages whatsoever arising out of the content or use of this blog.