mirror of
https://github.com/carlospolop/hacktricks
synced 2024-11-24 21:53:54 +00:00
GITBOOK-4302: No subject
This commit is contained in:
CPol
gitbook-bot
parent
c55d66804a
commit
7bff273b23
46 changed files with 241 additions and 127 deletions
|
|
@ -134,7 +134,7 @@ In addition to the above WebSec is also a **committed supporter of HackTricks.**
|
|||
|
||||
## License & Disclaimer
|
||||
|
||||
**Check them in:**
|
||||
Check them in:
|
||||
|
||||
{% content-ref url="welcome/hacktricks-values-and-faq.md" %}
|
||||
[hacktricks-values-and-faq.md](welcome/hacktricks-values-and-faq.md)
|
||||
|
|
|
|||
|
|
@ -697,13 +697,14 @@
|
|||
* [ROP - Return Oriented Programing](binary-exploitation/rop-return-oriented-programing/README.md)
|
||||
* [Ret2csu](binary-exploitation/rop-return-oriented-programing/ret2csu.md)
|
||||
* [Ret2dlresolve](binary-exploitation/rop-return-oriented-programing/ret2dlresolve.md)
|
||||
* [Ret2esp / Ret2reg](binary-exploitation/rop-return-oriented-programing/ret2esp-ret2reg/README.md)
|
||||
* [SROP - Sigreturn-Oriented Programming](binary-exploitation/rop-return-oriented-programing/ret2esp-ret2reg/srop-sigreturn-oriented-programming.md)
|
||||
* [Ret2esp / Ret2reg](binary-exploitation/rop-return-oriented-programing/ret2esp-ret2reg.md)
|
||||
* [Ret2lib](binary-exploitation/rop-return-oriented-programing/ret2lib/README.md)
|
||||
* [Leaking libc address with ROP](binary-exploitation/rop-return-oriented-programing/ret2lib/rop-leaking-libc-address/README.md)
|
||||
* [Leaking libc - template](binary-exploitation/rop-return-oriented-programing/ret2lib/rop-leaking-libc-address/rop-leaking-libc-template.md)
|
||||
* [One Gadget](binary-exploitation/rop-return-oriented-programing/ret2lib/one-gadget.md)
|
||||
* [Ret2syscall](binary-exploitation/rop-return-oriented-programing/rop-syscall-execv.md)
|
||||
* [Ret2vDSO](binary-exploitation/rop-return-oriented-programing/ret2vdso.md)
|
||||
* [SROP - Sigreturn-Oriented Programming](binary-exploitation/rop-return-oriented-programing/srop-sigreturn-oriented-programming.md)
|
||||
* [Array Indexing](binary-exploitation/array-indexing.md)
|
||||
* [Integer Overflow](binary-exploitation/integer-overflow.md)
|
||||
* [Format Strings](binary-exploitation/format-strings/README.md)
|
||||
|
|
|
|||
|
|
@ -26,9 +26,14 @@ More info about One Gadget in:
|
|||
[one-gadget.md](../rop-return-oriented-programing/ret2lib/one-gadget.md)
|
||||
{% endcontent-ref %}
|
||||
|
||||
{% hint style="warning" %}
|
||||
Note that hooks are **disabled for GLIBC >= 2.34**. There are other techniques that can be used on modern GLIBC versions. See: [https://github.com/nobodyisnobody/docs/blob/main/code.execution.on.last.libc/README.md](https://github.com/nobodyisnobody/docs/blob/main/code.execution.on.last.libc/README.md).
|
||||
{% endhint %}
|
||||
|
||||
## References
|
||||
|
||||
* [https://ir0nstone.gitbook.io/notes/types/stack/one-gadgets-and-malloc-hook](https://ir0nstone.gitbook.io/notes/types/stack/one-gadgets-and-malloc-hook)
|
||||
* [https://github.com/nobodyisnobody/docs/blob/main/code.execution.on.last.libc/README.md](https://github.com/nobodyisnobody/docs/blob/main/code.execution.on.last.libc/README.md).
|
||||
|
||||
<details>
|
||||
|
||||
|
|
|
|||
|
|
@ -24,7 +24,7 @@ Each entry in the GOT corresponds to a symbol in the external libraries that the
|
|||
|
||||
### **PLT: Procedure Linkage Table**
|
||||
|
||||
The **Procedure Linkage Table (PLT)** works closely with the GOT and serves as a trampoline to handle calls to external functions. When a binary **calls an external function for the first time, control is passed to an entry in the PLT associated with that function**. This PLT entry is responsible for invoking the dynamic linker to resolve the function's address if it has not already been resolved. After the address is resolved, it is stored in the GOT.
|
||||
The **Procedure Linkage Table (PLT)** works closely with the GOT and serves as a trampoline to handle calls to external functions. When a binary **calls an external function for the first time, control is passed to an entry in the PLT associated with that function**. This PLT entry is responsible for invoking the dynamic linker to resolve the function's address if it has not already been resolved. After the address is resolved, it is stored in the **GOT**.
|
||||
|
||||
**Therefore,** GOT entries are used directly once the address of an external function or variable is resolved. **PLT entries are used to facilitate the initial resolution** of these addresses via the dynamic linker.
|
||||
|
||||
|
|
@ -62,7 +62,7 @@ You can see the PLT addresses with **`objdump -j .plt -d ./vuln_binary`**
|
|||
|
||||
## **Protections**
|
||||
|
||||
The **FullRELRO** protection is meant to protect agains this kind of technique by resolving all the addresses of the functions when the binary is started and making the **GOT table read only** after it:
|
||||
The **Full RELRO** protection is meant to protect agains this kind of technique by resolving all the addresses of the functions when the binary is started and making the **GOT table read only** after it:
|
||||
|
||||
{% content-ref url="../common-binary-protections-and-bypasses/relro.md" %}
|
||||
[relro.md](../common-binary-protections-and-bypasses/relro.md)
|
||||
|
|
|
|||
|
|
@ -17,7 +17,7 @@ Other ways to support HackTricks:
|
|||
## .dtors
|
||||
|
||||
{% hint style="danger" %}
|
||||
Nowadays is very **weird to find a binary with a .dtors section**.
|
||||
Nowadays is very **weird to find a binary with a .dtors section!**
|
||||
{% endhint %}
|
||||
|
||||
The destructors are functions that are **executed before program finishes** (after the `main` function returns).\
|
||||
|
|
@ -64,7 +64,7 @@ In order to abuse **`.fini_array`** to get an eternal loop you can [**check what
|
|||
* This will make **`__libc_csu_fini`** call himself again executing the **`.fini_array`** functions again which will call the vulnerable WWW function 2 times: one for **arbitrary write** and another one to overwrite again the **return address of `__libc_csu_fini`** on the stack to call itself again.
|
||||
|
||||
{% hint style="danger" %}
|
||||
Note that with [**Full Relro**](../common-binary-protections-and-bypasses/relro.md)**,** the section **`.fini_array`** is made **read-only**.
|
||||
Note that with [**Full RELRO**](../common-binary-protections-and-bypasses/relro.md)**,** the section **`.fini_array`** is made **read-only**.
|
||||
{% endhint %}
|
||||
|
||||
<details>
|
||||
|
|
|
|||
|
|
@ -17,7 +17,7 @@ Other ways to support HackTricks:
|
|||
## **\_\_atexit Structures**
|
||||
|
||||
{% hint style="danger" %}
|
||||
Nowadays is very **weird to exploit this**.
|
||||
Nowadays is very **weird to exploit this!**
|
||||
{% endhint %}
|
||||
|
||||
**`atexit()`** is a function to which **other functions are passed as parameters.** These **functions** will be **executed** when executing an **`exit()`** or the **return** of the **main**.\
|
||||
|
|
|
|||
|
|
@ -18,7 +18,7 @@ Other ways to support HackTricks:
|
|||
|
||||
This category includes all vulnerabilities that occur because it is possible to overwrite certain data through errors in the handling of indexes in arrays. It's a very wide category with no specific methodology as the exploitation mechanism relays completely on the conditions of the vulnerability.
|
||||
|
||||
However he you can find some nice examples:
|
||||
However he you can find some nice **examples**:
|
||||
|
||||
* [https://guyinatuxedo.github.io/11-index/swampctf19\_dreamheaps/index.html](https://guyinatuxedo.github.io/11-index/swampctf19\_dreamheaps/index.html)
|
||||
* There are **2 colliding arrays**, one for **addresses** where data is stored and one with the **sizes** of that data. It's possible to overwrite one from the other, enabling to write an arbitrary address indicating it as a size. This allows to write the address of the `free` function in the GOT table and then overwrite it with the address to `system`, and call free from a memory with `/bin/sh`.
|
||||
|
|
|
|||
|
|
@ -16,7 +16,7 @@ Other ways to support HackTricks:
|
|||
|
||||
## ELF Basic Info
|
||||
|
||||
Before start exploiting anything it's interesting to understand part of the structure of an ELF binary:
|
||||
Before start exploiting anything it's interesting to understand part of the structure of an **ELF binary**:
|
||||
|
||||
{% content-ref url="elf-tricks.md" %}
|
||||
[elf-tricks.md](elf-tricks.md)
|
||||
|
|
@ -69,8 +69,8 @@ Something to take into account is that usually **just one exploitation of a vuln
|
|||
* In a bof with [**canary**](../common-binary-protections-and-bypasses/stack-canaries/), you will need to bypass it
|
||||
* If you need to set several parameter to correctly call the **ret2win** function you can use:
|
||||
* A [**ROP**](./#rop-and-ret2...-techniques) **chain if there are enough gadgets** to prepare all the params
|
||||
* [**SROP**](../rop-return-oriented-programing/ret2esp-ret2reg/srop-sigreturn-oriented-programming.md) (in case you can call this syscall) to control a lot of registers
|
||||
* Gadgets from [**ret2csu**](../rop-return-oriented-programing/ret2csu.md) to control several registers
|
||||
* [**SROP**](../rop-return-oriented-programing/srop-sigreturn-oriented-programming.md) (in case you can call this syscall) to control a lot of registers
|
||||
* Gadgets from [**ret2csu**](../rop-return-oriented-programing/ret2csu.md) and [**ret2vdso**](../rop-return-oriented-programing/ret2vdso.md) to control several registers
|
||||
* Via a [**Write What Where**](../arbitrary-write-2-exec/) you could abuse other vulns (not bof) to call the **`win`** function.
|
||||
* [**Pointers Redirecting**](../stack-overflow/pointer-redirecting.md): In case the stack contains pointers to a function that is going to be called or to a string that is going to be used by an interesting function (system or printf), it's possible to overwrite that address.
|
||||
* [**ASLR**](../common-binary-protections-and-bypasses/aslr/) or [**PIE**](../common-binary-protections-and-bypasses/pie/) might affect the addresses.
|
||||
|
|
@ -83,7 +83,7 @@ Something to take into account is that usually **just one exploitation of a vuln
|
|||
* [**(Stack) Shellcode**](./#stack-shellcode): This is useful to store a shellcode in the stack before of after overwriting the return pointer and then **jump to it** to execute it:
|
||||
* **In any case, if there is a** [**canary**](../common-binary-protections-and-bypasses/stack-canaries/)**,** in a regular bof you will need to bypass (leak) it
|
||||
* **Without** [**ASLR**](../common-binary-protections-and-bypasses/aslr/) **and** [**nx**](../common-binary-protections-and-bypasses/no-exec-nx.md) it's possible to jump to the address of the stack as it won't never change
|
||||
* **With** [**ASLR**](../common-binary-protections-and-bypasses/aslr/) you will need techniques such as [**ret2esp/ret2reg**](../rop-return-oriented-programing/ret2esp-ret2reg/) to jump to it
|
||||
* **With** [**ASLR**](../common-binary-protections-and-bypasses/aslr/) you will need techniques such as [**ret2esp/ret2reg**](../rop-return-oriented-programing/ret2esp-ret2reg.md) to jump to it
|
||||
* **With** [**nx**](../common-binary-protections-and-bypasses/no-exec-nx.md), you will need to use some [**ROP**](../rop-return-oriented-programing/) **to call `memprotect`** and make some page `rwx`, in order to then **store the shellcode in there** (calling read for example) and then jump there.
|
||||
* This will mix shellcode with a ROP chain.
|
||||
|
||||
|
|
@ -91,7 +91,8 @@ Something to take into account is that usually **just one exploitation of a vuln
|
|||
|
||||
* [**Ret2syscall**](../rop-return-oriented-programing/rop-syscall-execv.md): Useful to call `execve` to run arbitrary commands. You need to be able to find the **gadgets to call the specific syscall with the parameters**.
|
||||
* If [**ASLR**](../common-binary-protections-and-bypasses/aslr/) or [**PIE**](../common-binary-protections-and-bypasses/pie/) are enabled you'll need to defeat them **in order to use ROP gadgets** from the binary or libraries.
|
||||
* [**SROP**](../rop-return-oriented-programing/ret2esp-ret2reg/srop-sigreturn-oriented-programming.md) can be useful to prepare the **ret2execve**
|
||||
* [**SROP**](../rop-return-oriented-programing/srop-sigreturn-oriented-programming.md) can be useful to prepare the **ret2execve**
|
||||
* Gadgets from [**ret2csu**](../rop-return-oriented-programing/ret2csu.md) and [**ret2vdso**](../rop-return-oriented-programing/ret2vdso.md) to control several registers
|
||||
|
||||
#### Via libc
|
||||
|
||||
|
|
|
|||
|
|
@ -1,4 +1,4 @@
|
|||
# ELF Tricks
|
||||
# ELF Basic Information
|
||||
|
||||
<details>
|
||||
|
||||
|
|
@ -14,7 +14,7 @@
|
|||
|
||||
## Program Headers
|
||||
|
||||
The describe to the loader how to load the ELF into memory:
|
||||
The describe to the loader how to load the **ELF** into memory:
|
||||
|
||||
```bash
|
||||
readelf -lW lnstat
|
||||
|
|
@ -367,7 +367,7 @@ int main() {
|
|||
}
|
||||
```
|
||||
|
||||
Note that these global variables are located in `.data` or `.bss` but in the lists `__CTOR_LIST__` and `__DTOR_LIST__` the objects to initialize and destruct are stored in order to keep track of them.
|
||||
Note that these global variables are located in `.data` or `.bss` but in the lists `__CTOR_LIST__` and `__DTOR_LIST__` the objects to initialize and destruct are stored in order to keep track of them.
|
||||
|
||||
From C code it's possible to obtain the same result using the GNU extensions :
|
||||
|
||||
|
|
|
|||
|
|
@ -227,7 +227,7 @@ _Remember that the first 0x08 from where the RIP is saved belongs to the RBP._
|
|||
|
||||
### Debugging in remote linux
|
||||
|
||||
Inside the IDA folder you can find binaries that can be used to debug a binary inside a linux. To do so move the binary _linux\_server_ or _linux\_server64_ inside the linux server and run it nside the folder that contains the binary:
|
||||
Inside the IDA folder you can find binaries that can be used to debug a binary inside a linux. To do so move the binary `linux_server` or `linux_server64` inside the linux server and run it nside the folder that contains the binary:
|
||||
|
||||
```
|
||||
./linux_server64 -Ppass
|
||||
|
|
|
|||
|
|
@ -1,4 +1,4 @@
|
|||
|
||||
# PwnTools
|
||||
|
||||
<details>
|
||||
|
||||
|
|
@ -9,19 +9,18 @@ Other ways to support HackTricks:
|
|||
* If you want to see your **company advertised in HackTricks** or **download HackTricks in PDF** Check the [**SUBSCRIPTION PLANS**](https://github.com/sponsors/carlospolop)!
|
||||
* Get the [**official PEASS & HackTricks swag**](https://peass.creator-spring.com)
|
||||
* Discover [**The PEASS Family**](https://opensea.io/collection/the-peass-family), our collection of exclusive [**NFTs**](https://opensea.io/collection/the-peass-family)
|
||||
* **Join the** 💬 [**Discord group**](https://discord.gg/hRep4RUj7f) or the [**telegram group**](https://t.me/peass) or **follow** us on **Twitter** 🐦 [**@hacktricks_live**](https://twitter.com/hacktricks_live)**.**
|
||||
* **Join the** 💬 [**Discord group**](https://discord.gg/hRep4RUj7f) or the [**telegram group**](https://t.me/peass) or **follow** us on **Twitter** 🐦 [**@hacktricks\_live**](https://twitter.com/hacktricks\_live)**.**
|
||||
* **Share your hacking tricks by submitting PRs to the** [**HackTricks**](https://github.com/carlospolop/hacktricks) and [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) github repos.
|
||||
|
||||
</details>
|
||||
|
||||
|
||||
```
|
||||
pip3 install pwntools
|
||||
```
|
||||
|
||||
# Pwn asm
|
||||
## Pwn asm
|
||||
|
||||
Get opcodes from line or file.
|
||||
Get **opcodes** from line or file.
|
||||
|
||||
```
|
||||
pwn asm "jmp esp"
|
||||
|
|
@ -35,7 +34,7 @@ pwn asm -i <filepath>
|
|||
* avoid bytes (new lines, null, a list)
|
||||
* select encoder debug shellcode using gdb run the output
|
||||
|
||||
# **Pwn checksec**
|
||||
## **Pwn checksec**
|
||||
|
||||
Checksec script
|
||||
|
||||
|
|
@ -43,9 +42,9 @@ Checksec script
|
|||
pwn checksec <executable>
|
||||
```
|
||||
|
||||
# Pwn constgrep
|
||||
## Pwn constgrep
|
||||
|
||||
# Pwn cyclic
|
||||
## Pwn cyclic
|
||||
|
||||
Get a pattern
|
||||
|
||||
|
|
@ -54,14 +53,14 @@ pwn cyclic 3000
|
|||
pwn cyclic -l faad
|
||||
```
|
||||
|
||||
**Can select:**
|
||||
**Can select:**
|
||||
|
||||
* The used alphabet (lowercase chars by default)
|
||||
* Length of uniq pattern (default 4)
|
||||
* context (16,32,64,linux,windows...)
|
||||
* Take the offset (-l)
|
||||
|
||||
# Pwn debug
|
||||
## Pwn debug
|
||||
|
||||
Attach GDB to a process
|
||||
|
||||
|
|
@ -77,15 +76,15 @@ pwn debug --process bash
|
|||
* gdbscript to execute
|
||||
* sysrootpath
|
||||
|
||||
# Pwn disablenx
|
||||
## Pwn disablenx
|
||||
|
||||
Disable nx of a binary
|
||||
Disable nx of a binary
|
||||
|
||||
```
|
||||
pwn disablenx <filepath>
|
||||
```
|
||||
|
||||
# Pwn disasm
|
||||
## Pwn disasm
|
||||
|
||||
Disas hex opcodes
|
||||
|
||||
|
|
@ -99,7 +98,7 @@ pwn disasm ffe4
|
|||
* base addres
|
||||
* color(default)/no color
|
||||
|
||||
# Pwn elfdiff
|
||||
## Pwn elfdiff
|
||||
|
||||
Print differences between 2 fiels
|
||||
|
||||
|
|
@ -107,7 +106,7 @@ Print differences between 2 fiels
|
|||
pwn elfdiff <file1> <file2>
|
||||
```
|
||||
|
||||
# Pwn hex
|
||||
## Pwn hex
|
||||
|
||||
Get hexadecimal representation
|
||||
|
||||
|
|
@ -115,7 +114,7 @@ Get hexadecimal representation
|
|||
pwn hex hola #Get hex of "hola" ascii
|
||||
```
|
||||
|
||||
# Pwn phd
|
||||
## Pwn phd
|
||||
|
||||
Get hexdump
|
||||
|
||||
|
|
@ -129,11 +128,11 @@ pwn phd <file>
|
|||
* Number of bytes per line highlight byte
|
||||
* Skip bytes at beginning
|
||||
|
||||
# Pwn pwnstrip
|
||||
## Pwn pwnstrip
|
||||
|
||||
# Pwn scrable
|
||||
## Pwn scrable
|
||||
|
||||
# Pwn shellcraft
|
||||
## Pwn shellcraft
|
||||
|
||||
Get shellcodes
|
||||
|
||||
|
|
@ -160,7 +159,7 @@ pwn shellcraft .r amd64.linux.bindsh 9095 #Bind SH to port
|
|||
* list possible shellcodes
|
||||
* Generate ELF as a shared library
|
||||
|
||||
# Pwn template
|
||||
## Pwn template
|
||||
|
||||
Get a python template
|
||||
|
||||
|
|
@ -170,7 +169,7 @@ pwn template
|
|||
|
||||
**Can select:** host, port, user, pass, path and quiet
|
||||
|
||||
# Pwn unhex
|
||||
## Pwn unhex
|
||||
|
||||
From hex to string
|
||||
|
||||
|
|
@ -178,7 +177,7 @@ From hex to string
|
|||
pwn unhex 686f6c61
|
||||
```
|
||||
|
||||
# Pwn update
|
||||
## Pwn update
|
||||
|
||||
To update pwntools
|
||||
|
||||
|
|
@ -186,7 +185,6 @@ To update pwntools
|
|||
pwn update
|
||||
```
|
||||
|
||||
|
||||
<details>
|
||||
|
||||
<summary><strong>Learn AWS hacking from zero to hero with</strong> <a href="https://training.hacktricks.xyz/courses/arte"><strong>htARTE (HackTricks AWS Red Team Expert)</strong></a><strong>!</strong></summary>
|
||||
|
|
@ -196,9 +194,7 @@ Other ways to support HackTricks:
|
|||
* If you want to see your **company advertised in HackTricks** or **download HackTricks in PDF** Check the [**SUBSCRIPTION PLANS**](https://github.com/sponsors/carlospolop)!
|
||||
* Get the [**official PEASS & HackTricks swag**](https://peass.creator-spring.com)
|
||||
* Discover [**The PEASS Family**](https://opensea.io/collection/the-peass-family), our collection of exclusive [**NFTs**](https://opensea.io/collection/the-peass-family)
|
||||
* **Join the** 💬 [**Discord group**](https://discord.gg/hRep4RUj7f) or the [**telegram group**](https://t.me/peass) or **follow** us on **Twitter** 🐦 [**@hacktricks_live**](https://twitter.com/hacktricks_live)**.**
|
||||
* **Join the** 💬 [**Discord group**](https://discord.gg/hRep4RUj7f) or the [**telegram group**](https://t.me/peass) or **follow** us on **Twitter** 🐦 [**@hacktricks\_live**](https://twitter.com/hacktricks\_live)**.**
|
||||
* **Share your hacking tricks by submitting PRs to the** [**HackTricks**](https://github.com/carlospolop/hacktricks) and [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) github repos.
|
||||
|
||||
</details>
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -1,4 +1,4 @@
|
|||
# Common Binary Protections
|
||||
# Common Binary Exploitation Protections & Bypasses
|
||||
|
||||
<details>
|
||||
|
||||
|
|
@ -20,7 +20,7 @@ Other ways to support HackTricks:
|
|||
|
||||
### **Enabling Core Dump Generation**
|
||||
|
||||
By default, many systems limit the size of core files to 0 (i.e., they do not generate core files) to save disk space. To enable the generation of core files, you can use the `ulimit` command (in bash or similar shells) or configure system-wide settings.
|
||||
By default, many systems limit the size of core files to 0 (i.e., they do not generate core files) to save disk space. To enable the generation of core files, you can use the **`ulimit`** command (in bash or similar shells) or configure system-wide settings.
|
||||
|
||||
* **Using ulimit**: The command `ulimit -c unlimited` allows the current shell session to create unlimited-sized core files. This is useful for debugging sessions but is not persistent across reboots or new sessions.
|
||||
|
||||
|
|
|
|||
|
|
@ -20,7 +20,7 @@ Other ways to support HackTricks:
|
|||
|
||||
### **Checking ASLR Status**
|
||||
|
||||
To **check** the ASLR status on a Linux system, you can read the value from the `/proc/sys/kernel/randomize_va_space` file. The value stored in this file determines the type of ASLR being applied:
|
||||
To **check** the ASLR status on a Linux system, you can read the value from the **`/proc/sys/kernel/randomize_va_space`** file. The value stored in this file determines the type of ASLR being applied:
|
||||
|
||||
* **0**: No randomization. Everything is static.
|
||||
* **1**: Conservative randomization. Shared libraries, stack, mmap(), VDSO page are randomized.
|
||||
|
|
|
|||
|
|
@ -39,15 +39,15 @@ payload = flat(
|
|||
)
|
||||
```
|
||||
|
||||
Note how **`puts`** (using the address from the PLT) is called with the address of `puts` located in the `GOT`. This is because by the time `puts` prints the `GOT` entry of puts, this **entry will contain the address of `puts` in memory**.
|
||||
Note how **`puts`** (using the address from the PLT) is called with the address of `puts` located in the GOT (Global Offset Table). This is because by the time `puts` prints the GOT entry of puts, this **entry will contain the exact address of `puts` in memory**.
|
||||
|
||||
Also note how the address of `main` is used in the exploit so when `puts` ends its execution, the **binary calls `main` again instead of exiting** (so the leaked address will continue to be valid).
|
||||
|
||||
{% hint style="danger" %}
|
||||
Note how in order for this to work the **binary cannot be compiled with PIE** or you must have **found a leak to bypass PIE** in order to know the address of the `PLT`, `GOT` and `main`.
|
||||
Note how in order for this to work the **binary cannot be compiled with PIE** or you must have **found a leak to bypass PIE** in order to know the address of the PLT, GOT and main. Otherwise, you need to bypass PIE first.
|
||||
{% endhint %}
|
||||
|
||||
You can find a [**full example of this bypass here**](https://ir0nstone.gitbook.io/notes/types/stack/aslr/ret2plt-aslr-bypass). This was the final exploit from that example:
|
||||
You can find a [**full example of this bypass here**](https://ir0nstone.gitbook.io/notes/types/stack/aslr/ret2plt-aslr-bypass). This was the final exploit from that **example**:
|
||||
|
||||
```python
|
||||
from pwn import *
|
||||
|
|
|
|||
|
|
@ -16,7 +16,7 @@ Other ways to support HackTricks:
|
|||
|
||||
## Ret2ret
|
||||
|
||||
The main goal of this technique is to try to **bypass ASLR by abusing an existing pointer in the stack**.
|
||||
The main **goal** of this technique is to try to **bypass ASLR by abusing an existing pointer in the stack**.
|
||||
|
||||
Basically, stack overflows are usually caused by strings, and **strings end with a null byte at the end** in memory. This allows to try to reduce the place pointed by na existing pointer already existing n the stack. So if the stack contained `0xbfffffdd`, this overflow could transform it into `0xbfffff00` (note the last zeroed byte).
|
||||
|
||||
|
|
|
|||
|
|
@ -32,7 +32,7 @@ The **shadow stack** is a **dedicated stack used solely for storing return addre
|
|||
**ROP and JOP attacks** rely on the ability to hijack the control flow of an application by leveraging vulnerabilities that allow them to overwrite pointers or return addresses on the stack. By directing the flow to sequences of existing code gadgets or return-oriented programming gadgets, attackers can execute arbitrary code.
|
||||
|
||||
* **CET's IBT** feature makes these attacks significantly harder by ensuring that indirect branches can only jump to addresses that have been explicitly marked as valid targets. This makes it impossible for attackers to execute arbitrary gadgets spread across the binary.
|
||||
* The **shadow stack**, on the other hand, ensures that even if an attacker can overwrite a return address on the normal stack, the discrepancy will be detected when comparing the corrupted address with the secure copy stored in the shadow stack upon returning from a function. If the addresses don't match, the program can terminate or take other security measures, preventing the attack from succeeding.
|
||||
* The **shadow stack**, on the other hand, ensures that even if an attacker can overwrite a return address on the normal stack, the **discrepancy will be detected** when comparing the corrupted address with the secure copy stored in the shadow stack upon returning from a function. If the addresses don't match, the program can terminate or take other security measures, preventing the attack from succeeding.
|
||||
|
||||
<details>
|
||||
|
||||
|
|
|
|||
|
|
@ -16,7 +16,7 @@ Other ways to support HackTricks:
|
|||
|
||||
## Basic Information
|
||||
|
||||
Memory Tagging Extension (MTE) is designed to enhance software reliability and security by **detecting and preventing memory-related errors**, such as buffer overflows and use-after-free vulnerabilities. MTE, as part of the **ARM** architecture, provides a mechanism to attach a **small tag to each memory allocation** and a **corresponding tag to each pointer** referencing that memory. This approach allows for the detection of illegal memory accesses at runtime, significantly reducing the risk of exploiting such vulnerabilities for executing arbitrary code.
|
||||
**Memory Tagging Extension (MTE)** is designed to enhance software reliability and security by **detecting and preventing memory-related errors**, such as buffer overflows and use-after-free vulnerabilities. MTE, as part of the **ARM** architecture, provides a mechanism to attach a **small tag to each memory allocation** and a **corresponding tag to each pointer** referencing that memory. This approach allows for the detection of illegal memory accesses at runtime, significantly reducing the risk of exploiting such vulnerabilities for executing arbitrary code.
|
||||
|
||||
### **How Memory Tagging Extension Works**
|
||||
|
||||
|
|
|
|||
|
|
@ -20,7 +20,7 @@ The **No-Execute (NX)** bit, also known as **Execute Disable (XD)** in Intel ter
|
|||
|
||||
## Bypasses
|
||||
|
||||
* It's possible to use techniques such as [**ROP**](../rop-return-oriented-programing/) to bypass this protection by executing chunks of executable code already present in the binary.
|
||||
* It's possible to use techniques such as [**ROP**](../rop-return-oriented-programing/) **to bypass** this protection by executing chunks of executable code already present in the binary.
|
||||
* [**Ret2libc**](../rop-return-oriented-programing/ret2lib/)
|
||||
* [**Ret2syscall**](../rop-return-oriented-programing/rop-syscall-execv.md)
|
||||
* **Ret2...**
|
||||
|
|
|
|||
|
|
@ -35,7 +35,7 @@ In order to bypass PIE it's needed to **leak some address of the loaded** binary
|
|||
[bypassing-canary-and-pie.md](bypassing-canary-and-pie.md)
|
||||
{% endcontent-ref %}
|
||||
|
||||
* Use an arbitrary read vulnerability such as [**format string**](../../format-strings/) to leak an address of the binary (e.g. from the stack, like in the previous technique) to get the base of the binary and use offsets from there. [**Find an example here**](https://ir0nstone.gitbook.io/notes/types/stack/pie/pie-bypass).
|
||||
* Use an **arbitrary read** vulnerability such as [**format string**](../../format-strings/) to leak an address of the binary (e.g. from the stack, like in the previous technique) to get the base of the binary and use offsets from there. [**Find an example here**](https://ir0nstone.gitbook.io/notes/types/stack/pie/pie-bypass).
|
||||
|
||||
## References
|
||||
|
||||
|
|
|
|||
|
|
@ -25,7 +25,7 @@ However, you can manually notice this if you find that a value is saved in the s
|
|||
|
||||
## Brute-Force Addresses
|
||||
|
||||
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.\
|
||||
For example, if a binary is protected using both a **canary** and **PIE**, you can start brute-forcing the canary, then the **next** 8 Bytes (x64) will be the saved **RBP** and the **next** 8 Bytes will be the saved **RIP.**
|
||||
|
||||
{% hint style="success" %}
|
||||
|
|
|
|||
|
|
@ -22,15 +22,15 @@ Other ways to support HackTricks:
|
|||
|
||||
**Partial RELRO** takes a simpler approach to enhance security without significantly impacting the binary's performance. By **positioning the GOT above the program's variables in memory, Partial RELRO aims to prevent buffer overflows from reaching and corrupting the GOT**. 
|
||||
|
||||
This **doesn't prevent to GOT** to be abused **from arbitrary write** vulnerabilities.
|
||||
This **doesn't prevent the GOT** to be abused **from arbitrary write** vulnerabilities.
|
||||
|
||||
### **Full RELRO**
|
||||
|
||||
**Full RELRO** steps up the protection by **making the GOT and .fini\_array** section completely **read-only.** Once the binary starts all the function addresses are resolved and loaded in the GOT, then, GOT is marked as read-only, effectively preventing any modifications to it during runtime.
|
||||
|
||||
However, the trade-off with Full RELRO is in terms of performance and startup time. Because it necessitates resolving all dynamic symbols at startup before marking the GOT as read-only, **binaries with Full RELRO enabled may experience longer load times**. This additional startup overhead is why Full RELRO is not enabled by default in all binaries.
|
||||
However, the trade-off with Full RELRO is in terms of performance and startup time. Because it needs to resolve all dynamic symbols at startup before marking the GOT as read-only, **binaries with Full RELRO enabled may experience longer load times**. This additional startup overhead is why Full RELRO is not enabled by default in all binaries.
|
||||
|
||||
It's possible to see if Full RELRO is enabled in a binary with:
|
||||
It's possible to see if Full RELRO is **enabled** in a binary with:
|
||||
|
||||
```bash
|
||||
readelf -l /proc/ID_PROC/exe | grep BIND_NOW
|
||||
|
|
@ -40,6 +40,8 @@ readelf -l /proc/ID_PROC/exe | grep BIND_NOW
|
|||
|
||||
If Full RELRO is enabled, the only way to bypass it is to find another way that doesn't need to write in the GOT table to get arbitrary execution.
|
||||
|
||||
Note that **LIBC's GOT is usually Partial RELRO**, so it can be modified with an arbitrary write. More information in [Targetting libc GOT entries](https://github.com/nobodyisnobody/docs/blob/main/code.execution.on.last.libc/README.md#1---targetting-libc-got-entries)**.**
|
||||
|
||||
<details>
|
||||
|
||||
<summary><strong>Learn AWS hacking from zero to hero with</strong> <a href="https://training.hacktricks.xyz/courses/arte"><strong>htARTE (HackTricks AWS Red Team Expert)</strong></a><strong>!</strong></summary>
|
||||
|
|
|
|||
|
|
@ -64,9 +64,23 @@ The stack vulnerable to a stack overflow might **contain addresses to strings or
|
|||
[pointer-redirecting.md](../../stack-overflow/pointer-redirecting.md)
|
||||
{% endcontent-ref %}
|
||||
|
||||
* **Modifying both master and thread canary**
|
||||
|
||||
A buffer **overflow in a threaded function** protected with canary can be used to **modify the master canary of the thread**. As a result, the mitigation is useless because the check is used with two canaries that are the same (although modified).
|
||||
|
||||
This attack is performed in the writeup: [http://7rocky.github.io/en/ctf/htb-challenges/pwn/robot-factory/#canaries-and-threads](http://7rocky.github.io/en/ctf/htb-challenges/pwn/robot-factory/#canaries-and-threads)
|
||||
|
||||
* **Modify the GOT entry of `__stack_chk_fail`**
|
||||
|
||||
If the binary has Partial RELRO, then you can use an arbitrary write to modify the **GOT entry of `__stack_chk_fail`** to be a dummy function that does not block the program if the canary gets modified.
|
||||
|
||||
This attack is performed in the writeup: [https://7rocky.github.io/en/ctf/other/securinets-ctf/scrambler/](https://7rocky.github.io/en/ctf/other/securinets-ctf/scrambler/)
|
||||
|
||||
## References
|
||||
|
||||
* [https://guyinatuxedo.github.io/7.1-mitigation\_canary/index.html](https://guyinatuxedo.github.io/7.1-mitigation\_canary/index.html)
|
||||
* [http://7rocky.github.io/en/ctf/htb-challenges/pwn/robot-factory/#canaries-and-threads](http://7rocky.github.io/en/ctf/htb-challenges/pwn/robot-factory/#canaries-and-threads)
|
||||
* [https://7rocky.github.io/en/ctf/other/securinets-ctf/scrambler/](https://7rocky.github.io/en/ctf/other/securinets-ctf/scrambler/)
|
||||
|
||||
<details>
|
||||
|
||||
|
|
|
|||
|
|
@ -122,6 +122,9 @@ log.info(f"The canary is: {canary}")
|
|||
|
||||
Threads of the same process will also **share the same canary token**, therefore it'll be possible to **brute-forc**e a canary if the binary spawns a new thread every time an attack happens. 
|
||||
|
||||
Moreover, a buffer **overflow in a threaded function** protected with canary can be used to **modify the master canary of the thread**. As a result, the mitigation is useless because the check is used with two canaries that are the same (although modified).\
|
||||
This attack is performed in the writeup: [http://7rocky.github.io/en/ctf/htb-challenges/pwn/robot-factory/#canaries-and-threads](http://7rocky.github.io/en/ctf/htb-challenges/pwn/robot-factory/#canaries-and-threads)
|
||||
|
||||
## Other examples & references
|
||||
|
||||
* [https://guyinatuxedo.github.io/07-bof\_static/dcquals16\_feedme/index.html](https://guyinatuxedo.github.io/07-bof\_static/dcquals16\_feedme/index.html)
|
||||
|
|
|
|||
|
|
@ -33,7 +33,7 @@ Obviously, this tactic is very **restricted** as the attacker needs to be able t
|
|||
|
||||
## Arbitrary Read
|
||||
|
||||
With an arbitrary read like the one provided by format **strings** it might be possible to leak the canary. Check this example: [**https://ir0nstone.gitbook.io/notes/types/stack/canaries**](https://ir0nstone.gitbook.io/notes/types/stack/canaries) and you can read about abusing format strings to read arbitrary memory addresses in:
|
||||
With an **arbitrary read** like the one provided by format **strings** it might be possible to leak the canary. Check this example: [**https://ir0nstone.gitbook.io/notes/types/stack/canaries**](https://ir0nstone.gitbook.io/notes/types/stack/canaries) and you can read about abusing format strings to read arbitrary memory addresses in:
|
||||
|
||||
{% content-ref url="../../format-strings/" %}
|
||||
[format-strings](../../format-strings/)
|
||||
|
|
|
|||
|
|
@ -39,7 +39,7 @@ p.interactive()
|
|||
|
||||
## Socat & pty
|
||||
|
||||
Note that socat already transfers `stdin` and `stdout` to the socket. However, the `pty` mode **include DELETE characters**. So, if you send a `\x7f` ( `DELETE` -)it will **delete the previous character** of your exploit.
|
||||
Note that socat already transfers **`stdin`** and **`stdout`** to the socket. However, the `pty` mode **include DELETE characters**. So, if you send a `\x7f` ( `DELETE` -)it will **delete the previous character** of your exploit.
|
||||
|
||||
In order to bypass this the **escape character `\x16` must be prepended to any `\x7f` sent.**
|
||||
|
||||
|
|
|
|||
|
|
@ -143,7 +143,7 @@ python -c 'print "\x26\x97\x04\x08"+"\x24\x97\x04\x08"+ "%.49143x" + "%4$hn" + "
|
|||
|
||||
### Pwntools Template
|
||||
|
||||
You can find a template to prepare a exploit for this kind of vulnerability in:
|
||||
You can find a **template** to prepare a exploit for this kind of vulnerability in:
|
||||
|
||||
{% content-ref url="format-strings-template.md" %}
|
||||
[format-strings-template.md](format-strings-template.md)
|
||||
|
|
|
|||
|
|
@ -1,4 +1,4 @@
|
|||
|
||||
# Format Strings Template
|
||||
|
||||
<details>
|
||||
|
||||
|
|
@ -9,12 +9,11 @@ Other ways to support HackTricks:
|
|||
* If you want to see your **company advertised in HackTricks** or **download HackTricks in PDF** Check the [**SUBSCRIPTION PLANS**](https://github.com/sponsors/carlospolop)!
|
||||
* Get the [**official PEASS & HackTricks swag**](https://peass.creator-spring.com)
|
||||
* Discover [**The PEASS Family**](https://opensea.io/collection/the-peass-family), our collection of exclusive [**NFTs**](https://opensea.io/collection/the-peass-family)
|
||||
* **Join the** 💬 [**Discord group**](https://discord.gg/hRep4RUj7f) or the [**telegram group**](https://t.me/peass) or **follow** us on **Twitter** 🐦 [**@hacktricks_live**](https://twitter.com/hacktricks_live)**.**
|
||||
* **Join the** 💬 [**Discord group**](https://discord.gg/hRep4RUj7f) or the [**telegram group**](https://t.me/peass) or **follow** us on **Twitter** 🐦 [**@hacktricks\_live**](https://twitter.com/hacktricks\_live)**.**
|
||||
* **Share your hacking tricks by submitting PRs to the** [**HackTricks**](https://github.com/carlospolop/hacktricks) and [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) github repos.
|
||||
|
||||
</details>
|
||||
|
||||
|
||||
```python
|
||||
from pwn import *
|
||||
from time import sleep
|
||||
|
|
@ -152,10 +151,9 @@ format_string.execute_writes()
|
|||
# control the parameters passed to printf to execute arbitrary code.
|
||||
|
||||
P.interactive()
|
||||
|
||||
```
|
||||
|
||||
|
||||
|
||||
<details>
|
||||
|
||||
<summary><strong>Learn AWS hacking from zero to hero with</strong> <a href="https://training.hacktricks.xyz/courses/arte"><strong>htARTE (HackTricks AWS Red Team Expert)</strong></a><strong>!</strong></summary>
|
||||
|
|
@ -165,9 +163,7 @@ Other ways to support HackTricks:
|
|||
* If you want to see your **company advertised in HackTricks** or **download HackTricks in PDF** Check the [**SUBSCRIPTION PLANS**](https://github.com/sponsors/carlospolop)!
|
||||
* Get the [**official PEASS & HackTricks swag**](https://peass.creator-spring.com)
|
||||
* Discover [**The PEASS Family**](https://opensea.io/collection/the-peass-family), our collection of exclusive [**NFTs**](https://opensea.io/collection/the-peass-family)
|
||||
* **Join the** 💬 [**Discord group**](https://discord.gg/hRep4RUj7f) or the [**telegram group**](https://t.me/peass) or **follow** us on **Twitter** 🐦 [**@hacktricks_live**](https://twitter.com/hacktricks_live)**.**
|
||||
* **Join the** 💬 [**Discord group**](https://discord.gg/hRep4RUj7f) or the [**telegram group**](https://t.me/peass) or **follow** us on **Twitter** 🐦 [**@hacktricks\_live**](https://twitter.com/hacktricks\_live)**.**
|
||||
* **Share your hacking tricks by submitting PRs to the** [**HackTricks**](https://github.com/carlospolop/hacktricks) and [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) github repos.
|
||||
|
||||
</details>
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -16,7 +16,7 @@ Other ways to support HackTricks:
|
|||
|
||||
## Basic Information
|
||||
|
||||
At the heart of an integer overflow is the limitation imposed by the **size** of data types in computer programming and the **interpretation** of the data.
|
||||
At the heart of an **integer overflow** is the limitation imposed by the **size** of data types in computer programming and the **interpretation** of the data.
|
||||
|
||||
For example, an **8-bit unsigned integer** can represent values from **0 to 255**. If you attempt to store the value 256 in an 8-bit unsigned integer, it wraps around to 0 due to the limitation of its storage capacity. Similarly, for a **16-bit unsigned integer**, which can hold values from **0 to 65,535**, adding 1 to 65,535 will wrap the value back to 0.
|
||||
|
||||
|
|
|
|||
|
|
@ -24,6 +24,10 @@ Other ways to support HackTricks:
|
|||
2. **Gadget Chaining**: The attacker then carefully selects and chains gadgets to perform the desired actions. This could involve setting up arguments for a function call, calling the function (e.g., `system("/bin/sh")`), and handling any necessary cleanup or additional operations.
|
||||
3. **Payload Execution**: When the vulnerable function returns, instead of returning to a legitimate location, it starts executing the chain of gadgets.
|
||||
|
||||
### Tools
|
||||
|
||||
Typically, gadgets can be found using [**ROPgadget**](https://github.com/JonathanSalwan/ROPgadget), [**ropper**](https://github.com/sashs/Ropper) or directly from **pwntools** ([ROP](https://docs.pwntools.com/en/stable/rop/rop.html)).
|
||||
|
||||
## ROP Chain in x86 Example
|
||||
|
||||
### **x86 (32-bit) Calling conventions**
|
||||
|
|
@ -37,7 +41,7 @@ First, let's assume we've identified the necessary gadgets within the binary or
|
|||
|
||||
* `pop eax; ret`: This gadget pops the top value of the stack into the `EAX` register and then returns, allowing us to control `EAX`.
|
||||
* `pop ebx; ret`: Similar to the above, but for the `EBX` register, enabling control over `EBX`.
|
||||
* `mov [ebx], eax; ret`: Moves the value in `EAX` to the memory location pointed to by `EBX` and then returns.
|
||||
* `mov [ebx], eax; ret`: Moves the value in `EAX` to the memory location pointed to by `EBX` and then returns. This is often called a **write-what-where gadget**.
|
||||
* Additionally, we have the address of the `system()` function available.
|
||||
|
||||
### **ROP Chain**
|
||||
|
|
@ -60,7 +64,7 @@ p = process(binary.path)
|
|||
bin_sh_addr = next(binary.search(b'/bin/sh\x00'))
|
||||
|
||||
# Address of system() function (hypothetical value)
|
||||
system_addr = 0xdeadcode
|
||||
system_addr = 0xdeadc0de
|
||||
|
||||
# A gadget to control the return address, typically found through analysis
|
||||
ret_gadget = 0xcafebabe # This could be any gadget that allows us to control the return address
|
||||
|
|
@ -105,7 +109,7 @@ And we know the address of the **system()** function.
|
|||
Below is an example using **pwntools** to set up and execute a ROP chain aiming to execute **system('/bin/sh')** on **x64**:
|
||||
|
||||
```python
|
||||
pythonCopy codefrom pwn import *
|
||||
from pwn import *
|
||||
|
||||
# Assuming we have the binary's ELF and its process
|
||||
binary = context.binary = ELF('your_binary_here')
|
||||
|
|
@ -152,7 +156,7 @@ In this example:
|
|||
## x86 vs x64 main difference
|
||||
|
||||
{% hint style="success" %}
|
||||
Since x64 uses registers for the first few arguments, it often requires fewer gadgets than x86 for simple function calls, but finding and chaining the right gadgets can be more complex due to the increased number of registers and the larger address space. The increased number of registers and the larger address space in **x64** architecture provide both opportunities and challenges for exploit development, especially in the context of Return-Oriented Programming (ROP).
|
||||
Since **x64 uses registers for the first few arguments,** it often requires fewer gadgets than x86 for simple function calls, but finding and chaining the right gadgets can be more complex due to the increased number of registers and the larger address space. The increased number of registers and the larger address space in **x64** architecture provide both opportunities and challenges for exploit development, especially in the context of Return-Oriented Programming (ROP).
|
||||
{% endhint %}
|
||||
|
||||
## Protections Against ROP
|
||||
|
|
|
|||
|
|
@ -119,7 +119,7 @@ print(p.recvline()) # should receive "Awesome work!"
|
|||
```
|
||||
|
||||
{% hint style="warning" %}
|
||||
Note that the previous exploit isn't meant to do a **`RCE`**, it's meant to just call a function called `win` (taking the address of `win` from stdin calling gets in the ROP chain and storing it in r15) with a third argument with the value `0xdeadbeefcafed00d`.
|
||||
Note that the previous exploit isn't meant to do a **`RCE`**, it's meant to just call a function called **`win`** (taking the address of `win` from stdin calling gets in the ROP chain and storing it in r15) with a third argument with the value `0xdeadbeefcafed00d`.
|
||||
{% endhint %}
|
||||
|
||||
### Bypassing the call and reaching ret
|
||||
|
|
|
|||
|
|
@ -18,14 +18,14 @@ Other ways to support HackTricks:
|
|||
|
||||
As explained in the page about [**GOT/PLT**](../arbitrary-write-2-exec/aw2exec-got-plt.md) and [**Relro**](../common-binary-protections-and-bypasses/relro.md), binaries without Full Relro will resolve symbols (like addresses to external libraries) the first time they are used. This resolution occurs calling the function **`_dl_runtime_resolve`**.
|
||||
|
||||
The **`_dl_runtime_resolve`** function takes from the stack references to some structures it needs in order to resolve the specified symbol.
|
||||
The **`_dl_runtime_resolve`** function takes from the stack references to some structures it needs in order to **resolve** the specified symbol.
|
||||
|
||||
Therefore, it's possible to **fake all these structures** to make the dynamic linked resolving the requested symbol (like **`system`** function) and call it with a configured parameter (e.g. **`system('/bin/sh')`**).
|
||||
|
||||
Usually, all these structures are faked by making an **initial ROP chain that calls `read`** over a writable memory, then the **structures** and the string **`'/bin/sh'`** are passed so they are stored by read in a known location, and then the ROP chain continues by calling **`_dl_runtime_resolve`** , having it **resolve the address of `system`** in the fake structures and **calling this address** with the address to `$'/bin/sh'`.
|
||||
|
||||
{% hint style="success" %}
|
||||
This technique is useful specially if there aren't syscall gadgets (to use techniques such as [**ret2syscall**](rop-syscall-execv.md) or [SROP](ret2esp-ret2reg/srop-sigreturn-oriented-programming.md)) and there are't ways to leak libc addresses.
|
||||
This technique is useful specially if there aren't syscall gadgets (to use techniques such as [**ret2syscall**](rop-syscall-execv.md) or [SROP](srop-sigreturn-oriented-programming.md)) and there are't ways to leak libc addresses.
|
||||
{% endhint %}
|
||||
|
||||
You can find a better explanation about this technique in the second half of the video:
|
||||
|
|
|
|||
|
|
@ -14,17 +14,17 @@ Other ways to support HackTricks:
|
|||
|
||||
</details>
|
||||
|
||||
## **Rest2esp**
|
||||
## **Ret2esp**
|
||||
|
||||
**Because the ESP (Stack Pointer) always points to the top of the stack**, this technique involves replacing the EIP (Instruction Pointer) with the address of a **`jmp esp`** or **`call esp`** instruction. By doing this, the shellcode is placed right after the overwritten EIP. When the `ret` instruction executes, ESP points to the next address, precisely where the shellcode is stored.
|
||||
|
||||
If **Address Space Layout Randomization (ASLR)** is not enabled in Windows or Linux, it's possible to use `jmp esp` or `call esp` instructions found in shared libraries. However, with [**ASLR**](../../common-binary-protections-and-bypasses/aslr/) active, one might need to look within the vulnerable program itself for these instructions (and you might need to defeat [**PIE**](../../common-binary-protections-and-bypasses/pie/)).
|
||||
If **Address Space Layout Randomization (ASLR)** is not enabled in Windows or Linux, it's possible to use `jmp esp` or `call esp` instructions found in shared libraries. However, with [**ASLR**](../common-binary-protections-and-bypasses/aslr/) active, one might need to look within the vulnerable program itself for these instructions (and you might need to defeat [**PIE**](../common-binary-protections-and-bypasses/pie/)).
|
||||
|
||||
Moreover, being able to place the shellcode **after the EIP corruption**, rather than in the middle of the stack, ensures that any `push` or `pop` instructions executed during the function's operation don't interfere with the shellcode. This interference could happen if the shellcode were placed in the middle of the function's stack.
|
||||
|
||||
### Lacking space
|
||||
|
||||
If you are lacking space to write after overwriting RIP (maybe just a few bytes), write an initial `jmp` shellcode like:
|
||||
If you are lacking space to write after overwriting RIP (maybe just a few bytes), write an initial **`jmp`** shellcode like:
|
||||
|
||||
```armasm
|
||||
sub rsp, 0x30
|
||||
|
|
@ -109,8 +109,8 @@ You can find some examples here: 
|
|||
|
||||
## Protections
|
||||
|
||||
* [**NX**](../../common-binary-protections-and-bypasses/no-exec-nx.md): If the stack isn't executable this won't help as we need to place the shellcode in the stack and jump to execute it.
|
||||
* [**ASLR**](../../common-binary-protections-and-bypasses/aslr/) & [**PIE**](../../common-binary-protections-and-bypasses/pie/): Those can make harder to find a instruction to jump to esp or any other register.
|
||||
* [**NX**](../common-binary-protections-and-bypasses/no-exec-nx.md): If the stack isn't executable this won't help as we need to place the shellcode in the stack and jump to execute it.
|
||||
* [**ASLR**](../common-binary-protections-and-bypasses/aslr/) & [**PIE**](../common-binary-protections-and-bypasses/pie/): Those can make harder to find a instruction to jump to esp or any other register.
|
||||
|
||||
## References
|
||||
|
||||
|
|
@ -103,7 +103,7 @@ for off in range(0xb7000000, 0xb8000000, 0x1000):
|
|||
|
||||
## One Gadget
|
||||
|
||||
Execute a shell just jumping to one specific address in libc:
|
||||
Execute a shell just jumping to **one** specific **address** in libc:
|
||||
|
||||
{% content-ref url="one-gadget.md" %}
|
||||
[one-gadget.md](one-gadget.md)
|
||||
|
|
|
|||
|
|
@ -29,7 +29,7 @@ rop2 = base + p64(ONE_GADGET) + "\x00"*100
|
|||
To the address indicated by One Gadget you need to **add the base address where `libc`** is loaded.
|
||||
|
||||
{% hint style="success" %}
|
||||
One Gadget is a **great help for Arbitrary Write 2 Exec techniques** and might **simplifies ROP** chains as you only need to call one address (and fulfill the requirements).
|
||||
One Gadget is a **great help for Arbitrary Write 2 Exec techniques** and might **simplify ROP** **chains** as you only need to call one address (and fulfil the requirements).
|
||||
{% endhint %}
|
||||
|
||||
<details>
|
||||
|
|
|
|||
|
|
@ -17,7 +17,7 @@ Other ways to support HackTricks:
|
|||
## Quick Resume
|
||||
|
||||
1. **Find** overflow **offset**
|
||||
2. **Find** `POP_RDI`, `PUTS_PLT` and `MAIN_PLT` gadgets
|
||||
2. **Find** `POP_RDI` gadget, `PUTS_PLT` and `MAIN` gadgets
|
||||
3. Use previous gadgets lo **leak the memory address** of puts or another libc function and **find the libc version** ([donwload it](https://libc.blukat.me))
|
||||
4. With the library, **calculate the ROP and exploit it**
|
||||
|
||||
|
|
@ -48,7 +48,6 @@ gcc -o vuln vuln.c -fno-stack-protector -no-pie
|
|||
|
||||
## ROP - Leaking LIBC template
|
||||
|
||||
I'm going to use the code located here to make the exploit.\
|
||||
Download the exploit and place it in the same directory as the vulnerable binary and give the needed data to the script:
|
||||
|
||||
{% content-ref url="rop-leaking-libc-template.md" %}
|
||||
|
|
|
|||
|
|
@ -204,7 +204,7 @@ P.interactive() #Interact with your shell :)
|
|||
|
||||
### MAIN\_PLT = elf.symbols\['main'] not found
|
||||
|
||||
If the "main" symbol does not exist. Then you can just where is the main code:
|
||||
If the "main" symbol does not exist (probably because it's a stripped binary). Then you can just find where is the main code:
|
||||
|
||||
```python
|
||||
objdump -d vuln_binary | grep "\.text"
|
||||
|
|
@ -220,7 +220,7 @@ MAIN_PLT = 0x401080
|
|||
|
||||
### Puts not found
|
||||
|
||||
If the binary is not using Puts you should check if it is using
|
||||
If the binary is not using Puts you should **check if it is using**
|
||||
|
||||
### `sh: 1: %s%s%s%s%s%s%s%s: not found`
|
||||
|
||||
|
|
|
|||
|
|
@ -0,0 +1,82 @@
|
|||
# Ret2vDSO
|
||||
|
||||
<details>
|
||||
|
||||
<summary><strong>Learn AWS hacking from zero to hero with</strong> <a href="https://training.hacktricks.xyz/courses/arte"><strong>htARTE (HackTricks AWS Red Team Expert)</strong></a><strong>!</strong></summary>
|
||||
|
||||
Other ways to support HackTricks:
|
||||
|
||||
* If you want to see your **company advertised in HackTricks** or **download HackTricks in PDF** Check the [**SUBSCRIPTION PLANS**](https://github.com/sponsors/carlospolop)!
|
||||
* Get the [**official PEASS & HackTricks swag**](https://peass.creator-spring.com)
|
||||
* Discover [**The PEASS Family**](https://opensea.io/collection/the-peass-family), our collection of exclusive [**NFTs**](https://opensea.io/collection/the-peass-family)
|
||||
* **Join the** 💬 [**Discord group**](https://discord.gg/hRep4RUj7f) or the [**telegram group**](https://t.me/peass) or **follow** us on **Twitter** 🐦 [**@hacktricks\_live**](https://twitter.com/hacktricks\_live)**.**
|
||||
* **Share your hacking tricks by submitting PRs to the** [**HackTricks**](https://github.com/carlospolop/hacktricks) and [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) github repos.
|
||||
|
||||
</details>
|
||||
|
||||
## Basic Information
|
||||
|
||||
There might be **gadgets in the vDSO region**, which is used to change from user mode to kernel mode. In these type of challenges, usually a kernel image is provided to dump the vDSO region.
|
||||
|
||||
Following the example from [https://7rocky.github.io/en/ctf/other/htb-cyber-apocalypse/maze-of-mist/](https://7rocky.github.io/en/ctf/other/htb-cyber-apocalypse/maze-of-mist/) it's possible to see how it was possible to dump the vdso section and move it to the host with:
|
||||
|
||||
```bash
|
||||
# Find addresses
|
||||
cat /proc/76/maps
|
||||
08048000-08049000 r--p 00000000 00:02 317 /target
|
||||
08049000-0804a000 r-xp 00001000 00:02 317 /target
|
||||
0804a000-0804b000 rw-p 00002000 00:02 317 /target
|
||||
f7ff8000-f7ffc000 r--p 00000000 00:00 0 [vvar]
|
||||
f7ffc000-f7ffe000 r-xp 00000000 00:00 0 [vdso]
|
||||
fffdd000-ffffe000 rw-p 00000000 00:00 0 [stack]
|
||||
|
||||
# Dump it
|
||||
dd if=/proc/76/mem of=vdso bs=1 skip=$((0xf7ffc000)) count=$((0x2000))
|
||||
8192+0 records in
|
||||
8192+0 records out
|
||||
8192 bytes (8.0KB) copied, 0.901154 seconds, 8.9KB/s
|
||||
|
||||
# Compress and leak it
|
||||
gzip vdso
|
||||
base64 vdso.gz
|
||||
|
||||
# Decompress and check of gadgets
|
||||
echo '<base64-payload>' | base64 -d | gzip -d - > vdso
|
||||
file vdso
|
||||
ROPgadget --binary vdso | grep 'int 0x80'
|
||||
```
|
||||
|
||||
ROP gadgets found:
|
||||
|
||||
```python
|
||||
vdso_addr = 0xf7ffc000
|
||||
|
||||
int_0x80_xor_eax_eax_ret_addr = 0x8049010
|
||||
bin_sh_addr = 0x804a800
|
||||
|
||||
# 0x0000057a : pop edx ; pop ecx ; ret
|
||||
pop_edx_pop_ecx_ret_addr = vdso_addr + 0x57a
|
||||
|
||||
# 0x00000cca : mov dword ptr [edx], ecx ; add esp, 0x34 ; pop ebx ; pop esi ; pop edi ; pop ebp ; ret
|
||||
mov_dword_ptr_edx_ecx_ret_addr = vdso_addr + 0xcca
|
||||
|
||||
# 0x00000ccb : or al, byte ptr [ebx + 0x5e5b34c4] ; pop edi ; pop ebp ; ret
|
||||
or_al_byte_ptr_ebx_pop_edi_pop_ebp_ret_addr = vdso_addr + 0xccb
|
||||
|
||||
# 0x0000015cd : pop ebx ; pop esi ; pop ebp ; ret
|
||||
pop_ebx_pop_esi_pop_ebp_ret = vdso_addr + 0x15cd
|
||||
```
|
||||
|
||||
<details>
|
||||
|
||||
<summary><strong>Learn AWS hacking from zero to hero with</strong> <a href="https://training.hacktricks.xyz/courses/arte"><strong>htARTE (HackTricks AWS Red Team Expert)</strong></a><strong>!</strong></summary>
|
||||
|
||||
Other ways to support HackTricks:
|
||||
|
||||
* If you want to see your **company advertised in HackTricks** or **download HackTricks in PDF** Check the [**SUBSCRIPTION PLANS**](https://github.com/sponsors/carlospolop)!
|
||||
* Get the [**official PEASS & HackTricks swag**](https://peass.creator-spring.com)
|
||||
* Discover [**The PEASS Family**](https://opensea.io/collection/the-peass-family), our collection of exclusive [**NFTs**](https://opensea.io/collection/the-peass-family)
|
||||
* **Join the** 💬 [**Discord group**](https://discord.gg/hRep4RUj7f) or the [**telegram group**](https://t.me/peass) or **follow** us on **Twitter** 🐦 [**@hacktricks\_live**](https://twitter.com/hacktricks\_live)**.**
|
||||
* **Share your hacking tricks by submitting PRs to the** [**HackTricks**](https://github.com/carlospolop/hacktricks) and [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) github repos.
|
||||
|
||||
</details>
|
||||
|
|
@ -16,7 +16,7 @@ Other ways to support HackTricks:
|
|||
|
||||
## Basic Information
|
||||
|
||||
This is similar to Ret2lib, however, in this case we won't be calling a function from a library. In this case, everything will be prepared to call the syscall `sys_execve` with some aregumentes to execute `/bin/sh`.
|
||||
This is similar to Ret2lib, however, in this case we won't be calling a function from a library. In this case, everything will be prepared to call the syscall `sys_execve` with some arguments to execute `/bin/sh`. This technique is usually performed on binaries that are compiled statically, so there might be plenty of gadgets and syscall instructions.
|
||||
|
||||
In order to prepare the call for the **syscall** it's needed the following configuration:
|
||||
|
||||
|
|
@ -28,14 +28,14 @@ In order to prepare the call for the **syscall** it's needed the following confi
|
|||
So, basically it's needed to write the string `/bin/sh` somewhere and then perform the `syscall` (being aware of the padding needed to control the stack). For this, we need a gadget to write `/bin/sh` in a known area.
|
||||
|
||||
{% hint style="success" %}
|
||||
Another interesting syscall to call is **`mprotect`** which would allow an attacker to **modify the permissions of a page in memory**.
|
||||
Another interesting syscall to call is **`mprotect`** which would allow an attacker to **modify the permissions of a page in memory**. This can be combined with [**ret2shellcode**](../stack-overflow/stack-shellcode.md).
|
||||
{% endhint %}
|
||||
|
||||
## Register Gadgets
|
||||
## Register gadgets
|
||||
|
||||
Let's start by finding **how to control those registers**:
|
||||
|
||||
```c
|
||||
```bash
|
||||
ROPgadget --binary speedrun-001 | grep -E "pop (rdi|rsi|rdx\rax) ; ret"
|
||||
0x0000000000415664 : pop rax ; ret
|
||||
0x0000000000400686 : pop rdi ; ret
|
||||
|
|
@ -69,6 +69,14 @@ ROPgadget --binary speedrun-001 | grep " : mov qword ptr \["
|
|||
mov qword ptr [rax], rdx ; ret #Write in the rax address the content of rdx
|
||||
```
|
||||
|
||||
### Automate ROP chain
|
||||
|
||||
The following command creates a full `sys_execve` ROP chain given a static binary when there are write-what-where gadgets and syscall instructions:
|
||||
|
||||
```bash
|
||||
ROPgadget --binary vuln --ropchain
|
||||
```
|
||||
|
||||
#### 32 bits
|
||||
|
||||
```python
|
||||
|
|
@ -115,8 +123,8 @@ rop += writeGadget #Address to: mov qword ptr [rax], rdx
|
|||
|
||||
If you are **lacking gadgets**, for example to write `/bin/sh` in memory, you can use the **SROP technique to control all the register values** (including RIP and params registers) from the stack:
|
||||
|
||||
{% content-ref url="ret2esp-ret2reg/srop-sigreturn-oriented-programming.md" %}
|
||||
[srop-sigreturn-oriented-programming.md](ret2esp-ret2reg/srop-sigreturn-oriented-programming.md)
|
||||
{% content-ref url="srop-sigreturn-oriented-programming.md" %}
|
||||
[srop-sigreturn-oriented-programming.md](srop-sigreturn-oriented-programming.md)
|
||||
{% endcontent-ref %}
|
||||
|
||||
## Exploit Example
|
||||
|
|
|
|||
|
|
@ -28,8 +28,8 @@ Calling the syscall **`sigreturn`** from a ROP chain and **adding the registry v
|
|||
|
||||
Note how this would be a **type of Ret2syscall** that makes much easier to control params to call other Ret2syscalls:
|
||||
|
||||
{% content-ref url="../rop-syscall-execv.md" %}
|
||||
[rop-syscall-execv.md](../rop-syscall-execv.md)
|
||||
{% content-ref url="rop-syscall-execv.md" %}
|
||||
[rop-syscall-execv.md](rop-syscall-execv.md)
|
||||
{% endcontent-ref %}
|
||||
|
||||
If you are curious this is the **sigcontext structure** stored in the stack to later recover the values (diagram from [**here**](https://guyinatuxedo.github.io/16-srop/backdoor\_funsignals/index.html)):
|
||||
|
|
@ -105,7 +105,7 @@ p.sendline(payload)
|
|||
p.interactive()
|
||||
```
|
||||
|
||||
Check also the [**exploit from here**](https://guyinatuxedo.github.io/16-srop/csaw19\_smallboi/index.html) where the binary was already calling `sigreturn` and therefore it's not needed to buil that with a ROP:
|
||||
Check also the [**exploit from here**](https://guyinatuxedo.github.io/16-srop/csaw19\_smallboi/index.html) where the binary was already calling `sigreturn` and therefore it's not needed to buil that with a **ROP**:
|
||||
|
||||
```python
|
||||
from pwn import *
|
||||
|
|
@ -145,11 +145,11 @@ target.interactive()
|
|||
* [https://youtu.be/ADULSwnQs-s?feature=shared](https://youtu.be/ADULSwnQs-s?feature=shared)
|
||||
* [https://ir0nstone.gitbook.io/notes/types/stack/syscalls/sigreturn-oriented-programming-srop](https://ir0nstone.gitbook.io/notes/types/stack/syscalls/sigreturn-oriented-programming-srop)
|
||||
* [https://guyinatuxedo.github.io/16-srop/backdoor\_funsignals/index.html](https://guyinatuxedo.github.io/16-srop/backdoor\_funsignals/index.html)
|
||||
* Assembly binary that allows to **write to the stack** and then calls the **`sigreturn`** syscall. It's possible to write on the stack a [**ret2syscall**](../rop-syscall-execv.md) via a **sigreturn** structure and read the flag which is inside the memory of the binary.
|
||||
* Assembly binary that allows to **write to the stack** and then calls the **`sigreturn`** syscall. It's possible to write on the stack a [**ret2syscall**](rop-syscall-execv.md) via a **sigreturn** structure and read the flag which is inside the memory of the binary.
|
||||
* [https://guyinatuxedo.github.io/16-srop/csaw19\_smallboi/index.html](https://guyinatuxedo.github.io/16-srop/csaw19\_smallboi/index.html)
|
||||
* Assembly binary that allows to **write to the stack** and then calls the **`sigreturn`** syscall. It's possible to write on the stack a [**ret2syscall**](../rop-syscall-execv.md) via a **sigreturn** structure (the binary has the string `/bin/sh`).
|
||||
* Assembly binary that allows to **write to the stack** and then calls the **`sigreturn`** syscall. It's possible to write on the stack a [**ret2syscall**](rop-syscall-execv.md) via a **sigreturn** structure (the binary has the string `/bin/sh`).
|
||||
* [https://guyinatuxedo.github.io/16-srop/inctf17\_stupidrop/index.html](https://guyinatuxedo.github.io/16-srop/inctf17\_stupidrop/index.html)
|
||||
* 64 bits, no relro, no canary, nx, no pie. Simple buffer overflow abusing `gets` function with lack of gadgets that performs a [**ret2syscall**](../rop-syscall-execv.md). The ROP chain writes `/bin/sh` in the `.bss` by calling gets again, it abuses the **`alarm`** function to set eax to `0xf` to call a **SROP** and execute a shell.
|
||||
* 64 bits, no relro, no canary, nx, no pie. Simple buffer overflow abusing `gets` function with lack of gadgets that performs a [**ret2syscall**](rop-syscall-execv.md). The ROP chain writes `/bin/sh` in the `.bss` by calling gets again, it abuses the **`alarm`** function to set eax to `0xf` to call a **SROP** and execute a shell.
|
||||
* [https://guyinatuxedo.github.io/16-srop/swamp19\_syscaller/index.html](https://guyinatuxedo.github.io/16-srop/swamp19\_syscaller/index.html)
|
||||
* 64 bits assembly program, no relro, no canary, nx, no pie. The flow allows to write in the stack, control several registers, and call a syscall and then it calls `exit`. The selected syscall is a `sigreturn` that will set registries and move `eip` to call a previous syscall instruction and run `memprotect` to set the binary space to `rwx` and set the ESP in the binary space. Following the flow, the program will call read intro ESP again, but in this case ESP will be pointing to the next intruction so passing a shellcode will write it as the next instruction and execute it.
|
||||
|
||||
|
|
@ -18,10 +18,11 @@ Other ways to support HackTricks:
|
|||
|
||||
A **stack overflow** is a vulnerability that occurs when a program writes more data to the stack than it is allocated to hold. This excess data will **overwrite adjacent memory space**, leading to the corruption of valid data, control flow disruption, and potentially the execution of malicious code. This issue often arises due to the use of unsafe functions that do not perform bounds checking on input.
|
||||
|
||||
The main problem of this overwrite is that the **EIP** and **EBP** pointers to return to the previos function are **stored in the stack**. Therefore, an attacker will be able to overwrite those and **control the execution flow of the program**.
|
||||
The main problem of this overwrite is that the **saved instruction pointer (EIP/RIP)** and the **saved base pointer (EBP/RBP)** to return to the previous function are **stored on the stack**. Therefore, an attacker will be able to overwrite those and **control the execution flow of the program**.
|
||||
|
||||
The vulnerability usually arises because a function **copies inside the stack more bytes than the amount allocated for it**, therefore being able to overwrite other parts of the stack.\
|
||||
Some common functions vulnerable to this are: `strcpy`, `strcat`, `sprintf`, `gets`, `fgets`...
|
||||
The vulnerability usually arises because a function **copies inside the stack more bytes than the amount allocated for it**, therefore being able to overwrite other parts of the stack.
|
||||
|
||||
Some common functions vulnerable to this are: **`strcpy`, `strcat`, `sprintf`, `gets`**... Also, functions like **`fgets`** , **`read` & `memcpy`** that take a **length argument**, might be used in a vulnerable way if the specified length is greater than the allocated one.
|
||||
|
||||
For example, the following functions could be vulnerable:
|
||||
|
||||
|
|
@ -36,11 +37,11 @@ void vulnerable() {
|
|||
|
||||
### Finding Stack Overflows offsets
|
||||
|
||||
The most common way to find stack overflows is to give a very big input of `A`s (e.g. `python3 -c 'print("A"*1000)'`) and expected a `Segmentation Fault` indicating that the **address `0x41414141` was tried to be accessed**.
|
||||
The most common way to find stack overflows is to give a very big input of `A`s (e.g. `python3 -c 'print("A"*1000)'`) and expect a `Segmentation Fault` indicating that the **address `0x41414141` was tried to be accessed**.
|
||||
|
||||
Moreover, once you found that there is Stack Overflow vulnerability you will need to find the offset until it's possible to **overwrite the EIP pointer**, for this it's usually used a **De Bruijn sequence.** Which for a given alphabet of size _k_ and subsequences of length _n_ is a **cyclic sequence in which every possible subsequence of length **_**n**_** appears exactly once** as a contiguous subsequence.
|
||||
Moreover, once you found that there is Stack Overflow vulnerability you will need to find the offset until it's possible to **overwrite the return address**, for this it's usually used a **De Bruijn sequence.** Which for a given alphabet of size _k_ and subsequences of length _n_ is a **cyclic sequence in which every possible subsequence of length \_n**\_\*\* appears exactly once\*\* as a contiguous subsequence.
|
||||
|
||||
This way, instead of needing to figure out which offset is overwriting the EIP by hand, it's possible to use as padding one of these sequences and then find the offset of the bytes that ended overwriting it.
|
||||
This way, instead of needing to figure out which offset is needed to control the EIP by hand, it's possible to use as padding one of these sequences and then find the offset of the bytes that ended overwriting it.
|
||||
|
||||
It's possible to use **pwntools** for this:
|
||||
|
||||
|
|
@ -67,14 +68,14 @@ pattern search $rsp #Search the offset given the content of $rsp
|
|||
|
||||
## Exploiting Stack Overflows
|
||||
|
||||
During an overflow (supposing the overflow size if big enough) you will be able to overwrite values of other variables inside the stack until reaching the EBP and EIP (or even more).\
|
||||
The most common way to abuse this type of vulnerability is by **modifying the EIP pointer** so when the function ends the **control flow will be redirected wherever the user specified** in this pointer.
|
||||
During an overflow (supposing the overflow size if big enough) you will be able to **overwrite** values of local variables inside the stack until reaching the saved **EBP/RBP and EIP/RIP (or even more)**.\
|
||||
The most common way to abuse this type of vulnerability is by **modifying the return address** so when the function ends the **control flow will be redirected wherever the user specified** in this pointer.
|
||||
|
||||
However, in other scenarios maybe just **overwriting some variables values in the stack** might be enough for the exploitation (like in easy CTF challenges).
|
||||
|
||||
### Ret2win
|
||||
|
||||
In this type of CTF challenges, there is a **function** **inside** the binary that is **never called** and that **you need to call in order to win**. For these challenges you just need to find the **offset to overwrite the EIP** and **find the address of the function** to call (usually [**ASLR**](../common-binary-protections-and-bypasses/aslr/) would be disabled) so when the vulnerable function returns, the hidden function will be called:
|
||||
In this type of CTF challenges, there is a **function** **inside** the binary that is **never called** and that **you need to call in order to win**. For these challenges you just need to find the **offset to overwrite the return address** and **find the address of the function** to call (usually [**ASLR**](../common-binary-protections-and-bypasses/aslr/) would be disabled) so when the vulnerable function returns, the hidden function will be called:
|
||||
|
||||
{% content-ref url="ret2win.md" %}
|
||||
[ret2win.md](ret2win.md)
|
||||
|
|
@ -82,7 +83,7 @@ In this type of CTF challenges, there is a **function** **inside** the binary th
|
|||
|
||||
### Stack Shellcode
|
||||
|
||||
In this scenario the attacker could place a shellcode in the stack and abuse the controlled EIP to go to the shellcode and execute the attackers code:
|
||||
In this scenario the attacker could place a shellcode in the stack and abuse the controlled EIP/RIP to jump to the shellcode and execute arbitrary code:
|
||||
|
||||
{% content-ref url="stack-shellcode.md" %}
|
||||
[stack-shellcode.md](stack-shellcode.md)
|
||||
|
|
@ -90,7 +91,7 @@ In this scenario the attacker could place a shellcode in the stack and abuse the
|
|||
|
||||
### ROP & Ret2... techniques
|
||||
|
||||
This technique is the fundamental framework to bypass the main protection to the previous technique: **No executable stack**. And it allows to perform several other techniques (ret2lib, ret2syscall...) that will end executing arbitrary commands by abusing existing instructions in the binary:
|
||||
This technique is the fundamental framework to bypass the main protection to the previous technique: **No executable stack (NX)**. And it allows to perform several other techniques (ret2lib, ret2syscall...) that will end executing arbitrary commands by abusing existing instructions in the binary:
|
||||
|
||||
{% content-ref url="../rop-return-oriented-programing/" %}
|
||||
[rop-return-oriented-programing](../rop-return-oriented-programing/)
|
||||
|
|
|
|||
|
|
@ -20,7 +20,7 @@ If a function call is going to use an address of a string that is located in the
|
|||
|
||||
If for example a **`system`** function call is going to **use the address of a string to execute a command**, an attacker could place the **address of a different string in the stack**, **`export PATH=.:$PATH`** and create in the current directory an **script with the name of the first letter of the new string** as this will be executed by the binary.
|
||||
|
||||
You can find an example of this in:
|
||||
You can find an **example** of this in:
|
||||
|
||||
* [https://github.com/florianhofhammer/stack-buffer-overflow-internship/blob/master/ASLR%20Smack%20and%20Laugh%20reference%20-%20Tilo%20Mueller/strptr.c](https://github.com/florianhofhammer/stack-buffer-overflow-internship/blob/master/ASLR%20Smack%20and%20Laugh%20reference%20-%20Tilo%20Mueller/strptr.c)
|
||||
* [https://guyinatuxedo.github.io/04-bof\_variable/tw17\_justdoit/index.html](https://guyinatuxedo.github.io/04-bof\_variable/tw17\_justdoit/index.html)
|
||||
|
|
|
|||
|
|
@ -16,7 +16,7 @@ Other ways to support HackTricks:
|
|||
|
||||
## Basic Information
|
||||
|
||||
**Ret2win** challenges are a popular category in **Capture The Flag (CTF)** competitions, particularly in tasks that involve **binary exploitation**. The goal is to exploit a vulnerability in a given binary to execute a specific, uninvoked function within the binary, often named something like `win`, `ret2win`, etc. This function, when executed, usually prints out a flag or a success message. The challenge typically involves overwriting the **return address** on the stack to divert execution flow to the desired function. Here's a more detailed explanation with examples:
|
||||
**Ret2win** challenges are a popular category in **Capture The Flag (CTF)** competitions, particularly in tasks that involve **binary exploitation**. The goal is to exploit a vulnerability in a given binary to execute a specific, uninvoked function within the binary, often named something like `win`, `flag`, etc. This function, when executed, usually prints out a flag or a success message. The challenge typically involves overwriting the **return address** on the stack to divert execution flow to the desired function. Here's a more detailed explanation with examples:
|
||||
|
||||
### C Example
|
||||
|
||||
|
|
@ -89,7 +89,7 @@ The Python script sends a carefully crafted message that, when processed by the
|
|||
|
||||
## Protections
|
||||
|
||||
* [**ASLR**](../common-binary-protections-and-bypasses/aslr/) **should be disabled** for the address to be reliable across executions or the address where the function will be stored won't be always the same and you would need some leak in order to figure out where is the win function loaded.
|
||||
* [**PIE**](../common-binary-protections-and-bypasses/pie/) **should be disabled** for the address to be reliable across executions or the address where the function will be stored won't be always the same and you would need some leak in order to figure out where is the win function loaded. In some cases, when the function that causes the overflow is `read` or similar, you can do a **Partial Overwrite** of 1 or 2 bytes to change the return address to be the win function. Because of how ASLR works, the last three hex nibbles are not randomized, so there is a **1/16 chance** (1 nibble) to get the correct return address.
|
||||
* [**Stack Canaries**](../common-binary-protections-and-bypasses/stack-canaries/) should be also disabled or the compromised EIP return address won't never be followed.
|
||||
|
||||
## Other examples & References
|
||||
|
|
@ -111,6 +111,8 @@ The Python script sends a carefully crafted message that, when processed by the
|
|||
* 32 bit, nx, nothing else, partial overwrite of EIP (1Byte) to call the win function
|
||||
* [https://guyinatuxedo.github.io/35-integer\_exploitation/int\_overflow\_post/index.html](https://guyinatuxedo.github.io/35-integer\_exploitation/int\_overflow\_post/index.html)
|
||||
* The program is only validating the last byte of a number to check for the size of the input, therefore it's possible to add any zie as long as the last byte is inside the allowed range. Then, the input creates a buffer overflow exploited with a ret2win.
|
||||
* [https://7rocky.github.io/en/ctf/other/blackhat-ctf/fno-stack-protector/](https://7rocky.github.io/en/ctf/other/blackhat-ctf/fno-stack-protector/)
|
||||
* 64 bit, relro, no canary, nx, pie. Partial overwrite to call the win function (ret2win)
|
||||
|
||||
<details>
|
||||
|
||||
|
|
|
|||
|
|
@ -16,13 +16,13 @@ Other ways to support HackTricks:
|
|||
|
||||
## Basic Information
|
||||
|
||||
This technique exploits the ability to manipulate the **Base Pointer (EBP)** to chain the execution of multiple functions through careful use of the EBP register and the `leave; ret` instruction sequence.
|
||||
This technique exploits the ability to manipulate the **Base Pointer (EBP)** to chain the execution of multiple functions through careful use of the EBP register and the **`leave; ret`** instruction sequence.
|
||||
|
||||
As a reminder, **`leave`** basically means:
|
||||
|
||||
```
|
||||
movl %ebp, %esp
|
||||
popl %ebp
|
||||
mov ebp, esp
|
||||
pop ebp
|
||||
ret
|
||||
```
|
||||
|
||||
|
|
@ -43,7 +43,7 @@ Then, you need to know the address used by `ret` that will **execute arbitrary c
|
|||
|
||||
* A valid [**ONE\_GADGET**](https://github.com/david942j/one\_gadget) address.
|
||||
* The address of **`system()`** followed by **4 junk bytes** and the address of `"/bin/sh"` (x86 bits).
|
||||
* The address of a **`jump esp;`** gadget ([**ret2esp**](../rop-return-oriented-programing/ret2esp-ret2reg/)) followed by the **shellcode** to execute.
|
||||
* The address of a **`jump esp;`** gadget ([**ret2esp**](../rop-return-oriented-programing/ret2esp-ret2reg.md)) followed by the **shellcode** to execute.
|
||||
* Some [**ROP**](../rop-return-oriented-programing/) chain
|
||||
|
||||
Remember than before any of these addresses in the controlled part of the memory, there must be **`4` bytes** because of the **`pop`** part of the `leave` instruction. It would be possible to abuse these 4B to set a **second fake EBP** and continue controlling the execution.
|
||||
|
|
@ -68,7 +68,7 @@ Now, the **`ESP`** is controlled pointing to a desired address and the next inst
|
|||
|
||||
Basically this way it's possible to chain several fake EBPs to control the flow of the program.
|
||||
|
||||
Tbh, this is like a [ret2lib](../rop-return-oriented-programing/ret2lib/), but more complex with no apparent benefit but could be interesting in some edge-cases.
|
||||
This is like a [ret2lib](../rop-return-oriented-programing/ret2lib/), but more complex with no apparent benefit but could be interesting in some edge-cases.
|
||||
|
||||
Moreover, here you have an [**example of a challenge**](https://ir0nstone.gitbook.io/notes/types/stack/stack-pivoting/exploitation/leave) that uses this technique with a **stack leak** to call a winning function. This is the final payload from the page:
|
||||
|
||||
|
|
@ -189,20 +189,20 @@ p.sendline(payload)
|
|||
print(p.recvline())
|
||||
```
|
||||
|
||||
### xchg \<rag>, rsp gadget
|
||||
### xchg \<reg>, rsp gadget
|
||||
|
||||
```
|
||||
pop <reg> <=== return pointer
|
||||
<reg value>
|
||||
xchg <rag>, rsp
|
||||
xchg <reg>, rsp
|
||||
```
|
||||
|
||||
### jmp esp
|
||||
|
||||
Check the ret2esp technique here:
|
||||
|
||||
{% content-ref url="../rop-return-oriented-programing/ret2esp-ret2reg/" %}
|
||||
[ret2esp-ret2reg](../rop-return-oriented-programing/ret2esp-ret2reg/)
|
||||
{% content-ref url="../rop-return-oriented-programing/ret2esp-ret2reg.md" %}
|
||||
[ret2esp-ret2reg.md](../rop-return-oriented-programing/ret2esp-ret2reg.md)
|
||||
{% endcontent-ref %}
|
||||
|
||||
## References & Other Examples
|
||||
|
|
|
|||
|
|
@ -16,7 +16,7 @@ Other ways to support HackTricks:
|
|||
|
||||
## Basic Information
|
||||
|
||||
**Stack shellcode** is a technique used in binary exploitation where an attacker writes shellcode to a vulnerable program's stack and then modifies the **Instruction Pointer (IP)** or **Extended Instruction Pointer (EIP)** to point to the location of this shellcode, causing it to execute. This is a classic method used to gain unauthorized access or execute arbitrary commands on a target system. Here's a breakdown of the process, including a simple C example and how you might write a corresponding exploit using Python with **pwntools**.
|
||||
**Stack shellcode** is a technique used in **binary exploitation** where an attacker writes shellcode to a vulnerable program's stack and then modifies the **Instruction Pointer (IP)** or **Extended Instruction Pointer (EIP)** to point to the location of this shellcode, causing it to execute. This is a classic method used to gain unauthorized access or execute arbitrary commands on a target system. Here's a breakdown of the process, including a simple C example and how you might write a corresponding exploit using Python with **pwntools**.
|
||||
|
||||
### C Example: A Vulnerable Program
|
||||
|
||||
|
|
|
|||
|
|
@ -21,7 +21,7 @@ The core idea here is to understand what happens with **uninitialized variables
|
|||
* **Function 1: `initializeVariable`**: We declare a variable `x` and assign it a value, let's say `0x1234`. This action is akin to reserving a spot in memory and putting a specific value in it.
|
||||
* **Function 2: `useUninitializedVariable`**: Here, we declare another variable `y` but do not assign any value to it. In C, uninitialized variables don't automatically get set to zero. Instead, they retain whatever value was last stored at their memory location.
|
||||
|
||||
When we run these two functions sequentially:
|
||||
When we run these two functions **sequentially**:
|
||||
|
||||
1. In `initializeVariable`, `x` is assigned a value (`0x1234`), which occupies a specific memory address.
|
||||
2. In `useUninitializedVariable`, `y` is declared but not assigned a value, so it takes the memory spot right after `x`. Due to not initializing `y`, it ends up "inheriting" the value from the same memory location used by `x`, because that's the last value that was there.
|
||||
|
|
|
|||
|
|
@ -267,7 +267,7 @@ There are shellcodes that will **overwrite themselves**, therefore it's importan
|
|||
|
||||
Add this parameters:
|
||||
|
||||
```
|
||||
```bash
|
||||
EXITFUNC=thread -e x86/shikata_ga_nai
|
||||
```
|
||||
|
||||
|
|
|
|||
Loading…
Reference in a new issue