Introduction:
Heartbleed is a critical OpenSSL vulnerability. This flaw allows an attacker to trick the vulnerable server into revealing sensitive information from parts of its memory. This can include passwords, private keys, and other confidential data. In this blog, we’ll dive into how Heartbleed works, the vulnerable code and how to exploit it.
What is OpenSSL?
OpenSSL is a open source cryptographic library which facilitates secure communication between two endpoints. This cryptography toolkit can be used in CSR (Certificate Signing Request) generation, public and private key generation and managing SSL/TLS protocols. When we connect to a web server, OpenSSL helps in establish a secure communication between the server and our machine. It supports security protocols like SSL/TLS, which function at the Transport Layer of the OSI model.
Heartbeat request
A Heartbeat request is an important extension of the SSL/TLS protocol. A heartbeat request is used to check if two computers are still connected when no data is being transmitted. One computer sends an encrypted data called a Heartbeat request, to the other. The second computer sends the exact same data back to confirm that the connection remains active.
What is Heartbleed bug?
Heartbleed vulnerability is a critical bug which lets attackers get critical information from web server’s memory by exploiting a simple functionality in OpenSSL Heartbeat request. Normally, User machine sends a heartbeat request to the server, which includes a small payload (a piece of data) and the size of the payload. The server stores the payload in memory, then reads and returns data from its memory based on the size specified by the request.
A step-by-step explanation of Heartbleed:
- The attacker sends a Heartbeat request with a small payload (e.g., “hello” which is 5 bytes) but falsely claims the payload size is much larger (e.g., 64 KB).
- The vulnerable web server stores the 5-byte payload in memory.
- When processing the response, the web server retrieves data from memory based on the claimed payload size (64 KB). Since the actual payload is only 5 bytes, the server unintentionally retrieves an additional data from its memory.
- The server sends this 64 KB of data back to the attacker.
- This extra memory data can contain sensitive information such as user credentials, private keys which the attacker can now exploit.
Below meme explains the bug in layman’s terms.
Vulnerable Code:
The single line of code contains the bug that led to Heartbleed vulnerability is,
memcpy(bp, pl, payload);- memcpy() — A function used to copy data from one location to another.
- bp — The destination where the data is being copied.
- pl — The actual payload.
- payload — Size of the payload.
The problem arises when there is no check to verify if the length of pl (the actual payload) matches the value of payload (the claimed size).
Exploitation:
Metasploit module: auxiliary/scanner/ssl/openssl_heartbleed
This module can be used to easily find and exploit Heartbleed vulnerability. This module offers three actions.
- SCAN — Scan the host to see if it is vulnerable.
- DUMP — Dump the memory and store it as loot.
- KEYS — Similar to DUMP but scan the results for the private key.
We can also use the below nmap command to check if the web server is vulnerable or not.
nmap -p <port> --script ssl-heartbleed <ip>Conclusion:
The Heartbleed vulnerability is a critical lesson in writing secure code for simple functionalities. Security Magazine estimated that just the cost of thousands of organizations needing to revoke and replace their SSL certificates could run as high as $500 million.
You can read about how this Heartbleed vulnerability was found here: https://www.csoonline.com/article/562859/the-heartbleed-bug-how-a-flaw-in-openssl-caused-a-security-crisis.html
