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.