 von einem alten Bekannten, der schon zum 32 C3 und zum 33 C3 uns in eine wundersame Welt entführt hat, voller mobiler Endgeräte und unsicherer Verbindungen und dem Vertrauen, was wir darin stecken. Er ist Doktorand an der Uni Erlang Nürnberg, die hat auch einen langen Namen, den ich nicht aufgeschrieben habe. Er ist Doktorand der Informatik, interessiert sich besonders für die Sicherheit von Mobilgeräten und wird uns heute die fabelhafte Welt des Mobile-Bankings näher bringen. Beruhst mit mir, Vincent Haupert. Ja, herzlichen Dank für die Einführung. Ja, fabelhaft ist ja ein sehr vielschichtiges Wort. An dieser Stelle möchte ich zuerst einmal die fabelhafte Zusammenarbeit mit meinem Kollegen Nikolas Schneider hervorheben, ohne den diese Arbeit hier in der Form nicht möglich gewesen wäre. Herzlichen Dank an ihn. Ja, Online-Banking, ich denke mal so gut wie jeder hier durfte das machen, ist hingelänglich bekannt, ist seit jeher im Pintan-Verfahren, seitdem vor 30 Jahren, jetzt bin ich weg. Test? Ja? Ah, okay, hört man nicht auf. Sorry. Also seit jeher im Pintan-Verfahren und ja, also erster Faktor ist irgendwie immer, man lockt sich im Online-Banking-Portal ein mit seinem Benutzernamen Passwort und danach muss man eine Transaktion aufgeben mit einer E-Bahn, mit einem Betrag und im zweiten Schritt hat man dann irgendein Tantverfahren mit dem man die Transaktion bestätigen muss. Also das ist ganz klare Sicherheitselemente, dass es seit Anfang des Online-Bankings gibt. Ja, und die Art und Weise, wie man im Pintan generiert, empfängt, abliest, ist recht unterschiedlich. Die ersten drei Verfahren, die man jetzt hier auf dieser Liste sieht, das E-Tantverfahren, SMS-Tantverfahren und Chip-Tantverfahren, sind hauptsächlich aus der Motivation entstanden, dass es relativ viele Schadensfälle in dem Bereich gab, also Fishing vor allem und mit Chip-Tan ist man da quasi an den Zenit angereicht, erlangt, ja, technisch kann man das eigentlich kaum noch besser machen, dass natürlich auch noch andere Aspekte wie Benutzerfreundlichkeit, die da wichtig sind. Deswegen gingen dann so die Verfahren wie Fototan oder auch Eptan gehen dann eigentlich mehr in die Richtung, dass sie die Benutzerfreundlichkeit adressieren wollen, was auch durchaus legitim ist. Per se habe ich eigentlich auch gar nichts gegen Ept-basierte Tantverfahren, solange man zwei Geräte verwendet. Also wenn man eine zwei Geräte-Authentifizierung macht, hat man ja immer noch den Schutz, dass wenn ein Gerät kompromittiert ist, dass andere nicht, ja, zumindest nicht automatisch mit den Mitleidenschaft gezogen wird. So, von daher ist es durchaus legitim. Ich kann mich erinnern, vor zwei Jahren, als ich hier den Talk gehalten habe, wurde ich nach Fototan gefragt und habe noch gesagt, das ist ein relativ solides Verfahren, weil es ja implizit eigentlich forciert, dass man zwei Geräte verwendet, weil man muss man ja von dem anderen Gerät abscannen und das generiert dann die TAN. Dann gibt es halt die Verfahren, die Push-Tan-Verfahren, bzw. die, die über zwei Apps realisiert sind, also eine die Banking-App, die andere TAN-App, das gibt es jetzt mittlerweile seit Jahren und das Paradoxe ist, dass man mittlerweile auch Fototan auf einem Gerät machen kann. Also da kann man zwar nichts mehr abscannen, sondern die kommunizieren einfach untereinander, aber das zeigt eigentlich erst mal, wie abstrus es wird. Ja, aber eigentlich redet auch heute keiner mehr über zwei App-Verfahren, vielleicht war das auch nur eine Art und Weise, um uns daran zu gewöhnen, dass es eigentlich keine richtige zwei Fakta-Authentifizierung mehr gibt und eigentlich will heute jeder ein App-Verfahren implementieren. Das ist insofern eigentlich bemerkenswert, weil das SMS-Tan-Verfahren, wenn man sich das mal anschaut, hat ja eine Geräteentwicklung durchgemacht von einem Spezialgerät hin zu einem Mehrzweckgerät, also heute empfängt ja jeder seine SMS auf einem Smartphone und es ist im Prinzip auf eine bestimmte Art und Weise auch eine App, mit der man das empfängt. Und damals war es dann das erste Mal möglich, dass man von einem Gerät aus eine Transaktion aufgibt und bestätigt und da hat die deutsche Kreditwirtschaft Weise 2008 schon erkannt, dass das keine so gute Idee ist. Dies impliziert bereits, dass die Verwendung des mobilen Tan-Verfahrens zum Beispiel über nur ein mobile Smartphone für beide Kommunikationsstrecken nicht zulässig ist und daher in den Kundenbedingungen für das Online-Backing explizit ausgeschlossen wird. Dies impliziert bereits, so ist ja eh klar. Jetzt frage ich mich natürlich, wo ist denn da jetzt dann der Unterschied? Also hier wird ja auch alles auf einem Gerät gemacht und das habe ich vor zwei Jahren dann auch gezeigt, haben dann einen Angriff auf das Push-Tan-Verfahren gezeigt mit einer Transaktionsmanipulation. Das hat entgegen die Sparkasse nicht so richtig beeindruckt, die haben halt gesagt, ja das waren eigentlich alles nur Laborbedingungen, das geht in Wirklichkeit gar nicht und es funktioniert nur bei genau einem Gerät, genau einer App und bei genau einer Version und jedes Mal, wenn wir eine neue Version rausbringen, ist es ein hoher individueller und manueller aufwand und genau das werden wir heute adressieren. Jetzt habe ich ja vorhin gesagt, bei SMS-Tan hat man gesagt, ja das machen wir nicht, das ist das nicht sicher und jetzt muss man sich fragen, was ist denn dann eigentlich anders bei diesen Apps, also da gibt es eine ganze Reife und Eigenschaft, aber ich denke wichtig ist diese Absicherung durch Dritte und zwar gibt es mittlerweile einen recht großen Markt an Drittanbietern, die App-Herzungen und App-Sicherheit verkaufen, also Drittanbieterprodukte und das ist jetzt tatsächlich nur eine kleine Auswahl und denjenigen, den wir uns heute etwas genauer anschauen werden, ist Promon. So, Promon hat das Produkt Promon Shield und das ist die Information, die hier stehen, sind alle Samt von der Webseite und der Zweck von Promon Shield ist, Schutz von Apps in nicht vertrauenswürdigen Umgebungen. Das Ganze ist universal, das heißt es ist egal, was für eine App das ist und das ist plattformunabhängig, also geht unter Android und IOS und die haben auch Lösungen für Windows. Ja, und es ist anwendbar innerhalb von wenigen Minuten und das ist jetzt aus dem Video des nächsten Zitat, es erkennt und verhindert jede Gefahr in Echtzeit und reagiert, indem es die notwendigen Schritte einleitet, um die App vollständig zu schützen. Die App wird dadurch sicher verwendbar, sogar auf hochgradig Infizierten gerätten. Schauen wir uns das mal genauer an. So, was gibt es denn eigentlich so Vereigenschaften, die diese ganzen App-Herzungsgeschichten implementieren? Also das sind jetzt zwei Sparten, da gibt es diesen klassischen App-Herzungsbereich, der will statische und dynamische Analyse hauptsächlich verhindern und dann gibt es einen eher neueren Bereich, da geht es dann eher um so Security-Best-Practices, also solche Sachen wie Zertificate-Pinning und dass man halt die Anwendungsdaten nochmal verschlüsselt, also klassische Sachen, die die Entwickler normalerweise gemacht haben. Und deswegen werden die mittlerweile zum Dreh- und Angelpunkt für sowas und es ist gerade im Bereich des Mobile-Banking sind die ja eine wichtige Nummer. Wie verwendet man denn jetzt eigentlich das Promo-GIS? Wenn ich das jetzt verwenden will für meine App, für meine Android oder iOS-App, die links unten dargestellt ist, muss ich jetzt als Kunde noch eine Konfig, die da oben ist, spezifizieren, also welche Features möchte ich denn haben, zum Beispiel Route-Erkennung, sagen wir jetzt mal und dann kommt dieses Promo-Intecration-Tool und macht irgendwie eine Promo-Geschützte App daraus und danach kann ich so sofort in die offiziellen Stores hochladen. Und das ist jetzt so die Liste an Apps, das sind 31 International, die Promo und Shield verwenden. Jetzt die zwei, die ich jetzt gerade ausgeblendet habe, das sind eigentlich keine Banking-Apps, kommen auch aus dem Finance-Bereich, aber wir wollen jetzt erst mal nur auf die Banking-Apps konzentrieren. Und hier noch spezielle eigentlich auf die deutschen Banking-Apps und dann sieht man auch ganz deutlich, die haben in Deutschland eine wichtige Stellung. Also wenn man sich hier allein anschaut, Kommerzbank, DKB, VR-Banken, die Sparkhassen kommen direkt, es sind alles Banken, die sagen zumindest jedem was. Und da sieht man schon, die sind wichtig im deutschen Markt, im Markt der mobilen Banking-Apps. Wir schauen jetzt jetzt tatsächlich eine App an oder machen einem Beispiel an eine App, die vielleicht nicht jeder kennt und das ist Jomo. Warum ist eigentlich Jomo so besonders interessant? Also Jomo ist eigentlich erst mal ein App-Autentifizierungsverfahren, wie ich schon gesagt habe, ist eigentlich heutzutage nichts mehr Besonderes, das macht eigentlich jeder mittlerweile und das ist N26 nachempfunden. Also ich höre immer wieder das Gerücht, dass es intern sogar ein Number 27 hieß. Also das Vorbild ist Number 26. Aber das Interessante ist eigentlich, dass es die wahrscheinlich die neuste Version von Promo verwenden. Warum? Weil das eine sehr junge App ist und da gehe ich davon aus, das ist auch von Starfinance, um die Ecken irgendwie mit Sparkhassen was, dass die dann schon die neuste Version verwenden, wenn sie jetzt sagen, wir machen auch so einen App-Autentifizierungssystem. Gut, jetzt, wie funktioniert denn das jetzt intern, wenn es mal ein bisschen technischer wird? Also wenn dieses Integration-Tool von Promo kommt, dann übernimmt es die Main-Activity, also den Einsprungspunkt der App letztendlich und bindet dann eine native Bibliothek ein, die LibShield-Punkt so. Zusätzlich fügen die dann irgendwie noch Java-Klassen ein, die müssen ja irgendwie auch ihre eigene Library laden und irgendwie so ein bisschen Glucode und die sind unter anderem auch ausfoskiert, aber das spielt jetzt hier in dem Talk erst mal nicht so die Rolle. Das sind auch nur die in ihrer eigenen Klassen. Dann werden aber zusätzlich aus der App, aus der eigenen App jetzt zum Beispiel Promo, alle Strings und ein Teil von Konstanten herausgezogen und werden in diese LibShield-Punkt so reingemacht. Das gleiche gilt jetzt bei Promo im speziellen Fall auch für ein Klein-Zertifikat, dass eben die App braucht, um mit dem Backend zu sprechen und das macht eben jetzt nicht mehr Promo direkt, sondern darum kümmert sich die LibShield-Punkt so. Ja, die erste Idee, die man jetzt hat ist, ja, ja gut, wir wollen das jetzt irgendwie loswerden, dann modifizieren wir halt mal diese Library, diese Native Library. Dann hat sich das jetzt anschaut dann den Einspringspunkt von der, wenn man mal Eider aufmacht, wem das ein Begriff ist, das ein Control-Flow-Graph, also das ist nicht Windows abgestürzt oder sowas, das ist tatsächlich einfach totales Control-Flow-Flattening und ja, das will man sich eigentlich nicht anschauen. Also da gibt es schon auch Ansätze, um das zu sprechen, das ist mit dem LLVM-Office-Cater gemacht, wahrscheinlich weiß ich nicht, ob das diese Open-Source-Variante ist oder irgendwas selbst angepasst ist, kann ich nicht genau sagen, aber auf jeden Fall, das ist ökonomisch nicht machbar, sagen wir mal, ja, also wir wollen ja irgendwas einfaches, ja. Ja, gut, nächster Ansatz ist dann, ja, wenn wir schon die nicht modifizieren können, ja, dann entfernen wir die Bibliothek halt aus der App, ja. So, jetzt, so einfach ist dann auch wieder nicht, weil wir haben ja das Problem, die ganzen Strings und die Hand und das kleine Zertifikat, die sind ja auch alle in dieser, in dieser Lippschildpunkt so drinnen, deswegen müssen wir die irgendwie erst mal los werden. Ja, und fangen wir mal an mit den Strings, wie schaut es denn da eigentlich aus? Also jetzt ist da immer dargestellt, links ist Jomo und rechts ist Promo, die native Lipp von dem, die Lippschildpunkt so, und links ist immer vorher, bevor man irgendwie Promo verwendet hat und unten ist dann danach. Ja, es ist dann halt so, dass jetzt einfach ein String ausgegeben werden soll, wie Jomo, dann ersetzen die das mit einem Aufruf zu ihrer native Library und die hat dann irgendwie irgendwelche Mappings bei sich drinnen und gibt dann halt den Spring zurück. Genau. Also das ist eigentlich auch nicht schwer, sag ich jetzt mal. Also es ist logisch, was da gemacht, was macht man jetzt jetzt, um das zu umgehen? Ja, wir schauen halt mal, was ist der höchste Index in dem Ding und dann iterieren wir eben von Null bis End drüber und erstellen uns dann Mapping davon. Ja, dann können wir das ganze wieder rückgängig machen, was die gemacht haben. Ja, so weit so klar. Das war dann danach, hätte man sich die ganze Arbeit gar nicht machen brauchen, weil man kann da einfach drüber iterieren bis Null zurück kommt. Okay, Konstanten hat man im Prinzip ein ähnliches Problem. Ja, bei den Konstanten ist es eben so oben, hat man da eine Konstante, die war da vor minus 1 und dann, nachdem man Promo verwendet hat, steht da halt irgend Käse drinnen. Ja, das hat keinen Sinn mehr gemacht, was nicht funktional ist, nicht der Wert, den die Klasse eigentlich erwartet. Ja, und stattdessen wird ein statischer Konstruktor installiert in der Klasse, die dann dafür sorgt, dass über Reflection dieses Statisch-Finale fällt, dass man könnte, man mit Java Code gar nicht, also er wird es nicht mal kumpelieren, wenn man sowas hätte, aber über Reflection kann man solche Sachen machen. Also über Reflection wird das dann wieder richtig gesetzt, bevor das 1. Mal drauf zugegriffen und alle Klassen rein, die das eben aufrufen, dieses Push to Class und man ruft das selber auf und erstellt sich wieder ein Mapping. So, jetzt haben wir das weg. Jetzt kommt das kleinen Zertifikat. Jetzt wird es schon ein bisschen tricky, weil man kann jetzt nicht mehr genau so vorgehen wie gerade eben, weil das Problem ist ja, Jomo macht selber aus seinem Java Code irgendeinen Request. Danach geht das aber nicht an die Android Library oder an die Java Library in irgendeiner Form und dann geht es um die Promen rein und Promen verarbeitet in diesen Request in dieser Native Library und die fügen das Zertifikat hinzu und jetzt kann man ja nicht einfach irgendwas aufrufen, gib mir mal das kleinen Zertifikat, ja gut, könnte es sein, aber er ist da nicht so. Genau, was machen wir denn jetzt da? Dann ist die Idee, gut, dann schauen wir halt mal im Speicher, das muss ja irgendwo im Speicher liegen, das muss man doch irgendwie finden können. Wir haben halt eigentlich erwartet, das ist eine sehr interessante Datenstruktur. So, das sieht ein bisschen wirr aus, aber das ist eine Konfigurations-Datei. Aber da komme ich gleich noch drauf, aber da ist auch das, was wir wollen. Nämlich das Kleinzertifikat drinnen. Das ist Base64 inkudierter drinnen und ja, Kleinzertifikat, Kleinzertifikat key. Schön. Ja, jetzt können wir loslegen. Also, was machen wir, jetzt können wir unser eigenes Tool NoMob verwenden um diesen ganzen Prozess von Promen wieder rückgängig zu machen. Also, gerade ist es aus dem Play Store runter, dann haben wir diese Promen geschützte App. Im nächsten Schritt müssen wir irgendwie unseren Analyse injecten, der basiert bei uns irgendwie auf dem Free-Dar Gadget und der sorgt dann eben dafür, dass diese Mappings extrahiert werden. Dafür müssen wir das auf einem Gerät installieren und sobald die App gestartet wird putzeln da diese ganzen Mappings raus und die Konfigurations-Datei auch bzw. das Kleinzertifikat in dem Fall auch noch. Genau, und das füttern wir jetzt in unserem Tool eben und dann kommt die ungeschützte App raus. Also, dann hat man das los geworden. Ja. Der ganze Prozess, also vom Runterladen über das Installieren auf dem Gerät bis das Ausführen von NoMob dauert so fünf bis zehn Minuten. Das dauern kommt ein bisschen drauf an, wie groß die App ist. Wenn das irgendwie zehn Megabyte sind, dann dauert es nicht so lange. Und wenn das irgendwie so eine 100 MB App ist, dann dauert es entsprechend ein bisschen länger, weil wir da irgendwie Transformationen auf Basis von Desktop 2 machen müssen und dann dauert es halt ein bisschen. Aber trotzdem keine Zeit eigentlich, kommt ein Update raus, laden wir direkt runter und das war es. Jetzt schauen wir aber trotzdem nochmal auf diese Mappings, auf diese Konfigurations-Datei, die wir gerade eben hatten, weil das nämlich eigentlich bemerkungswert ist, weil ich habe jetzt schon die ganze Zeit gesagt, die haben Strings und Konstanten, die sind alle in dieser Lipshield-Punktsow drinnen. Aber das scheint ja dann gar nicht zu stimmen, weil wir haben ja dann die Konfigurations-Datei gesehen, warum sollte denn das dann drin sein? Da würde ich ja irgendwie schon ein Binär-Datei erwarten, dass das irgendwie alles schon in bestimmten Datenstrukturen drin ist. Also stellt sich raus, diese Lipshield-Punktsow wird schon bei Promo kompelliert und wird so an den Kunden ausgeliefert. Das heißt, bei dem Kunden wird da gar nichts kompelliert. Stattdessen, wenn man sich jetzt die Grafik rechts anschaut, ist als Kunde habe ich eben nur diese App und meine Konfigurations-Datei, dann gebe ich die diesem Promo- and Integration-Tool und die hat schon diese Lipshield-Punktsow drinnen, hat aber natürlich auch irgendwelche Analyse und Modifikationsmodule. Und die sind dann halt dafür verantwortlich, dass dann da unten diese Konfig verschlüsselt wird und die Mappings verschlüsselt werden, aber die liegen letztendlich in dieser App mit drinnen. Und werden dann halt einfach geladen und man verwendet die dann entsprechend. Und das macht ja jetzt eigentlich nochmal ein ganz anderes Angriffsszenario interessant. Wenn wir jetzt das links nochmal ein bisschen strukturierter anschauen, dann sind da ja irgendwie solche Sachen wie CheckDebugger, Exit und Debugger, Exit und Debugger URL. Okay, was heißt das? Soll ich überhaupt auch Debugger überprüfen? Was, wenn ich einen Debugger finde, soll ich dann die App crashen und wenn ich sie crash, soll er diese URL hier öffnen. Und das ist bei den anderen Sachen relativ analog, sag ich jetzt mal. Wie wär's denn, diese Konfigurationsdatei einfach nachdem sie entschlüsselt wurde bevor sie gepasst wird modifizieren und sagen einfach hey, wir schreiben da überall Null rein. Zu dem Zeitpunkt haben wir uns schon ein bisschen geärgert, weil das andere war echt viel Arbeit. Genau, also das hat sich jetzt bisher alles war sehr iOS, Android spezifisch, jetzt machen wir mal ganz kurz auch zur iOS. Bei iOS ist es letztendlich recht ähnlich. Da gibt es auch eine Konfigurationsdatei, die ist aber wesentlich weniger umfangreich und insgesamt habe ich auch das Gefühl, da wird weniger gemacht. Das ist halt auch Binaire-Coding, kann man nicht so schön transformieren wie irgendwie Java-Bitecode. Letztendlich sind da aber ähnliche Checks halt analog zur Android-Welt drin und man könnte wieder sagen, ja, wir schreiben das halt um. Ja, jetzt fassen wir nochmal die Angriffe zusammen. Also wir haben zwei verschiedene Angriffe gerade gesehen, der eigentlich relativ komplex war, weil man da relativ transformieren muss, der darauf abzielt, dass man das Promo-Schild entfernt und dann eben gerade eben, was ich vorgestellt habe, man schreibt einfach die Konfigurationsdatei um und da hat man irgendwie auch kein Problem mit irgendwelchen Kompatibilitäten, bleibt ja alles kompatibel. Man sagt im Prinzip nur die Fakto, mach einfach nichts. Danach ist die App jetzt ja komplett ungeschützt, im Prinzip. Man kann damit die ganze Hersteller implementieren in großem Stil und auch kein Repackaging-Schutz und dergleichen mehr. Ja, jetzt können wir doch eigentlich weiter automatisieren. Also jetzt mal als Beispiel-Angriff Transaktionsmanipulation. Dann haben wir gesagt, ja gut, dann erweitern wir doch nochmal mal so, dass wir das fast vollständig automatisch machen können. Und dann hier jetzt mal als Beispiel, das ist die VR Banking App, weil eigentlich, was man immer nur machen will bei einer Transaktionsmanipulation ist, man will ja bestimmte Fuse, Textfuse oder sowas manipulieren. Und das sind halt in dem Fall die Interessanten und das sind, der, okay, der Name des Empfängers ist jetzt hier falsch, das muss natürlich eigentlich was anderes sein, müsste die Ibern sein. Entschuldigung, ist ein Fehler. Aber unten drunter Textbetrag, das ist richtig. Und deshalb, die haben natürlich eine ID irgendwo. Und die muss man quasi manuell ermitteln und alles andere kann man dann vollständig automatisch machen. Also man kann alles injecten. Man muss ja nur wissen, was man danach austauschen muss beziehungsweise auslesen muss. Jetzt machen wir mal eine kleine Demo. Jetzt kann sich aber mal wieder Jomo zurücklegen. Also wir brauchen jetzt keine Angst haben, geht nicht mit Ihnen weiter. Sondern wir schauen jetzt mal das anhand der VR Banken an. So. Und jetzt mal, das Video haben wir heute Nachmittag gemacht. Deswegen ist es noch etwas, ja, ist etwas zügig entstanden. Deswegen sage ich jetzt mal noch mal vor, was man jetzt gleich alle sehen wird. Also das Szenario ist das folgende. Wir haben ein Nexus 5X mit Android 7 und es hat ein Security Patch Level vom letzten Jahr. Also vor ungefähr einem Jahr. Warum ist das so? Weil da ist, wir wollten irgendwas, wo man da Teilen schreiben darf, die man eigentlich schreiben darf. Also Dirty Cow ist ein klassisch gutes Beispiel. Und warum ist es auch so ein gutes Beispiel? Damit ist es gar nicht so einfach, Root im Sinne von Super Zoo zu bekommen. Ich glaube, das ist erst vor kurzem gelungen. Aber man kann halt Dateien schreiben, die man eigentlich schreiben dürfte. Ja, und dann in dem letztlich eben der Nutzer eine scheinbar gutartige App aus dem offiziellen Play Store runter. Das soll ja schon vorgekommen sein, dass da Leute das geschafft haben, so was zu plastieren. Und die App ersetzt dann eben die Fire Banking und die VR Security Go App mit einer Nom-Op-Version. Das wird man dann gleich auch sehr schön sehen. Und danach führt der Nutzer eben eine Transaktion über 15 Euro durch und die wird durch 1,23 Euro. Das ist nicht so logisch, wenn man jetzt mal kriminell denkt, aber ja, ersetzt. Und ja, das ist eben eine Transaktionsmanipulation. Und bis auf das bestimmte ID, die man gerade gesagt hat, ist das komplett vollautomatisch. Also, das musste man nicht weiter antasten mit manuellen Aufwand, sondern Nut die IDs bestimmen. Jetzt machen wir kurz noch auf, damit man kurz die Version sieht. Das war das, was ich gerade gesagt hatte. Und als nächstes machen wir jetzt erstmal die VR Banking App auf und die wird schwarz, weil die hat halt dieses Flex Secure gesetzt, damit man keine Aufnahmen machen kann. Also, da sieht man jetzt irgendwie nichts. Okay, die funktioniert anscheinend. So, und jetzt geht es weiter. Jetzt lädt man sich aus dem Play Store runter und ja, das ist echt. So, und das sieht man hier oben diese Leiste und jetzt, das ist quasi eine scheinbar gute App. Und jetzt wurde mein Hintergrund explodiert. Ja, und jetzt machen wir die VR Banking App nochmal auf. So, genau. Jetzt muss man sich da eben einloggen. Jetzt machen wir die Transaktion. Und ihr geht diesmal an mich. Noch kurz die I-Bahn eingeben. Ich habe eben die 15 Euro, die ich gerade eben gesagt habe, mit Verwendungswerk 34 C3. Ist aber nicht so wichtig jetzt in dem Fall. So, genau. Und jetzt ist die Überweisung versendet worden. Das bedeutet jetzt, im nächsten Schritt muss man die Transaktion in der TAN App, in der Secure Go App freigeben und gleiches Spiel wurde auch wieder irgendwas gemacht. Ich muss auch wieder das Passwort eingeben und dann im nächsten Schritt. Also wichtig ist jetzt natürlich hier, dass die I-Bahn stimmt. Es geht aber so schnell, da versichere ich euch, dass es stimmt. Es stehen noch 15 Euro immer noch. Genau, also stimmt ja alles. Also geben wir die Transaktion frei. So, genau, da unten steht auch irgendwie 15 Euro. Passt ja alles. Und ja, wenn man jetzt hier reinschaut, dann waren es aber wirklich 1,23 Euro. Was hier wichtig ist, also das war wirklich, dass das voll automatisch war. Also das war nicht, dass jeder jetzt irgendwie nochmal eine App reversed hat und die IDs bestimmen, nachdem Promon draußen war und dann geht das. Gut, dann komme ich mal zum Schluss, mal die Reaktionen der beteiligten Parteien anschauen und mal einen Fazit schließen dazu. Also mit Promon stehen wir seit Ende November, also gut einem Monat im Kontakt. Die waren da sehr nett und professionell und sie haben mittlerweile auch eine neue Version des Promon Shields entwickelt. Das liegt mir in der Beispiel-App auch vor, aber ich hatte jetzt noch nicht die Zeit, um da genauer reinzuschauen. Ich kann aber sagen, jetzt unseren Nomop-Toolchain funktioniert auf die Art und Weise nicht mehr. Also funktioniert nicht wieder vor. Ich kann nämlich genau sagen, was wurde da jetzt genau gemacht und welche großen Anpassungen sind dazu machen. Kann sein, dass es unglaublich viel Arbeit ist, kann aber auch sein, dass es nicht viel Arbeit ist. Aber ich kann es einfach nicht sagen. Der Punkt ist aber eigentlich, um die Angriffe wirklich komplexer zu machen, um die Angriffe von den Apps. Man kann ja alle Apps gleichartig angreifen. Man kann das Promon Shield auf die gleiche Art und Weise aus all diesen 31 Apps oder kann es da deaktivieren, indem man diese Config rewrites, weil das überall gleich ist, weil das so ein universaler Ansatz ist. Ja, und bei den Banken, die Reaktion, die ich seit Jahren höre, bis heute keine Schadensfälle bekannt. Das ist natürlich ein merkwürdiges Verständnis von IT-Sicherheit, aber gut. Wenn man mal anschaut, wie eigentlich überhaupt die Verteilungen von Mobile Banking ist oder von appbasierten Tantverfahren, dann sind die einfach nicht relevant aktuell im Markt. Also 5-8% hat letztes Jahr eine Studie ergeben, sind diese appbasierten Tantverfahren verbreitet und es soll sich dieses Jahr nicht groß geändert haben. Also natürlich aktuell lohnt sich das noch nicht, aber das kann sich für die Zukunft ändern. Ja, und das finde ich ein sehr schönes Zitat von Jens Bender und Dennis Kügler vom BSI. Im Bereich des Zahlungswesens hat sich eine besondere Kreativität in der Auslegung der Eigenschaften einer zwei Faktor- Authentisierung entwickelt. Ja, kann ich nur zustimmen und jetzt, wenn man jetzt irgendwie denkt, der ist so nach Mobile Banking, also nach zwei Apps auf einem Smartphone, wird es nicht mehr schlimmer. Es gibt es jetzt mittlerweile auch auf einem Windows und auf einem Mac-PC. Ja, okay, kann man machen. Gut, jetzt um mal zwei Fragen. Ganz zum Schluss. Ist App-Herrtung überhaupt sinnvoll? Also sind diese ganzen Produkte, die da angeboten werden im ganzen Markt, haben die überhaupt einen Daseinsberechtigung? Ja, natürlich haben die eine Daseinsberechtigung. Die haben schon einen sinnvollen Schutz, die die da einbetten, aber das muss ein zusätzlicher Schutz sein. Und die andere Frage ist, ist App-Herrtung ein Ersatz für unabhängige zwei Faktor- Authentisierung? Natürlich nicht, das habe ich hier gerade eben gesagt und eben, weil eben das sind Software-Maßnahmen und die können, wie wir in dem Beispiel jetzt gezeigt haben, einfach nicht verhindern, dass jemand das ausnutzt. Danke. Vielen Dank, Vincent, für deinen Talk und einen weiteren Ausflug in die Welt des Mobile Bankings. Wir haben Zeit für einige Fragen. Also wenn ihr Fragen habt, reit euch an den Mikrofonen auf. Hier gibt es eins, also das drei, da vorne ist zwei und so weiter, die haben Nummern dran und dann können wir noch ein paar Fragen oder Vincent kann ein paar Fragen für euch beantworten. Ihr könnt euch winken, wenn ihr an einem steht. Okay, an Mikrofon 3 haben wir eine Frage. Ja genau, vielen Dank für den Talk. Ganz toll. Jetzt gibt es ja für DRM-Systeme schon Dinge wie Widevine die Trust Zone im Chip direkt verwenden. Hast du bei einer Forschung da irgendwas von gesehen? Also das ist ein wichtiger Punkt und ich glaube eigentlich auch das Trust Zone oder allgemein irgendwie Trusted Execution Environments in der Art und Weise wäre, in der man so was zufriedenstellen sicher auf einem Gerät machen könnte. Also gerade eben läuft der Bootstomp Vortrag von den Jungs von der UCSB, die würden mir da jetzt vielleicht widersprechen, aber ich sage insgesamt das ist ein Ansatz auf den, dass ich da was genau gesehen habe, kann ich jetzt nicht behaupten. Also jetzt gerade auch die alle setzen das nicht ein. Ist natürlich auch das Problem, dass es da keine einheitliche Lösung bisher gibt. Also gibt es irgendwie ein paar proprietäre Lösungen und jeder will sich da irgendwie durchsetzen, aber so ein einheitlichen Standard gibt es nicht, von daher ist das schwierig. Mikrofon 1 bitte. Waren die Untersuchten ab, alle schon nach der PSD2 Richtlinie sozusagen zugelassen. Die schreibt das ja explizit vor zwei Fakultatisierung. Ja, also genau, die PSD2 schreibt vor, starke Kundenautonfizierung müsste man jetzt ein bisschen weiter ausholen. Da wurden jetzt gerade eben aber die genauen technischen Standards dafür erst verabschiedet. Es gibt noch eine 18-monatige Übergangsfrist, wo die Bankenzeit haben, das sich da anzupassen. Aber halt in den ganzen Berbel-Videos wird ganz oft auch davon gesprochen, jetzt gerade von diesen Drittanbietern auch, dass die PSD2 kompatibel sind. Ich muss sagen, was die PSD2 jetzt genau vorschreibt, ich glaube die letzte Entscheidung, die dazu getroffen wurde, ist eher Richtung akzeptierenden Status quo. Man kann das aber meiner Meinung auch immer noch so lesen, dass man eigentlich eine sichere Anzeige und eine Nicht-Kopierbarkeit für den Besitzelement hat. Also von daher, das ist nicht ganz klar. Wenn Sie jetzt die Banken fragen, dann sagen die RTÜS in die PSD2-Konform. Eine Frage, oder fragen wir den Signal Angel, die Frage aus dem Internet, das scheint nicht der Fall zu sein. Ich habe noch eine Frage bei Mikrofon 2. Hast du dir außer Promon noch andere Bibliotheken angesehen? Nein, hab ich nicht. Das liegt aber einfach auch daran. Es gibt ein paar andere, die im deutschen Markt auch nur verbreitet sind. Es gibt Einzelne, die das einsetzen, die Deutsche Bank setzt mittlerweile Erxern ein. Dann gibt es irgendwie noch die ING-Dieber, die Kobiel verwendet und so was. Da kann ich jetzt nichts genaueres dazu sagen. Ich habe noch nichts per se gegen Promon. Also kein Problem mit denen. Aber das Problem ist halt eigentlich eher, dass sie so relevant im deutschen Markt sind und ich mich festgestellt habe, dass das so gut wie jeder verwendet. Deswegen hat sich es halt gelohnt, das sich genauer anzuschauen. Wenn jetzt jeder eine andere App-Herzungslösung verwenden würde, dann hätte man ja auch wieder einen viel größeren Aufwand. Also müsste man die sicher alle anschauen. Man kann irgendwie einmal Promon deaktivieren und das geht für alle. Das ist das letzte Frage. Vielen Dank für den Vortrag. Eine Frage zu dem Angriffsvektor. In diesem Fall wurde ja einfach die App ausgetauscht und dann, sagen wir mal, leicht angreifbar gemacht. Wäre es denkbar, vielleicht auch beim gerouteten Phone, dass man einfach neben dran eine Application hat, die das dann einfach on-the-fly austauscht und so Applikation angreift? Wurde das untersucht? Also ich meine, das machen wir im Endeffekt. Wir binden ja eine Komponente in diese App ein, die das macht. Also ich meine, in dem Fall wurde es jetzt ersetzt, aber das ging ja natürlich auch. Also ich glaube nur, dass das Ersetzen von der App ist ja quasi so mitunter das Einfachste, was man machen kann. Also ich meine, wenn es nicht geroutet wäre, dann wäre es ja wahrscheinlich nicht möglich von einer App auf die andere nachher zuzugreifen und das auszutauschen. Aber das müsste natürlich geroutet werden oder gibt es anderen Sätzen dort? Also ich meine, es gibt zumindest nur eine Unschärfe zwischen, was ist ein Root Exploit, also Privilege Escalation und was ist geroutetes Gerät. Also geroutetes Gerät ist bei mir eine bewusste Entscheidung. Ich installiere jetzt bei mir Super-Zoo oder Magisk oder weiß es auch immer was. Also das ist bei mir eine bewusste Entscheidung. Dafür verwende ich unter Umständen Privilege Escalation, um das zu platzieren. Aber der einen Privilege Escalation an sich, zum Beispiel Dirty Cow ausnutzen, das ist ja nicht persistent. Also das wird irgendwie einmal ausgenutzt und die Referenziker fragen. Aber ich glaube, das ist schwierig. Und das ist ja, glaube ich, auch der große Unterschied. Privilege Escalation mache ich einmal, um meine Angriffswekte zu platzieren und danach helfen die ganzen Root Detections von den Lösungen sowieso gar nichts mehr. Ich habe keine Super-Zoo installiert. Okay, nochmal herzlichen Dank, Vincent Haubert, einen großen Applaus.