mirror of
https://github.com/carlospolop/hacktricks
synced 2024-11-24 05:33:33 +00:00
Translated ['binary-exploitation/heap/unlink-attack.md', 'binary-exploit
This commit is contained in:
parent
839b4fac36
commit
31a164d755
2 changed files with 30 additions and 31 deletions
|
@ -6,7 +6,7 @@
|
|||
|
||||
Outras maneiras de apoiar o HackTricks:
|
||||
|
||||
* Se você deseja ver sua **empresa anunciada no HackTricks** ou **baixar o HackTricks em PDF** Verifique os [**PLANOS DE ASSINATURA**](https://github.com/sponsors/carlospolop)!
|
||||
* Se você quiser ver sua **empresa anunciada no HackTricks** ou **baixar o HackTricks em PDF** Verifique os [**PLANOS DE ASSINATURA**](https://github.com/sponsors/carlospolop)!
|
||||
* Adquira o [**swag oficial PEASS & HackTricks**](https://peass.creator-spring.com)
|
||||
* Descubra [**A Família PEASS**](https://opensea.io/collection/the-peass-family), nossa coleção exclusiva de [**NFTs**](https://opensea.io/collection/the-peass-family)
|
||||
* **Junte-se ao** 💬 [**grupo Discord**](https://discord.gg/hRep4RUj7f) ou ao [**grupo telegram**](https://t.me/peass) ou **siga-nos** no **Twitter** 🐦 [**@hacktricks\_live**](https://twitter.com/hacktricks\_live)**.**
|
||||
|
@ -93,20 +93,24 @@ return 0;
|
|||
|
||||
### Objetivo
|
||||
|
||||
* Modificar um ponteiro para um chunk na pilha para que ele aponte para a pilha, tornando possível alterar o conteúdo da pilha escrevendo no chunk
|
||||
Este ataque permite **alterar um ponteiro para um chunk para apontar 3 endereços antes de si mesmo**. Se este novo local (arredores onde o ponteiro estava localizado) tiver informações interessantes, como outras alocações controláveis / pilha..., é possível ler/sobrescrevê-las para causar um dano maior.
|
||||
|
||||
* Se este ponteiro estava localizado na pilha, porque agora está apontando 3 endereços antes de si mesmo e o usuário potencialmente pode lê-lo e modificá-lo, será possível vazar informações sensíveis da pilha ou até mesmo modificar o endereço de retorno (talvez) sem tocar no canário
|
||||
* Em exemplos de CTF, este ponteiro está localizado em um array de ponteiros para outras alocações, portanto, fazendo-o apontar 3 endereços antes e sendo capaz de ler e escrever nele, é possível fazer com que os outros ponteiros apontem para outros endereços.\
|
||||
Como potencialmente o usuário pode ler/escrever também nas outras alocações, ele pode vazar informações ou sobrescrever novos endereços em locais arbitrários (como na GOT).
|
||||
|
||||
### Requisitos
|
||||
|
||||
* Algum controle em uma memória (por exemplo, pilha) para criar alguns chunks dando valores a alguns dos atributos.
|
||||
* Algum controle em uma memória (por exemplo, pilha) para criar um par de chunks dando valores a alguns dos atributos.
|
||||
* Vazamento de pilha para definir os ponteiros do chunk falso.
|
||||
|
||||
### Ataque
|
||||
|
||||
* Existem dois chunks (chunk1 e chunk2)
|
||||
* Existem um par de chunks (chunk1 e chunk2)
|
||||
* O atacante controla o conteúdo do chunk1 e os cabeçalhos do chunk2.
|
||||
* No chunk1, o atacante cria a estrutura de um chunk falso:
|
||||
* Para contornar proteções, ele garante que o campo `size` está correto para evitar o erro: `corrupted size vs. prev_size while consolidating`
|
||||
* e os campos `fd` e `bk` do chunk falso apontam para onde o ponteiro do chunk1 está armazenado com deslocamentos de -3 e -2, respectivamente, para que `fake_chunk->fd->bk` e `fake_chunk->bk->fd` apontem para a posição na memória (pilha) onde o endereço real do chunk1 está localizado:
|
||||
* e os campos `fd` e `bk` do chunk falso estão apontando para onde o ponteiro do chunk1 está armazenado com deslocamentos de -3 e -2 respectivamente, então `fake_chunk->fd->bk` e `fake_chunk->bk->fd` apontam para a posição na memória (pilha) onde o endereço real do chunk1 está localizado:
|
||||
|
||||
<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>
|
||||
|
||||
|
@ -114,9 +118,9 @@ return 0;
|
|||
* Quando o segundo chunk é liberado, então este chunk falso é desvinculado acontecendo:
|
||||
* `fake_chunk->fd->bk` = `fake_chunk->bk`
|
||||
* `fake_chunk->bk->fd` = `fake_chunk->fd`
|
||||
* Anteriormente foi feito com que `fake_chunk->fd->bk` e `fake_chunk->fd->bk` apontassem para o mesmo lugar (a localização na pilha onde `chunk1` estava armazenado, então era uma lista vinculada válida). Como **ambos estão apontando para a mesma localização**, apenas o último (`fake_chunk->bk->fd = fake_chunk->fd`) terá **efeito**.
|
||||
* Isso irá **sobrescrever o ponteiro para o chunk1 na pilha para o endereço (ou bytes) armazenado 3 endereços antes na pilha**.
|
||||
* Portanto, se um atacante puder controlar o conteúdo do chunk1 novamente, ele será capaz de **escrever dentro da pilha**, podendo potencialmente sobrescrever o endereço de retorno pulando o canário e modificar os valores e ponteiros de variáveis locais. Até mesmo modificando novamente o endereço do chunk1 armazenado na pilha para uma localização diferente onde, se o atacante puder controlar novamente o conteúdo do chunk1, ele será capaz de escrever em qualquer lugar.
|
||||
* Anteriormente foi feito com que `fake_chunk->fd->bk` e `fake_chunk->fd->bk` apontassem para o mesmo lugar (a localização na pilha onde `chunk1` estava armazenado, então era uma lista vinculada válida). Como **ambos estão apontando para o mesmo local**, apenas o último (`fake_chunk->bk->fd = fake_chunk->fd`) terá **efeito**.
|
||||
* Isso irá **sobrescrever o ponteiro para o chunk1 na pilha para o endereço (ou bytes) armazenados 3 endereços antes na pilha**.
|
||||
* Portanto, se um atacante puder controlar o conteúdo do chunk1 novamente, ele será capaz de **escrever dentro da pilha** sendo capaz de potencialmente sobrescrever o endereço de retorno pulando o canário e modificar os valores e ponteiros de variáveis locais. Até mesmo modificando novamente o endereço do chunk1 armazenado na pilha para um local diferente onde, se o atacante puder controlar novamente o conteúdo do chunk1, ele será capaz de escrever em qualquer lugar.
|
||||
* Note que isso foi possível porque os **endereços são armazenados na pilha**. O risco e a exploração podem depender de **onde os endereços para o chunk falso estão sendo armazenados**.
|
||||
|
||||
<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>
|
||||
|
@ -126,19 +130,6 @@ return 0;
|
|||
* [https://heap-exploitation.dhavalkapil.com/attacks/unlink\_exploit](https://heap-exploitation.dhavalkapil.com/attacks/unlink\_exploit)
|
||||
* Embora seja estranho encontrar um ataque de unlink mesmo em um CTF, aqui estão alguns writeups onde esse ataque foi usado:
|
||||
* Exemplo de CTF: [https://guyinatuxedo.github.io/30-unlink/hitcon14\_stkof/index.html](https://guyinatuxedo.github.io/30-unlink/hitcon14\_stkof/index.html)
|
||||
* Neste exemplo, em vez da pilha, há uma matriz de endereços malloc'ed. O ataque de unlink é realizado para poder alocar um chunk aqui, sendo capaz de controlar os ponteiros da matriz de endereços malloc'ed. Em seguida, há outra funcionalidade que permite modificar o conteúdo dos chunks nesses endereços, o que permite apontar endereços para o GOT, modificar endereços de funções para obter vazamentos e RCE.
|
||||
*
|
||||
|
||||
<details>
|
||||
|
||||
<summary><strong>Aprenda hacking AWS do zero ao herói com</strong> <a href="https://training.hacktricks.xyz/courses/arte"><strong>htARTE (HackTricks AWS Red Team Expert)</strong></a><strong>!</strong></summary>
|
||||
|
||||
Outras maneiras de apoiar o HackTricks:
|
||||
|
||||
* Se você quiser ver sua **empresa anunciada no HackTricks** ou **baixar o HackTricks em PDF** Confira os [**PLANOS DE ASSINATURA**](https://github.com/sponsors/carlospolop)!
|
||||
* Adquira o [**swag oficial PEASS & HackTricks**](https://peass.creator-spring.com)
|
||||
* Descubra [**A Família PEASS**](https://opensea.io/collection/the-peass-family), nossa coleção exclusiva de [**NFTs**](https://opensea.io/collection/the-peass-family)
|
||||
* **Junte-se ao** 💬 [**grupo Discord**](https://discord.gg/hRep4RUj7f) ou ao [**grupo telegram**](https://t.me/peass) ou **siga-nos** no **Twitter** 🐦 [**@hacktricks\_live**](https://twitter.com/hacktricks\_live)**.**
|
||||
* **Compartilhe seus truques de hacking enviando PRs para os** [**HackTricks**](https://github.com/carlospolop/hacktricks) e [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) github repos.
|
||||
|
||||
</details>
|
||||
* Neste exemplo, em vez da pilha, há um array de endereços malloc'ed. O ataque de unlink é realizado para poder alocar um chunk aqui, sendo capaz de controlar os ponteiros do array de endereços malloc'ed. Em seguida, há outra funcionalidade que permite modificar o conteúdo dos chunks nesses endereços, o que permite apontar endereços para a GOT, modificar endereços de função para obter vazamentos e RCE.
|
||||
* Outro exemplo de CTF: [https://guyinatuxedo.github.io/30-unlink/zctf16\_note2/index.html](https://guyinatuxedo.github.io/30-unlink/zctf16\_note2/index.html)
|
||||
* Assim como no exemplo anterior, há um array de endereços de alocações. É possível realizar um ataque de unlink para fazer o endereço da primeira alocação apontar algumas posições antes de começar o array e sobrescrever essa alocação na nova posição. Portanto, é possível sobrescrever ponteiros de outras alocações para apontar para a GOT de atoi, imprimi-la para obter um vazamento de libc e, em seguida, sobrescrever a GOT de atoi com o endereço de um one gadget.
|
||||
|
|
|
@ -6,8 +6,8 @@
|
|||
|
||||
Outras maneiras de apoiar o HackTricks:
|
||||
|
||||
* Se você quiser ver sua **empresa anunciada no HackTricks** ou **baixar o HackTricks em PDF** Verifique os [**PLANOS DE ASSINATURA**](https://github.com/sponsors/carlospolop)!
|
||||
* Adquira o [**swag oficial PEASS & HackTricks**](https://peass.creator-spring.com)
|
||||
* Se você deseja ver sua **empresa anunciada no HackTricks** ou **baixar o HackTricks em PDF** Verifique os [**PLANOS DE ASSINATURA**](https://github.com/sponsors/carlospolop)!
|
||||
* Adquira o [**swag oficial do PEASS & HackTricks**](https://peass.creator-spring.com)
|
||||
* Descubra [**A Família PEASS**](https://opensea.io/collection/the-peass-family), nossa coleção exclusiva de [**NFTs**](https://opensea.io/collection/the-peass-family)
|
||||
* **Junte-se ao** 💬 [**grupo Discord**](https://discord.gg/hRep4RUj7f) ou ao [**grupo telegram**](https://t.me/peass) ou **siga-nos** no **Twitter** 🐦 [**@hacktricks\_live**](https://twitter.com/hacktricks\_live)**.**
|
||||
* **Compartilhe seus truques de hacking enviando PRs para os** [**HackTricks**](https://github.com/carlospolop/hacktricks) e [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) repositórios do github.
|
||||
|
@ -20,13 +20,13 @@ Quando você libera memória em um programa usando glibc, diferentes "bins" são
|
|||
|
||||
### Bins Não Ordenados
|
||||
|
||||
Quando você libera um pedaço de memória que não é um pedaço rápido, ele vai para o bin não ordenado. Este bin age como uma lista onde novos pedaços liberados são adicionados à frente (a "cabeça"). Quando você solicita um novo pedaço de memória, o alocador olha para o bin não ordenado de trás (a "cauda") para encontrar um pedaço grande o suficiente. Se um pedaço do bin não ordenado for maior do que o que você precisa, ele é dividido, com a parte da frente sendo retornada e a parte restante permanecendo no bin.
|
||||
Quando você libera um pedaço de memória que não é um pedaço rápido, ele vai para o bin não ordenado. Este bin age como uma lista onde novos pedaços liberados são adicionados à frente (a "cabeça"). Quando você solicita um novo pedaço de memória, o alocador olha para o bin não ordenado de trás para frente (a "cauda") para encontrar um pedaço grande o suficiente. Se um pedaço do bin não ordenado for maior do que o que você precisa, ele é dividido, com a parte da frente sendo retornada e a parte restante permanecendo no bin.
|
||||
|
||||
Exemplo:
|
||||
|
||||
* Você aloca 300 bytes (`a`), então 250 bytes (`b`), libera `a` e solicita novamente 250 bytes (`c`).
|
||||
* Quando você libera `a`, ele vai para o bin não ordenado.
|
||||
* Se então você solicitar 250 bytes novamente, o alocador encontra `a` na cauda e o divide, retornando a parte que se encaixa em sua solicitação e mantendo o restante no bin.
|
||||
* Se você então solicitar 250 bytes novamente, o alocador encontra `a` na cauda e o divide, retornando a parte que se encaixa em sua solicitação e mantendo o restante no bin.
|
||||
* `c` estará apontando para o `a` anterior e preenchido com os `a's`.
|
||||
```c
|
||||
char *a = malloc(300);
|
||||
|
@ -59,6 +59,14 @@ d = malloc(20); // a
|
|||
```
|
||||
## Outras Referências e Exemplos
|
||||
|
||||
* [https://heap-exploitation.dhavalkapil.com/attacks/first\_fit](https://heap-exploitation.dhavalkapil.com/attacks/first\_fit)
|
||||
* [https://8ksec.io/arm64-reversing-and-exploitation-part-2-use-after-free/](https://8ksec.io/arm64-reversing-and-exploitation-part-2-use-after-free/)
|
||||
* ARM64. Use after free: Gerar um objeto de usuário, liberá-lo, gerar um objeto que obtém o bloco liberado e permite escrever nele, **sobrescrevendo a posição da senha do usuário** da anterior. Reutilizar o usuário para **burlar a verificação da senha**
|
||||
* [**https://heap-exploitation.dhavalkapil.com/attacks/first\_fit**](https://heap-exploitation.dhavalkapil.com/attacks/first\_fit)
|
||||
* [**https://8ksec.io/arm64-reversing-and-exploitation-part-2-use-after-free/**](https://8ksec.io/arm64-reversing-and-exploitation-part-2-use-after-free/)
|
||||
* ARM64. Use after free: Gerar um objeto de usuário, liberá-lo, gerar um objeto que recebe o chunk liberado e permite escrever nele, **sobrescrevendo a posição de user->password** do anterior. Reutilizar o usuário para **burlar a verificação de senha**
|
||||
* [**https://ctf-wiki.mahaloz.re/pwn/linux/glibc-heap/use\_after\_free/#example**](https://ctf-wiki.mahaloz.re/pwn/linux/glibc-heap/use\_after\_free/#example)
|
||||
* O programa permite criar notas. Uma nota terá as informações da nota em um malloc(8) (com um ponteiro para uma função que pode ser chamada) e um ponteiro para outro malloc(\<size>) com o conteúdo da nota.
|
||||
* O ataque seria criar 2 notas (nota0 e nota1) com conteúdos de malloc maiores do que o tamanho das informações da nota e, em seguida, liberá-las para que entrem no fast bin (ou tcache).
|
||||
* Em seguida, criar outra nota (nota2) com tamanho de conteúdo 8. O conteúdo estará na nota1, pois o chunk será reutilizado, onde poderíamos modificar o ponteiro da função para apontar para a função win e, em seguida, Use-After-Free na nota1 para chamar o novo ponteiro da função.
|
||||
* [**https://guyinatuxedo.github.io/26-heap\_grooming/pico\_areyouroot/index.html**](https://guyinatuxedo.github.io/26-heap\_grooming/pico\_areyouroot/index.html)
|
||||
* É possível alocar alguma memória, escrever o valor desejado, liberá-lo, realocá-lo e como os dados anteriores ainda estão lá, eles serão tratados de acordo com a nova estrutura esperada no chunk, tornando possível definir o valor ou obter a flag.
|
||||
* [**https://guyinatuxedo.github.io/26-heap\_grooming/swamp19\_heapgolf/index.html**](https://guyinatuxedo.github.io/26-heap\_grooming/swamp19\_heapgolf/index.html)
|
||||
* Neste caso, é necessário escrever 4 dentro de um chunk específico que é o primeiro a ser alocado (mesmo após liberar todos eles forçadamente). Em cada novo chunk alocado, seu número no índice do array é armazenado. Em seguida, alocar 4 chunks (+ o inicialmente alocado), o último terá 4 dentro dele, liberá-los e forçar a realocação do primeiro, que usará o último chunk liberado, que é o que tem 4 dentro dele.
|
||||
|
|
Loading…
Reference in a new issue