mirror of
https://github.com/cyber-defence-campus/netgear_r6700v3_circled
synced 2026-08-09 12:29:06 +00:00
Update section Exploit Strategy
This commit is contained in:
Damian Pfammatter
+49
-21
@@ -8,7 +8,10 @@
|
||||
6. [Exploitation](./6_exploitation.md#exploitation)
|
||||
1. [Analysis Module morion_control_hijacker](./6_exploitation.md#analysis-module-morion_control_hijacker)
|
||||
1. [Vulnerability Characteristics](./6_exploitation.md#vulnerability-characteristics)
|
||||
2. [Return Oriented Programming (ROP)](./6_exploitation.md#return-oriented-programming-rop)
|
||||
2. [Exploit Strategy](./6_exploitation.md#exploit-strategy)
|
||||
1. [Non-Executable (NX) Stack](./6_exploitation.md#non-executable-nx-stack)
|
||||
2. [Position-Independent Executable (PIE)](./6_exploitation.md#position-independent-executable-pie)
|
||||
3. [Address Space Layout Randomization (ASLR)](./6_exploitation.md#address-space-layout-randomization-aslr)
|
||||
3. [Payload Generation](./6_exploitation.md#payload-generation)
|
||||
2. [Analysis Module morion_rop_generator](./6_exploitation.md#analysis-module-morion_rop_generator)
|
||||
<!--TODO--------------------------------------------------------------------------------------------
|
||||
@@ -151,20 +154,11 @@ function `1) fgets`, as shown in Figure [5.4](./5_vulnerability.md#memory-layout
|
||||
|
||||
At this point, we learned that registers *r4*-*r11*, as well as the *pc* are based on symbolic
|
||||
variables that an attacker might control. We verified that we can modify the *pc* to point to another value. Further we got an intuition about the memory layout relevant for our exploit.
|
||||
### Return Oriented Programming (ROP)
|
||||
- design a simple ROP chain (crashing the binary)
|
||||
- why ROP chaining? data execution prevention, partly ASLR
|
||||
- defeat ASLR
|
||||
- binary restarts after a crash
|
||||
<hr>
|
||||
<figure>
|
||||
<img src="../images/ROP_Chain.svg" alt="ROP Chain"/>
|
||||
<figcaption>
|
||||
Figure 6.1: ROP Chain - Showing ...
|
||||
</figcaption>
|
||||
</figure>
|
||||
<hr>
|
||||
|
||||
### Exploit Strategy
|
||||
With the intention to develop an exploit strategy, let's now inspect some **security properties** of
|
||||
binary `circled`. For instance, we can do this by using the open-source tool
|
||||
[checksec](https://github.com/slimm609/checksec.sh) (here out of tool
|
||||
[pwndbg](https://github.com/pwndbg/pwndbg)):
|
||||
```
|
||||
pwndbg> checksec
|
||||
[*] '/tmp/tmpijt0kv4v/tmpsf82yc22'
|
||||
@@ -174,16 +168,50 @@ pwndbg> checksec
|
||||
NX: NX enabled
|
||||
PIE: No PIE (0x8000)
|
||||
```
|
||||
#### Non-Executable (NX) Stack
|
||||
Most importantly for us, we see that the binary has a **non-executable (NX)** stack. For our exploit
|
||||
strategy, this means that we cannot just write instructions to the stack and redirect execution to
|
||||
them. Instead, we will use a typical strategy to defeat NX memory, namely, by using a technique
|
||||
commonly referred to as **Return Oriented Programming (ROP)**. In ROP, one executes carefully chosen
|
||||
instruction sequences (so called **gadgets**) that are already present in the binary's memory.
|
||||
|
||||
- We cannot write instructions to the stack and redirect execution to them, since our target binary
|
||||
has a non-executable (NX) stack.
|
||||
- Non-executable stacks are typically targeted with Return Oriented Programming (ROP), where one
|
||||
chains multiple ROP gadgets...
|
||||
- Gadget that allows us to call `system` with a controlled parameter
|
||||
In our exploit, we will use a very simple ROP chain that calls *libc* function `system` with a
|
||||
controlled argument (command string). The corresponding chain is depicted in Figure 6.1 below:
|
||||
<hr>
|
||||
<figure>
|
||||
<img src="../images/ROP_Chain.svg" alt="ROP Chain"/>
|
||||
<figcaption>
|
||||
Figure 6.1: ROP Chain - Simple ROP chain, calling the function system@libc with a controlled
|
||||
argument.
|
||||
</figcaption>
|
||||
</figure>
|
||||
<hr>
|
||||
|
||||
Gadget 0 corresponds to the `pop` instruction at address `0xcf24` that we investigated above in
|
||||
section
|
||||
[Exploitation: Vulnerability Characteristics](./6_exploitation.md#vulnerability-characteristics). We
|
||||
have already seen that, due to the `pop` instruction, the *pc* receives a value we control. We will
|
||||
try making the *pc* become the value `0xc9b8`, which corresponds to the address of gadget 1. As gadget 1, we choose one that consists of the following two instructions:
|
||||
- `mov r0, r6`: Move the value of register *r6* (that is based on a symbolic variable) to register
|
||||
*r0*.
|
||||
- `bl #0x94a0 <system@plt>`: Call function `system` from *libc*, using register *r0* as argument
|
||||
(synopsis: `int system(const char *command)`).
|
||||
|
||||
**Note**: Several (open-source) tools exist that help finding suitable ROP gadgets in
|
||||
your targets. One such tool for instance is [ropper](https://github.com/sashs/Ropper).
|
||||
|
||||
- Mention that it will crash the binary, the binary however restarts after a crash, so no big deal
|
||||
- The mentioned chain works and is easy to explain Morion's features
|
||||
|
||||
#### Position-Independent Executable (PIE)
|
||||
- Due to no PIE, gadget 1 is at a fixed known address (`0xc9b8`)
|
||||
#### Address Space Layout Randomization (ASLR)
|
||||
|
||||
- defeat ASLR
|
||||
- binary restarts after a crash
|
||||
- We have partial/conservative ASLR
|
||||
1 - Conservative Randomization: Shared libraries, **stack**, mmap(), VDSO and heap are randomized
|
||||
- As the process restarts after crashing, we have almost unlimited tries to find the correct address
|
||||
- Due to no PIE, gadget 1 is at a known address
|
||||
- (Characters we might not use: null-bytes, space, carriage return)
|
||||
|
||||
### Payload Generation
|
||||
|
||||
Reference in New Issue
Block a user