[unhush]

I helped write this post. Note that we're very interested in anyone who has been keeping raw packet logs from before the Heartbleed vuln. was public. If you find 18 03 (01 | 02 | 03) 00 03 01 in them, please let me know or post pcap files. Contact info: https://www.eff.org/about/staff/yan-zhu

[gojomo]

Are heartbeats typically visible in the raw traffic, or (after some point) do they wind up inside the secured stream?

(If the latter, this could be an unfortunate case where Perfect Forward Security, when enabled, also helps obscure exploits from later forensic discovery...)

[anaphor]

It appears that you might be right, from the RFC:

"However, a HeartbeatRequest message SHOULD NOT be sent during handshakes. If a handshake is initiated while a HeartbeatRequest is still in flight, the sending peer MUST stop the DTLS retransmission timer for it. The receiving peer SHOULD discard the message silently, if it arrives during the handshake. In case of DTLS, HeartbeatRequest messages from older epochs SHOULD be discarded."

But that doesn't make sense to me because the PoC code didn't complete the handshake did it?

Edit: according to Google the reason is that OpenSSL does not honour the "SHOULD" part of the spec :/

[unhush]

In the case of the sample described in the post, there was a TLS handshake that was immediately terminated, followed by a client hello and the heartbeats. The client hello and heartbeats were sent in the clear.

I conjecture that the TLS handshake was used to fingerprint the server, since not all 3 versions of the payload will succeed on all TLS versions.

[kyrra]

VRT (people who maintain a ruleset for Snort) published free rules for detecting Heartbleed attempts. If you read their blog post about it[0] (and the comments), the first 5 bytes of all the Heartbeat messages are unencrypted and you are able to detect the lookup within those first 5 bytes.

[0] http://vrt-blog.snort.org/2014/04/heartbleed-memory-disclosu...