Spring4Shell avait-il beaucoup d’air chaud ? Non, mais…

Pas facile à exploiter

Une chose est sûre. Spring4Shell n’est pas une fausse nouvelle. Et selon Martin Jartelius, responsable de la sécurité d’Outpost24, il est facilement aussi critique que Log4Shell « pour toute personne affectée par celui-ci ».

Il est vrai que la criticité d’une vulnérabilité est quelque peu subjective et augmente si vous en êtes victime, mais comme Jartelius poursuit en expliquant, il est rapidement devenu évident que les conditions préalables à l’exploitation de Spring4Shell n’ont pas été créées égales, en tant que telles.

« Cette vulnérabilité a suscité un énorme intérêt car elle était quelque peu similaire à Log4j, car elle partageait les caractéristiques d’être une bibliothèque populaire et utilisée dans des contextes similaires avec un impact similaire », a-t-il déclaré. « La seule différence était les conditions préalables, et cette différence était énorme. »

Shachar Menashe, directeur principal de la recherche en sécurité chez JFrog, a expliqué ces conditions dans un article de blog. Au niveau le plus élevé, une application est vulnérable si elle est construite sur Spring Framework, s’exécutant sur JDK9 ou version ultérieure, ou si elle utilise la liaison de données pour lier les paramètres de demande à un objet Java (car la vulnérabilité se trouve dans le mécanisme de liaison de données de Spring).

En outre, a déclaré Menashe, grâce au vecteur d’exploitation spécifique choisi par l’exploit de preuve de concept – l’écrasement arbitraire de fichiers via AccessLogValve – Spring4Shell impose deux exigences supplémentaires, à savoir que l’application Web doit être servie par Apace Tomcat et qu’elle doit être déployée sur Tomcat en tant que ressource d’application Web.

En d’autres termes, l’ensemble particulier de conditions qui doivent être remplies pour que Spring4Shell soit exploité est un peu plus compliqué que ceux qui étaient nécessaires pour tirer parti de Log4Shell, donc même si Spring4Shell est également répandu grâce à la popularité du framework Spring, il est moins probable à exploiter pour l’instant.

La gueule de bois Log4Shell

Eduardo Ocete Entrala, chercheur en sécurité chez AT & T Alien Labs, a déclaré qu’au moins une partie de la réaction à Spring4Shell provient de la réaction à Log4Shell en décembre 2021.

« Les vulnérabilités du framework Java Spring ont provoqué une réaction généralisée dans la communauté de la sécurité logicielle en raison de leur similitude avec Log4Shell, qui était une vulnérabilité vraiment critique et percutante », a-t-il déclaré. « En outre, l’utilisation généralisée du framework Spring signifiait également que le nombre de systèmes susceptibles d’être affectés par la vulnérabilité était important. »

Jartelius a déclaré : « Une vulnérabilité critique, difficile à identifier, qui peut résider pendant des années dans vos applications et réseaux en attendant qu’un attaquant utilise le bon La charge utile n’est jamais un problème pour rien, mais la panique créée était clairement disproportionnée.

« Il est probable que nous continuerons à voir ce genre de sensationnalisme journalistique ou vendeur, et le meilleur conseil pour les entreprises est toujours de pratiquer une bonne cyberhygiène grâce à une évaluation régulière de la sécurité pour mesurer et réduire la surface d’attaque externe », a-t-il déclaré.

Ne soyez pas complaisant

Cela témoigne d’un besoin plus large parmi les organisations, ainsi que leurs responsables informatiques et leurs équipes de sécurité, de bien se familiariser avec les différents outils et composants utilisés dans le parc informatique, car il peut y avoir un certain nombre de dépendances ou de vulnérabilités cachées sous le capot.

Pascal Geenens, directeur du renseignement sur les menaces chez Radware, a déclaré : « SpringShell devrait rappeler à chacun de faire le point sur les bonnes pratiques d’hygiène. En tant que communauté, nous sommes devenus trop à l’aise pour prendre de grandes bibliothèques et modules complexes et avons oublié de nous concentrer sur les dépendances entre les modules.

« Les organisations doivent réduire leurs bibliothèques et limiter les dépendances sur les modules et le code qui ne sont pas pertinents pour l’application ; soyez plus prudents et plus perspicaces quant à ce que nous exposons; et assurez-vous que nous exécutons les versions les plus récentes. Les attaquants ne laissent aucune pierre non retournée. »

Interrogez vos sources

La saga Spring4Shell est également un avertissement pour faire attention à ne pas tomber dans la peur, l’incertitude et le doute, et un rappel à tous les membres de la communauté de la sécurité, qu’il s’agisse d’un responsable de la sécurité de l’information, d’un chercheur, d’un pirate informatique éthique ou d’un journaliste, d’interroger les nouvelles informations de manière responsable.

« Tout cela nous amène à une réalité au sein de l’informatique », a déclaré Mackey de Synopsys : « Une stratégie de gestion des correctifs influencée par la couverture médiatique n’est pas un processus efficace !

« Les équipes qui disposaient d’une solution d’analyse de la composition logicielle, ou SCA, configurée pour alerter de manière proactive des nouvelles vulnérabilités affectant leurs opérations savaient dans les heures qui ont suivi la publication du CVE quels systèmes étaient affectés et quelles mesures correctives étaient nécessaires.

« Dans le cas de Spring4Shell, plus connu sous le nom de CVE-2022-22965, l’effort de marque distrait de la tâche à accomplir et la confusion entourant ce qu’était le composant vulnérable n’a pas aidé », a-t-il déclaré.

Malgré cela, a déclaré Mackey, comme pour de nombreuses vulnérabilités très médiatisées, la portée du code affecté est susceptible de croître à mesure que davantage de connaissances sont acquises, donc si vous avez trié la vulnérabilité plutôt que de la corriger, juste après avoir terminé cet article serait un très bon moment pour vérifier les mises à jour.

En bref, soyez prudent là-bas, mais n’ayez pas de cauchemars.