Jamf Blog

Faux mode avion : une technique de sabotage pour maintenir la connectivité des mobiles

Jamf Threat Labs a développé une technique de persistance post-exploit sur iOS 16 qui affiche un faux « mode avion ». Une fois l’appareil exploité, le pirate met en place un mode avion artificiel : il modifie l’interface utilisateur pour afficher l’icône du mode avion et coupe la connexion de toutes les applications, à l’exception de la sienne. Il conserve ainsi l’accès à l’appareil alors que l’utilisateur pense être hors ligne. Cette technique n’a pas encore été observée dans la nature et n’est possible que sur un appareil déjà exploité ou jailbreaké.

Recherches menées par Hu Ke et Nir Avraham.

Le mode avion de votre téléphone a-t-il été saboté ?

Comme son nom l’indique, le mode avion permet aux passagers d’un vol à utiliser un appareil mobile en toute sécurité. Il désactive les fonctionnalités cellulaires pour éviter toute interférence avec les équipements de vol critiques.

Mais l’utilisation de cette fonctionnalité ne s’arrête pas là : certains s’en servent pour économiser leur batterie, d’autres pour se couper de notre monde connecté en permanence. On suggère même de l’utiliser comme technique de méditation.

Pour les personnes souffrant de cyberparanoïa et de technophobie, le mode avion peut être utile pour retrouver une certaine tranquillité d’esprit et un sentiment de confidentialité.

Mais faut-il utiliser le mode avion pour protéger sa sécurité et sa vie privée ?

Aujourd’hui, nous allons nous plonger dans la technologie qui sous-tend le mode avion sur iOS pour présenter une technique de piratage. Cette technique permettrait à un acteur malveillant de maintenir une connexion au réseau cellulaire pour une application spécifique, alors même que l’utilisateur croit avoir activé le mode avion.

Les fondements

Commençons par analyser le fonctionnement du mode avion. Deux démons se chargent de la tâche qui consiste à passer en mode avion. SpringBoard effectue les changements sur l’interface utilisateur, et CommCenter intervient sur l’interface réseau sous-jacente. Notez que c’est aussi CommCenter qui permet aux utilisateurs de « bloquer l’accès aux données cellulaires pour des applications spécifiques ».

Comme vous pouvez le constater, dans des conditions normales, lorsque l’utilisateur active le mode avion, l’interface réseau pdp_ip0 (données cellulaires) n’affiche plus les adresses IPv4/IPv6. Le réseau cellulaire est déconnecté et inutilisable, du moins au niveau de l’utilisateur.

Création d’un mode avion artificiel

Nous allons maintenant expliquer comment nous avons créé un mode avion artificiel afin de conserver les modifications de l’interface utilisateur tout en préservant la connectivité cellulaire d’une application particulière. Dans un scénario de piratage, il s’agirait du logiciel malveillant installé grâce à une exploitation de l’appareil.

Commençons par suivre les journaux de la console. Lorsque vous activez le mode avion, la première entrée pertinente semble être la suivante : « #N User airplane mode preference changing from... » (modification de la préférence mode avion de l’utilisateur...).

Utilisons cette chaîne pour localiser le code qui y fait référence dans le désassembleur. Il s’agit d’une fonctionnalité C++ sans symbole que l’on trouve ici :

En espérant que cette fonctionnalité se trouve suffisamment tôt dans la chaîne d’appels qui activent le mode avion, nous avons réussi à l’accrocher et à la remplacer par une fonction vide (« ne rien faire »). Le résultat : un faux mode avion. Maintenant, lorsque l’utilisateur active le mode avion, l’appareil n’est pas déconnecté du réseau cellulaire et l’accès à Internet est maintenu.

Préserver l’expérience utilisateur attendue

Mais pour dissimuler l’attaque derrière l’expérience normale du mode avion, il faut apporter quelques modifications supplémentaires à l’interface utilisateur. Nous allons, par exemple, atténuer l’icône « réseau cellulaire » et empêcher l’utilisateur d’interagir avec elle.

Pour ce faire, nous avons accroché deux méthodes Objective-C et injecté du code qui modifie l’icône « réseau cellulaire » pour obtenir l’effet escompté. -[SBStatusBarStateAggregator _noteAirplaneModeChanged] and -[CCUIModularControlCenterOverlayViewController _beginPresentationAnimated:interactive:]

Simulation de déconnexion

Une fois le mode avion activé, et en l’absence de connexion Wi-Fi, l’utilisateur s’attend à n’avoir aucune connexion à Internet en ouvrant Safari. Normalement, une fenêtre de notification l’invite à « Désactiver le mode avion ». Pour reproduire ce comportement, nous utilisons la fonctionnalité CommsCenter vue plus haut afin de « Bloquer l’accès aux données cellulaires pour des applications spécifiques » et nous la déguisons en mode avion grâce à la fonction accrochée ci-dessous.

L’expérience utilisateur contrefaite est visible dans les capteurs d’écran ci-dessous. Le message habituel de la fonctionnalité « Bloquer l’accès aux données cellulaires pour des applications spécifiques » apparaît sur la gauche, le résultat de l’accrochage de la fenêtre de notification imitant le mode avion se trouve à droite.

Remplacer la fenêtre d’alerte est une chose, mais comment avons-nous coupé Internet pour Safari sans activer réellement le mode avion et affecter l’ensemble de l’appareil ? C’est en effet un signe clair que le mode avion est activé.

Comment fonctionne la fenêtre d’alerte « Les données cellulaires sont désactivées » ?

Comme dans le cas de la manipulation des icônes, nous avons découvert que le gestionnaire d’interface SpringBoard affichait la fenêtre d’alerte sur notification de CommCenter. En allant un plus loin, nous avons compris que CommCenter recevait lui-même une notification du noyau par l’intermédiaire d’une fonction d’observation/callback enregistrée.

CommCenter`CellularUsagePolicyController::createNEConfigurationStore_sync

-> NetworkExtension.framework`-[NEPathEventObserver initWithQueue:eventHandler:]

-> libnetwork.dylib`network_config_cellular_blocked_observer_create

Ces fonctions network_config_* appellent socket()/ioctl() en interne pour interagir avec le noyau :

network_config_cellular_blocked_observer_create

-> network_config_policy_observer_create

-> __network_config_policy_observer_create_block_invoke

-> network_config_setup_policy_event_watcher

-> socket(32, 3, 1)

-> ioctl(...)

Nous avons tiré parti de ’fsevents’, et observé que le démon CommCenter gère également un fichier de base de données SQL /private/var/wireless/Library/Databases/CellularUsage.db. Cette base de données enregistre le statut d’accès aux données cellulaires de chaque application.

La valeur de « flags » est fixée à 8 si une application n’est pas autorisée à accéder aux données cellulaires. C’est très pratique : le fichier de base de données SQL nous donne une liste d’identifiants de paquets d’applications et leur valeur prédéfinie.

À l’aide de cette base de données, nous pouvons maintenant bloquer ou autoriser de manière sélective l’accès d’une application au Wi-Fi ou aux données cellulaires grâce au code suivant. En associant cette manipulation aux autres techniques décrites plus haut, nous obtenons un faux mode avion qui a toutes les apparences du vrai, à ceci près que l’interdiction d’accès à Internet s’applique uniquement aux applications et pas aux autres processus – un cheval de Troie qui installerait une porte dérobée par exemple.

Jamf Executive Threat Protection identifie les attaques sophistiquées pour assurer la sécurité de vos utilisateurs.

S'abonner au blog

Recevez directement dans votre boîte mail les tendances du marché informatique, les mises à jour Apple et les actualités Jamf.

Pour en savoir plus sur la manière dont nous collectons, utilisons, partageons, transférons et protégeant vos informations personnelles, veuillez consulter notre Politique de confidentialité.