En juin, le FSB accusait Apple et la NSA d’avoir lancé une vaste campagne d’espionnage sur des iPhone d’employés de Kaspersky et de diplomates russes. On en sait désormais plus sur cette opération, d’une grande sophistication. En dépit des nombreux détails techniques, il semble impossible pour l’heure d’attribuer cette attaque à qui que ce soit.
« Triangulation » : c’est le nom donné à cette campagne d’espionnage par Kaspersky. La société de sécurité, largement connue pour son antivirus, était la première visée. Les acteurs malveillants ont utilisé une série de failles 0-day ayant conduit à la compromission totale des iPhone. Dans un vaste rapport technique, l’entreprise a mis en avant deux points : les nombreuses défenses intégrées dans iOS et le degré extrême de sophistication pour les contourner et exploiter les vulnérabilités.
Mais le résultat est là : infectés, les téléphones ont livré tous leurs secrets, aussi bien les messages que la voix, les photos, données de géolocalisation et autres. Toutes ces informations ont été envoyées vers des serveurs contrôlés par les acteurs malveillants. Leur finalité d’utilisation est inconnue, mais on sait que la manœuvre a duré quatre ans et a concerné potentiellement des milliers d’iPhone.
Une série de quatre failles
Les vulnérabilités utilisées sont connues, car elles ont été corrigées entre mars et juillet de cette année. Elles sont estampillées CVE-2023-32434, CVE-2023-32435, CVE-2023-38606 et CVE-2023-41990. Mais l’exploitation de ces failles n’aurait jamais pu avoir lieu si les pirates n’avaient pas utilisé des fonctions cachées, aussi bien dans le logiciel que dans le matériel.
L’exploitation commence en effet par le simple envoi d’une pièce jointe via iMessage. L’application traite alors le fichier, en fait un code exploitant la faille CVE-2023-41990 dans la gestion de la police vectorielle TrueType, plus précisément son instruction ADJUST, non documentée et réservée à Apple. Le résultat est une exécution de code à distance.
Ce code utilise la programmation orientée retour/saut (ROP), des instructions NSExpression/NSPredicate et se sert de la bibliothèque JavaScriptCore pour parvenir à une escalade de privilèges. Cette dernière partie contient 11 000 lignes obscurcies et est dédiée à la manipulation de la mémoire du noyau, notamment via DollarVM. Le code exécuté possède alors des privilèges minimaux.
Deux autres vulnérabilités sont ensuite utilisées. CVE-2023-32434 d’abord, pour parvenir à une corruption de la mémoire de XNU, le noyau des systèmes Apple, équipé de mécanismes pour résister à ce type de tentative, notamment la couche de protection des pages (PPL). Celle-ci est contournée par l’exploitation de la faille CVE-2023-38606, située dans des registres MMIO secrets (nous y reviendrons).
La dernière faille, CVE-2023-32435, résidait dans Safari. Elle a été utilisée pour exécuter un shellcode. Ce dernier réexploite alors les failles CVE-2023-32434 et CVE-2023-38606, débloquant le graal : l’accès root et ses privilèges. La dernière charge utile du logiciel espion est alors implantée dans l’appareil.
Précisons que cette implantation ne pouvait pas résister à un redémarrage de l’appareil. Cependant, en cas d’interruption des signaux reçus, l’envoi d’un nouveau message suffisait à relancer la chaine d’exploitation, sans intervention de la victime.
Les pirates ont utilisé des fonctions cachées
Dans son compte rendu, Boris Larin, chercheur chez Kaspersky, réitère à plusieurs reprises que cette campagne d’espionnage a atteint un degré de sophistication rarement vu jusqu’ici. L’enchainement des quatre failles est déjà remarquable, mais l’opération n’aurait pas été possible sans l’utilisation de fonctions cachées. C’est ici que le niveau augmente singulièrement.
Le chercheur indique qu’au cours de la longue analyse – plus d’un an – les chercheurs se sont penchés sur les MMIO (Memory-mapped Input/Outputs), des registres matériels ayant pour mission de fournir des adresses mémoires au CPU, pour qu’il puisse communiquer avec d’autres composants matériels, tels que le GPU, l’USB ou encore les contrôleurs mémoire. Le CPU peut donc écrire des informations dans le registre matériel d’un périphérique spécifique.
Toutes ces adresses sont normalement répertoriées dans l’arborescence des périphériques (devicetree). Mais, surprise, quand les chercheurs ont parcouru cette arborescence, ils n’y ont trouvé aucune trace des adresses MMIO utilisées par les pirates. Pas davantage dans les images du noyau, dans le code source ou dans les microprogrammes, autant d’informations obtenues après une longue rétro-ingénierie.
Les chercheurs ont découvert que les pirates avaient utilisé une fonction matérielle cachée, qui leur permettait de contourner les protections matérielles mises en place par Apple : « Nous pensons que cette fonction matérielle inconnue était très probablement destinée à être utilisée à des fins de débogage ou de test par les ingénieurs d'Apple ou par l'usine, ou qu'elle a été incluse par erreur. Étant donné que cette fonction n'est pas utilisée par le micrologiciel, nous ne savons pas comment les attaquants pourraient savoir comment l'utiliser », indique le compte rendu.
C’est l’un des plus grands mystères de cette opération Triangulation : comment les acteurs malveillants en sont-ils venus à connaître cette fonction ? En l’état, personne ne semble savoir. Boris Larin ajoute que l’on ne sait même pas si la fonction faisait partie intégrante de l’iPhone, ou si elle était « simplement » activée par un composant matériel tiers, comme CoreSight d’ARM.
Une vaste opération difficile à attribuer
Si la campagne d’espionnage marque son haut degré de technicité, elle restera également dans les mémoires par son ampleur et sa durée.
La collecte des données a pu perdurer pendant quatre ans. Ce temps prouve à lui seul la sophistication de l’attaque, puisqu’elle est passée inaperçue pendant presque toute cette période. En outre, elle a ciblé en priorité une partie des employés de Kaspersky, mais les accusations de la Russie portaient sur des milliers de personnes travaillant dans des ambassades, tout spécialement celles de pays membres de l’OTAN et de l’ex-URSS, de la Chine et d’Israël.
Pour la Russie, cette campagne ne pouvait avoir qu’une origine : la NSA. Le renseignement russe (FSB) avait renchéri en accusant Apple d’avoir aidé l’agence américaine de sécurité en livrant des informations techniques et secrètes.
Dans le compte rendu technique de Kaspersky, le son de cloche est différent : aucune preuve ne permettrait actuellement d’attribuer cette attaque à un acteur spécifique. Boris Larin évoque les caractéristiques « uniques » de cette opération, qui ne correspondent à aucun schéma connu.
Bien sûr, il pourrait s’agir d’une prudence particulière de Kaspersky pour des raisons géopolitiques. Il pourrait également s’agir de prudence élémentaire face à une opération dont l’entreprise a été elle-même la victime, n’ayant pas détecté l’intrusion dans les appareils de ses employés sur une très longue durée. Elle ne s’étend pas d’ailleurs sur les données qui ont pu être collectées sur plusieurs années.
Les failles n’étaient pas limitées à iOS
Le noyau XNU et une bonne partie des technologies utilisées par Apple se retrouvent dans l’intégralité de ses produits. Comme le confirme Kaspersky, ces failles étaient techniquement exploitables sur d’autres de la marque : Mac, Apple Watch et même l’Apple TV.
Boris Larin dit ainsi avoir repéré la fameuse fonction matérielle inconnue dans la puce M1 équipant des Mac. Toutes les puces récentes d’Apple (dont les M1, M2 et M3) sont équipées de protections supplémentaires pour les registres matériels, mais la faille dans la fameuse fonction cachée a permis systématiquement de les contourner.
Dans tous les cas, les brèches ont été colmatées sur l’ensemble des appareils et la fonction cachée ne semble plus accessible aujourd’hui. Apple ne s’est pas exprimée sur les résultats dévoilés hier, les failles corrigées ou sur les déclarations de la Russie. L’entreprise avait cependant nié toute implication dans l’opération et aide apportée à la NSA.
Quoi qu’il en soit, la situation rappelle la difficulté que peuvent avoir même les entreprises les mieux équipées en matière de sécurité dans ce type de cas. C’est d’autant plus vrai avec Apple, dont une grande partie des mécanismes de sécurité ne sont pas documentés. Le travail effectué et les résultats fournis sont le résultat d’une vaste rétro-ingénierie.
Ce que Boris Larin résume ainsi : « ce que nous savons, et ce que cette vulnérabilité démontre, c'est que les protections matérielles avancées sont inutiles face à un attaquant sophistiqué tant qu'il existe des caractéristiques matérielles permettant de contourner ces protections. La sécurité du matériel repose très souvent sur la "sécurité par l'obscurité" et il y est beaucoup plus difficile de faire de la rétro-ingénierie que pour les logiciels, mais c'est une approche erronée, car tôt ou tard, tous les secrets sont révélés. Les systèmes qui reposent sur la "sécurité par l'obscurité" ne peuvent jamais être vraiment sûrs ».
Commentaires (32)
#1
Et pourtant, aujourd'hui, nombre de personnes considèrent qu'une obscurité d'un niveau suffisant les protège… quand bien même ils sont parfaitement incapables d'évaluer les moyens, la motivation ou les opportunités d'un attaquant éventuel, qui ne leur ressemblerait pas.
Merci pour ce récit détaillé, et pour la démonstration qu'une fonction laissée "au cas où", apparemment inutilisable par elle-même, mais qui pourrait être dangereuse si bien exploitée, doit systématiquement être vue comme un risque dans tout système. Et on parle de sécurité, pas uniquement informatique.
#1.1
C'est tout le problème d'ailleurs de ne plus avoir aucun constructeur européen de matériel informatique...
(et je parle bien de gérer tout bios/firmware etc)
#1.2
#1.3
#1.4
Comme je l'ai indiqué dans un autre commentaire, j'ai un doute sur la correction faite par Apple, elle me semble trop simple, mais elle bloque au moins temporairement cette attaque sophistiquée.
#1.5
Les iMessages sont vantés par Apple comme bien supérieurs à la concurrence en particulier RCS et mis en avant par les fameuses bulles bleues.
On voit ici qu'ils offrent une surface d'attaque bien plus forte qu'un simple SMS.
Et je me demande bien pourquoi l'application de messagerie Apple fait appel à une fonction gérant les fontes TrueType avant même que l'utilisateur ait demandé à afficher le message reçu d'un émetteur probablement inconnu. Cela permet une attaque 0-click alors que sinon, si l'appel se faisait suite à une demande d'affichage du iMessage, un utilisateur prudent (surtout s'il se sait cible potentielle) n'aurait pas demandé l'affichage du message et n'aurait donc pas déclenché l'attaque.
À vouloir faire trop de choses sans l'utilisateur pour lui faciliter la vie, on ouvre des failles inutilement.
Alors, oui, il y a eu aussi des failles par simple réception de SMS, mais le code nécessaire pour afficher un simple texte (SMS) est plus petit et plus facilement maîtrisable.
#1.7
#1.13
My-2-cents : L'image de l'article indique que le fichier est un PDF, j'imagine, qu'iMessage génère un aperçu du fichier pour le faire figurer dans la conversation, le fichier PDF est ouvert, interprété et une image d'aperçu du fichier est généré. Prb il faut interpréter la police pour faire le rendu du pdf, et ce composant est troué.
#1.14
#1.6
Et la réception d'un message passe bien par la couche logicielle d'iMessage ici pour pouvoir descendre sur le matériel et profiter des failles/backdoor de plus bas niveau. C'est bien mon propos : le logiciel permet une couche de protection pour ne pas pouvoir envoyer n'importe quoi à la couche basse. Et ton commentaire apporte de l'eau à mon moulin.
#1.8
Tu as manifestement une définition plus accommodante que la mienne à ce sujet. On ne pourra donc pas être d'accord.
#1.9
Du coup si pour toi ça ne l'est pas, je veux bien que tu m'expliques quels logiciels tu utilises qui auraient un niveau de sécurité suffisantes. Visiblement tu commentes ici donc tu utilises sans doute le JavaScript, à moins que tu te sois amusé à envoyer ça avec cURL.
#1.10
On est ici dans de l'attaque de niveau étatique ou assimilé (type NSO par exemple). C'est une attaque contre Kaspersky mais elle permet aussi d'attaquer des états, des opposants, etc.
Je commente dans ce contexte et le fil de commentaires est aussi sur ce sujet, en particulier le second message qui aborde le sujet de la souveraineté en citant l'absence de fabricants européens
De nombreuses cibles potentielles de ce type d'attaques utilisent du matériel grand public, y compris nos ministres. C'est par rapport à cela que je dis que un logiciel bien protégé n'existe pas. C'est encore plus vrai quand les logiciels font plein de choses inutiles et qu'ils augmentent ainsi la surface d'attaque.
Tu as raison, des logiciels qui protègent des scripts kiddies, ça existe et ça suffit pour monsieur ou madame tout le monde, mais je ne les appelle pas bien protégés. Il faut garder à l'esprit qu'ils sont vulnérables et qu'ils seront attaqués si l'enjeu en vaut la peine.
J'utilise aussi Firefox (en version ESR, donc peut-être plus éprouvée que ta version), mais je ne suis pas une cible de ce genre d'attaque, donc, ça me convient. Si j'étais une cible, j'utiliserais probablement tails pour tout ce que je voudrais protéger, mais ça serait assez pénible.
#1.12
Pour moi, dans ce contexte, on n'utilise justement pas les mêmes logiciels que le grand public, et on pourrait potentiellement utiliser le matériel grand public. Je ne vois pas en quoi utiliser PGP sur une debian minimale pose problème pour chiffrer un mail et l'envoyer à un autre ministre par exemple. Je ne suis pas d'accord avec ton a priori sur les logiciels comme quoi ils ne seraient pas assez protégés ici.
Plein de logiciel ne le serait pas, c'est certain et je ne dis pas le contraire, mais sous-entendre qu'aucun logiciel ne l'est, ça n'est pas vrai, de mon point vue. Notamment parce que plusieurs logiciels sont justement mis en avant par beaucoup de grands noms de la sécurité (Snowden, Bruce Schneier, etc.)
Ah bah pour le coup non puisque j'utilise aussi l'ESR
#1.11
Peut importe ce que tu fais tu peux avoir un espion en interne, mais disons que déjà tu limites le vecteur d'attaque avec des intérêts communs.
Bien évidemment rien ne l'empêche, mais tu as normalement déjà plus les moyens de contrôler et vérifier.
#2
#3
Il manque les complotistes dans le public chez nxi/PCI/nx pour déterminer d'où vient l'attaque, dommage.
#3.1
#4
#5
J’aimerai bien savoir a quoi ça ressemble de la rétro ingénierie concrètement.
#5.1
Pour le matériel, c'est encore plus compliqué.
#5.2
Le principe est le même pour le matériel.
Dans certains cas, du épluche le matériel même (au sens propre).
#5.3
https://youtube.com/@dexsilicium?si=JM0psQpUith4_mdh
#5.4
#6
#7
#8
#9
#10
#10.1
En effet, celui-ci ne reprend pas (suffisamment) ce qui est expliqué dans son papier à partir de :
The mystery and the CVE-2023-38606 vulnerability et jusqu'à la fin de son papier.
Il y explique ce qu'il a appris (et ce qu'il suppose) sur le matériel qui réagit aux plages d'adresses non définies dans les device tree d'Apple.
En résumé très rapide, Ces zones d'adresses servent probablement à debugger le coprocesseur GPU.
Le code de l'exploit permet d'activer un DMA de ce composant qui écrit directement dans la mémoire en bypassant les systèmes de protection de la mémoire conçus par Apple.
L'utilisation de cette fonction hardware se fait en indiquant les données à écrire et l'adresse où écrire et elle est protégée par un hash des données à inscrire en mémoire. Et c'est le calcul de ce hash fait par logiciel (qui a été désassemblé par Kaspersky) qui est secret. C'est cet algo de hash qui est qualifié de protection par l'obscurité.
Effectivement, une fois cet algo connu, il n'y a plus de protection de la mémoire. Comment les attaquants ont connu cet algo qui n'est présent dans aucun code d'Apple (que a pu étudier), mystère ! Il fait des suppositions, mais sans aucune certitude.
Pour finir, comment Apple a corrigé cette vulnérabilité : en mettant les plages d'adresses dans son device tree et en interdisant l'accès (DENY). Cela initialise probablement un mécanisme de protection interdisant l'accès à ces plages d'adresses à l'initialisation du kernel.
Mon commentaire : à voir si cette protection sera suffisante ou si elle pourra elle aussi être bypassée. En tout cas, ils ne pouvaient probablement pas faire mieux sur ces matériels. Il faudra attendre une prochaine génération de puces pour protéger mieux cette fonction.
#11
#11.1