Heartbleed OpenSSL: Explanation and Exploit

Summary :

1.HeartBleed
1.2. Is it that dangerous ?
1.2.1. Is HeartBleed vulnerability exploit detectable by existing IDS ?
1.2.2. Origins
1.2.3. Who discovered it ?
1.2.4. HeartBleed: But why this strange name ?
1.3. HeartBleed vulnerability identification
1.3.1. Is this the final collapse of SSL ?
1.3.2. What are the vulnerable OpenSSL versions ?
1.4. How could I know if my server is vulnerable ?
1.4.1. Are there available tools to use and check my server ?
1.4.2. I’m not using neither Apache nor Nginx: am I HeartBleed free ?
1.5. My server is HeartBleed vulnerable: what should I do ?
2. Technical details
2.1. Introduction to SSL & TLS protocols
2.1.1. SSL/TLS handshake protocol
2.2. HeartBeat extension
2.2.1. Heartbeat Hello format
2.2.2. Heartbeat protocol
2.2.3. HeartBeat message specification
3. Proof of concept
3.1. Code organization
3.2 Fetched results
3.2.1 Note on the performane of the program
3.3. Conclusion
Bibliography

 

1. HeartBleed:

With the growth of Internet, security holes have risen allowing miscreants to harm trusted systems or attack innocent users. Nevertheless, as we are going to see throughout this article, Internet has also become the victim of its own development..

Groundbreaking, serious, dangerous … that’s how security experts qualify the HeartBleed vulnerability that has been made public on April 7th, 2014. [1]

The aim of this article is to go behind the scoop to check the ins and outs of the vulnerability so as to answer the questions that our HTTPCS clients might ask and to which they could not necessarily find answers elsewhere; this will be the subject of the first section of our article. After that, we’ll dive into the technical realms from which this bug exudes. Finally we’ll demonstrate a proof of concept on how to exploit this vulnerability in order to render HTTPCS clients (even if HTTPCS web vulnerability scanner has the detection mechanism embedded within it) aware of the dangerousness of HeartBleed and how to remedy to it.

1.2. Is it that dangerous?

Theoretically , we could sweep up the whole server’s memory and fetch all the data it stores including the sensitive one such as X.509 certificates without the need for any particular high user privileges.[2]

1.2.1.Is HeartBleed vulnerability exploit detectable by existing IDS?

No. And that is one of the reasons HeartBleed is qualified as being so dangerous by security experts.

1.2.2. Origins

HeartBleed was first introduced by Stephen Henson just an hour before 2011 new year’s Eve (has not he something else to do at this time ? 😄). To be more accurate it’s Robin Seggelmann, who was then a Ph.D. student at Duisburg-Essen University who developed the HeartBeat extension for OpenSSL (HeartBeat was already present in SSL2.0 specification) and suggested it to the OpenSSL lead developer project Stephen Henson who failed (did he ever check ?) to find the bug and comitted it on its repository. Others suggest that this vulnerability was known and exploited long time ago before it is announced publicly.

1.2.3. Who discovered it?

HeartBleed was announced on April 7th, 2014 par Neel Mehta who’s working to Google Security group and recommended to upgrade OpenSSL version.[1]. Two of his colleagues implemented the solution. However, the world leading fuzzing solution Finnish company Codenomicon also discovered the bug at the same time independently from Google Security group. Since Americans are more talented in communication, it is not flabbergasting to read everywhere that it’s Google Group that discovered HeartBleed. A good news to remedy to this unfairness is that Codenomicon has designed the famous HeartBleed logo and created the first website dedicated to it.

1.2.4. HeartBleed: But why this strange name?

That’s an interesting question. At least if you’re curious 😏 . To understand how a server’s heart could bleed, all what you need is to be patient until we’ll explore the HeartBeat extention through section 2.

1.3. HeartBleed vulnerability identification

If you’re a developer, you might be curious to know where the vulnerability does lay. If so, go to Github and search for OpenSSL’s project repository and browse through this path:

• openssl -> openssl -> blob -> master -> ssl -> t1_lib.c

You can also simply click on this link, where you can find the source of the bug on the line number 1480 of code in front of your eyes:

• buffer = OPENSSL_malloc(1 + 2 + payload + padding);

The problem is that this line performs memory allocation without boundaries check. An attacker has the full control over the size of the variables payload and padding. That’s where the whole problem comes from.

1.3.1. Is this the final collapse of SSL?

No. One must remember that SSL is only a protocol specification. The problem is not the standard itself but its various implementations. Precisely, it’s only the OpenSSL implementation of SSL that suffers from HeartBleed bug.

1.3.2. What are the vulnerable OpenSSL versions?

From version 1.0.1 (March 14, 2012) to version 1.0.2 (February 24, 2014 (beta)).

• 1.0.1 (March 14th,) à 1.0.2 (February 24th)

Of course, this includes the whole OpenSSL 1.0.1ω versions , where ω ∈ {a, b, c, d, e, f}.

 

1.4. How could I know if my server is vulnerable?

Now that you know only OpenSSL implementation of the SSL/TLS protocols is affected by this bug, you could guess logically that only the web servers using OpenSSL are concerned.

If you belong to this majority of people who’re using Apache or Nginx web servers, you are likely to be vulnerable. In fact, a recent survey shows that 70% of the existing servers relay on Apache or Nginx: [3]

 

According to an other survey , 17.5% of servers have enabled the HeartBeat extension before HeartBleed has been discovered [4]. We insist again: if your machines are not using Apache or Ngnix, there is no reason to worry about HeartBleed vulnerability. For instance, you may use IIS (Internet Information Services) which is MicroSoft server that does not utilize OpenSSL but has its own SSL implementation called SChannel which does not implement HeartBeat extension the same way OpenSSL does.

 

 

1.4.1. Are there available tools to use and check my server?

Application and online tools are already developed for this purpose. HTTPCS scanner has developed its own tool embedded within it. We relaeased here a proof of concept that you can use to test if your server is HeartBleed affected or not.

1.4.2. I’m not using neither Apache nor Nginx: am I HeartBleed free?

Not really. Well, it depends … you have to carefully check your network’s architecture. Maybe a good example to explain you this is to mention the case of the administrators of the famous website StackOverFlow that are running all their .NET applications on Microsoft IIS servers [5] whereas load balancing is monitored by HAProxy reverse proxy and the SSL termination is nothing else than an Nginx server. To sum up the situation, you need to carefully to check your network’s architecture even if it seems to you that obviously you’re not using Apache or Nginx.

1.5. My server is HeartBleed vulnerable: what should I do?

Obviously, you have to upgrade your OpenSSL version to the current one (1.0.1g). On your Debian-like machine, you can run this command:

• sudo apt -get install openssl -server

If you don’t want to use a new OpenSSL version, you can simply correct the bug yourself (check the boundaries before allocating the memory for payload and padding variables), compile your software and you’re done.

2. Technical details

2.1. Introduction to SSL & TLS protocols

SSL protocol was developed on 1994 by NetScape. It started with the version SSL2.0 in order to secure online payments [6]. However, due to several vulnerabilities found, SSL3.0 version was soon released. On the same year (1999), TLS protocol appeared and was implemented in its first version TLS1.0 which is nothing more than SSL3.0 upgrade.

2.1.1. SSL/TLS handshake protocol

SSL/TLS provides encryption, authentication and integrity for data being in exchange on Internet.

SSL/TLS-handshake protocol is a set of a three way TCP-handshake followed by a set of more or less complicated series and calculations to perform where important elements are negociated between the peers needing to communicate with each other :encryption types and algorithms, authentication, key exchange and secure session establishment . Because this procedure is heavy to perform for each new connexion request, a new technique was developed for TCP and HTTP protocols: it is called keep-alive; this allows to maintain a session so as several requests can be performed without the need to redo the whole process shown on the following schema. SSL/TLS protocol has developed a similar concept that can do that in a higher rate thanks to the HeartBeat extension.

 

 

2.2.HeartBeat extension :

HeartBeat is an add-on added to SSL/TLS protocol so as to keep alive a communication session between 2 peers during the required period of time. It also permits to check whether a machine is on or off before deciding to send to it data as it is the case with DTLS protocol.

2.2.1. Heartbeat Hello format

A machine can inform an other machine that it supports the HeartBeat extension and whether it accepts or not to receive HeartBeat answers to its HeartBeat requests thanks to this data structure:

enum {
peer_allowed_to_send (1),
peer_not_allowed_to_send (2),
(255)
} HeartbeatMode;

struct {
HeartbeatMode mode;
} HeartbeatExtension;

2.2.2. Heartbeat protocol

The HeartBeat protocol is defined following these 2 main messages:

enum {
heartbeat_request(1),
heartbeat_response (2),
(255)
} HeartbeatMessageType

The total length of a HeartBeat message can not exceed 64 KB, i.e. the max_fragment_length [7] length. The nature and content of a HeartBeatMessageType is shown on the following subsection.

2.2.3. HeartBeat message specification:

struct {
HeartbeatMessageType type;
uint16 payload_length;
opaque payload[HeartbeatMessage.payload_length];
opaque padding[padding_length];
} HeartbeatMessage;

Where:

Type: heartbeat_request/heartbeat_response.
Payload: arbitrary content.
Padding: arbitrary content that is always ignored by the receiver.The length of the type field is 1 byte, and the length of the payload_length is 2.
padding_length=TLSPlaintext.length – payload_length – 3 for TLS
and
DTLSPlaintext.length- payload_length – 3 for DTLS.
padding_length>=16. [8]

3. Proof of concept

3.1. Code organization

3.2. Fetched results

After running the program:

 

… we have retrieved the following data (we’re showing a very small data sample):

 

3.2.1. Note on the performane of the program

If you want to read a large amount of your servers’s memory, you may change the program so as it can run endlessly (for instance, until a keyboard is pressed).

3.3. Conclusion

Performing an upgrade in this case is a must however, as this bug taught us, upgrading could lead to new security bugs.

Open source software is supposed to be safer than the proprietary one, nevertheless we must be highly informed about the consistence and the quality of the software we want to use. For instance, being aware that OpenSSL is developed by 2 developers of which only is working full time, could help to be more careful about using OpenSSL and maybe review the code ourselves.

We think that open source software can be used only if it is supported by a large developers community.

Coming back to HeartBleed vulnerability, as we said before, you must upgrade your OpenSSL version. That is the way to feel safe … until the next bug !

Bibliography

[1]: OpenSSL Security Advisory Neel MEHTA, https://www.openssl.org/news/secadv/20140407.txt, April 7th , 2014
[2]: The Heartbleed Bug, Codenomicon, http://heartbleed.com/ , April 7th , 2014
[3]: April 2014 Web Server Survey, NetCraft, http://news.netcraft.com/archives/2014/04/02/april-2014-web-server-survey.html , April , 2014
[4]: Half a million widely trusted websites vulnerable to Heartbleed bug, NetCraft, http://news.netcraft.com/archives/2014/04/08/half-a-million-widely-trusted-websites-vulnerable-to-heartbleed-bug.html , April, 2014
[5]: Stackoverflow.com: the road to SSL, Nick Craver, http://nickcraver.com/blog/2013/04/23/stackoverflowcom-the-road-to-ssl/, April 23rd, 2013
[6]: History of SSL, IBM, http://publib.boulder.ibm.com/infocenter/iseries/v5r3/index.jsp?topic=%2Frzain%2Frzainhistory.htm
[7]: RFC 6066: Transport Layer Security (TLS) Extensions: Extension Definitions IETF, http://tools.ietf.org/html/rfc6066, Page 8, January, 2011
[8]: RFC 6520: Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS) Heartbeat Extension IETF, http://tools.ietf.org/html/rfc6520, Page 5, February, 2012
[9]: RFC 6101: The Secure Sockets Layer (SSL) Protocol Version 3.0, http://tools.ietf.org/html/rfc6101, August 2011

Test the security of my site