On 07, April 2014 a patch was released for OpenSSL to fix a very controversial vulnerability – The Heartbleed Bug. According to a report, over 500,000 servers were found to be vulnerable but more and more admins are now patching their machines and the numbers are decreasing steadily.
Affected servers are vulnerable to hacking (extraction of information such as user credential’s, cookies, server private keys, Personal Identification Info etc. from the memory). The bug is so big that major websites like Google, Facebook, Tumblr, Instagram, Yahoo, Pinterest etc. were also vulnerable. This exploit is in existence for more than 2 years without anyone’s attention.
Basically, OpenSSL is an encryption library used in HTTPS (secure HTTP). The idea is that any data traveling over this secured version of HTTP should be secure and encrypted. During communication, OpenSSL uses a “heartbeat” that echoes back data to verify that the data was received correctly. It’s kind of like one machine telling the other, “Yes, I got that data and you can send more now.”
The Heartbleed vulnerability enables a hacker to trick OpenSSL by sending a single byte of data while telling the server it sent 64K bytes of data. The server will then send back 64K bytes of data to be checked and echoed back. The server will then respond with 64K of random data from its memory.
In this post 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.
Steps To Follow :-
First of all, if you haven’t updated your metasploit framework in quit a while i would recommend it doing now to get the new auxiliary module for Heartbleed.
Step 1. Update Metasploit
Open terminal in kali linux and type:
Metasploit will then go through the long and slow process of updating its modules and framework. Be patient here, it takes awhile. When you are finally returned to the Kali prompt, the update has completed.
And you should see the file listed:
Step 2. Start the Metasploit
Now it’s time to run the attack. To do so, start the metasploit console by running the following command
And you should see a screen like this:
Step 3. Find Heartbleed and Use Auxiliary Module
Now, we need to find the new Heartbleed module. We can use the built-in search feature in Metasploit. Type:
This should bring up two auxiliary modules for Heartbleed. Select the first one as I’ve highlighted below:
After You Got the heart Bleed Auxiliary Path. Issue the following Command:
This will load the heartbleed module.
Step 4. Set Options and Run the Module
Although this module has numerous options, the critical one is RHOSTS (notice the plural here). Let’s set it to a target website I set up on my network that is still vulnerable to Heartbleed. type the following command to set RHOSTS:
#set RHOSTS 192.168.1.169
#set RPORT 443
Finally, set the option ‘verbose” to “true”. This will provide us with verbose output. type:
#set verbose true
And you are all set to run the command. And how do you run it. Well. By simply typing
And here is an example of the output of a vulnerable website:
Fixing the Bug
Ok, so we have talked about the dark side of the moon. So it’s customary to talk about the bright side as well. So here is a quick 3 step guide on how to fix your site if it possesses this vulnerability. And how do you know if it possesses or not? You do the above steps and see if the output throws back any data or not. If it shows a screen like below. Then you are all clear.
But if you find the vulnerability then you should
1. Go ahead and upgrade your Open SSL version with the patched version of the OpenSSL. And that would be “OpenSSL 1.0.1g”. Also there is a chance your Linux Distribution has back ported the fix to an older stable release of the OpenSSL. So please check with your distribution provider to see if you can just run a package upgrade or you have to compile the latest version of SSL from code for your distribution.
2. Regenerate the SSL Private Key and certification verification request. This is necessary to make sure if anyone has already exploited your server’s vulnerability during the zero day or before the information went public. S/he cannot at least compromise your secure data by using the previously captured private key anymore.
3. And finally, get the key verified by a SSL Certification Authority of your choice and redeploy it to your webserver
And there is a point 4 as well. But this one is more philosophical than technical. If your server had the vulnerability and you have just fixed it. And your server was storing user password. Then please go ahead and ask all your user’s to immediately change their password. This is to make sure if someone had already exploited this vulnerability on your server. Then he cannot use the user credentials anymore.