Pour citer Yogi Berra, l’immortel receveur des Yankees de New York, membre du Temple de la renommée de la Ligue majeure de baseball et fournisseur d’inexactitudes, « C’est à nouveau du déjà-vu. »
Juste au moment où nous pensions tous qu'il était sûr de replonger dans le développement d'applications après la douleur et le désordre causés par la vulnérabilité Log4j et les attaques Log4Shell, voici une autre bête de vulnérabilité qui vient saper une partie de la sécurité et dévorer des ressources précieuses.
Comme vous l'avez probablement déjà entendu, le 29 mars 2022, un chercheur basé en Chine a publié des captures d'écran d'une vulnérabilité d'exécution de code à distance (RCE) dans la bibliothèque Spring Core Java. La vulnérabilité a depuis été classée CVE-2022-22965 et s'est vu attribuer un score de gravité CVSS de « Critique ». La vulnérabilité, signalée par VMware , avait été publiée sur GitHub mais a été rapidement supprimée. Malheureusement, le mal était fait et la vulnérabilité a été rapidement publiée dans d’autres dépôts.
Comme pour de nombreuses vulnérabilités graves qui font l'objet d'une attention médiatique généralisée, CVE-2022-22965 a également reçu un nom commun : Spring4Shell, ou dans certains cas, SpringShell. Quoi qu’il en soit, une vulnérabilité de cette gravité, quel que soit son nom, est définitivement dangereuse, car les bibliothèques Spring sont utilisées dans la majorité des applications pour gagner du temps pour les programmeurs Java.
Selon un blog publié par Spring en tant qu'annonce précoce du RCE le 31 mars 2022, la vulnérabilité affecte les applications Spring MVC et Spring WebFlux lorsqu'elles sont exécutées sur Java Development Kit (JDK) 9+. Il peut également être nécessaire que l'application soit exécutée sur un Apache Tomcat en tant que WAR. La vulnérabilité affecte les versions 5.3.0 à 5.3.17, 5.2.0 à 5.2.19 de Spring Framework et les versions antérieures. Ce qui est peut-être plus inquiétant, c’est que Spring poursuit en avertissant que « la nature de la vulnérabilité est plus générale et qu’il peut y avoir d’autres moyens de l’exploiter qui n’ont pas encore été signalés ».
De plus, selon Spring, les applications exécutées en tant que déploiements Java Archive (JAR) (qui est la valeur par défaut) ne sont pas vulnérables à CVE-2022-22965 ; cependant, le fournisseur reconnaît qu'elles peuvent être affectées par d'autres techniques d'exploitation.
La vulnérabilité Spring4Shell fait également suite à une autre. Dans le logiciel Spring Cloud Function, versions 3.1.6 et 3.2.2 ainsi que dans les versions plus anciennes non prises en charge, des expressions de routage spécialement conçues dans Spring Expression Language (SpEL) peuvent être créées pour accéder aux ressources locales et éventuellement permettre une attaque RCE. Initialement classée avec un score de gravité CVSS « Moyen », CVE-2022-22963 a depuis été reclassée comme une vulnérabilité « Critique ». Des correctifs sont disponibles en effectuant une mise à niveau vers les versions 3.1.7 ou 3.2.3 de Spring Cloud Function.
Indépendamment de CVE-2022-22965 et CVE-2022-22963, une autre vulnérabilité dans Spring, CVE-2022-22950, a été signalée le 28 mars 2022. Il s’agit d’une vulnérabilité par déni de service (DoS) dans les versions 5.3.0 à 5.3.16 de Spring Framework et les versions antérieures, non prises en charge. Spring a publié des correctifs dans Spring Framework 5.3.17+.
À ce jour, des scanners Spring4Shell ont déjà été créés et déployés, et des rapports font état d’une exploitation active de la vulnérabilité.
Spring a publié des versions qui corrigent la vulnérabilité CVE-2022-22965, notamment Spring Framework 5.3.18 et 5.2.20 ; et Spring Boot 2.5.12 qui dépend de Spring Framework 5.3.18. (Spring Boot 2.6.6, qui dépend également de Spring Framework 5.3.18, devrait être publié prochainement, selon Spring.)
Même si Spring a bien fait en publiant des correctifs pour remédier à ces vulnérabilités redoutables, il incombe une fois de plus aux organisations de mettre à jour et d’appliquer les correctifs le plus rapidement possible. Le défi, comme pour les problèmes liés à Log4j / Log4Shell, est l’omniprésence des bibliothèques et le fait qu’elles peuvent être utilisées dans des applications dont les organisations peuvent ne pas être conscientes. Si une organisation ne sait pas qu’une application utilise un ensemble de bibliothèques affectées, comment peut-elle se protéger et protéger ses utilisateurs contre l’exploitation de cette vulnérabilité ?
C’est là qu’intervient F5.
Bien qu'il existe des similitudes et des différences dans les caractéristiques entre les vulnérabilités du framework Spring et les vulnérabilités Log4j et les exploits Log4Shell, les deux peuvent être détectées et bloquées en déployant des pare-feu d'applications Web (WAF) et des solutions de sécurité similaires.
En tant que client F5, vous disposez déjà de certaines des protections les plus puissantes pour vous défendre contre les attaques basées sur Spring4Shell et les vulnérabilités associées. Cependant, F5 vous exhorte, ainsi que vos équipes de développement, à mettre à niveau immédiatement toutes les bibliothèques Spring concernées et, si elles ne sont plus nécessaires, à supprimer toutes les bibliothèques Spring vulnérables de vos applications.
Voici comment F5 vous accompagne et sécurise vos applications, votre organisation et vos utilisateurs grâce à notre portefeuille complet de produits et services de sécurité dynamiques.
Si vous êtes victime d'une attaque ou craignez que votre organisation et ses applications soient vulnérables et exposées, veuillez contacter notre équipe d'assistance F5 et demander une escalade vers le SIRT F5 . Disponible 24h/24, 7j/7 et 365j/an, cette équipe vous guidera dans la mise à jour des correctifs des systèmes et logiciels F5, vous aidera dans les configurations et vous assistera dans le déploiement des iRules F5 pour limiter toute exposition ou atténuer les attaques.
F5 a publié (et continuera de traiter et de publier) des ensembles de signatures disponibles pour les déploiements BIG-IP Advanced WAF et BIG-IP ASM afin de bloquer tous les vecteurs d'attaque connus exposés par les vulnérabilités Spring4Shell. Les signatures sont également continuellement mises à jour avec des protections contre toute tentative de contournement. Assurez-vous que vous disposez et travaillez avec le package de mise à jour des signatures d'attaque (ASU) le plus récent.
Pour les clients qui n'ont pas déployé Advanced WAF ou ASM, une iRule peut être appliquée à l'application pour détecter, enregistrer et supprimer tout trafic incriminé susceptible de cibler des CVE spécifiques.
F5 garantit une sécurité cohérente des applications quelle que soit la plate-forme F5 utilisée et déployée par les clients. Par conséquent, les clients de NGINX App Protect WAF recevront les mêmes signatures mises à jour simultanément que les clients BIG-IP Advanced WAF. Assurez-vous de mettre à jour vos signatures WAF NGINX App Protect. Pour plus d’informations sur la façon de procéder, veuillez vous référer à ce guide . Assurez-vous également que le type d’attaque « Injection de code côté serveur » est activé dans votre politique WAF.
La solution récemment publiée F5 Distributed Cloud Web Application and API Protection (WAAP) protège les applications et les API déployées sur les clouds et les sites périphériques avec le pare-feu d'application Web (WAF) basé sur SaaS et la protection contre les robots de F5, la sécurité API avancée et la défense DDoS L3-L7. L'approche WAF unique de F5 garantit une sécurité cohérente des applications, quelle que soit l'offre F5 déployée par les clients. Par conséquent, comme les signatures permettant de remédier aux vulnérabilités Spring4Shell ont déjà été créées et mises à disposition pour BIG-IP Advanced WAF et NGINX App Protect WAF, elles ont également été simultanément mises à disposition pour Distributed Cloud WAAP. Aucune action supplémentaire ne doit être entreprise, car en tant que client Distributed Cloud WAAP, vous êtes déjà protégé.
Comme BIG-IP Advanced WAF, NGINX App Protect et Distributed Cloud WAAP, F5 Distributed Cloud WAF a déjà reçu les signatures nécessaires pour se protéger contre l'exposition liée aux vulnérabilités de Spring4Shell. Ils sont inclus dans la politique WAF par défaut, donc aucune action supplémentaire n'est requise.
La mise en œuvre des mesures d’atténuation nécessaires a déjà été entreprise par l’équipe F5 Silverline , garantissant aux clients que leurs applications sont protégées contre Spring4Shell et les vulnérabilités associées. Surveillant en permanence les menaces et prêt à appliquer toutes les mesures d'atténuation nécessaires, en collaboration avec l'équipe de recherche sur les menaces de F5 et vous, nos clients, F5 Silverline SOC étend votre équipe AppSec, travaillant pour vous 24 heures sur 24, 7 jours sur 7 et 365 jours par an. Si vous avez des questions concernant F5 Silverline, veuillez contacter l'équipe à support@f5silverline.com .
Threat Stack, récemment acquis par F5, offre des capacités d'inspection, de détection et de reporting. Le service Threat Stack inclut des règles de détection qui déterminent si une compromission Spring4Shell est préoccupante et peuvent lancer des services en tant que root ou s'exécuter à partir d'un shell et intensifier les tentatives. Pour plus d'informations, veuillez contacter votre représentant commercial F5 ou visiter https://www.threatstack.com .
Une tentative d’exploitation d’une vulnérabilité comme Spring4Shell commence généralement par une reconnaissance automatisée. F5 Distributed Cloud Bot Defense est votre première ligne de défense. Il peut arrêter les analyses automatisées, augmentant ainsi le facteur de difficulté pour les attaquants essayant de découvrir si votre organisation possède des applications Web vulnérables à Spring4Shell. Les services cloud distribués F5 s'adaptent aux tactiques en constante évolution des attaquants exploitant des botnets, permettant une adaptation en temps réel contre les attaques automatisées pilotées par des bots.
Les bibliothèques Spring étant utilisées dans une grande majorité d'applications basées sur Java, il sera difficile pour des organisations comme la vôtre de déterminer l'étendue complète des vulnérabilités et des exploits potentiels qu'elles génèrent. Il faudra peut-être également du temps pour mettre à jour toutes vos applications concernées, si vous parvenez à les trouver toutes. Cela peut rendre vos applications et vos organisations vulnérables et exploitables. F5 SSL Orchestrator rend le trafic chiffré visible, arrêtant ainsi les menaces chiffrées. Il décrypte le trafic traversant votre réseau, même le trafic du serveur, et achemine automatiquement le trafic vers des chaînes de sécurité que vous pouvez définir en fonction des solutions de votre pile de sécurité. SSL Orchestrator ne traite pas seulement les menaces chiffrées, mais peut également arrêter le trafic malveillant chiffré, comme le trafic destiné à une commande et un contrôle (C2 ) serveur. SSL Orchestrator peut non seulement atténuer la vulnérabilité CVE-2022-22965, mais également protéger contre les vulnérabilités et les exploits futurs.
F5 vous aidera à vous tenir au courant des dernières nouveautés concernant Spring4Shell ( CVE-2022-22965 ) et les vulnérabilités associées, et comment F5 se défend et atténue tout autre exploit engendré.
Au fur et à mesure que de nouvelles informations apparaîtront, nous mettrons à jour ce blog. Pour plus de contexte, vous pouvez accéder aux ressources suivantes :