Deux ans aprs la divulgation de la vulnrabilit Log4Shell dans l’utilitaire de journalisation Log4j bas sur Java, environ une application sur quatre dpend de bibliothques obsoltes, ce qui la rend vulnrable l’exploitation. Une tude mene par la socit de scurit Veracode a rvl que la grande majorit des applications vulnrables n’ont peut-tre jamais mis jour la bibliothque Log4j aprs sa mise en uvre par les dveloppeurs, puisque 32 % d’entre elles utilisent des versions antrieures 2015, date de fin de validit.
Des enqutes antrieures de Veracode ont galement montr que 79 % des dveloppeurs ne mettent jamais jour les bibliothques tierces aprs les avoir introduites dans leurs projets. tant donn que Log4j2 – la version spcifique de Log4j affecte par la vulnrabilit – date de 2014, cela pourrait expliquer la grande proportion d’applications non corriges.
Une minorit beaucoup plus rduite utilise des versions qui taient vulnrables au moment de la divulgation de la vulnrabilit de Log4j en dcembre 2021. Seuls 2,8 % utilisent encore les versions 2.0-beta9 2.15.0, c’est–dire des versions postrieures la fin de la priode de validit qui restent exposes Log4Shell, le surnom donn par l’industrie l’exploitation de la vulnrabilit. Quelque 3,8 % des utilisateurs utilisent encore la version 2.17, une version post-patch de l’enregistreur Java qui n’est pas expose aux attaques Log4Shell, mais qui est vulnrable un bogue distinct d’excution de code distance (CVE-2021-44832).
Les chercheurs pensent que cela illustre une minorit de dveloppeurs qui ont agi rapidement lorsque la vulnrabilit a t divulgue pour la premire fois, comme on le conseillait l’poque, et qui ont repris leurs anciennes habitudes en laissant les bibliothques intactes. Au total, un peu moins de 35 % des dveloppeurs restent vulnrables Log4Shell, et prs de 40 % sont vulnrables aux failles RCE. Les versions EOL de Log4j sont galement vulnrables trois autres bogues critiques annoncs par Apache, ce qui porte le total sept problmes classs comme levs et critiques.
« premire vue, les chiffres ci-dessus montrent que l’effort massif pour remdier la vulnrabilit de Log4Shell a permis d’attnuer le risque d’exploitation de la vulnrabilit zero-day. Cela ne devrait pas tre surprenant« , a dclar Chris Eng, directeur de recherche chez Veracode.
« Le plus important, l’occasion de ce deuxime anniversaire, est qu’il y a encore des progrs faire en matire de scurit des logiciels libres. Si Log4Shell tait un autre exemple d’une longue srie d’appels adopter des pratiques plus strictes en matire de scurit des logiciels libres, le fait que plus d’une application sur trois utilise actuellement des versions vulnrables 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 exposes en matire de scurit des logiciels libres et de la manire dont elles peuvent les attnuer.«
tat des vulnrabilits de Log4j : Dans quelle mesure Log4Shell a-t-il chang ?
Le 9 dcembre, deux ans se sont couls depuis que le monde s’est mis en tat d’alerte cause de ce qui a t considr comme l’une des vulnrabilits zero-day les plus critiques de tous les temps : Log4Shell. La vulnrabilit qui portait la note de gravit la plus leve possible (10.0) se trouvait dans Apache Log4j, un cadre de journalisation Java omniprsent qui, selon Veracode, tait alors utilis dans 88 % des organisations.
Si elle est exploite, la vulnrabilit zero-day (CVE-2021-44228) dans les versions Log4j2 2.0-beta9 2.15.0 ( l’exception des versions de scurit 2.12.2, 2.12.3 et 2.3.1) permet aux attaquants de raliser une excution de code distance (RCE) et de compromettre le serveur concern.
Cela a dclench un effort massif pour corriger les systmes affects, dont le nombre est estim des centaines de millions. L’apocalypse que beaucoup redoutaient ne s’est pas produite, mais compte tenu de son omniprsence, le comit d’examen de la cyberscurit du ministre amricain de la scurit intrieure a estim qu’il faudrait une dcennie pour remdier compltement Log4Shell.
L’anniversaire des deux ans de Log4Shell est une bonne occasion d’examiner l’tat des vulnrabilits de Log4j et d’valuer comment les leons tires ont amlior l’tat de la scurit des logiciels open-source. Pour ce faire, Veracode a analys des donnes provenant d’analyses de logiciels effectues sur 90 jours entre le 15 aot et le 15 novembre 2023 pour 38 278 applications uniques excutant les versions 1.1 3.0.0-alpha1 de Log4j dans 3 866 organisations.
Les rsultats illustrent comment la dette technique de scurit non traite 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 vulnrables de Log4j. Cela se dcompose comme suit :
- 2,8 % des applications utilisent encore des versions de Log4j comportant les vulnrabilits Log4Shell (Log4j2 2.0-beta9 2.15.0).
- 3,8 % des applications utilisent encore Log4j2 2.17.0, qui est corrig contre la vulnrabilit Log4Shell mais contient CVE-2021-44832. Il s’agit d’une vulnrabilit RCE de haute svrit qui permet un attaquant ayant le privilge de modifier la configuration de la journalisation d’envoyer une configuration malveillante via JDBC Appender avec une source de donnes rfrenant une URI JNDI. La prvalence surprenante des applications vulnrables utilisant la version 2.17.0 peut tre due au fait que les quipes ont ragi rapidement pour corriger la vulnrabilit initiale de Log4Shell, mais sont ensuite revenues leur comportement antrieur consistant ne pas appliquer de correctifs, mme aprs la publication de la version 2.17.1 et des versions suivantes.
- 32 % des applications utilisent Log4j2 1.2.x, une version qui est arrive en fin de vie en aot 2015 et qui n’est donc plus supporte par des correctifs. En janvier 2022, Apache a annonc trois vulnrabilits critiques affectant cette version, CVE-2022-23307, CVE-2022-23305 et CVE-2022-23302. Cela porte sept le nombre total de vulnrabilits importantes et critiques publies depuis que Log4j 1.2.x a atteint sa fin de vie.
L’analyse
premire vue, les chiffres ci-dessus montrent que l’effort massif pour remdier la vulnrabilit Log4Shell a permis d’attnuer le risque d’exploitation de la vulnrabilit zero-day. Cela n’a rien de surprenant.
Toutefois, ce qui ressort de ce deuxime anniversaire, c’est qu’il y a encore des progrs faire en matire de scurit des logiciels libres. Si Log4Shell tait un autre exemple d’une longue srie d’appels adopter des pratiques plus strictes en matire de scurit des logiciels libres, le fait que plus d’une application sur trois utilise actuellement des versions vulnrables 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 exposes en matire de scurit des logiciels libres et de la manire dont elles peuvent les attnuer.
Veracode a explor cette question en profondeur dans la rcente tude State of Software Security (SOSS) v11 Open Source Edition.
Dans cette tude, ils ont constat que, dans 79 % des cas, les dveloppeurs ne mettent jamais jour les bibliothques tierces aprs les avoir intgres 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 coteuses pour les dveloppeurs en raison de la difficult maintenir la compatibilit ascendante (mme si 65 % des mises jour de bibliothques open-source sont des changements de version mineurs ou moins importants et donc peu susceptibles d’interrompre la fonctionnalit de l’application, mme la plus complexe).
Cela signifie que les dveloppeurs se contentent gnralement d’effectuer une mise niveau vers la version mineure la plus leve (qui est 1.2.17 pour la srie 1.x), car cela peut gnralement tre fait en quelques minutes sans modifier le code de l’application. Le guide officiel de mise niveau de Log4j donne une bonne ide de la quantit de travail ncessaire pour passer de la version 1.2 la version 2.x.
L’tude a galement rvl qu’une fois que les dveloppeurs sont avertis de la prsence d’une bibliothque vulnrable par le biais d’une analyse, ils la corrigent relativement rapidement : 50 % des vulnrabilits sont corriges en 89 jours dans l’ensemble, en 65 jours pour les vulnrabilits de gravit leve et en 107 jours pour les vulnrabilits de gravit moyenne. (Remarque : dans l’tude sur l’tat de la scurit des logiciels, Veracode parle de la correction de 50 % des failles – ou demi-vie – car cette mesure illustre l’efficacit des quipes remdier aux vulnrabilits). Cela contredit les donnes de Log4j ci-dessus, qui montrent que la correction n’est pas rapide pour cette bibliothque open-source, en particulier pour Log4j 1.2.x.
L’tude a galement mis en vidence plusieurs facteurs exognes qui ralentissent les dveloppeurs. Il est rare que les dveloppeurs manquent de comptences pour rsoudre les problmes, mais cela se rsume un manque d’informations et/ou de ressources (par exemple, le temps et/ou le personnel des dveloppeurs). Plus prcisment, lorsque les dveloppeurs ne disposent pas des ressources ncessaires pour corriger les vulnrabilits, la correction de la moiti d’entre elles peut prendre prs de 13,7 fois plus de temps. En outre, les dveloppeurs qui manquent d’informations contextuelles sur la manire dont une bibliothque vulnrable est lie leur application mettent plus de 7 mois pour corriger 50 % de leur arrir de vulnrabilits.
Pourquoi le changement s’impose-t-il aujourd’hui ?
Log4j n’est qu’un exemple parmi d’autres de la faon dont les vulnrabilits dans les logiciels libres posent des risques importants qui peuvent avoir un impact sur les oprations, la scurit des donnes et la sant informatique en gnral. Les choix technologiques stratgiques peuvent avoir un impact important sur le niveau de risque auquel votre source ouverte vous expose. Les nouvelles rglementations de la SEC indiquent clairement qu’on a tous un rle jouer en matire de scurit. La stratgie nationale de cyberscurit a dclar que « la scurit et la rsilience des logiciels libres sont un impratif pour la scurit nationale, l’conomie et l’innovation technologique« .
l’poque o Log4Shell a vu le jour, le directeur technique de Veracode, Chris Wysopal, a dclar : « Log4j a fait prendre conscience de la ncessit d’automatiser autant que possible les tests de scurit dans les processus de construction. Cela a galement t un signal d’alarme sur la faon dont la dette technique en matire de scurit, lorsqu’elle n’est pas traite, peut entraner des problmes urgents dont la rsolution prend normment de temps« .
Les donnes prsentes montrent quel point cette affirmation est fonde. Pour apporter les changements ncessaires, voici quelques conseils pour rduire la dette technique de scurit lie aux logiciels libres.
- Sachez ce qu’il y a dans les applications que vous crez. Avec l’analyse SCA et Infrastructure as Code, vous pouvez crer un sous-ensemble limit de modules autoriss que les dveloppeurs peuvent utiliser. Veillez ce qu’il y ait des politiques pour interdire ou fixer des priodes de grce autour des vulnrabilits open-source par gravit et/ou « casser la construction » de sorte que les dveloppeurs ne soient pas autoriss dployer des changements qui introduisent de nouvelles vulnrabilits (dans le premier code ou dans le code tiers). Veillez optimiser les risques l’aide d’une solution capable d’identifier les mthodes vulnrables les plus importantes.
- Sachez ce que contiennent les logiciels que vous avez achets 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 vulnrabilit drive d’un composant open-source. tre en mesure de l’identifier rapidement et d’y remdier 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 crdible ou pertinente ?
Quel est votre avis sur le sujet ?
Voir aussi :