Wild at Heart: Were Intelligence Agencies Using Heartbleed in November 2013?

Yesterday afternoon, Ars Technica published a story reporting two possible logs of Heartbleed attacks occurring in the wild, months before Monday’s public disclosure of the vulnerability. It would be very bad news if these stories were true, indicating that blackhats and/or intelligence agencies may have had a long period when they knew about the attack and could use it at their leisure.

In response to the story, EFF called for further evidence of Heartbleed attacks in the wild prior to Monday. The first thing we learned was that the SeaCat report was a possible false positive; the pattern in their logs looks like it could be caused by ErrataSec’s masscan software, and indeed one of the source IPs was ErrataSec.

The second log seems much more troubling. We have spoken to Ars Technica’s second source, Terrence Koeman, who reports finding some inbound packets, immediately following the setup and termination of a normal handshake, containing another Client Hello message followed by the TCP payload bytes 18 03 02 00 03 01 40 00 in ingress packet logs from November 2013. These bytes are a TLS Heartbeat with contradictory length fields, and are the same as those in the widely circulated proof-of-concept exploit.

Koeman’s logs had been stored on magnetic tape in a vault. The source IP addresses for the attack were 193.104.110.12 and 193.104.110.20. Interestingly, those two IP addresses appear to be part of a larger botnet that has been systematically attempting to record most or all of the conversations on Freenode and a number of other IRC networks. This is an activity that makes a little more sense for intelligence agencies than for commercial or lifestyle malware developers.

To reach a firmer conclusion about Heartbleed’s history, it would be best for the networking community to try to replicate Koeman’s findings. Any network operators who have extensive TLS-layer traffic logs can check for malicious heartbeats, which most commonly have a TCP payload of 18 03 02 00 03 01 40 00 or 18 03 01 00 03 01 40 00, although the 0x4000 at the end may be replaced with lower numbers, particularly in implementations that try to read multiple malloc chunk bins.

Network operators might also keep an eye out for other interesting log entries from 193.104.110.* and the other IPs in the related botnet. Who knows what they might find?

A lot of the narratives around Heartbleed have viewed this bug through a worst-case lens, supposing that it might have been used for some time, and that there might be tricks to obtain private keys somewhat reliably with it. At least the first half of that scenario is starting to look likely.