The HeartBleed Bug 04-12-2014, 09:00 AM
#1
The HeartBleed Bug
Recently, this new bug (but almost 2 years old :troll
in the OpenSSL library used in most servers surfaced and this is no ordinary bug. Yes!! It affects a major share of websites and poses a threat to numerous internet users' online safety. Even Yahoo was vulnerable to it (Fixed now).
"The Heartbleed bug allows anyone on the Internet to read the memory of the systems protected by the vulnerable versions of the OpenSSL software."
OpenSSL versions 1.0.1 through 1.0.1f (inclusive) are vulnerable and can user ids and password are easily leaked due to this bug.
Now, what exactly is this bug?
I was searching for the bug, its cause, and the fix for, but ended up in boring news headlines that just said what we already know. ie. OpenSSL got a bug and leaks sensitive credentials, but not a single of them explained the real thing behind it. Finally, Fb1h2s (Rahul Sasi) explained everything on his blog and now I share the same with HackCommunity members.
Heartbleed.com says "Bug is in the OpenSSL's implementation of the TLS/DTLS (transport layer security protocols) heartbeat extension (RFC6520). When it is exploited it leads to the leak of memory contents from the server to the client and from the client to the server."
So, whats wrong in the implementation of this extension?
In an established SSL connection, it is required that the connection be maintained for a longer time. And this is the reason the Heartbeat extension is used. (As long as the heart beats, there is life :Nerd
Its same as the HTTP keep-alive feature which holds the connection for a long time. But Heartbeat protocol allows a client to perform this action in much higher rate. So, client sends a HeartBeat request and the server has to respond back with a HeartBeat response (Its a simple request and response module in short).
The client can send a Heart-Beat request message and the server has to respond back with a HeartBeat response. Simple.
This is the actual protocol used:
And the TLS packet with HeartBeat addon or extension whatever you say (I can't differentiate between the two even when using Mozilla Firefox. :Yuck
And the shitty bug is this one:
A bad malloc. Insecure one, as memory is allocated from the payload + padding which is a user controlled value without any length checking algo for this allocation. This enabled a hacker to force the Openssl server to read arbitrary memory locations.
And the result?
This comic strip explains this best :Laughing::
![[Image: heartbleed_explanation.png]](http://bappamehendi.com/images/heartbleed_explanation.png)
"The total length of a HeartbeatMessage does NOT exceed 2^14 or max_fragment_length when negotiated as defined in [RFC6066]. Here we are only able to leak 64 kb of memory and that could easily have usernames/password etc." - says Fb1h2s. Its right. Constant HB request could be made to the server leaking (random memory) any amount of data from the server .
Now, the Fix to this bug.
If we implement a bounds check the payload + padding that is <= 16 bytes, the bug hangs itself to death. Isn't it? :Nerd:
Like this:
And yes, the HeartBleed length should be made not to exceed the Max Length.
Oops, I forgot to mention something.
Some Linux based OS, that use this vulnerable OpenSSL version (like Ubuntu 12.04.4 and some versions of CentOS) are vulnerable to this bug. And yes, a major part of the world's Android users are also vulnerable [Version 4.1.1 is Vulnerable and isn't patched till this post was last updated]. :troll:
Regards.
Recently, this new bug (but almost 2 years old :troll
in the OpenSSL library used in most servers surfaced and this is no ordinary bug. Yes!! It affects a major share of websites and poses a threat to numerous internet users' online safety. Even Yahoo was vulnerable to it (Fixed now). "The Heartbleed bug allows anyone on the Internet to read the memory of the systems protected by the vulnerable versions of the OpenSSL software."
OpenSSL versions 1.0.1 through 1.0.1f (inclusive) are vulnerable and can user ids and password are easily leaked due to this bug.
Now, what exactly is this bug?
I was searching for the bug, its cause, and the fix for, but ended up in boring news headlines that just said what we already know. ie. OpenSSL got a bug and leaks sensitive credentials, but not a single of them explained the real thing behind it. Finally, Fb1h2s (Rahul Sasi) explained everything on his blog and now I share the same with HackCommunity members.
Heartbleed.com says "Bug is in the OpenSSL's implementation of the TLS/DTLS (transport layer security protocols) heartbeat extension (RFC6520). When it is exploited it leads to the leak of memory contents from the server to the client and from the client to the server."
So, whats wrong in the implementation of this extension?
In an established SSL connection, it is required that the connection be maintained for a longer time. And this is the reason the Heartbeat extension is used. (As long as the heart beats, there is life :Nerd
Its same as the HTTP keep-alive feature which holds the connection for a long time. But Heartbeat protocol allows a client to perform this action in much higher rate. So, client sends a HeartBeat request and the server has to respond back with a HeartBeat response (Its a simple request and response module in short).The client can send a Heart-Beat request message and the server has to respond back with a HeartBeat response. Simple.
Code:
heartbeat_request(1),
heartbeat_response(2),This is the actual protocol used:
Code:
struct {
HeartbeatMessageType type;
uint16 payload_length;
opaque payload[HeartbeatMessage.payload_length];
opaque padding[padding_length];
} HeartbeatMessage;And the TLS packet with HeartBeat addon or extension whatever you say (I can't differentiate between the two even when using Mozilla Firefox. :Yuck

Code:
const unsigned char good_data_2[] = {
// TLS record
0x16, // Content Type: Handshake
0x03, 0x01, // Version: TLS 1.0
0x00, 0x6c, // Length (use for bounds checking)
// Handshake
0x01, // Handshake Type: Client Hello Hi Namaste
0x00, 0x00, 0x68, // Length (use for bounds checking)
0x03, 0x03, // Version: TLS 1.2
// Random (32 bytes fixed length)
0xb6, 0xb2, 0x6a, 0xfb, 0x55, 0x5e, 0x03, 0xd5,
0x65, 0xa3, 0x6a, 0xf0, 0x5e, 0xa5, 0x43, 0x02,
0x93, 0xb9, 0x59, 0xa7, 0x54, 0xc3, 0xdd, 0x78,
0x57, 0x58, 0x34, 0xc5, 0x82, 0xfd, 0x53, 0xd1,
0x00, // Session ID Length (skip past this much)
0x00, 0x04, // Cipher Suites Length (skip past this much)
0x00, 0x01, // NULL-MD5
0x00, 0xff, // RENEGOTIATION INFO SCSV
0x01, // Compression Methods Length (skip past this much)
0x00, // NULL
0x00, 0x3b, // Extensions Length (use for bounds checking)
// Extension
0x00, 0x00, // Extension Type: Server Name (check extension type)
0x00, 0x0e, // Length (use for bounds checking)
0x00, 0x0c, // Server Name Indication Length
0x00, // Server Name Type: host_name (check server name type)
0x00, 0x09, // Length (length of your data)
// "localhost" (data your after)
0x6c, 0x6f, 0x63, 0x61, 0x6c, 0x68, 0x6f, 0x73, 0x74,
// Extension
0x00, 0x0d, // Extension Type: Signature Algorithms (check extension type)
0x00, 0x20, // Length (skip past since this is the wrong extension)
// Data
0x00, 0x1e, 0x06, 0x01, 0x06, 0x02, 0x06, 0x03,
0x05, 0x01, 0x05, 0x02, 0x05, 0x03, 0x04, 0x01,
0x04, 0x02, 0x04, 0x03, 0x03, 0x01, 0x03, 0x02,
0x03, 0x03, 0x02, 0x01, 0x02, 0x02, 0x02, 0x03,
// Extension
0x00, 0x0f, // Extension Type: Heart Beat (check extension type)
0x00, 0x01, // Length (skip past since this is the wrong extension)
0x01 // Mode: Peer allows to send requests
};And the shitty bug is this one:
Code:
buffer = OPENSSL_malloc(1 + 2 + payload + padding);A bad malloc. Insecure one, as memory is allocated from the payload + padding which is a user controlled value without any length checking algo for this allocation. This enabled a hacker to force the Openssl server to read arbitrary memory locations.
And the result?
This comic strip explains this best :Laughing::
![[Image: heartbleed_explanation.png]](http://bappamehendi.com/images/heartbleed_explanation.png)
"The total length of a HeartbeatMessage does NOT exceed 2^14 or max_fragment_length when negotiated as defined in [RFC6066]. Here we are only able to leak 64 kb of memory and that could easily have usernames/password etc." - says Fb1h2s. Its right. Constant HB request could be made to the server leaking (random memory) any amount of data from the server .
Now, the Fix to this bug.
If we implement a bounds check the payload + padding that is <= 16 bytes, the bug hangs itself to death. Isn't it? :Nerd:
Like this:
Code:
unsigned int write_length = 1 /* heartbeat type */ +
+ 2 /* heartbeat length */ +
+ payload + padding;And yes, the HeartBleed length should be made not to exceed the Max Length.
Code:
unsigned int write_length = 1 /* heartbeat type */ +
+ 2 /* heartbeat length */ +
+ payload + padding;
+ if (write_length > SSL3_RT_MAX_PLAIN_LENGTH)
+ return 0;Oops, I forgot to mention something.
Some Linux based OS, that use this vulnerable OpenSSL version (like Ubuntu 12.04.4 and some versions of CentOS) are vulnerable to this bug. And yes, a major part of the world's Android users are also vulnerable [Version 4.1.1 is Vulnerable and isn't patched till this post was last updated]. :troll:
Regards.
![[Image: MUJ8qSW.png]](http://i.imgur.com/MUJ8qSW.png)
-----------------------------------
Now learning:
Android Development, Java
Working on:
An FTP Client for Android
-----------------------------------


![[+]](https://sinister.li/images/modern/collapse_collapsed.png)

