Capitolo
II: Criticità degli SMS generati da Internet nelle reti GSM
Criticità degli SMS generati da Internet: introduzione
Le reti cellulari sono un elemento critico
dell’infrastruttura economica e sociale in cui viviamo [25, 23]. La maggior
parte degli utenti di telefonica mobile è abilitata ad usare il servizio di
Short Message (SMS). Per incoraggiare
lo sviluppo di tale servizio, le compagnie di telecomunicazioni hanno pensato
di offrire un collegamento tra Internet e le loro reti. Questa apertura a nuove
funzionalità ha permesso lo sviluppo di servizi a valore aggiunto per l’utente;
dal punto di vista della sicurezza ha rilevato un elemento di alta criticità nelle reti GSM.
Lo scopo di questo capitolo è di valutare la sicurezza
delle interfacce per inviare SMS disponibili per reti di telefonia mobile. In particolare ci occuperemo degli SMS
generati da Internet e dell’impatto che può avere un uso malizioso di questi sulla sicurezza del sistema SMS di reti
cellulari GSM, considerando due differenti scenari d'attacco: area metropolitana e Stato.
Ripercorriamo in breve quanto descritto nel Capitolo I,
approfondendo gli elementi che possono presentare una criticità nel sistema SMS
di un rete GSM.
Possiamo dire che ci sono due modi per inviare SMS:
attraverso un dispositivo cellulare, oppure attraverso una entità esterna detta External Short Messaging Entities (ESME). In queste entità esterne sono
incluse anche e-mail e portali web.
Cosa accade quando uno dei sistemi descritti prima è
connesso via Internet ad una rete di telefonica mobile ed invia un SMS? Prima
di tutto il messaggio viene consegnato a un server che gestisce il traffico
degli SMS; tale entità è stata in precedenza definita come centro messaggi
SMSC. Come visto nel precedente capitolo, un provider di SMS deve avere almeno
un centro messaggi nella sua rete. Qualora il provider volesse aumentare la sua
capacità di lavoro, può aggiungere più SMSC in modo da smaltire più traffico.
Una volta ricevuto il messaggio, viene esaminato il contenuto del pacchetto e
se necessario (qualora il messaggio fosse contenuto in un pacchetto con un
formato diverso da quello standard degli SMS) viene convertito nel formato SMS
standard delle reti GSM. A tal punto non esiste più la differenza tra un
messaggio proveniente da Internet e uno generato da un dispositivo mobile.
Quindi il messaggio viene posto in coda per essere inoltrato.
· il routing di un SMS;
· l'interfaccia air.
Il centro messaggi SMSC, dopo aver ricevuto un
messaggio, deve sapere dove instradarlo, quindi interroga il database HLR, che
è un repository di dati relativi agli
utenti quali: informazioni di sottoscrizione del servizio (es: avviso di
chiamata, SMS, etc.), disponibilità dell’utente e localizzazione corrente.
Questo database, attraverso l’interazione con altre reti, determina le
informazioni di routing per il dispositivo a cui è destinato un messaggio.
(a)
(b)
Figura 1: esempio di invio di un messaggio SMS in una
rete GSM.
(a) Diagramma di una rete telefonica mobile. (b)
Procedure per l’invio di messaggi:
External Short Messaging Enities (ESME) invia un messaggio ad un
dispositivo mobile Mobile Host (MH).
In questo scenario, il centro messaggi riceve una
risposta dal database HLR circa la disponibilità dell’utente destinatario sulla
rete. Se l’utente non è disponibile, il centro messaggi SMSC memorizza il
messaggio per poi consegnarlo successivamente; altrimenti la risposta dell’unità
HLR contiene l’indirizzo del nodo switch MSC al quale inviare il messaggio per
poterlo consegnare. La componente MSC è responsabile del routing. Inoltre ha il
compito di facilitare l’autenticazione dei dispositivi mobili, di gestire la
localizzazione delle Base Station (BS) connesse agendo come un gateway
di una rete pubblica.
Quando arriva un messaggio dal centro messaggi ad uno
“nodo switch” MSC, questo interroga
il database VLR che contiene le informazioni sui dispositivi mobili localizzati
in una determinata area MSC. La risposta del VRL all’interrogazione ritorna
informazioni sulla localizzazione del dispositivo destinatario. A questo punto
MSC inoltra il messaggio verso la stazione BS, la quale provvederà a consegnare
al destinatario il messaggio SMS.
Le Figure 1(a) e 1(b) illustrano meglio gli attori
principali dello scenario descritto e come questi interagiscono tra loro.
L’interfaccia air
con la quale le stazioni mobili MS comunicano con il sottosistema base BSS, è
divisa in due parti (Figura 2):
·
Control Channels (CCH)
·
Traffic Channels (TCH)
Figura 2: interfaccia “Air”.
Il canale TCH è usato per trasportare voce e dati.
Il canale di controllo CCH è a sua volta suddiviso in
due parti:
-
Dedicated CCH:
ogni entità connessa è identificata attraverso un identificativo del canale
fisico (codice);
- Common CCH:
le entità che vi si connettano necessitano di essere identificate, quindi
inattive (entità in Idle mode).
Il Common CCH
è il canale usato da una BS per la consegna di dati riguardanti voce e SMS; è
composto da canali logici, tra i quali il Paging
Channel (PCH) e il Random Access Channel (RACH). Tutti i dispositivi connessi,
sia per traffico voce che per SMS, sono inseriti nel Common CCH.
Una BS invia un messaggio sul canale logico PCH,
contenente un identificativo del destinatario detto Temporary Mobile Subscriber ID (TMSI). La rete usa tale identificativo per mettere in comunicazione
il dispositivo richiedente e quello di destinazione. Quando un dispositivo mobile
rileva il suo TMSI (Figura 3), contatta la stazione base attraverso il canale RACH e allerta la rete circa la sua
disponibilità, quindi la capacità di ricevere voce e dati. Appena arriva la
risposta,
Usando SDCCH
- autenticare la
stazione di destinazione (attraverso le informazioni di sottoscrizione nel
MSC);
-
cifrare la
comunicazione;
-
consegnare un
nuovo TMSI;
-
consegnare il
messaggio SMS stesso.
Al fine di ridurre l’overhead di informazioni
scambiate in fase di handshake, nel caso in cui debbano essere consegnati più
messaggi SMS presenti sul centro messaggi SMSC, è possibile trasmettere
all’interno della stessa sessione SDCCH più messaggi [17]. Qualora ci fosse una
chiamata in attesa sulla BS, potranno essere usati tutti gli altri canali
disponibili per veicolare altre comunicazioni come SMS. Un’idea di questo
schema di interazione per stabilire una comunicazione è illustrata in Figura 3.
Figura 3:
comunicazione sull’interfaccia “air”: MH1 e MH2 sono le due stazioni mobili.
2.4
Vulnerabilità di reti cellulari SMS
Solitamente l’uso degli SMS è stato da sempre caratterizzato
come una feature secondaria della rete GSM.
In occasione dell’attacco alle “Torri Gemelle”
(Manatthan, NY) del 2001, è stato possibile scorgere aspetti che hanno fatto
cambiare connotati e valore alla comunicazione SMS.
In quella situazione così drammatica, milioni di
persone cercavano di comunicare localmente, chiamando amici e conoscenti
presenti nella zona dell’attentato. Le compagnie telefoniche interessate hanno
avuto incrementi di traffico strabilianti che vanno dal 100% della Verizon
Wireless, al 1000% della Cingular Wireless. E’ facile capire come presto si è
avuta una saturazione della comunicazione telefonica vocale, a causa della
saturazione del canale di traffico TCH. Intanto il traffico della comunicazione
SMS era ancora disponibile sulle reti saturate localmente, poiché i canali di
controllo CCH ,responsabili della consegna dei messaggi di testo, erano ancora
disponibili all’uso. Da allora gli SMS sono visti come un mezzo per comunicare
quando tutti gli altri modi sembrano non disponibili.
Data la proliferazione dei messaggi di testo, è
interessante analizzare l’impatto di un attacco portato con gli SMS alla rete
GSM, quindi prevedere gli effetti sulla comunicazione vocale e sugli altri
servizi disponibili su una rete cellulare.
Come spesso occorre fare per difendersi, bisogna prima
esaminare il problema dal punto di vista di un attaccante, quindi individuare
le fragilità e gli aspetti critici.
In definitiva i messaggi di testo SMS su apparecchi
mobili e le chiamate vocali usano lo stesso canale (CCH) per effettuare il
setup della sessione. Attraverso l’individuazione dei “colli di bottiglia” che il sistema SMS di una rete GSM presenta, si
intravedono buoni spunti per portare un attacco a tale sistema. Se un adeguato
numero di SMS viene immesso sulla rete al punto da saturare il canale di
controllo, sarà impossibile accettare sia nuove chiamate che nuovi SMS (vedi Figura
4).
Figura 4: Canale di controllo CCH: sulla
sinistra è illustrata una richiesta di instaurare una sessione per una chiamata
vocale che va a buon fine; sulla destra la stessa richiesta viene rifiutata.
2.5 Individuazione
di “colli di bottiglia” nelle reti cellulari
C’è un "costo" individuabile tra l’inserimento di
messaggi SMS nella rete telefonica e la consegna all’utente. Questo “costo” è
la base di partenza per un attacco Denial
of Service (DoS), che ha lo
scopo di rendere inutilizzabile il servizio.
L’osservazione di questi colli di bottiglia richiede
uno studio accurato delle reti cellulari. La documentazione standard in proposito offre
una trattazione esaustiva su come è costruito il sistema, tralasciando dettagli
specifici. Per colmare questo gap utilizzeremo test basati su “gray-box”
[19, 26].
Il metodo di testing denominato “gray-box” è una fusione dei metodi “white-box” e “black-box”,
dove come “box” è da intendersi l’elemento da testare.
Il metodo di analisi “white-box”, presuppone la conoscenza e lo studio dei codici
sorgenti o degli algoritmi dell’oggetto del test; in definitiva si posseggono
gli strumenti per entrare nella “box” da studiare.
Riguardo il metodo “black-box”, si è nella situazione opposta alla precedente: è
possibile solo avere risposte ad input forniti alla “box” da testare; rimane
solo da studiare i risultati agli input forniti.
Il metodo di testing “gray-box” combina i due metodi descritti. I test usando “white-box”
rilevano più bugs, anche se allo stesso tempo non individuano problemi reali
che possono generarsi con un uso malizioso della “box”. Al contrario, i test “black-box” mettono in luce i reali
problemi dell’oggetto del test, ponendo la “box”
alle sollecitazioni più disparate. Combinando assieme i due metodi è possibile
avere risultati più ampi circa le potenzialità, i bugs e le debolezze di un
particolare elemento.
Nel nostro caso la “box” da testare è costituita dall’invio di SMS su una rete GSM. In
particolare ci sono dei parametri interessanti da analizzare usando il metodo
di testing “gray-box”.
Tali parametri sono:
·
discipline di consegna;
·
velocità di consegna;
·
interfacce usate.
I metodi di consegna di messaggi SMS, determinano il
movimento dei messaggi all’interno del sistema. Studiando tale flusso è
possibile determinare la risposta del sistema ad un inserimento di messaggi di
testo. La risposta globale del sistema evidenzia più punti in cui è possibile
avere code, quindi potenziali colli di bottiglia. La documentazione standard ci
aiuta indicandoci due punti di grande interesse:
·
centro messaggi
SMSC;
·
dispositivo
portatile.
Il centro messaggi SMSC è il luogo attraverso il quale
passano tutti i messaggi. Ogni SMSC ha una limitazione pratica dovuta al numero
limitato di messaggi che può mantenere in coda per ogni utente. Poiché i centri
messaggi instradano messaggi secondo un meccanismo di “store-and-forward”, ogni messaggio è memorizzato fino a quando il
dispositivo ricevente non lo riceve correttamente oppure supera il suo tempo
massimo di vita. La capacità del buffer e la politica di selezione determinano
quali messaggi giungono al ricevente.
La valutazione del buffer di un centro messaggi e
della politica di selezione, viene testata inserendo messaggi nella rete
lentamente tenendo il terminale del ricevente spento. Tale valutazione è stata
effettuata su tre provider americani: AT&T, Verizon e Sprint. Per ogni
provider sono stati inviati 400 SMS, uno ogni 60 secondi. Nel momento in cui viene
acceso il dispositivo mobile al quale sono stati inviati i messaggi, la
quantità e l’ordine in cui essi arriveranno indicheranno la grandezza del
buffer del provider preso in esame e la politica di selezione usata.
La prova ha evidenziato che il centro messaggi di
AT&T ha bufferizzato tutti i 400 SMS. Lo stesso test fatto sulla Verizon ha
fornito risultati differenti. Quando il dispositivo mobile veniva acceso, il
primo messaggio scaricato non era il primo inviato: i primi 300 messaggi erano
stati persi. Ciò dimostrava che la grandezza del buffer nel caso del centro
messaggi della Verizon è di 100 messaggi e usa una politica di tipo FIFO. Il
centro messaggi della Sprint ha una capacità di 30 messaggi e la sua politica è
LIFO.
C’è da considerare che i messaggi rimangono
all’interno del SMSC anche nel caso in cui il buffer del dispositivo mobile
ricevente è pieno. A tale proposito lo standard GSM prevede che il dispositivo
mobile in questione ritorni un Mobile-Station-Memory-Capacity-Exceeded-Flag
al registro HLR. Poiché è impossibile determinare la capacità di messaggi in
entrata di ogni dispositivo mobile, per il test saranno considerati tre
telefoni che rappresentano tre segmenti di prezzo e di prestazioni (vedi Tabella
1).
Tabella 1:
capacità di immagazzinare messaggi dei dispositivi mobili presi in esame.
I risultati dei test al fine di determinare le
discipline di consegna, indicano come i sistemi SMS reagiscono ad un inserimento
di messaggi in una rete GSM. È possibile affermare che in molti centri messaggi
SMSC esiste una capacità limitata del buffer; stesso dicasi per i dispositivi
mobili. Con tali premesse è plausibile che un attacco di tipo DoS possa essere
portato a termine con successo.
La velocità con cui un insieme di nodi processa ed
instrada un messaggio viene definita Velocità
di Consegna di un messaggio. La determinazione della velocità massima di
inserimento per una rete cellulare è una cosa estremamente complessa. Possiamo
avere un range approssimativo, considerando che, tale velocità di inserimento
di SMS in una interfaccia è compresa tra centinaia e migliaia di messaggi al
secondo. Nella Tabella 2 sono elencate alcune interfacce dalle quali è
possibile immettere SMS sulla rete.
Tabella 2: esempi di accessi a servizi per
l’invio di SMS.
Queste interfacce possono essere
raggruppate in tre categorie principali:
- Instant Messaging: ha le stesse funzionalità di un
messaggio di testo, in più connette una rete differente alla rete cellulare;
- Information Services: gli utenti vengono inondati da messaggi
su news riguardo gli argomenti più disparati;
- Bulk SMS: usato dalle compagnie per inviare messaggi di notifica o
aggiornamento agli impiegati.
I Bulk
SMS usano un protocollo noto denominato
Short Message Peer Protocol (SMPP).
Quindi se per le prime due interfacce la velocità di inserimento di messaggi di
testo è sconosciuta, per quest’ultimo è nota. Infatti i provider di Bulk SMS offrono
soluzioni con 30-35 messaggi per secondo per ogni connessione SMPP.
Usando più connessioni SMPP, START Corp. (www.startcorp.com), possiamo moltiplicare
la velocità di inserimento di SMS sulla rete. Combinando assieme tali
soluzioni, si dà modo ad un avversario di avere una potenza enorme di
inserimento di SMS all’interno di una rete GSM.
Nel momento in cui il tempo di consegna di
un messaggio relativo al suo invio, eccede rispetto alla sua scadenza, un
sistema è soggetto a un attacco DoS.
Per inserire messaggi sulla rete usiamo
uno script PERL che ci permette di inserire circa un messaggio al secondo in
ogni interfaccia web di un provider.
I messaggi SMS hanno una taglia massima di
160 bytes, ma c’è da considerare che ogni invio di messaggio richiede un
overhead aggiuntivo. Usando tcpdump è
possibile osservare contemporaneamente le righe relative all’indirizzo IP e al
traffico.
Non considerando l’overhead del TCP/IP,
Sprint, AT&T e Verizon necessitano di 700 bytes per inviare un messaggio di
160 byte (includendo il http POST e overhead del browser). Considerando anche
gli ACK utili a scaricare le pagine web dei provider (5KB Sprint, 13.6KB
AT&T, 36.4KB Verizon), la grandezza dell’upload è abbastanza significativa.
In definitiva avremo 1300 bytes Sprint, 1100 bytes AT&T, 1600 bytes
Verizon.
Dall’analisi compiuta segue che si può
stimare a 1500 bytes lo “sforzo”, in termini di bytes, per inviare un messaggio
SMS su Internet attraverso le interfacce considerate. Questo parametro tornerà
utile quando si dovrà valutare la potenza di upload necessaria per sferrare un
attacco a tale sistema.
Non bisogna dimenticare di valutare i
messaggi persi e gli invii falliti. Questi aspetti coinvolgono anche la
velocità con la quale l’interfaccia web permette di inviare messaggi. A tale
proposito sono stati inviati gruppi di 50 messaggi alla velocità di circa uno
al secondo. Se non venivano riscontrati problemi il numero di messaggi da
inviare in gruppo aumentava e si eseguiva un nuovo test, alla ricerca di un
limite superiore. Dopo 44 messaggi inviati di seguito tramite l’interfaccia web
messa a disposizione da Verizon, si è verificato un invio fallito. Riguardo
AT&T, si è riscontrato un blocco (impossibilità ad inviare altri SMS)
inviando 50 messaggi a un singolo telefono.
Mentre per Verizon e AT&T viene usata
una limitazione basata sull’indirizzo IP, l’altra compagnia Sprint aggiunge un
nuovo ostacolo: quando si invia un messaggio attraverso l’interfaccia web,
viene richiesto un cookie di sessione (un identificativo di sessione per un
singolo utente).
2.9
Elementi per un attacco via SMS da Internet
Ricapitolando, attraverso test basati su “gray-box”, abbiamo appurato che i centri
messaggi SMSC tipicamente immagazzinano più messaggi dei dispositivi mobili.
Mentre le grandi piattaforme immagazzinano fino a 500 messaggi, i telefoni
comuni possono contenere dai 30 ai 50 messaggi. Quando un dispositivo mobile
non può più ricevere messaggi, se si continua ad inviare SMS da Internet questi
verranno immagazzinati in coda al centro messaggi. Le limitazioni riscontrate con
i test, unitamente all’utilizzo fatto dell’interfaccia air, espongono il sistema di SMS di una rete GSM a un attacco DoS
su più terminali mobili.
Al fine di portare un attacco su una rete
di telefonia mobile con successo, è utile che l’attaccante faccia qualcosa in
più che inviare soltanto messaggi di testo su ogni possibile numero di
telefono. La cosa migliore sarebbe creare
delle hit-list per accelerare
la propagazione via Internet [65], creando un database di “vittime” potenziali
sulla rete da attaccare. Alcune delle tecniche illustrate in seguito sono solo un
piccolo sottoinsieme dei metodi disponibili per creare un attacco diretto.
Il primo passo ovviamente è quello di procurare
i numeri di telefono. Possiamo avere un aiuto in questo senso osservando il
Web
Osserviamo, ad esempio, che gli Stati
Uniti, con il Canada e altre 18 nazioni, fanno parte del North American Numbering Plan (NANP) per la gestione del formato
dei numeri telefonici. Un numero telefonico NANP è formato da 10 cifre
rappresentate da “NPA-NXX-XXXX”. Questi gruppi di cifre rappresentano
rispettivamente
Queste informazioni sono utili ad un
attaccante al fine di ridurre la quantità di numeri da ricercare per uno stato.
Tale informazione non dà direttamente informazione sui terminali effettivamente
collegati a quella rete in quello stato. Inoltre dopo il 23 novembre 2004 è
stata attivata la portabilità dei numeri di telefonia mobile da un provider
all’altro. In tal modo il metodo visto sopra potrebbe essere meno efficace.
Rimane comunque un metodo efficiente se usato assieme ad altre tecniche volte a
ridurre lo spazio dei numeri possibili.
Usando la rete per creare una lista di potenziali vittime si trovano numerose tecniche, tra le quali il Web
Scraping. Questa tecnica è comunemente usata dagli spammers per raccogliere
informazioni sulle potenziali vittime. È possibile reperire informazioni
personali quali email, numeri di telefono, etc., poste in pagine web, usando
motori di ricerca tradizionali oppure script ad-hoc. Ad esempio usando Google e
scrivendo "Cell 999-999-0000..9999", risulteranno circa 865 numeri di telefono
presenti sul Web, relativi allo State College, nello stato di Pasadena; 7308
da New York City; 6184 da Washington D.C..
La difficoltà di questo metodo, come per
il precedente, è che non dà una lista definitiva di numeri attivi; molte volte
le informazioni delle pagine web non sono aggiornate. Questo approccio riduce
in modo significativo lo spazio delle potenziali vittime di un attacco.
Ogni provider di rete mobile negli Stati
Uniti ha un sito web dal quale è possibile usufruire di vari servizi, tra i
quali anche inviare SMS. Se un messaggio viene inviato da tali interfacce,
solitamente, deve avere come destinatario un utente appartenente al medesimo
provider. In caso contrario il messaggio viene rigettato.
Figura 5: risposta negativa e positiva di un SMS inviato da (a) Verizon; (b) Cingular e (c) Sprint.
Un esempio di come un messaggio può essere
rifiutato dalle varie interfacce web è dato in Figura 5.
Le risposte positive e negative di una
interfaccia web posso essere usate per creare delle hit-list di numeri validi
per un dato dominio NPA/XXX: ogni risposta positiva all’invio di un SMS rileva
una potenziale vittima.
2.10
Scenari possibilie per un attacco DoS
Avendo trovato dei “colli di bottiglia” nella rete cellulare GSM e avendo trovato il
modo di creare una hit-list, è possibile ora compiere un attacco contro una
rete cellulare. Un avversario può inviare messaggi SMS simultaneamente da
differenti portali, immettendoli così nella rete mobile. Il risultato è quello
di saturare il canale di controllo CCH in modo da bloccare la comunicazione
vocale e di SMS. A seconda della grandezza dell’attacco è possibile coinvolgere
da piccole aree urbane ad interi continenti.
Nello specifico ci limitiamo a considerare i seguenti scenari:
· attacco ad un´area metropolitana;
· attacco ad uno Stato.
2.11 Attacco
in area metropolitana
Come visto in precedenza, la parte
riguardante il collegamento wireless della consegna di un SMS inizia quando il
dispositivo mobile destinatario “intercetta” il suo Temporary Mobile Subscriber ID (TMSI) sul Paging Channel (PCH). Il dispositivo mobile accetta la
richiesta attraverso il Random Access
Channell (RACH), quindi procede
con l’autenticazione e la consegna dei contenuti sul Standalone Dedicated Control Channel (SDCCH).
Il setup di una chiamata vocale è simile a
quanto accade per gli SMS, eccetto per il Traffic
Channel (TCH) che in questo caso
viene usato per il traffico voce e segnali di controllo. Il vantaggio di tale
approccio è che SMS e traffico voce non competono per aggiudicarsi i canali TCH.
In tal modo il canale TCH può essere ottimizzato per il numero massimo di
chiamate concorrenti che è possibile soddisfare. D’altro canto è da considerare
che il traffico voce e SMS usano gli stessi canali per stabilire la sessione,
ci sarà quindi una contesa di tali risorse. Dato un messaggio SMS, il canale
necessario per stabilire una sessione potrebbe essere saturo al fine di
preservare le chiamate vocali in una certa area [42, 16, 30, 50, 58, 15]. Per
determinare il numero di messaggi richiesto per indurre una saturazione, devono
essere esaminati i dettagli della interfaccia air.
L’interfaccia air di una rete GSM è un sistema timesharing (utenti allocati all’uso di una stessa risorsa la
condividono nel tempo). Questa tecnica è molto usata in vari sistemi al fine di
dare una equa distribuzione di risorse ai richiedenti. La tecnica usata dallo
standard GSM per realizzare questa condivisione è una combinazione tra Time Division Multiple Access e Frequency Division Multiple Access (rispettivamente
TDMA e FDMA). In definitiva avremo una suddivisione sia nel tempo che
nelle frequenze (Figura 6).
FDMA permette la suddivisione della banda in
124 frequenze distinte; una o più tra queste frequenze possono essere assegnate
ad una BS. Ognuna di queste frequenze è divisa, attraverso TDMA, in slot
temporali chiamati timeslot (Figura
6).
Figura 6: suddivisione TDMA e
FDMA dell’interfaccia air.
TDMA permette di suddividere il canale è in 8 timeslot, l’intero ottetto compone un frame. Durante un dato timeslot,
l’utente assegnato ha il pieno controllo del canale. Osservando il tutto da una
prospettiva telefonica, un utente assegnato ad un dato TCH è abilitato a
trasmettere traffico voce per ogni frame.
Per dare l’illusione di una continuità
nella trasmissione vocale, la lunghezza del frame è limitata a 4.615 ms. Una
idea di tale sistema la dà
Figura 7:
esempi di interfaccia air con 4 carrier (ognuno illustrato in un singolo
frame). Il primo timeslot di TRX1 è il CCH comune. Il secondo timeslot di TRX1
è riservato alla connessione SDCCH. In tal modo è allocata la capacità di 8
utenti. I timeslot rimanenti sono riservati ai dati voce. Questo tipo di setup
è solito apparire in una area urbana denominata settore.
In definitiva
lo standard GSM utilizza la tecnologia di
accesso a divisione di frequenza (FDMA) combinata con quella ad accesso
a divisione di tempo (TDMA): questo significa che, dopo aver diviso la
banda disponibile in un certo numero di canali radio (FDM), ogni canale viene
utilizzato da 8 (Full Rate) oppure 16 (Half Rate) utenti secondo
una tecnica a divisione di tempo (TDM).
Dato il singolo canale
radio (da 200 kHz), esso è utilizzato da 8 o 16 utenti
contemporaneamente, a ciascuno dei quali è assegnato uno slot temporale di
durata prefissata. Gli slot temporali sono talmente brevi e ravvicinati, che
l’utente non si accorge minimamente della temporizzazione, avendo cioè la “sensazione”
di essere l’unico ad usare quel dato canale.
Grazie al TDMA, è
possibile suddividere i canali come segue:
- canali di traffico: (cioè quelli dedicati alle conversazioni vere e
proprie) sono organizzati in base a gruppi di 26 frame (numerate da
- canali di controllo: (usati per l’instaurazione delle conversazioni) sono
organizzati in base a gruppi di 51
frame (numerate da
Sia l’insieme delle 26
trame di traffico sia quello delle 51 trame di controllo prendono il nome di multiframe
(Figura 8).
In tal modo è possibile abilitare, ad ogni
istante di tempo, otto utenti all’uso del SDCCH (Figura 8).
Figura 8: il
timeslot 1 da ogni frame di un multiframe crea 8 canali logici SDCCH. In un
singolo multiframe almeno 8 utenti possono avere un accesso SDCCH.
Alla fine otteniamo una serie di canali
logici mappati in un canale fisico. Un canale logico può essere adibito al
traffico (TCH) oppure al controllo (CCH). Per quanto riguarda il canale del
traffico TCH, è definito usando 26 frame di tipo multiframe. Di questi 26 frame
TDMA, 24 sono usati per il traffico, uno per il canale SDCCH e uno rimane non
utilizzato.
Ricordiamo che ogni canale
dell’interfaccia air ha
caratteristiche distinte.
Il canale PCH è usato per segnalare ogni chiamata in entrata e ogni messaggio
di testo, il suo compito in ogni sessione è limitato alla trasmissione di un
TMSI. Quindi è usato per funzioni di paging,
vale a dire avvisare le stazioni mobili connesse di qualche evento.
I canali TCH, invece, rimangono occupati per la durata della chiamata [56].
Il canale SDCCH, che approssimativamente ha la larghezza di banda del PCH su
un multiframe, è occupato per il periodo necessario (pochi secondi) al setup
della sessione; in alcuni scenari questo canale potrebbe diventare un collo di
bottiglia.
Volendo determinare i colli di bottiglia
di reti wireless, è necessario capire l’ampiezza di banda disponibile. Come
illustrato in Figura 8, ogni SDCCH è suddiviso in 4 timeslot logici consecutivi
in un multiframe. Considerando 184 bits per canale di controllo e un tempo di
ciclo di multiframe 235,36 ms, l’ampiezza
di banda effettiva è 782 bps [16]. Una volta stabilita la sessione, il TMSI
si rinnova, si abilita la cifratura, quindi è possibile inviare messaggi di
testo di 160 byte; un singolo SDCCH è solitamente memorizzato attraverso una
sessione di 4-5 secondi [56].
Il test di tipo “gray-box” effettuato in precedenza avvalora l’ipotesi di questo risultato:
si è potuto osservare che i messaggi non sono consegnati prima di 6 secondi.
Questa latenza fornisce la possibilità di
portare 900 sessioni di SMS per ora su ogni SDCCH. Nei sistemi reali il numero
totale di SDCCH disponibili in un settore è solitamente uguale al doppio del
numero dei carrier, oppure uno per
tre o quattro canali voce. Ad esempio in una area urbana, come indicato in Figura
7, dove sono presenti 4 carrier, sono allocati 8 SDCCH.
A noi interessa ora calcolare la capacità massima per una data area, di
gestire comunicazioni SDCCH. Come indicato negli studi condotti dal National Communications
System (NCS) [56], la città di Washington D.C. ha un totale di 120 settori. Assumendo che ogni settore ha 8
SDCCH (Figura 7), il numero totale di messaggi necessari per saturare la
capacità C di allocare nuovi SDCCH è:
La città di Manhattan copre un’area più
piccola. Assumendo la stessa distribuzione dei settori fatta per Washington
D.C., avremo 55 settori per Manhattan. Data la grande densità di popolazione
assumiamo 12 SDCCH per settore.
Quindi avremo che:
I centri messaggi SMSC nel 2000 erano
capaci di processare 2500 msg/sec [71], questo volume di traffico è plausibile
anche nell’ipotesi che un settore abbia il doppio del numero dei SDCCH.
Usando una sorgente di trasmissione via
Internet per l’invio di SMS, che prevede uno costo di upload pari a circa 1500
byte (per un singolo messaggio) come descritto in precedenza, è possibile ricavare
l’ampiezza di banda richiesta alla sorgente al fine di saturare i canali di
controllo. In tal modo si rende impossibile la comunicazione localmente
attraverso SMS, sia per Washington D.C. che per Manhattan.
Tabella 3: larghezza
di banda richiesta in upload per saturare una rete vuota.
L’ampiezza di banda richiesta ad un attaccante può
essere diminuita ulteriormente quando si
sceglie Verizon e Cingular Wireless come provider, considerando un singolo
messaggio ripetuto per 10 riceventi.
Come visto in precedenza il buffer dei telefoni mobili
si riempie con molta facilità. Quando tale buffer è riempito i messaggi sono
conservati in coda al centro messaggi sulla rete fino a quando lo spazio lì
riservato lo permette. Potenziando la capacità dei buffer si eviterebbe la
saturazione e attacchi di questo genere.
Usando dati demografici disponibili dal report tecnico
NCS TIB 03-2 [56] (572.059 persone con il 60% di copertura wireless e 8 SDCCH)
e supponendo che il 50% degli utenti di rete mobile siano utenti della stessa
rete, con un costante invio di circa 504 messaggi ad ogni telefono in un ora
(1 messaggio ogni 11,92 minuti), si arriverebbe a saturare la città di
Washington D.C.. In una città più densamente popolata come Manhattan, con una popolazione
di circa 1.318.000 abitanti, con il 60% copertura wireless e 12 SDCCH, potranno
essere ricevuti 1.502 messaggi per utente in un ora, se metà della clientela
wireless usa lo stesso provider. Questo numero arriva a 301 se il numero di
utenti wireless si ferma al 20%.
A seconda dell’intenzione che si ha durante l’attacco,
non è necessario creare una hit-list
molto ampia.
Assumendo che:
-
l’attaccante
abbia una hit-list con soli 2500 numeri di telefono;
-
le vittime
abbiamo un buffer di 50 messaggi;
-
l’attacco sia
lanciato in una città con 8 SDCCH (come Washington);
-
si usi una hit-list
in modo casuale;
allora sarà possibile inviare un singolo messaggio
ogni 10,4 secondi ad ogni singolo telefono e dopo poco più di 8 minuti saranno
saturati i buffer.
Come accade per la maggior parte dei worm in Internet, questo attacco sarà
completato prima che ci sia la possibilità di reagire.
Osservando bene
La maggior popolarità del servizio SMS ed altre
ragioni di business, hanno costretto i provider a trovare metodi nuovi per
incrementare la capacità degli SMS nelle loro reti. Un gran numero di industrie
[32, 44] offrono soluzioni riportando il traffico SMS dal tradizionale sistema
telefonico SS7 verso un sistema più economico, con una rete basata su indirizzi
IP e con una banda più ampia. I nuovi centri messaggio SMSC hanno una capacità
di processare 20.000 SMS al secondo, in tal modo viene velocemente soddisfatta
la domanda del mercato.
Inoltre nuovi servizi quali General Racket Radio Service (GPRS),
Enhanced Data rates for GSM Evolution
(EDGE), garantiscono una alta
velocità di connessione a Internet per i dispositivi mobili. L’uso di SMS con
contenuto multimediale non sostituirà di certo il classico messaggio testuale
SMS, quindi i centri messaggi SMSC non saranno alleviati dal solito regime di
lavoro; continueranno ad essere sempre un collo di bottiglia nel sistema. In
questo nuovo scenario, tutti gli aspetti di una rete di telefonia mobile, in
termini di consegna di SMS, sono incrementati, eccetto il collo di bottiglia
dovuto a SDCCH.
Ora esaminiamo un attacco all’infrastruttura di
telefonia cellulare degli Stati Uniti.
Dai dati del censimento del 2000, circa 92.505 mi² [69]
(1 mi=1.609344 Km) sono considerati urbani. Nel 2,62% del territorio abita l’80% della
popolazione.
Nel nostro primo modello assumiamo che tutte le aree
urbane nel paese abbiano settori ad alta capacità (8 SDCCH per settore). Questa
assunzione porta ai seguenti risultati:
Questo attacco richiede una grande banda di upload per
l’attaccante (nell’ordine di Gbps) e una hit-list che comprenda tutta la
nazione. Se l’attaccante è capace di inviare un singolo messaggio
contemporaneamente a più di 10 riceventi, allora il requisito della larghezza
della banda scende nell’ordine dei Mbps. Considerando che in precedenza un DoS
attack distribuito (DDoS) ha
paralizzato Yahoo con una larghezza di banda nell’ordine di Gigabit per
secondo, l’attacco proposto è realizzabile con l’ausilio di una “piccola” rete.
Non è un fatto nuovo che attraverso Internet si
possano portare attacchi mirati a domini specifici. Ad esempio, nel 2002,
anonimi inondarono un tale Alan Rasky, con migliaia di ordini via email in un
solo giorno. Attraverso un semplice script, i malintenzionati riuscirono ad
inviare ordini più velocemente del meccanismo deputato alla loro cancellazione.
In tal modo venne meno la possibilità del signor Rasky di poter ricevere
normali email, causa la saturazione del servizio.
Gli stessi attacchi possono essere portati al servizio
SMS. La completa distruzione di un servizio SMS è pericolosa, ma un attacco DoS
è molto plausibile. Per esempio un ex amante geloso, può sperare che un
messaggio non arrivi.
Questo tipo di attacco porta ad inondare l’utente con
un enorme mole di messaggi. Di conseguenza possono presentarsi tre situazioni:
- buffer overflow e
il messaggio è perso;
- il messaggio è
ritardato più del suo tempo massimo di vita, quindi il messaggio è perso;
- l’utente non
riceve il messaggio perché sommerso da messaggi privi di significato.
In ogni caso il messaggio è perso.
I dispositivi mobili, come già detto, hanno una
capacità di memorizzazione degli SMS (tra i 30-50 tipicamente) che ne limita la
ricezione. Inoltre i centri messaggi hanno una capacità limitata di memorizzare
messaggi relativi ad ogni utente (precedentemente è stata fatta una stima per
alcuni providers). Basta ciò a capire che la possibilità che un utente
malizioso possa distruggere i dati di un utente esiste ed è concreta.
Il centro messaggi SMSC non è l’unico luogo dove i
messaggi possono essere persi. Osservando il Nokia 3560, quando il buffer
diventa pieno, qualsiasi messaggio successivo viene cancellato. Questo modo di
operare è isolato al firmware di un certo telefono.
Nel test di attacco descritto in precedenza, dove
venivano immessi 400 SMS in un centro messaggi SMSC, la consegna di tutti i
messaggi inviati richiedeva circa 90 minuti (anche con il costante monitoraggio
e pulizia del buffer del telefono). In questo periodo il servizio messaggi
dell’utente era inutilizzabile, quindi messaggi inviati erano inevitabilmente
persi. Inoltre la ricezione di una mole enorme di messaggi incide anche sul
consumo della batteria. Questo potrebbe essere un altro obiettivo di un attacco
DoS.
In molti aspetti gli SMS sono simili alle email, se
usati correttamente entrambi sono utili ad un potenziamento della
comunicazione. Sfortunatamente gli SMS [66] hanno ereditato molti degli stessi
problemi, tra cui:
·
Spam;
· Phishing;
·
Virus.
Spam
Lo Spam [35]
ha piegato Internet per vari anni. La sua realizzazione è resa possibile da
caratteristiche quali:
-
anonimato;
-
automation;
-
costi bassi per
un attacco.
Tali caratteristiche permettono un profitto allo spammer (colui il quale effettua
l’attacco di Spam), anche se risponde
solo una piccola percentuale di coloro che ricevono il messaggio. Inoltre lo Spam congestiona la posta elettronica e
nel peggiore dei casi la blocca. Avendo già saturato le email, gli spammers
sono costantemente alla ricerca di nuove frontiere. Gli SMS sono una logica
conseguenza [23, 25] e purtroppo questa nuova frontiera è già in atto. Negli
anni scorsi sia in Europa che in Asia ci sono stati episodi di Spam fatto con SMS. Sfortunatamente
sforzi come CAN-SPAM (controlla l’assalto di
azioni pornografiche o commerciali non richieste) [58] non hanno mitigato il
problema.
Phishing
Il Phishing
[18, 22, 40, 41, 47] è un pericoloso abuso del servizio di email. Le forme
comuni di phishing includono email riguardanti aggiornamenti e notizie
provenienti da banche ed istituti finanziari.
Molti utenti di telefonia mobile autorizzano il
servizio di ricezione avvisi via SMS da parte del proprio provider per
notificare informazioni. Una volta che l’utente si è abituato a ricevere
informazioni di scarsa o media importanza tramite cellulare, è facile pensare
che possa sottoscrivere anche servizi che richiedono la gestione e la ricezione
di informazioni più riservate, quindi esporsi a pericoli maggiori. Ad esempio
il controllo via telefono cellulare del proprio saldo bancario, con il rischio
di inserire i propri dati di accesso.
Figura 9: lo
spoofing della notifica di un
messaggio banale: l’immagine di sinistra rappresenta una falsificazione del
messaggio originale presente sulla destra.
Virus
L’esigenza di avere nel telefono cellulare un
dispositivo “all-purpose”, ha reso gli apparecchi di telefonia mobile più
vulnerabili. A tale proposito gli SMS diventano veicolo di infezione, capaci di
trasportare virus sulle varie piattaforme, come già accaduto con Cabir [37] e
Skulls [39], entrambi trasmessi via Bluetooth.
Questa vulnerabilità ha dato modo alle compagnie che
sviluppano antivirus di porre in essere soluzioni come F-Secure, al fine di
scongiurare danni al proprio apparecchio mobile [36]. F-Secure usa SMS per
distribuire la definizione dei virus e aggiornarne la lista [36]. Sfortunatamente
questo mezzo nato per la salvaguardia dei dispositivi mobili viene anche
sfruttato per propagare gli stessi virus. Infatti Mabir [38], una variante di
Cabir, ha già sfruttato questa strada. La propagazione di Mabir, sfruttando SMS
e MMS, non è limitata solo al canale Bluetooth.
Alcuni meccanismi che tuttora sono usati non
permettono una adeguata protezione della rete. Basta osservare le
considerazioni fatte in precedenza per capire che la rete oggi presenta punti
critici che permettono attacchi in modo abbastanza semplice [21]. Una limitazione d’uso degli SMS potrebbe
essere una soluzione. Tale scenario pare improponibile vista la crescita del
servizio di SMS e l’orientamento alle open-functionality che i provider hanno. Ogni
possibile soluzione a tale problema, deve necessariamente tener conto di queste
esigenze di mercato e sociali, oramai radicate nell’uso della telefonia mobile.
· separazione traffico voce e dati;
· aumento delle risorse;
· limitazione della velocità.
Separazione
di traffico voce e dati
Un modo intuitivo per eliminare la possibilità degli
attacchi prima citati è quello di separare il traffico voce e quello degli SMS.
In tal modo l’invio di dati su un apparecchio mobile non porterebbe alcun
degrado della comunicazione vocale. Dedicando un trasporto sulla interfaccia air per i segnali di controllo relativi
ai dati, si elimina la possibilità di bloccare le chiamate vocali saturando i
buffer con l’invio di SMS. Prendendo in considerazione l’ipotesi di canali dati
dedicati, si ha comunque un uso inefficiente dell’interfaccia. Separando il
traffico dei messaggi di testo su indirizzi IP o su link dedicati SS7, non
previene un attacco di overload. Una parziale separazione è già avvenuta con
l’introduzioni dei servizi dati GPRS e EDGE; tuttavia le reti rimangono
vulnerabili fino a quando esisteranno gli SMS via Internet.
La separazione del traffico voce da quello dati non è
abbastanza per rendere l’infrastruttura delle reti wireless sicura. In
situazioni simili a quelle del 11 settembre 2001, dove il traffico voce era
saturato, i messaggi di testo inviati da Internet potevano essere usati per
riempire i canali dati come se fossero SMS inviati normalmente. Il traffico SMS
potrebbe essere classificato a seconda della sua origine. I messaggi di testo
originati fuori dalla rete devono avere una bassa priorità nei canali dati. I
messaggi che si originano con i dispositivi mobili devono avere una alta
priorità. Questa soluzione comporta che SMSC sia sufficientemente protetto da
attacchi al fine che la sua funzionalità non sia mai compromessa. Se questa
aspettativa non fosse mantenuta, allora bisognerebbe cercare soluzioni più
onerose distribuite sulle reti SS7.
Aumento
delle risorse
Molti provider hanno avuto esperienza di dover tener
fronte ad aumenti temporanei del normale traffico. Ad esempio la compagnia
greca COSMOTE, responsabile del servizio delle telecomunicazioni per le Olimpiadi
di Atene
L’effetto di un attacco da Internet fatto con SMS può
essere ridotto incrementando la capacità di smaltire messaggi in zone critiche
o per eventi eccezionali. Sfortunatamente il costo di questo aumento di risorse
è molto elevato. Inoltre tale strategia pone un attacco DoS poco probabile ma
non impossibile.
Limitazione
della velocità
A causa del tempo e del denaro utile per realizzare le
soluzioni citate prima, è necessario trovare una terza via che possa dare
maggior sicurezza alla rete cellulare. A tale proposito osserviamo le tecniche
messe a punto per limitare la velocità degli SMS.
Nella interfaccia air,
il numero di canali SDCCH autorizzati alla consegna di messaggi di testo SMS
può essere ristretto. Dando al traffico vocale un peso maggiore, gli attacchi
descritti colpirebbero pochi individui sulla rete e non la totalità. In questo
tipo di approccio è rallentata la velocità di consegna dei messaggi. Di fatto
aumenterebbe la congestione nel cuore della rete telefonica, essendo i messaggi
costretti a “rallentare” durante il loro percorso. Questo approccio non si
presenta come una soluzione adeguata.
Poiché gli attacchi visti si basano su hit-list,
potrebbe essere una buona idea impedire la creazione di queste. Nello specifico
tutte le interfacce web dedite all’invio di messaggi potrebbero no dare
indicazioni positive o negative in relazione all’invio di SMS (come descritto
in precedenza è un modo per costruire le hit-list). Un simile approccio
ridurrebbe l’affidabilità dei messaggi generati da internet facendo perdere
interesse negli utenti.
Ridurre la capacità di inviare automaticamente fino a
10 messaggi (come molte interfacce tipo Verizon già fanno) potrebbe essere
considerata una soluzione temporanea. In questo modo aumenterebbe oltre dieci
volte la capacità di upload necessaria ad un attaccante per inondare la rete [20,
75].
L’ultima soluzione, ultima anche come popolarità, è
quella di chiudere l’interazione tra Internet e le reti di telefonia cellulare.
Le reti cellulari sono una componente critica delle
infrastrutture economiche e sociali delle quali sono parte. Tuttavia il
proliferare di servizi esterni a tali reti, espone questa tecnologia ad un uso
malizioso dei servizi disponibili. Si è dimostrato che l’introduzione di messaggi
generati da Internet può causare seri danni in aree metropolitane, usando delle
hit-list contenenti circa 2500 potenziali vittime.
Il traffico vocale mobile e quello degli SMS è
divenuto indispensabile per un numero sempre più crescente di persone nel
mondo. Pensare di arrestare l’uso di SMS e la divulgazione di questi via
Internet è impossibile, sia per ragioni sociali che commerciali; produrre
sforzi volti a proteggere tali comunicazioni è plausibile.
Letture:
-
Guillaume Peersman and Srba Cvetkovic, The
-
CCS’05, November
7–11, 2005, Alexandria, Virginia, USA. Copyright 2005 ACM
1595932267/05/0011.
Note:
[1] ETSI GSM 03.41, Digital Cellular Telecommunication System (Phase 2);
[2] ETSI GSM 03.40, Digital Cellular Telecommunications System (Phase
2+)
[3] J. Scourias, A Brief Overview of GSM,
[4] M. Mouly and M. Pautet, “The GSM System for
[5] W. Roth, Data Service on the GSM Platform, GSM Summit Hong Kong, Mar. 1993.
[6] ISO/IEC10646, Universal Multiple Octet Coded Character Set (USC), UCS2, 16 Bit Coding.
[7] ETSI GSM 03.38, Digital Cellular Telecommunications System (Phase
2+): Alphabets and
language-specific information, v. 5.2, May. 1996.
[8] GSM Worls, Mobile terms and acronyms, http://www.gsmworld.com/technology/glossary.shtml#s
[9] CCITT E.164, Numbering Plan of the International Telephone Service,
[10] GSM 07.05, Digital Cellular Telecommunications System (Phase 2); Use of Data Terminal
Equipment — Data Circuit terminating; Equipment
[11] SEMA Group Telecommunications, SMS2000 v. 4.0, Open Interface
[12] Telocator Alphanumeric Protocol (PCIA) v. 1.2 Functional Spec for
TAPAIM
[13] Denial of service attacks. Technical report,
http://www.cert.org/tech_tips/denial_of_service.html.
[14]
[15] Record calls, text again expected for nye,
http://www.itnews.com.au/newsstory.aspx?CIaNID=17434,
December 31, 2004.
[16] 3rd Generation Partnership Project. Physical layer on the radio
path; general
[17] 3rd Generation Partnership Project. Technical realization of the
short message
[18] Anti-Phishing Working Group. Reports of email fraud and phishing
attacks
[19] A. Arpaci-Dusseau and R. Arpaci-Dusseau. Information and control in
[20] T. Aura, P. Nikander, and J. Leiwo. Dos-resistant authentication
with client
[21] S. Bellovin. Security problems in the TCP/IP protocol suite.
Computer
[22] S. Bellovin. Inside risks: Spamming, phishing, authentication, and
privacy.
[23] S. Berg, A. Taylor, and R. Harper. Mobile phones for the next
generation:
[24] S. Buckingham. What is GPRS?
http://www.gsmworld.com/technology/gprs/intro.shtml#5, 2000.
[25] J. V. D. Bulck. Text messaging as a cause of sleep interruption in
adolescents,
[26] N. Burnett, J. Bent, A. Arpaci-Dusseau, and R. Arpaci-Dusseau.
Exploiting
[27] S. Byers, A. Rubin, and D. Kormann. Defending against an
internet-based
[28] Cellular Online.
[29] CERT. Advisory CA-1996-26 ’denial-of-service attack via ping’, http://www.cert.org/advisories/CA-1996-26.html,
December 1996.
[30]A. Choong. Wireless watch: Jammed A. Choong. Wireless watch: Jammed,
http://asia.cnet.com/reviews/handphones/wirelesswatch/0,39020107,39186280,00.htm, September 7, 2004.
[31] Cingular Wireless. Text messaging, http://www.cingular.com/media/text_messaging.
[32] Cisco Systems Whitepaper. A study in mobile messaging: The evolution of messaging in mobile networks, and how to efficiently and effectively manage the growing messaging traffic. Technical report, 2004,
http://www.cisco.com/en/US/netsol/ns341/ns396/ns177/networking_solutions_white_paper09186a008020e2a8.shtml.
[33] Computer Associates. Carko.
http://www3.ca.com/securityadvisor/pest/pest.aspx?id=453075555.
[34] COSMOTE Whitepaper. COSMOTE and the ’Athens
http://www.cosmote.gr/content/en/attached_files/investorrelations/COSMOTE_annualreport2004.pdf.
[35] L. Cranor and B. LaMacchia. Spam! Communications of the ACM,
[36] F-Secure Corporation. F-Secure mobile anti-virus.
http://www.f-secure.com/products/fsmav.html.
[37] F-Secure Corporation. F-Secure virus descriptions : Cabir.h.
[38] F-Secure Corporation. F-Secure virus descriptions : Mabir.a.
[39] F-Secure Corporation. F-Secure virus descriptions : Skulls.a.
[40] E. Felten, D. Balfanz, D. Dean, and D. Wallach. Web spoofing: An
internet
[41] G. Goth. Phishing attacks rising, but dollars losses down. IEEE
Security and
[42] M. Grenville. Operators: Celebration messages overload sms network.
http://www.160characters.org/news.php?action=view&nid=819,
November 2003.
[43] K. Houle and G. Weaver. Trends in denial of service attack
technology.
[44] Intel Whitepaper. SMS messaging in SS7 networks: Optimizing revenue
with
[45] J. Ioannidis and S. Bellovin. Implementing pushback: Router-based
defense
[46] S. Kasera, J. Pinheiro, C. L. M. Karaul, A. Hari, and T. L. Porta.
Fast and
[47] E. Levy. Interface illusions. IEEE Security & Privacy Magazine,
2(6):66–69,
[48] G. Lorenz, T. Moore, G. Manes, J. Hale, and S. Shenoi. Securing ss7
[49] S. Makris. Athens 2004 games: The ”extreme makeover” olympics!,
April
[50] S. Marwaha. Will success spoil sms? http://telephonyonline.com/wireless/mag/wireless_success_spoil_sms/, March 15, 2001.
[51] J. Mirkovic and P. Reiher. A taxonomy of DDoS attacks and DDoS
defense
[52] D. Moore, V. Paxson, S. Savage, C. Shannon, S. Staniford, and N.
Weaver.
[53] T. Moore, T. Kosloff, J. Keller, G. Manes, and S. Shenoi.
Signalling system 7
[54] G. Mori and J. Malik. Recognizing objects in adversarial clutter:
Breaking a
[55] M. Naor. Verification of human in the loop or identification via
the turing test.
http://www.wisdom.weizmann.ac.il/%7Enaor/PAPERS/human.pdf,
1996.
[56] National Communications System. SMS over SS7. Technical Report
Technical
[57] Nextel. Text messaging. http://www.nextel.com/en/services/messaging/text_messaging.shtml.
[58] J. Pearce. Mobile firms gear up for new years text-fest.
[59] H. Project. The honeynet project. http://project.honeynet.org,
2005.
[60] RedTeam. o2
[61] P. Roberts. Nokia phones
vulnerable to dos attack. http://portal.acm.org/citation.cfm?id=1102171&dl=GUIDE&coll=GUIDEl, February 26, 2003.
[62] S. Savage, D. Wetherall, A. Karlin, and T. Anderson. Practical
network
[63] C. Schuba,
[64] G. Shannon. Security vulnerabilities in protocols. In Proceedings
of ITU-T
[65] S. Staniford, V. Paxson, and N. Weaver. How to 0wn the internet in
your spare
[66] J. Swartz. Cellphones now richer targets for viruses, spam, scams.
http://knowledgemanagement.ittoolbox.com/news/display.asp?i=128846,
April 28, 2005.
[67] Telecommunication Industry Association/Electronic Industries Association
[68] Tom’s Hardware. How to: Building a bluesniper rifle.
[69]
[70]
[71] S. van Zanen. Sms: Can networks handle the explosive growth?
http://www.wirelessdevnet.com/channels/sms/features/smsnetworks.html,
2000.
[72] Verizon Wireless. About the service. https://www.vtext.com/customer_site/jsp/aboutservice.jsp.
[73] L. von Ahn, M. Blum, N. Hopper, and J. Langford. CAPTCHA: Using
hard AI
[74] B. Waters, A. Juels, J. Halderman, and E. Felten. New client puzzle
Letture
addizionali:
-
M. Rahnema, Overview of the GSM System and Protocol
Architecture, IEEE Commun. Mag., vol. 3, no. 4, Apr. 1993, pp. 92–100.