Differences
This shows you the differences between two versions of the page.
|
isc:labs:05 [2024/11/03 21:38] florin.stancu |
isc:labs:05 [2024/11/04 10:43] (current) florin.stancu |
||
|---|---|---|---|
| Line 1: | Line 1: | ||
| ====== Lab 05 - Application Security ====== | ====== Lab 05 - Application Security ====== | ||
| + | |||
| + | ===== Objectives ===== | ||
| + | |||
| + | * Call conventions & stack structure | ||
| + | * Buffer overflow vulnerabilities | ||
| + | * Using pwndbg & pwntools to facilitate exploit development | ||
| ===== Resources ===== | ===== Resources ===== | ||
| - | *[[https://dhavalkapil.com/blogs/Buffer-Overflow-Exploit/|Buffer overflow explained]] | + | * [[https://dhavalkapil.com/blogs/Buffer-Overflow-Exploit/|Buffer overflow explained]] |
| - | *[[https://dhavalkapil.com/blogs/Shellcode-Injection/|Shellcode explained]] | + | * [[https://dhavalkapil.com/blogs/Shellcode-Injection/|Shellcode explained]] |
| + | * [[https://chatgpt.com/share/67279837-b05c-800e-a60a-6629ef3dd7f7|ChatGPT's record for stack structure & buffer overflow]] //(same length, but why bother read the opinion of some anonymous industry expert when you got the popular AI kid parroting the same stuff, right?)// | ||
| ===== Setup ===== | ===== Setup ===== | ||
| - | * [[:isc:info:virtualmachine|Open a lab VM instance]] on [[https://cloud.grid.pub.ro|OpenStack]], use the **m1.medium** flavor for 2GB of RAM (required by ''pwndbg'' :(( ). | + | * [[:isc:info:virtualmachine|Open a lab VM instance]] on [[https://cloud.grid.pub.ro|OpenStack]], use the **m1.medium** flavor for 1.5GB of RAM (required by ''pwndbg'' :(( ). |
| **If you're not using the OpenStack VM**: | **If you're not using the OpenStack VM**: | ||
| Line 37: | Line 44: | ||
| {{:isc:labs:stack_layout.png?700}} | {{:isc:labs:stack_layout.png?700}} | ||
| + | |||
| + | Also check out one of the resources linked on top ^^ ! | ||
| <note tip> | <note tip> | ||
| Line 133: | Line 142: | ||
| * Use ''gdb'', ofc! | * Use ''gdb'', ofc! | ||
| * Trouble navigating through the runtime code? see the tutorials / cheatsheets above! | * Trouble navigating through the runtime code? see the tutorials / cheatsheets above! | ||
| + | |||
| + | <note tip> | ||
| + | To change a variable without typing info built-in (not compiled using ''-g''), take the variable's address, cast to pointer of desired type then dereference:<code> | ||
| + | set variable *(int *)&myvar = value | ||
| + | </code> | ||
| + | </note> | ||
| + | |||
| + | * Hint: you're on 64-bit, check the links above for the calling convention... | ||
| + | * Hint 2: you also don't have debugging info compiled-in, so you must use disassembly to find the RBP offset of the ''buf'' variable; | ||
| + | <spoiler In case of emergency, expand> | ||
| + | If this seems too difficult or you wasted too much time, just add ''-g'' to the ''gcc'' rule inside the Makefile, recompile and try it this way :( | ||
| + | </spoiler> | ||
| + | |||
| + | <solution -hidden> | ||
| + | <code> | ||
| + | # gdb obfusflag | ||
| + | gdb> break check_fl0gz0rx | ||
| + | gdb> run 12345678901234567890 | ||
| + | gdb> set var *(int*)&deez = 1 | ||
| + | gdb> tbreak *check_fl0gz0rx + 159 # before strcmp | ||
| + | gdb> continue | ||
| + | gdb> x/10s $rbp - 0x30 # find out buf's RBP offset from disass | ||
| + | </code> | ||
| + | </solution> | ||
| === [50p] 02. Stack overflow (EZ) === | === [50p] 02. Stack overflow (EZ) === | ||
| - | * Run & study the ''buffovf'' binary. There is a stack overflow vulnerability in there, can you see it? | + | * Run & study the ''buffovf'' binary. There is a vulnerability in there, can you see it? |
| * Yep, you **must** use stack overflow to get this flag! | * Yep, you **must** use stack overflow to get this flag! | ||
| * First, try to crash the program. Use programmatically generated input (e.g., from Python3); | * First, try to crash the program. Use programmatically generated input (e.g., from Python3); | ||
| Line 154: | Line 187: | ||
| * Things start to become easy; call the ''for_the_win'' function (simply replace the address above with the function's virtual address)! | * Things start to become easy; call the ''for_the_win'' function (simply replace the address above with the function's virtual address)! | ||
| * Do not forget: x86 uses little endian encoding for multi-byte integers! | * Do not forget: x86 uses little endian encoding for multi-byte integers! | ||
| - | * Another warning: ASLR is enabled and the program is compiled as position independent code! Use ''gdb'' to "leak" the function's address, which shouldn't change while using ''gdb'' (it uses the same constant seed for ASLR's randomizer)! | + | * As bonus, can you further chain calls to make the exploited program gracefully exit? |
| <solution -hidden> | <solution -hidden> | ||
| <code> | <code> | ||
| - | pwndbg> run "briliantul" < <(python3 -c 'import sys; sys.stdout.buffer.write(b"A" * 24 + b"\xa6\x91\x04\x08")') | + | pwndbg> run "Salam" < <(python3 -c 'import sys; sys.stdout.buffer.write(b"A" * 0x19 +b"\xb6\x91\x04\x08" + b"\x12\x93\x04\x08" + b"\xbe\xba\xfe\xca")') |
| - | ... | + | |
| - | hey, args | + | |
| - | what's ur last name? | + | |
| - | almost there, try to supply the correct arguments! | + | |
| - | bye | + | |
| - | + | ||
| - | Program received signal SIGSEGV, Segmentation fault. | + | |
| </code> | </code> | ||
| </solution> | </solution> | ||
| Line 181: | Line 207: | ||
| * For practice, you could also (trivially) implement the exploit for the previous task in ''pwntools''! | * For practice, you could also (trivially) implement the exploit for the previous task in ''pwntools''! | ||
| <note warning> | <note warning> | ||
| - | Beware of this behavior: if you overwrite just 1-2 extra bytes after the saved EIP, you will invalidate the ''get_user_info'' function's arguments, thus your program will crash earlier on one of those ''memcpy'' lines and won't get to return properly! Use the attached GDB and set breakpoints before these lines to debug (or just ''reverse-*'' your execution to discover the segfault reason ;) ). | + | Beware of this behavior: if you overwrite just 1-2 extra bytes after the saved EIP, you will invalidate the ''get_user_info'' function's arguments, thus your program will crash earlier on one of those ''memcpy'' lines and won't get to return properly! Use the attached GDB and set breakpoints before these lines to debug (or just ''reverse-*'' your execution to discover the crash reason ;) ). |
| </note> | </note> | ||
