Banking-Sicherheit: Mobile Apps, APIs und die PSD2 – das Risiko fehlenden Binärcodeschutzes

Die Ära der offenen Programmier­schnitt­stellen (API) ist im Banking längst angebrochen – Stichwort PSD2. Doch die Sicherheit der notwendigen API und der Banking-Anwendungen selbst rückt erst jetzt richtig in den Fokus. Banken und Entwickler müssen nun auf die richtigen Sicher­heits­tech­no­lo­gien setzen, wenn sie auch weiterhin höchste Sicherheit gewährleisten möchten.

von Mirko Brandner, Technical Manager, Arxan Technologies

Die Vorteile der neuen Zahlungsrichtlinie PSD2 liegen auf der Hand: Der Wettbewerb zwischen den Zahlungsdienstleistern wird das Finanz-Ökosystem mehr denn je beleben und den Verbrauchern eine noch nie dagewesene Auswahl an Anbietern, Technologien und Innovationen bereitstellen. Damit dies gelingt, bedarf es jedoch Standardschnittstellen (APIs), die einen mühelosen Datenaustausch zwischen Bank und Drittanbieter und eine reibungslose Kommunikation zwischen Apps und Servern ermöglichen.

Diese Schnittstellen bzw. die damit verbundenen Sicherheitsrisiken sind wiederum ein nicht zu verachtender Nachteil der PSD2. Denn immerhin enthalten die APIs alle sensiblen Schlüssel, die Hackern den Zugang zu den kritischen Daten verschaffen können.”

API: Einfache Authentifizierung begünstigt die Freilegung sensibler Schlüssel

Die größte Schwachstelle von APIs ist der Einsatz von einfachen Authentifizierungsverfahren. Viele API-Lösungen setzen auf einen herkömmlichen Challenge-Response-Austausch, um die Echtheit der Client-App zu bestätigen und deren Zugriff auf die Server-Ressourcen freizugeben. Dieser Austausch ist in der Regel eine kryptographische Operation, d.h. der mobile Client enthält üblicherweise einen geheimen Schlüssel für eine asymmetrische Chiffrierung wie Rivest Shamir Adleman (RSA) oder Elliptische Kurvenkryptographie (ECC). Ist ein Angreifer nun in der Lage, die erste Sicherheitsbarriere zu durchbrechen und den Code zu dekompilieren, bedeutet es für ihn keine große Anstrengung mehr, die sensiblen Kodierungsschlüssel freizulegen. Ist der Hacker erst einmal so weit gekommen, kann er einen legitimen Client vortäuschen und sich auf diese Weise Zugriff auf grundsätzlich alle Systeme verschaffen, die zur API eine Verbindung herstellen dürfen. Eine Schnittstelle, die auf Daten auf dem Backend-Server für eine Cloud-Anwendung zugreift, bietet Angreifern beispielsweise die Möglichkeit, vertrauliche Daten abzugreifen oder andere schädliche Aktivitäten auszuführen. Im Falle von Bank-Anwendungen können so Kontodaten ausgespäht und Transaktionen manipuliert werden.

Das Risiko fehlenden Binärcodeschutzes

Unsichere API-Management-Lösungen sind aber nur die eine Seite der Risiko-Medaille. Denn damit Mobile Banking und Mobile Payment auch in Zeiten von Drittanbieter-Services sicher ist, müssen allen voran die Banken- sowie die Drittanbieter-Anwendungen gegen schadhafte Manipulationen und Datendiebstahl immun sein. Dass diese Sicherheit in vielen Fällen nicht gewährleistet wird, zeigen verschiedene Studien immer wieder. So hat eine Untersuchung von Pradeo Lab, bei der 50 Apps der weltweiten Top-100-Banken auf Sicherheitslücken hin überprüft wurden, alarmierende Ergebnisse zu Tage gebracht. Jede Anwendung wies demnach im Durchschnitt sieben verschiedene Sicherheitslücken auf und keine einzige der überprüften Apps war ohne Sicherheitsmangel. Aber auch „gutwillige Hacker“ wie der Informatiker Vincent Haupert von der Universität Erlangen-Nürnberg forschen zu diesem Thema. Schon mehrmals hatte Haupert kritische Sicherheitslücken in beliebten und weit verbreiteten Banking-Apps identifiziert und die Anbieter vor möglichen Kompromittierungen gewarnt. Im Jahr 2015 konzentrierten sich seine Hacking-Bemühungen etwa auf eine TAN-vermittelnde App eines bekannten deutschen Kreditinstituts, die zusammen mit der regulären Banking-App Online-Banking auf einem einzigen Gerät ermöglicht. Dabei konnte Haupert die Sicherheitsmechanismen der App deaktivieren und im Anschluss eine Überweisung manipulieren, ohne dass ein Opfer die Manipulation bemerkt.

Was den Großteil der Finanz- und Bezahl-Applikationen so gefährlich macht, ist zum einen das Fehlen eines wirksamen Binärcodeschutzes. Diese Sicherheitslücke begünstigt Reverse Engineering und öffnet Hackern Tür und Tor für gefährliche Manipulationen. Und auch eine unzureichende Sicherung der Transportschicht macht Apps zu einem Risiko, da hier die Gefahr besteht, dass die Kommunikation zwischen App und Server offengelegt wird und Cyber-Kriminelle auf diese Weise sensible Daten ausspähen können.

Reverse Engineering und Laufzeitmanipulation effektiv verhindern

Sicherheit steht im Bankensektor seit jeher an oberster Stelle. In Zeiten zunehmender Digitalisierung und neuer „Open Banking“-Modelle darf sich daran nichts ändern. Der Einsatz effektiver Application Protection-Technologien, die über herkömmliche Standard-Lösungen hinausgehen, ist für Banken und andere Finanzdienstleister längst keine Kür mehr, sondern letztlich unabdingbar. Dabei ist es wichtig, dass sich die verschiedenen Sicherheitsmaßnahmen sinnvoll ergänzen und ein undurchdringbares Netzwerk an Schutzmechanismen bilden. Jede sensible Applikation muss letztlich selbstständig in der Lage sein, erstens Manipulationen abzuwehren, zweitens Laufzeit-Angriffe aufzuspüren und drittens mögliche Schäden zu melden und zu reparieren.

Um ersteres gewährleisten zu können, müssen die sensiblen Schlüssel der Anwendung anspruchsvoll verschleiert werden.

Hierfür empfehlen sich Code-Härtungs-Maßnahmen wie etwa fortgeschrittene Obfuscation-Techniken, bei denen Programmcodes und ihre Kontrollstrukturen in unlesbare Formen gewandelt werden und auf diese Weise Reverse Engineering und eine Dekompilierung (Wiederherstellung des Source Codes) des zugrundeliegenden Bytecodes verhindern.”

Aber auch String Encryption, d.h. die Verschlüsselung von Klartext-Zeichenketten, oder Dynamic-Damage-Technologien, die Code oder Daten gleich nach der Benutzung zerstören und so eine dynamische Analyse des Speichers erschweren, sind äußerst effektive Schutzmaßnahmen.

Manipulationen während der Laufzeit einer Applikation lassen sich am besten mit Hilfe von Checksum-Tools verhindern. Eine spezielle in die App eingebaute Logik spürt manipulative Veränderungen an Code und Daten auf, indem sie während der Laufzeit Prüfsummen berechnet und miteinander vergleicht. Zusätzliche Sicherheit gewähren Anti-Debug-Tools, die aufgeschaltete Debugger aufspüren und entsprechend reagieren können.

Genauso wichtig wie die Identifikation und Abwehr von Cyber-Manipulationen ist jedoch auch eine angemessene Reaktion und die vollständige Reparatur möglicher Modifikationen. App-Protection-Lösungen der nächsten Generation bieten den App-Anbietern die Möglichkeit, individuelle Reaktionen auf Cyber-Angriffe festzulegen. Neben dem Beenden einer App, z.B. bevor ein Bezahlvorgang eingeleitet wird, kann dies bei sensiblen Banking-Apps auch das Löschen sensitiver Daten oder kryptographischer Schlüssel sein.

Darüber hinaus sollte die App über Self-Repair-Fähigkeiten verfügen, d.h. in der Lage sein, bösartige Veränderungen am Code oder an kritischen Daten rückgängig zu machen, indem die ursprünglichen Werte zur Laufzeit automatisch wiederhergestellt werden.”

Die neue Zahlungsrichtlinie PSD2 und die damit verbundene Öffnung des Banken- und Bezahlmarktes zwingen Finanzdienstleister zu einem Umdenken und einer neuen IT-Security-Strategie. Ein sicherer Austausch von persönlichen und finanziellen Daten kann aber letztlich nur gelingen, wenn alle Akteure und Anbieter konsequent in Sachen Sicherheit an einem Strang ziehen. Denn nur wenn APIs, Banking- und Drittanbieter-Applikation sicher sind, sind die Reputation der Anbieter und die Finanzen ihrer Kunden vollständig abgesichert. Denn eine geschützte Bankenanwendung garantiert keine sichere Transaktion, wenn die Drittanbieter-App eine Schwachstelle hat – und umgekehrt. Einmal mehr ist ein ganzheitlicher und umfassender Sicherheitsansatz unumgänglich.aj