Le chiffre peut être effrayant, 40% des téléchargements de paquets Log4j depuis le dépôt Maven Central sont des versions vulnérables à la faille Log4Shell. Cette dernière a été présentée au début décembre et a provoqué une panique au sein des entreprises, car cet outil de journalisation open source est présent dans plusieurs solutions et services IT. Sonatype qui gère le dépôt Maven a eu l’idée de créer un tableau de bord recensant au jour le jour les versions de Log4j récupérées par les développeurs et les entreprises. Il s’intéresse surtout sur les itérations avant Log4j 2.15 comprenant le correctif publié le 10 décembre dernier.
Ce dashboard montre qu’il y a eu au total 31,7 millions (au 11 mars) de téléchargements de Log4j toutes versions confondues. Si on extrapole avec les statistiques de téléchargement des versions vulnérables entre 39 et 41%, pas moins de 10 millions d’unités circulent encore dans le monde. Sonatype constate néanmoins des pics de récupération de certaines versions comme le 2.17 qui intègre des correctifs complémentaires après la découverte de variants à la faille initiale Log4Shell.
Plusieurs explications
La question qui se pose est pourquoi les entreprises et les développeurs téléchargent autant ces versions exposées de l’outil open source. Nos confrères de Darkreading ont sollicité l’avis d’experts en cybersécurité et leurs explications sont multiples. Travis Smith, vice-président de la recherche sur les menaces liés aux malwares chez Qualys, pointe du doigt « les outils de développement automatisés qui sont configurés pour télécharger une version spécifique de leurs dépendances ». Cela évite selon lui l’apparition de conflit. Par ailleurs, il constate que Log4j est intégré dans de nombreuses applications Java, mais difficilement détectable et continue à s’appuyer sur des versions vulnérables. Enfin, il émet l’hypothèse que ce taux élevé de téléchargement provienne des chercheurs pour tester les défenses et les attaquants pour améliorer leurs exploits.
Pour le directeur technique de Sonatype, Ikka Turunen, le problème vient de l’absence de gestion de la supply chain logicielle dans de nombreuses entreprises. Sans outils d’analyse de la composition et d’une nomenclature des logiciels, elles ont du mal à déterminer quels composants ont été utilisés et dans quelles versions. « En bref, de nombreuses entreprises essaient encore de constituer leur inventaire de logiciels avant de commencer à réagir », résume le dirigeant. Interrogé sur un moyen plus radical, supprimer les dépôts incriminés ? Ikka Turunen indique que le faire est risqué, car de nombreux logiciels dépendent des versions vulnérables de Log4j, et leur suppression soudaine pourrait entraîner la défaillance des systèmes.