Heartbleed no hemorrhage – LAWtrust

Despite widespread outcry, the threat isn’t as critical as it seems, says LAWtrust solutions director Maeson Maherry.

April 10, 2014

News broke Tuesday of a bug in OpenSSL code that reportedly leaves two thirds of web servers vulnerable to attack. The bug – dubbed heartbleed – has been classed as critical because it could make it possible for possible for attackers to steal login credentials, actual content, and the private keys that underpin the TLS/SSL used to secure and identify web servers. The vulnerability has existed in OpenSSL code for the past two years, and, due to the nature of the bug, there is no log to reveal whether or not a system has been compromised.

Despite widespread outcry, the threat isn’t as critical as it seems, says LAWtrust solutions director Maeson Maherry. “Firstly, the vulnerability only applies to OpenSSL version 1.0.1 through to 1.0.1f and not to previous versions (0.9.8 through to 1.0.1g). This is important because many Apache Web Servers and Tomcat Servers, for example, are bundled with OpenSSL and many have OpenSSL implementations prior to the vulnerable versions. So if you’ve downloaded the Apache 2.2.25 installer complete with OpenSSL you are not going to be affected because the installer comes with OpenSSL version 0.9.8.”

Further, he notes, you could attack a vulnerable web server, but you’d firstly need to do a recce to see if the host is in fact vulnerable – the server type, model and SSL implementation isn’t advertised. Once you know a server is vulnerable you can attack it, but the random memory you get in return may not contain any useful information. You can’t just send a heartbeat message and include a reference to ‘the memory where the private SSL key lives’. The memory heap is not ordered to such a degree.

“Yes, you might get lucky and retrieve something important but the chances are you could also get back utter useless junk in your attempts,” he states.

Not all SSL queries terminate at the host either. “If I terminate my SSL/TLS connection on a hardware device then Apache OpenSSL for example, does not enter the equation,” Maherry notes. “This is because the secure communication part is handled by the hardware module and the communication with Apache is done internally, either through a secure channel or not. Hardware SSL termination is a common practice for hosted solutions because it delivers faster response and handling times than software-based OpenSSL systems.”

And then there are the good, old-fashioned security precautions prevalent in modern systems.

“If the host employs Perfect Forward Secrecy (PFS) from day one then obtaining the private SSL key is a nice achievement but is not going to help one jot when it comes to decrypting any current, previous or future traffic – the master secret key used for encryption will never have been sent over any communication channels. Given most modern browsers support the cipher suites necessary to allow PFS, and similar server side support, your data remains safe regardless – until another attack (brute force from NSA entire supercomputer rack, for instance) possibly prevails,” Maherry says.

These same security precautions – by way of intrusion detection systems – should allow you to see if your system has been compromised. Most attacks leave no logs and no traces and most data thefts take up a minimum of three years to be noticed. That heartbleed leaves no traces is neither surprising nor remarkable.

In other words, says Maherry, “although I may worry about an attacker getting lucky with their unauthorised memory request via the loophole, on a server which my provider has managed to deploy with no hardware SSL termination, and picked the right version of OpenSSL to enable the flaw, and that the vulnerable service has decided against any other security measure to prevent fraud or data theft, I will probably still sleep soundly tonight.”

For those with vulnerable systems, or who are worried they have been compromised Roberts offers the following advice: “Recompile the OpenSSL libraries with a compilation flag to remove the heartbeat functionality, or, upgrade to the latest OpenSSL version.

“For the slightly more paranoid (those who do not believe they have been exploited thus far but are taking precautions) – once OpenSSL has been rectified, generate new key pairs, and attain new SSL certificates for potentially affected servers.

“For the completely paranoid (those who believe they may have already fallen victim) – do all of the above, and ask all customers who use static login information (passwords, shared secrets, etc.) to change their respective credentials.”