[Soci SLIP] spaventosa situazione con android

[loredana]

On Sun, 2011-05-22 at 13:05 +0200, Lucio Crusca wrote:
> In data sabato 21 maggio 2011 13:33:00, loredana ha scritto:
> > 
> > Qui c'e' invece il rapporto dei ricercatori dell'universita' di Ulm, che
> > hanno fatto un ottimo lavoro ed un ottimo servizio, sia a google che ai
> > suoi "clienti":
> > 
> > http://www.uni-ulm.de/en/in/mi/staff/koenings/catching-authtokens.html
> 
> Prendo direttamente da lì:
> 
> "The fix does not require an update of the Android OS"
[..]
> 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 :) Ma
leggi sotto, dove riporto per intero la descrizione dell'attacco dal
sito dell'universita', e vedrai che non ha poi proprio tutti i torti chi
lo riferisce ai dispositivi mobili android. 

> Ma tu guarda, Juniper è un inserzionista di eWeek... sarà un caso?
> http://justmedia.com/blog/category/eweek/

No, magari no. Ma adesso tocca a me ribadire il concetto: a furia di
limitarsi a scoprire le eventuali magagne, a prendersela con questo o
con quello, a dimostrare quanto e' cattivo chi mi attacca, si perde la
possibilita' di approfittare in pieno della funzione "critica", che
nessuno come il tuo peggior nemico sa esercitare come si deve. E di cui
gli si dovrebbe esser infinitamente grati perche' lo fa "contro", ma suo
malgrado ti sta facendo un gran favore. La cura e' tanto piu efficace
quanto piu' ci si corregge in tempo. Tant'e' vero che chi continua a
ritenere che il cattivo sia sempre l'altro, prima o poi perde contatto
con la realta' e si disintegra (lo fanno letteralmente quelli che si fan
saltare in aria, per esempio, e anche interi stati) o sparisce (e qui vi
risparmio i dolorosi nonche' numerosi esempi).

> Che significa che lo studio di Juniper, oltre a non specificare il 400% di quale 
> numero ed oltre ad essere uno studio non divulgato, è probabilmente stato 
> finanziato da Microsoft... storia già vista, solo che al tempo al posto di 
> Juniper c'era il Gartner Group...

Si', anch'io detesto le percentuali senza sapere di che. Pero', in
alcuni casi, servono solo a segnalare un trend, cioe' sono davvero
informazioni di natura relativa. Non c'e' nessuna ragione di assumere
che il trend continui, a meno che il problema non sia preso nella dovuta
considerazione. Ignorarlo e' invece cattiva strategia.

> > Fra le altre cose, spiega in maniera molto semplice in cosa consista
> > l'attacco e quali rimedi siano stati suggeriti sia a google che a chi
> > usa i servizi di google. Questo vale solo per il problema specifico
> > della cattura dei tokesn e l'impersonificazione
> > (man-in-the-middle-attack)
> 
> 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.

Ti riporto la spiegazione che a me sembra molto chiara e non troppo 
tecnica dal sito dell'universita' di Ulm, cosi' forse si capisce a cosa
ci si riferisce con clientlogin, man-in-the-middle-attack, perche'
android etc. Da:

 http://www.uni-ulm.de/en/in/mi/staff/koenings/catching-authtokens.html

We wanted to know if it is really possible to launch an impersonation
attack against Google services and started our own analysis. The short
answer is: Yes, it is possible, and it is quite easy to do so. Further,
the attack is not limited to Google Calendar and Contacts, but is
theoretically feasible with all Google services using the ClientLogin
authentication protocol for access to its data APIs.

"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.) contro i servizi google e abbiamo
iniziato la nostra analisi. La risposta veloce e': si', e' possibile ed
e' anche molto semplice farlo. Inoltre, l'attacco non e' solo relativo
al calendario google e ai contatti, ma e' teoricamente possibile con
tutti i servizi google che usano il clientlogin autentication protocol
per accedere alle sue API (application programming interfaces). 

Clientlogin     
is meant to be used for authentication by installed applications and
Android apps. Basically, to use ClientLogin, an application needs to
request an authentication token (authToken) from the Google service by
passing an account name and password via a https connection. The
returned authToken can be used for any subsequent request to the service
API and is valid for a maximum duration of 2 weeks. However, if this
authToken is used in requests send over unencrypted http, an adversary
can easily sniff the authToken (e.g. with Wireshark, see screenshot
below). Because the authToken is not bound to any session or device
specific information the adversary  can subsequently use the captured
authToken to access any personal data which is made available through
the service API. 

"Clientlogin e' il meccanismo usato per l'autenticazione dalle
applicazioni installate e dalle applicazioni android. In pratica, per
usare clientlogin, un'applicazione deve richiedere un gettone di
autenticazione (authtoken)  al servizio google e lo fa mandando un nome
di account ed una password attraverso una connessione https. Il token
restituito puo' essere usato per ogni richiesta seguente al servizio ed
e' valido per un massimo di 14 giorni. Tuttavia, se questo token e'
usato in richieste spedite attraverso una connessione http non
crittografata, un avversario puo' facilmente "sniffare" il token di
autenticazione (per esempio, con wireshark). Siccome il token non e'
legato ad una sessione o ad alcuna informazione specifica del
dispositivo che lo ha richiesto, l'avversario che se ne e' impossessato
puo' usarlo per accedere ad ogni dato personale che e' disponibile
tramite il servizio che ha rilasciato il token." 

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. While syncing would fail (unless the
adversary forwards the requests), the adversary would capture authTokens
for each service that attempted syncing. Due to the long lifetime of
authTokens, the adversary can comfortably capture a large number of
tokens and make use of them later on from a different location.

"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. Anche se la sincronizzazione fallisce (a
meno che l'avversario, quello che si e' interposto, mandi avanti la
richiesta) l'avversario puo' catturare il token di ogni applicazione che
cerchi di sincronizzarsi. Grazie alla lunga vita (14 giorni) dei token
di autenticazione, l'avversario puo' comodamente catturare un gran
numero di token e far uso di essi piu' tardi da una locazione diversa
(da cui l'impersonificazione, n.d.r.)."

Lucio non mi ha risposto, ma com'e la rete del Veloce? Magari viene
usata per "rubarvi" i token per i servizi google :) Scherzo, ma immagino
che sia perfettamente fattibile, se e' aperta.

> 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

> È semplicemente una chiamata HTTP o HTTPS. 

Un po' di piu', se si gestiscono gli errori. Dal punto di vista
dell'utente, di fatto permette di inserire login e password una sola
volta per tutte le richieste successive al servizio. Molto comodo, ma
vuol dire autenticarsi una sola volta in 14 giorni, nel nostro caso, con
quel che a quella comodita' consegue.

> Sì il kill switch è una porcheria, sono d'accordo

Ed e' una funzione di android? A che livello e' implementata?
Si puo' davvero pensare che l'utente possa mai disabilitarla?
Ed essere sicura che sia stata davvero disabilitata? Come?

> 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. 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, penetra
all'interno e agisce dal di dentro. 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.

> se solo l'utente facesse la fatica di leggere i commenti lasciati dagli altri 
> o di scaricare solo programmi di cui ha letto prima una recensione da qualche 
> parte il problema non esisterebbe.

Se fosse cosi' semplice, non ci sarebbe stato il problema enorme della
sicurezza con sistemi microsoft. Apple lo risolve con il controllo a
priori, google con la rimozione dal tuo dispositivo (ci pensa mamma
google), le distribuzioni serie con gli aggiornamenti automatici per la
sicurezza e cercando di creare consapovelezza (che e' l'opposto di cosa
fa chi ha paura di perdere fette di mercato "confessando" il buco e deve
percio' rassicurare a tutti i costi i suoi utenti che, peraltro, non
chiedono di meglio che credere alla cieca, perche' un'alternativa non ce
l'hanno). 

> 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 :)

> > Sembra che si sia trattato di un rootkit che
> > ha infettato piu' di 50 applicazioni prima che qualcuno se ne
> > accorgesse. 
> 
> Questo dato non l'ho trovato. MI sembrava anzi che DroidDream alla fine 
> riuscisse solo a leggere il modello del cellulare, ma magari mi sbaglio. Hai 
> un link? 

Non ci credo, che non l'hai trovato :) Basta scrivere droiddrean in
google. Il primo che mi capita:

http://www.pcworld.com/article/221478/googles_droiddream_cleanup_faq.html

Elenco completo delle applicazioni:
http://blog.mylookout.com/2011/03/security-alert-malware-found-in-official-android-market-droiddream/
 
Parte la macchina investigativa, chissa' questi chi sono :) Pero' il
punto e': il problema c'e' o no?

> > Se ho capito bene, le applicazioni girano in una sorta di
> > jail e droiddream e' capace di quello che in altri contesti si chiama
> > "priviledge escalation", 
> 
> Sì, ma solo se lo scarichi e lo installi volontariamente. La stessa cosa la sa 
> fare Z4Root, che però non è un malware ma è utile per far ottenere all'utente 
> i permessi di root sul proprio telefono cellulare.

Comunque, non sembra essere la prima volta che google pulisce i
dispositivi dei suoi clienti android. Questo lo dicono loro:

http://android-developers.blogspot.com/2010/06/exercising-our-remote-application.html

Qui descrivono la sandbox e il modello usato per le autorizzazioni:

http://developer.android.com/guide/topics/security/security.html
 
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.

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 :)

> > Google ha certamente quello che si chiama backdoor sui vostri
> > dispositivi android. La stessa cosa che i trojan usano per le
> > loro sporche faccende su windows e unix system alike. 
> 
> No, qui stai confondendo le cose. La backdoor di Google sarebbe il killswitch 
> di cui sopra ed ha i suoi problemi etici, ma non è la stessa cosa che usano i 
> trojan, i quali usano semplicemente l'ingenuità degli utenti.

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. 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?

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. Vuol dire come minimo che TUTTI i
dispositivi android sono vulnerabili, certamente almeno da google. Piu'
tutti gli altri che sfrutteranno il meccanismo, facendo un bel porting
pari pari del lavoro sviluppato nei decenni recenti per windows. E'
questione di tempo e di presa sul mercato, ma il successo stesso di
android ce lo garantisce, diciamo, al 99,7%, che succedera'.

> > Google lo
> > usa per controllare le applicazioni, spedire informazioni che poi
> > servono ai suoi scopi, 

Ma certo. E quando mai? E se anche fosse vero, tutti quelli che non sono
cosi' buoni come facciamo ad esser sicuri che non ne approfitteranno?
Il tempo (in pochissimo tempo la storia) ce lo dira'.

> > Cosi' e', se vi pare. Ignorarlo puo' solo far male.
> 
> Non proprio così, è giusto sapere le cose, ma è giusto sapere quelle corrette.

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. 
 
L'ipotesi della correttezza assoluta e come quella della verita'
assoluta (che non esiste, quella si chiama fede). Si va per
approssimazioni successive e ci si ferma quando si e' soddisfatti per le
esigenze del momento, sempre pronti a rivedere come stanno le cose
se ci sono nuovi dati. 

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.

> > Ah, gli altri son peggio di google e android, per definizione.
> 
> Sì, infatti Apple, oltre ad avere il kill switch, ce l'ha pure senza 
> giustificazione, perché le applicazioni sull'AppStore sono soggette ad 
> approvazione da parte di Apple prima della pubblicazione (e ci mette qualche 
> giorno ad approvarle), quindi ci si chiede che senso abbia per Apple poter 
> mettere le mani sui terminali degli utenti.

Lo stesso, proprio lo stesso che ha per google, secondo me, ma google e'
necessariamente piu' furbo perche' parte svantaggiato e non puo' che far
meglio di apple per recuperare.

Non basta andare dal nemico del tuo nemico per esser sicuro ti fare
davvero i tuoi interessi e quelli di miliardi di utenti, e non quelli di
qualcun altro. Sconsiglio l'entusiasmo eccessivo. Se google ha troppo
successo, probabilmente microsoft ha gia' messo da parte abbastanza
soldi per comprarselo, prima o poi :) 

Loredana