Falsification du mode verrouillage : une technique de sabotage post-exploitation

Les chercheurs se sont demandés comment se déroule un scénario impliquant la compromission d'un appareil par un pirate qui aurait implanté le code de falsification du mode verrouillage. Si un utilisateur à haut risque (journaliste, responsable gouvernemental, dirigeant d’entreprise) lance le mode verrouillage, il déclenche le code du pirate qui active les témoins visuels du verrouillage, sans apporter aucune modification au fonctionnement de l'appareil.

Votre mode verrouillage a-t-il été altéré ?

Le mode verrouillage introduit par Apple dans iOS 16 est une fonctionnalité utile dans certaines situations. Mais si votre téléphone a déjà été compromis, il ne vous protégera pas. Cet article de blog approfondit nos recherches sur la falsification du mode verrouillage et démontre comment un pirate informatique qui a déjà infiltré votre appareil peut « contourner » le mode verrouillage au moment où vous l’activez.

L'introduction du mode verrouillage

Apple a introduit le mode verrouillage en septembre 2022 en réponse à la multiplication des campagnes de cyberattaques dans le monde entier. Comme on le voit ci-dessous, et comme le dit le Threat Analysis Group (TAG) de Google, c’est en 2021 et en 2022 que le plus grand nombre d'attaques « zero day » ont été détectées depuis que l'entreprise a commencé à suivre ces incidents dans le courant de 2014. Pegasus par exemple, sans doute le logiciel espion le plus célèbre, peut infecter le dernier iPhone sans aucune interaction de la part de l’utilisateur : c’est ce qu’on appelle une attaque sans clic. Malgré les efforts constants d'Apple pour améliorer son architecture de sécurité ces dernières années, les opérateurs de Pegasus se sont illustrés par leur talent à découvrir de nouvelles vulnérabilités et à exécuter des attaques sans clic. L’inquiétude suscitée par ces attaques a encouragé le développement du mode verrouillage, qui doit apporter une protection face à cette nouvelle tendance tout en rassurant les utilisateurs d'iPhone.

Le mode verrouillage minimise les fonctionnalités auxquelles un pirate pourrait accéder à distance. Cette approche est aussi simple que robuste : moins vous exposez de code, moins les attaquants peuvent en exploiter les éventuelles vulnérabilités. Apple décrit le mode de Isolement comme suit :

Le mode verrouillage est une protection extrême et facultative pensée pour les très rares individus qui, en raison de leur identité ou de leurs activités, pourraient être personnellement la cible de menaces numériques hautement sophistiquées. La plupart des gens ne seront jamais la cible d’attaques de cette nature.

Lorsque le mode verrouillage est activé, votre appareil ne fonctionne pas comme il le fait habituellement. Pour réduire la surface d'attaque potentiellement exploitable par des logiciels espions mercenaires, certaines applications, sites web et fonctionnalités sont strictement limités, et certaines expériences sont entièrement désactivées.

Le mode verrouillage est disponible à partir d’iOS 16, iPadOS 16, watchOS 10 et macOS Ventura. Des protections supplémentaires sont disponibles dans iOS 17, iPadOS 17, watchOS 10 et macOS Sonoma. Pour une protection complète, installez la version la plus récente du système d’exploitation sur vos appareils avant d'activer le mode de verrouillage.

Le mode verrouillage présente notamment un moteur de navigateur web restreint qui s’utilise avec des portails captifs. Un portail captif est une page web comparable à celle qui s'affiche lorsque vous vous connectez à un réseau Wi-Fi public ; il est souvent utilisée à des fins de publicité ou d'authentification. Le moteur web qui s'applique derrière un portail captif impose davantage de contraintes, et désactive en particulier la compilation JavaScript Just-In-Time (JIT) pour des raisons de sécurité. Cette restriction s'applique également au mode verrouillage. On a donc observé que le mode de verrouillage entraîne jusqu'à 95 % de réductions de performance et de réactivité du moteur JavaScript dans les applications web.

L'activation du mode verrouillage interrompt la prise en charge de certains formats de fichiers, principalement en raison des exploitations qui en ont été faites par le passé. Il désactive également certaines fonctionnalités pratiques, comme l’aperçu des liens dans Messages et les albums partagés. Il empêche également l'installation de profils de configuration et l'inscription dans une solution de gestion des appareils mobiles (MDM).

L'illustration ci-dessous, provenant de blacktop sur GitHub, dresse la liste des fonctionnalités désactivées par le mode verrouillage.

Faisons un bon jusqu’en 2023 : l’efficacité du mode verrouillage ne fait plus aucun doute. En septembre 2023, CitizenLab a identifié une chaîne d'exploitations sans clic appelée BLASTPASS, qui ciblait activement la version d'iOS 16 disponible à l'époque. CitizenLab et Apple ont affirmé que le mode verrouillage bloquait spécifiquement cette attaque. Les équipes n’ont pas divulgué plus de détails pour éviter une utilisation abusive, mais il est probable qu'il faille désormais un certain niveau d'interaction de l'utilisateur pour déclencher l'exploitation après l'activation du mode de verrouillage. L’attaque ne peut donc plus se faire « sans clic » et les utilisateurs ont l’opportunité de réagir.

Limites du mode verrouillage

Bien que le mode verrouillage ait prouvé son efficacité dans certains scénarios, notre évaluation rappelle qu’il ne peut pas arrêter une attaque déjà lancée sur l’appareil. Les utilisateurs d'iPhone doivent comprendre qu’une fois leur appareil infecté, le mode verrouillage n'arrêtera pas un cheval de Troie qui a déjà pénétré le système. L'objectif principal du mode verrouillage est de limiter les vecteurs d'attaque potentiels; il n’apporte aucune mesure de sécurité supplémentaire visant à empêcher l'exécution de code malveillant.

Dans la suite de l'article, nous allons voir comment le mode verrouillage d'un iPhone infecté peut être manipulé pour donner à l’utilisateur un faux sentiment de sécurité.

Activation

Comme indiqué ci-dessous, commençons par examiner le bouton du mode de verrouillage dans l'application Réglages. De nombreuses opérations se déroulent en coulisses, et l’utilisateur ne voit que le redémarrage. Nous avons recherché la chaîne « lockdownMode » dans le dyldcache et constaté qu'un framework appelé PrivacySettingsUI implémente deux fonctions C portant les noms suivants :

bool isLockdownModeEnabled()

void setLockdownModeEnabled(bool)

La fonction void setLockdownModeEnabled(bool) définit la valeur booléenne de la clé LDMGlobalEnabled sur « Yes » via l'API NSUserDefaults. En surveillant les événements de modification de fichier, nous avons trouvé le chemin suivant : /var/mobile/Library/Preferences/.GlobalPreferences.plist

C’est grâce à cette valeur unique que le système sait si le mode de verrouillage est actif ou non. On peut écraser manuellement la base de données par défaut de l'utilisateur afin de définir cette valeur sur « Yes », à l’aide d’une commande telle que :

[[NSUserDefaults standardUserDefaults] setObject: [NSNumber numberWithBool: 1] forKey:@"LDMGlobalEnabled" inDomain: @"NSGlobalDomain"]

Cette commande peut être exécutée dans tous les processus ou presque, en dehors du bac à sable. On peut observer des modifications dans les valeurs de retour de nombreuses fonctions, que vous retrouverez en exécutant « grep -i LockMode »" dans le dyldcache.

Quelques fonctions, telles que PUILockdownModeController, nécessitent l'initialisation d'une nouvelle instance car la lecture du fichier a lieu dans la méthode d'initialisation. Néanmoins, une fois ces processus redémarrés, tous renvoient des résultats positifs qui activent le mode de verrouillage sur l'ensemble de l'appareil, et tout cela sans redémarrage complet de l'appareil.

Cela confirme nos soupçons, à savoir qu’à l’heure d’iOS 16.5, le mode verrouillage fonctionne comme un artefact de l'espace utilisateur (le noyau n'est pas informé de cet état). Nous n'avons trouvé aucune implémentation de code liée au mode verrouillage dans le noyau d’iOS 16.5. Aucun redémarrage du système n'est nécessaire pour activer ou désactiver le mode verrouillage à ce stade.

Mais ce n’était que temporaire.. À l’écoute des informations révélées par « Anatomie du mode verrouillage » de blacktop, Apple a inscrit le mode verrouillage au niveau du noyau à partir d’iOS 17. Ce mode possède désormais son propre démon d'arrière-plan, situé dans /System/Library/PrivateFrameworks/LockdownMode.framework/lockdownmoded, ainsi qu’un KEXT appelé com.apple.driver.AppleLockdownMode. Cette décision stratégique représente une étape décisive pour l'amélioration de la sécurité. En effet, les modifications apportées par le mode verrouillage au noyau sont généralement impossibles à annuler sans redémarrer le système, grâce aux mesures d'atténuation de sécurité existantes.

Faux redémarrage

Pour revenir au sujet de la manipulation du mode de verrouillage, notre objectif dans l'application Réglages consiste à rendre le mode verrouillage inopérant et à remplacer le redémarrage du système par celui de l'espace utilisateur. Cette démonstration vise à montrer comment un logiciel malveillant pourraient tromper l'utilisateur. Sur un téléphone infecté, aucune protection n’empêche le malware de s'exécuter en arrière-plan, que l'utilisateur active ou non le mode de verrouillage.

Lorsqu'un utilisateur choisit d'activer le mode de verrouillage dans l'application Réglages, cela déclenche la méthode -[PUILockdownModeController setLockdownModeGloballyEnabled:]. Comme vous pouvez le voir, la séquence d'événements fournit un aperçu clair du fonctionnement du mode verrouillage. Il commence par désactiver les albums partagés et les aperçus de liens, désactive ensuite le mode développeur et termine en activant le mode USB restreint. L'installation de profil est désactivée elle aussi, la clé LDMGlobalEnabled est définie sur « YES » dans la base de données par défaut de l'utilisateur, et les modifications sont synchronisées. Dans la fonction _DaemonReady, CFNotificationCenterPostNotification() est invoquée pour informer les processus WebKit du changement de configuration. Enfin, l'appareil redémarre.

Étant donné que -[PUILockdownModeController setLockdownModeGloballyEnabled:] est une méthode objective-C, vous pouvez utiliser la technique de Method Hooking method_exchangeImplementations pour remplacer son contenu. Ce que nous avons fait est très simple : Chaque fois que l'utilisateur active le mode verrouillage, un fichier nommé /fakelockdownmode_on est créé à titre d’indicateur et le redémarrage de l'espace utilisateur est lancé. Nous avons également accroché d'autres fonctions, dont -[PUILockdownModeController LockModeEnabled], pour renvoyer des résultats basés sur l'existence de ce fichier.

Grâce à cela, l'appareil n'a pas vraiment redémarré et notre code injecté conserve un contrôle sur le mode verrouillage. Cela signifie également que des logiciels malveillants incapables de persistance peuvent tout de même s’exécuter et surveiller l’utilisateur durablement.

Falsification du mode verrouillage dans Safari

Pour mieux illustrer la manipulation du mode verrouillage, nous avons choisi Safari, l'une des applications les plus couramment utilisées. Lorsqu'un utilisateur visite un site web à l'aide de Safari, une étiquette bien visible lui indique « Verrouillage activé ». Cela signifie que la page web est affichée au sein de la version « portail captif » du moteur web. Si, pour une raison ou une autre, c’est le moteur web standard qui est utilisé, Safari affichera un message « Verrouillage désactivé » en rouge très visible. Ce scénario se produit lorsqu'un utilisateur navigue sur un site web de confiance, une configuration qui peut être ajustée dans les paramètres des sites web

Safari s'appuie entièrement sur une fonction, [WBSUIFeatureAvailability isLockdownModeEnabledForSafari], pour déterminer l'état du mode verrouillage. En accrochant cette fonction, nous pouvons faire en sorte qu’elle renvoie les résultats souhaités dans différents scénarios. Par exemple, elle renverra « Non » au moment de décider d'utiliser ou non le portail captif, et « Oui » lorsqu’il s'agira de déterminer l'apparence des éléments de surface, comme l'étiquette « Verrouillage » de l'interface utilisateur.

Désormais, Safari se comporte comme si tous les sites web étaient fiables. Nous devons toutefois prendre certaines mesures pour modifier l'étiquette « Verrouillage désactivé ». Pour ce faire, nous recherchons d'abord la chaîne « Lockdown Off » et localisons la fonction appelée WBSAnnotationStringForLockdownModeStatus. En surveillant sa trace, nous voyons qu'elle a été invoquée par -[SFLockdownStatusBar _updateLabelWithLockdownStatus:], une méthode objective-C qui est facile à accrocher. Nous allons donc modifier cette fonction pour afficher « Verrouillage activé » et non pas « Verrouillage désactivé » comme elle devrait le faire.

Vidéo de démonstration

Dans cette vidéo de démonstration, un utilisateur active le mode verrouillage dans les Réglages. L'appareil semble être en mode verrouillage, mais ce n’est pas le cas en réalité : nous parvenons toujours à visualiser les fichiers PDF dans Safari. Notre démonstration a également utilisé un site développé par crypt.ee, qui emploie des moyens techniques pour vérifier l'état du mode verrouillage.