Sans protection (Exp. Binaires) - 404CTF 2022

Principe:
Exploiter un binaire classique en prenant la main sur l'EIP pour rediriger l'exécution vers la stack (NX disabled) et obtenir un shell pour lire le flag

Le challenge

Ce challenge s'appelle "Fragile" dans mes dossiers et "Sans protection" dans le CTF: j'ignore pourquoi. Peut-être avait-il changé de nom en cours de route?

Exploration

On regarde d'abord quelles protections sont en place sur ce binaire. En gros, aucune

C'est un bon réflexe à avoir quand on veut exploiter un binaire car ces quelques protections peuvent rapidement rendre compliquées un exploit (voire impossible) lorsqu'elles sont actives

Overflow

On note que le binaire nous donne ce qui ressemble à une addresse: je ne serai pas étonné que ce soit un leak à exploiter

Via *msfpattern_create*, on essaie un payload plus long, espérant écraser le *EIP*

Si on peut écraser l'EIP (ou RIP qui est son nom lorsqu'on est en 64 bits) alors on pourra rediriger l'exécution du programme vers une addresse mémoire de notre choix

Comme NX (No Execute) n'est pas actif, toute la mémoire du programme sera exécutable. Si on a une addresse dans la mémoire ou la stack vers un emplacement dont on contrôle le contenu (par exemple, l'addresse de ce qu'on a entré) alors on aura une RCE (Remote Code Execution)

On obtient un segfault avec une valeur d'*EIP* qu'on va chercher dans notre entrée

Cela nous permet de déterminer où, dans notre payload, se trouve les octets qui finiron dans l'EIP

Stack dynamique

Comme la stack n'est pas toujours à la même addresse (ASLR), il va falloir forger la valeur de l'EIP, probablement à partir de ce que le programme "leak" (*0x7ffd86baeb90*)

On se scriptera donc un payload dynamique basé sur l'addresse leakée, et sur un payload *msfvenom* (commande ls)

Exploitation

On teste en ligne avec un *cat flag.txt* et… fail!

La commande ls aussi avait fail, d'où l'idée de directement faire un cat

J'essaie d'autres commandes, et seule la première passe!

Je galère, je patauge, j'essaie d'autres variantes que *cat* pour voir si elles existent

Je m'étais dit "peut-etre que cat n'est pas sur le serveur? et qu'il faut utiliser un autre moyen de lire le flag, genre xxd?"

On notera que cat avait stoppé à la première commande, alors que base64 affiche bien superman et lexluthor. Le 4 qui apparait avec cat me laisse à penser que seul le 1er caractère du fichier flag est lu, j'ignore pourquoi

Wireshark (sorti de nulle part)

Je lance alors Wireshark, et je recommence l'exploit avec *cat* m'étant dit "peut-etre que l'affichage bug?" et paf! oui!

Cela m'a permis de me dire "le pipe réseau doit être coupé trop tôt par mon script… pourquoi?"

Et révélation! Mon script était buggé. Une fois corrigé, le flag tombe:
*404CTF{V0U5_3735_Pr37_P0Ur_14_Pr0CH41N3_M15510N}*

Je faisais un while (fgetc…), qui va renvoyer string "0" pour le second caractère du flag (404CTF{…}). Comme PHP fait des conversions de typage, le string "0" devient false, et donc, le while se stoppe!

⇇ 404CTF 2022