Nous faisons glisser tout ce qui est mauvais des iPhones via un Apple Find My qui fuit

Suite à la récente sortie de la technologie AirTags d'Apple, je me suis demandé si le système de recherche hors ligne "Find My" pouvait être utilisé de manière abusive pour télécharger des données arbitraires sur Internet à partir d'appareils non connectés au WiFi ou à l'Internet mobile. Ces données pourraient être diffusées via Bluetooth Low Energy et récupérées par les appareils Apple à proximité. Ces appareils, dès qu'ils se connectent à Internet, transmettraient immédiatement ces données aux serveurs Apple, d'où elles pourront être récupérées ultérieurement. Une telle technique pourrait être utilisée par de petits capteurs dans des environnements non contrôlés, afin de ne pas gaspiller d'énergie supplémentaire en utilisant l'Internet mobile. De plus, cela pourrait être intéressant pour voler des données depuis des endroits protégés par une cage de Faraday, si une personne avec un iPhone vient de regarder là-bas. 



Théoriquement, cela devrait être possible : si vous parvenez à émuler deux AirTags, alors vous pouvez encoder les données en n'activant qu'un seul d'entre eux à un moment donné. Dans ce cas, l'appareil récepteur doit vérifier quel AirTag était actif à quel moment et décoder les données dans leur forme d'origine. Cependant, un tel schéma semble être extrêmement peu fiable et, peut-être, inadapté à une utilisation dans des situations pratiques réelles en raison de la bande passante de transmission de données très étroite (en particulier compte tenu de la limitation de 16 AirTag sur Apple ID  , il semblait que la quantité de données transféré ne pouvait pas dépasser quelques bits par heure).



Par conséquent, la faisabilité de cette idée dépend de la façon dont le système est conçu et mis en œuvre. Il s'avère que les décisions prises pour assurer la sécurité et la confidentialité lors de la conception du mécanisme hors ligne montrent que le cas que nous avons proposé est très efficace comme méthode de pénétration et qu'il est presque impossible de s'en défendre.





Résultat : extraire les données précédemment transférées/téléchargées à l'aide d'une application Mac dédiée

• Vous pouvez télécharger des données arbitraires à partir d'  appareils non connectés à Internet en diffusant des messages Find My via la technologie BLE (Bluetooth Low Energy)  vers les appareils Apple à proximité, qui téléchargent ensuite les données pour vous
•  ESP32, ( )  macOS, , : https://github.com/positive-security/send-my
• ,   - Find My,  ,  

Localiser mon modem (ESP32) // Localiser mon modem (ESP32)



Appareils Apple à proximité //



Tour mobile Apple ou point d'accès Wifi à proximité // Tour cellulaire ou point d'accès Wifi



Appareil macOS avec application de récupération de données // Appareil macOS avec application pour récupérer des données



Flux de données // flux de données



.

Description du réseau de recherche hors ligne

Heureusement, ce protocole a déjà été largement inversé par un groupe de chercheurs de l'Université de technologie de Darmstadt, qui a publié l'article « Who Can  Find My  Devices ? «En mars 2021 et pour la preuve de concept, a publié l'implémentation open source d'  OpenHaystack . Avec cette implémentation, vous pouvez créer vos propres composants qui sont suivis sur le réseau Apple Find My. Un grand merci à cette équipe ! C'est grâce à leur travail que le nôtre a pu avoir lieu, et notre firmware (également fait pour la preuve de concept) et l'application Mac sont basés sur OpenHaystack.



Sous une forme légèrement simplifiée, le principe du système de recherche hors ligne Find My est le suivant :

1. AirTag Apple, , , AirTag ( )
2. 2 AirTag Bluetooth, , ( 15 )
3. , , .., Find My, , (  ECIES)  
4. Lors de la recherche d'appareils, l'appareil du propriétaire couplé génère une liste de clés publiques remplaçables qu'AirTag a dû utiliser ces derniers jours et demande à Apple ses hachages SHA256. Le backend Apple renvoie des rapports de localisation chiffrés pour les clés dont les ID ont été demandés. 
5. L'appareil du propriétaire décode les rapports d'emplacement et affiche l'emplacement approximatif. 

Serveurs Apple // Serveurs Apple



Appareils de recherche // Appareils de recherche Appareil 



propriétaire // Appareil propriétaire Appareil



perdu // Appareil perdu

1. // Couplage lors de la configuration initiale
2. // Diffuser. Présentation de la clé publique Bluetooth
3. // Télécharger les rapports de localisation cryptés
4. // Télécharger et décrypter les rapports de localisation

Figure. 1. Organigramme simplifié des tâches résolues lors de la recherche d'appareils hors ligne 



Ce très beau design présente des propriétés de sécurité caractéristiques, notamment :

• Protection de suivi contre les attaquants à proximité avec des clés publiques amovibles 
• Impossibilité de déterminer l'emplacement des utilisateurs Apple 

Cependant, pour nous dans ce cas, le plus intéressant est celui-ci : Apple ne sait pas quelles clés publiques appartiennent à votre AirTag, et, par conséquent, quels rapports de localisation vous sont adressés. Ainsi, un point de terminaison demandant des rapports de localisation pour un identifiant de clé spécifique n'effectue aucune autorisation (mais vous devez vous authentifier avec votre identifiant Apple pour accéder au point de terminaison). 



Toute la sécurité est assurée au niveau du chiffrement des rapports de localisation : la localisation ne peut être déchiffrée qu'avec la bonne clé privée, et elle n'est stockée que sur l'Appareil du Propriétaire appairé, et il est impossible de la récupérer avec une simple force brute attaque.

Concevoir un protocole de vol de données 

Cela suggère que le seul moyen que nous pouvons utiliser pour crypter les données est la clé publique EC diffusée (par exemple, nous ne pouvons pas influencer les coordonnées GPS, puisque le dispositif de « recherche » les ajoute).



Dans la section suivante, nous considérerons le backend Apple comme un magasin partagé de valeurs de clé publique, où le hachage SHA256 est utilisé comme clé et le rapport de localisation crypté est utilisé comme valeur. De plus, les opérations principales sont les suivantes :

• Vous pouvez vérifier si des rapports de localisation existent pour un hachage spécifique si SHA256 
• Vous pouvez ajouter des rapports de localisation à un hachage SHA256 spécifique en diffusant la clé publique correspondante 

Je pense que vous comprenez déjà le cours des événements : vous pouvez définir des bits arbitraires dans la clé partagée et le magasin de valeurs et les interroger à nouveau. Si l'expéditeur et le destinataire s'entendent sur un tel schéma de cryptage, des données arbitraires peuvent être transmises en l'utilisant.



J'ai décidé de construire un modem qui accepte un message via une interface série, puis parcourt ces données jusqu'à ce qu'un nouveau message soit reçu. Pour nous assurer que nous pouvons distinguer un bit "0" d'un bit non défini, nous diffuserons différentes clés publiques en fonction de la valeur du bit et demanderons au récepteur les deux clés publiques possibles.



Il n'y a aucune garantie quant au moment (ou le cas échéant) des messages de diffusion spécifiques seront téléchargés sur le backend Apple en tant que rapports de localisation. Le fait est que certains paquets peuvent n'atteindre aucun appareil Apple et que les appareils de recherche peuvent avoir des délais très variables entre la réception d'un message diffusé et le téléchargement d'un rapport de localisation, ce qui peut dépendre de la connectivité en amont ou du mode d'alimentation. Ainsi, notre encodage de données ne doit pas dépendre des rapports de position qui arrivent et dans quel ordre, et permet également la récupération des flux de données partiellement reçus - ceux dans lesquels certains bits sont complètement perdus. Pour y parvenir, j'ai décidé de crypter un bit de données par diffusion, avec une valeur d'index indiquant,quel bit de message est défini. Grâce au message supplémentaire et à l'ID de modem, le système est adapté à une utilisation multiple par plusieurs utilisateurs, gérant plusieurs messages.



Ainsi, en envoyant un bit spécifique, nous créons un tableau de 28 octets comme "[4b bit index] [4b message ID] [4b modem ID] [zeros padding ...] [bit value]", l'exploitons en tant que public clé et envoyer des représentations BLE, par exemple, pour diffuser des informations "le bit 0 du message 0 vaut 1".



Pour envoyer un message complet, le programme itère simplement sur tous ses bits et envoie la représentation à un bit avec une clé publique, dans laquelle l'index et la valeur de ce bit sont cryptés.







Message à encoder // Message à encoder



Clé publique générée à diffuser // Clé publique générée pour la diffusion



Indice de bit // Indice de



bit Valeur de bit // Valeur de bit



 



Encoder les bits du message dans la charge utile de diffusion



Lors de la récupération des données, l'application réceptrice générera les mêmes 28 tableaux d'octets (deux par bit, où les valeurs binaires possibles sont 0 et 1) et demandez un service Apple avec les hachages SHA256 de ces "clés publiques". Une seule de ces clés doit avoir des rapports de localisation attachés, qui peuvent ensuite être interprétés (par exemple, le bit avec l'index 0 est 1).







Bits potentiels à interroger // Bits pouvant potentiellement être interrogés



Clés publiques potentielles à tester // Clés publiques pouvant potentiellement être testées



Interroger le backend Apple // Interroger l'



existence de la clé publique du backend Apple Décoder les données d'origine // Décrypter la clé publique en obtenir des données brutes





Récupère les données précédemment envoyées à partir d'un appareil macOS connecté à Internet



Remarque : vous pouvez envoyer non seulement un bit par message, mais, par exemple, envoyer un octet entier, qui contiendra les 8 derniers bits de la clé publique. Bien que cela nécessite une bande passante de transmission de données plus large, le récepteur devra désormais demander 255 identifiants de clé différents pour sélectionner / forcer brutalement un octet (comparer avec 16 identifiants de clé lors de l'encodage au niveau du bit).

Mise en œuvre

Côté expéditeur

Du côté de l'expéditeur, j'ai décidé d'utiliser ESP32 - un microcontrôleur tout à fait ordinaire et bon marché (et un test rapide a montré qu'il peut changer l'adresse MAC BT beaucoup plus rapidement que, disons, un Raspberry Pi basé sur Linux). Au démarrage, le firmware basé sur OpenHaystack diffuse un message par défaut codé en dur puis écoute l'interface série (en boucle) pour voir si de nouvelles données de diffusion arrivent - et ainsi de suite jusqu'à ce qu'un nouveau message soit reçu... Lors de la diffusion d'une clé publique, elle doit être fractionnée et encodée dans les 6 premiers octets de l'adresse MAC Bluetooth (tous sauf les deux premiers bits, car la norme Bluetooth exige que les deux premiers bits soient mis à 1). Nous vous référons à Voir la section 6.2 de l'article de l'Université de technologie de Darmstadt , où cet encodage fait maison est décrit plus en détail.



J'ai ajouté un préfixe statique à ma charge utile afin de ne pas rencontrer de problèmes avec la spécification BT, et j'ai également inclus un index de bits incrémentiel dans les 6 premiers octets de la clé publique, ce qui fait que chaque bit transmis a son propre MAC BT adresse, juste au cas où il y a une limitation de débit basée sur l'adresse MAC n'importe où dans la pile.





Sortie modem ESP32 dans la console série a

Côté extraction de données

L'application Mac est également basée sur OpenHaystack et utilise la même astuce avec le plugin AppleMail pour envoyer des demandes de récupération de localisation correctement authentifiées au backend Apple. L'utilisateur est invité à saisir un identifiant de modem à 4 octets (peut être défini pendant le firmware ESP), après quoi l'application sélectionnera, décodera et affichera automatiquement un message avec l'identifiant 0. Ensuite, l'utilisateur peut sélectionner d'autres messages ou changer de modem .



Le message est récupéré 16 octets (128 bits) à la fois (256 identifiants de clé sont demandés) jusqu'à ce qu'il n'y ait plus de rapports (pour un octet entier).

Complication mineure : expiration de la clé publique

 

Après avoir implémenté à la fois l'expéditeur et le destinataire, j'ai effectué le premier test en diffusant et en essayant d'obtenir une valeur de 32 bits. Après quelques minutes, j'ai pu obtenir 23 bits sur 32, chacun est définitivement correct et avec environ 100 rapports de localisation, mais je n'ai obtenu aucun rapport de ce type pour les 9 bits restants.



Suspecté que certaines des clés publiques générées ont été rejetées par les appareils Apple à proximité pendant la phase de cryptage ECIES en tant que clés publiques invalides - et cela a été rapidement confirmé en essayant de charger chacune des charges utiles générées en tant que clés publiques codées SEC-1 sur une courbe P224 en utilisant Package Python fastecdsa : pour chaque bit pour lequel je n'avais pas de rapports de localisation, le microcontrôleur a diffusé la clé publique, lançant une exception InvalidSEC1PublicKey lors de l'importation de la clé fastecdsa.



Un petit contexte du cryptage utilisé ici :

• Le public EC de 28 octets représente la coordonnée X d'un point particulier, codé avec SEC1. 
• La clé publique SEC1 a généralement aussi un bit "signe" qui détermine laquelle des deux coordonnées Y possibles pour une coordonnée X donnée doit être codée. Ce bit n'est pas transmis lors de la diffusion et n'est pas important pour la date d'expiration de la clé publique. 
• Lors du décodage de la clé publique compressée, la coordonnée Y correspondante est calculée à l'aide des paramètres de courbe fixes et vérifiée si la clé est valide. Certaines des clés publiques générées échouent à ce test. Pour plus de détails voir la section 3.2.2 dans l'article " Validation des clés publiques sur les courbes elliptiques " :

Ce problème de clés publiques invalides peut être résolu d'au moins deux manières :

1. , , , . , , . , , , id  
2. ( ). 28- X , 28- , , , , ( )

L'avantage de la deuxième option est que pour chaque bit reçu, on pourrait également déchiffrer les rapports de localisation pour déterminer à quel moment un bit donné a été reçu, mais cela nécessite un peu plus de traitement informatique. Lors de l'implémentation de cette option, j'ai découvert qu'en raison de  bugs dans l'implémentation de la multiplication de courbes elliptiques  dans la bibliothèque uECC utilisée pour cela, pour certaines clés privées, ESP calculait des clés publiques différentes de BoringSSL sur Mac et fastecdsa sur Python (un flou différentiel s'est glissé accidentellement ? ). Ces clés publiques ont même été considérées comme invalides par la fonction uECC_valid_public_key () d'uECC. Par conséquent, dans ce projet pilote, j'ai opté pour l'option 1.







Message à encoder // Message encodé



Générer une clé publique à encoder // Générer une clé publique pour encoder



l'adresse MAC BT // Adresse MAC BT



Tester la validité, sinon incrémenter le compteur // Vérifier si la clé est valide, sinon augmenter le compteur de one



Advertisement payload // Payload pour la présentation



Encodage et envoi du message

Tests / Performances

Lorsque nous avons mis en place un contrôle de validation de clé publique, tout fonctionne parfaitement. Je n'ai pas effectué de tests de performances approfondis ni effectué de mesures, mais voici quelques estimations :

•     ~3 . ,  
•     - Mac.  16    ~5
•     1 60 , , , . . , , , , ( , Apple)

CDF // Fonction de distribution cumulée



Médiane… min // Médiane… 26,3 min.



Délai de publication (min) // Délai avant publication (min.)



Fig. 8. Retards dans la réception de tous les rapports, considérés au § 7.1 comme une fonction de distribution cumulative





Retards dans la réception des rapports, mesurés par une équipe de l'Université de technologie de Darmstadt, sur la base des documents « Qui peut trouver mes appareils ? »

Utilisations potentielles

Bien que je m'intéressais principalement à vérifier la faisabilité de ce que j'ai décrit, je pense que l'application pratique potentiellement la plus courante consiste à télécharger des lectures de capteurs ou des données à  partir d'appareils IoT sans modem haut débit, carte SIM, plan de données ou connectivité Wifi. Étant donné qu'Amazon  utilise un réseau similaire appelé Sidewalk utilisant des appareils Echo,  il pourrait bien y avoir une demande pour de telles technologies. Étant donné que le cache des chercheurs accumule les diffusions reçues et y reste jusqu'à ce qu'une connexion Internet soit établie, les capteurs peuvent envoyer des données même à partir de zones sans couverture de réseau mobile, si des personnes munies d'appareils marchent dans de tels endroits.



Dans un monde  de réseaux de haute sécurité , où la technologie combinant lasers et scanners semble être une astuce prometteuse  pour combler les vides, les appareils Apple fournis par les visiteurs peuvent également servir d'intermédiaire viable pour  voler les données des  systèmes à vide.ou des chambres protégées par une cage de Faraday. 



Il apparaît également que le protocole de découverte hors ligne pourrait être utilisé pour drainer le trafic sur les iPhones à proximité connectés à des tarifs illimités . En limitant le nombre de rapports de localisation pouvant être envoyés à partir d'un seul demandeur (255 rapports/soumissions car le nombre d'octets est égal à 1), et avec chaque rapport dépassant 100 octets, la diffusion de nombreuses clés publiques uniques peut entraîner une augmentation significative du trafic sortant. depuis le smartphone. Bien que je n'aie remarqué aucune limitation de fréquence pour les rapports de localisation sortants, je n'ai pas non plus testé la quantité de données pouvant être consommée.

Comment régler le problème

Comme je l'ai mentionné au tout début, il sera difficile pour Apple de se défendre contre ce genre d'abus s'il choisit de le faire.



Apple a conçu le système en pensant à l'économie des données. Ils ne peuvent pas lire les emplacements non cryptés et ne savent pas quelles clés publiques appartiennent à votre AirTag, ni même à quelle clé publique un rapport d'emplacement crypté particulier est associé (car ils ne reçoivent que le hachage SHA256 de la clé publique).



Dans cette optique, la limite indiquée de 16 AirTags pour Apple ID est intéressante, car il me semble qu'Apple n'est actuellement pas en mesure de l'obliger à l'utiliser. 



Cependant, un durcissement supplémentaire de ce système est possible, par exemple, dans les deux domaines suivants :

• BLE.  , , AirTag OpenHaystack, AirTag . , , , BLE , , AirTag , , .
•   Apple , id id AirTag, id , 15 16 id Apple ID ( id ). , , : Apple ID .

Dans cet article, nous avons répondu à la question de savoir s'il est possible de télécharger des données arbitraires à l'aide d'appareils Apple appartenant à d'autres utilisateurs : définitivement oui.



Le firmware du modem ESP32 et une application d'extraction de données pour macOS ont été implémentés, ils sont postés sur Github , vous pouvez les expérimenter.



Notez que cette implémentation n'est qu'une "preuve de faisabilité", et le "protocole" lui-même n'est ni crypté ni authentifié. Par exemple, vous pouvez examiner les détails d'un modem avec l'ID 0x42424242 en entrant simplement son ID (peut-être qu'en attendant quelqu'un peut également démontrer qu'il n'y a pas d'authentification dans ce protocole).



Une dernière remarque : lors de la préparation de cet article, j'ai remarqué que l'"octet d'état" inclus dans la vue BLE est évidemment utilisé, par exemple, comme indicateur de niveau de batterie. Combiné avec les clés privées générées de manière déterministe qui sont tournées, cela ouvre probablement un autre trou de fuite de données (octet par vue), mais je n'ai pas testé cette approche.

---

Les serveurs cloud de Macleod sont rapides et sécurisés.



Enregistrez-vous en utilisant le lien ci-dessus ou en cliquant sur la bannière et obtenez un rabais de 10 % pour le premier mois de location d'un serveur de n'importe quelle configuration !