[Soci SLIP] Il rapporto Juniper [Era: spaventosa situazione con android]

[Lucio Crusca]

In data domenica 22 maggio 2011 17:25:22, loredana ha scritto:
> > Come dire, "noi l'abbiamo provato su Android, ma il problema non è di 
> > Android, è di Google e delle applicazioni che usano i servizi Google in
> > generale". Cioè quello che io sto dicendo fin dall'inizio.
> 
> Difatti, se avessi aggiunto "come diceva Lucio", Lucio se ne sarebbe
> forse accontentato e non avrebbe di nuovo ribadito il concetto :) 

:) lo ribatto solo perché continui a dire che è un problema specifico di 
Android! Ok va bene, non serve che cerchi di spiegarmelo di nuovo, ho capito 
il tuo punto di vista molti messaggi fa, solo che non lo condivido.

> > Scusami se ti correggo di nuovo su questo aspetto, ma il problema del
> > ClientLogin NON porta ad un attacco MITM:
>
> Scusato, ma faccio fatica a capire di quale correzione si tratti.
>
> "Volevamo sapere se fosse davvero possibile lanciare un impersonation
> attack (significa che qualcuno si mette in mezzo ad una comunicazione
> tra due, impersonificando l'una o l'altra parte, altrimenti detto
> man-in-the-middle attack, n.d.r.) 

La correzione è proprio qui, dove hai aggiunto del tuo alla traduzione ed hai 
dato per scontate delle cose sbagliate. Un impersonation attack non è 
altrimenti detto MITM. Sono due cose diverse. Nel MITM, l'utente sta usando un 
servizio ed in mezzo c'è il terzo uomo che agisce in diretta, di nascosto e 
modifica i pacchetti in transito. Un'impersonation attack è invece un furto 
d'identità e l'identità rubata viene usata in differita. In realtà sono 
dettagli poco rilevanti dal punto di vista della nostra disquisizione, ma li 
segnalo solo perché così diamo informazioni corrette.

> Qui sotto, invece, si descrive come sia possibile attaccare i telefoni
> android.
> 
> To collect such authTokens on a large scale an adversary could setup a
> wifi access point with a common SSID of an unencrypted wireless network,
> e.g., T-Mobile, attwifi, starbucks. With default settings, Android
> phones automatically connect to a previously known network and many apps
> will attempt syncing immediately. 
> 
> "Per collezionare tokens di autenticazione su larga scala, un avversario
> potrebbe metter su' un access point wifi con un SSID (nome della rete,
> n.d.r.) comune di una rete wireless non crittografata, per esempio
> T-mobile, attwifi, startbucks (comuni negli stati uniti, n.d.r.). Con i
> parametri di default, i telefoni android si connettono automaticamente
> ad una rete registrata in precedenza e molte applicazioni si
> sincronizzano immediatamente.

Sì questa parte preferivo non citarla, perché denota ancora una volta la 
scarsa preparazione del team di ricercatori, su cui non volevo infierire 
ulteriormente. Un qualsiasi dispositivo (Android o meno, ma parliamo pure di 
Android che ci sta tanto a cuore al momento) non usa solo il nome della rete 
(SSID) per decidere che la rete è conosciuta e che quindi può connettersi, ma 
usa anche il BSSID, che poi sarebbe il mac address del router. Conseguenza? Se 
metti su un access point con SSID = "T-Mobile" Android non si connetterà 
affatto in modo automatico, ma sarà l'utente che dovrà selezionare la rete (e 
c'è scritto che è una rete non protetta) e connettersi. Quindi questo modo di 
raccogliere tokens fallirebbe miseramente.

> Lucio non mi ha risposto, ma com'e la rete del Veloce? 

Non ho risposto perché lo sai anche tu, è aperta. 

> Magari viene
> usata per "rubarvi" i token per i servizi google :) Scherzo, ma immagino
> che sia perfettamente fattibile, se e' aperta.

Esatto, è possibile (poi ovviamente non succede). La cosa da capire è che ciò 
è possibile anche se vi connettete a quella rete con un normale notebook 
invece che con un dispositivo Android (ah già, non dovevo più ribatterlo...).

> 
> > No, non esiste alcuna libreria per Android o per altri sistemi che
> > implementi ClientLogin.
> 
> Qui c'e la loro documentazione:
> 
>   http://code.google.com/apis/accounts/docs/AuthForInstalledApps.html

E quindi? Quella è la documentazione, non una libreria.

> > Sì il kill switch è una porcheria, sono d'accordo
> 
> Ed e' una funzione di android? A che livello e' implementata?

A livello di applicazione Market. Se stai senza market, non c'è più il kill 
switch.

> Si puo' davvero pensare che l'utente possa mai disabilitarla?

Per ora solo rinunciando al Market.

> Ed essere sicura che sia stata davvero disabilitata? Come?

Come dicevo manca ad oggi un'opzione semplice che permetta all'utente di 
disabilitare il kill switch a suo rischio e pericolo ed è ciò che auspico che 
Google aggiunga al più presto, ma temo che non accadrà.

> 
> > Prima che tu mi dica "allora vedi che esistono i virus per Android?",
> > ricordo che i trojan non sono dei virus,
> 
> E io ti ricordo che li ho chiamati trojan e che so la differenza tra
> virus e trojan, questi ultimi essendo piu' pericolosi dei virus e piu'
> difficilmente rilevabili o rimuovibili. 

In realtà è esattamente il contrario. I trojan sono meno pericolosi perché 
così come il cavallo di troia storico, richiedono la collaborazione della 
vittima per installarsi.

> E' bene che la sappiano tutti,
> anche solo a livello molto generico: 
> un virus si autoriproduce e
> propaga, un trojan e' come il cavallo di troia, non si propoga, 

Ok fin qua 

> penetra
> all'interno e agisce dal di dentro. 

Questo lo fa anche il virus, ragione per cui è più pericoloso del trojan: 
distruttivo allo stesso modo e non ha bisogno della collaborazione della 
vittima per installarsi in quanto si riproduce da solo.

> Quali che siano le sue intenzioni,
> il fatto e' che e' a casa vostra, oltre la porta e al di qua delle mura,
> a far quel che vuole, con privilegi di amministratore.

Anche qui, esattamente come i vìrus. Solo che il trojan, non riproducendosi e 
necessitando della collaborazione dell'utente per installarsi, è più facile da 
rimuovere.

> > No non fatelo, o almeno prima di farlo assicuratevi che ne abbiate
> > l'autorizzazione (in base alle osservazioni sopra, secondo me non ce
> > l'avete). Se bisogna registrarsi per vederlo probabilmente significa che
> > non si è autorizzati a divulgarlo a proprio piacimento.
> 
> Penso che significhi solo dare il vostro email e quelli vi romperanno
> per un po'. Ne' piu' ne' meno di quel che fanno praticamente tutti.
> Abbastanza, per me, per trattenermi dalla curiosita' di leggere il
> rapporto. Che pero' accetto, se arriva da qualche altra parte e non
> devo violare il copyright nel leggerlo e commentarlo :)

Guarda, io invece non ho resistito, mi sono registrato ed ora ho il rapporto 
Juniper in formato PDF qui sul mio hard disk.... non credo di essere 
autorizzato ad inoltrarlo, perché non viene fatto accettare alcun accordo di 
licenza che parli del diritto di divulgazione, da cui quel diritto resta 
all'autore e basta. Credo però di poter dire una cosa: quella frase riportata 
dal simpaticissimo giornalista, proprio quella relativa agli "SMS Trojan" che 
mandano messaggi a "premium rate numbers", c'è veramente nel rapporto, a 
pagina 4. Peccato solo che in quel paragrafo il rapporto stesse parlando di... 
indovina un po? Windows Mobile!

ROTFL! :D :D :D era un pezzo che non ridevo così di gusto!

> Io lo trovo allucinante. I certificati, che per buona norma dovrebbero
> essere autenticati da una certification authority, vengono invece usati
> solo per distinguere un autore dall'altro. Piu' diseducativo di cosi'
> non so cosa si possa inventare. Cosi' se c'era ancora un utente in giro
> e un browser configurato come si deve per avvertire che ci si trovava di
> fronte a qualcosa di potenzialmente insicuro e da verificare,
> quell'ultimo saggio ce lo perdiamo. E adesso non mi dire che questo e'
> necessario per il bene dell'open source. Ci sono altre vie, senza
> togliere significato ai certificati di sicurezza.

Con tutto l'impegno, non capisco di cosa stai parlando.

> Il kernel fornisce una sandbox per ogni applicazione. Le applicazioni
> sono percio' isolate l'una dall'altra e comunicano/usano i dati
> attraverso un meccanismo di permessi. E' l'utente, immaginatevi
> l'utente, che non sa quello che succede, a dare i permessi ad
> un'applicazione per usare i dati delle altre, una volta per tutte, nel
> momento in cui la installa (cioe', nel momento in cui clicca, immagino).
> Per comodita', ovviamente. Vi viene in mente niente? Bello. Per me
> android ha chiuso. Adesso saprei anche dire esattamente perche',
> anziche' tirar fuori il solito approccio minimalista e l'intuito
> femminile :)

E cosa vorresti che facesse altrimenti? È già molto di più di quello che fa 
Ubuntu Software Center (o anche solo apt), che ti chiede solo la password, la 
quale vale come autorizzazione a fare qualsiasi cosa senza limitazioni per 
l'applicazione che stai installando. Il fatto che il malware per Linux ancora 
non si veda sul desktop, è solo dovuto al fatto che Linux sul desktop ha una 
fetta della torta troppo piccola perché ne valga la pena. Nel caso di Android 
invece la fetta è più grande, ergo il malware (ma non ha nulla a che vedere 
con il problema del ClientLogin). Come dicevo nell'articolo sul vecchio wiki, 
è solo questione di tempo, ma dal punto di vista architetturale, Android è 
ancora più attento di apt alla sicurezza, perché ti elenca le singole 
autorizzazioni che stai concedendo all'applicazione che stai per installare.

> Non credo di confondermi ma, se e' cosi', correggi. "backdoor" significa
> porta sul retro aperta, attraverso cui google o un trojan fanno passare
> tutto il traffico che vogliono. 

Non proprio. La backdoor è installata dal Google Market ed è aperta solo per 
Google. Nessun malware può installarsi a tua insaputa attraverso quella 
backdoor a meno che non venga prima craccato il server di Google su cui c'è il 
Market.

> Google poi lo potra' usare solo in
> termini di contratto, ma per rimuovere applicazioni a mia insaputa dal
> mio dispositivo ammetterai anche tu che, se non bussa a me, deve avere
> una porta aperta o di cui ha la chiave. O android gli apre senza
> chiedermi. O come fa?

L'applicazione Market va periodicamente a chiedere a Google se sia ora di 
installare o rimuovere qualcosa senza notificare l'utente. Se Google risponde 
"sì, installa/rimuovi questo" l'applicazione Market lo fa.

> Certo, gli altri son cattivi e google no, le applicazioni degli altri
> sono trojans e android e' trojan solo per il mio bene e immune dai
> trojan cattivi davvero ... Mai ci sara' un virus che sfrutta questo
> meccanismo che trova li' bell'e' pronto ... Ma insomma, per piacere...
> Una porta in rete aperta in INGRESSO, cioe' non aperta a
> seguito di una richiesta che venga da me (e anche questo certo non basta
> a proteggermi), ma quando fa piacere a qualcuno entrare sul mio
> dispositivo non importa se se la apra google o microsoft, e' un problema
> enorme di privacy E DI SICUREZZA. 

Certo. Se solo ci fosse l'opzione di chiuderla semplicemente a rischio e 
pericolo dell'utente tutto il problema non esisterebbe.

> Vuol dire come minimo che TUTTI i
> dispositivi android sono vulnerabili, certamente almeno da google. 

Vero.

> Direi che e' soprattutto giusto saperle, in qualche forma.
> 
> Senza la versione "scorretta" del famigerato giornalista non ne avrei
> saputo niente da te, e forse non ne sapevi niente neppure te :) Cosi'
> invece la discussione e' stata utile, credo, non solo a moi due.

Non saprei. Per me, te ed altri tecnici la discussione è certamente stata 
utile. Credo però che i semplici curiosi (se mai sono arrivati a leggerci fino 
a qui) abbiano solo le idee più confuse di prima.

> Scusa se lo sottolineo con te, non e' affatto personale, vale per me e
> per tutti. Troppe volte si pensa di saper come stanno le cose, o si
> delega ad altri il fatto di accertarle: due facce della stessa medaglia,
> entrambe basate su presupposti sbagliati. Ce ne deve essere una terza.

Certo che c'è: fra Google che fa il finto filantropo con il kill switch ed Apple 
che fa il despota come al solito, possiamo sempre scegliere Windows Mobile! :D