Tutorial sul test del fuzz (Fuzzing).

Cos'è il Fuzz Test?

Test di fuzzing o fuzzing Il fuzz testing è una tecnica di test del software che consiste nell'inserire dati non validi o casuali, chiamati FUZZ, in un sistema software per scoprire errori di programmazione e falle di sicurezza. Lo scopo del fuzz testing è quello di inserire dati utilizzando tecniche automatizzate o semi-automatizzate e testare il sistema per individuare varie eccezioni, come arresti anomali del sistema o malfunzionamenti del codice integrato.

Il fuzz testing è stato originariamente sviluppato da Barton Miller all'Università del Wisconsin-Madison, che ha coniato il termine dopo che il rumore di linea su un collegamento modem ha mandato in crash i programmi che stava usando. I suoi studenti hanno eseguito i primi fuzzer nel 1989 e hanno scoperto che circa un terzo delle utility UNIX che prendevano di mira andavano in crash o si bloccavano. Il fuzz testing è un test del software tecnica, ed è un tipo di Test di sicurezza.

Il diagramma seguente mostra il ciclo base del fuzzing, in cui i dati generati vengono inviati all'applicazione da testare e si osserva la risposta.

Perché fare il Fuzz Testing?

Il fuzzing si guadagna un posto in un piano di test perché esplora gli input per i quali nessuno aveva pensato di scrivere un caso di test. I principali motivi per cui i team lo adottano sono elencati di seguito.

• I test di fuzzing solitamente individuano le falle e i difetti di sicurezza più gravi, poiché un arresto anomalo è la prova diretta di un percorso di input non gestito.
• Il test fuzz fornisce un risultato più efficace se utilizzato con Nero Box Collaudo, beta testing e altri metodi di debug.
• Il fuzz testing viene utilizzato per verificare la vulnerabilità del software ed è una tecnica di test molto conveniente in termini di costi, poiché gli input vengono generati anziché scritti manualmente.
• Il fuzz testing è una delle tecniche di test black box. Il fuzzing è anche uno dei metodi più comuni utilizzati dagli hacker per trovare una vulnerabilità in un sistema, quindi eseguirlo per primo elimina la via d'accesso più facile per un attaccante.

Tipi di test fuzz

I fuzzer vengono generalmente classificati in base alla quantità di informazioni che possiedono sul programma che stanno attaccando. Maggiore è la conoscenza del fuzzer, più a fondo può penetrare nel codice.

Tipo	Cosa sa il fuzzer	Utilizzo tipico
Fuzzing della scatola nera	Non si tratta di dettagli interni; il sistema rileva solo input e output.	Test di fumo rapidi su un file binario o su un endpoint reale.
Fuzzing della scatola bianca	Codice sorgente completo, spesso combinato con l'esecuzione simbolica per risolvere i problemi legati a rami difficili da raggiungere.	Analisi approfondita di un componente di cui è disponibile il codice sorgente.
Sfocatura della scatola grigia	Nessuna revisione del codice sorgente, ma feedback in fase di esecuzione, ad esempio quali rami del codice sono stati raggiunti da un input.	L'impostazione predefinita per i motori moderni come AFL++ e libFuzzer.

Una seconda, più antica, separazione stupido fuzzing da fuzzing intelligenteUn fuzzer "stupido" si limita a invertire i bit senza alcuna idea del formato di input, quindi la maggior parte dei suoi dati viene rifiutata dal primo parser che incontra. Un fuzzer "intelligente" comprende i checksum, i campi di lunghezza e la struttura del messaggio, quindi i suoi input superano la validazione e raggiungono la logica sottostante. Fuzzing guidato dalla copertura È il perfezionamento della "scatola grigia" che ha reso il fuzzing una pratica diffusa: il motore strumenta il binario, conserva qualsiasi input che raggiunga un nuovo ramo e muta i sopravvissuti, in modo che il corpus si evolva costantemente verso codice inesplorato invece di ripartire da un rumore casuale.

Come eseguire il Fuzz Test

Le fasi del fuzz testing includono le fasi di test di base:

Passaggio 1) Identificare il sistema di destinazione — scegli il binario, la libreria, il servizio o l'endpoint del protocollo che verrà attaccato e conferma di essere autorizzato a testarlo.

Passaggio 2) Identificare gli input — elenca tutti i punti di ingresso da cui il target legge: file, argomenti della riga di comando, variabili d'ambiente, pacchetti di rete, campi dei moduli e payload delle API.

Passaggio 3) Genera dati fuzzed — produrre input non validi mutando campioni validi, generandoli da un modello del formato o combinando entrambi i metodi.

Passaggio 4) Eseguire il test utilizzando dati fuzzy — eseguire il target sui dati di input generati, idealmente in un ciclo che riavvia automaticamente il processo dopo ogni errore.

Passaggio 5) Monitorare il comportamento del sistema — Presta attenzione a crash, blocchi, errori di asserzione, utilizzo eccessivo della memoria e report di sanificazione, anziché limitarti a controllare l'output stampato.

Passaggio 6) Registrare i difetti — salva l'input esatto che ha attivato ogni errore, riducilo al caso più piccolo che lo riproduce e archivialo con lo stack trace allegato.

Esempi di Fuzzer

I fuzzer vengono classificati anche in base al modo in cui elaborano i dati di input, e i tre approcci descritti di seguito sono quelli che incontrerete più frequentemente.

• Fuzzer basati su mutazioni Modificare i campioni di dati esistenti per creare nuovi dati di test. Questo è un approccio molto semplice e diretto: si parte da campioni validi di un protocollo e si continua a manipolare ogni byte o file.
• Fuzzer basati sulla generazione Definiscono nuovi dati in base all'input del modello. Iniziano a generare input da zero in base alle specifiche.
• Fuzzer basati su protocolli Dipende da una conoscenza dettagliata del formato del protocollo in fase di test, e tale comprensione deriva dalle specifiche. Il processo prevede la scrittura di un array delle specifiche nello strumento, quindi l'utilizzo di una tecnica di generazione di test basata su modelli per analizzare le specifiche e aggiungere irregolarità al contenuto dei dati, alla sequenza e così via. Questo è anche noto come test di sintassi, test grammaticale o test di robustezza. Un fuzzer può generare casi di test a partire da casi esistenti, oppure può utilizzare input validi o non validi.

Esistono due limitazioni del fuzzing basato su protocollo:

1. Il test non può procedere finché la specifica non sarà matura.
2. Molti protocolli utili sono un'estensione dei protocolli pubblicati. Se il test fuzz si basa su specifiche pubblicate, Copertura di prova per i nuovi protocolli sarà limitato.

La forma più semplice di tecnica di fuzzing consiste nell'inviare input casuali al software, sia sotto forma di pacchetti di protocollo che di eventi. Questa tecnica, che prevede l'invio di input casuali, è molto efficace per individuare bug in numerose applicazioni e servizi. Esistono anche altre tecniche, molto facili da implementare. Per implementarle, è sufficiente modificare gli input esistenti, ad esempio scambiandone i bit.

Tipi di bug rilevati da Fuzz Testing

Poiché il fuzzing valuta un'esecuzione in base al comportamento del programma piuttosto che in base a un valore atteso, i difetti che individua si raggruppano in tre famiglie.

• Errori di asserzione e perdite di memoria: Questa metodologia è ampiamente utilizzata per applicazioni di grandi dimensioni in cui i bug compromettono la sicurezza della memoria, che rappresenta una grave vulnerabilità. Buffer Overflow, use-after-free e letture fuori dai limiti sono tutti presenti qui.
• Input non valido: Nel fuzz testing, i fuzzer vengono utilizzati per generare input non validi che vengono utilizzati per testare le routine di gestione degli errori, e questo è importante per il software che non controlla il suo input. Il fuzzing semplice può essere visto come un modo per automatizzare test negativo.
• Errori di correttezza: Il fuzzing può essere utilizzato anche per rilevare alcuni tipi di bug di "correttezza", come un database corrotto o risultati di ricerca scadenti. Il fuzzing differenziale, che fornisce lo stesso input a due implementazioni e confronta le risposte, è il metodo usuale per individuarli.

Strumenti di test fuzz

Gli strumenti utilizzati nella sicurezza web possono essere ampiamente utilizzati nel fuzz testing, come ad esempio Burp Suite e Peach Fuzzer. Molti dei nomi classici qui sotto sono ora archiviati, quindi il loro stato attuale è indicato accanto a ciascuna voce.

• Soffice alla pesca: Peach Fuzzer offre una copertura di sicurezza più robusta rispetto a uno scanner. Altri strumenti di test possono cercare solo minacce note, mentre Peach Fuzzer consente agli utenti di trovare minacce note e sconosciute. Peach Tech è stata acquisita da GitLab e Community Edition v3 non è più mantenuta; il successore mantenuto è GitLab Protocol Fuzzer Community Edition.
• Proxy Spike: uno strumento di livello professionale che cerca vulnerabilità a livello di applicazione nelle applicazioni web. SPIKE Proxy copre le basi, come ad esempio SQL Iniezione e cross-site scripting, su un sistema completamente aperto Python infrastrutture ed era disponibile per Linux and WindowsNon è stato sottoposto a manutenzione per molti anni ed è incluso qui a scopo di contesto storico.
• Scarabeo Web: WebScarab è scritto in Java È quindi portabile su molte piattaforme. Il framework WebScarab comunica utilizzando i protocolli HTTP e HTTPS e funziona come un proxy di intercettazione: consente all'operatore di rivedere e modificare le richieste create dal browser prima che vengano ricevute dal server, e di rivedere e aggiornare le risposte generate dal server prima che vengano ricevute dal browser. Qualsiasi falla rilevata da WebScarab viene aggiunta al suo elenco di problemi segnalati. Il repository è stato archiviato nell'aprile 2024 ed è ora di sola lettura.
• OWASP WSFuzzer: WSFuzzer è un programma con licenza GPL scritto in Python che prendeva di mira i servizi web e nella sua ultima versione era basato su HTTP Servizi SOAP erano l'obiettivo principale. È stato distribuito come parte di WebScarab ed è stato ritirato con esso; OWASP ZAP e il suo componente aggiuntivo Fuzzer sono i sostituti consigliati.
• Alternative mantenute: AFL++ and libFuzzer sono i motori standard guidati dalla copertura per il codice nativo, OSS-Fuzz li esegue continuamente e gratuitamente per i progetti open-source e boofuzz copre il fuzzing del protocollo di rete in Python. Un elenco più ampio è raccolto nella guida a strumenti di test di sicurezza.

Fuzz Testing migliori pratiche

Un fuzzer puntato su un bersaglio e lasciato indisturbato raramente trova molto. Le pratiche descritte di seguito distinguono una campagna che produce difetti documentati da una che si limita a consumare tempo CPU.

• Parti da un buon corpus di semi. Raccogli input reali e validi che l'applicazione già accetta. Modificare un file autentico raggiunge il codice di analisi molto più velocemente rispetto alla modifica di byte casuali.
• Scrivi un piccolo e veloce cablaggio. Il punto di ingresso dovrebbe eseguire una sola operazione per ogni ciclo, evitare chiamate di rete e scritture su disco e terminare rapidamente, poiché la velocità di elaborazione si misura in esecuzioni al secondo.
• Attivare i dispenser di disinfettante. La corruzione silenziosa della memoria spesso non provoca un arresto anomalo. AddressSanitizer e UndefinedBehaviorSanitizer la trasformano in un errore immediato e diagnosticabile.
• Corri a lungo e corri senza interruzioni. Un'esecuzione di una o due ore permette di individuare bug superficiali; per individuare problemi più complessi, di solito sono necessarie molte ore, motivo per cui il fuzzing dovrebbe essere integrato in un processo di integrazione continua (CI) notturno piuttosto che eseguito manualmente.
• Riduci al minimo e deduplica ogni arresto anomalo. Riduci l'input difettoso alla sua forma più piccola e raggruppa gli arresti anomali per stack trace, altrimenti un bug si traduce in centinaia di ticket.
• Mantieni un corpus per le regressioni. Aggiungi ogni input che riproduce il problema a un set permanente che viene eseguito a ogni compilazione, in modo che un difetto corretto non possa ripresentarsi silenziosamente.
• Definire legalmente l'ambito dell'obiettivo. Effettuare test di fuzzing su un servizio di terze parti attivo senza autorizzazione scritta è indistinguibile da un attacco informatico.

Vantaggi del Fuzz Test

Se utilizzata con aspettative realistiche, la tecnica del fuzzing aggiunge un valore che altre tecniche faticano a eguagliare.

• Il fuzz testing migliora i test di sicurezza del software.
• I bug rilevati tramite fuzzing sono talvolta gravi e spesso coincidono con quelli sfruttati dagli aggressori, tra cui crash, perdite di memoria ed eccezioni non gestite.
• Se, a causa di limiti di tempo e risorse, alcuni bug non vengono rilevati dai tester, questi vengono individuati anche tramite il fuzz testing.
• I dati di input vengono generati automaticamente da una macchina, quindi la copertura continua ad aumentare durante la notte senza alcuno sforzo manuale aggiuntivo.

Svantaggi del Fuzz Test

Le stesse caratteristiche che rendono il fuzzing economico ne limitano anche ciò che può dimostrare.

• I test di fuzzing da soli non possono fornire un quadro completo di una minaccia alla sicurezza nel suo complesso o di un insieme di bug.
• Il fuzz testing è meno efficace nell'affrontare le minacce alla sicurezza che non causano arresti anomali del programma, come alcuni virus, worm e trojan.
• Il fuzz testing è in grado di rilevare solo difetti o minacce relativamente semplici e non analizza la logica aziendale.
• Per funzionare in modo efficace, richiede un tempo di elaborazione considerevole.
• Definire una condizione di valore limite con input casuali è molto problematico, sebbene oggi i tester risolvano gran parte di questo problema con algoritmi deterministici guidati dagli input dell'utente.

Test di fuzzing vs test di penetrazione

Entrambe le attività mirano a individuare falle di sicurezza, ma rispondono a domande diverse e raramente sono intercambiabili.

Criteri	Test fuzz	Test di penetrazione
Guidata da	Un motore automatizzato che genera input non validi	Un tester esperto ragiona sul sistema
Cerca	Arresti anomali, blocchi e errori di sicurezza della memoria	Punti deboli sfruttabili, inclusi difetti di logica e di configurazione.
Profondità	Ampia copertura degli input, ragionamento superficiale	Copertura ristretta, ragionamento approfondito
Uscita	Riproduzione degli input e dello stack traces	Un rapporto sui risultati con percorsi di sfruttamento e valutazioni del rischio
momento migliore	Continuamente, nella pipeline di compilazione	Periodicamente, contro un candidato di rilascio

In pratica, i due processi si alimentano a vicenda: il fuzzing elimina i crash più semplici e automatizzabili, in modo che le ore limitate di un tester possano essere dedicate ai difetti che solo un essere umano è in grado di individuare.

DOMANDE FREQUENTI