daily.out

Codesign-Ausnahme in iOS in Version 4.3 und 5

Apple hat offenbar mit iOS 4.3 eine Ausnahme beim Codesigning eingeführt, die nun auf ungeplante Weise verwendet wurde.

Codesigning, wie es sein sollte

Normal ist bei iOS, daß nur passend signierte Apps ausgeführt werden können. Um die Herkunft und Identität sicherzustellen, stellt Apple für die Entwickler die nötigen Zertifikate aus. Zum Vergleich: Bei Android darf man selbstsignierte Zertifikate benutzen, die nichts über die wahre Identität aussagen.

Apple untersagt das Nachladen von Code sowie undokumentierte versteckte Funktionen in iOS-Apps. Hat man eine nicht so offensichtliche Funktion in seiner App, dann muß man sie beschreiben. Auf keinen Fall jedoch möchte Apple, daß die App sich später anders verhalten kann als während des Reviews bei der Aufnahme in den Store. Damit wollen sie sicherstellen, daß das geprüfte und für gut befundene Verhalten auch beim Kunden noch so gegeben ist. Zum Vergleich: Bei Android ist das Nachladen von Code erlaubt.

Hausgemachte Lücke

Wie es technisch genau funktioniert wird Charlie erst Mitte November 2011 erzählen auf der SysCan 2011 Konferent in Taiwan. Hier ist sein Vortrag.

Nach den vorab vorliegenden Informationen sieht es jedoch danach aus, als hätte Apple in iOS 4.3 ein Ausnahme für Codesigning eingebaut, die auf unerwünschte Weise auch von Dritten verwendet werden kann.

Den anfänglichen Informationen nach ginge es darum, die in iOS 4.3 neu eingeführte JavaScript-Engine Nitro zu beschleunigen, wobei ihr angeblich ermöglicht wurde, unsignierten Code auszuführen. Diese Ausnahme sollte laut Gerücht eigentlich auf Safari und vertrauenswürdige Webseiten beschränkt sein und keinen anderen Apps zur Verfügung stehen. Das wäre natürlich eine Tradeoff zwischen Geschwindigkeit und Sicherheit.

Mit iOS 5.0.1 hat Apple den Logikfehler in mmap, einer Funktion für Hauptspeicher-Verwaltung, behoben, der es zuließ, daß eine übergebene ungültige Flag-Kombinationen zum Auslassen der Signatur-Prüfungen führen konnte.

Exploit-Beispiel InstaStock

Dr. Charlie Miller hat im September seine InstaStock.app in den AppStore gebracht, die das Problem demonstriert. Beim ersten Aufruf nach der Installation verbindet sie sich mit Charlies Server und fragt nach, ob es Code zum Nachladen gibt. Charlie hat dabei eingebaut, daß nur für den Fall, daß sich sein iPhone meldet, ein Payload tatsächlich angeboten wird.

So sah die Installation von InstaStock aus:

So sah InstaStock für normale Benutzung aus:

Mitte Oktober 2011, also circa einen Monat später, hat er Apple über das Problem informiert, ihnen allerdings nichts von seiner App im Store gesagt. Apple hat das Problem ihm gegenüber bestätigt. Anfang November 2011 hat er in einem Interview und einem YouTube-Video, von dem ich auch die Bilder entnommen habe, seine unerlaubte App geoutet.

Das Problem mit der InstaStock.app ist, daß sie gegen die grundlegenden Regeln des AppStores verstößt, nämlich Code nachladen kann und versteckte Funktionen enthält, und eine typische Malware-Funktionalität, eine Backdoor für Remote-Control, enthält. Da die App zu dieser Zeit schon circa zwei Monate im Store war, haben sie auch diverse User heruntergeladen. Die Malware mußte auf allen Geräten unschädlich gemacht werden. Steve Jobs hat vor einiger Zeit bestätigt, daß in iOS eine Funktion enthalten ist, die es Apple erlaubt, Programme zu löschen, falls eines, das beispielsweise User-Daten stiehlt, versehentlich in den App Store kommen sollte. Es wäre denkbar, daß Apple das nun gegen InstaStock verwendet hat.

Das Zurückziehen seines Entwickler-Zertifikates, mit dem Apps in den Store Review geschickt werden, wäre nicht ausreichend gewesen, denn Apple signiert die Apps für den Store mit einem eigenen Zertifikat, so daß iOS nur dieses prüfen muß, bevor es die jeweilige App startet. Anders ist das mit Enterprise-Deployment-Zertifikaten; diese akzeptiert iOS auch und damit signierte Malware könnte durch Rückruf des verwendeten Zertifikates unschädlich gemacht werden, weil iOS die Gültigkeit der Zertifikate periodisch mit Apple abgleicht.

Entwickler, die massiv gegen App Store-Richtlinien verstoßen, verlieren ihren Account und die Möglichkeit ihre Apps zu signieren. Das traf hier leider auch auf Charlie Miller zu. Weil er gegen die AppStore-Regeln verstoßen hat, hat Apple seinen Account für (mindestens) ein Jahr stillgelegt. Er kann von Glück reden, wenn er nicht verklagt wird wegen der in Umlauf gebrachten Malware. Im Oktober 2014 war Charlie immer noch verbannt, wie er auf Twitter bestätigte.

Charlie konnte die Malware-Funktion und den zugrundeliegenden Fehler in iOS auf seinem Entwicklergerät testen ohne daß er die App in den Store hochladen müßte. Im ging es darum, völlig sicher zu sein, daß seine Schadfunktion beim Prüfprozeß des AppStores nicht auffällt. Das war jedoch von vornherein klar, denn die Apps werden einerseits von Menschen auf Bedienbarkeit und GUI getestet und andererseits programmatisch auf unerlaubte Nutzung privater APIs und dergleichen geprüft.

Weil Charlies App jedoch einen bislang unbekannten Fehler nutzte, hatte der Reviewprozeß überhaupt keine Chance, die böse Funtionalität zu finden. Die Kommunikation mit seinem Server dürfte auch nicht groß auffallen, da die App von dort auch ihre Aktienkurse für ihre normale Funktion abfragt und der kurze Request nach einem Payload für die versteckte Funktion, der an denselben Server geht, dabei nicht auffällt.

Korrektes Vorgehen wäre gewesen, seine Exploit-App per Bugreporter an Apple zu schicken. Sie hätten damit sowohl den Fehler in iOS früher schliessen können, da sie es einen Monat früher erfahren hätten, als auch den Review-Prozeß intern testen können und die App nicht unnötigerweise an die Öffentlichkeit gelangen lassen.

Charlie wollte jedoch wie gewohnt die pressewirksame Öffentlichkeit und hat allen Ernstes geglaubt, Apple würde die App aus dem Store löschen und sie wären weiter Freunde. Die Store-Regeln brechen, wochenlang die App im Store verheimlichen und Malware verbreiten ist nicht gerade eine gute Basis für Freundschaft. Er nahm an, ihm würde sonst niemand glauben, daß es die App in den Store schaffen würde.

InstaStock.app konnte beliebigen unsignierten Code vom Server nachladen und ausführen. Der nachgeladene Code konnte alles tun, was der Trojaner-App erlaubt ist: Also Zugriff auf das Adreßbuch beispielsweise haben. Die App hat jedoch weiterhin nur Userrechte und keinen Root-Zugriff.

Und so sah die Abfrage der Aktienkurse auf Charlies Server aus:

So sah es auf Charlies Server aus, wenn die InstaStock.app sich mit ihm verbunden hatte und nachgeladenen Code ausführt. In diesem Fall einen Shell-Zugriff, mit dem er manuell das Adreßbuch, auf das jede App Zugriff hat, herunterlädt:

Charlie sagt, mit diesem Bug fiele iOS auf die Sicherheit von Android herunter:

Apple hat die Ausnahme für unsignierten Code jetzt zwar besser abgesichert, aber sicherheitstechnisch perfekt fände ich es, diese Ausnahme komplett wieder herauszunehmen, so wie es vor iOS 4.3 war. Den hohen Sicherheitslevel von iOS für etwas mehr Geschwindigkeit im Browser zu riskieren, halte ich für nicht die beste Idee.

---