As most everyone in the security industry is well aware, the Heartbleed vulnerability (CVE-2014-0160) is a major issue that has a drastic impact on the Internet as a whole. This specifically affects the heartbeat extension of OpenSSL, which allows for ‘keep-alive’ functionality without performing a renegotiation.
“The Heartbleed Bug is a serious vulnerability in the popular OpenSSL cryptographic software library. This weakness allows stealing the information protected, under normal conditions, by the SSL/TLS encryption used to secure the Internet. SSL/TLS provides communication security and privacy over the Internet for applications such as web, email, instant messaging (IM) and some virtual private networks (VPNs).
The Heartbleed bug allows anyone on the Internet to read the memory of the systems protected by the vulnerable versions of the OpenSSL software. This compromises the secret keys used to identify the service providers and to encrypt the traffic, the names and passwords of the users and the actual content. This allows attackers to eavesdrop on communications, steal data directly from the services and users and to impersonate services and users.”
The following versions of OpenSSL are vulnerable:
Versions 1.0.1g, 1.0.0, and 0.9.8 have been reported to not include this bug. If you are running a vulnerable version of OpenSSL you can remediate the vulnerability by downloading the patch here: https://www.openssl.org/source/.
The severity of this vulnerability is extrapolated only by the sheer number of servers running vulnerable versions of OpenSSL. Many of these servers are hosting ‘trusted’ applications which store very sensitive user data that is now at risk of being exposed.
Figure 1: Metrics on known vulnerable servers world wide
Lists are even being compiled of popular vulnerable sites.
Right now, hackers can attack vulnerable servers and read the host’s memory. This vulnerability, when exploited, will inevitably expose sensitive data — including usernames, passwords, server certificates, and much more, depending on the server’s configuration and purpose.
Figure 2: Testing against known vulnerable servers
The folks over at BugCrowd have released an excellent summary of the currently available Exploit PoC code to test this vulnerability, which includes a Metasploit Module that allows for very easy internal testing. For public facing services, the Heartbleed test site is great and can also be run internally, however beware that this does have the potential to leak your target’s memory to the internet, make sure you understand and are okay with this before proceeding. In our testing, the easiest one to demonstrate with is the very simple ssltest.py script, available on Pastebin. Be careful running any of these scripts, as exploit code can very dangerous if you are inexperienced with this sort of thing…
This is a fascinating vulnerability that is full of potential, especially for penetration testers and ‘hackers’ as a wealth of information can be exposed without leaving many traces on the target host. In-fact, the ssl-access logs will show nothing when this vulnerability is triggered. So, for this type of attack we must rely on network flow data and anomaly detection at layer 3.
Figure 3: Log traces from Heartbleed attack
Examining a packet capture of the network traffic this generates, we can see the request…
Figure 4: Heartbleed Request
Figure 5: Heartbleed Response
In reviewing the SSL request, we can see the encrypted heartbeat, which gives us a content type of Heartbeat (24) and a length of 3. This gives us a unique indicator that can be used to catch this activity as it passes across the network. The only problem being, this would result in many false positives.
Figure 6: SSL Heartbeat Request Details
There are a few ways to do this, one of which is to utilize Snort rules and trigger on this activity within a SIEM so that the Security Analysts can detect and respond to this vulnerability from a central interface. Speaking of Snort, they have covered the details of the vulnerability in a recent blog post. This is an excellent summary of why specific versions of OpenSSL are vulnerable to this attack and more importantly how this activity can be detected using an Intrusion Detection System (IDS). With LogRhythm, we can utilize these rules along with the following Advanced Intelligence Engine (AIE) Rule Blocks to alert on this activity within Snort logs.
This is made up of two rule blocks, the first of which consists of four unique Snort Vendor Message ID’s (VMID), which essentially reflect a ‘Heartbleed’ request.
Figure 7: Heartbleed Request AIE Rule Block
The second half of this rule, triggers on the response from a vulnerable server. This helps in reducing false positives so that security analysts do not waste time tracking down unsuccessful attacks.
Figure 8: Heartbleed Response AIE Rule Block
If you are interested in the details of this rule, Snort has documented each of these relevant VMID’s in their Heartbleed blog post.
The best solution is to apply the OpenSSL patch and test your entire environment using the supplied tools to assure that the vulnerability has been remediated across the board. If you are using something like Puppet, Chef, or Ansible, this entire patching process can be automated rather easily.