Uma vulnerabilidade foi identificada na plataforma Android (CVE-2022-20465), permitindo desativar a bloqueio de tela ao trocar o cartão SIM e inserir o código PUK. A possibilidade de desativar a bloqueio foi demonstrada em dispositivos Google Pixel, mas como a correção afeta a base de código principal do Android, é provável que o problema também se aplique a firmwares de outros fabricantes. O problema foi corrigido no pacote de atualizações de segurança de novembro para Android. O pesquisador que destacou a questão recebeu uma recompensa de 70 mil dólares da Google.
O problema é causado pelo tratamento inadequado da desbloqueio após a inserção do código PUK (Personal Unblocking Key), utilizado para restaurar o funcionamento do cartão SIM bloqueado após múltiplas tentativas incorretas de inserção do PIN. Para desativar o bloqueio de tela, basta colocar seu cartão SIM no telefone, que está protegido por um código PIN. Após trocar para um cartão SIM protegido por PIN, uma solicitação de PIN é exibida na tela. Se o PIN for inserido incorretamente três vezes, o cartão SIM será bloqueado, após o que será possível inserir o código PUK para desbloquear. Foi constatado que a inserção correta do código PUK não apenas desbloqueia o cartão SIM, mas também permite o acesso à interface principal, contornando o bloqueador de tela, sem confirmação de acesso por meio da senha principal ou de um padrão gráfico.
A vulnerabilidade é causada por um erro na lógica de verificação dos códigos PUK no controlador KeyguardSimPukViewController, que é responsável pela exibição da tela adicional de autenticação. O Android usa vários tipos de telas de autenticação (para PIN, PUK, senha, padrão gráfico, autenticação biométrica) e essas telas são chamadas sequencialmente quando múltiplas verificações são necessárias, por exemplo, quando tanto o PIN quanto o padrão gráfico são necessários.
Com a inserção correta do código PIN, inicia-se a segunda fase de verificação, que exige a entrada do código principal de desbloqueio, mas ao inserir o código PUK, esta fase é pulada e o acesso é concedido sem solicitar a senha principal ou o padrão gráfico. A omissão da próxima etapa de desbloqueio ocorre porque, ao chamar o KeyguardSecurityContainerController#dismiss(), não há comparação entre o método de verificação esperado e o passado, ou seja, o manipulador considera que não houve mudança no método de verificação e a conclusão da verificação do código PUK indica uma validação bem-sucedida das credenciais.
A vulnerabilidade foi descoberta acidentalmente — um usuário teve seu telefone descarregado e após carregá-lo e ligá-lo, ele cometeu alguns erros ao digitar o código PIN, depois desbloqueou usando o código PUK e ficou surpreso ao ver que o sistema não solicitou a senha principal utilizada para descriptografar os dados, após o que o dispositivo ficou travado com a mensagem "Pixel is starting…". O usuário, curioso, decidiu investigar a situação e começou a experimentar de várias maneiras a inserção dos códigos PIN e PUK, até que acidentalmente esqueceu de reiniciar o dispositivo após trocar o cartão SIM e obteve acesso ao ambiente em vez de travamento.
A reação do Google à notificação da vulnerabilidade é especialmente interessante. A informação sobre o problema foi enviada em junho, mas até setembro o pesquisador não conseguiu obter uma resposta clara. Ele acreditava que esse comportamento se devia ao fato de que não era o primeiro a relatar esse erro. Suspeitas de que algo estava errado surgiram em setembro, quando o problema permaneceu sem correção após a instalação da atualização de firmware, liberada após 90 dias, quando já havia expirado o período de divulgação declarado.
Como todas as tentativas de descobrir o estado da mensagem enviada sobre o problema resultaram apenas em respostas automatizadas e padronizadas, o pesquisador tentou entrar em contato pessoalmente com funcionários do Google para esclarecer a situação sobre a preparação da correção e até demonstrou a vulnerabilidade no escritório do Google em Londres. Somente depois disso, o trabalho para corrigir a vulnerabilidade começou a avançar. Durante a análise, ficou claro que alguém já havia relatado o problema antes, mas o Google decidiu fazer uma exceção e pagar uma recompensa por um novo relato do problema, pois somente graças à insistência do autor a questão foi finalmente notada.
Fonte: opennet.ru
