Fournisseur : HackTheBox Système : Android Difficulté : Facile Objectif : Récupérer un flag intermédiaire dans /storage puis le flag dans /data Enumération On scanne tous les ports (avec -p-). Malgré le -sV qui devrait nous retourner le logiciel et sa version derrière chaque port, nmap galère à savoir ce qu'il s'y trouve, je vous mets donc un retour nmap trafiqué avec des recherches que j'ai faites. $ nmap -p- 10.10.10.247 PORT STATE SERVICE 2222/tcp open SSH Server Banana Studio 5555/tcp filtered freeciv 40487/tcp open unknown 42135/tcp open unknown 59777/tcp open ES File Explorer Vulnérabilitée CVE-2019–6447 d'ES File Explorer Le port 59777 appartient à un service accessible via le navigateur, mais l'adresse http://10.10.10.247:59777/ retourne une erreur FORBIDDEN: No directory listing.. On ne peut pas lister le dossier courant, mais on pourrait potentiellement accéder à un fichier si on donne sont entièrement son chemin. La lecture de cet article nous indique une faille de l'application ES File Explorer, cette dernière laisse un port ouvert au monde et cela nous permet de lui faire exécuter des commandes et d'en récupérer le retour. On teste donc avec la commande getDeviceInfo indiqué par l'article et ça marche ! $ curl --header "Content-Type: application/json" --request POST --data "{\"command\":\"getDeviceInfo\"}" http://10.10.10.247:59777 {"name":"VMware Virtual Platform", "ftpRoot":"/sdcard", "ftpPort":"3721"} Le retour de la commande confirme donc notre théorie, on a un ftp accessible via le navigateur dont la base se trouve dans le /sdcard du téléphone. On tâtonne donc et on trouve finalement que le flag user est accessible à l'adresse http://10.10.10.247:59777/sdcard/user.txt. USER OWN ! Il ne reste plus qu'à récupérer le flag root pour valider le SYSTEM OWN. On continue à creuser la faille d'ES File Explorer, le repo ESFileExplorerOpenPortVuln nous informe sur d'autres commandes que l'on pourrait exécuter, on peut lister les fichiers, les images, les vidéos, etc. On se balade un peu dans le system de fichiers et en listant le dossier DCIM, on tombe sur une photo dont le nom semble évoquateur (creds.jpg) $ curl --header "Content-Type: application/json" --request POST --data "{\"command\":\"listFiles\"}" http://10.10.10.247:59777/sdcard/DCIM [ ... {"name":"creds.jpg", "time":"4/21/21 02:38:18 AM", "type":"file", "size":"1.14 MB (1,200,401 Bytes)", }, ... ] On accède à l'image via le navigateur (http://10.10.10.247:59777/sdcard/DCIM/creds.jpg) Ça ressemble bien une paire d'identifiants et ceux-ci nous permettent en effet de nous connecter en SSH au smartphone. Problème, on a accès à rien de plus qu'on ce qu'on avait précédemment, on a pas les droits de lecture dans tous les dossiers un peu croustillant où pourrait se trouver le flag root. FreeCIV Arbitrary Code Execution Une petite recherche sur Google pour ssh server banana studio exploit semble donner à chaques fois le même résulat, un script de Raed Ahsan, de plus, on tombe sur le même script quand on recherche freeciv exploit, un autre service qui tourne sur le port 5555. En analysant un peu le script, on se rend compte qu'il fait au final une seule chose que l'on peut faire en une seule commande, il se connecte en SSH à l'appareil (ce qu'on peut faire grâce aux identifiants de la photo) et "redirige" le port 5555 du téléphone sur notre port 5555 local : $ ssh -p 2222 -L 5555:localhost:5555 kristi@10.10.10.247 Tant que cette connexion est ouverte, on a accès au port 5555 du téléphone en local. Ce port va nous permettre d'ouvrir une connexion ADB (Android Debug Bridge) à distance. Pour ce faire, on démarre le démon adb avec adb start-server (le démon adb DOIT être démarré après avoir redirigé le port 5555, s'il est déjà démarré, on le kill avec adb kill-server). Si on lance maintenant un adb devices, on voit qu'un appareil est connecté : $ adb devices List of devices attached emulator-5554 device On peut maintenant faire (quasiment) ce qu'on veut sur ce téléphone. Pour s'amuser, on peut même afficher et contrôler son écran à distance grâce à l'outil scrcpy. Le problème reste par contre le même : on n'a pas les droits de lecture sur les dossiers qui nous intéressent. Une solution "facile" serait que le téléphone soit rooté et qu'on a juste à faire un su via le shell ADB pour devenir root. Et plus j'y pense, plus je me dis que c'est possible, et ça ne coute rien d'essayer : $ adb shell x86_64:/ $ su :/ # ET ÇA MARCHE, on a maintenant accès à un shell root sur le téléphone ! Un simple find nous permet de localiser le fichier root.txt : $ find / -name root.txt ... /data/root.txt $ cat /data/root.txt f04fc82b6d49b41c9b08982be59338c7 SYSTEM OWN !!

Fournisseur : HackTheBox Système : Linux Difficulté : Facile Objectif : Récupérer un flag intermédiaire dans le home de Nathan puis le flag dans le home du root Scan des ports pour voir keskia : $ nmap -sV -sC 10.10.10.245 PORT STATE SERVICE VERSION 21/tcp open ftp vsftpd 3.0.3 22/tcp open ssh OpenSSH 8.2p1 Ubuntu 4ubuntu0.2 (Ubuntu Linux; protocol 2.0) 80/tcp open http gunicor Exploration du serveur web On a accès aux téléchargements de données Wireshark et en manipulant l'URL, on accède aux premières données enregistrées (sur http://10.10.10.245/data/0). On trouve dans ce fichier Wireshark le trafic FTP de Nathan en clair : on trouve son de passe FTP (Buck3tH4TF0RM3!) qui nous permet aussi de se connecter en SSH ! SSH pour le user flag On arrive directement dans le home de Nathan et un fichier user.txt contient le flag user. Le classicos escalade de privilèges Après quelques tests on arrive à faire une escalade de privilèges avec Python : import os os.setuid(0) # on se met root os.system("/bin/bash") # on ouvre un bash rooté Ce bash rooté nous donne accès au /root dans lequel on trouve un root.txt qui contient le flag !