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.
No comments:
Post a Comment