- Apple a corrigé CVE-2024-54471 dans macOS Sequoia 15.1, Sonoma 14.7.1 et Ventura 13.7.1, publiés le 28 octobre 2024 ; avant cette mise à jour, des identifiants stockés pouvaient être exposés via NetAuthAgent
- Le cœur du problème tenait au fait que le serveur MIG de NetAuthAgent exposait des routines de consultation, de création et, dans certains cas, d’écrasement partiel d’identifiants de serveurs de fichiers, sans vérifier l’expéditeur des messages
- Un attaquant pouvait envoyer des messages au service Mach
com.apple.netauth.user.gui, amener NetAuthAgent à consulter à sa place des élémentsinternet passworddu Keychain, et recevoir le nom d’utilisateur et le mot de passe - L’impact ne se limitait pas aux identifiants FTP, Samba, WebDAV ou de serveurs d’impression enregistrés via « Connect to Server » dans le Finder : une chaîne distincte pouvait aussi mener à l’exposition des informations de compte iCloud et de jetons d’API
- Après le correctif, NetAuthAgent vérifie, via l’audit token des messages Mach, l’entitlement du processus émetteur et ne répond pas en l’absence de
com.apple.private.netauth.useragent.allow=true
Périmètre du correctif de CVE-2024-54471
- CVE-2024-54471 est une vulnérabilité macOS corrigée dans les mises à jour de sécurité d’Apple
- Les versions incluant le correctif ont toutes été publiées le 28 octobre 2024
- macOS Sequoia 15.1
- macOS Sonoma 14.7.1
- macOS Ventura 13.7.1
- Les appareils macOS qui n’ont pas été mis à jour vers ces versions doivent l’être immédiatement
IPC macOS et architecture basée sur Mach
- Le noyau de macOS et de la plupart des OS d’Apple est XNU, un noyau hybride qui combine des éléments de la famille BSD avec une variante fortement modifiée du noyau Mach
- Dans macOS moderne, Mach repose toujours sur quatre abstractions
- task : environnement d’exécution dans lequel les threads s’exécutent, et unité de base d’allocation des ressources
- thread : unité de base d’utilisation du CPU
- port : canal de communication correspondant à une file de messages protégée par le noyau
- message : ensemble d’objets de données typés utilisés pour la communication entre threads
- Les ports Mach ne sont pas des files directement exposées à l’espace utilisateur ; ils sont manipulés sous forme de port rights dans l’espace de noms de ports de chaque task
- Il existe deux droits principaux
- send right : plusieurs tasks peuvent le posséder pour un même port
- receive right : une seule task peut le posséder
- Cette structure crée un modèle client-serveur, dans lequel une task serveur reçoit les messages de plusieurs tasks clientes
- Le bootstrap server de macOS reçoit un port pour lequel toutes les tasks disposent d’un send right, et permet aux clients de demander le send right d’un service Mach enregistré sous un nom textuel
Une absence d’authentification dans un serveur MIG
- MIG est un outil qui enveloppe l’envoi et la réception de messages Mach dans une interface fonctionnelle
- MIG se compose d’un IDL pseudo-C et d’un compilateur, et génère les fichiers suivants à partir d’un fichier IDL
- source C côté client
- source C côté serveur
- en-tête C utilisé des deux côtés
- Chaque fonction est appelée routine, et un ensemble de routines est appelé subsystem ; le numéro du subsystem et l’index de la routine sont reflétés dans l’ID du message
- Dans les communications en espace utilisateur de macOS, MIG a globalement été supplanté par l’API XPC, mais XPC est lui aussi construit au-dessus des messages Mach
- Un serveur MIG n’intègre pas de mécanisme d’authentification obligatoire ; si le serveur ne vérifie pas l’expéditeur, n’importe quelle task disposant d’un send right peut appeler des routines à distance
- Pour explorer les serveurs MIG, le CLI ipsw de blacktop est utile ; une approche consiste à chercher les binaires qui importent le symbole
NDR_record- Cette méthode peut trouver non seulement des serveurs MIG, mais aussi des clients MIG
- Le code serveur et le code client se distinguent relativement facilement dans un désassembleur ou un décompilateur
Les identifiants gérés par NetAuthAgent
- NetAuthAgent est l’agent utilisateur de macOS chargé de traiter les identifiants de serveurs de fichiers comme FTP, Samba ou WebDAV
- La boîte de dialogue d’authentification qui apparaît lorsqu’on se connecte à un serveur de fichiers via « Go → Connect To Server » dans le Finder est fournie par NetAuthAgent ou par des processus associés
- Lorsque l’utilisateur coche l’option d’enregistrement du mot de passe, les identifiants sont stockés dans le Keychain de macOS
- NetAuthAgent ne stocke pas directement les mots de passe ; il utilise le Keychain comme un magasin central de secrets
- Les éléments du Keychain possèdent leur propre liste de contrôle d’accès, qui empêche généralement les applications d’accéder à des secrets auxquels elles ne devraient pas accéder
- Toutefois, si un processus donné expose un mécanisme lui permettant d’effectuer des requêtes Keychain pour le compte d’autres processus, tout le modèle de sécurité peut être affaibli
Le service MIG vulnérable de NetAuthAgent
- NetAuthAgent exposait un serveur MIG consultable via le bootstrap server
- Le nom du service était
com.apple.netauth.user.gui - Ce serveur fournissait des routines permettant de lire, créer et, dans certains cas, écraser des identifiants de serveurs de fichiers
- Avant le correctif, ces routines ne vérifiaient pas l’expéditeur du message
- La routine 19, avec l’ID de message 40219, pouvait proxyfier la consultation d’éléments de classe
internet passworddu Keychain - Cette routine recevait un dictionnaire d’options sérialisé sous forme de descriptor de données out-of-line, et renvoyait le nom d’utilisateur et le mot de passe sous forme de deux descriptors de données out-of-line
Déroulé de l’attaque et composition du PoC
- Le PoC utilise Kass, un outil de recherche en sécurité écrit en Swift, pour manipuler les messages Mach et les clients MIG
- Le client NetAuthAgent est défini avec les valeurs suivantes
- Nom du service :
com.apple.netauth.user.gui - ID de routine de base du subsystem : 40200
- Nom du service :
- Les options de recherche sont sérialisées sous forme de Property List, et peuvent inclure des champs comme
Scheme,Host,AlternatePortouPath - L’API Keychain macOS
SecItemCopyMatchingpeut être utilisée par des processus non autorisés pour obtenir les métadonnées d’éléments du Keychain, à condition de ne pas demander les valeurs secrètes - Les listes de contrôle d’accès étant elles aussi accessibles comme métadonnées, il était possible de vérifier si
/System/Library/CoreServices/NetAuthAgent.appfigurait dans la liste des applications de confiance d’un élément - Le code d’attaque pouvait parcourir les éléments
internet passwordauxquels NetAuthAgent avait accès et extraire les informations suivantes- nom affiché
- protocole
- hôte
- port
- chemin
- nom d’utilisateur
- mot de passe
Impact de la fuite d’identifiants de serveurs de fichiers
- Avant le correctif, un processus malveillant ayant obtenu un send right vers NetAuthAgent pouvait exfiltrer l’ensemble des identifiants de serveurs de fichiers
- En environnement d’entreprise, ces identifiants pouvaient être des identifiants SSO, donnant potentiellement à l’attaquant accès à de nombreuses ressources des systèmes de l’entreprise
- L’ampleur de l’usage de la fonction Connect to Server du Finder est inconnue, mais les documentations d’aide de plusieurs universités et établissements d’enseignement recommandaient aux étudiants et au personnel d’utiliser cette fonction, et certaines conseillaient de cocher l’enregistrement dans le Keychain
- Des guides de connexion à des imprimantes publiés par des fournisseurs de serveurs d’impression ont aussi été trouvés, et NetAuthAgent gère également les identifiants de serveurs d’impression
- Au moins un document recommandait de ne pas cocher l’enregistrement du mot de passe, au motif que l’application Keychain Access est difficile à utiliser pour les utilisateurs ordinaires lorsqu’il faut mettre à jour un mot de passe enregistré
- Sur des appareils gérés, si les mêmes identifiants étaient également utilisés comme identifiants de superuser, cela pourrait entraîner une élévation de privilèges, mais cela n’a pas été confirmé faute de tests sur des appareils gérés
- Lorsqu’un particulier se connectait à un NAS via le Finder et enregistrait ses identifiants, les identifiants du NAS pouvaient aussi être exposés à un attaquant
- Si les mêmes identifiants étaient réutilisés pour d’autres comptes Internet, ces comptes pouvaient également être compromis
- FTP, Samba et WebDAV disposent d’interfaces bien définies, ce qui facilite l’automatisation de l’exploration et de l’exfiltration des fichiers du serveur après une fuite d’identifiants
Exploitation supplémentaire via le Keychain
- Comme NetAuthAgent exposait aussi une routine de création d’éléments Keychain, un processus malveillant pouvait y dissimuler des données arbitraires dans le champ
password - Cette méthode pouvait servir de moyen de dissimulation de données contournant les logiciels de sécurité, puisqu’elle évitait les écritures directes sur le disque
- On ne sait pas s’il existe des logiciels de sécurité inspectant explicitement les éléments suspects du Keychain
- Un processus malveillant pouvait aussi enregistrer des identifiants légitimes dans le Keychain
- Pris isolément, ce comportement pouvait avoir un effet limité, mais il pouvait être utilisé dans une attaque combinée où l’attaquant enregistre les identifiants d’un serveur de fichiers qu’il contrôle, puis manipule l’utilisateur par ingénierie sociale
Chaîne d’exploitation jusqu’aux jetons d’API iCloud
- Même les utilisateurs qui n’utilisaient pas Connect to Server n’étaient pas à l’abri de cette vulnérabilité
- La plupart des appareils macOS contiennent des éléments Keychain dont l’ACL est suffisamment large pour que NetAuthAgent y ait accès
- Cet élément Keychain contient une clé de déchiffrement permettant de déchiffrer un fichier spécifique sur le disque
- Ce fichier contient les informations de compte iCloud et des jetons d’API de l’utilisateur
- En utilisant l’élément Keychain et le fichier situé à un emplacement connu, l’attaquant pouvait obtenir les informations suivantes
- prénom et nom
- adresse e-mail
- alias e-mail
- fonctionnalités et endpoints activés
- plusieurs jetons d’API longue durée
Actions possibles avec les jetons iCloud
- Des recherches antérieures de Wojciech Reguła avaient montré qu’il était possible de retrouver les mêmes jetons d’API par une autre méthode et d’exfiltrer les données suivantes
- Contacts
- Calendriers
- Rappels
- localisation de l’utilisateur via Find My
- Parmi ces résultats, tous ont été reproduits à l’exception des Rappels
- Pour les nouveaux comptes et les comptes migrés, Apple a déplacé les Rappels vers CloudKit, plus sûr, et ils ne sont désormais accessibles que sous forme chiffrée
- Les actions supplémentaires possibles étaient les suivantes
- exfiltration des photos de contacts
- requêtes CloudKit, mais sans déchiffrement
- exfiltration des données de l’iCloud key-value store
- exfiltration des métadonnées de sauvegardes iCloud, y compris les numéros de série des appareils
- exfiltration de la position des autres appareils de l’utilisateur via Find My
- exfiltration de la position des amis de l’utilisateur via Find My
- exécution d’actions de verrouillage, d’effacement et de lecture de son via Find My
- Le déchiffrement des données CloudKit a été étudié, mais n’a pas abouti
- Il n’était pas exclu que des sociétés de forensic commercial puissent utiliser ces jetons d’API, éventuellement avec le PIN de l’appareil iOS, pour déchiffrer des données CloudKit ou des données CloudKit présentes dans des sauvegardes iCloud
La méthode de correction d’Apple
- Après le correctif, NetAuthAgent commence par vérifier l’entitlement de l’expéditeur lorsqu’il reçoit un message
- Un entitlement est une paire clé-valeur attachée au binaire lors de la signature du code
- Sur macOS avec la configuration de sécurité standard, Apple Mobile File Integrity vérifie les entitlements restreints lors de l’exécution d’un processus et met fin au processus s’il ne dispose pas d’un provisioning profile approprié
- Le provisioning profile devant être signé par Apple, ce contrôle est conçu pour être difficile à contourner
- L’entitlement exigé par NetAuthAgent est le suivant
- clé :
com.apple.private.netauth.useragent.allow - valeur : booléen
true
- clé :
- NetAuthAgent ne répond pas aux expéditeurs qui ne disposent pas de cet entitlement
- Le trailer ajouté par le noyau à la réception d’un message Mach contient un audit token
- La task réceptrice peut utiliser cet audit token pour identifier la task émettrice, demander au noyau le dictionnaire d’entitlements correspondant, puis en vérifier la valeur
Les maillons faibles de l’architecture de sécurité
- Même si les identifiants de serveurs de fichiers sont enregistrés de façon à n’être accessibles qu’à certaines applications, si l’une de ces applications accepte des commandes de consultation provenant d’autres applications, elle devient un maillon faible
- Même si les jetons d’API iCloud sont stockés dans un fichier chiffré sur le disque, si la clé de déchiffrement se trouve dans un élément Keychain à l’ACL large, cette ACL devient le maillon faible
- macOS dispose de mécanismes de sécurité qui rendent l’injection de processus difficile, et son infrastructure de sécurité globale est jugée solide
- Pourtant, comme le montre cette vulnérabilité, une simple absence de validation de l’expéditeur peut mener à l’exposition d’identifiants de serveurs de fichiers et de jetons d’API iCloud
Mesures recommandées aux utilisateurs
- Si c’est encore possible, il est recommandé d’activer Advanced Data Protection
- Si vous n’utilisez pas iCloud depuis un navigateur web, la désactivation de l’accès web aux données iCloud est également une option
- Le site web iCloud utilise parfois des endpoints d’API différents de ceux des applications iCloud d’Apple
- Cette vulnérabilité ne permet plus d’accéder aux jetons, mais ceux-ci ont déjà pu être exposés par d’anciennes vulnérabilités et pourraient l’être à nouveau via d’autres vulnérabilités
- Rien ne prouve que cet exploit ait été utilisé ou découvert par des acteurs malveillants
- Néanmoins, si l’exploitation d’identifiants vous préoccupe particulièrement, il faut changer les mots de passe
- Les appareils qui n’ont pas mis à jour macOS depuis octobre 2024 doivent l’être immédiatement
1 commentaires
Avis sur Hacker News
Article bien écrit, qui rappelle le zero-day où une connexion root pouvait être contournée en essayant deux fois un mot de passe vide, et qu’Apple avait plus ou moins tenté d’étouffer. C’était vers 2017, peut-être 2018
Dans n’importe quelle boîte de connexion root, si l’on saisissait un nom d’utilisateur administrateur et qu’on laissait le mot de passe vide, la première tentative indiquait que le mot de passe était incorrect, mais après avoir fermé l’alerte et cliqué une deuxième fois, on était connecté avec cet utilisateur
C’était reproductible à 100 % le jour même et a été corrigé peu après s’être répandu sur les réseaux sociaux, mais cela ressemblait tout de même à un énorme oversight. Il semble qu’il reste encore de vieux résidus autour des mécanismes d’authentification du Mac, et la mention du système de ports du noyau Mach est intéressante
Quand le tampon du nom d’utilisateur a atteint 256 caractères arbitraires, XDM a crashé et a lancé un shell root. Cela dit, c’était au début des années 90, quand tout le monde était bien plus naïf en matière de sécurité
grep, et ça marchait à 100 %« ACLs don't » : https://waterken.sourceforge.net/aclsdont/current.pdf
Une petite correction a été apportée à l’article : la vérification des entitlements ne se trouve pas dans la couche Mach du noyau
https://github.com/nmggithub/wts/commit/2bdce1c0c76c7adc360e17a6a42ee547462b99d3
C’est une modification d’un seul mot qui corrige une erreur factuelle dans la partie décrivant le fonctionnement de XNU
Le passage disant qu’« un processus qui expose un mécanisme permettant à un autre processus de proxyfier de fait une requête au keychain peut affaiblir la sécurité de tout le système » ressemble au problème du député confus : https://en.wikipedia.org/wiki/Confused_deputy_problem
Une conception fondée sur les capabilities devrait pouvoir empêcher systématiquement ce genre de problème
Je me demande où l’auteur a fourni le véritable code PoC. J’aimerais tester un peu les mesures d’atténuation, mais le code d’exemple est visible et semble incomplet
Quel est le niveau de risque réaliste ?
Côté risque, une app pouvant obtenir un send right vers NetAuthAgent — en pratique presque toute app non sandboxée — peut demander silencieusement à NetAuthAgent les identifiants enregistrés de lecteurs de fichiers comme FTP, WebDAV ou Samba. Cela peut aussi mener à l’exfiltration complète des contacts et calendriers iCloud, ainsi qu’à d’autres fuites de données liées à iCloud
Le sandboxing rend cela plus difficile, mais pas impossible. Si le système est à jour, le risque est nul, et le correctif est arrivé en octobre dernier, donc, franchement, il devrait déjà être installé. Si vous n’avez pas mis à jour et ne comptez pas le faire, le risque est bien plus élevé, à moins de vérifier absolument tous les processus qui s’exécutent sur la machine
C’est un article très détaillé, et j’ai apprécié qu’il couvre aussi l’histoire de plusieurs noyaux. Cela dit, pour un article sur un problème de sécurité sérieux, j’aimerais voir au début une très brève explication de la portée de l’impact, des conditions d’attaque, et du fait qu’il s’agisse d’une erreur logique ou d’une corruption mémoire
Il suffirait que ce soit assez court pour décider si l’on veut lire la suite
Article vraiment passionnant. Je ne savais pas qu’il y avait autant de coulisses dans la création de Mach et du noyau Darwin
À ce stade, Mach donne l’impression d’être une source régulière de bugs macOS. Je sais qu’Apple travaille dur à le verrouiller, mais existe-t-il une voie pour s’en éloigner complètement ?
Si un démon ne vérifie pas l’entitlement, ce n’est pas sûr. Il faut blâmer la façon dont le mécanisme de messagerie est utilisé, plutôt que le mécanisme lui-même
En réalité, tout système de messagerie verrouillé a besoin de plus qu’un simple transfert de messages, par exemple une vérification de l’expéditeur. Ce n’est pas quelque chose qu’on obtient automatiquement avec un protocole de communication bas niveau comme Mach, sauf si Apple remanie le compilateur MIG pour y ajouter des vérifications d’entitlements
Mach est excellent lorsqu’il est utilisé avec des vérifications d’entitlements
Techniquement, davantage de composants différents pourraient coexister, ce qui augmenterait la surface d’attaque potentielle. Mais une surface plus spécialisée peut simplifier le contrôle et, au final, permettre de mieux la protéger