<summary><strong>Aprenda hacking AWS do zero ao herói com</strong><ahref="https://training.hacktricks.xyz/courses/arte"><strong>htARTE (HackTricks AWS Red Team Expert)</strong></a><strong>!</strong></summary>
* 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) repositórios do github.
</details>
## Informações Básicas
**Randomização do Layout do Espaço de Endereços (ASLR)** é uma técnica de segurança usada em sistemas operacionais para **randomizar os endereços de memória** usados por processos do sistema e de aplicativos. Ao fazer isso, torna significativamente mais difícil para um atacante prever a localização de processos e dados específicos, como a pilha, heap e bibliotecas, mitigando assim certos tipos de exploits, especialmente estouros de buffer.
Para **verificar** o status do ASLR em um sistema Linux, você pode ler o valor do arquivo **`/proc/sys/kernel/randomize_va_space`**. O valor armazenado neste arquivo determina o tipo de ASLR aplicado:
* **2**: Randomização completa. Além dos elementos randomizados pela randomização conservadora, a memória gerenciada por meio de `brk()` é randomizada.
Você pode verificar o status do ASLR com o seguinte comando:
```bash
cat /proc/sys/kernel/randomize_va_space
```
### **Desativando o ASLR**
Para **desativar** o ASLR, você define o valor de `/proc/sys/kernel/randomize_va_space` como **0**. Desativar o ASLR geralmente não é recomendado fora de cenários de teste ou depuração. Veja como você pode desativá-lo:
```bash
echo 0 | sudo tee /proc/sys/kernel/randomize_va_space
```
Você também pode desativar o ASLR para uma execução com:
Para **ativar** o ASLR, você pode escrever um valor de **2** no arquivo `/proc/sys/kernel/randomize_va_space`. Isso geralmente requer privilégios de root. A ativação da randomização completa pode ser feita com o seguinte comando:
```bash
echo 2 | sudo tee /proc/sys/kernel/randomize_va_space
```
### **Persistência através de reinicializações**
As alterações feitas com os comandos `echo` são temporárias e serão redefinidas após a reinicialização. Para tornar a alteração persistente, você precisa editar o arquivo `/etc/sysctl.conf` e adicionar ou modificar a seguinte linha:
```tsconfig
kernel.randomize_va_space=2 # Enable ASLR
# or
kernel.randomize_va_space=0 # Disable ASLR
```
Depois de editar `/etc/sysctl.conf`, aplique as alterações com:
O PaX divide o espaço de endereço do processo em **3 grupos**:
* **Código e dados** (inicializados e não inicializados): `.text`, `.data` e `.bss` —> **16 bits** de entropia na variável `delta_exec`. Esta variável é inicializada aleatoriamente a cada processo e adicionada aos endereços iniciais.
* **Memória** alocada por `mmap()` e **bibliotecas compartilhadas** —> **16 bits**, chamado `delta_mmap`.
* **A pilha** —> **24 bits**, referido como `delta_stack`. No entanto, ele efetivamente usa **11 bits** (do 10º ao 20º byte inclusive), alinhados a **16 bytes** —> Isso resulta em **524.288 possíveis endereços reais de pilha**.
Os dados anteriores são para sistemas de 32 bits e a entropia final reduzida torna possível contornar o ASLR tentando a execução repetidamente até que o exploit seja concluído com sucesso.
* Se você tiver um estouro grande o suficiente para hospedar um **grande NOP sled antes do shellcode**, você poderia simplesmente forçar os endereços na pilha até que o fluxo **salte sobre alguma parte do NOP sled**.
* Outra opção para isso, caso o estouro não seja tão grande e o exploit possa ser executado localmente, é possível **adicionar o NOP sled e o shellcode em uma variável de ambiente**.
* Se estiver atacando um servidor remoto, você pode tentar **forçar o endereço da função `usleep` da `libc`**, passando como argumento 10 (por exemplo). Se em algum momento o **servidor demorar 10s extras para responder**, você encontrou o endereço dessa função.
É possível ocupar uma grande parte da pilha com variáveis de ambiente e então tentar abusar do binário centenas/milhares de vezes localmente para explorá-lo.\
O código a seguir mostra como é possível **apenas selecionar um endereço na pilha** e a cada **algumas centenas de execuções** esse endereço conterá a **instrução NOP**:
Portanto, se o atacante estiver no mesmo computador que o binário sendo explorado e esse binário não esperar o estouro de argumentos brutos, mas de uma **entrada diferente que pode ser criada após a leitura deste arquivo**. É possível para um atacante **obter alguns endereços deste arquivo e construir offsets a partir deles para o exploit**.
Para mais informações sobre este arquivo, consulte [https://man7.org/linux/man-pages/man5/proc.5.html](https://man7.org/linux/man-pages/man5/proc.5.html) procurando por `/proc/pid/stat`
Se você receber um vazamento (desafios fáceis de CTF), você pode calcular offsets a partir dele (supondo, por exemplo, que você saiba a versão exata da libc que está sendo usada no sistema que está explorando). Este exploit de exemplo é extraído do [**exemplo daqui**](https://ir0nstone.gitbook.io/notes/types/stack/aslr/aslr-bypass-with-given-leak) (verifique essa página para mais detalhes):
Assim como no ret2plt, se você tiver uma leitura arbitrária via uma vulnerabilidade de strings de formato, é possível extrair o endereço de uma **função libc** do GOT. O seguinte [**exemplo está aqui**](https://ir0nstone.gitbook.io/notes/types/stack/aslr/plt\_and\_got):
O mecanismo **`vsyscall`** serve para melhorar o desempenho, permitindo que certas chamadas de sistema sejam executadas no espaço do usuário, embora façam parte fundamental do kernel. A principal vantagem das **vsyscalls** está em seus **endereços fixos**, que não estão sujeitos ao **ASLR** (Randomização do Layout do Espaço de Endereços). Essa natureza fixa significa que os atacantes não precisam de uma vulnerabilidade de vazamento de informações para determinar seus endereços e usá-los em uma exploração.\
No entanto, não serão encontrados gadgets super interessantes aqui (embora, por exemplo, seja possível obter um equivalente a `ret;`)
(O exemplo e código a seguir são [**deste artigo**](https://guyinatuxedo.github.io/15-partial\_overwrite/hacklu15\_stackstuff/index.html#exploitation))
Por exemplo, um atacante pode usar o endereço `0xffffffffff600800` dentro de uma exploração. Enquanto tentar pular diretamente para uma instrução `ret` pode levar à instabilidade ou falhas após a execução de alguns gadgets, pular para o início de uma `syscall` fornecida pela seção **vsyscall** pode ser bem-sucedido. Ao colocar cuidadosamente um gadget **ROP** que direcione a execução para este endereço **vsyscall**, um atacante pode obter a execução de código sem precisar contornar o **ASLR** para esta parte da exploração.
Note que pode ser possível **burlar o ASLR abusando do vdso** se o kernel for compilado com CONFIG\_COMPAT\_VDSO, pois o endereço do vdso não será randomizado. Para mais informações, consulte: