dungsocool/cve-2019-20933Rédaction pas à pas d'un laboratoire démontrant le contournement d'authentification InfluxDB via des jetons JWT falsifiés (CVE-2019-20933), incluant l'exploitation, la post-exploitation et les conseils de correction.
En commençant par ce qui s'exécute dans l'environnement. Je liste tous les conteneurs actifs :
docker ps
La victime expose un seul port : 8086.
Actuellement, je ne dispose pas d'informations détaillées sur la cible. D'après la sortie de docker ps, le système n'expose qu'un seul service notable en externe sur le port 8086, qui est mappé au service à l'intérieur du conteneur. C'est la principale surface d'attaque à analyser.
Au lieu d'y accéder immédiatement via le navigateur, nous procédons à l'empreinte du service avec Nmap pour déterminer quel service tourne sur le port 8086 :
nmap -sV -sC -p 8086 192.168.3.137
Les résultats du scan montrent que le port 8086 est le service HTTP d'InfluxDB OSS 1.6.6. Il s'agit d'une base de données de séries temporelles exposée via une API HTTP, et non d'une application web classique.
InfluxDB est une base de données de séries temporelles (TSDB) open source écrite en Go. Contrairement aux SGBDR (optimisés pour les transactions précises) ou à Elasticsearch (optimisé pour la recherche textuelle), InfluxDB a été créé dans un seul but : Gérer des volumes d'écriture massifs (débit d'écriture élevé) et interroger des données sur l'axe temporel avec une faible latence.
Le service ayant été identifié comme InfluxDB, l'étape suivante consiste à se référer à la façon dont InfluxDB communique avec les clients. D'après la documentation de l'API HTTP d'InfluxDB v1, le port 8086 est le port d'API HTTP par défaut. Les points de terminaison importants incluent :
/ping : vérifie l'état opérationnel du serveur./query : envoie des requêtes InfluxQL pour lire des métadonnées ou des données./write : écrit des données de séries temporelles dans la base de données.⇒ Réflexion : Après que Nmap a identifié le service comme InfluxDB http admin 1.6.6, nous ne continuons pas à le tester comme un site web standard. Pour les applications web, nous cherchons généralement des routes, des formulaires de connexion ou des répertoires. Cependant, avec InfluxDB, la surface d'attaque réside dans l'API HTTP. Par conséquent, nous devons basculer vers le test des points de terminaison standard de l'API InfluxDB pour déterminer si l'API nécessite une authentification. En conséquence, la prochaine direction de test n'est pas d'accéder à / via le navigateur, mais d'envoyer des requêtes directement aux points de terminaison de l'API d'InfluxDB.
/pingAprès avoir identifié le port 8086 comme l'API HTTP d'InfluxDB, vérifiez le point de terminaison /ping pour confirmer que le service est opérationnel :
curl -i <http://192.168.3.137:8086/ping>
La réponse 204 No Content confirme qu'InfluxDB fonctionne normalement. Les en-têtes confirment en outre la version du service comme InfluxDB OSS 1.6.6
/querycurl -i -s "http://192.168.3.137:8086/query?q=SHOW+DATABASES"
Le point de terminaison /query n'autorise pas les requêtes directes sans informations d'identification. Cela confirme qu'InfluxDB a l'authentification activée et bloque toutes les requêtes anonymes envoyées au système.
Je réfléchis : est-ce que la version 1.6.6 d'InfluxDB présente une vulnérabilité permettant de contourner le mécanisme d'authentification ?
En consultant les bases de données de vulnérabilités publiques, les versions d'InfluxDB antérieures à 1.7.6 sont affectées par CVE-2019-20933. Il s'agit d'une vulnérabilité de contournement d'authentification dans la fonction d'authentification d'InfluxDB, liée à la gestion des jetons JWT avec un secret partagé vide.
Étant donné que la cible exécute InfluxDB 1.6.6, qui est inférieure à la version corrigée 1.7.6, le service se situe dans la plage de versions affectées.
On peut conclure :
Service : InfluxDB OSS
Version : 1.6.6
Authentification : Activée
Correspondance CVE : CVE-2019-20933
Impact : Contournement d'authentification
Statut : Version vulnérable
⇒ Réflexion : Initialement, le point de terminaison /query renvoie 401 Unauthorized, indiquant que le mécanisme d'authentification est actif. Cependant, avoir l'authentification activée ne signifie pas une sécurité absolue. Lorsque la version est identifiée comme 1.6.6, nous devons la corréler avec les CVE connues. Les résultats indiquent que cette version se situe dans la plage affectée par CVE-2019-20933, ce qui signifie qu'il est possible de contourner le mécanisme d'authentification protégeant le point de terminaison /query. Sur la base de ces résultats d'identification, la phase d'exploitation se concentrera sur la vérification de CVE-2019-20933 en générant un jeton JWT approprié pour contourner l'authentification et exécuter des requêtes contre le point de terminaison /query.
La vulnérabilité CVE-2019-20933 se produit dans la fonction authenticate du fichier services/httpd/handler.go d'InfluxDB antérieur à la version 1.7.6.
InfluxDB supporte l'authentification utilisant JSON Web Tokens (JWT) pour les requêtes API HTTP. Lors de la réception d'une requête avec l'en-tête :
Authorization: Bearer <token>
InfluxDB effectuera les étapes suivantes :
shared-secret du fichier influxdb.conf pour agir comme clé secrète pour la vérification de la signature du jeton.username des revendications pour déterminer l'utilisateur exécutant la requête.Dans les versions affectées, si l'authentification JWT est activée mais que le paramètre shared-secret n'est pas configuré, la valeur secrète peut être traitée comme une chaîne vide ("").
Le système ne parvient pas à valider correctement la force de sécurité du secret avant de vérifier la signature JWT. Cela permet à un attaquant de construire un JWT personnalisé, de le signer avec un secret vide, puis de définir la revendication username sur un compte valide du système, tel que admin si ce compte existe dans le laboratoire.
Lorsque ce jeton est soumis via l'en-tête Authorization: Bearer <token>, InfluxDB utilise le même secret vide pour vérifier la signature. Si la signature correspond et que le nom d'utilisateur existe, la requête sera autorisée sans nécessiter le mot de passe réel de l'utilisateur.
Le flux de traitement peut être résumé comme suit :