Panoramica

what the fuzz o wtf è un fuzzer distribuito, guidato dalla copertura del codice, personalizzabile, cross-platform, basato su snapshot, progettato per attaccare target in modalità utente e/o kernel in esecuzione su Microsoft Windows o Linux (sperimentale, vedere linux_mode). L'esecuzione del target può essere effettuata all'interno di un emulatore con bochscpu (più lento, più preciso), all'interno di una VM Windows con le API Windows Hypervisor Platform o all'interno di una VM Linux con le API KVM (più veloce).

Ha scoperto vulnerabilità di corruzione della memoria in un'ampia gamma di software: IDA Pro, un popolare gioco AAA, il kernel Windows, il client RDP Microsoft, il driver per display GPU NVIDIA, ecc.

I binari compilati sono disponibili sia dagli artefatti CI che dalla sezione Releases sia per Windows che per Linux.

Se desideri saperne di più sulla sua storia o su come usarlo su un target reale, ti consiglio di dare un'occhiata a questi post per iniziare 🔥

• Costruire un nuovo snapshot fuzzer e fuzzare IDA
• Fuzzing di protocolli di gioco UDP moderni con snapshot fuzzer di Markus Gaasedelen
• Fuzzing di RDPEGFX con "what the fuzz" di Colas Le Guernic, Jérémy Rubert e Anonimo
• Un viaggio nel fuzzing di protocolli di rete – Dissezionare il protocollo client IMAP di Microsoft di Wayne Chin Yick Low
• La sezione Snapshot Fuzzing del Manuale di Testing di Trail of Bits
• Attaccare gli EDR Parte 4: Fuzzare il motore di scansione ed emulazione di Defender (mpengine.dll) di Manuel Feifel

Utilizzo

Il modo migliore per provare le funzionalità è lavorare con i moduli fuzzer_hevd / fuzzer_tlv_server. Puoi scaricare gli archivi target-hevd.7z / target-tlv_server.7z ed estrarli nella directory targets/. Gli archivi contengono le strutture di directory previste per ogni target:

• inputs è la cartella dove inserire i tuoi casi di test di input,
• outputs è la cartella dove vengono salvati i file minset correnti,
• coverage è la cartella dove ci si aspetta che siano i file .cov,
• crashes è dove vengono salvati i crash,
• state è dove vengono archiviati il dump della memoria (mem.dmp), lo stato della CPU (regs.json) e lo store dei simboli (symbol-store.json). Lo store dei simboli è un semplice file JSON che viene utilizzato sui sistemi Linux per sapere dove posizionare i breakpoint poiché non c'è supporto per simboli / dbgeng su quelle piattaforme. wtf genera questo file in esecuzione ogni volta che esegui il target su Windows.

Quanto segue presuppone che tu abbia scaricato il file target-hevd.7z allegato all'ultima release e lo abbia estratto nella directory targets del tuo clone di wtf. Dovresti avere wtf/targets/hevd in cui trovi le directory inputs / outputs, ecc.

Avviare un nodo server

Il server è fondamentalmente il cervello e tiene traccia di tutto lo stato: la copertura del codice aggregata, il corpus, genera e distribuisce i casi di test al client.

Ecco come potresti scegliere di avviare un nodo server locale:```text wtf.exe master --name hevd --max_len=1028 --runs=10000000

L'opzione `max_len` è usata per limitare la dimensione del test-case generato, `runs` è il numero di test-case che verranno generati, `address` specifica dove **wtf** deve restare in ascolto, `target` è una directory con l'albero delle directory descritto sopra (l'utente può anche scegliere di sovrascrivere quelle directory con `--input` / `--output` / `--crashes`) e `name` specifica il  nome del tuo modulo di fuzzing in modo che il master possa invocare la tua funzione generatrice se ne hai definita una.

<p align='center'>
<img src="https://assets.kitploit.com/production/public/readmes/4699/4a03fc75eed3ed5a92f7f10def697dbf220ae36b0701f05b37759eb432fc0fd9.webp">
</p>

### Nodi di fuzzing

I nodi client eseguono un test-case che è stato generato e distribuito dal server e comunicano il risultato al server (copertura del codice, risultato, ecc.).

Ecco come si avvia un nodo client che utilizza il backend *bochscpu*:```text
wtf.exe fuzz --name hevd --limit 10000000

Il sottocomando fuzz viene utilizzato con l'opzione name per specificare quale modulo fuzzer deve essere utilizzato, backend specifica il backend di esecuzione e limit il numero massimo di istruzioni da eseguire per test case (a seconda del backend, questa opzione ha un significato diverso).

Esecuzione di un test-case

Se desideri eseguire un test-case (o una cartella piena di test-case), puoi utilizzare il sottocomando run.

Ecco come eseguiresti il test-case crash-0xfffff764b91c0000-0x0-0xffffbf84fb10e780-0x2-0x0:``` wtf.exe run --name hevd --limit 10000000 --input crashes\crash-0xfffff764b91c0000-0x0-0xffffbf84fb10e780-0x2-0x0

<p align='center'>
<img src="https://assets.kitploit.com/production/public/readmes/4699/49b3ca8582d6314724e5615c687472499d5f8f41d04c9543c0a6a070c51f56f8.webp">
</p>

### Minset di un corpus

Per eseguire il minset di un corpus, è necessario utilizzare un nodo server e tanti nodi client quanti necessari, come si farebbe per un lavoro di fuzzing. Puoi semplicemente impostare l'opzione `runs` a 0.

Ecco come eseguire il minset del corpus in `outputs` nella directory `minset` (mostra anche come sovrascrivere le directory `inputs` e `outputs`):```
wtf.exe master --name hevd --max_len=1028 --runs=0 --inputs=outputs --outputs=minset

Generazione di tracce di esecuzione