App Wrapping- Konzept mit Zukunft oder falsche Fährte?

Wie in Teil 1 beschrieben greifen viele Firmen gerne auf Lösungsanbieter mit "Wrapping" Ansätzen zurück. In diesem Teil möchten wir Ihnen weitere Argumente an die Hand geben um die technische Umsetzung von Wrapping bewerten zu können.

Wie funktioniert Wrapping wirklich ?

In einem Unternehmen erlaubt das App Wrapping einem Administrator, einer App zusätzliche Sicherheits- und Management-Funktionen (MAM) beizubringen. Danach hat er die Möglichkeit, die App als einzelnes, in einen Container verpacktes Programm via Enterprise App Store auszurollen. Es ist wichtig zu verstehen, dass Wrapping genutzt werden kann um das Management einer App zu ermöglichen. Es ist aber nicht so, das jede App gewrappt sein muss damit MAM funktioniert. Das Wrapping kann aber in jedem Fall als eine Möglichkeit dargestellt werden, die prinzipiell allen Apps im Nachhinein zu zusätzlichen Funktionen verhelfen kann, die vom Entwickler nicht bedacht wurden. Das MAM oder die Implementierung von Sicherheitsfeatures sind nur einige davon.

Am Beispiel von iOS möchten wir Ihnen das Konzept hinter Wrapping erklären. Diese Erklärung ist auf andere Plattformen adaptierbar.

Die Apps in der iOS Welt sind Großteils in Obejctive-C oder in SWIFT geschrieben und Android-Apps vorwiegend in Java. Objective-C ist eine objektorientierte Erweiterung der klassischen Programmiersprache C, die jedoch im Gegensatz zu C oder C++ keine gewöhnlichen Funktionsaufrufe nutzt. Viel mehr werden Methoden über so genannte Nachrichten aufgerufen. Ein Methodenaufruf unter Objective-C erfolgt dabei immer über die gleiche Anweisung ( [Empfänger Nachricht] ). Die Nachricht enthält sowohl den Bezeichner für die aufzurufende Methode als auch die zugehörigen Übergabe-Parameter.

Als Vermittlungszentrale dieser Nachrichten nutzt Objective-C die von iOS bereitgestellte objc_msgSend-Methode. Da alle Funktionsaufrufe zentral über diese objc_msgSend-Methode geleitet werden, ist es offensichtlich, dass es ebenso einen zentralen Weg gibt, um die aufgerufenen Funktionen zu beeinflussen.

Beim Wrapping wird durch das so genannte Method Swizzling, auf das Ausführen von alternativem Code, ohne dass der originale Quellcode der App verfügbar ist oder verändert wird, gesetzt.

Wie sicher ist das Wrapping?

Ändern sich die Methodenaufrufe, ändern sich auch die Anforderungen an die Wrapping Routinen. Um am Beispiel von iOS zu bleiben: hat Ihr Wrapping Anbieter den Datenabfluss erfolgreich unterbunden , war mit AirDrop auch mehrere Monate eine neue Funktion mit diesem Risiko trotzdem möglich. Auch wenn die alten Routinen von den früheren Abflussszenarien noch geschützt haben, wurde das Schutzschild löchrig aufgrund neuer Routinen in neuen iOS Versionen.

Kompatibilitäten mit dem Betriebssystem sind zusätzlich eine Herausforderung. Auch hier dient iOS als ein perfektes Beispiel. Im Jahr 2014 hat Apple die alternative Programmiersprache Swift vorgestellt.

Bei der Aufrufsemantik von Swift geht die Möglichkeit verloren, dynamische Manipulationen zur Laufzeit, wie es mit Objective-C Apps möglich ist, durchzuführen. Dies bedeutet, dass sich Methoden in Swift nicht per "Method Swizzling" überschreiben lassen. Ein gezieltes modifizieren des Programmablaufs wird durch die Funktionsweise von Swift erheblich aufwändiger, da keine generischen Hooking-Methoden mehr angewendet werden können.

Spätestens mit Überführung von Standard-iOS Bibliotheken in die Swift-Welt, werden klassische Betriebssystemfunktionen damit nicht mehr von Anbietern mit heutigen Lösungen, wrappbar sein. Mit iOS9 ist dies zwar noch nicht direkt der Fall, aber es ist eine Frage der - kurzfristig absehbaren- Zeit.

Transferieren und Deaktvieren von Wrapping

Die auf den ersten Blick gewonnene Sicherheit ist jedoch oft trügerisch. Um die am Anfang erwähnten Manipulationen des Wrapping-Prozesses durchzuführen, müssen entsprechende Bibliotheken per Code Injection in die zu schützende App überführt werden. Was sich wie ein komplizierter Prozess anhört, stellt für den versierten Angreifer eine einfache Vorgehensweise dar, egal auf welcher Zielplattform.

Um in diesem Artikel konsistent zu bleiben, greifen wir wieder das Beispiel iOS auf. In dem so genannten Header einer App sind allgemeine Informationen der App enthalten. Hier existiert auch der so genannte "Load commands" Bereich. Dort fügen die meisten Wrapping Anbieter ihre Bibliotheken ein. Hierzu wird die Struktur "struct dylib_command" mit der Konstante LC_LOAD_DYLIB verwendet. Dies wird durchgeführt, um die Wrapping Bibliotheken bei jedem Start einer App zu verwenden und das Method Swizzling anzuwenden.

Bei der Konstanten LC_LOAD_DYLIB, die dem Hex-Wert: 0xC entspricht, ist die verwiesene Bibliothek zwingend beim App-Start erforderlich. Alternativ dazu gibt es die Konstante LC_LOAD_WEAK_DYLIB, die dem Hex-Wert 0x18 entspricht, bei der diese Bibliothek nur optional vorhanden sein muss.
Mit einem Hexeditor, zum Beispiel Hexfiend, lässt sich durch eben diesen Hex-Wert der Eintrag von LOAD_DYLIB in WEAK_DYLIB ändern. Die Ändern dieses Bytes und das Entfernen der Bibliothek (.dylib) kann das Wrapping, bei Lösungsanbietern dieser Art, auf einem gekailbreakten iPad oder iPhone, deaktivieren.

Wie kann ein exemplarisches Angriffsszenario aussehen?

Durch einen Jailbreak sind die restriktiven Sicherheitsmaßnahmen der iOS Plattform außer Kraft gesetzt. Dies bedeutet konkret, dass Apps nun unter Root Berechtigungen laufen können und, dass durch die Deaktivierung der Signaturprüfung auch Apps aus fremden, nicht vertrauenswürdigen App Stores installiert werden können. Eine bösartige App ist also selbstständig durch die Root Berechtigungen in der Lage, die oben beschriebene Manipulation der Load Anweisung an der geschützten App durchzuführen. Die ausgehebelte Signaturprüfung sorgt gleichzeitig dafür, dass die fehlerhafte Integrität der manipulierten App nicht durch das iOS Betriebssystem bemerkt wird. Et voilà der Angriff ist vollzogen.

Blick über den Tellerrand

Ein kurzer Blick auf Android sollte der Vollständigkeit halber doch noch gewährt werden. Im Android Umfeld fällt auf, dass es viele Anbieter gibt, die ihre Sicherheitsbibliotheken im Zuge des Wrapping Prozesses einfach in der Main-Funktion der Android App im Java-Quellcode einbinden. Hier verhält es sich sehr ähnlich wie in der iOS Welt - wir hatten bereits die Ähnlichkeit der Verfahren erwähnt. Wird das Laden dieser Bibliothek im Java-Quellcode entfernt, so sind sämtliche Sicherheitsfunktionen auf einmal ausgehebelt.

Damit eine bösartige App diese Manipulation an der angegriffenen App durchführen kann, sind auch unter Android Root-Berechtigungen nötig. Das mobile Endgerät muss also gerooted sein.

Eine kleine Besonderheit gibt es jedoch schon in der Android Welt. Die Apps müssen nicht zwangsläufig über den offiziellen Google Playstore installiert werden und eine restriktive Signaturprüfung verglichen mit iOS ist ebenso nicht vorhanden.
Ein Angreifer könnte also zum Beispiel eine manipulierte, ungewrappte App in einem der alternativen App Stores anbieten. Warum sollten nun die Opfer diese App laden und nicht jene aus dem offiziellen Playstore? Die Unwissenheit der Anwender ist immer noch ein riesiges Problem, da oftmals nicht bekannt ist, dass diese alternativen Appstores mit äußerster Vorsichtig zu genießen sind. Ein weiterer fast noch wichtigerer Faktor ist monetärer Natur. Falls die offizielle, geschützte App auch noch Geld kostet, kann der Angreifer seine manipulierte Version billiger oder gar umsonst anbieten. Gemäß dem Motto geiz ist geil, wird es nicht lange dauern, bis arglistige Opfer die manipulierte App-Version auf dem Gerät installiert haben.

Fazit

Wir wollen hier keine detaillierte Anleitung geben. Auch das Diskreditieren einzelner Anbieter liegt uns fern. Viel mehr möchten wir Ihnen die Augen öffnen, dass die Versprechen von Wrapping individuell zu bewerten und den PPT-Slides oder Flyer-Versprechen der Anbieter nicht blind vertraut werden sollte

Unter den Plattformen am Markt, ist mit entsprechendem Wissen ein derartiger Eingriff möglich. Natürlich arbeiten Wrapping Anbieter auch hier mit Gegenmaßnahmen. Die Anbieter unterscheiden sich dabei in ihrer Qualität stark. Arbeiten einige mit aufwändigen Hash-Verfahren und nutzen tiefgreifende Verschleierungsverfahren, um die Schutzmaßnahmen integer abzusichern, so arbeiten andere Anbieter mit einfachen BASE64 Verschleierungen, die bereits Informatik Studenten des ersten Semesters Problemfrei aushebeln können. (bw)