Operation Triangulation: o que se obtém ao atacar os iPhones de pesquisadores

• Pesquisadores da Kaspersky revelaram na 37C3 a cadeia de ataque Operation Triangulation por iPhone 0-click via iMessage, considerada uma das cadeias mais sofisticadas já vistas até agora
• O ataque foi projetado para funcionar até o iOS 16.2 e encadeia quatro zero-days para chegar a execução remota de código, elevação de privilégios, bypass de PPL e execução de estágio via Safari
• O mistério central é a mitigação de CVE-2023-38606, em que os atacantes usam registradores MMIO desconhecidos no SoC Apple A12–A16 Bionic para contornar a proteção de memória do kernel baseada em hardware
• A análise indica que esses registradores parecem estar relacionados ao coprocessador auxiliar da GPU e alguns deles não são referenciados no DeviceTree nem no firmware, então ainda não se sabe como os atacantes descobriram como usá-los
• Em uma atualização de 9 de janeiro de 2024, os valores que pareciam um “hash customizado” foram identificados como ECC baseado em código de Hamming, reforçando a hipótese de que esse recurso seja uma função de depuração com acesso direto ao cache, e não à memória

---

Cadeia de ataque divulgada

• Em 27 de dezembro de 2023, na apresentação da 37C3, foi divulgado o resultado da análise de longo prazo da Operation Triangulation
• Nessa apresentação, os detalhes dos exploits e das vulnerabilidades usados no ataque foram revelados pela primeira vez
• Os pesquisadores já descobriram e reportaram mais de 30 zero-days explorados no mundo real em produtos da Adobe, Apple, Google e Microsoft, mas avaliaram essa cadeia de ataque como uma das mais sofisticadas entre todas

Do iMessage 0-click ao carregamento do spyware

• Os atacantes enviam um anexo malicioso no iMessage, e o aplicativo o processa sem exibi-lo ao usuário
• O anexo explora CVE-2023-41990, uma vulnerabilidade de execução remota de código em um comando de fonte TrueType ADJUST não documentado e exclusivo da Apple
  • Esse comando existia desde o início dos anos 1990 e foi removido no patch
• Em seguida, vêm vários estágios escritos com return/jump oriented programming e com a linguagem de consultas NSExpression/NSPredicate
  • O ambiente do JavaScriptCore é modificado para executar um exploit de elevação de privilégios escrito em JavaScript
• O exploit em JavaScript foi reduzido para economizar tamanho e ofuscado de forma a ficar totalmente ilegível, mas tem cerca de 11.000 linhas
  • A maior parte é usada para parsing e manipulação de memória do JavaScriptCore e do kernel
• O recurso de depuração do JavaScriptCore, DollarVM($vm), é abusado para manipular a memória do JavaScriptCore a partir do script e executar funções de API nativas
• Ele foi projetado para suportar tanto iPhones antigos quanto novos e inclui também bypass de PAC para explorar os modelos mais recentes

Acesso à memória do kernel e bypass de PPL

• O exploit usa CVE-2023-32434, uma vulnerabilidade de integer overflow nos syscalls de mapeamento de memória do XNU mach_make_memory_entry e vm_map
  • Isso fornece acesso de leitura e escrita, em nível de usuário, a toda a memória física do dispositivo
• Depois disso, ele contorna a Page Protection Layer (PPL) usando registradores MMIO de hardware
  • Essa etapa foi mitigada por CVE-2023-38606
• Após explorar todas as vulnerabilidades, o exploit em JavaScript podia executar ações arbitrárias no dispositivo
  • Os atacantes executavam o processo IMAgent e injetavam a carga útil para apagar rastros do exploit
  • Eles iniciavam o processo Safari em modo invisível e o encaminhavam para a página web do estágio seguinte
• A página web verifica a vítima e, se ela atender às condições, entrega o exploit do Safari
• O exploit do Safari usa CVE-2023-32435 para executar shellcode
• O shellcode executa outro exploit de kernel no formato de arquivo Mach object
  • Esse exploit também usa CVE-2023-32434 e CVE-2023-38606
  • Embora seja diferente em grande parte do exploit de kernel em JavaScript, compartilha uma parte do código relacionada à exploração das mesmas vulnerabilidades
• No fim, ele obtém privilégios de root e executa outras etapas para carregar o spyware

O mistério de hardware da CVE-2023-38606

• Os modelos mais recentes de iPhone têm proteções baseadas em hardware para resguardar áreas sensíveis da memória do kernel
• Essa proteção foi projetada para impedir que um atacante assuma controle total do dispositivo, mesmo que consiga ler e escrever na memória do kernel
• Os atacantes da Operation Triangulation contornaram essa proteção usando outro recurso de hardware presente nos SoCs projetados pela Apple
• O comportamento identificado é o seguinte
  • Escrevem dados, endereço de destino e hash dos dados em registradores de hardware desconhecidos do chip
  • Esses registradores parecem não ser usados pelo firmware
  • Como resultado, conseguem ignorar a proteção de memória baseada em hardware e escrever dados em endereços físicos específicos
• Esse recurso pode ter sido uma função de depuração para engenheiros da Apple ou para testes de fábrica, ou pode ter sido incluído por engano
• Como se trata de uma função não usada no firmware, não foi possível determinar como os atacantes descobriram seu funcionamento

Análise de MMIO e DeviceTree

• Os periféricos do SoC podem expor registradores especiais de hardware para que a CPU controle o dispositivo
• Esses registradores são mapeados em memória acessível pela CPU e são chamados de memory-mapped I/O (MMIO)
• Nos produtos da Apple, os intervalos de endereços MMIO de periféricos ficam armazenados no formato DeviceTree
  • Os arquivos DeviceTree podem ser extraídos do firmware
  • É possível ver seu conteúdo com o utilitário dt
• A maior parte dos MMIO usados pelos atacantes no bypass de PPL não pertencia a nenhum intervalo MMIO definido no DeviceTree
• O exploit tem como alvo os SoCs Apple A12–A16 Bionic e usa os seguintes blocos MMIO desconhecidos
  • 0x206040000
  • 0x206140000
  • 0x206150000
• Não foram encontradas referências a esses endereços em DeviceTrees de vários dispositivos e firmwares, nem em código-fonte público, imagens de kernel, extensões de kernel, iBoot ou firmware de coprocessadores auxiliares

Relação com o coprocessador auxiliar da GPU

• Ao verificar os MMIO conhecidos ao redor, os endereços desconhecidos apareciam próximos de gfx-asc, isto é, o coprocessador auxiliar da GPU
• O gfx-asc possui dois intervalos MMIO
  • 0x206400000–0x20646C000
  • 0x206050000–0x206050008
• Os endereços desconhecidos realmente usados pelo exploit são os seguintes
  • 0x206040000
  • 0x206140008
  • 0x206140108
  • 0x206150020
  • 0x206150040
  • 0x206150048
• A maioria fica entre as duas regiões de gfx-asc, e o restante fica perto do início da primeira região de gfx-asc
• A conclusão é que esses registradores muito provavelmente pertencem ao coprocessador auxiliar da GPU
• Durante a inicialização do exploit, também foi identificado código que manipula registradores do gerenciador de energia GFX em endereços diferentes conforme o SoC
  • Com o utilitário pmgr, foi possível confirmar que esses endereços correspondem a registradores GFX no intervalo MMIO do gerenciador de energia
• Ao acessar registradores da região desconhecida, o coprocessador auxiliar da GPU entrava em pânico com a mensagem “GFX SERROR Exception”
  • Esse resultado também reforça a conclusão de que os registradores pertencem ao coprocessador auxiliar da GPU

CoreSight e a região UTT proprietária da Apple

• O registrador 0x206040000 é usado apenas nas etapas de inicialização e encerramento do exploit
  • Ele é configurado primeiro na inicialização e processado por último no encerramento
• A análise indica que esse registrador serve para ativar e desativar o recurso de hardware ou controlar interrupções
• O comportamento do exploit corresponde à função ml_dbgwrap_halt_cpu no código-fonte dbgwrap.c do XNU
• O dbgwrap.c contém código que lida com registradores MMIO de depuração ARM CoreSight da CPU principal
• O código-fonte do XNU menciona quatro regiões MMIO ligadas ao CoreSight: ED, CTI, PMU e UTT
  • Cada região ocupa 0x10000 bytes
  • As quatro regiões são adjacentes entre si
• A região UTT, segundo o código-fonte, não veio da ARM, mas é um recurso proprietário da Apple adicionado por conveniência
• Ao escrever ARM_DBG_LOCK_ACCESS_KEY nesse local, foi possível confirmar que 0x206000000–0x206050000 é o bloco de registradores MMIO de depuração CoreSight do coprocessador auxiliar da GPU
• Cada núcleo da CPU principal também tem seu próprio bloco de registradores MMIO de depuração CoreSight, mas, ao contrário do coprocessador auxiliar da GPU, esses endereços podem ser encontrados no DeviceTree
• O autor do exploit também sabia como usar a região UTT proprietária da Apple para liberar um CPU halt
  • Esse código não está incluído no código-fonte do XNU

Recurso não identificado que age como DMA

• Os registradores 0x206140008 e 0x206140108 controlam a ativação, desativação e execução do recurso de hardware usado pelo exploit
• 0x206150020 é usado apenas nos SoCs Apple A15/A16 Bionic
  • Ele é configurado como 1 na inicialização e restaurado ao valor original no encerramento
• 0x206150040 é usado para armazenar flags e a metade inferior do endereço físico de destino
• 0x206150048 é usado para armazenar os dados a serem escritos, a metade superior do endereço físico de destino, o hash dos dados e mais um outro valor
  • O recurso de hardware escreve dados em blocos alinhados de 0x40 bytes
  • O registrador 0x206150048 exige 9 escritas consecutivas
• Se todo o procedimento estiver correto, o hardware realiza uma operação no estilo DMA e grava os dados no local solicitado
• O exploit usa esse recurso para contornar a PPL, principalmente aplicando patch em entradas da tabela de páginas
• Ele também pode ser usado para modificar dados no segmento protegido __PPLDATA
• Esse recurso não foi usado para modificar o código do kernel
  • Em um teste, ao sobrescrever uma instrução do kernel no segmento __TEXT_EXEC, foi obtido um panic “Undefined Kernel Instruction” no endereço e valor esperados
  • Em outras tentativas, ocorreu panic de AMCC

Hash, ECC e a possibilidade de acesso ao cache

• Na análise inicial, esse recurso parecia exigir um hash personalizado
  • O hash era calculado com uma tabela sbox predefinida
  • A busca por essa tabela em uma grande coleção de binários não encontrou nenhuma ocorrência
• O hash parecia ter 20 bits, ou seja, era composto por dois cálculos de valores de 10 bits
• Se o atacante não souber como calcular nem como usar isso, a estrutura fica próxima de security by obscurity
• Em uma atualização de 9 de janeiro de 2024, Hector Martin confirmou que esse valor não era um simples hash customizado, mas sim um código de correção de erros (ECC)
  • Mais especificamente, trata-se de um código de Hamming com tabela de lookup personalizada
• Essa descoberta ajudou a entender o objetivo original do recurso de hardware não identificado
  • No início, ele parecia ser um recurso de depuração com acesso direto à memória e um hash “falso” acoplado
  • Como há uso de ECC e foi observado comportamento instável ao modificar código do kernel, cresce a hipótese de que essa função dê acesso direto ao cache

Experimentos com M1 e mitigação no iOS 16.6

• Foi confirmado que esse recurso de hardware desconhecido também existe no chip M1 do Mac
• Com a função trace_range da ferramenta m1n1, foi feito o rastreamento de acessos MMIO no intervalo 0x206110000–0x206400000
  • Não houve relatos de uso desses registradores pelo macOS
• No iOS 16.6, a Apple mitigou o exploit adicionando os intervalos MMIO usados por ele ao pmap-io-ranges do DeviceTree
  • Os intervalos adicionados foram 0x206000000–0x206050000 e 0x206110000–0x206400000
• O XNU usa as informações de pmap-io-ranges para decidir se permite o mapeamento de determinados endereços físicos
• Entradas típicas de pmap-io-ranges trazem nomes de tag significativos, como PCIe, DART e DAPF, mas os nomes de tag dessas regiões ligadas à vulnerabilidade chamavam atenção por seu formato diferente dos demais

Perguntas em aberto e implicações de segurança

• Ainda não se sabe como os atacantes descobriram como usar esse recurso de hardware desconhecido
• O propósito original desse recurso também continua incerto
  • Não está claro se foi desenvolvido pela Apple ou se veio de um componente de terceiros, como o ARM CoreSight
• Mesmo após a atualização, o mistério permanece
  • Os atacantes até poderiam descobrir por brute force os valores da tabela de lookup personalizada apenas com experimentação
  • Mas ainda precisariam conhecer a existência desse poderoso recurso de depuração de cache, o uso do código de Hamming, a posição e finalidade dos registradores MMIO relacionados e a ordem correta de interação entre eles
• Mesmo quando existe proteção baseada em hardware, ela pode se tornar inútil diante de atacantes sofisticados se houver recursos de hardware capazes de contorná-la
• Segurança em hardware é muito mais difícil de fazer engenharia reversa do que software, mas sistemas que dependem de “security through obscurity” deixam de ser seguros no momento em que o segredo é revelado

[GN⁺]

Comentários do Hacker News

• O vídeo da apresentação também já foi publicado: https://www.youtube.com/watch?v=7VWNUUldBEE

• É um conteúdo bem impressionante. O abuso de MMIO significa que os atacantes ou tinham uma capacidade de pesquisa realmente extraordinária, ou invadiram a Apple para obter documentação interna de hardware; a segunda hipótese parece mais plausível
  Até aparecer a S-box da função de hash customizada, eu achava que talvez isso fosse possível para uma grande equipe de pesquisa no nível da NSA, mas a partir desse ponto parece que a Apple sabia que esse recurso era perigoso e o escondeu de propósito, e ainda o protegeu com uma espécie de função fraca de assinatura digital, seja lá o que aquilo for
  Como o post do blog observa, não há um método claro para encontrar a “batida mágica” correta que ativa esse recurso, a não ser desmontando e fazendo engenharia reversa de todo o silício. Isso é praticamente inviável nesse nó de processo, então sobra a hipótese de que invadiram um desenvolvedor e roubaram documentos internos
  O uso de uma longa cadeia de zero-days de alto custo para abrir um Safari invisível e então carregar uma página web com uma cadeia de exploits totalmente diferente para comprometer o dispositivo novamente também tem o cheiro de uma organização gigante com silos internos graves
  Considerando que os pesquisadores eram russos da Kaspersky, há uma grande chance de isso ser obra da NSA, ou talvez até do GCHQ
  Outra parte interessante da apresentação é que o malware consegue ativar o rastreamento de anúncios e também detectar hospedagem de iPhones em nuvem, muito usada por pesquisadores de segurança. A plataforma de malware para iOS/macOS parece ter sido desenvolvida por mais de 10 anos e até roda aprendizado de máquina no dispositivo para fazer reconhecimento de objetos e OCR, evitando enviar os bytes das fotos; só os rótulos gerados são enviados. Foi um esforço enorme, mas no fim não foi suficiente diante de estudantes russos inteligentes
  Ainda assim, não concordo totalmente com a fala do apresentador de que “segurança por obscuridade não funciona”. Essa plataforma esteve em uso real por 10 anos, e ninguém sabe por quanto tempo esse “recurso” de hardware oculto foi explorado. Se esse recurso de hardware tivesse sido documentado publicamente, ele teria sido descoberto muito, muito mais cedo

  • A parte de “teria sido descoberto muito mais cedo se o recurso de hardware fosse documentado publicamente” significa que, pelo princípio de Kerckhoffs, ele deveria ter sido documentado publicamente desde o início, e qualquer pessoa que tivesse visto a documentação antes da distribuição deveria ter dito “isso não pode ser lançado assim, esse recurso precisa ser removido”
  • Também existe um script de IoC para escanear indicadores de comprometimento do Operation Triangulation em backups do iTunes: https://github.com/KasperskyLab/triangle_check
  • É realmente um ataque impressionante, e concordo com a análise acima. A parte de “comprometer novamente” o dispositivo por meio de uma aba oculta do Safari pode, como foi dito, ser resultado ruim de silos internos na organização, ou também lembra a abordagem de “fazer vírus” usada por script kiddies dos anos 90
    Pode ser um design modular para adaptação rápida, ou seja, possivelmente uma estrutura menos direcionada
  • Ou então a Apple pode simplesmente ter implementado essa “API” porque pediram educadamente
  • Há informação errada demais nesta thread. Isso é Hamming ECC, como explicado aqui[1]
    [1] https://social.treehouse.systems/@marcan/111655847458820583

• Steve Weis resumiu isso melhor no Twitter:
  “Esse exploit de iMessage é insano. Tem uma vulnerabilidade de TrueType que existe desde os anos 90, 2 exploits de kernel, um exploit de navegador e até um recurso de hardware não documentado que não era usado no software lançado”
  https://x.com/sweis/status/1740092722487361809?s=46&t=E3U2EI...

• Se você tiver curiosidade sobre a apresentação dos pesquisadores da Kaspersky, o vídeo editado ainda não tinha sido publicado, mas o replay do streaming podia ser visto aqui:
  https://streaming.media.ccc.de/37c3/relive/a91c6e01-49cf-422...
  A apresentação começa em 26:20

  • Agora já foi publicado: https://media.ccc.de/v/37c3-11859-operation_triangulation_wh...

• Também há um post em alemão do Fefe¹ sobre a apresentação da 37c3: https://blog.fefe.de/?ts=9b729398
  Segundo ele, o valor dessa cadeia de exploits provavelmente estava na casa de oito dígitos em dólares
  ¹ https://en.wikipedia.org/wiki/Felix_von_Leitner
  Parece que alguém vai ser demitido

  • Por quê? Queimar exploits faz parte desse negócio

• Coresight não é um backdoor, é um recurso de depuração presente em todas as CPUs ARM. Isso parece ser uma extensão do Coresight necessária para funcionar junto com os recursos de proteção de memória da Apple
  Mesmo sem documentação pública, milhares de engenheiros da Apple provavelmente teriam acesso a um gdb modificado ou outras ferramentas capazes de usar isso

  • Para alguns é uma ferramenta de depuração, para outros é um backdoor
  • Ainda assim, esse hashing estranho continua sem explicação

• Se for um dispositivo supervisionado, é possível desativar o iMessage via MDM local usando o Apple Configurator gratuito da Mac App Store do macOS: https://support.apple.com/guide/deployment/restrictions-for-...
  Em dispositivos somente com Wi‑Fi, o app Messages fica oculto
  Em dispositivos com Wi‑Fi e celular, o app Messages continua visível, mas só os serviços SMS/MMS podem ser usados
  Por exemplo, ao usar o dispositivo apenas com Wi‑Fi por um longo período, dá para desativar mensagens SMS/MMS e tráfego celular não emergencial com o PIN do SIM

  • Comprei um iPad celular e coloquei o SIM do meu país para continuar recebendo SMS, porque os bancos de lá ainda exigem autenticação por SMS no login
    Mas descobri que, na prática, iPads celulares não exibem SMS que não tenham sido enviados pela operadora do cartão SIM

• Chama a atenção o fato de que o hash de gravações de dados compostas só por zeros também é zero
  E, no caso de um único bit, o valor do hash vira um único valor da tabela S-box. Ou seja, esse algoritmo de hash provavelmente poderia ter sido suficientemente revertido por engenharia reversa mesmo sem documentação interna

  • Isso tem o “cheiro” típico de um mecanismo para impedir que gravações de memória em endereços aleatórios acionem esse hardware por engano. Não parece ter sido pensado como recurso de segurança
    Na verdade, se alguém tivesse dito que um bug não podia causar uma gravação arbitrária, eu implementaria assim. Essa implementação também impede de forma eficaz o uso desse recurso quando se conhece o endereço do buffer, mas não o seu conteúdo
    Se o sistema reiniciar sempre que o hash estiver errado, até 10 bits de segurança provavelmente bastariam para esse uso. O recurso de depuração Coresight pode reiniciar completamente o sistema se quiser

• Qual seria a probabilidade de terem descoberto esse registrador MMIO por busca exaustiva em todos os endereços de registradores?
  Só pela diferença de timing já poderia dar para saber que aquele endereço era válido, e o hash na prática também pode ser só um hash de 20 bits, então talvez desse para bruteforçar

  • Parece que o registrador podia mesmo ser identificado com relativa facilidade por força bruta. Ele fica fisicamente perto de registradores de GPU documentados e, ao acessá-lo, causa panic na GPU, então os pesquisadores também o atribuíram a um componente da GPU. O atacante também poderia ter percebido a existência do registrador com o mesmo teste
    A parte menos fácil de explicar é como restauraram uma tabela S-box customizada para executar o código de depuração. É aí que a insinuação de ameaça interna fica mais forte, mas pessoalmente não acho que isso exclua outras explicações plausíveis
    Por exemplo, os atacantes podem ter extraído a S-box de firmware antigo, patches de atualização OTA, dispositivos de desenvolvimento pré-lançamento (que em algum momento provavelmente podiam ser comprados no eBay), releases beta do iOS e vários outros canais de vazamento
    O pesquisador basicamente diz que “não encontrou essa tabela S-box em nenhum outro binário analisado”. Mas, considerando que ela parece ser específica da Apple e que o número de binários em que ela provavelmente apareceria é limitado, isso não é necessariamente surpreendente. Como o próprio pesquisador disse, isso inclui binários ainda não públicos que podem ter sido distribuídos por engano. É perfeitamente plausível que os atacantes procurem esses vazamentos de forma sistemática e, em algum momento, tenham tido sorte em obtê-la, enquanto para o pesquisador pode ser difícil ter a mesma sorte tão cedo
  • Olhando para a implementação dessa S-box, é difícil acreditar que ela tenha sido implementada em hardware do chip como tabela de consulta. Deve haver uma expressão booleana mais compacta que produza o mesmo resultado
    O fato de os atacantes não conhecerem essa expressão booleana sugere mais engenharia reversa do que posse de documentação

• https://streaming.media.ccc.de/37c3/relive/11859

  • Começa em 27:21
    Juntando com o conteúdo da apresentação, a cronologia fica assim
    Setembro de 2018: lançamento do Apple A12 Bionic SOC, a primeira CPU com MMIO não documentado
    Dezembro de 2021: a infraestrutura inicial da cadeia de exploit, backuprabbit.com, foi criada em 2021-12-15T18:33:19Z, e cloudsponcer.com em 2021-12-17T16:33:50Z
    Abril de 2022: a infraestrutura posterior da cadeia de exploit, snoweeanalytics.com, foi criada em 2022-04-20T15:09:17Z, sugerindo que até essa data o exploit já estava operacionalizado
    Dezembro de 2023: parece ser o momento aproximado da detecção. Isso foi calculado a partir do período de análise de “meio ano” e do relatório da Apple de meados de 2023
    Os apresentadores dizem que, pelos vestígios no código, o grupo APT de origem usava a mesma base de código de ataque havia “10 anos”, ou seja, desde por volta de 2013, e também a usava em ataques a notebooks macOS. Isso inclui bypass de antivírus
    Os apresentadores também levantam a possibilidade de que uma funcionalidade de depuração assinada, com forte aparência de “backdoor”, tenha sido incluída no chip sem o conhecimento da Apple, por exemplo por um desenvolvedor de GPU
    Ou seja, menos de 3,5 anos após o primeiro chip vulnerável chegar ao mercado, uma série de MMIOs de depuração não documentados da GPU Apple Coresight, que exigem conhecimento de segredos longos, foi operacionalizada e explorada com sucesso por um grupo APT já existente com mais de 10 anos de histórico. A Kaspersky diz que “não especula”, mas pessoalmente acho pouco provável que isso seja viável para alguém que não seja um grande ator estatal
    Especulando, como a Apple recebeu evidências suficientes para que cerca de 40 Apple IDs ligados a APT se identificassem por conta própria, talvez dê para inferir a identidade a partir de eventuais anúncios posteriores ligados à segurança nacional dos EUA. Se tudo ficar em silêncio, provavelmente seria a NSA
  • O que parece ser a primeira versão da gravação real agora foi publicado:
    https://media.ccc.de/v/37c3-11859-operation_triangulation_wh...