Spring4Shell zero-day est apparu sur les équipes de sécurité

Les chercheurs et les analystes en sécurité se sont penchés sur une vulnérabilité zero-day d’exécution de code à distance (RCE) récemment découverte dans Spring Framework, qui est comparée par certains à Log4Shell dans sa gravité.

Surnommé Spring4Shell ou SpringShell dans certains milieux, il contourne une vulnérabilité précédemment connue sous le nom de CVE-2010-1622. Cela affecte toute application construite sur l’élément de journalisation Spring Core, et toute personne utilisant un logiciel construit sur Spring, qui est un framework très populaire comparable à Apache Struts.

Cette vulnérabilité nécessite l’utilisation de Java Development Kit (JDK) 9 ou version ultérieure pour être exploitée et, si elle est exploitée, permet finalement à un acteur non authentifié d’exécuter du code arbitraire sur le système cible.

Selon Anthony Weems et Dallas Kaman de Praetorian, qui ont été parmi les premiers à confirmer la validité de la vulnérabilité, l’exploitation est relativement triviale, « car elle ne nécessite qu’un attaquant pour envoyer une requête HTTP conçue à un système vulnérable » dans certaines configurations. L’exploitation de différentes configurations nécessitera que l’attaquant effectue des recherches supplémentaires pour trouver des charges utiles efficaces, ont-ils ajouté.

Aucun correctif n’existe et un exploit de preuve de concept public a été rapidement mis à disposition, il faut donc s’attendre à ce que Spring4Shell soit utilisé dans des attaques imminentes, et l’a probablement déjà été. L’équipe de Praetorian a publié une mesure d’atténuation temporaire, dont plus de détails peuvent être trouvés dans l’avis de divulgation de Weems et Kaman.

Brian Fox, CTO chez Sonatype, dont l’équipe a également enquêté sur Spring4Shell au cours des dernières 24 heures, a déclaré que les comparaisons avec Log4Shell étaient compréhensibles, mais que la vulnérabilité pourrait finalement ne pas s’avérer aussi percutante.

« La nouvelle vulnérabilité semble permettre un RCE non authentifié, mais en même temps a des atténuations et n’est actuellement pas au niveau de l’impact de Log4j », a déclaré Fox à Computer Weekly dans des commentaires envoyés par courrier électronique.

« Nous continuons à examiner cela pour déterminer comment cela va se passer, cependant. Nous pouvons comprendre que la récente mémoire Log4shell cause à juste titre de l’anxiété dans l’industrie, car Spring est l’un des frameworks logiciels les plus populaires. Quoi qu’il en soit, cela devrait être une raison supplémentaire pour chaque organisation de faire le point sur la façon dont elle gère ses composants tiers. »

Jeff Costlow, RSSI d’ExtraHop, a ajouté : « Lorsque des exploits zero-day comme Spring4Shell sont mis au jour, les organisations sont immédiatement poussées en mode panique, se démenant pour déterminer le rayon de vulnérabilité potentiel.

« Les équipes de sécurité doivent immédiatement comprendre quels logiciels et appareils pourraient être affectés et identifier s’il existe des périphériques vulnérables dans leur environnement. Cela peut être remarquablement difficile car de nombreuses organisations ont du mal à maintenir un inventaire à jour des appareils dans leur environnement, sans parler de la capacité de détecter les types et les versions de logiciels en cours d’exécution sur leurs appareils professionnels.

Dans le même temps, une confusion est apparue au sujet d’une vulnérabilité distincte, signalée comme CVE-2022-22963, une vulnérabilité RCE dans la fonction Spring Cloud de VMware – certains ayant confondu les deux.

Selon VMware, CVE-2022-22963 affecte les versions 3.1.6 et 3.2.2 et les anciennes versions non prises en charge de Spring Cloud Function. Il permet à un acteur malveillant de fournir un langage SpEL (Spring Expression Language) spécialement conçu comme expression de routage lors de l’utilisation de la fonctionnalité de routage, ce qui peut lui donner accès aux ressources locales. Les versions 3.1.7 et 3.2.3 le corrigent, de sorte que les utilisateurs doivent mettre à niveau dès que possible.

Travis Biehn, consultant principal en sécurité chez Synopsys, a déclaré que la confusion et l’amalgame des deux vulnérabilités portaient sur des problèmes plus larges liés à la façon dont les divulgations sont faites et diffusées au sein de la cybercommunauté en ligne.

Il a suggéré que l’indice de gravité appliqué à CVE-2022-22963 par VMware pourrait sous-estimer son impact potentiel, tandis que le fait que de nombreuses voix influentes de la communauté avaient « initialement tourné en dérision » Spring4Shell comme une fausse nouvelle ou un simple malentendu, pourrait laisser les défenseurs à six et sept ans.

« CVE-2022-22963 est ce qui se produit lorsque la divulgation responsable est suivie – un fournisseur peut minimiser l’importance d’une vulnérabilité, ce qui rend plus difficile d’agir », a déclaré Biehn. « Spring4Shell est ce qui se passe lorsque les processus de divulgation responsable ne sont pas suivis – le manque d’informations crédibles immédiates et entièrement vérifiées dans une mer de personnalités fortes rend un travail déjà difficile impossible. »