Chaîne de vulnérabilités Zero-Click via des invitations Calendar sur macOS

 (medium.com/@mikko-kenttala)
1 points par GN⁺ 2024-09-14 | 1 commentaires | Partager sur WhatsApp
  • Un défaut dans le traitement des pièces jointes des invitations de Calendar sur macOS permettait à un attaquant d’écrire et supprimer des fichiers arbitraires dans le sandbox de Calendar, ouvrant la voie à une chaîne menant à l’exécution de code à distance et à l’accès aux données de Photos
  • L’étape 1, CVE-2022-46723, ne nettoyait pas correctement des entrées de traversée de chemin dans la section ATTACH comme FILENAME=../../../PoC.txt, ce qui permettait d’enregistrer une pièce jointe en dehors de l’emplacement prévu
  • La chaîne d’exécution de code à distance exploitait le comportement Open File de Calendar lors de la mise à niveau de Monterey vers Ventura, en injectant plusieurs fichiers et en combinant DMG, montages SMB et schéma d’URL personnalisé
  • À l’étape Photos, defaults import appliquait une configuration malveillante pour faire pointer la System Photo Library vers /var/tmp/mypictures/Syndication.photoslibrary, afin que les originaux de photos iCloud soient synchronisés dans un répertoire non protégé par TCC
  • Apple a corrigé l’ensemble des vulnérabilités concernées entre octobre 2022 et septembre 2023 ; la faille Photos a été traitée sous CVE-2023-40434 et le contournement de Gatekeeper sous CVE-2023-40433

Traversée de chemin dans les pièces jointes de Calendar

  • Une invitation Calendar malveillante pouvait inclure une pièce jointe, et une validation insuffisante du nom de fichier rendait possible une traversée de répertoires
  • L’attaquant pouvait spécifier un chemin arbitraire dans la section ATTACH, par exemple FILENAME=../../../PoC.txt
    • L’emplacement normal d’enregistrement est ~/Library/Calendar/[CalendarID]/Attachments/[eventid]/
    • Dans le comportement vulnérable, le fichier était enregistré dans ~/Library/Calendar/PoC.txt
  • Si un fichier du même nom existait déjà, le nouveau était enregistré sous PoC.txt-2, mais si l’événement ou la pièce jointe envoyé ensuite par l’attaquant était supprimé, le PoC.txt d’origine pouvait être supprimé
  • Ce comportement pouvait aussi servir à supprimer des fichiers existants à l’intérieur du sandbox de Calendar sur le système de fichiers
  • La vulnérabilité existait au minimum dans la dernière version de macOS Monterey 12.5, et il a été confirmé que macOS 13.0 beta4 n’était plus vulnérable

Une chaîne étendue jusqu’à l’exécution de code à distance

  • Une vulnérabilité découverte juste avant la sortie de macOS Ventura a été étendue jusqu’à l’exécution de code à distance en exploitant le processus de mise à niveau de version et la fonction Open File de Calendar
  • L’attaquant utilisait la vulnérabilité d’écriture de fichiers arbitraires de Calendar pour injecter plusieurs fichiers et préparer une chaîne RCE déclenchée lors du passage de Monterey à Ventura

  • Composition des fichiers injectés

    • 000Hacked-$RANDOM.calendar
      • Contient des données Calendar ressemblant à un calendrier « Siri Suggested »
      • Inclut des événements récurrents et des alertes, et agit pour ouvrir d’autres fichiers injectés
    • CalendarTruthFileMigrationInProgress
      • Fichier destiné à forcer l’ancien Calendar à effectuer une mise à niveau et une fusion depuis l’ancien format vers la nouvelle base de données
    • CalPoCInit.dmg
      • La première alerte Calendar ouvre ~/Library/Calendars/CalPoCInit.dmg
      • Le bookmark du .DS_Store à l’intérieur du DMG inclut une référence d’image d’arrière-plan située sur un serveur Samba externe
      • Même si CalPoCInit.dmg lui-même est en quarantaine, le montage se fait sans quarantine flag
    • stage1.url
      • La deuxième alerte Calendar ouvre ~/Library/Calendars/stage1.url
      • Ce fichier contient une URL file:///Volumes/CalPoCPayload/MyMidiTest.app pointant vers une application dans le volume Samba monté à l’étape précédente
      • Quand Finder ouvre /Volumes/CalPoCPayload/, l’indexation se lance automatiquement et MyMidiTest.app est indexée
      • Le Info.plist du bundle applicatif enregistre un gestionnaire de schéma d’URL personnalisé mymiditest
    • stage2.url
      • La troisième alerte Calendar ouvre ~/Library/Calendar/stage2.url
      • Ce fichier référence mymiditest:// pour lancer l’application malveillante sans interaction utilisateur

Contournement de Gatekeeper et exécution de l’application

  • L’exécution de mymiditest:// était possible parce que l’application se trouvait dans un montage Samba créé par l’exploit, et que cet emplacement n’avait pas de quarantine flag
  • L’application mymiditest écrit les fichiers nécessaires à l’étape 3 dans /var/tmp/, puis exécute le script via Terminal avec open /var/tmp/PhotosPoC.sh
  • L’ensemble de la chaîne était conçu pour sortir du sandbox de Calendar en injectant plusieurs fichiers, contourner les atténuations de Gatekeeper via l’astuce SMB, puis exécuter du code arbitraire

Modification des réglages de Photos pour accéder aux photos iCloud

  • L’étape suivant l’exécution de code à distance visait à modifier la configuration de Photos pour accéder aux photos sensibles de l’utilisateur, en particulier iCloud Photos
  • En temps normal, l’accès à des fichiers sensibles comme ceux de Photos devrait être restreint par TCC, mais en modifiant les réglages de Photos, la System Photo Library pouvait pointer vers un chemin non protégé par TCC
  • L’attaquant pouvait créer un fichier de configuration Photos utilisant une autre System Photo Library, puis l’importer avec defaults import
  • Dans la chaîne PoC, l’étape 2 préparait automatiquement une configuration utilisant /var/tmp/mypictures/Syndication.photoslibrary comme System Photo Library
    • Les fichiers de configuration malveillants associés étaient créés dans /var/tmp/mypictures/*.plist
    • Les applications Photos en cours d’exécution étaient fermées
    • La configuration d’origine était sauvegardée dans /var/tmp/mypictures/*-orig.plist
    • La configuration malveillante était importée depuis /var/tmp/mypictures/
    • La nouvelle photothèque était ouverte dans Photos avec open /var/tmp/mypictures/Syndication.photoslibrary
  • Syndication.photoslibrary est une photothèque modèle vide ; quand Photos démarre avec cette nouvelle System Photo Library, la synchronisation iCloud s’active et les fichiers originaux sont téléchargés dans un répertoire non protégé
  • Les fichiers synchronisés sur le disque étaient copiés vers un nouveau répertoire sous /var/tmp/PoCLoot$RANDOM/
  • Avec de simples modifications, le PoC pouvait copier les données vers une ressource externe ou les publier vers un serveur web externe via la commande curl

Calendrier des correctifs et question de prime encore en suspens

  • La chaîne complète devait franchir successivement les barrières de sécurité de macOS
    • Injection de plusieurs fichiers dans Calendar pour contourner le sandbox et activer l’étape suivante
    • Contournement des atténuations de Gatekeeper via l’astuce SMB pour exécuter du code arbitraire
    • Contournement de la protection TCC pour accéder à des données sensibles comme iCloud Photos
  • Avant les correctifs, il était possible d’envoyer une invitation Calendar malveillante à des utilisateurs Apple iCloud et de voler leurs iCloud Photos sans interaction utilisateur
  • Apple a corrigé toutes les vulnérabilités concernées entre octobre 2022 et septembre 2023

  • Chronologie

    • 2022-08-08 : signalement d’une écriture/suppression arbitraire de fichiers dans le sandbox de Calendar
    • 2022-10-24 : correctif dans macOS Monterey 12.6.1 et Ventura 13
      • Cet élément n’avait pas de CVE, et Ventura beta3 était vulnérable
    • 2022-11-14 : transmission d’un PoC étendant la vulnérabilité Calendar à l’exécution de code arbitraire et au contournement de Gatekeeper
    • 2022-12-04 : transmission d’un PoC d’accès à iCloud Photos
    • 2023-02-20 : ajout d’un crédit et d’un CVE, CVE-2022-46723, pour la vulnérabilité Calendar
    • 2023-03-27 : correction du contournement de Gatekeeper dans macOS Ventura 13.3
      • À ce moment-là, il n’y avait ni CVE ni crédit
    • 2023-09-26 : correction de la vulnérabilité Photos CVE-2023-40434 avec attribution du crédit
    • 2023-10-09 : annonce de la bug bounty liée au contournement de Gatekeeper et à la vulnérabilité Photos
    • 2023-12-21 : attribution du crédit CVE-2023-40433 au contournement de Gatekeeper
    • 2024-09-12 : toujours aucune bounty pour la vulnérabilité initiale d’écriture/suppression arbitraire de fichiers dans Calendar, CVE-2022-46723
    • Mise à jour du 2024-10-20 : Apple a décidé que la vulnérabilité d’écriture/suppression arbitraire de fichiers dans Calendar, CVE-2022-46723, ne donnait pas droit à une bounty car elle n’affectait que macOS Monterey et n’existait déjà plus dans Ventura au stade bêta

À lire aussi

1 commentaires

 
GN⁺ 2024-09-14
Avis sur Hacker News

  • Je suis content de ne pas utiliser iCloud Photo Library, mais il est étrange que, si l’on change l’emplacement de la photothèque, le nouvel emplacement ne bénéficie d’aucune protection
    Si l’on définit /var/tmp/mypictures/Syndication.photoslibrary comme photothèque système et qu’on ouvre Photos, je m’attendais à ce que l’exploit échoue, puisque l’app Photos devrait protéger ce répertoire
    En faisant un essai rapide sous Sonoma 14.6.1, si l’on maintient la touche Option enfoncée et qu’on ouvre Photos pour créer une nouvelle photothèque dans ~/Pictures, une app sans accès complet au disque ni autorisation d’accès aux photos se voit refuser l’accès à ce dossier
    Mais si l’on crée une nouvelle photothèque dans /tmp, la même app peut y accéder, et ce comportement est déroutant et incohérent
    Si Apple veut vraiment prendre en charge la possibilité de déplacer une photothèque n’importe où dans le système de fichiers, elle doit aussi appliquer correctement les protections

    • Ça se comprend dans une certaine mesure. Historiquement, /tmp a toujours été un emplacement de la hiérarchie des répertoires où tout le monde peut lire et écrire, et ce n’est pas un bon choix pour stocker des données privées
    • TCC a toujours été un peu étrange et assez troué de cette manière
    • Sous Linux, il est désormais bien plus facile que sous macOS d’isoler tout ce qu’on veut
      Même sans AppArmor ni Firejail, la plupart des services reçoivent par défaut un répertoire temporaire dédié

  • Ce fil contient beaucoup de discussions sur le versement des primes de bug bounty, mais si un géant de la tech qui gère un programme de primes permanent ne verse pas la récompense, il y a généralement de bonnes chances qu’il ait une raison valable
    Les incitations de ce type de programme sont presque toutes alignées sur le fait de récompenser les soumissions légitimes
    C’est un cas rare où les incitations sont plutôt bien alignées : l’entreprise crée un programme de primes pour encourager certains types de recherche, et ne pas verser une récompense légitime va à l’encontre de cet objectif
    La personne responsable côté fournisseur ne dépense pas son propre argent, et les montants ne sont pas significatifs à l’échelle de l’entreprise
    En général, les membres de l’équipe qui gère le programme sont incités à verser davantage, plutôt qu’à réduire les primes

    • Non. C’est parce que la product security team d’Apple, chargée d’enquêter sur les bug bounties et de les verser, est mal gérée et inefficace
      Elle a récemment été transférée du SWE program office vers SEAR (security engineering & arch), et son manager a lui aussi été récemment évincé et est parti chez AirBNB
      La plupart des membres de l’équipe sont des ICT2·ICT3 tout juste diplômés, des gens qui ne réussiraient même pas les entretiens de code ailleurs dans l’entreprise, et travaillent surtout comme des trieurs de bugs
      Ils passent plus de temps à aller à des conférences et à traîner avec des hackers qu’à travailler devant leur ordinateur
      Le graphique du portail « enquête en cours » ne fait que monter, ce qui signifie que les e-mails s’accumulent et qu’ils n’essaient même pas de rattraper le retard
      Les personnes qui devraient recevoir une prime mais ne l’ont pas reçue doivent mettre publiquement la pression sur Ivan, le responsable de SEAR, sur Twitter pour voir les choses avancer
    • C’est possible. Le programme de bug bounty défaillant d’Apple est peut-être le résultat de l’incompétence, et non d’une malveillance délibérée
      Mais est-ce que cela compte pour les chercheurs en sécurité ou pour le public ? Non. Quelle que soit la raison de son dysfonctionnement, Apple doit corriger son programme de primes
      Au fond, cet article de blog n’est qu’un exemple de plus dans une pile déjà énorme[1][2][3][4][5]
      1: https://arstechnica.com/information-technology/2021/09/three...
      2: https://mjtsai.com/blog/2021/07/13/more-trouble-with-the-app...
      3: https://medium.com/macoclock/apple-security-bounty-a-persona...
      4: https://theevilbit.github.io/posts/experiences_with_asb/
      5: https://shail-official.medium.com/accessing-apples-internal-...
    • À moins que cela ne signifie que l’auteur ait déformé la situation, je ne vois pas quelle « très bonne raison » pourrait exister alors qu’il y a une trace claire montrant que quelqu’un a signalé le bug bien avant qu’il soit corrigé
      Au mieux, cela ressemble à de la lenteur bureaucratique classique, et ce n’est pas vraiment une bonne raison
      Si l’entreprise encourage réellement ce genre de choses, il n’y a aucune raison que l’approbation prenne plus d’un an
      Le raisonnement peut se tenir, mais face à une telle situation, il est difficile de considérer que « l’entreprise est pingre ou, comme dans presque tous les autres contextes, excessivement bureaucratique » est moins plausible que « il existe une raison légitime de ne pas verser une prime qui, en apparence, remplit les conditions »
      Si l’auteur a décrit l’affaire avec exactitude, il me semble bien plus plausible que les incitations à l’œuvre partout ailleurs se soient aussi infiltrées dans ce domaine
    • Avez-vous déjà signalé un problème de sécurité ou de confidentialité à Apple ? Moi oui. J’ai encore au moins un dossier ouvert chez Apple
      L’un d’eux pourrait être corrigé avec une ligne de code sans effet secondaire, mais il est ouvert depuis deux ans
      L’équipe sécurité d’Apple s’en moque ou est incompétente, et dans les deux cas ce n’est pas bon
      C’est l’une des expériences les plus rageantes et frustrantes que j’aie vécues en informatique
      Ils veulent clairement que le problème ne soit pas partagé publiquement, tout en le laissant traîner indéfiniment
      Franchement, j’approche de ma limite
      Je me fiche complètement de la prime, je veux juste que le bug soit corrigé
      Je leur laisserais autant de marge que possible si je pouvais croire qu’ils traitent le sujet sérieusement, mais c’est difficile à croire
    • Il y a eu beaucoup de cas documentés où de grands groupes tech ont tout simplement refusé de payer
      En changeant les règles de participation après coup, en excluant discrètement des chercheurs en sécurité d’un programme de primes en cours, en transmettant des divulgations de bonne foi aux autorités, ou avec des responsables faisant preuve d’une mesquinerie extrême
      Le fait que « les montants n’aient pas d’importance pour l’entreprise » rend justement cette gestion désastreuse encore plus difficile à comprendre

  • Encore une autre façon de manipuler le flag de quarantaine. L’autre est ce lien : https://imlzq.com/apple/macos/2024/08/24/Unveiling-Mac-Secur...
    On dirait qu’un trop grand nombre de systèmes différents peuvent modifier ce flag de quarantaine

  • « Un attaquant peut envoyer à la victime une invitation de calendrier malveillante contenant une pièce jointe… Avant le correctif, il était possible d’envoyer une invitation de calendrier malveillante à n’importe quel utilisateur d’Apple iCloud et de voler ses photos iCloud sans interaction de l’utilisateur. »
    Quelle est l’ampleur de ce périmètre ? Cela veut-il dire que, depuis n’importe où dans macOS, n’importe qui peut envoyer n’importe quelle invitation à toute personne utilisant iCloud ? Qui voudrait ça ?

    • Je ne veux pas être sarcastique, mais comment une invitation est-elle censée fonctionner autrement ?
    • Je ne comprends pas. En quoi recevoir une invitation de calendrier est-il différent de recevoir n’importe quel autre e-mail ? macOS traite-t-il automatiquement quelque chose, par conception, pour les invitations de calendrier ?
    • Google Calendar ne fait-il pas la même chose ?
    • Je ne pense pas que ce soit spécifique à iCloud. En général, les invitations sont automatiquement détectées dans les e-mails
      Les invitations de calendrier sont depuis longtemps une source de spam, donc ce n’est pas surprenant qu’il y ait aussi des vulnérabilités

  • « Si le fichier indiqué par l’attaquant existe déjà, le fichier indiqué est enregistré sous le nom PoC.txt-2. Mais si l’événement/la pièce jointe envoyé(e) par l’attaquant est supprimé(e) plus tard, le fichier portant le nom d’origine (PoC.txt) est supprimé. Cette vulnérabilité peut être utilisée pour supprimer des fichiers existants à l’intérieur du “sandbox” du système de fichiers. »
    C’est de la mauvaise ingénierie

  • Je n’aime pas trop la situation de la prime ici. Du point de vue des chercheurs en sécurité, est-il courant d’attendre aussi longtemps avec Apple ou d’autres entreprises du niveau FAANG ?

    • Tout à fait

  • La première étape à elle seule est une vulnérabilité absurde. Comment Apple a-t-elle pu ne pas envisager ça ?
    « L’attaquant peut définir un chemin arbitraire vers un fichier dans la section ATTACH, par exemple FILENAME=../../../PoC.txt, et réussir une attaque par traversée de répertoires. »

    • Cela illustre un problème plus large qui peut exister dans n’importe quelle entreprise. Quelqu’un chez Apple a sûrement écrit une fonction de bibliothèque qui gère ça de façon sûre, mais comment imposer son utilisation ?
      Surtout si le reviewer du code ne connaît pas non plus cette bibliothèque, il est difficile d’empêcher quelqu’un de réimplémenter le tout de manière non sûre
      Existe-t-il une solution moderne à ce genre de problème ?

  • Je suis étrangement content à chaque fois qu’une faille de sécurité majeure qui n’est pas liée à la sûreté mémoire apparaît
    Je sais que c’est un peu mesquin, mais j’aime l’idée que tout le temps et l’énergie investis dans Rust puissent au final être réduits à néant par un simple bug de traversée de chemin

  • Lockdown Mode bloque-t-il ça ?

    • Pure spéculation, mais j’espère que oui
      Quand on pense aux anciens exploits zero-click liés aux pièces jointes d’images, on dirait que Lockdown Mode a été conçu pour empêcher ce genre de choses, et j’imagine que tous les fichiers seraient traités de cette manière

  • Waouh. C’est un exploit assez old school
    Les chemins dans les noms de fichiers, je me souviens avoir lu des choses là-dessus il y a environ 10 ans