App Security-Spezialist Build38 begrüßt Manuel Holzhauer als neues Advisory Board-Mitglied

Fokussierung auf die digitale Transformation im Finanz- und Versicherungsmarkt

Ab sofort bringt sich Manuel Holzhauer als neues Mitglied im Advisory Board von Build38 mit ein. Dabei profitiert das Start-up von seiner langjährigen Erfahrung und dem weitreichenden Netzwerk aus seinen Aktivitäten in der Start-up-, Finanz- und Versicherungsbranche. Zurzeit ist Holzhauer als Insurance Industry Executive bei Microsoft tätig.

Vor seiner derzeitigen Funktion bei Microsoft hat Manuel Holzhauer im Laufe seiner Karriere für viele namhafte Unternehmen und Organisationen wie PricewaterhouseCoopers, Accenture, Munich Re und dem InsurTech Hub Munich gearbeitet. Über den InsurTech Hub kennt und unterstützt er die Build38 GmbH schon seit deren Gründung. Er hat eine Passion für Innovationen und die digitale Transformation im Finanz- und Versicherungssektor. Gerade in der Finanzbranche ist die Kundenzentrierung ein entscheidender Wettbewerbsfaktor. Dies gilt für interne Prozesse, aber viel mehr noch für externe Kundenschnittstellen. Hier sollte der Kundennutzen zu jedem Zeitpunkt im Mittelpunkt stehen. Beispielsweise lassen sich mit mobilen Apps neue Konzepte umsetzen, die die Kommunikation mit den Kunden verbessern sowie die Ausführung von Transaktionen vereinfachen.

„Mobile Apps als Frontend zum Kunden haben bei vielen Unternehmen inzwischen einen sehr hohen Stellenwert. Hierbei legen Entwickler und Betreiber jedoch häufig ihr Hauptaugenmerk auf die Funktionalitäten beziehungsweise die User Experience, nicht aber auf die notwendige Security und Compliance. Da aber vor allem der Banken- und Versicherungsbereich Sicherheit als wesentliches Leistungsversprechen hat, stellen Cyberangriffe eine enorme Gefahr dar, welche schnell zu einem Reputationsrisiko werden kann. Daher ist es aus meiner Sicht unerlässlich, geeignete Sicherheitsmaßnahmen zu ergreifen. Aus diesem Grund sehe ich es als essenziell an, App Security schon während der frühen Entwicklungsphase zu integrieren. Genau hier setzt das innovative Konzept von Build38 an“, sagt Holzhauer.

„Wir freuen uns, mit Manuel Holzhauer einen erfahrenen Experten an Bord zu haben, der uns mit seinen inspirierenden Ideen und guten Beziehungen dabei hilft, Brücken in die Finanz- und Versicherungswelt zu bauen. Mit seiner Unterstützung gelingt es uns, die Reichweite unseres App Security-Ansatzes zu vergrößern, neue Kontakte zu knüpfen und Geschäftsprozesse voranzubringen“, sagt Dr. Christian Schläger, CEO von Build38.

Manuel Holzhauer, neues Mitglied im Advisory
Board von Build38


Banking Fraud

Banking Fraud: Mit App-Sicherheit Bankdaten schützen

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.


Sicheres Mobile Banking: Build38 als Teilnehmer der Financial Institutions Edition des Nordic IT Security Summit

Cybersecurity-Event für den Finanzsektor

Weltweit kommt es immer öfter zu Cyberattacken. Gerade Banken und Finanzinstitute sind sehr stark davon betroffen. Um den Finanzsektor bei der Thematik Cybersecurity zu unterstützen, wurde die Financial Institutions Edition des jährlichen Nordic IT Security (NITS) Summit ins Leben gerufen. Damit wird eine Plattform für die Fintech-, E-Commerce- und Mobile Banking-Branche geschaffen, die eine optimale Gelegenheit zur Vernetzung und zum gegenseitigen Austausch bietet. Das Event findet am 15. und 16. April 2021 statt. Insgesamt nehmen viele führende Branchenvertreter an dem Summit teil, skizzieren ihre Visionen und teilen wertvolle Geschäftseinblicke. Zudem ist es möglich, virtuelle Ausstellungen zu durchstöbern, in denen modernste Technologien präsentiert werden. Auch Build38, Experte für die Sicherheit mobiler Banking-Apps, ist Teil der digitalen Veranstaltung.

Nordic IT Security - The Financial Institutions Edition Gerade durch die Corona-Situation wird das Mobile Payment noch häufiger von Kunden in Anspruch genommen. Gleichzeitig ist es dadurch aber auch verstärkt in den Fokus von Cyberkriminellen gerückt, die Banking-Apps hacken und sich so Zugriff auf die persönlichen Zahlungsdaten der Kunden verschaffen. Mit der frühzeitigen Integration eines mehrschichtigen Security-Frameworks, das alle notwendigen Sicherheitsfunktionen umfasst, lässt sich dieses Risiko jedoch eliminieren. Build38 hat ein solches Framework entwickelt, das bekannte und unbekannte Angriffe jederzeit verhindert und Banking-Apps somit optimal absichert. Gemäß dem Shift Left Security-Ansatz lässt sich das Software Development Kit (SDK) schon während der frühen Entwicklungsphase in kürzester Zeit integrieren. Damit ist die Sicherheit von vornherein gegeben. Im Rahmen des Events können sich die Teilnehmer intensiv über das Trusted Application Kit (T.A.K) von Build38 informieren.

Weitere Informationen zu der Veranstaltung finden Sie hier.