nickstadb/pocRepositório para exploits de prova de conceito e ferramentas.
Repositório para exploits e ferramentas de prova de conceito.
Exploit de execução remota de comandos não autenticado para o agente RSCD do BMC Server Automation. O exploit funciona contra servidores afetados pela CVE-2016-1542 (detectada pelo Nessus).
Este agora é um módulo do Metasploit, veja exploits/multi/misc/bmc_server_automation_rscd_nsh_rce
O exploit foi criado ao fazer o Nessus escanear um script Python que gravava pacotes e os enviava/lixo de volta ao Nessus. Com os pacotes capturados, o formato dos dados era trivial de "reverter" para criar um exploit parcialmente funcional. Mais tarde, tive acesso ao software do agente afetado e pude usar um depurador e um pouco de fuzzing para eliminar as falhas e transformar isso em um exploit RCE sólido.
Confira meus posts no blog sobre como construí o exploit para mais detalhes:
Exploit de execução remota de código não autenticado para HP Device Manager versões 5.0.0 a 5.0.3 (CVE-2020-6926, CVE-2020-6927).
O exploit tira proveito de um serviço Java RMI não autenticado que possui uma vulnerabilidade de injeção de Hibernate Query Language. A injeção de ORM é usada para contrabandear um payload de injeção de SQL do Postgres para sobrescrever o arquivo pg_hba.conf no servidor HP Device Manager, permitindo acesso remoto ao banco de dados Postgres que vem com o HPDM. Uma vez habilitado, uma conta de superusuário backdoor é usada para autenticar no banco de dados Postgres e executar comandos arbitrários do sistema operacional.
Confira meu post no blog sobre como descobri essas vulnerabilidades para mais detalhes:
Embora este exploit funcione apenas contra HPDM 5.x, o serviço Java RMI não autenticado está presente em todas as versões do HPDM anteriores a 5.0.4 e ao service pack 13 do 4.7. O impacto de explorar esse serviço pode ser menor, mas ainda há uma vulnerabilidade HQLi/SQLi, além da capacidade de extrair configuração (potencialmente incluindo senhas de outros serviços) e todos os nomes de usuário das contas HPDM e os hashes de senha MD5 correspondentes.
Exploit de execução remota de código não autenticado para endpoints de serviço Java JNBridge configurados de forma insegura. Baseado no trabalho de Moritz Bechler (CVE-2019-7839).
O protocolo de rede implementado pelo JNBridge é projetado unicamente para facilitar a execução remota de código para interoperabilidade entre aplicações Java e .NET. Assim, isso não é tecnicamente um exploit, apenas um pequeno e útil script Python para executar comandos arbitrários contra um endpoint Java JNBridge.
Confira meu post no blog para um passo a passo da minha jornada desde o comunicado de segurança até a produção de um exploit completo:
Este exploit visa a funcionalidade insegura de atualização automática no WordPress para implantar um shell PHP no servidor subjacente. O exploit foi testado com sucesso até o WordPress 4.9.8, que é a versão mais recente na data de publicação.
Quando o WordPress verifica atualizações, ele tenta uma conexão HTTPS segura com api.wordpress.org. Se essa conexão falhar, por exemplo, porque um certificado não confiável é apresentado, o WordPress recorre a uma conexão HTTP insegura.
A segunda questão é que o WordPress confia em atualizações de tradução. Ele não atualiza automaticamente plugins, temas ou versões principais do núcleo, presumivelmente devido aos riscos de instalar novo código no servidor. No entanto, ele atualiza automaticamente traduções. Infelizmente, o WordPress não valida adequadamente os arquivos de tradução; portanto, desde que o arquivo ZIP de tradução contenha pelo menos um arquivo com a extensão .po e um arquivo com a extensão .mo, o WordPress extrairá o conteúdo para o servidor subjacente (incluindo o shell inserido lá pelo MitM).
Me deparei com esses problemas por acidente, mas quando os relatei (novembro de 2017), a equipe do WordPress basicamente disse WONTFIX por causa da compatibilidade com versões anteriores. Se alguém estiver executando o WordPress em um servidor que não consegue estabelecer uma conexão SSL/TLS de saída, ainda assim deve ser capaz de atualizar o WordPress automaticamente por razões de segurança, dizem eles.
¯\_(ツ)_/¯
Confira meu post no blog para mais detalhes:
