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:
- A malicious Heartbeat request is sent.
- 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
[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
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.