jgoyd/ams-failopenZero-Day in AppleMediaServices: Fehler beim Bag-Abruf deaktiviert die Mescal/Absinthe-Signierung. Anfragen an Apple-Dienste werden unsigniert übertragen, wodurch Downgrade-, Replay- und Bypass-Risiken entstehen. Enthält Analyse, Log-Nachweise und PoC-Angriffslogik.
Zusammenfassung
Bei diesem Problem handelt es sich um eine aktive Zero-Day-Schwachstelle, die einen systemischen Designfehler in AppleMediaServices.framework widerspiegelt und nicht eine Regression oder einen versionsspezifischen Fehler.
Ein kritischer Fail-Open-Fehler im AppleMediaServices-Framework von Apple ermöglicht es, die Signierung von Anfragen stillschweigend zu deaktivieren, wenn eine entfernte Konfigurationsdatei (das "Bag") nicht geladen werden kann. Dies betrifft iOS, macOS, tvOS und watchOS.
Wenn das Bag nicht abgerufen werden kann – aufgrund von DNS-Manipulation, Timeouts oder Netzwerkstörungen – deaktivieren AppleMediaServices-Daemons die Mescal/Absinthe-Signierung und senden unsignierte Anfragen an Apple-Server. Diese Anfragen entbehren Integritätsschutz und setzen Benutzer Downgrade- und Replay-Angriffen aus.
Log-Nachweise:
Entdeckung
Betroffene Systeme
Alle Apple-Plattformen, die AppleMediaServices.framework verwenden, sind betroffen.
Zu den betroffenen Daemons gehören:
Übersicht über die Schwachstelle
Apple-Geräte rufen ein dynamisches Konfigurations-Bag vom folgenden Endpunkt ab:
https://bag.itunes.apple.com/bag.xml?deviceClass=...&format=json
Diese Konfiguration enthält Flags wie useAMSMescal, mescalURL und absintheURL, die festlegen, ob ausgehende Anfragen signiert werden müssen.
Wenn das Bag nicht geladen werden kann, protokolliert AppleMediaServices den Fehler, deaktiviert die Signierungslogik und sendet unsignierte Anfragen. Es gibt keine Signaturvalidierung, Integritätsprüfung oder erzwungenen Fallback-Mechanismus. Das Bag ist nicht authentifiziert und nicht signiert, wodurch der Sicherheitszustand anfällig für Netzwerkstörungen ist.
Proof of Concept
Voraussetzungen:
Exploit-Schritte:
Blockieren oder manipulieren Sie den Zugriff auf den Bag-Endpunkt mithilfe von DNS-NXDOMAIN-Antworten, verworfenen TCP-Handshakes oder verzögerten Antworten.
Beobachten Sie Systemprotokolle, die anzeigen, dass das Bag nicht geladen werden konnte und Mescal/Absinthe-Signaturen übersprungen werden.
Lösen Sie Systemkomponenten (z. B. App Store, Musik-App) aus, um Anfragen zu senden. Überwachen Sie den Netzwerkverkehr und bestätigen Sie das Fehlen von Signatur-Headern:
Ergebnis:
Unsignierter Datenverkehr wird ohne Überprüfung an Apple-Endpunkte übertragen. Dies ermöglicht Manipulation, Replay und andere Integritätsrisiken.
Bedrohungsmodelle
bag.itunes.apple.com blockiertAMSBagManager, um Sicherheitsflags zu überschreibenEmpfohlene Abhilfemaßnahmen
Signierte Konfiguration Signieren Sie das Bag mit CMS, JWT oder HMAC und verifizieren Sie Signaturen clientseitig.
Fail-Secure-Standardeinstellungen AppleMediaServices sollte signierungsabhängigen Datenverkehr blockieren, wenn das Bag nicht abgerufen oder validiert werden kann.
Serverseitige Erzwingung Die Backend-APIs von Apple sollten unsignierte Anfragen ablehnen, die Mescal- oder Absinthe-Schutz erfordern.
Validiertes Caching Bag-Inhalte sollten nur zwischengespeichert werden, wenn sie Integritätsprüfungen bestehen und innerhalb definierter Ablaufbeschränkungen liegen.
Begründung des Schweregrads
Apple-Geräte verlassen sich für Vertrauen auf signierte Anfragen – vom App Store bis zur Medienwiedergabe. Wenn diese Signaturen verschwinden, sobald eine Konfigurationsdatei nicht geladen werden kann, können Angreifer in einem Wi-Fi-Netzwerk die Integrität entfernen und Datenverkehr einschleusen oder erneut abspielen, ohne dass der Benutzer es merkt. Eine einzige verworfene Bag-Anfrage bedeutet, dass Apples Sicherheitsgarantien im Fail-Open-Modus versagen.