iOS-Anwendungen auf ARM-Macs: Pentesting-Möglichkeiten

(Nur auf Englisch verfügbar)

Blogbeitrag 20. Juli 2021 von Jim Aspers, Sicherheitsspezialist bei Bureau Veritas Cybersecurity

Bei der Untersuchung von iOS-Anwendungen auf Sicherheitslücken sind Penetrationstester in der Regel darauf angewiesen, jailbroken Geräte zu bekommen. Bei Anwendungen mit Jailbreak-Erkennung kann diese Anforderung zu Verzögerungen bei der Ausführung führen, da die Umgehung der Jailbreak-Erkennung eine komplizierte Aufgabe sein kann.

Es gibt zwar Methoden, die es ermöglichen, Sicherheitsbewertungswerkzeuge in die Zielanwendung auf einem nicht gejailbreakten Gerät zu injizieren (siehe z.B. frida-agent), doch ist dies im Allgemeinen zeitaufwändig und in seinen Möglichkeiten begrenzt. Die Verfügbarkeit einer umfassenden und komfortablen Plattform für die Durchführung von Sicherheitstests, die von Anwendungen nicht als jailbroken erkannt wird, wäre von großem Vorteil.

MacOS kann die Rolle einer solchen Plattform spielen. Das Betriebssystem enthält viele leistungsstarke systemeigene Funktionen, die für Reverse Engineering nützlich sind, wie dtrace und seine Derivate (z.B. dtruss, opensnoop). Außerdem kann der Wi-Fi- und Bluetooth-Verkehr ganz einfach lokal auf dem System abgefangen werden (z.B. mit Wireshark oder einem Proxy wie Burp Suite), anstatt ein externes Man-in-the-Middle-Setup einrichten zu müssen.

Kurz nach dem Erscheinen der ARM-betriebenen Mac-Computer wurde von Apple die Möglichkeit angekündigt, iOS-Anwendungen auf dem macOS-Betriebssystem auszuführen.Um die Möglichkeiten, die diese Funktion für das Pentesting bietet, zu erkunden und gleichzeitig mit Apples Einschränkungen umzugehen, haben wir nach einer Möglichkeit gesucht, beliebige iOS-Anwendungen auf macOS-Rechnern auszuführen.

Obwohl die Installation von iOS-Apps möglich ist, behält Apple die Kontrolle darüber, was installiert werden kann und was nicht, um den gleichen Schutz vor Piraterie/DRM zu bieten, den die iOS-Plattform bietet. Aus diesem Grund empfiehlt Apple seinen Nutzern, iOS-Anwendungen über den macOS App Store zu installieren. Darüber hinaus können bei der manuellen Installation aus einem .ipa-Paket nur signierte Installationspakete installiert werden. Nachdem die Community die Möglichkeit des "Sideloadings" von Anwendungen entdeckt hatte, die mit derselben Apple ID gekauft wurden, mit der auch der macOS-Rechner registriert war, fügte Apple eine weitere Einschränkung hinzu, die besagt, dass nur Anwendungen installiert werden können, die für die Ausführung unter macOS zugelassen sind (siehe z.B. diesen Bericht).

Obwohl die Methode alles andere als 'sauber' ist, hoffen wir, dass sie von Anwendungs-Pentestern zu ihrem Vorteil genutzt werden kann.

Accelerated mobile pages amp improve seo

Zielanwendung entschlüsseln

Die Binärdateien von iOS-Anwendungen werden mit dem FairPlay-DRM von Apple verschlüsselt, wodurch sie für jeden außer dem Inhaber der Apple-ID des App-Käufers unbrauchbar werden. Diese Verschlüsselung ist nicht nur ein wirksamer Mechanismus gegen Piraterie, sondern hat auch folgende Auswirkungen:

Die Anwendung kann nicht auf ein Gerät übertragen werden, das nicht an dieselbe Apple ID gekoppelt ist;
Die Anwendung kann nicht statisch in einem Disassembler für Reverse Engineering analysiert werden;
Die Anwendung kann nicht auf der Festplatte zu Patchzwecken verändert werden.

Aus diesem Grund werden Sicherheitstests und insbesondere Reverse Engineering in der Regel mit einer unverschlüsselten iOS-Anwendung durchgeführt.

Die Beschaffung einer unverschlüsselten Version aller Binärdateien der Anwendung, einschließlich der Bibliotheken und Frameworks, lässt sich am einfachsten mit frida-ios-dump durchführen (siehe AloneMonkey/frida-ios-dump). Dieses auf Frida basierende Tool macht sich die Tatsache zunutze, dass ein iOS-Gerät, um eine verschlüsselte Binärdatei ausführen zu können, diese im Speicher in ein ausführbares Format entschlüsseln muss. Das Tool findet die entschlüsselten Binär-Images aus dem Speicher eines jailbroken Geräts direkt nach dem Start der Zielanwendung und erstellt ein .ipa-Installationsarchiv für die App, das unverschlüsselte Binärdateien enthält.

Zu Demonstrationszwecken wurde die von VMware entwickelte Anwendung "Intelligent Hub" aus dem iOS App Store auf ein jailbroken Gerät heruntergeladen. Diese Anwendung kann nicht über den macOS App Store installiert werden und enthält viele Bibliotheken und Frameworks. Daher ist sie das perfekte Ziel für unser Experiment. Im weiteren Verlauf dieses Artikels wird diese Anwendung als das Subjekt verwendet, das wir auf einem macOS-System ausführen möchten, und wird als "Zielanwendung" bezeichnet.

Um ein .ipa-Archiv für die Zielanwendung zu dumpen, das entschlüsselte Binärdateien enthält, wird der folgende Befehl ausgeführt, während das jailbroken iOS-Gerät über USB angeschlossen ist:

Wenn wir nun versuchen, das resultierende Archiv direkt über den iOS Application Installer.app (zu finden in /System/Library/CoreServices/Applications/) von macOS zu installieren, stoßen wir auf einen Fehler:

Ein Blick auf die Protokolle in Console.app zeigt, dass die Archivsignatur nicht akzeptiert wird

Dies ist ein erwartetes Verhalten, da die IPA nicht für die nun entschlüsselten Binärdateien gekündigt wurde. Wir könnten die IPA zurücktreten lassen, aber dieser Prozess kann ziemlich schnell mühsam werden, insbesondere wenn mehrere Frameworks enthalten sind oder wenn die Zielanwendung exotische Berechtigungen erfordert. Zu diesem Zweck können Tools wie AltSignverwendet werden. Da wir jedoch in der Lage sein möchten, jederzeit beliebige (modifizierte) Anwendungspakete für Sicherheitstests zu installieren, suchen wir nach einer Methode, um die Signaturvalidierung der installierten Anwendung zu umgehen.

Lernen am Beispiel

Wenn wir uns die Ausgabe in Console.app ansehen, wenn wir iOS-Apps aus dem App Store installieren, die offiziell als kompatibel mit macOS gekennzeichnet sind, stellen wir fest, dass der Installationsprozess mehr tut, als nur die Dateien des Installationspakets zu platzieren. Als Beispiel für die Untersuchung des Installationsprozesses haben wir die Anwendung 'Aangifte 2020' verwendet, die von der niederländischen Steuer- und Zollverwaltung entwickelt wurde. Diese Anwendung war als iOS-App sowohl über den iOS- als auch den macOS-App-Store erhältlich. In diesem Artikel werden wir diese Anwendung als "Spenderanwendung" bezeichnen.

Die erste Beobachtung ist, dass eine spezielle 'Wrapper'-Ordnerstruktur in /Applications erstellt wird:

Es wurde festgestellt, dass der Ordner maa.iOS.app eine typische Ordnerstruktur für iOS-Anwendungspakete enthält.

Weitere Beobachtungen zeigen, dass das Installationsprogramm mehr tut, als nur diesen Wrapper für die eigentliche iOS-Anwendung zu erstellen. Ein Blick auf die Systemprotokolle und die Dateiaktivitäten zeigt, dass zahlreiche Betriebssystemkomponenten an diesem scheinbar komplexen Prozess beteiligt sind, bei dem Datensätze mit Bundle-Details in einer Systemdatenbank gekoppelt sind.

Anstatt den Installationsprozess weiter zurückzuentwickeln, wird die Möglichkeit untersucht, den gültigen Anwendungs-Wrapper zum Hosten unserer Zielanwendung zu verwenden.

Den Parasiten spielen

Wenn Sie zum entschlüsselten Anwendungsarchiv für die VMware Intelligent Hub-Anwendung zurückkehren, kann der Inhalt des Archivs ganz einfach extrahiert werden:

Wir können den Inhalt des Bundles der Spenderanwendung mit dem extrahierten Inhalt des Bundles der Zielanwendung überschreiben:

Dies funktioniert jedoch nicht sofort nach der Installation. Alle macOS- und iOS-Binärdateien (einschließlich dynamisch verlinkter Bibliotheken und Frameworks) müssen digital signiert werden. Zur Erstellung einer gültigen Signatur können nur von Apple ausgestellte Zertifikate verwendet werden. Wenn Sie eine Binärdatei ändern, müssen Sie den geänderten Code neu signieren. Diese Signaturen sind in die Binärdatei selbst eingebettet. Für Bibliotheken, Frameworks und andere wichtige Ressourcen innerhalb eines Anwendungspakets (z.B. Info.plist) werden die Signaturen zusätzlich in einer eigenen Datei (_CodeSignature/CodeResources) gespeichert. Auf diese Weise kann das Betriebssystem die Integrität des ausgeführten Codes garantieren. Einzelheiten hierzu finden Sie in der Entwicklerdokumentation von Apple.

Aus diesem Grund kann der Inhalt des Anwendungsbündels unseres gültigen Wrappers nicht einfach mit dem Inhalt von Hub.app überschrieben werden: Die Codesignaturen für die Binärdateien innerhalb des extrahierten Bündels sind ungültig. Da wir die geänderten Inhalte des Anwendungsbündels in den Wrapper der Spenderanwendung kopiert haben, müssen wir den entsprechenden Dateien eine Codesignatur hinzufügen. Wir möchten jedoch nicht das erforderliche Bereitstellungsprofil mit allen erforderlichen Berechtigungen für jede zu testende Anwendung manuell erstellen. Dies würde einen erheblichen manuellen Aufwand im Apple Developer Portal bedeuten. Außerdem müssten wir die Berechtigungen der Binärdateien bearbeiten, damit sie mit unserer Codesigning-Identität übereinstimmen. Wenn wir diesen Ansatz wählen würden, könnten wir genauso gut das entschlüsselte Installationsarchiv in seiner Gesamtheit zurückgeben. Um all dies zu umgehen, verwenden wir hier die so genannte "Ad-hoc-Signierung". Aus man codesign(1):

Wenn Sie die Ad-hoc-Signierung anstelle der regulären Signierung mit einer ordnungsgemäßen Code-Signatur-Identität verwenden, enthalten die Code-Signaturen der Binärdateien nur einen Hash der jeweiligen signierten Binärdatei. Dieser Hash wird vom Kernel vor der Ausführung mit dem statischen Vertrauenscache des Betriebssystems abgeglichen. Der vertrauenswürdige Cache enthält Hashes für bekannte Apple System-Binärdateien und kann zur Laufzeit nicht verändert werden, ohne eine schwerwiegende Sicherheitslücke in einer Standardkonfiguration von macOS auszunutzen.

Vor diesem Hintergrund beginnen wir damit, unser modifiziertes Wrapped Bundle ad-hoc zu signieren:

Wenn wir die Ad-hoc-Codesignatur anwenden und versuchen, die Anwendung auszuführen, stürzt der Lader die Anwendung beim Laden ab, wie wir es aufgrund unserer Kenntnisse über die Codesignatur erwartet haben. Kurz vor dem Absturz beobachten wir den folgenden Protokolleintrag, der vom Kernel stammt:

Wir sehen, dass die betroffene Komponente AppleMobileFileIntegrity ist , allgemein bekannt als AMFI. AMFI läuft als Teil des Kernels (KEXT) und ist für die Integritätsprüfung von Binärdateien zuständig. Die gefundene Meldung zeigt den Rückgabewert 0xe00002f0.

Ein Blick auf den beobachteten IOreturn-Rückgabe-Subcode im XNU-Kernel-Quellcode zeigt, dass die Ursache dieses Fehlers erklärt werden kann:

Der Kernel gab ein kIOReturnNotFound als Ergebnis zurück, als er den Hash unserer Binärdatei im Trust Store suchte.Das macht Sinn, denn wir wissen, dass der Trust Cache eine vorkompilierte, fest kodierte Datenstruktur ist, die nur Hashes für Binärdateien enthält, denen Apple vertraut. Das Hinzufügen unserer Hashes zum Trust Store würde den Rahmen dieses Artikels sprengen und wir werden stattdessen eine triviale Umgehung verwenden.

Zu Testzwecken erlaubt macOS im Gegensatz zu iOS die (teilweise) Deaktivierung von AMFI.Wenn wir AMFI deaktivieren, wird das Fehlen des Hashes unserer ad-hoc signierten Binärdatei im Trust Cache nicht länger ein Problem darstellen. Die Deaktivierung von AMFI kann durch die Übergabe eines besonders interessanten Boot-Arguments an den macOS-Kernel erfolgen. Das Argument kann von einem Live-System wie folgt hinzugefügt werden, um nach dem Neustart wirksam zu werden:

Beachten Sie, dass der Systemintegritätsschutz (SIP) in neueren Versionen von macOS deaktiviert sein muss, um die Boot-Argumente ändern zu können.

Nach dem Hinzufügen der Boot-Argumente und dem Neustart des Rechners wird das ad-hoc signierte Anwendungspaket nicht mehr blockiert und kann wie eine normale Anwendung über Finder.app gestartet werden.

HINWEIS: Die Deaktivierung von AMFI und vor allem von SIP deaktiviert den Kern des Sicherheitsmodells des Betriebssystems von macOS. SIP sollte auf einem Produktionssystem NIEMALS ohne sorgfältige Abwägung der damit verbundenen Sicherheitsrisiken deaktiviert werden!

Damit diese Methode funktioniert, sollte die Spenderanwendung, die wir als gültigen Wrapper für unsere Zielanwendung verwenden, nicht gestartet werden, bevor ihr Inhalt überschrieben wird. Dies hängt damit zusammen, dass macOS beim ersten Start scheinbar eine Referenz der Bundle-Kennung der iOS-Anwendung in Bezug auf das Wrapper-Bundle selbst speichert. Das bedeutet, dass wir, wenn wir eine andere Zielanwendung innerhalb des Wrappers verschieben möchten, entweder dieselbe Bundle-Kennung beibehalten oder die Spenderanwendung aus dem App Store einfach deinstallieren und neu installieren müssen. Die Änderung des Inhalts des umhüllten iOS-Anwendungs-Bundles ist ohne Einschränkungen möglich, solange die Bundle-Kennung unverändert bleibt und das gesamte Bundle nach der Änderung (ad-hoc) neu signiert wird.

Machen wir uns an die Arbeit!

Dank unseres kleinen Hacks können wir nun unsere Zielanwendung, den VMware Intelligent Hub, erfolgreich auf unserem macOS-System ausführen:

Besonders interessant für einen Pentester ist die komfortable Inspektion der Datenspeicher der Anwendung:

Wir können die Anwendung selbst mit minimalen Einschränkungen ändern (unter Berücksichtigung der erforderlichen Neusignierung). So können Sie Patches im Handumdrehen anwenden. Ein Beispiel für die Änderung des Anzeigenamens der Anwendung:

Infolgedessen änderte sich der Anzeigename der Anwendung (und damit der Fenstertitel) nach dem Neustart der Anwendung:

Da die iOS-Anwendung in der nativen macOS-Umgebung läuft, wird sie fast genauso behandelt wie reguläre macOS-Anwendungen. Das bedeutet, dass der Netzwerkverkehr mit gängigen Tools wie Wireshark, Burp Suite oder Charles überwacht und abgefangen werden kann. Außerdem können die macOS-eigenen Tracing- und Debugging-Tools wie lldb und dtrace-ähnliche Tools verwendet werden:

Das Anhängen einer vollständigen Xcode-Debugging-Umgebung ist ebenfalls trivial und bietet ein deutlich besseres Erlebnis als die Verwendung einfacher Jailbreak-Tools:

Und jetzt?

Hatten wir Erfolg? Nun, teilweise. Wir können jetzt beliebige iOS-Anwendungen auf unseren macOS-Systemen ausführen. Um jedoch auf unser in der Einleitung formuliertes Problem zurückzukommen: Mehrere Anwendungen, die einen Jailbreak erkennen, weisen unser System immer noch als jailbroken aus. Um zu wissen, ob dieser Ansatz geeignet ist, dieses Problem zu lösen, wären weitere Untersuchungen erforderlich.

Außerdem ist es uns nicht gelungen, eine beliebige iOS-Anwendung zu installieren. Wir haben lediglich eine Spenderanwendung "parasitiert". Das Reverse Engineering der Art und Weise, wie macOS intern mit dem Spawnen von iOS-Apps umgeht, und die Anwendung dieser Methode zum Erreichen unseres Ziels werden wir in einem Folgebeitrag behandeln (siehe https://github.com/srepsa/launchr für einen kleinen Einblick). Bleiben Sie dran!