Connect with us

Technologie

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

Published

on


Il a été brièvement salué comme le prochain Log4Shell – un sérieux zero-day dans un framework largement utilisé sous-tendant des milliers d’applications – mais un peu plus d’une semaine après la divulgation de la vulnérabilité d’exécution de code à distance (RCE) Spring4Shell dans Spring Framework, il n’y a pratiquement aucune preuve d’un impact significatif sur les utilisateurs.

Spring4Shell, également connu sous le nom de SpringShell et maintenant suivi sous le nom de CVE-2022-22965, contourne une vulnérabilité précédemment connue sous le nom de CVE-2010-1622 et affecte toute application basée sur l’élément de journalisation Spring Core de Spring, l’un des frameworks les plus populaires. S’il est exploité, il permet finalement à un acteur non authentifié d’exécuter du code arbitraire sur le système cible. Jusqu’à présent, c’est le CAS; plus de détails sont disponibles ici.

Les choses n’ont pas été aidées par la divulgation simultanée d’une vulnérabilité distincte dans Spring, avec laquelle Spring4Shell a malheureusement été confondu, ce qui a conduit à une confusion généralisée et a conduit plus d’un expert en sécurité autoproclamé qui n’avait pas correctement lu quelque chose à crier « fausses nouvelles ».

Tim Mackey, stratège principal en sécurité au Centre de recherche sur la cybersécurité (CyRC) de Synopsys, a déclaré que cette confusion pose un problème avec la façon dont les pirates et les chercheurs éthiques communiquent et divulguent leurs découvertes.

Même si les chercheurs divulguent avec les meilleures intentions, la divulgation est un processus difficile et peut facilement être mal interprétée si une seule personne est motivée à faire du sensationnalisme pour attirer les lecteurs vers un blog ou écrire un tweet viral.

« La divulgation responsable existe pour un certain nombre de raisons, mais l’une des plus importantes est de s’assurer que des informations concises et exploitables sont mises entre les mains de ceux qui doivent résoudre rapidement et avec précision un problème », a déclaré Mackey.

« La confusion rencontrée par les équipes avec Spring4Shell n’avait pas eu besoin de se produire et aurait probablement été évitée si les informations sur Spring4Shell n’avaient pas été divulguées et s’il n’y avait pas eu de vulnérabilité indépendante dans un autre composant partageant le nom Spring. »

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.

Click to comment

Leave a Reply

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Tendance