How to Check Logs for Heartbleed Exploit Use

How to Check Logs for Heartbleed Exploit Use

According to articles such as the following, it’s apparently possible to check logs for heartbeat requests matching the payloads described in the Heartbleed exploit.

Server operators can check for Heartbleed exploit usage in their own logs. However, from the access logs of a service (nginx, Dovecot, etc.), you cannot see whether you were affected or not. Unless you have previously captured all SSL traffic, you cannot see whether you got attacked in the past either.

The pattern to match in a packet capture is very simple:

1. A malicious Heartbeat request is sent.
2. An overly long Heartbeat response is returned (for buggy versions).

If the Heartbeat request is not encrypted (i.e. it got sent before the handshake is completed), then the data in the transport layer (UDP, TCP or an extra application-specific layer) is:

18       # Content Type Heartbeat 
vv vv    # TLS version (e.g. 03 01 is TLS 1.0, 03 03 is TLS 1.2)
ll ll    # Record length (length of the following data)
01       # Message type (1 = request, 2 = response)
xx xx    # Payload length
[payload]
[at least 16 bytes of padding]

If the payload is not exactly the length xx xx (big-endian), then you were possibly attacked. It would be successful if you get a response back:

18 vv vv    # Same record layer header
ll ll       # Length of following data
02
xx xx       # Same length as requested
[data of length xx xx]

An example command (which requires root) that captures all future data from network interface eth0 until interrupted:

tcpdump -i eth0 'tcp port 443' -w ssl.pcap

You can use Wireshark to investigate the file ssl.pcap. The display filter ssl.heartbeat_message shows all Heartbeats requests and messages. Note: sometimes the SSL filter does not get applied. In that case, right-click a packet, click Decode as.. and select SSL. Since git commit 3f81af22e0116a2f83c0298de7874959b3967da2 (11 April 2014), you can also use the expert filter ssl.heartbeat_message.payload_length.invalid to target malformed Heartbeat requests (if unencrypted).

As for encrypted heartbeats… it is not common to see heartbeats, so when you got one for TCP connections, it already becomes suspicious. Some hints for encrypted heartbeats that may help:

• A heartbeat request followed by gigantic heartbeat responses is a sign of a vulnerable server that was successfully exploited.
• A heartbeat request not followed by a heartbeat response may signal an attempt to exploit the server, but the server is patched and does not respond.
• A heartbeat request followed by an encrypted Alert may signal an attempt to exploit the server, but the server does not run OpenSSL and rejects the invalid request.
• A large number of subsequent heartbeats (even if it is small) may be successful exploitation attempts with small payload lengths.