Skip to content
KitploitKITPLOIT
FerramentasBlog
Enviar
FerramentasBlog
Enviar

Ferramentas de Hacking, PenTest e Cibersegurança para o seu Arsenal de Segurança!

Kitploit é um diretório de ferramentas de hacking, cibersegurança e pentesting. Descubra as últimas atualizações de projetos para encontrar vulnerabilidades, analisar sistemas, automatizar testes e fortalecer sua segurança.

··Feeds·Contato·Privacidade·© 2026 Kitploit

Diretório de Ferramentas

Categorias

Ver todas as categorias
Loading categories
Ferramentas/GitHubGitHub/silasspringer/cve-2018-10933
Análise de VulnerabilidadesExploraçãoCTFAprendizado e EducaçãoExploração de BináriosLabs e Prática
GitHubsilasspringer/cve-2018-10933

CVE-2018-10933

Ver Repositório
há 3 anosAinda não revisado

Mais Populares

Ver todos →

Descubra as ferramentas mais usadas pela nossa comunidade.

Explore todas as ferramentas

Navegue pela nossa coleção de ferramentas

Ver todas as ferramentas →
Compartilhar

Desafio CTF de Prova de Conceito

Por Silas Springer

Baseado em CVE-2018-10933

Contexto

CVE-2018-10933 é uma vulnerabilidade descoberta em versões selecionadas do libSSH, que pode permitir acesso potencialmente irrestrito à máquina. A vulnerabilidade surge do tratamento inadequado dos cabeçalhos de pacotes durante o processo de autenticação, onde o envio de um pacote manipulado com o byte MSG_USERAUTH_SUCCESS pode permitir que qualquer pessoa ignore a autenticação. Eles então têm acesso total à máquina.

A base deste desafio, então, é exigir que os competidores investiguem a imagem docker fornecida, descubram esta vulnerabilidade, explorem-na para obter acesso e, em seguida, encontrem a chave escondida em um link simbólico na máquina.

Exemplo de Descrição do Desafio CTF

root@kitploit:~
Someone got into my machine via port 22...
It looks like they didnt even know my credentials.

Anyways, they made a file with an odd name, but it's gone now, 
I wonder if there's still some trace of the filename - 
it might be something symbolic of the attacker...

Can you figure out how they got in and help me find the filename?

Solução

A seguir está um passo a passo detalhado da solução pretendida:

Observe, pela Descrição do Desafio, que o atacante obteve acesso através da porta 22, uma porta tipicamente reservada para SSH. Observe também que o atacante não usou credenciais para obter acesso.

A partir disso, se você procurar por erros passados relacionados a obter acesso a uma máquina via SSH sem credenciais, o problema com o byte MSG_USERAUTH_SUCCESS é bastante provável. Alternativamente, iniciando uma conexão na porta 22, pode-se determinar a versão do libSSH que está sendo executada e então procurar por exploits comuns para essa versão.

Também é possível ver pela Descrição que o nome do arquivo que procuram (a flag) existe apenas como alvo de um link simbólico.

Sabendo agora que o acesso pode ser obtido explorando esta vulnerabilidade, pode-se escrever o seu próprio script ou copiar um exemplo que execute este exploit e execute um comando na máquina alvo. Adaptei um script de exploração para esta solução e o chamei de libsshauthbypass.py.

Para executar este script e obter a flag da máquina, no caso da imagem de demonstração, pode-se executar um comando semelhante ao seguinte:

root@kitploit:~
./libsshauthbypass.py --host localhost -p 1337 -c 'find / -type l -exec stat {} + | grep "File:" | sed -E "s/.*\-> (.*)$/\1/g" | grep "definitelyarealCTF"'
-- Nota: isso assume que a imagem está sendo executada localmente, ou que um túnel para o contêiner em execução foi estabelecido via localhost:1337

que então produz uma saída semelhante a

root@kitploit:~
sspringer-fedora-CVE: ./libsshauthbypass.py --host localhost -p 1337 -c 'find / -type l -exec stat {} + | grep "File:" | sed -E "s/.*\-> (.*)$/\1/g" | grep "definitelyarealCTF"'
INFO:paramiko.transport:Connected (version 2.0, client libssh_0.8.1)
definitelyarealCTF{totally_a_REAL_flag}

Reutilização

Para usar uma versão deste desafio no seu próprio CTF, é altamente recomendável alterar o Dockerfile para usar um caminho diferente do padrão, alterar a flag em flag.txt (embora ainda deva ser uma linha) e então reconstruir a imagem. Note que pode ser necessário hospedar um novo contêiner para cada tentativa de conexão para evitar que alguém execute um comando destrutivo e afete todos os participantes.

Para reconstruir a imagem docker com uma nova flag (e testá-la)

  • Atualize flag.txt com a nova flag
  • Execute ./build_run <image name>[:<version number] <port number>
  • Utilize ./libsshauthbypass.py ou seu próprio script para contactar o contêiner com o payload correto e um comando que deseje executar
  • Ao sair do shell fornecido pelo script build_run, o contêiner será desligado e excluído, mas a imagem permanecerá e será marcada como <image name>

Vídeos

Prova de Conceito: https://youtu.be/ELrOBm02ANg

Passo a passo do desafio https://youtu.be/Ii121piSZR0

Baixar ferramenta