home
tags
whoami

CTF inter-IUT - PokéMaster

2018/06/05

Ma deuxième write-up du CTF inter-IUT, organisé par des étudiants de l’ENSIBS. Celui-là nous a donné beaucoup de fil à retordre avec Guigui, au point qu’on y a passé bien 1h30 (sur 7h d’épreuves) sans flag. Nous étions salés. Heureusement, Maki, le Créateur de l’épreuve (avec une majuscule oui), dispose d’un git sur lequel celle-ci reste disponible. J’ai pu prendre ma revanche face à Dracaufeu EX. Attaque éboulement super efficace coup critique.


Challenge : PokéMaster
Catégorie : Web
Points : 200
Énoncé : This organization steals and mistreats Pokemon… You can’t close your eyes on this story! Help them!
Ressource : GitHub de Maki

Une fois le docker lancé, on se rend à l’adresse 127.0.0.1:5004. on découvre un site web statique, doté de 3 pages : services.html, pricing.html, contact.html.
screen
En explorant les 3 pages, on découvre différents textes et faux liens, comme celui-ci : https://lc.cx/QJA. Rien d’intéressant en terme de flag, simplement un site RP.
On se dirige donc dans le code source des 3 pages. On y trouve des liens vers les répertoires css et js par exemple. Donc au cas où, on va aux adresses 127.0.0.1:5004/css/ et 127.0.0.1:5004/js/. On se fait accueillir par une jolie page blanche avec pour titre "Silence is Eloquence". Si tu le dis.
Rien en apparence, rien dans le code source… pourtant on doit extraire des informations de ce site. Qu’est-ce qu’on connaît comme fichier récurrent sur un serveur web ?
robots.txt
Go 127.0.0.1:5004/robots.txt :
screen
Et miracle, un path ! Sans plus attendre : 127.0.0.1:5004/cgi-bin/uptime.
screen
Le voici… le Dracaufeu EX nous ayant taunt mon camarade et moi. Donc pour info, c’est sur cette page qu’on est resté bloqué des plombes.
Mais concrètement, que nous apporte cette page ?
Et bien on sait maintenant qu’un répertoire cgi-bin existe. Il est utilisé dans les serveurs web pour exécuter des scripts et afficher le retour généré. Il se trouve qu’ici, la commande bash uptime est lancée, comme en témoigne le retour de son exécution "09:13:45 up 1:13, 0 users, load average: 0.00, 0.00, 0.00".
Donc sur le papier, on est pas trop mal. On peut par exemple essayer d’exécuter une autre commande à la place de uptime ?
On essaye 127.0.0.1:5004/cgi-bin/ls
screen
Peut-être en chaînant la commande uptime avec une autre ?
127.0.0.1:5004/cgi-bin/uptime;ls
screen
Ah. C’est le moment fatidique où on a pas su quoi tester d’autre. Au bout d’un moment on a donc plus ou moins laissé tomber.
Néanmoins, après le CTF, on voulait absolument une write-up pour ce chall qui nous a laissé sur notre faim. Maki nous a parlé dans un tweet de la faille "Shellshock".
En se documentant sur Shellshock, on se rend compte qu’en fait c’est une grosse faille découverte en 2014 notée 10⁄10 : CVE-2014-6271. Sympa !
Comment l’exploiter ?
On tape "cve-2014-6271 exploitation" sur notre search engine favori. Je suis tombé sur le site de docker : article
On y découvre le payload suivant à injecter à la place de notre User-Agent, constituant une RCE (Remote Code Execution), nous permettant ici de lire le contenu du fichier /etc/passwd par exemple :
() { :; }; echo; echo; /bin/bash -c 'cat /etc/passwd;'
OK, testons ça. On ouvre Burp et on paramètre Firefox pour avoir un proxy HTTP en 127.0.0.1:8080 (proxy Burp). On actualise notre page uptime vulnérable, et dans Burp on modifie le User-Agent comme ci-dessous :
screen
screen
On clique sur "Forward", et on retourne voir le résultat sur 127.0.0.1:5004/cgi-bin/uptime :
screen
Et bim, le fichier /etc/passwd du serveur en gros plan. Bon bah on a notre payload, plus qu’à trouver et lire le fichier de flag :
() { :; }; echo; echo; /bin/bash -c 'cat $(find / -name flag)'
screen


Tags

ctf inter-iut web shellshock