jgoyd/ams-failopen
Zero-day dans AppleMediaServices : un échec de récupération du Bag désactive la signature Mescal/Absinthe. Les requêtes adressées aux services Apple sont envoyées sans signature, exposant à des risques de rétrogradation, de rejeu et de contournement. Inclut une analyse, des preuves issues des journaux et la logique d'attaque du PoC.
Résumé
Ce problème constitue une faille zero-day active et reflète un défaut de conception systémique dans AppleMediaServices.framework, plutôt qu'une régression ou un bug spécifique à une version.
Une faille critique de type fail-open dans le framework AppleMediaServices d'Apple permet de désactiver silencieusement la signature des requêtes si un fichier de configuration distant (le « Bag ») ne parvient pas à se charger. Cela affecte iOS, macOS, tvOS et watchOS.
Lorsque le Bag ne peut pas être récupéré — en raison d'une manipulation DNS, de dépassements de délai ou d'interférences réseau — les daemons AppleMediaServices désactivent la signature Mescal/Absinthe et envoient des requêtes non signées aux serveurs d'Apple. Ces requêtes ne comportent aucune protection d'intégrité et exposent les utilisateurs à des attaques par déclassement et par rejeu.
Preuve par journaux :
Découverte
Systèmes concernés
Toutes les plateformes Apple qui utilisent AppleMediaServices.framework sont concernées.
Les daemons impactés incluent :
Présentation de la vulnérabilité
Les appareils Apple récupèrent un Bag de configuration dynamique à partir du point de terminaison suivant :
https://bag.itunes.apple.com/bag.xml?deviceClass=...&format=json
Cette configuration inclut des indicateurs comme useAMSMescal, mescalURL et absintheURL, qui déterminent si les requêtes sortantes doivent être signées.
Si le Bag ne parvient pas à se charger, AppleMediaServices consigne l'échec, désactive la logique de signature et envoie des requêtes non signées. Il n'existe aucune validation de signature, aucun contrôle d'intégrité ni aucun mécanisme de repli imposé. Le Bag est non authentifié et non signé, ce qui rend l'état de sécurité vulnérable aux interférences réseau.
Preuve de concept
Conditions préalables :
Étapes de l'exploit :
Bloquez ou altérez l'accès au point de terminaison du Bag à l'aide de réponses DNS NXDOMAIN, de poignées de main TCP interrompues ou de réponses retardées.
Observez les journaux système indiquant que le Bag ne s'est pas chargé et que les signatures Mescal/Absinthe sont ignorées.
Déclenchez des composants système (par exemple, l'App Store, l'application Musique) pour qu'ils envoient des requêtes. Surveillez le trafic réseau et confirmez l'absence d'en-têtes de signature :
Résultat :
Le trafic non signé est transmis aux points de terminaison d'Apple sans vérification. Cela permet la manipulation, le rejeu et d'autres risques liés à l'intégrité.
Modèles de menace
bag.itunes.apple.comAMSBagManager via Frida ou un jailbreak pour remplacer les indicateurs de sécuritéRemédiation recommandée
Configuration signée Signez le Bag à l'aide de CMS, JWT ou HMAC et vérifiez les signatures côté client.
Défauts de sécurité par défaut (fail-secure) AppleMediaServices doit bloquer le trafic dépendant de la signature lorsque le Bag ne peut pas être récupéré ou validé.
Application côté serveur Les API backend d'Apple doivent rejeter les requêtes non signées qui exigent la protection Mescal ou Absinthe.
Cache validé Le contenu du Bag ne doit être mis en cache que s'il passe les contrôles d'intégrité et s'il respecte les contraintes d'expiration définies.
Justification de la sévérité
Les appareils Apple dépendent des requêtes signées pour établir la confiance — de l'App Store à la lecture multimédia. Si ces signatures disparaissent dès qu'un fichier de configuration ne peut pas se charger, les attaquants sur un réseau Wi-Fi peuvent dépouiller l'intégrité et injecter ou rejouer du trafic à l'insu de l'utilisateur. Une seule requête de Bag abandonnée suffit pour que les garanties de sécurité d'Apple échouent en mode fail-open.