SSL Port 443 – The Heartbleed Attack

Lately, the hot topic in the cyber security community, which has socialized to flood the mainstream media, has been all about the latest bug to hit the Internet – with the catchy name – Heartbleed. The bug allows an attacker to capture passwords and other confidential information via the SSL port 443. Heartbleed is not a virus or a Trojan but simply a coding error discovered in OpenSSL’s implementation of the SSL secure communication protocol. So can we still trust SSL? Are certificates, customer data, (passwords, credit cards) safe – and what about those encryption keys? This article will look what went wrong, how it can be fixed, and what it means to Cyber Security.

If you are interested in cyber security, then studying the SSL protocol is a good starting point.

The first point that requires clarification is that it’s not SSL that is compromised. The protocol is not at fault. If you are running IIS, for example, the good news is your websites are not vulnerable. The fault lies not with SSL, but with specific versions of OpenSSL going back two years. The bad news, though, is that OpenSSL is one of the most widespread SSL packages used on the market, because it’s used with the market-dominant Apache Web Server.

OpenSSL is also very popular within the open source community and as a result it also comes packaged with the popular Linux, Apache, MySQL, PHP (LAMP) open-source server configurations. The widespread use of Apache and the bundled LAMP configurations is a big problem, because Apache/OpenSSL runs on around 14% of all web-servers on the internet. To compound the problem, Apache and LAMP are typically used on lower-end ecommerce sites, which perhaps do not have the resources or technological knowledge to resolve the problem.

So what is the Heartbleed bug and how can it be fixed?

Heartbleed is simply a coding error in the OpenSSL package versions 1.0.1 which has been in the wild since March 2012 and in all versions up to and including 1.0.1f. The vulnerability allows an attacker to target SSL on port 443 and manipulate SSL heartbeats in order to read the memory of a system running a vulnerable version of OpenSSL. A heartbeat is simply a keep-a-alive message sent to ensure that the other party is still active and listening. Its use is to maintain the unique session between the server and the host. If SSL did not use heartbeats then the hosts would continually have to renegotiate security parameters, which is not efficient. Therefore, heartbeats are a good thing hence their widespread use in SSL.

The problem however is not with heartbeats themselves but with one line of code, which allowed an attacker to change the heartbeat size and fire it off using TCP on port 443. Unfortunately, as the code did not check the memory size boundaries, the attacker was able read up to 64KB of memory from the web server. By repeatedly changing the heartbeat size and repeating the exploit, the attacker could obtain additional 64KB blocks of data. The attacker continues this process until he gains access to private information such as a user name and password or the server’s private keys. The fix restricts the heartbeat payload boundary to 16KB and validates the entire heartbeat.

The latest package 1.0.1g released 7^th April 2014 has the latest fix to the OpenSSL package.  Earlier versions are not affected. Therefore, only systems built during that period are likely to be affected by Heartbleed, unless, ironically, as a system administrator you have been adhering to best practices and following the latest upgrade path.

Mitigating the problem and upgrading the code then is easy, but that isn’t really the major concern. It is what an attacker may have found in those 64K blocks of memory, which is the real problem. Was the attacker able to view passwords, credit card details, or other confidential information? Therefore, owners of compromised systems were advising their customers to change their passwords, though more as a precaution, that in the unlikely event, that their credentials had been stolen. However in order to get the message out to all their customers required socializing the vulnerability. Within hours, the mainstream media had picked it up and the newly named Heartbleed bug was front-page news.

It soon became apparent though that it was not really an unlikely event that customers’ credentials may have been compromised, it was all too likely. Indeed, there were several demonstrations of passwords being captured doing the rounds on Twitter and other social media networks. This revelation, though disputed by some, clearly pointed towards another potential problem. This time it was a problem with catastrophic potential. Could the attacker get hold of the encryption keys?

As with all asymmetric encryption, it is vital that the SSL private keys remain secure. If the private key is compromised, or even suspected to have been, then so has the security. This had further ramifications, if the keys were compromised then so were the digital certificates, they would need to be revoked and new certificates generated by the trusted certificate authorities (CA), and that would be very costly.

The following statement was issued to webmasters who host OpenSSL encryption:

These are the crown jewels, the encryption keys themselves. Leaked secret keys allows the attacker to decrypt any past and future traffic to the protected services and to impersonate the service at will. Any protection given by the encryption and the signatures in the X.509 certificates can be bypassed. Recovery from this leak requires patching the vulnerability, revocation of the compromised keys and reissuing and redistributing new keys. Even doing all this will still leave any traffic intercepted by the attacker in the past still vulnerable to decryption. All this has to be done by the owners of the services.

The Heartbleed bug has potentially grave consequences for the security and ecommerce industries. Even just the potential of compromised encryption keys and certificates can erode trust and shake public confidence, and all this came about because of one small error in a single line of code.

If you would like to learn more about cyber security and data encryption, learn how to write secure code at Udemy.com