Chanson d'Inde
Last updated
Last updated
Catégorie: Web - Difficulté: Difficile
Description:
Lien : https://chanson-d-inde.challenges.404ctf.fr/
Solution:
Pour ce challenge, nous avons accès à une page basique avec un bouton qui nous emmène vers une autre page :
Le possible point d'entrée est l'URL d'un fichier audio à envoyer (en haut de la page). Cependant après avoir fais différents tests, rien de bien concluant.
Dans le doute, nous tentons de voir s'il n'y a pas un fichier robots.txt disponible. Et c'est le cas : https://chanson-d-inde.challenges.404ctf.fr/robots.txt
Nous voyons donc qu'il y a un fichier CHANGELOG.md existant (https://chanson-d-inde.challenges.404ctf.fr/CHANGELOG.md)
Nous pouvons donc voir ce qui a été fait sur ce site ainsi que les dates de ces changements. Nous pouvons tout lire mais le plus intéressant est ce qui a été changé le plus récemment :
En regardant les changements, nous voyons que la version d'ExpressJS a été mise à jour juste avant le démarrage du 404CTF, ce qui fait qu'une nouvelle vulnérabilité aurait été bien vite trouvée (en 1 semaine). Mais pour être sûr, nous allons vérifier les anciennes dates de découvetes de vulnérabilités pour ExpressJS : https://security.snyk.io/package/npm/express La dernière en date est répertoriée en Octobre 2022.
Passons au deuxième changement datant du 15/02/2021 où la version d'EJS a été changée. En regardant les vulnérabilités sur la version d'EJS en Février 2021, nous trouvons ceci :
En regardant les dates des CVE découvertes et celle de la mise à jour d'EJS sur le site web, nous trouvons qu'il s'agit d'une vulnérabilité à exploiter avec une RCE : CVE-2022-29078. Sur la page, nous trouvons directement un payload préparé. Néanmoins pour bien comprendre, nous pouvons chercher d'autres ressources. Voici celle que j'ai utilisée : https://eslam.io/posts/ejs-server-side-template-injection-rce/
Nous voyons donc le payload utilisé : ?id=2&settings[view options][outputFunctionName]=x;process.mainModule.require('child_process').execSync('command_to_execute');s et comment l'utiliser. Nous passons simplement une commande que nous voulons exécuter sur le serveur et ça sera bon.
Maintenant il faut trouver où envoyer ce payload... Souvenons nous au début, nous avons trouvé qu'il est possible d'envoyer une URL d'un fichier audio afin qu'il soit pris en compte. Voilà notre porte d'entrée.
Pour la pratique, nous allons utiliser le proxy de Burp et modifier la requête avant de la renvoyer. 1. Interception de la requête :
ℹ️Pour ne pas réexécuter à chaque fois toutes ces étapes, nous allons envoyer la requête au module "Repeater" pour simplement changer les paramètres souhaités (ici l'URL).
Une fois dans le module Repeater, nous allons pouvoir passer à la suite. 2. Modification de la requête et envoi de notre payload :
Là nous avons la requête et notre payload a exécuter sur le serveur. Pour pouvoir l'envoyer, nous allons l'ajouter après notre URL comme ceci :
Mais étrangement nous n'avons aucun résultat, pas de retour... Il faut donc trouver une solution pour récupérer le retour de notre commande, car sinon ça ne servira pas à grand chose.
En y réfléchissant il faut trouver une solution pour retourner le résultat : echo() ? print() ? alert() ? return ?
En les testant tous, nous voyons qu'il n'y a que le return qui fonctionne :
3. Récupération du résultat de notre payload :
Nous récupérons enfin le résultat de notre commande. C'est génial, car maintenant nous pouvons naviguer dans les fichiers et chercher où pourrait se situer notre flag (assez simple ici).
On continue étape par étape, jusqu'à récupérer le flag :
Nous parvenons enfin à récupérer notre flag grâce au payload suivant : ?id=2&settings[view%20options][outputFunctionName]=x;return global.process.mainModule.constructor._load('child_process').execSync('cat flag/flag.txt');s
Ce chall était assez complexe mais très intéressant sur la manière d'exploiter une ancienne vulnérabilité d'un service utilisé très souvent.
