Roberto Pulito

Android e iOS, privacy in comune violata?

Occhi puntati su una falla che coinvolge sistemi mobile concorrenti, sbloccati e non. Le app di Facebook e Dropbox non proteggerebbero a sufficienza i dati d'accesso. Leggerezza da non sottovalutare?

Roma - Una bizzarra vulnerabilità, individuata nei file di configurazione (.plist) di certe applicazioni mobile, sta gettando scompiglio nel mondo iOS e in quello del rivale Android. Il problema di sicurezza sembrava inizialmente confinato all'applicativo di Facebook, utilizzato con dispositivi dal firmware sbloccato, ma nelle ultime ore sono emersi nuovi e inquietanti particolari.

Il ricercatore di sicurezza Gareth Wright è stato il primo a dare l'allarme, rivelando che l'app Facebook memorizza le informazioni personali con i parametri di accesso in semplice formato testo, piuttosto che utilizzare la crittografia, e che il file non sarebbe assolutamente protetto. La replica del noto social network lascia intendere che serve comunque un dispositivo aperto dal "jailbreak" per arrivare a prelevare queste informazioni.

In realtà, Wright dichiara di aver tranquillamente raggiunto, copiato e letto il file .plist salvato sul suo iPad non sbloccato, utilizzando un programma per computer come iExplorer ad un livello superficiale. Anche i dispositivi senza jailbreak sarebbero quindi vulnerabili, perché i file con le configurazioni del profilo utente lavorano alla luce del Sole invece di starsene sotto chiave.
Il team di Next Web ha scoperto che anche l'applicazione ufficiale DropBox utilizza la medesima filosofia ed è quindi afflitta dalla stessa falla. Per rubare dati altrui con questo stratagemma, funzionante anche in ambito Android, un malintenzionato deve accedere fisicamente al dispositivo mobile, via USB, ma un programma ad hoc installato su un computer pubblico potrebbe copiare .plist in maniera automatica, da tutti gli smartphone e i tablet che si colleghino a esso.

Roberto Pulito
Notizie collegate
22 Commenti alla Notizia Android e iOS, privacy in comune violata?
Ordina
  • La differenza tra Android ed iOS sta nei commenti di questo post.

    iOS (Ruppolo): non è vero, non può succedere, sono solo chiacchiere.

    Android(chiunque altro): ho verificato se il problema esisteva.



    Altresì:

    if (ruppolo is Professionista)
    {
         me.SparoNeiMaroni();
         me.Mansione=Mansione.ColtivatoreDiretto;
    }
  • - Scritto da: HermanHesse Quello TOSTO!
    > La differenza tra Android ed iOS sta nei commenti
    > di questo
    > post.
    >
    > iOS (Ruppolo): non è vero, non può succedere,
    > sono solo
    > chiacchiere.
    >
    > Android(chiunque altro): ho verificato se il
    > problema
    > esisteva.
    >
    >
    >
    > Altresì:
    >
    > if (ruppolo is Professionista)
    > {
    >       me.SparoNeiMaroni();
    >       me.Mansione=Mansione.ColtivatoreDiretto;
    > }

    +1A bocca aperta
  • buahahahahaaha +1
    non+autenticato
  • "PC pubblico"... HAHAHAHAH!!!!!!!

    Esiste al mondo un PC pubblico e un motivo per collegarci il proprio iPhone o iPad via USB?
    No, non esiste.

    Quindi fine del problema.
    ruppolo
    33147
  • Qualcuno con un pretesto te lo farà connettere.

    Lo diceva K.Mitnick e funziona.
  • Avendo un device Android con accesso root ho verificato effetivamente che dati sono salvati nei Preferences file (sia per Facebook che Dropbox). A me risulta che per entrambi i casi l'unica componente leggibile (quindi salvato in plain-text) è il nome utente, mentre la password è cryptata (se poi utilizzano AES o altro non lo saprei..). Quindi non mi torna proprio quello che dice l'articolo, almeno per quanto riguarda Android.
    non+autenticato
  • La password non é salvata in chiaro ma il cookie di sessione si... Puoi verificarlo tu stesso:

    1) Salva databases, locale preferences e tutti i dati di un'appli sul tuo pc
    2) Copiali su un altro dispositivo che ha FB installato
    3) FB accederà tranquillamente al tuo conto senza chiederti la password

    PS: Puoi fare la stessa cosa con una serie di altre applicazioni:
    EBay, Twitter, Gmail e in generale con tutte le applicazioni che non ti chiedono la password ad ogni avvio!
    non+autenticato
  • Ah... Il tel deve essere rootato per effettuare il passo 1)

    - Scritto da: Michele Sartori
    > La password non é salvata in chiaro ma il cookie
    > di sessione si... Puoi verificarlo tu
    > stesso:
    >
    > 1) Salva databases, locale preferences e tutti i
    > dati di un'appli sul tuo
    > pc
    > 2) Copiali su un altro dispositivo che ha FB
    > installato
    > 3) FB accederà tranquillamente al tuo conto senza
    > chiederti la password
    >
    >
    > PS: Puoi fare la stessa cosa con una serie di
    > altre
    > applicazioni:
    > EBay, Twitter, Gmail e in generale con tutte le
    > applicazioni che non ti chiedono la password ad
    > ogni
    > avvio!
    non+autenticato
  • Non esistono i file plist su Android.

    Esistono delle preferences, salvate nella cartella privata dell'applicazione, accessibile solo a quell'applicazione (perche` c'è il kernel Linux che impedisce alle altre di accedere).

    L'unico modo per accederci è di avere rootato il telefono e di aver dato l'accesso a un software malevolo.

    Certo che se fai un backup Titanium (che richiede root) e lasci i file di dump sulla SD, quelli sono in chiaro e leggibili da chiunque...

    Ma nessuno degli articoli linkati spiega come possa essere vulnerabile Android. Dicono solo che le password non vengono crittate prima di essere salvate (nel plist su iOS, nelle Preferences su Android).
    Solo che iOS passa i plist ad iTunes quando lo si connette al PC. Android non passa niente a nessuno, di quello che c'è nelle cartelle private delle app.

    Bye.
    Shu
    1232
  • In realtà Android viene citato nella fonte originale (Gareth Wright) perché "qualcuno gli ha detto che anche Android è vulnerabile" ma "non ha avuto occasione di verificare", dopo di che il suo articolo riguarda esclusivamente iOS.
    Poi chi invece ci ha scritto sopra altri articoli, ha posto tutto sullo stesso piano.

    In un Android non rootato (a meno di nuove grosse falle di sistema, ovviamente) non è semplicemente possibile accedere ai dati delle applicazioni. Anche Dropbox ha fatto la medesima precisazione, e credo sarebbe dovere riportare le dovute distinzioni in questo articolo.
    Se poi il dispositivo è rootato, e si danno i permessi ad un'applicazione, direi che è abbastanza implicito e prevedibile che questa possa leggere tutto (ma anche senza andare a prendersi il file, le basta intercettare il traffico).
    non+autenticato
  • - Scritto da: Shu
    > Solo che iOS passa i plist ad iTunes quando lo si
    > connette al PC. Android non passa niente a
    > nessuno, di quello che c'è nelle cartelle private
    > delle
    > app.
    >
    > Bye.

    In realtà il problema è un altro: il protocollo che itunes utilizza per trasferire i dati è, almeno in parte, documentato ed esistono dei programmi (diskaid, iphonedrive…giusto un paio a memoria) che ti permettono di accedere al dispositivo come se fosse una qualsiasi memoria usb. Tramite questi programmi (o tramite uno scritto ad hoc che lo faccia in modo automatico) è quindi possibile andarsi a pescare i file con le password in chiaro.
  • Password salvate in chiaro: quei programmatori sono all'asilo nido della sicurezza informatica, altro che parlare di progressi nella sicurezza base delle applicazioni!
    non+autenticato
  • - Scritto da: OldDog

    > Password salvate in chiaro: quei programmatori
    > sono all'asilo nido della sicurezza informatica,
    > altro che parlare di progressi nella sicurezza
    > base delle
    > applicazioni!

    Magari non sono un esperto di sicurezza, ma se salvi le password crittate deve essere un algoritmo reversibile, e crittarle usando solo dati presenti sul dispositivo (chiavi private, id del telefono, o altro) non serve a niente, perche` vengono decrittate automaticamente.

    L'unico modo sicuro e` crittarle chiedendo una chiave dall'esterno, che banalmente può essere una password chiesta all'utente, un PIN, una gesture.

    Davvero credi che un utente si metterebbe a crittare una password con un'altra password per poi essere costretto, ogni volta che riaccende il telefono o esce dalla modalita` aereo, a mettere la password n volte (una per ogni software che la salva)?

    L'alternativa sarebbe un keyring di sistema, magari associato al PIN o al codice di sblocco del telefono, ma anche qui il rischio e` che, una volta messo il PIN, i dati sono comunque in chiaro.

    Bye.
    Shu
    1232
  • Uhm... non è proprio così eh!
    Posso usare uno dei (tanti) algoritmi (MD5 docet) per criptare una pwd... magari però non ho capito a cosa ti stavi riferendo.
  • md5 per criptare? andiamo bene...
    perché non base64? infondo ti da comunque "caratteri strani, quindi è cifrato" in uscita
    non+autenticato
  • Mr. "andiamo bene", stiamo parlando di una pwd su di un file o di una pwd che deve transitare avanti ed indietro via web?
    Spiegami, perché non si capisce tanto bene cosa si intende su.

    MD5 è debole secondo te?
  • - Scritto da: HermanHesse Quello TOSTO!
    > Mr. "andiamo bene", stiamo parlando di una pwd su
    > di un file o di una pwd che deve transitare
    > avanti ed indietro via
    > web?
    > Spiegami, perché non si capisce tanto bene cosa
    > si intende
    > su.
    >
    > MD5 è debole secondo te?

    Secondo voi due MD5 è un algoritmo che serve per crittare? Rotola dal ridere Andiamo bene...
    non+autenticato
  • - Scritto da: ...
    > md5 per criptare? andiamo bene...
    > perché non base64? infondo ti da comunque
    > "caratteri strani, quindi è cifrato" in
    > uscita

    Cioè fammi capire... secondo te il motivo per cui md5 non va bene "per crittare" è perché è troppo debole?!? Rotola dal ridere
    non+autenticato
  • - Scritto da: Shu
    > - Scritto da: OldDog
    >
    > > Password salvate in chiaro: quei programmatori
    > > sono all'asilo nido della sicurezza informatica,
    > > altro che parlare di progressi nella sicurezza
    > > base delle
    > > applicazioni!
    >
    > Magari non sono un esperto di sicurezza, ma se
    > salvi le password crittate deve essere un
    > algoritmo reversibile

    Ecco, non sei un esperto di sicurezza quindi evita di scrivere castronerie.

    Le password si possono salvare usando algoritmi non reversibili, di hash. Semplicemente una volta che immetti la stessa password il sistema verifica che applicando lo stesso algoritmo si generi la stessa serie di byte che è stata salvata: se sì, allora hai inserito la password corretta, altrimenti la password non è corretta.
    non+autenticato
  • Certo che vi impegnate assai per scrivere ma non per leggere. Quanti commenti hai lasciato sullo stesso thread, 3?

    E nemmeno hai capito a che si riferiva l'altro utente?

    Se l'app si salva la password in locale è per poterla riusare senza farla digitare di nuovo all'utente, quindi deve poterla "recuperare" prima di inviarla (si presume, visto l'uso che se ne deve fare) al server, quindi sì, va usato un algoritmo invertibile.

    O pensi forse che sia furbo mandare al server la versione crittata? A quel punto tanto vale copiarsi/intercettare quella e chi se ne frega se non so la password originale, tanto il server si preoccupa solo di vedere se mando "l'hash giusto"...

    Ma probabilmente, visto il nick, sei un troll ed ho solo sprecato tempoOcchiolino
    - Scritto da: ingiurioso
    > - Scritto da: Shu
    > > - Scritto da: OldDog
    > >
    > > > Password salvate in chiaro: quei programmatori
    > > > sono all'asilo nido della sicurezza
    > informatica,
    > > > altro che parlare di progressi nella sicurezza
    > > > base delle
    > > > applicazioni!
    > >
    > > Magari non sono un esperto di sicurezza, ma se
    > > salvi le password crittate deve essere un
    > > algoritmo reversibile
    >
    > Ecco, non sei un esperto di sicurezza quindi
    > evita di scrivere
    > castronerie.
    >
    > Le password si possono salvare usando algoritmi
    > non reversibili, di hash. Semplicemente una volta
    > che immetti la stessa password il sistema
    > verifica che applicando lo stesso algoritmo si
    > generi la stessa serie di byte che è stata
    > salvata: se sì, allora hai inserito la password
    > corretta, altrimenti la password non è
    > corretta.
    non+autenticato
  • - Scritto da: uno di passaggio
    > Certo che vi impegnate assai per scrivere ma non
    > per leggere. Quanti commenti hai lasciato sullo
    > stesso thread,
    > 3?
    >
    > E nemmeno hai capito a che si riferiva l'altro
    > utente?
    >
    > Se l'app si salva la password in locale è per
    > poterla riusare senza farla digitare di nuovo
    > all'utente, quindi deve poterla "recuperare"
    > prima di inviarla (si presume, visto l'uso che se
    > ne deve fare) al server, quindi sì, va usato un
    > algoritmo
    > invertibile
    >
    > O pensi forse che sia furbo mandare al server la
    > versione crittata? A quel punto tanto vale
    > copiarsi/intercettare quella e chi se ne frega se
    > non so la password originale, tanto il server si
    > preoccupa solo di vedere se mando "l'hash
    > giusto"...

    Eh!?! "Intercettare"!?! Ma l'unico modo di proteggersi da un "man in the middle" allora è usare SSL o simili, o al limite un algoritmo a chiave pubblica... ma che razza di discorsi fai? Che differenza farebbe usare un hash o un algoritmo invertibile, in entrambi i casi intercetti i byte che ti servono!!!

    Che differenza fa se i byte sono un md5 o uno sha-256 o una serie di byte crittati con AES con password sconosciuta, una volta intercettati invii quelli al server ed il gioco è fatto anche se no hai la password!

    Ma che castronerie vai dicendo!??

    >
    > Ma probabilmente, visto il nick, sei un troll ed
    > ho solo sprecato tempo
    >Occhiolino

    Ma studia un po' vai...
    non+autenticato
  • Lascio stare, non c'è peggior sordo di chi non vuol sentire

    Sei andato talmente fuori discorso che devo pensare che è deliberatoOcchiolino

    Continua così, il tuo mestiere lo sai fare abbastanza beneA bocca aperta
    non+autenticato