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 
