Introduzione alla sicurezza dei sistemi embedded

Introduzione alla sicurezza dei
sistemi embedded
Alessandro Budai - eMaze Networks
24 Settembre 2012
Agenda
1 Motivazioni
2 Panoramica vulnerabilità
3 Esempio completo
4 Indicazioni e conclusioni
Agenda
1 Motivazioni
2 Panoramica vulnerabilità
3 Esempio completo
4 Indicazioni e conclusioni
Perchè un sistema embedded 1/2
I
I sistemi embedded sono largamente diffusi e
presenti:
I
I
I
I
I
I
Router, telecamere, stampanti
Sistemi di controllo
Terminali di pagamento
...
Sempre più dispositivi connessi in rete
Spesso ”invisibili”
Perchè un sistema embedded 2/2
I
I
I
Spesso mancanza di interazione diretta
Finchè funziona è spesso ignorato
La sicurezza è spesso esclusa (risorse e time to
market)
Un sistema embedded è quindi target molto
appetibile per un attacco.
Vulnerabilità
Difetto nella progettazione, implementazione,
configurazione che può essere sfruttato localmente o
remotamente allo scopo di modificare o degradare
un sistema in termini di:
I Confidenzialità
I Integrità
I Disponiblità
Obiettivi di un attaccante
Quali possono essere gli obiettivi/motivazioni
nell’attaccare un sistema embedded ?
I Clonazione dispositivo / estrazione proprietà
intellettuale
I Abilitazione di funzionalità a pagamento
I Estrazioni di informazioni (es.: chiavi
crittografiche, traffico dati)
I Impersonificazione dell’utente
I Utilizzo come punto di attacco verso altri
sistemi
I Causare disservizio
Attenzione !
I
I
La cifratura è solo uno dei componenti di
un sistema sicuro
Security through obscurity non è una
buona idea
Agenda
1 Motivazioni
2 Panoramica vulnerabilità
3 Esempio completo
4 Indicazioni e conclusioni
Livello degli attacchi
I
I
I
Software (Applicativo, OS, Bootloader)
Board (Bus, Interfacce comunicazione)
Chip
Vulnerabilità software
Tipiche vulnerabilità individuate in sistemi
embedded
I Buffer overflow
I Command injection
I Credenziali di default o mancanza di
autenticazione
I Chiavi di cifratura / token predicibili
I Servizi di rete non utilizzati (e vulnerabili)
I Vulnerabilità interfacce di configurazione Web:
I
I
Cross site request forgery
Cross site scripting
Command injection: esempio 1/2
Il diffuso router WRT54 ne è stato vulnerabile:
I Interfaccia Web con funzione di diagnostica
rete (ping)
I L’utente inserisce l’indirizzo IP nell’interfaccia
I Viene composto il comando ”ping indirizzo” e
chiamata system
Manca validazione, quindi se inserisco
192.168.1.1; reboot
ho ottenuto una command injection
Command injection: esempio 2/2
Esecuzione ping
void diagnose_network(char *userinput)
{
char buffer[256];
snprintf(buffer, 256, "ping %s",
userinput);
system(userinput);
...
}
Chiavi predicibili: esempio 1/2
Sistema di controllo con abilitazione/disabilitazione
via SMS
I Invio SMS da numero registrato verso il sistema
I Il sistema genera un token
I Il token viene ricevuto e utilizzato per l’invio
del comando
Chiavi predicibili: esempio 2/2
I
I
I
I
Token generato con rand
Il seeding è fatto tramite time ogni volta !
Il sistema ha l’orologio sincronizzato via NTP
Posso generare alcuni token e inviare il
comando
Alcuni suggerimenti
I
I
I
I
I
L’input utente non è mai fidato, validarlo
sempre
Accessi alla memoria sempre controllati rispetto
alla dimensione dei buffer (strncpy vs strcpy)
Rimuovere credenziali di default
Utilizzare veri generatori casuali
...
Attacchi a livello board
I
I
Accesso a console di gestione e/o testing
Interazione con interfacce di DEBUG (JTAG)
I
I
I
I
Download di immagini di firmware
Modifica di parametri di configurazione
Upload di firmware modificati
Interazione con bus
Alcuni suggerimenti
I
I
I
I
Rimozione marking
Rimozione a livello software e PCB interfacce
Utilizzo di chip con fusing JTAG
Rendere i segnali ”delicati” difficilmente
accessibili
I
I
I
I
Segnali su layer interni
Utilizzo di resine
Package complessi (BGA, COB, ...)
Meccanismi (efficaci) antitamper
Attacchi a livello chip
I
Side channel attack
I
I
I
I
Analisi emissioni
Power analysis
Failure injection (power glitch, temperatura,
irradiazione)
Decapping e ricostruzione layer
Anatomia di un attacco 1/2
I
I
I
I
I
Acquisizione del prodotto
Analisi visiva del dispositivo
Ispezione della board e individuazione
componenti principali
Ricerca di interfacce comunicazione / debug
(console, JTAG, ...)
Estrazione delle immagini del firmware
Anatomia di un attacco 2/2
I
I
Analisi del contenuto delle immagini
Ricerca di vulnerabilità conosciute e non
I
I
I
I
I
Network e vulnerability scan
Fuzzing input
Reverse engineering codice
Preparazione del vettore di attacco (diretto,
indiretto)
Azione
Agenda
1 Motivazioni
2 Panoramica vulnerabilità
3 Esempio completo
4 Indicazioni e conclusioni
Esempio 1/6: il dispositivo e l’attacco
Dispositivo in ambito networking con chiavi
crittografiche
Scopo di un potenziale attacco:
I Accesso al sistema sottostante
I Estrazione delle chiavi
I Estrazione dei flussi non cifrati
Esempio 2/6: analisi dispositivo
I
I
I
I
Acquisizione due dispositivi (uno da
”sacrificare”)
Analisi visiva del dispositivo e rimozione case
(no antitamper)
Ispezione PCB (nessun evidente segno di
console/JTAG)
Ricerca seriale/JTAG (non
disponibile/disabilitato)
Esempio 3/6: Board dissection
Analisi dei componenti della board
I SoC - recuperato datasheet parziale
I RAM
I Flash NAND
I Area coperta da resina
Esempio 4/6: Estrazione bootloader e
firmware
I
I
I
I
I
I
I
Rimozione della flash NAND e dump
Prima analisi del firmware (tracce interessanti)
Boot del SoC avviene da flash seriale (SPI)
Individuate piste con segnali bus SPI
Rimozione delle resistenze di terminazione
Dump della flash seriale
Flash SPI con protezione abilitata
Esempio 5/6: Reversing bootloader
I
I
I
Reversing codice binario bootloader
Individuata modalità di abilitazione console
bootloader
Analisi delle immagini di sistema
Esempio 6/6: Accesso al sistema
I
I
I
I
Modifica delle risposta della flash (test mode)
Verifica della signature abilitata da flag
contenuto nell’immagine
Immagine modificata con flag verifica signature
disabilitato
Upload di firmware modificato con accesso al
sistema
Obiettivo raggiunto !
Principali vulnerabilità riscontrate
I
I
I
Bus SPI / Flash accessibile
Firmware con modalità di test
Verifica della signature controllata da flag
modificabili
Possibili rimedi
I
I
I
Utilizzo di bootloader e firmware cifrati (con
supporto CPU)
Rimozione di qualsiasi modalità utilizzate in
fase di factory test
Verifica signature non disabilitabile
Agenda
1 Motivazioni
2 Panoramica vulnerabilità
3 Esempio completo
4 Indicazioni e conclusioni
Concetti generali
I
Nulla è sicuro al 100%
I
I
Con tempo, risorse e motivazioni qualunque
sistema è attaccabile
Valutare correttamente il rischio e le minacce
I
I
Comprendere le minacce a cui il sistema è esposto
Ridurre il rischio ad un livello accettabile
Sicurezza e sviluppo
Correggere a posteriori è sempre complesso e
costoso
I Secure design all’interno del ciclo di sviluppo
I Applicazione e conoscenza secure programming
I Testing prima di rollout massivi
I Imparare dagli errori del passato:
I
I
Database di errori comuni (CWE)
Database di vulnerabilità (CVE)
Gestire le segnalazioni
Le vulnerabilità sono spesso individuate da utenti o
ricercatori e riportate al vendor
I Evitare di ignorarle
I Avere un contatto per la raccolta
I Stabile un processo per fixing e rollout
Riferimenti utili
I
I
I
I
CVE: http://nvd.nist.gov,
http://www.cvedetails.com
CWE: http://cwe.mitre.org
OWASP Testing project:
https://www.owasp.org/index.php/
OWASP_Testing_Project
... motori di ricerca
Conclusioni
I
I
I
I
I
Il problema della sicurezza c’è
Va affrontato
Più sistemi, maggiori possibilità di attacco
Il fixing a posteriori è la soluzione più complessa
Contestualizzare e valutare correttamente
Fine !
Grazie !
email: [email protected]
twitter: pmst