Discussion :

[Sandra Coret]

Les équipes de sécurité trouvent plus facile d'atténuer Log4Shell plutôt que de le corriger définitivement, le délai moyen de remédiation après détection est de 17 jours, selon Qualys Cloud Platform

Lorsque la vulnérabilité Log4Shell est apparue en décembre de l'année dernière, ses effets se sont fait sentir dans le monde de la cybersécurité, avec des millions de dispositifs potentiellement touchés.

Une nouvelle étude de Qualys examine la manière dont les entreprises ont réagi à cette vulnérabilité et le succès de leurs efforts de remédiation.

Les mauvais acteurs ont réagi rapidement, avec près d'un million de tentatives d'attaques lancées en 72 heures seulement après la divulgation de la vulnérabilité Log4Shell. Et bien sûr, les attaques ont eu lieu à l'approche des fêtes de fin d'année, alors que de nombreuses équipes de sécurité n'avaient que des effectifs réduits.

La Qualys Cloud Platform a analysé plus de 150 millions d'actifs informatiques à travers le monde et a détecté 22 millions d'installations d'applications vulnérables. Log4Shell a été détecté dans plus de trois millions d'instances vulnérables.

Plus de 50 % des installations d'applications avec Log4j ont été signalées comme étant "en fin de support", avec peu de chances que les éditeurs fournissent des correctifs de sécurité pour Log4Shell. Plus de 80 % des ressources vulnérables se trouvaient sur des systèmes Linux.

Le délai moyen de remédiation après détection était de 17 jours. Les systèmes qui pouvaient être exploités à distance ont été corrigés plus rapidement (12 jours), tandis que les systèmes internes ont été plus lents. Les efforts ont également ralenti après le premier mois, peut-être parce que les équipes de sécurité ont trouvé plus facile d'atténuer Log4Shell plutôt que de le corriger définitivement.

"Tout le monde parlait de cette vulnérabilité au début du mois de décembre et nous en parlons encore à la mi-mars. Cela montre qu'il y a encore beaucoup de choses à régler concernant les bases de la cybersécurité", déclare Paul Baird, responsable de la sécurité technique au Royaume-Uni chez Qualys. "En regardant les données, Log4J est incroyablement répandu et il a été discuté à grande échelle. Cette vulnérabilité est facile à exploiter lorsque les correctifs et les mesures d'atténuation n'ont pas été mis en œuvre. De par sa nature, Log4Shell est difficile à détecter, sauf si vous disposez d'outils capables de trouver la vulnérabilité dans tous les recoins de votre environnement. Les équipes sont incapables de prendre des mesures d'atténuation et sont donc en danger."

Qualys a également développé un nouvel utilitaire d'analyse Log4j open-source pour faire gagner un temps précieux aux équipes de sécurité.

Source : Qualys Cloud Platform

Et vous ?

Qu'en pensez-vous ?

Voir aussi :

Plus de 35 000 packages Java impactés par les vulnérabilités Log4j, selon un rapport de l'équipe open source de Google

Log4j : une entreprise du Fortune 500 exige des réponses rapides et gratuites du créateur de cURL, qui leur a indiqué qu'il le ferait « dès que nous aurons signé un contrat de support »

Un bogue vieux de 12 ans dans polkit permet d'obtenir des privilèges « root » sur les principales distributions GNU/Linux, Ubuntu et Red Hat ont déjà publié des correctifs

[Sandra Coret]

Les 10 principales cibles attaquables par Log4j, qui continue d'être un problème pour les entreprises : VMWare Horizon est en tête, suivie de Jamf et PingFederate, selon une étude de Randori

Cela fait maintenant plus de trois mois que la vulnérabilité Log4Shell, qui affecte le cadre de journalisation Log4j, est apparue. Mais une nouvelle étude de Randori montre qu'elle continue à donner des maux de tête aux entreprises et identifie les 10 principales cibles attaquables.

VMWare Horizon est en tête de liste, 10 % des grandes entreprises ayant une instance exposée à l'Internet. Si elle est piratée, elle donne à un pirate un accès en aval. VMware Horizon a été touché quelques semaines après l'apparition de la vulnérabilité et des courtiers d'accès vendent des accès via des exploits Log4j.

Viennent ensuite Jamf et PingFederate, qui sont utilisés par 1 à 2 % du marché des entreprises. Comme VMware, ils fournissent à un attaquant un accès supplémentaire en aval à d'autres systèmes - mécanismes d'authentification (Ping), d'automatisation (Jamf) - qui offrent aux attaquants une excellente occasion de pivoter et d'étendre leurs opérations.

Log4j étant enfoui profondément dans des couches et des couches de code tiers partagé, il est probable que la vulnérabilité Log4j continuera d'être exploitée dans les services utilisés par les organisations qui utilisent beaucoup de logiciels libres.

Il est conseillé aux entreprises de considérer que les actifs ayant un grand nombre d'accès sont les plus attaquables. Commencez par examiner les éléments que vous souhaitez le plus protéger et partez de là. Cela signifie qu'il faut ajouter la journalisation et la surveillance autour des applications clés ainsi que des actifs ayant un accès important, comme les VPN et les outils d'accès à distance.

Source : Randori

Et vous ?

Qu'en pensez-vous ?

Voir aussi :

Une vulnérabilité Log4J extrêmement critique met une grande partie d'Internet en danger

Log4j : la directrice du CISA s'attend à des retombées de la faille qui vont s'étendre sur des années, et servir à des intrusions futures dans les systèmes des entreprises

Log4j : une entreprise du Fortune 500 exige des réponses rapides et gratuites du créateur de cURL, qui leur a indiqué qu'il le ferait « dès que nous aurons signé un contrat de support »

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

[Bill Fassinou]

Un nouveau groupe de travail sur la cybersécurité affirme que la faille du logiciel Log4j est "endémique"
et qu'elle pourrait poser des risques de sécurité pendant une décennie ou plus

Alors que les organisations se démènent pour colmater les brèches liées à la faille du logiciel Log4j, un nouveau rapport estime que cette vulnérabilité est "endémique" et qu'elle posera des risques de sécurité pendant potentiellement une décennie ou plus. Le rapport, publié jeudi par un comité d'examen de la cybersécurité (The Cyber Safety Review Board - CSRB) créé par le président américain Joe Biden, indique également que la faille de Log4j est l'une des vulnérabilités logicielles les plus graves de l'histoire et que, même s'il n'y a pas eu de signe de cyberattaque majeure due cet exploit, les entreprises auront du mal à s'en débarrasser.

Log4j est une bibliothèque logicielle utilitaire open source programmée en langage Java. Il enregistre les événements - erreurs et opérations de routine d'un système - et communique des messages de diagnostic à leur sujet aux administrateurs et aux utilisateurs du système. Le logiciel est fourni par l'Apache Software Foundation. Un exemple courant de Log4j au travail est lorsque vous tapez ou cliquez sur un mauvais lien Web et obtenez un message d'erreur 404. Le serveur qui gère le domaine de l'adresse Web que vous avez essayé d'atteindre vous indique qu'il n'existe pas une page Web de ce type.

Il enregistre également cet événement dans un journal destiné aux administrateurs système du serveur à l'aide de Log4j. Des messages de diagnostic similaires sont utilisés dans toutes les applications logicielles. Par exemple, dans le jeu en ligne Minecraft, Log4j est utilisé par le serveur pour enregistrer des activités telles que la mémoire totale utilisée et les commandes utilisateur tapées dans la console. Seulement, une faille découverte dans le logiciel fin 2021 permettrait aux attaquants de prendre facilement le contrôle de tout, des systèmes de contrôle industriels aux serveurs Web et aux appareils électroniques grand public.

Les premiers signes évidents de l'exploitation de la faille sont apparus dans Minecraft de Microsoft. La découverte de la faille a suscité des mises en garde urgentes de la part des responsables gouvernementaux et des efforts massifs de la part des professionnels de la cybersécurité pour corriger les systèmes vulnérables. Le CSRB a déclaré jeudi qu'à sa grande surprise, l'exploitation du bogue de Log4j s'était produite à des niveaux inférieurs à ceux prévus par les experts. « Log4j est l'une des failles logicielles les plus graves de l'histoire », a déclaré le président du comité, Rob Silvers, sous-secrétaire du ministère de la Sécurité intérieure (DHS).

Le comité a ajouté qu'il n'avait pas connaissance d'attaques "importantes" liées à la vulnérabilité de Log4j sur des systèmes d'infrastructures critiques, mais a noté que certaines cyberattaques ne sont pas signalées. Le groupe a allégué que de futures attaques sont probables, en grande partie parce que Log4j est couramment intégré à d'autres logiciels et qu'il peut être difficile pour les organisations de détecter son fonctionnement dans leurs systèmes. Selon les analystes, la bibliothèque Log4j est extrêmement populaire auprès des développeurs de logiciels commerciaux. « Cet événement n'est pas terminé », prévient Silvers.

Pour mémoire, un chercheur en sécurité d'Alibaba a informé la fondation le 24 novembre. Il a fallu deux semaines pour développer et publier un correctif. Les médias chinois ont rapporté que le gouvernement avait puni Alibaba pour ne pas avoir signalé la faille plus tôt aux responsables de l'État. Le comité a déclaré jeudi qu'il avait trouvé des "éléments troublants" dans la politique du gouvernement chinois en matière de divulgation des vulnérabilités, affirmant que cela pouvait donner aux pirates informatiques de l'État chinois un aperçu précoce des failles informatiques qu'ils pouvaient utiliser à des fins néfastes.

La vulnérabilité de Log4j peut être exploitée à distance pour permettre l'exécution de code sur les systèmes vulnérables et a reçu un score de gravité CVSS maximal de 10 sur 10. Selon le CSRB, ces groupes affiliés à l'État chinois pourraient exploiter ce type de failles pour voler des secrets commerciaux ou espionner les dissidents. Le gouvernement chinois a longtemps nié tout acte répréhensible dans le cyberespace et a déclaré qu'il encourageait un meilleur partage des informations sur les vulnérabilités des logiciels. Le CSRB est composé de 15 responsables de la cybersécurité issus du secteur privé et du gouvernement.

Le groupe d'experts a été chargé d'examiner les événements majeurs en matière de cybersécurité et de formuler des recommandations pour améliorer la cybersécurité des secteurs public et privé. Le rapport sur la vulnérabilité de Log4J est le premier publié par le CSRB depuis sa création par le président Biden en février 2022. Pour l'examen de la vulnérabilité de Log4j, le CSRB s'est entretenu avec près de 80 organisations pour comprendre comment la vulnérabilité a été ou est encore atténuée, afin d'élaborer des recommandations concrètes pour prévenir et répondre efficacement à de futurs incidents de ce type.

Le rapport du CSRB est divisé en trois sections, fournissant des informations factuelles sur la vulnérabilité et ce qui s'est passé, les résultats et les conclusions basés sur une analyse des faits, et une liste de recommandations. Les 19 recommandations exploitables sont réparties en quatre catégories : traiter les risques continus liés aux vulnérabilités du logiciel Log4j ; conduire les meilleures pratiques existantes en matière d'hygiène de sécurité ; construire un meilleur écosystème logiciel ; et les investissements dans l'avenir. Le groupe recommande également d'investir plus dans la formation d'expert en cybersécurité.

L'une des recommandations les plus importantes est de créer et de maintenir un inventaire précis des actifs informatiques, car les vulnérabilités ne peuvent être traitées si l'on ne sait pas où elles existent. Il est essentiel de disposer d'une nomenclature complète des logiciels (SBOM) qui inclut tous les composants logiciels tiers et les dépendances utilisés dans les solutions logicielles. L'un des plus gros problèmes pour traiter les vulnérabilités de Log4j est de comprendre quels produits ont été affectés. Le rapport recommande également aux entreprises de développer un programme de réponse aux vulnérabilités.

En outre, le CSRB conseille aux entreprises de mettre en place un processus de divulgation et de traitement des vulnérabilités, et suggère au gouvernement américain d'étudier la viabilité d'un centre d'excellence pour l'évaluation des risques de sécurité des logiciels. « Jamais auparavant les responsables informatiques de l'industrie et du gouvernement ne s'étaient réunis de cette manière pour examiner des incidents graves, identifier ce qui s'est passé et conseiller l'ensemble de la communauté sur la façon dont nous pouvons faire mieux à l'avenir », a déclaré Silvers la semaine dernière.

« Notre examen de Log4j a donné lieu à des recommandations qui, nous en sommes convaincus, peuvent conduire à des changements et améliorer la cybersécurité », a-t-il ajouté. Le décret de Biden demande également au comité de procéder à un examen de la campagne massive de cyberespionnage prétendument russe connue sous le nom de SolarWinds. Les pirates informatiques russes auraient réussi à pénétrer dans plusieurs agences fédérales, y compris dans des comptes appartenant à de hauts responsables de la cybersécurité du DHS, bien que les retombées de cette campagne ne soient pas encore claires.

Source : Rapport du Cyber Safety Review Board (PDF)

Et vous ?

Quel est votre avis sur le sujet ?
Que pensez-vous des conclusions du rapport du CSRB ?

Voir aussi

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

Log4j : une entreprise du Fortune 500 exige des réponses rapides et gratuites du créateur de cURL, qui leur a indiqué qu'il le ferait « dès que nous aurons signé un contrat de support »

L'exploitation de Log4Shell se poursuit : plus de 30 000 scans signalés en janvier, la vulnérabilité continue de représenter une vaste menace malgré le correctif publié par la Fondation Apache

[marsupial]

Les recommandations font preuve de bon sens mais ont-ils pensé à la cruelle pénurie de ressources pour les appliquer en dehors de la demande de formation ?

[damthemad]

L'exemple donné d'utilisation n'est pas très pertinent. Les erreurs 404 sont généralement gérées par un serveur http frontal et ne parviennent pas à la couche applicative qui fait usage de log4j. Apache, nginx, iis etc. ont leur propre mécanisme de journalisation.

Même si il reste très présent pour des raisons historiques, Log4j est en perte de vitesse depuis longtemps déjà et est largement supplanté par SLF4J + logback. Beaucoup de dev. Java moderne sont basés sur Spring et Spring Boot qui n'utilisent pas log4j par défaut.

Quand à l'exploitabilité de la faille, je reste dubitatif. Je n'ai pas vraiment creusé le sujet car j'étais en congés quand la faille est apparue au grand jour mais de mes souvenirs, il faut quand même une sacré conjonction de conditions. Par exemple où je travaille chaque appli est dans un subnet dédié avec un contrôle strict des flux en entrée et en sortie sont contrôlés, aucune chance que cette faille puisse être exploitée. Le mécanisme qui créé la faille n'est par ailleurs pas non plus des plus utilisés.

Enfin quand à la recommandation de tracer tous les éléments logiciels ça me fait bien marrer. Aujourd'hui le moindre projet java moderne, notamment si il est basé sur les frameworks les plus couramment utilisés, tire des dizaines et des dizaines, voire plus encore, de dépendances. Vouloir tracer et analyser ces dépendances transitives (a a une dépendance sur b qui en a une sur c et d, d en a une sur e etc.) est juste mission impossible sauf à cartographier tout l'écosystème open source qui est très riche sur la plateforme java. Ce genre de recommandation est purement théorique et hors sol.

[Sandra Coret]

Six mois après la divulgation de la vulnérabilité Log4Shell, les instances vulnérables restent accessibles sur Internet et des personnes tentent de les exploiter, selon le rapport Trustwave SpiderLabs Telemetry

À partir des données recueillies par le moteur de recherche de périphériques Shodan, le rapport montre qu'au 9 juin 2022, 1 467 instances étaient vulnérables à Log4Shell.

Ces instances vulnérables proviennent de la Fédération de Russie, des États-Unis et de l'Allemagne, avec 266 (18 %), 215 (15 %) et 205 (15 %) hôtes, respectivement.

Sur une note positive, le rapport montre que les entreprises sont susceptibles d'appliquer des correctifs à leurs systèmes en temps opportun, ou qu'elles sont plus conscientes de leur sécurité qu'elles ne l'étaient l'année dernière, certaines des vulnérabilités très graves sélectionnées pour ce rapport affectant moins de 10 % des hôtes échantillonnés par Shodan.

Le nombre de vulnérabilités critiques a augmenté de 5 % par rapport aux 13 % de l'année dernière et le nombre total de CVE pour 2022 devrait dépasser celui de l'année dernière.

Les auteurs du rapport concluent : "Les acteurs de la menace scrutent continuellement Internet pour prendre l'avantage sur les organisations dont les processus de correction sont lents ou obsolètes. Par conséquent, une approche proactive de l'identification des vulnérabilités est incroyablement importante. Savoir quelles sont les vulnérabilités, nouvelles et anciennes, qui doivent nous préoccuper, et agir au bon moment, sont deux facteurs critiques qui doivent être en place pour avoir une bonne posture de sécurité. Comme le montre ce rapport, de plus en plus d'organisations s'impliquent dans la protection de leurs actifs à mesure que des vulnérabilités critiques apparaissent dans le domaine public."

Pour améliorer la protection, le rapport recommande que le personnel de sécurité procède à un examen régulier des actifs au moyen d'audits, de scans et/ou de tests de pénétration, et qu'il donne la priorité à l'application de correctifs sur les systèmes clés. Les entreprises devraient également limiter l'accès aux systèmes et appliquer le principe du moindre privilège, et soutenir autant que possible les équipes de sécurité chargées de protéger et d'appliquer ces concepts.

Source : Trustwave

Et vous ?

Qu'en pensez-vous ?

Et vous ?

Les équipes de sécurité trouvent plus facile d'atténuer Log4Shell plutôt que de le corriger définitivement, le délai moyen de remédiation après détection est de 17 jours, selon Qualys Cloud Platform

L'exploitation de Log4Shell se poursuit : plus de 30 000 scans signalés en janvier, la vulnérabilité continue de représenter une vaste menace malgré le correctif publié par la Fondation Apache

73% des organisations ont considérablement augmenté leurs efforts en matière de sécurité de la chaîne logistique logicielle, suite aux évènements Log4Shell, SolarWinds et Kaseya, selon Synopsys

[Steinvikel]

Qu'en pensez-vous ?

" Les entreprises devraient également limiter l'accès aux systèmes et appliquer le principe du moindre privilège, et soutenir autant que possible les équipes de sécurité chargées de protéger et d'appliquer ces concepts. "

Le problème récurrent étant que l'organe de décision exprime chez beaucoup d'entreprises :
"on veut de la sécurité, mais hors de question de débourser autant, hors de question que la mise en oeuvre prends autant de temps ...on veut de la sécu à pas cher, parce qu'on a décidé que ce serait suffisant pour l'instant." ...le "après" étant éternellement reporté par la suite.

Ce qu'il faut est simple : former ses équipes de sécurité, leur permettre un temps pour la veille, et leur donner les pouvoirs (de décision) pour agir sur le plan technique afin d'atteindre leur but. C'est ce que j'ai constaté dans la plupart des entreprises jusqu'à aujourd'hui, qui n'est que trop rarement appliqué.

[Sandra Coret]

Trois organisations sur quatre sont encore vulnérables à Log4Shell malgré des améliorations : 2,5 % des actifs restent vulnérables en octobre 2022, contre 10 % en décembre 2021, d'après Tenable

La vulnérabilité Log4j ou Log4Shell a fait la une de l'actualité en décembre 2021, provoquant des remous dans le monde de la cybersécurité. Il est donc normal de penser qu'elle n'est plus une menace. Cependant, un an plus tard, un an plus tard, il semble que ce soit une vulnérabilité qui continue à être vulnérable.

Une nouvelle étude de Tenable, basée sur des données collectées à partir de plus de 500 millions de tests, montre que 72 % des organisations restent vulnérables à Log4Shell en octobre de cette année.

L'analyse de la télémétrie de Tenable a révélé qu'un actif sur 10 était vulnérable à Log4Shell en décembre 2021, y compris un large éventail de serveurs, d'applications web, de conteneurs et d'appareils IoT. En octobre 2022, les données ont montré des améliorations, avec 2,5 % des actifs vulnérables. Pourtant, près d'un tiers (29 %) de ces actifs présentaient des récurrences de Log4Shell après la réalisation d'une remédiation complète.

"Il est très difficile d'obtenir une correction complète d'une vulnérabilité aussi répandue et il est important de garder à l'esprit que la correction des vulnérabilités n'est pas un processus unique", déclare Bob Huber, directeur de la sécurité chez Tenable. "Bien qu'une organisation ait pu être entièrement corrigée à un moment donné, elle est susceptible de rencontrer à nouveau Log4Shell au fur et à mesure qu'elle ajoute de nouveaux actifs à ses environnements. L'éradication de Log4Shell est une bataille permanente qui demande aux organisations d'évaluer continuellement leurs environnements pour détecter cette faille, ainsi que d'autres vulnérabilités connues."

Certains secteurs s'en sortent mieux que d'autres, l'ingénierie (45 %), les services juridiques (38 %), les services financiers (35 %), les organisations à but non lucratif (33 %) et les administrations publiques (30 %) étant en tête du peloton avec le plus grand nombre d'organisations entièrement remédiées. Environ 28 % des organisations d'infrastructures critiques définies par la CISA sont également entièrement remédiées.

Les organisations d'Amérique du Nord sont les plus susceptibles d'avoir entièrement remédié à Log4j (28 %), suivies par l'Europe, le Moyen-Orient et l'Afrique (27 %), l'Asie-Pacifique (25 %) et l'Amérique latine (21 %). L'Amérique du Nord est également la première région pour le pourcentage d'organisations qui ont partiellement remédié à la situation (90 %) par rapport à l'Europe, le Moyen-Orient et l'Afrique (85 %), l'Asie-Pacifique (85 %) et l'Amérique latine (81 %).

Source : Tenable

et vous ?

Qu'en pensez-vous ? trouvez-vous cette étude pertinente ?
Qu'en est-il dans votre organisation ?

Voir aussi :

Un nouveau groupe de travail sur la cybersécurité affirme que la faille du logiciel Log4j est "endémique", et qu'elle pourrait poser des risques de sécurité pendant une décennie ou plus

Six mois après la divulgation de la vulnérabilité Log4Shell, les instances vulnérables restent accessibles sur Internet et des personnes tentent de les exploiter, selon un rapport de Trustwave

Les 10 principales cibles attaquables par Log4j, qui continue d'être un problème pour les entreprises*: VMWare Horizon est en tête, suivie de Jamf et PingFederate, selon une étude de Randori

Des sénateurs présentent une législation bipartisane visant à renforcer la sécurité des logiciels libres, suite à une audition organisée sur l'incident Log4j

[Anthony]

Le nombre de téléchargements de versions Log4j vulnérables reste élevé un an après l'incident, environ 30 à 40 % de tous les téléchargements concernent la version exposée

Cette semaine marque le premier anniversaire de la vulnérabilité Log4j/Log4Shell affectant la bibliothèque de journalisation Java et, comme indiqué récemment, de nombreuses organisations sont toujours vulnérables même si des versions corrigées ont été rapidement disponibles.

Sonatype a produit un centre de ressources pour montrer l'état actuel de la vulnérabilité, ainsi qu'un outil pour aider les entreprises à analyser leur code source ouvert pour voir s'il est affecté.

Le tableau de bord montre le pourcentage de téléchargements de Log4j qui restent vulnérables -- actuellement autour de 34% depuis décembre dernier -- il montre également les parties du monde qui ont vu le pourcentage le plus élevé de téléchargements vulnérables.

Brian Fox, directeur technique de Sonatype, déclare :

Log4j a été un rappel brutal de l'importance cruciale de la sécurisation de la chaîne d'approvisionnement des logiciels. Il était utilisé dans pratiquement toutes les applications modernes et a affecté les services des organisations dans le monde entier. Un an après l'incident Log4Shell, la situation reste sombre. D'après nos données, 30 à 40 % de tous les téléchargements de Log4j concernent la version vulnérable, bien qu'un correctif ait été publié dans les 24 heures suivant la divulgation prématurée de la vulnérabilité.

Il est impératif que les organisations reconnaissent que la plupart des risques liés à l'open source se situent au niveau des consommateurs, qui doivent adopter les meilleures pratiques au lieu de blâmer un code défectueux. Log4j n'est pas un incident isolé : 96 % des téléchargements de composants open source vulnérables disposaient d'une version corrigée.

Les organisations ont besoin d'une meilleure visibilité de chaque composant utilisé dans leurs chaînes d'approvisionnement en logiciels. C'est pourquoi les solutions d'analyse de la composition des logiciels de qualité sont si importantes aujourd'hui, alors que le monde envisage l'utilité des SBOM à l'avenir. La politique britannique et européenne en matière de logiciels devrait exiger que les consommateurs commerciaux de logiciels libres soient en mesure d'effectuer l'équivalent d'un rappel ciblé, tout comme nous l'attendons des fabricants de biens physiques tels que l'industrie automobile. La visibilité générale conférera des avantages supplémentaires aux organisations, comme la possibilité de prendre des décisions à l'échelle du portefeuille pour investir ou désinvestir dans certaines technologies, et de réduire la portée.

Source : Sonatype

Et vous ?

Qu'en pensez-vous ?
D'après vous, pourquoi les entreprises continuent-elles de télécharger la version vulnérable de Log4j ?

Voir aussi

Une vulnérabilité Log4J extrêmement critique met une grande partie d'Internet en danger
Deuxième vulnérabilité Log4j découverte : un correctif est déjà publié, le correctif de la première vulnérabilité étant « incomplet »

[Bruno]

Log4Shell : la menace n'a pas disparu et pourrait refaire surface si l'industrie ne fait pas attention,
72 % des entreprises restent sensibles à Log4Shell, selon Tenable

Les projets de vacances de décembre des informaticiens ont été bouleversés l'année dernière par la divulgation d'un bogue majeur dans l'outil Log4j, largement utilisé. Cette découverte a entraîné des mois d'activité fébrile pour corriger la vulnérabilité, mais un an plus tard, elle a disparu du radar. Selon les experts en sécurité, la menace n'a pas disparu pour autant et pourrait refaire surface si l'industrie ne fait pas attention.

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

Grâce à Log4j, les entreprises technologiques peuvent vérifier si leurs applications fonctionnent correctement. S'il y a un défaut quelque part dans une application, un message d'erreur est envoyé via Log4j au fabricant, qui peut alors déterminer si une réparation est nécessaire. Amazon, Apple, Cloudflare, Tesla, Minecraft et Twitter, entre autres, utilisent également Log4j.

Lorsqu'il a été révélé pour la première fois au début du mois de décembre 2021, le bogue Log4Shell a été décrit comme l'une des vulnérabilités de sécurité les plus graves jamais rencontrées. Il visait un outil populaire de journalisation de l'activité dans les logiciels Java, conçu pour aider à garder une trace des erreurs et à diagnostiquer les problèmes de performance. Grâce à sa grande utilité, Log4j a été intégré dans des milliers de logiciels et a été trouvé dans une grande variété de services commerciaux, y compris Amazon Web Services et le jeu vidéo Minecraft. Qui plus est, le bogue a permis aux attaquants de prendre le contrôle total des systèmes vulnérables en toute simplicité.

Cela a entraîné une course effrénée pour combler les lacunes. La fondation Apache Software, qui gère l'outil open source, a rapidement publié un correctif, et les organisations ont passé des mois à analyser leurs systèmes et à mettre à jour leurs logiciels. Mais plus d'un an plus tard, la société de cybersécurité Tenable affirme que 72 % des entreprises restent sensibles à Log4Shell. Et, fait inquiétant, un grand nombre d'organisations qui avaient corrigé le bogue l'ont depuis réintroduit dans leurs systèmes en installant des logiciels vulnérables, déclare Bernard Montel, directeur technique et stratège en sécurité chez Tenable.

Le 9 décembre 2021, 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. La vulnérabilité dans Log4J permet à un cybercriminel 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.

Comme dit précedement, Log4Shell est une vulnérabilité logicielle dans Apache Log4j 2, une bibliothèque Java populaire permettant de consigner les messages d'erreur dans les applications. La vulnérabilité, publiée sous le nom de CVE-2021-44228, permet à un attaquant distant de prendre le contrôle d'un appareil sur Internet si l'appareil exécute certaines versions de Log4j 2.

Apache a publié un correctif pour CVE-2021-44228, version 2.15, le 6 décembre 2021. Cependant, ce correctif laissait une partie de la vulnérabilité non corrigée, ce qui a donné lieu à CVE-2021-45046 et à un deuxième correctif, version 2.16, publié le 13 décembre. Apache a publié un troisième correctif, la version 2.17, le 17 décembre pour corriger une autre vulnérabilité connexe, CVE-2021-45105. Un quatrième correctif, 2.17.1, a été publié le 28 décembre pour corriger une autre vulnérabilité, CVE-2021-44832.

Les attaquants peuvent exploiter cette vulnérabilité en utilisant des messages texte pour contrôler un ordinateur à distance. L'Apache Software Foundation, qui publie la bibliothèque Log4j 2, a attribué à la vulnérabilité un score CVSS de 10, le score de gravité le plus élevé, en raison de son potentiel d'exploitation à grande échelle et de la facilité avec laquelle les attaquants malveillants peuvent l'exploiter. Alors que les mesures d'atténuation évoluent et que les dégâts se déploient, les principes fondamentaux de la vulnérabilité Log4j ne changeront pas.

Le chercheur en sécurité Chen Zhaojun d'Alibaba, la plus grande société de commerce électronique de Chine, a signalé pour la première fois la vulnérabilité à la Fondation Apache (un projet open-source) le 24 novembre. Ils ont découvert l'attaque le 9 décembre sur des serveurs qui hébergent le jeu Minecraft. Après une analyse forensique plus poussée, ils ont réalisé que les cybercriminels avaient découvert la faille plus tôt, et l'exploitaient depuis au moins le 1er décembre 2021.

L'équipe open source de Google a déclaré avoir analysé Maven Central, le plus grand référentiel de packages Java, et a découvert que 35 863 packages Java utilisent des versions vulnérables de la bibliothèque Apache Log4j. Cela inclut les packages Java qui utilisent des versions Log4j vulnérables à l'exploit Log4Shell d'origine (CVE-2021-44228) et un deuxième bogue d'exécution de code à distance découvert dans le correctif Log4Shell (CVE-2021-45046).

« Lorsqu'ils ont mis en place un plan pour le réparer il y a environ un an, ils pensaient l'avoir fait », dit-il. « Ils ont nettoyé, ils ont identifié, ils ont scanné, ils ont patché leurs logiciels et pour eux, ils ont fait ce qu'ils avaient à faire. Ils ont juste oublié le fait que la surface d'attaque se déplace. »

Tenable estime que la proportion de machines vulnérables à l'exploit est passée d'une sur dix en décembre dernier à seulement 2,5 % en octobre dernier. Mais jusqu'à un tiers de ces machines avaient déjà été entièrement corrigées et ont depuis été réinfectées par Log4Shell. Selon Montel, une partie du problème réside dans le fait que Log4j est profondément enfoui dans un grand nombre de bibliothèques logicielles courantes.

Il n'est souvent pas évident de savoir si l'utilitaire est inclus dans un outil particulier, et même lorsqu'il l'est, la plupart des développeurs ne sont pas suffisamment sensibilisés à la sécurité pour vérifier s'il s'agit de la version la plus récente, compte tenu notamment de la pression qu'ils subissent pour produire du code rapidement, ajoute-t-il. Des recherches menées par la société de sécurité Sonatype il y a un an ont révélé que 65 % des téléchargements de Log4j concernaient des versions vulnérables de l'outil.

Au niveau organisationnel, Montel pense également qu'après l'énorme pression exercée pour traiter la vulnérabilité au cours des premiers mois, il était presque inévitable que les gens se déconcentrent une fois qu'ils avaient l'impression d'avoir remédié au problème. Il pense qu'il existe des analogies évidentes avec la pandémie de Covid-19, au cours de laquelle des mesures rigoureuses telles que les fermetures ont rapidement permis de maîtriser le virus, avant qu'il ne réapparaisse lorsque les choses se sont à nouveau détendues. « Il [Log4j] revient », affirme Montel. « Il est toujours là quelque part, il suffit d'observer les vagues ».

Un rapport de juillet du Cyber Safety Review Board du ministère de la Sécurité intérieure indique que le bug était devenu « endémique » et qu'il était susceptible de rester un problème pendant des années, voire des décennies. Et les données recueillies par la société de sécurité Imperva ont montré que si les attaques exploitant le bug ont considérablement diminué depuis les deux premiers mois de 2022, on observe une augmentation constante depuis novembre, le 3 décembre de cette année ayant vu les attaques quotidiennes les plus élevées depuis la découverte de la vulnérabilité.

Imperva estime qu'environ 7 % de ces attaques sont couronnées de succès. Mais bien qu'il y ait eu quelques piratages très médiatisés - dont ceux menés par des pirates chinois parrainés par l'État en mars et une attaque iranienne contre une agence fédérale américaine en novembre - jusqu'à présent, le bug n'a pas été à la hauteur des prédictions terribles faites l'année dernière. « Bien que de nombreuses entreprises aient été touchées, le nombre d'attaques a été largement inférieur à ce qui avait été prévu », explique Gabi Stapel, analyste de la recherche sur les menaces chez Imperva.

Il a cependant mis en lumière la dépendance de nombreuses entreprises à l'égard de codes tiers et open source sur lesquels elles n'ont que peu de contrôle ou de visibilité. « Historiquement, les entreprises se sont concentrées sur le risque introduit par leurs fournisseurs immédiats et les logiciels critiques dont elles dépendent », explique Stapel. « Les organisations doivent adopter un modèle de menace qui inclut toutes les parties de la chaîne d'approvisionnement. »

Le coût et la complexité de la réponse à Log4Shell ont certainement incité à mettre de plus en plus l'accent sur la sécurisation de la chaîne d'approvisionnement des logiciels et à stimuler la transparence, déclare Eric Goldstein, directeur adjoint exécutif pour la cybersécurité à la Cybersecurity and Infrastructure Security Agency (CISA). « Une multitude de nouveaux outils, entreprises et produits ont vu le jour l'année dernière pour aider à mieux comprendre les dépendances logicielles, et Log4j est souvent utilisé comme motivation principale pour l'innovation et l'adoption », explique-t-il.

L'un des remèdes potentiels promus par la CISA est le Software Bill of Materials (SBOM). Il s'agit d'un inventaire de tous les composants d'une application logicielle, conçu pour permettre aux développeurs de repérer plus facilement toute dépendance à l'égard de parties de code potentiellement dangereuses. Le gouvernement américain a indiqué qu'ils pourraient bientôt devenir une exigence pour les logiciels fournis aux agences fédérales.

Pour que cette approche ait réellement un impact, elle doit cependant se déplacer plus en amont, déclare Brian Behlendorf, directeur général de l'Open Source Security Foundation (OSSF), afin que même les paquets ou bibliothèques de logiciels libres originaux que les développeurs assemblent pour créer des applications soient accompagnés de leurs propres SBOM. Pour y parvenir, il faudra probablement créer de nouveaux outils qui simplifient ce processus et les intégrer aux outils de création de logiciels existants, explique Behlendorf, car « il peut être difficile d'inciter les développeurs à fournir un effort supplémentaire ».

L'industrie dans son ensemble doit également mieux se coordonner et être plus proactive en matière de sécurisation des outils open source sur lesquels elle s'appuie, dit-il. Selon Behlendorf, les projets individuels ne disposent tout simplement pas des ressources financières ou humaines nécessaires pour effectuer des tâches telles que la révision du code. « Il y a tout simplement un décalage entre la valeur que doit recevoir l'écosystème et la capacité à rassembler ce type de ressources », dit-il. « Ce dont nous avons besoin, c'est d'institutions capables d'agréger la demande d'un meilleur examen de ces choses et de canaliser les ressources vers des objectifs ciblés et faciles à atteindre. »

Source : IEEE

Et vous ?

Quel est votre avis sur le sujet ?

Voir aussi :

Log4j : une entreprise du Fortune 500 exige des réponses rapides et gratuites du créateur de cURL, qui leur a indiqué qu'il le ferait « dès que nous aurons signé un contrat de support »

Log4j : une entreprise du Fortune 500 exige des réponses rapides et gratuites du créateur de cURL, qui leur a indiqué qu'il le ferait « dès que nous aurons signé un contrat de support »

[Jade Emy]

38 % des applications Java toujours affectées par Log4Shell, la grande majorité des applications vulnérables n'ont peut-être jamais mis à jour la bibliothèque Log4j, d'après une étude de Veracode

Deux ans après la divulgation de la vulnérabilité Log4Shell dans l'utilitaire de journalisation Log4j basé sur Java, environ une application sur quatre dépend de bibliothèques obsolètes, ce qui la rend vulnérable à l'exploitation. Une étude menée par la société de sécurité Veracode a révélé que la grande majorité des applications vulnérables n'ont peut-être jamais mis à jour la bibliothèque Log4j après sa mise en œuvre par les développeurs, puisque 32 % d'entre elles utilisent des versions antérieures à 2015, date de fin de validité.

Des enquêtes antérieures de Veracode ont également montré que 79 % des développeurs ne mettent jamais à jour les bibliothèques tierces après les avoir introduites dans leurs projets. Étant donné que Log4j2 - la version spécifique de Log4j affectée par la vulnérabilité - date de 2014, cela pourrait expliquer la grande proportion d'applications non corrigées.

Une minorité beaucoup plus réduite utilise des versions qui étaient vulnérables au moment de la divulgation de la vulnérabilité de Log4j en décembre 2021. Seuls 2,8 % utilisent encore les versions 2.0-beta9 à 2.15.0, c'est-à-dire des versions postérieures à la fin de la période de validité qui restent exposées à Log4Shell, le surnom donné par l'industrie à l'exploitation de la vulnérabilité. Quelque 3,8 % des utilisateurs utilisent encore la version 2.17, une version post-patch de l'enregistreur Java qui n'est pas exposée aux attaques Log4Shell, mais qui est vulnérable à un bogue distinct d'exécution de code à distance (CVE-2021-44832).

Les chercheurs pensent que cela illustre une minorité de développeurs qui ont agi rapidement lorsque la vulnérabilité a été divulguée pour la première fois, comme on le conseillait à l'époque, et qui ont repris leurs anciennes habitudes en laissant les bibliothèques intactes. Au total, un peu moins de 35 % des développeurs restent vulnérables à Log4Shell, et près de 40 % sont vulnérables aux failles RCE. Les versions EOL de Log4j sont également vulnérables à trois autres bogues critiques annoncés par Apache, ce qui porte le total à sept problèmes classés comme élevés et critiques.

"À première vue, les chiffres ci-dessus montrent que l'effort massif pour remédier à la vulnérabilité de Log4Shell a permis d'atténuer le risque d'exploitation de la vulnérabilité zero-day. Cela ne devrait pas être surprenant", a déclaré Chris Eng, directeur de recherche chez Veracode.

"Le plus important, à l'occasion de ce deuxième anniversaire, est qu'il y a encore des progrès à faire en matière de sécurité des logiciels libres. Si Log4Shell était un autre exemple d'une longue série d'appels à adopter des pratiques plus strictes en matière de sécurité des logiciels libres, le fait que plus d'une application sur trois utilise actuellement des versions vulnérables de Log4j montre qu'il y a encore du travail à faire."

"Ce qu'il faut retenir, c'est que les entreprises ne sont peut-être pas conscientes de l'ampleur des risques auxquels elles sont exposées en matière de sécurité des logiciels libres et de la manière dont elles peuvent les atténuer."

État des vulnérabilités de Log4j : Dans quelle mesure Log4Shell a-t-il changé ?

Le 9 décembre, deux ans se sont écoulés depuis que le monde s'est mis en état d'alerte à cause de ce qui a été considéré comme l'une des vulnérabilités zero-day les plus critiques de tous les temps : Log4Shell. La vulnérabilité qui portait la note de gravité la plus élevée possible (10.0) se trouvait dans Apache Log4j, un cadre de journalisation Java omniprésent qui, selon Veracode, était alors utilisé dans 88 % des organisations.

Si elle est exploitée, la vulnérabilité zero-day (CVE-2021-44228) dans les versions Log4j2 2.0-beta9 à 2.15.0 (à l'exception des versions de sécurité 2.12.2, 2.12.3 et 2.3.1) permet aux attaquants de réaliser une exécution de code à distance (RCE) et de compromettre le serveur concerné.

Cela a déclenché un effort massif pour corriger les systèmes affectés, dont le nombre est estimé à des centaines de millions. L'apocalypse que beaucoup redoutaient ne s'est pas produite, mais compte tenu de son omniprésence, le comité d'examen de la cybersécurité du ministère américain de la sécurité intérieure a estimé qu'il faudrait une décennie pour remédier complètement à Log4Shell.

L'anniversaire des deux ans de Log4Shell est une bonne occasion d'examiner l'état des vulnérabilités de Log4j et d'évaluer comment les leçons tirées ont amélioré l'état de la sécurité des logiciels open-source. Pour ce faire, Veracode a analysé des données provenant d'analyses de logiciels effectuées sur 90 jours entre le 15 août et le 15 novembre 2023 pour 38 278 applications uniques exécutant les versions 1.1 à 3.0.0-alpha1 de Log4j dans 3 866 organisations.

Les résultats illustrent comment la dette technique de sécurité non traitée expose les organisations à de nombreux risques.

Ce qu'il faut retenir

Globalement, il est constaté que plus d'une application sur trois (38 %) utilise actuellement des versions vulnérables de Log4j. Cela se décompose comme suit :

• 2,8 % des applications utilisent encore des versions de Log4j comportant les vulnérabilités Log4Shell (Log4j2 2.0-beta9 à 2.15.0).
  
  
• 3,8 % des applications utilisent encore Log4j2 2.17.0, qui est corrigé contre la vulnérabilité Log4Shell mais contient CVE-2021-44832. Il s'agit d'une vulnérabilité RCE de haute sévérité qui permet à un attaquant ayant le privilège de modifier la configuration de la journalisation d'envoyer une configuration malveillante via JDBC Appender avec une source de données référençant une URI JNDI. La prévalence surprenante des applications vulnérables utilisant la version 2.17.0 peut être due au fait que les équipes ont réagi rapidement pour corriger la vulnérabilité initiale de Log4Shell, mais sont ensuite revenues à leur comportement antérieur consistant à ne pas appliquer de correctifs, même après la publication de la version 2.17.1 et des versions suivantes.
  
  
• 32 % des applications utilisent Log4j2 1.2.x, une version qui est arrivée en fin de vie en août 2015 et qui n'est donc plus supportée par des correctifs. En janvier 2022, Apache a annoncé trois vulnérabilités critiques affectant cette version, CVE-2022-23307, CVE-2022-23305 et CVE-2022-23302. Cela porte à sept le nombre total de vulnérabilités importantes et critiques publiées depuis que Log4j 1.2.x a atteint sa fin de vie.

L'analyse

À première vue, les chiffres ci-dessus montrent que l'effort massif pour remédier à la vulnérabilité Log4Shell a permis d'atténuer le risque d'exploitation de la vulnérabilité zero-day. Cela n'a rien de surprenant.

Toutefois, ce qui ressort de ce deuxième anniversaire, c'est qu'il y a encore des progrès à faire en matière de sécurité des logiciels libres. Si Log4Shell était un autre exemple d'une longue série d'appels à adopter des pratiques plus strictes en matière de sécurité des logiciels libres, le fait que plus d'une application sur trois utilise actuellement des versions vulnérables de Log4j montre qu'il y a encore du travail à faire. Ce qu'il faut retenir, c'est que les entreprises ne sont peut-être pas conscientes de l'ampleur des risques auxquels elles sont exposées en matière de sécurité des logiciels libres et de la manière dont elles peuvent les atténuer.

Veracode a exploré cette question en profondeur dans la récente étude State of Software Security (SOSS) v11 Open Source Edition.

Dans cette étude, ils ont constaté que, dans 79 % des cas, les développeurs ne mettent jamais à jour les bibliothèques tierces après les avoir intégrées dans une base de code. Cela explique pourquoi un si grand pourcentage d'applications utilisent une version de Log4j en fin de vie.

Les mises à jour de versions majeures (par exemple de 1.x à 2.x) peuvent être coûteuses pour les développeurs en raison de la difficulté à maintenir la compatibilité ascendante (même si 65 % des mises à jour de bibliothèques open-source sont des changements de version mineurs ou moins importants et donc peu susceptibles d'interrompre la fonctionnalité de l'application, même la plus complexe).

Cela signifie que les développeurs se contentent généralement d'effectuer une mise à niveau vers la version mineure la plus élevée (qui est 1.2.17 pour la série 1.x), car cela peut généralement être fait en quelques minutes sans modifier le code de l'application. Le guide officiel de mise à niveau de Log4j donne une bonne idée de la quantité de travail nécessaire pour passer de la version 1.2 à la version 2.x.

L'étude a également révélé qu'une fois que les développeurs sont avertis de la présence d'une bibliothèque vulnérable par le biais d'une analyse, ils la corrigent relativement rapidement : 50 % des vulnérabilités sont corrigées en 89 jours dans l'ensemble, en 65 jours pour les vulnérabilités de gravité élevée et en 107 jours pour les vulnérabilités de gravité moyenne. (Remarque : dans l'étude sur l'état de la sécurité des logiciels, Veracode parle de la correction de 50 % des failles - ou demi-vie - car cette mesure illustre l'efficacité des équipes à remédier aux vulnérabilités). Cela contredit les données de Log4j ci-dessus, qui montrent que la correction n'est pas rapide pour cette bibliothèque open-source, en particulier pour Log4j 1.2.x.

L'étude a également mis en évidence plusieurs facteurs exogènes qui ralentissent les développeurs. Il est rare que les développeurs manquent de compétences pour résoudre les problèmes, mais cela se résume à un manque d'informations et/ou de ressources (par exemple, le temps et/ou le personnel des développeurs). Plus précisément, lorsque les développeurs ne disposent pas des ressources nécessaires pour corriger les vulnérabilités, la correction de la moitié d'entre elles peut prendre près de 13,7 fois plus de temps. En outre, les développeurs qui manquent d'informations contextuelles sur la manière dont une bibliothèque vulnérable est liée à leur application mettent plus de 7 mois pour corriger 50 % de leur arriéré de vulnérabilités.

Pourquoi le changement s'impose-t-il aujourd'hui ?

Log4j n'est qu'un exemple parmi d'autres de la façon dont les vulnérabilités dans les logiciels libres posent des risques importants qui peuvent avoir un impact sur les opérations, la sécurité des données et la santé informatique en général. Les choix technologiques stratégiques peuvent avoir un impact important sur le niveau de risque auquel votre source ouverte vous expose. Les nouvelles réglementations de la SEC indiquent clairement qu'on a tous un rôle à jouer en matière de sécurité. La stratégie nationale de cybersécurité a déclaré que "la sécurité et la résilience des logiciels libres sont un impératif pour la sécurité nationale, l'économie et l'innovation technologique".

À l'époque où Log4Shell a vu le jour, le directeur technique de Veracode, Chris Wysopal, a déclaré : "Log4j a fait prendre conscience de la nécessité d'automatiser autant que possible les tests de sécurité dans les processus de construction. Cela a également été un signal d'alarme sur la façon dont la dette technique en matière de sécurité, lorsqu'elle n'est pas traitée, peut entraîner des problèmes urgents dont la résolution prend énormément de temps".

Les données présentées montrent à quel point cette affirmation est fondée. Pour apporter les changements nécessaires, voici quelques conseils pour réduire la dette technique de sécurité liée aux logiciels libres.

• Sachez ce qu'il y a dans les applications que vous créez. Avec l'analyse SCA et Infrastructure as Code, vous pouvez créer un sous-ensemble limité de modules autorisés que les développeurs peuvent utiliser. Veillez à ce qu'il y ait des politiques pour interdire ou fixer des périodes de grâce autour des vulnérabilités open-source par gravité et/ou "casser la construction" de sorte que les développeurs ne soient pas autorisés à déployer des changements qui introduisent de nouvelles vulnérabilités (dans le premier code ou dans le code tiers). Veillez à optimiser les risques à l'aide d'une solution capable d'identifier les méthodes vulnérables les plus importantes. 
  
  
• Sachez ce que contiennent les logiciels que vous avez achetés ou acquis (peut-être dans le cadre d'une fusion-acquisition). Demandez un SBOM pour les logiciels tiers que vous installez. Il est probable qu'à un moment ou à un autre, le logiciel que vous fabriquez ou que vous utilisez contienne une vulnérabilité dérivée d'un composant open-source. Être en mesure de l'identifier rapidement et d'y remédier pourrait vous éviter de graves ennuis.

Source : "State of Log4j Vulnerabilities: How Much Did Log4Shell Change?" , Veracode

Et vous ?

Pensez-vous que cette étude est crédible ou pertinente ?
Quel est votre avis sur le sujet ?

Voir aussi :

Trois organisations sur quatre sont encore vulnérables à Log4Shell malgré des améliorations : 2,5 % des actifs restent vulnérables en octobre 2022 contre 10 % en décembre 2021, d'après Tenable

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

Log4Shell : la menace n'a pas disparu et pourrait refaire surface si l'industrie ne fait pas attention, 72 % des entreprises restent sensibles à Log4Shell, selon Tenable

[vdaburon]

Bonjour,
Concernant les vulnérabilités de log4j1.2.x, j'ai regardé les conditions pour exploiter les vulnérabilités.
Il s'agit de vulnérabilité sur les appenders (système d'écriture des logs) très peu utilisés comme écrire les logs directement en base de données JDBX, ou envoyé dans des files de message JMS ou via des connexions réseaux distantes.

Si on fait des logs dans des fichiers locaux de façon beaucoup plus classique pas de problème.

Je ne dis pas que ces vulnérabilités ne sont pas graves, je dis qu'elles ne sont pas pour des cas standards d'utilisation.

Et donc dire qu'il y a 4 vulnérabilités et donc que le risque est important n'est pas vrai.

C'est juste pour relativiser l'article sur les dangers de ne pas changer de version des librairies ayants des vulnérabilités.
Cordialement
Vincent DAB.

[chrtophe]

Tellement peu standards que les hyperviseurs VMWare non patchés sont vulnérables, exemple le plus connu pour moi.