snip3r69/spring-shell-vulnSpring a confirmé la RCE dans Spring Framework. L'équipe vient de publier la déclaration ainsi que les guides d'atténuation pour ce problème. Maintenant, cette vulnérabilité peut être suivie sous le nom CVE-2022-22965.
Spring a confirmé la RCE dans Spring Framework. L'équipe vient de publier la déclaration ainsi que les guides d'atténuation pour ce problème. Maintenant, cette vulnérabilité peut être suivie sous le nom CVE-2022-22965.
Quelques informations sur la vulnérabilité Spring4Shell et ont partagé les détails sur le post Spring4Shell: Détails et Exploit. De plus, l'équipe de sécurité de Praetorian a confirmé que Spring Core sur JDK9+ est vulnérable à l'exécution de code à distance en raison d'un contournement de CVE-2010-1622.
Initialement, cela a commencé le 30 mars, la première notification de la vulnérabilité a été suggérée par le leader de l'équipe KnownSec 404, Heige. Il a tweeté avec le message d'avertissement "Spring core RCE （JDK >=9" accompagné de l'image de la PoC.
Alors que nous publions l'histoire de la vulnérabilité, Heige disparaît de Twitter. On ne connaît pas la raison derrière cela, mais il y a peut-être quelque chose.
Fin 2021, Internet était en ébullition avec la publication d'une vulnérabilité Zero-day d'exécution de code à distance également connue sous le nom de Log4Shell, dans Apache Log4j2. La vulnérabilité a été découverte par l'équipe de sécurité d'Alibaba Cloud.
Aujourd'hui, des chercheurs ont découvert une autre très grave vulnérabilité qui pourrait causer des dégâts importants. Maintenant, le bogue est suivi sous le nom CVE-2022-22965, nous pouvons l'appeler Spring4Shell. La vulnérabilité existe dans Spring core avec une version JDK supérieure ou égale à 9.0.
Spring Framework et framework dérivé spring -beans-*.jar fichiers ou CachedIntrospectionResults.class
Tous les détails ci-dessous sont maintenant confirmés. Je n'assume aucune responsabilité pour les dommages causés.
En tant que l'un des frameworks open-source légers Java les plus populaires au monde, Spring permet aux développeurs de se concentrer sur la logique métier et simplifie le cycle de développement des applications d'entreprise Java.
L'exploitation nécessite un point d'accès 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 de l'application. Par exemple, lorsque Spring est déployé sur Apache Tomcat, le WebAppClassLoader est accessible, ce qui permet à un attaquant d'appeler des getters et setters pour finalement écrire un fichier JSP malveillant sur le disque. Cependant, si Spring est déployé avec le conteneur de servlet Tomcat embarqué, le classloader est un LaunchedURLClassLoader qui a un accès limité.
Cependant, dans la version JDK9 (et supérieure) du framework Spring, un attaquant distant peut obtenir l'objet AccessLogValve et des valeurs de champs malveillants via la fonction de liaison de paramètres du framework, à condition de remplir certaines conditions.
Sur le serveur en cours d'exécution du système de l'organisation, exécutez la commande "java -version" pour vérifier la version JDK en cours d'exécution. Si le numéro de version est inférieur ou égal à 8, il n'est pas affecté par la vulnérabilité.
Après avoir terminé les deux étapes de dépannage ci-dessus, les deux conditions suivantes sont remplies en même temps pour déterminer qu'il est affecté par cette vulnérabilité :
Maintenant, l'équipe Spring a corrigé la vulnérabilité et a publié les dernières versions de Spring Boot 2.6.6 et 2.5.12 qui dépendent de Spring Framework 5.3.18
Sur les dispositifs de protection réseau tels que WAF, mettez en œuvre un filtrage de règles pour les chaînes telles que "class.", "Class.", ".class." et ".Class." en fonction de la situation réelle du trafic des services déployés. Après avoir filtré les règles, testez le fonctionnement métier pour éviter tout impact supplémentaire.
La réparation temporaire de la fuite doit être effectuée en suivant les deux étapes suivantes simultanément :
Recherchez globalement l'annotation @InitBinder dans l'application pour voir si la méthode dataBinder.setDisallowedFields est appelée dans le corps de la méthode. Si l'introduction de cet extrait de code est trouvée, ajoutez {"class.","Class.",".class.",".Class."} à la liste noire d'origine. (Remarque : si cet extrait de code est beaucoup utilisé, il doit être ajouté partout)
Créez la classe globale suivante sous le package du projet du système d'application, et assurez-vous que cette classe est chargée par Spring (il est recommandé de l'ajouter dans le package où se trouve le Controller). Une fois la classe ajoutée, le projet doit être recompilé et empaqueté, testé pour vérification fonctionnelle, puis republié.
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 GlobalControllerAdvice{ @InitBinder public void setAllowedFields(webdataBinder dataBinder){ String[]abd=new string[]{"class.","Class.",".class.",".Class."}; dataBinder.setDisallowedFields(abd); } }
D'après le dépôt Git des projets Spring, il semble que le développeur Spring travaille sur un correctif pour la vulnérabilité d'exécution de code à distance, mais nous devons attendre la confirmation officielle.
