Spezielle Apps versprechen mehr Komfort und vor allem mehr Sicherheit beim Online-Banking als der Web-Browser. Der für c't durchgeführte Test zeigt, dass das nur die halbe Wahrheit ist.
Dass das iPhone durchaus auch fürs Online-Banking interessant ist, sieht man schon daran, dass der AppStore mit einer eigenen Kategorie „Finanzen“ aufwartet. Einige Online-Banking-Apps erfreuen sich großer Beliebtheit und können reihenweise gute Bewertungen vorweisen, in denen dann etwa von der „Bank für die Hosentasche“ die Rede ist. Um genauer zu untersuchen, wie es die Hosentaschenbanker mit der Sicherheit halten, haben wir die drei beliebtesten, Multibank-fähigen Apps genauer untersucht: iControl, iOutBank und S-Banking.
Neben den vertraulichen Daten wie Kontonummer, Kontostand und gespeicherten Transaktionen hantieren Online-Banking-Apps auch mit PINs und TANs. Und wenn die in fremde Hände fallen, kann das richtig teuer werden. Grundsätzlich gibt es zwei Angriffsszenarien, denen die kritischen Online-Banking-Daten ausgesetzt sind. Zum einen könnten Angreifer versuchen, die übertragenen Daten im Netz abzufangen. Zum anderen besteht natürlich auch die Gefahr, dass das iPhone verloren geht oder geklaut wird.
In beiden Fällen schützt Verschlüsselung – aber nur, wenn man sie richtig einsetzt. Und das ist keineswegs trivial, wie auch dieser Test wieder belegt. Im Netz genügt es nicht, dass die Banking-App alle übertragenen Daten verschlüsselt, sondern sie darf auch nicht auf Phishing-Angriffe hereinfallen, bei denen der Angreifer den Netzwerkverkehr umleitet und sich als die Bank ausgibt. Das iPhone verschickt dann zwar unknackbar verschlüsselten Datensalat – aber der Angreifer auf der Empfängerseite hat ja vorher mit ihm den Schlüssel ausgehandelt und kann die Daten damit ganz bequem dekodieren. Insbesondere in fremden WLANs ist dieses Angriffsszenario akut, da sich dort Netzwerkverkehr leicht umleiten lässt.
Die 3D-Darstellung gut verschlüsselter Daten weist keinerlei Struktur auf. Die Klartext-Datenbank hingegen zeigt deutliche Klumpen.
Wird das iPhone geklaut, hat man hoffentlich eine Code-Sperre aktiviert, die den direkten Zugang zum Gerät blockiert. Auch iTunes kann nicht mit einem gesperrten iPhone sprechen, mit dem es nicht bereits zuvor in ungesperrtem Zustand bekannt gemacht wurde. Die zusätzliche Option „Daten löschen“ putzt das Gerät nach 10 falschen Eingaben.
Doch leider schützt all das nur vor zufälligen Findern und Gelegenheitsdieben. Motivierte Gauner können diese Sperre leicht austricksen, indem sie die entsprechenden Konfigurationsdateien ändern. Das funktioniert etwa über Jailbreaks, die bereits sehr früh im Boot-Prozess aktiv werden. So gelang es im Test, ein aktuelles und gesperrtes iPhone 4 mit iOS 4.1 an einem Linux-Rechner, den das Gerät nie zuvor gesehen hatte, zu jailbreaken.
Dabei modifizierte GreenPois0n das System so, dass es nicht von Apple signierte Apps ausführt und legte die Loader-App auf dem Desktop ab. Genauso gut hätte es auch noch die Code-Sperre entfernen können. Mit dem kürzlich veröffentlichten Quellcode wird es zur Fingerübung, das selbst einzubauen. Ansonsten bieten das auch Dienstleister im Netz für etwa 30 Dollar an. [Nachtrag: Ab iOS 4 funktionieren die bekannten Methoden, die Code-Sperre zu entfernen, nicht mehr. Da aber der Jailbreak Zugriff auf das Dateisystem hatte, muss man auch bei iOS 4 alle dort abgelegten Daten als gefährdet betrachten.]
Für Verwirrung sorgt gelegentlich Apples Produktbeschreibung, die mit AES-Hardware-Verschlüsselung wirbt. In der Tat sind seit dem 3GS die Daten im Flash-Speicher mit einem quasi unknackbaren 256-Bit-Schlüssel verschlüsselt. Allerdings erledigt das System die Entschlüsselung vollkommen transparent; wer Zugang zu einem iPhone hat, kann spätestens nach Entfernung der Code-Sperre alle Daten auslesen.
Somit bleibt als Hauptaufgabe dieser Hardware-Verschlüsselung vor allem das sichere Löschen. Statt beim Erhalt eines Löschbefehls 32 GByte Flash-Speicher zu überschreiben, genügt es, dass das System den 256 Bit langen Schüssel wegwirft. Für alle praktischen Anforderungen mutieren die Daten damit augenblicklich zu einer quasi-zufälligen Zahlenfolge, aus der sich keine Informationen mehr extrahieren lassen.
[Nachtrag: Darüber hinaus bietet iOS seit Version 4 erweiterte Schutzmechanismen für Dateien. So kann ein Entwickler beim Erstellen einer Datei das erweiterte Attribut NSFileProtectionComplete zuweisen. Das hat zur Folge, dass die Datei mit einem Schlüssel verschlüsselt wird, in den unter anderem auch der Passcode eingeht. Die Datei lässt sich dann auf einem gesperrten iPhone nicht mehr auslesen. Ein schneller Test zeigte jedoch, dass keine der getesteten Apps diesen erst ab iOS 4 verfügbaren Mechanismus verwendete.]
Alle Online-Banking-Apps setzen ein eigenes Passwort, das zum Start der App erforderlich ist. Sie verschlüsseln die Daten mit AES 256. Wenn ein Angreifer durch Reverse Engineering das Verfahren ermittelt, wie das Passwort in den Schlüssel eingeht, kann er damit einen Brute-Force-Angriff starten, der alle Möglichkeiten durchprobiert. Diesen kann er auf einem High-End-System direkt auf die verschlüsselten Daten loslassen. Deshalb ist es extrem wichtig, lange Passwörter zu verwenden. Eine mit einem sechsstelligen, einfachen Passwort gesicherte iControl-Datenbank konnten wir ohne große Optimierungen innerhalb weniger Stunden knacken. Erst ab 10 Zeichen – ohne Großbuchstaben oder Zahlen sogar 12 – kann man davon ausgehen, dass sich Brute-Force-Angreifer die Zähne ausbeißen.