Ricerca tra la vecchia roba

Exploit: prevenire NON è meglio che curare

Posted: settembre 11th, 2011 | Author: | Filed under: Guide | Tags: , , , | Commenti disabilitati su Exploit: prevenire NON è meglio che curare

Eccoci alla seconda puntata di come capire il funzionamento degli exploit; l’ultima volta siamo rimasti alla potenziale modifica del flusso di un programma scritto male a nostro uso e consumo, oggi non andremo di molto avanti in quanto cercheremo di capire assieme come viene gestita la memoria relativa ad un processo in un OS moderno. Partire subito con esempi di exploit non sarebbe utile perché gli esempi semplici praticamente non esistono: il primo paper di Aleph1 risale al 1996 e da allora i sistemi informatici si sono evoluti con contromisure proprio atte a evitare il succedersi di intrusioni alzando sempre di più l’asticella della difficoltà insita nel deviare il $pc tanto agognato.

C’è da dire che benché molti sforzi siano stati fatti, la genialità degli exploiter è cresciuta altrettanto portando questa pratica ad uno stato quasi magico. Ma bando alle ciance e iniziamo ad analizzare come è strutturato un programma (mi limiterò al formato eseguibile ELF of course).

Teoria

Nella prima parte abbiamo visto come un programma funziona a livello di istruzioni, ma per eseguire istruzioni un programma ha prima di tutto bisogno di essere caricato in memoria; bisogna tenere conto che ci saranno zone di memoria apposite per ogni tipo di necessità, elenchiamole:

  • Stack: visto sempre nella puntata precedente, contiene le variabili locali del contesto di esecuzione più le variabili della funzione attualmente in esecuzione
  • File mappings: esiste la possibilità di mappare direttamente file in memoria ed è anche il metodo con cui vengono caricate le shared library (ne parlerò un po’ meglio dopo)
  • Heap: zone di memoria allocate dinamicamente (in pratica malloc() et familia)
  • BSS: variabili statiche non inizializzate
  • Data: variabili statiche inizializzate
  • Text: contiene il codice eseguibile

Ognuna di queste sezioni ha ovviamente delle proprietà sue proprie, in particolare può essere scrivili,leggibile ed eseguibile. Per avere un esempio pratico eseguiamo

$ cat /proc/self/maps
08048000-08052000 r-xp 00000000 08:21 8421442    /bin/cat
08052000-08053000 rw-p 0000a000 08:21 8421442    /bin/cat
0875a000-0877b000 rw-p 00000000 00:00 0          [heap]
b74bc000-b76bc000 r--p 00000000 08:21 1035297    /usr/lib/locale/locale-archive
b76bc000-b76bd000 rw-p 00000000 00:00 0
b76bd000-b7810000 r-xp 00000000 08:21 29540827   /lib/i386-linux-gnu/i686/cmov/libc-2.13.so
b7810000-b7811000 ---p 00153000 08:21 29540827   /lib/i386-linux-gnu/i686/cmov/libc-2.13.so
b7811000-b7813000 r--p 00153000 08:21 29540827   /lib/i386-linux-gnu/i686/cmov/libc-2.13.so
b7813000-b7814000 rw-p 00155000 08:21 29540827   /lib/i386-linux-gnu/i686/cmov/libc-2.13.so
b7814000-b7817000 rw-p 00000000 00:00 0
b784a000-b784c000 rw-p 00000000 00:00 0
b784c000-b784d000 r-xp 00000000 00:00 0          [vdso]
b784d000-b7868000 r-xp 00000000 08:21 29540776   /lib/i386-linux-gnu/ld-2.13.so
b7868000-b7869000 r--p 0001b000 08:21 29540776   /lib/i386-linux-gnu/ld-2.13.so
b7869000-b786a000 rw-p 0001c000 08:21 29540776   /lib/i386-linux-gnu/ld-2.13.so
bfb95000-bfbb6000 rw-p 00000000 00:00 0          [stack]

Come potete vedere vengono visualizzati i vari mappings che il programma ha nella sua esecuzione; per capire cosa significhi ‘sta roba ecco a voi la pagina di man

/proc/[pid]/maps
 A file containing the currently mapped memory regions and their access permissions.

 The format is:

 address           perms offset  dev   inode   pathname
 08048000-08056000 r-xp 00000000 03:0c 64593   /usr/sbin/gpm
 08056000-08058000 rw-p 0000d000 03:0c 64593   /usr/sbin/gpm
 08058000-0805b000 rwxp 00000000 00:00 0
 40000000-40013000 r-xp 00000000 03:0c 4165    /lib/ld-2.2.4.so
 40013000-40015000 rw-p 00012000 03:0c 4165    /lib/ld-2.2.4.so
 4001f000-40135000 r-xp 00000000 03:0c 45494   /lib/libc-2.2.4.so
 40135000-4013e000 rw-p 00115000 03:0c 45494   /lib/libc-2.2.4.so
 4013e000-40142000 rw-p 00000000 00:00 0
 bffff000-c0000000 rwxp 00000000 00:00 0

 where "address" is the address space in the process that it occupies, "perms" is a set of permissions:

 r = read
 w = write
 x = execute
 s = shared
 p = private (copy on write)

 "offset"  is  the  offset  into  the  file/whatever,  "dev" is the device (major:minor), and "inode" is the inode on that
 device.  0 indicates that no inode is associated with the memory region, as the case would  be  with  BSS  (uninitialized
 data).

 Under Linux 2.0 there is no field giving pathname.

Piccolo appunto: se controllate i mappings in vari programmi eseguiti contemporanemente potreste chiedervi come mai c’è un overlap fra le varie regioni di memoria fra programmi diversi e la spiegazione è semplice: ogni programma ha a disposizione virtualmente 3GB di memoria flat, è il sistema operativo che si preoccupa di eseguire i mappings virtuale/fisico in maniera corretta.

Tornando all’ouput di cui sopra potete vedere che tutte le zone di memoria elencate sono presenti con in più una zona chiamata vdso (Virtual Dynamic Shared Object) che si preoccupa di fare da trampolino per le syscall (invenzione di linus che dichiara “I’m a disgusting pig, and proud of it to boot.“)

Prendiamo il seguente programma

#include<stdio.h>
#include<string.h>

int main(int argc, char* argv[]) {
 char* unitialized;
 static char* s_unitialized;
 char initialized[] = "porcamadonna";
 static char s_initialized[] = "porcamadonna";

 printf("process %d \n"
  "\t       uninitialzed: 0x%08x\n"
  "\tstatic uninitialzed: 0x%08x\n"
  "\t       initialized:  0x%08x\n"
  "\tstatic initialized:  0x%08x\n",
  getpid(), &unitialized, &s_unitialized, &initialized, &s_initialized);

 int iMustWait = !(argc > 1 && ! strcmp(argv[1], "-go"));
 if (iMustWait)
  getchar();

 return 0;
}

e compiliamolo

$ gcc segment.c -o segment

Una volta lanciato si bloccherà mostrandoci gli indirizzi di memoria assegnati alle variabili

$ ./segment
process 11663
        uninitialzed: 0xbf9e3ad8
 static uninitialzed: 0x08049804
        initialized:  0xbf9e3acb
 static initialized:  0x080497ec

Se controlliamo il map del programma in esecuzione

$ cat /proc/11663/maps
08048000-08049000 r-xp 00000000 08:13 3556546    /home/packz/Programmazione/Ci/Exploit/Data segment/segment
08049000-0804a000 rw-p 00000000 08:13 3556546    /home/packz/Programmazione/Ci/Exploit/Data segment/segment
b76ad000-b76ae000 rw-p 00000000 00:00 0
b76ae000-b7801000 r-xp 00000000 08:21 29540770   /lib/i386-linux-gnu/i686/cmov/libc-2.13.so
b7801000-b7802000 ---p 00153000 08:21 29540770   /lib/i386-linux-gnu/i686/cmov/libc-2.13.so
b7802000-b7804000 r--p 00153000 08:21 29540770   /lib/i386-linux-gnu/i686/cmov/libc-2.13.so
b7804000-b7805000 rw-p 00155000 08:21 29540770   /lib/i386-linux-gnu/i686/cmov/libc-2.13.so
b7805000-b7808000 rw-p 00000000 00:00 0
b7839000-b783d000 rw-p 00000000 00:00 0
b783d000-b783e000 r-xp 00000000 00:00 0          [vdso]
b783e000-b7859000 r-xp 00000000 08:21 29540856   /lib/i386-linux-gnu/ld-2.13.so
b7859000-b785a000 r--p 0001b000 08:21 29540856   /lib/i386-linux-gnu/ld-2.13.so
b785a000-b785b000 rw-p 0001c000 08:21 29540856   /lib/i386-linux-gnu/ld-2.13.so
bf9c4000-bf9e5000 rw-p 00000000 00:00 0          [stack]

possiamo vedere che le variabili statiche (cioé globali all’interno del flusso del programma) sono nello spazio di memoria indicato nella seconda riga. Le altre sono nello spazio dello stack (ultima riga).

Tuttavia fra le due variabili statiche c’è una leggera differenza: se andiamo a vedere con readelf i section headers scopriamo che la variabile inizializzata punta alla sezione .data, mentre quella non inizializzata alla sezione .bss

$ readelf -S segment
There are 31 section headers, starting at offset 0x934:

Section Headers:
 [Nr] Name              Type            Addr     Off    Size   ES Flg Lk Inf Al
 [ 0]                   NULL            00000000 000000 000000 00      0   0  0
...
 [25] .data             PROGBITS        080497e4 0007e4 000018 00  WA  0   0  4
 [26] .bss              NOBITS          080497fc 0007fc 00000c 00  WA  0   0  4
...
 [30] .strtab           STRTAB          00000000 00126c 00024a 00      0   0  1
Key to Flags:
 W (write), A (alloc), X (execute), M (merge), S (strings)
 I (info), L (link order), G (group), T (TLS), E (exclude), x (unknown)
 O (extra OS processing required) o (OS specific), p (processor specific)

Un ulteriore segmento di memoria è quello denominato heap che è associato con l’allocazione dinamica di memoria (si pensi alle varie malloc(), calloc() e free()). A livello implementativo sono variazioni della chiamata di sistema brk() che per esempio nelle libc è eseguita tramite la Doug Lea’s malloc; se avrò tempo un giorno potrei scrivere come eseguire exploit dall’heap, pratica molto diffusa nei browser.

L’argomento che rimane da discutere è il caricamento delle librerie dinamiche che necessità l’eseguibile e ciò avviene tramite l’uso dell’interpreter (nei sistemi linux rappresentato da /lib/linux-so.2). In realtà quando un file eseguibile viene lanciato (funzione load_elf_binary in fs/binfmt.c), il kernel si preoccupa di leggere dall’apposita sezione del file ELF proprio quale è il suo interpreter  e dopo aver impostato opportunamente le zone di memoria carica le librerie necessarie al funzionamento del programma tramite esso. Se interessa il codice di ld.so si trova nella directory elf/ del tree delle libc; il suo punto di ingresso è la funzione dl_main in rtld.c.

Siccome le librerie vengono caricate a run-time esiste un processo chiamato di relocation che avviene all’interno di un processo ELF quando si necessità di eseguire una routine appartenente ad una libreria esterna: se disassembliamo il programma segment, possiamo vedere che alla riga in cui viene eseguita la call alla printf, la jump salta alla sezione .plt del nostro eseguibile

$gdb segment
Reading symbols from /home/packz/Programmazione/Ci/Exploit/Data segment/segment...(no debugging symbols found)...done.
(gdb)disassemble main
...
0x080484ad <+89>:    call   0x8048350 <printf@plt>
...

Se disassembliamo quella sezione otteniamo

$ objdump -j .plt -d segment

segment:     file format elf32-i386

Disassembly of section .plt:

08048340 <printf@plt-0x10>:
 8048340:       ff 35 c8 97 04 08       pushl  0x80497c8
 8048346:       ff 25 cc 97 04 08       jmp    *0x80497cc
 804834c:       00 00                   add    %al,(%eax)
 ...

08048350 <printf@plt>:
 8048350:       ff 25 d0 97 04 08       jmp    *0x80497d0
 8048356:       68 00 00 00 00          push   $0x0
 804835b:       e9 e0 ff ff ff          jmp    8048340 <_init+0x38>

Se in gdb andiamo a vedere che indirizzo c’è scritto alla cella di memoria 0x80497d0

(gdb) x/a 0x80497d0
0x80497d0 <printf@got.plt>:    0x8048356 <printf@plt+6>

con stupore scopriamo che punta alla istruzione successiva. Seguendo il flusso delle istruzioni vediamo che viene pushato un numero (l’indice della funzione da relocare) e avviene una jump all’inizio della sezione .plt; viene pushato un indirizzo (?) e si salta alla routine (call *0x80497cc) che andrà a risolvere la routine printf. L’indirizzo di quest’ultima jump è riempito dal linker all’avvio del programma.

Finita la routine all’indirizzo 0x80497d0 si ritroverà direttamente l’indirizzo della funzione in questione così da non aver più necessità di rieseguire tutto la relocazione alla prossima invocazione della printf. La Procedure Linkage Table e la Global Offset Table hanno un ruolo molto importante nella scrittura degli exploit avanzati, spero di poterlo spiegare in futuro.

Dopo tutta la teoria

Dopo tutto questo viaggio sulle varie zone di memoria possiamo passare al collegare questo con la sicurezza di un eseguibile: per prima cosa c’è da notare che se andiamo ad eseguire lo stesso programma due volte e controlliamo gli indirizzi assegnati alle varie aree di memoria scopriamo che tutti gli indirizzi tranne quelli per il codice e dei dati globali sono cambiati, in particolare sono randomizzati.

Questa è una delle prime contromisure sviluppate nel corso degli anni per prevenire i buffer overflow: se gli indirizzi cambiano ogni volta non è così facile scrivere un exploit che funzioni correttamente.

Per sapere come è implementata la randomizzazione leggetevi questo post: https://xorl.wordpress.com/2011/01/16/linux-kernel-aslr-implementation/.

Secondo step di protezione è lo stack non eseguibile (NX): siccome il codice per l’exploit viene posto (solitamente) nello stack e si cerca di eseguirlo da lì, rimuovendo dalle pagine di memoria dello stack il bit eseguibile provoca un segmentation fault quando l’istruction pointer viene dirottato in quelle zone. Come si nota l’unica zona eseguibile è quella text e le librerie condivise.

Terzo step di protezione è l’anteporre al frame dello stack dei valori random che vengono chiamati canary values da controllare al termine di una routine per la loro corruzione: siccome un buffer overflow dovrà per forza passare attraverso questi valori corrompendoli, la protezione dovrebbe essere effettiva.

L’ultimo livello di protezione è la cosiddetta ASCII-Armor, cioé caricare librerie  con indirizzi contenenti un byte nullo in maniera da rendere impossibile utilizzare tali indirizzi in un payload.

Purtroppo(?) tutte queste contromisure sono (per la maggior parte dei casi)  inutili, un eseguibile ha dentro di se abbastanza spazio di azione da rendere un overflow exploitabile nella maggioranza dei casi; nei post futuri spero di riuscire a spiegare come.


Exploit: intro

Posted: agosto 20th, 2011 | Author: | Filed under: Guide | Tags: , , , , | 2 Comments »

L’hacking da che mondo e mondo tratta l’usare uno strumento in un modo non concepito dal suo inventore; chi si occupa di programmazione e non solo si deve preoccupare in maniera critica di non esporre il proprio lavoro a mani poco scrupolose. Io non mi ritengo un esperto ma ci sono alcune cose che mi affascinano, tra queste la programmazione a basso livello e gli exploit (due cose molto legate tra loro).

Chi si fosse chiesto come sia possibile entrare in un computer altrui questo vuol essere un intro non esauriente (spero ulteriori posts seguiranno) che possa gettare luce.

Partiamo da un programma molto semplice

int bau(char* porcodio, int alpha) {
    return porcodio[0] + alpha;
}
 
int main(int argc, char* argv[]) {
    return bau("bastardo", 137);
}

Questo programma non fa niente di utile (se non un po’ di blasfemia spicciola) ma servirà a noi per capire come funziona sotto il cofano un programma per computer (quanto segue è tutto eseguito su sistemi x86).

Per prima cosa compiliamolo

$ gcc boh.c -o boh

e lanciamolo controllando il valore di ritorno

$ ./boh
$ echo $?
235

Entusiasmante vero (235 = ‘p’+ 137 dove il valore ASCII di “p” è 98)? ok, adesso proviamo a vedere passo passo cosa succede; utilizziamo il fido compagno di ogni programmatore, il prode gdb: lanciamolo e impostiamolo in maniera tale da fermarsi alla funzione main e mostrare le istruzioni a livello assembler

$ gdb -q ./boh
Reading symbols from /sti/cazzi/boh...(no debugging symbols found)...done.
(gdb) b main
Breakpoint 1 at 0x80483cb
(gdb) display /3i $pc

Piccolo appunto: il linguaggio assembler è il linguaggio a più basso livello con cui si può dialogare con un processore ed è ovviamente unico per ogni tipologia di architettura: l’assembler per x86 è diverso da quello per x86_64 e quello per ARM, ognuno ha le sue peculiarità ma la cosa più importante è capire che sono simili ma incompatibili.

Per chi non conoscesse il linguaggio assembler un piccolo riassunto: siccome parla con il processore le sue variabili possono essere solo i vari registri del processore stesso; in un sistema x86 si hanno i registri eax, ebx, ecx, edx che sono registri generici più dei registri più specifici come %ebp e %esp che gestiscono lo stack di cui parleremo più diffusamente subito dopo. Un registro molto importante è %eip che punta  all’indirizzo di memoria che contiene la prossima istruzione da eseguire (in gdb è $pc non so perché).

Lo stack è una parte fondamentale del sistema: è in pratica una area di memoria che contiene le variabili che una data routine deve gestire; infatti siccome i registri sono in numero limitato si ha bisogno di definire una area di memoria per gestire i dati. Lo stack permette di isolare le variabili locali proprie di una data routine definendo la base dello stack (puntata dal registro %ebp) e la cima dello stack (puntata dal registro %esp). Le istruzioni assembler per gestire lo stack sono push e pop, la prima inserisce nello stack il valore del registro indicato come argomento, il secondo invece fa l’opposto; la posizione nello stack è indicata da %esp che viene decrementato nel primo caso e incrementato nel secondo (nei sistemi x86 lo stack cresce verso il basso). In pratica lo stack è una coda LIFO (Last In First Out).

Facciamo girare il nostro programma e vediamo cosa succede in pratica

(gdb) r
Starting program: /sti/cazzi/boh 

Breakpoint 1, 0x080483cb in main ()
1: x/3i $pc
=> 0x80483cb <main+6>:    movl   $0x89,0x4(%esp)
 0x80483d3 <main+14>:    movl   $0x80484b0,(%esp)
 0x80483da <main+21>:    call   0x80483b4 <bau>

L’istruzione puntata dalla freccia muove nello stack il valore 137 mentre quella seguente mette la stringa “bastardo”

(gdb) x/s 0x80484b0
0x80484b0:     "bastardo"

Infine, l’ultima istruzione, chiama la funzione bau. Il perché di questa procedura consiste nel fatto che i parametri di una funzione devono essere passati nello stack in ordine inverso rispetto all’ordine nella definizione. Ultimo particolare da sapere è che l’istruzione call fa una push nello stack del registro %eip e salta all’indirizzo indicato come argomento.

Saltiamo alla funzione bau() eseguendo il comando si 3 volte così da ritrovarci in quello che viene chiamato prologo

0x080483b4 in bau ()
1: x/3i $pc
=> 0x80483b4 <bau>:    push   %ebp
 0x80483b5 <bau+1>:    mov    %esp,%ebp
 0x80483b7 <bau+3>:    mov    0x8(%ebp),%eax

Le prime due istruzioni sono chiamate in questo modo perché definiscono il frame per la funzione corrente, cioè il contesto in memoria dove collocare le variabili locali che saranno utilizzate da questa funzione; per farlo si imposta la base dello stack a coincidere con la cima dello stack. Tutto preceduto dal salvataggio del frame della precedente funzione.

In gdb è possibile ricavare questa info comodamente

(gdb) info frame
Stack level 0, frame at 0xbffff310:
 eip = 0x80483b7 in bau; saved eip 0x80483df
 called by frame at 0xbffff320
 Arglist at 0xbffff308, args:
 Locals at 0xbffff308, Previous frame's sp is 0xbffff310
 Saved registers:
 ebp at 0xbffff308, eip at 0xbffff30c

Quindi riassumendo, all’avvio di una nuova funzione nello stack saranno posizionate le seguenti variabili

secondo argomento
primo argomento
indirizzo di ritorno
vecchio ebp

una sopra l’altra. Sempre gdb ci aiuta

(gdb) x/4a $ebp
0xbffff308:    0xbffff318    0x80483df <main+26>    0x80484b0    0x89

Se analizziamo in toto la funzione bau, possiamo notare quello che si chiama epilogo nelle due ultime righe

(gdb) disassemble bau
Dump of assembler code for function bau:
 0x080483b4 <+0>:    push   %ebp
 0x080483b5 <+1>:    mov    %esp,%ebp
=> 0x080483b7 <+3>:    mov    0x8(%ebp),%eax
 0x080483ba <+6>:    movzbl (%eax),%eax
 0x080483bd <+9>:    movsbl %al,%eax
 0x080483c0 <+12>:    add    0xc(%ebp),%eax
 0x080483c3 <+15>:    pop    %ebp
 0x080483c4 <+16>:    ret   
End of assembler dump.

il cui scopo è ripristinare il frame precedente e riportare il flusso di esecuzione a dove era stata chiamata la funzione bau() recuperando dallo stack l’indirizzo di ritorno (ricordate cosa fa call? fa una push del registro %eip, ret lo recupera).

Bene, direte voi, ma chi se ne frega? vogliamo vedere la ciccia!!1!!!! Ok, state calmi, passiamo ad un altro programma tipo questo

int main(int argc, char* argv[]){
    char buffer[256];
    return strcpy(buffer, argv[1]);
}

Questo programma ha un difetto sostanziale, non controlla l’input dell’utente! abbiamo un buffer che può contenere 256 fucking char (grossi un byte) e ci copiamo dentro (senza fucking controllare) il primo argomento passato alla funzione. Quando non si controlla quello che si inserisce lato utente aspettatevi un problema, può essere un programma in C, in PHP o un controller di una view di una webapp.

Se proviamo a lanciare il programma passandogli 300 caratteri “A” cosa succede?

$ ./c `python -c 'print "A"*300'`
Errore di segmentazione (core dumped)

Oh, crasha! mio dio. Ma non finisce qui, se controlliamo con gdb il file core che ha creato scopriamo una cosa interessante

$ gdb -q ./c core
Reading symbols from /tmp/c...(no debugging symbols found)...done.
[New Thread 19714]

warning: Can't read pathname for load map: Errore di input/output.
Reading symbols from /lib/i386-linux-gnu/i686/cmov/libc.so.6...Reading symbols from /usr/lib/debug/lib/i386-linux-gnu/i686/cmov/libc-2.13.so...done.
done.
Loaded symbols for /lib/i386-linux-gnu/i686/cmov/libc.so.6
Reading symbols from /lib/ld-linux.so.2...(no debugging symbols found)...done.
Loaded symbols for /lib/ld-linux.so.2
Core was generated by `./c AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA'.
Program terminated with signal 11, Segmentation fault.
#0  0x41414141 in ?? ()

per capirci

(gdb) print $pc
$1 = (void (*)()) 0x41414141

Abbiamo sovrascritto il registro $pc, cioè (in teoria) abbiamo modificato il flusso del programma!!!Questo è successo semplicemente perché strcpy() è andata a copiare a partire dalla parte dello stack in cui era definita la variabile buffer andando a sbordare sopra il frame precedente e sovrascrivendo sia il vecchio %ebp che %eip. Infatti controllando i registri si conferma quanto detto

(gdb) info register
eax            0xbfce7c20    -1076986848
ecx            0x0    0
edx            0x12d    301
ebx            0xb76d3ff4    -1217576972
esp            0xbfce7d30    0xbfce7d30
ebp            0x41414141    0x41414141
esi            0x0    0
edi            0x0    0
eip            0x41414141    0x41414141
eflags         0x10246    [ PF ZF IF RF ]
cs             0x73    115
ss             0x7b    123
ds             0x7b    123
es             0x7b    123
fs             0x0    0
gs             0x33    51

Certo la strada è ancora lunga, ma in potenziale possiamo aprire una shell, ma questo è argomento di una prossima puntata.