muhammad-ali007/log4j_cve-2021-44228Exercice pratique de laboratoire pour exploiter Log4Shell (CVE-2021-44228) avec injection JNDI, serveurs de référence LDAP et charges utiles de shell inversé. Inclut la détection, les techniques de contournement et les conseils de post-exploitation.
La vulnérabilité Log4j, également connue sous le nom de « Log4Shell » ou « CVE-2021-44228 », est une faille de sécurité critique dans la bibliothèque Apache Log4j. Log4j est un framework de journalisation basé sur Java, très largement utilisé, qui permet aux développeurs d'envoyer des messages de journalisation d'applications vers diverses destinations, comme des fichiers, des bases de données ou des sorties console.
La vulnérabilité a été découverte en décembre 2021 et a suscité une attention considérable en raison de sa gravité et de son potentiel d'exploitation. Elle affecte les versions 2.x de Log4j et, dans certains cas, même les versions antérieures. La vulnérabilité Log4j est une vulnérabilité d'exécution de code à distance (RCE), ce qui signifie qu'un attaquant peut exécuter du code arbitraire sur un système cible en exploitant la faille. Elle est causée par un défaut de conception dans la bibliothèque Log4j lié au traitement des messages de journalisation contenant des données spécialement conçues.
L'exploitation de la vulnérabilité repose sur la capacité d'injecter du code malveillant dans le message de journalisation. Cela peut se faire par divers vecteurs, tels que des champs de saisie contrôlés par l'utilisateur, des en-têtes de requêtes HTTP ou d'autres données fournies par l'utilisateur qui sont transmises à l'instruction de journalisation.
Lorsqu'une application vulnérable traite un message de journalisation contenant ces données spécialement conçues, Log4j interprète ces données comme une recherche JNDI (Java Naming and Directory Interface). En exploitant ce comportement, un attaquant peut élaborer une charge utile qui déclenche une recherche JNDI vers un serveur malveillant contrôlé par l'attaquant. Ce serveur peut alors répondre avec une charge utile qui est exécutée sur le système cible, permettant ainsi à l'attaquant de réaliser une exécution de code à distance.
L'impact de la vulnérabilité Log4j est sévère car Log4j est largement utilisé dans diverses applications basées sur Java, notamment les serveurs web, les applications et les services cloud. La vulnérabilité permet aux attaquants d'obtenir un accès non autorisé aux systèmes concernés, ce qui peut potentiellement conduire à des violations de données, au compromission du système et à une exploitation plus poussée de l'environnement compromis.
Aujourd'hui, la version 2.16.0 de log4j est disponible et corrige cette vulnérabilité (JNDI est entièrement désactivé, la prise en charge des Message Lookups est supprimée, et la nouvelle vulnérabilité DoS CVE-2021-45046 n'est pas présente). (https://github.com/apache/logging-log4j2/releases/tag/rel%2F2.16.0)
Cependant, le danger immense de cette vulnérabilité vient du caractère omniprésent du paquet de journalisation. Des millions d'applications ainsi que des fournisseurs de logiciels utilisent ce paquet comme dépendance dans leur propre code. Bien que vous puissiez corriger votre propre base de code utilisant log4j, d'autres éditeurs et fabricants devront toujours pousser leurs propres mises à jour de sécurité en aval. De nombreux chercheurs en sécurité ont comparé cette vulnérabilité à Shellshock en raison de son immense surface d'attaque. Nous verrons cette vulnérabilité pendant des années encore.
Pour une liste croissante, soutenue par la communauté, de logiciels et de services vulnérables à CVE-2021-44228, consultez ce dépôt GitHub (https://github.com/YfryTchsGD/Log4jAttackSurface)
Bien qu'il existe de nombreux autres articles, blogs, ressources et supports pédagogiques autour de CVE-2021-44228, je (l'auteur de cet exercice) suis particulièrement attaché à ceux-ci :
Le paquet log4j ajoute une logique supplémentaire aux journaux en « analysant » les entrées, afin d'enrichir les données — mais il peut également entreprendre des actions et même évaluer du code en fonction des données de l'entrée. C'est l'essentiel de CVE-2021-44228. D'autres syntaxes peuvent en réalité être exécutées telles qu'elles sont saisies dans les fichiers journaux. Quelques exemples de cette syntaxe sont :
Vous connaissez peut-être déjà la charge utile générale permettant d'abuser de cette vulnérabilité log4j. Le format de la syntaxe habituelle qui l'exploite ressemble à ceci :
Cette syntaxe indique que log4j invoquera des fonctionnalités de « JNDI », ou « Java Naming and Directory Interface ». En fin de compte, cela peut être utilisé pour accéder à des ressources externes, ou « références », ce qui est précisément ce qui est utilisé comme arme dans cette attaque.
Remarquez le schéma « ldap:// ». Cela indique que la cible contactera un point de terminaison (un emplacement contrôlé par l'attaquant, dans le cas de cette attaque) via le protocole LDAP. Par souci de concision, nous n'avons pas besoin de couvrir ici tous les détails de LDAP, mais sachez que c'est quelque chose avec lequel nous devrons travailler lorsque nous affinerons notre attaque. Pour l'instant, sachez que la cible établira en effet une connexion vers un emplacement externe. Cela est indiqué par l'espace réservé ATTACKERCONTROLLEDHOST dans la syntaxe ci-dessus. Vous, en tant qu'attaquant dans ce scénario, pouvez héberger un simple auditeur pour visualiser cette connexion.
La question suivante est : où pouvons-nous saisir cette syntaxe ? Partout où des données sont journalisées par l'application.
C'est le cœur de cette vulnérabilité. Malheureusement, il est très difficile de déterminer où se trouve la surface d'attaque pour différentes applications et, par conséquent, quelles applications sont réellement vulnérables. Le simple fait de voir la présence de fichiers log4j ne renseigne pas sur le numéro de version exact, ni même sur l'endroit ou la manière dont l'application pourrait utiliser le paquet.
Autres endroits où vous pouvez fournir cette syntaxe JNDI :
Si vous souhaitez plus d'informations sur ce vecteur d'attaque JNDI, veuillez consulter cette présentation Black Hat USA de 2016. https://www.blackhat.com/docs/us-16/materials/us-16-Munoz-A-Journey-From-JNDI-LDAP-Manipulation-To-RCE.pdf
POC
