Post

Heartbleed explained

Posted
Preview Image
By CodingTarik 15 min read

Heartbleed TLS Vulnerability: Unraveling the Exploit

Introduction

The Heartbleed TLS vulnerability, discovered in April 2014, sent shockwaves through the cybersecurity landscape, exposing a critical flaw in the widely-used OpenSSL cryptographic library. This article aims to provide a comprehensive understanding of the technical intricacies behind the Heartbleed vulnerability, exploring how attackers could exploit it to access sensitive information. Additionally, we’ll include a simplified Python code snippet for educational purposes, demonstrating how a malicious heartbeat message can be crafted to trigger the exploit.

Technical Background

TLS and OpenSSL

Transport Layer Security (TLS) is a cryptographic protocol essential for securing communication over computer networks. OpenSSL, an open-source implementation of TLS and Secure Sockets Layer (SSL), plays a pivotal role in enabling encryption and decryption functions for secure data transmission.

Heartbeat Extension

The Heartbleed vulnerability is tied to the OpenSSL implementation of the Heartbeat Extension, designed to maintain TLS connections by exchanging periodic “heartbeat” messages between the client and the server. These messages include a payload and a field specifying the payload length.

How Heartbleed Works

Buffer Over-read

At the core of the Heartbleed vulnerability is a programming error in handling the heartbeat message. Upon receiving a heartbeat message, the server is expected to respond with an echo of the payload. However, inadequate bounds checking opens the door for attackers to exploit a buffer over-read.

Data Leakage

Exploiting this vulnerability involves crafting a malicious heartbeat message with a manipulated payload length. By convincing the server that the payload is longer than it actually is, the attacker can trick the server into reading and returning additional data from its memory. This unforeseen data leakage could expose sensitive information, including usernames, passwords, and private keys.

Python Code Demonstration

To illustrate the Heartbleed vulnerability, we provide a simplified Python code snippet below. This code is for educational purposes only, and any attempt to exploit real systems without proper authorization is strictly prohibited.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23

import socket
import struct

def send_heartbeat_request(host, port):
    payload = b"Hello, server! Are you there?"
    payload_length = len(payload)
    
    # Craft malicious heartbeat request with a fake payload length
    heartbeat_request = struct.pack('>BH', 1, payload_length + 3) + payload
    
    # Send the crafted heartbeat request
    with socket.socket(socket.AF_INET, socket.SOCK_STREAM) as s:
        s.connect((host, port))
        s.sendall(heartbeat_request)
        
        # Receive and print the server's response
        response = s.recv(4096)
        print("Server response:", response)

# Example usage
host = "example.com"
port = 443
send_heartbeat_request(host, port)

This code sends a crafted heartbeat request to the specified host and port. The server’s response will include the additional data read from its memory, showcasing the potential data leakage facilitated by the Heartbleed vulnerability.

Anatomy of a Heartbeat Message

In the TLS protocol, a heartbeat message is used to check if the other party is still alive. It consists of two parts:

  1. Payload Length Field: A 16-bit unsigned integer indicating the length of the payload.
  2. Payload: Arbitrary data whose length is determined by the payload length field.

For example, a normal heartbeat message might look like this:

1
2
3
4

+----------+---------------------------+
| Payload  | "Hello, server! Are you   |
| Length   | there?"                   |
+----------+---------------------------+

The payload length field indicates the length of the payload, and the server responds with the same payload.

Crafting a Malicious Heartbeat Message

In the Heartbleed attack, an attacker crafts a malicious heartbeat message by manipulating the payload length field. The key is to specify a payload length that is larger than the actual length of the payload.

Let’s consider an example where the payload is “blabla,” and the attacker manipulates the payload length field to indicate a length of 15 instead of 6:

1
2
3
4

+----------+-------------------------------+
| Payload  | "blabla"                      |
| Length   | 15 (manipulated by attacker)  |
+----------+-------------------------------+

Server’s Response

When the malicious heartbeat message is sent to the server, the server allocates a buffer based on the manipulated payload length (15 in this case) and attempts to copy the payload into the buffer. However, since the actual payload is only 6 bytes long, the server ends up reading beyond the actual data in its memory.

As a result, the server may inadvertently include additional data from its memory in the response:

1
2
3
4

+----------+-------------------------------+
| Payload  | "blabla" + (extra data)       |
| Length   | 15                            |
+----------+-------------------------------+

The “extra data” could include sensitive information such as usernames, passwords, or even private keys, depending on what is stored in the server’s memory at that moment.

Python Code Explanation

In the Python code snippet provided earlier, the send_heartbeat_request function is responsible for crafting and sending the malicious heartbeat message. The payload is set to “Hello, server! Are you there?” and the payload length is manipulated to be larger than the actual payload length.

1
2

# Craft malicious heartbeat request with a fake payload length
heartbeat_request = struct.pack('>BH', 1, payload_length + 3) + payload

Here, struct.pack('>BH', 1, payload_length + 3) creates a packed binary string that includes the heartbeat message type (1 byte) and the manipulated payload length (2 bytes).

The server’s response is then printed:

1
2
3

# Receive and print the server's response
response = s.recv(4096)
print("Server response:", response)

This response may contain the actual payload echoed by the server and any additional data that the Heartbleed vulnerability allows the attacker to read from the server’s memory.

Let’s break down the components:

  • '>BH': This is a format string that defines the structure of the packed data. Each character in the format string corresponds to a specific data type and size. Here:
    • > indicates that the data should be packed in big-endian (most significant byte first) order.
    • B denotes an unsigned char (1 byte).
    • H denotes an unsigned short (2 bytes).

  • 1: This is the heartbeat message type. In the TLS protocol, a heartbeat request typically has a message type of 1.

  • payload_length + 3: This represents the manipulated payload length. The original payload length is increased by 3 to create a payload length that is intentionally larger than the actual payload. This manipulation is a crucial part of the Heartbleed exploit.

  • payload: This is the actual payload of the heartbeat message.

When you use struct.pack('>BH', 1, payload_length + 3), it combines the message type (1 byte) and the manipulated payload length (2 bytes) into a binary string. This binary string is then concatenated with the actual payload to create the malicious heartbeat message.

In the context of the Heartbleed exploit, the goal is to make the server believe that the payload is longer than it really is, leading to a buffer over-read and potential leakage of sensitive information from the server’s memory.

Example 1:

1
2
3
4
5

Copy code
import struct

data = struct.pack('>BH', 1, 100)
print(repr(data))

In this example, the values 1 and 100 are packed into a binary string using the format ‘>BH’. The resulting binary string is three bytes long, with the first byte representing the unsigned char 1, and the next two bytes representing the unsigned short 100 in big-endian order.

It’s crucial to emphasize that the code provided is for educational purposes only, and any attempt to exploit real systems without permission is both illegal and unethical. The Heartbleed vulnerability has been patched, and systems should be regularly updated to protect against such security risks.

Full working code

This block of code is responsible for importing necessary modules and setting up command-line options using the OptionParser class. Let’s break it down:

  1. Module Imports: 
    1
2
3
4
5
6
7
8
9

     import sys
 import struct
 import socket
 import time
 import select
 import re
 import time
 import os
 from optparse import OptionParser
    • sys: Provides access to some variables used or maintained by the interpreter and functions that interact with the interpreter.
    • struct: Allows for the interpretation and manipulation of packed binary data.
    • socket: Provides access to the BSD socket interface.
    • time: Provides various time-related functions.
    • select: Provides low-level I/O multiplexing.
    • re: Provides regular expression matching operations.
    • os: Provides a way of using operating system-dependent functionality.
    • OptionParser from optparse: Used for parsing command-line options.
  2. OptionParser Setup: 
    1

     options = OptionParser(usage='%prog server [options]', description='Test and exploit TLS heartbeat vulnerability aka heartbleed (CVE-2014-0160)')
    • OptionParser is initialized with usage information and a description for the script.
  3. Adding Command-Line Options: 
    1
2
3
4
5
6
7
8
9
10

     options.add_option('-p', '--port', type='int', default=443, help='TCP port to test (default: 443)')
 options.add_option('-n', '--num', type='int', default=1, help='Number of times to connect/loop (default: 1)')
 options.add_option('-s', '--starttls', action="store_true", dest="starttls", help='Issue STARTTLS command for SMTP/POP/IMAP/FTP/etc...')
 options.add_option('-f', '--filein', type='str', help='Specify input file, line delimited, IPs or hostnames or IP:port or hostname:port')
 options.add_option('-v', '--verbose', action="store_true", dest="verbose", help='Enable verbose output')
 options.add_option('-x', '--hexdump', action="store_true", dest="hexdump", help='Enable hex output')
 options.add_option('-r', '--rawoutfile', type='str', help='Dump the raw memory contents to a file')
 options.add_option('-a', '--asciioutfile', type='str', help='Dump the ascii contents to a file')
 options.add_option('-d', '--donotdisplay', action="store_true", dest="donotdisplay", help='Do not display returned data on screen')
 options.add_option('-e', '--extractkey', action="store_true", dest="extractkey", help='Attempt to extract RSA Private Key, will exit when found. Choosing this enables -d, do not display returned data on screen.')
    • Various command-line options are added, specifying short and long forms, types, default values, and help messages.
  4. Parsing Command-Line Options: 
    1

     opts, args = options.parse_args()
    • The parse_args() method parses the command-line arguments and options.
  5. Conditional Import: 
    1
2
3
4

     if opts.extractkey:
     import base64, gmpy
     from pyasn1.codec.der import encoder
     from pyasn1.type.univ import *
    • If the --extractkey option is specified, additional modules (base64, gmpy, encoder, and univ from pyasn1) are imported. These modules are used for handling RSA private key extraction.

This code sets up the necessary environment for command-line option parsing and selectively imports modules based on the specified options. The parsed options are stored in the opts variable, and the remaining positional arguments are stored in the args variable.

STARTTLS The client initiates an initial unencrypted network connection to the server through the designated plaintext communication port. If the server signals support for STARTTLS, the client issues the STARTTLS command. This prompts both communication partners to commence the TLS handshake, where they negotiate encryption. Following this, the application protocol continues in an encrypted fashion.

In contrast to implicit TLS, where the TLS handshake begins immediately upon connection without any plaintext communication, STARTTLS involves explicit negotiation regarding the use of TLS. When STARTTLS emerged in 1999, unencrypted data transmission prevailed on the internet. In this context, STARTTLS offered a convenient upgrade mechanism, allowing the use of TLS when available and reverting to unencrypted transmission otherwise (opportunistic encryption). Another advantage is the conservation of port numbers at IANA, requiring only one port for both encrypted and unencrypted transmission, as opposed to implicit TLS.

However, STARTTLS has a notable drawback—it is susceptible to man-in-the-middle attacks through the upgrade mechanism. Manipulating plaintext commands enables an attacker to prevent TLS encryption. To safeguard against such downgrade attacks, additional measures like DANE or MTA-STS are necessary. When used in conjunction with a firewall, a potential downside may be the requirement for deep packet inspection at the application layer to differentiate between encrypted and unencrypted connections.

In subsequent years, TLS gained wider adoption. A 2018 reassessment by STARTTLS developers now leans toward implicit TLS, strongly discouraging plaintext transmission.

  1. def hex2bin(arr):
    • This line defines a function named hex2bin that takes a parameter arr, presumably an array of integers.
    • The function converts each integer in the array to a two-digit hexadecimal representation using the '{:02x}'.format(x) formatting.
    • The join method concatenates these hexadecimal representations into a single string.
    • Finally, decode('hex') is used to convert the hexadecimal string into its binary representation.
  2. tls_versions = {0x01:'TLSv1.0',0x02:'TLSv1.1',0x03:'TLSv1.2'}
    • This line creates a dictionary named tls_versions that maps integer values to corresponding TLS version strings.
    • The keys are hexadecimal values (e.g., 0x01), and the corresponding values are strings representing TLS versions (e.g., 'TLSv1.0').
    • This dictionary can be used to easily map numeric TLS version codes to their human-readable equivalents in the code.

In summary, the hex2bin function converts an array of integers to a binary string, and the tls_versions dictionary provides a mapping between numeric TLS version codes and their string representations. These elements are commonly used in cryptography and network programming, especially when dealing with TLS/SSL protocols.

The {:02x} is a string formatting syntax used in Python, and it specifically deals with formatting integers as hexadecimal strings. Here’s a breakdown of its components:

  • {}: This is a placeholder within a string, indicating where a value should be inserted. The value to be inserted is specified separately in the format method.

  • :: This colon is used to indicate that what follows is the format specification.

  • 02: Here, 0 is a flag, and 2 specifies the minimum width of the field. The 0 flag means that if the resulting string is shorter than the specified width, it will be padded with zeros on the left.

  • x: This indicates that the value should be formatted as a hexadecimal number.

So, {:02x} is a format specification that says “format the given integer as a hexadecimal string with at least two characters, and pad with zeros if necessary.”

Here’s an example:

1
2
3

decimal_number = 12
hexadecimal_string = '{:02x}'.format(decimal_number)
print(hexadecimal_string)

In this example, decimal_number is formatted as a hexadecimal string using {:02x}, and the result is the string '0c'. The 0 ensures that there are two characters, and since 12 in hexadecimal is represented as 0c, it doesn’t need any padding.

The provided code defines two functions, build_client_hello and build_heartbeat, which are used to construct TLS (Transport Layer Security) handshake messages for a client hello and a heartbeat, respectively.

build_client_hello Function:

This function constructs a TLS ClientHello message, which is a part of the TLS handshake process where a client and server negotiate the parameters of their secure connection.

Here’s a breakdown of the structure:

  • TLS Header (5 bytes):
    • 0x16: Content type for handshake.
    • 0x03, tls_ver: TLS version.
    • 0x00, 0xdc: Length of the entire message.
  • Handshake Header (4 bytes):
    • 0x01: Type for ClientHello.
    • 0x00, 0x00, 0xd8: Length of the handshake message.
  • Random (32 bytes):
    • Randomly generated data used in the key exchange process.
  • Session ID Length and Cipher Suites Length (3 bytes):
    • 0x00: Session ID length.
    • 0x00, 0x66: Cipher suites length.
  • Cipher Suites (51 suites, each 2 bytes):
    • A list of supported cipher suites.
  • Compression Methods (2 bytes):
    • 0x01: Length of compression methods.
    • 0x00: Compression method (NULL).
  • Extensions (73 bytes):
    • ec_point_formats extension (8 bytes).
    • elliptic_curves extension (52 bytes).
    • SessionTicket TLS extension (4 bytes).
    • Heartbeat extension (5 bytes).

build_heartbeat Function:

This function constructs a TLS Heartbeat message, which is part of the Heartbeat Extension used to keep a TLS connection alive and check for potential vulnerabilities (such as the Heartbleed bug).

Here’s a breakdown of the structure:

  • TLS Header (5 bytes):
    • 0x18: Content type for heartbeat.
    • 0x03, tls_ver: TLS version.
    • 0x00, 0x03: Length of the entire message.
  • Heartbeat Payload (5 bytes):
    • 0x01: Type (Request).
    • 0x40, 0x00: Payload length (indicating a payload of 16384 bytes).

These functions generate raw byte arrays representing TLS messages that can be sent over a network during the TLS handshake process or when performing a TLS Heartbeat.

Creating ASCII art representations of TLS packets can be challenging due to the complexity and detailed structure of the packets. However, I can provide simplified representations to give you a rough idea. Keep in mind that these are highly simplified and may not accurately reflect the actual structure of TLS packets.

TLS Hello Packet:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

+---------------------+
|   TLS Header        |
|    Content Type     | 0x16 (Handshake)
|    TLS Version      | 0x03, 0x03 (TLS 1.2)
|    Length           | 0x00, 0xdc (Length of entire message)
+---------------------+
|   Handshake Header  |
|    Type             | 0x01 (ClientHello)
|    Length           | 0x00, 0x00, 0xd8 (Length of handshake message)
+---------------------+
|   Random            |
|    32 bytes         |
+---------------------+
|   Session ID Length | 0x00
|   Cipher Suites Len | 0x00, 0x66 (Length of cipher suites)
|   Cipher Suites     | ...
|   Compression Meth. | 0x01 (Length), 0x00 (NULL)
|   Extensions        | ...
+---------------------+

TLS Heartbeat Packet:

1
2
3
4
5
6
7
8
9
10

+---------------------+
|   TLS Header        |
|    Content Type     | 0x18 (Heartbeat)
|    TLS Version      | 0x03, 0x03 (TLS 1.2)
|    Length           | 0x00, 0x03 (Length of entire message)
+---------------------+
|   Heartbeat Payload |
|    Type             | 0x01 (Request)
|    Payload Length   | 0x40, 0x00 (Payload length, e.g., 16384 bytes)
+---------------------+

Please note that these representations simplify the actual structure of TLS packets for readability. In a real-world scenario, the fields and values would be more detailed and follow the TLS protocol specification.

Conclusion

Heartbleed served as a stark reminder of the critical importance of rigorous security practices in widely-used software. While the vulnerability has been patched, its legacy underscores the ongoing challenges in maintaining a secure digital environment. Cybersecurity vigilance, regular software updates, and adherence to best practices remain paramount to mitigating the risk of similar vulnerabilities in the future.

Further Reading: https://www.ietf.org/rfc/rfc2246.txt https://www.ietf.org/rfc/rfc6520.txt

cs, security
web Linux security
This post is licensed under CC BY 4.0 by the author.

Impressum  | 

Datenschutz  | 

Manage cookie settings  | 

Using the Chirpy theme for Jekyll

© 2024 CodingTarik. Some rights reserved.