34c3 intro Herald: Der kommende Vortag ist von einem alten Bekannten, der schon zum 32C3 und zum 33C3 uns in eine wundersame Welt entführt hat voller mobiler Endgeräte und unsicherer Verbidungen und dem Vertrauen was wir daran stecken. Er ist Doktorrand an der Uni Erlangen-Nürnberg – die hat auch einen langen Namen, den ich nicht aufgeschrieben habe. Er ist Doktorrand der Informatik und interessiert sich besonders für die Sicherheit von Mobilgeräten und wird uns heute die fabelhafte Welt des Mobilbankings näher bringen. Begrüßt mit mir Vincent Haupert. Applaus Vincent: Herzlichen Dank für die Einführung. Fabelhaft ist ein sehr vielschichtiges Wort. An dieser Stelle möchte ich zuerst einmal die fabelhafte Zusammenarbeit mit meinem Kollegen Nicolas Schneider hervorheben ohne den diese Arbeit hier in der Form nicht möglich gewesen wäre. Herzlichen Dank an ihn. Applaus Onlinebanking – ich denke mal so gut wie jeder hier dürfte es machen – ist hinlänglich bekannt. Ist seit jeher im PIN/TAN Verfahren seitdem es von vor 30 Jahren. Ihr erster Faktor ist wie immer man loggt sich auch Onlinebanking Portal ein mit seinem Benutzername und Passwort. Danach muss man eine Transaktion aufgeben mit einer IBAN und mit einem Betrag. Im zweiten Schritt hat man dann irgendein TAN Verfahren mit dem man die Transaktion bestätigen muss. Das ist ganz klares Sicherheitselement das es seit Anfang des Onlinebanking gibt. Und die Art und Weise wie man eben die TAN generiert, empfängt, abliest ist recht unterschiedlich. Die ersten drei Verfahren die man jetzt hier auf dieser Liste sieht das iTAN Verfahren, smsTAN Verfahren und chipTAN Verfahren sind hauptsächlich aus der Motivation entstanden, dass es relativ viele Schadensfälle in dem Bereich gab, also Phishing vor allem, und mit chipTAN ist man quasi an den Zenit an gereicht / erlangt. Technisch kann man das eigentlich kaum noch besser machen. Gibt es natürlich auch noch andere Aspekte wie Benutzerfreundlichkeit die da wichtig sind. Deswegen gingen die Verfahren wie photoTAN oder auch appTAN gehen dann eigentlich mehr in die Richtung dass sie die Benutzerfreundlichkeit adressieren wollen – was auch durchaus legitim ist. Per se habe ich eigentlich gar nichts gegen App basierte TAN Verfahren. Solange man zwei Geräte verwendet. Also wenn man zwei Geräte Authentifizierung macht hat man ja immer noch den Schutz, dass, wenn ein Gerät kompromittiert ist, das andere zumindest nicht automatisch mit in Mitleidenschaft gezogen wird. Von daher ist es durchaus legitim. Ich kann mich erinnern vor zwei Jahren als ich hier den Talk gehalten habe, wurde ich nach photoTAN gefragt und hab noch gesagt das ist ein relativ solides Verfahren, weil es ja implizit eigentlich forciert, dass man zwei Geräte verwendet. Dann muss man ja von einem anderen Gerät abscannen und das generiert dann die TAN. Dann gibts halt die Verfahren die pushTAN Verfahren bzw. die, die über zwei Apps realisiert sind: also eine Banking App die andere die TAN App. Das gibt es jetzt mittlerweile seit Jahren. Und das Paradoxe ist, dass man mittlerweile auch photoTAN auf einem Gerät machen kann. Da kann man zwar nichts mehr abscannen erkennen, sondern kommunizieren einfach untereinander, aber das zeigt eigentlich erst mal wie abstrus es wird. 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-Faktor- Authentifizierung mehr gibt. Und eigentlich will heute jeder ein Ein-App- Verfahren implementieren. Das ist insofern eigentlich bemerkenswert, weil das SMS TAN Verfahren, wenn man sich das mal anschaut, hat eine Geräte-Entwicklung durchgemacht von einem Spezialgerät hin zu einem Mehrzweckgerät. Also heute empfängt jeder seine SMS auf einem Smartphone. Und das 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 mobileTAN Verfahrens zum Beispiel nur ein mobiles Smartphone für beide Kommunikation Strecken nicht zulässig ist und daher den Kundenbedingungen für das Online-Banking explizit ausgeschlossen wird." "Dies impliziert bereits" so ist ja eh klar. Jetzt frage ich mich natürlich: Wo ist denn da jetzt der Unterschied? Also hier wird auch alles auf einem Gerät gemacht und das habe ich vor zwei Jahren dann auch gezeigt: habe einen Angriff auf das pushTAN Verfahren gezeigt mit einer Transaktionsmanipulation. Das hat hingegen die Sparkasse nicht so richtig beeindruckt. Die haben gesagt: "Ja das waren eigentlich alles nur Laborbedingungen – das geht in Wirklichkeit gar nicht. Und das funktioniert nur bei genau einem Gerät, genau einer App und bei genau einer Version" und "jedes Mal wenn wir eine neue Version herausbringen ist das ein hoher individueller und manuelle Aufwand." Und genau dies werden wir heute adressieren. Glächter und Applaus Jetzt habe ich ja vorhin gesagt so bei smsTAN hat man gesagt "ja das machen wir nicht, das ist nicht sicher." Und jetzt muss man sich fragen was ist denn dann eigentlich anders bei diesen Apps? Da gibt es eine ganze Reihe von Eigenschaft, aber ich denke wichtig ist diese Absicherung durch Dritte. Und zwar gibt es mittlerweile einen recht großen Markt an Drittanbietern die App-Härtung und App- Sicherheit verkaufen. Also Drittanbieter Produkte und das hier ist nur eine kleine Auswahl. Und denjenigen die wir uns heute etwas genauer anschauen werden ist Promon. Promon hat das Produkt Promon SHIELD. Die Information die hier stehen sind allesamt von der Website. Der Zweck von Promon SHIELD ist Schutz von Apps in nicht vertrauenswürdigen Umgebungen. Das Ganze ist universal, d.h. es ist egal was für eine App es ist, und es ist plattformunabhängig. Also es geht unter Android und iOS und die haben auch Lösungen für Windows. Es ist anwendbar innerhalb von wenigen Minuten. Das Zitat is aus dem Video: "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äten." Gelächter und Applaus Schauen wir uns das mal genauer an... Was gibt es denn eigentlich Eigenschaften die diese ganzen App-Härtungs-Geschichten implementieren? Also das sind nur zwei Sparten. Da gibt es in klassischen App-Härtungsbereich, der will statische und dynamische Analyse hauptsächlich verhindern. Und dann gibt es den eher neueren Bereich, da geht es dann eher um zu Security Best Practices. Also solche Sachen wie Certificate-Pinning und dass man die Anwendungs 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 gerade im Bereich des Mobilebanking sind die Inhalte eine wichtige Nummer. Wie verwendet man denn jetzt eigentlich das Promo SHIELD? 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 Config die da oben ist spezifizieren. Also welche Features möchte ich denn haben z.B. Root-Erkennung sagen wir mal. Und dann kommt diese Promo und Integration Tool und macht irgendwie eine Promon geschützte App daraus. Danach kann ich sie sofort in die offiziellen Stores hochladen. Dies ist die Liste an Apps – das sind 31 international – die Promon SHIELD verwenden. Die zwei die ich jetzt gerade ausgeblendet habe sind keine Banking Apps. Sie kommen auch aus dem Finanzbereich aber wir wollen uns dieses Mal nur auf die Banking Apps konzentrieren und hier noch spezieller eigentlich auf die deutschen Banking Apps. Und dann sieht man auch ganz deutlich die haben in Deutschland eine wichtige Stellung. Also wenn man sich allein anschaut: Commerzbank, DKB, VR-Banken, die Sparkassen, Comdirect. Das sind alles Banken die sagen zumindest jedem etwas. Und da sieht man schon die sind wichtig im deutschen Markt der mobilen Banking Apps. Wir schauen uns tatsächlich eine App an oder machen ein Beispiel an einer App die vielleicht nicht jeder kennt und das ist: Yomo. Warum ist eigentlich Yomo so besonders interessant? Yomo ist eigentlich erst einmal Ein-App- Authentifizierungsverfahren. Wie ich schon gesagt habe, das ist heutzutage nicht mehr Besonderes – das macht eigentlich jeder mittlerweile und das ist N26 nachempfunden. Ich höre immer wieder das Gerücht, dass das intern sogar Number 27 hieß. Also das Vorbild ist Number 26. Aber das Interessante ist eigentlich, dass es wahrscheinlich die neueste Version von Promon verwendet. Warum? Weil das eine sehr junge App ist. Daher gehe ich davon aus, da es auch von Starfinanz ist – das ist um die Ecken irgendwie mit Sparkasse was, dass die da schon die neueste Version verwenden. Wenn sie jetzt sagen Wir machen auch so ein Ein-App-Authentifizierungs-System. Wie funktioniert das denn intern, wenn man ein bisschen technischer wird? Wenn dieses Integration-Tool von Promon kommt, dann übernimmt es die MainActivity, also den Einsprungspunkt der App letztendlich und bindet dann eine native Bibliothek ein: die libshield.so. Zusätzlich fügt Promon noch Java Klassen ein, die müssen irgendwie auch ihre eigene Library laden und irgendwann ein bisschen glue code. Und die sind unter anderem auch obfuskiert aber das spielt hier in diesem Talk erstmal nicht so die Rolle. Das ist es denn auch nur denen ihre eigenen Klassen. Dann werden aber zusätzlich aus der App, jetzt also zum Beispiel Yomo, alle Strings und ein Teil von Konstanten herausgezogen und werden in diese libshield.so reingemacht. Das Gleiche gilt es bei Yomo im speziellen Fall auch für ein Client-Zertifikat, das die App braucht um mit dem Backend zu sprechen. Und das macht eben jetzt nicht mehr Yomo direkt, sondern darum kümmert sich die libshield.so. Die erste Idee, die man jetzt hat, ist wir wollen das jetzt irgendwie loswerden. Dann modifizieren wir halt mal diese Library – diese native library. Wenn man sich jetzt anschaut, den Einstiegspunkt von dem, wenn man mal IDA aufmacht. Das ein Controllflow-Graph, also nicht das Windows abgestürzt oder sowas. Das ist tatsächlich einfach totales Controlflow-Flattening und das will man sich eigentlich nicht anschauen. Also da gibts schon auch Ansätze um das zu unpacken. Das ist mit dem LLVM obfuscator gemacht. Wahrscheinlich. Ich weis nicht ob das diese Open-Source Variante ist oder irgendwas selbst angepasst ist. Das kann ich nicht genau sagen. Aber auf jeden Fall das ist ökonomisch nicht machbar. Sagen wir jetzt mal. Also wir wollen ja irgendwas einfaches. Nächster Ansatz ist dann wenn wir schon die nicht modifizieren können, dann entfernen wir die Bibliothek halt aus der App. So einfach ist das dann auch wieder nicht. Weil wir haben ja das Problem, die ganzen Strings, die Konstanten und Client-Zertifikate sind auch alle in dieser libshield.so drin. Deswegen müssen wir diese irgendwie erstmal loswerden. Und fangen wir mal an mit den Strings wie schaut es da eigentlich aus? Also es ist da immer dargestellt links ist Yomo und rechts ist Promon, die native Lib von dem die libshield.so. Links oben ist immer bevor man in die Promon verwendt hat und links unten ist danach. Es ist dann halt so, dass wenn da jetzt einfach ein String ausgegeben werden soll wie Yomo, dann ersetzen sie das mit einem Aufruf zu ihrer native Library und die hat dann irgendwie irgendwelche Mappings bei sich drinnen und gibt dann halt den String zurück. Eigentlich auch nicht schwer, weil das ist logisch was man da gemacht hat. Und was macht man jetzt um das zu umgehen? Wir schauen halt mal was der höchste Index in dem Ding. Und dann iterieren wir eben von null bis n drüber und erstellen uns dann ein Mapping davon. Und dann können wir das Ganze wieder rückgängig machen was sie gemacht haben. Soweit so klar. Man hätte sich die ganze Arbeit gar nicht machen brauchen, weil man kann ja einfach drüber iterieren bis NULL zurückkommt. Mit Konstanten hat man im Prinzip ein ähnliches Problem. Bei den Konstanten ist es eben so: oben hat man da eine Konstante die war -1. Und nachdem man Promon verwendet hat, steht da halt irgendein Käse drin. Also irgendwas was keinen Sinn mehr macht, etwas das nicht funktional ist, also nicht der Wert den die Klasse eigentlich erwartet. Stattdessen wird ein statischer Konstruktor in der Klasse installiert, die dann dafür sorgt dass über Reflection dieses statisch finale Feld, das könnte man mit Java Code gar nicht - also nicht mal kompilieren, wenn man so etwas hätte. Aber über Reflection kann man kann man solche Sachen machen. Über Reflection wird es dann wieder richtig gesetzt bevor das erste Mal darauf zugegriffen wird. Die Lösung ist relativ ähnlich: Man geht einfach in alle Klassen rein, die dieses pushToClass aufrufen, und man ruft dasselbe auf und erstellt sich wieder ein Mapping. So haben wir das weg. Jetzt kommt das Client-Zertifikat. Jetzt wird es schon ein bisschen tricky, weil man kann jetzt nicht mehr genau so vorgehen wie gerade eben. Das Problem ist: Yomo macht selber aus Java Code irgendnen Request. Danach geht das aber nicht an die Android Library oder die Java Library in irgendeiner Art und Weise. Sondern es geht in Promon rein und Promon verarbeitet dann 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 Client Zertifikat" – ja gut das könnte sein aber ist nicht so. Was machen wir denn jetzt da? Dann ist die Idee: Dann schauen wir halt mal im Speicher. Das muss ja irgendwo im Speicher liegen und das muss man doch irgendwie finden können. Ja wir haben eigentlich erwartet, dass wir nur das Zertifikat, aber was wir gefunden haben war eine noch viel interessantere Datenstruktur. Das sieht ein bisschen wirr aus, aber das ist eine Konfigurationsdatei. Da komme ich gleich noch drauf, aber da ist auch das was wir wollen, nämlich das Client-Zertifikat. Das ist base64 enkodiert da drin: clientCertificate und clientCertificateKey. Schön. Jetzt können wir loslegen. Was machen wir jetzt? Wir können jetzt unser eigenes Tool Nomorp verwenden, um diesen ganzen Prozess von Promon wieder rückgängig zu machen. Also wir laden es aus dem Playstore herunter dann haben wir eine geschützte App. Im nächsten Schritt müssen wir unseren Analyzer injecten, der basiert auf dem Frida Gadget. Und der sorgt dann dafür, dass diese Mappings extrahiert werden. Dafür müssen wir das auf einem Gerät installieren und sobald die App gestartet wird, purzeln da diese ganzen Mappings raus und die Konfigurationsdatei auch bzw. halt das Client-Zertifikat in dem Fall auch noch. Und das füttern wir jetzt unser Tool und dann kommt die ungeschützte App raus. Also dann ist man das losgeworden. Applaus Der ganze Prozess vom Herunterladen, über das Installieren auf dem Gerät, bis dem Ausführen von Nomorp dauert fünf bis zehn Minuten. Die Dauer kommt ein bisschen darauf an wie groß die App ist. Wenn das 10 MB sind dann dauert es nicht so lange. Und wenn es halt eine 100 MB App ist, dann dauert es halt entsprechend bisschen länger weil wir da irgendwie Transformation auf Basis von textlib2 machen müssen und dann dauert es halt ein bisschen – aber trotzdem keine Zeit eigentlich. Kommt ein Update raus, laden wir das direkt runter und das wars. Jetzt schauen wir aber trotzdem nochmal auf diese auf die Mappings, auf diese Konfigurationsdatei die wir gerade eben hatten, weil das nämlich eigentlich bemerkenswert ist. Ich habe jetzt schon die ganze Zeit gesagt: Diese ganzen Strings und Konstanten sind alle in dieser libshield.so drin. Aber das scheint gar nicht zu stimmen. Wir haben ja eine Konfigurationsdatei gesehen. Warum sollte denn das dann drin sein? Da würde ich schon eine binär Datei erwarten, dass das irgendwie alles schon in bestimmten Datenstrukturen drin ist. Es stellt sich heraus, dass diese libshield.so schon bei Promon kompiliert wurde und wird so an den Kunden ausgeliefert. Das heißt bei den Kunden wird gar nichts kompiliert. Stattdessen, wenn man sich jetzt die Grafik rechts anschaut: Als Kunde habe ich eben nur diese App und meine Konfigurationsdatei. Dann gebe ich diese dem Promon Integration Tool und dies hat schon diese libshield.so drin, hat aber natürlich auch irgendwelche Analyse- und Modifikations-Module. Die sind dann dafür verantwortlich das da unten diese Config verschlüsselt wird und die Mappings verschlüsselt werden. Aber die liegen letztendlich in dieser App mit drin, werden dann einfach geladen und man verwendet die dann entsprechend. Und das macht letztendlich nochmal ein ganz anderes Angriffszenario interessant. Wenn wir das links nochmal ein bisschen strukturierter anschauen,dann sind dort solche Sachen wie checkDebugger, exitOnDebugger und exitOnDebuggerUrl. Was heisst das? Heisst das soll ich überhaupt noch Debugger überprüfen? Was wenn ich einen Debugger finde, soll ich dann die App crashen? Und wenn ich sie crashe, sollte diese URL hier öffnen. Das ist bei den anderen Sachen relativ analog. Wie wärs denn wenn wir diese Konfigurationsdatei einfach nachdem sie entschlüsselt wurde, bevor sie geparsed wird modifizieren? Wir sagen einfach "Hey wir schreiben da überall null rein". Also zu dem Zeitpunkt haben uns schon ein bisschen geärgert, weil das andere war echt viel Arbeit. Gelächter und Applaus Das war bisher alles sehr Android spezifisch. Also ganz kurz zu 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 binär Coding kann man nicht so schön transformieren wie irgendwie bei Java Bytecode. Letztendlich sind aber ähnliche Checks halt analog zur zu Android Welt drin und man könnte wieder sagen "wir schreiben das halt um". Fassen wir nochmal die Angriffe zusammen: Wir haben zwei verschiedene Angriffe gesehen. Dein Einen, wo ich gerade schon gesagt habe der eigentlich relativ komplex war, weil man da relativ viel transformieren muss, der darauf abzielt dass man Promon SHIELD entfernt. Und dann was ich gerade vorgestellt habe. Man schreibt einfach die Konfigurationsdatei um. Da hat man auch kein Problem mit Inkompatibilitäten, bleibt ja alles kompatibel. Man sagt im Prinzip nur de facto mach einfach nichts. Danach ist die App im Prinzip komplett ungeschützt. Die Hersteller implementieren in großem Stil auch keinen Repackaging- Schutz und dergleichen mehr. Jetzt können wir doch eigentlich weiter automatisieren. Jetzt mal als Beispiel-Angriff: Transaktionsmanipulation. Wir haben dann gesagt, gut dann erweitern wir doch Nomorp mal so, dass wir das fast vollständig automatisch machen können. Hier mal als Beispiel das VR Banking App. Eigentlich was man immer nur machen will bei einer Transaktionsmanipulation ist: Man will hier bestimmte Views, Text Views oder sowas, manipulieren. Das sind halt in dem Fall die interessanten. Der 'Name des Empfängers' ist im Beispiel falsch. Das muss natürlich was anders sein, das müsste die IBAN sein. Entschuldigung. Das ist ein Fehler. Aber der txt_betrag ist richtig und 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 dies alles injecten. Man muss ja nur wissen was man danach austauschen muss bzw. auslesen muss. Jetzt machen wir mal eine kleine Demo. Jetzt kann sich aber mal wieder Yomo zurücklehnen und brauchen jetzt keine Angst haben geht nicht mit ihnen weiter. Wir schauen uns das jetzt mal anhand der VR Banken an. Das Video haben wir heute Nachmittag gemacht. Es ist etwas zügig entstanden. Deswegen sage ich jetzt mal nochmal zuvor, was man gleich sehen wird. Dieses Szenario ist das folgende: Wir haben ein Nexus 5X mit Android 7.0 und es hat einen Security Patch Level von vor ungefähr einem Jahr. Und warum ist das so? Wir wollten irgendwas wo man Dateien schreiben darf, die man eigentlich schreiben darf. Also DirtyCOW ist ein klassisch gutes Beispiel. Und warum es es auch so ein gutes Beispiel? Damit ist es gar nicht so einfach root im Sinne von SuperSU zu bekommen. Ich glaube dass es erst vor kurzem gelungen. Aber man kann Dateien schreiben die man eigentlich schreiben dürfte. Dann lädt sich der Nutzer eine scheinbar gutartige App aus dem offiziellen PlayStore herunter. Soll ja schon vorgekommen sein, dass da Leute es geschafft haben sowas zu platzieren. Die App ersetzt dann die VR-Banking und die VR-SecureGo App mit einer Nomorp Version – wird man dann gleich auch sehr schön sehen. Danach führt der Nutzer eine Transaktion über 15 Euro durch und die wird durch 1,23 Euro – ist nicht so logisch wenn man jetzt mal kriminell denkt – ersetzt. Das ist eben eine Transaktionsmanipulation. Und bis auf das bestimmen der ID ist was ich gerade gesagt habe komplett vollautomatisch. Also das musste man nicht weiter antasten mit manuellen Aufwand, sondern nur die IDs bestimmen. Jetzt machen wir kurz noch auf, dass man die Versionen sieht. Das war das was ich gerade gesagt habe. Und als nächstes macht mir jetzt erst mal die VR-Banking App auf und die wird jetzt schwarz, weil die hat halt dieses Flag "secure" gesetzt damit man keine Aufnahmen machen machen kann. So also da sieht man jetzt nichts. Ok. Die funktioniert anscheinend. So und jetzt gehts weiter. Jetzt lädt man sich aus dem PlayStore herunter und ja, das ist echt. Gelächter Und das sieht man oben diese Leiste. Das ist eine scheinbar gute App und jetzt wurde man im Hintergrund exploitet. Jetzt machen wir die VR-Banking App nochmal auf. Gelächter und Applaus Jetzt muss man sich einloggen. Jetzt machen wir die Transaktion und die geht diesmal an mich. Nur noch kurz die IBAN eingeben. Die 15 Euro die ich gerade eben gesagt habe mit Verwendungszweck 34C3 (ist aber nicht so wichtig in dem Fall). Und jetzt ist die Überweisung versendet worden. Das bedeutet im nächsten Schritt muss man die Transaktion in der TAN App, der VR-SecureGo App, freigeben. Gleiches Spiel: Hier wurde auch wieder irgendwas gemacht. Ich muss wieder das Passwort eingeben. Dann im nächsten Schritt: wichtig ist natürlich dass die IBAN stimmt, das geht aber so schnell, da versichere ich euch dass das stimmt. Da stehen auch 15 Euro immer noch. Also stimmt ja alles. Also geben wir die Transaktion frei. So genau da unten stehen auch irgendwie 15 Euro. Passt ja alles. Und wenn man jetzt hier rein schaut, dann waren es aber wirklich 1,23 Euro. Applaus Was hier wichtig ist, dass das vollautomatisch war. Das nicht jeder irgendwie nochmal eine App reversed hat, sondern man muss nur die IDs bestimmen nachdem Promon draußen war und dann geht das. Dann komme ich mal zum Schluss: die Reaktionen der beteiligten Parteien anschauen und ein Fazit zu schließen. Also mit Promon stehen wir seit Ende November – also gut einen Monat – in Kontakt. Die waren sehr nett und professionell und sie haben mittlerweile auch eine neue Version des Promon SHIELDs entwickelt. Die liegt mir in der Beispiel-App auch vor, aber ich hatte noch nicht die Zeit, um da genauer anzuschauen. Ich kann aber sagen unsere Nomorp Toolchain funktioniert auf diese Art und Weise nicht mehr, also funktioniert nicht mehr wie zuvor. Ich kann nicht genau sagen was wurde da jetzt genau gemacht und welche großen Anpassungen sind zu machen. Es kann sein, dass es unglaublich viel Arbeit ist. Kann aber auch sein, dass es nicht viel Arbeit ist. Ich kann es einfach nicht sagen. Der Punkt ist eigentlich, um die Angriffe wirklich komplexer zu machen bräuchte man mehr Individualisierung von den Apps. Man kann ja alle Apps gleichartig angreifen. Man kann das Promon SHIELD auf die gleiche Art und Weise in all diesen 31 Apps deaktivieren indem man diese Config rewritet, weil es überall gleich ist, da es ein universaler Ansatz ist. Die Reaktion der Banken die ich seit Jahren höre: "bis heute keine Schadensfälle bekannt." Das ist natürlich ein merkwürdiges Verständnis von IT-Sicherheit. Wenn man sich jetzt aber mal anschaut, wie eigentlich überhaupt die Verteilung von Mobilebanking ist oder von App basierten TAN Verfahren, dann sind die einfach nicht relevant aktuell im Markt. 5-8% hat letztes Jahr hat eine Studie ergeben, sind die App basierten TAN Verfahren verbreitet. Dies soll sich dieses Jahr nicht groß geändert haben. Natürlich, aktuell lohnt sich das noch nicht aber das kann sich für die Zukunft ändern. 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 Eigenschaft einer Zweifaktorauthentisierung entwickelt." Gelächter Applaus Ja, kann ich nur zustimmen. Und jetzt wenn man jetzt denkt nach Mobilebanking, also nach zwei Apps auf einem Smartphone, wird es nicht mehr schlimmer – das gibt es jetzt mittlerweile auch auf einem Windows und auf einem Mac PC. Ok, kann man machen. Zwei Fragen ganz zum Schluss: ist App- Härtung überhaupt sinnvoll? Also haben diese ganzen Produkte, die ganzen Markt angeboten werden, eine Daseinsberechtigung? Ja, natürlich haben die eine eine Daseinsberechtigung. Sie haben schon einen sinnvollen Schutz die sie da einbetten. Aber das muss ein zusätzlicher Schutz sein. Und die andere Frage: Ist App-Härtung ein Ersatz für unabhängige Zweifaktor-Authentifizierung? Natürlich nicht! Das habe ich gerade eben gesagt. Weil dies Softwaremaßnahmen sind und die können, wie wir in dem Beispiel gezeigt haben, einfach nicht verhindern, dass jemand das ausnutzt. Danke Applaus Herald: Vielen Dank Vincent für Deinen Talk und Deinen weiteren Ausflug in die Welt des Mobilebankings. Wir haben Zeit für einige Fragen. Also wenn ihr Fragen habt, reiht auch an den Mikrofonen auf. Hier gibt es 1,3, da vorne ist 2, usw. Die haben Nummern dran und dann kann Vincent ein Paar Fragen für Euch beantworten. Ihr könnt auch winken wenn ihr an einem steht. Ok. An Mikrofon 3 haben wir eine Frage. Mikrofon 3: Vielen Dank für den Talk. Ganz toll! Jetzt gibt es schon für DRM-Systeme Dinge wie Widevine, die TrustZone im Chip direkt verwenden. Hast Du bei Deiner Forschung das irgendwas von gesehen? Vincent: Das ist ein wichtiger Punkt und ich glaube auch das TrustZone oder allgemeiner Trusted Execution Environments eine Art und Weise wäre, in der man so etwas in zufriedenstellend sicherer auf einem Gerät machen könnte. Gerade eben lief der BootStomp Vortrag von den Jungs der UCSB. Die würden mir da vielleicht widersprechen. Insgesamt ist das ein Einsatz auf den könnte das aufbauen, aber das ich genau da etwas gesehen habe, kann ich jetzt nicht behaupten. Jetzt gerade die alle setzen das nicht ein. Ist natürlich auch das Problem, dass es da keine einheitliche Lösung gibt. Da gibt es bisher ein Paar proprietäre Lösungen und jeder will sich da irgendwie durchsetzen. Aber einen einheitlichen Standard gibt es nicht und von daher ist es schwierig. Herald: Mikrofon 1 bitte. Mikrofon 1: Waren die untersuchten Apps alle schon nach der PSD2-Richtlinie zugelassen? Also bezog sich darauf das Zitat von den BSI Leuten? Die schreibt das ja explizit vor Zweifaktorauthentisierung. Vincent: Genau die PSD2 schreibt vor: starke Kundenauthentifizierung. Da müsste man jetzt weiter ausholen. Da wurden gerade eben die technischen Standards dafür verabschiedet. Gibt es noch eine 18-monatige Übergangsfrist, wo die Banken Zeit haben sich da anzupassen. Aber in den ganzen Werbevideos wird ganz oft davon gesprochen – jetzt gerade von diesen Drittanbietern, dass sie PSD2 kompatibel sind. Es ist ein bisschen schwierig zu sagen, was die PSD2 da genau vorschreibt. Ich glaube so die letzte Entscheidung die dazu getroffen wurde ist eher in Richtung wir akzeptieren den status quo. Man kann das meiner Meinung nach immer noch so lesen, dass eine sichere Anzeige und eine Nichtkopierbarkeit für ein Besitzelement hat. Also von daher ist das nicht ganz klar. Wenn sie jetzt die Banken fragen, dann sagen die natürlich sind sie PSD2 konform. Herald: Fragen wir den Signal Angel. Gibt es Fragen aus dem Internet? Stille Herald: Das scheint nicht der Fall zu sein. Ich habe noch eine Frage an Mikrofon 2. Mikrofon 2: Hast Du Dir aus Promon noch andere Bibliotheken angesehen? Vincent: Nein. Habe ich nicht. Das liegt aber einfach auch daran, es gibt ein Paar andere die im deutschen Markt verbreitet sind, oder was heist Verbreitung? Es gibt Vereinzelte, die das einsetzen. Die Deutsche Bank setzt mittlerweile ARXAN ein. Dann gibt es noch die ING-DiBa die Kobil verwendet. Da kann ich jetzt nicht genaueres zu sagen. Ich meine ich habe ja auch nichts per se gegen Promon - kein Problem mit denen. Aber das Problem ist eher, dass sie so relevant im deutschen Markt sind und ich irgendwie fesgestellt habe, dass so gut wie jeder sie verwendet. Deswegen hat es sich halt gelohnt, das genauer anzuschauen. Wenn jetzt jeder eine andere App-Härtungslösung verwenden würde, dann hätte man einen viel größeren Aufwand. Dann müsste man sich ja alle anschauen. Und so ist es aber man kann einmal Promon deaktivieren und das geht für alle. Das ist ja eigentlich das Problem. Herald: Letzte Frage von Mikrofon 1. Mikrofon 1: Vielen Dank für den Vortrag. Eine Frage zu dem Angriffsvektior: in diesem Fall wurde einfach die App ausgetauscht und dann – sagen wir einmal – leicht angreifbar gemacht. Wäre es denkbar, vielleicht auch beim gerooteten Phone, dass man da einfach nebendran eine Application hätte, die das einfach on-the- fly austauscht und so Applikationen angreift. Hast Du das untersucht? Vincent: Also das machen wir ja im Endeffekt. Wir binden eine Komponente in diese App ein die das macht. Ich meine in dem Fall wurde das halt ersetzt, aber ich glaube nur, dass das Ersetzen von einer App ist mitunter das Einfachste, was man machen kann. Mikrofon 1: Ich meine, wenn es nicht gerootet wäre, dann wäre es nicht möglich von einer App auf die Andere zuzugreifen und das auszutauschen. Also das müsste natürlich gerootet werden oder gibt es andere Ansätze? Vincent: Es gibt immer noch eine Unschärfe zwischen was ist ein root-Exploit also priviledge escalation und was ist ein gerootetes Gerät. Ein gerootetes Gerät ist bei mir eine bewusste Entscheidung: ich installiere bei mir SuperSU oder Magisk. Das ist bei mir eine bewusste Entscheidung. Dafür verwende ich unter Umständen priviledge escalation um das zu Platzieren, aber ein priviledge escalation an Sich, zum Beispiel DirtyCow ausnutzen ist nicht persistent – das wird einmal ausgenutzt. Spuren davon, da müssen wir jetzt einen Forensiker fragen, aber ich glaube das ist schwierig. Und das ist der große Unterschied davon. Priviledge escalation mache ich einmal, um meinen Angriffsvektor zu platzieren und danach nützen die ganzen root detections von den Systemen gar nichts mehr: ich habe kein SuperSU installiert. Herald: Ok. Nochmal herzlichen Dank Vincent Haupert. Einen großen Applaus. Applaus 34c3 outro Untertitel erstellt von c3subtitles.de im Jahr 2018. Mach mit und hilf uns!