Operation Triangulation: Was man bekommt, wenn man die iPhones von Forschern angreift

 (securelist.com)
1 Punkte von GN⁺ 2023-12-28 | 1 Kommentare | Auf WhatsApp teilen
  • Kaspersky-Forschende stellten auf dem 37C3 die iPhone-0-Click-iMessage-Angriffskette von Operation Triangulation vor und bewerten sie als die bislang ausgefeilteste Kette, die sie gesehen haben
  • Der Angriff war darauf ausgelegt, bis iOS 16.2 zu funktionieren, und verknüpfte vier Zero-Days zu Remote Code Execution, Privilege Escalation, PPL-Bypass und der Ausführung einer Safari-Stufe
  • Das zentrale Rätsel ist der durch CVE-2023-38606 entschärfte Abschnitt: Die Angreifer nutzten unbekannte MMIO-Register der Apple A12–A16 Bionic SoCs, um hardwarebasierten Kernel-Speicherschutz zu umgehen
  • Analysen deuten darauf hin, dass diese Register mit dem GPU-Coprozessor zusammenhängen; einige werden weder im DeviceTree noch in Firmware referenziert, weshalb unklar bleibt, wie die Angreifer ihre Nutzung kannten
  • In einem Update vom 9. Januar 2024 stellte sich heraus, dass der zunächst wie ein „Custom Hash“ wirkende Wert ein ECC auf Basis eines Hamming-Codes ist; die Funktion dürfte eher eine Debugging-Funktion sein, die direkt auf Caches statt auf Speicher zugreift

Veröffentlichte Angriffskette

  • Am 27. Dezember 2023 wurden auf dem 37C3 die Ergebnisse einer Langzeitanalyse von Operation Triangulation veröffentlicht
  • In diesem Vortrag wurden erstmals Details zu den im Angriff verwendeten Exploits und Schwachstellen offengelegt
  • Die Forschenden haben mehr als 30 in freier Wildbahn ausgenutzte Zero-Days in Produkten von Adobe, Apple, Google und Microsoft entdeckt und gemeldet, bewerten diese Angriffskette aber selbst darunter als eine der anspruchsvollsten

Vom iMessage-0-Click bis zum Laden von Spyware

  • Die Angreifer senden einen schädlichen iMessage-Anhang, den die Anwendung verarbeitet, ohne ihn dem Nutzer anzuzeigen
  • Der Anhang nutzt CVE-2023-41990 aus, eine Remote-Code-Execution-Schwachstelle in Apples proprietärem, undokumentiertem ADJUST-TrueType-Font-Befehl
    • Dieser Befehl existierte seit den frühen 1990er-Jahren und wurde durch den Patch entfernt
  • Danach folgen mehrere Stufen, die mit Return-/Jump-Oriented Programming und der Abfragesprache NSExpression/NSPredicate geschrieben sind
    • Sie patchen die JavaScriptCore-Umgebung, um einen in JavaScript geschriebenen Privilege-Escalation-Exploit auszuführen
  • Der JavaScript-Exploit wurde zur Größenreduzierung und zur vollständigen Unlesbarmachung obfuskiert, umfasst aber etwa 11.000 Zeilen
    • Der Großteil davon dient dem Parsen und Manipulieren von JavaScriptCore- und Kernel-Speicher
  • Die JavaScriptCore-Debugging-Funktion DollarVM($vm) wird missbraucht, um aus dem Skript heraus JavaScriptCore-Speicher zu manipulieren und native API-Funktionen auszuführen
  • Die Kette ist darauf ausgelegt, sowohl ältere als auch neuere iPhones zu unterstützen, und enthält auch einen PAC-Bypass für das Ausnutzen aktueller Modelle

Kernel-Speicherzugriff und PPL-Bypass

  • Der Exploit nutzt die Integer-Overflow-Schwachstelle CVE-2023-32434 in den XNU-Speicher-Mapping-Syscalls mach_make_memory_entry und vm_map
    • Dadurch erhält er auf User-Ebene Lese-/Schreibzugriff auf den gesamten physischen Speicher des Geräts
  • Anschließend umgeht er über Hardware-MMIO-Register den Page Protection Layer (PPL)
  • Nach Ausnutzung aller Schwachstellen konnte der JavaScript-Exploit beliebige Aktionen auf dem Gerät ausführen
    • Die Angreifer starten den IMAgent-Prozess und injizieren Payloads, um Spuren des Exploits zu löschen
    • Sie starten den Safari-Prozess in einem unsichtbaren Modus und leiten ihn auf die Webseite der nächsten Stufe weiter
  • Die Webseite überprüft das Opfer und liefert, wenn die Bedingungen erfüllt sind, den Safari-Exploit aus
  • Der Safari-Exploit nutzt CVE-2023-32435, um Shellcode auszuführen
  • Der Shellcode führt einen weiteren Kernel-Exploit in Form einer Mach-Object-Datei aus
    • Auch dieser Exploit nutzt CVE-2023-32434 und CVE-2023-38606
    • Er unterscheidet sich größtenteils vom JavaScript-Kernel-Exploit, teilt aber einige Codeabschnitte zur Ausnutzung derselben Schwachstellen
  • Am Ende werden Root-Rechte erlangt und weitere Stufen ausgeführt, um die Spyware zu laden

Das Hardware-Rätsel von CVE-2023-38606

  • Aktuelle iPhone-Modelle verfügen über hardwarebasierte Schutzfunktionen für sensible Kernel-Speicherbereiche
  • Dieser Schutz soll verhindern, dass Angreifer selbst mit Lese-/Schreibzugriff auf Kernel-Speicher die vollständige Kontrolle über das Gerät erlangen
  • Die Angreifer von Operation Triangulation nutzten eine weitere Hardware-Funktion der von Apple entwickelten SoCs, um diesen Schutz zu umgehen
  • Das beobachtete Verhalten sieht so aus:
    • Daten, Zieladresse und Daten-Hash werden in unbekannte Hardware-Register des Chips geschrieben
    • Diese Register scheinen in der Firmware nicht verwendet zu werden
    • Dadurch können Daten an bestimmte physische Adressen geschrieben und der hardwarebasierte Speicherschutz umgangen werden
  • Diese Funktion könnte eine Debugging-Funktion für Apple-Ingenieure oder Werkstests gewesen oder versehentlich enthalten gewesen sein
  • Da die Funktion in der Firmware nicht genutzt wird, bleibt unklar, wie die Angreifer ihre Verwendung kannten

MMIO- und DeviceTree-Analyse

  • Peripheriegeräte eines SoC können spezielle Hardware-Register bereitstellen, über die die CPU das Gerät steuern kann
  • Diese Register werden in für die CPU zugänglichen Speicher gemappt und als memory-mapped I/O (MMIO) bezeichnet
  • Die MMIO-Adressbereiche von Peripheriegeräten in Apple-Produkten werden im Format DeviceTree gespeichert
    • DeviceTree-Dateien lassen sich aus der Firmware extrahieren
    • Mit dem Tool dt kann man ihren Inhalt anzeigen
  • Die meisten vom Angreifer für den PPL-Bypass genutzten MMIO-Adressen gehörten zu keinem der im DeviceTree definierten MMIO-Bereiche
  • Der Exploit zielt auf Apple-A12–A16 Bionic SoCs und nutzt die folgenden unbekannten MMIO-Blöcke:
    • 0x206040000
    • 0x206140000
    • 0x206150000
  • In DeviceTrees mehrerer Geräte und Firmware-Versionen, öffentlichem Source Code, Kernel-Images, Kernel Extensions, iBoot und Coprozessor-Firmware wurden keine Referenzen auf diese Adressen gefunden

Zusammenhang mit dem GPU-Coprozessor

  • Beim Prüfen bekannter MMIO-Adressen in der Umgebung lagen die unbekannten Adressen nahe bei gfx-asc, also dem GPU-Coprozessor
  • gfx-asc hat zwei MMIO-Bereiche:
    • 0x206400000–0x20646C000
    • 0x206050000–0x206050008
  • Die vom Exploit tatsächlich verwendeten unbekannten Adressen sind:
    • 0x206040000
    • 0x206140008
    • 0x206140108
    • 0x206150020
    • 0x206150040
    • 0x206150048
  • Die meisten liegen zwischen den beiden gfx-asc-Bereichen, eine weitere nahe am Anfang des ersten gfx-asc-Bereichs
  • Es wird daher als sehr wahrscheinlich eingeschätzt, dass diese Register zum GPU-Coprozessor gehören
  • In der Initialisierung des Exploits wurde außerdem Code gefunden, der SoC-spezifische GFX-Power-Manager-Register an anderen Adressen manipuliert
    • Mit dem Tool pmgr wurde bestätigt, dass diese Adressen GFX-Registern im MMIO-Bereich des Power Managers entsprechen
  • Beim Zugriff auf Register in dem unbekannten Bereich löste der GPU-Coprozessor eine Panic mit der Meldung „GFX SERROR Exception“ aus
    • Auch dieses Ergebnis stützt die Einschätzung, dass die Register zum GPU-Coprozessor gehören

CoreSight und Apples eigener UTT-Bereich

  • Das Register 0x206040000 wird nur in der Initialisierungs- und Beendigungsphase des Exploits verwendet
    • Es wird in der Initialisierung als Erstes gesetzt und in der Beendigung als Letztes verarbeitet
  • Analysiert wurde dieses Register als zuständig für das Ein- und Ausschalten einer Hardware-Funktion oder die Steuerung von Interrupts
  • Das Verhalten des Exploits entspricht der Funktion ml_dbgwrap_halt_cpu in der XNU-Quelldatei dbgwrap.c
  • dbgwrap.c ist Code zur Behandlung der ARM-CoreSight-MMIO-Debug-Register der Haupt-CPU
  • Der XNU-Quellcode erwähnt vier CoreSight-bezogene MMIO-Bereiche: ED, CTI, PMU und UTT
    • Jeder Bereich belegt 0x10000 Byte
    • Die vier Bereiche liegen direkt nebeneinander
  • Im Quellcode steht, dass der UTT-Bereich nicht von ARM stammt, sondern eine von Apple aus Bequemlichkeitsgründen hinzugefügte proprietäre Funktion ist
  • Schreibt man ARM_DBG_LOCK_ACCESS_KEY an die entsprechende Stelle, lässt sich bestätigen, dass 0x206000000–0x206050000 der CoreSight-MMIO-Debug-Registerblock des GPU-Coprozessors ist
  • Auch jeder Kern der Haupt-CPU besitzt einen eigenen CoreSight-MMIO-Debug-Registerblock, dessen Adresse jedoch im Gegensatz zum GPU-Coprozessor im DeviceTree zu finden ist
  • Der Exploit-Autor wusste auch, wie man über Apples proprietären UTT-Bereich einen CPU-Halt aufhebt
    • Dieser Code ist nicht im XNU-Quellcode enthalten

Ungeklärte Funktion mit DMA-ähnlichem Verhalten

  • Die Register 0x206140008 und 0x206140108 steuern das Aktivieren, Deaktivieren und Ausführen der vom Exploit genutzten Hardware-Funktion
  • 0x206150020 wird nur auf Apple A15/A16 Bionic SoCs verwendet
    • In der Initialisierungsphase wird es auf 1 gesetzt und in der Beendigungsphase auf seinen ursprünglichen Wert zurückgesetzt
  • 0x206150040 wird verwendet, um Flags und die untere Hälfte der physischen Zieladresse zu speichern
  • 0x206150048 dient dazu, die zu schreibenden Daten, die obere Hälfte der physischen Zieladresse, den Daten-Hash und einen weiteren Wert gemeinsam zu speichern
    • Die Hardware-Funktion schreibt Daten in ausgerichteten 0x40-Byte-Blöcken
    • Für das Register 0x206150048 sind neun aufeinanderfolgende Schreibvorgänge erforderlich
  • Wenn alle Schritte korrekt ausgeführt werden, führt die Hardware eine DMA-Operation aus und schreibt die Daten an die angeforderte Stelle
  • Der Exploit nutzt diese Funktion für den PPL-Bypass, hauptsächlich durch das Patchen von Page-Table-Entries
  • Sie kann auch zum Patchen von Daten im geschützten Segment __PPLDATA verwendet werden
  • Für Kernel-Code-Patches wurde diese Funktion nicht verwendet
    • In einem Test wurde einmal eine Kernel-Instruktion im Segment __TEXT_EXEC überschrieben, was an der erwarteten Adresse und mit dem erwarteten Wert zu einer Panic „Undefined Kernel Instruction“ führte
    • In anderen Versuchen kam es zu AMCC-Panics

Hash, ECC und möglicher Cache-Zugriff

  • In der ersten Analyse schien diese Funktion einen benutzerdefinierten Hash zu verlangen
    • Der Hash wurde mithilfe einer vordefinierten sbox-Tabelle berechnet
    • In einer großen Sammlung von Binärdateien wurde nach dieser Tabelle gesucht, sie wurde jedoch nicht gefunden
  • Der Hash wirkte wie 20 Bit, also zwei Berechnungen eines 10-Bit-Werts
  • Wenn Angreifer die Berechnung und Nutzung nicht kennen, ähnelt diese Struktur stark security by obscurity
  • In einem Update vom 9. Januar 2024 bestätigte Hector Martin, dass dieser Wert kein einfacher Custom Hash ist, sondern ein Fehlerkorrekturcode (ECC)
    • Genauer gesagt handelt es sich um einen Hamming-Code mit einer benutzerdefinierten Lookup Table
  • Diese Entdeckung liefert einen Hinweis auf den ursprünglichen Zweck der unbekannten Hardware-Funktion
    • Zunächst wirkte sie wie eine Debugging-Funktion mit direktem Speicherzugriff, an die ein „Dummy“-Hash angehängt war
    • Da ECC verwendet wird und beim Patchen von Kernel-Code instabiles Verhalten beobachtet wurde, ist es wahrscheinlicher, dass diese Funktion direkt auf den Cache zugreift

M1-Experiment und Abschwächung in iOS 16.6

  • Es wurde bestätigt, dass auch der M1-Chip im Mac über diese unbekannte Hardware-Funktion verfügt
  • Mit der trace_range-Funktion des Tools m1n1 wurden MMIO-Zugriffe im Bereich 0x206110000–0x206400000 nachverfolgt
    • Es wurden keine Hinweise berichtet, dass macOS diese Register nutzt
  • In iOS 16.6 entschärfte Apple die Schwachstelle, indem die vom Exploit genutzten MMIO-Bereiche zu pmap-io-ranges im DeviceTree hinzugefügt wurden
    • Die hinzugefügten Bereiche sind 0x206000000–0x206050000 und 0x206110000–0x206400000
  • XNU nutzt die Informationen aus pmap-io-ranges, um zu entscheiden, ob das Mapping bestimmter physischer Adressen erlaubt wird
  • Übliche pmap-io-ranges-Einträge tragen aussagekräftige Tag-Namen wie PCIe, DART oder DAPF; die Tag-Namen der Bereiche im Zusammenhang mit dieser Schwachstelle fielen jedoch im Vergleich zu den anderen Einträgen deutlich auf

Offene Fragen und Sicherheitsimplikationen

  • Wie die Angreifer die Verwendung dieser unbekannten Hardware-Funktion kannten, ist nicht geklärt
  • Auch der ursprüngliche Zweck der Funktion ist weiterhin unklar
    • Es ist nicht bekannt, ob es sich um eine von Apple entwickelte Funktion oder um eine Drittanbieter-Komponente wie ARM CoreSight handelt
  • Auch nach dem Update bleiben Rätsel offen
    • Angreifer könnten die Werte der benutzerdefinierten Lookup Table allein durch Experimente per Brute Force ermitteln
    • Sie müssten aber die Existenz einer mächtigen Cache-Debugging-Funktion, die Verwendung eines Hamming-Codes, Position und Zweck der zugehörigen MMIO-Register sowie die Reihenfolge der Interaktionen kennen
  • Selbst hardwarebasierter Schutz kann gegenüber hochentwickelten Angreifern wirkungslos werden, wenn Hardware-Funktionen existieren, mit denen er umgangen werden kann
  • Hardware-Sicherheit ist deutlich schwieriger zu reverse-engineeren als Software, doch Systeme, die auf „security through obscurity“ setzen, sind nicht mehr sicher, sobald ihre Geheimnisse offenliegen

Verwandte Beiträge

1 Kommentare

 
GN⁺ 2023-12-28
Hacker-News-Kommentare

  • Das Video des Vortrags ist inzwischen ebenfalls online: https://www.youtube.com/watch?v=7VWNUUldBEE

  • Ziemlich erstaunlicher Inhalt. MMIO-Missbrauch bedeutet entweder, dass die Angreifer wirklich enorme Forschungskapazitäten hatten, oder dass sie Apple gehackt und interne Hardware-Dokumentation erbeutet haben; Letzteres wirkt plausibler.
    Bis zum Auftauchen der S-Box der Custom-Hash-Funktion hätte ich gedacht, dass ein großes Forschungsteam auf NSA-Niveau das vielleicht schaffen könnte, aber ab diesem Punkt sieht es so aus, als habe Apple gewusst, dass diese Funktion gefährlich ist, sie absichtlich versteckt und sie – was auch immer sie genau ist – zusätzlich mit einer Art schwacher digitaler Signatur geschützt.
    Wie der Blogpost hervorhebt, gibt es außer dem Zerlegen und Reverse Engineering des gesamten Siliziums keinen offensichtlichen Weg, den richtigen „magischen Klopfcode“ zu finden, der diese Funktion auslöst. Bei solchen Prozessknoten ist das praktisch unrealistisch; übrig bleibt also die Variante, dass Entwickler gehackt und interne Dokumente gestohlen wurden.
    Auch die Methode, mit einer langen, teuren Zero-Day-Chain ein unsichtbares Safari zu starten und dann über eine Webseite mit einer völlig anderen Exploit-Chain das Gerät erneut zu hacken, riecht nach einer riesigen Organisation mit gravierenden internen Silos.
    Wenn man bedenkt, dass die Forschenden von Kaspersky Russen sind, ist das sehr wahrscheinlich NSA oder vielleicht GCHQ.
    Weitere interessante Punkte aus dem Vortrag: Die Malware kann Werbe-Tracking aktivieren und auch Cloud-iPhone-Hosting erkennen, wie es Sicherheitsforscher häufig nutzen. Die iOS/macOS-Malware-Plattform scheint seit über 10 Jahren entwickelt worden zu sein; sie führt sogar Machine Learning auf dem Gerät aus, mit Objekterkennung und OCR, um keine Fotobytes hochladen zu müssen, und lädt nur die erzeugten Labels hoch. Es wurde wirklich viel Aufwand betrieben, aber am Ende reichte es gegen kluge russische Studierende nicht aus.
    Allerdings stimme ich der Aussage des Vortragenden „Security through obscurity funktioniert nicht“ nicht vollständig zu. Diese Plattform war 10 Jahre lang in realen Umgebungen aktiv, und niemand weiß, wie lange sie diese versteckte Hardware-„Funktion“ ausgenutzt hat. Wäre diese Hardware-Funktion öffentlich dokumentiert gewesen, wäre sie viel, viel früher entdeckt worden.

    • Der Punkt „Wäre diese Hardware-Funktion öffentlich dokumentiert gewesen, wäre sie viel früher entdeckt worden“ bedeutet nach Kerckhoffs’ Prinzip, dass sie von Anfang an öffentlich dokumentiert hätte sein müssen und dass jeder, der die Dokumentation vor der Auslieferung gesehen hätte, hätte sagen müssen: „So darf das nicht veröffentlicht werden, diese Funktion muss raus.“
    • Es gibt auch ein IoC-Skript, mit dem sich Indikatoren für eine Kompromittierung durch Operation Triangulation in iTunes-Backups scannen lassen: https://github.com/KasperskyLab/triangle_check
    • Ein wirklich beeindruckender Angriff, und ich stimme der obigen Analyse zu. Der Teil, bei dem das Gerät über einen versteckten Safari-Tab „erneut gehackt“ wird, könnte wie gesagt das schlechte Ergebnis interner organisatorischer Silos sein, erinnert aber auch an den „Virusbaukasten“-Ansatz von Script Kiddies aus den 90ern.
      Es könnte ein modulares Design zur schnellen Anpassung sein, also möglicherweise auch eine weniger stark zielgerichtete Struktur.
    • Oder Apple hat diese „API“ einfach implementiert, nachdem sie höflich darum gebeten hatten.
    • In diesem Thread gibt es viel zu viele Fehlinformationen. Das ist Hamming ECC, wie hier[1] beschrieben.
      [1] https://social.treehouse.systems/@marcan/111655847458820583

  • Steve Weis hat es auf Twitter am besten zusammengefasst:
    „Dieser iMessage-Exploit ist verrückt. Er enthält eine TrueType-Schwachstelle, die seit den 90ern existiert, zwei Kernel-Exploits, einen Browser-Exploit und sogar eine undokumentierte Hardware-Funktion, die in ausgelieferter Software nicht verwendet wurde.“
    https://x.com/sweis/status/1740092722487361809?s=46&t=E3U2EI...

  • Falls ihr euch für den Vortrag der Kaspersky-Forschenden interessiert: Ein geschnittenes Video ist noch nicht online, aber die Streaming-Aufzeichnung gibt es hier:
    https://streaming.media.ccc.de/37c3/relive/a91c6e01-49cf-422...
    Der Vortrag beginnt bei 26:20.

  • Zu dem 37c3-Vortrag gibt es auch einen deutschsprachigen Beitrag von Fefe¹: https://blog.fefe.de/?ts=9b729398
    Ihm zufolge lag der Wert dieser Exploit-Chain wahrscheinlich im achtstelligen Dollarbereich.
    ¹ https://en.wikipedia.org/wiki/Felix_von_Leitner
    Da wird wohl jemand gefeuert werden.

    • Warum? Dass Exploits „verbrannt“ werden, gehört zu diesem Geschäft dazu.

  • Coresight ist keine Backdoor, sondern eine Debug-Funktion, die es in allen ARM-CPUs gibt. Das hier sieht nach einer Coresight-Erweiterung aus, die nötig ist, um mit Apples Speicherschutzfunktionen zusammenzuarbeiten.
    Auch wenn es keine öffentliche Dokumentation gibt, dürften Tausende Apple-Ingenieure Zugriff auf ein angepasstes gdb oder andere Tools haben, die sie nutzen können.

    • Für die einen ist es ein Debug-Tool, für die anderen eine Backdoor.
    • Trotzdem erklärt das nicht das seltsame Hashing.

  • Bei verwalteten Geräten lässt sich iMessage deaktivieren, indem man über den kostenlosen Apple Configurator aus dem macOS App Store ein lokales MDM verwendet: https://support.apple.com/guide/deployment/restrictions-for-...
    Auf reinen Wi-Fi-Geräten wird die Messages-App ausgeblendet.
    Auf Geräten mit Wi-Fi und Mobilfunk bleibt die Messages-App sichtbar, aber es sind nur SMS/MMS-Dienste nutzbar.
    Wenn man ein Gerät zum Beispiel längere Zeit nur per Wi-Fi nutzt, kann man per SIM-PIN SMS/MMS-Nachrichten und nicht notfallbezogenen Mobilfunkverkehr deaktivieren.

    • Ich hatte ein Cellular-iPad gekauft, eine SIM-Karte aus meinem Heimatland eingelegt und wollte weiter SMS empfangen, weil die Banken dort beim Login immer noch SMS-Authentifizierung verlangen.
      Dann stellte ich aber fest, dass ein Cellular-iPad praktisch keine SMS anzeigt, die nicht vom Mobilfunkanbieter der SIM-Karte gesendet wurden.

  • Auffällig ist, dass der Hashwert eines Schreibvorgangs mit ausschließlich Nullen ebenfalls 0 ist.
    Und bei einem einzelnen Bit wird der Hashwert zu einem einzelnen Wert aus der S-Box-Tabelle. Das heißt, dieser Hash-Algorithmus hätte sich wahrscheinlich auch ohne interne Dokumente ausreichend reverse engineeren lassen.

    • Das riecht nach einer typischen Methode, um zu verhindern, dass Speicher-Schreibzugriffe auf zufällige Adressen diese Hardware versehentlich auslösen. Es wirkt nicht so, als sei das als Sicherheitsfunktion gedacht gewesen.
      Wenn tatsächlich jemand gesagt hätte, dass durch einen Bug keine beliebigen Schreibzugriffe passieren dürfen, hätte ich es genau so implementiert. Diese Implementierung verhindert auch effektiv, dass man die Funktion nutzt, wenn man zwar die Pufferadresse kennt, aber nicht dessen Inhalt.
      Wenn das System bei jedem falschen Hashwert neu startet, reichen 10 Bit Sicherheit für diesen Zweck vermutlich aus. Die Coresight-Debug-Funktion kann das System bei Bedarf vollständig neu starten.

  • Wie wahrscheinlich ist es, dass dieses MMIO-Register durch Brute-Force-Suche über alle Registeradressen entdeckt wurde?
    Schon ein Timing-Unterschied könnte verraten haben, dass die betreffende Adresse gültig ist, und da der Hash effektiv nur ein 20-Bit-Hash ist, war auch er vielleicht per Brute Force zu knacken.

    • Das Register scheint per Brute Force recht leicht identifizierbar gewesen zu sein. Es liegt physisch in der Nähe dokumentierter GPU-Register, und ein Zugriff darauf löst eine GPU-Panic aus, weshalb auch die Forscher es einer GPU-Komponente zugeordnet haben. Angreifer hätten mit denselben Tests die Existenz des Registers feststellen können.
      Weniger leicht zu erklären ist, wie die Custom-S-Box-Tabelle wiederhergestellt wurde, um Debug-Code auszuführen. Hier ist die Andeutung einer Insider-Bedrohung am stärksten, aber persönlich finde ich nicht, dass damit andere plausible Erklärungen ausgeschlossen sind.
      Beispielsweise könnten Angreifer die S-Box aus älterer Firmware, OTA-Update-Patches, vorab veröffentlichten Entwicklungsgeräten (die zu irgendeinem Zeitpunkt mit hoher Wahrscheinlichkeit auf eBay zu kaufen waren), iOS-Beta-Releases oder zahlreichen anderen Leckquellen extrahiert haben.
      Der Forscher sagt im Wesentlichen: „In keinem anderen Binary, das ich durchsucht habe, habe ich diese S-Box-Tabelle gefunden.“ Angesichts der Tatsache, dass sie Apple-spezifisch wirkt und daher nur in einer begrenzten Zahl von Binaries aufgetaucht sein dürfte, ist das aber nicht unbedingt überraschend. Wie der Forscher ebenfalls sagt, schließt das auch Binaries ein, die heute nicht öffentlich sind, aber versehentlich verteilt worden sein könnten. Es ist durchaus plausibel, dass Angreifer systematisch nach solchen Leaks gesucht haben und irgendwann Glück hatten, während der Forscher dieses Glück nicht so bald wiederholen kann.
    • Wenn man sich diese S-Box-Implementierung ansieht, fällt es schwer zu glauben, dass sie in der Chip-Hardware als Lookup-Tabelle implementiert wurde. Es dürfte einen kompakteren booleschen Ausdruck geben, der dasselbe Ergebnis liefert.
      Dass die Angreifer diesen booleschen Ausdruck offenbar nicht kannten, deutet eher auf Reverse Engineering hin als darauf, dass sie Dokumentation besaßen.

  • https://streaming.media.ccc.de/37c3/relive/11859

    • Beginnt bei 27:21.
      Zusammen mit den Inhalten des Vortrags ergibt sich chronologisch etwa Folgendes:
      September 2018: Veröffentlichung des Apple A12 Bionic SoC, der ersten CPU mit undokumentiertem MMIO.
      Dezember 2021: Die Infrastruktur der frühen Exploit-Chain wurde angelegt: backuprabbit.com am 2021-12-15T18:33:19Z, cloudsponcer.com am 2021-12-17T16:33:50Z.
      April 2022: Die spätere Exploit-Chain-Infrastruktur snoweeanalytics.com wurde am 2022-04-20T15:09:17Z angelegt, was nahelegt, dass der Exploit bis zu diesem Datum weaponisiert war.
      Dezember 2023: Das scheint ungefähr der Zeitpunkt der Entdeckung zu sein, rückgerechnet aus der „halbes Jahr“-Analysezeit und Apples Bericht von Mitte 2023.
      Die Vortragenden sagen, Spuren im Code deuteten darauf hin, dass die ursprüngliche APT-Gruppe dieselbe Angriffscodebasis seit „10 Jahren“ nutzte, also etwa seit 2013, und sie auch für Angriffe auf macOS-Laptops einsetzt. Auch Antivirus-Umgehung ist enthalten.
      Die Vortragenden erwähnen auch die Möglichkeit, dass eine stark „backdoor-artige“, signierte Debug-Funktion ohne Apples Wissen in den Chip gelangt sein könnte, etwa durch einen GPU-Entwickler.
      Das heißt: Weniger als 3,5 Jahre nachdem der erste verwundbare Chip auf den Markt kam, wurde eine undokumentierte Debug-MMIO-Serie der Apple-Coresight-GPU, die Wissen über einen langen geheimen Wert erfordert, von einer bestehenden APT-Gruppe mit über zehnjähriger Historie erfolgreich weaponisiert und ausgenutzt. Kaspersky „spekuliert nicht“, aber persönlich erscheint mir außer einem bedeutenden staatlichen Akteur kaum jemand wahrscheinlich.
      Spekulativ gesagt: Da Apple offenbar ausreichende Belege erhalten hat, dass rund 40 APT-bezogene Apple-IDs ihre Identität selbst offengelegt haben, könnte man die Identität später daran ablesen, ob es eine US-Ankündigung mit Bezug zur nationalen Sicherheit gibt. Wenn es still bleibt, war es wahrscheinlich die NSA.
    • Was wie die erste Version der tatsächlichen Aufzeichnung aussieht, ist nun online:
      https://media.ccc.de/v/37c3-11859-operation_triangulation_wh...