Operation Triangulation : ce que l’on obtient en attaquant les iPhone de chercheurs

 (securelist.com)
1 points par GN⁺ 2023-12-28 | 1 commentaires | Partager sur WhatsApp
  • Les chercheurs de Kaspersky ont présenté à la 37C3 la chaîne d’attaque iMessage 0-click sur iPhone d’Operation Triangulation, qu’ils considèrent comme la plus sophistiquée qu’ils aient jamais vue
  • L’attaque était conçue pour fonctionner jusqu’à iOS 16.2 et enchaînait quatre zero-days pour aboutir à l’exécution de code à distance, l’élévation de privilèges, le contournement de PPL et l’exécution d’une étape Safari
  • Le principal mystère concerne la partie atténuée sous CVE-2023-38606 : les attaquants ont utilisé des registres MMIO inconnus des SoC Apple A12–A16 Bionic pour contourner la protection matérielle de la mémoire du noyau
  • L’analyse indique que ces registres semblent liés au coprocesseur GPU ; certains ne sont référencés ni dans le DeviceTree ni dans le firmware, si bien qu’on ignore comment les attaquants ont appris à les utiliser
  • Dans la mise à jour du 9 janvier 2024, la valeur qui semblait être un « hash personnalisé » a été identifiée comme un ECC basé sur un code de Hamming, ce qui rend plus probable l’hypothèse d’une fonction de débogage accédant directement au cache plutôt qu’à la mémoire

Chaîne d’attaque dévoilée

  • Les résultats d’une analyse au long cours d’Operation Triangulation ont été publiés lors d’une présentation à la 37C3 le 27 décembre 2023
  • Cette présentation a révélé pour la première fois les détails des exploits et des vulnérabilités utilisés dans l’attaque
  • Les chercheurs ont découvert et signalé plus de 30 zero-days exploités dans la nature dans des produits Adobe, Apple, Google et Microsoft, mais ils estiment que cette chaîne d’attaque est parmi les plus sophistiquées

De l’iMessage 0-click au chargement du spyware

  • L’attaquant envoie une pièce jointe iMessage malveillante, que l’application traite sans l’afficher à l’utilisateur
  • La pièce jointe exploite CVE-2023-41990, une vulnérabilité d’exécution de code à distance dans la commande de police TrueType propriétaire et non documentée ADJUST d’Apple
    • Cette commande existait depuis le début des années 1990 et a été supprimée par le correctif
  • Plusieurs étapes suivent ensuite, écrites en return/jump oriented programming et dans le langage de requête NSExpression/NSPredicate
    • Elles patchent l’environnement JavaScriptCore pour exécuter un exploit d’élévation de privilèges écrit en JavaScript
  • L’exploit JavaScript a été réduit en taille et fortement obfusqué jusqu’à être totalement illisible, mais représente environ 11 000 lignes
    • L’essentiel sert à analyser et manipuler JavaScriptCore et la mémoire du noyau
  • Il abuse de DollarVM($vm), une fonctionnalité de débogage de JavaScriptCore, pour manipuler la mémoire de JavaScriptCore depuis le script et exécuter des fonctions d’API natives
  • Il est conçu pour prendre en charge à la fois les anciens et les nouveaux iPhone, et inclut aussi un contournement de PAC pour exploiter les modèles récents

Accès à la mémoire du noyau et contournement de PPL

  • L’exploit utilise CVE-2023-32434, une vulnérabilité de dépassement d’entier dans les appels système de mappage mémoire XNU mach_make_memory_entry et vm_map
    • Cela permet d’obtenir, depuis le niveau utilisateur, un accès en lecture/écriture à toute la mémoire physique de l’appareil
  • Il contourne ensuite la Page Protection Layer(PPL) au moyen de registres MMIO matériels
  • Une fois toutes les vulnérabilités exploitées, l’exploit JavaScript pouvait effectuer des actions arbitraires sur l’appareil
    • L’attaquant lançait le processus IMAgent et y injectait une charge utile pour effacer les traces de l’exploit
    • Il lançait le processus Safari en mode invisible et le faisait passer à la page web de l’étape suivante
  • La page web vérifie la victime puis, si les conditions sont remplies, livre l’exploit Safari
  • L’exploit Safari utilise CVE-2023-32435 pour exécuter du shellcode
  • Le shellcode exécute un autre exploit noyau sous forme de fichier Mach object
    • Cet exploit utilise lui aussi CVE-2023-32434 et CVE-2023-38606
    • Il diffère largement de l’exploit noyau JavaScript, mais partage une partie du code liée à l’exploitation des mêmes vulnérabilités
  • Au final, l’attaquant obtient les droits root et exécute d’autres étapes pour charger le spyware

Le mystère matériel de CVE-2023-38606

  • Les modèles récents d’iPhone disposent d’une protection matérielle destinée à protéger les zones sensibles de la mémoire du noyau
  • Cette protection est conçue pour empêcher un attaquant de prendre totalement le contrôle de l’appareil même s’il peut lire et écrire dans la mémoire du noyau
  • Les attaquants d’Operation Triangulation ont utilisé une autre fonction matérielle du SoC conçu par Apple pour contourner cette protection
  • Le comportement identifié est le suivant
    • Écriture des données, de l’adresse de destination et du hash des données dans des registres matériels inconnus de la puce
    • Ces registres ne semblent pas être utilisés par le firmware
    • Résultat : il devient possible d’écrire des données à certaines adresses physiques en contournant la protection mémoire matérielle
  • Cette fonction pourrait avoir été une fonctionnalité de débogage destinée aux ingénieurs Apple ou aux tests en usine, ou avoir été incluse par erreur
  • Comme il s’agit d’une fonction non utilisée par le firmware, on ignore comment les attaquants ont appris à s’en servir

Analyse de MMIO et du DeviceTree

  • Les périphériques d’un SoC peuvent fournir des registres matériels spéciaux pour permettre au CPU de les contrôler
  • Ces registres sont mappés dans la mémoire accessible au CPU et sont appelés memory-mapped I/O(MMIO)
  • Les plages d’adresses MMIO des périphériques dans les produits Apple sont stockées au format DeviceTree
    • Les fichiers DeviceTree peuvent être extraits du firmware
    • L’utilitaire dt permet d’en consulter le contenu
  • La plupart des MMIO utilisés par les attaquants pour contourner PPL n’appartenaient à aucune plage MMIO définie dans le DeviceTree
  • L’exploit cible les SoC Apple A12–A16 Bionic et utilise les blocs MMIO inconnus suivants
    • 0x206040000
    • 0x206140000
    • 0x206150000
  • Aucune référence à ces adresses n’a été trouvée dans les DeviceTree de plusieurs appareils et firmwares, ni dans le code source public, les images noyau, les extensions noyau, iBoot ou les firmwares de coprocesseurs

Lien avec le coprocesseur GPU

  • En examinant les MMIO connus environnants, les adresses inconnues se trouvaient à proximité de gfx-asc, c’est-à-dire le coprocesseur GPU
  • gfx-asc possède deux plages MMIO
    • 0x206400000–0x20646C000
    • 0x206050000–0x206050008
  • Les adresses inconnues réellement utilisées par l’exploit sont les suivantes
    • 0x206040000
    • 0x206140008
    • 0x206140108
    • 0x206150020
    • 0x206150040
    • 0x206150048
  • La plupart se trouvent entre les deux zones gfx-asc, et la dernière près du début de la première zone gfx-asc
  • Ces registres sont donc très probablement associés au coprocesseur GPU
  • Dans la phase d’initialisation de l’exploit, du code manipulant des registres du gestionnaire d’alimentation GFX à des adresses différentes selon le SoC a aussi été observé
    • L’utilitaire pmgr a permis de confirmer que ces adresses correspondent à des registres GFX dans la plage MMIO du gestionnaire d’alimentation
  • L’accès aux registres de la zone inconnue a provoqué un panic du coprocesseur GPU avec le message « GFX SERROR Exception »
    • Ce résultat renforce lui aussi l’hypothèse que ces registres appartiennent au coprocesseur GPU

CoreSight et zone UTT propre à Apple

  • Le registre 0x206040000 n’est utilisé que lors des phases d’initialisation et de terminaison de l’exploit
    • Il est configuré en premier pendant l’initialisation et traité en dernier lors de la terminaison
  • Ce registre est analysé comme servant à activer ou désactiver une fonction matérielle, ou à contrôler des interruptions
  • Le comportement de l’exploit correspond à la fonction ml_dbgwrap_halt_cpu du code source XNU dbgwrap.c
  • dbgwrap.c est du code qui manipule les registres de débogage MMIO ARM CoreSight du CPU principal
  • Le code source XNU mentionne quatre zones MMIO liées à CoreSight : ED, CTI, PMU et UTT
    • Chaque zone occupe 0x10000 octets
    • Les quatre zones sont contiguës
  • Le code source indique que la zone UTT ne vient pas d’ARM, mais qu’il s’agit d’une fonctionnalité propre à Apple ajoutée par commodité
  • En écrivant ARM_DBG_LOCK_ACCESS_KEY à cet emplacement, on peut confirmer que 0x206000000–0x206050000 correspond au bloc de registres de débogage MMIO CoreSight du coprocesseur GPU
  • Chaque cœur du CPU principal possède également son propre bloc de registres de débogage MMIO CoreSight, mais contrairement à celui du coprocesseur GPU, son adresse figure dans le DeviceTree
  • L’auteur de l’exploit savait aussi comment utiliser la zone UTT propre à Apple pour lever l’arrêt du CPU
    • Ce code ne figure pas dans le code source XNU

Fonction inconnue se comportant comme du DMA

  • Les registres 0x206140008 et 0x206140108 contrôlent l’activation, la désactivation et l’exécution de la fonction matérielle utilisée par l’exploit
  • 0x206150020 n’est utilisé que sur les SoC Apple A15/A16 Bionic
    • Il est réglé à 1 pendant l’initialisation, puis restauré à sa valeur d’origine à la terminaison
  • 0x206150040 sert à stocker des flags et la moitié basse de l’adresse physique de destination
  • 0x206150048 sert à stocker ensemble les données à écrire, la moitié haute de l’adresse physique de destination, le hash des données et une autre valeur
    • La fonction matérielle écrit les données par blocs alignés de 0x40 octets
    • Le registre 0x206150048 nécessite 9 écritures consécutives
  • Si toute la procédure est correcte, le matériel effectue une opération de type DMA et écrit les données à l’emplacement demandé
  • L’exploit utilise cette fonction pour contourner PPL, principalement en patchant des entrées de tables de pages
  • Elle peut aussi être utilisée pour patcher des données dans le segment protégé __PPLDATA
  • Cette fonction n’a pas été utilisée pour patcher le code du noyau
    • Lors d’un test, l’écrasement d’une instruction du noyau dans le segment __TEXT_EXEC a produit un panic « Undefined Kernel Instruction » avec l’adresse et la valeur attendues
    • Lors d’une autre tentative, un panic AMCC s’est produit

Hash, ECC et possibilité d’accès au cache

  • L’analyse initiale laissait penser que cette fonction exigeait un hash personnalisé
    • Le hash était calculé à l’aide d’une table sbox prédéfinie
    • Une recherche de cette table dans une grande collection de binaires n’a rien donné
  • Le hash semblait faire 20 bits, sous la forme de deux calculs d’une valeur de 10 bits
  • Si les attaquants n’en connaissaient pas le calcul et l’usage, cette structure s’apparente à de la security by obscurity
  • Dans la mise à jour du 9 janvier 2024, Hector Martin a confirmé que cette valeur n’était pas un simple hash personnalisé, mais un code de correction d’erreurs(ECC)
    • Plus précisément, il s’agit d’un code de Hamming utilisant une lookup table personnalisée
  • Cette découverte fournit un indice sur l’objectif d’origine de la fonction matérielle inconnue
    • Au départ, cela ressemblait à une fonction de débogage donnant un accès direct à la mémoire avec un hash « factice » ajouté
    • Compte tenu de l’utilisation d’ECC et du comportement instable observé lors du patching du code noyau, il devient plus probable que cette fonction permette un accès direct au cache

Expériences sur M1 et atténuation dans iOS 16.6

  • Il a été confirmé que la puce M1 des Mac possède elle aussi cette fonction matérielle inconnue
  • La fonction trace_range de l’outil m1n1 a été utilisée pour tracer les accès MMIO dans la plage 0x206110000–0x206400000
    • Aucun signe d’utilisation de ces registres par macOS n’a été signalé
  • Dans iOS 16.6, Apple a atténué la vulnérabilité en ajoutant les plages MMIO utilisées par l’exploit à pmap-io-ranges dans le DeviceTree
    • Les plages ajoutées sont 0x206000000–0x206050000 et 0x206110000–0x206400000
  • XNU utilise les informations de pmap-io-ranges pour décider s’il autorise le mappage de certaines adresses physiques
  • Les entrées habituelles de pmap-io-ranges portent des noms de tag explicites comme PCIe, DART ou DAPF, mais les noms de tag des zones liées à cette vulnérabilité se distinguaient nettement des autres entrées

Questions restantes et implications de sécurité

  • On ignore comment les attaquants ont appris à utiliser cette fonction matérielle inconnue
  • L’objectif d’origine de cette fonction reste lui aussi flou
    • On ne sait pas si elle a été développée par Apple ou s’il s’agit d’un composant tiers comme ARM CoreSight
  • Même après la mise à jour, le mystère demeure
    • Les attaquants pourraient brute-forcer les valeurs de la lookup table personnalisée uniquement par expérimentation
    • Mais il fallait connaître l’existence d’une puissante fonction de débogage du cache, l’usage d’un code de Hamming, l’emplacement et le rôle des registres MMIO concernés, ainsi que l’ordre des interactions
  • Même en présence de protections matérielles, l’existence d’une fonction matérielle capable de les contourner peut les rendre inefficaces face à des attaquants sophistiqués
  • La sécurité matérielle est bien plus difficile à rétro-ingénierer que le logiciel, mais les systèmes qui reposent sur la « security through obscurity » cessent d’être sûrs dès que le secret est dévoilé

À lire aussi

1 commentaires

 
GN⁺ 2023-12-28
Avis Hacker News

  • La vidéo de la présentation est désormais en ligne aussi : https://www.youtube.com/watch?v=7VWNUUldBEE

  • C’est assez stupéfiant. L’exploitation de MMIO signifie soit que les attaquants disposent de capacités de recherche absolument énormes, soit qu’ils ont piraté Apple pour obtenir de la documentation matérielle interne ; la seconde hypothèse paraît plus plausible
    Jusqu’à l’apparition de la S-box de la fonction de hachage personnalisée, j’aurais pu imaginer qu’une grande équipe de recherche de niveau NSA y parvienne, mais à partir de là, il semble qu’Apple savait que cette fonctionnalité était dangereuse, l’avait délibérément cachée et, quoi qu’elle soit, l’avait en plus protégée par une sorte de faible mécanisme de signature numérique
    Comme le souligne l’article de blog, à part démonter tout le silicium pour en faire de la rétro-ingénierie, il n’existe pas vraiment de moyen évident de trouver le bon « toc-toc magique » qui active cette fonctionnalité. Sur ce type de nœud de gravure, c’est pratiquement irréaliste, ce qui laisse l’hypothèse du piratage d’un développeur pour voler de la documentation interne
    Le fait d’utiliser une longue chaîne de zero-days coûteuse pour lancer un Safari invisible, puis de charger une page web via une chaîne d’exploits totalement différente afin de re-pirater l’appareil, sent aussi la très grande organisation aux silos internes très marqués
    Étant donné que les chercheurs de Kaspersky sont russes, il est très probable que ce soit quasiment la NSA, voire peut-être une opération du GCHQ
    Parmi les autres points intéressants de la présentation : le malware peut activer le suivi publicitaire et détecter aussi l’hébergement d’iPhone dans le cloud, souvent utilisé par les chercheurs en sécurité. La plateforme de malware iOS/macOS semble avoir été développée pendant plus de dix ans ; elle va jusqu’à exécuter du machine learning sur l’appareil pour faire de la reconnaissance d’objets et de l’OCR afin de ne pas téléverser les octets des photos, mais seulement les labels générés. Un effort vraiment considérable, mais au final insuffisant face à de brillants étudiants russes
    Cela dit, je ne suis pas entièrement d’accord avec l’affirmation du présentateur selon laquelle « la sécurité par l’obscurité ne fonctionne pas ». Cette plateforme était présente dans la nature pendant dix ans, et personne ne sait depuis combien de temps cette « fonctionnalité » matérielle cachée a été exploitée. Si cette fonctionnalité matérielle avait été documentée publiquement, elle aurait été découverte beaucoup, beaucoup plus vite

    • Quand on dit que « si la fonctionnalité matérielle avait été documentée publiquement, elle aurait été découverte beaucoup plus vite », cela signifie qu’en vertu du principe de Kerckhoffs, elle aurait dû être documentée publiquement dès le départ, et que quiconque aurait lu la documentation avant le déploiement aurait dû dire : « il ne faut pas lancer ça tel quel, il faut retirer cette fonctionnalité »
    • Il existe aussi un script IoC permettant de rechercher les indicateurs de compromission d’Operation Triangulation dans les sauvegardes iTunes : https://github.com/KasperskyLab/triangle_check
    • C’est une attaque vraiment impressionnante, et je suis d’accord avec l’analyse ci-dessus. La partie où l’appareil est « re-piraté » via un onglet Safari caché peut, comme indiqué, être le résultat de mauvais silos organisationnels internes, mais elle rappelle aussi l’approche « kit de création de virus » utilisée par les script kiddies des années 90
      Cela pourrait être une conception modulaire destinée à s’adapter rapidement, donc possiblement une architecture moins ciblée
    • Ou alors Apple a peut-être simplement implémenté cette « API » quand ils le lui ont demandé poliment
    • Il y a beaucoup trop de désinformation dans ce fil. C’est du Hamming ECC, comme expliqué ici[1]
      [1] https://social.treehouse.systems/@marcan/111655847458820583

  • Steve Weis l’a le mieux résumé sur Twitter :
    « Cet exploit iMessage est délirant. Il y a une vulnérabilité TrueType présente depuis les années 90, deux exploits kernel, un exploit de navigateur, et même une fonctionnalité matérielle non documentée qui n’était pas utilisée dans les logiciels livrés »
    https://x.com/sweis/status/1740092722487361809?s=46&t=E3U2EI...

  • Si la présentation des chercheurs de Kaspersky vous intéresse, la vidéo montée n’est pas encore en ligne, mais le replay du stream est disponible ici :
    https://streaming.media.ccc.de/37c3/relive/a91c6e01-49cf-422...
    La présentation commence à 26:20

  • À propos de la présentation du 37c3, il y a aussi un billet en allemand de Fefe¹ : https://blog.fefe.de/?ts=9b729398
    Selon lui, cette chaîne d’exploits valait probablement un montant en dollars à huit chiffres
    ¹ https://en.wikipedia.org/wiki/Felix_von_Leitner
    Quelqu’un risque de se faire virer

    • Pourquoi ? Qu’un exploit soit « brûlé », ça fait partie de ce business

  • Coresight n’est pas une backdoor, mais une fonctionnalité de débogage présente dans tous les CPU ARM. Cela ressemble à une extension de Coresight nécessaire pour fonctionner avec les protections mémoire d’Apple
    Même s’il n’existe pas de documentation publique, des milliers d’ingénieurs Apple doivent avoir accès à un gdb modifié ou à d’autres outils capables de l’exploiter

    • Pour certains, c’est un outil de débogage ; pour d’autres, c’est une backdoor
    • Cela n’explique toujours pas ce hachage bizarre

  • S’il s’agit d’un appareil supervisé, il est possible de désactiver iMessage via un MDM local avec l’outil gratuit Apple Configurator du macOS App Store : https://support.apple.com/guide/deployment/restrictions-for-...
    Sur les appareils uniquement Wi‑Fi, l’app Messages est masquée.
    Sur les appareils avec Wi‑Fi et cellulaire, l’app Messages reste visible, mais seuls les services SMS/MMS sont utilisables.
    Par exemple, lorsqu’un appareil est utilisé longtemps uniquement en Wi‑Fi, un code PIN SIM permet de désactiver les messages SMS/MMS et le trafic radio cellulaire non urgent.

    • J’ai acheté un iPad cellulaire pour y mettre la carte SIM de mon pays d’origine et continuer à recevoir des SMS, parce que les banques de ce pays exigent encore une authentification par SMS lors de la connexion.
      Mais j’ai découvert qu’un iPad cellulaire n’affiche pratiquement pas les SMS qui ne proviennent pas de l’opérateur de la carte SIM.

  • Il est frappant que la valeur de hachage d’une écriture de données composées uniquement de zéros soit 0.
    Et, pour un bit unique, la valeur de hachage devient une seule valeur de la table S-box. Autrement dit, cet algorithme de hachage aurait probablement pu être suffisamment rétro‑ingénieré sans documentation interne.

    • Ça a l’odeur d’un mécanisme classique destiné à empêcher des écritures mémoire à des adresses aléatoires de déclencher ce matériel par accident. Ça ne semble pas avoir été conçu comme une fonction de sécurité.
      En pratique, si quelqu’un m’avait dit qu’une écriture arbitraire due à un bug ne devait pas pouvoir se produire, je l’aurais implémenté comme ça. Cette implémentation empêche aussi efficacement d’utiliser cette fonction lorsqu’on connaît l’adresse du tampon mais pas son contenu.
      Si le système redémarre à chaque fois que la valeur de hachage est incorrecte, une sécurité de 10 bits est probablement suffisante pour cet usage. La fonction de débogage Coresight peut, si on le souhaite, redémarrer complètement le système.

  • Quelle est la probabilité que ce registre MMIO ait été découvert par recherche exhaustive sur toutes les adresses de registres ?
    Les seules différences de timing auraient pu indiquer que l’adresse était valide, et le hachage étant en pratique un hachage sur 20 bits, il a peut-être aussi été possible de le brute-forcer.

    • Le registre semble avoir été assez facile à identifier par force brute. Il est physiquement proche de registres GPU documentés et, lorsqu’on y accède, il provoque une panique GPU, si bien que les chercheurs l’ont eux aussi attribué à un composant GPU. Les attaquants auraient pu découvrir l’existence du registre avec les mêmes tests.
      La partie moins facile à expliquer est la façon dont ils ont récupéré la table S-box personnalisée pour exécuter le code de débogage. C’est là que l’hypothèse de la menace interne devient la plus forte, mais, personnellement, je ne pense pas que cela exclue d’autres explications plausibles.
      Par exemple, les attaquants ont pu extraire la S-box d’un ancien firmware, de correctifs de mise à jour OTA, d’appareils de développement précommercialisation (qui ont très probablement pu s’acheter sur eBay à un moment donné), de versions bêta d’iOS ou de nombreuses autres voies de fuite.
      Le chercheur dit en substance : « nous n’avons trouvé cette table S-box dans aucun autre binaire que nous avons examiné ». Mais, puisqu’elle semble propre à Apple, le nombre de binaires dans lesquels elle aurait pu apparaître est limité, ce qui n’est pas forcément surprenant. Comme le chercheur l’a aussi dit, cela inclut des binaires qui ne sont pas publics aujourd’hui et qui ont pu être distribués par erreur. Il est tout à fait plausible que les attaquants aient recherché systématiquement ce type de fuite et aient eu de la chance à un moment donné, sans que le chercheur puisse nécessairement avoir la même chance rapidement.
    • Quand on regarde cette implémentation de la S-box, il est difficile de croire qu’elle ait été implémentée sous forme de table de correspondance dans le matériel de la puce. Il doit exister une expression booléenne plus compacte produisant le même résultat.
      Le fait que les attaquants ne connaissaient pas cette expression booléenne suggère plutôt une rétro‑ingénierie qu’un accès à la documentation.

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

    • Ça commence à 27:21.
      En combinant cela avec la présentation et en l’ordonnant chronologiquement, on obtient ceci :
      Septembre 2018 : sortie de l’Apple A12 Bionic SOC, premier CPU doté de MMIO non documentées.
      Décembre 2021 : l’infrastructure de la chaîne d’exploitation initiale, backuprabbit.com, est créée le 2021-12-15T18:33:19Z, et cloudsponcer.com le 2021-12-17T16:33:50Z.
      Avril 2022 : l’infrastructure ultérieure de la chaîne d’exploitation, snoweeanalytics.com, est créée le 2022-04-20T15:09:17Z, ce qui suggère que l’exploit était militarisé à cette date au plus tard.
      Décembre 2023 : cela semble être la date approximative de détection, déduite de la période d’analyse de « six mois » et du rapport d’Apple à la mi‑2023.
      Les intervenants disent que, d’après les traces dans le code, le groupe APT à l’origine utilisait la même base de code d’attaque depuis « 10 ans », c’est-à-dire vers 2013, et qu’elle sert aussi à attaquer des ordinateurs portables macOS. Elle inclut aussi le contournement d’antivirus.
      Les intervenants évoquent également la possibilité qu’une fonction de débogage signée, très « backdoor-like », ait été intégrée à la puce à l’insu d’Apple, par exemple par un développeur GPU.
      Autrement dit, moins de 3,5 ans après la mise sur le marché de la première puce vulnérable, une série de MMIO de débogage non documentées du GPU Apple Coresight, nécessitant la connaissance d’une longue valeur secrète, a été militarisée et exploitée avec succès par un groupe APT existant fort de plus de dix ans d’historique. Kaspersky dit « ne pas spéculer », mais, personnellement, j’ai du mal à voir autre chose qu’un grand acteur étatique.
      Si je devais spéculer, je dirais qu’Apple a reçu suffisamment de preuves qu’environ 40 identifiants Apple liés à l’APT ont exposé leur propre identité ; on pourra donc peut-être en juger à partir d’éventuelles annonces américaines liées à la sécurité nationale. S’il n’y a pas de bruit, ce sera probablement la NSA.
    • Ce qui semble être la première version du véritable enregistrement est maintenant en ligne :
      https://media.ccc.de/v/37c3-11859-operation_triangulation_wh...