As the world comes to terms with the fixing the heartbleed bug which is affected OpenSSL software, researchers have uncovered another version of attack.
The heartbleed bug which was revealed last week grabbed headlines around the world, but just as system administrators are coming to terms with patching their software, researchers have revealed a "reverse heartbleed" attack which opens up a whole new set of problems for
The heartbleed bug, as reported last week, typically works with a client (laptop, tablet, smartphone) making a malicious 'heartbeat' request - as part of a Transport Layer Security (TLS) connection - to the server which is hosting the target website, allowing the attacker to steal chunks of unencrypted data on that server including passwords, credit cards numbers and even encryption keys for the websites in question.
Researchers at Meldium, an online password management tool, have discovered that the same vulnerability in the OpenSSL code could be used for an attack initiated by a malicious server towards a client which also uses a vulnerable version of the open source software.
As Meldium explains: "The TLS heartbeats used in this attack are symmetric: they can be initiated by either the "client" or the "server" in a TLS connection, and both endpoints use the same vulnerable parsing code."
What this means in reality is that criminals looking to exploit the OpenSSL vulnerability will be able to target individual users rather than trying to steal information from the server hosting a website.
This may sound like a less effective attack vector for cybercriminals but as most of the online world has been made aware of the heartbleed bug and the traditional method of attack, most have taken steps to prevent these attacks, meaning criminals may find more joy in using the reverse heartbleed attack.
The attack works like this:
A criminal sets up a malicious server to send malicious heartbeat messages to their victims "client" - which could be a laptops, desktop PC, tablet or smartphone.
However, unlike the typical heartbleed attack, they cannot simply send a malformed heartbeat message to the victim out of the blue, as this is not allowed.
What has to happen is that the criminals must first trick the victim into clicking on a malicious link (in a spam email or social media page), which establishes an SSL connection with the malicious server.
For the attack to work properly, it will need the victim to be running software which uses the vulnerable version of OpenSSL. While this is most likely to be a web browser, it is also possible that applications such as PDF viewers are also vulnerable.
Smartphones and tablets
However one of the biggest avenues for this type of attack could be smartphones and tablets, with many of the apps running on Android and iOS using OpenSSL to encrypt communication.
Google has already revealed that one particular version of Android is itself vulnerable as a result of using the flawed OpenSSL code. While Apple has declared iOS to be safe, the same cannot be said for specific apps sunning on iPhones and iPads.
Meldium says the "surface of exposed clients is potentially very broad – any code in an application that makes outbound HTTP requests must be checked against reverse Heartbleed attacks."
The company added that at a high-level, the reverse heartbleed exploit code is very similar to the client-initiated heartbleed attack, but that there are some factors which make it more difficult for attackers to pull off.
The fix is the same as it was with heartbleed, simply update any older versions of OpenSSL being used to the most recent version.
Meldium adds: "The important takeaway is that it's not enough to patch your perimeter hosts - you need to purge bad OpenSSL versions from your entire infrastructure. And you should keep a healthy distance between agent code that fetches user-provided URLs and sensitive parts of your systems."
The company has also created an online reverse heartbleed checker to allow you check if your system is vulnerable to attack.
Just as with the heartbleed attack it is virtually impossible to trace these types of attack, so it's unlikely we will know if this attack vector has been successfully exploited for a long time to come.