Heartbleed-Labor

Bildungslabor zum Studium der Heartbleed-Sicherheitslücke
(CVE-2014-0160) unter Verwendung einer echten anfälligen OpenSSL-Umgebung in Docker.

Dieses Projekt reproduziert einen anfälligen TLS-Server mit OpenSSL 1.0.1f und implementiert einen benutzerdefinierten, rohen TLS-Heartbeat-Client, um zu demonstrieren, wie fehlerhafte Heartbeat-Pakete eine Speicheroffenlegung auslösen können.

Das Labor wurde zu Bildungs- und Forschungszwecken erstellt, insbesondere zum Studium von:

• TLS-Rahmenbildung (Framing)
• Heartbeat-Erweiterungsanalyse
• Sicherheitslücken bei Speicheroffenlegung
• Parser-Vertrauensfehler
• Rahmenbildungsinkonsistenzen zwischen Protokollen
• Konzeptionelle Ähnlichkeiten zwischen Heartbleed und HTTP-Desynchronisationssicherheitslücken

Aktuelle Projektstruktur

heartbleed-lab/
├── client/
│   ├── attacker.py
│   └── Dockerfile
│
├── vulnerable/
│   ├── Dockerfile
│   └── server/
│
├── fixed/
│   ├── Dockerfile
│   └── server/
│
├── docs/
│   └── diagrams/
│
├── notes/
│
├── docker-compose.yml
├── .gitignore
└── README.md

Architektur

heartbleed-client
        ↓
 Docker internal network
        ↓
vulnerable-heartbleed

Wobei:

• heartbleed-client sendet rohe TLS-Datensätze
• vulnerable-heartbleed führt OpenSSL 1.0.1f aus
• Die Kommunikation findet innerhalb eines isolierten Docker-Netzwerks statt

Anfällige Umgebung

Der anfällige Server verwendet:

• Ubuntu 14.04
• OpenSSL 1.0.1f (anfällige Version von 2014)
• openssl s_server

Die Umgebung ist absichtlich so konfiguriert, dass sie das ursprüngliche Heartbleed-Verhalten reproduziert.

Implementierte Funktionen

Anfälliger TLS-Server

• Echter OpenSSL 1.0.1f-Build
• TLS-Handshake-Unterstützung
• Heartbeat-Erweiterung aktiviert
• Docker-isolierte Umgebung

Roher TLS-Heartbeat-Client

Die Client-Implementierung:

• erstellt rohe TCP-Sockets
• sendet handgefertigte TLS-Datensätze
• führt ein manuelles TLS-ClientHello durch
• sendet fehlerhafte Heartbeat-Anfragen
• empfängt durchgesickerte Speicherantworten

Heartbleed-Demonstration

Die aktuelle Implementierung reproduziert das ursprüngliche Heartbleed-Verhalten, indem sie ein fehlerhaftes Heartbeat-Paket sendet, bei dem:

payload_length > real payload size

Beispiel:

Declared payload length: 0x4000
Real payload: 1 byte ("A")

Der anfällige Server vertraut fälschlicherweise der deklarierten Länge und antwortet mit Speicherinhalten, die über die tatsächlichen Nutzlastgrenzen hinausgehen.

Ausführen des Labors

Container erstellen und starten

sudo COMPOSE_HTTP_TIMEOUT=300 docker-compose up --build

Auf den Client-Container zugreifen

sudo docker exec -it heartbleed-client bash

Heartbleed-Proof-of-Concept ausführen

python attacker.py

Beispiel einer erfolgreichen Ausgabe

[+] Sending malformed heartbeat
[+] Got TLS record: type=24 version=(3, 2) length=16384
[!!!] Heartbeat response received

Dies zeigt, dass der anfällige Server Speicherinhalte jenseits der legitimen Heartbeat-Nutzlast zurückgegeben hat.

Forschungsziele

Dieses Projekt untersucht die Beziehung zwischen:

• TLS-Rahmenbildungsinkonsistenzen
• Parser-Vertrauensfehler
• Grenzverwirrung
• fehlerhafte Längenfelder
• Konzepte der Protokolldesynchronisation

Eines der Hauptforschungsinteressen dieses Labors ist der Vergleich:

HTTP Request Smuggling
vs
TLS Heartbeat Parsing Failures

aus der Perspektive von:

• Rahmenbildungsinkonsistenzen
• Parser-Verhalten
• Metadaten-Vertrauensannahmen

Zukünftige Arbeiten

Geplante nächste Schritte umfassen:

• verbesserte Leckvisualisierung
• Hilfsprogramme zum Parsen von Speicherlecks
• Vergleich mit gepatchten OpenSSL-Versionen
• Experimente mit vermittelnden TLS-Proxys
• automatisiertes Heartbeat-Mutationstesten

Referenzen

• CVE-2014-0160
• RFC 6520 (TLS Heartbeat Extension)

Haftungsausschluss

Dieses Repository dient ausschließlich:

• Bildung
• akademische Forschung
• defensive Sicherheitsstudien