Les vulnérabilités de Log4j s'accumulent alors que les entreprises se bousculent pour mettre à jour les correctifs

Dec 21 2021
La crise gargantuesque suscitée par log4j n'est pas encore terminée, même pas proche. Au cours de la semaine dernière, de nouvelles vulnérabilités ont été découvertes dans la malheureuse bibliothèque de journalisation Apache (dont la vulnérabilité omniprésente est surnommée "Log4Shell" dans le monde de l'infosec) mais, selon les experts, il n'y a pas lieu de paniquer.

La crise gargantuesque suscitée par log4j n'est pas encore terminée, même pas proche. Au cours de la semaine dernière, de nouvelles vulnérabilités ont été découvertes dans la malheureuse bibliothèque de journalisation Apache (dont la vulnérabilité omniprésente est surnommée "Log4Shell" dans le monde de l'infosec) mais, selon les experts, il n'y a pas lieu de paniquer. Voici un bref aperçu des derniers développements et de la réaction des professionnels de la sécurité.

L'application de correctifs logiciels n'est pas toujours un processus très simple, et cela n'a été nulle part plus évident que dans le fiasco log4j. Au cours de la semaine dernière, Apache a publié plusieurs correctifs, mais avec chaque correctif successif, des problèmes supplémentaires sont apparus.

Vendredi, Apache a publié son troisième correctif, la version 2.17.0 , destiné à corriger une vulnérabilité récemment découverte qui aurait permis des attaques par déni de service (cette nouvelle faille est officiellement suivie sous le nom de CVE-2021-45105 ).

Le correctif précédent, 2.16.0 , avait été publié après que le 2.15.0 - le correctif d'origine - n'ait pas réussi à atténuer un exploit d'attaque à distance qui, dans certains cas, aurait pu permettre le vol de données. En d'autres termes, le correctif destiné à corriger la vulnérabilité d'origine avait sa propre vulnérabilité et le correctif pour corriger ce correctif avait également des problèmes. Bon produit.

Cela dit, ces nouvelles failles de sécurité ne sont pas aussi graves que l'original et ne devraient pas être une raison de perdre trop de sommeil, selon certains experts.


Il s'agit de la vulnérabilité d'origine, CVE-2021-44228 , qui, si elle n'est pas corrigée, fait toujours l'objet de cauchemars en matière de cybersécurité.

Un autre épisode coloré de cette saga a été un débat récent parmi les professionnels de la sécurité pour savoir si log4j avait donné naissance à un ver ou non.

Dimanche, un chercheur en sécurité, Germán Fernández,  a affirmé avoir repéré un ver - un programme malveillant qui se propage automatiquement - qui affectait les appareils qui n'avaient pas corrigé la vulnérabilité log4j. VX Underground, un grand référentiel en ligne d'échantillons de logiciels malveillants et d'universités connexes, a partagé les conclusions du chercheur : « Le chercheur en sécurité @1ZRR4H a identifié le premier ver Log4J. Il s'agit d'un bot Mirai auto-propagé. Nous avons agrégé l'échantillon », a tweeté le compte de VX . Greg Linares, un autre chercheur en sécurité, a déclaré qu'il semblait que le programme malveillant ciblait principalement les routeurs Huawei non corrigés.

Cependant, d'autres experts ont rapidement jeté de l'eau froide sur certaines de ces affirmations, soulignant que le programme ne semblait pas tout à fait fonctionnel et pourrait même ne pas être techniquement qualifié de ver. "J'ai procédé à une rétro-ingénierie de ce prétendu ver log4j et cela ne fonctionne pas du tout", a tweeté Marcus Hutchins, un éminent chercheur en cybersécurité. "Il y a aussi plusieurs bogues dans le code qui signifient que même s'ils corrigeaient la défaillance du noyau, il serait toujours complètement inefficace."


Les experts en sécurité se sont également disputés sur la gravité d'un ver dans le contexte de log4j. Tom Kellermann, responsable de la stratégie de cybersécurité chez VMware, a récemment déclaré à ZDnet qu'un ver pourrait être potentiellement "armé" par une puissance étrangère ou un service de renseignement hostile, dont le résultat final pourrait être assez mauvais.

Pendant ce temps, une explosion de tentatives d'exploitation visant log4j continue de révéler de nouvelles stratégies d'attaque.

Lundi, le ministère belge de la Défense a révélé qu'il avait été contraint de fermer certaines parties de son réseau après qu'un groupe de pirates ait exploité log4j pour accéder à ses systèmes. Bien que peu de choses aient été révélées sur l'incident, c'est l'un des exemples les plus visibles à ce jour de l'utilisation du bogue Apache pour causer des dommages dans le monde réel. Ce ne sera certainement pas le dernier.

En effet, des rapports récents montrent que des groupes criminels à motivation financière rejoignent la mêlée, y compris des chevaux de Troie bancaires. En plus de cela, des gangs de ransomwares, des activités de cyberespionnage d'États-nations et de crypto-minage ont également tous été repérés. Les courtiers d'accès initiaux - des cybercriminels qui piratent des appareils et des réseaux informatiques avec l'intention de retourner et de vendre cet accès à d'autres criminels (principalement des pirates de rançongiciels) - ont pillé les systèmes vulnérables log4j. L'équipe de sécurité de Microsoft a publié la semaine dernière des recherches qui ont montré 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".

En bref : le plaisir continue ! Nous continuerons à suivre les changements plus larges de toute cette crise au fur et à mesure qu'elle se déroule.