Aujourd’hui je m’attaque à la machine Mirai, classée facile sur HTB.
Comme d’habitude, scan de port.
3 ports d’ouvert, port 22 ssh, port 53 dns et port 80 http.
Je regarde le port 80, rien d’intéressant sur la page d’accueil. Une recherche via ffuf nous indique deux autre pages.
La page admin est une page vers Pi hole. Pi Hole est un bloqueur de pub au niveau du réseau qui agit comme un dns menteur, destiné a être utilisé sur un réseaux privée. Cela nous indique très certainement que la machine est un Raspberry Pi.
Ayant eu un Raspberry Pie, je sais que pour se connecter, on utilise une Connexion ssh. Les identifiants de base sont pi:raspberry.
https://itsfoss.com/ssh-into-raspberry/
L’utilisation avec Hydra nous montre que ceux ci n’ont pas été changés.
Une fois connecté en SSH, élevons nos privilèges.
En utilisant sudo -l, nous pouvons tout lancer en root et sans mot de passe.
Un simple sudo su et nous voila root.
Malheureusement, le flag root n’est pas présent.
D’après l’indication du fichier root.txt, on peut supposer qu’il existe un lecteur ou une partition montée qui contient une copie du fichier original. L’exécution de df -h fournit une liste des partitions de la machine, la dernière étant montée sur /media/usbstick.
En naviguant dans /media/usbstick, on trouve un seul fichier, damnit.txt. James a malencontreusement supprimé les fichiers dans la clé usb.
Le flag supprimé doit être récupéré. Une vérification rapide dans lost+found ne donne aucun résultat, il faut donc utiliser d’autres méthodes.
La commande
sudo dcfldd if=/dev/sdb of=/home/pi/usb.ddva créer une image de la clé USB et la sauvegarder dans le répertoire personnel de l’utilisateur de la pi.
De là, le fichier peut être exfiltré de plusieurs façons. Dans ce cas, un simple SCP depuis la machine attaquante suffira. La commande suivante copie le fichier usb.dd dans le répertoire de travail de la machine locale :
scp pi@10.10.10.48:/home/pi/usb.dd .
Avec l’image USB en main, il est possible d’exécuter une large gamme d’outils contre elle pour extraire les données. Malheureusement, dans ce cas, les données entre le nom du fichier et le contenu du fichier lui-même ont été écrasées, donc la récupération avec la plupart des outils n’est pas possible. Une vérification rapide avec testdisk montre que le fichier a une taille de 0.
Sachant que le fichier a existé à un moment donné, on peut supposer que les données peuvent encore se trouver dans l’image. L’ouvrir avec n’importe quel éditeur de texte ou hexa révélera le drapeau, tout comme l’exécution de chaînes de caractères sur l’image.
