Behind the scenes: iOS 6.0 Jailbreak unter der Lupe

By ,

note: this article is in german. if you are interested in english i suggest the original article posted here

Das evad3rs Team hat ja gestern den neuen untethered Jailbreak für iOS 6.1 rausgebracht. Lange erwartet und vor allem sehr lange seit dem letzten untethered Jailbreak. Umso interessanter ist es daher mal einen kleinen Blick unter die Haube zu werfen und sich etwas mit den verwendeten Techniken zu beschäftigen. Die Jungs von accuvantlabs haben dies getan und ich möchte euch hier in deutsch davon erzählen :)

Schritt für Schritt durch den iOS 6.1 Jailbreak

Wir werden uns heute hier nur auf den userland Bereich konzentrieren. Dieser ist ziemlich einzigartig, denn er basiert bei Evasi0n rein auf Dateisystem Ebene. Es wird keine "memory corruption" benötigt um Admin Rechte zu erlangen.
Wer sich dafür interessiert wie exploits mit "memory corruptions" aussehen kann hier einen kleinen Artikel mit Anleitung lesen ( auf englisch)

Evasi0n operiert in den unten beschriebenen 3 Phasen. Alle 3 Phasen laufen auf dem iPhone dank des MobileBackup. Dieser Dienst wird zum zurückschreiben von iPhone Backups benutzt. Bedingt dadurch, das Backups über verschiedene Devices hinweg benutzt werden können müssen(z.B. iPhone 3GS Backup auf einem iPhone 5) kann Apple diese Backups auch nicht signieren, weshalb Sie aus technischer Sicht unsignierte Daten sind.

MobileBackup benutzt sowohl eine Domain ( MediaDomain in unserem Fall) und einen relativen Pfad um jede Datei zu identifizieren. Ein statischer absoluter Pfad in Zusammenhang mit der Domain und dem relativen Pfad ergibt den vollständigen absoluten Pfad einer Datei. Evasi0n erstellt alle seine Dateien in "MediaDomain" daher sind alle Dateien innerhalbt von /var/mobile/Media.

Phase 1

In Phase 1 wird ein neuer Backup erstellt und auf die iDevice aufgespielt. Dieser Backup enthält nur folgende Dateien:

  • Verzeichnis: Media/
  • Verzeichnis: Media/Recordings/
  • symlink: Media/Recordings/.haxx -> /var/mobile
  • Verzeichnis: Media/Recordings/.haxx/DemoApp.app/
  • Datei: Media/Recordings/.haxx/DemoApp.app/Info.plist
  • Datei: Media/Recordings/.haxx/DemoApp.app/DemoApp
  • Datei: Media/Recordings/.haxx/DemoApp.app/Icon.png
  • Datei: Media/Recordings/.haxx/DemoApp.app/Icon@2x.png
  • Datei: Media/Recordings/.haxx/DemoApp.app/Icon-72.png
  • Datei: Media/Recordings/.haxx/DemoApp.app/Icon-72@2x.png
  • Datei: Media/Recordings/.haxx/Library/Caches/com.apple.mobile.installation.plist

Interessant hierbei ist der symlink. Normalerweise müssen alle Dateien die über den Backup hochgeschoben werden ja innerhalb des Verzeichnis /var/mobile/Media sein. Durch den symlink wird erreicht, dass diese Beschränkung umgangen wird. Jede Datei und jeder Ordner der innerhalb von Media/Recordings/.haxx angelegt wird, wird eigentlich nach /var/mobile geschrieben.
Eine kreative Art und einfache Möglichkeit entsprechende Beschränkungen zu umgehen. Neu ist dies allerdings nicht. Kam diese Technik doch schon in vergangenen Jailbreaks zum Tragen.

Nach dem Symlink wird eine App namens "DemoApp.app" kopiert. Diese beinhaltet alles was notwendig ist inklusive Icons und drumrum. Die App wird auch in die com.apple.mobile.installation.plist eingetragen damit das "Springboard" weiss wo die App ist und die App so auf dem Home Bildschirm anzeigen kann.

Info: Hier erklärt sich auch, warum manche user Probleme nach dem Jailbreak mit der Wetterapp etc haben. Die .plist Datei scheint entweder leicht fehlerhaft oder nur für ein bestimmtes Gerät gedacht gewesen und verursacht dadurch Probleme. Ein Löschen und Neuerstellen behebt diese allerdings auch schon wieder :)

Diese DemoApp wiederum ist recht interessant, da sie nur aus folgendem besteht:

#!/bin/launchctl submit -l remount -o /var/mobile/Media/mount.stdout -e /var/mobile/Media/mount.stderr -- /sbin/mount -v -t hfs -o rw /dev/disk0s1s1

Hier wird der launchctl mit speziellen Argumenten gestartet. Gleichzeitig wird eine Umgebungsvariable in der com.apple.mobile.installation.plist festgelegt:

key>EnvironmentVariables
dict >
key>LAUNCHD_SOCKET /key>
/private/var/tmp/launchd/sock /string>
/dict>

Phase 1 endet damit, dass das Gerät neu gestartet wird und die DemoApp dem User angezeigt wird.

Phase 2.1

Nachdem in Phase 1 alle benötigten Dateien an ihren Platz gepackt wurden wird in Phase 2 zunächst ein frisches neues Backup angelegt um mehr Dateien auf euer Gerät zu bekommen.

  • directory: Media/
  • directory: Media/Recordings/
  • symlink: Media/Recordings/.haxx -> /var/db
  • symlink: Media/Recordings/.haxx/timezone -> /var/tmp/launchd

Grundlegend wird hier via des ersten Symlinks ein zweiter Symlink angelegt der /var/db/timezone heisst und auf /var/tmp/launchd zeigt. Die normalen Zugriffsrechte auf /var/tmp wären: 700 root/wheel
Dies verhindert normalerweise, dass Apps die unter dem Benutzer "user" laufen in das Verzeichnis kommen.

Als nächstes wird dem Dienst "lockdownd" eine Anfrage geschickt, die verändert wurde um /var/db/timezone die Rechte 777 zu geben und es damit verfügbar und zugreifbar zu machen. "lockdownd" ist der Dienst der Befehle via USB empfangen und darauf reagieren kann. Er wird zum Beispiel dafür benutzt andere Dienste via USB zu starten oder stoppen. Da "lockdownd" als root läuft UND alle Benutzer mit Ihm kommunizieren können, wurde er auch bereits in der Vergangenheit gerne benutzt.

Phase 2.2

In Phase 2.2 geht es etwas tiefer in /var/tmp/launchd. Jetzt werden die Zugriffsrechte im System so verändert, dass der launchd socket auch für jeden Benutzer zugreifbar ist. In dieser Phase wird der timezone Symlink wie folgt geändert:

Media/Recordings/.haxx/timezone -> /var/tmp/launchd
wird zu
Media/Recordings/.haxx/timezone -> /var/tmp/launchd/sock

Wie bereits in Phase 2.1 wird wieder die bereits benutzte Anfrage an lockdownd gesendet um auch die sock Datei mit 777 Rechten auszustatten.

Phase 2.3

Jetzt wird sowohl Cydia als auch ein packagelist tarfile auf das Gerät geladen. Beide sind direkt in der .exe enthalten und können z.b. mit Visual Studio angeschaut werden. Diese 2 Dateien werden noch nicht benutzt sondern nur hochgeladen.

Der Benutzer wird nun aufgefordert die Jailbreak App auszuführen. Dies ist die in Pase 1 hochgeladene DemoApp. Wir erinnern uns, dass diese nur aus einem Bash Befehl bestand in dem launchd mit Parametern aufgerufen wird.

launchd IPC Mechanismus arbeitet mit unix domain sockets und damit unterscheidet er sich von normalen iOS Diensten. Es gibt mehrere launchd Prozesse. Je einer pro Benutzer. Im Falle von iOS wären dies: root und mobile. Mit der DemoApp wird also launchctl vom Benutzer aufgerufen und läuft damit als "mobile". Die Besonderheit: launchctl kommuniziert nicht mit dem eigentlichen "launchd" des Benutzers "mobile" sondern mit dem "launchd" des Benutzers "root" . Dies wird durch die in Phase 2.2 vorgenommenen Änderungen an der Datei sock erreicht.

Da die DemoApp also launchd von root aufruft läuft der gesamte Job als root. Der Job mounted dabei die Systempartition als read/write und macht es so möglich permanente Änderungen vorzunehmen die unter dem Benutzer root bereits in einer frühen boot-Umgebung ausgeführt werden.

Phase 3

Jetzt kommen wir zur finalen Phase des Jailbreaks. Alles beginnt mal wieder mit einem Backup. Diesmal haben wir jedoch die Möglichkeit des Vollzugriffs auf die System Partition.

  • Datei: Media/
  • Verzeichnis: Media/Recordings/
  • symlink: Media/Recordings/.haxx -> /
  • symlink: Media/Recordings/.haxx/private/etc/launchd.conf -> /private/var/evasi0n/launchd.conf
  • Verzeichnis: Media/Recordings/.haxx/var/evasi0n
  • Datei: Media/Recordings/.haxx/var/evasi0n/evasi0n
  • Datei: Media/Recordings/.haxx/var/evasi0n/amfi.dylib
  • Datei: Media/Recordings/.haxx/var/evasi0n/udid
  • Datei: Media/Recordings/.haxx/var/evasi0n/launchd.conf

Das Ganze sieht jetzt etwas unübersichtlich aus, da hier viel mit Symlinks gearbeitet wird aber im Grunde wird einfach nur ein Verzeichnis /var/evasi0n erstellt in das eine ausführbare Datei, eine Bibliothek und eine neue launchd.conf kopiert werden.

Mit der neuen .conf Datei werden Parameter für den Bootvorgang vergeben. Dies führt dann zu folgenden Schritten während des bootens:

  • System Partion schreibend einbinden
  • amfi.dylib in jede App einfügen die nach launchd läuft. (das ist die vorher kopierte Bibliothek)
  • Laden des MobileFileIntegrity Dienstes
  • Ausführen des ausführenbaren Programmcodes (die vorher kopierte Datei)
  • Rückgängig machen der Änderung in Punkt 2
  • Löschen einer evtl. vorher vorhandenen sock Datei in /private/var/evasi0n/
  • Erstellen eines Symlinks von /var/tmp/launchd/sock nach /private/var/evasi0n/sock um jedem Programm die Möglichkeit zu geben als Root zu laufen.

Nachdem die Dateien kopiert wurden wird das Gerät neu gestartet und damit die Liste oben ausgeführt.

Interessant sowohl an der Bibliothek als auch an dem evasi0n programm ist, dass beide nicht signiert wurden. Sieht man sich amfi.dylib genauer an (mit otool) bemerkt man, dass kein TEXT/text Bereich existiert. Da kein TEXT/text Bereich bedeutet, dass es nichts zu signieren gibt umgeht man so die Signaturprüfung.

Die Bibliothek enthält nur "lazy binding" Informationen. Die Technik dazu wird beschrieben.

Mit dieser sehr schlauen Technik des Erzeugens von Bibliotheken ohne code kann man existierende gültige Methoden als andere Methoden mit der selben Signatur reexportieren. Dies sorgt dann dafür, dass MISValidateSignature immer 0 zurückgibt und damit jede unsignierte Anwendung laufen kann.

Sicherheitsvorteile des neuen Jailbreaks via USB

Ein wichtiges Thema auf einem iDevice ist sicherlich immer die Sicherheit. Gerade im Geschäftsumfeld ist es wichtig, das Daten auf dem Gerät geheim bleiben. Allerdings gilt dies auch im privaten Bereich. Soll ja nicht jeder an jede noch so kleine Information rankommen.

Bei einem Verlust des iPhones war es in der Vergangenheit so, dass trotz Passwortsperre das Gerät gejailbreaked werden konnte und damit kam man natürlich auch an die Daten ran.

Aufgrund der technischen Natur des neuen iOS 6.1 Jailbreaks geht dies nun nicht mehr. Um den Jailbreak aufspielen zu können muss die Passwortsperre entfernt werden. ( Es sei denn, das iPhone / iPad wurde bereits vorher mal mit dem PC verbunden auf dem man den Jailbreak ausführen will).

Fazit und Zusammenfassung

Evasi0n ist wirklich interessant aufgebaut. Es umgeht Beschränkungen und hat vollen Zugriff auf die System Partition ohne auch nur ein "memory corruption" zu nutzen. Es nutzt einen Exploit im /var/db/timezone Programm aus um Zugriff auf den launchd socket zu erhalten. Dann benutzt launchd um MobileFileIntegrity aufzurufen, das wiederum eine Bibliothek ohne Quellcode enthält. Die Bibliothek überschreibt die Funktion MISValidateSignature, so dass diese immer 0 zurück gibt.

Ich hoffe ich konnte euch ein bißchen zeigen, wie der aktuellste Jailbreak eigentlich so funktioniert.
Wenn euch der Artikel gefallen hat freuen wir uns immer über ein +1, einen Twitter Post oder sonstiges :)

Einen schönen Tag aus Stuttgart wünscht

Matthias

You liked this post? Give us a +1 :)



Related Posts

Leave a Comment

Comments are moderated. Please don't spam.