What is Exploiting Heartbleed?
Overview
Heartbleed is a bug in OpenSSL’s Heartbeat extension implementation. It’s just an OpenSSL extension that keeps the session alive for HTTPS connections, similar to the Keep-Alive header in HTTP.According to the RFC, the formal structure of Heartbeat is:
This is request/ response pair. The code for the Heartbeat packet is:
Struct
{ HeartbeatMessageType type; //length 1 Byte
uint16 payload_length; // length 2 Bytes
opaque payload[HeartbeatMessage.payload_length];
opaque padding[padding_length];
} HeartbeatMessage;
Where the message type is 1 byte long, the Payload is 3 bytes long and the rest are padding lengths. The payload variable appears to be vulnerable. Ideally, the code must check the length of the payload data against the actual length of the data sent in the Heartbeat request. So if the payload exceeds the standard length in the request, the server may return more data in the response than it should ideally return.
This is a buffer overflow (BoF) case. Note the following vulnerable code:
[simple]
p = &s->s3->rrec.data[0]
…..
buffer = OPENSSL_malloc(1 + 2 + payload + padding);
bp = buffer;
…….
memcpy(bp, pl, payload);
[/simple]
The rrec file contains all incoming request data. The code reads the data. The
the first byte is used to check if it is a Heartbeat protocol, and then the next 2 bytes determine the length of the Heartbeat payload. Ideally, the length must be equal to the payload sent in the Heartbeat request. As mentioned above, the code does not check the actual length sent in the Heartbeat request. So the code copies the amount of data required by incoming requests to the outgoing server’s response (see the memcpy function), and in some cases possibly more than required. This can leak valuable information such as session IDs, tokens, keys, etc. to attackers.
The fix for this bug is to check the payload length, which should not exceed 16 bytes.
What can escape?
So, as said earlier, a lot of sensitive information can be sent from the server’s memory through the response. Some of them are session related information like session ID, various tokens, keys and some other sensitive internal information like queries, internal data etc. A real example shows what we can receive in the responses:
Exploitation
The easiest way is to hijack the session of an already logged in user.Since we can get all the session IDs and possible csrf tokens, we can hijack the user’s session. However, in my case it was very laborious and had some limitations:
- I had to collect a bunch of session IDs, tokens, and other dependencies needed to login.
- It’s a trial and error method as session IDs can be old/invalid/cached.
- Once a valid session ID is detected, hijacking is possible.
The first step was to collect as many session IDs as possible, along with their corresponding nuances, if any. The main problem was that sometimes they expired / were not valid, so we had a really hard time building a valid cookie. But keep trying. One of the valid cookies I was able to compile:
Related article:Ethical Hacking Interview Questions 2023
Now you know what to do. Just try to access the internal page of the vulnerable site and replay the cookie. The website was using the vulnerable version, which was also confirmed by the response header:
And replaying the supposedly valid cookie and trying to access the internal page enters us into someone’s profile:
