The Heartbleed Attack

This attack was made possible due to a programming vulnerability in OpenSSL libraries. The attack was discovered in 2014. It can help attackers steal very sensitive data like session Ids, cookies, etc.

1. Heartbleed Attack - Shreyas Kothari (140302003) M.Tech (CNIS) Manipal University Jaipur

2. Introduction Heartbleed is a security bug disclosed in April 2014 in the OpenSSL cryptography library, which is a widely used for the implementation of the Transport Layer Security (TLS) protocol.  Heartbleed may be exploited regardless of whether the party using a vulnerable OpenSSL instance for TLS is a server or a client.  It results from improper input validation (due to a missing bounds check) in the implementation of the TLS heartbeat extension,  thus the bug's name derives from " heartbeat”. The vulnerability is classified as a buffer over-read, a situation where more data can be read than should be allowed.

3. OpenSSL OpenSSL is an open-source implementation of the SSL and TLS protocols. The core library, written in the C programming language, implements basic cryptographic functions and provides various utility functions . The OpenSSL project was founded in 1998 to invent a free set of encryption tools for the code used on the Internet. As of 2014 two thirds of all webservers use it.

4. Heartbeat Extension The Heartbeat Extension provides a new protocol for TLS/DTLS allowing the usage of keep-alive functionality without performing a renegotiation. TLS is based on reliable protocols, but there is no feature available to keep the connection alive without continuous data transfer . The Heartbeat Extension overcomes these limitations. The user can use the new HeartbeatRequest message, which has to be answered by the peer with a HeartbeartResponse immediately .

5. Heartbeat Hello Extension A peer cannot only indicate that its implementation supports Heartbeats, it can also choose whether it is willing to receive HeartbeatRequest messages and respond with HeartbeatResponse messages or only willing to send HeartbeatRequest messages. The former is indicated by using peer_allowed_to_send as the HeartbeatMode; the latter is indicated by using peer_not_allowed_to_send as the Heartbeat mode . This decision can be changed with every renegotiation.

6. The Heartbeat Protocol The Heartbeat protocol is a new protocol running on top of the Record Layer . The protocol itself consists of two message types: HeartbeatRequest and HeartbeatResponse . A HeartbeatRequest message can arrive almost at any time during the lifetime of a connection . There must not be more than one HeartbeatRequest message in flight at a time. A HeartbeatRequest message is considered to be in flight until the corresponding HeartbeatResponse message is received , or until the retransmit timer expires.

7. Heartbeat Request / Response Message The Heartbeat protocol messages consist of their type and an arbitrary payload and padding . struct { HeartbeatMessageType type; uint16 payload_length; opaque payload[HeartbeatMessage.payload_length]; opaque padding[padding_length]; } HeartbeatMessage ;

8. Heartbeat Request / Response Message The total length of a HeartbeatMessage must not exceed 2^14 Bytes. t ype : The message type; either heartbeat_request or heartbeat_response. payload_length : The length of the payload. payload : The payload consists of arbitrary content. Padding : It can be any random content and the sender of this message must use at least 16 Bytes of padding.

9. Working When a HeartbeatRequest message is received and sending a HeartbeatResponse is not prohibited, the receiver must send a corresponding HeartbeatResponse message carrying an exact copy of the payload of the received HeartbeatRequest. If a received HeartbeatResponse message does not contain the expected payload , the message must be discarded. If it does contain the expected payload, the retransmission timer must be stopped .

10. The Heartbleed Attack We had discussed earlier in the introduction part that this attack was made possible because of the improper input validation of the TLS Heartbeat extension. The vulnerability lies in the payload variable. Ideally the code must check the payload data length with the actual length of data sent in the Heartbeat request, but it isn’t checking it. So if the payload exceeds the standard length in the request, the server may return more data in response than what it should ideally return.

11. The Heartbleed Attack This is a case of Buffer Overflow (BoF). Look at the following vulnerable code :

12. The Heartbleed Attack The rrec contains all the incoming request data. The code reads the data. The first byte is to check if it’s a Heartbeat protocol and then another 2 bytes determine the length of the Heartbeat payload.  Ideally the length of the payload must be equal to the payload_length sent in the Heartbeat request. But as discussed, the code is not checking actual length sent in the Heartbeat request. 

13. The Heartbleed Attack So the code copies the amount of data requested by incoming requests to the outgoing server response and possibly more than requested in some cases. This may leak valuable information to attackers, such as session IDs, tokens, keys, etc .

14. The Heartbleed Attack Let us try to understand this with the help of one scenario.

15. The Heartbleed Attack

16. The Heartbleed Attack

17. The Heartbleed Attack

18. What can be leaked ? As said earlier, much sensitive information from the server’s memory can be sent in through the response. Some of them are session-related information such as session ID, different tokens, keys, and some other sensitive internal information such as queries, internal data, etc.  The next image shows a real example of what we can receive in the responses.

19. What can be leaked ?

20. Solution This vulnerability lies in the OpenSSL version 1.0.1f and 1.0.2 – beta1. Affected users should upgrade to OpenSSL 1.0.1g. Users unable to immediately upgrade can alternatively recompile OpenSSL with - DOPENSSL_NO_HEARTBEATS. OpenSSL version 1.0.2 will be fixed in 1.0.2 – beta2.

21. To check whether your website is safe visit https ://lastpass.com/heartbleed / https://filippo.io/Heartbleed /

22. jaipur.manipal.edu

23. ams.muj.edu.in

24. Question ??

25. References RFC 6520 - https :// tools.ietf.org/html/rfc6520 www.heartbleed.com Infosec Institute - http ://resources.infosecinstitute.com/exploiting-heartbleed / https://xkcd.com/1354 / https:// www.openssl.org/news/secadv_20140407.txt https://lastpass.com/heartbleed /