Translated ['binary-exploitation/heap/fast-bin-attack.md', 'binary-explo

This commit is contained in:
Translator 2024-06-16 08:46:17 +00:00
parent 79271ebfec
commit 382e968ad6
3 changed files with 52 additions and 41 deletions

View file

@ -10,7 +10,7 @@ Altri modi per supportare HackTricks:
* 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) github repos.
* **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>
@ -22,7 +22,7 @@ Per ulteriori informazioni su cosa sia un fast bin, controlla questa pagina:
[bins-and-memory-allocations.md](bins-and-memory-allocations.md)
{% endcontent-ref %}
Poiché il fast bin è single linked, ci sono molte meno protezioni rispetto ad altri bin e semplicemente **modificare un indirizzo in un chunk fast bin liberato** è sufficiente per poter **allocare successivamente un chunk in qualsiasi indirizzo di memoria**.
Poiché il fast bin è singolarmente collegato, ci sono molte meno protezioni rispetto ad altri bin e semplicemente **modificare un indirizzo in un chunk fast bin liberato** è sufficiente per poter **allocare successivamente un chunk in qualsiasi indirizzo di memoria**.
In sintesi:
@ -141,15 +141,19 @@ Se è possibile sovrascrivere il valore della variabile globale **`global_max_fa
* **CTF** [**https://guyinatuxedo.github.io/28-fastbin\_attack/0ctf\_babyheap/index.html**](https://guyinatuxedo.github.io/28-fastbin\_attack/0ctf\_babyheap/index.html)**:**
* È possibile allocare chunk, liberarli, leggerne i contenuti e riempirli (con una vulnerabilità di overflow).
* **Consolidare chunk per infoleak**: La tecnica consiste nell'abuso dell'overflow per creare una dimensione previa fittizia in modo che un chunk precedente venga inserito in uno più grande, quindi quando si alloca il più grande contenente un altro chunk, è possibile stamparne i dati e ottenere un indirizzo a libc (main\_arena+88).
* **Sovrascrivere l'hook di malloc**: Per fare ciò, e sfruttando la situazione di sovrapposizione precedente, è stato possibile avere 2 chunk che puntavano alla stessa memoria. Di conseguenza, liberandoli entrambi (liberando un altro chunk in mezzo per evitare protezioni) è stato possibile avere lo stesso chunk nel fast bin 2 volte. Quindi, è stato possibile allocarlo di nuovo, sovrascrivere l'indirizzo al chunk successivo in modo che punti un po' prima di malloc\_hook (in modo che punti a un intero che malloc pensa sia una dimensione libera - un altro bypass), allocarlo di nuovo e quindi allocare un altro chunk che riceverà un indirizzo agli hook di malloc.\
Infine è stato scritto un **one gadget** lì.
* **Consolidare chunk per infoleak**: La tecnica consiste nell'abusare dell'overflow per creare una fake prev\_size in modo che un chunk precedente venga inserito all'interno di uno più grande, quindi quando si alloca il chunk più grande contenente un altro chunk, è possibile stamparne i dati e ottenere un leak di un indirizzo a libc (main\_arena+88).
* **Sovrascrivere malloc hook**: Per fare ciò, e sfruttando la situazione di sovrapposizione precedente, è stato possibile avere 2 chunk che puntavano alla stessa memoria. Di conseguenza, liberandoli entrambi (liberando un altro chunk in mezzo per evitare protezioni) è stato possibile avere lo stesso chunk nel fast bin 2 volte. Poi, è stato possibile allocarlo di nuovo, sovrascrivere l'indirizzo al prossimo chunk in modo che punti un po' prima di malloc\_hook (in modo che punti a un intero che malloc pensa sia una dimensione libera - un altro bypass), allocarlo di nuovo e quindi allocare un altro chunk che riceverà un indirizzo ai malloc hooks.\
Infine è stato scritto un **one gadget** dentro.
* **CTF** [**https://guyinatuxedo.github.io/28-fastbin\_attack/csaw17\_auir/index.html**](https://guyinatuxedo.github.io/28-fastbin\_attack/csaw17\_auir/index.html)**:**
* C'è un heap overflow e user after free e double free perché quando un chunk viene liberato è possibile riutilizzare e liberare nuovamente i puntatori.
* **Leak di informazioni su Libc**: Basta liberare alcuni chunk e otterranno un puntatore a una parte della posizione dell'arena principale. Poiché è possibile riutilizzare i puntatori liberati, basta leggere questo indirizzo.
* C'è un heap overflow e user after free e double free perché quando un chunk viene liberato è possibile riutilizzare e liberare di nuovo i puntatori.
* **Libc info leak**: Basta liberare alcuni chunk e otterranno un puntatore a una parte della posizione dell'arena principale. Poiché è possibile riutilizzare i puntatori liberati, basta leggere questo indirizzo.
* **Attacco fast bin**: Tutti i puntatori alle allocazioni sono memorizzati all'interno di un array, quindi possiamo liberare un paio di chunk fast bin e nell'ultimo sovrascrivere l'indirizzo per puntare un po' prima di questo array di puntatori. Quindi, allocare un paio di chunk con la stessa dimensione e otterremo prima quello legittimo e poi quello falso contenente l'array di puntatori. Ora possiamo sovrascrivere questi puntatori di allocazione per puntare all'indirizzo got di `free` per puntare a system e quindi scrivere il chunk 1 `"/bin/sh"` per poi `free(chunk1)` che eseguirà `system("/bin/sh")`.
* Puoi trovare un attacco Fast Bin abusato attraverso un attacco unsorted bin.
* Nota&#x20;
* **CTF** [**https://guyinatuxedo.github.io/33-custom\_misc\_heap/csaw19\_traveller/index.html**](https://guyinatuxedo.github.io/33-custom\_misc\_heap/csaw19\_traveller/index.html)
* Un altro esempio di abuso di un overflow di 1B per consolidare chunk nell'unsorted bin e ottenere un infoleak di libc e quindi eseguire un attacco fast bin per sovrascrivere malloc hook con un indirizzo one gadget
* **CTF** [**https://guyinatuxedo.github.io/33-custom\_misc\_heap/csaw18\_alienVSsamurai/index.html**](https://guyinatuxedo.github.io/33-custom\_misc\_heap/csaw18\_alienVSsamurai/index.html)
* Dopo un infoleak abusando dell'unsorted bin con un UAF per leakare un indirizzo libc e un indirizzo PIE, lo sfruttamento di questo CTF ha utilizzato un attacco fast bin per allocare un chunk in un punto in cui erano situati i puntatori ai chunk controllati, quindi è stato possibile sovrascrivere certi puntatori per scrivere un one gadget nel GOT
* Puoi trovare un attacco Fast Bin abusato attraverso un attacco unsorted bin:
* Nota che è comune prima di eseguire attacchi fast bin abusare della lista non piaciuta per leakare indirizzi libc/heap (quando necessario).
{% content-ref url="unsorted-bin-attack.md" %}
[unsorted-bin-attack.md](unsorted-bin-attack.md)
@ -163,8 +167,8 @@ 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 PEASS & HackTricks**](https://peass.creator-spring.com)
* Scopri [**The PEASS Family**](https://opensea.io/collection/the-peass-family), la nostra collezione di esclusivi [**NFT**](https://opensea.io/collection/the-peass-family)
* 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 ai** [**HackTricks**](https://github.com/carlospolop/hacktricks) e [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) repository di github.
* **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>

View file

@ -115,12 +115,12 @@ Poiché potenzialmente l'utente può leggere/scrivere anche le altre allocazioni
<figure><img src="../../.gitbook/assets/image (1245).png" alt=""><figcaption><p><a href="https://heap-exploitation.dhavalkapil.com/attacks/unlink_exploit">https://heap-exploitation.dhavalkapil.com/attacks/unlink_exploit</a></p></figcaption></figure>
* Gli header del chunk2 vengono modificati per indicare che il chunk precedente non è utilizzato e che la dimensione è la dimensione del chunk falso contenuto.
* Quando il secondo chunk viene liberato, allora avviene questo scollegamento del chunk falso:
* Quando il secondo chunk viene liberato, avviene lo scollegamento di questo chunk falso:
* `fake_chunk->fd->bk` = `fake_chunk->bk`
* `fake_chunk->bk->fd` = `fake_chunk->fd`
* In precedenza è stato fatto in modo che `fake_chunk->fd->bk` e `fake_chunk->fd->bk` puntassero allo stesso posto (la posizione nello stack dove `chunk1` era memorizzato, quindi era una lista concatenata valida). Poiché **entrambi puntano alla stessa posizione**, solo l'ultimo (`fake_chunk->bk->fd = fake_chunk->fd`) avrà **effetto**.
* Questo sovrascriverà il puntatore a chunk1 nello stack con l'indirizzo (o byte) memorizzato 3 indirizzi prima nello stack.
* Pertanto, se un attaccante potesse controllare nuovamente il contenuto del chunk1, sarà in grado di **scrivere all'interno dello stack** potenzialmente sovrascrivendo l'indirizzo di ritorno saltando il canary e modificando i valori e i puntatori delle variabili locali. Anche modificando nuovamente l'indirizzo di chunk1 memorizzato nello stack in una posizione diversa dove se l'attaccante potesse controllare nuovamente il contenuto di chunk1 sarà in grado di scrivere ovunque.
* Pertanto, se un attaccante potesse controllare nuovamente il contenuto del chunk1, sarà in grado di **scrivere all'interno dello stack** potenzialmente sovrascrivendo l'indirizzo di ritorno saltando il canary e modificando i valori e i puntatori delle variabili locali. Anche modificando nuovamente l'indirizzo di chunk1 memorizzato nello stack in una posizione diversa dove, se l'attaccante potesse controllare nuovamente il contenuto di chunk1, sarà in grado di scrivere ovunque.
* Notare che ciò è stato possibile perché gli **indirizzi sono memorizzati nello stack**. Il rischio e lo sfruttamento potrebbero dipendere da **dove sono memorizzati gli indirizzi del chunk falso**.
<figure><img src="../../.gitbook/assets/image (1246).png" alt=""><figcaption><p><a href="https://heap-exploitation.dhavalkapil.com/attacks/unlink_exploit">https://heap-exploitation.dhavalkapil.com/attacks/unlink_exploit</a></p></figcaption></figure>
@ -128,11 +128,13 @@ Poiché potenzialmente l'utente può leggere/scrivere anche le altre allocazioni
## Riferimenti
* [https://heap-exploitation.dhavalkapil.com/attacks/unlink\_exploit](https://heap-exploitation.dhavalkapil.com/attacks/unlink\_exploit)
* Anche se sarebbe strano trovare un attacco di unlink persino in un CTF, ecco alcuni writeup in cui è stato utilizzato questo attacco:
* Anche se sarebbe strano trovare un attacco di unlink anche in un CTF, ecco alcuni writeup in cui è stato utilizzato questo attacco:
* Esempio di CTF: [https://guyinatuxedo.github.io/30-unlink/hitcon14\_stkof/index.html](https://guyinatuxedo.github.io/30-unlink/hitcon14\_stkof/index.html)
* In questo esempio, invece dello stack c'è un array di indirizzi mallocati. L'attacco di unlink viene eseguito per poter allocare un chunk qui, quindi essere in grado di controllare i puntatori dell'array di indirizzi mallocati. Poi, c'è un'altra funzionalità che consente di modificare il contenuto dei chunk in questi indirizzi, il che consente di puntare gli indirizzi alla GOT, modificare gli indirizzi delle funzioni per ottenere leak di libc e RCE.
* In questo esempio, invece dello stack c'è un array di indirizzi malloc'ati. L'attacco di unlink viene eseguito per poter allocare un chunk qui, quindi essere in grado di controllare i puntatori dell'array di indirizzi malloc'ati. Poi, c'è un'altra funzionalità che consente di modificare il contenuto dei chunk in questi indirizzi, il che consente di puntare gli indirizzi alla GOT, modificare gli indirizzi delle funzioni per ottenere leak di libc e RCE.
* Altro esempio di CTF: [https://guyinatuxedo.github.io/30-unlink/zctf16\_note2/index.html](https://guyinatuxedo.github.io/30-unlink/zctf16\_note2/index.html)
* Proprio come nel precedente esempio, c'è un array di indirizzi di allocazioni. È possibile eseguire un attacco di unlink per far sì che l'indirizzo della prima allocazione punti a poche posizioni prima dell'inizio dell'array e sovrascrivere quindi questa allocazione nella nuova posizione. Pertanto, è possibile sovrascrivere i puntatori di altre allocazioni per puntare alla GOT di atoi, stamparla per ottenere un leak di libc e quindi sovrascrivere la GOT di atoi con l'indirizzo di un one gadget.
* Proprio come nel precedente esempio, c'è un array di indirizzi di allocazioni. È possibile eseguire un attacco di unlink per far sì che l'indirizzo della prima allocazione punti a poche posizioni prima dell'inizio dell'array e sovrascrivere quindi questa allocazione nella nuova posizione. Pertanto, è possibile sovrascrivere i puntatori di altre allocazioni per puntare alla GOT di atoi, stamparla per ottenere un leak di libc e quindi sovrascrivere atoi GOT con l'indirizzo di un one gadget.
* Esempio di CTF con funzioni malloc e free personalizzate che sfruttano una vulnerabilità molto simile all'attacco di unlink: [https://guyinatuxedo.github.io/33-custom\_misc\_heap/csaw17\_minesweeper/index.html](https://guyinatuxedo.github.io/33-custom\_misc\_heap/csaw17\_minesweeper/index.html)
* C'è un overflow che consente di controllare i puntatori FD e BK del malloc personalizzato che verrà liberato (personalizzato). Inoltre, l'heap ha il bit exec, quindi è possibile estrarre un indirizzo dell'heap e puntare una funzione dalla GOT a un chunk dell'heap con un shellcode per eseguire.
<details>
@ -144,6 +146,6 @@ Altri modi per supportare HackTricks:
* Ottieni il [**merchandising ufficiale 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 ai** [**HackTricks**](https://github.com/carlospolop/hacktricks) e [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) repository di github.
* **Condividi i tuoi trucchi di hacking inviando PR ai** [**HackTricks**](https://github.com/carlospolop/hacktricks) e [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) github repos.
</details>

View file

@ -2,7 +2,7 @@
<details>
<summary><strong>Impara l'hacking di AWS da zero a eroe con</strong> <a href="https://training.hacktricks.xyz/courses/arte"><strong>htARTE (Esperto Red Team AWS di HackTricks)</strong></a><strong>!</strong></summary>
<summary><strong>Impara l'hacking AWS da zero a eroe 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:
@ -10,7 +10,7 @@ Altri modi per supportare HackTricks:
* 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.
* **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>
@ -24,43 +24,46 @@ Per ulteriori informazioni su cosa sia un bin non ordinato, controlla questa pag
Le liste non ordinate sono in grado di scrivere l'indirizzo in `unsorted_chunks (av)` nell'indirizzo `bk` del chunk. Pertanto, se un attaccante può **modificare l'indirizzo del puntatore bk** in un chunk all'interno del bin non ordinato, potrebbe essere in grado di **scrivere quell'indirizzo in un indirizzo arbitrario** che potrebbe essere utile per ottenere un indirizzo libc o bypassare alcune difese.
Quindi, fondamentalmente, questo attacco permette di **sovrascrivere un indirizzo arbitrario con un numero grande** (un indirizzo che potrebbe essere un indirizzo di heap o un indirizzo libc) come un indirizzo di stack che potrebbe essere rilevato o una restrizione come la variabile globale **`global_max_fast`** per consentire di creare bin veloci con dimensioni maggiori (e passare da un attacco al bin non ordinato a un attacco al bin veloce).
Quindi, fondamentalmente, questo attacco permette di **sovrascrivere un indirizzo arbitrario con un numero grande** (un indirizzo che potrebbe essere un indirizzo di heap o un indirizzo libc) come un indirizzo di stack che potrebbe essere rivelato o una restrizione come la variabile globale **`global_max_fast`** per consentire di creare bin veloci con dimensioni maggiori (e passare da un attacco al bin non ordinato a un attacco al bin veloce).
{% hint style="success" %}
Guardando l'esempio fornito in [https://ctf-wiki.mahaloz.re/pwn/linux/glibc-heap/unsorted\_bin\_attack/#principle](https://ctf-wiki.mahaloz.re/pwn/linux/glibc-heap/unsorted\_bin\_attack/#principle) e utilizzando 0x4000 e 0x5000 invece di 0x400 e 0x500 come dimensioni dei chunk (per evitare i tcaches) è possibile vedere che **oggi** l'errore **`malloc(): unsorted double linked list corrupted`** viene attivato.
Guardando l'esempio fornito in [https://ctf-wiki.mahaloz.re/pwn/linux/glibc-heap/unsorted\_bin\_attack/#principle](https://ctf-wiki.mahaloz.re/pwn/linux/glibc-heap/unsorted\_bin\_attack/#principle) e utilizzando 0x4000 e 0x5000 invece di 0x400 e 0x500 come dimensioni dei chunk (per evitare tcaches) è possibile vedere che **oggi** l'errore **`malloc(): unsorted double linked list corrupted`** viene attivato.
Pertanto, questo attacco al bin non ordinato ora (tra altri controlli) richiede anche di essere in grado di correggere la lista doppiamente collegata in modo che venga bypassato `victim->bck->fd == victim` o no `victim->fd == av (arena)`. Ciò significa che l'indirizzo in cui vogliamo scrivere deve avere l'indirizzo del chunk falso nella sua posizione `fd` e che il `fd` del chunk falso punti all'arena.
Pertanto, questo attacco al bin non ordinato ora (tra altri controlli) richiede anche di essere in grado di correggere la lista doppiamente collegata in modo che venga bypassato `victim->bck->fd == victim` o non `victim->fd == av (arena)`. Ciò significa che l'indirizzo in cui vogliamo scrivere deve avere l'indirizzo del chunk falso nella sua posizione `fd` e che il `fd` del chunk falso punti all'arena.
{% endhint %}
{% hint style="danger" %}
Nota che questo attacco corrompe il bin non ordinato (quindi anche quello piccolo e grande). Quindi possiamo **usare solo assegnazioni dal bin veloce ora** (un programma più complesso potrebbe fare altre assegnazioni e bloccarsi), e per attivare questo dobbiamo **assegnare la stessa dimensione o il programma si bloccherà.**
Nota che questo attacco corrompe il bin non ordinato (quindi anche piccolo e grande). Quindi possiamo **usare solo allocazioni dal bin veloce ora** (un programma più complesso potrebbe fare altre allocazioni e bloccarsi), e per attivare questo dobbiamo **allocare la stessa dimensione o il programma si bloccherà.**
Nota che rendere **`global_max_fast`** potrebbe aiutare in questo caso fidandosi che il bin veloce sarà in grado di gestire tutte le altre assegnazioni fino a quando l'exploit non è completato.
Nota che rendere **`global_max_fast`** potrebbe aiutare in questo caso fidandosi che il bin veloce sarà in grado di gestire tutte le altre allocazioni fino a quando l'exploit non è completato.
{% endhint %}
Il codice di [**guyinatuxedo**](https://guyinatuxedo.github.io/31-unsortedbin\_attack/unsorted\_explanation/index.html) lo spiega molto bene, anche se se si modificano le malloc per allocare memoria sufficientemente grande in modo che non finisca in un tcache, si può vedere che compare l'errore precedentemente menzionato: **`malloc(): unsorted double linked list corrupted`**
Il codice di [**guyinatuxedo**](https://guyinatuxedo.github.io/31-unsortedbin\_attack/unsorted\_explanation/index.html) lo spiega molto bene, anche se se si modificano le malloc per allocare memoria sufficientemente grande in modo che non finisca in un tcache, si può vedere che compare l'errore precedentemente menzionato impedendo questa tecnica: **`malloc(): unsorted double linked list corrupted`**
## Attacco di Infoleak al Bin non ordinato
Questo è in realtà un concetto molto basilare. I chunk nel bin non ordinato avranno puntatori doppi per creare il bin. Il primo chunk nel bin non ordinato avrà effettivamente i collegamenti **FD** e **BK** **che puntano a una parte dell'arena principale (libc)**.\
Pertanto, se puoi **mettere un chunk all'interno di un bin non ordinato e leggerlo** (uso dopo la liberazione) o **allocarlo di nuovo senza sovrascrivere almeno 1 dei puntatori** per poi **leggerlo**, puoi ottenere un **leak di info sulla libc**.
Pertanto, se puoi **mettere un chunk all'interno di un bin non ordinato e leggerlo** (uso dopo la liberazione) o **allocarlo di nuovo senza sovrascrivere almeno 1 dei puntatori** per poi **leggerlo**, puoi ottenere un **leak di info libc**.
Un [**attacco simile usato in questo articolo**](https://guyinatuxedo.github.io/33-custom\_misc\_heap/csaw18\_alienVSsamurai/index.html), è stato quello di abusare di una struttura a 4 chunk (A, B, C e D - D serve solo per evitare la consolidazione con il chunk superiore) in modo che un overflow di byte nullo in B fosse usato per far sì che C indicasse che B non era utilizzato. Inoltre, in B è stata modificata la data `prev_size` in modo che la dimensione anziché essere la dimensione di B fosse A+B.\
Quindi C è stata deallocata e consolidata con A+B (ma B era ancora in uso). È stato allocato un nuovo chunk di dimensione A e quindi gli indirizzi libc trapelati sono stati scritti in B da dove sono trapelati.
## Riferimenti e Altri esempi
* [**https://ctf-wiki.mahaloz.re/pwn/linux/glibc-heap/unsorted\_bin\_attack/#hitcon-training-lab14-magic-heap**](https://ctf-wiki.mahaloz.re/pwn/linux/glibc-heap/unsorted\_bin\_attack/#hitcon-training-lab14-magic-heap)
* L'obiettivo è sovrascrivere una variabile globale con un valore maggiore di 4869 in modo da poter ottenere il flag e PIE non è abilitato.
* È possibile generare chunk di dimensioni arbitrarie e c'è un overflow di heap con la dimensione desiderata.
* L'attacco inizia creando 3 chunk: chunk0 per sfruttare l'overflow, chunk1 per essere sovrascritto e chunk2 in modo che il chunk superiore non consolidi quelli precedenti.
* Quindi, chunk1 viene liberato e chunk0 viene sovrascritto in modo che il puntatore `bk` di chunk1 punti a: `bk = magic - 0x10`
* L'attacco inizia creando 3 chunk: chunk0 per sfruttare l'overflow, chunk1 per essere sovraffollato e chunk2 in modo che il chunk superiore non consolidi quelli precedenti.
* Quindi, chunk1 viene liberato e chunk0 viene sovraffollato in modo che il puntatore `bk` di chunk1 punti a: `bk = magic - 0x10`
* Quindi, chunk3 viene allocato con la stessa dimensione di chunk1, il che attiverà l'attacco al bin non ordinato e modificherà il valore della variabile globale, rendendo possibile ottenere il flag.
* [**https://guyinatuxedo.github.io/31-unsortedbin\_attack/0ctf16\_zerostorage/index.html**](https://guyinatuxedo.github.io/31-unsortedbin\_attack/0ctf16\_zerostorage/index.html)
* La funzione di merge è vulnerabile perché se entrambi gli indici passati sono gli stessi, realloc su di esso e poi lo libera ma restituisce un puntatore a quella regione liberata che può essere utilizzato.
* Pertanto, **vengono creati 2 chunk**: **chunk0** che verrà unito con se stesso e chunk1 per evitare la consolidazione con il chunk superiore. Quindi, la **funzione di merge viene chiamata con chunk0** due volte, causando un uso dopo la liberazione.
* Quindi, la funzione **`view`** viene chiamata con l'indice 2 (che è l'indice del chunk uso dopo la liberazione), che **fa trapelare un indirizzo libc**.
* La funzione di merge è vulnerabile perché se entrambi gli indici passati sono gli stessi, realloc su di esso e quindi lo libera ma restituisce un puntatore a quella regione liberata che può essere utilizzato.
* Pertanto, **vengono creati 2 chunk**: **chunk0** che verrà unito con se stesso e chunk1 per evitare la consolidazione con il chunk superiore. Quindi, la **funzione di merge viene chiamata con chunk0** due volte, il che causerà un uso dopo la liberazione.
* Quindi, la funzione **`view`** viene chiamata con l'indice 2 (che è l'indice del chunk in uso dopo la liberazione), che **fa trapelare un indirizzo libc**.
* Poiché il binario ha protezioni per allocare solo dimensioni maggiori di **`global_max_fast`** quindi nessun fastbin viene utilizzato, verrà utilizzato un attacco al bin non ordinato per sovrascrivere la variabile globale `global_max_fast`.
* Quindi, è possibile chiamare la funzione di modifica con l'indice 2 (il puntatore uso dopo la liberazione) e sovrascrivere il puntatore `bk` per puntare a `p64(global_max_fast-0x10)`. Quindi, creando un nuovo chunk userà l'indirizzo di free compromesso in precedenza (0x20) attiverà l'attacco al bin non ordinato sovrascrivendo il `global_max_fast` con un valore molto grande, consentendo ora di creare chunk nei bin veloci.
* Ora viene eseguito un **attacco al bin veloce**:
* Prima di tutto si scopre che è possibile lavorare con **chunk veloci di dimensione 200** nella posizione **`__free_hook`**:
* Quindi, è possibile chiamare la funzione di modifica con l'indice 2 (il puntatore in uso dopo la liberazione) e sovrascrivere il puntatore `bk` per puntare a `p64(global_max_fast-0x10)`. Quindi, creando un nuovo chunk userà l'indirizzo di free compromesso in precedenza (0x20) attiverà l'attacco al bin non ordinato sovrascrivendo il `global_max_fast` con un valore molto grande, consentendo ora di creare chunk nei bin veloci.
* Ora viene eseguito un **attacco al fast bin**:
* Prima di tutto è stato scoperto che è possibile lavorare con **chunk veloci di dimensione 200** nella posizione di **`__free_hook`**:
* <pre class="language-c"><code class="lang-c">gef➤ p &#x26;__free_hook
$1 = (void (**)(void *, const void *)) 0x7ff1e9e607a8 &#x3C;__free_hook>
gef➤ x/60gx 0x7ff1e9e607a8 - 0x59
@ -69,15 +72,17 @@ gef➤ x/60gx 0x7ff1e9e607a8 - 0x59
0x7ff1e9e6076f &#x3C;list_all_lock+15>: 0x0000000000000000 0x0000000000000000
0x7ff1e9e6077f &#x3C;_IO_stdfile_2_lock+15>: 0x0000000000000000 0x0000000000000000
</code></pre>
* Se riusciamo ad ottenere un fast chunk di dimensione 0x200 in questa posizione, sarà possibile sovrascrivere un puntatore a funzione che verrà eseguito
* Per fare ciò, viene creato un nuovo chunk di dimensione `0xfc` e la funzione merged viene chiamata con quel puntatore due volte, in questo modo otteniamo un puntatore a un chunk liberato di dimensione `0xfc*2 = 0x1f8` nel fast bin.
* Successivamente, la funzione edit viene chiamata in questo chunk per modificare l'indirizzo **`fd`** di questo fast bin in modo che punti alla precedente funzione **`__free_hook`**.
* Poi, viene creato un chunk di dimensione `0x1f8` per recuperare dal fast bin il chunk inutile precedente, quindi viene creato un altro chunk di dimensione `0x1f8` per ottenere un chunk fast bin nel **`__free_hook`** che viene sovrascritto con l'indirizzo della funzione **`system`**.
* Infine, viene liberato un chunk contenente la stringa `/bin/sh\x00` chiamando la funzione delete, attivando la funzione **`__free_hook`** che punta a system con `/bin/sh\x00` come parametro.
* Se riusciamo a ottenere un chunk veloce di dimensione 0x200 in questa posizione, sarà possibile sovrascrivere un puntatore di funzione che verrà eseguito
* Per fare ciò, viene creato un nuovo chunk di dimensione `0xfc` e la funzione unita viene chiamata con quel puntatore due volte, in questo modo otteniamo un puntatore a un chunk liberato di dimensione `0xfc*2 = 0x1f8` nel fast bin.
* Successivamente, la funzione di modifica viene chiamata in questo chunk per modificare l'indirizzo **`fd`** di questo fast bin in modo che punti alla funzione precedente **`__free_hook`**.
* Quindi, viene creato un chunk con dimensione `0x1f8` per recuperare dal fast bin il chunk inutile precedente, quindi viene creato un altro chunk di dimensione `0x1f8` per ottenere un chunk fast bin nel **`__free_hook`** che viene sovrascritto con l'indirizzo della funzione **`system`**.
* Infine, viene liberato un chunk contenente la stringa `/bin/sh\x00` chiamando la funzione di eliminazione, attivando la funzione **`__free_hook`** che punta a system con `/bin/sh\x00` come parametro.
* **CTF** [**https://guyinatuxedo.github.io/33-custom\_misc\_heap/csaw19\_traveller/index.html**](https://guyinatuxedo.github.io/33-custom\_misc\_heap/csaw19\_traveller/index.html)
* Un altro esempio di abuso di un overflow di 1B per consolidare i chunk nel bin non ordinato e ottenere un infoleak della libc e quindi eseguire un attacco fast bin per sovrascrivere l'hook di malloc con un indirizzo one gadget
<details>
<summary><strong>Impara l'hacking su AWS da zero a esperto con</strong> <a href="https://training.hacktricks.xyz/courses/arte"><strong>htARTE (HackTricks AWS Red Team Expert)</strong></a><strong>!</strong></summary>
<summary><strong>Impara l'hacking su 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:
@ -85,6 +90,6 @@ Altri modi per supportare HackTricks:
* Ottieni il [**merchandising ufficiale 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.
* **Condividi i tuoi trucchi di hacking inviando PR ai** [**HackTricks**](https://github.com/carlospolop/hacktricks) e [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) repos di github.
</details>