Vulnerabilidade 0-day explorada por empresa de vigilância comercial no Egito

 (blog.google)
1 pontos por GN⁺ 2023-09-23 | 1 comentários | Compartilhar no WhatsApp
  • O Google TAG e o The Citizen Lab encontraram uma cadeia de exploits 0-day para iPhone sendo usada em ataques reais, e a Intellexa a utilizou para instalar secretamente o spyware Predator
  • A Apple corrigiu as CVE-2023-41991·41992·41993 no iOS 16.7 e no iOS 17.0.1, e o Google recomenda que usuários de iOS atualizem imediatamente
  • O ataque interceptava o tráfego por meio de injeção MITM quando o alvo acessava um site HTTP e redirecionava para c.betly[.]me e sec-flare[.]com, sem exigir clique adicional nem atendimento de chamada
  • A cadeia para iOS envolvia execução remota de código no Safari, problema de validação de certificado e elevação local de privilégio no XNU Kernel, após o que um pequeno binário decidia se instalaria o implante completo do Predator
  • Ataques contra Android também foram observados no Egito, e a vulnerabilidade de execução remota de código inicial no renderizador do Chrome explorando a CVE-2023-4762 foi corrigida em 5 de setembro

Cadeia de exploits da Intellexa para instalar o Predator

  • O Google Threat Analysis Group (TAG), em conjunto com o The Citizen Lab, descobriu uma cadeia de exploits 0-day para iPhone que estava sendo usada em ataques reais
  • Essa cadeia, desenvolvida pela empresa de vigilância comercial Intellexa, era usada para instalar secretamente o spyware Predator no dispositivo
  • A Apple corrigiu as seguintes vulnerabilidades no iOS 16.7 e no iOS 17.0.1
    • CVE-2023-41991
    • CVE-2023-41992
    • CVE-2023-41993
  • A correção rápida reforçou a proteção dos usuários, e é recomendado que todos os usuários de iOS instalem a atualização o quanto antes

Método de entrega via MITM

  • A cadeia de exploits da Intellexa era entregue por meio de um ataque man-in-the-middle (MITM)
  • Em um ataque MITM, o invasor se posiciona entre o alvo e o site que ele tenta acessar para interceptar o tráfego
  • Quando o alvo acessa um site http, o invasor pode devolver dados falsos para redirecioná-lo a outro site
  • Em sites https, o tráfego é criptografado e os certificados permitem verificar se os dados recebidos vieram do site pretendido
  • Nesta campanha, sempre que o alvo acessava qualquer site http, ele era silenciosamente redirecionado por injeção de tráfego para o site da Intellexa c.betly[.]me
    • Se o usuário fosse um alvo esperado, era então redirecionado novamente para o servidor de exploit sec-flare[.]com
    • Não era necessária nenhuma ação do usuário, como abrir documentos, clicar em links específicos ou atender chamadas

Composição da cadeia de exploits para iOS

  • Quando o alvo era redirecionado para o servidor de exploit, a cadeia de exploits para iOS era executada
  • A cadeia era composta por três vulnerabilidades
    • CVE-2023-41993: execução remota de código (RCE) inicial no Safari
    • CVE-2023-41991: problema de validação de certificado
    • CVE-2023-41992: elevação local de privilégio (LPE) no XNU Kernel
  • Em seguida, um pequeno binário era executado para decidir se instalaria o implante completo do Predator
  • O TAG não conseguiu obter o implante completo do Predator
  • O Google planeja divulgar uma análise técnica aprofundada desse exploit de acordo com a Google vulnerability disclosure policy

Ataques contra Android e vulnerabilidade no Chrome

  • Os invasores também possuíam uma cadeia de exploits para instalar o Predator em dispositivos Android no Egito
  • O TAG observou duas formas de entrega do exploit para Android
    • injeção MITM
    • link descartável enviado diretamente ao alvo
  • O que o TAG conseguiu obter foi apenas a vulnerabilidade de execução remota de código inicial no renderizador do Chrome, que explorava a CVE-2023-4762
  • Esse bug já havia sido reportado por outro pesquisador de segurança ao Chrome Vulnerability Rewards Program e foi corrigido em 5 de setembro
  • O Google avalia que a Intellexa usou essa vulnerabilidade anteriormente como 0-day

Defesa MITM do Chrome e resposta do Google

  • O Chrome vem promovendo há anos a adoção universal de HTTPS na web
  • O “HTTPS-First Mode” do Chrome pode reduzir a possibilidade de entrega de exploits por injeção de rede MITM
    • Ele tenta primeiro carregar todas as páginas em HTTPS
    • Exibe um grande aviso antes de voltar a uma solicitação HTTP
  • Essa configuração vem ativada por padrão para usuários inscritos no Advanced Protection Program e conectados ao Chrome
  • O Google recomenda que todos os usuários ativem o “HTTPS-First Mode” para se defender de ataques MITM
  • Esta campanha mostra que a expansão das empresas de vigilância comercial pode criar um risco sério para a segurança dos usuários online
  • O TAG continuará tomando medidas contra a indústria de spyware comercial e divulgando pesquisas, além de cooperar com os setores público e privado para dar continuidade à resposta relacionada

Leituras relacionadas

1 comentários

 
GN⁺ 2023-09-23
Comentários do Hacker News

  • É bom que tenham saído mais informações, mas é meio preocupante que só mencionem o patch do Chrome. Fico curioso sobre qual foi a fuga de sandbox no Android
    Mesmo que tenha sido possível executar código dentro do processo do Chrome no Android, isso não deveria permitir persistência, então claramente há outra vulnerabilidade envolvida
    O vetor deste ataque foi um ataque man-in-the-middle via HTTP e um link de uso único em uma campanha direcionada, mas também não parece haver nada que impeça alguém de colocar isso numa campanha de anúncios ou em spam via SMS/Discord/Matrix para espalhar em massa, criar uma botnet ou roubar credenciais de usuários

    • Esse é exatamente o ponto central. Essa informação está faltando no post do blog, então é preciso ler nas entrelinhas, mas parece que há uma falha ainda não corrigida no lado do Android
    • Foi dito que eles não conseguiram capturar as etapas posteriores da cadeia no Android e só obtiveram o componente inicial de execução
      Ou seja, estão faltando a fuga de sandbox e o bug de escalonamento de privilégios
      Além disso, embora aqui pareça ter sido entregue por um ataque man-in-the-middle em nível de ISP usando capacidade legal de interceptação, não há motivo para que esse exploit não pudesse também ser entregue em modo de um clique por meio de um link de phishing
    • Como existem milhões de aparelhos Android abandonados pelos fabricantes, talvez estejam omitindo alguns detalhes porque se trata de uma falha ainda sem correção e que provavelmente nunca será corrigida em parte desses dispositivos
    • O foco do texto é a cadeia de exploit no iPhone: exploit do Safari → bypass de PAC → exploit de kernel
      A versão para Android parecia bem parecida, mas parece que exigia mais dois exploits para contornar as mitigações do kernel Linux
      Há uma boa análise técnica sobre isso no PZ
    • Não conheço tão bem o ambiente móvel, mas eu imaginava que, ao sair da sandbox do Chrome, você já entraria no sistema operacional subjacente. A partir daí, não seria possível obter persistência sem explorar vulnerabilidades adicionais?

  • É melhor do que não ter HTTPS, e este ataque usa HTTP para injetar o payload inicial, mas parece que alguns agentes estatais de certos países poderiam simplesmente contornar ou comprometer CAs ou infraestrutura de CDN

    • Se falsificassem certificados dessa forma, todos os navegadores provavelmente perceberiam e removeriam essa CA, então existem proteções contra isso
    • Ou então poderiam fazer todos nós clicarmos em um domínio falsificado certificado pela nossa querida LetsEncrypt
      Pelo que parece, tudo o que é necessário é uma resposta de redirecionamento HTTP 302/307 que envie o cliente para c.betly[.]me. Um payload de redirecionamento em HTML, ou talvez até DNS, também poderia funcionar
    • O ponto importante é que bastava, ou basta, visitar uma única vez qualquer site HTTP para comprometer o dispositivo

  • Há um episódio recente e relacionado do Darknet Diaries sobre o spyware Predator: https://darknetdiaries.com/episode/137/

  • O que esses 0-days ensinam é que, se você for alvo de um adversário poderoso, precisa agir com paranoia extrema e reduzir ao máximo sua superfície de ataque
    Se James Bond quisesse se comunicar com segurança com M, seria melhor usar um dispositivo móvel customizado, dedicado apenas a essa função. Ele teria de deixar mensagens criptografadas em um fórum aleatório usando um aparelho pré-pago anônimo de terceiros, seguindo uma ordem previamente combinada de um livro de códigos rotativo com bloqueio geográfico. Qualquer descuido mínimo em segurança operacional e já era
    Se uma pessoa comum usa um dispositivo digital conectado de forma comum, deve presumir que tudo o que colocou nele já foi roubado. Se quiser mesmo manter algo privado, não coloque isso no mundo digital; deixe em papel ou em mídia analógica antiga, como fita. Aí pelo menos seria preciso roubar fisicamente, o que, dependendo da situação, pode ser muito mais difícil, embora não signifique necessariamente mais seguro. No fim, você perde de um jeito ou de outro
    A única saída real é ter governos democráticos com forte transparência e freios e contrapesos, leis robustas de proteção de dados efetivamente aplicadas e forte apoio a trabalhos como o do Citizen Lab

  • É bem provável que essa vulnerabilidade tenha sido usada pelas autoridades egípcias para hackear o celular do candidato Ahmed El Tantawy, que disputa a eleição presidencial contra o atual presidente Abdel Fatah El Sisi
    https://x.com/jsrailton/status/1705271600868692416?s=46&t=Kq...

  • O texto não menciona isso, mas o Modo de Isolamento do iOS bloqueou essa cadeia de exploit

  • Há algo que não entendo: tanto as empresas de spyware quanto as que vendem 0-days têm equipes dedicadas a encontrar 0-days. Por que Google e Apple simplesmente não contratam essas pessoas?
    Google e Apple certamente poderiam oferecer salários muito competitivos, então fico me perguntando por que não fazem isso. Será que concluíram que o custo de praticamente tirar do mercado todos os caçadores experientes de 0-day seria maior do que o custo de simplesmente lançar patches?

    • Eu sou justamente uma dessas pessoas. Trabalho como pesquisador de 0-day
      Do ponto de vista do funcionário, o salário é parecido. O trabalho em Big Tech é menos interessante. Você constrói grandes máquinas de detecção de bugs que encontram muitos problemas, coloca os bugs encontrados no rastreador e talvez eles só sejam corrigidos três meses depois. O trabalho em segurança ofensiva é mais interessante. As vulnerabilidades rasas a Big Tech encontra; o que você precisa são poucas, e para isso é necessário conhecer profundamente o sistema estudado. Também é preciso saber como sair de uma vulnerabilidade até chegar à execução de código. Escrever exploits não é fácil. É difícil explicar por que engenheiros trabalham em empresas que eu considero antiéticas, mas provavelmente é porque eles não veem isso da mesma forma que eu
      Do ponto de vista do empregador, é uma questão de “quanto gastar para encontrar X vulnerabilidades por ano”. Mesmo que o código tenha bugs, se ainda for considerado o código mais seguro do mercado, aumentar o orçamento de segurança pode não beneficiar a empresa. Se aumentar o orçamento de segurança, é preciso ver de qual departamento esse dinheiro sairia e qual seria o efeito líquido para a saúde da empresa
      Se você quiser corrigir vulnerabilidades, precisa elevar o preço de encontrar e explorar essas falhas a um nível que os compradores não consigam pagar. E, à medida que os avanços em segurança ofensiva reduzem o custo de descoberta e exploração, é preciso manter esse preço cada vez mais alto. Empresas defensivas não ganham dinheiro principalmente evitando bugs, enquanto empresas ofensivas ganham dinheiro principalmente encontrando bugs, daí surge esse desalinhamento. A vulnerabilidade definitiva de qualquer empresa ou organização são os recursos finitos
    • O Google já tem uma das melhores equipes que dinheiro e prestígio podem comprar: https://en.m.wikipedia.org/wiki/Project_Zero
      A colaboração com pesquisadores independentes do mundo todo também é excelente. Mas, considerando a quantidade de software escrita todos os dias, ainda assim alguns problemas podem passar
    • Isso parece parecido com olhar para o orçamento do governo dos EUA e perguntar: “por que não subornar todos os criminosos em potencial para reduzir a maior parte do crime nos Estados Unidos?”
    • Alguns deles provavelmente nem gostariam de trabalhar no Google ou na Apple, independentemente do salário
      Mesmo que você os contratasse hoje, amanhã surgiriam muitas outras pessoas novas trabalhando nesse tipo de empresa, então seria um ciclo sem fim
    • É uma boa ideia, mas em certo sentido se parece com perguntar “por que o país mais rico do mundo não contrata todos os melhores generais do mundo e não deixa nenhum para os outros países?”
      Há muitos motivos pelos quais isso é impossível, mas no fim tudo se resume ao fato de que o mundo e a humanidade são grandes e complexos demais para que um único ator tenha tudo, ou mesmo a maior parte. Existe diversidade demais e heterogeneidade demais embutidas em tudo. Há também visões de mundo e lealdades que vão além do dinheiro

  • O Firefox também tem HTTPS First, mas parece que é preciso ativar a configuração dom.security.https_first
    Se possível, o “HTTPS-Only Mode” certamente é o melhor

    • Ainda assim, é preciso resistir ao impulso de clicar em “permitir mesmo assim”. Sinceramente, mesmo sabendo do risco, acho que eu também clicaria. Eu só quero visitar o site
      A menos que o aviso pareça extremamente suspeito, por exemplo se surgir em um site como Google.com que você sabe que suporta HTTPS, isso não resolve nada

  • O post do Citizen Lab linkado por este texto traz detalhes do ataque man-in-the-middle. Quase nem dá para chamar de ataque; a rede foi projetada para injetar conteúdo quando necessário