1337 Secur1ty
Dernière mise à jour
Dernière mise à jour
"1337 Secur1ty" est un challenge Web de niveau difficile (hard). Son accès se fait grâce à une URL indiquée dans une modale :
L'application permet de s'authentifier ainsi que de créer un compte. Je commence donc par m'enregistrer afin d'aller voir ce qu'il se cache derrière cette mire d'authentification :
Une fois le compte créé, je suis automatiquement authentifié et redirigé vers la page de profil :
Je possède une adresse email "sforce@1337secur1ty.hak" qui a été automatiquement créée par l'application. Avant d'aller plus loin, je m'intéresse au mécanisme de session. L'application fournit deux cookies. Le premier nommé "secret", semble contenir une valeur aléatoire, le second est nommé "userid" et a pour valeur 3, qui représente sans aucun doute l'id en base de données de la ligne correspondant à notre compte. Je tente tout d'abord de changer cet id, l'objectif étant de voir s'il n'est pas possible d'accéder à un compte d'une autre personne. Malheureusement cela me ramène à la mire d'authentification.
Je continue donc l'exploration des fonctionnalités avec l'onglet "Messages" et "Employees", en commençant par le dernier, soit "Employees" :
Le premier compte est intéressant, il s'agit d'un compte de type administrateur. L'identifiant "ID" correspond également à l'id stocké dans le cookie, soit "3" dans mon cas.
Je passe à la fonctionnalité "Messages" et j'ai déjà un message en attente de lecture provenant de l'administrateur du site :
En cliquant sur le numéro du message (# 1) il est possible de lire le message complet :
Le message possède l'id 2 présent en paramètre de l'URL. Le champ des possibles est assez grand ici, je commence par tenter d'accéder à d'autres messages en itérant l'id. L'itération est effectuée via Burp et son intruder pour pouvoir itérer sur un grand ensemble de valeur dans le cas ou un message serait "caché" avec un id très grand par exemple :
La taille de la réponse permet de voir que l'id 1 est un message valide :
Intéressant, les cookies ne doivent pas être si sécurisés que cela. Je tente maintenant de détecter une injection SQL. Après plusieurs essais, j'identifie l'injection grâce à un sleep(10). De plus, il faut faire attention au paramètre qui ne semble pas être un entier :
Je sors l'artillerie lourde pour gagner du temps, merci sqlmap . Une seule base de données est disponible (en plus de "information_schema") nommée "1337_Secur1ty" :
Je dump la base qui m'intéresse, et plus particulièrement la table nommé "Users" :
sqlmap n'arrive pas à cracker le mot de passe de l'administrateur. Ce n'est pas grave, connaissant son id (id 1) et possédant la valeur de son jeton secret (transmis par le cookie) il me suffit d'un petit changement et me voilà connecté en tant qu'administrateur. Le flag s'affiche alors :
Il est tout de même possible de récupérer le mot de passe grâce à https://hashtoolkit.com :
Mais la connexion au compte administrateur n'est en fait pas possible, car je ne connaissais pas son OTP (One Time Password) demandé à l'authentification.
