Examining The Impact Of Heartbleed

On April 10, Bishop Fox Security Analyst Tim Sapio was published in Dark Reading - hot on the tails of the discovery of the Heartbleed vulnerability. Tim discussed the vulnerability's implications as well as how Internet users could take measures to protect themselves.

Yesterday saw the beginning of the most significant breaches in Internet security to date. I’m talking, of course, about the vulnerability that was discovered in OpenSSL (CVE-2014-0160), becoming commonly known as Heartbleed. This was not a breach like the ones we’ve grown accustomed to hearing about in recent months, such as Target, Drupal, or the California DMV, wherein customer’s personal data or login credentials were leaked. Instead, this breach strikes at the heart of encrypted transfers to the servers we all use in our day-to-day lives.

The Heartbleed vulnerability exists in all default versions of OpenSSL going back to March 2012. Among the products that use OpenSSL are Apache, IIS, Nginx, Cisco AnyConnect, your home router…it’s harder come up with a list of Web products that DON’T use OpenSSL than those that do.

What exactly does this vulnerability do, and why is it so bad? Basically, this vulnerability allows an attacker to abuse a normal function of SSL, known as the heartbeat. The vulnerability permits an attacker to read bits of memory on an affected server to which he or she should not have access. Since the bug occurs at such a low level, merely connecting to a vulnerable system and sending it a specially formed request is enough to trigger the vulnerability. No authentication with the server is required. In practice, this means that attackers can connect to a vulnerable server, keep the connection alive, and wait for something interesting to come to their way. This may sound like an ineffective attack, since the attacker has no control over which specific parts of memory can be read, and no ability to change what is stored in the accessible locations.

However, the consequences could not be more serious. The contents of the compromised memory include portions of all transactions the server has serviced. This includes private encryption keys, unencrypted traffic received or transmitted by the server, login credentials, pieces of your database, and pieces of confidential documents transferred through the application. Essentially, anything that the vulnerable application has in its own memory has a chance to end up in the tiny window the attacker can read.

What You Need to Know

So what does this mean, exactly?:

• Heartbleed-vulnerable applications are those applications that use the default build of the OpenSSL library to build their connections and are using any vulnerable versions of the library.
• There are no reasonable limits on what information can be compromised. As long as it gets read by the application process, it is vulnerable.
• Attacks can be easily automated and distributed in order to make identifying possible attackers extraordinarily difficult.
• The attack has potentially been in the wild now for two years.

Starting to understand the full impact of this breach now? For other recent breaches, extreme though they were, we were able to put an upper limit on what may have been compromised, and who was to blame for those compromises. Here, however, EVERYONE who was vulnerable could have potentially been leaking EVERYTHING those applications saw for the past two years. There is also little hope of determining if an asset was breached in this way, or if a breach CAN be identified, you simply have no idea what sensitive data, if any, was leaked.

One thing is certain, however: if you do not take measures now against this bug, you will be hacked sooner rather than later. The attack is simply too easy to perform, and too widespread for it not to become one of the most popular automated attacks ever.

The patched version is available from OpenSSL's website, and from all major vendors through their own respective software update systems. For those of you who include OpenSSL in your own software, build using the patched version and push out your own patches! For those of you who are still waiting for patches or will not be able to patch the applications about which you are concerned, there are packet filters available that will filter out any heartbeat requests before they reach your vulnerable devices. Not sure if you are vulnerable? Run the Python script linked to below on your own server.

Additional Resources:

Proof of Concept Code to check to see if you’re vulnerable
Recovering OpenSSL ECDSA Nonces using the Flush+Reload Cache Side-channel Attack
Detecting the Heartbleed Bug using Bro IDS
IPTables Rules for blocking heartbeats
OpenSSL Changelog
OpenSSL diff which illustrates the bug