iMessage Media Parser Zero-Click → CoreAudio RCE → PAC/RPAC → Kernel → CryptoTokenKit Abuse

Reading time: 7 minutes

Diese Seite fasst eine moderne iOS Zero-Click-Angriffsfläche und eine beobachtete End-to-End-Exploitation-Kette zusammen, die iMessage automatische Medienverarbeitung missbraucht, um CoreAudio zu kompromittieren, BlastDoor zu umgehen, Pointer Authentication (PAC) über einen RPAC-Pfad zu besiegen, auf den Kernel zu eskalieren und schließlich CryptoTokenKit für unautorisierte Schlüsselverwendungen zu missbrauchen.

Warnung: Dies ist eine pädagogische Zusammenfassung, um Verteidigern, Forschern und Red Teams die Techniken näherzubringen. Nicht offensiv verwenden.

Überblick der Kette

• Delivery vector: ein bösartiger Audioanhang (z. B. .amr / MP4 AAC), gesendet via iMessage/SMS.
• Auto-ingestion: iOS parst Medien automatisch für Vorschauen und Konvertierungen ohne Benutzerinteraktion.
• Parser bug: fehlerhafte Strukturen treffen CoreAudio’s AudioConverterService und korrumpieren Heap-Speicher.
• Code exec in media context: RCE innerhalb des Media-Parsing-Prozesses; berichtet wurde, dass bestimmte Pfade die BlastDoor-Isolierung umgehen (z. B. der “known sender” framing path).
• PAC/RPAC bypass: sobald beliebiges R/W erreicht ist, ermöglicht ein PAC-Bypass im RPAC-Pfad stabile Kontrolle des Control-Flows unter arm64e PAC.
• Kernel escalation: die Kette wandelt userland exec in kernel exec um (z. B. über wireless/AppleBCMWLAN Codepfade und AMPDU-Handling, wie in den Logs unten zu sehen).
• Post-exploitation: mit Kernel-Rechten CryptoTokenKit missbrauchen, um mit Secure Enclave–gestützten Schlüsseln zu signieren, sensible Datenpfade auszulesen (Keychain-Kontexte), Nachrichten/2FA abzufangen, Aktionen stillschweigend zu autorisieren und unbemerkte Überwachung (Mikrofon/Kamera/GPS) ohne Prompts zu ermöglichen.

iMessage/BlastDoor Angriffsflächen-Hinweise

BlastDoor ist ein gehärteter Dienst, der dafür konzipiert ist, untrusted message content zu parsen. Beobachtete Logs weisen jedoch auf Pfade hin, in denen Schutzmechanismen umgangen werden können, wenn Nachrichten von einem “known sender” gerahmt sind und zusätzliche Filter (z. B. Blackhole) gelockert werden:

IDSDaemon    BlastDoor: Disabled for framing messages
SpamFilter   Blackhole disabled; user has disabled filtering unknown senders.

Wesentliche Erkenntnisse:

• Auto-parsing stellt weiterhin eine remote, zero-click Angriffsfläche dar.
• Policy-/Kontext-Entscheidungen (bekannter Absender, Filterzustand) können die effektive Isolation wesentlich verändern.

CoreAudio: AudioConverterService Heap-Korruption (userland RCE)

Betroffene Komponente:

• CoreAudio → AudioConverterService → AAC/AMR/MP4 Parsing- und Konvertierungsabläufe

Beobachteter Parser-Kontaktpunkt (Protokolle):

AudioConverterService    ACMP4AACBaseDecoder.cpp: inMagicCookie=0x0, inMagicCookieByteSize=39

Technikübersicht:

• Fehlerhafte Container/Codec-Metadaten (z. B. ungültige/zu kurze/NULL magic cookie) verursachen eine memory corruption während des decode setup.
• Wird im iMessage media conversion path ausgelöst, ohne dass der Benutzer tippt.
• Ermöglicht code execution im media parsing process. Der Write-up behauptet, dass dies BlastDoor im beobachteten delivery path umgeht und die nächste Stufe ermöglicht.

Praktische Tipps:

• Fuzz AAC/AMR magic cookie und MP4 codec atoms, wenn AudioConverterService conversions das Ziel sind.
• Konzentriere dich auf heap overflows/underflows, OOB reads/writes und size/length confusion rund um die decoder initialization.

PAC bypass via RPAC path (CVE-2025-31201)

arm64e Pointer Authentication (PAC) erschwert das Hijacking von return addresses und function pointers. Die Kette berichtet, PAC mittels eines RPAC path zu überwinden, sobald arbitrary R/W verfügbar ist.

Kernidee:

• Mit arbitrary R/W können Angreifer gültige, neu-signierte pointers erstellen oder die Ausführung zu PAC-tolerant paths pivoten. Der sogenannte “RPAC path” ermöglicht control-flow unter PAC-Beschränkungen und verwandelt einen userland RCE in ein zuverlässiges kernel exploit setup.

Hinweise für Forscher:

• Sammle info leaks, um KASLR zu umgehen und ROP/JOP chains auch unter PAC zu stabilisieren.
• Ziele auf callsites, die PAC auf kontrollierbare Weise erzeugen oder authentifizieren (z. B. Signaturen, die auf attacker-controlled values generiert werden, vorhersehbare context keys oder gadget sequences, die pointers neu signieren).
• Erwarte Unterschiede im Apple hardening je nach SoC/OS; die Zuverlässigkeit hängt von leaks, Entropie und robusten primitives ab.

Kernel escalation: wireless/AMPDU path example

In der beobachteten Kette wurde, sobald man in userland mit memory corruption und einer PAC bypass primitive war, die Kernel-Kontrolle über Codepfade im Wi‑Fi-Stack (AppleBCMWLAN) unter fehlerhafter AMPDU-Verarbeitung erreicht. Beispiel-Logs:

IO80211ControllerMonitor::setAMPDUstat unhandled kAMPDUStat_ type 14
IO80211ControllerMonitor::setAMPDUstat unhandled kAMPDUStat_ type 13

Allgemeine Technik:

• Verwende userland primitives, um kernel R/W oder kontrollierte Aufrufpfade aufzubauen.
• Missbrauche erreichbare kernel surfaces (IOKit, networking/AMPDU, media shared memory, Mach interfaces), um kernel PC control oder arbitrary memory zu erlangen.
• Stabilisiere, indem du read/write primitives aufbaust und PPL/SPTM-Einschränkungen umgehst, wo anwendbar.

Post-exploitation: CryptoTokenKit and identity/signing abuse

Sobald der Kernel kompromittiert ist, können Prozesse wie identityservicesd nachgeahmt werden und privilegierte kryptografische Operationen über CryptoTokenKit ohne Benutzeraufforderungen ausgeführt werden. Beispiel-Logs:

CryptoTokenKit    operation:2 algo:algid:sign:ECDSA:digest-X962:SHA256
CryptoTokenKit    <sepk:p256(d) kid=9a86778f7163e305> parsed for identityservicesd

Impact:

• Use Secure Enclave–backed keys for unauthorized signing (tokens, messages, payments), breaking trust models even if keys are not exported.
• Intercept 2FA codes/messages silently; authorize payments/transfers; enable stealth mic/camera/GPS.

Defensive angle:

• Treat post-kernel integrity breaks as catastrophic: enforce runtime attestation for CTK consumers; minimize ambient authority; verify Entitlements at the point of use.

Reproduction and telemetry hints (lab only)

• Delivery: send a crafted AMR/MP4-AAC audio to the target device via iMessage/SMS.
• Observe telemetry for the foregoing log lines around parsing and wireless stack reactions.
• Ensure devices are fully patched; only test in isolated lab setups.

Mitigations and hardening ideas

• Patch level: iOS 18.4.1 reportedly fixes this chain; keep devices up to date.
• Parser hardening: strict validation for codec cookies/atoms and lengths; defensive decoding paths with bounds checks.
• iMessage isolation: avoid relaxing BlastDoor/Blackhole in “known sender” contexts for media parsing.
• PAC hardening: reduce PAC-gadget availability; ensure signatures are bound to unpredictable contexts; remove PAC-tolerant bypassable patterns.
• CryptoTokenKit: require post-kernel attestation and strong Entitlements at call-time for key-bound operations.
• Kernel surfaces: harden wireless AMPDU/status handling; minimize attacker-controlled inputs from userland after compromise.

Affected versions (as reported)

• iOS 18.x prior to iOS 18.4.1 (April 16, 2025).
• Primary: CoreAudio → AudioConverterService (media auto-parsing path via iMessage/SMS).
• Chained: PAC/RPAC path and kernel escalation via AppleBCMWLAN AMPDU handling.

References

• iOS Crypto Heist repo (README)
• Remote Crypto Attack Chain details