2014/04/13

Yet Another HeartBleed Analysis

by InterDimensional_Shambler
Categories: Analysis, Network Forensics
Tags: No Tags
Comments: Leave a Comment

Yet Another HeartBleed Analysis (Bonus: Incident Response):

By InterDimSham

Preparation

What’s affected

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:

  1. OpenSSL receives a heartbeat
  2. OpenSSL reads the payload length, plus some user-supplied data (in the heartbeat)
  3. 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.
  4. OpenSSL sends the data back to the user (keeps session alive).

Exploit Breakdown:

  1. A SSL handshake Hello is sent by user (telling server to expect heartbeat)
  2. 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)
  3. Server will allocate the memory based upon the payload length (in the heartbeat)
  4. Server will send that memory out to requester. (This is the exfil)

Notes:

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.

Identification

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:

Wireshark Filters:

  • (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:

Wireshark Filters:

  • 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

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.

Eradication

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).

Recovery:

If you had to break connections / alter access make sure all previous availability is currently available.

Lessons Learned

  • 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.

Additional Reference

Here’s a list of very useful heartbleed info (there’s TONS on the web):


Leave a Reply

Your email address will not be published. Required fields are marked *



Today is Friday
2018/02/23