Ingmar Stein
Seit der Vorstellung des iPhone im Jahr 2007 erlebt der Smartphone-Markt ein rasantes Wachstum. Aufgrund dieser stetig zunehmenden Verbreitung werden die Geräte auch als Ziel für Angriffe und Malware immer beliebter, wie eine immer länger werdende Liste von Schwachstellen zeigt (siehe Infobox auf dieser Seite). In die Pflicht genommen werden müssen dabei nicht nur die Nutzer, sondern häufig auch die Anwendungsanbieter. Sie haben prinzipiell zwei Möglichkeiten, um Nutzer zu schützen: Sie reduzieren entweder die Funktionalität von potentiell unsicheren mobilen Apps, um das Schadensrisiko zu minimieren, oder bauen weitergehende Sicherheitsvorkehrungen ein.
Schadensrisiko minimieren
Die Nutzer verlangen nach immer mehr Funktionalität. Dem gegenüber steht ein steigendes Sicherheitsrisiko. Es gilt deshalb die beiden Punkte sorgfältig abzuwägen. Im Bereich Mobile Banking ist der Fall klar: Hier sollte der Sicherheitsaspekt ganz klar an erster Stelle stehen. Deshalb hat sich bei den Banken auch der Trend entwickelt, Transaktionen mit mobilen Anwendungen bezüglich Betrag zu limitieren. Damit soll das Schadensrisiko im Missbrauchsfall minimiert werden. Ausserdem ist es oftmals nur möglich, Geld zwischen verschiedenen eigenen Konten zu transferieren. Auf Dauer werden sich die Benutzer mit derartig beschränkten Anwendungen jedoch nicht zufrieden geben und gegebenenfalls zur Konkurrenz wechseln, die mehr bietet. Deshalb sind auch im Bankenumfeld andere Sicherheitsstrategien gefragt.
Mobile Websites oder native Apps?
Ein Ansatz für sichere mobile Applikationen ist die Entwicklung von mobilen Webseiten oder der Einsatz von hybriden Apps, also Programmen, die teilweise mit Webtechnologien wie HTML5 entwickelt werden. Auf diese Weise erreicht man exakt die Sicherheitsstufe wie auf Desktop-PCs – das Smartphone ist ja eigentlich auch nichts anderes als ein kleiner Rechner mit Browser. Das bedeutet jedoch, dass natürlich wie auf PCs auch Attacken wie Cross-Site-Scripting, Phishing und Man-In-The-Middle denkbar sind.
Eine weit bessere Lösung ist deshalb die Entwicklung von sogenannten nativen Apps. Native Apps haben die besseren Voraussetzungen, sichere Anwendungen zu werden, da ihre initiale Angriffsfläche deutlich kleiner ist als die einer Webanwendung: Es gibt keinen Javascript-Interpreter, der ungewollten Code ausführen könnte, und keine Möglichkeit, die Benutzeroberfläche zu verändern, etwa durch externen HTML-Code.
Nachfolgend werden einige Aspekte aufgeführt, die Entwickler nativer Apps berücksichtigen sollten und zwar vom Beginn der Entwicklung an. Denn Sicherheit ist kein Feature, das mit Version 2.0 nachgeliefert werden kann.
Sandbox – isolierte Apps
Apps laufen sowohl unter Apples Betriebssystem iOS als auch unter Googles Android in einer Sandbox. Das bedeutet, dass das Betriebssystem dafür sorgt, dass keine Anwendung Operationen durchführen kann, die andere Apps oder das Betriebssystem selbst ungewollt beeinflussen. Dazu gehört, dass Apps in getrennten Prozessräumen ausgeführt werden und keinen Zugriff auf die Daten anderer Applikationen haben.
Die Implementierung einer solchen Sandbox ist je nach Plattform unterschiedlich. iOS-Apps werden in einem sogenannten chroot-jail ausgeführt, das heisst eine Anwendung sieht nur einen kleinen Teil des gesamten Dateisystems, nämlich ihre eigenen Daten und bestimmte, für den allgemeinen Zugriff freigegebene Bereiche (Fotos, Adressbuch, etc.). Android-Apps in einer Sandbox haben dagegen eine komplette Sicht auf das Dateisystem, laufen jedoch unter einem eigenen Benutzerkonto mit eingeschränkten Rechten. Android-Entwickler müssen deshalb aufpassen, dass sie die Berechtigungen der Anwendungsdaten korrekt setzen, was zum Beispiel bei früheren Skype-Versionen nicht der Fall war.
Keychain – Passwörter sichern
Eine Sandbox allein genügt aber nicht, wie das Beispiel einer früheren Wordpress-App gezeigt hat. Wichtig ist, dass auch in einer Sandbox Benutzernamen und Passwörter nicht im Klartext gespeichert werden, denn diese landen bei einem Backup auf dem Desktop-PC und sind dort für jedermann zugänglich. Apples iOS bietet einen speziellen, verschlüsselten Container zur Speicherung solcher Daten, den Keychain. Das folgende Code-Beispiel illustriert die Benutzung der Keychain-API:
NSMutableDictionary *query = [NSMutableDictionary dictionary];
[query setObject:(id)kSecClassGenericPassword forKey:(id)kSecClass];
[query setObject:@“username“ forKey:(id)kSecAttrAccount];
[query setObject:(id)kSecAttrAccessibleWhenUnlocked forKey:(id kSecAttrAccessible];
[query setObject:[@“password“ dataUsingEncoding:NSUTF8StringEncoding] forKey:(id)kSecValueData];
SecItemAdd((CFDictionaryRef)query, NULL);
Android kennt seit Version 2.0 mit dem Account Manager ein ähnliches Konzept.
Protected Data – Daten verschlüsseln
Neben Benutzernamen und Passwörtern gibt es für Anwendungsentwickler möglicherweise weitere Daten, die geschützt werden müssen. Seit der iOS-Version 4.0 gibt es dafür ein spezielles Dateiattribut, mit dem beliebige Dateien als geschützt markiert werden können. Geschützte Dateien sind mit einem Schlüssel verschlüsselt, der aus dem Zugangscode für das iPhone abgeleitet wird, und sind daher nur verfügbar, wenn das iPhone entsperrt wurde. Das folgende Code-Beispiel zeigt wie man das NSFileProtection-Attribut zu einer bestehenden Datei hinzufügt:
NSError *error = nil;
NSDictionary *attributes = [NSDictionary dictionaryWithObjectsAndKeys:NSFileProtectionComplete, NSFileProtectionKey, nil];
[[NSFileManager defaultManager] setAttributes:attributes ofItemAtPath:file error:&error];
Die sichersten Daten sind jedoch solche, die gar nicht erst auf dem Dateisystem abgelegt werden. Als Anwendungsentwickler sollte man sich deshalb fragen, ob zum Beispiel wirklich eine TAN-Liste gespeichert werden muss oder ob man den Benutzer erst bei der Durchführung einer Transaktion danach fragt. Die beiden deutschen Mobile Banking Apps iControl und iOutBank fielen in einem Test von «Heise Security» in diesem Punkt beispielsweise durch.
Sichere Netzwerkkommunikation
Wenn sämtliche lokalen Daten einer App geschützt sind, das heisst am richtigen Ort mit den richtigen Berechtigungen gespeichert sind, ist man aber noch nicht am Ende angelangt. Als nächstes gilt es, die Netzwerkkommunikation abzusichern. Wichtigstes Werkzeug hierfür ist die Verwendung des Secure Sockets Layer (SSL), der transparent alle Daten auf der Transportebene verschlüsselt. Aber auch mit HTTPS müssen einige Regeln eingehalten werden, damit die Sicherheit nicht kompromittiert wird:
- Keine selbstsignierten Zertifikate verwenden. SSL-Zertifikate, die nicht von einer anerkannten Zertifizierungsstelle ausgestellt wurden, haben keine Aussagekraft.
- Sensitive Daten müssen im Body des HTTP-Requests stehen, damit sie verschlüsselt werden. Passwörter dürfen also nicht als Query-Parameter übergeben werden (z.B. https://www.mycompany.ch/service/buy?username=foo&password=bar)
- Der im SSL-Zertifikat enthaltene Hostname muss überprüft werden, sonst sind Man-In-The-Middle-Attacken möglich. Beispiel: Die App der deutschen Sparkassen S-Banking hatte diesen Check versäumt und akzeptierte somit jeden beliebigen Server als Gegenstelle.
Jailbreaking und seine Folgen
Eine Modeerscheinung bei Smartphones ist das Jailbreaking (iOS) oder Rooting (Android). Damit werden Schutzmechanismen der jeweiligen Betriebssysteme ausser Kraft gesetzt, um die Installation von Apps zu ermöglichen, die nicht über den App Store verteilt werden oder Root-Rechte brauchen. Auf Apples iOS bedeutet dies unter anderem, dass das Code Signing nicht mehr effektiv ist und eine Anwendung nicht mehr davon ausgehen kann, dass ihr Code nicht verändert wurde. Aus diesem Grund prüfen manche Anwendungen wie Skype oder die Paypal-Library anhand einiger Muster, ob ein Jailbreak durchgeführt wurde. Auf solche Checks kann man jedoch getrost verzichten, da diese relativ einfach entfernt werden können, etwa mit Mobilesubstrate-Plugins, und man Nutzer damit verärgert. Apple hat mit iBooks 1.2.1 einen solchen Check eingeführt, der nach nur wenigen Tagen bereits umgangen wurde und in der darauffolgenden Version wieder entfernt wurde.
Fazit
Smartphones sind also unsicher. Das bedeutet aber nicht, dass man diese Geräteklasse nicht für sichere Transaktionen verwenden kann oder man keine sensitiven Daten darauf speichern darf. Anwendungsentwickler, die die genannten Best Practices umsetzen, erreichen einen vernünftigen Sicherheitslevel und legen die Hürde für Hacker hoch genug, um Angriffe aufwendig und damit unattraktiv zu machen.
Dr.-Ing. Ingmar Stein ist Senior Software Engineer bei der BSgroup Technology Innovation AG.
Angriffe auf Smartphones nehmen zu
- Mai 2008: Eine SMS-Lücke in Smartphones mit Windows Mobile taucht auf, die die Ausführung von bösartigem Programmcode ermöglicht.
- Januar 2009: Charlie Miller entdeckt eine Lücke im Android-Browser und rät von der weiteren Verwendung bis zur Schliessung der Lücke ab.
- November 2009: Der erste «iPhone-Wurm» ikee befällt iPhones mit Jailbreaks, deren Besitzer das Standardpasswort nicht geändert haben.
- Februar 2011: Ein Online-Banking-Trojaner für Windows Mobile, Blackberrys und Symbian späht mTANs aus.
- März 2011: Eine Cross-Site-Scripting-Lücke im Android Market erlaubt die unbefugte Installation von Apps auf Android-Geräten.
- April 2011: Ein Sicherheitsleck in Skype für Android erlaubt es, über die App an Namen, Telefonnummern und Chat-Logs zu kommen.
