Thoughts on the Heartbleed Bug

heartbleed.png

 

The Heartbleed bug is big. It's bigger than most thought it was when they heard about it, and now that the patching dance has begun people are finally starting to feel the weight of it.

 

In this short article we'll cover some basics (what the bug is, what the risks are to organizations) and we'll offers some analysis and commentary as well.

 

The bug

 

Let's talk first about what the bug is. In simple language, the bug is a flaw in certain versions of OpenSSL that allows an attacker to read areas of memory from a system running the software. This functionality is part of the SSL "heartbeat" functionality--hence the name--and it allows one to read data from the server in 64 byte chunks per query.

 

More information can be found here (NVD): 

 

Implications

 

Adding to the severity of the bug is the fact that multiple requests can be made in order to pull significant data from the vulnerable system. The most common question we get related to that is simply, "Ok, but what can they read out of memory?"

 

This breaks down to two main issues:

  1. It's possible to use this technique to read the private keys associated with a vulnerable server's certificate, thus making it possible to 1) impersonate that server, and 2) decrypt data sent to it.
  2. It's possible to use this technique to extract sensitive data that's been sent over the "secure" connection. This can include things like customers' financial data, PII, administrative credentials, etc.

Analysis

 

The heartbleed bug is an interesting example of complexity adding insecurity. It's a simple matter of surface area--the more you have the more chance you have for bugs.

 

It's not without irony that the vulnerable component is security software itself. It reminds this writer of performing penetration tests for customers whereby the method of gaining system level access to the system was in fact the security agent (AV/HIPS/etc).

 

There are a couple of lessons to take from this:

  • Simplicity of mechanism is key. The more complexity you have the more potential you have for insecurity. Without any other knowledge, the assumption should be made that a simple system is more secure than a complex one. In this case we see that something as seemingly benign as a heartbeat function can rock the entire Internet.
  • A push for performance is often the enemy of security. It is still being discussed, but it appears that a conscious decision was made by the development team to avoid the critical bounds check at play here in the name of performance. The link between performance and insecurity is not intrinsic, as it's really just one example of a functionality decision (in this case performance) coming before security, but the flag should be raised in the mind of every security person once they hear "Ok, well, let's do what we need to do to make this thing fast."  

Recommended actions

 

As recommended by the OpenSSL website, there are two main ways to address the issue:

  1. Upgrade to OpenSSL 1.0.1g
  2. Recompile OpenSSL with DOPENSSL_NO_HEARTBEATS 

Additionally, here is a link that allows you to check to see if a given domain is vulnerable. One caveat on the tool, however, and on similar tools whenever you see them: Look into what they're doing before you use them. The tool below, for example, will validate the issue exists by actually pulling 64K of memory, and many similar tools do the same.

 

This doesn't mean you shouldn't use it (it's live on the Internet where anyone can do the same) but you should at least be aware of it.

 

http://filippo.io/Heartbleed

 

About Fortify on Demand

 

Fortify on Demand is a cloud-based application security solution. We perform multiple types of security testing, including web assessments, mobile application assessments, thick client testing, SAP, etc.--and we do it using both static and dynamic techologies and techniques.

 

We also have the ability to tell you if you're vulnerable to the heartbleed issue, at scale, very quickly.

 

We're here if you need us. Feel free to reach out on Twitter @hpappsecurity or via fodsales(at)hp.com to get your questions answered.

 

Additional information

 

Here are a few links for additional reading:

 

 

--

 

As always, feel free to reach out with any questions via Twitter (@danielmiessler) or via email (daniel.miessler@hp.com).

 

: :
 
Daniel Miessler is a Practice Principal with Fortify on Demand based out of San Francisco, California. His areas of expertise are web and mobile application security testing and building application security programs for the Global and Fortune 100. He can be reached at daniel.miessler@hp.com and on Twitter at @danielmiessler

 

Comments
Robert94117(anon) | ‎04-09-2014 12:38 PM

Are the HP Tipping Point IPS Sensors and the management platform running a vulnerble version of OpenSSL?

tarnrevick(anon) | ‎04-11-2014 10:03 AM

Are printers and their web based config pages affected? Would they use open SSL? Or say a secure release printer that uses a key fob or card to release a print job?

Nathan Grist(anon) | ‎04-11-2014 10:54 AM

How about your thoughts or URL's on HP vulnerability assessment for all your products such as iLO and System Management Homepage, etc. ?

Leave a Comment

We encourage you to share your comments on this post. Comments are moderated and will be reviewed
and posted as promptly as possible during regular business hours

To ensure your comment is published, be sure to follow the Community Guidelines.

Be sure to enter a unique name. You can't reuse a name that's already in use.
Be sure to enter a unique email address. You can't reuse an email address that's already in use.
Type the characters you see in the picture above.Type the words you hear.
Search
About the Author
http://www.danielmiessler.com/about


Follow Us
The opinions expressed above are the personal opinions of the authors, not of HP. By using this site, you accept the Terms of Use and Rules of Participation