Apr 15, 2014 6:00:29 AM
Where Does My Heartbleed Now?

Vulnerabilities tend to morph over time. Upon initial identification, researchers, companies, and experts tend to rush to offer opinions, sometimes factual and sometimes less so.

The disclosures concerning Heartbleed have been no exception. However, one of the most interesting discoveries came in the past few days.

Initially, many were quick to deny that private keys could be exposed via the OpenSSL bug. Turns out that this is not true. Private keys are vulnerable.

Cloudflare, who had initially declared that private keys could not be exposed, offered a challenge to anyone to prove otherwise. Results…two individuals were able to obtain sufficient information to reproduce the signature of the private keys used on the challenge server.

So, what does that mean? In short, the security of the internet and enterprise networks just became a little scarier. Let's take a moment to break down what we now know.

The bad news is that products and servers that use OpenSSL 1.0.1a through 1.0.1f (inclusive) are vulnerable and are at risk of having been compromised. As a result of this vulnerability, information otherwise considered private might in fact have been exposed. The bug leading to this vulnerability has been around for approximately 2 years, meaning a lot of info might have been captured.

The worst news is that the private keys of the SSL certificates used to encrypt all data traveling to and from these servers may be decrypted on the fly if someone has the private keys to these servers.

And if you thought that was really bad news…turns out that many products have embedded the OpenSSL libraries in question inside their products. This includes products from major vendors like Cisco, Juniper, and some versions of Android just to name a few.

While network administrators struggle trying to get patches on web servers, it turns out those might just be the tip of the iceberg for this vulnerability.

So the question for many is "what has been compromised?" We need to think in terms of a scope never previously considered. The reality is that many things may have been compromised. In fact, it's reasonable to assume that all data traveling over one of these affected end points (web servers, routers, switches, etc.) may have been compromised. It is somewhat like living in a house with hundreds of doors and only a few keys that can be used to open every door. Now someone else has a copy of that key and can come and go as they please. You'll never know if they have been in or not.

The only way to fix the problem is to change the locks and get new keys. The real emphasis being on getting new keys. Changing private keys is the only way to be fully protected from Heartbleed.

Without changing the private keys on affected devices, it's like calling a locksmith to change the locks (apply the patch) but having the locks configured to use the same key (SSL certificate) you previously used. In short, it's about as effective as changing the hinges and door handle and painting the door in the hopes the thief will think because the door looks different, they have the wrong house.

So it's time to re-issue all those certificates that reside on affected products and devices. It is likely most organizations do not know every affected endpoint and will have t0 spend a considerable amount of time and effort finding and patching SSL servers. Most have ignored internal routers, switches, and other equipment. Even with the patch applied, if the certificates have not been updated, these devices may still be vulnerable.

One good thing coming out of this Heartbleed experience is that organizations should now understand the important role certificates play in an organization. While nothing can eliminate the pain associated with the identification, patching, and certificate reissuance required as a result of Heartbleed, the importance of knowing and being able to manage certificate lifecycle in an enterprise should now be very clear. Having the tools to quickly identify and remediate "at risk" certificates should not be overlooked as a part of a comprehensive security strategy and tool.