Foi identificada uma vulnerabilidade na plataforma Android (CVE-2022-20465) que permite desabilitar o bloqueio de tela trocando o cartão SIM e inserindo o código PUK. A capacidade de desativar o 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 afete o firmware de outros fabricantes. O problema foi resolvido no Android Security Patch Roll de novembro. O pesquisador que chamou a atenção para o problema recebeu uma recompensa de US$ 70 do Google.
O problema é causado pelo processamento de desbloqueio incorreto após a inserção de um código PUK (chave de desbloqueio pessoal), que é usado para reativar um cartão SIM que foi bloqueado após várias entradas incorretas de PIN. Para desativar o bloqueio de tela, basta inserir o cartão SIM no telefone, que possui proteção baseada em PIN. Depois de trocar o cartão SIM protegido por PIN, uma solicitação de código PIN é exibida primeiro na tela. Se o código PIN for inserido incorretamente três vezes, o cartão SIM será bloqueado, após o que você terá a oportunidade de inserir o código PUK para desbloqueá-lo. Descobriu-se que a entrada correta do código PUK não apenas desbloqueia o cartão SIM, mas leva a uma transição para a interface principal ignorando o protetor de tela, sem confirmar o acesso usando a senha ou padrão principal.
A vulnerabilidade é causada por um erro na lógica de verificação dos códigos PUK no manipulador KeyguardSimPukViewController, que é responsável por exibir uma tela de autenticação adicional. O Android usa vários tipos de telas de autenticação (para PIN, PUK, senha, padrão, autenticação biométrica) e essas telas são invocadas sequencialmente quando várias verificações são necessárias, como quando PIN e padrão são necessários.
Se o código PIN for digitado corretamente, a segunda etapa de verificação é acionada, exigindo a entrada do código de desbloqueio principal, mas ao inserir o código PUK, essa etapa é pulada e o acesso é concedido sem solicitar a senha principal ou padrão. O próximo estágio de desbloqueio é descartado porque quando KeyguardSecurityContainerController#dismiss() é chamado, o método de verificação esperado e aprovado não é comparado, ou seja, o responsável considera que a alteração do método de verificação não ocorreu e a conclusão da verificação do código PUK indica uma confirmação bem-sucedida da autoridade.
A vulnerabilidade foi descoberta por acidente - o telefone do usuário ficou sem bateria e, após carregá-lo e ligá-lo, ele cometeu um erro ao inserir o código PIN várias vezes, após o qual desbloqueou o código PUK e ficou surpreso ao ver que o sistema não solicite a senha principal usada para descriptografar os dados, após o que travou com a mensagem "Pixel está iniciando ...". O usuário se mostrou meticuloso, decidiu descobrir o que estava acontecendo e começou a experimentar a inserção de códigos PIN e PUK de várias maneiras, até que acidentalmente esqueceu de reiniciar o dispositivo após trocar o cartão SIM e teve acesso ao ambiente em vez de congelando.
De particular interesse é a resposta do Google ao relatório de vulnerabilidade. Informações sobre o problema foram enviadas em junho, mas até setembro o pesquisador não conseguiu uma resposta clara. Ele acreditava que esse comportamento se devia ao fato de não ter sido o primeiro a relatar esse erro. As suspeitas de que algo estava errado surgiram em setembro, quando o problema permaneceu sem correção após o lançamento de uma atualização de firmware 90 dias depois, após o período de não divulgação declarado já ter expirado.
Como todas as tentativas de descobrir o status do relatório de problemas enviado levaram apenas a cancelamentos automatizados e de modelo, o pesquisador tentou entrar em contato pessoalmente com os funcionários do Google para esclarecer a situação com a preparação de uma correção e até demonstrou uma vulnerabilidade no escritório do Google em Londres. Só depois disso, o trabalho para eliminar a vulnerabilidade avançou. Durante a análise, descobriu-se que alguém já havia relatado o problema antes, mas o Google decidiu abrir uma exceção e pagar uma recompensa por relatar novamente o problema, pois foi somente graças à perseverança de seu autor que o problema foi percebido .
Fonte: opennet.ru