BF Forked & Threaded Stack Canaries
Last updated
Last updated
Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Se stai affrontando un binario protetto da un canary e PIE (Position Independent Executable) probabilmente devi trovare un modo per bypassarli.
Nota che checksec
potrebbe non rilevare che un binario è protetto da un canary se questo è stato compilato staticamente e non è in grado di identificare la funzione.
Tuttavia, puoi notarlo manualmente se trovi che un valore è salvato nello stack all'inizio di una chiamata di funzione e questo valore viene controllato prima di uscire.
Il modo migliore per bypassare un semplice canary è se il binario è un programma che fork ogni volta che stabilisci una nuova connessione con esso (servizio di rete), perché ogni volta che ti connetti ad esso verrà utilizzato lo stesso canary.
Quindi, il modo migliore per bypassare il canary è semplicemente forzarlo carattere per carattere, e puoi capire se il byte del canary indovinato era corretto controllando se il programma è andato in crash o continua il suo flusso regolare. In questo esempio la funzione forza un canary di 8 byte (x64) e distingue tra un byte indovinato corretto e un byte errato semplicemente controllando se una risposta viene inviata dal server (un altro modo in altra situazione potrebbe essere utilizzare un try/except):
Questo esempio è implementato per 64 bit ma potrebbe essere facilmente implementato per 32 bit.
Questo è implementato per 32 bit, ma potrebbe essere facilmente cambiato a 64 bit. Si noti anche che per questo esempio il programma si aspettava prima un byte per indicare la dimensione dell'input e il payload.
I thread dello stesso processo condivideranno anche lo stesso token canary, quindi sarà possibile forzare un canary se il binario genera un nuovo thread ogni volta che si verifica un attacco.
Inoltre, un overflow di buffer in una funzione thread protetta con canary potrebbe essere utilizzato per modificare il master canary memorizzato nel TLS. Questo perché potrebbe essere possibile raggiungere la posizione di memoria in cui è memorizzato il TLS (e quindi, il canary) tramite un bof nello stack di un thread. Di conseguenza, la mitigazione è inutile perché il controllo viene eseguito con due canary che sono gli stessi (anche se modificati). Questo attacco è descritto nel writeup: http://7rocky.github.io/en/ctf/htb-challenges/pwn/robot-factory/#canaries-and-threads
Controlla anche la presentazione di https://www.slideshare.net/codeblue_jp/master-canary-forging-by-yuki-koike-code-blue-2015 che menziona che di solito il TLS è memorizzato da mmap
e quando viene creato uno stack di thread è anch'esso generato da mmap
, il che potrebbe consentire l'overflow come mostrato nel writeup precedente.
64 bit, no PIE, nx, BF canary, scrivere in qualche memoria un ROP per chiamare execve
e saltare lì.