Banking Fraud: Mit App-Sicherheit Bankdaten schützen

Vor einigen Wochen meldete IBM Trusteer eine massive Betrugsaktion gegen Banken, die zu Verlusten in Höhe von mehreren Millionen Dollar führte. Den Angreifern ist es zum einen gelungen, die Anmeldedaten von zahlreichen Endbenutzern zu stehlen. Zum anderen haben sie es geschafft, das Fraud-Management-Konzept der Banken zu umgehen, um Millionen an kleinen Transaktionen zu automatisieren, die unentdeckt alle Risikoanalyse- und Sicherheitsinfrastrukturen passieren können und potenziell auch vom User nicht bemerkt werden.

Der erste Schritt wurde offenbar mithilfe einer Art Social-Engineering-Angriff durchgeführt, bei dem Malware auf dem Gerät des Benutzers installiert wurde. Im zweiten Schritt hingegen verwendeten die Angreifer Emulatoren, um das Betrugsmanagementsystem der verschiedenen Banken „auszutricksen“. Hieraus ist zu schließen, dass das Fraud-Management-System in diesem Fall seine Aufgabe nicht richtig erfüllt hat. Denn diese besteht genau darin, vor solchen Situationen zu schützen, in denen die Benutzer getäuscht wurden.

Identifizieren der Schwachstelle

Ein Anti-Fraud-System sollte eigentlich Situationen erkennen, in denen ein Benutzerkonto auf einem anderen Gerät als dem des rechtmäßigen Benutzers verwendet wurde. So ist es ein typisches Szenario für das Fraud Management, wenn das System bemerkt, dass der Benutzer ein iPhone verwendet, während er sich normalerweise von einem Samsung-Gerät aus verbindet. Damit es den Hackern gelingt, die Anti-Fraud-Lösung zu überlisten, haben sie Emulatoren verwendet. Damit sieht es so aus, als würde das Gerät des Users genutzt, obwohl dies in Wirklichkeit nicht der Fall war.

Da die Forscher nicht genügend Details genannt haben, lässt sich die Funktionsweise nicht eindeutig bestimmen. Es ist aber anzunehmen, dass die Angreifer

• es irgendwie geschafft haben, Malware in das Gerät des Benutzers einzuschleusen (beispielsweise über einen Phishing-Betrug).
• diese Malware verwendet haben, um Anmeldedaten und Geräteinformationen zu stehlen und Zugriff auf SMS zu erhalten.
• mit den erbeuteten Informationen ein automatisches Schema eingerichtet haben, das
  a) das Einrichten eines Emulators erlaubte, der (in den Augen des Anti-Fraud-Systems) genau wie das Gerät eines Benutzers aussieht.
  b) sich mit den gestohlenen Anmeldedaten bei der Banking-App angemeldet hat. Da das Gerät wie das des Users aussah, reagierte das Anti-Fraud-System nicht.
  c) das Ausführen einer kleinen Transaktion ermöglichte, die im System der Bank keinen Verdacht erregt (und wahrscheinlich vom Benutzer unbemerkt bleibt).
  d) in der Lage war, diese Schritte innerhalb weniger Tage millionenfach zu wiederholen und so effektiv Millionen von Dollar zu stehlen.

Es gibt mehrere Dinge, die in diesem Szenario hätten anders gemacht werden können. Wir wollen uns in erster Linie darauf konzentrieren, wie es den Angreifern gelungen ist, das Gerät zu „fälschen“; oder anders ausgedrückt, wie stark der Mechanismus zur Geräteidentifikation war. Um diese Frage zu beantworten, ist es sinnvoll, sich in die Lage des Angreifers zu versetzen.

Der relevante Schritt bei der „Fälschung“ des End User Device ist das Sammeln der richtigen Geräteinformationen, die später verwendet werden sollen. Denn das Wichtigste, was der Angreifer wissen muss, ist, welche Informationen das Fraud-Management-System verwendet, um ein Gerät zu identifizieren. Am Ende sind das die Informationen, die die Hacker – mit Hilfe der Malware – aus dem Endgerät extrahieren müssen, um es fälschen zu können.

Höchstwahrscheinlich verwendet das Fraud-Management-System viele verschiedene Werte zur Geräteidentifikation: Einige davon sind offensichtlich, andere eher weniger. Unter den offensichtlichen Werten finden sich Dinge wie der Gerätehersteller, das Gerätemodell, die Betriebssystemversion, die Android-ID (für Android-Geräte) oder die IDFV (für iOS-Geräte). Diese sind jedoch nicht so relevant, da jedes Geräteidentifikationssystem sie verwenden würde.

Die eigentliche Stärke des Device Identification-Systems liegt in den nicht so offensichtlichen Gerätekennungen, insbesondere darin, wie viele von ihnen verwendet werden und wie gut sie geschützt sind. Hier ist es nicht so wichtig, welcher Parameter verwendet wird, sondern wie schwierig es für einen Angreifer ist zu wissen, dass er verwendet wird. Am Ende besteht das Ziel des Angreifers darin, ein Stück Malware zu schreiben, das die Parameter sammelt – und genau das gilt es zu verhindern.

Die Schwäche ausnutzen

Die Frage ist also: Woher könnte ein Angreifer wissen, welche Gerätekennungen verwendet werden?

• Der einfachste Ansatz wäre wahrscheinlich, die von der App an das Backend übertragenen Informationen mithilfe einer MITM-Attacke auszuspionieren. Durch die Analyse des Datenverkehrs würde der Angreifer ein gutes Verständnis dafür bekommen, welche Identifikatoren verwendet werden.
• Eine andere Möglichkeit wäre, den Quellcode der Anwendung zu lesen, um die Routinen zu finden, die diese Informationen sammeln und an die Backend-Systeme senden. Da der Quellcode dem Angreifer vermutlich nicht vorliegt, wird die Alternative die dekompilierte Binärdatei sein. Sie ist zwar nicht so nützlich wie der Quellcode, aber durch eine statische Analyse lassen sich daraus eine ganze Reihe von Informationen extrahieren.
• Die letzte und schwierigste Option, die dem Hacker zur Verfügung steht, wäre die dynamische Analyse. Beispiele dafür sind das Debuggen der Anwendung während der Ausführung und die Verwendung eines Hooking-Frameworks wie Frida.

All diese Optionen müssen aber nicht erfüllt sein: Der Angreifer muss nur bei einer von ihnen erfolgreich sein, um den gesamten Angriff erfolgreich durchzuführen. Lösungen, die nur eines der Szenarien verhindern, machen dem Angreifer das Leben schwer, verhindern aber nicht, dass er Erfolg hat.

Apps richtig schützen

Bedenkt man all das, lässt sich sagen, dass ein starkes Konzept zur Geräteidentifizierung Folgendes leisten sollte:

1. Viele, nicht offensichtliche Gerätekennungen verwenden. Je mehr Device Identifier, desto besser.
2. Schutz vor MITM-Angriffen. Das Abhören des Netzwerkverkehrs liefert eine Menge Informationen. Daher ist ein guter Schutz an dieser Stelle ein Muss.
3. Verschleiern der sensiblen Teile der Binärdatei. Bei mobilen Anwendungen haben Angreifer immer Zugriff auf das Binärprogramm. Daher ist eine angemessene Verschleierung zur Verhinderung statischer Analysen entscheidend.
4. Vorbeugung gegen dynamische Analyse. Wenn die statische Analyse nicht ausreicht, werden Angreifer auf die dynamische Analyse zurückgreifen: Debugging, Instrumentierung, Modifizierung der App usw. Das bedeutet, dass unter anderem der Schutz vor Debuggern, Hooking-Frameworks und Code-Injektion ebenfalls wichtig ist.

Unter einem breiteren Blickwinkel betrachtet, lässt sich schlussfolgern, dass eine angemessene Endpoint Protection ein Muss für Lösungen zur Fraud-Prävention ist, die auf der Identifizierung von End User Devices basieren. Andernfalls wird es Angreifern gelingen, „gefakte“ Daten einzuspeisen, die die im Backend implementierten Schutzmechanismen umgehen.