Heartbleed: What is HeartBleed And How TO Protect Against Heartbleed [ILFS Explains]

Editor Ratings:
User Ratings:
[Total: 0    Average: 0/5]

HeartBleed, the newly publicly revealed online security threat, is cause for very serious concern among Internet users but is not cause for panic. While software publishers, hardware manufacturers, and websites work to contain the threat, there are steps we can take to help protect ourselves.

Let’s start by understanding what Heartbleed is and why it is so severe.

Do not panic but do take this threat very, very seriously. Change all your passwords, even of secured sites.

Sponsored Links

So, just what is this HeartBleed threat and why is it so threatening?

Much of our online activity consists of casual interactions: we input data like search terms, we click on links, play videos and songs or post comments. Those interactions are routine, user-initiated, and usually not encrypted because they reveal little or nothing personal about us. However, when our interactions include sharing personal, confidential and sensitive information, such as with banks, online stores, payment processors or simply providing a log-on password, we expect and deserve a greater degree of security and confidentiality than when watching another YouTube video of a cute kitten. This is where SSL/TLS encryption comes into play.

Encryption is the process by which information is scrambled, or encrypted, so that only those who know how we scrambled the information can unscramble and read it. There are many different “recipes” for encrypting and decrypting information. The basic recipe, or basic protocol, used on the Internet to do this is SSL/TLS. And, by a very large margin, the most widely used of all variations of that basic protocol is OpenSSL, two flawed versions of which are at the center of the Heartbleed crisis.

The SSL/TLS protocols (TLS is a successor to SSL but, for our purposes, we will consider them the same.) have very specific rules to which all software and hardware providers must adhere, including, OpenSSL the open-source provider who caused this crisis.

In helping to secure our Internet communications, OpenSSL implemented its own version of SSL/TLS . Two of those versions, introduced about two years ago, contain a programming error that has been given the name “Heartbleed”.

When our computer establishes a connection to another computer (or server), there is a back-and-forth flow of information. If, for some reason, there is a pause in that flow of information longer than a specified time, one or the other computer may close the connection. In order to prevent a premature closing of connections, OpenSSL introduced an improvement (an extension) that, instead of simply closing the connection, would cause a message to be sent, essentially asking, “Are you still there?” This message is called a “Heartbeat Response Request”. If it was still connected, the responding computer would send back a Heartbeat Response that includes its own One-byte “padding” plus the original sender’s data-package.

Sounds good so far and makes good sense, right? HOWEVER, there was a simple mistake that leads us here.

The Heartbeat Request and Heartbeat Response packets are supposed to be a precise size: 64 kilobytes (65, 536 bytes). In a normal Heartbeat transaction, the exchange looks like this:

OpenSSL - Normal Heartbeat Request

The Heartbleed problem occurs when a malicious user crafts a Heartbeat packet that contains LESS than the normal 65,536 bytes total and LIES about its true size. The flaw in those affected versions of OpenSSL is that there is no mechanism for checking the ACTUAL sizes of Heartbeat packets being exchanged.

Heartbleed - Malicious Response

So, here is what happens when a malicious package is sent: The malicious user sends a packet with only ONE byte of data and false information stating that the package includes the full 65,536 bytes. The recipient of that Heartbeat packet receives it and sends back its own Heartbeat response. HOWEVER, since that response is SUPPOSED to include the sender’s data package, which we now know is much smaller than expected, where does the responder get the data to construct a full Heartbeat response? From memory! And, THAT is the problem: the response Heartbeat will be constructed with the normal One-byte padding AND the first 65,535 bytes of stored memory, which may include passwords or other confidential information to which the malicious sender should not have access. Even worse, this stored memory may include the encryption/decryption keys (the main “recipe”) used to encrypt the entire SSL/TLS session. And, if that’s not bad enough, since most websites do not use what is called “Perfect Forward Security” that prevents past communications from being decrypted with the keys presently being used, if a malicious user manages to steal the keys, ALL your communications with that website over the past TWO YEARS may be compromised. The only good news is that it would take a great deal of resources and repeated attacks for any one individual to be at statistically significant risk.

How to Protect Against Heartbleed Vulnerability:

The first thing to do is to change all your passwords, particularly on sensitive websites that were vulnerable. Keep in mind that, unless the website was never vulnerable or it has since patched the flaw, you may have to change your password again after the patch is applied. You can get a partial list of affected sites by visiting Heartbleed.com or Lastpass.com or several other resources that are a Bing/Google search away.

There is also an excellent Google Chrome extension available that will tell you if a visited website is vulnerable. It is available here.

LastPass Password Manager, in addition to providing a site-checking tool, also provides excellent information and other resources, which can be accessed here.

[You might be wondering that why isn’t there a list out there that tells which websites have already lost information because of this bug. Simple: the way this exploit works, it does not leaves any traces at all on the website from which the information is exploited. So, there is no way to find which websites have already leaked sensitive information because of this. It could be very well possible that security community found this bug before hackers did and no information was leaked, but its better to be prepared for the worst and change passwords as soon as you can.]

Second, wherever possible, take advantage of secondary logon authentications, using secret questions, cell phones, smart devices or special secondary codes. In the unlikely event that your information was compromised in the past, this will keep that stolen information from being used successfully now.

Third, though not specific to Heartbleed, you should contact ALL sites you subscribe to and ask them to implement SSL, if they do not already. In addition, you should ask whether they implement “Perfect Forward Security” and, if not, why not?

Fourth, and also not specific to Heartbleed, start using or continue to use a GOOD password manager that encrypts your logon data BEFORE it leaves your computer. There are several excellent free and commercial products from which to choose. I do not recommend storing credentials online but, if you do choose to use such a service, make sure that they encrypt your data BEFORE it leaves your computer AND “salts” that encrypted data once it reaches their servers.

Safe & Happy Surfing. J

Editor Ratings:
User Ratings:
[Total: 0    Average: 0/5]