« Operation Triangulation : ce que l’on découvre en attaquant les iPhone des chercheurs »

Chaîne d’attaque « Operation Triangulation »

• Envoi d’une pièce jointe iMessage malveillante, traitée par l’application à l’insu de l’utilisateur.
• Cette pièce jointe exploite la vulnérabilité d’exécution de code à distance CVE-2023-41990 dans une instruction de police TrueType ADJUST non documentée, spécifique à Apple.
• Utilisation de plusieurs étapes, écrites avec la programmation orientée retour/saut et le langage de requête NSExpression/NSPredicate, afin de modifier l’environnement de la bibliothèque JavaScriptCore et d’exécuter un exploit d’élévation de privilèges écrit en JavaScript.
• L’exploit JavaScript est obfusqué au point d’être totalement illisible et minimise sa taille. Environ 11 000 lignes de code sont principalement consacrées à l’analyse et à la manipulation de la mémoire de JavaScriptCore et du noyau.
• Utilisation de la fonctionnalité de débogage DollarVM($vm) de JavaScriptCore pour obtenir, depuis le script, la capacité de manipuler la mémoire de JavaScriptCore et d’exécuter des fonctions d’API natives.
• Conçu pour prendre en charge à la fois les anciens et les nouveaux iPhone, avec un contournement de Pointer Authentication Code (PAC) pour exploiter les vulnérabilités des modèles les plus récents.
• Exploitation de la vulnérabilité de dépassement d’entier CVE-2023-32434 dans les appels système de mappage mémoire de XNU (mach_make_memory_entry et vm_map) afin d’obtenir, au niveau utilisateur, un accès en lecture/écriture à l’ensemble de la mémoire physique de l’appareil.
• Contournement du Page Protection Layer (PPL) à l’aide de registres de memory-mapped I/O (MMIO). Ce point a été atténué par CVE-2023-38606.
• Une fois toutes les vulnérabilités exploitées, l’exploit JavaScript peut effectuer les actions souhaitées sur l’appareil et, au lieu d’exécuter directement un spyware, lancer le processus IMAgent et y injecter une charge utile qui efface les traces de l’exploit sur l’appareil, ou lancer le processus Safari en mode invisible pour rediriger vers une page web comportant l’étape suivante.
• La page web contient un script qui vérifie la victime et, si les contrôles sont validés, livre l’étape suivante : l’exploit Safari.
• L’exploit Safari utilise CVE-2023-32435 pour exécuter du shellcode.
• Le shellcode exécute un autre exploit noyau sous la forme d’un fichier objet Mach. Il utilise les mêmes vulnérabilités que CVE-2023-32434 et CVE-2023-38606. Il est massif par sa taille et ses fonctionnalités, mais totalement différent de l’exploit noyau écrit en JavaScript. Les parties liées sont partagées entre les deux exploits, mais l’essentiel du code est consacré à l’analyse et à la manipulation de la mémoire du noyau. Il inclut divers utilitaires de post-intrusion, dont la plupart ne sont pas utilisés.
• L’exploit obtient les privilèges root et exécute d’autres étapes pour charger le spyware.

Mystère et vulnérabilité CVE-2023-38606

• Les modèles récents d’iPhone disposent de protections de sécurité supplémentaires, basées sur le matériel, pour certaines zones sensibles de la mémoire noyau.
• Ces protections empêchent un attaquant de prendre le contrôle complet de l’appareil, même s’il parvient à lire et écrire dans la mémoire noyau.
• L’attaquant contourne cette protection matérielle en utilisant une autre fonctionnalité matérielle du SoC conçue par Apple.
• Il contourne cette protection en écrivant les données, l’adresse de destination et le hachage des données dans des registres matériels inconnus d’une puce non utilisée par le firmware.
• Cette fonctionnalité matérielle inconnue aurait probablement été prévue par des ingénieurs Apple ou pour l’usine à des fins de débogage ou de test, ou aurait été incluse par erreur.

Détails techniques

• Les différents périphériques présents dans le SoC exposent des registres matériels spéciaux que le CPU peut utiliser pour piloter ces dispositifs.
• Ces registres matériels sont mappés dans une mémoire accessible par le CPU et sont connus sous le nom de « memory-mapped I/O (MMIO) ».
• Dans les produits Apple (iPhone, Mac, etc.), les plages d’adresses MMIO des périphériques sont stockées dans un format de fichier spécial appelé DeviceTree.
• La plupart des MMIO utilisées dans l’attaque n’appartiennent à aucune plage MMIO définie dans DeviceTree.
• On ne sait pas comment les attaquants ont identifié des MMIO non utilisées par le firmware, ni à quels périphériques appartiennent ces adresses MMIO.
• Il a été établi que ces registres MMIO appartiennent à un coprocesseur GPU.
• Les attaquants utilisent ces registres MMIO pour contourner le Page Protection Layer (PPL) et modifier des entrées de table de pages.
• La méthode de calcul du hachage permet à la fonctionnalité matérielle utilisée dans l’attaque d’effectuer une opération DMA (direct memory access) vers l’emplacement mémoire demandé.

L’avis de GN⁺

• Cette recherche met au jour une chaîne d’attaque extrêmement sophistiquée visant les iPhone. C’est une découverte très importante pour les chercheurs en sécurité, qui peut contribuer à renforcer la sécurité des produits Apple.
• La manière dont les attaquants ont découvert ces fonctionnalités matérielles non utilisées par le firmware demeure un mystère. Cela souligne l’importance de la recherche en sécurité matérielle.
• Cet article offre un contenu particulièrement intéressant pour celles et ceux qui s’intéressent à la sécurité logicielle et matérielle. La complexité extrême des méthodes d’attaque et le processus d’analyse montrent la profondeur et la nécessité de la recherche en sécurité.

[GN⁺]

Commentaires Hacker News

• Ce qui est surprenant dans l’abus de MMIO

  • Les attaquants disposaient soit de capacités de recherche exceptionnelles, soit, plus probablement, ils ont piraté Apple pour obtenir une documentation matérielle interne.
  • Apple savait que cette fonctionnalité était dangereuse, l’a dissimulée et l’a protégée en plus par une fonction de signature numérique.
  • Sans décapsulation du silicium ni rétro-ingénierie, il serait impossible de trouver cette fonctionnalité ; il est donc possible qu’un développeur ait été piraté pour voler des documents internes.
  • Le fait de repirater via Safari en utilisant une autre chaîne de vulnérabilités suggère en interne une très grande organisation fortement cloisonnée.
  • Étant donné que les chercheurs sont russes, il est probable qu’il s’agisse d’un travail de la NSA ou du GCHQ.
  • Le malware peut activer le suivi publicitaire et détecter l’hébergement de services cloud d’iPhone souvent utilisés par les chercheurs en sécurité.
  • La plateforme de malware iOS/macOS est développée depuis plus de 10 ans et utilise du ML sur l’appareil pour la reconnaissance d’objets et l’OCR des photos, sans téléverser les octets des images.
  • Je ne suis pas d’accord avec l’affirmation selon laquelle l’obscurité comme mesure de sécurité ne fonctionne pas. Cette plateforme a été utilisée pendant 10 ans sans être connue.

• Résumé Twitter de Steve Weis

  • La vulnérabilité iMessage est stupéfiante : elle comprend une vulnérabilité TrueType présente depuis les années 90, 2 vulnérabilités kernel, une vulnérabilité du navigateur, ainsi qu’une fonctionnalité matérielle non documentée et inutilisée dans des logiciels commercialisés.

• Explication à propos de Coresight

  • Coresight n’est pas une backdoor, mais une fonction de débogage présente sur tous les CPU ARM.
  • Cela semble être une extension de Coresight nécessaire pour fonctionner avec les mécanismes de protection mémoire d’Apple.
  • Même sans documentation publique, des milliers d’ingénieurs Apple auraient probablement accès à un gdb modifié ou à d’autres outils permettant de l’exploiter.

• Spéculation sur la possibilité de découvrir les registres MMIO

  • Question sur la possibilité de découvrir les registres MMIO en explorant aléatoirement toutes les adresses de registres.
  • Il aurait été possible de déterminer qu’une adresse était valide uniquement par différence de timing, et comme il s’agissait d’un hash sur 20 bits, celui-ci aurait aussi pu être brute-forcé.

• Doute sur l’usage d’un hash de données dans une fonction de débogage de puce

  • Question sur l’intérêt d’utiliser un hash dans une fonction de débogage qui devrait être désactivée en production.
  • Je ne suis pas ingénieur électronicien, mais il vaut mieux qu’une fonction de débogage reste simple et rapide afin de minimiser les interférences.
  • Il est très peu probable qu’un attaquant de la supply chain ait pu l’implanter sur toutes les puces Apple.

• Observation sur les caractéristiques de l’algorithme de hash

  • Quand toutes les données valent 0, la valeur du hash est 0, et pour un seul bit, elle prend une valeur unique dans la table sbox.
  • Il est possible qu’un tel algorithme de hash ait pu être rétro-ingéniéré même sans documentation interne.

• Admiration pour les efforts des attaquants

  • Question de savoir si ces attaquants ressentent de la frustration de ne pas être reconnus pour leur travail.

• Explication de la fonctionnalité exploitée par les attaquants

  • Les attaquants peuvent écrire des données à des adresses physiques spécifiques en contournant la protection mémoire matérielle.
  • Cela consiste à écrire des données, l’adresse de destination et le hash des données dans des registres matériels inconnus d’une puce non utilisés par le firmware.

• Importance des nouvelles vulnérabilités découvertes

  • Il est plus important de savoir si ses propres vulnérabilités peuvent être compromises que d’en obtenir de nouvelles.
  • Cela peut aider à empêcher des opérations de contre-renseignement.