Pericoloso bypass della schermata di blocco dello scambio di SIM: aggiorna ora Android!

Un cacciatore di taglie di insetti chiamato David Schütz ha appena pubblicato un relazione dettagliata descrivendo come ha incrociato le spade con Google per diversi mesi su quella che considerava una pericolosa falla nella sicurezza di Android.

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.

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 rese conto di esserlo nel tipo sbagliato di lockscreen, perché gli stava offrendo la possibilità di sbloccare il dispositivo utilizzando 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 dal molte volte Abbiamo scritto su bug della schermata di blocco negli 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.

Quello che Schütz si era imbattuto, in una sequenza di operazioni perfettamente ineccepibile, era un difetto di ciò che in gergo è noto come lockscreen macchina a stati.

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 "convalida" 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 proprio team di Project Zero notoriamente fermo sulla necessità di stabilire tempi di divulgazione rigorosi e attenersi a loro, avresti potuto aspettarti che l'azienda si attenesse alle regole di 90 giorni più 14 in 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 descrivendo la correzione come: "Non eliminare keyguard dopo lo sblocco del PUK SIM."

In termini tecnici, il bug era ciò che è noto a condizione di gara, dove la parte del sistema operativo che stava osservando il processo di immissione del PUK per tenere traccia di "è 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?

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

Si noti che quando abbiamo visitato il Aggiornamento di sicurezza schermo, non avendo utilizzato il nostro telefono Pixel per un po ', ha proclamato audacemente Android Il tuo sistema è aggiornato, dimostrando che era stato controllato automaticamente un minuto o giù di lì, ma continuando a dirci che eravamo in October 5, 2022 aggiornamento di sicurezza.

Abbiamo forzato manualmente un nuovo controllo di aggiornamento 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, 2022 livello di patch.

Quindi siamo tornati indietro e ne abbiamo fatto un altro Ricerca aggiornamenti per confermare che non c'erano correzioni ancora in sospeso.

---

Abbiamo usato Impostazioni profilo > Sicurezza > Aggiornamento di sicurezza per arrivare alla pagina di download forzato:

---

La data riportata sembrava sbagliata, quindi abbiamo costretto Android a farlo Ricerca aggiornamenti Comunque:

---

C'era davvero un aggiornamento da installare:

---

Invece di aspettare abbiamo usato CV per procedere subito:

---

È seguito un lungo processo di aggiornamento:

---

Ne abbiamo fatto un altro Ricerca aggiornamenti per confermare che c'eravamo:

---