Le nouveau framework Spring Java zero-day permet l’exécution de code à distance

Spring

Une nouvelle vulnérabilité zero-day dans le framework Spring Core Java appelée « Spring4Shell » a été divulguée publiquement, permettant l’exécution de code à distance non authentifié sur les applications.

Spring est un cadre d’application très populaire qui permet aux développeurs de logiciels de développer rapidement et facilement des applications Java avec des fonctionnalités de niveau entreprise. Ces applications peuvent ensuite être déployées sur des serveurs, tels qu’Apache Tomcat, en tant que packages autonomes avec toutes les dépendances requises.

Hier, une nouvelle vulnérabilité Spring Cloud Function suivie comme CVE-2022-22963 a été divulgué, avec des exploits Proof-of-Concept qui suivront bientôt.

Cependant, des informations sur une vulnérabilité d’exécution de code à distance Spring Core plus critique ont ensuite circulé sur le service de chat QQ et un Site chinois de cybersécurité.

Cette nouvelle vulnérabilité Spring RCE, désormais appelée Spring4Shell, n’affecte que les applications Spring exécutées sur Java 9 et versions ultérieures et est causée par une désérialisation non sécurisée des arguments passés.

Aujourd’hui, un exploit pour cette vulnérabilité zero-day a été brièvement divulgué puis supprimé, mais pas avant que les chercheurs en cybersécurité aient pu télécharger le code.

Depuis lors, de nombreux chercheurs en cybersécurité et entreprises de sécurité ont confirmé que la vulnérabilité est valide et préoccupante.

Jang-twee

Tweet d'Alvaro

La société de cybersécurité Praetorian a également confirmé le bug, mais a déclaré qu’elle s’appuie sur des configurations spécifiques pour l’exploiter correctement.

« L’exploitation nécessite un point de terminaison avec DataBinder activé (par exemple, une requête POST qui décode automatiquement les données du corps de la requête) et dépend fortement du conteneur de servlet pour l’application », a expliqué Praetorian dans un article de blog.

« Par exemple, lorsque Spring est déployé sur Apache Tomcat, le WebAppClassLoader est accessible, ce qui permet à un attaquant d’appeler des getters et des setters pour finalement écrire un fichier JSP malveillant sur le disque. »

« Cependant, si Spring est déployé à l’aide du conteneur de servlet Tomcat intégré, le chargeur de classe est un LaunchedURLClassLoader qui a un accès limité. »

« Dans certaines configurations, l’exploitation de ce problème est simple, car il suffit qu’un attaquant envoie une requête POST spécialement conçue à un système vulnérable. Cependant, l’exploitation de différentes configurations obligera l’attaquant à effectuer des recherches supplémentaires pour trouver des charges utiles efficaces. . »

Cependant, des chercheurs ont déclaré à EZpublish-france.fr que Spring est couramment utilisé avec Apache Tomcat, ce qui signifie qu’il existe un grand potentiel d’abus généralisé.

Pour aggraver les choses, des rapports indiquent que la vulnérabilité Spring4Shell pourrait déjà être activement exploitée dans des attaques, selon les avis du China CERT.

Tweet Colin

Le billet de blog de Praetorian décrit un moyen d’atténuer partiellement les attaques Spring4Shell en interdisant la transmission de « modèles » spécifiques à la fonctionnalité Spring Core DataBinder.

Comme cette vulnérabilité n’a pas actuellement de correctif, il est fortement conseillé aux administrateurs utilisant les applications Spring de déployer ces atténuations dès que possible.

Est-ce le nouveau Log4Shell ?

Spring est un cadre d’application très populaire pour les applications Java, ce qui soulève des inquiétudes importantes quant au fait que cela pourrait conduire à des attaques généralisées lorsque les acteurs de la menace recherchent des applications vulnérables.

Comme l’exploitation nécessite un simple HTTP POST vers une application vulnérable, les pirates pourront créer des scripts qui analysent Internet et exploitent automatiquement les serveurs vulnérables.

Les pirates peuvent utiliser ces exploits pour exécuter des commandes sur le serveur, ce qui permettra un accès à distance complet à l’appareil.

Ce scénario d’attaque rappelle ce que nous avons vu en décembre avec l’exploitation massive des serveurs Log4j utilisant les exploits Log4Shell pour installer des logiciels malveillants et mener des attaques de ransomwares.

Pour éviter que ce scénario ne se réalise, il est fortement conseillé à l’administrateur d’appliquer les mesures d’atténuation fournies par Praetorian dès que possible.