Blue Coat Labs

Labs Blog

BPF's Limitations Detecting Heartbleed Traffic

BPF's Limitations Detecting Heartbleed Traffic

Andrew Brandt, Joe Levy

In a previous blog post, I wrote about a Berkeley Packet Filter (BPF) rule that was able to detect a specific version of the attack methodology employed by the proof-of-concept attack. That BPF filter was created with a very narrow focus on a particular set of bytes inside of individual packets, which themselves were indicative of an attack in progress in the format employed by the released POC.

The tight construction of the BPF rule meant two things: (1) it was very resilient against false positives (that is, it could only trigger on true attack packets issued by the POC tool); unfortunately, (2) it is not capable of identifying the attack packets that have been created after the POC was released, when coders began toying with the attack and changing the packets, even slightly, to evade detection by filters like the one we and other folks published.

Part of the problem lies in the limitations of BPF syntax, which basically specifies the binary data values of individual bytes within a packet at offsets from the beginning of the packet. It's a bit like giving someone directions to the bank, but always using the same starting point and by using dead reckoning (go two blocks west then five blocks east, etc.). A more complete treatment of the BPF filter method was composed by PJ Malloy of Riverbed, published on his blog.

The reality of BPF filtering is that it is a wholly unsatisfactory method for the task of finding every conceivable permutation of the attack traffic which may cross the wires. Change a single byte in the attack packet, and a tightly-written BPF filter rule will miss that attack; Write a looser, more flexible BPF rule and you end up alerting on false positives.

Limiting the BPF rule to specific ports is also a conundrum. If you write a BPF filter rule that looks just at traffic on port 443, you will miss the attacks against SSH on port 22, or on devices with management ports on port 8082 or 11344, for example. Alternatively, you could use DPI to determine which ports were used for SSL, and craft complex OR statements in BPF syntax, but then it gets even more complex, which could also increase the likelihood of inadvertent syntax errors in an already complex BPF rule, or a false positive result.

To that end, the Security Analytics team has been working on deep packet inspection (DPI) tweaks and rules that will permit the DPI engine in Security Analytics to identify not only the initial attack packets, but also the responses, regardless of the attack method employed.

It's also worth mentioning that once the exploit is used during the encrypted part of the session, then DPI methods won't work as the encryption will prevent matching on a signature. To be able to check for a malformed TLS Hearbeat, you would need to be a man-in-the-middle on the SSL session, decrypting and re-encrypting the traffic.

The update to Security Analytics will give customers the ability to not only detect fresh attacks (both in the encrypted and unencrypted form), but also to retrospectively determine when attacks occurred in the past. Security Analytics can today reveal any data that might have leaked as a result of the unencrypted form of the attacks, and, where the SSL visibility appliance is installed, what data might have leaked as a result of attacks inside the encrypted packets.

In addition, the update also includes the ability to index the serial numbers of SSL certificates, so customers of Security Analytics will be able to search for critical certificates that might have been revoked -- and all of that will be re-indexed from the existing packet data stored on the appliance, retrospectively.

So, stay tuned, and keep an eye on this blog for further updates.