bannsec/autopwnAutomatizza compiti ripetitivi per il fuzzing
Completamente riscritto in questo momento. L'attenzione sarà sulle applicazioni Linux interattive che accettano solo input da stdin per iniziare. Si tenta di utilizzare la funzionalità Driller e Fuzzer di Shellphish.
autoPwn nel suo stato attuale farà questo in forma limitata. Basta eseguire autoPwn ./binary e poi selezionare l'opzione Start.
Dati tutti i problemi di dipendenza, il modo più semplice per far funzionare autoPwn è usare la build Docker. Nota, puoi rimuovere le opzioni --security-opt e --cap-add, ma alcuni aspetti del fuzzing potrebbero non funzionare.
$ sudo docker pull bannsec/autoPwn
$ sudo docker run -it -v $PWD:/mount --security-opt="apparmor=unconfined" --cap-add=SYS_PTRACE -e DISPLAY=$DISPLAY -v /tmp/.X11-unix/:/tmp/.X11-unix/ bannsec/autopwn
Nella build Docker, tutto dovrebbe essere pronto. Puoi semplicemente avviare lo strumento con:
$ autoPwn ./file
autoPwn cerca di rendere più facile la compilazione del sorgente per il fuzzing di un progetto. Per aiutare in questo, è stato creato autoPwnCompile. Basta puntarlo al tuo codice sorgente, dargli le opzioni e produrrà un eseguibile pronto per il fuzzing.
usage: autoPwnCompile [-h] [--file FILE] [--ASAN | --MSAN] [--UBSAN]
[--fuzzer FUZZER]
Compile source to binaries for use in autoPwn.
optional arguments:
-h, --help show this help message and exit
--file FILE Single file to compile.
--ASAN Enable ASAN (default off)
--MSAN Enable MSAN (default off)
--UBSAN Enable UBSAN (default off)
--fuzzer FUZZER (optional) What fuzzer to compile for. Options are:
['AFL']. Default is AFL.
Quanto segue è dalla VECCHIA versione di autoPwn..
autoPwn è un nome altisonante per un semplice script. Lavorando con fuzzing e afl-fuzz, ho notato che facevo sempre le stesse operazioni. Con questo in mente, volevo creare uno script che realizzasse quanto segue:
Finora, lo script è in grado di fare i primi 5. La parte 6 è speculativa e si sta tentando di svilupparla ora. Sfrutterebbe il motore di esecuzione simbolica angr per creare possibili percorsi iniziali. A quel punto, lo script potrebbe teoricamente automatizzare completamente compiti di fuzzing semplici.
Diamo un'occhiata a una recente sfida TUCTF chiamata "WoO2". Anche se non trova necessariamente l'exploit necessario, mostra come autoPwn possa essere utilizzato per semplificare la scoperta dei percorsi.
Ecco un'esecuzione di base del programma:
$ ./e67eb287f23011a40ef5bd5c2ad2f48ca97834cf
Welcome! I don't think we're in Kansas anymore.
We're about to head off on an adventure!
Select some animals you want to bring along.
Menu Options:
1: Bring a lion
2: Bring a tiger
3: Bring a bear
4: Delete Animal
5: Exit
Enter your choice:
1
Choose the type of lion you want:
1: Congo Lion
2: Barbary Lion
1
Enter name of lion:
Test
Menu Options:
1: Bring a lion
2: Bring a tiger
3: Bring a bear
4: Delete Animal
5: Exit
Enter your choice:
5
Creiamo un semplice caso di test di input:
$ cat in/1
1
1
Test
5
Ora possiamo avviare facilmente il fuzzer:
$ autoPwn
Setting up fuzz configuration
Target Binary (full or relative path): e67eb287f23011a40ef5bd5c2ad2f48ca97834cf
Command line args:
Number of cores (default: 8):
Test Case Dir (default: 'in/'):
Test Case Dir (default: 'out/'):
Max memory (default: 200): 4096
Starting fuzz
autoPwn> s
status check tool for afl-fuzz by <[email protected]>
Individual fuzzers
==================
>>> SESSION007 (0 days, 0 hrs) <<<
cycle 1, lifetime speed 1 execs/sec, path 0/1 (0%)
pending 1/1, coverage 0.15%, no crashes yet
>>> SESSION000 (0 days, 0 hrs) <<<
cycle 1, lifetime speed 1 execs/sec, path 0/1 (0%)
pending 1/1, coverage 0.15%, no crashes yet
>>> SESSION002 (0 days, 0 hrs) <<<
cycle 1, lifetime speed 1 execs/sec, path 0/1 (0%)
pending 1/1, coverage 0.15%, no crashes yet
>>> SESSION006 (0 days, 0 hrs) <<<
cycle 1, lifetime speed 1 execs/sec, path 0/1 (0%)
pending 1/1, coverage 0.15%, no crashes yet
>>> SESSION004 (0 days, 0 hrs) <<<
cycle 1, lifetime speed 1 execs/sec, path 0/1 (0%)
pending 1/1, coverage 0.15%, no crashes yet
>>> SESSION001 (0 days, 0 hrs) <<<
cycle 1, lifetime speed 1 execs/sec, path 0/1 (0%)
pending 1/1, coverage 0.15%, no crashes yet
>>> SESSION005 (0 days, 0 hrs) <<<
cycle 1, lifetime speed 1 execs/sec, path 0/1 (0%)
pending 1/1, coverage 0.15%, no crashes yet
>>> SESSION003 (0 days, 0 hrs) <<<
cycle 1, lifetime speed 1 execs/sec, path 0/1 (0%)
pending 1/1, coverage 0.15%, no crashes yet
Summary stats
=============
Fuzzers alive : 8
Total run time : 0 days, 0 hours
Total execs : 0 million
Cumulative speed : 8 execs/sec
Pending paths : 8 faves, 8 total
Pending per fuzzer : 1 faves, 1 total (on average)
Crashes found : 0 locally unique
autoPwn> h
autoPwn
s == fuzzer (s)tatus
e == collect (e)xploits
a == collect (a)ll paths
m == (m)inimize corpus
q == (q)uit
Quindi quello che è successo qui è che lo script ha creato alcuni valori predefiniti (inclusa la determinazione del numero di core disponibili). Abbiamo modificato un valore predefinito a causa della necessità di memoria extra per eseguire questo in QEMU. autoPwn ha creato un file di configurazione che poi ha passato a afl-utils (https://github.com/rc0r/afl-utils). Nel file di configurazione, ha anche impostato le affinità della CPU, in modo che il fuzzing fosse ottimale per impostazione predefinita.
A questo punto, il tuo computer sta lavorando al fuzzing. Tuttavia, un aspetto chiave del fuzzing è la minimizzazione del corpus. Con questo in mente, autoPwn osserva l'istanza di afl-fuzz per monitorare quando una serie di mutazioni è completata. Quando ciò accade, fermerà il fuzzing (non ottimale, ma va bene per ora), minimizzerà il corpus, poi riavvierà il fuzzing. Lo fa senza alcun intervento umano, così puoi impostare e dimenticare.
A un certo punto potresti voler dare un'occhiata a quali percorsi afl ha trovato. Eseguendo il comando "a", autoPwn copierà tutti i percorsi noti, minimizzerà il corpus e poi minimizzerà i casi stessi e li fornirà in una directory di output.