cisco-talos/mutiny-fuzzerFuzzer di protocolli di rete che riproduce il traffico PCAP attraverso un motore di mutazione (Radamsa) per scoprire rapidamente vulnerabilità nei host target tramite processori di messaggi e monitor personalizzabili.
Post del blog qui:
Link a questa demo video di YouTube:
Per ulteriori funzionalità orientate a campagne di fuzzing/feedback/harness:
Il Mutiny Fuzzing Framework è un fuzzer di rete che opera riproducendo PCAP tramite un fuzzer mutazionale. L'obiettivo è avviare il fuzzing di rete il più rapidamente possibile, a scapito della completezza.
Il flusso di lavoro generale per Mutiny è prelevare un campione di traffico legittimo, ad esempio una richiesta del browser, e inserirlo in uno script di preparazione per generare un file .fuzzer. Quindi, Mutiny può essere eseguito con questo file .fuzzer per generare traffico verso un host target, mutando i pacchetti desiderati dall'utente.
Esistono estensioni che consentono di modificare il comportamento di Mutiny, inclusa la modifica dei messaggi in base a input/output, la modifica della risposta di Mutiny agli errori di rete e il monitoraggio del target in un thread separato.
Mutiny utilizza Radamsa per eseguire le mutazioni.
Il Decept Proxy è un proxy di rete multiuso che può inoltrare il traffico da una connessione socket TCP/UDP/domain in chiaro o TLS a una connessione socket TCP/UDP/domain in chiaro o TLS, tra le altre funzionalità. È un buon compagno per Mutiny, poiché può sia generare file .fuzzer direttamente, particolarmente utile quando si fuzzano connessioni TLS, sia consentire a Mutiny di comunicare con host TLS.
sample_apps dà un'idea di base di alcune cose che possono essere fatte con il fuzzer, con alcune diverse applicazioni/client da testare.
Scritto da James Spadaro ([email protected]) e Lilith Wyatt ([email protected])
Assicurati che python e scapy siano installati.
Estrai Radamsa e esegui make (Non è necessario eseguire make install, a meno che non lo si voglia in /usr/bin - utilizzerà il Radamsa locale). Aggiorna mutiny.py con il percorso di Radamsa se lo hai modificato.
Salva il pcap in una cartella. Esegui mutiny_prep.py su <XYZ>.pcap (opzionalmente passa anche la directory di un processore personalizzato, se presente, più avanti). Rispondi alle domande e otterrai un file <XYZ>.fuzzer nella stessa cartella del pcap.
Esegui mutiny.py <XYZ>.fuzzer <IP_target>. Questo avvierà il fuzzing. I log verranno salvati nella stessa cartella, nella directory <XYZ>_logs/<time_of_session>/<seed_number>
I file .fuzzer sono leggibili e commentati. Permettono di modificare varie opzioni per ogni file fuzzer, inclusi quali messaggi o parti di messaggi vengono fuzzati.
All'interno di un file .fuzzer ci sono i contenuti dei messaggi. Sono semplicemente righe che iniziano con 'inbound' o 'outbound', a indicare la direzione del messaggio. Sono in formato stringa Python, con '\xYY' usato per caratteri non stampabili. Sono generati automaticamente da 'mutiny_prep.py' e Decept, ma a volte devono essere modificati manualmente.
Se un messaggio ha la parola chiave 'fuzz' dopo 'outbound', indica che deve essere fuzzato tramite Radamsa. Un dato messaggio può avere continuazioni di riga, semplicemente mettendo più dati del messaggio tra virgolette su una nuova riga. In questo caso, questa seconda riga verrà unita alla prima.
In alternativa, la parola chiave 'sub' può essere usata per indicare un sottocomponente. Ciò permette di specificare un componente separato del messaggio, per fuzzare solo certe parti e per comodità all'interno di un Message Processor.
Ecco un esempio arbitrario di dati del messaggio:
outbound 'say'
' hi'
sub fuzz ' and fuzz'
' this'
sub ' but not this\xde\xad\xbe\xef'
inbound 'this is the server's'
' expected response'
Questo farà sì che Mutiny trasmetta say hi and fuzz this but not this(0xdeadbeef). 0xdeadbeef verrà trasmesso come 4 byte esadecimali. and fuzz this verrà passato a Radamsa per il fuzzing, mentre say hi e but not this(0xdeadbeef) rimarranno invariati.
Mutiny attenderà una risposta dal server dopo aver trasmesso il singolo messaggio sopra, a causa della riga 'inbound'. La risposta attesa dal server è this is the server's expected response. Mutiny non farà molto con questi dati, a parte verificare se ciò che il server ha effettivamente inviato corrisponde a questa stringa. Se si verifica un crash, Mutiny registrerà sia l'output atteso dal server sia ciò che il server ha effettivamente risposto.
mutiny_classes/ contiene classi base per Message Processor, Monitor e Exception Processor. Qualsiasi di questi file può essere copiato nella stessa cartella del .fuzzer (per impostazione predefinita) o in una sottocartella separata specificata come 'processor_dir' all'interno del file .fuzzer.
Queste tre classi consentono di memorizzare le risposte del server e modificare i messaggi in uscita, monitorare il target su un thread separato e cambiare il modo in cui Mutiny gestisce le eccezioni.
Il Message Processor definisce vari callback che vengono chiamati durante un'esecuzione di fuzzing. All'interno di questi callback, è possibile eseguire qualsiasi codice Python. In base all'esperienza, vengono utilizzati principalmente in tre modi.
Il più comune è quando il server invia token che devono essere aggiunti ai futuri messaggi in uscita. Ad esempio, se il primo messaggio di Mutiny effettua il login e il server risponde con un ID di sessione, il callback postReceiveProcess() può essere utilizzato per memorizzare quell'ID di sessione. Quindi, in preSendProcess(), i dati in uscita possono essere corretti con quell'ID di sessione. Un esempio di ciò si trova in sample_apps/session_server.
Un altro uso comune di un Message Processor è limitare o modificare un messaggio fuzzato. Ad esempio, se il server scarta sempre messaggi più grandi di 1000 byte, potrebbe non valere la pena inviare messaggi grandi. preSendProcess() può essere usato per accorciare i messaggi dopo il fuzzing ma prima che vengano inviati, o per sollevare un'eccezione.
Sollevare un'eccezione introduce l'ultimo modo in cui i Message Processor vengono comunemente utilizzati. All'interno di un callback, è possibile sollevare qualsiasi eccezione personalizzata definita in mutiny_classes/mutiny_exceptions.py. Ci sono diverse eccezioni, tutte commentate, che causeranno vari comportamenti da parte di Mutiny. Queste generalmente comportano la registrazione, il tentativo o l'interruzione dell'esecuzione corrente.
Il Monitor ha una funzione monitorTarget() che viene eseguita su un thread separato dal fuzzer principale di Mutiny. Lo scopo è consentire l'implementazione di un processo a lunga esecuzione che possa monitorare un host in qualche modo. Può essere qualsiasi cosa realizzabile in Python, come comunicare con un demone di monitoraggio in esecuzione sul target, leggere un file lungo, o anche solo eseguire ping ripetuti all'host, a seconda dei requisiti della sessione di fuzzing.
Se il Monitor rileva un crash, può chiamare signalMain() in qualsiasi momento. Questo segnalerà al thread principale di Mutiny che si è verificato un crash e lo registrerà. Questa funzione dovrebbe generalmente operare in un ciclo infinito, poiché la restituzione causerà la terminazione del thread e non verrà riavviato.
L'Exception Processor determina cosa Mutiny dovrebbe fare con una determinata eccezione durante una sessione di fuzzing. Nel senso più generale, la funzione processException() tradurrà le eccezioni di Python e del sistema operativo in azioni di gestione degli errori di Mutiny nel miglior modo possibile.
Ad esempio, se Mutiny riceve 'Connection Refused', la risposta predefinita è presumere che il server target sia morto in modo irreversibile, quindi Mutiny registrerà l'esecuzione precedente e si fermerà. Questo è vero nella maggior parte dei casi, ma questo comportamento può essere modificato in quello di una qualsiasi delle eccezioni in mutiny_classes/mutiny_exceptions.py secondo necessità, consentendo di adattare il rilevamento dei crash e la correzione degli errori.