Quel a été le dénouement de cette aventure ? Découvrez le tout de suite…

Étape 4

« Nous récupérons un fichier crypté et l’exécutable qui l’a vraisemblablement crypté. Après quelques recherches inutiles sur WannaCry, nous avons commencé à reverse l’exécutable sur Windows et l’avons reconstruit en C++ (après avoir réinstallé les outils, parce que nous n’étions vraiment pas prêts). Malheureusement, crypter un fichier via l’exécutable ou via notre outil n’a pas le même résultat.

Nous décidons donc d’installer GDB (et d’imprimer les cheat sheets), ce qui nous permet de tracer l’exécution. Cela n’est pas sans difficulté, particulièrement avant que nous découvrions l’existence de la commande layout regs, qui permet d’avoir un affichage texte graphique. Nous avons enregistré l’écran (avec Windows Games, un outil très professionnel) lors de l’exécution instruction par instruction, ce qui nous permet de suivre l’évolution des registres et les calculs effectués.

À partir de tout cela, nous réalisons que le rand (algorithme de génération de nombres pseudo-aléatoires) n’est pas le même que sur Windows. Même joueur joue encore. Après avoir installé C++ sur Windows, nous installons donc GCC sur Linux. À partir de là, connaissant toutes les variables (notamment nom du fichier et date de cryptage, récupérée grâce au format zip), nous pouvons reconstituer l’algorithme de cryptage, qui nous donne le même résultat que le binaire d’origine.

Victoire ?! Non.

Notre fichier de test fonctionne parfaitement, mais impossible de décrypter le flag. Plusieurs heures de travail et une nuit de sommeil plus tard, nous réalisons avec horreur une erreur de signe sur un des entiers. Le flag se décrypte. »

Étape 5

« Nous commençons cette étape avec une commande socat à lancer. Première action : une recherche Google sur socat, suivie d’un sudo apt install socat, et d’une exécution de la commande présente dans le fichier txt fourni, ce qui nous permet de nous connecter avec succès. Après avoir résolu cette étape intermédiaire du CTF, nous voilà au point de départ de l’étape 5.

Le shell très vexant nous indique en boucle « bag flag » tel une mauvaise chanson de l’été dès qu’on essaie de communiquer avec lui. Désormais convaincus que le shell ne parle pas français, nous décidons de lui envoyer des caractères spéciaux. Un single quote le fait planter et nous envoyer une callstack Python, qui nous fournit enfin des éléments de réponse quant au type de challenge.

Nous découvrons alors un eval, ce qui nous indique que tout ce que nous rentrons dans le prompt va être envoyé pour évaluation. Le jeu est alors de lui faire exécuter autre chose qu’un simple affichage. Nous écrivons donc une commande qui va clôturer la chaîne et en ouvrir une autre, capable de s’exécuter correctement et de nous donner plus d’information.

Une fois en capacité d’exécuter des commandes sur le serveur, nous faisons quelques tests pour voir ce à quoi nous pouvions accéder, et nous découvrons que le namespace os était importé. Nous sortons alors notre meilleur doc sur os et nous cherchons des idées. Une des idées consiste à récupérer les variables d’environnement.

Nous trouvons la variable d’environnement FLAG avec beaucoup de joie, très vite retombée car elle était vide. En poursuivant nos recherches, nous réalisons que nous pouvons tout simplement lire le code source afin de trouver comment le flag est initialisé. Et surtout, comment il est immédiatement vidé. Oups.

Après une recherche Google, nous découvrons qu’il est possible de récupérer ses propres variables d’environnement via /proc/self/environ, et cette fois, nous trouvons le flag ! »

Étape 6

« En regardant le code source de la page, nous apprenons qu’il faut nous rendre sur /secret. Nous essayons… La page nous indique qu’il faut que la requête provienne du serveur lui-même. Nous entrons donc l’IP locale /secret, et découvrons que la chaîne que nous passons est modifiée par le serveur (http:// au début, :80/ à la fin). Il faut donc escape cette partie, et nous le faisons en ajoutant ?a= pour lui faire ignorer le port 80. Trop facile, le serveur nous demande maintenant d’être authentifiés.

Le cookie demandé est présent dans la page principale, le jeu est donc de le faire passer dans la requête effectuée par le serveur lui-même. Le challenge nous rappelle rapidement une présentation vue sur l’exploitation des reverse proxys, et quelques recherches nous amènent à penser à une faille de type SSRF (Server-Side Request Forgery, un type d’exploit où un attaquant abuse des fonctionnalités du serveur pour lire ou modifier ses ressources internes). Nous nous documentons sur le sujet (notamment via A new era of SSRF par Orange Tsai).

En fournissant au serveur une URL externe, nous obtenons un message d’erreur indiquant qu’il n’arrive pas à se connecter. Nous déterminons donc (un peu trop rapidement et à tort) qu’il nous faudra rédiger l’exploit en aveugle. Nous installons Go en local pour essayer de reproduire avec un succès relatif, puisqu’il y a une différence entre le résultat de la requête sur le serveur et en local.

Le navigateur ayant tendance à modifier le texte rentré, nous avons développé un client TCP en C# pour pousser l’URL et garantir qu’elle ne sera pas modifiée. Nous craftons un certain nombre d’URL en 172 (basées sur l’IP local de la machine), aucune d’entre elle ne fonctionne pour diverses raisons (404, parsing incorrect…) et finissons par réaliser que l’hypothèse de départ est fausse, et que si nous ne pouvons pas lui fournir une URL, nous pouvons utiliser une adresse IP.

En remplaçant l’IP par celle d’un serveur de test sur lequel nous écoutons sur le port 80, nous obtenons la requête et voyons enfin d’où vient le problème : le serveur interprète notre espace comme faisant partie de l’URL. Nous ajoutons donc un ?a=1 après secret pour bloquer l’URL à cet endroit-là, puis un « X-DROP » pour bloquer le parsing de la fin de la requête initiale et nous obtenons ainsi le flag. »

Ce que nous avons appris

1.  Les outils préalablement tu installeras.

2. Les règles attentivement tu liras.

3. Une fois le flag trouvé, à la suite tu passeras.

4. « password » dans tout champ mot de passe tu essaieras.

5. Ton code soigneusement tu reliras.

5. Tes tests préliminaires tu confirmeras.

Notre résultat

Eh bien nous sommes qualifiés pour la deuxième phase ! 🎊

Cette dernière se déroulera le matin du 29 janvier pendant le FIC !

Bon courage à nos collègues qui devront tenir le stand en notre absence. 🤞

Toute l’équipe AntemetA est très fière de nos trois élus et de leur performance lors de cette première participation à un CTF.