Yet Another HeartBleed Analysis (Bonus: Incident Response):
Any device implementing OpenSSL 1.0.1 through 1.0.1f.
How it Works
Heartbeat is an extension of the TLS/DTLS protocol.
The heartbeat is used as a keep-alive function without having to re-neg(otiate).
The attack allows someone to get ~64KB of memory from a server running OpenSSL.
This exploit is used by a malformed Heartbeat packet with a specific payload length request.
Most exploit scripts were set to ask for 16,834 bytes [40:00]
But this can be set to ask for between 0 and 65,535 bytes.
Actual Heartbeat Breakdown:
- OpenSSL receives a heartbeat
- OpenSSL reads the payload length, plus some user-supplied data (in the heartbeat)
- OpenSSL packages the payload length, user-supplied data, and ~16 bytes of padding (This is where the server allocates ~64KB of memory to send a response.
- OpenSSL sends the data back to the user (keeps session alive).
- A SSL handshake Hello is sent by user (telling server to expect heartbeat)
- The malformed heartbeat is sent with the following notable changes:
- Payload Length will be quite large (scripts initially set to 16,384)
- There will be NO user-supplied data after the length (you might still see some frame trailer bytes)
- Server will allocate the memory based upon the payload length (in the heartbeat)
- Server will send that memory out to requester. (This is the exfil)
There are some caveats about the memory that is being exfiltrated:
- OpenSSL will only have access to certain portions of memory.
- The maximum amount of memory returned (per successful exploit) is ~65,534 bytes.
- It is all dependent on what’s in the memory buffer (that’s next to OpenSSL) of the server receiving this packet.
To identify the scope of your compromise you will need a lot of PCAP visibility and some variant of SNORT/IDS rules along with some logs that identify:
- All the heartbleed exploit successes/attempts.
- Show the malicious IPs (for eradication).
- Show internal IPs (for eradication).
Wireshark filters and SNORT rules to help in identifying heartbleed attempts:
(ssl[0:2]==18:03 and (ssl[2:1]==00 or ssl[2:1]==01 or ssl[2:1]==02 or ssl[2:1]==03) and ssl[3:2]==0003 and ssl[5:1]==01 and ssl[6:2]>16)
ssl.heartbeat_message && ssl.record.content_type == 24 && ssl.record.length == 3 && ssl.heartbeat_message.type == 1 && ssl.heartbeat_message.payload_length > 16
SNORT Rule (You might have to tweak this depending on your infrastructure’s setup):
alert TCP any any -> any 443 (sid:0000; msg:"Heartbeat_Exploit_Attempt"; flow:to_server; content:"|18 03|"; depth:2; byte_test:1,<,4,0,relative; content:"|00 03 01|"; depth:6; byte_test:2,>,16,0,relative;)
Wireshark filters and SNORT rules to help in identifying heartbleed successes:
ssl.heartbeat_message && ssl.record.content_type == 24 && ssl.record.length > 16
(ssl[0:2]==18:03 and (ssl[2:1]==00 or ssl[2:1]==01 or ssl[2:1]==02 or ssl[2:1]==03)) and ssl[3:2]>0016
SNORT Rule (Again; you might have to tweak to your infrastructure):
alert TCP any 443 -> any any (sid:0001; msg:"Heartbleed_Exploit_Success"; flow:to_client; content:"|18 03|"; depth:2; byte_test:1,<,4,3,relative; byte_test:2,>,16,4,relative; dsize:>20;)
Containment of exfiltrated data is heavily dependent on the server exploited. But you definitely will want to gather the following data:
- All of the Malicious IPs involved (for eradication).
- All of the SUCCESSFULLY exploited internal IPs (for eradication).
- Check what user(s), roles, passwords, and certificates could possibly show up in that server.
- Sift through all the exfiltrated data and quantify what might have been compromised.
To properly eradicate / remediate you will want to do all of the following:
- Update all affected software/firmware to OpenSSL1.0.1g (or higher).
- Renew any private keys that were exfilled (if unsure probably best to renew all certificates stored on edge-facing devices.
- Reset passwords to any compromised users/services
- Address any additional risks (if files were exfilled, other scenarios).
If you had to break connections / alter access make sure all previous availability is currently available.
- Gather your team(s).
- Go over all of what you did, what needed to be done, what wasn’t done, etc.
- Evaluate and provide constructive criticism on what was done well, and what wasn’t.
Here’s a list of very useful heartbleed info (there’s TONS on the web):
- RFC of SSL Heartbeat
- More detailed description of exploit:
- Heartbleed website: