Schwachstelle im SSH-Protokoll – Was Sie über den Terrapin-Angriff CVE-2023-48795 wissen müssen

Der SSH-Terrapin-Angriff (CVE-2023-48795) hat kürzlich Aufmerksamkeit erregt, da er durch das Abschneiden kryptografischer Informationen auf die Sicherheit des SSH-Protokolls abzielt. Der inhärente Fehler im SSH-Protokoll selbst betrifft eine Vielzahl von Implementierungen von SSH-Clients und -Servern. Im Anschluss an unsere erste Forschungsmitteilung werden in diesem Beitrag die Grundlagen und Auswirkungen näher erläutert.

• Betroffene Implementierungen
• Auswirkungen des Terrapin-Angriffs
• Übersicht zu CVE-2023-48795
• Analyse von CVE-2023-48795
• Wie CVE-2023-48795 in OpenSSH behoben wurde
• Behebung von CVE-2023-48795 mit JFrog Xray und JFrog Advanced Security

Betroffene Implementierungen

Viele SSH-Client- und -Server-Implementierungen sind betroffen, z.B. OpenSSH, paramiko, PuTTY, KiTTY, WinSCP, libssh, libssh2, AsyncSSH, FileZilla und viele mehr. Hier ist die vollständige Liste der bekannten betroffenen Implementierungen.

Auswirkungen des Terrapin-Angriffs

1. Signatur-Downgrade-Angriffe, die die Sicherheit einer SSH-Verbindung auf verschiedene Weise beeinträchtigen.
2. In der OpenSSH-Implementierung, insbesondere in neueren Versionen als 9.5, umgeht der Angriff die Funktion zur Verschleierung des Tastenanschlag-Timings, wodurch MitM-Angreifer SSH-Passwörter per Brute-Force-Angriff erraten könnten, indem sie die SSH-Netzwerkpakete untersuchen.

Übersicht zu CVE-2023-48795

Der Terrapin-Angriff ist ein neuartiger Angriff auf das SSH-Protokoll selbst, bei dem ein kompromittierter Client durch einen Man-in-the-Middle-Angriff (MitM) fälschlicherweise annimmt, dass der Server die bei der Benutzerauthentifizierung verwendeten aktuellen Signaturalgorithmen nicht unterstützt.

Die Schwachstelle betrifft alle SSH-Verbindungen. Diese Untersuchung konzentriert sich auf die OpenSSH-Implementierung.

Es gibt zwei anfällige OpenSSH-Konfigurationen:

1. ChaCha20-Poly1305
2. Alle aes(128|192|256)-cbc-Chiffren, die die Standard-MACs verwenden (oder jeden MAC, der Encrypt-then-MAC, EtM, verwendet, zum Beispiel hmac-sha2-256-etm@openssh.com).

Der standardmäßige OpenSSH-Client und -Server sind für diesen Angriff anfällig, da sie so konfiguriert sind, dass sie die anfällige ChaCha20-Poly1305-Chiffre zulassen.

Hinweis: Nur den Server oder nur den Client zu aktualisieren, reicht nicht aus! Beide müssen gepatcht werden. Ein anfälliger Client, der sich mit einem gepatchten Server verbindet, führt trotzdem zu einer anfälligen Verbindung.

Analyse von CVE-2023-48795

Die Ausnutzung von CVE-2023-48795 ermöglicht es einem Man-in-the-Middle-Angreifer, wichtige Teile des SSH-Handshakes abzuschneiden, ohne die SSH-Verbindung zu schließen, was Sicherheitsauswirkungen auf den SSH-Client/-Server hat. Um die Auswirkungen des Angriffs zu untersuchen, gehen wir näher auf die Details des SSH-Handshakes ein.

SSH-Handshake

SSH-HandshakeSSH-Handshake
Der Client initiiert eine TCP-Verbindung, anschließend wird ein Austausch der Protokollversion (RFC 4253) durchgeführt.

Gemäß dem RFC findet anschließend eine Algorithmus-Aushandlung statt. Im RFC heißt es:

Wählen Sie den ersten Algorithmus aus, der die folgenden Bedingungen erfüllt:

    +  der Server unterstützt den Algorithmus ebenfalls

Das bedeutet, dass der Client den ersten Algorithmus auswählt, den der Server unterstützt. Im Standardfall für OpenSSH wird dies chacha20-poly1305@openssh.com sein.

EXT_INFO-Nachricht

Gemäß RFC 8308 unterstützt die Nachricht sicher nach dem SSH-Schlüsselaustausch Protokollerweiterungen. Die EXT_INFO-Nachricht ist ein sehr wichtiger Teil des Angriffs. Aufgrund der Terrapin-Schwachstelle kann das Paket abgeschnitten werden, was zu einer Herabstufung der Sicherheit und zur Deaktivierung der OpenSSH 9.5p1-Funktion zur Verschleierung des Tastenanschlag-Timings führt (siehe den folgenden Abschnitt „Verschleierung des Tastatur-Timings“).

Ein Beispiel für eine Protokollerweiterung ist die Erweiterung der Liste der Signaturalgorithmen. Moderne Algorithmen werden dieser Liste hinzugefügt, wie zum Beispiel Algorithmen mit SHA-2. Wenn das Paket gekürzt wird, wird die Sicherheit der Verbindung herabgestuft und es wird auf den SHA-1-Hash-Algorithmus zurückgegriffen. Dieser gilt als praktisch unbrauchbar und kann zu mehreren Angriffen auf die SSH-Verbindung führen (z. B. Identitätsdiebstahl aufgrund einer Hash-Kollision).

Dasselbe Paket enthält die folgenden Nachrichten:

1. Kex-Antwortnachricht (Schlüsselaustausch)
2. Meldung zu neuen Schlüsseln
3. EXT_INFO-Nachricht

Hier sind die Inhalte eines SSH2_MSG_EXT_INFO -Pakets aus einem Client-Debug-Protokoll:

debug1: SSH2_MSG_EXT_INFO received
debug1: kex_input_ext_info: server-sig-algs=<ssh-ed25519,sk-ssh-ed25519@openssh.com,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,sk-ecdsa-sha2-nistp256@openssh.com,webauthn-sk-ecdsa-sha2-nistp256@openssh.com,ssh-dss,ssh-rsa,rsa-sha2-256,rsa-sha2-512>
debug1: kex_ext_info_check_ver: publickey-hostbound@openssh.com=<0>
debug1: kex_ext_info_check_ver: ping@openssh.com=<0>

Praktische Details

Forschende, die den Terrapin-Angriff identifiziert haben, enthüllten, dass ein Man-in-the-Middle-Angreifer (MitM) in der Lage ist, das ausgewählte kryptografische Protokoll zu umgehen. In diesem Szenario können Angreifer die EXT_INFO-Nachricht, die in der Regel zur Aushandlung verschiedener Protokollerweiterungen verwendet wird, weglassen, ohne beim Client oder Server Verdacht zu erregen.

Normalerweise würde der Client das Löschen von Paketen beim Empfang des nachfolgenden Binärpakets vom Server erkennen, da dies zu Abweichungen bei den Sequenznummern führen würde.

Man-in-the-Middle-Terrapin-AngriffMan-in-the-Middle-Terrapin-Angriff

Um dem entgegenzuwirken, schleust der Angreifer während des Handshake-Prozesses ein Paket ein, um Sequenznummern zu manipulieren und so der Erkennung zu entgehen. Der konkrete Inhalt des eingeschleusten Pakets hängt von der kryptografischen Chiffre ab, die wir umgehen wollen:

1. ChaCha20-Poly1305: Der MitM-Angreifer fügt eine SSH2_MSG_IGNORE -Nachricht ein, bevor der Handshake abgeschlossen ist. Die Änderung der Sequenznummern ermöglicht es dem MitM-Angreifer, EXTINFO aus dem sicheren Kanal zu entfernen.
2. CBC-EtM: Der MitM fügt eine unbekannte Nachricht ein, bevor der Handshake abgeschlossen ist. Wie im vorherigen Szenario ermöglicht dies dem Angreifer, EXTINFO aus dem sicheren Kanals zu entfernen. In diesem Fall ist die Erfolgsrate jedoch eher zufällig.Sehen wir uns an, warum: Es gibt zwei verschiedene Ansätze zur Verwendung von MACs (Message Authentication Codes): EaM (Encrypt-and-MAC) und EtM (Encrypt-then-MAC). Beim EaM-Ansatz wird der MAC über den Klartext berechnet. Wenn der Angreifer Terrapin verwendet, um den Chiffretext in diesem Modus zu kürzen, ist der resultierende entschlüsselte Klartext pseudozufällig. Da EaM den MAC über den Klartext berechnet, schlägt die MAC-Verifizierung mit ziemlicher Sicherheit fehl, und der Angriff wird keine Auswirkungen auf die Sicherheit haben. Dies steht im Gegensatz zu EtM, bei dem der MAC über den Chiffretext (den verschlüsselten Text) berechnet wird. Hier ist die Paketlänge nicht verschlüsselt, damit der MAC vor der Entschlüsselung geprüft werden kann. Wenn der Angreifer Terrapin verwendet, um den Chiffretext in diesem Modus zu kürzen, kann er die unverschlüsselte Länge ändern, und die MAC-Überprüfung wird wahrscheinlich erfolgreich sein, sodass der Angreifer Pakete kürzen kann. Insbesondere ermöglicht dies dem MitM-Angreifer, EXTINFO innerhalb des sicheren Kanals zu entfernen, genau wie im Szenario ChaCha20-Poly1305. Die Ergänzung von EtM wurde später als Erweiterung in SSH eingeführt. In CBC-EtM wird der MAC über die Sequenznummer, die unverschlüsselte Paketlänge und den Chiffretext des Pakets berechnet. Die Erfolgsrate des Angriffs ist eher zufällig, da das Risiko eines MAC-Fehlers besteht, wenn der Angreifer eine Trunkierung durchführt (das EXT-INFO-Paket in Teile schneidet). Dies hängt von den spezifischen Details der kryptografischen Implementierung ab.

Auswirkung Nr. 1 – Signatur-Downgrade-Angriff

Die Durchführung des Angriffs auf OpenSSH zur Demonstration der Auswirkungen der Schwachstelle kann, wie in diesem Abschnitt beschrieben, zu Problemen bei der Benutzerauthentifizierung führen.

Den Aufbau der Nachricht sehen wir im folgenden Code (entnommen aus OpenSSH 9.5p1):

static int
kex_send_ext_info(struct ssh *ssh)
{
	int r;
	char *algs;

	debug("Sending SSH2_MSG_EXT_INFO");
	if ((algs = sshkey_alg_list(0, 1, 1, ',')) == NULL)
		return SSH_ERR_ALLOC_FAIL;
	/* XXX filter algs list by allowed pubkey/hostbased types */
	if ((r = sshpkt_start(ssh, SSH2_MSG_EXT_INFO)) != 0 ||
	    (r = sshpkt_put_u32(ssh, 3)) != 0 ||
	    (r = sshpkt_put_cstring(ssh, "server-sig-algs")) != 0 ||
	    (r = sshpkt_put_cstring(ssh, algs)) != 0 ||
	    (r = sshpkt_put_cstring(ssh,
	    "publickey-hostbound@openssh.com")) != 0 ||
	    (r = sshpkt_put_cstring(ssh, "0")) != 0 ||
	    (r = sshpkt_put_cstring(ssh, "ping@openssh.com")) != 0 ||
	    (r = sshpkt_put_cstring(ssh, "0")) != 0 ||
	    (r = sshpkt_send(ssh)) != 0) {
		error_fr(r, "compose");
		goto out;
	}
	/* success */
	r = 0;
 out:
	free(algs);
	return r;
}

Signatur-Downgrade-Angriff
Unter server-sig-algs wird dem Paket eine Liste von Argumenten angehängt. Diese Liste ist für eine der verfügbaren Methoden relevant, nämlich für die Authentifizierung mithilfe eines öffentlichen Schlüssels.

Diese Liste legt genau die unterstützten Signaturalgorithmen fest, d. h., sie bestimmt, ob wir mithilfe einer bestimmten Signatur kommunizieren können. Ohne diese Liste können Server und Client die neuesten Signaturalgorithmen (z. B. rsa-sha2-512, das SHA2-Hashing verwendet – SHA512) gemäß RFC 8308 nicht verwenden.

Um den Downgrade-Angriff zu demonstrieren, verwenden wir den Terrapin-PoC und zwingen den Client, sich mithilfe einer passwortbasierten Authentifizierung mit dem Server zu verbinden (anstelle der üblichen schlüsselbasierten Authentifizierung). Diese Verbindungsmethode ist schwächer als die schlüsselbasierte Authentifizierung und kann dazu verwendet werden, die Verbindungsbedingungen zu erzwingen, die zur zweiten Auswirkung dieses Angriffs führen (siehe nächsten Abschnitt „Umgehung der Verschleierung des Tastenanschlag-Timings“).

Führen wir den Angriff aus, indem wir ein IGNORE-Paket einschleusen, die EXT_INFO-Nachricht entfernen und uns mit dem MitM-Server statt mit dem normalen SSH-Server verbinden.
Unser öffentlicher Schlüssel, der zuvor erkannt und akzeptiert wurde, wird nun nicht verwendet – stattdessen wird eine andere Authentifizierungsmethode verwendet (in unserem Beispiel: Passwort):

In den Debug-Protokollen des OpenSSH-Servers können wir sehen, wie sich dies von einer normalen Verbindung unterscheidet.
Bei Verwendung der normalen Verbindung (bei der der öffentliche Schlüssel akzeptiert wurde) ist Folgendes in den Logs zu sehen:

debug1: expecting SSH2_MSG_KEX_ECDH_INIT [preauth]
debug1: SSH2_MSG_KEX_ECDH_INIT received [preauth]
debug1: rekey out after 134217728 blocks [preauth]
debug1: SSH2_MSG_NEWKEYS sent [preauth]
debug1: Sending SSH2_MSG_EXT_INFO [preauth]
debug1: expecting SSH2_MSG_NEWKEYS [preauth]
debug1: SSH2_MSG_NEWKEYS received [preauth]
debug1: rekey in after 134217728 blocks [preauth]
debug1: KEX done [preauth]
debug1: userauth-request for user user service ssh-connection method none [preauth]
debug1: attempt 0 failures 0 [preauth]
debug1: userauth-request for user user service ssh-connection method publickey [preauth]
debug1: attempt 1 failures 0 [preauth]
debug1: userauth_pubkey: publickey test pkalg rsa-sha2-512 pkblob RSA SHA256:PkY4eNr7FRIZn31XNF+4J71s2Fs+5r7CVGFH5o5ck1E [preauth]

Beim Verbinden mit dem MitM-Server und beim Herabstufen der Signatur lauten die Protokolle:

debug1: SSH2_MSG_KEX_ECDH_INIT received [preauth]
debug1: rekey out after 134217728 blocks [preauth]
debug1: SSH2_MSG_NEWKEYS sent [preauth]
debug1: Sending SSH2_MSG_EXT_INFO [preauth]
debug1: expecting SSH2_MSG_NEWKEYS [preauth]
debug1: SSH2_MSG_NEWKEYS received [preauth]
debug1: rekey in after 134217728 blocks [preauth]
debug1: KEX done [preauth]
debug1: userauth-request for user user service ssh-connection method none [preauth]
debug1: attempt 0 failures 0 [preauth]
debug1: userauth-request for user user service ssh-connection method keyboard-interactive [preauth]
debug1: attempt 1 failures 0 [preauth]
debug1: keyboard-interactive devs  [preauth]
debug1: auth2_challenge: user=user devs= [preauth]

Ein OpenSSH-Client, der im Debug-Modus ausgeführt wird, würde außerdem die folgende Fehlermeldung ausgeben:

debug1: send_pubkey_test: no mutual signature algorithm

Dies liegt daran, dass server-sig-algs in der EXT_INFO-Nachricht fehlt.
Dies bedeutet im Wesentlichen, dass der Client keine schlüsselbasierte Authentifizierung verwenden kann.

Auswirkung Nr. 2 – Umgehung der Verschleierung des Tastenanschlag-Timings

Die Studie Timing Analysis of Keystrokes and Timing Attacks on SSH, die auch als Präsentation vorgestellt und vor 12 Jahren veröffentlicht wurde, zeigte, dass die Analyse der Zeitabstände zwischen Tastenanschlägen zur Ermittlung der exakten Länge des Passworts eines Benutzers und anschließend zur Nutzung präziser Zeitabstände zwischen den Tastenanschlägen führen kann, um das Passwort zu knacken.

Mit OpenSSH Version 9.5p1 wurde eine neue Sicherheitsfunktion namens „Verschleierung des Tastenanschlag-Timings“ eingeführt. Diese Funktion verschleiert die Zeitabstände zwischen Tastenanschlägen, indem sie in festen Intervallen Datenverkehr sendet (Standard: alle 20 Millisekunden), statt unmittelbar nach jedem Tastendruck.

Damit die Verschleierung aktiviert werden kann, muss diese Funktion sowohl im Client als auch auf dem Server implementiert sein (daher müssen beide mindestens die OpenSSH-Version 9.5p1 verwenden).
Diese Kompatibilitätsdaten werden über die EXT_INFO-Nachricht gesendet, die mithilfe des Terrapin-Angriffs entfernt werden kann.

Nachfolgend finden Sie Wireshark-Aufnahme-Screenshots, die das Feature bei einer normalen Verbindung mit OpenSSH 9.5p1 in Aktion zeigen:

Wireshark-Aufnahme einer normalen SSH-Verbindung mit OpenSSH 9_5p1Wireshark-Aufzeichnung einer normalen SSH-Verbindung mit OpenSSH 9.5p1

Die neben den Paketnummern angezeigte Zeit gibt die seit dem zuvor angezeigten Paket vergangenen Sekunden an. Beachten Sie, dass der Unterschied 20–21 Millisekunden beträgt, wenn die Verschleierungsfunktion aktiv ist.

Führen wir den Angriff aus, indem wir ein IGNORE-Paket einschleusen, die EXT_INFO-Nachricht entfernen und uns mit dem MitM-Server statt mit dem normalen SSH-Server verbinden.
Nachfolgend ist die Wireshark-Aufnahme der MitM-SSH-Verbindung zu sehen:

Wireshark-Aufnahme einer MitM_d-SSH-Verbindung mit OpenSSH 9_5p1Wireshark-Aufnahme einer MitM-SSH-Verbindung mit OpenSSH 9.5p1

Diese Verbindung wurde unter Verwendung derselben OpenSSH 9.5p1-Versionen sowohl des Clients als auch des Servers hergestellt. Wir können sehen, dass die Timing-Verschleierung umgangen wurde, da für jedes in der Verbindung gesendete Paket unterschiedliche Zeitangaben vorliegen.

Es ist erwähnenswert, dass, wenn keine Verschleierung des Tastenanschlag-Timings verwendet wird (oder im Fall von OpenSSH 9.5p1 umgangen wird), ein Signatur-Downgrade eingesetzt werden kann, um das Passwort effektiv zu knacken, wie in der Studie zur Timing-Analyse von SSH-Tastenanschlägen dargelegt.

Wie CVE-2023-48795 in OpenSSH behoben wurde

Im ursprünglichen technischen Forschungsartikel zum Terrapin-Angriff schlugen die Forschenden zwei Gegenmaßnahmen vor (Abschnitt 8): 1. das Zurücksetzen der Sequenznummer und 2. die Überprüfung des gesamten Handshake-Prozesses.

Die erste besteht im Zurücksetzen der Sequenznummer; wenn die Sequenznummern des Clients oder Servers beim Aktivieren der Verschlüsselungsschlüssel auf null zurückgesetzt werden, können die zuvor beschriebenen Manipulationen die Verschlüsselung nicht beeinträchtigen.

Zur Verbesserung der Sicherheit besteht die zweite Gegenmaßnahme darin, den gesamten Handshake-Prozess zu überprüfen, um sämtliche Manipulationsversuche eines Man-in-the-Middle-Angreifers zu erkennen. Diese Authentifizierung umfasst den Austausch eines Message Authentication Code (MAC) des vollständigen Transkripts zu Beginn des sicheren Kanals, ähnlich wie bei TLS FINISHED-Nachrichten.

OpenSSH hat dieses Problem durch die Implementierung eines neuen „strict KEX“-Protokolls behoben, das Folgendes implementiert:

1. Wenn ein Paket empfangen wird, das nicht dem erwarteten oder korrekten Typ entspricht, oder wenn das erste Paket nicht SSH2_MSG_KEXINIT ist, sollte die Verbindung beendet werden.
   Zu den unerwarteten Paketen gehören Nachrichten wie SSH2_MSG_DEBUG und SSH2_MSG_IGNORE, auch wenn diese während der Verbindung im Allgemeinen zulässig sind. Es sind genau diese Arten von Nachrichten, die den Angriff ermöglichen.
2. Nach dem Senden oder Empfangen einer SSH2_MSG_NEWKEYS -Nachricht sollte die Sequenznummer für Pakete auf null zurückgesetzt werden. Diese Regel gilt für die gesamte Dauer der Verbindung, nicht nur unmittelbar nach der SSH2_MSG_NEWKEYS -Nachricht.

Die Fixes wurden veröffentlicht als Teil der OpenSSH-Version 9.6p1 und entsprechen direkt den Vorschlägen der Forschenden.

Wie in den SSH-Versionshinweisen erwähnt, sollte jede dieser Änderungen ausreichen, um den Terrapin-Angriff zu stoppen.

So entschärfen Sie CVE-2023-48795 ohne Upgrade

Die Forscher von Terrapin stellen ein einfaches Tool bereit, mit dem überprüft werden kann, ob Ihr SSH-Client und -Server anfällig sind.

OpenSSH

Um CVE-2023-48795 abzumildern, deaktivieren Sie die anfällige ChaCha20-Poly1305 -Chiffre in den OpenSSH-Client- und Serverkonfigurationen.

Fügen Sie insbesondere Folgendes zu /etc/ssh/ssh(d)_config hinzu:

Chiffren -chacha20-poly1305@openssh.com

Beachten Sie das „-“ am Anfang der chacha20-Chiffre-Zeichenfolge.

Starten Sie anschließend Ihren SSH-Server neu, damit die Änderung wirksam wird.

Stellen Sie außerdem sicher, dass Sie in Ihrer OpenSSH-Konfiguration keine aes(128|192|256)-cbc-Chiffren explizit aktivieren, während Sie die Standard-MACs verwenden (diese Chiffren sind standardmäßig deaktiviert).

Paramiko

Paramiko unterstützt die ChaCha20-Poly1305-Chiffre nicht. Um CVE-2023-48795 zu entschärfen, deaktivieren Sie bei Verbindungen mit Paramiko aes(128|192|256)-cbc und alle EtM-MACs.

Dies ist ab Paramiko-Version 2.6 verfügbar.

Ein Beispiel:

import paramiko

SERVER_IP = '127.0.0.1'

ssh_client = paramiko.SSHClient()
ssh_client.set_missing_host_key_policy(paramiko.AutoAddPolicy())
ssh_client.connect(SERVER_IP, disabled_algorithms={'ciphers': ['aes128-cbc', 'aes192-cbc', 'aes256-cbc'], 'macs': ['hmac-sha2-256-etm@openssh.com', 'hmac-sha2-512-etm@openssh.com']})

Behebung von CVE-2023-48795 mit JFrog Xray und JFrog Advanced Security

JFrog Xray Advanced Security
JFrog Security Essentials (Xray) und JFrog Advanced Security können verwendet werden, um jedes Vorkommen von Sicherheitslücken in Ihrer gesamten Codebasis und in kompilierten Artefakten zu identifizieren, einschließlich Docker-Containern, Repository-Paketen und sogar eigenständigen Binärdateien.

Bleiben Sie mit JFrog Security Research auf den Laufenden

Die Erkenntnisse und Forschungsarbeit des Security Research Teams spielen eine wichtige Rolle bei der Verbesserung der Sicherheitsfunktionen der JFrog Platform für Anwendungssoftware.

Verfolgen Sie die neuesten Entdeckungen und technischen Updates des JFrog Security Research Teams auf unserer Forschungswebsite und auf X unter @JFrogSecurity.