Exploiting Tools
Last updated
Last updated
Impara e pratica l'Hacking su AWS: HackTricks Training AWS Red Team Expert (ARTE) Impara e pratica l'Hacking su GCP: HackTricks Training GCP Red Team Expert (GRTE)
È possibile utilizzare facoltativamente questo fork di GEF che contiene istruzioni più interessanti.
Durante il debug, GDB avrà indirizzi leggermente diversi rispetto a quelli utilizzati dal binario in esecuzione. È possibile far sì che GDB abbia gli stessi indirizzi eseguendo i seguenti passaggi:
unset env LINES
unset env COLUMNS
set env _=<percorso> Inserisci il percorso assoluto al binario
Sfrutta il binario utilizzando lo stesso percorso assoluto
PWD e OLDPWD devono essere gli stessi quando si utilizza GDB e quando si sfrutta il binario
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.
È possibile 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:
gdbserver --multi 0.0.0.0:23947 (in IDA devi inserire 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 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.
Ottenere ogni opcode eseguito nel programma.
gcc -fno-stack-protector -D_FORTIFY_SOURCE=0 -z norelro -z execstack 1.2.c -o 1.2 --> Compila senza protezioni -o --> Output -g --> Salva il codice (GDB potrà vederlo) echo 0 > /proc/sys/kernel/randomize_va_space --> Per disattivare l'ASLR in Linux
Per compilare uno shellcode: nasm -f elf assembly.asm --> restituisce un ".o" ld assembly.o -o shellcodeout --> Eseguibile
-d --> Disassembla le sezioni eseguibili (vedi opcode di uno shellcode compilato, trova ROP Gadgets, trova l'indirizzo di una funzione...) -Mintel --> Sintassi Intel -t --> Tabella dei simboli -D --> Disassembla 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).
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, 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
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...:
Impara e pratica l'Hacking su AWS:HackTricks Training AWS Red Team Expert (ARTE) Impara e pratica l'Hacking su GCP: HackTricks Training GCP Red Team Expert (GRTE)
