Heartbleed Scan: Check Site Vulnerability

TL;DR

Yes, external tools can accurately determine if a site was vulnerable to Heartbleed at the time of scanning. However, they cannot definitively prove current vulnerability without access to server logs and configuration. They can only tell you if the server was susceptible based on its TLS/SSL setup. Remediation is confirmed by checking for patched OpenSSL versions.

How Heartbleed Scanners Work

Heartbleed (CVE-2014-0160) exploited a bug in older versions of OpenSSL. Scanners don’t ‘hack’ the site; they send specially crafted requests to see if the server responds with leaked memory. Here’s how it works:

1. TLS Handshake: The scanner initiates a TLS (Transport Layer Security) connection, like a normal web browser.
2. Heartbeat Request: It sends a ‘heartbeat’ request to the server. This is part of the TLS protocol used to keep connections alive.
3. Exploitation Attempt: The scanner intentionally crafts the heartbeat request with an invalid length, larger than what the server expects.
4. Response Analysis: If vulnerable, the server will respond by sending back a chunk of its memory – potentially containing sensitive data like private keys and user information. A non-vulnerable server should ignore or properly handle the malformed request without leaking data.

Scanning Tools

Several tools can check for Heartbleed vulnerability:

• Online Scanners: Websites like SSL Test and SSL Labs SSL Server Test include Heartbleed checks.
• Command-Line Tools: nmap with the ssl-heartbleed script is a popular option.

Using nmap to Scan

If you have nmap installed, you can use it like this:

nmap --script ssl-heartbleed example.com

The output will tell you if the server is vulnerable, not vulnerable, or if the scan couldn’t determine the status.

Interpreting Scan Results

• Vulnerable: The server was susceptible to Heartbleed at the time of the scan. This means it likely ran an unpatched version of OpenSSL.
• Not Vulnerable: The server is not currently vulnerable based on its TLS/SSL configuration. It either never had the vulnerability or has been patched.
• Scan Failed: The scanner couldn’t determine the status. This could be due to network issues, firewall restrictions, or the server’s configuration.

Confirming Remediation

A ‘Not Vulnerable’ result doesn’t guarantee complete safety. You need to verify that the OpenSSL version has been updated.

1. Check Server Version: Access the server and run openssl version.
2. Verify Patch Level: Ensure the version is 1.0.1g or later (the patched version).

openssl version

Example output:

OpenSSL 1.0.2k  3 Mar 2015

Limitations

• Past Vulnerability: Scanners only detect if the server was vulnerable at the time of scanning. They can’t tell you if it was exploited in the past.
• Caching: Some servers cache TLS handshake information, potentially giving a false negative result if the scan is performed after a patch but before the cache is cleared.
• Reverse Proxies/Load Balancers: If a reverse proxy or load balancer sits in front of the server, the scanner might be testing the proxy instead of the actual web server.

Further Steps

• Private Key Rotation: Even after patching, consider rotating your private keys as a precaution if you suspect exploitation.
• Certificate Revocation: If you believe your certificate was compromised, revoke it and issue a new one.