Dobin 0x52_DefeatExploitMitigations.pdf
Dobin 0x52_DefeatExploitMitigations.pdf
Dobin 0x52_DefeatExploitMitigations.pdf
Set of flashcards Details
| Flashcards | 21 |
|---|---|
| Language | English |
| Category | Religion/Ethics |
| Level | University |
| Created / Updated | 24.06.2019 / 24.06.2019 |
| Weblink |
https://card2brain.ch/box/20190624_dobin_0x52defeatexploitmitigations_pdf
|
| Embed |
<iframe src="https://card2brain.ch/box/20190624_dobin_0x52defeatexploitmitigations_pdf/embed" width="780" height="150" scrolling="no" frameborder="0"></iframe>
|
How can you defete the stack canary with arbitrary write?
With a string format like:
- userData = "AAAA%204x%n";
204 bytes are skiped.
When we have an arbitrary write we can write behind the stack canary.
How can we prevent arbitrary write?
Wrong:
- printf(userData);
Correct:
- printf("%s", userData)
What causes the arbitrary write vulnerability and why is this not a problem nowerdays?
Example: Formatstring attacks
- Problem:
- Did not specify format in source
- Problem: %n writrs data
- Nowadays:
- Easy to detect on compile time (static analysis)
- Easy to completly fix (rmeove %n)
- Nowadays: Net a problem anymore, solved
What does the stack cannary protect, does it protect from overwriting local variables?
The stack canary protects metadata fo the stack (SBP [Stored Base Pointer], SIP [Stored Instruction Pointer])
It does NOT protect Local variables.
Is the heap protected by the Stack Canary, and name some Heap Bug classes.
The heap is not protected by the Stack Canary.
Heap bug classes:
- Inter-chunk heap overflow/corruption
- Use after free
- Intra-chunk heap overflow / relative write
- Type confusion
How can you brute force the stack canary?
A network server fork()'s on connect()
- If child crashes, next connection gets an "identical" child with the same stack canary.
Stack canary stay's the same.
This allows us to iteratively bruteforce the stack cannary, by only partially overwriting it an testing.
A stack canary has 32 bites = 4 billion possibilites, how many posibilities are there if we brute force it iteratively?
4 * 2^8 = 1024 possibilities
This means an avarege of 512 tries (crashes)
Why do you need to brute force the SBP (Stored Base Pointer) first, before you can brute force the stack canary?
Need to break SBP (Stored Base Pointer) first...
Defeat ASLR (Address Space Layout Randomization) for free, because brute force SBP
- SBP points into stack segment
- ASLR is minimum on per-page level, lower 4096 bytes stay the same
DEP (Data Execution Prevention) makes stack, heap and libraries non-executable, what can still be executed?
Existing code can still be executed.
- Existing LIBC Functions (ret2plt)
- Existing Code (ROP)
How does Ret2plt work?
- "call system" is actuallu "call system@plt"
- The PLT resolves system@libc at runtime
- The PLT stores system@libc in system@got
How can we use Ret2plt in order to execute arbitrary code and why does it defeat DEP (Data Execution Prevention)?
Ret2plt
- LIBC interface is stored at a static location
- Can jump to system() at known location to execute arbitrary code
- No need for shellcode on stack or heap.
What is ROP?
ROP (Return Oriented Programming)
- Extension of "return to libc"
- "Borrowed Code Junks"
- Code from binary, followed by RET
- Called "gadgets"
ROP is possible because
- Code section is not randomized
- This allows us to smartly re-use existing code.
What are the two techniques to defeat ASLR?
- Partial function pointer overwrite
- Using NOP sleds and Heap spray
What is a partial function overwrite?
Function pointers are stored in little endian format.
That means if we overwrite only parts of the function pointer we will overwrite only the least segnificant bits.
Even when ASLR (Address Space Layout Randomization) is done the offset between two functions will be the same every time. This allows us to change the function pointer to point to another function without knowing where in memory the function is. This is because the most segnificant bits stay the same. This means a small change in the function pointer will most likely cause it to point to another function.
How can you defeat ASLR using a NOP sled and a heap spray?
The heap is sprayed with NOP sleds with our shell code at the end
|NOP||NOP|NOP|NOP|NOP|NOP|NOP|NOP|...|CODE|
This is to increase the chance of when we jump from the code segment to the heap to execute code that the probability of hitting a NOP sled and thus executing our shell code is high.
Since ASLR randomizes the location where the heap, we can not controll exactly to where in the heap we jump. But by doing a heap spray, we increase the chances of actualy hitting a NOP sled.
What are the 3 default exploit mitigations?
- Stack Canary (crash on overflow)
- ASLR (make memory location unpredictable)
- DEP (make writeable memory non-executable)
What exploit techniques can be used to bypass:
- Stack Protector (Stack Canary)
- No-Exec Stack DEP (Data Execution Prevention)
- ASLR (Address Space Layout Randomization) / PIE
Stack Protector (Stack Canary)
- Arbitrary write (non overflow)
- Byte-wise stack protector brute force
- Heap vulnerability
No Exec Stack (DEP)
- Return to LIBC / PLT
- ROP
ASLR / PIE
- Brute Force
- ROP
- Information Disclosure
- Pointer re-use
- Spray & Pray
What are the key characteristics of RET 2 PLT and ROP?
RET 2 PLT
- Jump to static address which executes system(), with bash-shell shellcode
- Circumvent DEP
- Fix: PIE
ROP:
- Return Oriented Programming
- Take gadgets from binary
- Gadget are little code sequences, followed with a RET
- Fix: PIE
- Super fix: CFI
What is information disclosure?
Information Disclosure:
- The death of anti-exploiting techniques
- Get content past a buffer -> get SIP (Saved Instruction Pointer) or stack pointer
- Relocation happens en-block, so just calculate base address and offset for ret2plt or ROP
Why is partial overwrite usefull against ASLR (Address Space Layout Randomization)
Because of Little Endianness, we can overwrite LSB (least segnificant bit) of function pointers to point to other stuff (not affected by ASLR because in same segment)
Name 2 Heap attacks.
- Use after free
- Double Free
- etc ...
