Soluzioni hitech per la protezione dei terminali e dei servizi mobili di nuova generazione

Transcript

1 TECNOLOGIE Soluzioni hitech per la protezione dei terminali e dei servizi mobili di nuova generazione STEFANO BRUSOTTI GIANLUCA CANGINI FRANCESCO CODA ZABETTA La diffusione di cellulari, smartphone e Personal Digital Assistant (PDA) in genere, è in forte aumento. Il fenomeno è direttamente legato alla continua introduzione sul mercato di nuove tecnologie, che permettono di far evolvere i terminali, la memoria e soprattutto le funzionalità offerte. Tutto questo è accompagnato dallo sviluppo delle reti mobili di nuova generazione, che permettono una sempre maggiore velocità di trasmissione delle informazioni e nuovi servizi. L aumento della numerosità e della complessità dei terminali e dei servizi mobili è terreno fertile per la comparsa di problematiche di sicurezza fino ad ora confinate al mondo delle tecnologie dell informazione tradizionali, ovvero dei personal computer, come i virus, i worm, i messaggi di phishing e tutte le altre minacce, che abbiamo imparato a riconoscere e gestire nel campo dell IT, ma che ci trovano ancora impreparati quando si manifestano sul nostro terminale mobile, sfruttando vulnerabilità di cui lo ritenevamo immune. A queste si aggiungono anche gli attacchi che sono specifici dell ambito mobile, come ad esempio quelli che mirano a frodare l Operatore o gli utenti, oppure a rendere indisponibile la rete o i servizi. In tale situazione le soluzioni di sicurezza tradizionali non sono più sufficienti o efficaci e occorre affrontare il problema in modo nuovo, con un approccio che parta dalle peculiarità dell ambito in cui le nuove minacce si sviluppano. L articolo descrive e analizza lo stato dell arte in questo settore e illustra dettagliatamente l innovativo sistema per il rilevamento precoce di nuove minacce ideato e realizzato in Telecom Italia da Security Innovation. 1. Introduzione Il mondo delle comunicazioni mobili ha subito negli ultimi anni una vera e propria rivoluzione tecnologica dovuta all'incremento delle possibilità di connessione e all'evoluzione dei terminali (figura 1). La banda delle connessioni radio è in continuo aumento (GPRS, EDGE, UMTS, HSDPA,...) e ad essa si aggiungono la connessione WiFi nei terminali dual-mode e numerose modalità di connessioni PAN (Personal Area Network): Bluetooth, ZigBee, MANet. Dai cellulari si è passati agli smartphone e ai PDA, dotati delle funzionalità tipiche dei personal computer. Inoltre, altre tipologie di dispositivi mobili come PocketPC, BlackBerry, terminali per il Mobile Gaming, Mobile TV, Mobile Music, iniziano a fornire la connettività e le funzionalità della telefonia mobile. Questi dispositivi sono sempre più performanti dal punto di vista della computazione e della memoria a disposizione. Il software, di conseguenza, è sempre più sofisticato e complesso: dai sistemi operativi Symbian, Windows Mobile, Palm OS, RIM, agli ambienti di sviluppo J2ME, BREW, alle applicazioni Office, giochi e multimedia. Caratteristiche queste che aprono nuove possibilità di business per gli sviluppatori di software e per i fornitori di servizi: messaggistica, peer-to-peer, accesso remoto alle risorse, sincronizzazione e backup, download di loghi e suonerie, giochi on-line, micro-pagamenti ma anche nuove occasioni per gli attaccanti di sfruttare vulnerabilità legate a questi sistemi e servizi. In quest'ottica, il tema della sicurezza dei dati, delle comunicazioni, delle credenziali, del credito è un elemento cardine a supporto della diffusione dei nuovi terminali e dei relativi servizi. NOTIZIARIO TECNICO TELECOM ITALIA Anno 17 n. 2 - Agosto

2 Evoluzione tecnologica dei terminali TACS... GSM GPRS EDGE UMTS... HSDPA EDGE = Enhanced Data for GSM Evolution GPRS = General Packet Radio Service GSM = Global System for Mobile communications FIGURA 1 Evoluzione dei terminali mobili. L attenzione mondiale, anche dei mass-media, verso la mobile security ha subito una brusca impennata a partire da metà del 2004, con la comparsa di quello che è da considerarsi a tutti gli effetti il primo virus per dispositivi mobili: Cabir [1]. Attualmente sono stati riscontrati poco meno di quaranta diverse famiglie di malware per sistemi mobili. Tra tutti, quelli che hanno suscitato il maggiore interesse sono sicuramente il già citato Cabir e Commwarrior [2]. Caratteristica fondamentale di un worm è la sua capacità di replicarsi e questi due virus sono stati d esempio per diversi altri: Cabir è stato il primo a trovare un metodo di diffusione tramite bluetooth, utilizzato poi da tutta una serie di varianti successive; CommWarrior ne ha aggiunto un secondo, potenzialmente molto più pericoloso, ovvero l utilizzo di MMS con allegati infetti. Cabir è un worm che gira su dispositivi mobili Symbian della Serie 60. Si replica attraverso le connessioni Bluetooth e arriva sul dispositivo nella Inbox dell utente come file con estensione.sis; dopo il click dell utente sul file e l esplicita conferma per il processo di installazione (figura 2) il dispositivo si infetta. Il worm va in esecuzione ogni volta che il dispositivo si avvia e non ha un vero e proprio payload malevolo: non fa altro che cercare altri dispositivi raggiungibili via bluetooth per propagarsi inviando a questi nuovamente il file.sis che contiene il worm. È importante sottolineare che la propagazione di Cabir richiede che il dispositivo sia configurato in modo da essere raggiungibile via Bluetooth, non necessariamente attivo di default, e, soprattutto, è necessaria l esplicita conferma dell utente per procedere all installazione del worm, cioè all infezione del sistema. Questi fattori ne hanno limitato notevolmente la diffusione. Inoltre il raggio di azione efficace di Bluetooth è dell ordine delle decine di metri e questo riduce ulteriormente la pericolosità per possibili infezioni su larga scala. In ogni caso, Cabir è stato importante anche perché il suo codice è stato reso pubblico e un grande numero di virus successivi ha potuto facilmente riutilizzare il suo sistema di propagazione per il trasporto di payload applicativi più o meno pericolosi. Una svolta importante nel contesto dei worm per dispositivi mobili è stata data da CommWarrior, comparso a marzo Questo worm per Symbian Series 60 è da segnalare perché, oltre a replicare il meccanismo di propagazione di Cabir via Bluetooth, si può propagare anche via MMS attraverso allegati infetti. Il meccanismo di propagazione via MMS è sicuramente più pericoloso e può effettivamente diventare veicolo di infezioni su larga scala. Esattamente come un worm tradizionale, infatti, CommWarrior legge la rubrica sul cellulare e si propaga allegando a messaggi MMS un file.sis contenente il worm. Il testo del messaggio, scelto a caso tra diverse possibilità, presenta l allegato come un gioco o un applicazione di sicurezza oppure immagini pornografiche, inducendo così l utente ad eseguire l allegato e quindi ad infettare il sistema. Una volta installato, il worm va in esecuzione ad ogni avvio del terminale e tenta di propagarsi via Bluetooth o via MMS. Anche in questo caso è da sottolineare come sia necessaria la conferma esplicita dell utente prima di procedere con l installazione, come mostrato nella figura 2. HSDPA = High Speed Downlink Packet Access TACS = Total Access Communication System UMTS = Universal Mobile Telecommunications System FIGURA 2 Schermate di conferma per l installazione di Cabir e CommWarrior. 16 NOTIZIARIO TECNICO TELECOM ITALIA Anno 17 n. 2 - Agosto 2008

3 Oltre a virus/worm/trojan, nella telefonia mobile esistono altri tipi di attacchi mirati a perpetrare frodi verso l operatore telefonico (es. bombardamento di messaggi a profili ricaricabili) o verso singoli utenti, come l SMS phishing che tramite SMS ingannevoli invita l utente ad effettuare una chiamata verso un numero ad alta tariffazione. Al momento, la principale tecnologia di sicurezza che è stata adattata al contesto mobile è rappresentata dall'antivirus. I principali produttori di anti-virus tradizionali hanno rapidamente rilasciato una versione dei loro motori di scansione ed analisi adatta ai sistemi operativi più diffusi (Symbian e Windows Mobile) sui terminali mobili. L'antivirus opera cercando nei file presenti sul terminale i segni distintivi di un'infezione virale; queste informazioni vengono mantenute in un opportuno database delle signature. Il grosso problema degli antivirus è rappresentato proprio dall'aggiornamento tempestivo di questo database; infatti, alcuni produttori hanno sviluppato delle tecnologie ad-hoc per ottimizzare questo processo nel contesto dei terminali mobile. Il secondo problema tipico degli antivirus è quello di limitare la propria capacità protettiva ad attacchi ben noti, ma di essere abbastanza ciechi di fronte ad attacchi mirati, condotti grazie ad un mix di social-engineering e l'utilizzo di trojan-horse e/o virus sviluppati appositamente per quello specifico scenario e caratterizzati da una diffusione molto limitata (che, pertanto, sono difficilmente catturabili dai produttori di anti-virus, specie durante le fasi iniziali della diffusione). Problemi di questo genere non sono molto comuni nell'ambito Internet tradizionale, ma nel caso delle reti cellulari esistono due elementi che rendono più plausibili tali scenari: 1) il fatto che il cellulare sia un oggetto intrinsecamente personale, con un numero di telefono associato in modo indiscutibile ad una persona; mentre, nel caso delle reti IP, l'indirizzo (sia esso simbolico, sia esso un nome DNS valido) è quasi sempre associato ad una macchina; 2) il fatto che sul cellulare sia presente del credito che può essere utilizzato per vari scopi: per scaricare una suoneria, per inviare dei messaggi multimediali, per navigare su Internet a spese del malcapitato. 2. Il Mobile Security System (MoSeS) Nel 2005 è stato avviato in Telecom Italia un progetto per studiare le allora nascenti minacce in ambito mobile. Da quei primi studi e dalle successive realizzazioni di Security Innovation è nata una piattaforma molto innovativa, finalizzata all identificazione precoce delle minacce legate principalmente al mobile malware. Il sistema integra diverse tecnologie proprietarie, messe a punto nei laboratori Telecom Italia, ed è stato denominato MoSeS (Mobile Security System). Il MoSeS mira ad identificare attacchi ancora sconosciuti, quelli cioè che non si propagano necessariamente seguendo degli schemi noti e sfruttando vulnerabilità già identificate. Per questo motivo, tutti gli elementi di rilevazione che costituiscono la piattaforma operano in base al paradigma dell'anomaly Detection, cioè identificano tutto ciò che si discosta dal normale funzionamento. Questo approccio è duale rispetto a quello degli antivirus, che invece operano con l approccio Misuse Detection, ovvero bloccando gli attacchi rilevati a partire da alcuni segni distintivi, che devono però essere noti a priori. MoSeS è caratterizzato da un approccio pervasivo, la cui rete di rilevazione si estende in modo da coprire l'intera infrastruttura, senza limitarsi al solo terminale; in questo modo è possibile raccogliere e correlare numerose informazioni che provengono da sorgenti e da viste differenti così da identificare anche attacchi mirati, che non hanno necessariamente una larga diffusione ma che possono comunque provocare dei danni significativi. In questo modo, MoSeS contribuisce a dare importanza al ruolo dell operatore nel processo della sicurezza, trasformando anche l azione isolata in uno sforzo coordinato ed organizzato per aumentare la sicurezza dell intera infrastruttura di comunicazione a beneficio di tutti i suoi utilizzatori. La piattaforma MoSeS è stata progettata fin dall inizio pensando alle peculiarità specifiche dell ambito mobile. Dal punto di vista della sicurezza, l elemento più debole di tutta l infrastruttura della rete radio-mobile è rappresentato dal terminale, che si trova ad operare proprio sul limite esterno di questa infrastruttura; il terminale è infatti sotto il diretto controllo dell utente e l operatore può intervenire su di esso in maniera estremamente limitata. Il terminale e le risorse, che sono sotto il suo controllo, sono dunque il bersaglio privilegiato di chiunque voglia condurre un attacco volto a comprometterne il corretto funzionamento; tuttavia, anche gli elementi della rete che erogano i servizi potrebbero essere l oggetto di attacchi su scala più vasta, sebbene oggi questo scenario appaia ancora poco probabile. Indipendentemente dal bersaglio, è lecito supporre che la stragrande maggioranza degli attacchi che interesseranno il mobile, saranno comunque correlati ad una qualche attività che coinvolge il terminale, che però potrebbe essere rilevata solo incrociando le informazioni raccolte analizzando tutti gli elementi coinvolti. La piattaforma MoSeS è stata progettata seguendo i principi della Defense in Depth [3], cercando cioè di evitare un approccio mono-tecnologico al problema. La rete di rilevazione è composta da numerosi meccanismi che operano in modo differente, e che analizzano le informazioni raccolte da molteplici punti di osservazione. Tutte le anomalie rilevate sono poi raccolte in un punto centrale, dove è possibile correlarle tra loro e filtrare i comportamenti inusuali, ma ammissibili, da quelli decisamente sospetti o chiaramente pericolosi. Si tratta dunque di un sistema distribuito, che però prevede un punto centrale di controllo. NOTIZIARIO TECNICO TELECOM ITALIA Anno 17 n. 2 - Agosto

4 L architettura di MoSeS è pertanto a stella (figura 3) per evitare le problematiche associate all esistenza di un singolo punto di fallimento (rappresentato dal collettore di eventi), è possibile utilizzare le tecniche tradizionali di faulttolerance e pensare all utilizzo di più sistemi che operano in parallelo. Le componenti del sistema sono: le MoSeS Sentinel; i Mobile Client Honeypot; gli MMSC probe; l Application Analyzer; l alert collector; sistemi di monitoring e reporting. Nel proseguimento dell'articolo il lettore troverà le descrizioni di dettaglio sulle finalità e i meccanismi di funzionamento dei singoli componenti. rete di MoSeS Sentinel alert MMSC-Probe Servizio MMS Alert Collector Application Analyzer rete di Honeypot alert Monitoring & Reporting console 2.1. MoSeS Sentinel La sentinella è il componente software che si occupa di eseguire un analisi sistematica di ciò che accade sul terminale mobile. La logica della sentinella è molto simile a quella di un sistema di Host Intrusion Detection e come molti HIDS (Host-based Intrusion Detection System) essa opera in base al paradigma dell Anomaly Detection, monitorando accuratamente l utilizzo di tutte le risorse più importanti che caratterizzano il terminale. Trattandosi di un componente software che gira sul terminale di un utente reale, è fondamentale che l azione della sentinella non disturbi il normale funzionamento del dispositivo. Pertanto, la sentinella deve essere necessariamente leggera, ed evitare l esecuzione di algoritmi che richiedano notevoli risorse computazionali. Inoltre, è fondamentale che la sentinella si preoccupi di trattare le informazioni personali presenti sul terminale in maniera appropriata, evitando di inviare un allarme a fronte di un qualsiasi evento insolito, ma limitandosi a segnalare solo delle situazioni realmente anomale dal punto di vista della sicurezza del dispositivo e dei dati. Ad esempio, la sentinella deve accorgersi del tentativo compiuto da una certa applicazione di effettuare una chiamata verso un numero ad elevata tariffazione in maniera automatica, ma deve evitare di inviare un allarme se tale operazione sia stata compiuta direttamente dall utente, per evitare violazioni della privacy. La figura 4 illustra l architettura schematica della sentinella, costituita da due elementi principali che incapsulano le due funzioni fondamentali: la cattura degli eventi significativi per il monitoraggio delle anomalie, ed i moduli specifici che contengono la logica di analisi per discriminare il comportamento lecito da quello anomalo. MMS Bluetooth File Transfer MoSeS Sentinel MMS = Multimedia Message Service MMSC = Multimedia Message Service Center MoSeS = Mobile Security System FIGURA 3 Architettura della piattaforma MoSeS. SMS La sentinella ha altri due componenti, che hanno però un ruolo più strutturale:il modulo di invio degli allarmi, che si occupa di serializzare le informazioni presenti nell allarme e di inviarle per mezzo di una connessione dati ad-hoc, ed il modulo che si occupa del mantenimento dello stato, di modo che la sentinella possa mantenere memoria e traccia di ciò che è accaduto anche se il terminale dovesse essere riavviato. MMS_A Operating System (Symbian 8.x) Bluetooth_A State Event Interceptor SMS_A GPRS = General Packet Radio Service MMS = Multimedia Message Service SMS = Short Message Service FIGURA 4 Architettura MoSeS Sentinel. Boot_A Install_A.sis install Alerter A boot start SIM access phone data access data connection (GPRS/WiFi) Analyzers Allert Collector GPRS/UMTS UMTS = Universal Mobile for Telecommunications System WiFi = Wireless Fidelity 18 NOTIZIARIO TECNICO TELECOM ITALIA Anno 17 n. 2 - Agosto 2008

5 La maggior parte dei sistemi operativi che prevedono l uso di una GUI (Graphical User Interface) sfruttano un meccanismo ad eventi per gestire il flusso di esecuzione dell applicazione. In pratica, ciò vuol dire che il sistema operativo invia una notifica ogni qual volta accade uno degli eventi a cui si è interessati. Symbian offre una serie di meccanismi dipendenti dal particolare tipo di oggetto che si vuole tenere sotto controllo, ma tutti i meccanismi si basano sul pattern dell Observer [4]. All attivazione, la sentinella registra con il sistema operativo una serie di Observer relativi agli eventi rilevanti; nel caso specifico, sono intercettati i seguenti eventi: Ricezione e invio di un messaggio, sia esso MMS, SMS o (Symbian prevede una API unificata per la gestione della messaggistica); Scritture su zone critiche del file-system, per monitorare, nel caso specifico: - installazione di nuove applicazioni; - installazione di nuove applicazioni che vengono automaticamente eseguite all avvio del telefono; - installazione/modifica/cancellazione di librerie eseguibili. Inoltre è stato implementato un meccanismo che consenta di intercettare altri eventi utili ai fini della sicurezza, anche se il sistema operativo non li espone direttamente con il pattern dell Observer. La tecnica utilizzata è un esempio di dll hijacking e permette di monitorare una grande quantità di eventi del sistema. Ogni volta che uno di questi eventi viene rilevato dal sistema operativo, l Event Interceptor provvede a normalizzare le informazioni in un formato che sia quanto più possibile indipendente dalle caratteristiche del sistema operativo, e provvede ad inoltrare queste informazioni a tutti gli analizzatori che si sono registrati per ricevere le notifiche relative a quel particolare evento. Ogni analizzatore ha una logica ritagliata sul tipo di dati che deve analizzare. L analizzatore dei messaggi controlla tutti i messaggi ricevuti o inviati dal cellulare, siano essi SMS, MMS, o messaggi Bluetooth. L analizzatore delle applicazioni controlla tutte le applicazioni che vengono installate sul telefono, in particolare se un applicazione appena installata cerca di partire automaticamente ad ogni avvio del telefono. L ultimo elemento della sentinella è l Alerter, che si occupa di gestire l inoltro degli allarmi, che avviene per mezzo di una connessione dati. L Alerter provvede inoltre a memorizzare localmente gli allarmi, qualora l invio sia impossibile (perché ad esempio non c è copertura di rete), occupandosi poi dell inoltro quando ciò risulti possibile. Infine, l Alerter si occupa dell invio degli heartbeat, che servono a registrare centralmente il corretto funzionamento della sentinella. Le sentinelle vengono installate sui terminali di utenti collaborativi che, su base volontaria, concorrono a costruire, sul territorio, una prima rete di allerta precoce. 2.2 Mobile Client Honeypot Il ruolo principale del Mobile Client Honeypot (MCH) è complementare rispetto a quello della sentinella; la sentinella infatti controlla ciò che accade su un terminale che è comunque usato da un utente reale, con tutte le limitazioni del caso. L MCH, essendo appunto una risorsa il cui valore deriva proprio da un uso illecito o non autorizzato, può essere usato attivamente per scoprire o identificare un attività anomala. Le similitudini tra l MCH ed un honeypot standard si limitano però all idea di base; l implementazione è completamente diversa, dal momento che l approccio tradizionale prevede che si configuri un sistema pubblicamente accessibile sulla rete Internet, che esponga anche dei servizi vulnerabili. I dispositivi mobili, invece, non sono sempre connessi alla rete Internet e, quando lo sono, tipicamente non offrono servizi su particolari porte: un attaccante potrebbe contattare il dispositivo solo se è a conoscenza del numero di telefono oppure operando una scansione su una rete a corto raggio, come quella Bluetooth. In realtà, il paradigma d uso del Mobile Client Honeypot è totalmente ribaltato, rispetto allo scenario tipico. Infatti, mentre nel caso classico l honeypot [5] si limita a svolgere il ruolo di entità passiva manipolata dall attaccante, nel caso dei terminali mobili il terminale svolge un ruolo attivo, manipolando direttamente il materiale che l attaccante si limita a consegnare. Uno dei problemi è quindi quello di consentire a tale materiale di raggiungere l honeypot. Nell ambito della piattaforma MoSeS, l MCH è raggiungibile attraverso due canali: la rete telefonica e una rete di accesso a corto raggio, tipicamente Bluetooth. La conoscenza del numero di telefono è sufficiente per portare un attacco utilizzando qualche forma di messaggio, di solito MMS o SMS. Per diffondere questa informazione, si prevede di inserire i numeri di telefono associati agli honeypot nella rubrica delle SIM dell Operatore, come già succede per i numeri di particolari servizi d interesse generale. Occorre che il numero dell honeypot non sia immediatamente riconoscibile, altrimenti un attaccante potrebbe evitarlo facilmente, perciò è importante usare numeri diversi tra loro, collocati in diverse posizioni della rubrica, e non necessariamente associabili ad un servizio automatico. L altro canale di accesso estremamente interessante per catturare eventi anomali è rappresentato dalla connessione a corto raggio; al momento, la tipologia di connessione più diffusa è quella Bluetooth, e dunque l MCH prevede un modulo specifico per interagire con tutto ciò che può arrivare via Bluetooth. Ovviamente, nel momento in cui dovessero diventare disponibili altre tecnologie, è molto semplice estendere questo approccio; ad esempio, nel caso di telefoni cosiddetti dual-mode (WiFi e UMTS), è possibile estendere il monitoraggio eseguito dall honeypot anche alle connessioni WiFi. Trattandosi comunque sempre di reti a breve raggio di copertura, è essenziale che l MCH che deve operare su questo canale sia dislocato in aree dove NOTIZIARIO TECNICO TELECOM ITALIA Anno 17 n. 2 - Agosto

6 si presume sia alta la concentrazione di dispositivi mobili di ultima generazione. Come illustrato in figura 5 il Mobile Client Honeypot è composto di una serie di telefoni, equipaggiati con una specifica variante del software della sentinella, collegati ad un PC tramite cavo USB. Il computer gestisce la batteria di telefoni e permette di simulare il comportamento dell utente reale. Tale interazione è resa possibile dall utilizzo di diverse componenti. In particolare, sul telefono sono presenti due moduli: La logica di intercettazione degli eventi, identica a quella utilizzata dalla sentinella, che può segnalare situazioni quali l arrivo di nuovi messaggi (SMS, MMS) o l installazione di nuove applicazioni; gli eventi rilevati sono però inoltrati al PC di controllo, invece di essere gestiti localmente dal software installato sul terminale. Inoltre, la logica di intercettazione è configurata in modo da risultare molto più sensibile agli eventi identificati, in quanto in condizioni normali non si dovrebbe registrare nessun tipo di attività sull honeypot ed ogni evento è per sua natura sospetto. Un componente che riceve i comandi dal PC e li esegue sul telefono, per simulare l attività di un utente che, ad esempio, invia messaggi o installa applicazioni, o esegue un reboot del terminale. Anche sul PC sono installati dei componenti specifici per interagire con i terminali, in particolare: Un componente che riceve gli eventi dal telefono, li elabora ed eventualmente fornisce azioni di risposta da emulare sul telefono stesso. In questo modo è possibile simulare il comportamento di un utente piuttosto disinvolto dal punto di vista della security, che dunque installa tutte le applicazioni ricevute, accetta qualsiasi connessione in ingresso (anche da parte di dispositivi sconosciuti) ed eventualmente risponde ai messaggi ricevuti, che potrebbero essere parte di una scansione. Un componente che si occupa di inoltrare gli allarmi rilevati verso il collettore. A differenza della sentinella, che prevede che tale azione sia compiuta dal telefono, è possibile inviare dal PC informazioni molto più dettagliate, avendo a disposizione maggiori risorse computazionali e maggiore banda trasmissiva. L MCH emula il comportamento di un utente che non ha alcuna sensibilità verso le problematiche di sicurezza. Dal punto di vista pratico, questo comportamento viene implementato in tre modi diversi: 1) installando tutti gli applicativi ricevuti attraverso uno dei canali disponibili, e mandandoli in esecuzione; 2) cercando di seguire i link presenti nei messaggi ricevuti (SMS, MMS, ); 3) cercando di aprire con il relativo visualizzatore un documento ricevuto attraverso uno dei canali disponibili. Bluetooth File Transfer Data Connection URL open apps download... MMS SMS MMS = SMS = URL = Real-Time Resource Monitoring User-Like Action.sis install.app.exe run reboot reset Multimedia Message Service Short Message Service Universal Resource Locator FIGURA 5 Architettura MCH (Mobile Client Honeypot). User Emulation Logic Alerter Analisi degli eventi registrati, definizione e attivazione possibili reazioni human-like Collector L installazione delle applicazioni ricevute è sicuramente una delle tecniche che può rivelare il maggior numero di anomalie; infatti, la maggior parte dei virus odierni si diffonde tramite l installazione esplicita di applicazioni malevole che possono essere scambiate sia attraverso una connessione a corto raggio (ad esempio attraverso Bluetooth), sia sotto forma di allegati in un MMS. Nel caso specifico dei sistemi Symbian, le applicazioni sono solitamente impacchettate in file.sis che sono gestiti dall installer locale presente sul terminale. L installazione prevede che i file che costituiscono l applicazione siano copiati in specifici punti del file-system e che siano eventualmente eseguiti dei programmi al contorno. In ogni caso, l installazione prevede una certa interazione con l utente attraverso semplici finestre di dialogo. Essendo noto il formato dei file.sis, è possibile automatizzare la procedura di installazione, evitando l interfaccia utente, riconoscendo i singoli file contenuti nel pacchetto ed eseguendo automaticamente la procedura di installazione descritta nel pacchetto. All arrivo di un.sis, l honeypot ne riconosce il contenuto applicativo, controlla se quel file è stato già ricevuto, nel qual caso si limita semplicemente a segnalare l arrivo di un file già visto in precedenza, altrimenti lo installa automaticamente. Al termine dell installazione l MCH verifica la situazione del file system e segnala tutti i file creati, cancellati o modificati dal processo di installazione. Allo stesso tempo verifica anche l elenco dei processi in esecuzione e segnala eventuali differenze. Dopo questi controlli l MCH esegue l applicazione installata. Il terminale su cui gira l applicazione è strumentato per mezzo della logica di intercettazione degli eventi ed è in grado di rilevare immediatamente situazioni anomale, che indicano la possibile natura malevola dell applicativo. Nei casi più sem- 20 NOTIZIARIO TECNICO TELECOM ITALIA Anno 17 n. 2 - Agosto 2008

7 plici, l esecuzione dell applicativo può scatenare comportamenti illeciti, come chiamate a numeri ad alta tariffazione o invio di messaggi. In casi più complessi potrebbe essere necessario simulare un interazione dell applicativo con l utente per scatenare un eventuale comportamento sospetto. In quest ultimo caso, l honeypot invia al dispositivo degli eventi emulati (ad esempio la pressione di un bottone di OK). L MCH monitora l esecuzione dell applicativo sul terminale per un prefissato periodo di tempo durante il quale rileva tutto ciò che accade sul dispositivo. Considerando che su di un honeypot non dovrebbe essere registrata nessuna attività (il fatto stesso che sia arrivato un contenuto applicativo da eseguire è molto sospetto), qualunque evento è un anomalia che potrebbe indicare la presenza di malware. Per poter legare gli eventi sospetti alla specifica applicazione, sul telefono viene installata, eseguita e monitorata una sola applicazione alla volta. Al termine dell analisi viene eseguita una procedura di ripristino, che riporta il cellulare nelle condizioni iniziali. Questo approccio permette di identificare due categorie di malware: 1) virus/worm, che contengono payload malevoli di varia natura (ad esempio inviano messaggi utilizzando il credito dell utente, come nel caso di CommWarrior) e li manifestano durante l esecuzione; 2) trojan, che aprono delle backdoor, vie di comunicazione con l esterno per poter essere manovrati da remoto, e restano in attesa di comandi. Questa categoria di attacco è più complessa, molto utilizzata in ambito tradizionale, ma non esistono ancora esempi noti in contesto mobile. Durante dell intervallo di analisi, l MCH fornisce un resoconto dettagliato degli eventi intercettati sul telefono, rendendo possibile non solo il rilevamento di attacchi semplici, come quelli apparsi finora, ma anche di quelli più complessi. L applicativo viene inoltrato al collettore di allarmi, che lo passerà quindi al sistema di analisi statica delle applicazioni. In questo modo, è possibile avere due viste diverse sulle caratteristiche specifiche dell applicazione. Al termine dell analisi parte la procedura di disinstallazione, verificata monitorando il filesystem e l elenco dei processi in esecuzione, per riportare il sistema nello stato iniziale. L approccio basato sull installazione automatica delle applicazioni funziona se le applicazioni arrivano direttamente sul terminale; in alcuni casi, l applicazione potrebbe essere consegnata in modo indiretto, ad esempio seguendo un link contenuto in un messaggio ricevuto precedentemente sul terminale. Pertanto, ogni volta che arriva un messaggio, l MCH controlla se esso contiene un link ad un applicazione scaricabile via web ed in caso la scarica e la installa, eseguendo quindi la procedura descritta in precedenza. In ogni caso, la ricezione di un messaggio e la relativa attività che ne deriva sono comunque segnalate per mezzo del meccanismo di inoltro degli allarmi. Il tracciamento di questi messaggi consente di identificare attività di spam e phishing. Sebbene non siano ancora noti casi di problemi correlati allo sfruttamento di vulnerabilità presenti negli applicativi, l MCH prevede un terzo comportamento che mira proprio ad identificare questo genere di attacchi. Come è ben noto nel contesto Internet tradizionale, molti applicativi che visualizzano e manipolano documenti complessi, possono avere delle vulnerabilità che consentono ad un attaccante di eseguire del codice arbitrario sul sistema compromesso. Buffer Overflow [6] e Format String [7] sono due dei più noti esempi di questo genere di problemi. Le applicazioni potenzialmente più a rischio in questo specifico ambito sono rappresentate dal browser e dal sistema di lettura/scrittura dei messaggi. L MCH pertanto cerca di visualizzare tutti i messaggi ricevuti e cerca di navigare, sempre con un approccio di tipo crawler, sui siti web indicati nei messaggi. Se a fronte di questa attività viene rilevata una qualche anomalia, come ad esempio l apertura di una porta TCP in ascolto, l invio di un messaggio o la modifica della configurazione del terminale, la pagina in questione viene considerata anomala e si procede quindi con l invio di un allarme. La pagina stessa viene inclusa nel payload associato all allarme. In futuro possono essere previsti controlli anche per altre applicazioni che risultino vulnerabili e potenzialmente pericolose. 2.3 MMSC-Probe La piattaforma MoSeS prevede la possibilità di inserire nell architettura di riferimento le sonde di rete che operano a livello centrale; la caratteristiche essenziale di questi elementi è quella di analizzare tutti i dati specifici del server a cui sono associate, fornendo una vista ortogonale rispetto a quella fornita dagli elementi che lavorano a livello del terminale. Questo fatto però richiede lo sviluppo di un componente ad-hoc per ciascun elemento che si vuole monitorare. Al momento, è stata sviluppata la sonda specifica per l MMSC, visto che gli MMS sono uno dei vettori privilegiati per la propagazione delle infezioni. La MMSC-Probe analizza il flusso di messaggi MMS di tipo Person-to-Person che transitano sulla rete dell operatore. Quest analisi centralizzata dei messaggi integra quella effettuata dalle sentinelle. Sul terminale si possono analizzare in dettaglio tutti i messaggi di un utente con controlli locali ; ovvero, ad esempio, la provenienza di un MMS da un numero non in rubrica o la reazione dell utente all arrivo un file eseguibile (installazione o cancellazione). In rete, invece, la visione è allargata: non si scende nel dettaglio del singolo utente, ma si analizzano tutti gli MMS, registrando i flussi, i picchi di frequenza e la diffusione anomala di payload sospetti. L MMSC-Probe è costituita da un sistema di acquisizione degli MMS, da un componente di analisi ed un modulo di formattazione ed invio degli Alert al sistema centrale di smistamento. I primi due NOTIZIARIO TECNICO TELECOM ITALIA Anno 17 n. 2 - Agosto

8 moduli operano essenzialmente in modo seriale ; in altre parole, ogni messaggio che raggiunge l MMSC viene inoltrato anche alla sonda, che effettua le analisi relative e, se necessario, emette un allarme. Nel caso specifico della rete TIM, i messaggi MMS arrivano in primo luogo ad un server denominato MNS (Multimedia Networking System), che svolge funzioni di load balancing, smistando i messaggi su diversi MMSC. A questi server, che forniscono il servizio essenziale di invio dei messaggi agli utenti, ne sono affiancati altri che svolgono servizi aggiuntivi; in particolare, il sistema ibox, utilizzato per rendere accessibili i messaggi via Web. L MMSC-Probe è interfacciato direttamente all MNS in maniera del tutto passiva: è sufficiente che la sonda riceva tutto il flusso di MMS in transito. Un interprete è in grado di ricomporre i messaggi dal flusso di rete, seguendo lo standard OMA [8], e renderli disponibili per le analisi. Sul flusso di MMS in arrivo possono essere svolte diverse analisi, suddivise in moduli per avere una soluzione flessibile e aperta a futuri miglioramenti. È inoltre possibile aggiungere dei moduli specifici che implementino gli algoritmi euristici suggeriti dai produttori di antivirus partner di Telecom Italia, usufruendo così della loro esperienza decennale in questo campo. Anche in questo caso, la rilevazione di fenomeni malevoli non noti a priori si basa sul paradigma dell Anomaly Detection, ovvero lo scostamento da comportamenti considerati normali. Infatti, questo approccio è il più indicato per un sistema di rilevazione precoce, in cui vengono inizialmente identificati comportamenti sospetti che devono poi essere monitorati più approfonditamente, per poter giungere a considerazioni di sicurezza più dettagliate ed affidabili. Il comportamento normale può essere definito da precise regole (Rule-Based) o da un insieme di valori standard di riferimento (Statistical Anomaly Detection). Nel primo caso, le regole sono impostate tramite opportune policy, eventualmente modificabili dinamicamente per adeguarsi al mutare delle situazioni. L anomalia corrisponde al non rispetto di una o più di queste regole. Nel secondo caso, invece, l anomalia è legata ad una metrica che misura la distanza dai valori standard. In entrambi i casi occorre un periodo iniziale, cosiddetto di learning, su dati da considerarsi non malevoli, per registrare i valori standard ed effettuare la verifica delle policy ed il tuning delle soglie. Il learning può poi continuare dinamicamente durante la fase di analisi per effettuare un autotuning dei valori standard, in modo da recepire le lente variazioni del sistema. I moduli di analisi attualmente previsti nell MMSC-Probe sono: 1) Content Analysis (Rule-based): analizza l header degli MMS e di tutte le parti all interno di ogni MMS per verificarne la correttezza sintattica e semantica secondo policy di sicurezza. L invio di MMS malformati potrebbe rappresentare un tentativo di sfruttare eventuali vulnerabilità dei moduli di parsing dei server di rete che erogano il servizio o dei cellulari che visualizzano i messaggi. 2) Payload Analysis (Statistical): analizza il contenuto dei messaggi per rilevare anomalie rispetto alla composizione standard e per registrare diffusione o permanenza troppo elevata in rete di singoli payload (parti del messaggio). Ogni payload normale quale testo, foto, audio, video ha infatti una diffusione ed tempo di vita limitato in rete, a differenza di virus e worm che hanno una diffusione molto più significativa e per un periodo di tempo più lungo. 3) Frequency Analysis (Statistical): rileva picchi di frequenze rispetto ai flussi standard, con suddivisione temporale per fasce orarie e catalogazione degli utenti per profili di utilizzo del sistema MMS. L idea alla base di questo modulo di analisi è che varie forme virali o di malware possano alterare significativamente il flusso di MMS dei singoli utenti. Questo è vero sia nel caso di worm con meccanismi di autopropagazione (che faranno quindi anche scattare un anomalia da parte del modulo di Payload Analysis), sia nel caso di trojan che effettuano ripetuti invii di messaggi senza payload malevolo (DDoS, SPAM, dialer, esaurimento credito del cliente). Per quanto riguarda le analisi del comportamento degli utenti in termini di invio di MMS, questo viene sempre monitorato senza utilizzare i numeri telefonici reali, per ovvi motivi di privacy, ma tramite una trasformazione univoca (es. cifratura) del numero stesso in modo che l analisi sia completamente anonima ma riesca comunque a mantenere traccia dei singoli flussi. 2.4 Application Analyzer Le applicazioni sono al momento il meccanismo di propagazione del malware più tipico; per questo motivo, la piattaforma MoSeS prevede un componente specifico per eseguirne un analisi particolarmente approfondita. Una applicazione può trasportare il malware nei modi più svariati: è possibile nascondere il file infetto tra quelli presenti nell installer, modificare l entry-point dell programma principale per eseguire del codice malevolo, o l applicazione stessa può essere a tutti gli effetti un trojan horse. L Application Analyzer esegue una serie di controlli basati su varie tecniche di Reverse Engineering [9], per cercare di definire il livello di pericolosità associato all applicazione. L analisi tramite Reverse Engineering di un programma in binario viene solitamente eseguita manualmente, e prevede una combinazione di tecniche statiche e dinamiche. L approccio statico si basa sull analisi diretta del disassemblato, allo scopo di ricostruire il programma nella sua interezza. Teoricamente, è l approccio più potente, perché consente un analisi completa di tutto il codice; tuttavia, è estremamente difficile analizzare dei binari che siano stati sottoposti a manipolazioni specifiche per rendere il codice meno comprensibile o cifrato. 22 NOTIZIARIO TECNICO TELECOM ITALIA Anno 17 n. 2 - Agosto 2008

9 L approccio dinamico prevede l esecuzione del binario in un ambiente controllato e strumentato; questo modo di operare è più semplice rispetto a quello descritto nel caso precedente ed in molti casi è possibile isolare immediatamente il comportamento illecito del programma; tuttavia, così facendo, è possibile osservare solo uno specifico comportamento del programma, corrispondente a quella particolare esecuzione; in altre parole, l analisi dinamica fornisce sempre una vista limitata del comportamento dell applicazione. Normalmente, la Reverse Enginering mira alla ricostruzione completa del codice sorgente del programma, così da capire esattamente tutto ciò che fa. È praticamente impossibile ottenere tale comprensione usando solo uno strumento automatico; tuttavia, nel nostro specifico ambito applicativo, non è tanto importante ricostruire l intero programma, ma è sufficiente identificare frammenti di codice potenzialmente pericolosi, per fornire una segnalazione in tal senso. Si noti che questo approccio è totalmente diverso da quello usato in un anti-virus tradizionale: in questo caso, il programma viene setacciato per identificare un comportamento anomalo che non è associato ad una signature precisa. Inoltre, nel caso specifico del sistema operativo Symbian, la struttura degli applicativi è caratterizzata da vincoli molto particolari (si rimanda alla documentazione specifica per i dettagli) e questo fatto consente di semplificare ulteriormente l analisi. L Application Analyzer sfrutta esclusivamente delle tecniche di analisi statica. Ogni volta che uno dei componenti della piattaforma MoSeS identifica un applicativo, sia sotto forma di file di installazione (.sis), sia sotto forma di eseguibile (.exe,.app oppure.dll), associato ad una qualche anomalia, viene emesso un alert. Questo alert raggiunge il collettore di allarmi, che invoca l Application Analyzer passandogli in input l oggetto ricevuto. L Application Analyzer disassembla il file che ha ricevuto e costruisce il call-graph di riferimento. Il call-graph è un grafo i cui nodi sono gli entry-point delle subroutine da cui è costituito l eseguibile, ed i cui archi collegano un vertice V1 ad un vertice V2 se e solo se la funzione rappresentata da V1 chiama la funzione rappresentata da V2; la ricostruzione del call-graph è resa complicata dalla presenza delle funzioni virtuali, ma è comunque possibile identificare l interfaccia astratta associata alla classe. Dopo aver ottenuto il call-graph, se ci sono API potenzialmente pericolose utilizzate dall applicazione, si esegue un controllo sul grafo di eventuali frammenti di codice che somigliano a frammenti di codice estratti dal malware esistente. Ad esempio, è possibile andare alla ricerca delle sequenze di funzioni che consentono di eseguire un azione quale l invio di una chiamata, l invio di un messaggio senza che l utente venga notificato, o di quelle che eseguono un analisi esaustiva della rubrica o della porzione del file-system riservata ai dati personali. L output dell'application Analyzer è una scheda riassuntiva delle caratteristiche dell applicazione, che sottolinea le criticità identificate; queste informazioni possono quindi essere inserite nel database gestito dall alert collector e possono essere quindi incrociate con le informazioni raccolte dagli altri elementi dal sistema di correlazione. 2.5 Alert Collector La possibilità di incrociare i dati raccolti dalle sentinelle, dagli MCH e dalle sonde è cruciale per il corretto funzionamento del sistema. Per questo motivo, la piattaforma MoSeS prevede l esistenza di un punto centrale di raccolta, memorizzazione, aggregazione e correlazione dei dati. L efficacia dell intero framework deriva infatti proprio dalla capacità di fornire diverse viste dei problemi presenti sulla rete mobile, in modo da poter delineare un quadro complessivo che sia quanto più possibile preciso. Il sistema centrale, denominato Alert Collector, svolge dunque diversi compiti fondamentali per il funzionamento complessivo dell intera piattaforma: Raccolta di allarmi dalle componenti distribuite dell architettura: è la funzione fondamentale dell Alert Collector; gli allarmi sono emessi dagli elementi di rilevazione sono quindi memorizzarli su un database. Il formato degli allarmi è già normalizzato, poiché ogni elemento è dotato di un opportuno modulo che si occupa di generare le segnalazioni in un formato comune. Inoltro degli applicativi da analizzare all Application Analyzer: l Alert Collector ha il compito di inoltrare all Application Analyzer tutti i nuovi file eseguibili (.sis,.app,.exe,.dll) giunti dalle componenti dell architettura insieme agli allarmi. Il risultato delle analisi approfondite ritornato dall Application Analyzer sarà a sua volta memorizzato nel data-base, insieme ad un identificativo univoco del binario. Analisi dei dati ricevuti, generazione di nuovi alert: dopo che gli allarmi sono stati ricevuti, memorizzati ed eventualmente integrati da un analisi approfondita dei payload eseguibili, è possibile applicare ai dati presenti nel database degli algoritmi di analisi ed aggregazione per creare alert di secondo livello, che forniscano ad un operatore umano delle informazioni più precise e dettagliate. Attivazione di contromisure automatiche di protezione: l obiettivo principale della piattaforma MoSeS è la rilevazione anticipata degli attacchi specifici del contesto mobile; è possibile però usare in modo estremamente utile queste informazioni per attivare e riconfigurare altri sistemi di protezione e prevenzione automatici o semiautomatici. Uno di questi scenari può essere quello di velocizzare il processo di scoperta di nuovi virus e generazione della signature inviando direttamente ai produttori di anti-virus i payload sospetti non appena vengono rilevati (prima cioè che si propaghino in modo esteso sulla rete). Inoltre, è possibile associare all output della piattaforma un sistema di policy enforcement che riesca a riconfigurare remotamente NOTIZIARIO TECNICO TELECOM ITALIA Anno 17 n. 2 - Agosto

10 i terminali degli utenti, anche solo temporaneamente, per arginare il problema in attesa che venga generata la signature del virus, o rilasciata la patch dell applicazione vulnerabile, o inseriti gli opportuni filtri sui server di rete. Infine, è possibile pensare ad un invio di notifiche agli utenti, fornendo delle indicazioni che evitino di contrarre il virus. Gestione del sistema: lo sviluppo futuro della piattaforma prevede che tutti gli elementi di rilevazione siano configurabili ed aggiornabili da remoto. 3. Conclusioni Il problema della sicurezza del contesto mobile esiste, ci sono virus già diffusi tra gli utenti, ma non hanno ancora payload particolarmente dannosi e sono tenuti sotto controllo dagli opportuni antivirus di rete. Fortunatamente il livello di rischio attuale è basso, ma le possibilità di confezionare software malevolo dal potenziale molto dannoso per il singolo utente o per l infrastruttura mobile aziendale, ci sono già tutte. L offerta di nuovi servizi da parte degli Operatori e l evoluzione tecnologica dei terminali mobili impongono una standardizzazione delle piattaforme che inevitabilmente espone il fianco a vulnerabilità o a nuove specifiche famiglie di virus. Le soluzioni derivate dall attuale mondo dell informatica non saranno sufficienti a garantire una completa copertura di sicurezza. In questo scenario, l innovativo sistema di rilevamento anticipato di minacce e attacchi, presentato nell'articolo, sarà un utile strumento per individuare e monitorare le problematiche che affliggeranno i terminali e la rete mobile, cogliendoli fin dai primi segnali più deboli e permettendo di approntare tempestivamente le contromisure più idonee per proteggere la rete, i servizi e gli utenti finali. francesco.codazabetta@telecomitalia.it gianluca.cangini@telecomitalia.it stefano.brusotti@telecomitalia.it Stefano Brusotti si è laureato in Scienze dell Informazione presso l Università degli Studi di Torino nel 1994 e ha conseguito il Master COREP in Telecomunicazioni nel È entrato in CSELT nel 1996 dove si è inizialmente occupato di sistemi di pagamento e moneta elettronica e successivamente di ricerca e sviluppo per la sicurezza delle reti, dei sistemi e delle applicazioni su cui ha maturato oltre dieci anni di esperienza. Oggi è Responsabile Security Innovation in Telecom Italia. Gianluca Cangini si è laureato in Ingegneria Informatica presso l Università degli Studi di Bologna nel 2000 ed ha conseguito il master COREP in Telecomunicazioni nel Dal 2001 fa parte del gruppo Security Innovation di Telecom Italia dove inizialmente si è occupato di Vulnerabiliy Assessment ed Intrusion Detection. Negli ultimi anni ha affrontato prevalentemente la tematica di sicurezza in ambito mobile. BIBLIOGRAFIA [1] Cabir - [2] CommWarrior - [3] Information Assurance through Defense-in-Depth ; Control, Communications, and Computer Systems, U.S. Department of Defense Joint Staff, February [4] E. Gamma, R. Helm, R. Johnson, J. Vlissides: Design Pattern Elements of Reusable Object Oriented Software ; January 1995; Addison-Wesley.[5] L. Spitzner: Honeypots: Definition and Value ; [6] Aleph One: Smashing the Stack for Fun and Profit ; published in Phrack vol. 7, Issue 49, File 14. [7] Anonymous: Advances in Format String Exploitation ; published in Phrack vol. 11, Issue 59, File 9. [8] Multimedia Messaging Service Encapsulation Protocol, OMA-MMS-ENC-V1_ A; disponibile on-line: gram/docs/mms/v1_ a/oma-mms-enc- V1_ A.pdf [9] Reverse Engineering: ACRONIMI API BREW EDGE HIDS J2ME MANet MCH MMS MMSC MNS MoSeS OMA PDA PAN RIM SIM SMS UMTS USB WiFi Application Programming Interface Binary Runtime Environment for Wireless Enhanced Data GSM Environment Host based Intrusion Detection System Java 2 Mobile Edition Mobile Ad hoc Network Mobile Client Honeypot Multimedia Message Service Multimedia Message Service Center Multimedia Networking System Mobile Security System Open Mobile Alliance Personal Digital Assistant Personal Area Network Research In Motion Subscriber Identity Module Short Message Service Universal Mobile Telecommunications System Universal Serial Bus Wireless Fidelity Francesco Coda Zabetta si è laureato in Fisica a Torino nel 2000, dedicandosi prevalentemente alla fisica teorica e delle particelle. Dal 2001, dopo un master in Internet Security presso la SSGRR, si è unito al Centro di Sicurezza Be-Secure di TILAB (oggi Security Innovation in Telecom Italia), dove è impegnato su tematiche di innovazione nel settore delle tecnologie di rilevamento e contrasto delle intrusioni, sia in ambito tradizionale che in ambito mobile. 24 NOTIZIARIO TECNICO TELECOM ITALIA Anno 17 n. 2 - Agosto 2008