Log4Shell est celui qui apparaîtra dans les violations de données au cours de la prochaine décennie
Ce dernier mois de l'année 2023 a marqué le deuxième anniversaire de la découverte de la vulnérabilité Log4j/Log4Shell, Il s'agit d'une vulnérabilité qui continue d'affecter de nombreux projets aujourd'hui et qui présente un risque pour la sécurité.
Et Log4j continue d'être une cible privilégiée des cyberattaques, selon le rapport annuel « Year in Review » de Cloudflare ainsi que les résultats d'une étude sur la pertinence des vulnérabilités critiques de la bibliothèque Java Log4j publiée par des chercheurs en sécurité par Veracode.
Les Les chercheurs de Veracode mentionnent qu'après avoir étudié 38.278 XNUMX applications utilisé par 3.866 XNUMX organisations, ils ont découvert que deux applications sur cinq utilisent encore des versions vulnérables de la bibliothèque Apache Log4j, deux ans après qu'une vulnérabilité critique ait été rendue publique.
Le rapport souligne qu'environ un tiers des applications exécutent Log4j2 1.2.x (qui est arrivé en fin de vie en août 2015 et ne reçoit plus de mises à jour de correctifs) ce qui représente 38 %. La principale raison pour laquelle on continue à utiliser le code existant est l'intégration d'anciennes bibliothèques dans des projets ou la difficulté de migrer de branches non prises en charge vers de nouvelles branches rétrocompatibles. De plus, 2.8 % des applications utilisent encore des versions vulnérables à la vulnérabilité bien connue Log4Shell.
En plus de cela, Il est mentionné qu'il existe trois catégories principales des applications utilisant encore des versions vulnérables de Log4j, selon le rapport Veracode :
- Vulnérabilité Log4Shell (CVE-2021-44228) :
2.8 % des applications continuent d'utiliser les versions Log4j de 2.0-beta9 à 2.15.0, qui contiennent la vulnérabilité connue. - Vulnérabilité d'exécution de code à distance (RCE) (CVE-2021-44832) :
3.8 % des applications utilisent la version Log4j2 2.17.0, qui corrige la vulnérabilité Log4Shell, mais ne résout pas la vulnérabilité d'exécution de code à distance (RCE) identifiée comme CVE-2021-44832. - Branche Log4j2 1.2.x (prise en charge terminée en 2015) :
32% des applications utilisent encore la branche Log4j2 1.2.x, dont le support a pris fin en 2015. Cette branche a été affectée par des vulnérabilités critiques, telles que CVE-2022-23307, CVE-2022-23305 et CVE-2022-23302, identifiées dans 2022, sept ans après la fin de la maintenance.
Ces données mettent en évidence la diversité des situations dans lesquelles les applications continuent d'utiliser des versions obsolètes et vulnérables de Log4j, suscitant de vives inquiétudes de la part des chercheurs.
Et un fait inquiétant est que 3.8 % des applications utilisent Log4j2 2.17.0, qui a été corrigé contre Log4Shell, mais contient CVE-2021-44832, une autre vulnérabilité d'exécution de code à distance de haute gravité.
Le rapport souligne que, malgré les efforts déployés ces dernières années pour améliorer les pratiques de sécurité dans le développement de logiciels et l'utilisation de l'open source, il y a du travail à faire.
Chris Eng, directeur de recherche chez Veracode, souligne que :
Les développeurs ont une responsabilité cruciale et des améliorations sont possibles en matière de sécurité des logiciels open source.
Bien que de nombreux développeurs aient initialement répondu de manière appropriée à la crise de Log4j en installant la version 2.17.0, le rapport suggère que certains sont revenus aux modèles précédents en n'appliquant pas de correctifs au-delà de la version 2.17.1.
L'Apache Software Foundation (ASF) a activement informé les projets en aval de l'urgence d'une mise à jour, mais les conclusions du rapport indiquent qu'il existe encore des applications qui n'ont pas implémenté les correctifs nécessaires.
Le rapport de Veracode était basé sur les données d'analyses logicielles de plus de 38,000 90 applications sur une période de 15 jours entre le 15 août et le 4 novembre. Les applications exécutaient les versions Log1.1j de 3.0.0 à 1 alpha 3,866 dans XNUMX XNUMX organisations différentes.
Nos recherches ont également révélé qu'une fois que les développeurs sont alertés d'une bibliothèque vulnérable via une analyse, ils la corrigent relativement rapidement : 50 % des vulnérabilités sont corrigées en 89 jours au total, en 65 jours pour les vulnérabilités de gravité élevée et en 107 jours pour les vulnérabilités de gravité moyenne.
Ces résultats sont cohérents avec les avertissements précédents, tels que le rapport du Federal Cybersecurity Review Board de 2022, qui indiquait que la crise Log4j prendrait des années pour être complètement résolue.
enfin si tu es intéressé à en savoir plus, je vous invite à visiter l'article original sur le blog veracode. Le lien est le suivant.