Les données utilisateur ne sont pas une monnaie d'échange. Apple a déployé des efforts importants pour bâtir sa réputation en combattant fermement le FBI et les autres responsables de l'application des lois à la recherche d'opportunités de collecte de données arbitraires sur les propriétaires d'iPhone.
En 2016, Apple a refusé d'affaiblir les défenses iOS afin que le FBI puisse déverrouiller l'iPhone du tireur de San Bernardino. Après avoir saisi le smartphone de Syed Farouk et raté dix fois un code PIN à quatre chiffres, les forces de l'ordre ont bloqué le smartphone. Ensuite, le FBI a demandé à Apple de créer un système d'exploitation spécial dans lequel il est possible de forcer brutalement le code de sécurité ...
Au début, les choses n'allaient pas en faveur d'Apple, le tribunal de district des États-Unis pour la Californie a pris le parti des forces de l'ordre. Apple a interjeté appel, les formalités administratives ont commencé et, à la suite de la réunion, le procès s'est terminé sur cette initiative à l'initiative du FBI.
En fin de compte, le gouvernement fédéral a obtenu son chemin avec Cellebrite, une société privée israélienne de criminalistique numérique, pour plus d'un million de dollars américains . Au fait, rien n'a été trouvé dans le smartphone.
D'une manière étrange, quatre ans plus tard, l'histoire s'est répétée presque exactement. En janvier 2020, pas n'importe qui, mais le procureur général américain William Barr a demandé à la société d'aider les enquêteurs à accéder au contenu de deux iPhones utilisés lors d'une fusillade sur une base aérienne navale de Pensacola, en Floride, en décembre 2019. Sans surprise, Apple a obtenu un autre rejet.
Il convient de souligner que dans les deux cas, il ne s'agissait pas d'un transfert ponctuel d'informations d'Apple. C'est très bien, la société transfère des métadonnées, des sauvegardes d'iCloud avec des demandes officielles et autorisées des forces de l'ordre. Le refus se heurte à des demandes de création et de fourniture d'une clé principale universelle, un firmware iOS spécial qui permet de déverrouiller les smartphones confisqués.
C'est cette circonstance qui provoque la plus grande opposition de la direction d'Apple et personnellement PDG Tim Cook, qui croient raisonnablement qu'il n'y a pas et ne peut pas être des portes dérobées bénignes, et qu'une protection complète de votre plate-forme mobile n'est que la première fraîcheur. Un lockpick entre de bonnes mains devient très vite un lockpick entre les mains de douteux, et il sera peut-être là dès le premier jour.
Ainsi, nous savons maintenant qu'iOS n'a pas de failles spéciales créées pour les forces de l'ordre. Cela signifie-t-il que l'iPhone est immunisé contre la pénétration et le vol de données?
Vérification de la vulnérabilité BootROMm8
Fin septembre 2019, un chercheur en sécurité de l'information surnommé axi0mX a publié le code d'exploit sur Github pour presque tous les appareils Apple dotés de puces A5-A11. La particularité de la vulnérabilité découverte est qu'elle se situe au niveau du matériel et ne peut être éliminée avec aucune mise à jour logicielle, car elle est cachée dans le mécanisme même de protection du démarrage sécurisé BootROM, aka SecureROM.
Le modèle de démarrage iOS de la présentation d'Apple WWDC 2016.
Lors du démarrage à froid, SecureROM est le premier à s'exécuter à partir de la mémoire en lecture seule, qui est le code le plus fiable du processeur d'application et s'exécute donc sans aucune vérification. C'est la raison pour laquelle les correctifs iOS sont impuissants ici. Il est également extrêmement important que SecureROM soit responsable de la transition de l'appareil vers le mode de récupération (mise à jour du micrologiciel de l'appareil) via l'interface USB en appuyant sur une combinaison de touches spéciale.
Basculer iOS en mode DFU.
La vulnérabilité Use-after-Free se produit lorsque vous référencez la mémoire une fois qu'elle a été libérée. Cela peut entraîner des conséquences désagréables telles que des pannes de programme, des valeurs imprévisibles ou, dans ce cas, l'exécution de code tiers.
Tout d'abord, pour comprendre le mécanisme d'exploitation, nous devons comprendre comment fonctionne le mode de récupération du système. Lorsqu'un smartphone entre en mode DFU, au moment de l'initialisation, un tampon d'E / S est alloué et une interface USB est créée pour traiter les demandes à DFU. Lorsque le package d'installation 0x21, 1 arrive via l'interface USB à l'étape de transfert de contrôle USB, le code DFU, après avoir déterminé l'adresse et la taille de bloc, copie les données du tampon d'E / S dans la zone de mémoire de démarrage.
Structure du paquet de configuration de transfert de contrôle USB.
La connexion USB reste active tant que l'image du micrologiciel est chargée, après quoi elle se termine normalement. Cependant, il existe également un scénario anormal de sortie du mode DFU.Pour cela, vous devez envoyer le signal d'abandon DFU selon le code bmRequestType = 0x21, bRequest = 4. Dans le même temps, le contexte global du pointeur vers le tampon de données et la taille du bloc sont préservés, créant ainsi une situation classique de vulnérabilité Use-after-Free.
Checkm8 exploite essentiellement une vulnérabilité Use-after-Free dans le processus DFU pour permettre l'exécution de code arbitraire. Ce processus comporte plusieurs étapes, mais l'une des plus importantes est connue sous le nom de tas feng shui , qui mélange le tas d'une manière spéciale pour faciliter l'exploitation de la vulnérabilité.
Exécutez la commande ./ipwndfu -p sur macOS.
En termes pratiques, tout se résume à mettre l'iPhone en mode DFU et à exécuter une simple commande ./ipwndfu -p. Le résultat de l'action du script Python est de déverrouiller tout le système de fichiers du smartphone avec un accès non autorisé. Cela permet d'installer des logiciels iOS à partir de sources tierces. Ainsi, les attaquants et les forces de l'ordre peuvent accéder à tous les contenus d'un smartphone volé ou saisi.
La bonne nouvelle est que pour jailbreaker et installer un logiciel tiers, un accès physique au téléphone Apple est nécessaire, et de plus, après le redémarrage, tout sera remis en place et l'iPhone sera en sécurité - c'est ce qu'on appelle. jailbreak captif. Si votre smartphone vous a été enlevé à la frontière puis rendu, il vaut mieux ne pas tenter à nouveau le destin et redémarrer.
iCloud et sauvegardes presque sécurisées
Il a déjà été dit plus haut que lors de la dernière confrontation entre le FBI et Apple à propos de la fusillade à Pensacola, la société a remis aux forces de l'ordre, des sauvegardes iCloud des téléphones des suspects. Le fait que le FBI n'ait pas levé le nez suggère que ces données, contrairement à l'iPhone verrouillé, étaient tout à fait appropriées pour la recherche.
Il serait naïf de croire qu'il s'agit d'un cas isolé. Rien qu'au premier semestre 2019, les enquêteurs ont eu accès à près de 6000 sauvegardes iCloud complètes d'utilisateurs de smartphones Apple 1568 fois . Dans 90% des demandes de l'Etat. structures, la société a fourni certaines données d'iCloud et il y a eu environ 18 000 demandes de ce type au cours de la même période.
Cela est devenu possible après qu'Apple ait discrètement abandonné un projet visant à fournir un chiffrement de bout en bout des sauvegardes iCloud aux utilisateurs il y a deux ans. Il est prouvé que cela a été fait suite à la pression du FBI. Cependant, il y a aussi des raisons de croire que le refus est motivé par le désir d'éviter une situation où les utilisateurs, en raison d'un mot de passe oublié, ne peuvent pas accéder à leurs propres données iCloud.
À la suite d'un compromis avec les forces de l'ordre et les utilisateurs, un gâchis s'est produit dans lequel il n'est pas évident de savoir quelles données d'iCloud sont masquées de manière fiable et lesquelles le sont. À tout le moins, on peut dire que le chiffrement de bout en bout s'applique aux catégories suivantes.
- Données personnelles.
- Données médicales.
- ICloud Keychain (y compris les comptes et les mots de passe enregistrés).
- Données de paiement.
- Clavier QuickType de vocabulaire accumulé (nécessite iOS v.11).
- Temps d'écran.
- Données Siri.
- Mots de passe Wi-Fi.
Tout autre élément, y compris les messages , peut être lu par les employés et les autorités Apple.
Nouvelle vulnérabilité au niveau matériel
Il y a une semaine, l'équipe de développement chinoise Pangu Team a signalé avoir trouvé un dysfonctionnement fatal, cette fois dans la puce SEP (Secure Enclave Processor). Tous les iPhones équipés de processeurs A7-A11 sont à risque.
SEP stocke les informations clés, littéralement. Il s'agit notamment des fonctionnalités cryptographiques, des clés d'authentification, de la biométrie et d'un profil Apple Pay. Il partage une partie de la RAM avec le processeur d'application, mais l'autre partie (connue sous le nom de TZ0) est cryptée.
Séquence de démarrage SEP.
SEP lui-même est un cœur de processeur AKF effaçable de 4 Mo (probablement Apple Kingfisher), brevet n ° 20130308838 . La technologie utilisée est similaire à ARM TrustZone / SecurCore, mais contrairement à elle contient du code propriétaire pour les cœurs Apple KF en général et SEP en particulier. Il est également responsable de la génération des clés UID sur les puces A9 et plus récentes, pour protéger statiquement les données des utilisateurs.
SEP a sa propre ROM de démarrage et est protégé en écriture, tout comme SecureROM / BootROM. Autrement dit, une vulnérabilité dans SEPROM aura les mêmes conséquences désagréables et irréparables. En combinant le trou SEPROM avec l'exploit checkm8 décrit ci-dessus, vous pouvez modifier le registre de mappage d'E / S pour contourner la protection d'isolation de mémoire. Concrètement, cela permet aux attaquants de verrouiller le téléphone sans pouvoir le déverrouiller.
Les hackers de Pangu ont démontré qu'ils pouvaient exploiter un bogue dans le contrôleur de mémoire qui contrôle le contenu du registre TZ0. Ils n'ont pas divulgué tous les détails et le code source, dans l'espoir de vendre leur trouvaille à Apple.
Le chercheur en sécurité de l'information axi0mX, déjà connu de nous, a écrit sur Twitter que la vulnérabilité de SEPROM ne peut être exploitée qu'avec un accès physique au smartphone, comme dans le cas de checkm8. Plus précisément, la possibilité même de manipuler le contenu du registre TZ0 dépend de la présence d'un trou dans le SecureROM / BootROM, car après un démarrage régulier de l'iPhone, la valeur du registre TZ0 ne peut pas être modifiée. Les modèles d'iPhone plus récents avec SoC A12 / A13 ne sont pas affectés par la nouvelle vulnérabilité.
Matériaux utilisés
- Le FBI voulait une porte dérobée à l'iPhone. Tim Cook a dit non
- Analyse technique de Checkm8 exploit
- ! checkm8
- Demystifying the Secure Enclave Processor
- Team Pangu demonstrates unpatchable Secure Enclave Processor (SEP) chip vulnerability in iOS
