I firmware vengono utilizzati in contesti molto diversi tra loro: si va dai costituenti di un’infrastruttura industriale ai dispositivi del mercato consumer. In questo articolo vedremo come analizzare un firmware alla ricerca di possibili vulnerabilità.
Bisogna tener conto che in questi casi:
Per la loro natura e per le loro capacità sempre maggiori, l’analisi di questi dispositivi è sempre più complessa e strutturata.
In genere, l’analisi non avviene sul codice sorgente ma sui file binari; sono diverse le motivazioni di questa scelta, ad esempio:
Ci sono essenzialmente due tipi di firmware:
Il risultato di queste problematiche è che l’individuazione delle vulnerabilità viene fatta manualmente. Analisi manuale che, oltre ad essere spesso anti-economica, può portare a diversi errori o approssimazioni dovuti alla complessità del codice in esame.
Schematicamente, i passi per un’analisi del firmware sono:
Il firmware da analizzare si può ottenere in diversi modi, ad esempio:
L’analisi esplorativa usa tecniche e strategie mutuate dal mondo dei dati, che risultano utili soprattutto quando abbiamo a che fare con un blob di dati e codice sconosciuto.
Se possibile, si possono ricavare informazioni utili semplicemente leggendo le specifiche e i datasheet distribuiti insieme al dispositivo. Capita spesso, però, che non siano disponibili né il datasheet né la documentazione; bisogna quindi estrapolare quante più informazioni possibile dal file binario, affidandosi a un’analisi esplorativa. Per prima cosa, bisogna trovare indizi per determinare il tipo di architettura; parliamo di indizi perché, almeno in questa fase, non si può avere ancora nessuna certezza riguardo al tipo di firmware in esame.
Questo tipo di analisi preliminare può essere fatta utilizzando diversi strumenti:
Questa prima analisi ci permette di fare delle assunzioni da verificare nelle analisi seguenti.
Dopo aver individuato le aree di interesse, anche in funzione degli scopi dell’intera operazione, possiamo procedere con l’analisi vera e propria.
Dall’analisi esplorativa, se siamo stati fortunati, abbiamo delle ipotesi sul tipo di firmware che ci troviamo ad analizzare. Prima di iniziare l’analisi vera e propria, occorre confermare queste ipotesi, in modo da identificare il tipo di firmware e prepararlo per le successive analisi.
Dalla definizione prima data, è subito chiaro che analizzare un firmware user-space è come analizzare un normale programma user-space e, quindi, non presenta particolari difficoltà. L’analisi di un blob binario invece è sicuramente più interessante e allo stesso tempo più impegnativa: sono ignoti e da scoprire l’indirizzo base e l’entry point del firmware.
Il prodotto finale di questa fase è un’immagine del firmware pronta per essere eseguita e analizzata.
In definitiva, l’analisi statica garantisce un’alta copertura e, allo stesso tempo, favorisce la precisione a discapito della scalabilità e della velocità di esecuzione.
In questo frangente, alcune ipotesi fatte rendono necessarie ulteriori verifiche. Inoltre, alcuni tool lavorano su rappresentazioni intermedie, aggiungendo un ulteriore livello di astrazione che, se da una parte è fondamentale per certe analisi, dall’altra non facilita la comprensione di un firmware.
Per sua natura, un’analisi statica presenta diverse approssimazioni: ad esempio, soffre della mancanza di informazioni derivate dall’esecuzione in ambiente reale, evidenti soprattutto quando abbiamo a che fare con un firmware.
L’analisi statica, come detto, presenta numerosi problemi, a volte capita che per venire a capo di alcuni elementi si prendano decisioni audaci, che possono portare a falsi indizi. Per ovviare a ciò viene eseguita l’analisi dinamica, che analizza il comportamento del firmware mentre è in esecuzione. Un’analisi dinamica può essere vista come un modo per confermare quanto scoperto nell’analisi statica e definire nuove potenziali vulnerabilità.
Se da un lato è molto precisa e attendibile nei risultati, dall’altro la sua copertura può essere molto limitata, dipendendo dai path raggiungibili dagli input testati.
Nel caso di un firmware, il vero problema però è rappresentato dalla correttezza dell’emulazione. Può risultare molto complesso eseguire propriamente il firmware, con tutte le chiamate alle periferiche del dispositivo che si vuole emulare. Per questi dispositivi non è sempre semplice o possibile emulare completamente la realtà, tool come Firmadyne (https://github.com/firmadyne/firmadyne/), QEMU o anche emulatori commerciali hanno difficoltà ad emulare alcuni tipi di architetture.
Abbiamo visto quali siano i passi per un’analisi completa di un firmware. L’ideale sarebbe automatizzare buona parte dell’intero procedimento – soprattutto le azioni ripetitive – in modo da rendere le analisi più efficienti in termini di tempo e copertura e di ridurre quanto più possibile il numero di errori.
Articolo a cura di Gianluigi Spagnuolo
I Big Data stanno cambiando le regole del commercio online. Finalmente le aziende possono comprendere…
Dal punto di vista tecnico-operativo, le indagini di digital forensics vengono svolte utilizzando specifici strumenti…
Nell’ambito dell’email security esistono diversi protocolli volti a garantire l'autenticità, l'integrità e la riservatezza delle…
Nel panorama della sicurezza informatica, la minaccia di attacchi fisici tramite dispositivi USB malevoli è…
Come per tutti i problemi complessi con cause molteplici, non esiste una soluzione per il…
In un mondo sempre più connesso e digitalizzato, le innovazioni tecnologiche stanno cambiando radicalmente il…