Sans protection (Exp. Binaires) - 404CTF2022

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

Infos (cf menu latéral):
🚩 Flaggué! +977 points gagnés — 💾 Téléchargez les fichiers du challenge
404CTF{V0U5_3735_Pr37_P0Ur_14_Pr0CH41N3_M15510N}

Le challenge

Le challenge nous demande d'exploiter un binaire un peu mieux protégé

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

Encore une fois, je passe par EDB pour explorer le binaire, et j'essaie de voir si un overflow existe

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 prendra gaffe au endian!
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?"

Je tente également base64, quedale

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

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!

Flag: 404CTF{V0U5_3735_Pr37_P0Ur_14_Pr0CH41N3_M15510N}