Vulnerabilità in Android che consente di aggirare il blocco dello schermo

È stata individuata una vulnerabilità nella piattaforma Android (CVE-2022-20465), che consente di disattivare il blocco dello schermo riorganizzando la scheda SIM e inserendo il codice PUK. La possibilità di disattivare il blocco è stata dimostrata sui dispositivi Google Pixel, ma poiché la correzione interessa il codebase principale di Android, è probabile che il problema riguardi firmware di altri produttori. Il problema viene risolto nel lancio della patch di sicurezza Android di novembre. Il ricercatore che ha attirato l'attenzione sul problema ha ricevuto da Google una ricompensa di 70mila dollari.

Il problema è causato da un'errata procedura di sblocco dopo aver inserito il codice PUK (Personal Unblocking Key), che viene utilizzato per riprendere il funzionamento di una carta SIM che è stata bloccata dopo aver inserito ripetutamente un codice PIN errato. Per disattivare il blocco dello schermo è sufficiente installare la scheda SIM nel telefono, dotata di protezione tramite codice PIN. Dopo aver cambiato una carta SIM protetta da un codice PIN, sullo schermo viene prima visualizzata una richiesta di codice PIN. Se inserisci per tre volte il codice PIN errato, la SIM card verrà bloccata, dopodiché ti verrà data la possibilità di inserire il codice PUK per sbloccarla. Si è scoperto che l'inserimento corretto del codice PUK non solo sblocca la scheda SIM, ma porta al passaggio all'interfaccia principale, bypassando lo screen saver, senza confermare l'accesso utilizzando la password o la sequenza principale.

La vulnerabilità è causata da un errore nella logica di controllo dei codici PUK nel gestore KeyguardSimPukViewController, responsabile della visualizzazione della schermata di autenticazione aggiuntiva. Android utilizza diversi tipi di schermate di autenticazione (per PIN, PUK, password, sequenza, autenticazione biometrica) e queste schermate vengono richiamate in sequenza quando è necessario eseguire più controlli, ad esempio quando sono richiesti un PIN e una sequenza.

Se inserisci correttamente il codice PIN, viene attivata la seconda fase di verifica, che richiede di inserire il codice di sblocco principale, ma quando inserisci il codice PUK, questa fase viene saltata e l'accesso viene concesso senza chiedere la password principale o la chiave sequenza . La fase di sblocco successiva viene scartata perché quando si chiama KeyguardSecurityContainerController#dismiss() non viene effettuato alcun confronto tra i metodi di verifica previsti e quelli superati, ad es. l'elaboratore ritiene che il metodo di verifica non sia cambiato e il completamento della verifica del codice PUK indica una conferma di autorizzazione avvenuta con successo.

La vulnerabilità è stata scoperta per caso: il telefono dell'utente era morto e dopo averlo caricato e acceso, ha commesso più volte un errore inserendo il codice PIN, dopodiché lo ha sbloccato con il codice PUK ed è rimasto sorpreso che il sistema non lo chiedesse per la password principale utilizzata per decrittografare i dati, dopodiché si è bloccato con il messaggio "Pixel sta iniziando...". L'utente si è rivelato meticoloso, ha deciso di capire cosa stava succedendo e ha iniziato a sperimentare l'inserimento dei codici PIN e PUK in diversi modi, finché non si è dimenticato accidentalmente di riavviare il dispositivo dopo aver cambiato la scheda SIM e ha ottenuto l'accesso all'ambiente invece di congelamento.

Di particolare interesse è la reazione di Google all'annuncio della vulnerabilità. Le informazioni sul problema sono state inviate a giugno, ma fino a settembre il ricercatore non è riuscito ad ottenere una risposta chiara. Credeva che questo comportamento fosse spiegato dal fatto che non era stato il primo a segnalare questo errore. I sospetti che qualcosa stesse andando storto sono sorti a settembre, quando il problema non è stato risolto dopo l'installazione di un aggiornamento del firmware rilasciato 90 giorni dopo, quando il periodo di riservatezza dichiarato era già scaduto.

Poiché tutti i tentativi di conoscere lo stato del messaggio inviato relativo al problema hanno portato solo a risposte automatizzate e modello, il ricercatore ha provato a contattare personalmente i dipendenti di Google per chiarire la situazione preparando una soluzione e ha persino dimostrato la vulnerabilità nella sede di Google a Londra . Solo dopo è stato possibile eliminare la vulnerabilità e procedere. Durante l'analisi si è scoperto che qualcuno aveva già segnalato il problema in precedenza, ma Google ha deciso di fare un'eccezione e pagare una ricompensa per aver segnalato nuovamente il problema, poiché è stato solo grazie alla tenacia del suo autore che il problema è stato notato.

Fonte: opennet.ru

Aggiungi un commento