Reconnaissance
Après une vite analyse du code on se rend compte que le flag sera donnée par un appel au back avec l’url http://localhost:8080/flag.php
Une fois cela en tête on peut essayé différent payload pour réalise une SSRF
Mais on est vite blocker par la “sécurité” mise en place 🤓 :
gethostbyname() nous empêche de faire un DNS rebinding comme mit dans le commentaire, quant a la regex elle me semble un peut juste pour filtrer tous les paylaods SSRF.
SSRF Injection ?
J’ai donc testé plusieurs payload à savoir
1 | http://0/ --> ❌ |
Avec le payload en IPV6 j’arrive à bypass la regex, mais je me rend compte que mon url utilisé par la suite est mauvais : http://::1:8080/flag.php, en effet il a été cassé lors de la gethostbyname(). Après plusieurs testes avec d’autre payload toujours rien de concluant …
J’opte donc pour tester une SSRF par redirection, je code un rapide server python avec flask :
1 | from flask import Flask, redirect |
Avec un petit Dockerfile fait par le goat GPT
1 | # Utilise une image Python légère |
Un fois démarrer j’ai bien une ip différente de 127.0.0.1, car je l’ai lancé sur 0.0.0.0
J’envoie cette adresse dans le formulaire .. Et bingo, le flag s’affiche !
Conclusion
Challenge vraiment cool première fois que je voyais une SSRF par redirection dans un challenge, donc vraiment cool de voir le sujet en pratique apprendre plus sur Server-side request forgery en générale 🫶
This work is licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International License .