Operation Triangulation: Wie ein Trojaner simple Security-Fehler bei Apple zeigt
Wenn weltweit bekannte Sicherheitsforscher über die Ausnutzung von Sicherheitslücken rätseln und sich öffentlich Fragen stellen, auf die sie selbst keine Antwort haben, nur um kurz darauf eine schlüssige und vertrauenswürdige Erklärung von einem einzelnen Hacker zu bekommen, kann das nichts Gutes bedeuten. Und wenn die Auflösung dann im Grunde nur ist, dass dies alles seit Jahren alles bekannt ist, ist das eine Security-Katastrophe mit Ansage, die nicht nur bei Apple kritisch aufgearbeitet werden sollte.
Dass es überhaupt so weit gekommen ist, liegt wahrscheinlich an staatlichen Hackern, die es am Ende wohl schlicht übertrieben haben. Bereits im Juni vergangenen Jahres berichteten Forscher der in Moskau ansässigen IT-Sicherheitsfirma Kaspersky von einem neuen Trojaner für iOS und iPhones, der ohne jegliche Nutzerinteraktion auskommen soll und auf Geräten des Unternehmens selbst gefunden worden sei.
Auf dem Chaos Communication Congress 37C3 in Hamburg haben die Forscher nun zahlreiche technische Details zu den Sicherheitslücken und dem genutzten Exploit veröffentlicht(öffnet im neuen Fenster) . Demnach ist die extrem ausgeklügelte Kette vieler Sicherheitslücken über mehrere Jahre genutzt worden und letztlich nur bekanntgeworden, weil auch Telefone der Kaspersky-Forscher infiziert worden sind. Wohl auch deshalb heißt der Vortrag: "Was Sie bekommen, wenn Sie iPhones von Forschern angreifen" . Die Angriffsserie selbst nennt Kaspersky Operation Triangulation.
Extrem komplizierte Exploit-Chain
Auffallend daran ist einerseits der extrem komplexe Aufbau des Exploits(öffnet im neuen Fenster) bis hin zum eigentlichen Trojaner. Dabei werden gleich sechs zuvor nicht bekannte Sicherheitslücken in Apple-Software verwendet und es werden laut den Kaspersky-Forschern 14 verschiedene Phasen in der Angriffskette durchlaufen, bis das iPhone übernommen worden ist. Die technischen Details sind dabei teils so kompliziert, dass uns auch Sicherheitsforscher auf dem 37C3 im Gespräch berichteten, dass sie es noch nicht komplett verstanden hätten.
Der an der Untersuchung beteiligte Kaspersky-Forscher Boris Larin sagte dem Magazin Ars Technica(öffnet im neuen Fenster) dazu: "Die Komplexität des Exploits und die Obskurität der Funktionen lassen darauf schließen, dass die Angreifer über fortgeschrittene technische Fähigkeiten verfügten."
Rätselraten zu Hardwarefunktion in Apple Silicon
Andererseits fällt an dem Exploit aber auf, dass eben nicht nur das Kaspersky-Team selbst, sondern auch weitere Sicherheitsforscher viele offene Fragen zu der dafür genutzten Technik haben. Entscheidend sind hier von Apple nicht öffentlich dokumentierte Hardwarefunktionen und Register, die letztlich zur Umgehung bestehender Sicherheitsmechanismen genutzt werden.
Der Darstellung zufolge werden die Hardwareteile durch die Geräte-Firmware jedoch nicht verwendet. Die Forscher vermuten, dass es sich dabei um Schnittstellen zum Debuggen oder Testen handelt, die in verkauften Geräten aus bisher unbekannten Gründen aktiviert geblieben sind.
Schon das Forscherteam selbst sagt, dass das Vorhandensein der Debug-Register kein Zufall sein könne, denn die Hardwarefunktionen finden sich nicht nur auf iPhones, sondern auch in den M1- und M2-Chipserien des sogenannten Apple Silicon in aktuellen ARM-basierten Macs.
Aufklärung dazu bietet der Entwickler Hector Martin, der unter anderen das Asahi-Linux-Projekt begründet hat, das Linux per Reverse Engineering auf Apple-Silicon-Macs portiert. Martin schreibt zu den auf dem Vortrag(öffnet im neuen Fenster) vorgestellten Erkenntnissen und Fragen: "Ich wette, ich habe ein paar Antworten."
Apple patzt bei einfacher Hardwaresicherheit
Zunächst klärt Martin in seiner Reaktion auf den Vortrag und auf die veröffentlichte Analyse der Kaspersky-Forscher(öffnet im neuen Fenster) einige Details zu dem ECC-Code für RAM-Cache, den das Forscherteam fälschlicherweise als Hash-Wert identifiziert hat. Darüber hinaus beschreibt Martin, dass die von den Forschern beschriebenen Debug-Register dem Asahi-Team schon länger für die Haupt-CPU bekannt seien und es nur folgerichtig sei, dass diese auch für die Firmware-Schnittstelle des ASC existierten.
Die GPU des Apple Silicon nutzt mit ASC einen Co-Prozesseor, bei dem es sich um eine komplette ARM64-CPU samt Echtzeitbetriebssystem handelt. Die so umgesetzte Firmware verwaltet im Prinzip jede Funktion der GPU: Energieverwaltung, Scheduling und Preemption, Fault-Recovery, Perf-Counter, weitere Statistiken und sogar die Temperatur.
Zu dem Mechanismus der undokumentierten Debug-Register schreibt Martin außerdem, dass dieser einfach zu erraten gewesen sei(öffnet im neuen Fenster) . Er selbst habe schon kompliziertere Dinge durch simples Ausprobieren gefunden.
Die für den Expoit wichtige Frage sei demnach nur, wie die für den Trojaner verantwortlichen Hacker darauf gekommen seien, danach zu suchen. Martin vermutet, dass Apple Hinweise darauf geleakt und es anderweitig Informationen dazu gegeben haben könnte. Diese könnten etwa aus Sicherheitswerkzeugen zum Untersuchen von iPhones stammen.
Apple wusste von Bug
Letztlich berichtet Martin aber, dass der für die Operation Triangulation genutzte Hardwarefehler von ihm bereits selbst gefunden und auch ausgenutzt worden sei. Er schreibt dazu: "Ich habe dafür kein Geld bekommen, weil die Art und Weise, wie ich es ausgenutzt habe, nicht für normales macOS galt, aber jetzt haben Staatshacker herausgefunden, wie man es für eine echte Exploit-Kette benutzen kann. 'Ups'."
Apple wusste also nicht nur von der durch Martin gemeldeten Lücke, sondern hat diese auch nicht als kritisch genug eingestuft, um sie zu beheben. Warum das nicht geschehen ist, kann vermutlich nicht mal Apple erklären.
Selbst wenn es für einige eine naheliegende Überlegung wäre, wollen auch die Forscher von Kaspersky nicht so weit gehen zu behaupten, dass die NSA hier ihre Finger im Spiel hatte, damit die Lücke ausgenutzt werden kann. Wie so oft dürfte hier Hanlon's Razor(öffnet im neuen Fenster) gelten.
Keine GPU-IOMMU in Apple Silicon
Aus Security-Sicht schwerwiegender ist jedoch eine dauerhafte Entscheidung des Apple-Hardware-Teams, die sich wohl nur langfristig für künftige Geräte ändern lassen wird. Martin schreibt dazu: "Das Ganze hängt mit dem Problem zusammen, dass es aus Leistungsgründen keine IOMMU für die GPU gibt."
Tatsächlich hat das Asahi-Linux-Team schon beim Erstellen des GPU-Treibers einen Fehler gefunden, der es ermöglichte, den statt der IOMMU genutzten Software-Sicherheitsmechanismus zu umgehen. Apple hat dies mit einer Bug-Bounty von 150.000 US-Dollar gedankt.
Der Softwaremechanismus nennt sich Page Protection Layer (PPL). Wie Googles Project Zero schon im Jahr 2020 schrieb(öffnet im neuen Fenster) , soll der PPL eigentlich verhindern, dass Angreifer selbst dann Code oder Seitentabellen von Prozessen verändern können, wenn diese Vollzugriff auf den Kernel haben. Aber insbesondere deshalb eignet sich der PPL offenbar als gutes Ziel zum Suchen nach Lücken, die es ermöglichen, den PPL zu umgehen. Seit Jahren werden immer wieder entsprechende Lücken gefunden.
Weiter heißt es bei Martin, dass der Patch für die eigentliche Lücke des Exploits trivial sei. Die Register werden schlicht nicht mehr vom PPL verwaltet. Aber: "Nun stellt sich die Frage, wie lange es dauert, bis jemand eine andere spaßige Umgehungsmaßnahme findet, die eine andere obskure Funktion oder einen Fehler der GPU oder ihrer Firmware nutzt?"
Eine Hardware-IOMMU würde das deutlich erschweren. Auch deshalb setzen andere Hersteller auf diese Technik. Der Nachteil: Mit der Nutzung IOMMU sinkt die Leistung der GPU etwas.
Technisch wäre es hingegen vergleichsweise einfach, eine IOMMU für die GPU umzusetzen und zu benutzen. Das macht Exploits zwar auch nicht unmöglich, erschwert sie aber massiv. Es bleibt zu hoffen, dass das Hardwareteam bei Apple dies mittelfristig in seinen Chips umsetzt.