Cette fois, nous avons droit à un vrai si, complet
Reconnaissance
On commence par l'habituel robots.txt, mais rien
J'oublie souvent ce fichier, mais les situations réelles reviennent régulièrement me rappeler
qu'il contient plein d'informations utiles (dont, par exemple, des valeurs par défaut
trahissant le framework ou le CMS utilisé).
On essaie alors le formulaire de connexion, avec quelques caractères classiques et "innocents":
Le "Grand", O'Rilley etc mais rien ne trahis une éventuelle SQLi
Dans les cookies, on trouve alors un token d'authentification, apparemment en bas64
Ce n'est pas un JWT, puisqu'il ne démarre pas par eyJ
Cookie
En décodant ce cookie (à droite), on retrouve notre pseudo et un hash de mot de passe (à gauche)
J'essaie souvent d'avoir, dans la moitié droite, la partie "locale" (ou test)
et dans la moitié gauche la partie "distante" (ou "prod").
Ca permet de limiter les risques de se mélanger.
Touche "Windows" + une flèche (gauche/droite) permet de mettre la fenêtre sur la moitié
correspondante de l'écran
J'essaie alors de générer un cookie dont le username serait "admin",
puisqu'il s'agit souvent du username le plus critique
La deuxième commande supprime les retours à la ligne du base64, via tr -d "\n"
Et ça fail, mais avec un message d'erreur quand on veut accéder à l'espace d'administration:
"mauvais mot de passe".
On a donc un chemin intéressant et le bon username, donc on continue
Forgot password
Le mot de passe de l'admin n'est pas le bon, alors, essayons de le récupérer…
mais le site refuse!
Quand un challenge dit qu'un truc est "infaillible", c'est qu'il y a très certainement une faille!
Je vadrouille alors, et la page "connect" me renvoie un autre message
Injection de connexion
Comme un ; est utilisé comme séparateur dans le cookie,
je vide ceux-ci et je tente un login avec un ;
Paf, une nouvelle erreur (une HTTP 500)
Casser le hash?
En reprenant mon cookie d'avant (dont je connais le mot de passe simpliste 123456),
j'essaie de voir ce qu'est le hash du password via John: c'est un SHA512
J'avais en tête d'essayer de "casser" le hash du mot de passe admin…
et je me suis aperçu que je n'avais pas ce hash! Donc, la piste n'a pas de sens
Tamper cookie
J'essaie alors de voir si je peux bricoler le cookie pour que le système me "connecte"
avec legrand et 123456 puis qu'ensuite, il interprète mon user comme admin
Il est courant, dans les systèmes réels, d'avoir ce genre de mauvaise interprétation.
Le cas classique concerne les headers HTTP: deux systèmes chaînés peuvent ne pas lire les headers
dans le même ordre, et en cas de header présent en double, le premier système ne lira que le premier
header, alors que l'autre utilisera le second header. Cela offre des possibilités de bypass
En essayant dans l'autre sens (username=dummy;password=dummy;username=admin;password=),
j'accès à la page "mot de passe oublié… et le site me prend pour l'admin!
Trouver le hash
J'essaie un mot de passe bidon, dans le but de voir s'il est envoyé au serveur:
aucun traffic n'apparait
Comme on l'a vu pour
Fiché JS (Web)
,
l'absence de traffic lors de la "vérification" du mot de passe implique que celle-ci se fait côté client.
On doit donc avoir reçu, dans un fichier quelconque, le mot de passe (hashé ou chiffré éventuellement)
En fouillant les codes, on trouve le hash de ce mot de passe
(qui est bien en SHA512 vu le nom de la fonction)
C'est là où je me suis dit
"inutile de casser ce hash! le cookie contient le hash! autant l'utiliser directement"
Connexion
Je réutilise alors le hash avec le login admin dans mon cookie, en me disant "ça devrait marcher direct"
Et on a un nouveau message: le cookie est blacklisté apparemment (zut!)
Passer la blacklist
J'ai donc tenté d'utiliser deux champs "password" (identiques): fail
(j'ai aussi essayé d'autres variantes du genre, mais on va les zapper)
Soupçonnant le serveur de construire un tableau associatif à partir du cookie,
je tente d'ajouter =; (clef vide, valeur vide) et poof! Flag!
404CTF{m3f13Z_V0Us_D3s_MdP_D4nS_L3s_c00k13s!}
Principe:
