Environ 38 % des applications utilisant la bibliothèque Apache Log4j utilisent une version vulnérable aux problèmes de sécurité, notamment Log4Shell, une vulnérabilité critique identifiée comme CVE-2021-44228 qui porte l'indice de gravité maximum, malgré la disponibilité des correctifs depuis plus de deux ans.
Log4Shell est une faille d'exécution de code à distance (RCE) non authentifiée qui permet de prendre le contrôle complet des systèmes avec Log4j 2.0-beta9 et jusqu'à 2.15.0.
La faille a été découverte comme un jour zéro activement exploité le 10 décembre 2021, et son impact généralisé, sa facilité d'exploitation et ses implications massives en matière de sécurité ont agi comme une invitation ouverte aux acteurs malveillants.
Cette situation a donné lieu à une vaste campagne visant à informer les responsables du projet et les administrateurs système concernés, mais malgré de nombreux avertissements, un nombre important d'organisations ont continué à utiliser des versions vulnérables longtemps après la disponibilité des correctifs.
Deux ans après la divulgation de la vulnérabilité et la publication des correctifs, de nombreuses cibles sont toujours vulnérables à Log4Shell.
Un rapport de la société de sécurité des applications Veracode, basé sur des données collectées entre le 15 août et le 15 novembre, souligne que d'anciens problèmes peuvent persister pendant de longues périodes.
Surface d'attaque solidifiée
Veracode a collecté des données pendant 90 jours auprès de 3 866 organisations qui utilisent 38 278 applications s'appuyant sur Log4j avec des versions comprises entre 1.1 et 3.0.0-alpha1.
Parmi ces applications, 2,8 % utilisent les variantes Log4J 2.0-beta9 à 2.15.0, qui sont directement vulnérables à Log4Shell.
3,8 % supplémentaires utilisent Log4j 2.17.0, qui, bien que non vulnérable à Log4Shell, est sensible au CVE-2021-44832, une faille d'exécution de code à distance qui a été corrigée dans la version 2.17.1 du framework.
Enfin, 32 % utilisent Log4j version 1.2.x, qui a atteint la fin du support depuis août 2015. Ces versions sont vulnérables à plusieurs vulnérabilités graves publiées jusqu'en 2022, notamment CVE-2022-23307, CVE-2022-23305 et CVE. -2022-23302.
Au total, Veracode a constaté qu'environ 38 % des applications visibles utilisent une version non sécurisée de Log4j.
Ceci est proche de ce que rapportent les experts en gestion de la chaîne d'approvisionnement logicielle de Sonatype sur leur Tableau de bord Log4joù 25 % des téléchargements de la bibliothèque la semaine dernière concernent des versions vulnérables.
Mauvaises pratiques de sécurité
L'utilisation continue de versions de bibliothèque obsolètes indique un problème persistant, que Veracode attribue aux développeurs souhaitant éviter des complications inutiles.
Selon les conclusions de Veracode, 79 % des développeurs choisissent de ne jamais mettre à jour les bibliothèques tierces après leur inclusion initiale dans leur base de code pour éviter de casser les fonctionnalités.
Cela est vrai même si 65 % des mises à jour des bibliothèques open source contiennent des modifications et des correctifs mineurs peu susceptibles de causer des problèmes fonctionnels.
De plus, l’étude a montré qu’il faut 50 % des projets sur 65 jours pour corriger des défauts de haute gravité. Il faut 13,7 fois plus de temps que d'habitude pour corriger la moitié de l'arriéré en cas de manque de personnel et plus de sept mois pour en traiter 50 % en cas de manque d'informations.
Malheureusement, les données de Veracode montrent que Log4Shell n'a pas été le signal d'alarme que beaucoup dans le secteur de la sécurité espéraient.
Au lieu de cela, Log4j à lui seul continue d’être une source de risque dans 1 cas sur 3 et peut très facilement être l’un des multiples moyens par lesquels les attaquants peuvent exploiter pour compromettre une cible donnée.
Il est recommandé aux entreprises d'analyser leur environnement, de rechercher les versions des bibliothèques open source utilisées, puis d'élaborer un plan de mise à niveau d'urgence pour chacune d'entre elles.
