What is Heartbleed vulnerability?
Heartbleed is a vulnerability in OpenSSL cryptography library (written in C) was discovered in 2014. OpenSSL provides Secure Socket Layer (SSL) and Transport Layer Security (TLS) implementation to encrypt the traffic going on the internet. Heartbleed vulnerability is a bug of OpenSSL library’s code that handles the heartbeat extension (RFC 6520) for TLS/DTLS, not a bug either of SSL or TLS protocols. TLS protocol is used to secure reliable protocols like TCP, SMTP, POP3, VoIP, VPN and DTLS (Datagram Transport Layer Protocol) is used to secure unreliable protocol like UDP, DCCP. Using this vulnerability, an attacker can exploit this bug to read memories of vulnerable systems without leaving any evidence of the particular compromised system.
What is heartbeat protocol?
heartbeat protocol is a protocol that running on top of the Record Layer which consists of two message types:
- HeartbeatRequest
- HeartbeatResponse
HeartbeatRequest can arrive any time in the lifetime of the connection from one peer to another peer and whenever the HeartbeatRequest is received, it should be answered with the HeartbeatResponse. If HeartbeatRequest is not got the corresponding HeartbeatResponse in pre-defined time period, it is eligible for resending the HeartbeatRequest up to pre-defined count of time until it receives corresponding HeartbeatResponse. Even after that count of time, if it not received particular HeartbeatResponse yet, the TLS/DTLS connection may be terminated by the application that initiated the HeartbeatRequest messages.
What is Heartbeat Extension?
The support of Heartbeats is indicated with Heartbeat Hello Extensions. A peer cannot only indicate that its implementation supports Heartbeats. It can choose whether it allows to receive HeartbeatRequest and respond with HeartbeatResponse messages or only allows to send HeartbeatRequest messages. This decision can be changed in every renegotiation. If the HeartbeatMode is peer_allowed_to_send, it allows to receive HeartbeatRequest and HeartbeatResponse messages. When the HeartbeatMode is peer_not_allowed_to_send, HeartbeatRequest message must not be sent to a corresponding endpoint. If an endpoint receives a HeartbeatRequest message that has indicated peer_not_allowed_to_send, the endpoint should drop the message and may send an unexpected message alert.
Figure1- Sample format of the Heartbeat Hello Extension
How does Heartbleed bug works?
Heartbleed bug got start from its improper input validation in the OpenSSL implementation of the TLS Heartbeat extension. because of its missing the bounds check on the length (length of the payload) and payload fields in Heartbeat requests, coupled with the trusting data received from other machines (an endpoint or other peer), the responding machine mistakenly sends back its own memory data.
Figure 2- Sample of Heartbeat protocol messages
According to the RFC 6520, two peers sending Heartbeat messages each other during TLS encrypted handshake. When Heartbeat response, it might have to contain extract copy of the payload which was in the HeartbeatRequest message. When a HeartbeatRequest message receives, the contents of the message are copied to the memory and copies the contents back in response. OpenSSL is allocated memory for the response that is based on the length and then it copies payload in the response using memcpy ().
Figure 3- command use for copy data
According to the Figure 3, bp is the place it’s coping it to, p1 is where it’s being copied from, and payload is the length of data being copied from. The problem is there is no way to check if the amount of data in p1 is equal to the value given of payload.
Since its does not validate the length field, attacker can send greater value than the actual length of the payload. The responding machine to Heartbeat requests, do not verify payload length is same as specified in length field. Thus, the machine copies extra data residing in memory after the payload into the response. Therefore, extra bytes are additional data in the remote process’s memory. That is how Heartbleed vulnerability works.
Figure 4- Example for how Heartbleed works
According to above example, in Normal usage, client sends 4 letter word “bird” as the payload in Heartbeat request and server copy that into the memory. When in responding, it copies back in to the payload and send. Because of it does not check the length field and payload, attacker asks for 500 characters even though it sends the word “bird”. Except word “bird”, it copies data in the memory up to 500 characters to the payload when HeartbeatResponse sends. In those data, it can be included sensitive data.
What is the impact of the Heartbleed vulnerability?
Heartbeat bug allows anyone in the internet to read the memory of the systems protected by the vulnerable versions of OpenSSL software. Sensitive information such as identifiers, tokens, usernames, passwords, server’s private cryptography keys can be extracted from the memory. This attack leaves no apparent of evidence in the log files. Therefore, it is difficult to identify whether machine has been compromised or not.
An attacker can be read 64 kilobytes of server memory for a single Heartbeat message. But there is no limit to amount of memory that can be read.
How can Heartbleed be avoided?
By validating message length and ignoring Heartbeat messages asking for more data than the payload needs.
Figure 5-Sample code that OpenSSL used to come over from Heartbleed bug
References:
- https://www.csoonline.com/article/3223203/what-is-the-heartbleed-bug-how-does-it-work-and-how-was-it-fixed.html
- https://www.synopsys.com/blogs/software-security/heartbleed-bug/
- https://datatracker.ietf.org/doc/rfc6520/?include_text=1
- https://forum.inductiveautomation.com/t/heartbeat-handshake/1626/3
- https://www.youtube.com/watch?v=TQQkKA3MydI
dpasidu7 