BF Forked & Threaded Stack Canaries
Impara e pratica l'Hacking su AWS:HackTricks Training AWS Red Team Expert (ARTE)
Impara e pratica l'Hacking su GCP:
HackTricks Training GCP Red Team Expert (GRTE)
Se ti trovi di fronte a un binario protetto da un canary e da PIE (Position Independent Executable) probabilmente devi trovare un modo per aggirarli.
![](https://book.hacktricks.xyz/~gitbook/image?url=https%3A%2F%2F197708944-files.gitbook.io%2F%7E%2Ffiles%2Fv0%2Fb%2Fgitbook-x-prod.appspot.com%2Fo%2Fspaces%252FE5VfhVAq0qYsgU9deMR8%252Fuploads%252Fgit-blob-95ac857d8ae19be9bc96c5b5e1a5ef50998db3d3%252Fimage%2520%28865%29.png%3Falt%3Dmedia&width=768&dpr=4&quality=100&sign=40cd062&sv=1)
Nota che checksec
potrebbe non trovare che un binario è protetto da un canary se è stato compilato staticamente e non è in grado di identificare la funzione.
Tuttavia, puoi notarlo manualmente se trovi che un valore viene salvato nello stack all'inizio di una chiamata di funzione e questo valore viene controllato prima di uscire.
Brute force sul Canary
Il modo migliore per aggirare un canary semplice è se il binario è un programma che crea processi figlio ogni volta che si stabilisce una nuova connessione con esso (servizio di rete), perché ogni volta che ci si connette ad esso verrà utilizzato lo stesso canary.
Quindi, il modo migliore per aggirare il canary è semplicemente forzarlo carattere per carattere, e puoi capire se il byte del canary indovinato era corretto controllando se il programma è crashato o continua il suo flusso regolare. In questo esempio la funzione forza un canary di 8 byte (x64) e distingue tra un byte indovinato correttamente e un byte sbagliato semplicemente controllando se viene inviata una risposta dal server (in un altro contesto potrebbe essere utilizzato un try/except):
Esempio 1
Questo esempio è implementato per 64 bit ma potrebbe essere facilmente implementato per 32 bit.
Esempio 2
Questo è implementato per 32 bit, ma potrebbe essere facilmente modificato per 64 bit. Nota anche che per questo esempio il programma si aspetta innanzitutto un byte per indicare la dimensione dell'input e del payload.
Threads
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 avviene un attacco.
Inoltre, un overflow del buffer in una funzione thread protetta con canary potrebbe essere utilizzato per modificare il canary principale 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 effettuato con due canary che sono gli stessi (sebbene modificati). Questo attacco è eseguito 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 un thread è generato anche da mmap
secondo questo, il che potrebbe consentire l'overflow come mostrato nel writeup precedente.
Altri esempi e riferimenti
64 bit, no PIE, nx, BF canary, scrivere in qualche memoria un ROP per chiamare
execve
e saltare lì.
Last updated