dungsocool/cve-2017-12635_36Laboratoire pas à pas démontrant l'exploitation de CVE-2017-12635 (élévation de privilèges) et CVE-2017-12636 (exécution de code à distance) contre Apache CouchDB 1.6.0, avec évaluation des risques et conseils de correction.
En commençant par ce qui est exécuté dans l'environnement. Je liste tous les conteneurs actifs :
docker ps
La victime expose un seul port : 5984
⇒ Je curl directement dessus pour sonder plus d'informations :
curl -i http://192.168.3.137:5984/
Analyse de la réponse :
Réponse : HTTP/1.1 200 OK, prouvant que le service sur le port 5984 est actif et accessible directement via HTTP.
En-tête du serveur : CouchDB/1.6.0 (Erlang OTP/17) et le corps JSON contenant "version":"1.6.0" confirment qu'il s'agit d'Apache CouchDB version 1.6.0.
Évaluation de la surface d'attaque :
Le service CouchDB est exposé extérieurement via le port 5984. Il s'agit du port par défaut de l'API HTTP CouchDB, permettant l'interaction avec la base de données via une API REST.
La version CouchDB 1.6.0 est une version ancienne, antérieure au correctif 1.7.1. Selon la documentation Apache, les versions de CouchDB dans cette plage sont affectées par :
roles JSON en double.=> Réflexion : À partir de la réponse obtenue, il y a suffisamment de preuves pour déterminer que la victime exécute Apache CouchDB 1.6.0 sur le port 5984. Il s'agit d'une version plus ancienne associée à la chaîne d'exploitation de CVE-2017-12635 et CVE-2017-12636. Par conséquent, un chemin d'exploitation logique consiste à tester d'abord l'état de l'authentification, puis à évaluer le potentiel d'élévation de privilèges ou d'exécution de commandes via l'API HTTP de CouchDB.
CVE-2017-12635 exploite la divergence entre deux analyseurs JSON dans CouchDB. Lors de l'envoi d'un document utilisateur à /_users avec deux clés roles en double, CouchDB utilise la deuxième clé roles pour vérifier les droits d'écriture du document, mais utilise la première clé roles pour les permissions réelles de l'utilisateur après la création. Ainsi, un attaquant définit la première roles sur ["_admin"] et la deuxième roles sur [] pour contourner la validation, ce qui fait que l'utilisateur créé possède des privilèges d'administrateur.
Selon la documentation de CouchDB, CouchDB stocke les informations utilisateur dans une base de données spéciale nommée _users, où chaque document utilisateur a un ID formaté comme org.couchdb.user:<nom_utilisateur>. Comme nous devons créer un utilisateur nommé hacker, le point de terminaison utilisé est /_users/org.couchdb.user:hacker. Je crée un nouvel utilisateur et lui attribue des privilèges admin pour voir comment le serveur répond.
curl -X PUT http://192.168.3.137:5984/_users/org.couchdb.user:hacker \
-H "Content-Type: application/json" \
-d '{
"type": "user",
"name": "hacker",
"roles": ["_admin"],
"roles": [],
"password": "password123"
}'
La réponse retournée est true, prouvant que l'utilisateur a été créé avec succès. J'effectue une vérification en utilisant les identifiants admin nouvellement créés : curl -u hacker:password123 http://192.168.3.137:5984/_users. Le point de terminaison /_users est une base de données système, qui par défaut seuls les administrateurs peuvent lire les métadonnées. Si elle est demandée par un utilisateur normal → 403 Forbidden. La réponse 200 OK avec les informations complètes de la DB confirme que le compte hacker possède bien les privilèges _admin. Cela correspond parfaitement à l'hypothèse CVE-2017-12635 sur Apache CouchDB 1.6.0.
Résumé :
J'ai vérifié avec succès CVE-2017-12635 sur Apache CouchDB 1.6.0. Initialement, le port 5984 montrait seulement que l'API HTTP CouchDB était exposée. Après fingerprinting via curl, la réponse a confirmé que le service est CouchDB 1.6.0, une version dans la plage de vulnérabilité de CVE-2017-12635.
Au lieu de conclure immédiatement que la RCE est possible, j'ai d'abord vérifié le flux d'authentification étape par étape. En envoyant un document utilisateur à /_users avec deux clés roles en double, la charge utile a créé avec succès l'utilisateur hacker. Ensuite, la requête à /_users via curl -u hacker:password123 a retourné 200 OK avec les détails de la base de données système, prouvant que l'utilisateur hacker possède véritablement les privilèges _admin.
Par conséquent, une fois les privilèges admin CouchDB acquis, la surface d'attaque s'étend à CVE-2017-12636, car les administrateurs peuvent modifier la configuration de CouchDB via l'API HTTP. Cela sert de prérequis pour évaluer plus en avant les capacités d'exécution de code à distance sur le serveur.
⇒ Réflexion : Utiliser les privilèges admin nouvellement acquis pour tester l'exécution de commandes au niveau du système d'exploitation.
Selon la documentation Apache CouchDB, un Query Server est un processus externe utilisé par CouchDB pour traiter les fonctions de conception, comme une vue JavaScript dans le mécanisme MapReduce. Lorsqu'un document de conception déclare un champ "language", CouchDB utilise cette valeur pour rechercher le serveur de requêtes correspondant dans la configuration query_servers.
Si le document de conception contient "language": "javascript", CouchDB interroge la configuration query_servers.javascript pour déterminer quel processus lancer pour traiter la fonction map/reduce. C'est une conception légitime de CouchDB, car le noyau CouchDB n'exécute pas directement tout le code de vue dans le moteur de base de données.
⇒ Le problème de CVE-2017-12636 réside dans la capacité d'un administrateur CouchDB à modifier la configuration du serveur via l'API HTTP. Certaines de ces configurations incluent des chemins vers des binaires ou des processus au niveau du système d'exploitation que CouchDB lancera. Par conséquent, après avoir obtenu les privilèges admin de CVE-2017-12635, un attaquant peut modifier query_servers.<langage> pour pointer vers une commande OS. Lors du déclenchement d'une vue qui utilise le langage correspondant, CouchDB va lancer la commande, entraînant l'exécution de commandes sur le serveur.
Flux d'exploitation :
query_servers.cmd via le point de terminaison /_config."language": "cmd".query_servers.cmd et lance le processus configuré.Écriture de la configuration malveillante du query_server