È 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 patch coinvolge il codice sorgente principale di Android, è probabile che il problema riguardi anche i firmware di altri produttori. La questione è stata risolta nel pacchetto di aggiornamenti di sicurezza di novembre per Android. Il ricercatore che ha segnalato il problema ha ricevuto un premio di 70.000 dollari da Google.
Il problema è dovuto a un'elaborazione errata dello sblocco dopo l'inserimento del codice PUK (Personal Unblocking Key), utilizzato per riattivare una scheda SIM bloccata dopo ripetuti tentativi errati di inserimento del codice PIN. Per disabilitare il blocco dello schermo, è sufficiente inserire la propria scheda SIM nel telefono, su cui è attivata la protezione tramite codice PIN. Dopo aver cambiato la scheda SIM protetta dal codice PIN, all'inizio verrà visualizzato un prompt per il codice PIN. Se il codice PIN viene inserito erroneamente tre volte, la scheda SIM verrà bloccata, dopodiché verrà data l'opportunità di inserire il codice PUK per sbloccare. Si è scoperto che l'inserimento corretto del codice PUK non solo sblocca la scheda SIM, ma consente anche di accedere all'interfaccia principale bypassando il custode dello schermo, senza confermare l'accesso tramite la password principale o il codice 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, pattern, autenticazione biometrica) e questi schermi vengono chiamati in sequenza quando è necessario eseguire più verifiche, ad esempio quando sono richiesti sia il PIN che il pattern.
Con l'immissione corretta del PIN, scatta la seconda fase di verifica, che richiede l'inserimento del codice di sblocco principale, ma con l'immissione del PUK, tale fase viene saltata e l'accesso viene fornito senza richiedere la password principale o il pattern. Il salto della fase successiva di sblocco avviene poiché durante la chiamata a KeyguardSecurityContainerController#dismiss() non viene effettuato il confronto tra il metodo di verifica previsto e quello completato, ovvero il gestore considera che non vi sia stata alcuna modifica nel metodo di verifica e che il completamento della verifica del PUK testimoni un'autenticazione riuscita.
La vulnerabilità è stata scoperta per caso: l'utente ha scaricato il telefono e, dopo averlo ricaricato e acceso, ha inserito erroneamente il PIN diverse volte, dopodiché ha sbloccato il dispositivo con il codice PUK e ha scoperto con sorpresa che il sistema non richiedeva la password principale utilizzata per decifrare i dati, rimanendo bloccato con il messaggio «Pixel is starting…». L'utente, curioso, ha deciso di indagare e ha iniziato a sperimentare diversi modi per inserire i codici PIN e PUK, fino a quando accidentalmente non ha dimenticato di riavviare il dispositivo dopo aver cambiato la SIM e ha ottenuto l'accesso all'ambiente anziché rimanere bloccato.
Particolarmente interessante è la reazione di Google alla segnalazione della vulnerabilità. L'informazione sul problema è stata inviata a giugno, ma fino a settembre il ricercatore non è riuscito a ottenere una risposta soddisfacente. Ha ritenuto che questo comportamento fosse spiegabile dal fatto che non era il primo a segnalare l'errore. I sospetti che qualcosa non andasse per il verso giusto sono sorti a settembre, quando il problema è rimasto irrisolto dopo l'installazione di un aggiornamento del firmware, rilasciato 90 giorni dopo, quando era già scaduto il periodo di non divulgazione dichiarato.
Poiché tutti i tentativi di ottenere informazioni sullo stato del messaggio di segnalazione del problema si sono tradotti solo in risposte automatiche e standardizzate, il ricercatore ha tentato di contattare personalmente i dipendenti di Google per chiarire la situazione relativa ai preparativi per la correzione e ha persino dimostrato la vulnerabilità nell'ufficio di Google a Londra. Solo dopo questo la situazione riguardante la vulnerabilità ha cominciato a muoversi. Durante l’analisi è emerso che qualcuno aveva già segnalato il problema in precedenza, ma Google ha deciso di fare un'eccezione e di corrispondere una ricompensa per la segnalazione del problema, poiché solo grazie alla perseveranza del suo autore l'attenzione è stata rivolta al problema.
Fonte: opennet.ru
