È stata identificata una vulnerabilità nella piattaforma Android (CVE-2022-20465) che consente di disattivare il blocco dello schermo attraverso la sostituzione della SIM e l'inserimento del codice PUK. La possibilità di disattivare il blocco è stata dimostrata su dispositivi Google Pixel, ma poiché la correzione riguarda il codice sorgente principale di Android, è probabile che il problema riguardi anche i firmware di altri produttori. Il problema è stato risolto nel pacchetto di aggiornamenti di novembre per la sicurezza di Android. Il ricercatore che ha segnalato il problema ha ricevuto un premio di 70.000 dollari da Google.
Il problema è causato da un'errata gestione dello sblocco dopo l'inserimento del codice PUK (Personal Unblocking Key), utilizzato per riattivare la SIM bloccata dopo ripetuti tentativi errati di inserimento del codice PIN. Per disattivare il blocco dello schermo è sufficiente inserire la propria SIM nel telefono, protetta da un codice PIN. Dopo aver cambiato la SIM protetta da PIN, viene inizialmente visualizzato un prompt per il codice PIN. Se il codice PIN viene digitato in modo errato per tre volte, la SIM verrà bloccata, dopo di che verrà fornita la possibilità di inserire il codice PUK per sbloccarla. È emerso che l'inserimento corretto del codice PUK non solo sblocca la SIM, ma porta anche al passaggio all'interfaccia principale, bypassando il blocco dello schermo, senza confermare l'accesso tramite la password principale o il modello grafico.
La vulnerabilità è causata da un errore nella logica di verifica dei codici PUK nel gestore KeyguardSimPukViewController, responsabile della visualizzazione dello schermo di autenticazione aggiuntivo. In Android vengono utilizzati diversi tipi di schermi di autenticazione (per PIN, PUK, password, modello grafico, autenticazione biometrica) e questi schermi vengono chiamati in sequenza quando è necessario eseguire più verifiche, ad esempio, quando è necessario inserire sia il PIN che il modello grafico.
Con l'inserimento corretto del codice PIN scatta la seconda fase di verifica, che richiede l'inserimento del codice principale di sblocco. Tuttavia, nel caso di immissione del codice PUK, questa fase viene saltata e l'accesso viene fornito senza richiedere la password principale o il key grafico. La fase successiva di sblocco viene ignorata poiché, durante la chiamata a KeyguardSecurityContainerController#dismiss(), non viene confrontato il metodo di verifica atteso con quello superato; in altre parole, il gestore considera che non ci sia stata una modifica del metodo di verifica e che il completamento della verifica del codice PUK indichi una conferma riuscita delle credenziali.
La vulnerabilità è stata scoperta per caso: un utente ha esaurito la batteria del telefono e, dopo averlo ricaricato e riacceso, ha commesso più volte errori durante l'inserimento del codice PIN, dopo di che ha sbloccato il dispositivo utilizzando il codice PUK e si è sorpreso che il sistema non ha richiesto la password principale usata per decrittografare i dati, rimanendo poi bloccato con il messaggio "Pixel is starting…". L'utente, che si è dimostrato meticoloso, ha deciso di indagare sul problema e ha iniziato a sperimentare in vari modi con l'inserimento dei codici PIN e PUK, finché non ha dimenticato di riavviare il dispositivo dopo aver cambiato la SIM e ha ottenuto, invece del blocco, accesso all'ambiente.
Particolare interesse suscita la reazione di Google al rapporto sulla vulnerabilità. L'informazione sul problema è stata inviata a giugno, ma fino a settembre il ricercatore non è riuscito a ottenere una risposta chiara. Ha ritenuto che tale comportamento fosse dovuto al fatto di non essere il primo a segnalare l'errore. I sospetti che qualcosa non andasse sono sorti a settembre, quando il problema è rimasto irrisolto dopo l'installazione di un aggiornamento del firmware, rilasciato 90 giorni dopo, quando il periodo di non divulgazione era già scaduto.
Poiché tutti i tentativi di scoprire lo stato del messaggio inviato riguardo al problema conducevano solo a risposte automatizzate e standardizzate, il ricercatore ha tentato di contattare personalmente i dipendenti di Google per chiarire la situazione relativa alla preparazione della correzione e ha persino dimostrato la vulnerabilità presso l'ufficio di Google a Londra. Solo dopo questo la lavoro per risolvere la vulnerabilità ha iniziato a progredire. Durante l'analisi è emerso che qualcun altro aveva già segnalato il problema in precedenza, ma Google ha deciso di fare un'eccezione e di offrire una ricompensa per la segnalazione reiterata del problema, poiché solo grazie alla determinazione del suo autore il problema è stato portato all'attenzione.
Fonte: opennet.ru
