Detecting the heartbleed bug using Bro

In TLS the payload size of a heartbeat packet and the size of the whole packet is specified in two different places. The heartbleed attack exploits the fact – vulnerable OpenSSL versions return random bits of server memory, when the request packet specified that the payload size is bigger then the size of the whole data packet.

Bro can detect this attack in several different ways. In the simplest incarnation, which is the only one we have seen in the wild so far, the heartbeat message is sent very early, before the TLS encryption kicks in.

In these cases, Bro just compares the payload and message sizes. If there is a mismatch, we know that an exploit has been tried. If the server responds to the message it very probably was vulnerable to the attack.

In theory, the attack also can take place after the TLS encryption started. In this case, we only know the message size, the payload size in the request is encrypted.

In these cases, we use several different heuristics to deduce when an attack is taking place. We count the numbers of heartbeats sent by the client and the server. If there is a divergence of more than a few packets, an attack is likely.

We also check if TLS heartbeat messages are smaller then the minimal length they are required to have, which probably also is only the case in an attack. Furthermore, we check if the encrypted heartbeat packets returned by the server have the same size as the packets sent by the client. If they diverge, the server is returning more data than the client sent in the first place — which only can happen due to this attack.