Apple Patch-Verlauf

In diesem Jahr sprachen a1exdandy und ich auf den Konferenzen von VolgaCTF und KazHackStan über Patch Diffing-Programme, die auf Objective-C geschrieben wurden, und darüber, wie man damit 0-Tage- und 1-Tage-Schwachstellen in Apple-Produkten sucht und findet. Sie können das Video der Präsentation hier ansehen und den Artikel lesen, willkommen bei cat.

Beim binären Vergleichen werden zwei ausführbare Dateien verglichen, um Gemeinsamkeiten und Unterschiede zwischen ihnen festzustellen. Patch Diffing ist ein Spezialfall von Binary Diffing, wenn eine Datei mit einer Sicherheitsanfälligkeit mit einer festen Datei (Datei mit einem Patch) verglichen wird. So können Sie herausfinden, welche Korrekturen der Entwickler vorgenommen hat, und die Schwachstelle nachvollziehen.

Vor einigen Jahren (2013) wurde ein Artikel über Patch Diffing für Windows-Programme veröffentlicht, an dem wir auch beteiligt waren. Wir empfehlen Ihnen, sich mit diesem Thema vertraut zu machen, wenn Sie sich für dieses Thema im Zusammenhang mit dem Windows-Betriebssystem interessieren. Im selben Artikel werden wir über die Analyse von Programmen für Apple OS sprechen.

Wie kann Binary Diffing und Patch Diffing nützlich sein?

Die Hauptaufgabe von Binary Diffing besteht darin, zu verfolgen, welche Änderungen an der Anwendung vorgenommen wurden. Dazu müssen Sie die alte Version mit der neuen vergleichen, um zu sehen, welche Änderungen der Entwickler hinzugefügt hat und wie sie implementiert werden.

Lassen Sie uns Situationen betrachten, in denen dies nützlich sein kann:

• Analyse der Programmentwicklung : Beim Vergleich der neuen und alten Versionen können Sie nachvollziehen, wie sich die Anwendung entwickelt, welche neuen Funktionen hinzugefügt, welche entfernt und welche Änderungen am vorhandenen Code vorgenommen wurden.
• Vorhandenes Wissen importieren : In Programmen, die keine symbolischen Informationen verwenden, müssen Reverse Engineers viel mehr Zeit damit verbringen, die Logik zu studieren und nach Schwachstellen zu suchen. Es kommt jedoch vor, dass Entwickler in einigen Versionen der Software versehentlich oder absichtlich symbolische Informationen hinterlassen. Diese Informationen können von dort auf die von Ihnen benötigte Softwareversion portiert werden. Beispielsweise konnten Mitarbeiter von Google Project Zero, die Binary Diffing verwendeten, Zeichen für neue Windows-Versionen von Adobe Reader aus älteren Versionen für andere Betriebssysteme abrufen, um Schwachstellen zu finden.
• Schulung zu echter Software : Patch Diffing ist unserer Meinung nach eine großartige Möglichkeit, um reibungslos von der Untersuchung kleiner CTF-Probleme zur Erforschung echter Software überzugehen. Durch Durchsuchen des Patches können Sie die tatsächliche Sicherheitsanfälligkeit in einem großen Softwareprodukt mit all seinen Funktionen untersuchen (wobei Sie sicher sein müssen, dass die Sicherheitsanfälligkeit im Code vorhanden ist). Indem Sie Fehler in einem Produkt untersuchen, können Sie nach und nach dieselben Sicherheitsanfälligkeiten finden. Als Bonus können Sie versuchen, Exploits für sie zu schreiben.
• Erstellen von 1-Tages-Exploits : Wenn ein Entwickler bereits einen Patch veröffentlicht hat, können Sie ihn schnell analysieren, einen Exploit für diese Sicherheitsanfälligkeit schreiben und einen 1-Tages-Exploit erhalten. Gleichzeitig gibt es das sogenannte Patch Gapping - die Zeit zwischen der Veröffentlichung des Patches und seiner direkten Installation durch die Clients. Während dieser Zeit kann ein eintägiger Exploit erfolgreich funktionieren und dem Autor zugute kommen (Updates rechtzeitig installieren!), Bis alle den von den Entwicklern veröffentlichten Patch installiert haben. Es gibt Situationen, in denen eine Sicherheitsanfälligkeit in einer Bibliothek behoben wurde, Programme jedoch weiterhin eine veraltete Version der Bibliothek verwenden. Hier einige interessante Beispiele für Patch Gapping für Chrome und WebKit .
• Suche nach 0-Tage-Sicherheitslücken : Unabhängig davon, wie seltsam dies bei der Analyse von Patches klingt, können Sie auch zuvor unbekannte Sicherheitslücken (0-Tage-Sicherheitslücken) finden. Entwickler irren sich ebenfalls und daher wird die Sicherheitsanfälligkeit beim Erstellen eines Patches möglicherweise nicht ordnungsgemäß geschlossen. Wenn Sie also ein Patch analysieren, können Sie einen Weg finden, um es zu umgehen. Zum Beispiel haben Apache Struts-Entwickler fünf Mal eine Sicherheitslücke behoben, aber der Patch funktionierte nur in der sechsten Version! Außerdem kann es vorkommen, dass ein Entwickler, der die ihm zugewiesene Aufgabe zur Behebung einer bestimmten Sicherheitsanfälligkeit eindeutig erfüllt, nicht bemerkt, was in benachbarten Abschnitten des Codes geschieht. Es könnte genau die gleiche Sicherheitsanfälligkeit in der Nähe sein, und im Falle einer Erkennung wird dies 0 Tage dauern. Es ist wichtig, das Muster eines erkannten Entwicklerfehlers zu untersuchen und zu versuchen, im selben Programm etwas Ähnliches zu finden. Wenn der Entwickler an einer Stelle einen Fehler gemacht hat, ist die Wahrscheinlichkeit groß, dass derselbe Fehler an einer anderen Stelle wiederholt wird.

Es gibt einen Mythos, dass das Verbergen von Informationen zu Schwachstellen-Patches die Sicherheit erhöht. In der Regel haben Angreifer jedoch bereits eine Infrastruktur für die Analyse von Patches entwickelt, sodass sie schnell die Daten finden, an denen sie interessiert sind. Das Verbergen von Schwachstellen erschwert die Arbeit derjenigen, die für den Schutz des Systems verantwortlich sind, da ohne vollständigen Zugriff auf Informationen nicht nachvollziehbar ist, wie wichtig dieser Patch für das Unternehmen ist. Zu diesem Thema empfehlen wir dringend, den Artikel "Rashomon of Disclosure" des Forschers Halvar Flake zu lesen, in dem die Situation aus verschiedenen Blickwinkeln betrachtet wird.

Nicht immer entdeckte Schwachstellen werden absichtlich ausgeblendet. Entwickler legen möglicherweise keinen besonderen Wert auf einige der Mängel ihres Produkts und beheben diese, wie bei einem normalen Fehler, ohne Werbung.

Wir sind sicher, dass dies nicht alle Situationen sind, in denen Sie Binary Diffing und Patch Diffing verwenden können, und in den Kommentaren können Sie Ihre eigenen Skripte schreiben.

Toolkit

Von der Theorie gehen wir allmählich zur Praxis über. Binary Diffing manuell durchzuführen ist natürlich ein verrücktes Unterfangen. Es wurde lange ein umfangreiches Toolkit entwickelt, das sowohl eigenständige Programme als auch Plug-Ins für gängige Binäranalysatoren umfasst: Diaphora, BinDiff, DarunGrim, YaDiff, Rizzo, Realyze, Turbodiff, Patchdiff2, Rematch und andere.

BinDiff-Schnittstelle.

Diaphora-Schnittstelle

In der Praxis verwenden wir hauptsächlich nur die ersten beiden (sie sind in den obigen Screenshots dargestellt). Leider sind die meisten der aktuellen Tools entweder nicht von der Qualität der Arbeit angetan oder werden gänzlich aufgegeben. Jetzt gibt es neue Tools, die ML verwenden, aber ihre Qualität lässt zu wünschen übrig, obwohl sie interessante Ideen für den Vergleich von Binärdateien verschiedener Architekturen haben.

Ich möchte auch die kürzlich erschienenen Tools zum Vergleichen von Open-Source-Code in Binärdateien gesondert erwähnen: Pigaios und Karta. Dies ist eine sehr interessante und nützliche Richtung. Sie sammeln Metriken aus dem Quellcode und verwenden sie dann, um Funktionen in Binärdateien zu vergleichen. Dies ist sehr nützlich, wenn keine Zeichen und statische Verknüpfungen vorhanden sind. Die Aufgabe dieser Tools besteht darin, Funktionen in einer Datei Funktionen in einer anderen zuzuordnen.

Vergleich von Patches für Apple-Betriebssysteme

In der Regel schreiben Anwendungen für Apple OS auf Objective-C. Dies ist eine objektorientierte Erweiterung für C, die auf Smalltalk-Sprachparadigmen mit eigener Laufzeit basiert.

Wenn wir das Programm auf Objective-C in einem Binäranalysator öffnen (in unserem Fall IDA), sehen wir so etwas: Funktionen in C / C ++ haben abstrakte Namen, und Funktionen in Objective-C werden sehr schön aufgerufen. (Wir werden gleich sagen, dass wir Situationen mit Code-Verschleierung nicht berücksichtigen - dies ist eine separate Geschichte.) Dies erleichtert den Reverse-Engineering: Es ist leicht zu erkennen, welches Objekt aufgerufen wird, welche Methode verwendet wird und welche Argumente es hat. Diese symbolischen Informationen vereinfachen auch die Arbeit mit Tools zum Vergleichen von Binärdateien erheblich. Sie können damit schnell und mit einer minimalen Anzahl von Fehlern Kartenfunktionen ausführen.

Wenn keine Symbole vorhanden sind, müssen die Tools interne Algorithmen für Analyse, Heuristik usw. verwenden. Natürlich funktionieren sie nicht immer richtig.

Anwendungsfälle, in denen Patch-Differenzen sehr nützlich waren

Wahrscheinlich wären diese Präsentation (im Format von 45 Minuten) und dieser Artikel nicht entstanden, wenn Apple die Weltforschungsgemeinschaft in letzter Zeit nicht mehrmals überrascht hätte. Schauen wir uns diese Fälle an.

Fall 1: CVE-2019-8606

Im Mai 2019 wurde iOS 12.3 für das iPhone veröffentlicht, bei dem die Schwachstelle behoben wurde, mit der ein Jailbreak installiert werden konnte. Im Juli dieses Jahres veröffentlichte Apple die Version 12.4, in der der Jailbreak wieder funktionierte: Mitarbeiter entfernten versehentlich den Schutzpatch. Die korrigierte Version wurde erst nach einem Monat veröffentlicht: Während dieser ganzen Zeit konnte jedes Gerät mit der neuesten Version leicht Jailbreak-Operationen unterzogen werden. All dies wurde dank Patch-Diffing entdeckt.

Fall 2: CVE-2019-7278 und CVE-2019-7286

Persönliche Erfahrungen mit unterschiedlichen Patches bei der Hack-in-the-Box-Konferenz in seinem Bericht Die Neuerstellung eines 0-tägigen iOS-Jailbreak aus Apples Sicherheitspatches wurde vom Sicherheitsforscher Stefan Esser beschrieben. Er sprach über CVE-2019-7278 und CVE-2019-7286 - sie sind bemerkenswert für diejenigen, die dank der Google Threat Analysis Group während ihrer tatsächlichen Verwendung durch Angreifer (ITW, in the wild) entdeckt wurden. Apple hat Informationen über sie erhalten, aber weder sie noch die Jungs von Google haben technische Details preisgegeben. Dann fragte sich Stefan, was die Angreifer benutzten. Wir empfehlen dringend, dass Sie seinen Bericht lesen, da er sich auch mit dem Vergleich von Kernel- und User-Space-Komponenten befasst.
Interessante Tatsache: ein oder zwei Tage vor Stefans Rede veröffentlichte Project Zero Ian Beer eine Reihe von Artikeln "Ein sehr tiefer Einblick in die in freier Wildbahn gefundenen iOS Exploit-Ketten" , die die Karten für den Forscher etwas verwirrten;)

Fall 3: checkm8

Apple-Geräte verwenden zwei Bootloader: Bootrom und Iboot. Die erste beginnt zu arbeiten, sobald sich das Gerät einschaltet. Es befindet sich im Nur-Lese-Speicher und kann nicht aktualisiert werden. Iboot ist ein Bootloader der zweiten Ebene, der die Authentifizierung in der Bootkette verbessert.
Die Besonderheit der Loader ist, dass sie den Code gemeinsam nutzen. Anfang letzten Jahres verglichen Spezialisten die Updates für Iboot und stellten fest, dass Apple eine Schwachstelle im USB-Stack behoben hat. Als sie wussten, dass derselbe Code im nicht aktualisierten Teil von Bootrom verwendet wird, stellten sie fest, dass diese Sicherheitsanfälligkeit auch dort besteht. Dann begann die Entwicklung des checkm8-Exploits. Jetzt sind alle Geräte, die auf Chips von A5 bis A11 basieren (von iPhone 4s bis iPhone X), vollständig anfällig, und es ist möglich, Ihren eigenen Code darauf auszuführen. Gleichzeitig ist diese Sicherheitsanfälligkeit auf Geräten der Versionen XR und 11 bereits geschlossen, und es gab keine Berichte von Apple darüber.
Wenn du also weißt, wo es gepatcht wurde und wie der Code aufgeteilt ist, findest du einige wirklich coole Sachen!

Unsere Geschichte: CVE-2019-8574

Im Mai veröffentlichte Apple ein neues Update für seine Geräte. Wir haben uns die Liste der behobenen Sicherheitslücken angesehen und das Dienstprogramm sysdiagnose gefunden. Dieses Programm sammelt Diagnoseinformationen aus verschiedenen Quellen und überträgt sie in Form eines Archivs zur weiteren Analyse, Unterstützung oder als Service-Center an den Benutzer. Es schien unmöglich zu sein, die Art und Weise zu beeinflussen, in der sie Informationen sammelte. In der Patch-Beschreibung wurde angegeben, dass die Sicherheitsanfälligkeit zur Erhöhung von Berechtigungen verwendet werden kann und ein Speicherbeschädigungsfehler ist, der uns noch mehr fasziniert. Und der Autor des Funds selbst hat keine Beschreibung von sich selbst veröffentlicht ...

Sie können sysdiagnose unter macOS aufrufen, indem Sie STRG + WAHL + UMSCHALT + drücken oder den Befehl sudo sysdiagnose verwenden. Auf iOS-Geräten müssen Sie die Ein- / Aus-Taste und die Lautstärketasten nach oben und unten gedrückt halten.

Patch Diffing Apple in der Praxis

Wenn Sie verschiedene Apple-Geräte patchen möchten, benötigen Sie zwei Versionen des Updates (alt und neu). Unter macOS können Sie Dateien im Software-Update-Katalog analysieren. Diese Methode hilft nicht immer, da Apple einige Updates entfernt. Updates finden Sie auch im Verzeichnis / Library / Updates. Firmware für iOS-Geräte finden Sie auf der ipsw.me- Website.
Für macOS müssen Sie ausführbare Dateien, Bibliotheksdateien, Frameworks und den Kernel mit dem Dienstprogramm Suspicious Package extrahieren.
Bei iOS-Geräten sind die Dinge etwas komplizierter. Das Update selbst ist ein ZIP-Archiv. In diesem Archiv müssen Sie die Kernelcache-Datei finden: Im Inneren befinden sich der Kernel und seine Erweiterung. Vor der Analyse müssen Sie die Datei jedoch in das Mach-O-Format konvertieren. Dies kann mit den Dienstprogrammen img4tool, joker, jtool2 und anderen erfolgen.
User-Land-Component-Firmware befindet sich im größten DMG-Image: Es enthält das Root-System und ausführbare Dateien. Wenn Sie sich jedoch gemeinsam genutzte Bibliotheken und Frameworks ansehen, sind diese nicht vorhanden. Tatsache ist, dass sie zur Optimierung des Speicherplatzes in dyld_shared_cache abgelegt werden. Diese Datei enthält alle Bibliotheken auf dem iPhone und benötigt mehr als 1 GB, was die Analyse erschwert. Wenn Sie einen separaten Teil der ipsw-Datei herunterladen müssen, verwenden Sie das Dienstprogramm ipsw ( https://github.com/blacktop/ipsw ).

Patchdifting CVE-2019-8574

Um den Patch CVE-2019-8574 zu studieren, rufen wir eine Datei aus Library / Updates ab und extrahieren zwei ausführbare sysdiagnose-Dateien (alte und neue) mit dem Suspicious Package. Dann suchen wir nach Updates mithilfe von Dienstprogrammen zum Vergleichen von Binärcodes, z. B. Diaphora oder BinDiff (das sind viele) besser als Hex-Editor).

Wie funktioniert der Patch?

Für die x86_64-Architektur haben wir nur eine geänderte Funktion gefunden. Es gibt weitere Änderungen in ARM, aber sie sind unbedeutend.

Das Problem war mit der [SDTask start] -Methode: Es wurde eine neue Prüfung hinzugefügt. In der Abbildung sehen Sie, wie ein Aufruf einer isAppleInternal-Funktion aufgerufen und das Vorhandensein der Teilzeichenfolge / usr / local in einem Pfad überprüft wird.

Wie bereits erwähnt, sammelt sysdiagnose Informationen aus verschiedenen Quellen. Quellen können entweder Dateien (z. B. ein Ereignisprotokoll) oder die Ausgabe einiger Informationsbefehle (z. B. Auflisten von Prozessen oder Threads mit ps) sein. Solche Aufgaben werden in sysdiagnose als SDTask-Objekte gespeichert. Die Methode [SDTask start] startet die Ausführung von Tasks. In der folgenden Abbildung sehen Sie den Code, in dem alle Aufgaben gebildet werden. Alle Pfade der ausführbaren Dateien und ihrer Argumente werden direkt in das Programm geschrieben, und es gibt Aufgaben aus verschiedenen Verzeichnissen, einschließlich / usr / local.

Vor der Installation des Patches kann daher jede Aufgabe ausgeführt werden, unabhängig davon, wo sich die ausführbare Datei befindet. Nach der Installation des Patches wird die Funktion isAppleInternal aufgerufen, die prüft, ob es sich bei dem Gerät um ein internes Testgerät von Apple handelt. Handelt es sich um ein internes Gerät, wird die Aufgabe auf standardmäßige Weise ausgeführt. Handelt es sich um eine clientseitige Aufgabe, wird überprüft, ob der Teilstring / usr / local / im Pfad der ausführbaren Aufgabendatei vorhanden ist. Wenn eine Teilzeichenfolge gefunden wird, wird die Aufgabe nicht abgeschlossen.

Denken Sie daran, dass in der Beschreibung der Sicherheitsanfälligkeit angegeben wurde, dass es sich um einen Speicherbeschädigungsfehler handelt, in dem Patch jedoch nichts dergleichen festgestellt wurde. Dies ist unserer Meinung nach eine gut und stabil ausgenutzte logische Sicherheitsanfälligkeit.

Wie man es ausnutzt

Um die Sicherheitsanfälligkeit auszunutzen, müssen Sie die folgenden Schritte ausführen:
Erstellen Sie eine ausführbare Datei (Binär- oder Shell-Skript), die sysdiagnose aus / usr / local / bin startet, und stellen Sie unsere Nutzdaten dort ab. Die Liste der gültigen Dateien ist unten angegeben. Es ist wichtig, dass der Brew-Paket-Manager auf dem System installiert ist: Er ermöglicht es dem Benutzer, Dateien in / usr / local / zu erstellen, ohne die Berechtigungen zu erhöhen.

Es ist notwendig, sysdiagnose aufzurufen. Gleichzeitig werden unsere Nutzdaten mit Root-Benutzerrechten ausgeführt und ihre Ausgabe in das Archiv gestellt, das sysdiagnose bildet. Dadurch erhalten wir eine Privilegieneskalation. Das Ausführen von sysdiagnose selbst erfordert jedoch erhöhte Berechtigungen. Wie oben erwähnt, kann sysdiagnose jedoch auch über eine Tastenkombination gestartet werden, und dies funktioniert sogar über den MacOS-Sperrbildschirm.
Diese Sicherheitsanfälligkeit kann verwendet werden, um verschiedene Schadprogramme zu erstellen.

/usr/local/bin/airplayutil /usr/local/bin/amstool /usr/local/bin/apsclient /usr/local/bin/audioDeviceDump /usr/local/bin/cdcontexttool /usr/local/bin/cddebug /usr/local/bin/cdknowledgetool /usr/local/bin/dastool /usr/local/bin/idstool /usr/local/bin/imtool /usr/local/bin/keystorectl /usr/local/bin/pmtool /usr/local/bin/xcpm /usr/local/efi/bin/efi-perf 

Interessanterweise können andere Sicherheitslücken mit dem Brew-Paket-Manager oder vielmehr mit der Fähigkeit, ohne Berechtigungen nach / usr / local / zu schreiben, verbunden sein.

Fazit

Mit dieser Studie möchten wir zeigen, wie wichtig und kritisch Patches sind, die sich nicht nur für Angreifer unterscheiden, sondern auch die Sicherheit von Softwareprodukten erhöhen. Leider kann der Patch nicht nur die Sicherheitslücke schließen, sondern auch dem Angreifer in die Hände spielen.

Dieser Ansatz ermöglicht es jedoch nicht nur, bekannte Schwachstellen zu untersuchen, sondern auch nach neuen Schwachstellen wie diesen zu suchen. Aus diesem Grund sind wir der Meinung, dass Patch-Unterschiede ein Muss für jeden Forscher sind.