Desvio perigoso da tela de bloqueio de troca de SIM – atualize o Android agora! – Segurança Nua

Um caçador de recompensas de bugs chamado David Schütz acaba de publicar um relatório detalhado descrevendo como ele cruzou espadas com o Google por vários meses sobre o que ele considerava uma perigosa falha de segurança do Android.

De acordo com Schütz, ele tropeçou em um bug total de desvio de tela de bloqueio do Android inteiramente por acidente em junho de 2022, sob condições da vida real que poderiam facilmente ter acontecido com qualquer pessoa.

Em outras palavras, era razoável supor que outras pessoas pudessem descobrir as falhas sem procurar deliberadamente por bugs, tornando sua descoberta e divulgação pública (ou abuso privado) como um buraco de dia zero muito mais provável do que o normal.

Infelizmente, ele não foi corrigido até novembro de 2022, e é por isso que ele só o divulgou agora.

Uma saída de bateria casual

Simplificando, ele encontrou o bug porque se esqueceu de desligar ou carregar o telefone antes de sair em uma longa jornada, deixando o dispositivo com pouca energia despercebido enquanto ele estava na estrada.

De acordo com Schütz, ele estava correndo para enviar algumas mensagens depois de chegar em casa (estamos supondo que ele estava em um avião) com a pequena quantidade de energia que ainda restava na bateria…

…quando o telefone morreu.

Todos nós já estivemos lá, procurando um carregador ou uma bateria reserva para reiniciar o telefone para que as pessoas saibam que temos segurança, estamos esperando na coleta de bagagem, chegamos à estação de trem, para chegar em casa em 45 minutos, podemos parar nas lojas se alguém precisar de alguma coisa urgentemente, ou o que quer que tenhamos a dizer.

E todos nós lutamos com senhas e PINs quando estamos com pressa, especialmente se forem códigos que raramente usamos e nunca desenvolvemos “memória muscular” para digitar.

No caso de Schütz, foi o humilde PIN em seu cartão SIM que o deixou perplexo e, como os PINs do SIM podem ter apenas quatro dígitos, eles são protegidos por um bloqueio de hardware que limita você a três palpites no máximo. (Nós estivemos lá, fizemos isso, nos trancamos.)

Depois disso, você precisa inserir um “PIN mestre” de 10 dígitos conhecido como PUK, abreviação de chave de desbloqueio pessoalque geralmente é impresso dentro da embalagem em que o SIM é vendido, o que o torna amplamente inviolável.

E para se proteger contra ataques de adivinhação de PUK, o SIM automaticamente se frita após 10 tentativas erradas e precisa ser substituído, o que normalmente significa ir até uma loja de celulares com identificação.

O que eu fiz com essa embalagem?

Felizmente, porque ele não teria encontrado o bug sem ele, Schütz localizou a embalagem original do SIM escondida em algum lugar em um armário, raspou a tira protetora que obscurece o PUK e a digitou.

Neste ponto, dado que ele estava no processo de iniciar o telefone depois que ficou sem energia, ele deveria ter visto a tela de bloqueio do telefone exigindo que ele digitasse o código de desbloqueio do telefone…

… mas, em vez disso, ele percebeu que estava no tipo errado de lockscreenporque estava oferecendo a ele a chance de desbloquear o dispositivo usando apenas sua impressão digital.

Isso só deve acontecer se o telefone travar durante o uso regular e não deve acontecer após um desligamento e reinicialização, quando uma reautenticação de senha completa (ou um desses “códigos padrão” de deslizar para desbloquear ) deve ser aplicada.

Existe realmente um “bloqueio” na sua tela de bloqueio?

Como você provavelmente sabe das muitas vezes que escrevemos sobre bugs de tela de bloqueio ao longo dos anos no Naked Security, o problema com a palavra “bloqueio” na tela de bloqueio é que simplesmente não é uma boa metáfora para representar o quão complexo é o código que gerencia o processo de “bloqueio” e “desbloqueio” de telefones modernos.

Uma tela de bloqueio móvel moderna é um pouco como uma porta da frente de uma casa que possui uma trava de qualidade decente instalada…

…mas também tem uma caixa de correio (slot de correio), painéis de vidro para deixar entrar a luz, uma aba de gato, uma trava de mola loidable que você aprendeu a confiar porque a trava é um pouco trabalhosa e uma campainha externa sem fio / câmera de segurança que é fácil de roubar, embora contenha sua senha de Wi-Fi em texto simples e os últimos 60 minutos de imagens de vídeo gravadas.

Ah, e, em alguns casos, mesmo uma porta da frente com aparência segura terá as chaves “escondidas” sob o capacho, o que é praticamente a situação em que Schütz se encontrou em seu telefone Android.

Um mapa de passagens sinuosas

As telas de bloqueio de telefone modernas não são tanto para bloquear seu telefone, mas para restringir seus aplicativos a modos de operação limitados.

Isso normalmente deixa você e seus aplicativos com acesso à tela de bloqueio a uma ampla variedade de recursos de “casos especiais”, como ativar a câmera sem desbloquear ou exibir um conjunto de mensagens de notificação ou linhas de assunto de e-mail selecionadas, onde qualquer pessoa pode vê-los sem a senha.

O que Schütz havia encontrado, em uma sequência de operações perfeitamente irrepreensível, era uma falha no que é conhecido no jargão como tela de bloqueio máquina de estado.

Uma máquina de estado é uma espécie de gráfico, ou mapa, das condições em que um programa pode estar, juntamente com as formas legais pelas quais o programa pode passar de um estado para outro, como uma conexão de rede mudando de “escutando” para “ conectado” e, em seguida, de “conectado” para “verificado”, ou uma tela do telefone mudando de “bloqueado” para “desbloqueável com impressão digital” ou para “desbloqueável, mas apenas com uma senha”.

Como você pode imaginar, máquinas de estado para tarefas complexas rapidamente se complicam, e o mapa de diferentes caminhos legais de um estado para outro pode acabar cheio de reviravoltas…

…e, às vezes, passagens secretas exóticas que ninguém notou durante os testes.

De fato, Schütz conseguiu transformar sua descoberta inadvertida do PUK em um desvio genérico de tela de bloqueio pelo qual qualquer pessoa que pegasse (ou roubasse, ou tivesse acesso breve a) um dispositivo Android bloqueado poderia enganá-lo no estado desbloqueado armado com nada mais do que um novo cartão SIM próprio e um clipe de papel.

Caso você esteja se perguntando, o clipe de papel é para ejetar o SIM já no telefone para que você possa inserir o novo SIM e enganar o telefone no estado “Preciso solicitar o PIN para este novo SIM por motivos de segurança”. Schütz admite que quando ele foi aos escritórios do Google para demonstrar o hack, ninguém tinha um ejetor de SIM adequado, então eles primeiro tentaram uma agulha, com a qual Schütz conseguiu se esfaquear, antes de conseguir um brinco emprestado. Suspeitamos que enfiar a agulha na ponta primeiro não funcionou (é difícil acertar o pino ejetor com uma ponta minúscula), então ele decidiu arriscar usá-la apontando para fora enquanto “tomando muito cuidado”, transformando assim uma tentativa de hacking em um literal hackear. (Nós estivemos lá, fizemos isso, nos cravamos na ponta do dedo.)

Jogando o sistema com um novo SIM

Dado que o invasor conhece o PIN e o PUK do novo SIM, ele pode deliberadamente obter o PIN errado três vezes e, em seguida, acertar imediatamente o PUK, forçando deliberadamente a máquina de estado da tela de bloqueio na condição insegura que Schütz descobriu acidentalmente.

Com o tempo certo, Schütz descobriu que não só poderia pousar na página de desbloqueio de impressão digital quando não deveria aparecer, mas também enganar o telefone para aceitar o desbloqueio PUK bem-sucedido como um sinal para descartar a tela de impressão digital e “validar” todo o processo de desbloqueio como se tivesse digitado o código de bloqueio completo do telefone.

Desbloqueie o desvio!

Infelizmente, grande parte do artigo de Schütz descreve o tempo que o Google levou para reagir e corrigir essa vulnerabilidade, mesmo depois que os próprios engenheiros da empresa decidiram que o bug era realmente repetível e explorável.

Como o próprio Schütz colocou:

Esta foi a vulnerabilidade mais impactante que encontrei até agora, e cruzou uma linha para mim, onde eu realmente comecei a me preocupar com a linha do tempo da correção e até mesmo em mantê-la como um “segredo”. Posso estar exagerando, mas não faz muito tempo que o FBI estava brigando com a Apple por quase a mesma coisa.

Atrasos de divulgação

Dada a atitude do Google em relação às divulgações de bugs, com sua própria equipe do Project Zero notoriamente firme sobre a necessidade de estabelecer prazos de divulgação rigorosos e cumpri-los, você poderia esperar que a empresa cumprisse seus 90 dias mais 14 dias extras. regras de casos especiais.

Mas, segundo Schütz, o Google não conseguiu nesse caso.

Aparentemente, ele concordou com uma data em outubro de 2022 na qual planejava divulgar o bug publicamente, como fez agora, o que parece bastante tempo para um bug que ele descobriu em junho de 2022.

Mas o Google perdeu esse prazo de outubro.

O patch para as falhas, designado número de bug CVE-2022-20465, finalmente apareceu nos patches de segurança do Android de novembro de 2022, datados de 2022-11-05, com o Google descrevendo a correção como: “Não descarte a proteção do teclado após o desbloqueio do SIM PUK.”

Em termos técnicos, o bug era o que se conhece como condição de corrida, onde a parte do sistema operacional que estava observando o processo de entrada do PUK para acompanhar o “é seguro desbloquear o SIM agora?” state acabou produzindo um sinal de sucesso que superou o código que acompanhava simultaneamente “é seguro desbloquear todo o dispositivo?”

Ainda assim, Schütz está agora significativamente mais rico graças ao pagamento de recompensas por bugs do Google (seu relatório sugere que ele esperava US$ 100.000, mas teve que se contentar com US$ 70.000 no final).

E ele adiou a divulgação do bug após o prazo de 15 de outubro de 2022, aceitando que a discrição às vezes é a melhor parte do valor, dizendo:

EU [was] Com muito medo de realmente lançar o bug ao vivo e, como a correção estava a menos de um mês, não valia a pena de qualquer maneira. Resolvi esperar a correção.

O que fazer?

Verifique se o seu Android está atualizado: Definições > Segurança > Atualização de segurança > Verifique atualizações.

Observe que quando visitamos o Atualização de segurança tela, sem usar nosso telefone Pixel por um tempo, o Android proclamou corajosamente O seu sistema está atualizadomostrando que foi verificado automaticamente um minuto antes, mas ainda nos dizendo que estávamos no October 5, 2022 atualização de segurança.

Forçamos uma nova verificação de atualização manualmente e fomos imediatamente informados Preparando a atualização do sistema…seguido por um breve download, um longo estágio preparatório e, em seguida, uma solicitação de reinicialização.

Após a reinicialização, chegamos ao November 5, 2022 nível de patch.

Então voltamos e fizemos mais uma Verifique atualizações para confirmar que não havia correções ainda pendentes.


Nós costumavamos Definições > Segurança > Atualização de segurança para chegar à página force-a-download:


A data informada parecia errada, então forçamos o Android a Verifique atualizações de qualquer forma:


De fato, havia uma atualização para instalar:


Em vez de esperar, usamos Retomar proceder imediatamente:


Seguiu-se um longo processo de atualização:


Fizemos mais um Verifique atualizações para confirmar que estávamos lá:


.

Leave a Comment

Your email address will not be published. Required fields are marked *