- The Heartbleed bug disclosed in 2014 allowed hackers to access sensitive data from vulnerable OpenSSL servers. It was caused by a failure to implement proper input validation in the OpenSSL TLS heartbeat extension. This allowed attackers to retrieve up to 64KB of server memory with each request, potentially exposing private keys, user credentials, and other confidential information. Upgrading to OpenSSL 1.0.1g resolved the vulnerability by implementing the missing bounds check.

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.
• type : 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
1) https://lastpass.com/heartbleed/
2) https://filippo.io/Heartbleed/

22. jaipur.manipal.edu

23. ams.muj.edu.in

24. Question ??

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