Heartbleed Vulnerability (CVE 2014–0160): How can users protect themselves?

Rook Security
SECOPS
Published in
2 min readApr 11, 2014

How can users protect themselves? This is a tough question to answer due to the nature of this particular vulnerability. The flaw has actually existed in OpenSSL since version 1.0.1 which was released 14 March 2012. This can be worrisome as this flaw could have been known and kept secret by malicious actors. There is also a Metasploit module available for this attack.

What Was Affected?

The ‘Heartbleed’ vulnerability lies within the heartbeat extension with OpenSSL. OpenSSL is an open source implementation of SSL and TLS. The heartbeat extension helps to ensure a connection is maintained during time of inactivity. Same type of functionality in SSH. For example, when a connection is made to an SSH server ‘heartbeat’ packets are sent to the server to prevent timeouts from occurring, this is known as ‘ServerAliveInterval’ in the SSH protocol. In OpenSSL, the server is supposed to respond with an echo of what the client sent.

How Does it Work?

The issue with the heartbeat extensions is known as a read overrun. Essentially what happens is when an attacker makes a specific query against a server that is vulnerable, the server responds with up to 64kb of RAM in plain text instead of echoing exactly what the attacker sent. Where this becomes a major issue is when users login to a website this information is stored in RAM in plain text during the encryption and decryption process. All an attacker needs to do is constantly query the server to obtain users credentials as they login. A secondary issue is, logs aren’t very useful in this situation as these queries, to the server, look normal. The only way to detect this attack is via your IDS or IPS.

What can users do?

First, users need to determine if the sites they access regularly are vulnerable. There are multiple ways to do this, from a list of sites being regularly scanned to a chrome extension to verify when you visit.

If the site has not been fixed yet, email the administrator and ask for an estimated time of completion for this update. Unfortunately, sometimes it takes an excess of pressure from end-users for some organizations to act.

Only after you have verified the site has been fixed, login and change your password. Avoid using the site until then. I would also suggest emailing the site administrator asking for them to revoke and obtain a new SSL certificate. Although it is unlikely private keys on the site were able to be stolen, it is a possibility. If an attacker was able to obtain these private keys, they would be able to spoof the site in question, thereby fooling end-users into entering personal information they otherwise may not have if a padlock, green lettering, or https was not visible.

Resources:

--

--

Rook Security
SECOPS
Editor for

Global provider of IT security solutions protecting against dynamic, emerging threats. -- Inc. 500 Company in 2014.