hacktricks/binary-exploitation/libc-heap/unsorted-bin-attack.md

# 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 &#x26;__free_hook
$1 = (void (**)(void *, const void *)) 0x7ff1e9e607a8 &#x3C;__free_hook>
gef➤  x/60gx 0x7ff1e9e607a8 - 0x59
<strong>0x7ff1e9e6074f: 0x0000000000000000      0x0000000000000200
</strong>0x7ff1e9e6075f: 0x0000000000000000      0x0000000000000000
0x7ff1e9e6076f &#x3C;list_all_lock+15>:      0x0000000000000000      0x0000000000000000
0x7ff1e9e6077f &#x3C;_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 %}