Eles detectaram uma vulnerabilidade no Android que permite contornar a tela de bloqueio

vulnerabilidade

Se exploradas, essas falhas podem permitir que invasores obtenham acesso não autorizado a informações confidenciais ou geralmente causem problemas

Recentemente, a notícia de que uma vulnerabilidade foi identificada no Android (CVE-2022-20465) que permite desativar o bloqueio de tela trocar o cartão SIM e inserir o código PUK.

O problema é devido ao processamento de desbloqueio incorreto depois de inserir 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, tudo o que você precisa fazer é inserir seu cartão SIM no seu celular, que tem 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. Sim o código PIN é digitado incorretamente três vezes, o cartão SIM será bloqueado, dapós o qual 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 com a senha mestra ou padrão.

A vulnerabilidade se deve a um erro na lógica de verificação. de códigos PUK no controlador KeyguardSimPukViewController, que se encarrega de 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 inserido corretamente, o segundo estágio de verificação é ativado, que requer a entrada do código de desbloqueio mestre, mas ao inserir o código PUK, esta etapa é ignorada e o acesso é concedido sem solicitar a senha ou padrão mestre.

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 manipulador 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 de autoridade .

A vulnerabilidade foi descoberta por acidente: o telefone do usuário ficou sem bateria e, após carregar e ligar o telefone, ele cometeu um erro ao inserir o código PIN várias vezes, após o que desbloqueou o código PUK e ficou surpreso que o sistema não pediu a senha mestra usada para descriptografar os dados, após o que aparece a mensagem “Pixel está iniciando…”.

O usuário acabou sendo 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 aparelho após trocar o cartão SIM e teve acesso ao ambiente em vez de congelar.

De particular interesse é a resposta do Google ao relatório de vulnerabilidade. euAs informações sobre o problema foram enviadas em junho, mas só em setembro o pesquisador conseguiu uma resposta clara. Ele considerou que esse comportamento se devia ao fato de ele não ter sido o primeiro a relatar esse bug.

As suspeitas de que algo estava errado foram levantadas em setembro, quando o problema permaneceu sem solução após o lançamento de uma atualização de firmware 90 dias depois, após o período de sigilo declarado já ter expirado.

Como todas as tentativas de descobrir o status do relatório de problemas enviado levaram apenas a modelos e cancelamentos automáticos, o pesquisador tentou entrar em contato pessoalmente com os funcionários do Google para esclarecer a situação com a preparação de uma soluçã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.

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 terceiros. 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,000 do Google.

fonte: https://bugs.xdavidhu.me


Seja o primeiro a comentar

Deixe um comentário

Seu endereço de email não será publicado. Campos obrigatórios são marcados com *

*

*

  1. Responsável pelos dados: Miguel Ángel Gatón
  2. Finalidade dos dados: Controle de SPAM, gerenciamento de comentários.
  3. Legitimação: Seu consentimento
  4. Comunicação de dados: Os dados não serão comunicados a terceiros, exceto por obrigação legal.
  5. Armazenamento de dados: banco de dados hospedado pela Occentus Networks (UE)
  6. Direitos: A qualquer momento você pode limitar, recuperar e excluir suas informações.