iOS Security: Sichere Apps für iPhone und iPad

Von Carsten Eilers

Apple betont gerne, wie sicher iOS ist. Doch jede Sicherheit ist relativ, wenn eine App nicht ausreichend geschützt ist. Dieses Buch erläutert die Möglichkeiten für Angriffe auf iOS-Geräte sowie iOS-Apps und erläutert, welche Schwachstellen sich im System befinden. Gleichzeitig werden die Schutzmaßnahmen wie die Sandbox, die Key Chain und weitere Apple Sicherheitsfunktionen so offengelegt, dass Sie deren Möglichkeiten voll ausnutzen und Ihre App richtig schützen können.

• Sprache: Deutsch
• Herausgeber: entwickler.press
• Erscheinungsdatum: 20. Jan. 2014
• ISBN: 9783868026252

Buchvorschau

Carsten Eilers

iOS Security - Sichere Apps für iPhone und iPad

ISBN: 978-3-86802-625-2

© 2014 entwickler.press

Ein Imprint der Software & Support Media GmbH

Vorwort

In diesem Buch geht es um die Entwicklung sicherer iOS-Apps, wobei die Betonung auf „sicherer" liegt. Wie Apps programmiert werden, sollten Sie bereits wissen oder sich zu dem Thema ein spezielles Buch anschaffen. Denn in diesem Buch geht es ausschließlich um das Thema Sicherheit:

Welche Angriffe auf iOS und iOS-Apps gibt es?

Welche Schutzmaßnahmen verhindern oder erschweren die Angriffe?

Wie werden diese Schutzmaßnahmen genutzt?

Was ist sonst noch alles zu beachten?

Damit am Ende des Entwicklungsprozess nicht nur einfach eine App, sondern eine sichere App herauskommt.

IT-Sicherheit ist ein Wettlauf

Die IT-Sicherheit ist ein ständiger Wettlauf zwischen Ihnen als Entwickler einer App und den Cyberkriminellen, die Schwachstellen in Ihrer App ausnutzen wollen. Sie wissen ja, wie schnell sich die IT-Welt ändert – nun, die IT-Sicherheit dreht noch ein paar Nummern schneller.

Für ein gedrucktes Buch zu einem Sicherheitsthema ist das natürlich ein gewisser Nachteil. Schon während ich noch mit dem Schreiben beschäftigt war, gab es neue Entwicklungen, die Änderungen am Text erforderlich machten. Zum Beispiel die Veröffentlichung von iOS 7 im September 2013 und die Entdeckung des HTTP Request Hijackings im Oktober 2013 [Eile_13.7].

Wie kann man diesen Nachteil ausgleichen oder sogar in einen Vorteil verwandeln? Zunächst einmal, indem man sich auf die Grundlagen konzentriert, denn die sind zum größten Teil auch in einigen Jahren noch genau so gültig wie sie es heute sind und wie sie es schon vor einigen Jahren waren.

Ein Pufferüberlauf zum Beispiel war schon vor 10 Jahren ein Pufferüberlauf und er wird es sehr wahrscheinlich auch in weiteren 10 Jahren noch sein. Was sich ändert, ist das Umfeld, im Fall des Pufferüberlaufs zum Beispiel in Form der Schutzmaßnahmen, die seine Ausnutzung im Laufe der Zeit immer schwieriger gemacht haben. Das grundlegende Problem ist aber immer noch das gleiche.

Wenn Sie die Ursachen der Schwachstellen und Angriffe sowie die möglichen Gegenmaßnahmen kennen, können Sie bei Bedarf aus Ihrer eigenen Erfahrung als Entwickler heraus auf neue Entwicklungen reagieren.

Ich habe mich außerdem auf nur wenige konkrete Codebeispiele beschränkt, denn Sie wissen ja: Nichts ist so überflüssig wie ein Beispiel zum API in einer alten Version. Ich habe dabei davon profitiert, dass einige Schutzmaßnahmen durch zusätzliche Parameter normaler API-Aufrufe gesteuert werden. Die APIs nutzen Sie sowieso, die Sicherheit gibt es dann quasi gratis dazu, Sie müssen sie nur nutzen.

Bei den Beispielen habe ich mich sehr eng an Apples Beispiele in der iOS Developer Library gehalten, sodass Sie sich nicht an ein anderes Konzept gewöhnen müssen, wenn Sie Buch und Developer Library parallel nutzen. Nebenbei hat das noch den Vorteil, dass die Beispiele im Buch und vor allem ihre Beschreibungen auf zukünftige API-Versionen übertragbar sind.

Wenn sich die APIs ändern, wird Apple sehr wahrscheinlich die vorhandenen Beispiele nur anpassen und nicht durch völlig neue ersetzen. Das Grundproblem und sogar der Lösungsansatz bleiben meist gleich, nur die jeweilige Implementierung ändert sich. Ich hoffe, dass genug Ähnlichkeit übrig bleibt, um die Grundlagen hier im Buch mit den zukünftigen API-Beschreibungen auf Apples Website zu verknüpfen.

Bevor Sie sich jetzt auf den Rest des Buchs und danach in das Wettrennen mit den Cyberkriminellen stürzen, noch ein wichtiger Hinweis und Rat:

Bleiben Sie auf dem Laufenden!

IT-Sicherheit ist nichts, auf dem man sich ausruhen kann. Ihre App kann noch so sicher entworfen und implementiert sein, sodass sie bei ihrer Veröffentlichung keine Schwachstellen enthält, und trotzdem können später noch welche darin auftauchen. Zum Beispiel wenn ein neuer Angriff wie das oben schon erwähnte HTTP Request Hijacking entdeckt wird. Außerdem wissen Sie als Entwickler ja, dass es keine fehlerfreie Software gibt – und mancher Fehler kann durchaus eine ausnutzbare Schwachstelle sein. Sie müssen daher die Sicherheit Ihrer App auch nach deren Veröffentlichung im Auge behalten. Und dabei gibt es vieles zu berücksichtigen.

Apple veröffentlicht laufend Updates für iOS, die meist mehrere Schwachstellen beseitigen. Diese Updates sollten Sie immer zügig installieren, bevor Cyberkriminelle auf die Idee kommen, die Schwachstellen auszunutzen und zum Beispiel einen Wurm auf die iPhone- und iPad-Benutzer loszulassen. Genau so wichtig ist es aber, die Auswirkungen des Updates auf Ihre App zu kontrollieren: Funktioniert sie auch mit der neuesten iOS-Version noch einwandfrei? Normalerweise wird das so sein, negative Auswirkungen sind aber nie ausgeschlossen, und mitunter kommt es dann nicht nur zu einem Fehler, sondern sogar zu einer Schwachstelle.

Die von Apple behobenen Schwachstellen sind aber eigentlich kein Problem: Wenn das Update installiert ist, ist die Gefahr gebannt. Aber es werden immer wieder neue Schwachstellen entdeckt, und manche davon werden von den Entdeckern nicht vertraulich an die Entwickler der betroffenen Software gemeldet, sondern für Angriffe ausgenutzt. Solche so genannten 0-Day-Schwachstellen, die ausgenutzt werden, bevor es einen Patch gibt, sind besonders gefährlich. Zum Glück blieb iOS bisher vor tatsächlichen Angriffen auf 0-Day-Schwachstellen verschont, aber dieses Glück kann schnell vorbei sein.

Informationen über solche Schwachstellen finden Sie zum Beispiel beim Antivirenhersteller Ihres geringsten Misstrauens. Wobei deren Blogs mit einer gesunden Skepsis zu lesen sind, denn vieles darin ist natürlich Marketing. Warnungen vor neuen Schwachstellen oder Angriffen sind aber im Allgemeinen ernst zu nehmen.

Fast genau so gefährlich wie 0-Day-Schwachstellen sind Schwachstellen, die zwar nicht ausgenutzt, aber ausschließlich im Internet veröffentlicht werden, ohne die Entwickler zu informieren. Denn dann können Cyberkriminelle Code zu ihrer Ausnutzung, einen so genannten Exploit, entwickeln und einsetzen, bevor der Entwickler überhaupt weiß, dass eine Schwachstelle entdeckt und veröffentlicht wurde.

Daher ist die Exploit Database unter www.exploit-db.com immer einen Besuch wert. Dort werden die im Internet aufgetauchten Exploits gesammelt und veröffentlicht. Auch Exploits für iOS und iOS-Apps sind dort mit unschöner Regelmäßigkeit zu finden.

Und dann gibt es da noch die Sicherheitsforscher, die neue Angriffe und Schutzmaßnahmen entwickeln und auf Sicherheitskonferenzen vorstellen. Auch dort sollten Sie auf dem Laufenden bleiben. Bekannte und interessante Konferenzen sind

die „Black Hat"-Konferenzen, die jeweils ein Mal pro Jahr in Europa, den USA und Abu Dhabi stattfinden (www.blackhat.com)

die „Hack in the Box"-Konferenzen in den Niederlanden und Malaysia, auf denen schon des Öfteren Jailbreaks vorgestellt wurden (conference.hitb.org)

die CanSecWest und ihre Schwesterkonferenzen PacSec und EU­SecWest, auf denen die Pwn2Own-Wettbewerbe abgehalten werden (cansecwest.com)

die Def Con (defcon.org)

Es lohnt sich, auf diese Konferenzen zu achten. Zum einen erfahren Sie dann schnell, wenn es neue Angriffe gibt, zum anderen werden dort auch durchaus für Entwickler interessante Themen behandelt wie zum Beispiel Analysen neuer Technologien und Ähnliches.

Danksagungen

Ich bedanke mich bei Sebastian Burkart von entwickler.press für die gute Zusammenarbeit und seine Geduld, als der Abgabetermin immer weiter in die Vergangenheit rückte und das Manuskript einfach nicht fertig werden wollte. Ohne seine Initiative würde es dieses Buch auch gar nicht geben. Ein erster Artikel zum Thema iOS-Sicherheit im Mobile Technology war zwar sehr gut bei den Lesern angekommen, aber erst Sebastians Frage, ob ich nicht ein Buch darüber schreiben wollte, hat dieses Projekt auf den Weg gebracht. Danke, Sebastian!

Ebenso bedanke ich mich bei Theresa Vögle von entwickler.press, die das Lektorat des Manuskripts übernommen hat, und den anderen Mitarbeitern der Schlussredaktion, die im Hintergrund an der Entstehung des fertigen Buchs mitgewirkt haben.

Ein besonderer Dank gilt meinem kleinen Helferlein, das mich immer wieder aufgemuntert und unterstützt hat.

Carsten Eilers

1 Angriffe in Theorie und Praxis

iOS ist ziemlich sicher – bisher gibt es keine bekannte Schadsoftware. Trotzdem ist und war iOS immer wieder Angriffen ausgesetzt. Damit Sie wissen, was Ihre App erwartet, gibt es daher in diesem Kapitel einen Überblick über die bisherigen Angriffe auf iOS und iOS-Apps. Wie sicher ist iOS denn eigentlich?

Eine Vorbemerkung ist leider notwendig: In der Betaversion von iOS 7 wurden unschöne Fehler gefunden, die in der Presse zu Schwachstellen aufgebauscht wurden. Meines Erachtens sind sie nicht der Rede wert. Fehler in einer Betaversion sind normal, und die Betaversion wird ja nur veröffentlicht, um Fehler darin zu finden. Zu wirklichen Schwachstellen würden diese Fehler erst, wenn sie nicht vor der Veröffentlichung der finalen Version behoben würden. Daher finden Sie im Folgenden keine Hinweise auf diese Fehler.

1.1 „Angriffe" durch Forscher

Apples Behauptung, iOS sei sicher, hat natürlich etliche Sicherheitsforscher auf den Plan gerufen, die diese Behauptung so nicht stehen lassen wollten. Und das mit Erfolg, wie der folgende kleine Überblick zeigen wird.

Der Schwerpunkt liegt auf Vorträgen der „Black Hat-Konferenzen. Natürlich wurden auch auf anderen Konferenzen Vorträge zu iOS gehalten, aber hier alle aufzuführen, würde den Rahmen bei weitem sprengen. Zudem haben die „Black Hats das am besten gepflegte Archiv. Und los geht es!

2009

Im April 2009 demonstrierten Charlie Miller und Vincenzo Iozzo auf der „Black Hat Europe 2009" die Entwicklung von Shellcode für iOS [MiIo_09]. Als Shellcode wird der Code bezeichnet, der zum Beispiel bei einem Angriff über eine Pufferüberlaufschwachstelle eingeschleust wird.

2010

Auf der „Black Hat DC 2010" im Januar 2010 führte Nicolas Seriot vor, auf welche Daten ein reguläres Programm aus Apples App Store zugreifen kann und wie ein bösartiges Programm theoretisch Apples Prüfungen unterlaufen könnte [Seri_10]. Seine Demo-App SpyPhone [Seri_10.1] wurde aber nicht über den App Store vertrieben.

Im März 2010 zeigten Derek Brown und Daniel Tijerina von TippingPoints Digital Vaccine Group, wie eine bösartige Anwendung, in diesem Fall eine Wetter-App, Informationen samt den GPS-Koordinaten sammeln und an ihre Entwickler schicken kann [Clul_10]. Ihre App vertrieben sie allerdings nicht über Apples App Store, sondern über Drittanbieter, sodass nur iPhones mit Jailbreak betroffen waren.

Im Juli 2010 führten Vincenzo Iozzo, Tim Kornau und Ralf-Philipp Weinmann auf der „Black Hat USA 2010" Möglichkeiten zum Umgehen einiger Schutzfunktionen wie beispielsweise der Codesignatur vor [IoKW_10].

2011

Auf der „Black Hat Europe 2011" stellte Nitesh Dhanjani im März 2011 neue Angriffsvektoren für Angriffe auf iOS samt möglicher Gegenmaßnahmen vor [Dhan_11]. Beschrieben wurden zum Beispiel Angriffe über Protokoll-Handler und unsichere URL-Scheme-Implementierungen, Spoofing-Angriffe auf die Benutzeroberfläche und der Missbrauch von Push Notifications.

Im August 2011 fand die „Black Hat USA 2011" statt, auf der es gleich mehrere interessante Vorträge zur iOS-Sicherheit gab. Stefan Esser demonstrierte einen Angriff auf den iOS Kernel über eine Integerüberlaufschwachstelle [Esse_11]. David Schuetz beschrieb Apples Mobile Device Management (MDM) zur Verwaltung von iOS-Geräten in Unternehmen und mögliche Angriffe darauf beziehungsweise darüber [Schu_11]. Andrey Belenki beschrieb das Aushebeln der Verschlüsselungsfunktionen von iOS 4 mit dem Ziel, das System für forensische Untersuchungen zu öffnen [Bele_11]. Was nach einem Angriff dessen Aufklärung dient, kann natürlich auch selbst als Angriff missbraucht werden. Und zu guter Letzt stellte Dino Dai Zovi die vorhandenen Schutzfunktionen in iOS 4 sowie mögliche Angriffe darauf vor [Zovi_11].

Im November 2011 fand Charlie Miller eine Schwachstelle, die das Ausführen unsignierten Codes erlaubte [Stoc_11]. Er entwickelte eine App, die Apples Prüfung bestand und im App Store veröffentlicht wurde. Später lud diese App dann Code nach und führte ihn über die Schwachstelle aus. Entsprechend der alten Tradition, die Überbringer schlechter Nachrichten zu bestrafen, hat Apple als Reaktion auf die Entdeckung erst mal Charlie Miller aus dem Entwicklerprogramm geschmissen [Eile_11.2]. Etwas später wurde dann aber auch die von ihm entdeckte Schwachstelle behoben.

Im Dezember 2011 haben Andrey Belenko und Dmitry Sklyarov auf der „Black Hat Abu Dhabi 2011" eine Überblick über die Entwicklung der Krypto-Funktionen von iOS 3 bis iOS 5 gegeben und Möglichkeiten aufgezeigt, sie in Rahmen forensischer Untersuchungen auszuschalten [BeSk_11]. Vereinfacht kann man das Ergebnis folgendermaßen zusammenfassen: „Wenn jemand physikalischen Zugriff auf das Gerät hat, kommt er mit mehr oder weniger viel Aufwand auch an die gespeicherten Daten heran".

Ebenfalls in Abu Dhabi demonstrierten Federico Maggi, Stefano Zanero und Alberto Volpatto, dass ein Angreifer aus der Videoaufzeichnung einer Touchscreen-Eingabe die Eingabe ermitteln kann [MaZa_11].

2012

Im März 2012 präsentierten Andrey Belenko und Dmitry Sklyarov auf der „Black Hat Europe 2012" die Ergebnisse ihrer Untersuchungen von Passwortmanagern und Dateiverschlüsselern für iOS [BeSk_12]. Das Ergebnis ist ernüchternd, die Programme halten Angriffen kaum stand und bieten keinen zusätzlichen Schutz im Vergleich zu den systemeigenen Lösungen, sofern sie überhaupt einen bieten. Ihr Fazit: Die systemeigenen Lösungen sind so sicher wie möglich, mit allen getesteten Apps verschlechtern Sie Ihre Sicherheit.

Ebenfalls im März, aber auf der Konferenz „CanSecWest 2012", wurden von Stefan Esser die sich durch die Verbesserungen der Schutzfunktionen in iOS 5 ergebenden Schwierigkeiten bei der Entwicklung eines Jailbreaks beschrieben [Esse_12]. Sein Ergebnis: „In reality Apple still makes it too easy to PWN the kernel".

Die „SyScan Singapore 2012" fand im April 2012 statt und wurde von Stefan Esser genutzt, um neue Angriffe auf den iOS Kernel vorzustellen [Esse_12.1]. Paul Craig stellte auf der gleichen Konferenz typische Schwachstellen in Apps vor [Crai_12].

Im Juli 2012 haben Justin Engler, Seth Law, Joshua Dubik und David Vo auf der „Black Hat USA 2012" beschrieben, wie iOS Apps halbautomatisch auf das Einhalten der für den App Store geltenden Regeln getestet werden können, und dazu das Tool Semi-automated iOS Rapid Assessment, kurz SiRA vorgestellt [ELDV_12]. Auf der gleichen Konferenz wurden von Stefan Esser Angriffsmöglichkeiten auf den Kernel von iOS 6 beschrieben [Esse_12.2], und Jonathan Zdziarski hat mögliche Angriffe auf Apps vorgestellt [Zdzi _12].

Im Oktober 2012 haben Mark Dowd und Tarjei Mandt auf der „Hack in the Box 2012" in Malaysia mögliche Angriffe auf die neuen Schutzfunktionen von iOS 6 vorgestellt [DoMa_12].

Ebenfalls im Oktober 2012 fand die Hack.LU 2012 statt, auf der Mathieu Renard einer wichtigen Frage nachging: „Is your company data safe when stored on iDevices?" [Rena_12]. Vorgestellt wurden unter anderem Angriffe auf ein iPhone ohne Jailbreak über ein präpariertes Dock sowie verschiedene Möglichkeiten zur Analyse von Apps und zum Ausspähen von Daten.

Auf der SyScan360 im Dezember 2012 haben Xu Hao und Chen Xiaobo die Suche nach Fehlern im iOS Kernel beschrieben [HaXi_12]. Vorgestellt wurden Fuzzing-Methoden und die Analyse gefundener möglicher Schwachstellen.

2013

Im März 2013 war es wieder Zeit für die CanSecWest, auf der es zwei hier relevante Vorträge gab. Vladimir Katalov widmete sich einem bisher weitgehend ausgeklammerten Thema: Angriffen auf iCloud-Backups und „Find My iPhone" sowie dem Document Storage [Kata_13]. Sein wichtigstes Fazit: Die in der Cloud gespeicherten Daten sollten zusätzlich verschlüsselt werden, da die vorhandene Verschlüsselung mit Apple bekannten Schlüsseln durchgeführt wird.

Stefan Esser widmete sich wieder einmal dem iOS Kernel: „iOS6 – Exploitation 280 Days Later" [Esse_13]. Nach einer Zusammenfassung der bisher bekannten Angriffe und Informationen stellte Stefan Esser die neuen Schutzfunktionen von iOS 6 vor, um sie dann anschließend auf Schwachstellen zu untersuchen.

Auf