La menace persistante : pourquoi des vulnérabilités majeures comme Log4Shell et Spring4Shell restent préoccupantes

En tant que développeurs, nous jonglons constamment entre fonctionnalités, correctifs et échéances. Pourtant, un problème latent est étonnamment passé inaperçu : de nombreux projets continuent d’utiliser des versions vulnérables de Log4j et de Spring Framework. Malgré la médiatisation des vulnérabilités Log4Shell et Spring4Shell, un nombre alarmant d’applications reposent encore sur ces bombes à retardement. Il ne s’agit pas d’un simple oubli : c’est un risque majeur. Nous avons l’âme de bâtisseurs, mais construire, c’est aussi veiller à la sûreté de nos ouvrages.

Le dilemme des développeurs

En tant que développeurs, nous devons sans cesse trouver un équilibre entre la livraison de nouvelles fonctionnalités et la maintenance des projets et fonctionnalités existants. C’est un exercice qui demande du temps et toute notre concentration. Suivre les dépendances de chaque projet et veiller à leur mise à jour peut sembler une tâche insurmontable, surtout lorsqu’il faut livrer de nouvelles fonctionnalités sous pression. Dans ce tourbillon, des vulnérabilités critiques comme Log4Shell et Spring4Shell peuvent passer entre les mailles du filet, non par négligence, mais en raison du volume considérable de tâches que nous gérons au quotidien. Pourtant, il est essentiel de reconnaître que la sûreté et la sécurité des applications que nous développons sont aujourd’hui des aspects fondamentaux du développement logiciel.

La situation actuelle de Log4Shell

Vous vous souvenez de Log4Shell ? Cette grave vulnérabilité d’Apache Log4j, découverte en 2021, permettait à des attaquants d’exécuter du code sur un serveur en journalisant une chaîne spécialement conçue. Un attaquant pouvait exploiter une recherche JNDI utilisant le protocole LDAP pour injecter un fichier de classe précompilé et exécuter du code malveillant. Même dans les versions récentes de Java, cette vulnérabilité pouvait causer des dommages par le biais d’attaques par désérialisation. La complexité d’exploitation de cette vulnérabilité critique est considérée comme très faible, ce qui rend la menace encore plus élevée que d’ordinaire. Consultez notre article de blog pour une analyse complète du problème.

Plus de 20 % des entreprises sont toujours vulnérables à Log4Shell.

Aujourd’hui, de nombreuses entreprises utilisent encore une version obsolète et vulnérable de la bibliothèque Log4j dans l’un de leurs projets. Parmi les entreprises qui analysent leur code de production à la recherche de vulnérabilités, 21 % ont encore des projets vulnérables à Log4Shell. Cela signifie que plus de 60 000 projets risquent encore d’être compromis par une vulnérabilité divulguée et corrigée il y a plus de deux ans. C’est énorme ! Sachant que ces entreprises utilisent déjà des outils de sécurité et s’emploient activement à corriger les problèmes qu’elles rencontrent, le nombre réel de versions vulnérables de Log4j en circulation est bien supérieur. Rien que cette idée est effrayante et profondément inquiétante.

Spring4Shell en circulation

Un autre exemple tristement célèbre est Spring4Shell, divulguée en mars 2022. La vulnérabilité de spring-beans pouvait également permettre l’exécution de code malveillant à distance. Bien que la complexité de l’attaque soit faible et qu’il existe des exploits pour certains cas précis, son impact était moins important que celui de Log4Shell. Consultez l’article de blog dédié pour en savoir plus.

En étendant cette vulnérabilité à Glassfish au moyen d’un nouvel exploit en avril 2022, l’équipe Snyk a démontré qu’elle était très importante et pouvait être exploitée dans bien d’autres cas que le premier exploit visant Tomcat.

Comme pour Log4Shell, nous avons constaté que Spring4Shell est toujours exploitable. Environ 35 % des entreprises ont encore Spring4Shell dans l’un de leurs projets. Même si le risque d’une compromission liée à Spring4Shell était moins important que celui associé à Log4Shell, l’équipe Snyk a démontré toute une série d’exploits potentiels en identifiant et en développant une preuve de concept (POC) d’exploit pour Glassfish. Cela montre que des menaces apparemment moins graves peuvent tout de même entraîner des vulnérabilités de sécurité importantes. Le fait qu’aucun exploit n’ait encore été publié ne signifie pas qu’une application ne peut pas être compromise par une vulnérabilité !

En outre, cela montre que de nombreuses applications Spring reposent sur d’anciennes versions obsolètes du framework, et que la mise à jour et la maintenance des applications existantes ne sont pas considérées comme prioritaires. Pourtant, au fond, nous savons que c’est une bombe à retardement qui peut exploser à tout moment.

Un signal d’alarme pour toutes les personnes qui assurent la maintenance des applications

Allons droit au but. Nous connaissons tous ce sentiment de fierté lorsque notre code fonctionne enfin sans accroc. La dernière chose que nous voulons, c’est y revenir pour y toucher, surtout pour une tâche qui paraît aussi anodine que la mise à jour de bibliothèques. Mais voilà : les vulnérabilités Log4Shell et Spring4Shell ne vont pas se corriger toutes seules. Et franchement, ce ne sont pas de petits bugs que l’on peut ignorer. Ce sont de véritables brèches dans les murs de nos applications. Si votre environnement contient encore des vulnérabilités comme Log4Shell ou Spring4Shell, vous vous exposez inutilement à des attaques très graves !

Snyk peut vous aider en détectant les vulnérabilités de sécurité dans vos applications et en vous aidant à les corriger. La solution s’intègre aux workflows de développement de plusieurs façons, notamment via les dépôts Git, son interface de ligne de commande (CLI) ou les pipelines d’intégration continue (CI) existants. Les développeurs peuvent ainsi repérer les risques de sécurité tôt dans le cycle de développement, avant qu’ils ne deviennent des problèmes plus importants. L’inscription est gratuite et donne immédiatement accès à ses fonctionnalités. Toutefois, la véritable valeur réside dans la gestion et la résolution des vulnérabilités découvertes.

Nous devons prendre nos responsabilités. Il ne s’agit pas simplement de trouver un correctif rapide ou d’espérer qu’une simple mise à jour suffira. Il faut parfois prendre la décision difficile de supprimer ou de remplacer une bibliothèque vulnérable. Oui, cela peut nous ralentir un peu et ce n’est pas la partie la plus passionnante de notre travail, mais c’est essentiel. Il s’agit de garantir la solidité de notre code, non seulement aujourd’hui, mais aussi sur le long terme.

Alors, n’attendons pas que quelqu’un d’autre règle ces problèmes. Avec les bons outils, nous pouvons repérer ces vulnérabilités rapidement, mais c’est à nous d’agir. À nous de renforcer nos défenses, de corriger ces vulnérabilités et de protéger nos applications. Au travail : pas seulement en tant que personnes qui écrivent du code, mais aussi en tant que professionnels qui assument leur travail et veillent à ce qu’il soit aussi sécurisé que possible.