Description

Sticky! Sticky!

sticky.wargame.ndh

Resolution

Nous arrivons sur  une page web sur laquelle nous pouvons nous enregistrer en rentrant un pseudo.

Une fois cette étape passée, un message de bienvenue nous est affiché.

Après quelques tests, nous nous apercevons qu’il est possible d’enregistrer n’importe quel pseudo, aussi bien admin, root, des caractères étranges.
A l’affichage, ce champ n’était pas du tout protégé, permettant d’insérer du HTML ou y exécuter du code rendant possible les attaques de type XSS. Mais ce n’était pas la bonne piste pour trouver le flag.

Ensuite, directions les cookies qui sont bien remplis :

• validator : contenant par défaut validator.wargame.ndh
• user_id : un identifiant numérique qu’il est possible de changer pour tomber sur le compte d’un autre utilisateur
• resolution : une chaine ressemblant à du base64 mais qui ne donne pas grand chose une fois décodée

En tentant de modifier le cookie validator, peu importe la chaine insérée, un message d’erreur est affiché nous expliquant que la valeur a été hijhackée et que donc la valeur par défaut serait utilisée : validator.wargame.ndh:8888.

Tip top, on va tenter de se connecter au validateur alors, histoire de voir comment il nous répond, un coup de requête http (fail)… Les DNS pointent vers un autre réseau que celui sur lequel nous sommes, 192.168.0.9, impossible de joindre ou même scanner les ports de la machine :(.

Ensuite, un hint nous informe que ce qui semblait être un base64 serait en fait un base32. En convertissant le cookie « resolution », on retrouve bien la même adresse ip que celle du validateur.

Un cookie resolution ; un validateur ayant comme valeur un dns ; et si on pouvait mettre notre propre service de résolution DNS en changeant l’adresse ip encodée en base32 du cookie, par un serveur à nous ?

Hop ! On y va, nous créons sur notre bon vieux bind, une zone dns avec une entrée pour validator.wargame.ndh qui pointe vers un serveur web, hébergé chez nous sur le port 8888, comme le validateur « officiel », puis on tente de s’enregistrer de nouveau sur le site du challenge.

Là on a un résultat, chaque refresh de page donne lieu à une requête HTTP GET sur notre machine et chaque demande d’enregistrement donne lieu à une requête POST contenant le login demandé.

Ahah, c’est là que ça devient moins drole, on a pu usurper l’identité du validateur, on peut mettre n’importe quel login, mais il doit répondre quoi notre validateur ?

Renvoyer la chaine « true » nous renvoie une 404 coté challenge, des fois pas, au bout de (très longues) minutes de guess, nous pensons à quelque chose de standard, un service, il répondrait avec quel format de nos jours ? Peut-être du JSON ? Et avec quoi comme données ? Peut-être un tableau avec les mêmes données que pour l’identification, à savoir un champ « name ».

Ok, cette fois-ci, plus aucun message d’erreur affiché, on controle le nom de la personne loguée grâce au validateur…

On fait quoi maintenant ? On tente de mettre un nouvel élément dans ce tableau du style admin = true ? Bingo !

Le flag était : ndh2k16_e5f3eb90c4438c1a062125e3f74c2b41

Pour la petite histoire, à la fin du wargame, le créateur de l’épreuve nous a avoué que le souci de résolution des dns n’était pas prévu. A la base nous aurions dû pouvoir communiquer directement avec le validateur afin de ne pas avoir à « deviner » le format de la requête à renvoyer, rahh, ça aurait fait une épreuve sans guess quand même 🙂