photoTAN-Hack von Banken-Apps verhindern

Bei der Deutschen Bank, der Commerzbank und der Norisbank wurden die Forscher fündig. Die Geldinstitute hatten die Zwei-Faktor-Authentisierung auf dem Smartphone zusammengeführt, auf die Einbindung einer Sicherheitsinstanz verzichtet und damit Einfallstore aufgemacht.

Die photoTAN-App ist eine beliebte Authentifizierungslösung beim Online-Banking, die gerade in Deutschland und in der Schweiz weite Verbreitung findet. Beim photoTAN-Verfahren muss der Nutzer einen Matrixcode vom PC, Notebook oder Tablet abscannen; die Smartphone-App generiert daraus eine TAN. "Das ist grundsätzlich ein sicheres Verfahren, weil daran zwei voneinander unabhängige Geräte beteiligt sind", beruhigt Vincent Haupert vom Lehrstuhl für IT-Sicherheitsinfrastrukturen der FAU.

Was ist passiert?

Die erfolgreiche Attacke gelang in einem Mobile-Banking-Szenario, bei dem die Mobile Banking-App und die photoTAN-App auf dem gleichen mobilen Gerät installiert waren: 1-Device/2-App Strategie. Erst im vergangenen Jahr hatten die Wissenschaftler mit einer ähnlichen Verfahren aufgezeigt, wie zum Beispiel die von den Sparkassen verwendete PushTAN erfolgreich angegriffen werden kann.

Zum eigentlichen photoTAN-Verfahren sind jedoch zwei Geräte nötig: eines, um die Matrix-Grafik mit den Transaktionsdetails (beispielsweise IBAN und Betrag) anzuzeigen und ein zweites, um diese abzufotografieren und dann die TAN zu generieren.

Dieser ursprüngliche photoTAN-Ansatz ist grundsätzlich nicht mit 1-Device Strategien vereinbar, weil man den auf dem Smartphone bereitgestellten Matrixcode nicht mit demselben Gerät fotografieren kann. Ergo greift die Banking-App direkt auf die TAN-App zu, um die Transaktion auszulösen.

Die betroffenen Banken haben beim mobilen photoTAN-Verfahren die Zweifaktor-Authentifizierung auf einem Gerät zusammengeführt und "so abgekürzt, dass die Transaktionsdetails aus der Mobile Banking App lokal - App-to-App - an die photoTAN App übertragen werden und die dort generierte TAN ebenso lokal zurück übertragen wird", erklärt Markus Tak, CTA/Chief Technology Architect von Kobil Systems, einem deutschen Security-Unternehmen, das sich auf Lösungen für Digitale Identitäten spezialisiert hat und mit der intelligenten Softwarelösung "mIDentity Application Security Technology" (mAST) entsprechend abgesicherte Banking-Kommunikationsketten ermöglicht.

Die von den Erlanger Forschern angegriffene photoTAN App ist stets offline, hat also keine Verbindung zu einem Server, obwohl sie das sensible Schlüsselmaterial zur Erstellung von TANs und die Komponente zur Visualisierung der Transaktionsdetails beherbergt.

Wie lief die Manipulation ab?

Durch den Einsatz verschiedener Hacking-Technologien gelang es den Sicherheitsforschern, sowohl die Mobile-Banking-App als auch die photoTAN App derart zu manipulieren, dass eine andere Überweisung ausgeführt wird als diejenige, die der Benutzer erfasst hat. Für den Benutzer sieht es so aus, als ob dessen beabsichtigte Überweisung ausgeführt würde, aber im Hintergrund - verborgen durch den Hacker Angriff - wird eine ganz andere Überweisung gegenüber der Bank ausgeführt, und diese ist aus Sicht der Bank vollständig legitimiert.

Brisant sind die Ergebnisse der FAU-Informatiker auch vor dem Hintergrund der im Januar 2016 in Kraft getretenen Zweiten Zahlungsdiensterichtlinie (PSD II), die nach einer Übergangsphase von zwei Jahren für alle Zahlungsdienstleister verbindlich wird. Hierfür hat die Europäische Bankenaufsichtsbehörde EBA einen Entwurf zur konkreten Ausgestaltung der obligatorisch werdenden starken Kundenauthentifizierung vorgelegt.

Danach müssen Zugriffe auf das Konto - Transaktionen genauso wie das Abfragen des Kontostands - mit zwei unabhängigen Authentifizierungselementen aus dem Bereich Wissen (Passwörter, Codes), Besitz (EC-Karte, TAN-Generator, Smartphone) und Inhärenz (biometrische Merkmale wie Fingerabdruck oder Iris) autorisiert werden. Darüber hinaus muss die Unabhängigkeit der verwendeten Elemente garantiert werden, so dass ein kompromittierter Faktor nicht auch das zweite Authentifizierungselement kompromittiert.

Wie lässt sich das sicherstellen?

Es müssen Lösungen zum Einsatz kommen, die Frontend- und Backend-Komponenten den Vorgaben von EZB und PSDII entsprechend absichern - durch den Einsatz gehärteter Apps und die Einbindung vertrauenswürdiger Instanzen: einem speziellen Sicherheitsserver, so dass Transaktionen nicht nur über rein lokale App-to-App Kommunikation getätigt werden.

• Gehärtete Smartphone-Apps beispielsweise können über eine 2-Faktor-Authentifizierung die digitale Identität eines Nutzers zweifelsfrei bestätigen, sie weisen außerdem einen zweiten sicheren Kommunikationskanal aufweisen und sichern zum anderen die kommunizierten Daten verschlüsselt gegen Hacker-Angriffe ab.

• Ein spezieller Security-Server im Backend nimmt dann die Überprüfung vor. Die freizugebenden bzw. zu signierenden Transaktionsdetails werden dabei nicht lokal von der Mobile Banking App zur Security App übertragen, sondern laufen über den Banking Server und den Security-Server und werden von dort aus über den Sicherheitskanal zur Security App weitergeleitet. Dadurch lassen sich Transaktionsdetails serverseitig nochmals prüfen und sie können nicht unbemerkt verändert werden. Auch die Weiterleitung an die Security App findet nur nach eingehender Prüfung des Mobile Devices bzw. der Apps statt.

• Eine weitere Sicherheitskomponente stellt eine Virtuelle Smartcard dar. Dieser Signatur-Schlüssel in der Security App wird erst dann kryptographisch freigeschaltet, nachdem der Security-Server eine Reihe von Security Sensoren am Mobile Device beziehungsweise der App erfolgreich überprüft hat, u.a. die Gerätebindung (Besitz und Wissen respektive 2-Faktor-Authentisierung) aber auch die Integritäts-Checks, mit denen Manipulationen an der App erkannt werden.

• Über einen dedizierten Sicherheits-Kanal schließlich ist der Signatur Schlüssel in der Security App nicht "lokal" von der Mobile Banking App aus erreichbar: die Mobile Banking App hat keinen direkten Zugriff darauf, sondern nur über den oben beschriebenen "Umweg" über den Sicherheitsserver. Nur authentisch vom SSMS Server (über den Security Kanal) übermittelte Signatur Anfragen werden verarbeitet. (sh)