Faille du protocole SSH : attaque Terrapin CVE-2023-48795, tout ce qu’il faut savoir

L’attaque Terrapin contre SSH (CVE-2023-48795) a récemment attiré l’attention. Elle cible la sécurité du protocole SSH en tronquant des informations cryptographiques. Cette faille inhérente au protocole SSH lui-même touche un large éventail d’implémentations clientes et serveurs SSH. Dans la continuité de notre première communication sur ces recherches, cet article en présente les principes fondamentaux et les répercussions.

• Implémentations affectées
• Impacts de l’exploitation de l’attaque Terrapin
• Présentation de la CVE-2023-48795
• Analyse de CVE-2023-48795
• Comment la CVE-2023-48795 a été corrigée dans OpenSSH
• Résolution de la CVE-2023-48795 avec JFrog Xray et JFrog Advanced Security

Implémentations affectées

De nombreuses implémentations de clients et de serveurs SSH sont affectées, telles que OpenSSH, paramiko, PuTTY, KiTTY, WinSCP, libssh, libssh2, AsyncSSH, FileZilla, et bien d’autres. Voici la liste complète des implémentations affectées connues.

Impacts de l’exploitation de l’attaque Terrapin

1. Les attaques par rétrogradation de signature, qui compromettent la sécurité d’une connexion SSH de plusieurs manières.
2. Dans l’implémentation OpenSSH, plus précisément dans les versions postérieures à la version 9.5, l’attaque contourne la fonctionnalité de brouillage temporel des frappes au clavier. Cela peut permettre à des pirates utilisant des attaques de type homme du milieu (MitM) de forcer les mots de passe SSH par force brute en inspectant les paquets réseau SSH.

Présentation de la CVE-2023-48795

L’attaque Terrapin est un nouveau type d’attaque visant le protocole SSH lui-même. Au moyen d’une attaque de type homme du milieu (MitM), elle amène le client compromis à croire à tort que le serveur ne prend pas en charge les algorithmes de signature récents utilisés pour l’authentification des utilisateurs.

La vulnérabilité affecte toutes les connexions SSH. Cette étude se concentre sur l’implémentation OpenSSH.

Deux configurations OpenSSH sont vulnérables :

1. ChaCha20-Poly1305
2. Tous les chiffrements aes(128|192|256)-cbc utilisant les MAC par défaut (ou tout MAC recourant au mécanisme Encrypt-then-MAC, EtM, par exemple hmac-sha2-256-etm@openssh.com).

Les configurations par défaut du client et du serveur OpenSSH sont vulnérables à cette attaque, car elles autorisent le chiffrement ChaCha20-Poly1305 vulnérable.

Remarque : mettre à jour le serveur ou le client ne suffit pas ! Les deux doivent être corrigés. Un client vulnérable se connectant à un serveur corrigé entraînera tout de même une connexion vulnérable.

Analyse de CVE-2023-48795

L’exploitation de la CVE-2023-48795 permet à un pirate utilisant une attaque de type homme du milieu de tronquer des parties importantes de la négociation SSH sans fermer la connexion SSH, ce qui a des répercussions sur la sécurité du client et du serveur SSH. Pour examiner les répercussions de l’attaque, intéressons-nous aux particularités de la négociation SSH.

Négociation SSH

Négociation SSHNégociation SSH
Le client établit une connexion TCP, puis un échange de versions du protocole est effectué (conformément à la RFC 4253).

D’après la RFC, une négociation des algorithmes a ensuite lieu. La RFC indique ce qui suit :

Choisir le premier algorithme qui remplit les conditions suivantes :

    +  le serveur prend également en charge l’algorithme

Cela signifie que le client choisira le premier algorithme pris en charge par le serveur. Dans la configuration OpenSSH par défaut, il s’agira de chacha20-poly1305@openssh.com.

Message EXT_INFO

D’après la RFC 8308, le message permet de prendre en charge les extensions de protocole de manière sécurisée après l’échange de clés SSH. Le message EXT_INFO joue un rôle très important dans l’attaque. Ce package peut être tronqué en raison de la faille Terrapin, ce qui entraîne une rétrogradation de la sécurité et la désactivation de la fonctionnalité de brouillage temporel des frappes au clavier d’OpenSSH 9.5p1 (voir la section « Brouillage temporel des frappes au clavier » ci-dessous).

L’extension de la liste des algorithmes de signature constitue un exemple d’extension de protocole. Des algorithmes modernes sont ajoutés à cette liste, notamment des algorithmes utilisant SHA-2. Lorsque le package est tronqué, la sécurité de la connexion est rétrogradée et celle-ci se rabat sur l’algorithme de hachage SHA-1. Celui-ci est considéré comme compromis en pratique et peut permettre plusieurs attaques contre la connexion SSH (par exemple, l’usurpation d’un compte au moyen d’une collision de hachage).

Le même package contient les messages suivants :

1. Message de réponse Kex (échange de clés)
2. Message New Keys
3. Message EXT_INFO

Voici le contenu d’un package SSH2_MSG_EXT_INFO provenant du journal de débogage d’un client :

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>

Détails pratiques

Les chercheurs ayant identifié l’attaque Terrapin ont révélé qu’un pirate utilisant une attaque de type homme du milieu (MitM) était capable de contourner le protocole cryptographique sélectionné. Dans ce scénario, le pirate peut supprimer le message EXT_INFO, normalement utilisé pour négocier différentes extensions de protocole, sans éveiller les soupçons du client ni du serveur.

En temps normal, le client détecterait la suppression du package lors de la réception du package binaire suivant envoyé par le serveur, car elle provoquerait une incohérence des numéros de séquence.

Attaque Terrapin de type homme du milieuAttaque Terrapin de type homme du milieu

Pour éviter cela, le pirate introduit stratégiquement un package pendant le processus de négociation afin de manipuler les numéros de séquence et d’échapper ainsi à la détection. Le contenu précis du package injecté dépend de l’algorithme cryptographique que l’on souhaite contourner :

1. ChaCha20-Poly1305 : le pirate utilisant l’attaque MitM injecte un message SSH2_MSG_IGNORE avant la fin de la négociation. La modification des numéros de séquence permet au pirate MitM de supprimer EXTINFO à l’intérieur du canal sécurisé.
2. CBC-EtM : le pirate MitM injecte un message UNKNOWN avant la fin du handshake. Comme dans le scénario précédent, cela lui permet de supprimer EXTINFO à l’intérieur du canal sécurisé. Cependant, dans ce cas, le taux de réussite est probabiliste. Voyons pourquoi : il existe deux approches différentes pour utiliser les MAC (codes d’authentification de message) : EaM (Encrypt-and-MAC) et EtM (Encrypt-then-MAC). Dans l’approche EaM, le MAC est calculé sur le texte en clair. Lorsque le pirate utilise Terrapin pour tronquer le texte chiffré dans ce mode, le texte en clair obtenu après déchiffrement est pseudo-aléatoire. Comme EaM calcule le MAC à partir du texte en clair, la vérification du MAC échouera presque certainement et l’attaque n’aura donc aucune incidence sur la sécurité. La situation est différente avec EtM, où le MAC est calculé à partir du texte chiffré. Dans ce cas, la longueur du package n’est pas chiffrée afin que le MAC puisse être vérifié avant le déchiffrement. Lorsque le pirate utilise Terrapin pour tronquer le texte chiffré dans ce mode, il peut modifier la longueur non chiffrée. La vérification du MAC a alors de fortes chances de réussir, ce qui permet au pirate de tronquer des packages. Plus précisément, cela permet au pirate MitM de supprimer EXTINFO à l’intérieur du canal sécurisé, comme dans le scénario ChaCha20-Poly1305. EtM a été ajouté ultérieurement afin d’améliorer SSH. Avec CBC-EtM, le MAC est calculé à partir du numéro de séquence, de la longueur non chiffrée du package et du texte chiffré du package. Le taux de réussite de l’attaque est probabiliste, car la vérification du MAC risque d’échouer lorsque le pirate procède à la troncation (c’est-à-dire au découpage du package EXT-INFO). Cela dépend des particularités de l’implémentation cryptographique concernée.

Répercussion nº 1 : attaque par rétrogradation de signature

L’exécution de l’attaque contre OpenSSH afin de démontrer les répercussions de la vulnérabilité peut entraîner des problèmes d’authentification des utilisateurs, comme l’explique cette section.

La construction du message est visible dans le code suivant (extrait d’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;
}

Attaque par rétrogradation de signature
Une liste d’arguments est ajoutée au package sous server-sig-algs. Cette liste concerne l’une des méthodes disponibles, à savoir l’authentification au moyen d’une clé publique.

Elle indique précisément les algorithmes de signature pris en charge et détermine donc s’il est possible de communiquer au moyen d’une signature donnée. Sans cette liste, le serveur et le client ne peuvent pas utiliser les algorithmes de signature les plus récents (par exemple rsa-sha2-512, qui utilise le hachage SHA-2 avec SHA-512), conformément à la RFC 8308.

Pour démontrer l’attaque par rétrogradation, nous utiliserons la preuve de concept de Terrapin et obligerons le client à se connecter au serveur au moyen d’une authentification par mot de passe (au lieu de l’authentification habituelle par clé). Cette méthode de connexion est moins robuste que l’authentification par clé. Elle peut être utilisée pour imposer les conditions de connexion qui entraînent la deuxième répercussion de cette attaque (voir la section suivante, « Contournement du brouillage temporel des frappes au clavier »).

Exécutons l’attaque en injectant un package IGNORE et en supprimant le message EXT_INFO, de façon à nous connecter au serveur MitM plutôt qu’au serveur SSH normal.
Notre clé publique, précédemment reconnue et acceptée, n’est désormais plus utilisée. Une autre méthode d’authentification est employée (en l’occurrence un mot de passe dans notre exemple) :

En examinant les journaux de débogage du serveur OpenSSH, nous pouvons constater la différence par rapport à une connexion normale.
Avec la connexion normale (dans laquelle la clé publique a été acceptée), les journaux contiennent les informations suivantes :

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]

Lors de la connexion au serveur MitM et de la rétrogradation de la signature, les journaux sont les suivants :

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]

Un client OpenSSH exécuté en mode débogage afficherait également le message d’erreur suivant :

debug1: send_pubkey_test: no mutual signature algorithm

Cette erreur est due à l’absence de server-sig-algs dans le message EXT_INFO.
Cela signifie essentiellement que le client ne peut pas utiliser l’authentification par clé.

Impact n° 2 – Contournement de l’obfuscation du timing des frappes

L’étude The Timing Analysis of Keystrokes and Timing Attacks on SSH (également présentée sous forme de conférence), publiée il y a 12 ans, a montré comment l’analyse du rythme des frappes au clavier pouvait permettre de déduire la longueur exacte du mot de passe d’un utilisateur, puis d’utiliser les intervalles précis entre les frappes pour découvrir ce mot de passe.

OpenSSH 9.5p1 a introduit une nouvelle fonctionnalité de sécurité appelée « brouillage temporel des frappes au clavier ». Cette fonctionnalité masque le rythme des frappes en envoyant du trafic à intervalles fixes (par défaut toutes les 20 millisecondes), plutôt qu’immédiatement après chaque frappe.

Pour que le brouillage soit activé, le client et le serveur doivent tous deux intégrer cette fonctionnalité. (Ils doivent donc utiliser au minimum OpenSSH 9.5p1.)
Ces informations de compatibilité sont transmises dans le message EXT_INFO, que l’attaque Terrapin permet de supprimer.

Les captures d’écran Wireshark ci-dessous montrent cette fonctionnalité à l’œuvre sur une connexion normale utilisant OpenSSH 9.5p1 :

Capture Wireshark d’une connexion SSH normale utilisant OpenSSH 9.5p1Capture Wireshark d’une connexion SSH normale utilisant OpenSSH 9.5p1

Les durées affichées à proximité des numéros de package correspondent au nombre de secondes écoulées depuis le précédent package affiché. On peut constater un intervalle de 20 à 21 millisecondes, dû au fonctionnement de la fonctionnalité de brouillage.

Exécutons l’attaque en injectant un package IGNORE et en supprimant le message EXT_INFO, de façon à nous connecter au serveur MitM plutôt qu’au serveur SSH normal.
Voici la capture Wireshark de la connexion SSH interceptée par le pirate MitM :

Capture Wireshark d’une connexion SSH interceptée par un pirate MitM utilisant OpenSSH 9.5p1Capture Wireshark d’une connexion SSH interceptée par un pirate MitM utilisant OpenSSH 9.5p1

Cette connexion a été établie avec la même version OpenSSH 9.5p1 côté client et côté serveur. Nous pouvons constater que le brouillage temporel a été contourné, puisque les packages envoyés au cours de la connexion présentent des intervalles différents.

Il convient de noter qu’en l’absence de brouillage temporel des frappes au clavier (ou lorsque celui-ci est contourné dans OpenSSH 9.5p1), une rétrogradation de signature peut être utilisée pour découvrir efficacement le mot de passe, comme l’explique l’étude sur l’analyse temporelle des frappes au clavier dans SSH.

Comment la CVE-2023-48795 a été corrigée dans OpenSSH

Dans l’article de recherche technique original consacré à l’attaque Terrapin, les chercheurs ont proposé deux contre-mesures (section 8) : 1. réinitialiser les numéros de séquence et 2. vérifier l’intégralité du processus de négociation.

La première contre-mesure consiste à réinitialiser les numéros de séquence. Si les numéros de séquence du client ou du serveur sont remis à zéro lors de l’activation des clés de chiffrement, les manipulations décrites précédemment ne peuvent pas affecter le chiffrement.

Pour renforcer la sécurité, la seconde contre-mesure consiste à vérifier l’intégralité du processus de négociation entre le client et le serveur afin de détecter toute tentative de manipulation par un pirate utilisant une attaque de type homme du milieu. Cette authentification comprend l’échange d’un code d’authentification de message (MAC) portant sur l’intégralité de la transcription au début du canal sécurisé, à la manière des messages FINISHED de TLS.

OpenSSH a corrigé ce problème en mettant en œuvre un nouveau protocole « strict KEX », qui fonctionne comme suit :

1. Si un package reçu ne correspond pas au type attendu ou correct, ou si le premier package n’est pas SSH2_MSG_KEXINIT, la connexion doit être interrompue.
   Les packages inattendus comprennent des messages tels que SSH2_MSG_DEBUG et SSH2_MSG_IGNORE, même si ceux-ci sont généralement valides pendant la connexion. Ce sont les types de messages qui rendent l’attaque possible.
2. Après l’envoi ou la réception d’un message SSH2_MSG_NEWKEYS, le numéro de séquence des packages doit être réinitialisé à zéro. Cette règle s’applique pendant toute la durée de la connexion, et pas seulement immédiatement après le message SSH2_MSG_NEWKEYS.

Les correctifs ont été publiés dans OpenSSH 9.6p1 et correspondent directement aux recommandations des chercheurs.

Comme l’indiquent les notes de version de SSH, chacune de ces modifications devrait suffire à bloquer l’attaque Terrapin.

Comment atténuer la CVE-2023-48795 sans effectuer de mise à niveau

Les chercheurs qui se sont consacrés à l’attaque Terrapin proposent un outil simple permettant de vérifier si votre client et votre serveur SSH sont vulnérables.

OpenSSH

Pour atténuer la CVE-2023-48795, désactivez le chiffrement ChaCha20-Poly1305 vulnérable dans les configurations du client et du serveur OpenSSH.

Plus précisément, ajoutez la ligne suivante à /etc/ssh/ssh(d)_config :

Ciphers -chacha20-poly1305@openssh.com

Notez le caractère ‘-‘ au début de la chaîne correspondant au chiffrement chacha20.

Redémarrez ensuite votre serveur SSH pour que la modification prenne effet.

Assurez-vous également de ne pas activer explicitement de chiffrement aes(128|192|256)-cbc dans votre configuration OpenSSH lorsque vous utilisez les MAC par défaut. (Ces chiffrements sont désactivés par défaut.)

Paramiko

Paramiko ne prend pas en charge le chiffrement ChaCha20-Poly1305. Pour atténuer la CVE-2023-48795 lors d’une connexion avec Paramiko, désactivez donc les chiffrements aes(128|192|256)-cbc ainsi que tous les MAC de type EtM.

Cette possibilité est disponible à partir de Paramiko 2.6.

Exemple :

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']})

Résolution de la CVE-2023-48795 avec JFrog Xray et JFrog Advanced Security

JFrog Xray Advanced Security
JFrog Security Essentials (Xray) et JFrog Advanced Security permettent d’identifier chaque occurrence vulnérable dans l’intégralité de votre code source et de vos artefacts compilés, y compris dans les conteneurs Docker, les packages des dépôts et même les fichiers binaires autonomes.

Tenez-vous au courant avec l’équipe JFrog Security Research

Les découvertes et les travaux de l’équipe de recherche en sécurité jouent un rôle important dans l’amélioration des fonctionnalités de sécurité des logiciels applicatifs de la plateforme JFrog.

Suivez les dernières découvertes et actualités techniques de l’équipe JFrog Security Research sur notre site consacré à la recherche ainsi que sur X, avec le compte @JFrogSecurity.