Fuzzing: cosa si cela dietro il metodo di test au­to­ma­ti­co?

Il fuzzing, noto anche come fuzz testing, è un metodo au­to­ma­tiz­za­to che si rivela par­ti­co­lar­men­te efficace nell’in­di­vi­dua­re la presenza di vul­ne­ra­bi­li­tà nei software. In questo articolo vi pre­sen­tia­mo questa procedura di test e vi spie­ghia­mo quali sono i suoi vantaggi e svantaggi, nonché i diversi strumenti di fuzzing di­spo­ni­bi­li.

Il fuzzing, detto anche fuzz testing, è un metodo svi­lup­pa­to dallo scien­zia­to Barton Miller per testare i software in modo si­ste­ma­ti­co alla ricerca di vul­ne­ra­bi­li­tà. Lo scopo del metodo non è tanto quello di in­ter­pre­ta­re il codice sorgente del programma, quanto più di con­si­de­ra­re il software come una black box e il suo contenuto come dato di fatto. Tutte le possibili in­ter­fac­ce di in­se­ri­men­to dati vengono ri­chia­ma­te in modo au­to­ma­ti­co e ali­men­ta­te con dati casuali. A seconda delle di­men­sio­ni del progetto software testato, questo processo può protrarsi per ore o persino giorni.

Obiettivo del fuzz testing è ve­ri­fi­ca­re se, per tutte le possibili varianti di input, il programma dispone delle reazioni ne­ces­sa­rie. Gli input insensati o erronei do­vreb­be­ro essere il più possibile in­ter­cet­ta­ti con routine di gestione degli errori. Se, per de­ter­mi­na­ti dati di input, queste routine non sono presenti oppure non fun­zio­na­no cor­ret­ta­men­te, la con­se­guen­za può essere un crash del programma. La prassi tecnica di ve­ri­fi­ca­re i software tenendo conto di tutte le even­tua­li­tà è ormai da tempo parte in­te­gran­te degli ambienti di sviluppo nel settore dello sviluppo web. Da anni, ad esempio, numerose ap­pli­ca­zio­ni web vengono testate in diversi web client o versioni dei browser uti­liz­zan­do il cross browser testing al fine di ve­ri­fi­car­ne la fun­zio­na­li­tà.

In linea generale si distingue tra tre varianti di fuzzing:

Nell’ambito di questo approccio di fuzz testing vengono testate funzioni quali i pulsanti e i campi di im­mis­sio­ne di programmi grafici o le opzioni dei programmi della riga di comando. Il test consiste nel ri­chia­ma­re le funzioni in modo mirato con una frequenza o una velocità in­na­tu­ra­li, oppure nel compilare i campi di im­mis­sio­ne con contenuti troppo grandi.

Per lo scambio di dati si uti­liz­za­no pro­to­col­li, ad esempio l’Hypertext Transfer Protocol (HTTP) sul web. I dati tra­sfe­ri­ti devono essere forniti in un de­ter­mi­na­to formato. Il protocol fuzzing ha lo scopo di ve­ri­fi­ca­re il com­por­ta­men­to del programma in caso di invio di contenuti con formato errato. In par­ti­co­la­re, è im­por­tan­te che i contenuti inviati non siano ac­ci­den­tal­men­te in­ter­pre­ta­ti come comandi e, pertanto, eseguiti su un server.

Gli strumenti di fuzzing che si basano sull’approccio del file format fuzzing generano file errati che vengono immessi nel software da testare allo scopo di essere elaborati. I file hanno un formato stan­dar­diz­za­to come .jpg per i file immagine, così da poter essere scambiati tra varie ap­pli­ca­zio­ni. Possono de­ter­mi­nar­si problemi nel caso in cui il file aperto non presenta il formato atteso. In una versione avanzata è anche possibile testare funzioni im­ple­men­ta­te, ad esempio i processi di com­pres­sio­ne dei file video.

Ri­co­strui­re il fun­zio­na­men­to di un software è un’attività complessa e di­spen­dio­sa. Spesso la lingua di pro­gram­ma­zio­ne è co­sti­tui­ta da diverse migliaia di righe di codice sorgente, che vengono rese ancor più im­pe­ne­tra­bi­li da ra­mi­fi­ca­zio­ni e funzioni integrate. Inoltre, una volta compilato, il codice sorgente deve essere ri­co­strui­to (ossia de­com­pi­la­to), ope­ra­zio­ne che non sempre è possibile.

Il fuzzing persegue pertanto un approccio diverso: genera tutti i dati casuali im­ma­gi­na­bi­li di un de­ter­mi­na­to tipo, in modo tale da coprire il massimo numero possibile di varianti di input. Il fuzzing rap­pre­sen­ta l’in­ter­fac­cia per l’input au­to­ma­tiz­za­to. Questo può avvenire a diversi livelli. Nell’ambito dell’ap­pli­ca­tion fuzzing, ad esempio, si simulano diversi tipi di dati, che in seguito sono inoltrati a un software. Il test può essere eseguito anche su possibili lunghezze e formati di dati degli input. Il protocol fuzzing utilizza pacchetti di dati creati au­to­no­ma­men­te. Un’altra pos­si­bi­li­tà consiste nell’in­ter­cet­ta­re dei contenuti, ma­ni­po­lar­li e re­sti­tuir­li. Il file format fuzzing funziona invece con file di test generati ca­sual­men­te. I fattori da testare sono, ad esempio, la di­men­sio­ne, la struttura e i marcatori (flag) uti­liz­za­ti.

L’ambito di ap­pli­ca­zio­ne prin­ci­pa­le del fuzzing è la garanzia di qualità nello sviluppo di software. In ragione dell’elevato grado di au­to­ma­tiz­za­zio­ne è possibile testare re­go­lar­men­te i software in un ambiente di test ap­po­si­ta­men­te pre­di­spo­sto. Con lo sviluppo agile, questo ambiente di test può essere integrato in processi già esistenti. Tuttavia, anche i software già di­stri­bui­ti possono essere testati nell’ambito di un audit di sicurezza, ad esempio per ac­cer­tar­ne l’idoneità a impieghi rilevanti per la sicurezza.

Ov­via­men­te, il fuzzing può essere utile anche per in­di­vi­dua­re po­ten­zia­li exploit. Tuttavia, il metodo consente di scoprire soltanto i possibili punti di attacco at­tra­ver­so gli errori delle funzioni del programma, poiché gli strumenti di fuzzing non offrono in ultima analisi alcun accesso alle strutture interne del software testato.

Sul mercato esistono mol­te­pli­ci strumenti di fuzzing, sia gratuiti che a pagamento, che offrono fun­zio­na­li­tà diverse. Ecco una piccola pa­no­ra­mi­ca:

• American Fuzz Lop: può compilare au­to­no­ma­men­te il codice sorgente e testarlo; per questo motivo, ap­par­tie­ne a una categoria di programmi de­no­mi­na­ti anche “Grey Box Fuzzer”. Se il testo sorgente non è di­spo­ni­bi­le, viene eseguita un’emu­la­zio­ne con QEMU (Quick Emulator).
• Fuzzino: offre una libreria per la ge­ne­ra­zio­ne di dati di input che possono essere uti­liz­za­ti per testare le ap­pli­ca­zio­ni (basate su pro­to­col­lo).
• LibFuzzer: libreria che fa parte dell’in­fra­strut­tu­ra di com­pi­la­zio­ne LLVM.
• Clu­ster­Fuzz: ambiente di test ori­gi­na­ria­men­te svi­lup­pa­to da Google per testare il browser Chrome.
• Sulley: offre una raccolta di strumenti nel lin­guag­gio di pro­gram­ma­zio­ne Python; adatto in par­ti­co­la­re per eseguire test semplici, come la ge­ne­ra­zio­ne di dati casuali.
• Peach: soluzione for­te­men­te au­to­ma­tiz­za­ta per il fuzz testing di hardware e software.
• Po­wer­fuz­zer: offre diversi scenari di attacco, come iniezioni SQL; è uti­liz­za­to at­tra­ver­so un’in­ter­fac­cia utente grafica basata sul web.

A seconda della finalità ap­pli­ca­ti­va, esistono delle al­ter­na­ti­ve al fuzz testing che per­se­guo­no un approccio diverso e for­ni­sco­no risultati diversi. Qui di seguito vi pre­sen­tia­mo una sintesi delle prin­ci­pa­li al­ter­na­ti­ve.

Per i ri­cer­ca­to­ri nel campo della sicurezza, il reverse en­gi­nee­ring fa parte degli strumenti standard del mestiere. Con questo termine si indica l’attività di analisi svolta dopo la de­com­pi­la­zio­ne (ri­tra­scri­zio­ne nei linguaggi di pro­gram­ma­zio­ne) oppure dopo il di­sas­sem­blag­gio (tra­du­zio­ne nel lin­guag­gio macchina assembler). Si tratta di un processo molto complesso e su­scet­ti­bi­le di errori. Tuttavia, in caso di successo, permette di ottenere tutti i dettagli relativi alla fun­zio­na­li­tà del programma.

Il debugging è un processo di ricerca errori uti­liz­za­to nell’ambito dello sviluppo di software. I programmi sono eseguiti tem­po­ra­nea­men­te nell’ambiente di sviluppo prima della fi­na­liz­za­zio­ne. Lo svi­lup­pa­to­re può inserire dei punti di in­ter­ru­zio­ne (break points) in cor­ri­spon­den­za dei quali il programma di blocca. Qui può leggere i contenuti delle variabili uti­liz­za­te e ve­ri­fi­car­ne la cor­ret­tez­za. Il debugging viene uti­liz­za­to anche nell’ambito del reverse en­gi­nee­ring.

I software complessi sono spesso creati su base modulare. Una prassi ormai con­so­li­da­ta consiste nel ve­ri­fi­ca­re i singoli com­po­nen­ti già nell’ambito di co­sid­det­ti test modulari in idonei ambienti di test.

Nella maggior parte dei casi gli errori e le falle di sicurezza dei software sono legati a una perdita di stima e fiducia degli svi­lup­pa­to­ri. La totale assenza di errori è un’utopia, cosa di cui la maggior parte degli uti­liz­za­to­ri di programmi dovrebbe essere con­sa­pe­vo­le. Con il fuzzing, tuttavia, lo svi­lup­pa­to­re dispone di una po­ten­zia­le soluzione per in­di­vi­dua­re gli errori prima che vengano segnalati da soggetti terzi. In ogni caso, il metodo promuove la stabilità e la sicurezza dei software. Tutti validi motivi, questi, per integrare il fuzz testing nella propria garanzia di qualità.