GitBook: [master] 2 pages and one asset modified

This commit is contained in:
CPol 2021-09-26 22:36:48 +00:00 committed by gitbook-bot
parent ab86549fc5
commit 89c0302c3c
No known key found for this signature in database
GPG key ID: 07D2180C7B12D0FF
3 changed files with 35 additions and 3 deletions

Binary file not shown.

After

Width:  |  Height:  |  Size: 29 KiB

View file

@ -9,7 +9,7 @@ Note that **`checksec`** might not find that a binary is protected by a canary i
However, you can manually notice this if you find that a value is saved in the stack at the begging of a function call and this value is checked before exiting. However, you can manually notice this if you find that a value is saved in the stack at the begging of a function call and this value is checked before exiting.
{% endhint %} {% endhint %}
## Canary ## Brute force Canary
The best way to bypass a simple canary is if the binary is a program **forking child processes every time you establish a new connection** with it \(network service\), because every time you connect to it **the same canary will be used**. The best way to bypass a simple canary is if the binary is a program **forking child processes every time you establish a new connection** with it \(network service\), because every time you connect to it **the same canary will be used**.
@ -104,6 +104,16 @@ canary = breakCanary()
log.info(f"The canary is: {canary}") log.info(f"The canary is: {canary}")
``` ```
## Print Canary
Another way to bypass the canary is to **print it**.
Imagine a situation where a **program vulnerable** to stack overflow can execute a **puts** function **pointing** to **part** of the **stack overflow**. The attacker knows that the **first byte of the canary is a null byte** \(`\x00`\) and the rest of the canary are **random** bytes. Then, the attacker may create an overflow that **overwrites the stack until just the first byte of the canary**.
Then, the attacker **calls the puts functionalit**y on the middle of the payload which will **print all the canary** \(except from the first null byte\).
With this info the attacker can **craft and send a new attack** knowing the canary \(in the same program session\)
Obviously, this tactic is very **restricted** as the attacker needs to be able to **print** the **content** of his **payload** to **exfiltrate** the **canary** and then be able to create a new payload \(in the **same program session**\) and **send** the **real buffer overflow**.
CTF example: [https://guyinatuxedo.github.io/08-bof\_dynamic/csawquals17\_svc/index.html](https://guyinatuxedo.github.io/08-bof_dynamic/csawquals17_svc/index.html)
## PIE ## PIE
In order to bypass the PIE you need to **leak some address**. And if the binary is not leaking any addresses the best to do it is to **brute-force the RBP and RIP saved in the stack** in the vulnerable function. In order to bypass the PIE you need to **leak some address**. And if the binary is not leaking any addresses the best to do it is to **brute-force the RBP and RIP saved in the stack** in the vulnerable function.
@ -141,5 +151,3 @@ In that example you can see that only **1 Byte and a half is needed** to locate
elf.address = RIP - (RIP & 0xfff) elf.address = RIP - (RIP & 0xfff)
``` ```

View file

@ -89,6 +89,20 @@ shellcode get 61 #Download shellcode number 61
pattern create 200 #Generate length 200 pattern pattern create 200 #Generate length 200 pattern
pattern search "avaaawaa" #Search for the offset of that substring pattern search "avaaawaa" #Search for the offset of that substring
pattern search $rsp #Search the offset given the content of $rsp pattern search $rsp #Search the offset given the content of $rsp
#Another way to get the offset of to the RIP
1- Put a bp after the function that overwrites the RIP and send a ppatern to ovwerwrite it
2- ef➤ i f
Stack level 0, frame at 0x7fffffffddd0:
rip = 0x400cd3; saved rip = 0x6261617762616176
called by frame at 0x7fffffffddd8
Arglist at 0x7fffffffdcf8, args:
Locals at 0x7fffffffdcf8, Previous frame's sp is 0x7fffffffddd0
Saved registers:
rbp at 0x7fffffffddc0, rip at 0x7fffffffddc8
gef➤ pattern search 0x6261617762616176
[+] Searching for '0x6261617762616176'
[+] Found at offset 184 (little-endian search) likely
``` ```
### Tricks ### Tricks
@ -121,6 +135,16 @@ gef➤ bt
`gdbserver --multi 0.0.0.0:23947` \(in IDA you have to fill the absolute path of the executable in the Linux machine and in the Windows machine\) `gdbserver --multi 0.0.0.0:23947` \(in IDA you have to fill the absolute path of the executable in the Linux machine and in the Windows machine\)
## Ghidra
### Find stack offset
**Ghidra** is very useful to find the the **offset** for a **buffer overflow thanks to the information about the position of the local variables.**
For example, in the example below, a buffer flow in `local_bc` indicates that you need an offset of `0xbc`. Moreover, if `local_10` is a canary cookie it indicates that to overwrite it from `local_bc` there is an offset of `0xac`.
_Remember that the first 0x08 from where the RIP is saved belongs to the RBP._
![](../../.gitbook/assets/image%20%28615%29.png)
## GCC ## GCC
**gcc -fno-stack-protector -D\_FORTIFY\_SOURCE=0 -z norelro -z execstack 1.2.c -o 1.2** --> Compile without protections **gcc -fno-stack-protector -D\_FORTIFY\_SOURCE=0 -z norelro -z execstack 1.2.c -o 1.2** --> Compile without protections