Navigieren durch Apples Bitcode-Änderungen: Stärkung der App-Sicherheit mit ARM-Schutz

Level eingestellt

Jeder hat es gehört. Es ist die Trenddiskussion über Wasserkühler. Apple entfernt eingebetteten Bitcode in Xcode 15. Der König ist tot; lang lebe der König.

Der eingebettete Bitcode schien ursprünglich dazu gedacht zu sein, Entwicklern die Einreichung einer einzigen Anwendung zu ermöglichen, die auf allen Apple-Produkten funktionieren würde. Bitcode überdeckt einen Großteil der Probleme, die mit der Handhabung unterschiedlicher Prozessorarchitekturen verbunden sind. Während es seit einiger Zeit klar ist, dass Apple beabsichtigt, seine gesamte Produktlinie auf arm64 zu standardisieren, könnte eingebetteter Bitcode verwendet werden, um eine einfachere plattformübergreifende Unterstützung zu ermöglichen und Apple ein gewisses Maß an Kontrolle über den Kompilierungsprozess für im App Store vertriebene Anwendungen zu geben . Es handelte sich um eine Funktion, die nicht so weit verbreitet war, wie Apple es sich gewünscht hätte, aber die Auswirkungen ihrer Entfernung haben im gesamten erweiterten Entwicklungsökosystem Schockwellen ausgelöst.

Es gab einige, an Panikmache grenzende Erwähnungen von Personen in der Sicherheitsgemeinschaft rund um Apple, die sich vollständig von LLVM abwenden würden. Durch diese Änderung verringert sich die Abhängigkeit von Apple von LLVM insgesamt etwas, aber das bedeutet nicht unbedingt, dass Apple beabsichtigt, die Swift-Open-Source-Community von LLVM abzuwandern. Das wäre eine große Änderung und ein Todesurteil für den Bitcode-Schutz während der Erstellung. Swift wird als erstes Open-Source-Projekt auf der Website von Apple aufgeführt und die Entwickler tragen weiterhin regelmäßig dazu bei. Ihr neuestes Betriebssystem, xrOS (nennen wir es iMask), wurde bereits zu ihrem LLVM-Fork hinzugefügt. Obwohl Apple keine Angst vor tiefgreifenden Änderungen hat, gibt es keine weiteren Anzeichen, die auf eine Abkehr von LLVM hindeuten. Obwohl es möglich ist, fühlt es sich nicht wie eine kurzfristige Realität an, und alle anderen Behauptungen werden als unaufrichtig aufgefasst. Aktuelle Lösungen, die auf Build-Time-Bitcode basieren, werden nicht verschwinden, und wir unterstützen und entwickeln weiterhin aktiv unsere aktuellen App Protection für Apple-Produkte. Allerdings sind Schutztools, die zur Build-Zeit integriert werden, deutlich schwieriger zu integrieren und anfällig, wenn sie Änderungen in der Toolchain ausgesetzt sind.

Vorteile von Post-Build vs. Build-Time

Die ursprüngliche Fähigkeit und Empfehlung von Apple, Bitcode in eine Binärdatei einzubetten, war eine einschneidende Veränderung für Bitcode-Schutztools. Build-Time-Integrationen sind instabil, erfordern umfangreiche Wartungsarbeiten im Zusammenhang mit Xcode und verursachen organisatorisches Unbehagen. Build-Time-Schutztools wirken sich tendenziell negativ auf die Fähigkeit eines Unternehmens aus, sein Build-System zu ändern oder zu aktualisieren, oder verhindern es sogar. Der Post-Build-Schutz ist die Zukunft, aber diese Zukunft enthält keinen Bitcode mehr. Damit verbleibt der Schutz auf Baugruppenebene. Auch wenn die Montage komplex und schwierig zu modifizieren sein kann, ist das Endergebnis ein flexiblerer Schutz, der nicht durch bestimmte Toolchains eingeschränkt ist und ein breiteres Spektrum an Schutzfunktionen bietet.

Vorteile von Bitcode gegenüber Assembly

Eine der großen Stärken von Bitcode ist seine (weitgehend) prozessorunabhängige Darstellung. Diese Stärke ist nicht besonders relevant, da Apple alle seine Produkte rund um den arm64-Befehlssatz standardisiert. Diese Verschiebung ermöglicht es allen Apple-basierten Schutztools, sich ausschließlich auf die Arm64-Montage zu konzentrieren. Der arm64-Befehlssatz ist ein starker, gut verstandener Standard, und dieser Standard ermöglicht einen gezielteren Ansatz zur Umgehung statischer und dynamischer Analysen. Während es schwieriger ist, Schutzmaßnahmen auf Mach-O-Binärdateien anzuwenden, was vor allem auf eine unvollständige Analyse zurückzuführen ist, ist das Endergebnis ein stärkerer Schutz. Unsere ARM-basierten Schutztools verschleiern und fügen IPA- und Xcarchive-App-Paketen erfolgreich dynamische Umgebungsschutzfunktionen hinzu. Der Schutz der nativen Assembly ermöglicht eine umfassendere Sicherheitsstrategie. Alle Binärdateien im Anwendungspaket können im selben Ein-Aufruf-Prozess geschützt werden. Der Schutz von Frameworks, die mit Swift Package Manager erstellt wurden, wird eher trivial als äußerst komplex oder unmöglich.

ARM-Montage

Der arm64-Befehlssatz (insbesondere die armv8-Version) ist nicht übermäßig komplex und beeindruckend effizient. Es bietet einige wesentliche Vorteile gegenüber der x86-Assemblierung hinsichtlich Analyse und Verschleierung. Am wichtigsten ist, dass alle arm64-Anweisungen genau vier Bytes lang sind. Außerdem sind Daten im Code scheinbar nicht sehr verbreitet (mit Ausnahme von Switch-Tabellen). Diese beiden Dinge vereinfachen die binäre Analyse erheblich. Es ist genau wie das Sprichwort sagt: „Eine umfassende Binäranalyse ist der erste Zweig im Baum einer robusten Verschleierungsstrategie.“

Eine unserer bedeutungsvolleren Verschleierungsmethoden, um die statische Analyse zu verhindern, ist Chopup. Das Zerlegen einer einzelnen Unterroutine in manchmal Hunderte von Teilen und deren Verteilung kann die Kontrollflussanalyse erheblich erschweren. Während es schwierig ist, diese zu bewegen, ist es noch schwieriger, sie richtig anzuschließen. Intern nennen wir diese Verbindungen „Sprünge“; Leider sind nicht alle Sprünge gleich. Vorhersehbarkeit ist der Feind der Sicherheit, daher ist die Nutzung aller Arten von Sprüngen von entscheidender Bedeutung. Der AB-Befehl (Branch) hat beispielsweise nur einen Bereich von +/-128 MB, während ein BR-Befehl (Branch to Register) einen binären breiten Bereich hat. Für einen BR-Befehl ist jedoch ein Register erforderlich, das die Adresse enthält, zu der verzweigt werden soll. Nicht alle Register sind es safe an allen Punkten in der Ausführung einer Binärdatei geschrieben werden, und einige, wie x18, sind es nie safe benutzen. Alle Kontrollflussanweisungen haben Vor- und Nachteile, und es ist eine Herausforderung, die richtige für die jeweilige Aufgabe zu finden. Sobald Chopup mit Zehntausenden Verschleierungen von Befehlsersetzungen gepaart ist, müssen Angreifer in Ghidra wie ein Pogopalooza-Weltmeister herumspringen, nur um eine einzige Subroutine zu lesen.

Ermöglichen hybrider Schutzmaßnahmen

In der Hybrid-App-Szene gibt es einiges zu entdecken, und glücklicherweise ermöglichen Schutzmaßnahmen auf Baugruppenebene auch einfachere und umfassendere Hybridschutzmaßnahmen. Flutter-Anwendungen können keine Bitcode-Schutzlösungen nutzen, da das Build-System von Flutter keinen Pfad zum Bitcode hat. Ebenso schränkt Microsofts .NET 7+ mit MAUI die Möglichkeit zur Ausgabe von Bitcode ein. Flutter und andere Hybrid-Frameworks verwenden jedoch die AoT-Kompilierung, um arm64-Binärdateien zu erstellen. Post-Build-ARM-Schutzmaßnahmen können diese Binärdateien wie jede andere iOS-Anwendung verschleiern und ihnen einen aktiven Schutz hinzufügen. Der Schutz „funktioniert“ für fast alle iOS-App-Pakete. Wenn Entwicklungsteams in die Lage versetzt werden, alle Binärdateien in ihrem Anwendungspaket mit einem einzigen Aufruf zu schützen, sieht ein echter Shift-Left-Vorgang aus.

Wie Post-Build in CI integriert werden kann

Ein CI/CD DevSecOps Pipeline ist mittlerweile ein bekannter Industriestandard und nichts ist frustrierender als das Debuggen von Build-Zeitproblemen in dieser Pipeline. Das Hinzufügen eines einzigen Aufrufs zu einem CI/CD-System direkt nach dem Build, aber direkt vor dem Testen, ist eine schmerzlose Integration und hält Entwicklung, Tests usw. aufrecht DevOps Teams laufen auf Hochtouren. Der Post-Build-Schutz kann Teil der normalen CI/CD-Pipeline sein. Das bedeutet, dass die Schutztools nicht auf jedem Entwicklercomputer installiert und lizenziert oder bei jedem Entwicklungs-Build ausgeführt werden müssen. Wir haben unzählige Probleme gesehen, die durch Build-Time-Schutzmaßnahmen in gut erstellten CI/CD-Umgebungen verursacht wurden. Durch den Wechsel zu einer Post-Build-Sicherheitslösung können Teams ihren Build-Prozess selbst übernehmen und ändern, während CI/CD-Abläufe umweltfreundlich und die Entwicklungsteams zufrieden bleiben. Unsere Teams mögen die Farbe Grün; Es steht schließlich im Logo. Denken Sie zum Schluss immer daran: Ein 16-Byte-ausgerichteter Stapelzeiger hält den EXC_BAD_ACCESS fern.

 

Entdecken Sie die Zukunft der iOS-App-Sicherheit mit ARM Protection weiter und erfahren Sie, wie dies möglich ist safeSchützen Sie Ihre Apps in unserem Blog vor sich entwickelnden Bedrohungen.Einführung von ARM Protection: Ein Game-Changer für die iOS-App-Sicherheit.