1

It is fairly easy to detect the heartbleed exploit if it all happens over cleartext, which it seems most things are doing for the time being. However, I believe that there are some heartbleed exploits occurring after encryption because the RFC allows (and suggests) that heartbeat requests be sent encrypted.

From RFC 6520:

A HeartbeatRequest message can arrive almost at any time during the lifetime of a connection. Whenever a HeartbeatRequest message is
received, it SHOULD be answered with a corresponding
HeartbeatResponse message.

However, a HeartbeatRequest message SHOULD NOT be sent during
handshakes. If a handshake is initiated while a HeartbeatRequest is
still in flight, the sending peer MUST stop the DTLS retransmission
timer for it. The receiving peer SHOULD discard the message
silently, if it arrives during the handshake. In case of DTLS,
HeartbeatRequest messages from older epochs SHOULD be discarded.

As it states above, a HeartbeatRequest SHOULD NOT be sent during handshakes. It is my assumption that many exploits today are being sent during the handshake in order to be more efficient.

If so, what does a HeartbeatRequest during the handshake look like in comparison to a HeartbeatRequest after it is encrypted, and how can we monitor for and detect post-encryption Heartbleed exploits on the network (not on the endpoint)?

JZeolla
  • 2,966
  • 1
  • 19
  • 25
  • Duplicate of [Check logs for Heartbleed exploit use?](http://security.stackexchange.com/q/55523/2630) If it got encrypted, then it is just like Application Data, you can only infer information from its size but cannot tell what is inside. – Lekensteyn Apr 14 '14 at 18:02
  • @Lekensteyn, that question specifically refers to server logs, whereas mine addresses network traffic. Even the accepted answer, which addresses network traffic, does not address post-encryption network traffic. – JZeolla Apr 15 '14 at 13:08
  • That's why I made the extra comment above. I've now updated the other answer to explain encrypted heartbeats, it seems sufficient duplicate now? – Lekensteyn Apr 15 '14 at 16:03

1 Answers1

2

To be exact, the RFC recommends legit heartbeats be done after handshake completes; it doesn't recommend exploits ever. (Compliant with https://www.rfc-editor.org/rfc/rfc3514 which sadly never made it to BCP.)

Yes, Heartbeat is a distinct record type (24 or 0x18). Any response longer than the request by more than reasonable padding is proof of exploit. Any request or response longer than 2^14 plus epsilon is also bad, and I'd say anything more than about 50 in TLS is suspect because that would only be useful for PMTU and PMTU here is useful only, if at all, for DTLS not TLS. You don't need the plaintext.

Community
  • 1
dave_thompson_085
  • 10,064
  • 1
  • 26
  • 29
  • Edited the wording to be more clear that I was saying that the RFC suggests encrypted heartbeat requests, not encrypted heartbleed exploits. – JZeolla Apr 14 '14 at 12:17