macOS : des chercheurs remplacent des apps téléchargées par des jumeaux malveillants - et Apple hausse les épaules

Des chercheurs démontrent qu'un attaquant local peut intercepter et remplacer une application macOS pendant son téléchargement, avant que Gatekeeper ait fini son travail. Apple, mise au courant, minimise. Détail d'une attaque « bête et méchante » qui met le doigt sur une zone grise du modèle de confiance macOS.

The Register publie ce 23 juillet 2026 les travaux de chercheurs qui décrivent une attaque locale sur macOS consistant à remplacer une application téléchargée par un « jumeau maléfique » - une copie signée par l'attaquant et déguisée en app légitime - avant que le système ait terminé sa vérification de sécurité. Réponse d'Apple : la firme n'y voit pas de vulnérabilité à corriger.

Faits

• Qui : chercheurs cités par The Register (nom de l'équipe et lien vers l'article ci-dessous). Publication de la démonstration le 2026-07-23.
• Quoi : lors d'un téléchargement d'application dans un dossier utilisateur (typiquement ~/Downloads), un processus tiers avec les droits utilisateur peut, sous certaines conditions, remplacer le fichier .app ou .dmg entre le moment où le téléchargement se termine et le moment où Gatekeeper / XProtect effectuent la vérification de signature au premier lancement. L'utilisateur croit alors lancer Firefox, Discord ou VS Code, et lance en réalité une app malveillante signée différemment mais visuellement identique.
• Pré-requis : l'attaquant a déjà une exécution locale avec les droits de l'utilisateur (pas de RCE distant magique). Ce point est central pour comprendre la réponse d'Apple.
• Réponse Apple : le Register rapporte qu'Apple, contactée, considère le scénario comme couvert par le modèle de menace standard - un processus qui a déjà les droits utilisateur peut, de toute façon, faire beaucoup de dégâts.

Analyse

Techniquement, Apple n'a pas tort au sens strict : dans le modèle de menace macOS, un binaire tournant avec les droits utilisateur a déjà accès à tout ce que l'utilisateur peut atteindre. La signature, Gatekeeper et Notarization protègent surtout contre le binaire téléchargé depuis le Web par un utilisateur non compromis, pas contre un attaquant qui exécute déjà localement.

Mais c'est aussi passer à côté d'une nuance importante. Le scénario réaliste, c'est l'app légèrement malveillante déjà installée - un utilitaire gratuit récupéré sur un site tiers, ou une extension de menu-bar - qui, en tâche de fond, guette les téléchargements de l'utilisateur et remplace ceux qui l'intéressent. L'attaquant élève ainsi sa persistance : au lieu de rester une petite app parasite, il devient « Firefox » ou « Slack » dans l'esprit de la victime, avec les habitudes d'usage qui vont avec (accès trousseau, permissions, comportement de démarrage). C'est une escalade de posture, pas une escalade de privilèges au sens Unix.

C'est exactement le type de scénario que le renseignement et les APT exploitent : ils ne cherchent pas la CVE spectaculaire, ils empilent des petites primitives « pas graves » jusqu'à ce que ça tienne. La position d'Apple - « pas de vulnérabilité » - est techniquement défendable, mais elle laisse durablement une primitive utilisable.

À faire maintenant

• Utilisateurs macOS : téléchargez vos apps depuis les sources primaires officielles (sites éditeurs, Mac App Store, Homebrew avec vérification de checksum) et lancez-les immédiatement, sans laisser traîner un .dmg monté ou un .app dans Downloads pendant des heures.
• Vérifiez la signature manuellement pour les installations sensibles : codesign -dv -verbose=4 /path/to/App.app et confrontez le Team Identifier annoncé à celui documenté par l'éditeur.
• Admins de flotte : durcissez la politique via MDM (Jamf, Kandji, Intune) pour restreindre les Team ID autorisés et interdire les binaires non notarisés - c'est le levier d'entreprise que l'utilisateur seul n'a pas.
• Suivi : nous suivrons cette histoire, notamment si des exploits publics ou des campagnes utilisant cette primitive émergent. À ce stade, il n'y a pas de PoC public d'exploitation en conditions réelles.

Sources primaires : à consulter dans The Register pour le détail technique et la timeline avec Apple.