Sicherheitsmechanismen in ios

Transkript

1 Sicherheitsmechanismen in ios Master-Seminar: Betriebssystemsicherheit und Trusted Computing WS 2012/13 Stephan Görgens Matr.Nr.: Februar 2013 Zusammenfassung Das Smartphone, unser ständiger Begleiter, bestimmt unser Leben und unsere Arbeit jeden Tag mehr. Zunehmend werden Informationen und sensible Daten, wie beispielsweise geschäftliche s oder Daten aus Bankgeschäften, gespeichert. Der Schutz vor Informationsdiebstahl auf Firmeneigenen Notebooks ist mittlerweile Standard und wird auch auf Smartphones zunehmend bedeutender. Diese Entwicklung soll folgend speziell am Apple Betriebssystem ios betrachtet werden. Die Sicherheitsarchitektur und der Signierungsprozess der Applikationen sowie die Sicherheitsprobleme, die ein Jailbreak mit sich bringt, werden näher erläutert. I

2 Inhaltsverzeichnis Abkürzungsverzeichnis Abbildungsverzeichnis Tabellenverzeichnis III IV IV 1 Einleitung 1 2 Grundlagen mobiles Betriebssystem ios 1 3 ios Sicherheitskonzept Secure Boot Chain Apple Software Personalisierung Over The Air Lokales Update App Code Signing Developer certificates Provisioning Profiles Signed applications Entitlements Code Signing Enforcement und Dynamic Code Signing StackGuard Sandboxing Runtime Process Security Encryption and Data Protection File Data Protection Schutzklassen Remote Wipe Networksecurity Jailbreak Jailbreak Arten Hardwarehacks Erkennen eines Jailbreaks Jailbreak Beispiel Auswertung 14 6 Ausblick 16 Literaturverzeichnis 18 Appendices 20 II

3 Abkürzungsverzeichnis API Application Programming Interface ASLR Adress Space Layout Randomization CA Certificate Authority CBC Cipher Block Chaining CFG Control Flow Graph CFI Control Flow Integrity CSE Code Signing Enforcement DCS Dynamic Code Signing GM Golden Master IV Initialisierungs Vektor JIT Just In Time Compiler LFSR Linear Rückgekoppeltes Schieberegister LLB Low Level Bootloader MCS Mandatory Code Signing MDM Mobile Device Management PIE Position Independent Executable PIN Persönliche-Identifikations-Nummer OS Operating System OTA Over The Air RAMdisk Random Access Memory disk ROM Read Only Memory RNG Random Number Generator ROP Return Oriented Programming SMS Short Message Service SSL Secure Sockets Layer TLS Transport Layer Security III

4 Abbildungsverzeichnis 1 Systemarchitektur ios Bootvorgang Bootvorgang Recovery Warnung beim ersten Start dynamic-codesining entitlement des mobilesafari Prinzip der Apple Sandbox Überblick Verschlüsselung Remote Wipe per icloud Remote Wipe per icloud - iphone löschen Esser zum Thema Jailbreak ios Esser zum Thema Jailbreak ios Tabellenverzeichnis 1 Developer program Apple Schutzklassen Mobile Security Projekt: Top 10 Mobile Risks Apple Prozessorfamilie Apple ios Softwarestände/Jailbreak - iphone Modelle (Ger) Apple ios Softwarestände/Jailbreak - ipad Modelle (Ger) Apple ios Softwarestände/Jailbreak - ipod touch Modelle (Ger) Apple ios Softwarestände/Jailbreak - Apple TV Modelle (Ger) IV

5 1 Einleitung Der Begriff Informationszeitalter ist schon alt, aber Informationen und Wissen sind trotzdem eines der wichtigsten Güter unserer Zeit. Diese Erkenntnis ist nicht neu, aber die Form ändert sich ständig. Smartphones haben sich schon längst als ständiger Begleiter und Informationsquelle Nr. 1 durchgesetzt. Nicht nur Diskussionen über Nachrichten sind häufig im privat Bereich verstummt, weil ständig Zugriff auf alle Informationen gewährleistet ist, sondern auch das Berufsleben mit seinen Informationen hat Einzug in den Alleskönner gehalten. Das Bild vom privaten Handy und vom Business Handy hat sich dahingehend gewandelt, dass beide miteinander verschmilzen und damit für Firmen nicht nur neue Möglichkeiten, sondern auch neue Sicherheitsrisiken entstehen. Datenschutz ist heute wichtiger denn je, weil nicht mehr nur private Daten, sondern auch Firmeninterna einen Platz auf unseren Smartphones finden. Diese neuen Gegebenheiten müssen von aktuellen Mobiltelefonen unterstützt werden damit sie auf dem Markt eine Chance haben. Genau diese Punkte lassen die Frage aufkommen wie sicher unser Smartphone ist. Im diesem Fall wird Apples iphone und sein Betriebssystem für mobile Geräte ios betrachtet. 2 Grundlagen mobiles Betriebssystem ios Das mobile Betriebssystem ios von Apple basiert auf dem Desktop-Betriebssystem Mac OS X, welches seinerseits wieder auf Darwin, einem frei erhältlichen proprietären Betriebssystem, basiert. Im Kern steckt in allen Betriebssystemvarianten ein XNU-Kernel, der entsprechend für Apple Computer und später auch für mobile Geräte angepasst wurde. Der grobe Aufbau der Systemarchitektur lässt sich wie folgt beschreiben: Abbildung 1: Systemarchitektur ios 1 Die abgebildeten Schichten zeigen das Betriebssystem ios etwas abstrahiert, wobei sich die drei untersten Schichten weniger von OS X unterscheiden als das für die mobile 1 In Anlehnung an Apple ios Technology Overview[16] 1

6 Anwendung entwickelte Cocoa Touch. Core OS Beinhaltet low-level features z. B. das Security Framework. Core Service Beinhaltet die grundlegenden System Services. Media Beinhaltet Technologien zur Darstellung von Grafik, Video und Sound. Cocoa Touch Definiert die grundlegenden Programmstruktur und die high-level System Services. Welche Anforderungen sollte ein mobiles Operating System (OS) im Hinblick auf die Sicherheit erfüllen? Datenintegrität Verändern der Daten nur durch autorisierten Benutzer. Informationsvertraulichkeit Keine unautorisierte Informationsgewinnung möglich. Authentizität Der Benutzer bzw. die benutzte Applikation besitzt eine nachprüfbare Identität. Verbindlichkeit Aktionen können auf ihre Quelle zurückgeführt werden. 3 ios Sicherheitskonzept iphone, ipad und ipod touch wurden mit verschiedenen Schichten (Layern) an Sicherheitstechnik entwickelt. Die untersten Schichten (low-level) dienen zur Hardwareverschlüsselung, zum Schutz der Firmware sowie zum Schutz vor Malware und Viren. Die high-level Schutzmechanismen dienen zum Schutz persönlicher Informationen und Firmendaten und verhindern den unerlaubten Zugriff auf das Gerät[08]. 3.1 Secure Boot Chain Jeder Schritt des Bootprozesses ist verschlüsselt und lässt sich nur mit einer Signatur von Apple öffnen und laden. In jedem Schritt steckt der Schlüssel, der für den nächsten Schritt benötigt wird. Somit kann die Bootkette nicht unterbrochen und kein Schadcode eingeschleust werden. Im ersten Schritt wird das ios Device eingeschaltet und der Code aus dem Read Only Memory (ROM) geladen. Dieser Schritt ist sicher, da aus dem ROM nur gelesen werden kann und die dort vorliegenden Daten bei der Herstellung in das Gerät geschrieben wurden. Das sogenannte Wurzelzertifikat, welches durch Apple (Certificate Authority (CA)) signiert wurde. Das Root Zerftifikat wird genutzt, um mit dem öffentlichen Schlüssel die Signatur des Low Level Bootloader (LLB) zu überprüfen bevor ihm erlaubt wird sich zu laden. Wenn der LLB geladen wurde und sichergestellt ist, dass sein Zertifikat von Apple stammt, kann der 2

7 nächste Schritt im Bootprozess erfolgen. In jedem Schritt wird geprüft, ob das Zertifikat korrekt ist um den entsprechenden Teil zu laden (siehe Abbildung: Bootvorgang). Dieser Prozess wird boot-chain genannt und stellt sicher, dass nur von Apple signierte Software geladen wird. Wenn diese boot-chain nicht eingehalten wird bricht der Bootvorgang ab. Daraufhin ist der User aufgefordert das Gerät mit itunes zu verbinden, um es in den Auslieferungszustand zurückzusetzen. Dieser Zustand wird Recovery Mode genannt und setzt das Gerät in den default Zustand zurück. Abbildung 2: Bootvorgang 2 Abbildung 3: Bootvorgang Recovery Apple Software Personalisierung Durch den sicheren Bootprozess kann nur ein von Apple signierter Code auf dem Device installiert werden. Um zu verhindern, dass ein Downgrade installiert wird, welches bereits geschlossene Sicherheitslücken wieder öffnet, benutzt ios den Prozess system software personalization. Hier wird zwischen zwei Arten der Softwareaktualisierung unterschieden. Bei der Over The Air (OTA) Update Prozedur wird nur der Teil der Software erneuert, der nicht dem aktuellen Stand entspricht, während bei der USB Methode das gesamte System neu aufgespielt wird Over The Air Während der Installation wird eine Verbindung zu dem Apple Autorisations Server aufgebaut, um cryptographic measurements für jeden zu installierenden Teil zu bestätigen. Informationen werden zum Softwarestand des Low Level Bootloader (LLB), iboot, Kernel, OS-Image, eine Zufalls-anti-replay-Zahl und die Device ID übertragen. Wenn eine neuere Version vorliegt wird die Device ID vom Apple Server signiert und eingefügt. Danach kann das Paket an das Device geschickt und der Installationsprozess gestartet werden. Die boot-time chain-of-trust versichert sich, dass die Signatur von Apple stammt und lässt die Installation zu. Anderenfalls wird die Installation verweigert Lokales Update Bei einer Installation über itunes wird das komplette ios neu geladen und installiert. Hierfür muss das Zertifikat nur an den Bootloader angepasst werden. Dieses geschieht, wie schon im vorherigen Abschnitt beschrieben, mit einem Vergleich der Softwareversion und dem Signieren der Device ID durch Apple. 2 Eigenwerk 3 Eigenwerk 3

8 3.3 App Code Signing Um sicherzustellen, dass auf einem ios Device nur der Code ausgeführt wird, den der User ausführen möchte, muss jede Applikation mit einem Zertifikat ausgestattet sein. Dieser Schutzmechanismus nennt sich Mandatory Code Signing (MCS). MSC dient als Basis des code signing Modells von ios und enthält folgende Entitäten: Developer certificates Provisioning profiles Signed applications Entitlements Developer certificates Das developer certificate unterscheidet nochmals vier Varianten mit unterschiedlichen Rechten. Das Einfachste ist der Apple Developer, der mit Hilfe von Xcode (der Apple eigenen Entwicklungsumgebung) Apps programmieren und testen kann. In dieser untersten Stufe besteht keine Möglichkeit die eigene Software auf einem Apple Device zu testen. In der nächsten Stufe, dem University Programm, wird den Entwicklern das Testen auf dem eigenen Device ermöglicht. Alle anderen Möglichkeiten bleiben auch hier verwehrt. Des weiteren besteht die Möglichkeit eines Standardprogrammes und des Enterpriseprogrammes. Diese beiden Profile unterscheiden sich nur in ihrer Verteilung der programmierten Apps. Im Einzelnen bedeutet es, dass der Entwickler (Standard oder Enterprise) sich bei Apple durch das Hinterlegen einer Kreditkarte und dem damit gezahlten Jahresbeitrag authentifiziert. Diese Authentifizierung räumt ihm mehr Rechte ein. Ab Standard- Entwickler ist das Testen auf eigenen Geräten erlaubt, und der Vertrieb (egal ob kostenlose oder bezahlte App) sowie das Verteilen der App geschieht durch den Apple eigenen App- Store. Diese Trennung geschieht aus dem Grund, dass Apple alle Apps mit einem Zertifikat versieht und diese erst nach dem Signierungsprozess lauffähig auf dem Device sind. Zusätzlich findet ein Review Prozess durch Apple statt, in dem die Apps durchgeschaut werden. In welcher Form und wie weit Dieses geschieht ist unklar und wird von Apple auch nicht publiziert. Neben dem Standard-Entwickler gibt es noch das Enterpriseprogramm, welches sich, wie im vorherigen Abschnitt schon erwähnt, nur in der Verteilung der Software unterscheidet. Diese Stufe der Entwicklung ist für große Firmen gedacht, die Software für ihre speziellen Zwecke entwickelt. Die Software wird dann auch nicht durch den AppStore von Apple vertrieben, sondern durch einen Hauseigenen. Die Prozesse sind ähnlich dem des Standard- Entwicklers, aber gehen beim Enterprise-Entwickler im eigenen Haus weiter und werden weniger durch Apple begleitet. Nur das Signieren muss immer noch durch Apple sichergestellt werden. 4

9 Developer Program Device testing Ad Hoc App Store In House Apple-Developer No No No No University-Program Yes No No No Standard-Program Yes Yes Yes No Enterprise-Program Yes Yes No Yes Tabelle 1: Developer program Provisioning Profiles Provisioning Profiles sind von Apple signierte plist 5 Files, die dem ios-gerät erlauben Code von zertifizierten Entwicklern auszuführen. Die plist ist selbst von Apple zertifiziert und somit in der Lage weitere Zertifikate zu öffnen. Wenn die zu entwickelnde Software auf dem Gerät selbst getestet werden soll, weil nicht alles in der Entwicklungsumgebung simuliert werden kann, muss das bei Apple registrierte ios-device von Apple in das provisioning profile aufgenommen werden. Bei dem Standard- Entwickler können bis zu 100 Geräte in das Ad-Hoc Distribution Provisioning Profile aufgenommen werden. Beim Enterprise Provisioning Profiles wird auch die hausinterne Verteilung der Apps darüber geregelt Signed applications Jeder ios-code muss durch ein Zertifikat zertifiziert sein. Damit ein neues Zertifikat installiert werden kann muss das Apple provisioning profile, welches im vorigen Abschnitt beschrieben wurde und durch Apple selbst zertifiziert ist, erweitert werden. Wenn eine App installiert wird, die nicht über den AppStore gekauft ist, wird beim ersten Start eine Warnmeldung ausgegeben. Diese weist darauf hin, dass es sich um eine unsignierte App handelt. Im Warnungsfenster wird der Name der Software und der Entwickler mit seinem Developer-Zertifikat genannt. Hier ist es dem Benutzer überlassen, ob er das Ausführen bestätigt oder abbricht. 4 In Anlehnung an Apple ios Security May 2012[08] 5 plist ist ein Apple XML Format 5

10 Abbildung 4: Warnung beim ersten Start Entitlements Signierte Applikationen können in ihrem plist file spezielle Privilegien fordern. In der plist finden sich verschiedene Schlüssel, sogenannte Entitlements, bei der jeder Schlüssel ein Privileg darstellt. Diese Schlüssel hängen mit dem entsprechenden Developer-Zertifikat zusammen. Auf diesem Weg kann Apple Entwicklern und ihren Applikationen mehr Rechte einräumen. 3.4 Code Signing Enforcement und Dynamic Code Signing In ios 2 wurde der Code Signing Prozess und die Trennung zwischen root und user eingeführt, wodurch nur signierter Code ausgeführt werden konnte. Die Idee war, dass das Einschleusen von Code während der Laufzeit nicht möglich sein sollte und es wurde dem Programmcode die Möglichkeit genommen sich selbst zu verändern, wie es z. B. in Malware in der Regel der Fall ist. Diese Technik firmiert unter dem Namen Code Signing Enforcement (CSE)[01, 02, 03] und wurde mit der ios-version 4.3 durch Dynamic Code Signing (DCS) erweitert, um den neuen Performanceansprüchen des mobilesafari gerecht zu werden. Wahrscheinlich hängt die Entscheidung damit zusammen, dass Just In Time Compiler (JIT) für JavaScript ermöglicht werden sollte [04]. Somit musste ermöglicht werden, dass Speicherbereiche lesbar, beschreibbar und ausführbar (RWX) sind. Um den Kompromiss zwischen Sicherheit und Performance nicht zu groß werden zu lassen, wurden nur wenigen Anwendungen, wie dem mobilesafari, die Rechte gegeben solche Speicher- 6 Dai Zovi - Apple ios security evaluation[03] 6

11 stellen zu nutzen um JIT auszuführen. Unter speziellem Schutz ist es immer nur einem Prozess gestattet einen beschreibbaren und ausführbaren Speicherbereich zu bekommen um JIT auszuführen. Diese Berechtigung erhält z. B. der mobilesafari duch ein spezielles Entitlement das dynamic-codesigning. Nur mit diesem Entitlement ist es möglich diesen speziellen Speicherbereich belegen zu dürfen. Mit dem request wird der Speicherbereich mit der Größe von 0x (16MB) alloziert, wobei der Kernel unter Verwendung eines Sicherheitsflags, welches nur dem XNU zu Verfügung steht, die Speicherbereichsrechte auf RWX setzt [04]. 3.5 StackGuard Abbildung 5: dynamic-codesining entitlement des mobilesafari 7 Stack Buffer Overflow Angriffe sind seit Ende der 1980iger Jahre bekannt und wurden seitdem für Angriffe genutzt. Das Prinzip des Buffer Overflows ist, wie der Name schon suggeriert, recht einfach. Hier werden Daten in einen zu klein reservierten Speicherbereich geschrieben und damit Speicherstellen nach dem eigentlichen Zielspeicheradressen überschrieben. Somit ist es möglich Exploits einzuschleusen, um schadhaften Code auszuführen. Um diesem Angriff entgegenzuwirken, wurde der so genannte StackGuard eingeführt. Diese Technik verwendet Kontrollwörter an relevanten Stellen des Stacks, die Canaries genannt werden. Diese so genannten Kanarienvögel werden beim Rücksprung überprüft. Fällt die Prüfung negativ aus, weil sich der Wert geändert hat, wird der Prozess wegen eines versuchten Buffer Overflows terminiert. Um diese Technik auch bei schon 7 ios Hackers Black Book[04] 7

12 bestehendem Code nutzen zu können, kann er mit StackGuard neu kompiliert werden und verliert nur minimal an Performance [21]. 3.6 Sandboxing ios bietet viele Schutzmaßnahmen um Schadcode vorzubeugen. Aber was passiert, wenn es doch der Fall sein sollte? Um den Schaden zu begrenzen greift in diesem Fall das Konzept der sandbox [05, 06]. Das Prinzip der sandbox wurde von Mac OS X übernommen und ursprünglich in FreeBSD entwickelt [07]. Alle laufenden Apps sind signiert, wenn sie auf dem Device ausgeführt werden. Um zu verhindern, dass Apps Daten am Gerät oder in anderen Applikationen ändert, werden sie in der sandbox ausgeführt. Zusätzlich wird das Programm in einem zufällig gewählten Teil des Speichers ausgeführt, um keine Informationen zu Speicheradressen und Sprungadressen preiszugeben. Diese Maßnahme des sandboxing erlaubt nur Zugriff auf so genannte APIs, also Schnittstellen, die von Apple freigegeben werden. Diese APIs unterliegen der Kontrolle des ios. Alle Daten, die von der App genutzt werden, sind im read only mode gemounted damit sie nicht kompromittiert werden können. Dieses hat zur Folge, dass Apps untereinander keine Daten austauschen können. Weiterhin können Apps nur bedingt im Hintergrund laufen gelassen werden. Die Multitaskingfunktionalität hängt von der Art der Aufgabe ab. Wenn eine API zum Nutzen des GPS-Empfängers genutzt wird ist es möglich, dass das vom System vorgesehen ist. Möglich ist aber auch, dass eine Applikation es sich selbst verbietet diese API zu benutzen. 3.7 Runtime Process Security Abbildung 6: Prinzip der Apple sandbox 8 Die Runtime Process Security kümmert sich um die Sicherheit des laufenden Prozesses. Seit ios 4.3 ist die Speicherverwaltung um Adress Space Layout Randomization (ASLR), zu Deutsch Zufallsgestaltung des Adressraumaufbaus, erweitert worden. ASLR wird genutzt, um das Ausnutzen von Sicherheitslücken zu erschweren. Durch diese Technik werden Adressbereiche den Programmen auf zufälliger Basis zugewiesen, wodurch das System praktisch nicht mehr deterministisch ist. Dadurch sollen Angriffe durch Pufferüberlauf verhindert werden. 8 Apple Developer Guidlines[06] 8

13 Seit ios 4.3 wird ASLR in zwei Stufen unterstützt. Der volle ASLR Support ist nur gegeben, wenn beim Entwickler Rücksicht auf Position Independent Executable (PIE) genommen wurde. Dadurch wird sichergestellt, dass nicht nur dem laufenden Code, dem Heap und dem Stack sowie dem dynamiklinker der Speicher randomisiert wird, sondern auch die Main Executable. Ohne PIE konnten immer noch Rückschlüsse auf die Speicheradressen gemacht werden, da ein Entwickler weiß wieviel Speicher das eigene Programm braucht. Die entsprechenden Adressen können somit anhand eines Anhaltspunktes berechnet werden. Das absichtliche Vermeiden von ASLR wird durch die Entwicklungsumgebung Xcode verhindert, da ASLR automatisch voreingestellt ist und andere Umgebungen wegen MCS nicht unterstützt werden. Wie bei fast jeder guten Sicherheitstechnik gibt es auch hier eine Möglichkeit diese zu umgehen. Unter Zuhilfenahme der Return Oriented Programming (ROP) -Technik ist die Ausnutzung von Softwareschwachstellen aber dennoch möglich. Bei dieser Technik wird nicht versucht eigenen Programmcode in den Speicher einzuschleusen, sondern auf die bereits im Speicher vorhandenen Instruktionen zurückzugreifen und aus diesen den Exploit-Code zusammenzustellen. Um die vorhandenen Instruktionen anspringen zu können, muss ein Schadcode allerdings deren Speicheradressen kennen. Aus diesem Grund ist execute-never Bit weiterer Bestandteil der Sicherheitsarchitektur von ios bzw. der Hardwarearchitektur von ARM. Hierbei handelt es sich um einen hardwareseitigen Schutz, der die Ausnutzung von Softwareschwachstellen erschwert. Mit Hilfe des sogenannten execute-never Bit (XN- Bit) des ARM-Prozessors ist das Betriebssystem in der Lage bestimmte Speicherbereiche wie Stack und Heap hardwareseitig als nicht ausführbar zu setzen. Darüber hinaus stellt das XN-Bit sicher, dass keine Speicherbereiche gleichzeitig Berechtigungen zum Lesen, Schreiben und Ausführen besitzen. Es bietet Schutz gegen Code Injection und verhindert das Einschleusen von Programmcode. 3.8 Encryption and Data Protection Jedes ios-device ist AES 256Bit verschlüsselt. Als Schlüssel dienen Device ID (UID) und Group ID (GID) gemeinsam. Die UID wir beim Herstellungsprozess in den application prozessor gebrannt und von Apple und deren Produzenten nicht festgehalten (zumindest sieht so die Vorgabe von Apple aus). Die GID ist bei allen Devices mit gleichem Prozessor (z. B. A5 Chip Familie) identisch. Beide IDs sind fest im Chip implementiert, womit das Auslesen dieser Nummern verhindert werden kann, um den AES Schlüssel sicher zu machen. Die UID bindet die verschlüsselten Daten an das Gerät. Auch der Austausch von einzelnen Bauteilen kann das Entschlüsseln nicht ermöglichen, da die UID hierarchisch aufgebaut ist und somit beim Booten, wie die boot-chain, erst freigegeben wird. Sollte ein Speicher entfernt und in einem anderen Gerät betrieben werden, sind die Daten nicht zu entschlüsseln. Eine weitere Schwierigkeit ist das Erstellen temporärer Schlüssel. Sie werden durch einen Random Number Generator (RNG) und den Algorithmus von Yarrow erstellt. Um das Erraten des Schlüssels zu erschweren, werden Bootzeitpunkt und die im Device verbauten Sensoren zur Verschleierung herangezogen. Das bedeutet, dass bestimmte Bitstrings aus den Daten gewonnen werden, die eine Startvariable für den RNG darstellen. Solche zufälligen Bitstrings werden genutzt, um die oben genannte Verschleierung zu gewährleisten. Sie sollen die Startvariable möglichst nicht rekonstruierbar machen. 9

14 3.8.1 File Data Protection Zusätzlich zur Hardwareverschlüsselung bietet ios eine Softwareverschlüsselung, welche die Daten auf dem System schützt. Das file data protection system ist auf den speziellen Einsatz mobiler Geräte zugeschnitten. Es entschlüsselt nicht bei jedem Zugriff auf das Gerät alle Daten, sondern nur die benötigten. Das hat zum Vorteil, dass z. B. bei einem Anruf nicht das ganze System entschlüsselt werden muss; viele abgelegte Daten werden nicht benötigt, um das Gespräch entgegen nehmen zu können. File Data Protection baut auf Data Protection auf und nutzt ihre hierarchische Schlüsselverteilung. Abbildung 7: Überblick Verschlüsselung 9 Jedes verschlüsselte File erhält einen per-file-key, der durch die Hardware AES-Verschlüsselung im Cipher Block Chaining (CBC) Mode verschlüsselt wird. Hierzu stellt das Linear Rückgekoppeltes Schieberegister (LFSR) seinen Output als Initialisierungs Vektor (IV) bereit. Das per-file-key kann von mehreren Schlüsseln umschlossen werden, was von der Zugänglichkeit der Datei abhängt. Diese Verschachtlung wird in den Metadaten (siehe Abbildung 6: Überblick Verschlüsselung) festgehalten. Beim Öffnen wird der file-system-key genutzt, um die Metadaten zu lesen. In diesen Daten steht der entsprechende class-key, der an den Hardware AES-Verschlüsselungsbaustein gegeben wird, um die Daten endgültig zu entschlüsseln. Die Metadaten werden entweder durch den Benutzer (Endsperren des Devices) oder durch den vom System bei der Installation generierten Key entschlüsselt. Durch diese auf den ersten Blick aufwendige Methode wird das System flexibel und trotzdem sicher. Der User-Schlüssel kann nur benutzt werden, wenn die Code-Sperre des Telefones durch eine Persönliche-Identifikations-Nummer (PIN) aktiviert wurde Schutzklassen Apple Data Protection kann vom Entwickler beeinflusst werden. Ihm stehen verschiedene Schutzklassen zur Verfügung in denen er die Sicherheit der im Programm genutzten Files einstellen kann [08]. 9 Apple ios Security May 2012[08] 10

15 Schutzklassen Dateisystem Keychain Verfügbarkeit Complete Protection WhenUnlocked Gerät nicht gesperrt Protected Unless Open Nach dem ersten Öffnen der Datei (im ungespeicherten Zustand) Protected Until First AfterFirstUnlock Nach der ersten Eingabe der Code- User Authentification Sperre No Protection Always Immer Tabelle 2: Apple Schutzklassen 10 Diese grundsätzlichen Schutzmöglichkeiten (Schutzklassen) können nur genutzt werden, wenn der User ein Benutzerpasswort eingerichtet hat. Prinzipiell kann vom Developer alles verschlüsselt werden was in der sandbox der Anwendung liegt. Schwierigkeiten treten auf wenn Applikationen einen Prozess im Hintergrund weiterlaufen lassen wollen, um z. B. einen Download zu beenden. Hier muss der Entwickler einen Kompromiss zwischen Usability und Sicherheit finden. Bei dem Umgang mit Kennwörtern stellt das Data Protection dem Developer eine Hilfe in Form der Keychain bereit. Die Keychain basiert auf einer verschlüsselten Datenbank, in der festgelegt werden kann zu welchem Zeitpunkt Inhalte zur Verfügung stehen. Des Weiteren hat sie den Vorteil, dass sie die Erweiterung ThisDeviceOnly bietet. Mit dieser Schutzklasse können hierbei Daten nur noch vom verschlüsselten Gerät entschlüsselt werden. Als letztes nennenswertes Feature wäre zu nennen, dass diese Schlüsseldaten bei einem Backup verloren gehen damit keine Schlüsselinformationen weitergeben werden Remote Wipe Der Remote Wipe bezeichnet das Löschen des Devices aus der Ferne. Diese Funktion wird entweder durch icloud, Mobile Device Management (MDM) oder durch einen Exchange ausgelöst. Wenn der Wipe aktiviert wurde, löscht das Gerät den so genannten effaceable storage. Dieser Speicherbereich ist ein kleiner Teil im Flashspeicher in dem der sogenannte Dkey[09], eine Art Masterkey, der in der Folge der Schlüsselhierarchie erzeugt wurde, gelöscht wird. Ab diesem Zeitpunkt ist die Entschlüsselungskette zerrissen und die Daten sind unbrauchbar. 10 In Anlehnung an Werkzeuge zum Knacken der Apple iphone und ipad Data Protection[15] 11

16 Abbildung 8: Remote Wipe per icloud 11 Eigenwerk Abbildung 9: Remote Wipe per icloud - iphone löschen 12 Eigenwerk 3.9 Networksecurity Im Bereich Netzwerksicherheit unterstützt ios die gängigen Standards. Secure Sockets Layer (SSL) und Transport Layer Security (TLS) werden von allen integrierten Apps, wie z. B. Safari, Calendar (ical) und Mail, genutzt. Weiterhin kann der Entwickler High-Level APIs nutzen, die diese Art der Verbindung automatisch sicherstellen. Für die Kommunikation über firmeninterne Server können von Apple unterstützte VPN Profile genutzt werden. Die Hardware-Schnittstellen, wie Wi-Fi und Bluetooth, haben selbst keinen Zugriff auf private Daten. 4 Jailbreak Es gibt viele Gründe für einen Jailbreak und genauso viele dagegen. Die häufigsten Gründe dafür werden wohl die totale Kontrolle über das Gerät, das Umgehen eines Betreiberschutzes oder auch das Ausführen von Software, die nicht über den AppStore bezogen wird, sein. Die Nachteile durch den Jailbreak sind recht einfach. Die meisten im Verlauf angesprochenen Sicherheitsfunktionen, wie das Code Signing, werden deaktiviert. Die Kontrolle wann welcher Code ausgeführt wird ist nicht mehr vorhanden. 4.1 Jailbreak Arten Mit verschiedenen Arten des Jailbreaks soll kurz beschrieben werden, dass nicht jeder Jailbreak gleich ist. Auch die Funktionen, die durch einen Jailbreak freigeschaltet werden, sind nicht immer gleich. Sie hängen stark davon ab mit welcher Schwachstelle in das Gerät eingedrungen wurde. Softwarefehler, die ausgenutzt werden, beziehen sich meist auf eine Version, da sie schnellstmöglich von Apple gepatched werden. Bei Hardwarefehlern sieht es für die User eines Jailbreaks besser aus, da eine neue Hardwarerevision deutlich länger braucht und damit auch ältere Gerätegruppen nicht beeinflusst werden können. Diese Problematik kann man gut sehen, wenn man sich die Geräte und ihre Jailbreakversionen anschaut 13. Im konkreten Fall bedeutet es, dass ein und die selbe ios Version auf einigen Hardwareplattformen mit 13 Siehe Anhang: Apple ios Softwarestände/Jailbreak 12

17 einem Jaibreak gebrochen werden kann und andere Geräte mit der gleichen ios Version nicht. Beispielsweise kann ios nur auf dem iphone 3GS und iphone 4 mittels eines tethered Jailbreak gebrochen werden und nicht auf dem iphone 4S und iphone 5. Hier lässt sich klar erkennen, dass der Schwachpunkt die Hardware und nicht das Betriebssystem selber ist. 4.2 Hardwarehacks Zu den Hardwarehacks gehört auch das Hacken des basebandprocessors. Er ist für die Kommunikation zwischen Device und Mobilfunknetz zuständig. Durch ihn können beispielsweise interessante Attacken auf das ios Gerät durchgeführt werden. Anrufe können getätigt und Short Message Service (SMS) im Hintergrund gesendet werden. Auch das Abhören durch automatisches Annehmen eines Anrufes ist damit möglich. 4.3 Erkennen eines Jailbreaks Ein großes Sicherheitsrisiko ist der Einsatz von gejailbreakten ios Geräten im Unternehmen. Da Mobiltelefone heute nicht mehr nur zum telefonieren genutzt werden, sondern auch sensible Daten wie s oder Kundendaten aus dem Firmenumfeld gespeichert haben, ist ein Jailbreak eine Gefahrenquelle, die unbedingt erkannt werden sollte. Daten können kopiert oder verändert werden, ohne das der Nutzer es zwangsläufig merken muss. Um diese Gefahrenquelle zu erkennen, können Entwickler Gerätemerkmale abfragen und mit einer gewissen Wahrscheinlichkeit auf ein kompromittiertes Gerät schließen. Die bekanntesten Parameter sind[10]: Abfragen der installierten Applikationen (Cydia, Apt. Bash, Open SSH) Schreibzugriffe auf Systempartition Anlegen von Dateien/Ordern außerhalb der sandbox Im letzten Punkt muss mit Vorsicht vorgegangen werden, weil Apps dieser Art gegen die AppStore Richtlinien verstoßen, da sie im Apple Review Prozess nicht zugelassen werden [11]. In dem Fall einer internen Verteilung (in House) kann diese Möglichkeit jedoch verwendet werden. Im Firmenumfeld sollte die Prüfung solcher Kriterien zum Schutz des Firmeneigentums sichergestellt sein. Somit können Mitarbeiter bzw. deren Geräte besser erkannt werden. 4.4 Jailbreak Beispiel Wie im vorherigen Kapitel dargestellt, gibt es eine Vielzahl von Angriffsmöglichkeiten für Hacker das System zu übernehmen. Eine der schlimmsten Möglichkeiten ist der Angriff auf einen Hardwarefehler. Um zu verdeutlichen wie sich diese Art des Hacks in der Sicherheitsstruktur auswirken kann, genügt eine kurze Übersicht des limera1n Exploits auf das iphone 4. Diese Betrachtung dient nur zu Anschauungszwecken und erhebt keinen Anspruch auf Vollständigkeit. Basis des Angriffs ist eine bekannte Schwachstelle im BootROM. Diese Schwachstelle wird vom limera1n Exploits ausgenutzt, um eine Live Betriebssystemumgebung zu starten. Als Live Betriessystemumgebung wird die eigene von Apple auf dem Device bereitgestellte Betriebssystemumgebung aus dem Random Access Memory disk (RAMdisk) genutzt. 13

18 Dieses eigentlich als Sicherheitsfunktion genutzte System dient der Wiederherstellung des ios durch itunes. Vorteil für die Entwickler von limera1n ist, dass die restore RAMdisk beim Start den Datenträger komplett entschlüsselt. Damit werden auch Systeme, wie die AES Hardwareverschlüsselung, angreifbar. Diese Art des Angriffs gilt als größte Schwachstelle, da das BootROM das highest privilege level hat. Wie highest privilege level schon andeutet, ist der Angriff auf das BootROM mit dem Angriff auf den Wurzelknoten eines Baumes zu vergleichen. Hier kann das ganze Sicherheitssystem, wie die boot-chain of trust, die aufeinanderfolgenden Zertifikate und auch die Schlüsselhierarchie gebrochen werden. Zurückzuführen ist diese Problematik auf eine Sicherheitslücke in der Hardwarearchitektur des iphones mit dem A4 Chip [04]. Dessen Sicherheitslücke ist ein heap basierter buffer overflow über den USB Stack [12]. Nachdem durch diese Methode das BootROM mit einer neuen Signatur gepatched wurde, können LLB, iboot und der Kernel verändert werden [13]. Ab dem Zeitpunkt der Kompromittierung kann mit frei erhältlichen Tools auch auf den internen AES Chip zugegriffen werden. Somit ist es dem Angreifer möglich den AES Schlüssel auszulesen und die verschlüsselten Daten zu entschlüsseln. Falls der User eine Code-Sperre verwendet, wird zusätzlich zum AES Schlüssel noch der vom User gewählte vierstellige PIN benötigt. Nach Angaben von cirosec GmbH [15] dauert das Berechnen mit der Brute Force Methode jedoch ca. 30 Minuten. 30 Minuten werden benötigt da nach neun Versuchen das Gerät neu gebootet werden muss. Damit wird der Schutzmechanismus umgangen, dass nach 10 falschen Pin-Eingaben alle Daten gelöscht werden. Wie bereits erwähnt, ist diese Beschreibung lediglich für Geräte mit dem A4 Prozessor und soll verdeutlichen wie schwerwiegend Hardwaresicherheitslücken sein können. Bei neueren Geräten mit neueren Prozessoren, wie dem A5, A5x oder A6 14, wurden noch keine solche Schwachstellen gefunden. Weitere Angriffe, wie die auf das iphone 4S (A5 Chip) oder das ipad 3 (A5x Chip), würden den Rahmen sprengen. Interessierten Lesern sei pod2g s ios Blog[14] ans Herz gelegt. 5 Auswertung Wie sicher ist ios wirklich? In den letzten Kapiteln wurden die Sicherheitsmechanismen und ihre Probleme beschrieben. Nun sollen einige wichtige Punkte gegenübergestellt und genauer betrachtet werden. Durch das geschlossene System hat Apple den Vorteil die Kontrolle über installierte Software zu haben. Diese Ausgangssituation bringt viele Sicherheitsvorteile mit sich und ermöglicht es den Signierungsprozess durchgängig anzuwenden. Es müssen keine Ausnahmen gewährt werden, die das System umgehen können. Im zweiten Schritt kümmern sich die Apple Sicherheitsfunktionen um die Applikation und die Daten, die sie mitbringt. Durch das von OS X übernommene sandboxing kann Apple es der Anwendung erlauben Daten mit auf das Gerät zu bringen, ohne die Sicherheit aus dem Auge zu verlieren. An dieser Stelle büßt das System leider auch Komfort ein, denn es ist nicht erlaubt Daten eines anderen Programmes zu ändern und sie dann wieder dort hin zurück zu speichern. Jedes Programm hat seinen eigenen Speicher, den es alleine verwaltet. Mit diesen grundsätzlichen Eigenschaften ist der Weg für viele kleinere Sicherheitsfunktionen geebnet. Die Einführung von ASLR gehörte sicherlich auch zu den wichtigen Schritten, ist aber nicht so weit verbreitet. ASLR könnte jedoch noch erweitert werden, um 14 siehe Anhang Tabelle: Apple Prozessorfamilie 14

19 Applikationen noch tiefergehend zu überprüfen. Durch den Signierungsprozess und das Nicht-Gestatten Code nachzuladen ist die die Möglichkeit gering Schadcode in das Device laden. Es besteht nur noch die Möglichkeit den Schadcode in eine App zu wandeln, die den Review Prozess durch Apple besteht. Wenn jetzt doch noch bestimmte Speicheradressen vorausgesagt werden können, ist es möglich Schadcode auszuführen. Damit auch diese Lücke gestopft wird könnte Apple Control Flow Integrity (CFI) in ios integrieren, um diesem Phänomen entgegenzuwirken. Solche Softwareangriffe basieren oft auf Exploits, die den ausführenden Code unterwandern. CFI [01] kann solche Angriffe durch Steuern des Kontrollflusses verhindern. Auch mit bestehender Software kann CFI genutzt werden. Genauer gesagt gibt CFI der Anwendung vor welchem Pfad (Control Flow Graph (CFG)) sie in welcher Zeit folgen soll. Ein CFG wird durch statische Analysen, Laufzeit-Verfolgung oder durch zusätzliche Compilerausgaben erstellt. Sicherheitsvorkehrungen im Bezug auf die Datenverschlüsselung sind auch ein Beispiel für das generell gut durchdachte System ios. Die Daten sind mit AES verschlüsselt, was heute (Jan.2013) Stand der Technik ist. Hier liegt die Schwachstelle weniger an der Technik, als am kurzen PIN für die Code-Sperre. Wenn das Betriebssystem gebrochen wurde, hat die Firma cirosec GmbH [15] festgestellt, dass per Brute Force der PIN für die Code-Sperre in wenigen Minuten herausfinden ist (ca. 30Minuten). An dieser Stelle gibt es zwei Ansätze, die Apple verbessern könnte. Wenn das Passwort in seinem Zeichenraum vergrößert und zusätzlich zu alphanumerischen Zeichen die Groß- und Kleinschreibung zugelassen wäre, könnte das Brute Forcen auf 33 Tage verlänger werden. Wäre jetzt noch eine fünfte Stelle im PIN zugelassen, würde dieses laut cirosec GmbH eine Verlängerung auf 5,5 Jahre bedeutet. In diesem Fall steht der Sicherheit zwar die Alltagstauglichkeit entgegen, jedoch könnte dem User freigestellt werden wie sicher er sein Device selbst gestalten möchte. Diese Variante des Angriffes setzt voraus, dass das betroffene Gerät schon kompromittiert ist. Dieser Umstand gestaltet sich bei den aktuellen Geräten und dem aktuellen ios schwer. Bis heute (Jan.2013) gibt es keinen Angriff der erfolgreich auf ein iphone 5 mit ios durchgeführt wurde. Die Aussichten auf einen erfolgreichen Jailbreak stehen momentan denkbar ungünstig. Stefan Esser, einer der Autoren des ios Hackers Blackbook und Maßgeblicher Hacker des iphone 4S Exploits [18], beschreibt die aktuelle Sicherheitssituation bezogen auf die ios Beta auf seinem Blog ( folgendermaßen: Abbildung 10: Esser zum Thema Jailbreak ios Web-Blog[17] 16 Web-Blog[17] Abbildung 11: Esser zum Thema Jailbreak ios

20 Einträge dieser Art bedeuten keineswegs, dass es keinen Hack geben wird. Aber sie bedeuten das Apple in Hinsicht auf sein Sicherheitskonzept auf dem richtigen Weg ist. Die hier beschriebenen Sicherheitsstrukturen beschränken sich hauptsächlich auf die Leistungen durch Apple. Allerdings sind, wie in Unterpunkt Schutzklassen gezeigt, noch nicht alle möglichen Sicherheitseinrichtungen genutzt. Der Programmierer kann in vielen Fällen zur aktiven Sicherheit beitragen. In Xcode werden dem Entwickler eine große Anzahl an Hilfestellungen angeboten. Es ist nicht notwendig sich Gedanken zu machen wie eine sichere SSL Verbindung aufgebaut werden kann, da Funktionen dieser Art von Haus aus implementiert sind und nur genutzt werden müssen. Weiterhin können Komfortfunktionen von ios abgeschaltet werden, um mehr Sicherheit zu gewährleisten. Konkret könnte das der Tastaturcach sein, um zu verhindern das ein Passwort bei der Eingabe gelockt wird. Der Komfort des Tastaturcaches besteht darin die Schreibweise des User zu analysieren und ggf. Verbesserungsvorschläge zu unterbreiten. Die Umschaltanimation, die beim wechseln einer App einen Screenshot erstellen kann, genauso ausgeschaltet werden, damit sensible Daten nicht abgelegt und später ausgelesen werden können. Viele dieser Details können effektiv zur Sicherheit beitragen, ohne das der Aufwand des Entwicklers zu sehr steigt [10]. In diesem Zusammenhang hat sich ein Projekt entwickelt, welches sich um die Programmierung und die Sicherheit mobiler Anwendungen kümmert. Unter Mobile Security Project - Top Ten Mobile Risks[20] werden die zehn häufigsten Fehler bzw. Sicherheitsrisiken bei der Programmierung angesprochen. Top 10 mobile risks 1. Insecure Data Storage 2. Weak Server Side Controls 3. Insufficient Transport Layer Protection 4. Client Side Injection 5. Poor Authorization and Authentication 6. Improper Session Handling 7. Security Decisions Via Untrusted Inputs 8. Side Channel Data Leakage 9. Broken Cryptography 10. Sensitive Information Disclosure Tabelle 3: Mobile Security Projekt: Top 10 Mobile Risks 17 Auch Sicherheitsfunktionen dieser Art gehören zum Sicherheitskonzept von ios und zeigen, dass Sicherheit nicht beim Device selber aufhört. 6 Ausblick Das Thema Sicherheit tritt mehr und mehr in den Vordergrund. Smartphone Betriebssysteme zeigen inzwischen Betriebssystemen für den Heimcomputer wie sich Sicherheit umsetzten lässt. Trotzdem gibt es auch hier Platz zum Nachbessern. ASLR bietet eine 17 In Anlehnung an Top Ten Mobile Risks v1.0[20] 16