Identificouse unha vulnerabilidade na plataforma Android (CVE-2022-20465), que permite desactivar o bloqueo da pantalla reorganizando a tarxeta SIM e introducindo o código PUK. A capacidade de desactivar o bloqueo demostrouse nos dispositivos Google Pixel, pero dado que a corrección afecta á base de código principal de Android, é probable que o problema afecte ao firmware doutros fabricantes. O problema resolveuse no lanzamento do parche de seguridade de Android en novembro. O investigador que chamou a atención sobre o problema recibiu unha recompensa de 70 mil dólares de Google.
O problema é causado por un procesamento de desbloqueo incorrecto despois de introducir o código PUK (Chave de desbloqueo persoal), que se usa para retomar o funcionamento dunha tarxeta SIM que foi bloqueada despois de introducir repetidamente o código PIN incorrecto. Para desactivar o bloqueo da pantalla, só tes que instalar a túa tarxeta SIM no teu teléfono, que ten protección con código PIN. Despois de cambiar unha tarxeta SIM protexida por un código PIN, aparece primeiro na pantalla unha solicitude de código PIN. Se introduces o código PIN incorrectamente tres veces, a tarxeta SIM bloquearase, despois de que terás a oportunidade de introducir o código PUK para desbloquealo. Resultou que introducir correctamente o código PUK non só desbloquea a tarxeta SIM, senón que leva a unha transición á interface principal, evitando o protector de pantalla, sen confirmar o acceso mediante o contrasinal ou o patrón principal.
A vulnerabilidade prodúcese por un erro na lóxica para comprobar os códigos PUK no controlador KeyguardSimPukViewController, que se encarga de mostrar a pantalla de autenticación adicional. Android usa varios tipos de pantallas de autenticación (para PIN, PUK, contrasinal, patrón, autenticación biométrica) e estas pantallas chámanse secuencialmente cando se precisan realizar varias comprobacións, por exemplo, cando se require un PIN e un patrón.
Se introduce o código PIN correctamente, activarase a segunda fase de verificación, que require que introduza o código de desbloqueo principal, pero cando introduce o código PUK, omítase esta fase e concédese o acceso sen pedir o contrasinal principal ou a clave de patrón. . Descártase a seguinte fase de desbloqueo porque ao chamar KeyguardSecurityContainerController#dismiss() non hai comparación entre os métodos de verificación esperados e aprobados, é dicir. o procesador considera que o método de verificación non cambiou e a conclusión da verificación do código PUK indica unha confirmación exitosa da autoridade.
A vulnerabilidade foi descuberta por accidente: o teléfono do usuario estaba morto e despois de cargalo e acendelo, cometeu un erro varias veces ao introducir o código PIN, despois de que o desbloqueou co código PUK e sorprendeuse de que o sistema non lle preguntara. para o contrasinal principal utilizado para descifrar os datos, despois de que conxelouse coa mensaxe "Pixel is starting...". O usuario resultou ser meticuloso, decidiu descubrir o que estaba a suceder e comezou a experimentar coa introdución de códigos PIN e PUK de diferentes xeitos, ata que accidentalmente esqueceu reiniciar o dispositivo despois de cambiar a tarxeta SIM e accedeu ao entorno en lugar de conxelación.
De particular interese é a reacción de Google ao anuncio de vulnerabilidade. A información sobre o problema enviouse en xuño, pero ata setembro o investigador aínda non puido obter unha resposta clara. Cría que este comportamento se explicaba polo feito de non ser o primeiro en informar deste erro. As sospeitas de que algo estaba a ir mal xurdiron en setembro, cando o problema non se corrixiu despois de instalar unha actualización de firmware lanzada 90 días despois, cando xa expirou o prazo de non divulgación indicado.
Dado que todos os intentos de coñecer o estado da mensaxe enviada sobre o problema só levaron a respostas automatizadas e modelo, o investigador intentou contactar persoalmente cos empregados de Google para aclarar a situación coa preparación dunha solución e mesmo demostrou a vulnerabilidade na oficina de Google en Londres. . Só despois disto traballouse para eliminar a vulnerabilidade. Durante a análise, resultou que alguén xa denunciara o problema con anterioridade, pero Google decidiu facer unha excepción e pagar unha recompensa por denunciar o problema de novo, xa que só foi grazas á persistencia do seu autor que se deu conta do problema.
Fonte: opennet.ru