Diversi sono gli elementi di vulnerabilità dell’identificazione in radiofrequenza e numerosi i possibili attacchi. Ecco come cautelarsi dai rischi
Anche se l’identificazione in radiofrequenza non è ancora diffusa su larga scala, le sue caratteristiche la rendono intrinsecamente vulnerabile, quindi soggetta a potenziali attacchi. I “buchi” più pericolosi, in linea di principio, sono relativi a tre elementi: i componenti Web, quelli del database e il codice “colla”. Molti middleware, che costituiscono la spina dorsale di un qualsiasi progetto Rfid, utilizzano, infatti, componenti Web based.
I più comuni sono quelli impiegati per fornire l’interfaccia utente o le opzioni di query sulla base dati nelle diverse sedi dell’azienda. Questi componenti sono potenzialmente aperti agli attacchi. Se, infatti, un browser Web è utilizzato per interrogare i dati contenuti nell’etichetta (sia direttamente, sia indirettamente, passando attraverso il database), è anche possibile abusare delle funzionalità dinamiche offerte dai browser di ultima generazione includendo del codice Javascript nel tag. Un altro modo per condurre azioni fraudolente è attraverso Ssi (Server side includes), tecnologia che permette di generare pagine Web “al volo”, attraverso l’esecuzione di un comando sul server Internet quando una certa Url è richiesta. Includendo dei comandi Ssi su un tag, sarà possibile “depistare” il server Web, in modo da fargli eseguire del codice maligno. Ma questa non è la sola vulnerabilità. I sistemi Rfid, infatti, utilizzano in genere un database per immagazzinare tutte le informazioni lette o scritte sulle etichette. Se il middleware non è in grado di trattare correttamente i dati, sarà possibile far eseguire dal database il codice Sql immagazzinato sul tag, con un “trucchetto”. Questa modalità di attacco è chiamata Sql injection. Infine, il codice glue (colla) è quello scritto per legare l’interfaccia del lettore Rfid con il middleware, redatto geralmente con linguaggi piuttosto semplici, tipo C o C++, particolarmente vulnerabili ai buffer overflow. Questa procedura può essere utilizzata per innestare codici maligni o mini virus all’interno del sistema, forzandolo e inondandolo di dati, provocando un overflow della memoria del middleware, che potrà essere sfruttato come veicolo di codici maligni. Un altro possibile attacco è l’Rfid exploit, che costituisce la base di ogni malware e si attua sfruttando i tag capaci di modificare gli indirizzi di memoria nel middleware. L’Rfid worm, ad esempio, si basa sul Rfid exploit, ma necessita anche di una connessione di rete per replicarsi, sfruttando le falle remote di altri sistemi di identificazione in radiofrequenza connessi. Può indurre una macchina a scaricare ed eseguire codice da remoto, compromettendo, così, il middleware e arrivando a sovrascrivere gli altri tag. Un middleware compromesso costituirà un facile terreno di proliferazione del worm, che si replicherà sovrascrivendo altri tag. L’Rfid virus costituisce una variante dell’Rfid worm che non necessita di una connessione di rete. Sfruttando un exploit, il virus comanda al middleware di sovrascrivere gli altri tag che, a loro volta, ne sovrascriveranno altri contribuendo, così, alla propagazione dell’infezione. Lo scenario che si prospetta non è, quindi, dei più tranquilli, tuttavia è possibile difendersi da questi pericoli. Come? Anzitutto, procedendo a periodiche revisioni del codice, che possono aiutare a trovare i “buchi” e le relative “toppe”. Ancora, stabilendo una rigida gestione dei privilegi d’accesso al database e all’infrastruttura middleware, sul principio che i permessi non concessi non possono essere sfruttati per compiere abusi. Infine, disabilitando tutte le funzionalità non strettamente necessarie che, se lasciate attive, potrebbero costituire una strada per perpetrare attacchi in futuro. Per frenare le minacce ai database, ciascun dato dovrà essere copiato all’interno di uno “statuto Sql”, sottoposto a rigidi controlli. Il pericolo dell’Ssi injection può essere evitato disabilitando Ssi, mentre contro lo scripting del client ci si può cautelare adottando modalità di estrazione in sicurezza dei dati dalle pagine Html. Tali funzionalità sono incluse, precaricate, all’interno dei più diffusi linguaggi di sviluppo Web. La prevenzione dei buffer overflow, infine, passa attraverso l’impiego di strumenti ad hoc (Valgrind o Electric Fence), che controllano i limiti strutturali dei tag. Meglio ancora sarebbe utilizzare, in fase di sviluppo dell’infrastruttura Rfid, linguaggi che automatizzano tutti questi controlli, come Java.
