Detecting and Exploiting the OpenSSL-Heartbleed Vulnerability
The internet has been plastered with news about the OpenSSL heartbeat or “Heartbleed” vulnerability (CVE-2014-0160) that some have said could affect up to 2/3 of the internet. Everything from servers to routers to smart phones could be tricked into giving up encrypted data in plain text.
Basically, OpenSSL is an encryption library used in HTTPS communication. When most think of HTTPS communication, they think of the little lock icon that shows up in the browser bar when you visit online stores and banking websites.
HTTPS is supposed to be the “secured” version of regular HTTP communication. Any data communication using SSL should be secure and encrypted. But with the latest OpenSSL vulnerability, unencrypted information can be recovered from a vulnerable system from specially crafted heartbeat messages.
During communication, OpenSSL uses a “heartbeat” message that echoes back data to verify that it was received correctly. The problem is, in OpenSSL 1.0.1 to 1.0.1f, a hacker can trick OpenSSL by sending a single byte of information but telling the server that it sent up to 64K bytes of data that needs to be checked and echoed back.
And the server will respond with random data – from its memory!
During testing, security researchers using this technique have been able to trick vulnerable systems into giving up login credentials, session cookies, and other sensitive data.
But as mentioned the vulnerability goes past just visiting shopping webpages – major websites, social media & game servers, even Android systems, embedded devices and routers could all be affected. Any device that uses the vulnerable version of OpenSSL is at risk.
The vulnerability is remedied in the latest update of OpenSSL, but the problem is it could take years for all the affected devices to be found and patched. And some embedded and proprietary devices may never be patched!
In this article we will quickly discuss some ways to detect the Heartbleed vulnerability, take a deeper look at finding vulnerable systems with the ever popular scanning tool, “Nmap”, and finally see how to exploit a vulnerable system using the Heartbleed exploit module in Metasploit.
Before we go any further, it is neither legal nor ethical to access servers that you do not own. Never run security scans or checks on systems that you do not own or have approval to scan.
Software used in this Article
For a vulnerable server, I used one of Turnkey Linux WordPress VMs . For the record, there are security updates available for Turnkey’s WordPress, but during the setup, and for this tutorial, I purposefully told this VM not to install the security updates so I could test for the OpenSSL vulnerability.
Simply boot up both images in your VMWare Player or Workstation. Once the WordPress VM is configured (just answer a few simple questions) you are pretty much set to go. Remember during configuration to choose not to install the security updates automatically, or this tutorial will not work.
Please note that we are basically putting a purposefully vulnerable VM on a computer. Never place a vulnerable VM on a mission critical system or a computer that has open or un-firewalled internet access.
Programs that will Detect Vulnerable Systems
Sadly for those who may not know they have at-risk systems, it is not hard to detect vulnerable systems. Shortly after the vulnerability was publicly announced, a plethora of tools and utilities to check for exploitable systems popped up all over the web.
Unbelievably there are even online lists of the top 10,000 websites that were vulnerable in early April (many have been patched since).
A quick Google search will reveal that there are various utilities, scripts available in several languages, and browser plug-ins (even a honeypot or two) that will detect the bug. I have just never felt comfortable using random “security” tools from the web. Without going through them line by line, you never know what you are getting – so use them at your own risk.
Nessus  and other main line security programs have updated their scanning engines earlier in the month to detect Heartbleed. If you are a corporate IT center, and haven’t done so already, check with your security scanning tool providers to see if they can detect it.
Lastly, and probably the most unnerving for those who haven’t patched their systems, you can find vulnerable devices worldwide very quickly using keyword searches in Shodan  – the “hacker’s Google”.
But as a security specialist or business owner, how can you scan your systems if you don’t have a capable security program or don’t want to trust a random script off the web?
How about using the ever popular scanning tool Nmap?
Detecting Exploit with Nmap
Nmap has created a Heartbleed script that does a great job of detecting vulnerable servers. If the Open-Heartbleed script is not already included in your nmap install, you will need to manually install it.
Figure 1. Copying “nmap.nse” file into scripts directory
You will also need the nmap “tls.lua” library file , save this to the nmap “nselib” directory as seen below:
Figure 2. Copying “tls.lua” file into the nselib directory
That’s it; we can now use the heartbleed script in nmap to detect vulnerable systems.
To use the command, the syntax is:
nmap -sV –script=ssl-heartbleed <target>
All we need to add is the IP address of our test target WordPress site, 192.168.1.70 in this instance:
Figure 3. Nmap command to scan for Heartbleed vulnerability
And if the target machine is vulnerable we will see this (Figure 4):
Figure 4. Screenshot of Nmap command running
Risk Factor: High
As you can see, Nmap scanned our test server and found that it indeed contains a vulnerable version of OpenSSL.
Exploiting with Metasploit
Metasploit has released a couple modules to its framework to deal with the new OpenSSL bug – A server module to test client software and a scanner module.
Now that we know we have a vulnerable server, we can use the Metasploit OpenSSL-Heartbleed scanner module to exploit it. (Note: you can use the module to detect vulnerable systems also)
Figure 5. Updating Metasploit Framework
Figure 6. Metasploit Console
• Next search for the heartbleed modules by typing, “search heartbleed”:
Figure 7. Using Metasploit Search Feature
Notice there are two, we will be using the scanner.
• Type, “use auxiliary/scanner/ssl/openssl_heartbleed”:
Figure 8. OpenSSL_Heartbleed Exploit Options
• We are just going to set two options, “set VERBOSE” to true and we need to “set RHOSTS” to our target IP address as seen in Figure 9:
Figure 9. Setting Exploit Options
• And finally, just “run” the exploit:
Figure 10. Random Data pulled from Server via Heartbleed
If you look at the picture above (Figure 10), you will see that Metasploit communicated with the server and was able to pull random data from the server’s memory.
If you re-run the module, you will get a totally different response from the server including different leaked data.
The important thing to note here is that the exploit pulls random data from memory. There is no guarantee that you will find account credentials, session cookie data or critical data every time you run this. The danger is in the fact that it could display sensitive data.
But be advised, with this type of attack it would be trivial to create a script that continuously hits a vulnerable site pulling data from it and then filter the responses for keywords like “username”, “password” or “cookie”.
Using a technique like this, the chance that confidential data could be recovered from server memory increases dramatically.
Thus the best practice (if you haven’t already) is to check your systems for the heartbleed vulnerability and patch them immediately. After all systems are patched, change any passwords on the effected machines.