Day by day as the complexity in the Internet increasing the vulnerabilities about the security is also increasing. So the knowledge about these flaws has to be spread. So this report discuss about the one of the vulnerability that exists for a long time called ‘Heartbleed’. The purpose of this report is to create awareness about the Heartbleed vulnerability in OpenSSL Library, using which attackers can get access to passwords, private keys or any encrypted data. It explains how Heartbleed works, what code causes data leakage and explains the resolution with code fix. It also explains perform how to perform heartbeat attack.

1. SHIVA SAGAR B
12CO83
HEARTBLEED
a review

2. • It is a critical bug in the OpenSSL's implementation of the TLS/DTLS
heartbeat extension that allows attackers to read portions of the
affected server’s memory, potentially revealing users data, that the
server did not intend to reveal.
• That means data leakage in the Heartbeat protocol implementation,
specifically the OpenSSL implementation of the protocol.
• This bug was independently discovered by a team of security
engineers (Riku, Antti and Matti) at Codenomicon and Neel Mehta of
Google Security, who first reported it to the OpenSSL team.
Heartbleed

3. • Encryption is the backbone of Internet security. It protects users
data, passwords and transaction details from attackers.
• To achieve encryption over Internet, one of the famous and widely
used protocols is HTTPS. HTTPS is simply HTTP over SSL/TLS.
• OpenSSL library provides implementation of cryptographic protocols
such as SSL and TLS. It is open source software written in C
programming language.
Let’s Start with the Internet

4. Common Internet Layer Protocols

5. • The Heartbeat protocol runs on top of the TLS Record Layer and
maintains the connection between the two peers alive requiring them
to exchange a “heartbeat”.
• Negotiates and monitors the availability of a resource.
• It was introduced in 2012 by RPC 6520.
• Platform independent and device scale independent.
• Generates a signal that indicates normal operation or to synchronize
other parts of a system.
The Heartbeat Protocol

6. • Is the device on the other end Up ?
• Device could be server or client.
• Used to achieve active login sessions and website security
certifications.
• Social networks, E-commerce, E-governance, Internet banking.
• The heartbeat extension was introduced because the then-current
TLS/DTLS renegotiation technique to figure out if a peer is still alive
was a costly process.
Usage of Heartbeat Protocol

7. • The Heartbeat extension protocol consists of two message types:
HeartbeatRequest message and HeartbeatResponse message.
• One side of the peer sends HBrequest message to other peer, who
immediately responds with the same message and thus, keeping the
connection alive.
• If no response is received within a specified timeout, the TLS
connection is terminated.
• If the response does not contain the same message, the HBRequest
message is retransmitted for a specified number of retransmissions.
How Heartbeat Protocol Works

8. • Assigns one bit to specify it is a Hbrequest message, 16 bytes for
actual payload and padding and 2 bytes for payload size.
ARGUMENTS of Heartbeat Request:
• Payload: Contains some text information which is generated on both
the ends.
• payload length: Gives the size of the payload.
Heartbeat Request Message

9. • Assigns one bit to specify it is a Hbresponse message, 16 bytes for
actual payload and padding and 2 bytes for payload size.
RESPONSE to the Heartbeat Request:
• Finds the Payload in its active memory.
• Count the number of characters to be sent using payload length.
• Returns the text info.
The first device is acknowledged that the other end is online.
Heartbeat Response Message

10. A Simple Example

11. • No bound check mechanism.
• Maliciously crafted Heartbeat request with mismatching Payload and
payload length arguments would still work.
• For a Hbrequest with small payload value and large payload length,
Hbresponse returns with a extra data from the active memory of the
replying device.
• Provides unauthorised access to data which should have been
hidden and abstracted.
Flaw in the Heartbeat …

12. Malicious Heartbeat Request

13. • By exploiting the Heartbleed vulnerability, an attacker can send a
Heartbeat request message and retrieve up to 64 KB of memory from
the victim's server.
• Could potentially contain usernames, passwords, session IDs or
secret private keys or other sensitive information.
• This attack can be made multiple times without leaving any trace of
it. There is no limit on how many times these 64KB chunks could be
retrieved.
• This bleeding of confidential data can happen to both sides – the
servers as well as the clients.
Impact of the Heartbleed…

14. • require two systems running each one in a Separate Workstation an
attacker system (kali linux) and a vulnernable system (ubuntu 12.04).
• Then, we have to configure the Apache with SSL support on Ubuntu.
Implementation

15. Client Side Data Leakage

16. • All Heartbleed-vulnerable systems should immediately upgrade to
OpenSSL 1.0.1g.
• Implementing the patch by oneself by correcting and re-compiling
the source code.
• . If you are not sure whether an application you want to access is
Heartbleed vulnerable or not, try any one of the Heartbleed detector
tools.
• Stolen security keys need to be revoked and re-allocated.
• An important step is to restart the services that are using OpenSSL
(like HTTPS, SMTP etc.).
Tackling Heartbleed

17. • Open Source Projects should be funded well.
• Open Source makes flaw discovery and correction a faster process.
• Adoption of new piece of code should be accompanied by negative
testing of it.
• You are never completely safe, even if you follow the best practices.
Conclusion

18. THANK YOU