Firmware Analysis
Last updated
Last updated
Impara e pratica il Hacking AWS:HackTricks Training AWS Red Team Expert (ARTE) Impara e pratica il Hacking GCP: HackTricks Training GCP Red Team Expert (GRTE)
Il firmware è un software essenziale che consente ai dispositivi di funzionare correttamente gestendo e facilitando la comunicazione tra i componenti hardware e il software con cui gli utenti interagiscono. È memorizzato in memoria permanente, garantendo che il dispositivo possa accedere a istruzioni vitali dal momento in cui viene acceso, portando al lancio del sistema operativo. Esaminare e potenzialmente modificare il firmware è un passo critico per identificare vulnerabilità di sicurezza.
Raccogliere informazioni è un passo iniziale critico per comprendere la composizione di un dispositivo e le tecnologie che utilizza. Questo processo implica la raccolta di dati su:
L'architettura della CPU e il sistema operativo in esecuzione
Specifiche del bootloader
Layout hardware e schede tecniche
Metriche del codice sorgente e posizioni
Librerie esterne e tipi di licenza
Storia degli aggiornamenti e certificazioni normative
Diagrammi architettonici e di flusso
Valutazioni di sicurezza e vulnerabilità identificate
A questo scopo, gli strumenti di intelligence open-source (OSINT) sono inestimabili, così come l'analisi di eventuali componenti software open-source disponibili attraverso processi di revisione manuale e automatizzati. Strumenti come Coverity Scan e Semmle’s LGTM offrono analisi statica gratuita che possono essere sfruttate per trovare potenziali problemi.
Ottenere il firmware può essere affrontato attraverso vari mezzi, ognuno con il proprio livello di complessità:
Direttamente dalla fonte (sviluppatori, produttori)
Costruendolo dalle istruzioni fornite
Scaricandolo dai siti di supporto ufficiali
Utilizzando query di Google dork per trovare file firmware ospitati
Accedendo direttamente allo storage cloud, con strumenti come S3Scanner
Intercettando aggiornamenti tramite tecniche man-in-the-middle
Estraendo dal dispositivo attraverso connessioni come UART, JTAG o PICit
Sniffando le richieste di aggiornamento all'interno della comunicazione del dispositivo
Identificando e utilizzando endpoint di aggiornamento hardcoded
Dumping dal bootloader o dalla rete
Rimuovendo e leggendo il chip di memoria, quando tutto il resto fallisce, utilizzando strumenti hardware appropriati
Ora che hai il firmware, devi estrarre informazioni su di esso per sapere come trattarlo. Diversi strumenti che puoi utilizzare per questo:
Se non trovi molto con quegli strumenti, controlla l'entropia dell'immagine con binwalk -E <bin>, se l'entropia è bassa, allora è improbabile che sia crittografata. Se l'entropia è alta, è probabile che sia crittografata (o compressa in qualche modo).
Inoltre, puoi utilizzare questi strumenti per estrarre file incorporati all'interno del firmware:
Oppure binvis.io (code) per ispezionare il file.
Con gli strumenti precedentemente commentati come binwalk -ev <bin> dovresti essere stato in grado di estrarre il filesystem.
Binwalk di solito lo estrae all'interno di una cartella chiamata come il tipo di filesystem, che di solito è uno dei seguenti: squashfs, ubifs, romfs, rootfs, jffs2, yaffs2, cramfs, initramfs.
A volte, binwalk non avrà il byte magico del filesystem nelle sue firme. In questi casi, usa binwalk per trovare l'offset del filesystem e ricavare il filesystem compresso dal binario e estrarre manualmente il filesystem secondo il suo tipo utilizzando i passaggi seguenti.
Esegui il seguente comando dd per estrarre il filesystem Squashfs.
Alternativamente, il seguente comando potrebbe essere eseguito.
$ dd if=DIR850L_REVB.bin bs=1 skip=$((0x1A0094)) of=dir.squashfs
Per squashfs (usato nell'esempio sopra)
$ unsquashfs dir.squashfs
I file saranno nella directory "squashfs-root" successivamente.
File di archivio CPIO
$ cpio -ivd --no-absolute-filenames -F <bin>
Per filesystem jffs2
$ jefferson rootfsfile.jffs2
Per filesystem ubifs con NAND flash
$ ubireader_extract_images -u UBI -s <start_offset> <bin>
$ ubidump.py <bin>
Una volta ottenuto il firmware, è essenziale disegnarlo per comprendere la sua struttura e le potenziali vulnerabilità. Questo processo implica l'utilizzo di vari strumenti per analizzare ed estrarre dati preziosi dall'immagine del firmware.
Un insieme di comandi è fornito per l'ispezione iniziale del file binario (denominato <bin>). Questi comandi aiutano a identificare i tipi di file, estrarre stringhe, analizzare dati binari e comprendere i dettagli della partizione e del filesystem:
Per valutare lo stato della crittografia dell'immagine, si controlla l'entropia con binwalk -E <bin>. Un'entropia bassa suggerisce una mancanza di crittografia, mentre un'entropia alta indica una possibile crittografia o compressione.
Per estrarre i file incorporati, si raccomandano strumenti e risorse come la documentazione di file-data-carving-recovery-tools e binvis.io per l'ispezione dei file.
Utilizzando binwalk -ev <bin>, è possibile solitamente estrarre il filesystem, spesso in una directory chiamata in base al tipo di filesystem (ad esempio, squashfs, ubifs). Tuttavia, quando binwalk non riesce a riconoscere il tipo di filesystem a causa di byte magici mancanti, è necessaria un'estrazione manuale. Questo comporta l'uso di binwalk per localizzare l'offset del filesystem, seguito dal comando dd per estrarre il filesystem:
Dopo, a seconda del tipo di filesystem (ad es., squashfs, cpio, jffs2, ubifs), vengono utilizzati comandi diversi per estrarre manualmente i contenuti.
Con il filesystem estratto, inizia la ricerca di vulnerabilità di sicurezza. Si presta attenzione a demoni di rete insicuri, credenziali hardcoded, endpoint API, funzionalità del server di aggiornamento, codice non compilato, script di avvio e binari compilati per analisi offline.
Posizioni chiave e elementi da ispezionare includono:
etc/shadow e etc/passwd per le credenziali degli utenti
Certificati e chiavi SSL in etc/ssl
File di configurazione e script per potenziali vulnerabilità
Binari incorporati per ulteriori analisi
Server web e binari comuni dei dispositivi IoT
Diverse strumenti assistono nel rivelare informazioni sensibili e vulnerabilità all'interno del filesystem:
LinPEAS e Firmwalker per la ricerca di informazioni sensibili
The Firmware Analysis and Comparison Tool (FACT) per un'analisi completa del firmware
FwAnalyzer, ByteSweep, ByteSweep-go, e EMBA per analisi statica e dinamica
Sia il codice sorgente che i binari compilati trovati nel filesystem devono essere scrutinati per vulnerabilità. Strumenti come checksec.sh per binari Unix e PESecurity per binari Windows aiutano a identificare binari non protetti che potrebbero essere sfruttati.
Il processo di emulazione del firmware consente un'analisi dinamica sia del funzionamento di un dispositivo che di un singolo programma. Questo approccio può incontrare sfide con dipendenze hardware o architetturali, ma trasferire il filesystem root o binari specifici su un dispositivo con architettura e endianness corrispondenti, come un Raspberry Pi, o su una macchina virtuale pre-costruita, può facilitare ulteriori test.
Per esaminare singoli programmi, è cruciale identificare l'endianness e l'architettura CPU del programma.
Per emulare un binario con architettura MIPS, si può utilizzare il comando:
E per installare gli strumenti di emulazione necessari:
For MIPS (big-endian), qemu-mips è utilizzato, e per i binari little-endian, qemu-mipsel sarebbe la scelta.
Per i binari ARM, il processo è simile, con l'emulatore qemu-arm utilizzato per l'emulazione.
Strumenti come Firmadyne, Firmware Analysis Toolkit e altri, facilitano l'emulazione completa del firmware, automatizzando il processo e aiutando nell'analisi dinamica.
A questo stadio, viene utilizzato un ambiente di dispositivo reale o emulato per l'analisi. È essenziale mantenere l'accesso shell al sistema operativo e al filesystem. L'emulazione potrebbe non imitare perfettamente le interazioni hardware, necessitando occasionali riavvii dell'emulazione. L'analisi dovrebbe riesaminare il filesystem, sfruttare le pagine web e i servizi di rete esposti, ed esplorare le vulnerabilità del bootloader. I test di integrità del firmware sono critici per identificare potenziali vulnerabilità backdoor.
L'analisi in tempo reale comporta l'interazione con un processo o un binario nel suo ambiente operativo, utilizzando strumenti come gdb-multiarch, Frida e Ghidra per impostare punti di interruzione e identificare vulnerabilità attraverso fuzzing e altre tecniche.
Sviluppare un PoC per le vulnerabilità identificate richiede una profonda comprensione dell'architettura target e programmazione in linguaggi di basso livello. Le protezioni binarie in tempo di esecuzione nei sistemi embedded sono rare, ma quando presenti, tecniche come il Return Oriented Programming (ROP) potrebbero essere necessarie.
Sistemi operativi come AttifyOS e EmbedOS forniscono ambienti preconfigurati per il testing della sicurezza del firmware, dotati degli strumenti necessari.
AttifyOS: AttifyOS è una distribuzione destinata ad aiutarti a eseguire valutazioni di sicurezza e penetration testing di dispositivi Internet of Things (IoT). Ti fa risparmiare molto tempo fornendo un ambiente preconfigurato con tutti gli strumenti necessari caricati.
EmbedOS: Sistema operativo per il testing della sicurezza embedded basato su Ubuntu 18.04 precaricato con strumenti per il testing della sicurezza del firmware.
Per praticare la scoperta di vulnerabilità nel firmware, utilizza i seguenti progetti di firmware vulnerabili come punto di partenza.
OWASP IoTGoat
The Damn Vulnerable Router Firmware Project
Damn Vulnerable ARM Router (DVAR)
ARM-X
Azeria Labs VM 2.0
Damn Vulnerable IoT Device (DVID)
Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
