The Heartbleed Bug

As you may be aware a flaw in the security infrastructure of much of the internet has been recently discovered. The defect is referred to as “heart bleed” or “Heartbleed” and it is without question one of the biggest challenges
to online security to date.

In essence, the bug is the result of a coding error in the OpenSSL cryptographic library, an error that can be exploited to obtain sensitive data and potentially used to decrypt information captured previously. To make matters worse, the bug is widespread. The OpenSSL library is a very popular tool for encrypting online data. It is the preferred library for creating secured transactions on both the Apache and Nginx web servers, which together account for over 66% of all web servers on the internet. It is also used for some mail servers and some types of VPN service. If you use the internet, and I’m assuming you do if you’re reading this now, the odds are very good that this bug affects you directly.

shutterstock_120638998 - Security locks pixelated

SSL stands for Secure Socket Layer, a standard that has been superseded by the more modern implementation of the same technique, called Transport Layer Security, or TLS. However, despite its name the OpenSSL library is used in TLS as well. SSL and TLS both work by means of a shared encryption key. This means that when two parties wish to communicate privately online, for example you and your bank, they exchange a numeric key that is used to encrypt all messages and information sent back and forth. Without the key none of the traffic can be read by a third party. Even were that third party to capture and record all messages sent between your bank and you all they would have would be a file of illegible gibberish.

The TLS protocol uses a technique called a “heartbeat” to keep the session between the two parties active. Normally this is a good thing to do as having to renegotiate the encrypted connection all the time would be relatively expensive in terms of CPU time. However, with the introduction of the defect the heartbeat signal becomes a serious problem. The nature of the bug is such that a cleverly formed request, a request to initiate a TLS session, can cause the server to send a little extra along with the basic heartbeat signal. An additional 64K of data, picked almost at random from the server’s memory, will be sent back along with the heartbeat signal.

This 64K can contain just about anything, including user names, passwords, and in some instances, the certificate that is used to generate the encryption key in the first place. This might seem like an almost trivial amount of data. 64K is not a lot by today’s standards. But then the attacker can get an additional 64K block with every heartbeat signal. They can do this all day long and the attack leaves no trace, no record that any data was lost, no record that an attack occurred at all.

palign="justify">To an attacker this is like being able to shake hands with a target server while at the same time reaching into its pockets with the other hand to get a small handful of stuff. The server will never refuse to shake hands and it will never notice you copying the contents of its pockets. Anything in memory is vulnerable, and since the attack can be repeated over and over while leaving no footprints, then it must be assumed that everything in the server’s memory is compromised. All of it.</p> <p align="justify">"o make matters worse, the bug is not really new. It was discovered and reported on April 7th, 2014. But the bug was introduced into the OpenSSL library with version 1.0.1, which came out over two years ago, and persists in each subsequent release up until version 1.0.1f. It has been patched in the very newly released version 1.0.1g and did not exist in prior versions such as 1.0.0 or 0.9.8, but that still means that we face a potentially catastrophic situation in terms of security breaches.

align="justify" />Also, the scenario described earlier, where a nefarious third party would record traffic between two hosts but be unable to read that data, now takes on a different context. Should that third party have exploited the Heartbleed defect and acquired the SSL certificate from the server’s memory they can use it to decrypt that entire historical record. So previously captured encrypted data could be read.</p> <p align="justify">"t’s this secondary level of vulnerability that makes the Heartbleed defect so catastrophic. Were it simply a matter of replacing the OpenSSL library it would not be so bad. Bad enough, but not a total disaster. But the lack of any way of knowing what was compromised and knowing that anything in the server’s memory could be, or could have been, compromised – without any record of the event – makes for a true internet train wreck. Worst case scenario, every SSL certificate used over the last two years must be black-listed, revoked, and new certificates reissued. If that happens then Heartbleed will have earned its place as, in the words of Forbes cyber security columnist Joseph Steinberg, “the worst vulnerability found since commercial traffic began to flow on the Internet.”</p> <p align="justify">So, what sho"ld you do? Well if you run a server that handles SSL encryption the immediate fix is to update any exposed servers that use SSL/TLS to the 1.0.0g version of OpenSSL. But unfortunately that just stops the bleeding. Without any record of whether or what has been pilfered from the server memory any user account that logs in via that server and the encryption certificate itself are all potentially compromised. This means all user passwords need to be updated after patching the OpenSSL library, and the certificates need to be revoked, blacklisted, and new certificates re-issued.</p> <p align="justify">For the home"user the best step is to change your passwords. There is a list of affected sites that can be used to guide you in terms of which passwords need to be changed. Also, there is a tool that can be used to test individual domains.</p> <p>The list is <a href="" target="_blan"" rel="noopener"noreferrer">here</a>. And"the tool to test a domain for the defect is located <a href="" target="_blank""rel="noopener noreferrer">here</a>.</p> "p align="justify">Keep in mind, s"nce there is no way to know if a site has been affected previously by this exploit then it is possible that your data is secure and no nefarious attacker has gotten any of your sensitive data. It is possible that this defect is as new to the criminals as it is to those who discovered and alerted everyone to it on April 7th, 2014. And the response to the problem has been rapid. Some sites patched their servers within four hours of the patch being released, which also happened on April 7th. So there is a chance that things are not as bad as they may seem. Unfortunately we cannot simply trust to luck to protect us.</p> <p align="justify">Also, we now ha"e evidence that the <a href="" target="_blank" "el="noopener noreferrer">National Securit" Agency</a> has k"own about this flaw for some time and has used it in their intelligence gathering, not bothering to alert anybody about the issue:</p> <p align="justify">This is exactly w"y the responsible security professional must treat anything that could have been compromised as compromised unless there is a way to determine whether or not a breech has occurred, and in this case there is no way to do that. So, if in doubt, change your password, especially those attached to financial accounts.</p> <p>By Dave Kuhl, Lead Senior Consultant – Olenick & Associates, Chicago</p>""

This site uses cookies to provide you with a more responsive and personalized service. By using this site you agree to our use of cookies.

Please read our cookie policy for more information on the cookies we use. Olenick’s privacy policy is available here.

More information Ok Decline