OpenSSL Heartbleed vulnerability scanner
About this tool
This tool attempts to identify servers vulnerable to the OpenSSL Heartbleed vulnerability (CVE-2014-0160).
The vulnerability affects all applications that use OpenSSL versions 1.0.1-1.0.1f and permits an attacker to read up to 64k of server memory. This memory can contain:
- HTTP requests made by other users to the server, which may include:
- Session cookies
- Usernames and passwords sent in form fields
- User agent and other headers sent by the client
- HTTP responses sent by the server to other users containing sensitive information
- SSL encryption keys
- Email messages (in case of SMTP, IMAP or POP3)
- Other sensitive data stored in server memory
- Target host(s): This can be an IP range, a single IP or a hostname. An IP range can be specified like 100.101.102.1-254. Maximum 255 hosts can be scanned in a row. When a single IP/hosname is being scanned, the tool will try to read a piece of server memory in order to prove the vulnerability.
- Target service: This is the service that will be scanned for Heartbleed vulnerability. The protocols that are supported right now are: HTTPS, SMTP, IMAP, POP3 and FTP.
- Target port: This is the port associated with the targt service. Can be changed as non-default port.
- Do reverse DNS: When checked, the tool will attempt to do reverse DNS for each live IP in the IP range. It will return the hostname of that IP configured in DNS. This option slows down the scan.
How it works
The OpenSSL Heartbleed vulnerability is caused by a programming error present in the heartbeat extension of OpenSSL, which is an implementation of RFC6520. The problem is caused by the fact that OpenSSL server does not verify if the value of 'payload length' received in the Heartbeat Request corresponds to the actual length of the payload received. Thus, the client can trick the server into believing that he had sent a much bigger payload than he actually did. When building the Heartbeat Response message, the server will try to send back the payload he had received, copying 'payload length' bytes of memory and sending them back to the client. This memory can contain random data, previously used by the server.
So the client controls the amount of memory the server will send back, maximum 65535 bytes (64k). The sequence of packets that is transmitted between the client (our scanner) and server in order to verify this vulnerability is:
Client -> Server: Client Hello
Server -> Client: Server Hello
Server -> Client: Certificate, Server Key Exchange, Server Hello Done
Client -> Server: Heartbeat Request ('payload length'=64k, small actual payload data)
Server -> Client: Heartbeat Response (containing server memory in payload data)