Exploiting Tools
Last updated
Last updated
Impara e pratica Hacking AWS:HackTricks Training AWS Red Team Expert (ARTE) Impara e pratica Hacking GCP: HackTricks Training GCP Red Team Expert (GRTE)
Puoi opzionalmente utilizzare questo fork di GEF che contiene istruzioni più interessanti.
Durante il debug, GDB avrà indirizzi leggermente diversi rispetto a quelli utilizzati dal binario quando eseguito. Puoi far sì che GDB abbia gli stessi indirizzi eseguendo:
unset env LINES
unset env COLUMNS
set env _=<path> Inserisci il percorso assoluto del binario
Sfrutta il binario utilizzando la stessa rotta assoluta
PWD e OLDPWD devono essere gli stessi quando si utilizza GDB e quando si sfrutta il binario
Quando hai un binario staticamente collegato, 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 all'utente.
Puoi facilmente identificare questo flusso eseguendo il binario con gdb fino a quando non ti viene chiesto di inserire un input. Poi, fermalo con CTRL+C e usa il comando bt (backtrace) per vedere le funzioni chiamate:
gdbserver --multi 0.0.0.0:23947 (in IDA devi riempire il percorso assoluto dell'eseguibile nella macchina Linux e nella macchina Windows)
Ghidra è molto utile per trovare l'offset per un buffer overflow grazie alle informazioni sulla posizione delle variabili locali.
Ad esempio, nell'esempio qui sotto, un buffer flow in local_bc indica che hai bisogno di un offset di 0xbc. Inoltre, se local_10 è un canary cookie, indica che per sovrascriverlo da local_bc c'è un offset di 0xac.
&#xNAN;Remember che i primi 0x08 da dove viene salvato il RIP appartengono al RBP.
Get every opcode executed in the program.
gcc -fno-stack-protector -D_FORTIFY_SOURCE=0 -z norelro -z execstack 1.2.c -o 1.2 --> Compila senza protezioni &#xNAN;-o --> Output &#xNAN;-g --> Salva il codice (GDB sarà in grado di vederlo) echo 0 > /proc/sys/kernel/randomize_va_space --> Per disattivare l'ASLR in linux
Per compilare un shellcode: nasm -f elf assembly.asm --> restituisce un ".o" ld assembly.o -o shellcodeout --> Eseguibile
-d --> Disassembla le sezioni eseguibili (vedi opcodes di un shellcode compilato, trova ROP Gadgets, trova indirizzo della funzione...) &#xNAN;-Mintel --> Sintassi Intel &#xNAN;-t --> Tabella dei simboli &#xNAN;-D --> Disassembla tutto (indirizzo di variabile statica) &#xNAN;-s -j .dtors --> sezione dtors &#xNAN;-s -j .got --> sezione got -D -s -j .plt --> sezione plt decompilata &#xNAN;-TR --> Ridenominazioni 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).
Esegui ulimit -c unlimited prima di avviare il mio programma
Esegui sudo sysctl -w kernel.core_pattern=/tmp/core-%e.%p.%h.%t
sudo gdb --core=<path/core> --quiet
ldd executable | grep libc.so.6 --> Indirizzo (se ASLR, allora questo cambia ogni volta) for i in `seq 0 20`; do ldd <Ejecutable> | grep libc; done --> Ciclo 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
All'interno della cartella IDA puoi trovare binari che possono essere utilizzati per eseguire il debug di un binario all'interno di un linux. Per farlo, sposta il binario linux_server o linux_server64 all'interno del server linux ed eseguilo nella cartella che contiene il binario:
Poi, configura il debugger: Debugger (linux remoto) --> Opzioni di processo...:
Impara e pratica il hacking AWS:HackTricks Training AWS Red Team Expert (ARTE) Impara e pratica il hacking GCP: HackTricks Training GCP Red Team Expert (GRTE)
