Questo articolo rappresenta la Puntata 2 della serie "Code injection attacks su architetture Harvard" della Rubrica Firmware Reload.
ATMEL-AVR
Il microcontrollore utilizzato in questo lavoro è un ATmega128 (Figura 1) prodotto da Atmel e appartenente alla famiglia di microcontrollori a 8 bit AVR.
Figura 1: Architettura a blocchi del microcontrollore Atmel
L’AVR è una famiglia di microcontrollori RISC ad architettura Harvard sviluppata da Atmel a partire dal 1996. L’AVR fu una delle prime famiglie di microcontrollori a utilizzare una memoria programma di tipo Flash: questo permette di cancellare la memoria e riscriverla con una nuova versione del firmware in pochi secondi e anche senza rimuovere il microcontrollore dalla scheda su cui è montato, velocizzando enormemente il processo di correzione e messa a punto del codice. L’ATmega128, realizzato in tecnologica CMOS, rappresenta un buon compromesso in fatto di prestazioni, consumo e costo; inoltre, possiede una serie di unità hardware indipendenti che facilitano la programmazione e migliorano il throughput del processore. Come qualsiasi macchina Harvard, il processore può caricare istruzioni solo dalla memoria programma e può scrivere solo verso il segmento della memoria dati, visto che il program counter può solo accedere alla memoria programmi. Una vera macchina Harvard impedisce la modifica, in modalità remota, della zona programmi. In realtà, macchine di questo tipo non sono comuni perché la maggior parte dei dispositivi a microcontrollori utilizza una versione Harvard modificata consentendo, in presenza di alcune circostanze, la modifica della sezione programmi. A questo proposito, può essere opportuno ricordare l’uso dell’istruzione LPM (Load from Program Memory) e SPM (Store to Program Memory) utilizzati per copiare informazioni from/to verso Program Memory e to/from verso data memory, e sono eseguite solo nella sezione bootloader. I due studiosi hanno mostrato l’esito di un attacco di questo tipo utilizzando una piattaforma hardware Micaz, (Figure 2 e 3) con compatibilità verso lo standard IEEE 802.15.4 su processore Atmel AVR Atmega 128 su 8 bit con una frequenza di funzionamento di a 8 MHz. In questa situazione ogni sensore è già configurato al momento del suo utilizzo e prima di essere inserito in questa rete: il codice implementa le azioni necessarie per eseguire le richieste inviate, tra le quali, ad esempio, la raccolta dati.
Figura 2: Nodo Micaz
Può risultare necessario, però, un aggiornamento del firmware del sensore anche successivamente e per questa evenienza è presente, sempre in ogni modulo, il relativo bootloader. L’attacco su un’architettura di questo tipo è stato condotto introducendo il concetto di meta-gadget, un componente chiave di tutta la questione. Non solo, è anche necessario assumere alcune condizioni: la rete sotto attacco è composta di nodi Micaz, tutti i nodi sono assolutamente identici e ospitano lo stesso codice, l’attaccante, poi, conosce il contenuto della memoria di programma (si assume che l’attaccante abbia catturato in precedenza e analizzato il codice binario). Non solo, ogni nodo utilizza la stessa versione del sistema operativo, nel nostro caso TinyOS, senza alcuna modifica alle sue librerie e in ogni nodo risulta presente lo stesso bootloader. Infine, il codice posto in esecuzione su ogni microcontrollore può presentare almeno una vulnerabilità come il buffer overflow. In questo contesto, un attaccante può sfruttare questa vulnerabilità per eseguire un gadget, in altre parole una sequenza di istruzioni già presente nella program memory e che si conclude con l’istruzione ret, a condizione che si riesca a iniettare i giusti parametri nello stack.
Figura 3: Struttura della memoria
È chiaro che l’insieme delle istruzioni che un attaccante può eseguire è limitato al contenuto dei gadget presenti nella memoria, ma è altrettanto chiaro che l’attacco può essere anche più complesso. È sufficiente concatenare le azioni di ciascun gadget, dei meta-gadget, per arrivare anche a definire e mettere a punto un vero worm. Si è mostrato che, su un normale computer, un utente malintenzionato, controllando correttamente lo stack, può definire diversi gadget fino a realizzarne una vera catena di esecuzione, potendo così realizzare qualsiasi azione. Questo particolare approccio è definito da molti come “return-oriented programming”. Ricordiamo che su ogni sensore il programma applicativo è molto piccolo, arrivando al massimo a pochi kb, e ciò può anche mettere in evidenza, in effetti, la limitata flessibilità o grado di libertà per ogni malintenzionato. Tuttavia, per semplici attacchi, questa limitazione non è fondamentale: una volta iniettato il codice, questo può essere eseguito come una porzione di programma definito “sano”.
