Fuzzing per trovare i crash

Il fuzzing consiste nell'inviare a un programma input malformati o sovradimensionati per provocare un comportamento imprevisto, in particolare un crash. Un crash spesso segnala un bug di corruzione della memoria.

Nel caso dei buffer overflow, il primo obiettivo è mandare in crash il programma, per verificare l'esistenza di un overflow.

Il classico flusso di lavoro per lo sfruttamento è:

• Eseguire il fuzzing per mandare in crash il programma.
• Trovare l'offset esatto fino all'indirizzo di ritorno.
• Controllare EIP.
• Reindirizzare l'esecuzione allo shellcode.

Questa lezione tratta i primi due passaggi.

Per osservare i crash, colleghi un debugger (ad esempio Immunity Debugger o x64dbg su Windows, oppure GDB su Linux) al programma bersaglio.

Quando il programma va in crash, il debugger mostra lo stato dei registri, in particolare di EIP, rivelando se l'indirizzo di ritorno è stato sovrascritto.

Un fuzzer semplice invia stringhe sempre più lunghe finché il programma va in crash. Un punto di partenza comune consiste nell'inviare molti caratteri «A» (0x41).

Se dopo il crash EIP mostra 41414141, ha confermato il controllo sull'indirizzo di ritorno.

Quando l'applicazione va in crash e EIP è uguale a 41414141, l'overflow ha raggiunto l'indirizzo di ritorno salvato.

Tuttavia, non sa ancora esattamente quanti byte precedono EIP. Inviare sempre lo stesso byte conferma che EIP è controllabile, ma non indica dove si trova.

Per trovare l'offset preciso, invii un pattern univoco non ripetitivo invece di usare solo «A». Ogni finestra di 4 byte è distinta, quindi il valore che finisce in EIP identifica l'offset.

Metasploit include pattern_create.rb per questo scopo.

Dopo il crash con il pattern, annoti il valore presente in EIP. Lo passi a pattern_offset.rb, che restituisce il numero esatto di byte prima di EIP.

Questo offset corrisponde alla dimensione del padding prima dei byte dell'indirizzo di ritorno.

Verifichi sempre il risultato. Costruisca un input composto da offset byte «A», seguiti da quattro byte «B» (0x42). Se EIP diventa 42424242, l'offset è esatto.

Questa conferma evita di perdere ore a eseguire il debug di un errore di pochi byte più avanti.

Dopo aver preso il controllo di EIP, annoti anche dove punta ESP al momento del crash. Di solito ESP punta subito dopo l'indirizzo di ritorno sovrascritto, all'interno del buffer rimanente.

Sarà questo lo spazio in cui inserirà successivamente lo shellcode.

Tra gli strumenti utili per il fuzzing e i pattern sono inclusi:

• Spike e boofuzz: fuzzer per protocolli di rete.
• pattern_create / pattern_offset: individuano l'offset di EIP.
• mona.py in Immunity: automatizza le attività relative a pattern, offset e caratteri non validi.

Un crash utile deve essere riproducibile. Salvi l'input esatto che lo provoca e ripeta l'esecuzione partendo da uno stato pulito, per confermare che l'offset sia stabile.

I crash incoerenti spesso indicano che il bug non è un semplice stack overflow oppure che una condizione (tempistica, lunghezza o contenuto) varia tra un'esecuzione e l'altra.

Ricordi perché un pattern ciclico è migliore di una stringa composta da byte identici.

Ora sa come trovare l'offset del crash:

• Esegua il fuzzing con input di lunghezza crescente per provocare un crash; lo confermi con 41414141 in EIP.
• Usi un pattern ciclico con pattern_create / pattern_offset per trovare l'offset esatto.
• Verifichi il risultato con padding seguito da quattro byte «B» (42424242).
• Annoti dove punta ESP per inserire successivamente lo shellcode.

Nel prossimo passaggio prenderà completamente il controllo di EIP e reindirizzerà l'esecuzione.