
A vulnerabilidade foi descoberta por um pesquisador da equipe do Google Project Zero, Ian Beer. Ele publicou um extenso artigo em 1º de dezembro , no qual descreveu em detalhes a vulnerabilidade em si e a história de sua descoberta. A simples descrição da vulnerabilidade a torna um pouco diferente das outras: uma conexão é estabelecida com o dispositivo da vítima via AWDL, uma série de pacotes preparados são enviados, causando um estouro de buffer e execução arbitrária de código. A postagem do blog de várias páginas mostra que a realidade é muito mais complicada. O pesquisador muitas vezes poderia recuar e se limitar a demonstrar um ataque DoS, a queda de um dispositivo baseado em iOS ou macOS. Mesmo assim, ele encerrou o assunto: no vídeo do ataque, ele invade seu próprio iPhone em dois minutos e rouba dados pessoais dele em outros três.
Beer teve a ideia de "cavar" exatamente na direção da comunicação sem fio em 2018, depois que a Apple lançou acidentalmente a versão beta do iOS sem remover os nomes das funções do módulo kernelcache (que contém o próprio kernel e alguns outros módulos). Esse erro simplificou um pouco a vida dos pesquisadores, à medida que informações textuais mais significativas sobre os princípios de operação do kernel apareciam. Lá Beer encontrou referências a AWDL na função de processamento de entrada. O primeiro resultado foi um relatório de bug informando que o sistema operacional travava após enviar pacotes incorretos pelo ar - esse bug foi corrigido no macOS 10.15.3 e no iOS 13.1.1. Ou seja, em janeiro de 2020, o problema foi resolvido.
Mas Beer passou mais seis meses investindo em seu próprio conhecimento e na ciência de encontrar vulnerabilidades, além de se proteger contra elas. Ele aperfeiçoou sua exploração inicial implementando um ataque de roubo de dados sem a intervenção do usuário. Ao contrário de muitos outros ataques que envolvem estar perto da vítima, o invasor e a vítima nem precisam estar na mesma rede Wi-Fi. A tecnologia Apple envolve a criação de uma rede mesh entre dispositivos e funciona em paralelo com a conexão principal ao ponto de acesso. O pesquisador precisava desmontar o protocolo de comunicação para saber ao menos como enviar os pacotes para que atendessem aos seus requisitos. Em seguida, foi necessário ativar o modo de comunicação necessário, selecionar um conjunto de dados enviados para que causasse uma falha e implementar a execução de código arbitrário.O vídeo acima mostra todo o processo de ataque, que usa um computador Raspberry Pi com um módulo Wi-Fi.
O que é notável neste estudo é que Beer encontrou o problema sozinho. Sim, demorou muito. Sim, provavelmente ninguém explorou a vulnerabilidade. Considerando o ritmo relativamente rápido de instalação de atualizações no iPhone / iPad, é improvável que os invasores tenham tempo para explorar o bug. Mas existe a possibilidade de que outros também possam descobrir essa vulnerabilidade e explorá-la para fins nada pacíficos. O artigo fornece links para tweets que provam que pelo menos um outro especialista em segurança da informação sabia sobre o problema descoberto durante a pesquisa e percebeu que ele foi fechado em um lançamento recente do iOS.
O que mais aconteceu
O ataque à rede de pontos de verificação PickPoint em 4 de dezembro ( notícias , mensagem da empresa, discussão sobre Habré) se tornou um raro (felizmente) exemplo claro de um hack de infraestrutura física. Um relatório técnico detalhado sobre os métodos de tais ataques e como se defender contra eles é útil para a comunidade de segurança da informação. No entanto, não é um facto que iremos aguardar essa divulgação de dados - as empresas não são obrigadas a fazê-lo e apenas na esfera das TI a divulgação de informação é considerada "boa forma".
Uma vulnerabilidade fechada em 6 de abril na biblioteca principal do Google Play (ela é incorporada em aplicativos Android para interagir com a loja online do Google) ainda não foi fechadaem uma variedade de aplicativos Android, incluindo a versão móvel do navegador Microsoft Edge. Um rastreamento da loja do Google mostrou que 13% dos aplicativos usam essa biblioteca. Destes, 8% nunca o atualizaram após o lançamento do patch.
Mais patches para vulnerabilidades no Google Chrome. Fechou três grandes buracos no navegador, um deles no motor V8 (CVE-2020-16040). Notavelmente, esta vulnerabilidade pode ser explorada para aumentar os privilégios no Linux.