Security Summer School

User Tools

Site Tools

session:09

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revision Previous revision
Next revision 		Previous revision
session:09 [2020/07/08 15:29]
Liza-Elena BABU (78556) 		session:09 [2020/07/19 12:49] (current)
Line 1: Line 1:
-= 0x08. Return Oriented Programming+====== 0x08. Return Oriented Programming ======
  
-== Resources+===== Resources =====
  
 [[https://security.cs.pub.ro/summer-school/res/slides/11-return-oriented-programming.pdf|Session 08 slides]] [[https://security.cs.pub.ro/summer-school/res/slides/11-return-oriented-programming.pdf|Session 08 slides]]
Line 10: Line 10:
  
  
-Make sure you reactivate ASLR before taking a look at this session. +=== PLT and GOT ===
- +
-If you disabled ASLR system-wide, re-enable it using (root access is required): +
- +
-<code bash> +
-~$ sudo bash -c 'echo 2 > /proc/sys/kernel/randomize_va_space' +
-</code> +
- +
-If you disabled ASLR at shell level, simply **close the shell** such as issuing the ''Ctrl+d'' keyboard shortcut. +
- +
-We can easily demonstrate the effects on shared libraries by running ''ldd'' multiple times in a row on a binary such as ''/bin/ls''. +
- +
-==== PLT and GOT+
  
 ASLR is not the only feature that prevents the compiler and the linker from solving some relocations before the binary is actually running. Shared libraries can also be combined in different ways, so the first time you actually know the address of a shared library is while the loader is running. The ASLR feature is orthogonal to this - the loader could choose to assign address to libraries in a round-robin fashion, or could use ASLR to assign them randomly. ASLR is not the only feature that prevents the compiler and the linker from solving some relocations before the binary is actually running. Shared libraries can also be combined in different ways, so the first time you actually know the address of a shared library is while the loader is running. The ASLR feature is orthogonal to this - the loader could choose to assign address to libraries in a round-robin fashion, or could use ASLR to assign them randomly.
Line 113: Line 101:
  
  
-=== Return Oriented Programming+==== Return Oriented Programming ====
  
 {{ :session:rop.png?nolink&600 |}} {{ :session:rop.png?nolink&600 |}}
  
-==== Motivation+=== Motivation ===
 In the previous sessions we discussed ''ret2libc'' attacks. The standard attack was to overwrite in the following way: In the previous sessions we discussed ''ret2libc'' attacks. The standard attack was to overwrite in the following way:
 <code> <code>
Line 144: Line 132:
 This kind of conflict can be resolved using Return Oriented Programming, a generalization of ''ret2libc'' attacks. This kind of conflict can be resolved using Return Oriented Programming, a generalization of ''ret2libc'' attacks.
  
-==== NOP analogy+=== NOP analogy ===
 While ''ret2libc'' uses functions directly, Return Oriented Programming uses a finer level of code execution: instruction groups. While ''ret2libc'' uses functions directly, Return Oriented Programming uses a finer level of code execution: instruction groups.
 Let's explore an example: Let's explore an example:
Line 217: Line 205:
  
  
-==== Gadgets & ROP chains+=== Gadgets & ROP chains ===
 Now that we have a sort of neutral primitive equivalent to a NOP let's actually do something useful. Now that we have a sort of neutral primitive equivalent to a NOP let's actually do something useful.
 The building blocks of ROP payloads are called gadgets. These are blocks of instructions that end with a 'ret' instruction. The building blocks of ROP payloads are called gadgets. These are blocks of instructions that end with a 'ret' instruction.
Line 319: Line 307:
  
  
-=== Some useful ninja tricks+==== Some useful ninja tricks ====
  
-==== Memory spraying+=== Memory spraying ===
 Let's take the following prog: Let's take the following prog:
 <code c> <code c>
Line 426: Line 414:
  
  
-==== Vulnerable function identification+=== Vulnerable function identification ===
 As you can see from above, the base pointer gets trashed so backtracing is not possible As you can see from above, the base pointer gets trashed so backtracing is not possible
 <code bash> <code bash>
Line 496: Line 484:
  
  
-==== ROP payload debugging+=== ROP payload debugging ===
 When you know what the offending function is, disassemble it and break on "ret" When you know what the offending function is, disassemble it and break on "ret"
 <code bash> <code bash>
Line 561: Line 549:
  
  
-==== checksec in peda+=== checksec in peda ===
 <code bash> <code bash>
 gdb-peda$ checksec gdb-peda$ checksec
Line 572: Line 560:
  
  
-==== gadget finding in peda+=== gadget finding in peda ===
 Apart from **objdump** which only finds aligned instructions, you can also use **dumprop** in peda to find all gadgets in a memory region or mapping: Apart from **objdump** which only finds aligned instructions, you can also use **dumprop** in peda to find all gadgets in a memory region or mapping:
 <code bash> <code bash>
Line 621: Line 609:
 </code> </code>
  
-==== Anti-anti-debugging and others+=== Anti-anti-debugging and others ===
 There can be various annoyances in binaries: **ptrace** calls for anti-debugging, **sleep** calls to prevent bruteforcing or **fork** calls to use child processes to serve requests. There can be various annoyances in binaries: **ptrace** calls for anti-debugging, **sleep** calls to prevent bruteforcing or **fork** calls to use child processes to serve requests.
 These can all be deactivated using **unptrace** (for ptrace) and **deactive** in peda. These can all be deactivated using **unptrace** (for ptrace) and **deactive** in peda.
  
  
-== Challenges+===== Challenges =====
  
-=== 00. Tutorial - Bypass NX Stack with return-to-libc+==== 00. Tutorial - Bypass NX Stack with return-to-libc ====
  
 Go to the ''01-tutorial-ret-to-libc/'' folder in the [[https://security.cs.pub.ro/summer-school/res/arc/09-defense-mechanisms-skel.zip|activities archive]]. Go to the ''01-tutorial-ret-to-libc/'' folder in the [[https://security.cs.pub.ro/summer-school/res/arc/09-defense-mechanisms-skel.zip|activities archive]].
Line 715: Line 703:
  
  
-=== 01. Challenge - ret-to-libc+==== 01. Challenge - ret-to-libc ====
  
 Looks good! Let's get serious and do something useful with this. Looks good! Let's get serious and do something useful with this.
Line 738: Line 726:
 </note> </note>
  
-=== 02. Challenge - no-ret-control+==== 02. Challenge - no-ret-control ====
  
 Go to the ''02-challenge-no-ret-control/'' folder in the [[https://security.cs.pub.ro/summer-school/res/arc/09-defense-mechanisms-skel.zip|activities archive]]. Go to the ''02-challenge-no-ret-control/'' folder in the [[https://security.cs.pub.ro/summer-school/res/arc/09-defense-mechanisms-skel.zip|activities archive]].
Line 746: Line 734:
 Alter the execution of ''force_exit'', in order to call the secret function. Alter the execution of ''force_exit'', in order to call the secret function.
  
-=== 03. Challenge - ret-to-plt+==== 03. Challenge - ret-to-plt ====
  
 Go to the ''03-challenge-ret-to-plt/'' folder in the [[https://security.cs.pub.ro/summer-school/res/arc/09-defense-mechanisms-skel.zip|activities archive]]. Go to the ''03-challenge-ret-to-plt/'' folder in the [[https://security.cs.pub.ro/summer-school/res/arc/09-defense-mechanisms-skel.zip|activities archive]].
Line 804: Line 792:
  
  
-=== 04. Challenge - Gadget tutorial+==== 04. Challenge - Gadget tutorial ====
  
 This task requires you to construct a payload using gadgets and calling the functions inside such that it will print This task requires you to construct a payload using gadgets and calling the functions inside such that it will print
Line 816: Line 804:
 stage B!stage A! stage B!stage A!
 </code> </code>
-=== Bonus Challenge - Echo service+==== Bonus Challenge - Echo service ====
 This task is a network service that can be exploited. Run it locally and try to exploit it. You'll find that if you call system("/bin/sh") the shell is opened in the terminal where the server was started instead of the one where the attack takes place. This happens because the client-server communication takes place over a socket. When you spawn a shell it will inherit the Standard I/O descriptors from the parent and use those. To fix this you need to redirect the socket fd into 0,1 (and optionally 2). This task is a network service that can be exploited. Run it locally and try to exploit it. You'll find that if you call system("/bin/sh") the shell is opened in the terminal where the server was started instead of the one where the attack takes place. This happens because the client-server communication takes place over a socket. When you spawn a shell it will inherit the Standard I/O descriptors from the parent and use those. To fix this you need to redirect the socket fd into 0,1 (and optionally 2).
  
session/09.1594211364.txt.gz · Last modified: 2020/07/08 15:29 by Liza-Elena BABU (78556)

Page Tools

Except where otherwise noted, content on this wiki is licensed under the following license: CC Attribution-Share Alike 4.0 International
CC Attribution-Share Alike 4.0 International Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki