Si elle est exploitée, la vulnérabilité zero-day (CVE-2021-44228) dans Log4j versions Log4j2 2.0-beta9 à 2.15.0 (excluant les versions de sécurité 2.12.2, 2.12.3, et 2.3.1) permettrait aux attaquants de réaliser une attaque par exécution de code à distance (RCE) et de compromettre le serveur affecté. Il a déclenché un effort massif de correction des 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.

Le deuxième anniversaire 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 de scans de logiciels sur 90 jours entre le 15 août et le 15 novembre 2023 pour 38 278 applications uniques utilisant Log4j versions 1.1 à 3.0.0-alpha1 au sein de 3 866 organisations. Ce que nous avons découvert illustre la façon dont la dette technique en matière de sécurité non traitée expose les organisations à de nombreux risques.

Les enseignements à tirer

Plus d’une application sur trois (38 %) utilise actuellement des versions vulnérables de Log4j. Cette proportion se répartit comme suit :

– 2,8 % des applications utilisent encore des versions de Log4j avec les vulnérabilités de Log4Shell (Log4j2 2.0-beta9 à 2.15.0).

– 3,8 % des applications utilisent encore Log4j2 2.17.0, qui nest plus exposée à la vulnérabilité Log4Shell mais qui contient la CVE-2021-44832. Il s’agit d’une vulnérabilité RCE de haute gravité qui permet à un attaquant disposant de privilèges de modifier la configuration de la journalisation pour envoyer une configuration malveillante via JDBC Appender avec une source de données faisant référence à une URI JNDI. La prévalence surprenante d’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 au-delà.

– 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-23307CVE-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 la fin de sa durée de vie.
Analyse

À première vue, les chiffres ci-dessus montrent que les efforts massifs déployés pour remédier à la vulnérabilité de Log4Shell ont permis d’atténuer le risque d’exploitation de la vulnérabilité de type "zero-day, ce qui n’est pas surprenant.

Toutefois, le fait le plus marquant de ce deuxième anniversaire est que l’on peut encore améliorer la 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 organisations ne sont peut-être pas conscientes de l’ampleur des risques de sécurité liés aux logiciels libres auxquels elles sont exposées et de la manière dont elles peuvent les atténuer.

Veracode a étudié cette question de manière approfondie dans sa récente étude State of Software Security (SOSS) v11 Open Source Edition. Dans cette étude, il a été 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 qui ne risquent donc pas d’interrompre la fonctionnalité de l’application la plus complexe).

Cela signifie que les développeurs se contentent généralement de passer à 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 à jour 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 Veracode 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 cette étude sur l’état de la sécurité des logiciels, Veracode parle de la correction de 50 % des failles 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. Les développeurs manquent rarement de compétences pour corriger les choses, mais cela se résume à un manque d’informations et/ou un manque 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, il faut près de 13,7 fois plus de temps pour corriger la moitié d’entre elles. 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 à 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 créent des risques importants qui peuvent avoir un impact sur les opérations, la sécurité des données et la santé globale de l’informatique. Les choix technologiques stratégiques peuvent avoir un impact important sur le niveau de risque auquel vos composants open source vous exposent. Les nouvelles réglementations de la SEC indiquent clairement que nous avons tous un rôle à jouer en matière de sécurité. La « National Security Strategy » 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 est apparu, notre directeur technique 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 build. Il nous a également fait prendre conscience que 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 opérer le changement nécessaire, voici quelques conseils pour réduire la dette technique en matière de sécurité des logiciels libres.

• Sachez ce qui entre dans la composition des applications que vous construisez. 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 le build » de sorte que les développeurs ne soient pas autorisés à déployer des changements qui introduisent de nouvelles vulnérabilités (dans le code in house ou dans le code tiers). Veillez à optimiser les risques grâce à 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 à l’occasion d’une fusion-acquisition). Demandez un SBOM pour les logiciels tiers que vous installez. Il est probable qu’à un moment donné, 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.