Alfonso Maruccia

Android, quando l'SSL va storto

Un gran numero di app androidi è vulnerabile ad attacchi di tipo man-in-the-middle, dicono i ricercatori, a causa di cattive implementazioni delle comunicazioni su standard SSL

Roma - La problematica situazione sul fronte della sicurezza di Android si fa ancora più preoccupante in seguito allo studio di ricercatori tedeschi, in cui viene descritta una tipologia di attacchi "man-in-the-middle" resa possibile da implementazioni errate (o semplicemente "pigre" e non sufficientemente stringenti) delle comunicazioni cifrate su protocollo SSL.

Prendendo in esame un campione di 13mila app più o meno popolari disponibili sul marketplace Android, i ricercatori teutonici hanno scoperto che il 17 per cento delle app progettate per usare il protocollo SSL sono vulnerabili.

Il problema, dicono i ricercatori, non sono tanto le vulnerabilità quanto l'autentica miniera d'oro che le app insicure possono rappresentare: nel loro studio gli esperti sono riusciti a carpire ogni genere di informazione personale, riservata e finanziaria inclusi i dettagli su account PayPal, carte di credito American Express, credenziali di email (Google, Yahoo!, Hotmail/Outlook), WordPress, Facebook, Twitter e chi più ne ha più ne metta.
Tra i casi più preoccupanti descritti dai ricercatori c'è una app antivirale a cui sarebbe teoricamente possibile trasferire firme di malware "malevole" o addirittura disabilitare del tutto la protezione, una app per scaricare dati cloud che comunica in bella mostra le credenziali di accesso, un sistema di messaging "molto popolare" (con una base utenza di 10-50 milioni di sottoscrittori) che comunica i numeri di telefono presenti nella rubrica.

L'origine del problema, almeno in questo caso, non è tanto Google quanto gli sviluppatori di app e la loro incapacità di usare in maniera sufficientemente le funzionalità della API SSL inclusa in Android: a causa di uno sviluppo non proprio attentissimo alla sicurezza, le app accettano indistintamente tutti i certificati loro presentati, e accettano certificati indipendentemente dal nome di dominio da cui provengono.

La ricerca teutonica non serve solo a evidenziare il pericolo insito nelle app "sicure" presenti su Android e il business criminale da esse alimentato: il tool creato per individuare le vulnerabilità SSL nelle app verrà messo a disposizione come servizio web e farà parte dello scanner di sicurezza Androguard.

Alfonso Maruccia
Notizie collegate
  • SicurezzaAndroid, malware e antivirusL'FBI avverte gli utenti sul pericolo crescente di imbattersi in codice malevolo sul sistema mobile di Google. Google ascolta e progetta l'integrazione di funzionalità antivirus nel suo marketplace
150 Commenti alla Notizia Android, quando l'SSL va storto
Ordina
  • Bello vedervi sviare i discorsi quando i post parlano di cose che ti urtano , se vuoi parliamo di auto. Rotola dal ridere
    non+autenticato
  • "L'origine del problema, almeno in questo caso, non è tanto Google quanto gli sviluppatori di app e la loro incapacità di usare in maniera sufficientemente le funzionalità della API SSL inclusa in Android"
    non+autenticato
  • E con questo sparisce il problema ?
    non+autenticato
  • - Scritto da: aphex twin
    > E con questo sparisce il problema ?

    Ma dimmi ...con le mappe del cavolo di Ios sparisce la figuraccia che ha fatto la mela ?? e il problema degli sms su Iphone è stato risolto,vero ?
    Io guarderei prima dentro casa mia,prima di vedere quella degli altri ...
    non+autenticato
  • - Scritto da: aphex twin
    > Bello vedervi sviare i discorsi quando i post
    > parlano di cose che ti urtano , se vuoi parliamo
    > di auto.
    > Rotola dal ridere


    ma perché sviare i discorsi?
    siete voi che vi sbracciate inutilmente.

    se uno non sa programmare, o intenzionalmente sviluppa malware, cosa c'è da sviare?
    rimane il fatto, e non vorremmo mai che non fosse così, che quello di android sia un ambiente libero, in cui puoi sviluppare e puoi anche sviluppare malware.
    non è a monte, o alla radice, che deve essere risolto il problema.
    sta sempre all'intelligenza dell'utente decidere.
    ma è importante poter decidere.
  • - Scritto da: Freedom of choice

    > sta sempre all'intelligenza dell'utente decidere.

    Oddio...

    Ok, non si possono trattare gli utenti come stupidi incapaci di decidere a priori e quindi è giusto dargli la possibilità di decidere. Ma, come criterio generale, non sarebbe il caso di dargli una mano quando non sono in grado di farlo? Anche perché poi non tutti abbiamo il tempo per decidere su tutto. Ne tantomeno è giusto che la libertà di decisione diventi obbligo a decidere.

    > ma è importante poter decidere.

    Ci sono tante cose importanti, mica solo questa.
    FDG
    10909
  • Quando ho visto la comparsa nel Play della App della mia banca ho avuto delle titubanze, ora la uso perché è troppo comoda (e quando dico "troppo" intendo anche nella sua accezione negativa).
    Spero solo che abbiano fatto un lavoro come si deve.

    (tanto nel mio conto no ghe xe niente da robàr)
  • - Scritto da: il solito bene informato
    > Quando ho visto la comparsa nel Play della App
    > della mia banca ho avuto delle titubanze, ora la
    > uso perché è troppo comoda (e quando dico
    > "troppo" intendo anche nella sua accezione
    > negativa).
    > Spero solo che abbiano fatto un lavoro come si
    > deve.
    >
    > (tanto nel mio conto no ghe xe niente da robàr)

    Ma robàr poc xe mejo de ninte.
    maxsix
    9440
  • - Scritto da: maxsix
    > - Scritto da: il solito bene informato
    > > Quando ho visto la comparsa nel Play della
    > App
    > > della mia banca ho avuto delle titubanze,
    > ora
    > la
    > > uso perché è troppo comoda (e quando dico
    > > "troppo" intendo anche nella sua accezione
    > > negativa).
    > > Spero solo che abbiano fatto un lavoro come
    > si
    > > deve.
    > >
    > > (tanto nel mio conto no ghe xe niente da
    > robàr)
    >
    > Ma robàr poc xe mejo de ninte.

    dovrebbero beccare quei 20 minuti alla mattina del giorno del mio stipendio in cui ho ancora tutti i soldiA bocca aperta
  • - Scritto da: il solito bene informato
    > - Scritto da: maxsix
    > > - Scritto da: il solito bene informato
    > > > Quando ho visto la comparsa nel Play
    > della
    > > App
    > > > della mia banca ho avuto delle
    > titubanze,
    > > ora
    > > la
    > > > uso perché è troppo comoda (e quando
    > dico
    > > > "troppo" intendo anche nella sua
    > accezione
    > > > negativa).
    > > > Spero solo che abbiano fatto un lavoro
    > come
    > > si
    > > > deve.
    > > >
    > > > (tanto nel mio conto no ghe xe niente da
    > > robàr)
    > >
    > > Ma robàr poc xe mejo de ninte.
    >
    > dovrebbero beccare quei 20 minuti alla mattina
    > del giorno del mio stipendio in cui ho ancora
    > tutti i soldi
    >A bocca aperta

    E che problema c'è.
    Basta poco che ce vò.
    maxsix
    9440
  • Chi si agita troppo in genere perde di vista (quasi incosciamente) la realtà dei fatti.

    Sorride


    Tutto ciò accadeva solo qualche mese fa, nel luglio 2012:


    http://www.digitaltrends.com/mobile/how-a-russian-.../


    Traduzione della parte specifica ed assolutmente analoga al contenuto di questo articolo su Android e SSL; a scanso di malinterpretazioni da parte dei più.

    Occhiolino


    "Quando un utente procede all'acquisto di una App, l'applicazione si connette al servizio iTunes di Apple per procedere

    alll'approvazione dell'operazione.

    Qualora l'operazione non vada a buon fine a causa di una AppleID non valida, la password errata, ed altro, Apple fa sapere all'App

    che l'operazione non si è conclusa correttamente. In caso contrario, il servizio iTunes di Apple restituisce una "ricevuta"

    digitale per la corretta transazione.

    Tali ricevute sono molto generiche: non contengono alcuna informazione di identificazione personale sull'utente che ha effettuato

    l'acquisto, invero consiste in un codice univoco della transazione e pochi altri dettagli.

    Per ottenere la sicurezza di queste informazioni, Apple utilizza la tecnologia standard del settore, ovvero SSL, per crittografare

    la connessione sino al servizio iTunes.

    Questa è la medesima tecnologia dietro il protocollo https:// usato nelle connessioni Web protetti.

    Apple consiglia quindi agli sviluppatori di App lo stesso metodo, cioé di convalidare le ricevute di acquisto per conto proprio:

    inviare in modo sicuro la ricevuta di un servizio controllato dallo sviluppatore, infine confermare tramite il servizio Apple che

    la ricevuta è legittima. Se si procede correttamente, al termine della trafila il servizio può quindi restituire all'applicazione

    la ricevuta di conferma.


    Smbrerebbe un sistema collaudato e sicuro, tranne per il fatto che buona parte degli sviluppatori non recepisce in modo completo

    il consiglio di Apple.

    In effetti accade spesso il contrario, e molti sviluppatori creano meccanismi per cui chiedono direttamente ad Apple di verificare

    la conferma che hanno appena ricevuta. Ciò significa che, il più delle volte, ci sono solo due interlocutori durante la

    transazione di acquisto di una App: l'utente (che rappresenta di fatto la App acquistata) ed Apple.


    L'attacco che Borodin ha ha dimostrato aver positivamente portato a termine funziona perché egli si è sostituito ad Apple, al

    momento di istituire il proprio server che approvi la transazione e quindi prima della verifica della legittimità della App.

    Per ottenere questo risultato, Borodin ha dovuto soltanto fare in modo che gli utenti installassero dei certificati di protezione

    falsi, in modo da dimostrare di essere Apple stessa - è così che Borodin è stato in grado di simulare una connessione protetta - e

    quindi impostare un sistema controllato direttamente da Borodin come server DNS.


    In sintesi il risultato è questo: quando un'applicazione tenta di connettersi ad iTunes per eseguire un acquisto in-app, la

    connessione viene reindirizzata al server di Borodin, il quale è in grado di creare una connessione che appare sicura - riguardo

    l'applicazione in questione - sostituendosi ad Apple stessa.

    L'estrema semplicità dei meccanismi di tutta la trafila di gestione del pagamento, così come impostato da Apple, ha facilmente

    portato Borodin alla generazione di false ricevute in merito al rispetto all'acquisto dell'App.


    Il trucco può funzionare proprio a causa della mancata verifica indipendente dell'acquisto da parte di alcuni sviluppatori."




    Oltre a far risaltare la (solita) ignoranza in materia, ogni ulteriore commento su alcune affermazioni di entusiasmo da parte dei soliti accaniti sostenitori Apple, appare davvero di pochissima utilità.


    Sorride
  • - Scritto da: Totocellux

    > Oltre a far risaltare la (solita) ignoranza in
    > materia, ogni ulteriore commento su alcune
    > affermazioni di entusiasmo da parte dei soliti
    > accaniti sostenitori Apple, appare davvero di
    > pochissima utilità.

    Interessante. Però questo riguarda gli acquisti in-app, così che puoi far credere all'applicazione che hai pagato e sfrutti a sbafo contenuti che dovresti pagare. Non si parla di dati personali dell'utente che transitano in rete.

    Certo, anche in questo caso la responsabilità è di chi fa l'applicazione. Punto.

    p.s.: ovviamente, se il codice è lo stesso e viene portato su iOS (o al contrario da iOS verso Android), il risultato non mi aspetto cambi parecchio.
    -----------------------------------------------------------
    Modificato dall' autore il 23 ottobre 2012 12.25
    -----------------------------------------------------------
    FDG
    10909
  • - Scritto da: FDG
    > - Scritto da: Totocellux
    >
    > > Oltre a far risaltare la (solita) ignoranza
    > in
    > > materia, ogni ulteriore commento su alcune
    > > affermazioni di entusiasmo da parte dei
    > soliti
    > > accaniti sostenitori Apple, appare davvero di
    > > pochissima utilità.
    >
    > Interessante. Però questo riguarda gli acquisti
    > in-app, così che puoi far credere
    > all'applicazione che hai pagato e sfrutti a sbafo
    > contenuti che dovresti pagare. Non si parla di
    > dati personali dell'utente che transitano in
    > rete.
    Beh oddio.. manca il numero di telefonoSorride
    "Last but certainly not least, Cupertino is transmitting its customers' Apple IDs and passwords in clear text (Apple assumed it would only ever be communicating with its own server). The following information is transferred from your device to Borodin's server: app restriction level, app id, version id, device guid, in-app purchase quantity, in-app purchase offer name, app identifier, app version, your language, and your locale"

    > Certo, anche in questo caso la responsabilità è
    > di chi fa l'applicazione.
    > Punto.
    Solo in parte... basta vedere la "battaglia" com'e' proseguita..

    > p.s.: ovviamente, se il codice è lo stesso e
    > viene portato su iOS (o al contrario da iOS verso
    > Android), il risultato non mi aspetto cambi
    > parecchio.
    Uhn? adesso le API e il market di google e apple sono uguali??????
    non+autenticato
  • - Scritto da: bubba
    > - Scritto da: FDG
    > > - Scritto da: Totocellux
    > >
    > > > Oltre a far risaltare la (solita)
    > ignoranza
    > > in
    > > > materia, ogni ulteriore commento su
    > alcune
    > > > affermazioni di entusiasmo da parte dei
    > > soliti
    > > > accaniti sostenitori Apple, appare
    > davvero
    > di
    > > > pochissima utilità.
    > >
    > > Interessante. Però questo riguarda gli
    > acquisti
    > > in-app, così che puoi far credere
    > > all'applicazione che hai pagato e sfrutti a
    > sbafo
    > > contenuti che dovresti pagare. Non si parla
    > di
    > > dati personali dell'utente che transitano in
    > > rete.
    > Beh oddio.. manca il numero di telefonoSorride
    >   "Last but certainly not least, Cupertino is
    > transmitting its customers' Apple IDs and
    > passwords in clear text (Apple assumed it would
    > only ever be communicating with its own server).
    > The following information is transferred from
    > your device to Borodin's server: app restriction
    > level, app id, version id, device guid, in-app
    > purchase quantity, in-app purchase offer name,
    > app identifier, app version, your language, and
    > your
    > locale"
    Mi son dimenticato una cosa importante pero'... anche se ovviamente l'utente e' "costretto" a trasferire svariati suoi dati alla fake-platform, il giochino e' in effetti CONTRO il developer (contro i guadagni del developer)... E' un punto importante, xche non e' il classico "steal the password"..
    non+autenticato
  • - Scritto da: bubba
    > Mi son dimenticato una cosa importante pero'...

    Fa nulla, tanto non frega a nessuno.
  • - Scritto da: bubba

    > Uhn? adesso le API e il market di google e apple
    > sono uguali??????

    No. Però mi aspetto che l'uso che ne fanno le applicazioni sia se non lo stesso molto simile.
    FDG
    10909
  • - Scritto da: FDG
    > - Scritto da: bubba
    >
    > > Uhn? adesso le API e il market di google e
    > apple
    > > sono uguali??????
    >
    > No. Però mi aspetto che l'uso che ne fanno le
    > applicazioni sia se non lo stesso molto
    > simile.
    pensavo a una tua sparata, ma ho capito dopo che probabilmente intendevi l'approccio GENERALE (cioe inserimento di cert fake e dns mangling).
    In questo caso, si. vero. Infatti il russo, dopo essersi stancato di iOS, ha gia iniziato a lavorare su android.Sorride
    Cmq devo dire che il russo non mi piace molto. Ok fai un PoC, figo, ecc... ma questo persevera proprio.. ha fatto app per cyndia, una tabella dei sw che si possono fregare, rilasciato il sw server-side, ecc. Cioe, come dire, puzza un po di criminaleCon la lingua fuori
    non+autenticato
  • - Scritto da: bubba

    > pensavo a una tua sparata, ma ho capito dopo che
    > probabilmente intendevi l'approccio GENERALE
    > (cioe inserimento di cert fake e dns
    > mangling).

    Beh, non penso siano problemi specifici di Android, iOS o qualsiasi altro sistema al mondo. Dico bene?
    FDG
    10909
  • - Scritto da: FDG

    > Interessante. Però questo riguarda gli acquisti
    > in-app, così che puoi far credere
    > all'applicazione che hai pagato e sfrutti a sbafo
    > contenuti che dovresti pagare. Non si parla di
    > dati personali dell'utente che transitano in
    > rete.
    >
    > Certo, anche in questo caso la responsabilità è
    > di chi fa l'applicazione.
    > Punto.
    >
    > p.s.: ovviamente, se il codice è lo stesso e
    > viene portato su iOS (o al contrario da iOS verso
    > Android), il risultato non mi aspetto cambi
    > parecchio.


    Boronin ha solo voluto dimostrare come il meccanismo della fiducia in quel contesto (acquisto in-App) mostra chiaramente una falla lato sviluppatore.

    Una volta attivato e portato a termine un meccanismo (lato attaccante) di tipo Man-in-the-Middle, nulla vieta all'attaccante stesso di affinare tutto il sistema malevolo, tramite anche la sostituzione della App stessa dello sviluppatore, con un'altra modificata ad arte e capace di trafugare ed esportare dati etc. etc.

    Certo servirebbero delle manine molto sapienti ma ... come ben sappiamo e la storia ci ha insegnato, ai criminali (anche informatici) serve solo un piccolo spunto iniziale per passare ad una seconda o ancora ulteriore fase operativa.


    Quello che fa più specie della vicenda di cui Boronin si è reso protagonista, è che lui abbia inserito un video su YouTube per mostrare l'intera finalizzazione della procedura (il link è all'interno dell'articolo di DigitalTrends http://www.youtube.com/watch?v=iSuo4xEucqE) ed Apple lo abbia fatto rimuovere.

    Questo è a mio modo di vedere un modo insulso di nuocere in qualche modo ai propri utenti, che dovrebbero conoscere come facile sia, per tutta una serie di approfittatori telematici, eludere alcuni meccanismi di fiducia lasciati ritenere a prova di ladro.


    In verità Apple dopo questa dimostrazione, oltre a far rimuovere il video, ha pensato di apportare delle modifiche al meccanismo, ma non se ne è saputo più nulla.


    Sorride
  • - Scritto da: Totocellux

    > http://www.youtube.com/watch?v=iSuo4xEucqE) ed
    > Apple lo abbia fatto rimuovere.

    A solito...A bocca aperta

    Non mi sorprende.

    > In verità Apple dopo questa dimostrazione, oltre
    > a far rimuovere il video, ha pensato di apportare
    > delle modifiche al meccanismo, ma non se ne è
    > saputo più nulla.

    Beh, almeno questo. Però non è un atteggiamento che gli eviterà altri casi.
    FDG
    10909
  • - Scritto da: Totocellux
    > Chi si agita troppo in genere perde di vista
    > (quasi incosciamente) la realtà dei fatti.
    >
    >
    > Sorride
    >
    >
    > Tutto ciò accadeva solo qualche mese fa, nel
    > luglio
    > 2012:
    >
    >
    > http://www.digitaltrends.com/mobile/how-a-russian-
    >
    >
    > Traduzione della parte specifica ed assolutmente
    > analoga al contenuto di questo articolo su
    > Android e SSL; a scanso di malinterpretazioni da
    > parte dei
    > più.
    carino... e no, non e' strettamente analoga. E' parecchio peggio. E' un workaround generalizzato per tutte le app che chiedono ad apple la validazione del receipt. Almeno questo spiega l'articolo. Tant'e' che la "temibile macchina da guerra" di Apple si mise subito in moto, cancellando i video su youtube e cercando di bloccare i server di Borodin (cosi leggo)

    > Oltre a far risaltare la (solita) ignoranza in
    > materia, ogni ulteriore commento su alcune
    > affermazioni di entusiasmo da parte dei soliti
    > accaniti sostenitori Apple, appare davvero di
    > pochissima utilità.
    questo sicuro. Il 99% dei troll qui non ha nemmeno letto la prima pagina della ricerca citata nell'articolo. E pontificano a vanvera.
    non+autenticato
  • Tra i due litiganti... preferisco tenermi il vecchio sano Blackberry.

    Avra le sue limitazioni, ma fa quello che deve fare: garantire telefonate, mail, organizer, un minimo di accesso al web in maniera sicura e stabile.

    I problemi ci sono già sulla scrivania, replicarli anche in tasca è ridicolo, come è ridicolo farsi spennare per un cellulare fatto coi piedi e venduto a peso d'oro, magari con gli stessi problemi di sicurezza dell'altro solo nascosti bene bene.

    bye
    non+autenticato
  • Quotissimo, io uso BB per l'ambito professionale e iOS per tutto il resto.
    non+autenticato
  • Clicca per vedere le dimensioni originali
    ma hai letto cosa ha scritto prima? perché allora quotissimo?
    non+autenticato
  • Parla di Blackberry giusto ? Ed io quello ho come smartphone.

    Che c'é che non va ?
    non+autenticato
  • - Scritto da: aphex twin
    > Che c'é che non va ?

    che non va (per te) c'è questo:

    > è ridicolo farsi spennare per un cellulare fatto coi piedi e venduto a peso d'oro, magari con gli stessi problemi di sicurezza

    qui parla di iphone.

    e tu hai quotato tutto.
    bravo
    Sorride
  • - Scritto da: Freedom of choice
    > > è ridicolo farsi spennare per un cellulare
    > fatto coi piedi e venduto a peso d'oro, magari
    > con gli stessi problemi di
    > sicurezza
    >

    "magari con gli stessi problemi di sicurezza", magari eh A bocca aperta

    E' proprio ridicolo spendere per un S3 (che costa quanto un iPhone5) per avere dei buchi con della plastica intorno.

    > qui parla di iphone.
    >

    Anche

    > e tu hai quotato tutto.
    > bravo
    > Sorride

    E questo ti urta ? Chi ha un minimo di intelletto ha capito.
    non+autenticato
  • - Scritto da: aphex twin
    > Chi ha un minimo di intelletto ha capito.


    infatti.
    sei tu a non aver capito.
    Occhiolino
  • Su apple non si possono vendere né antivirus né firewall, mentre su android play store sì. Risultato? Le ricerche sulla sicurezza di app e sys.op. vengono effettuate non dove c'è bisogno di sicurezza ma dove tale ricerche si possono monetizzare.
    non+autenticato
  • - Scritto da: gnammolo
    > Su apple non si possono vendere né antivirus né
    > firewall, mentre su android play store sì.
    > Risultato? Le ricerche sulla sicurezza di app e
    > sys.op. vengono effettuate non dove c'è bisogno
    > di sicurezza ma dove tale ricerche si possono
    > monetizzare.

    Quindi stai insinuando che:
    A) Android è un ambiente sano
    B) I malware sono fatti ad hoc dai produttori di firewall e antivirus
    C) A Google sta bene, tace e lascia fare.

    Mi ricorda un'altra compagnia del mondo IT.
    Eh si.
    maxsix
    9440
  • > Quindi stai insinuando che:
    > A) Android è un ambiente sano
    qua non si parla di malware, già significa che non hai capito il punto SSL/man in the middle

    > B) I malware sono fatti ad hoc dai produttori di
    > firewall e
    > antivirus
    leggi sopra

    > C) A Google sta bene, tace e lascia fare.
    è il prezzo della libertà, in korea del nord nessuno ti ruba l'auto negli usa sì.
    non+autenticato
  • - Scritto da: gnammolo
    > Su apple non si possono vendere né antivirus né
    > firewall, mentre su android play store sì.

    https://itunes.apple.com/us/app/smart-surfing/id30...
    https://itunes.apple.com/us/app/hosted-mobile-secu...
    non+autenticato
  • ma sono due semplici proxy che deviano la navigazione verso i servers trend micro
    non+autenticato
CONTINUA A LEGGERE I COMMENTI
1 | 2 | 3 | Successiva
(pagina 1/3 - 12 discussioni)