ALLERTA PERICOLI INFORMATICI Articoli in Evidenza

AGGIORNA SUBITO ANDROID : scoperto bug in grado di bypassare la schermata di blocco con una nuova scheda SIM e una graffetta

AGGIORNA SUBITO ANDROID : scoperto bug in grado di bypassare la schermata di blocco con una nuova scheda SIM e una graffetta
Scritto da gestore

Un “cacciatore di taglie di bug” chiamato David Schütz è stato in grado di sfruttare una falla in un generico bypass della schermata di blocco mediante il quale chiunque abbia raccolto (o rubato o altrimenti avuto un breve accesso a …) un dispositivo Android bloccato potrebbe portarlo allo stato sbloccato armato di nient’altro che un nuova scheda SIM e una graffetta.

David Schütz ha appena pubblicato un rapporto dettagliato che descrive come ha incrociato le spade con Google per diversi mesi su quella che considerava una pericolosa falla nella sicurezza di Android.

Intermezzo promozionale ... continua la lettura dopo il box:

Secondo Schütz, si è imbattuto in un bug di bypass totale della schermata di blocco di Android completamente per caso nel giugno 2022, in condizioni di vita reale che sarebbero potute facilmente accadere a chiunque.

In altre parole, era ragionevole presumere che altre persone potessero scoprire il difetto senza partire deliberatamente alla ricerca di bug, rendendo la sua scoperta e divulgazione pubblica (o abuso privato) come un buco zero-day molto più probabile del solito.

Sfortunatamente, non è stato corretto fino a novembre 2022, motivo per cui l’ha divulgato solo ora.

Un’interruzione fortuita della batteria

In poche parole, ha trovato il bug perché si è dimenticato di spegnere o caricare il telefono prima di partire per un lungo viaggio, lasciando il dispositivo a corto di energia inosservato mentre era in viaggio.

Secondo Schütz, si stava affrettando a inviare alcuni messaggi dopo essere tornato a casa (supponiamo che fosse su un aereo) con la piccola quantità di energia rimasta nella batteria…

…quando il telefono è morto.

Siamo stati tutti lì, cercando un caricabatterie o una batteria di riserva per riavviare il telefono per far sapere alla gente che siamo arrivati ​​sani e salvi, stiamo aspettando il ritiro dei bagagli, abbiamo raggiunto la stazione ferroviaria, ci aspettiamo di tornare a casa tra 45 minuti, potrebbe fermarsi nei negozi se qualcuno ha urgente bisogno di qualcosa, o qualunque cosa abbiamo da dire.

Intermezzo promozionale ... continua la lettura dopo il box:

E abbiamo tutti lottato con password e PIN quando siamo di fretta, soprattutto se sono codici che usiamo raramente e non abbiamo mai sviluppato “memoria muscolare” per la digitazione.

Nel caso di Schütz, è stato l’umile PIN sulla sua scheda SIM a lasciarlo perplesso e poiché i PIN della SIM possono essere brevi fino a quattro cifre, sono protetti da un blocco hardware che ti limita a tre ipotesi al massimo. (Ci siamo stati, l’abbiamo fatto, ci siamo chiusi fuori.)

Successivamente, è necessario inserire un “PIN principale” di 10 cifre noto come PUK, abbreviazione di chiave di sblocco personale , che di solito è stampato all’interno della confezione in cui viene venduta la SIM, il che la rende in gran parte a prova di manomissione.

E per proteggersi dagli attacchi di indovinare PUK, la SIM si frigge automaticamente dopo 10 tentativi sbagliati e deve essere sostituita, il che in genere significa presentarsi a un negozio di telefoni cellulari con l’identificazione.

Cosa ho fatto con quella confezione?

Fortunatamente, poiché senza di esso non avrebbe trovato il bug, Schütz ha individuato la confezione della SIM originale nascosta da qualche parte in un armadio, ha graffiato la striscia protettiva che oscura il PUK e l’ha digitata.

A questo punto, dato che stava avviando il telefono dopo che si era scaricato, avrebbe dovuto vedere la schermata di blocco del telefono che gli chiedeva di digitare il codice di sblocco del telefono…

…ma, invece, si è reso conto di essere nel tipo sbagliato di lockscreen , perché gli stava offrendo la possibilità di sbloccare il dispositivo usando solo la sua impronta digitale.

Ciò dovrebbe accadere solo se il telefono si blocca durante l’uso regolare e non dovrebbe accadere dopo uno spegnimento e un riavvio, quando una riautenticazione completa del passcode (o uno di quei “codici pattern” di scorrimento per sbloccare ) dovrebbe essere applicato.

C’è davvero un “blocco” nella schermata di blocco?

Come probabilmente saprai dalle molte volte in cui abbiamo scritto di bug della schermata di blocco nel corso degli anni su Naked Security, il problema con la parola “blocco” nella schermata di blocco è che semplicemente non è una buona metafora per rappresentare quanto sia complesso il codice che gestisce il processo di “blocco” e “sblocco” dei telefoni moderni.

Una moderna schermata di blocco mobile è un po’ come la porta d’ingresso di una casa che ha una serratura a catenaccio di qualità decente montata…

…ma ha anche una cassetta delle lettere (posta elettronica), pannelli di vetro per far entrare la luce, una gattaiola, una serratura a molla loidable su cui hai imparato a fare affidamento perché il catenaccio è un po’ una seccatura e un campanello wireless esterno/ telecamera di sicurezza facile da rubare anche se contiene la tua password Wi-Fi in chiaro e gli ultimi 60 minuti di riprese video che ha registrato.

Oh, e, in alcuni casi, anche una porta d’ingresso dall’aspetto sicuro avrà comunque le chiavi “nascoste” sotto lo zerbino, che è praticamente la situazione in cui si è trovato Schütz sul suo telefono Android.

Una mappa di passaggi tortuosi

Le moderne schermate di blocco del telefono non riguardano tanto il blocco del telefono quanto la limitazione delle app a modalità operative limitate.

Questo in genere lascia a te e alle tue app l’accesso alla schermata di blocco a un’ampia gamma di funzionalità “casi speciali”, come l’attivazione della fotocamera senza sbloccare o la visualizzazione di una serie curata di messaggi di notifica o righe dell’oggetto e-mail in cui chiunque potrebbe vederli senza il codice di accesso.

Ciò che Schütz si era imbattuto, in una sequenza di operazioni perfettamente ineccepibile, era un difetto di quella che in gergo è conosciuta come la macchina a stati dello schermo di blocco .

Una macchina a stati è una sorta di grafico, o mappa, delle condizioni in cui può trovarsi un programma, insieme ai modi legali in cui il programma può spostarsi da uno stato all’altro, come una connessione di rete che passa da “ascolto” a ” connesso”, e poi da “connesso” a “verificato”, oppure uno schermo del telefono che passa da “bloccato” a “sbloccabile con impronta” o a “sbloccabile ma solo con passcode”.

Come puoi immaginare, le macchine a stati per compiti complessi si complicano rapidamente e la mappa dei diversi percorsi legali da uno stato all’altro può finire piena di colpi di scena…

…e, a volte, esotici passaggi segreti che nessuno ha notato durante i test.

In effetti, Schütz è stato in grado di sfruttare la sua scoperta involontaria del PUK in un generico bypass della schermata di blocco mediante il quale chiunque abbia raccolto (o rubato o altrimenti avuto un breve accesso a) un dispositivo Android bloccato potrebbe portarlo allo stato sbloccato armato di nient’altro che un nuova scheda SIM e una graffetta.

Nel caso te lo stia chiedendo, la graffetta serve per espellere la SIM già nel telefono in modo da poter inserire la nuova SIM e ingannare il telefono nello stato “Devo richiedere il PIN per questa nuova SIM per motivi di sicurezza”. Schütz ammette che quando è andato negli uffici di Google per dimostrare l’hacking, nessuno aveva un vero espulsore della SIM, quindi hanno prima provato un ago, con il quale Schütz è riuscito a pugnalarsi, prima di riuscire con un orecchino preso in prestito. Sospettiamo che infilare prima l’ago nella punta non abbia funzionato (è difficile colpire il perno di espulsione con una punta minuscola), quindi ha deciso di rischiare di usarlo puntando verso l’esterno “facendo molta attenzione”, trasformando così un tentativo di hacking in un letterale hackerare. (Ci siamo stati, l’abbiamo fatto, ci siamo puntati sulla punta del dito.)

Giocare il sistema con una nuova SIM

Dato che l’attaccante conosce sia il PIN che il PUK della nuova SIM, può sbagliare deliberatamente il PIN tre volte e quindi correggere immediatamente il PUK, costringendo così deliberatamente la macchina a stati della schermata di blocco nella condizione di non sicurezza che Schütz ha scoperto accidentalmente.

Con il giusto tempismo, Schütz ha scoperto che non solo poteva atterrare sulla pagina di sblocco dell’impronta digitale quando non doveva apparire, ma anche ingannare il telefono facendogli accettare lo sblocco PUK riuscito come segnale per ignorare lo schermo dell’impronta digitale e “convalidare” l’intero processo di sblocco come se avesse digitato il codice di blocco completo del telefono.

Sblocca bypass!

Sfortunatamente, gran parte dell’articolo di Schütz descrive il tempo impiegato da Google per reagire e correggere questa vulnerabilità, anche dopo che gli stessi ingegneri dell’azienda avevano deciso che il bug era effettivamente ripetibile e sfruttabile.

Come disse lo stesso Schütz: Questa è stata la vulnerabilità di maggior impatto che ho trovato finora, e ha superato il limite per me in cui ho iniziato a preoccuparmi della sequenza temporale della correzione e anche solo di mantenerla come un “segreto” io stesso. Potrei reagire in modo esagerato, ma voglio dire che non molto tempo fa l’FBI stava litigando con Apple per quasi la stessa cosa.

Ritardi di divulgazione

Dato l’atteggiamento di Google nei confronti della divulgazione di bug, con il suo stesso team di Project Zero notoriamente fermo sulla necessità di fissare tempi di divulgazione rigorosi e attenersi ad essi , ci si sarebbe potuti aspettare che l’azienda si attenesse ai suoi 90 giorni-più-14-in-extra-in- regole sui casi speciali.

Ma, secondo Schütz, Google non poteva gestirlo in questo caso.

Apparentemente, aveva concordato una data nell’ottobre 2022 entro la quale aveva pianificato di rivelare pubblicamente il bug, come ha fatto ora, il che sembra un sacco di tempo per un bug che ha scoperto nel giugno 2022.

Ma Google ha mancato quella scadenza di ottobre.

La patch per il difetto, designato con il numero di bug CVE-2022-20465, è finalmente apparsa nelle patch di sicurezza di Android di novembre 2022, datate 2022-11-05, con Google che descrive la correzione come: “Non eliminare keyguard dopo lo sblocco del PUK SIM”.

In termini tecnici, il bug era ciò che è noto come race condition , in cui la parte del sistema operativo che stava osservando il processo di inserimento del PUK per tenere traccia del “è sicuro sbloccare la SIM ora?” lo stato ha finito per produrre un segnale di successo che ha prevalso sul codice che teneva simultaneamente traccia di “è sicuro sbloccare l’intero dispositivo?”

Tuttavia, Schütz è ora significativamente più ricco grazie al pagamento della taglia dei bug di Google (il suo rapporto suggerisce che sperava in $ 100.000, ma alla fine si è dovuto accontentare di $ 70.000).

E ha evitato di rivelare il bug dopo la scadenza del 15 ottobre 2022, accettando che la discrezione sia la parte a volte migliore del valore, dicendo:

[Ero] troppo spaventato per eliminare effettivamente il bug live e poiché la correzione era a meno di un mese di distanza, comunque non ne valeva davvero la pena. Ho deciso di aspettare la correzione.

Cosa fare? COME AGGIORNARE ANDROID

Verifica che il tuo Android sia aggiornato: Impostazioni > Sicurezza > Aggiornamento sicurezza > Verifica aggiornamenti .

Nota che quando abbiamo visitato la schermata di aggiornamento della sicurezza , non avendo utilizzato il nostro telefono Pixel per un po’, Android ha dichiarato audacemente che il tuo sistema è aggiornato , mostrando che era stato controllato automaticamente un minuto o giù di lì, ma continuando a dirci che eravamo in October 5, 2022aggiornamento di sicurezza.

Abbiamo forzato un nuovo controllo dell’aggiornamento manualmente e ci è stato immediatamente detto Preparazione dell’aggiornamento del sistema… , seguito da un breve download, una lunga fase preparatoria e quindi una richiesta di riavvio.

Dopo il riavvio abbiamo raggiunto il November 5, 2022livello di patch.

Siamo quindi tornati indietro e abbiamo eseguito un’altra verifica dell’aggiornamento per confermare che non c’erano correzioni ancora in sospeso.

Fonte : https://nakedsecurity.sophos.com/