Exploiting Tools
Metasploit
Shellcodes
GDB
Install
Parametri
Istruzioni
È possibile utilizzare facoltativamente questo fork di GEF che contiene istruzioni più interessanti.
Trucchi
Stessi indirizzi in GDB
Durante il debug, GDB avrà indirizzi leggermente diversi rispetto a quelli utilizzati dal binario in esecuzione. Puoi fare in modo che GDB abbia gli stessi indirizzi facendo:
unset env LINES
unset env COLUMNS
set env _=<percorso>
Inserisci il percorso assoluto al binarioSfrutta il binario utilizzando lo stesso percorso assoluto
PWD
eOLDPWD
devono essere gli stessi quando si utilizza GDB e quando si sfrutta il binario
Backtrace per trovare le funzioni chiamate
Quando si ha un binario collegato staticamente, tutte le funzioni apparterranno al binario (e non a librerie esterne). In questo caso sarà difficile identificare il flusso che il binario segue per esempio per richiedere input dall'utente.
Puoi identificare facilmente questo flusso eseguendo il binario con gdb fino a quando ti viene richiesto l'input. Poi, interrompilo con CTRL+C e utilizza il comando bt
(backtrace) per vedere le funzioni chiamate:
Server GDB
gdbserver --multi 0.0.0.0:23947
(in IDA devi inserire il percorso assoluto dell'eseguibile nella macchina Linux e nella macchina Windows)
Ghidra
Trovare l'offset dello stack
Ghidra è molto utile per trovare l'offset per un buffer overflow grazie alle informazioni sulla posizione delle variabili locali.
Ad esempio, nell'esempio sottostante, un flusso di buffer in local_bc
indica che è necessario un offset di 0xbc
. Inoltre, se local_10
è un cookie canary, indica che per sovrascriverlo da local_bc
c'è un offset di 0xac
.
Ricorda che i primi 0x08 da dove viene salvato il RIP appartengono al RBP.
qtool
Ottenere ogni opcode eseguito nel programma.
GCC
gcc -fno-stack-protector -D_FORTIFY_SOURCE=0 -z norelro -z execstack 1.2.c -o 1.2 --> Compilare senza protezioni -o --> Output -g --> Salvare il codice (GDB potrà vederlo) echo 0 > /proc/sys/kernel/randomize_va_space --> Disattivare l'ASLR in linux
Per compilare uno shellcode: nasm -f elf assembly.asm --> restituisce un ".o" ld assembly.o -o shellcodeout --> Eseguibile
Objdump
-d --> Disassemblare sezioni eseguibili (vedere gli opcode di uno shellcode compilato, trovare ROP Gadgets, trovare indirizzi di funzioni...) -Mintel --> Sintassi Intel -t --> Tabella dei simboli -D --> Disassemblare tutto (indirizzo di variabile statica) -s -j .dtors --> sezione dtors -s -j .got --> sezione got -D -s -j .plt --> sezione plt decompilata -TR --> Relocalizzazioni ojdump -t --dynamic-relo ./exec | grep puts --> Indirizzo di "puts" da modificare in GOT objdump -D ./exec | grep "VAR_NAME" --> Indirizzo di una variabile statica (queste sono memorizzate nella sezione DATA).
Core dumps
Eseguire
ulimit -c unlimited
prima di avviare il mio programmaEseguire
sudo sysctl -w kernel.core_pattern=/tmp/core-%e.%p.%h.%t
sudo gdb --core=<path/core> --quiet
Altro
ldd executable | grep libc.so.6 --> Indirizzo (se ASLR, questo cambia ogni volta) for i in `seq 0 20`; do ldd <Ejecutable> | grep libc; done --> Loop per vedere se l'indirizzo cambia molto readelf -s /lib/i386-linux-gnu/libc.so.6 | grep system --> Offset di "system" strings -a -t x /lib/i386-linux-gnu/libc.so.6 | grep /bin/sh --> Offset di "/bin/sh"
strace executable --> Funzioni chiamate dall'eseguibile rabin2 -i ejecutable --> Indirizzo di tutte le funzioni
Debugger di Immunity
IDA
Debugging in remoto su Linux
All'interno della cartella IDA è possibile trovare binari che possono essere utilizzati per eseguire il debug di un eseguibile all'interno di un sistema Linux. Per farlo, spostare l'eseguibile linux_server
o linux_server64
all'interno del server Linux e eseguirlo all'interno della cartella che contiene l'eseguibile:
Quindi, configurare il debugger: Debugger (linux remoto) --> Opzioni del processo...:
Last updated