iOS 14 fait face aux attaques d’iMessage avec BlastDoor

Dans un effort pour empêcher le lancement d’attaques via iMessage, Apple a lancé un service de sécurité appelé BlastDoor dans iOS 14, sa dernière version du système d’exploitation mobile.

D’abord détaillé dans une analyse réalisée cette semaine par Samuel Groß de Google Project Zero, BlastDoor agit comme un service « étroitement sandbox » qui est responsable de « presque toute » l’analyse des données non fiables dans iMessage.

Ce service survient après la découverte d’un exploit sans clic d’iMessage récemment découvert, qui a été exploité dans une attaque d’espionnage contre des journalistes et des cadres d’Al Jazeera. Citizen Lab, qui a dévoilé la campagne en Décembre, a déclaré à l’époque qu’il ne croyait pas que l’exploit fonctionne contre iOS 14, car il «inclut de nouvelles protections de sécurité».

Cependant, ces protections spécifiques étaient restées inconnues jusqu’à l’analyse de Groß cette semaine. Groß a pu effectuer du reverse-engineering afin d’analyser le nouveau service, en utilisant un M1 Mac Mini sous macOS 11.1, et en vérifiant ses résultats en les appliquant à iOS 14.3 (fonctionnant sur un iPhone XS),

«Dans l’ensemble, ces changements sont probablement très proches des meilleurs qui auraient pu être réalisés compte tenu du besoin de compatibilité ascendante, et ils devraient avoir un impact significatif sur la sécurité d’iMessage et de la plate-forme dans son ensemble», a déclaré Groß. «C’est formidable de voir Apple mettre de côté les ressources nécessaires à ce type de refactorisations importantes afin d’améliorer la sécurité des utilisateurs finaux.

Qu’est-ce que BlastDoor?

BlastDoor a deux implications importantes pour la sécurité.

Tout d’abord, le service permet d’appliquer des règles de sandbox à travers le pipeline lorsqu’un message est reçu sur un téléphone. Cela signifie que lorsqu’un message est reçu, les processus du backend exécutent le code séparément du système d’exploitation. Seuls deux processus (IMTransferAgent, qui gère les transferts de fichiers de messages, et apsd, le daemon du service de notification push d’Apple) sont nécessaires pour effectuer les opérations réseau.

Groß a déclaré que le profil sandbox de BlashDoor est «assez serré», car il bloque toutes les interactions du système de fichiers, l’accès au réseau sortant étant refusé et toute interaction avec les pilotes IOKit interdite. IOKit permet l’accès aux périphériques matériels et aux pilotes pour diverses applications et services, et est historiquement une grande source de vulnérabilités.

Cet environnement sécurisé signifie que tout code malveillant envoyé par des attaquants via iMessage est empêché d’accéder aux données utilisateur ou d’interagir avec d’autres parties du système d’exploitation.

Deuxièmement, BlastDoor est écrit en Swift, qui est un langage sans mémoire. Groß a déclaré que Swift rend «significativement» plus difficile l’introduction de vulnérabilités de corruption de mémoire dans le code. En effet, Swift dispose de diverses fonctionnalités pour s’assurer que les variables sont initialisées avant d’être utilisées, que la mémoire n’est pas accessible après avoir été libérée et que les indices de tableau sont vérifiés pour les erreurs hors-limites.

Un nouveau processus d’analyse de message

Dans les versions précédentes d’iOS, lorsqu’un message était envoyé, l’analyse se produisait dans Instant Messaging Agent (imagent). Pour analyser un message dans imagent, les données binaires seraient d’abord décompressées; puis le plist (également connu sous le nom de liste de propriétés; une extension utilisée pour enregistrer les préférences des applications) serait décodé à partir de son format de sérialisation binaire. Les différents champs seraient extraits pour s’assurer qu’ils ont le bon type; et enfin, le contenu du champ «x» du format iMessage serait décodé à l’aide d’un décodeur XML. Si un iMessage contenait une pièce jointe, des étapes supplémentaires seraient également prises pour l’analyse.

Dans iOS 14, ce processus a été déplacé vers le nouveau service BlastDoor. Le flux de traitement principal commence toujours dans imagent – qui reçoit les octets de charge utile bruts, mais les messages sont ensuite transmis au service BlastDoor (via +[IMBlastdoor sendDictionary:withCompletionBlock:]). À l’intérieur de BlastDoor, les processus d’analyse des messages et des pièces jointes se produisent principalement dans BlastDoor.framework et MessagesBlastDoorService, a déclaré Groß.

apple imessage iOS 14

Groß a noté que l’un des effets secondaires de ce nouveau pipeline de traitement est que imagent peut désormais détecter quand un message entrant a provoqué un plantage dans BlastDoor – et semble informer les serveurs d’Apple de tels événements.

« On ne sait pas à quoi cela sert sans avoir accès au code du serveur », a déclaré Groß. «Bien que ces notifications puissent simplement être utilisées à des fins statistiques, elles donneraient également à Apple un signal assez clair sur les attaques contre iMessage impliquant la force brute et un signal un peu plus faible sur tout exploit qui a échoué face au service BlastDoor.»

Les autres protections d’iOS 14

En plus de BlastDoor, Groß a mis en lumière deux autres protections de sécurité importantes intégrées à iOS 14, qui a été rendue publique en septembre.

Tout d’abord, Apple a résolu un problème avec la région de cache partagé de sa randomisation de disposition d’espace d’adressage (ASLR) qui posait une faiblesse architecturale. La faiblesse provenait du fait que la région des caches partagés ne se randomisait qu’au démarrage, ce qui signifie qu’elle resterait à la même adresse dans tous les processus. Cela aurait pu permettre aux attaquants de déduire l’adresse de base du cache partagé et d’interrompre l’ASLR – en les configurant potentiellement pour lancer des attaques sans clic.

BlastDoor imagent

Apple a maintenant ajouté une logique pour détecter spécifiquement ce type d’attaque. Désormais, le cache partagé est re-randomisé pour le service ciblé lors du prochain démarrage, ce qui rend ce type d’attaque inefficace.

«Cela devrait rendre le contournement de l’ASLR dans un contexte d’attaque à 0 clic beaucoup plus difficile, voire impossible (en dehors de la force brute) selon la vulnérabilité concrète», a déclaré Groß.

Deuxièmement, les services BlastDoor et imagent sont désormais soumis à un nouveau «mécanisme de limitation exponentielle» appliqué par launchd, le daemon de gestion des services du système d’exploitation d’Apple. Avec ce nouveau mécanisme, si un crash se produit sur l’appareil, les intervalles entre les redémarrages après le crash doublent avec chaque crash ultérieur (conduisant à un intervalle maximal de 20 minutes, a constaté Groß).

«Avec ce changement, un exploit qui reposait sur des plantages répétés du service attaqué nécessiterait probablement de l’ordre de plusieurs heures à environ une demi-journée au lieu de quelques minutes», a déclaré Groß.

Les problèmes de sécurité d’Apple

Apple, historiquement connu pour sa forte posture de sécurité, a été confronté à divers problèmes au cours des derniers mois, notamment la publication d’une mise à jour d’urgence cette semaine pour corriger 3 vulnérabilités zero-day découvertes dans iOS.

Les attaques sans clic s’exécutent automatiquement sans aucune interaction de l’utilisateur et sont particulièrement préoccupantes. En Août, des chercheurs ont découvert une chaîne d’exploit macOS sans clic qui pourrait permettre aux attaquants de fournir des logiciels malveillants aux utilisateurs de macOS à l’aide d’un document Microsoft Office avec des macros.

Groß a applaudi le travail de sécurité d’Apple reflété dans les changements récents, en particulier pour son impact contre les attaques sans clic basées sur des messages.

«Non seulement des failles simples ont été corrigées, mais des améliorations structurelles ont été apportées à la place en se basant sur des connaissances acquises grâce au travail de développement d’exploit», a-t-il déclaré.

Si cet article vous a plu, n’oubliez pas de jeter un coup d’œil à nos bons plans.

Laisser un commentaire