CSI MacMark: Jekyll

Tielei Wang, Kangjie Lu, Long Lu, Simon Chung, und Wenke Lee vom Georgia Institute of Technology haben einen technisch sehr interessanten Konzept-Schädling für iOS vorgestellt und testweise für kurze Zeit in den iOS App Store gebracht sowie mit Apple anschließend zusammengearbeitet. Allerfeinster Stoff für eine neue Folge "Crime Scene Investigation" aus der Serie "CSI:MacMark".

Dr. Jekyll und Mr. Hyde

Apples iOS gilt als eines der sichersten Betriebssysteme überhaupt. Im Gegensatz zu vielen anderen Plattformen ist das Nachladen von Code verboten, damit die App nicht nachträglich ihr Verhalten um böse Features erweitern kann. iOS-Entwickler dürfen keine dynamischen Libraries einbinden und können das auch nicht auf normalem Wege, weil die Nutzung entsprechender Funktionen auffallen würde. Android hingegen erlaubt das.

Falls eine App dennoch Code nachlädt, auf welche Weise auch immer, steht sie vor einem noch größeren Problem: Alle Apps im Store sind von Apple signiert und nur so signierter Code wird vom System ausgeführt. Eine bekannte Ausnahme bildet leider der Just-In-Time-Compiler für JavaScript in Mobile Safari.

Was tut man nun, wenn man keinen Code einschleusen kann? Man verwendet den vorhandenen Code und zwar nicht im Sinne des Erfinders, indem man lediglich die Reihenfolge der Anweisungen verändert. Wenn ein Programm die Schritte

1. Schwimmweste anziehen
2. Ins Wasser springen

enthält, dann ist das okay, solange man die Reihenfolge nicht ändert. Und genau das tut die hier diskutierte Konzept-Malware. Aus einem völlig braven Programm wird ein böswilliges, indem die Ausführungsreihenfolge verändert wird.

ROP reloaded

Ähnlich wie beim Return-oriented-Programming, bei dem auch vorhandene Anweisungen recycled werden, indem mit Puffer-Überläufen der Stack so manipuliert wird, daß das Programm seine Arbeit an ungeplanten Stellen fortsetzt, geht auch die Jekyll-App vor. Allerdings hat sie es leichter, weil sie vom gleichen Entwickler kommt und dieser nicht erst nach passenden Code-Teilen fürs Recycling in einem fremden zu beeinflussenden Programm suchen muß, sondern die passenden "Gadgets" schonmal vorab in seine App einbaut.

Beim normalen ROP wird der Pufferüberlauf durch eine passende fehlerhafte Eingabe an das Programm ausgelöst. Bei der Jekyll-App passiert das auch, allerdings von langer Hand geplant: Es sind in der Ziel-App nicht nur schon die passenden Code-Teile (Gadgets) vorhanden, sondern auch die nötigen Bugs eingebaut, die den Pufferüberlauf ermöglichen und damit den Programmablauf verändern, indem die gewünschten Gadgets angesprungen werden.

Review zwecklos

Die Entwickler dieser Jekyll-App weisen auf zwei wichtige Umstände hin: Es ist praktisch unmöglich, alle solche ausnutzbaren, absichtlich oder unabsichtlich eingebauten, Bugs in einem Programm zu entdecken. Ferner ist es nicht zuverlässig möglich, die mißbrauchbaren "Gadgets" in einem Programm zu entdecken, selbst wenn man den Quellcode vorliegen hat. Es gibt sogar Wege, solche Gadgets in Open Source Projekten so zu verstecken, daß man ein Code-Audit damit übersteht.

Damit steht Apple vor einem ähnlichen Problem wie die Antiviren-Industrie: Man kann eine Software nicht zuverlässig auf Gut- oder Bösartigkeit beurteilen. So wie man mit einem Messer sein Brötchen schmieren oder jemanden verletzen kann, ist ein und die gleiche Programm-Anweisung für gute oder schlechte Zwecke einsetzbar. Man sieht es ihr nicht an.

Eine dynamische Analyse hilft auch nicht viel weiter, weil die App die Untersuchung vom normalen Einsatz unterscheiden kann oder einfach erst nach 8 Wochen auf bösartig umgeschaltet wird, wenn sie schon lange online ist.

Private APIs

Die Jekyll-App nutzte auch private APIs, um bösartiges Verhalten zu demonstrieren. Private APIs dürfen von iOS-Entwicklern nicht benutzt werden und können von Dritt-Apps nicht direkt geladen werden, weil das auffallen würde. Darum haben sie in ihren Gadgets Trampolin-Funktionen aus öffentlichen Frameworks benutzt, die die jeweils absolute Adresse der Funktionen dlopen() und dlsym() direkt anspringen. Diese Funktionen dienen dem Laden und Linken einer dynamischen Library sowie dazu, enthaltene Funktionen in diesen Libs aufzufinden, um sie dann verwenden zu können.

Durch die Nutzung privater APIs konnte ihre App mehr tun, als normalerweise ohne Zustimmung des Benutzers möglich wäre. Apple hat diese privaten APIs jedoch in iOS 6 bereits schon teilweise besser geschützt, so daß nicht mehr jeder Mißbrauch möglich war auf diese Weise. Mit iOS 7 kann man weitere Schritte in diese Richtung erwarten zumal auch die Jekyll-Entwickler mit Apple kooperieren in dieser Sache.

Was nun?

Dieser Angriff zeigt, daß ein wesentlich größerer Aufwand als bei anderen Plattformen nötig ist, um iOS anzugreifen. Der Aufwand, der hier getrieben wurde, ist überall anders völlig unnötig. Apple hat inzwischen noch nicht alles, aber fast alles getan, um iOS extrem sicher zu machen. Den Review-Prozeß zu verbessern, hat bei dieser Art Angriffen wenig Sinn; die privaten APIs besser abzuschirmen, schon eher.