All Your Base Are Belong to #HeartBleed - OpenSSL Heartbeat Overflow

Unless you’ve been hiding under a rock, I’m sure you have heard about the overflow vulnerability in OpenSSL’s heartbeat extension.  All today I watched my Twitter feed talk back and forth about this vulnerability and its impact.  In fact, as I write this post a search for “heartbleed” on Twitter has had 181 new comments in the last 8 minutes…  and this is late at night when the US population is largely in bed.  It has made a big splash, that’s for certain.

So what is HeartBleed and what does it mean to organizations?  First, let’s take a look at what it is.  The OpenSSL project created a heartbeat extension to create keep-alive functionality within the Transport Layer Security (TLS) implementation without needing to constantly renegotiate keys.  This is to help speed up performance.  The heartbeat has a maximum data size of 64k.  According to the advisory posted on by OpenSSL, there is a missing check which allows someone to access 64k of memory on a client or server.  So this has impact on not only our web servers, but also our client software.

A lot of the excitement comes into play when we start debating what could be contained in that bit of memory we request.  The worst case fear appears to be that someone may be able to access the private key.  Others have commented that it may be possible to collect usernames and passwords that are in memory and get picked up by an attack.  Lots of different kinds of data could be picked up because TLS is used by lots of different protocols.  Not only does it put the “S” in HTTPS connections, but it is also used to encrypt data in transit for email, chat, VPNs, SSH, etc….  TLS is all over the place.

I spent some time playing with some attack code against one of my own systems just prior to patching it and the code performed very reliably.  I didn’t see anything go haywire on the server side and I was looking at data from my web site on the server.  The python script I was using performed its job quickly.  My site wasn’t very busy, so there wasn’t a ton exciting to see.  However, if someone were to attack a high traffic, sensitive system then this could get more interesting.  So the take away is that yes exploit code exists, it works and and could cause sensitive data to be randomly get snatched up by an attacker.  But only 64k of it and probably its not highly likely that each memory dump will relate to each other.

What do companies need to do about all this?  It’s actually what you would expect.  Patch your systems and applications.  OpenSSL released the fix in version OpenSSL 1.0.1g. Updates for our major operating systems are ready to go, so apply them and verify that your systems are no longer vulnerable. I tested with a python script. The vulnerability scanners have largely all announced that they have plugins to check for the flaw. Apply the update and turn on some vulnerability scans to make sure you have complete coverage of your environment.

One area that will be harder to pin down is the client side. Finding vulnerable clients isn’t as simple as performing a vulnerability scan to look for listening services that offer TLS. However, updates for the most common applications which use OpenSSL’s libraries will almost certainly have updates out already or soon. Once they are out, get the updates deployed to your client systems.

Some organizations may not want to start looking at deploying these updates until they are certain that they are impacted by the flaw. So the question may get asked, “How do we test ourselves?” As I said previously, the vulnerability scanning apps out there have plugins ready to check for it. Default scans by the major vendors are generally safe to run on our networks. Get a scanning window approved and start taking inventory of your environment. Or wrap some of the scripts that have been released into a shell script and feed a range of IP addresses. With that information in hand, you’ll have the evidence you need to help justify the maintenance window you need to deploy the updates.


Jason Wood is principal security consultant at Secure Ideas. If you are in need of a penetration test or other security consulting services you can contact him at jason@secureideas.com or visit the Secure Ideas – Professionally Evil site for services provided.