Blue Coat Labs

Labs Blog

A Security Analytics Hunt for Heartbleed Traffic

A Security Analytics Hunt for Heartbleed Traffic

Andrew Brandt, Joe Levy

Retrospectively searching for attack data long after the attack is normally a rough job, because by the time most victims find out about an attack, the data is usually gone. But when you're already keeping every packet that crosses the wire, things get a little easier.

So when news emerged this week about how someone discovered how to use SSL heartbeat requests to data-mine the memory space of servers running vulnerable versions of OpenSSL (including web servers, VPN appliances, routers, proxies, firewalls, etc.), we immediately starting using the Heartbleed proof-of-concept tools to see what it's possible to learn about the attack method, and find not only the attacker(s) and victim(s), but also to uncover what data may have leaked.

What follows are some specific steps you can take to find these poor, abused heartbeat packets, obtain the flows related to the abused packets, and retrieve the packets themselves for further analysis and determination as to what data might actually have been lost.

First, we'll figure out exactly which packets constitute these unexpected heartbeats. To do that, you can select the timeframe you're interested in using that part of the Security Analytics user interface. We recommend go back some days before the attack was publicized to see if you were targeted (or two years back, if you believe the recent conspiracy theories about the NSA’s involvement in this).

Now that the UI is focused on the key range of traffic, export a PCAP -- but don't worry, you won't have to create a massive archive of all the traffic over the time period. In this case, the system just filters the output even more narrowly, so you're exporting only the relevant "Heartbleed"-related SSL packets.

First, click the Actions menu and choose Download PCAP (you can also click the little informational "i" icon along the top of any tab on the Analyze -> Summary page).

Now, before you click the Download button, make a few changes. First, modify the Type dropdown selection to "PCAP without Filters." When you do that, "This PCAP will not be filtered by any of the web-interface filters. To filter this PCAP, specify a BPF filter below."

Just beneath that message, a new dropdown menu will have appeared, as well. Select the item Create New Filter from that new dropdown, labeled Filter.

In the following two fields, you name and define your filter. I called mine "Heartbleed heartbeat packets" but you can call it "Worst Internet attack of all time. OF ALL TIME packets" if you care to.

The BPF filter text is:

tcp[((tcp[12:1] & 0xf0) >> 2):2] = 0x1803 && tcp[((tcp[12:1] & 0xf0) >> 2) + 2] < 0x04 && tcp[(((tcp[12:1] & 0xf0) >> 2) + 3):2] = 0x0003 && tcp[((tcp[12:1] & 0xf0) >> 2) + 5] = 0x01 && tcp[(((tcp[12:1] & 0xf0) >> 2) + 6):2] > 0x64

With this filter in place, clicking the Download button both begins the process of a BPF-filtered PCAP download and saves this filter for later re-use in the Filter dropdown menu

We have tested this filter against a broad set of sample Heartbleed attack traffic, and while it has been tuned to reduce false positives and false negatives, you may further customize it by including key IP address filters (e.g. critical SSL servers) or by tuning the final “0x64” value to designate larger or smaller HeartBeat request sizes.

Here's what it will do: It produces a pcap containing every packet which bears the characteristics identified in the BPF filter. Each of these packets can be thought of as a pointer to each flow where a Heartbleed attack occurred. This will be your map to an investigation into what data might have actually been leaked through the exploit. Hopefully, it will be an empty, or a very small pcap.

It will take a little while to chug through the packet store, but eventually, you're presented with a download dialog to get the file.

The naming convention is automatic and follows the pattern of [interfaces]-[time range]-d-filtered.pcap where each interface for which data has been captured in the time range, delimited by hyphens, is prepended to the filename. At this point, re-import this PCAP you just created back into the system.

Click the little icon at the right edge of the imported capture, once the system has indexed its data contents.

Head to the IPv4 responders to obtain the list of IP addresses that were recipients of these packets; The IPv4 initiators report will show you a list of the machines from which the HeartBleed packets originated.

We can do fun things like look at the attack traffic on a map, but we'll make Favorites comprised of a list of either attackers' or attack recipients' IP addresses.

From the report, download a CSV version, open it in your spreadsheet app of choice, and copy out the list of IP addresses. Paste the list into a plain text file, save it with a memorable name, and then switch over to the Favorites management window.

When you import the list, choose the type "List" from the file type menu item. Be sure to choose the right metadata field for your data set, select the file you created, and click the Save button.

Once the Favorite has been created, you simply have to type the Favorite name into the Path Bar; The UI will bring up a report of all communication with the relevant IP addresses (either "bleeder" servers or whatever you'd call something that makes something else bleed -- cutters?).

Diving into the Packet Analyzer, it won't be hard to spot the "Continuation Data" packets full of exposed data. They'll be much larger than a typical SSL handshake, and they might contain sensitive data.

So, hopefully, you don't see any packets like these at all. If you do, it can clue you in to any data leakage by VPNs, switches, Web servers, UPSes, remote access appliances, your internal virtual infrastructure, or any other devices facing the public Internet with an SSL interface. It's also important to keep in mind that this is more than just an HTTPS Web server problem. If you're looking at your infrastructure for stuff like this, any device that's publicly accessible may also have been subject to these attacks. And the attacks may not only have originated from outside your network, but possibly from internal people experimenting with the proof-of-concept tool -- and you probably will want put the kibosh on that pretty quickly.