O blog de segurança da FireAI

Por FireAI Security & Research Team · Publicado

Zero-days no macOS: por que ameaças desconhecidas ainda precisam “ligar para casa”

Zero-days no macOS: por que ameaças desconhecidas ainda precisam “ligar para casa”

Um zero-day é uma falha de segurança que está sendo explorada antes que o fabricante tenha uma correção, e recebe esse nome porque os defensores tiveram zero dias para reagir. É a categoria de ameaça mais alarmante, porque o conselho de sempre, “mantenha seu software atualizado”, ainda não se aplica: não há para o que atualizar. Este artigo mostra como essas falhas realmente se apresentaram nas plataformas da Apple, com base nos boletins de segurança da própria Apple, no Google Project Zero e no Citizen Lab, e depois olha para a única coisa que um exploit desconhecido ainda precisa fazer depois de ter sucesso.

Um ponto precisa ser dito logo de cara, porque o marketing em torno desse assunto costuma ser enganoso: nenhum firewall impede um exploit. Nem o FireAI, nem nenhum outro. Um firewall não consegue ver uma imagem malformada sendo interpretada dentro do iMessage ou um bug do kernel sendo acionado a partir de uma página da web. O que um firewall consegue fazer é observar o que acontece em seguida, e isso acaba importando mais do que parece à primeira vista.

O que o histórico realmente mostra

A Apple documenta cada correção de segurança na sua página de atualizações de segurança da Apple, e quando uma falha já estava sendo usada contra pessoas reais ela diz isso com uma frase padrão: “A Apple está ciente de um relato de que esse problema pode ter sido explorado ativamente.” Ler essa página ao longo de alguns anos dá um retrato mais realista do que qualquer manchete. O Google Project Zero mantém um registro público complementar, o seu rastreador de 0-days “in the wild”, que lista exploits detectados em ataques reais antes de existir um patch. O Project Zero faz questão de observar que o rastreador só contém os casos que foram detectados, que por definição são os fracassos do atacante, então ele não serve para contar quanta exploração acontece de fato nem para comparar plataformas.

Três casos documentados mostram o formato do problema.

FORCEDENTRY, 2021

Em março de 2021, o Citizen Lab da Universidade de Toronto analisou o celular de um ativista saudita e recuperou um exploit que batizou de FORCEDENTRY. Era um ataque “zero-click”: um arquivo especialmente montado, entregue pelo iMessage, que não exigia nenhum toque da vítima e instalava o spyware Pegasus do NSO Group. O Citizen Lab encontrou evidências de que ele estava em uso desde pelo menos fevereiro de 2021. A Apple corrigiu a falha, CVE-2021-30860 no interpretador de imagens do CoreGraphics, em 13 de setembro de 2021 no iOS 14.8, no macOS Big Sur 11.6 e em uma atualização de segurança para o Catalina; as próprias notas de lançamento do Big Sur 11.6 confirmam que a falha “pode ter sido explorada ativamente”.

O Google Project Zero publicou depois uma análise técnica que explica por que esse tipo de coisa é tão difícil de pegar. O bug estava no código de compressão de imagens JBIG2 usado dentro de PDFs. O exploit da NSO usava os operadores lógicos do próprio formato para construir, a partir de mais de 70.000 comandos de segmento de imagem, um pequeno computador funcional dentro do decodificador de imagens, e rodava ali o resto do ataque. Visto de fora, nada disso se parece com um programa. É uma imagem, aberta por um processo de sistema legítimo e assinado.

O watering hole de Hong Kong, 2021

No fim de agosto de 2021, o Threat Analysis Group do Google encontrou uma campanha do tipo watering hole voltada aos visitantes dos sites de um veículo de imprensa de Hong Kong e de um grupo pró-democracia. Contra Macs, ela encadeava uma falha do WebKit já corrigida em janeiro com um bug de elevação de privilégios no kernel, CVE-2021-30869, que ainda estava sem correção no macOS Catalina; a Apple o corrigiu em 23 de setembro de 2021. A carga, um backdoor que o Google chamou de MACMA, conseguia identificar a máquina, capturar a tela, gravar áudio, registrar as teclas digitadas, enviar e baixar arquivos e executar comandos de terminal.

Esse exemplo é instrutivo porque o exploit e a carga são coisas separadas. O exploit era invisível: uma página da web. A carga era um programa implantado bem comum que, para ter alguma utilidade para seus operadores, precisava estabelecer um canal de comando e controle e tirar dados do Mac. O relatório do Google descreve exatamente essa infraestrutura.

BLASTPASS, 2023

Em setembro de 2023, o Citizen Lab relatou o BLASTPASS, outra cadeia do iMessage sem clique que entregava o Pegasus, dessa vez por meio de anexos PassKit contendo imagens maliciosas. A Apple atribuiu os identificadores CVE-2023-41064 e CVE-2023-41061 e distribuiu correções para iPhone, iPad, Mac e Apple Watch. Vale destacar que tanto os engenheiros de segurança da Apple quanto o Citizen Lab disseram acreditar que o Modo de Isolamento bloqueava essa cadeia em particular, o que é a evidência pública mais forte de que reduzir a superfície de ataque, em vez de detectar o ataque, é o que funciona contra essa classe de ameaça.

Por que detectar o exploit em si é tão difícil

Coloque os três casos lado a lado e o padrão fica claro. O exploit chega como dados (uma imagem, um PDF, uma página da web), não como um aplicativo. Ele é processado por código legítimo, assinado pela Apple. Não há arquivo para o XProtect reconhecer, nenhum binário sem assinatura para o Gatekeeper recusar e, muitas vezes, nenhum processo novo para uma ferramenta de segurança de endpoint sinalizar, porque o código hostil roda dentro de um processo que já era confiável. A detecção, quando acontece, costuma ser forense: o Citizen Lab encontrou o FORCEDENTRY examinando vestígios em um dispositivo depois do ocorrido, não por meio de um scanner que o pegou ao vivo.

É por isso que o conselho da Apple para quem acredita que pode ser alvo não é “instale um detector”, e sim o Modo de Isolamento, que no macOS Ventura e posteriores bloqueia a maioria dos tipos de anexo de mensagens, desativa tecnologias web complexas, recusa chamadas do FaceTime de desconhecidos e impede a instalação de perfis de configuração. Ele funciona removendo os caminhos de código de que um exploit precisa, a um custo em conveniência que a Apple deixa explícito.

Por que a etapa de rede é diferente

Um exploit é o começo de um ataque, não o seu propósito. O Pegasus existe para enviar mensagens, fotos e áudio do microfone ao seu operador. As capturas de tela e as teclas registradas pelo MACMA não valiam nada no disco da vítima. Em todos os casos documentados, o valor se concretizou por meio de tráfego saindo da máquina, e na matriz MITRE ATT&CK para macOS essa fase tem duas colunas próprias, comando e controle e exfiltração, porque é uma etapa distinta, observável, que os atacantes não podem pular.

Essa etapa tem propriedades que o exploit não tinha. Ela vem de um processo identificável, com uma assinatura de código (ou, o que diz muito, sem nenhuma). Vai para um destino com um IP, um nome de host e um histórico. Muitas vezes usa uma porta incomum, um IP puro em vez de um nome, ou um provedor de hospedagem sem nenhuma relação com os aplicativos do Mac. Nada disso exige conhecer a falha que foi usada. Exige apenas ver a conexão e ter permissão para dizer não.

É para essa parte que o FireAI foi construído. Suas regras por aplicativo são vinculadas à assinatura de código do processo que faz a conexão, então um binário implantado que não seja um aplicativo que você aprovou recebe um pedido de permissão em vez de passe livre, com o motivo do modelo local exibido em linguagem simples. Seus feeds de inteligência de ameaças (abuse.ch, Spamhaus, FireHOL, OpenPhish, Phishing Army e a lista atual de nós de saída do Tor) são aplicados localmente, então um endereço de comando e controle conhecido é recusado independentemente de qualquer outra coisa no Mac ter reconhecido a carga. Os modos Sob ataque e Paranoico endurecem o padrão até bloquear de imediato aplicativos sem assinatura e destinos desconhecidos, e o kill switch corta a internet mantendo a rede local, que é o primeiro movimento certo quando você suspeita de um comprometimento e quer preservar as evidências.

O que isso não cobre

A honestidade exige a outra metade da lista. Se uma carga roda inteiramente dentro de um aplicativo permitido, por exemplo dentro de um navegador que você já autorizou, seu tráfego herda as permissões desse aplicativo e o FireAI não vai distingui-lo. Tráfego criptografado para um destino com reputação limpa se parece com qualquer outra conexão. Um feed só contém endereços que alguém já denunciou; um servidor de comando e controle recém-criado ainda não está nele. E o FireAI não detecta, não remove nem analisa o exploit ou o implante: ele não escaneia arquivos nem memória, e não é um antivírus. Em um Mac que você acredita ter sido comprometido por um agente de nível estatal, o caminho correto é a orientação da Apple sobre notificações de ameaça e um especialista forense, não uma configuração de firewall.

A defesa prática contra falhas desconhecidas é, portanto, em camadas e nada glamourosa: aplique as atualizações da Apple no dia em que saem, já que a maior parte da exploração mira falhas que já têm correção; ative o Modo de Isolamento se o seu trabalho faz de você um alvo plausível; mantenha a superfície de ataque pequena; e controle quais aplicativos no seu Mac têm permissão sequer para falar com a internet, para que, quando algo desconhecido entrar mesmo assim, a etapa que ele não pode pular seja justamente a que você está observando.

Onde FireAI e HisnLabs entram nessa história

O FireAI não consegue impedir um exploit e não afirma que consegue; o que ele faz é ficar na única etapa que nenhum dos casos documentados acima pôde pular, a conexão para fora, e perguntar, para cada processo desconhecido, se essa conexão deve sequer ser permitida.

O FireAI é o produto da HisnLabs: um firewall com IA que roda direto no seu Mac. Ele mostra, em linguagem simples, cada conexão que seus aplicativos fazem e deixa você decidir o que sai do seu Mac — a IA roda localmente, então seu tráfego nunca é enviado para nós nem para ninguém. A equipe de pesquisa em segurança da HisnLabs é quem mantém essas decisões confiáveis: cataloga quais domínios são telemetria comum e quais são um serviço de verdade, rastreia o país e a rede por trás de uma conexão e treina o modelo local (o recurso Autopilot) com padrões reais de tráfego, sem que nada disso saia do seu Mac.

Você pode ler as decisões técnicas por trás dele, ou testar o FireAI por 17 dias, em FireAI, da HisnLabs.

Fontes