ttdennis/fpickerSuite di fuzzing in-process basata su Frida con proxy AFL++, modalità attiva/passiva standalone e comunicazione tramite memoria condivisa per la scoperta di vulnerabilità basata sulla copertura ad alte prestazioni su più piattaforme.
fpicker è una suite di fuzzing basata su Frida che offre una varietà di modalità di fuzzing per fuzzing in-process, come una modalità AFL++ o una modalità di tracciamento passivo. Dovrebbe funzionare su tutte le piattaforme supportate da Frida.
Alcune informazioni di base e i pensieri e le idee dietro fpicker si trovano in un post sul blog che ho scritto.
Fpicker si basa su precedenti sforzi su ToothPicker, sviluppato durante la mia tesi di laurea magistrale. La maggior parte di fpicker è stata sviluppata durante l'orario di lavoro presso il mio datore di lavoro (ERNW).
Requisiti per eseguire fpicker:
frida-core-devkit per la rispettiva piattaforma disponibile presso Frida releases su GitHub.
libfrida-core-ios.a, libfrida-core-macos.a o libfrida-core-linux.a.frida-core.h). Salvarli come frida-core-linux.h o frida-core-ios.h a seconda della piattaforma.update_frida_version.sh prima della compilazione.Requisiti solo quando si esegue in modalità AFL++:
CFLAGS="-DUSEMMAP=1".CFLAGS="-DUSEMMAP=1 -DTARGET_OS_IOS".Fpicker può essere compilato per macOS, iOS o Linux. Il Makefile attualmente supporta solo la compilazione per iOS su macOS, ma dovrebbe essere del tutto possibile compilare fpicker utilizzando un toolchain iOS su Linux.
A seconda del target desiderato, eseguire:
make fpicker-macos
make fpicker-ios
make fpicker-linux
per compilare fpicker.
Una volta compilato fpicker, è necessario compilare l'harness di fuzzing:
Vedere la cartella examples per diversi casi di fuzzing di esempio. L'approccio generale è il seguente:
examples/test/test.js) (vedere qui per maggiori informazioni sugli harness)frida-compile test.js -o harness.jsOra fpicker può iniziare il fuzzing. Il comando esatto dipende fortemente dalla configurazione e dall'impostazione. Di seguito vengono forniti alcuni casi di esempio. Questi corrispondono principalmente agli esempi nella cartella examples.
afl-fuzz -i examples/test-network/in -o ./examples/test-network/out -- \\
./fpicker --fuzzer-mode afl -e attach -p test-network -f ./examples/test-network/harness.js
./fpicker --fuzzer-mode standalone -e attach -p server-process -f harness.js --input-mode cmd \\
--command "./client-send @@" -i indir -o outdir
./fpicker --fuzzer-mode active --communication-mode shm -e attach -p server-process -f harness.js \\
-i indir -o outdir --standalone-mutator cmd --mutator-command "radamsa"
./fpicker --fuzzer-mode passive --communication-mode send -e attach -p server-process -o outdir -f harness.js
./fpicker --fuzzer-mode active -e attach -p test -D remote -o examples/test/out/ -i examples/test/in/ \\
-f fuzzer-agent.js --standalone-mutator cmd --mutator-command "radamsa"
Ogni target richiede il proprio harness di fuzzing. La parte più importante di questo harness è definire la funzione di ingresso di Frida's Stalker, che determina efficacemente a quale punto viene inserita l'instrumentazione. Nella modalità in-process questo è semplice. La funzione sarebbe solitamente quella che viene chiamata ad ogni iterazione di fuzzing. Tuttavia, potrebbe anche essere una diversa.
Un'implementazione di harness minimalista (in modalità command) potrebbe essere questa:
// Import the fuzzer base class
const Fuzzer = require("harness/fuzzer.js");
// The custom fuzzer needs to subclass the Fuzzer class to work properly
class TestFuzzer extends Fuzzer.Fuzzer {
constructor() {
// The constructor needs to specify the address of the targeted function and a NativeFunction
// object that can later be called by the fuzzer.
const FUZZ_FUNCTION_ADDR = Module.getExportByName(null, "FUZZ_FUNCTION");
const FUZZ_FUNCTION = new NativeFunction(
FUZZ_FUNCTION_ADDR,
"void", ["pointer", "int64"], {
});
super("test", FUZZ_FUNCTION_ADDR, FUZZ_FUNCTION);
}
}
const f = new TestFuzzer();
exports.fuzzer = f;
Questo harness configura l'instrumentazione per seguire la funzione FUZZ_FUNCTION. L'instrumentazione inizierà quando questa funzione viene inserita e si ferma quando la funzione ritorna. Questa funzione dovrebbe essere scelta attentamente poiché è costosa e più parti (potenzialmente non importanti) del processo vengono instrumentate, più il fuzzer diventa lento. Ovviamente, è una considerazione tra velocità e copertura desiderata. Inoltre, il fuzzer attualmente supporta solo funzioni che vengono inserite una sola volta durante un'iterazione di fuzzing, cioè, la funzione non dovrebbe essere chiamata più di una volta durante un caso di fuzz, altrimenti le informazioni di copertura potrebbero diventare inaffidabili.
Quando si utilizza la modalità in-process, è richiesta un'altra funzione nello script del fuzzer. Il metodo fuzz. Verrà chiamato ad ogni iterazione. Verrà chiamato con due parametri, un puntatore a un buffer e la lunghezza del buffer. La nostra funzione target esemplificativa prende due parametri, un puntatore a un buffer e la sua lunghezza. Quindi, possiamo semplicemente passare i parametri che stiamo ottenendo nel metodo fuzz.
fuzz(payload, len) {
this.target_function(payload, parseInt(len));
}
In modalità passive, è necessario specificare un callback che elabora i dati richiesti. Il fuzzer si aspetta di ricevere un buffer payload e la sua lunghezza. A seconda della funzione target che viene fuzzata, questi dati devono essere estratti. Nell'esempio seguente, abbiamo di nuovo una funzione che ha due parametri: un puntatore a un buffer e la sua lunghezza. Il parametro args contiene tutti i potenziali parametri che la funzione target riceve, quindi il parametro lunghezza (che è il secondo nel nostro caso) può essere accesso con args[1]. Leggiamo quindi il buffer come Uint8Array e lo rimandiamo al fuzzer usando il metodo sendPassiveCorpus.
passiveCallback(args) {
const len = args[1];
const data = new Uint8Array(Memory.readByteArray(args[0], parseInt(len)));
// this encodes the data and sends it back to the fuzzer
this.sendPassiveCorpus(data, len);
}
Nel caso in cui il target necessiti di una qualche preparazione prima che il fuzzer possa iniziare, fpicker fornisce un metodo prepare che viene chiamato durante l'inizializzazione del fuzzer. La preparazione potrebbe essere l'instaurazione di uno stato, ad esempio, istanziando un oggetto. Tale funzione di preparazione potrebbe apparire come segue:
prepare() {
// the object can be attached to the fuzzer instance so that it can be used within the
// fuzz() method later on.
this.required_object = call_native_function_that_creates_object();
}
pficker offre un'ampia gamma di modalità e configurazioni che vengono spiegate di seguito. La maggior parte di queste modalità può essere combinata in diversi modi. Alla fine di questa sezione c'è una tabella che mostra quali opzioni possono essere combinate e qual è il loro stato di implementazione.
Fpicker ha tre diverse modalità di fuzzing: Modalità AFL++, Modalità Attiva Standalone e Modalità Passiva Standalone:
Modalità AFL++: In modalità AFL++, fpicker agisce come proxy tra AFL++ e il processo target. Utilizzando le capacità di instrumentazione di Frida, il bitmap di copertura di AFL viene popolato mentre il target viene fuzzato con dati di input generati da AFL++.
Modalità Attiva Standalone: In modalità attiva standalone, il fuzzer utilizza i riepiloghi delle chiamate Stalker di Frida per raccogliere la copertura sotto forma di blocchi di base eseguiti durante un'iterazione. Questo non è nuovo ed è stato implementato in varie forme in precedenza. Tuttavia, in combinazione con alcune altre impostazioni del fuzzer, può avere vari vantaggi. È anche una buona alternativa se AFL++ non è applicabile o desiderato in un determinato ambiente o caso.
Modalità Passiva Standalone: La modalità passiva è più un tracciatore che un fuzzer. Essenzialmente, fa la stessa cosa della modalità attiva standalone. Tuttavia, non invia i propri input. Si limita a collegarsi a una determinata funzione e raccogliere la copertura. Una volta osservata una nuova copertura, vengono memorizzati sia la copertura che l'input.
Sebbene fpicker sia progettato principalmente come fuzzer in-process, supporta anche il fuzzing tramite un comando esterno. Per questo, fpicker offre due modalità di input.
Modalità Input In-Process: Nella modalità input in-process, l'harness chiama direttamente una funzione specificata nel processo target. Il fuzzer invia il payload all'harness e l'harness prepara il payload in modo tale da poter chiamare la funzione target.
Modalità Input CMD: Nella modalità input comando, il payload viene reindirizzato a un comando esterno. Questo è utile quando è troppo complesso preparare i parametri o altro stato quando si chiama direttamente la funzione target. La raccolta della copertura deve ancora essere collegata a una determinata funzione. Forse esiste un client che può essere fornito con un payload che poi attiva la funzione target.
La modalità di comunicazione determina come l'harness iniettato comunica con il fuzzer. Questo dipende in gran parte dall'applicazione target. Frida offre un'API per inviare e ricevere messaggi dallo script agente iniettato. Questo tipo di comunicazione è piuttosto costoso. Uno dei fattori è che il messaggio trasportato deve essere codificato in JSON. Quindi inviare dati binari è semplice. Pertanto, fpicker offre una seconda modalità di comunicazione tramite memoria condivisa. Tuttavia, questo funziona solo se è possibile stabilire una memoria condivisa tra il fuzzer e l'applicazione target, il che significa che questa modalità non può essere utilizzata quando il target è collegato all'host del fuzzer tramite USB. In modalità input CMD, la modalità di comunicazione si riferisce solo a come le informazioni di copertura vengono comunicate al fuzzer, non a come viene inviato il payload, poiché questo è delegato a un comando esterno.
Modalità di Comunicazione Send: Nella modalità di comunicazione send, il payload viene inviato utilizzando il meccanismo di chiamata RPC di Frida. Questo permette al fuzzer di eseguire una funzione JavaScript all'interno dello script dell'harness iniettato. Questa funzione all'interno dell'harness può quindi fare tutte le preparazioni necessarie per chiamare la funzione target. Una volta che la funzione target ritorna, la raccolta della copertura si ferma e l'harness può segnalare al fuzzer che l'iterazione è terminata. Questo viene fatto inviando le informazioni di copertura al fuzzer utilizzando l'API send di Frida.
Modalità di Comunicazione SHM: Nella modalità di comunicazione SHM, il fuzzer e lo script dell'harness comunicano tramite memoria condivisa e semafori. Un buffer nella memoria condivisa viene utilizzato per inviare il payload e ricevere le informazioni di copertura. Invece di inviare e ricevere, i due componenti utilizzano l'attesa e il rilascio del semaforo. A seconda del sistema e del target, questo introduce notevoli guadagni di prestazioni. Soprattutto perché il payload binario viene scritto in memoria una volta e non deve essere codificato e decodificato o copiato in altre locazioni di memoria. Sfortunatamente, questa modalità a volte porta a una bassa stabilità quando si esegue con AFL++. Non sono ancora sicuro del perché.
La modalità di esecuzione può essere spawn o attach. Questo è abbastanza autoesplicativo. fpicker può collegarsi a un processo in esecuzione o generare un processo. Una differenza importante tra le due modalità è che, se il target collegato si blocca, fpicker non tenterà di rigenerarlo.
In modalità standalone fpicker offre tre diverse strategie di mutazione dell'input. Detto in modo carino, la mutazione dell'input ha certamente molto margine di miglioramento.
Mutator Standalone NULL: Questo mutator non muta il payload e restituisce solo una copia dello stesso payload. Principalmente a scopo di test. Altrimenti non molto utile.
Mutator Standalone Rand: Un mutator casuale molto scadente. Tutto ciò che fa è sostituire casualmente valori in posizioni casuali nel payload originale. Non modifica la lunghezza del payload.
Mutator Standalone Custom: Questo mutator può chiamare un comando esterno per mutare i payload. Scrive il payload su stdin e riceve il payload mutato da stdout. A causa della sua implementazione superficiale ha un notevole impatto sulle prestazioni.
Utilizzando l'opzione dispositivo -D usb, Frida selezionerà il primo dispositivo USB locale, ad esempio un iPhone o un telefono Android.
Con l'opzione -D remote è possibile fuzzare un processo in esecuzione su un dispositivo di rete. Per questo, il dispositivo remoto deve eseguire frida-server. Come configurazione di esempio, utilizzare SSH con port forwarding per associare la porta di ascolto predefinita 27042 del frida-server sul dispositivo remoto a un socket sul client locale.
ssh -N [email protected] -L 127.0.0.1:27042:127.0.0.1:27042
Su un iPhone, si può anche usare iproxy per inoltrare la porta da una connessione USB. Questo potrebbe essere particolarmente utile se si esegue Frida su una porta non standard su un dispositivo non jailbroken con il gadget Frida. Quando si lavora con il gadget Frida, l'unico processo disponibile avrà il nome Gadget, indipendentemente dal nome dell'app target.
iproxy 27042 27042
Quindi utilizzare frida-ps per validare la configurazione elencando i processi sul dispositivo remoto:
frida-ps -R