StrandHogg 2.0 è una nuova pericolosa vulnerabilità Android. Ecco come può influenzare gli utenti e come gli sviluppatori possono proteggere le loro app da esso.
Sono le 22:00. Sai dove sono le tue Attività? C'è una nuova vulnerabilità che può essere sfruttata su milioni di dispositivi Android, ed è anche piuttosto pericolosa. In poche parole, questo difetto di progettazione consente a un utente malintenzionato di presentare la propria attività (pagina) sopra quella di un'altra app, confondendo potenzialmente l'utente e inducendolo a fornire i propri dati privati. La vulnerabilità è stata denominata StrandHogg 2.0 ed è stata recentemente divulgata da Promuovere, una società di sicurezza norvegese.
La vulnerabilità StrandHogg 2.0 colpisce teoricamente tutti i dispositivi Android che eseguono versioni Android precedenti a Honeycomb (3.0) e fino ad Android 9 Pie (9.0). Basato sul statistiche sulla distribuzione della versione Android più recente, ciò significa che circa il 91,8% di tutti i dispositivi Android sono vulnerabili a StrandHogg 2.0
. La vulnerabilità è stata assegnata CVE-2020-0096 e gli è stato dato un livello di gravità "critico". Non richiede autorizzazioni speciali per funzionare e può funzionare quasi interamente senza l'interazione dell'utente. Tutto ciò che un utente deve fare è aprire un'app con codice dannoso nascosto al suo interno e quindi sarà vulnerabile allo sfruttamento.Promon è stato così gentile da inviarci la sua app di prova del concetto e il suo codice sorgente in modo che potessimo farlo al meglio spiegare come funziona l'exploit, perché è importante per gli utenti e in che modo gli sviluppatori possono proteggere le proprie app contro di esso.
Come funziona
Supponiamo che tu stia utilizzando Gmail e fai clic su un collegamento web. Se vai alla schermata delle app recenti, potresti notare che la pagina web sembra essere "dentro" Gmail. L'anteprima mostra il sito Web, ma l'icona e il nome dell'app provengono ancora da Gmail. Questo è qualcosa che accade quando un'app/attività avvia un'altra app/attività nella stessa attività. Ora immagina di non aver aperto di proposito quel collegamento. A te sembra che sia solo una parte dell'app Gmail. Questo è il comportamento sfruttato da StrandHogg 2.0.
Dovremo tralasciare alcuni dettagli qui, ma ecco approssimativamente come funziona questo exploit. Per quanto segue, supponiamo che l'aggressore voglia ottenere l'accesso Gmail dell'utente.
- L'utente scarica un'app dannosa (ovviamente senza sapere che è dannosa) e la apre.
- In background, l'app apre Gmail, inserisce sopra un'attività di accesso simile e quindi avvia un'altra attività.
- L'utente apre Gmail e vede quella che sembra la schermata di accesso di Gmail ma che in realtà è l'attività di phishing dell'aggressore.
L'attività finale avviata nel passaggio 2 può essere qualsiasi cosa che eviti i sospetti. L'app potrebbe simulare un arresto anomalo e tornare alla schermata principale oppure potrebbe semplicemente aprirsi all'attività principale come se nulla fosse accaduto. L'unica cosa sospetta che l'utente potrebbe vedere è una serie di animazioni di apertura all'avvio di tutte le attività. La parte peggiore: non sembrerà nemmeno che Gmail sia stato aperto.
Naturalmente, un utente malintenzionato può fare molto di più che mostrare semplicemente una schermata di accesso falsa. Un'app dannosa potrebbe invece presentare una richiesta di autorizzazione, inducendo l'utente a concedere autorizzazioni indesiderate. Anche se richiedere autorizzazioni speciali come l'Accessibilità potrebbe insospettire l'utente, è possibile causare molti danni con qualcosa come Storage Access.
I pezzi tecnici
La sezione successiva offre una panoramica di alto livello del funzionamento di StrandHogg 2.0. Promon non rilascerà tutti i dettagli prima di qualche mese, quindi non possiamo condividere esattamente come viene implementato questo exploit. Ci sono però alcuni dettagli tecnici di cui possiamo parlare.
In poche parole, StrandHogg 2.0 dirotta Android Context.startActivities() Metodo API, utilizzando tre intenti.
- Il primo Intent è quello che avvia, nel caso del nostro esempio, Gmail. È contrassegnato con
Intent.FLAG_ACTIVITY_NEW_TASK. - Il secondo Intento è quello dannoso. Nel nostro esempio, è per l'attività di accesso simile. Questo intento non ha flag.
- Il terzo Intento è la distrazione. Si assicura che l'utente non sospetti che Gmail si apra in modo casuale invece dell'app che ha toccato (ovvero quella che ha lanciato l'attacco). È contrassegnato con
Intent.FLAG_ACTIVITY_NEW_TASK.
Tutti questi intenti vengono quindi passati in un array al file startActivities() metodo.
La chiave qui è la mancanza di flag del secondo Intent. In questo modo, abbiamo semplicemente replicato l'esempio di Gmail visto sopra. Tecnicamente l'attività è di Gmail, ma l'attività più in alto è dell'aggressore. Quando l'utente fa clic sull'icona della schermata iniziale di Gmail, viene visualizzata l'attività dell'autore dell'attacco invece di quella di Gmail.
Verifica teorica
Con le informazioni che Promon ci ha inviato, siamo stati in grado di replicare la loro prova di concetto. Ecco una registrazione dello schermo di un Samsung Galaxy Note8 con Android 9 Pie che lo mostra in azione.
Tecniche e problemi di mitigazione
Ora, replicare semplicemente quanto sopra nel codice non funzionerà effettivamente. Non è un esempio completo e ci sono alcune altre cose che un utente malintenzionato deve fare per farlo funzionare, che non possiamo condividere. Ma non sono particolarmente difficili da indovinare da soli, e questo è parte di ciò che rende questo attacco così pericoloso. StrandHogg 2.0 è un exploit relativamente facile da implementare e difficile da mitigare.
La mitigazione non può comportare semplicemente l'inserimento nella lista nera di tutte le app che utilizzano startActivities(), poiché ci sono molti usi legittimi per esso. È anche davvero difficile automatizzare un algoritmo di rilevamento per questo. Gli sviluppatori dannosi possono utilizzare tutti i tipi di trucchi per rendere la loro implementazione di StrandHogg 2.0 effettivamente invisibile a servizi come Google Play Protect. StrandHogg 1.0 richiedeva all'aggressore di aggiungere un attributo nel file AndroidManifest.xml dell'app dannosa, che era relativamente facile da rilevare. StrandHogg 2.0, invece, funziona interamente in Java/Kotlin.
Tenendo conto dell’offuscamento, della riflessione e anche solo dei diversi stili di codifica, sembra poco pratico rilevare automaticamente e correttamente un’app che utilizza questo exploit. Inoltre, se un utente è oggetto di un attacco StrandHogg 2.0, potrebbe non saperlo nemmeno. Se apri Gmail e vedi la sua schermata di accesso, potresti semplicemente pensare che la tua sessione sia scaduta e inserire i tuoi dati di accesso senza pensarci due volte.
Quando abbiamo contattato Google per una risposta, un portavoce ha offerto la seguente dichiarazione:
"Apprezziamo il lavoro dei ricercatori e abbiamo rilasciato una soluzione per il problema identificato. Inoltre, Google Play Protect rileva e blocca le app dannose, comprese quelle che utilizzano questa tecnica."
Sembra una buona cosa e si spera che abbia almeno qualche effetto contro gli attacchi di StrandHogg 2.0. Vale la pena notare, tuttavia, che Google Play Protect no rilevare la nostra app proof of concept come dannosa, anche dopo aver eseguito una scansione manuale.
Promon dice che loro "non ho osservato alcun malware reale che utilizzi la vulnerabilità StrandHogg 2.0," ma non vi è alcuna garanzia che questa sia la prima volta che l'exploit viene scoperto. Per questo motivo, Promon consiglia agli sviluppatori di andare avanti e proteggere le proprie app impostando le attività del programma di avvio launchMode contrassegnare entrambi singleTask O singleInstance. Entrambi questi flag impediranno l'inserimento delle attività, che è ciò su cui si basa StrandHogg 2.0. Tuttavia, il fatto che l'attività utilizzi uno di questi flag può causare problemi con determinati flussi dell'app, quindi non è sempre auspicabile.
Promon sta anche promuovendo il proprio prodotto "In-App Protection by Promon SHIELD" che suona come una libreria che gli sviluppatori di app possono implementare per monitorare le attività nel processo della tua app per verificare eventuali irregolarità inserimenti. Poiché non esiste una strategia di mitigazione degli sviluppatori o degli utenti veramente efficace, è piuttosto importante che i produttori implementino la patch per risolvere il problema il prima possibile.
Per fortuna, Promon ha seguito le linee guida sulla divulgazione responsabile prima di rendere pubblico questo exploit (e non è ancora del tutto pubblico: Promon sta aspettando 90 giorni prima di rivelare completamente come StrandHogg 2.0 lavori). Da allora Google ha eseguito il backport delle patch per questo exploit su Android 8.0 Oreo, Android 8.1 Oreo e Android 9 Pie con il Livello patch di sicurezza Android (SPL) di maggio 2020. Gli utenti su Android 10 e versioni successive non sono vulnerabili, anche se non siamo del tutto sicuri del motivo. Probabilmente ha qualcosa a che fare con le nuove restrizioni di Android 10 relative all'avvio delle attività e al modo in cui Google le ha integrate nello stack delle attività. Promon afferma che "su Android 10 l'attacco è del tutto inefficace e le attività sono suddivise in compiti diversi e in stack di attività separati a seconda adb shell dumpsys activity activities."
Se il produttore del tuo dispositivo fornisce ancora aggiornamenti di sicurezza (puoi leggere ulteriori informazioni su come funziona il processo delle patch di sicurezza qui), dovresti assillarli per un aggiornamento il prima possibile. Altrimenti, dovrai solo stare attento a quali app scarichi ed esegui (anche se dovresti farlo comunque).
Per maggiori dettagli e casi d'uso di StrandHogg 2.0, consulta il annuncio ufficiale sul sito web di Promon. Per gli sviluppatori di ROM personalizzate, è possibile trovare i commit AOSP pertinenti per prevenire gli attacchi StrandHogg 2.0 Qui E Qui.
Cronologia della divulgazione
Ecco la sequenza temporale della divulgazione che Promon ha condiviso nel suo documento StandHogg 2.0:
- 4 dicembre 2019 – Problema segnalato a Google
- 4 dicembre 2019 – Condiviso un PoC «app dannosa» e un video con Google
- 4 dicembre 2019 – Google ha confermato di aver ricevuto il rapporto
- 9 dicembre 2019 – Google ha impostato la gravità del rilievo come «Critico»
- 9 dicembre 2019 – Google conferma di essere in grado di riprodurre il problema
- 14 febbraio 2020 – Informiamo Google che all'inizio di marzo si avvicina la divulgazione dei 90 giorni e chiediamo lo status da parte loro
- 14 febbraio 2020 – Google risponde che il mese di aprile è il momento migliore per implementare una soluzione
- 14 febbraio 2020 – Informiamo Google che stiamo lavorando su mitigazioni
- 14 febbraio 2020 – risponde Google. Stanno lavorando alle soluzioni correttive e chiedono se possiamo condividere quali mitigazioni stiamo raccomandando
- 17 febbraio 2020 – Informiamo Google che possiamo trattenere la divulgazione fino ad aprile. Richiediamo il numero CVE
- 17 febbraio 2020 – Condividiamo le nostre strategie di mitigazione, nonché il modo in cui immaginiamo una mitigazione della piattaforma
- 23 marzo 2020 – Google risponde con l'ID CVE (CVE-2020-0096)
- 23 marzo 2020 – Google risponde che la disponibilità generale della correzione per Android sarà disponibile a maggio
- 23 marzo 2020 – Google chiede se prenderemo in considerazione di ritardare la divulgazione a maggio
- 27 marzo 2020 – Rispondiamo che ritarderemo la divulgazione fino a maggio
- 22 aprile 2020 – Google ci informa che il Bollettino sulla sicurezza di maggio dovrebbe contenere una patch per la vulnerabilità