mirror of
https://github.com/carlospolop/hacktricks
synced 2024-11-26 22:52:06 +00:00
101 lines
11 KiB
Markdown
101 lines
11 KiB
Markdown
# Attacco al Bin non ordinato
|
|
|
|
{% hint style="success" %}
|
|
Impara e pratica l'Hacking AWS:<img src="/.gitbook/assets/arte.png" alt="" data-size="line">[**HackTricks Training AWS Red Team Expert (ARTE)**](https://training.hacktricks.xyz/courses/arte)<img src="/.gitbook/assets/arte.png" alt="" data-size="line">\
|
|
Impara e pratica l'Hacking GCP: <img src="/.gitbook/assets/grte.png" alt="" data-size="line">[**HackTricks Training GCP Red Team Expert (GRTE)**<img src="/.gitbook/assets/grte.png" alt="" data-size="line">](https://training.hacktricks.xyz/courses/grte)
|
|
|
|
<details>
|
|
|
|
<summary>Sostieni HackTricks</summary>
|
|
|
|
* Controlla i [**piani di abbonamento**](https://github.com/sponsors/carlospolop)!
|
|
* **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 trucchi di hacking inviando PR ai** [**HackTricks**](https://github.com/carlospolop/hacktricks) e [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) repository di GitHub.
|
|
|
|
</details>
|
|
{% endhint %}
|
|
|
|
## Informazioni di Base
|
|
|
|
Per ulteriori informazioni su cosa sia un bin non ordinato, controlla questa pagina:
|
|
|
|
{% content-ref url="bins-and-memory-allocations.md" %}
|
|
[bins-and-memory-allocations.md](bins-and-memory-allocations.md)
|
|
{% endcontent-ref %}
|
|
|
|
Le liste non ordinate sono in grado di scrivere l'indirizzo a `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 Glibc o bypassare alcune difese.
|
|
|
|
Quindi, fondamentalmente, questo attacco consente di **impostare un grande numero in un indirizzo arbitrario**. Questo grande numero è un indirizzo, che potrebbe essere un indirizzo di heap o un indirizzo Glibc. Un obiettivo tipico è **`global_max_fast`** per consentire la creazione di 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 Tcache) è possibile vedere che **oggi** l'errore **`malloc(): unsorted double linked list corrupted`** viene attivato.
|
|
|
|
Pertanto, questo attacco al bin non ordinato ora (tra gli altri controlli) richiede anche di essere in grado di correggere la lista doppiamente collegata in modo che questo venga bypassato `victim->bk->fd == victim` o no `victim->fd == av (arena)`, il che 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 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 sovrascrivere **`global_max_fast`** potrebbe aiutare in questo caso fidandosi che il bin veloce sarà in grado di gestire tutte le altre allocazioni fino al completamento dell'exploit.
|
|
{% 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, è possibile vedere che compare l'errore precedentemente menzionato che impedisce 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 dei puntatori. Il primo chunk nel bin non ordinato avrà effettivamente i collegamenti **`fd`** e **`bk`** **che puntano a una parte dell'arena principale (Glibc)**.\
|
|
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 **info leak di Glibc**.
|
|
|
|
Un [**attacco simile usato in questo writeup**](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 utilizzato 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 leaked di libc sono stati scritti in B da dove sono stati leaked.
|
|
|
|
## 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 heap overflow con la dimensione desiderata.
|
|
* L'attacco inizia creando 3 chunk: chunk0 per sfruttare l'overflow, chunk1 per essere overflowed e chunk2 in modo che il chunk superiore non consolidi quelli precedenti.
|
|
* Quindi, chunk1 viene liberato e chunk0 viene overflowed in modo che il puntatore `bk` di chunk1 punti a: `bk = magic - 0x10`
|
|
* Successivamente, 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, reallocerà su di esso e quindi lo libererà ma restituendo 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 **farà trapelare un indirizzo di libc**.
|
|
* Poiché il binario ha protezioni per allocare solo dimensioni maggiori di **`global_max_fast`** in modo che non venga utilizzato alcun fastbin, 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 è 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 &__free_hook
|
|
$1 = (void (**)(void *, const void *)) 0x7ff1e9e607a8 <__free_hook>
|
|
gef➤ x/60gx 0x7ff1e9e607a8 - 0x59
|
|
<strong>0x7ff1e9e6074f: 0x0000000000000000 0x0000000000000200
|
|
</strong>0x7ff1e9e6075f: 0x0000000000000000 0x0000000000000000
|
|
0x7ff1e9e6076f <list_all_lock+15>: 0x0000000000000000 0x0000000000000000
|
|
0x7ff1e9e6077f <_IO_stdfile_2_lock+15>: 0x0000000000000000 0x0000000000000000
|
|
</code></pre>
|
|
* Se riusciamo a ottenere un chunk veloce 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 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`**.
|
|
* 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 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 al fast bin per sovrascrivere il hook di allocazione con un indirizzo one gadget
|
|
* [**Robot Factory. BlackHat MEA CTF 2022**](https://7rocky.github.io/en/ctf/other/blackhat-ctf/robot-factory/)
|
|
* Possiamo allocare solo chunk di dimensione maggiore di `0x100`.
|
|
* Sovrascrivere `global_max_fast` utilizzando un attacco al Unsorted Bin (funziona 1/16 volte a causa di ASLR, poiché dobbiamo modificare 12 bit, ma dobbiamo modificare 16 bit).
|
|
* Attacco al Fast Bin per modificare un array globale di chunk. Questo fornisce un primitivo di lettura/scrittura arbitrario, che consente di modificare il GOT e impostare alcune funzioni per puntare a `system`.
|
|
|
|
{% hint style="success" %}
|
|
Impara e pratica l'Hacking su AWS:<img src="/.gitbook/assets/arte.png" alt="" data-size="line">[**HackTricks Training AWS Red Team Expert (ARTE)**](https://training.hacktricks.xyz/courses/arte)<img src="/.gitbook/assets/arte.png" alt="" data-size="line">\
|
|
Impara e pratica l'Hacking su GCP: <img src="/.gitbook/assets/grte.png" alt="" data-size="line">[**HackTricks Training GCP Red Team Expert (GRTE)**<img src="/.gitbook/assets/grte.png" alt="" data-size="line">](https://training.hacktricks.xyz/courses/grte)
|
|
|
|
<details>
|
|
|
|
<summary>Sostieni HackTricks</summary>
|
|
|
|
* Controlla i [**piani di abbonamento**](https://github.com/sponsors/carlospolop)!
|
|
* **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 trucchi di hacking inviando PR ai** [**HackTricks**](https://github.com/carlospolop/hacktricks) e [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) github repos.
|
|
|
|
</details>
|
|
{% endhint %}
|