iPhone-Banking-Apps im Sicherheitscheck

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.

In Pocket speichern vorlesen Druckansicht
Lesezeit: 15 Min.
Inhaltsverzeichnis

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.

getestet: Version 2.3.6

Die erste App im Test wirbt gleich mit 256-Bit-AES-Verschlüsselung und allen relevanten Buzz-Words des Online-Bankings: HBCI+, FinTS und m/Smart/ Chip-TAN. Auf der Homepage prangen Empfehlungen und Auszeichnungen aus diversen Tests. Der erste Eindruck ist auch durchaus vertrauenerweckend. So fragt iControl bereits beim Einrichten ein Passwort ab, das zukünftig bei jedem Start einzugeben ist.

iControl beherrscht das gesamte Repertoire von der Überweisung bis zum Dauerauftrag.

Beim Versuch, auf ein Postbank-Konto zuzugreifen, erhielten wir wiederholt Fehlermeldungen; eventuell ist es mit der Multibank-Fähigkeit doch nicht ganz so gut bestellt. Das Konto bei der Netbank bereitete jedoch keine Probleme. Alle Versuche, den Netzwerkverkehr zu belauschen, scheiterten. Der Datenaustausch erfolgte verschlüsselt und unsere Versuche, uns mit gefälschten Zertifikaten als Man-in-the-Middle zu platzieren, quittierte die App mit einem Verbindungsabbruch.

Im Dateisystem des iPhone fand sich die Datei Documents/.db/ MyFinanceCrypt.sqlitedb. Wie der Name es bereits andeutet, war sie verschlüsselt; eine Analyse zeigte keinerlei Struktur oder andere Auffälligkeiten. Das änderte sich allerdings, als wir iControl starteten. Da tauchte dann aus heiterem Himmel im gleichen Verzeichnis eine Datei namens MyFinance.sqlitedb auf – noch bevor wir das Passwort eingegeben hatten, wohlgemerkt.

Die SQLite-Datenbank von iControl enthält unter anderem Kontodaten und -bewegungen im Klartext.

Ein schneller Check zeigte, dass es sich tatsächlich um die zentrale Datenbank der App handelte, die diese in Erwartung des Passworts schon mal für uns entschlüsselt hatte. In ihr fanden sich unter anderem die gespeicherten Konto- und Überweisungsdaten. Der Entwickler Truong Hoang lieferte recht flott einen Fix, der die Datenbank erst nach der Passwort-Eingabe freigibt.

Doch auch die neue Version 2.3.7 hatte Schwächen. So stürzte die App nach dem Ändern des Passworts regelmäßig ab und ließ dann wieder eine unverschlüsselte Datenbank zurück. Die in der Datenbank abgelegten PINs und TANs sind zwar zusätzlich verschlüsselt, aber nur mit einem statischen String plus drei Zeichen aus der Geräte-ID. Das bringt wenig zusätzliche Sicherheit, da man die konkreten Details mit ein wenig Reverse Engeneering aus der App extrahieren kann.

Der Entwickler gestand freimütig ein, dass er lediglich Anwendungsprogrammierer, aber kein Sicherheitsexperte sei und iControl nur in seiner Freizeit am Wochenende weiterentwickle. Leider merkt man das auch am Resultat. Wer diesem Programm vertrauliche Daten anvertraut, handelt fast schon fahrlässig.

getestet: Version 2.8.1

Professioneller in Sachen Sicherheit geht es bei iOutBank zu. Der Hersteller Stoeger IT wirbt mit einem Prüfsiegel des TÜV Süd, das bestätigen soll, dass die App „erfolgreich auf Funktion, Datenschutz und Datensicherheit getestet und zertifiziert“ wurde. Das muss doch sicher sein, oder?

Auch hier zunächst ein guter Eindruck: Das schlampige Testpasswort brandmarkte iOutBank als „unsicher“ und vor dem Speichern der PIN oder TANs gab es einen Warnhinweis, dass Banken das im Allgemeinen nicht gestatten. Die Netzwerkkommunikation erfolgte verschlüsselt und falsche Zertifikate führten zu einer Fehlermeldung. Leider war deren Text wenig aufschlussreich und suggerierte eher ein Verbindungsproblem als einen Angriff mit ungültigen Zertifikaten.

Gelegentlich ist es schon ganz praktisch, wenn man den Kontostand auch unterwegs checken kann.

Auch bei iOutBank tauchte eine Klartext-Datenbank im Dateisystem auf – allerdings erst nach der Passworteingabe. Trotzdem bleibt es riskant, die unverschlüsselten Daten ins Dateisystem zu schreiben. Denn es hängt dann stark von den Implementierungsdetails von App, Betriebssystem und Dateissystem ab, ob nach dem Überschreiben respektive Löschen etwa im ungenutzten Speicher noch Reste erhalten bleiben. Und was passiert, wenn die App beispielsweise abstürzt und nicht mehr dazu kommt, die Verschlüsselungsfunktion aufzurufen?

Dass diese Gefahr trotz TÜV-Süd-Siegel durchaus real ist, demonstrierte der Hersteller selbst. Zugunsten der Bequemlichkeit beim Online-Banking kann der Anwender TANs erfassen oder importieren. Unter einer solchen Liste prangt dann ein prominenter Button für den Export. Dessen Betätigung führt dazu, dass iOutBank die Daten in eine Datei schreibt – verschlüsselt wie die App versichert.

Der Kontrollblick des argwöhnischen Testers verriet jedoch, dass die Daten im Klartext vorlagen, auch wenn die App nicht mehr aktiv war. Schlimmer noch: Sie wanderten auch mit dem nächsten Sync via iTunes auf den Mac- oder Windows-Rechner. Da das iTunes-Backup standardmäßig unverschlüsselt erfolgt, liegt dann auch auf dem PC eine komplette TAN-Liste im Klartext zur Abholung durch den nächsten Online-Banking-Trojaner bereit.

Wenns denn so wäre. Die exportierten iOutBank-Daten lagen im Klartext auf dem iPhone.

Die Ursache des Debakels: Die Verschlüsselung von Dokumenten erfolgte analog zur Datenbank über eine beim Beenden der App aufgerufene Funktion. Seit iOS 4 beendet der Klick auf den Home-Button eine Anwendung aber nicht mehr und der Hersteller hatte die App nicht vollständig umgestellt. Das holte er erst nach unserer Benachrichtigung mit Version 2.8.2 nach. Wer iOutBank mit iOS 4 einsetzt, sollte dieses mittlerweile im AppStore erhältliche Update möglichst schnell installieren, starten und danach ein Backup seines iPhones durchführen, um eventuell vorhandene Klartext-Dokumente zu verschlüsseln.

[Nachtrag: Nach Fertigstellung des Print-Artikels teilte uns der Hersteller noch mit, dass eine zukünftige Version keine Klartext-Dateien mehr anlegen soll.]

getestet: Version 1.6.0

Also doch lieber eine App von einer richtigen Bank? S-Banking wurde zunächst im Auftrag der Sparkassen entwickelt und trägt nach wie vor deren Logo. Allerdings unterstützt die meistgekaufte Finanz-App mittlerweile viele Banken und der Hersteller Star Finanz hat bereits mit Star Money Renommee im Bereich Online-Banking gesammelt.

Trotz Logo ist S-Banking keineswegs auf die Sparkasse beschränkt.

Wie man es von einer Bank erwartet, wird hier Sicherheit groß geschrieben: Eine Möglichkeit etwa, TANs abzuspeichern, sucht man vergeblich. Das sei „Sicherheitshinweisen der Sparkassen […] geschuldet, die das Speichern der TANs auf einem Endgerät aus Sicherheitsgründen explizit ausschließen“ erklärte man uns auf Nachfragen.

Trotzdem unterstützt die App natürlich Transaktionen und die Eingabe von TANs. Wenn der Anwender die dann ausgedruckt im Klartext mit sich herumträgt und womöglich zusammen mit dem iPhone verliert, hat wenigstens der Hersteller nichts falsch gemacht. Ähnliches gilt im Übrigen auch für mTANs, die S-Banking nicht mehr unterstützt: „Gemäß der Vorgaben des Zentralen Kreditausschusses und des BSI ist beim Mobile-Banking die Verwendung des mobilen TAN-Verfahrens nur zulässig, sofern die Datenübertragung über zwei unterschiedliche Kanäle erfolgt.“ Und das ist nicht mehr gewährleistet, wenn die TAN via SMS aufs iPhone kommt. Wer deshalb das deutlich unsicherere iTAN-Verfahren einsetzt, ist dann wieder selber schuld.

Die Analyse des Dateisystems förderte keine Schwächen zu Tage. Alle relevanten Daten waren permanent verschlüsselt; zu keinem Zeitpunkt fanden wir vertraulichen Klartext. Einziger Kritikpunkt bis dahin: Wenn man statt die App zu beenden oder in den Hintergrund zu schicken, sein iPhone in den Sleep-Modus versetzt und Stunden später wieder aufweckt, strahlt einen die nach wie vor voll funktionsfähige S-Banking-App an. Die beiden anderen Apps fordern in dieser Situation zur erneuten Eingabe des Banking-Passworts auf; Star Finanz hat uns versichert, das ebenfalls nachzubessern. Bis dahin ist es unbedingt zu empfehlen, wenigstens den optionalen Passcode des Systems zu setzen.

Diese Kommunikation zwischen S-Banking und Netbank-Server sollte eigentlich verschlüsselt sein. Der Man-in-the-Middle belauscht sie trotzdem.

Eine böse Überraschung gab es dann, als wir den Netzwerk-Sniffer anwarfen und Man-in-the-Middle-Angriffe durchführten: Ohne zu zögern, vertraute S-Banking die für die Postbank gedachten Daten einem Server an, der sich zwar mit einem gültigen SSL-Zertifikat auswies – aber mit einem Namen, der überhaupt nichts mit Banking zu tun hatte. Ein solches Zertifikat kann sich jeder Inhaber einer Domain innerhalb von wenigen Minuten kostenlos ausstellen lassen. Damit kann ein Angreifer im Netz nicht nur Online-Banking-Vorgänge belauschen, sondern diese auch nach seinem Gusto manipulieren und gefälschte Überweisungen absetzen.

Richtige Risse in der so sehr auf Sicherheit getrimmten Fassade gab es dann, als wir dieses Problem dem Hersteller meldeten. Selbstverständlich reagierte er sofort und versuchte sogar, innerhalb von 24 Stunden eine neue Version bei Apple einzuchecken (iPhone: 1.6.4 iPad: 1.5.3, Android laut Hersteller nicht betroffen).

Doch im Gespräch stellte sich heraus, dass man sich des Problems offenbar schon länger bewusst war, einen Fix allerdings wegen möglicher Probleme bei der Multibank-Fähigkeit erst für ein späteres Update vorgesehen hatte. Dieses „wird schon keiner merken“ ist nicht gerade die Art und Weise, wie man sich den Umgang mit ernsten Sicherheitsproblemen einer Banking-Applikation vorstellt.

In allen drei Online-Banking-Apps fanden sich gravierende Sicherheitsmängel, die letztlich TANs kompromittieren können und damit Online-Banking-Transaktionen gefährden. iControl enthält so viele Nachlässigkeiten, dass man nur empfehlen kann, einen großen Bogen darum zu machen. Bei iOutBank und S-Banking hingegen treffen unterschiedliche Philosophien aufeinander, bei denen nicht von vornherein klar ist, welcher Ansatz letztlich weniger Risiko bedeutet.

Es mag durchaus sein, dass iOutBank nach dem Update im regulären Betrieb alle Daten korrekt verschlüsselt. Das Design bedeutet aber, dass vielleicht nach dem nächsten Update ein Absturz dazu führt, dass wieder irgendwo kritische Klartextdaten herumliegen. Das spartanische S-Banking hingegen unterstützt zwar Transaktionen, trifft aber selbst keine Vorkehrungen, die dafür erforderlichen TANs zu
sichern. Wer dann unverschlüsselte iTANs mit sich herumträgt, riskiert, diese mit dem iPhone zu verlieren. Eine definitiv bessere Alternative sind TAN-Generatoren oder „optische“ TANs (chipTAN comfort, sm@rtTAN optic), wie sie immer mehr Banken anbieten.

Die pragmatische Lösung für den iPhone-Junkie ist es, mit dem Smartphone keine Überweisungen zu tätigen, sondern es lediglich zur gelegentlichen Kontrolle von Kontostand und Umsätzen einzusetzen. Dabei riskiert man lediglich, seine PIN und Kontoinformationen preiszugeben, aber wenigstens keinen direkten finanziellen Verlust.

[Nachtrag: Von allen drei Apps stellen die Hersteller mittlerweile aktualisierte Versionen bereit, in denen die gefundenen Sicherheitsprobleme behoben wurden. Wir haben diese Versionen allerdings nicht mehr getestet. Darüber hinaus gibt es die Apps zum Teil auch als lizensierte Versionen unter anderem Namen. Ob diese von den Sicherheitsproblemen ebenfalls betroffen oder gar aktualisiert wurden, ist uns nicht bekannt. Das gilt auch für Versionen für andere Plattformen wie Android.] (ju)