Continuando con la serie Protostar, in questo articolo andremo ad analizzare una tecnica più avanzata rispetto allo Stack Buffer Overflow. Per questo motivo ho deciso di dividere in più articoli la serie Heap, facendo un livello per articolo.

Introduzione

Quando un programma viene eseguito, viene allocata dinamicamente della memoria per contenere i dati dello stesso. Lo heap è quindi un blocco di memoria assegnato ad un processo di dimensione definita a run-time.

L’allocazione della memoria in C avviene tramite diverse funzioni, tra le principali:

• Malloc(size): utilizzata per allocare un’area di memoria di una certa dimensione
• Free(*p): utilizzata per deallocare la memoria allocata in precedenza alla posizione *p

Per una descrizione più approfondita consiglio questo articolo.

Queste funzioni, se non gestite in maniera corretta, possono essere suscettibili ad overflow nel caso in cui si possa inserire una quantità di dati superiore alla memora allocata e di conseguenza andare a sovrascrivere aree di memoria adiacenti. La differenza con lo stack, dal punto di vista dell’attaccante, è che nell’area heap sono memorizzati solo puntatori e di conseguenza bisogna creare una chain di shellcode per ottenere un exploit funzionante.

[Per comprendere meglio su GDB i processi interni ho deciso di installare PwnGDB e Peda-Heap, che consiglio vivamente]

Heap 0

In questo caso l’esercizio è molto simile alla serie stack, in quanto a riga 36 possiamo vedere come la funzione strcpy copi la variabile passata a linea di comando all’interno di name (che fa parte della struct data) senza nessun controllo. Di conseguenza, sarà possibile andare a sovrascrivere il puntatore fp ed inserire al suo posto il puntatore a winner.

Se proviamo ad inserire un breakpoint alla fine ed eseguirlo con un semplice AAAA, possiamo analizzare cosa succede dietro le quinte.

Come si può vedere, la variabile data e fp risiedono nello heap e fp è assegnato alla funzione nowinner (che ha stampato Level has not been passed). Andando a guardare nel dettaglio

Con il primo comando analizziamo la struttura dati del processo, con il secondo gli indirizzi di memoria dello heap (dove vediamo il nostro AAAA), mentre con il terzo il contenuto di fp.

Avendo capito il giro, ora ci basterà:

1. Trovare l’offset per andare a sovrascrivere il puntatore a nowinner e modificarlo con winner. Questo lo otteniamo con il comando

osboxes@osboxes:~/Desktop/Protostar$   echo $  ((0x804b050 - 0x804b008)) 72

2. Trovare l’indirizzo della variabile winner da gdb

gdb-peda$   p *winner $  1 = {void ()} 0x804849b

Unendo le due cose, possiamo eseguire il programma con il payload cosi formato

Vediamo come ora la situazione sia cambiata, e ESP punta a winner

La sovrascrittura ha funzionato perfettamente e abbiamo puntato ad una funzione diversa rispetto a quella originale.

Possiamo ovviamente fare lo stesso giro direttamente fuori da GDB

Conclusione

Sebbene questo esercizio sia molto simile ai precedenti, abbiamo iniziato a scalfire solo la punta dell’iceberg. Esistono diversi attacchi allo heap, e nel prossimo esercizio il discorso sarà già molto più approfondito e con una metodologia decisamente diversa. Come approfondimento per ora consiglio solo questo piccolo libro, in modo tale da avere le idee chiare per il prossimi esercizio

Rispetto al precedente livello, in questo caso il focus inizia ad essere sullo heap e sulla sua struttura, ed andremo quindi a comprendere meglio come è fatto e come è possibile, ovviamente, exploitarlo.

Heap 1

Come per lo scorso esercizio, andiamo ad inserire un breakpoint alla fine del codice (riga 35) e eseguiamo dentro gdb con il comando r AA BB. Dopodiché analizziamo lo heap

Si può notare che al suo interno abbiamo:

• 0x00000001: è la variabile priority dello struct internet i1, assegnata a riga 24
• 0x0804b018: è il puntatore all’array name di i1, che vale 0x00004141 (AA)
• 0x00000002: è la variabile priority dello struct internet i2, assegnata a riga 28
• 0x0804b038: è il puntatore all’array name di i2, che vale 0x00004242 (BB)

Ora, osservando la riga 31 e 32 e la struttura appena analizzata, possiamo ipotizzare che l’overflow avvenga proprio durante il primo strcpy, in quanto se andiamo ad inserire più caratteri di quanti l’array name ne contenga (8), dovremmo riuscire a sovrascrivere la struct i2. Facciamo una prova con ltrace

Ed ecco che, come si può vedere, ora il puntatore dentro lo strcpy vale 0x41414141. Andando ad indagare con GDB e lo stesso payload

Non esiste più il puntatore alla variabile i2.name ed il programma è andato in crash. Ma come possiamo sfruttare questo overflow per avere un exploit funzionante?

Per prima cosa dobbiamo calcolare l’offset in modo tale da sovrascrivere l’indirizzo in maniera precisa, ed è presto detto.

In questo modo, abbiamo calcolato la differenza tra la posizione del puntatore a i2.name (0x804b02c) e la posizione di i1.name (0x0804b018). Facciamo un test rapido per vedere se è giusto con il payload

gdb-peda$   r `perl -e 'print "A"x20 . "BBBB"' CC

Viene sovrascritto in maniera perfetta.

Ora che abbiamo trovato il punto da sovrascrivere, dobbiamo trovare quale indirizzo sovrascrivere. Ci potrebbero essere più vie, vediamone un paio.

Metodo 1 – GOT

Un file ELF è composto da più sezioni, ognuna delle quali composta dai propri dati e dalle proprie peculiarità. Ad esempio, se guardiamo quelle di heap1

ne abbiamo molteplici,come:

• .text, che contiene la maggior parte del codice del programma
• .rodata, che contiene le costanti
• .data, che contiene le variabili inizializzate all’inizio
• .plt, .got e .plt.got che si occupano del cosidetto Lazy Binding.

Il Lazy Binding si assicura sostanzialmente che un dynamic linker non perda tempo a cercare tutte le librerie necessarie ad un programma ma solo quelle che sono necessarie a runtime. Questa procedura è implementata grazie a due sezioni:

1. Procedure Linkage Tabel (.plt): è utilizzato per chiamare procedure/funzioni esterne il cui indirizzo non è noto al momento del linking e che deve essere risolto dal linker dinamico al momento dell’esecuzione.
2. Global Offset Table (.got):  esso mappa i simboli nel codice ai loro corrispondenti indirizzi di memoria assoluti per facilitare l’esecuzione dello stesso

[Per chi non avesse chiaro il procedimento, consiglio questo ottimo articolo]

Ma quindi, se andassimo a sovrascrivere sul puntatore a i2.name la chiamata a printf della funzione winner?

Prima di tutto, con GDB-Peda analizzo la sezione GOT dell’eseguibile

Una volta identificata, dovremo andare ad inserire quale indirizzo andremo a far chiamare la printf. Per ricapitolare l’idea è:

1. Sovrascrivere l’indirizzo di memoria a cui punta i2.name con l’indirizzo della printf presente nella GOT
2. Dentro la GOT, inserire l’indirizzo di memoria che vogliamo far stampare alla printf, quindi la funzione winner

Troviamo winner con objdump

osboxes@osboxes:~/Desktop/Protostar$   objdump -d heap1|grep winner 080484cb winner:

Sembra non avere funzionato. Osservando meglio la GOT, oltre ad una printf c’è anche una puts. Proviamo con quella

Analizzando dentro GDB, possiamo vedere il giro completo che siamo riusciti a creare

Metodo 2 – Return Address

Ammetto di aver lasciato il metodo due dopo GOT perché decisamente più semplice rispetto al precedente. In questo caso, possiamo semplicemente sovrascrivere il puntatore a i2.name con l’indirizzo del return address e successivamente far puntare ad esso la funzione winner. Procedendo sempre per passi, dobbiamo quindi:

1. Trovare l’indirizzo a cui punta RET e usarlo per sovrascriverlo su *i2.name
2. Iniettare subito dopo l’indirizzo della funzione winner

Inseriamo un breakpoint a main e troviamo EIP

Ora, ci basta sostituire questo indirizzo con quello di GOT del precedente payload

Ma sembra non funzionare. Non sono riuscito a capire come mai, e ho iniziato a sparare nel mucchio trovando poi l’indirizzo di EIP corretto (0xbffff60c)

Cosa molto simile fuori da GDB, in quanto ho dovuto modificare l’indirizzo del return address in 0xbffff67c per ottenere un exploit funzionante

Se sapete come mai questo comportamento di GDB commentate pure!

Conclusioni

Già con questo esercizio abbiamo approfondito molti più argomenti e l’heap inizia ad essere un pelo più chiaro. Gli approfondimenti li lasciamo per il prossimo esercizio, già in questo di cose da studiare ne sono spuntate!