Attaque zero-click : comment voler les photos sur l’iPhone d’une personne à côté de vous dans la rue ?

L’article propose un titre très précis et intéressant, à savoir : An iOS zero-click radio proximity exploit odyssey (l’odyssée iOS d’un exploit de type proximité radio zero-click).

Mais c’est plutôt le titre de notre article qui illustre en pratique véritablement la philosophie de cette attaque zero-click de Beer.

La séquence d’exploit qu’il a imaginée permet vraiment à un attaquant de pénétrer dans un iPhone à proximité, en utilisant uniquement des connexions sans fil, et de voler des données personnelles, sans aucun clic ni avertissement, dupant ainsi l’utilisateur dont l’attention est accaparée par l’utilisation de son appareil.

En effet, l’article de Beer se termine par une courte vidéo le montrant en train de voler de manière automatique une photo présente sur son propre téléphone à l’aide d’un kit de piratage installé dans la pièce voisine :

• Il prend une photo d’un “document secret” à l’aide de l’iPhone dans une première pièce.
• Il laisse “l’utilisateur” du téléphone (un ours en peluche rose géant, en l’occurrence) assis tranquillement en train de regarder une vidéo YouTube.
• Il passe ensuite dans la pièce voisine et lance une attaque over-the-air automatisée qui exploite un bug au niveau du noyau du téléphone.
• L’exploit upload sournoisement un code malveillant sur le téléphone, se donne un accès au répertoire de données de l’application Photo, lit le fichier photo “secret” et l’upload de manière invisible sur son ordinateur portable présent à proximité.
• Le téléphone continue de fonctionner normalement tout au long de cette opération, sans aucun avertissement, pop-up ou autre signe qui pourrait alerter l’utilisateur d’un éventuel piratage.

Concernant ce piratage, c’est vraiment la mauvaise nouvelle.

Par contre, la bonne nouvelle est que la vulnérabilité principale sur laquelle Beer s’est appuyé est celle qu’il a lui-même découverte il y a plusieurs mois, signalée à Apple, et qui a déjà été corrigée.

NB : Selon le rapport de Beer : “Ce problème spécifique a été résolu avant le lancement de la focntionnalité ‘Privacy-Preserving Contact Tracing’ dans iOS 13.5 en mai 2020.

Donc, si vous avez mis à jour votre iPhone au cours des derniers mois, vous devriez être à l’abri de cette attaque zero-click spécifique.

L’autre bonne nouvelle est qu’il a fallu à Beer, de son propre aveu, six mois de travail minutieux et assidu pour comprendre comment exploiter son propre bug.

Pour vous donner une idée des efforts qu’il a fallu déployer concernant la vidéo de 5 minutes intitulée : “teddy bear’s data theft picnic” ci-dessus, et à titre d’avertissement si vous envisagez d’analyser en détail l’excellent article de Beer, gardez à l’esprit que son article de blog compte plus de 30 000 mots, plus long que ‘La ferme des animaux’ de George Orwell ou ‘Un chant de Noël’ de Charles Dickens.

Vous vous demandez peut-être, bien sûr, pourquoi Beer a pris la peine de prendre un bug qu’il avait trouvé et déjà signalé, et a déployé tant d’efforts dans le but de l’armer, pour reprendre le jargon paramilitaire couramment utilisé dans le domaine de la cybersécurité.

Eh bien, Beer donne lui-même la réponse, dès le début de son article :

L’élément important à retenir dans ce projet ne devrait pas être : personne ne passera six mois de sa vie à essayer de pirater mon téléphone, c’est bon !

Au lieu de cela, il faudrait plutôt retenir que : une personne, travaillant seule dans sa chambre, a pu créer une capacité qui lui a permis de compromettre sérieusement les utilisateurs d’iPhone avec lesquels elle aurait été en contact étroit.

Pour clarifier : Beer, via Google, a rapidement signalé le bug original, et selon nos informations, personne d’autre ne l’avait découvert avant lui, il est donc peu probable que ce bug ait été exploité par quiconque sur le terrain.

Cependant, il est tout à fait possible qu’une fois le dépassement de tampon au niveau du noyau découvert, même face aux dernières et meilleures mitigations d’exploit, un attaquant déterminé pourrait en produire un exploit dangereux.

Même si les contrôles de sécurité tels que la distribution aléatoire de l’espace d’adressage (ASLR : Address Space Layout Randomisation) et les codes d’authentification des pointeurs (PAC : Pointer Authentication Codes) augmentent considérablement notre cybersécurité, ces derniers n’auront pas l’effet d’une baguette magique (silver bullets).

Mozilla le souligne d’ailleurs, plutôt sèchement, lors de la correction des défauts liés à une mauvaise gestion de la mémoire dans Firefox, concernant des erreurs apparemment inoffensives ou dissimulées que l’équipe n’a pas pu ou n’a pas compris comment exploiter : “Certains de ces bugs ont montré des preuves de corruption de la mémoire et nous pensons qu’avec suffisamment d’efforts, certains d’entre eux auraient pu être exploités afin d’exécuter du code arbitraire”.

En bref, trouver des bugs est vital; les corriger est essentiel; apprendre de nos erreurs est important; mais nous devons néanmoins continuer à faire évoluer en permanence nos défenses en matière de cybersécurité.

La route qui mène à l’attaque zero-click opérationnelle de Beer

Il est difficile de rendre hommage aux efforts de Beer dans un résumé bref comme celui-ci, mais voici une description (peut-être trop simpliste) de quelques-unes des compétences de piratage qu’il a utilisées :

• Repérer un nom de variable de noyau qui semblait risqué : le nom plutôt surprenant qui a tout déclenché était IO80211AWDLPeer :: parseAwdlSyncTreeTLV, où TLV fait référence à Type-Length-Value (type-longueur-valeur), un moyen de regrouper des données complexes d’un côté pour déconstruire (analyser) de l’autre. AWDL est l’abréviation d’Apple Wireless Direct Link, le réseau maillé sans fil propriétaire utilisé pour les fonctionnalités Apple telles qu’AirDrop. Ce nom de fonction implique la présence d’un code complexe au niveau du noyau qui soit directement exposé à des données non approuvées envoyées à partir d’autres périphériques. Ce type de code est souvent une source d’erreurs de programmation dangereuses.
• Recherche d’un bug dans le code de traitement des données TLV : Beer a remarqué un détail concernant un objet de données TLV limité à une mémoire tampon de seulement 60 octets (10 adresses MAC au maximum) qui a été incorrectement “vérifié en longueur” par rapport à une limite de sécurité générique de 1024 octets, au lieu de la taille réelle du tampon disponible.
• Construire une pile de pilotes réseau AWDL pour créer des paquets douteux : ironiquement, Beer a commencé avec un projet open source existant destiné à être compatible avec le code propriétaire d’Apple, mais n’a pas pu le faire fonctionner comme il le souhaitait. Il a donc fini par développer le sien.
• Trouver un moyen pour que les paquets, dépassant la mémoire tampon, évitent de passer les contrôles de sécurité qui existaient à d’autres endroits : bien que le code du noyau central soit défectueux et n’ait pas effectué correctement la vérification finale des erreurs, plusieurs vérifications partielles de signes précurseurs ont rendu l’attaque beaucoup plus difficile. En effet, comme le souligne Beer, il est tentant, dans le code de bas niveau, et surtout s’il est critique pour les performances, de supposer que les données non fiables auront déjà été nettoyées, et donc de négliger le code de vérification des erreurs au moment justement où cette opération compte le plus. Donc ne le faites pas, surtout si ce code critique se trouve dans le noyau !
• Apprendre à transformer le dépassement de tampon en une corruption de tas (heap) contrôlable : cette possibilité a fourni une méthode prévisible et exploitable pour utiliser les paquets AWDL afin de forcer les lectures et les écritures non autorisées au niveau de la mémoire du noyau.
• Essayer un total de 13 adaptateurs Wi-Fi différents pour trouver un moyen de lancer l’attaque : Beer voulait pouvoir envoyer des paquets AWDL malveillants sur les canaux Wi-Fi 5 GHz largement utilisés aujourd’hui, il a donc dû trouver un adaptateur réseau qu’il pouvait reconfigurer pour répondre à ses besoins.

À ce stade, Beer avait déjà atteint un résultat en matière de preuve de concept alors que la plupart d’entre nous se seraient arrêtés là, victorieux !

Avec les pouvoirs de lecture-écriture au niveau du noyau, il pouvait forcer à distance l’application Calc à apparaître sur votre téléphone, à condition que la mise en réseau AWDL soit activée, par exemple lors de l’utilisation de l’icône “Partager” dans l’application Photos pour envoyer vos propres fichiers via AirDrop.

Néanmoins, il était déterminé à convertir cette tentative en une soi-disant attaque zero-click, dans laquelle la victime n’aurait pas à faire quoi que ce soit de particulier à part “utiliser son téléphone” à ce moment bien précis.

Comme vous pouvez l’imaginer, une attaque zero-click est beaucoup plus dangereuse, car même un utilisateur bien informé ne verrait pas à l’avance de signes révélateurs de problèmes imminents.

Ainsi Beer a également découvert des techniques permettant de :

• Prétendre être un appareil à proximité offrant des fichiers à partager via AirDrop : si votre téléphone pense qu’un appareil à proximité pourrait être l’un de vos contacts, en fonction des données Bluetooth qu’il transmet, il déclenchera temporairement AWDL pour voir de qui il s’agit. S’il ne s’agit pas de l’un de vos contacts, vous ne verrez aucune fenêtre contextuelle ou autre avertissement, mais le bug AWDL exploitable sera brièvement exposé via le sous-système AWDL activé automatiquement.
• Étendre l’attaque pour aller plus loin que la simple ouverture d’une application existante telle que Calc : Beer a compris comment utiliser son exploit initial dans une chaîne d’attaque détaillée qui pourrait accéder à des fichiers arbitraires sur l’appareil et les voler.

Dans la vidéo ci-dessus, l’attaque a pris le contrôle d’une application qui était déjà en cours d’exécution (l’ours en peluche regardait YouTube, si vous vous souvenez bien); à savoir “désandboxer” l’application depuis l’intérieur du noyau pour qu’elle ne se limite plus à afficher ses propres données; utiliser l’application pour accéder au répertoire DCIM (appareil photo) appartenant à l’application Photos; voler le dernier fichier image; puis l’exfiltrer en utilisant une connexion TCP à l’allure inoffensive.

Cette attaque est tout simplement sensationnelle !

Quoi faire ?

Astuce #1 : assurez-vous que vous êtes à jour avec les correctifs de sécurité, car le bug au cœur de la chaîne d’attaque de Beer a été trouvé et divulgué par ce dernier en premier lieu, il a donc déjà été corrigé. Accédez à Réglages> Général> Mise à jour logicielle.

Astuce #2 : désactivez le Bluetooth lorsque vous n’en avez pas besoin. L’attaque de Beer est un bon rappel que “moins c’est plus”, car il avait besoin du Bluetooth pour en faire une véritable attaque zero-click.

Astuce #3 : ne partez jamais du principe que, parce qu’un bug semble “difficile”, il ne sera jamais exploité. Beer admet que celui-ci était difficile, voire très difficile, à exploiter, mais au final pas impossible non plus.

Astuce #4 : si vous êtes un programmeur, soyez rigoureux avec les données. Ce n’est jamais une mauvaise idée de faire une bonne vérification des erreurs.

Pour tous les codeurs : attendez-vous au meilleur, c’est-à-dire espérez que tous ceux qui utiliseront votre code auront déjà vérifié les erreurs au moins une fois; mais préparez-vous au pire, à savoir partez du principe qu’ils ne le feront pas.

Billet inspiré de How to steal photos off someone’s iPhone from across the street, sur Sophos nakedsecurity.