1 00:00:00,000 --> 00:00:15,085 *34c3 intro* 2 00:00:15,085 --> 00:00:30,170 Herald: Der kommende Vortag ist von einem alten Bekannten, der schon zum 32C3 und 3 00:00:30,170 --> 00:00:36,980 zum 33C3 uns in eine wundersame Welt entführt hat voller mobiler Endgeräte und 4 00:00:36,980 --> 00:00:46,380 unsicherer Verbidungen und dem Vertrauen was wir daran stecken. Er ist Doktorrand 5 00:00:46,544 --> 00:00:52,329 an der Uni Erlangen-Nürnberg – die hat auch einen langen Namen, den ich nicht 6 00:00:52,329 --> 00:00:56,960 aufgeschrieben habe. Er ist Doktorrand der Informatik und interessiert sich besonders 7 00:00:56,960 --> 00:01:02,560 für die Sicherheit von Mobilgeräten und wird uns heute die fabelhafte Welt des 8 00:01:02,560 --> 00:01:06,900 Mobilbankings näher bringen. Begrüßt mit mir Vincent Haupert. 9 00:01:10,775 --> 00:01:15,260 *Applaus* 10 00:01:15,277 --> 00:01:17,460 Vincent: Herzlichen Dank für die Einführung. 11 00:01:17,460 --> 00:01:21,670 Fabelhaft ist ein sehr vielschichtiges Wort. An dieser Stelle 12 00:01:21,670 --> 00:01:25,700 möchte ich zuerst einmal die fabelhafte Zusammenarbeit mit meinem Kollegen Nicolas 13 00:01:25,700 --> 00:01:30,080 Schneider hervorheben ohne den diese Arbeit hier in der Form nicht möglich 14 00:01:30,080 --> 00:01:33,560 gewesen wäre. Herzlichen Dank an ihn. 15 00:01:33,560 --> 00:01:38,070 *Applaus* 16 00:01:38,080 --> 00:01:41,080 Onlinebanking – ich denke mal so gut wie 17 00:01:41,080 --> 00:01:45,070 jeder hier dürfte es machen – ist hinlänglich bekannt. Ist seit jeher im 18 00:01:45,070 --> 00:01:56,130 PIN/TAN Verfahren seitdem es von vor 30 Jahren. Ihr erster 19 00:01:56,130 --> 00:02:04,930 Faktor ist wie immer man loggt sich auch Onlinebanking Portal ein mit seinem 20 00:02:04,930 --> 00:02:10,020 Benutzername und Passwort. Danach muss man eine Transaktion aufgeben mit einer 21 00:02:10,020 --> 00:02:13,220 IBAN und mit einem Betrag. Im zweiten Schritt hat man dann irgendein TAN 22 00:02:13,220 --> 00:02:16,810 Verfahren mit dem man die Transaktion bestätigen muss. Das ist ganz klares 23 00:02:16,810 --> 00:02:21,830 Sicherheitselement das es seit Anfang des Onlinebanking gibt. Und die Art und Weise 24 00:02:21,830 --> 00:02:28,420 wie man eben die TAN generiert, empfängt, abliest ist recht unterschiedlich. Die 25 00:02:28,420 --> 00:02:30,959 ersten drei Verfahren die man jetzt hier auf dieser Liste sieht das iTAN Verfahren, 26 00:02:30,959 --> 00:02:35,069 smsTAN Verfahren und chipTAN Verfahren sind hauptsächlich aus der Motivation 27 00:02:35,069 --> 00:02:37,980 entstanden, dass es relativ viele Schadensfälle in dem Bereich gab, also 28 00:02:37,980 --> 00:02:43,120 Phishing vor allem, und mit chipTAN ist man quasi an den Zenit an gereicht / 29 00:02:43,120 --> 00:02:47,650 erlangt. Technisch kann man das eigentlich kaum noch besser machen. Gibt es natürlich 30 00:02:47,650 --> 00:02:49,520 auch noch andere Aspekte wie Benutzerfreundlichkeit die da wichtig 31 00:02:49,520 --> 00:02:54,540 sind. Deswegen gingen die Verfahren wie photoTAN oder auch appTAN gehen dann 32 00:02:54,540 --> 00:02:57,081 eigentlich mehr in die Richtung dass sie die Benutzerfreundlichkeit adressieren 33 00:02:57,081 --> 00:03:01,770 wollen – was auch durchaus legitim ist. Per se habe ich eigentlich gar nichts 34 00:03:01,770 --> 00:03:06,950 gegen App basierte TAN Verfahren. Solange man zwei Geräte verwendet. 35 00:03:06,950 --> 00:03:10,069 Also wenn man zwei Geräte Authentifizierung macht hat man ja immer 36 00:03:10,069 --> 00:03:13,281 noch den Schutz, dass, wenn ein Gerät kompromittiert ist, das andere zumindest 37 00:03:13,281 --> 00:03:18,440 nicht automatisch mit in Mitleidenschaft gezogen wird. Von daher ist es durchaus 38 00:03:18,440 --> 00:03:21,660 legitim. Ich kann mich erinnern vor zwei Jahren als ich hier den Talk gehalten 39 00:03:21,660 --> 00:03:25,790 habe, wurde ich nach photoTAN gefragt und hab noch gesagt das ist ein relativ 40 00:03:25,790 --> 00:03:29,959 solides Verfahren, weil es ja implizit eigentlich forciert, dass man zwei Geräte 41 00:03:29,959 --> 00:03:33,370 verwendet. Dann muss man ja von einem anderen Gerät abscannen und das generiert 42 00:03:33,370 --> 00:03:39,890 dann die TAN. Dann gibts halt die Verfahren die pushTAN Verfahren bzw. die, 43 00:03:39,890 --> 00:03:44,999 die über zwei Apps realisiert sind: also eine Banking App die andere die TAN App. 44 00:03:44,999 --> 00:03:50,629 Das gibt es jetzt mittlerweile seit Jahren. Und das Paradoxe ist, dass man 45 00:03:50,629 --> 00:03:56,310 mittlerweile auch photoTAN auf einem Gerät machen kann. Da kann man zwar nichts mehr 46 00:03:56,310 --> 00:03:58,810 abscannen erkennen, sondern kommunizieren einfach untereinander, aber das zeigt 47 00:03:58,810 --> 00:04:03,879 eigentlich erst mal wie abstrus es wird. Aber eigentlich redet auch heute keiner 48 00:04:03,879 --> 00:04:07,090 mehr über Zwei-App-Verfahren. Vielleicht war das auch nur eine Art und Weise um uns 49 00:04:07,090 --> 00:04:09,760 daran zu gewöhnen, dass es eigentlich keine richtige Zwei-Faktor- 50 00:04:09,760 --> 00:04:13,670 Authentifizierung mehr gibt. Und eigentlich will heute jeder ein Ein-App- 51 00:04:13,670 --> 00:04:18,259 Verfahren implementieren. Das ist insofern eigentlich bemerkenswert, weil das SMS TAN 52 00:04:18,259 --> 00:04:21,449 Verfahren, wenn man sich das mal anschaut, hat eine Geräte-Entwicklung durchgemacht 53 00:04:21,449 --> 00:04:25,729 von einem Spezialgerät hin zu einem Mehrzweckgerät. Also heute empfängt jeder 54 00:04:25,729 --> 00:04:29,419 seine SMS auf einem Smartphone. Und das ist im Prinzip auf eine bestimmte Art und 55 00:04:29,419 --> 00:04:33,470 Weise auch eine App mit der man das empfängt. Und damals war es dann das erste 56 00:04:33,470 --> 00:04:38,220 Mal möglich, dass man von einem Gerät aus eine Transaktion aufgibt und bestätigt. 57 00:04:38,220 --> 00:04:44,050 Und da hat die deutsche Kreditwirtschaft weise 2008 schon erkannt, dass das keine 58 00:04:44,050 --> 00:04:47,749 so gute Idee ist. "Dies impliziert bereits, dass die 59 00:04:47,749 --> 00:04:51,389 Verwendung des mobileTAN Verfahrens zum Beispiel nur ein mobiles Smartphone für 60 00:04:51,389 --> 00:04:54,469 beide Kommunikation Strecken nicht zulässig ist und daher den 61 00:04:54,469 --> 00:04:58,199 Kundenbedingungen für das Online-Banking explizit ausgeschlossen wird." "Dies 62 00:04:58,199 --> 00:05:03,110 impliziert bereits" so ist ja eh klar. Jetzt frage ich mich natürlich: Wo ist 63 00:05:03,110 --> 00:05:07,289 denn da jetzt der Unterschied? Also hier wird auch alles auf einem Gerät gemacht 64 00:05:07,289 --> 00:05:11,559 und das habe ich vor zwei Jahren dann auch gezeigt: habe einen Angriff auf das 65 00:05:11,559 --> 00:05:15,960 pushTAN Verfahren gezeigt mit einer Transaktionsmanipulation. Das hat hingegen 66 00:05:15,960 --> 00:05:20,400 die Sparkasse nicht so richtig beeindruckt. Die haben gesagt: "Ja das 67 00:05:20,400 --> 00:05:23,669 waren eigentlich alles nur Laborbedingungen – das geht in Wirklichkeit 68 00:05:23,669 --> 00:05:28,020 gar nicht. Und das funktioniert nur bei genau einem Gerät, genau einer App und bei 69 00:05:28,020 --> 00:05:31,300 genau einer Version" und "jedes Mal wenn wir eine neue Version herausbringen ist 70 00:05:31,300 --> 00:05:36,919 das ein hoher individueller und manuelle Aufwand." Und genau dies werden wir heute adressieren. 71 00:05:36,919 --> 00:05:44,769 *Glächter und Applaus* 72 00:05:44,769 --> 00:05:48,949 Jetzt habe ich ja vorhin gesagt so bei smsTAN hat man gesagt "ja das machen wir 73 00:05:48,949 --> 00:05:51,719 nicht, das ist nicht sicher." Und jetzt muss man sich fragen was ist denn dann 74 00:05:51,719 --> 00:05:55,629 eigentlich anders bei diesen Apps? Da gibt es eine ganze Reihe von Eigenschaft, aber 75 00:05:55,629 --> 00:06:00,139 ich denke wichtig ist diese Absicherung durch Dritte. Und zwar gibt es 76 00:06:00,139 --> 00:06:05,900 mittlerweile einen recht großen Markt an Drittanbietern die App-Härtung und App- 77 00:06:05,900 --> 00:06:09,360 Sicherheit verkaufen. Also Drittanbieter Produkte und das hier ist nur eine kleine 78 00:06:09,360 --> 00:06:17,949 Auswahl. Und denjenigen die wir uns heute etwas genauer anschauen werden ist Promon. 79 00:06:17,949 --> 00:06:23,349 Promon hat das Produkt Promon SHIELD. Die Information die hier stehen sind allesamt 80 00:06:23,349 --> 00:06:28,539 von der Website. Der Zweck von Promon SHIELD ist Schutz von Apps in nicht 81 00:06:28,539 --> 00:06:32,770 vertrauenswürdigen Umgebungen. Das Ganze ist universal, d.h. es ist egal 82 00:06:32,770 --> 00:06:35,900 was für eine App es ist, und es ist plattformunabhängig. Also es geht unter 83 00:06:35,900 --> 00:06:40,219 Android und iOS und die haben auch Lösungen für Windows. Es ist anwendbar 84 00:06:40,219 --> 00:06:45,640 innerhalb von wenigen Minuten. Das Zitat is aus dem Video: 85 00:06:45,640 --> 00:06:49,749 "Es Erkennt und verhindert jede Gefahr in Echtzeit und reagiert, indem es die 86 00:06:49,749 --> 00:06:54,409 notwendigen Schritte einleitet um die App vollständig zu schützen. Die App wird 87 00:06:54,409 --> 00:06:57,729 dadurch sicher verwendbar sogar auf hochgradig infizierten Geräten." 88 00:06:57,729 --> 00:07:05,809 *Gelächter und Applaus* 89 00:07:05,809 --> 00:07:08,669 Schauen wir uns das mal genauer an... 90 00:07:08,669 --> 00:07:12,639 Was gibt es denn eigentlich Eigenschaften die diese ganzen App-Härtungs-Geschichten 91 00:07:12,639 --> 00:07:15,830 implementieren? Also das sind nur zwei Sparten. Da gibt es in 92 00:07:15,830 --> 00:07:18,729 klassischen App-Härtungsbereich, der will statische und dynamische Analyse 93 00:07:18,729 --> 00:07:22,620 hauptsächlich verhindern. Und dann gibt es den eher neueren Bereich, da geht es dann 94 00:07:22,620 --> 00:07:26,300 eher um zu Security Best Practices. Also solche Sachen wie Certificate-Pinning und 95 00:07:26,300 --> 00:07:29,150 dass man die Anwendungs nochmal verschlüsselt. Also klassische Sachen die 96 00:07:29,150 --> 00:07:32,360 die Entwickler normalerweise gemacht haben. Und deswegen werden die 97 00:07:32,360 --> 00:07:36,429 mittlerweile zum Dreh- und Angelpunkt für sowas und gerade im Bereich des 98 00:07:36,429 --> 00:07:41,059 Mobilebanking sind die Inhalte eine wichtige Nummer. Wie verwendet man denn 99 00:07:41,059 --> 00:07:44,039 jetzt eigentlich das Promo SHIELD? Wenn ich das jetzt verwenden will für meine App, 100 00:07:44,039 --> 00:07:47,779 für meine Android oder iOS-App, die links unten dargestellt ist. Muss ich jetzt als 101 00:07:47,779 --> 00:07:52,830 Kunde noch eine Config die da oben ist spezifizieren. Also welche Features möchte 102 00:07:52,830 --> 00:07:58,189 ich denn haben z.B. Root-Erkennung sagen wir mal. Und dann kommt diese Promo und 103 00:07:58,189 --> 00:08:02,559 Integration Tool und macht irgendwie eine Promon geschützte App daraus. Danach kann 104 00:08:02,559 --> 00:08:07,409 ich sie sofort in die offiziellen Stores hochladen. Dies ist die 105 00:08:07,409 --> 00:08:14,470 Liste an Apps – das sind 31 international – die Promon SHIELD verwenden. 106 00:08:14,470 --> 00:08:17,710 Die zwei die ich jetzt gerade ausgeblendet habe sind keine Banking Apps. Sie kommen auch 107 00:08:17,710 --> 00:08:19,710 aus dem Finanzbereich aber wir wollen uns dieses Mal nur auf die Banking Apps 108 00:08:19,710 --> 00:08:24,119 konzentrieren und hier noch spezieller eigentlich auf die deutschen Banking Apps. 109 00:08:24,119 --> 00:08:27,270 Und dann sieht man auch ganz deutlich die haben in Deutschland eine wichtige 110 00:08:27,270 --> 00:08:32,190 Stellung. Also wenn man sich allein anschaut: Commerzbank, DKB, VR-Banken, 111 00:08:32,190 --> 00:08:36,610 die Sparkassen, Comdirect. Das sind alles Banken die sagen zumindest jedem etwas. 112 00:08:36,610 --> 00:08:41,889 Und da sieht man schon die sind wichtig im deutschen Markt der mobilen Banking Apps. 113 00:08:41,889 --> 00:08:46,649 Wir schauen uns tatsächlich eine App an oder machen ein Beispiel an einer App 114 00:08:46,649 --> 00:08:49,060 die vielleicht nicht jeder kennt und das ist: Yomo. 115 00:08:49,060 --> 00:08:53,089 Warum ist eigentlich Yomo so besonders interessant? 116 00:08:53,089 --> 00:08:57,379 Yomo ist eigentlich erst einmal Ein-App- Authentifizierungsverfahren. Wie ich schon 117 00:08:57,379 --> 00:08:59,529 gesagt habe, das ist heutzutage nicht mehr Besonderes – das macht eigentlich jeder 118 00:08:59,529 --> 00:09:05,839 mittlerweile und das ist N26 nachempfunden. Ich höre immer wieder das 119 00:09:05,839 --> 00:09:11,659 Gerücht, dass das intern sogar Number 27 hieß. Also das Vorbild ist 120 00:09:11,659 --> 00:09:17,040 Number 26. Aber das Interessante ist eigentlich, dass es wahrscheinlich die 121 00:09:17,040 --> 00:09:20,509 neueste Version von Promon verwendet. Warum? Weil das eine sehr junge App ist. 122 00:09:20,509 --> 00:09:24,891 Daher gehe ich davon aus, da es auch von Starfinanz ist – das ist um die Ecken 123 00:09:24,891 --> 00:09:29,799 irgendwie mit Sparkasse was, dass die da schon die neueste Version verwenden. Wenn 124 00:09:29,799 --> 00:09:36,289 sie jetzt sagen Wir machen auch so ein Ein-App-Authentifizierungs-System. 125 00:09:36,289 --> 00:09:40,160 Wie funktioniert das denn intern, wenn man ein bisschen technischer wird? Wenn dieses 126 00:09:40,160 --> 00:09:44,480 Integration-Tool von Promon kommt, dann übernimmt es die MainActivity, also den 127 00:09:44,480 --> 00:09:48,600 Einsprungspunkt der App letztendlich und bindet dann eine native Bibliothek ein: 128 00:09:48,600 --> 00:09:53,589 die libshield.so. Zusätzlich fügt Promon noch Java Klassen ein, die müssen 129 00:09:53,589 --> 00:09:57,590 irgendwie auch ihre eigene Library laden und irgendwann ein bisschen glue code. Und 130 00:09:57,590 --> 00:09:59,980 die sind unter anderem auch obfuskiert aber das spielt hier in diesem Talk 131 00:09:59,980 --> 00:10:03,480 erstmal nicht so die Rolle. Das ist es denn auch nur denen ihre eigenen Klassen. 132 00:10:03,480 --> 00:10:07,729 Dann werden aber zusätzlich aus der App, jetzt also zum Beispiel Yomo, 133 00:10:07,729 --> 00:10:11,709 alle Strings und ein Teil von Konstanten herausgezogen und werden in 134 00:10:11,709 --> 00:10:15,610 diese libshield.so reingemacht. Das Gleiche gilt es bei Yomo im speziellen 135 00:10:15,610 --> 00:10:19,860 Fall auch für ein Client-Zertifikat, das die App braucht um mit dem Backend zu 136 00:10:19,860 --> 00:10:23,209 sprechen. Und das macht eben jetzt nicht mehr Yomo direkt, sondern darum kümmert 137 00:10:23,209 --> 00:10:31,319 sich die libshield.so. Die erste Idee, die man jetzt hat, ist wir wollen das jetzt 138 00:10:31,319 --> 00:10:37,430 irgendwie loswerden. Dann modifizieren wir halt mal diese Library – diese native library. 139 00:10:37,430 --> 00:10:40,900 Wenn man sich jetzt anschaut, den Einstiegspunkt von dem, wenn man mal IDA 140 00:10:40,900 --> 00:10:46,130 aufmacht. Das ein Controllflow-Graph, also nicht das Windows abgestürzt oder sowas. 141 00:10:46,130 --> 00:10:51,350 Das ist tatsächlich einfach totales Controlflow-Flattening und das will man 142 00:10:51,350 --> 00:10:53,850 sich eigentlich nicht anschauen. Also da gibts schon auch Ansätze um das zu 143 00:10:53,850 --> 00:10:58,040 unpacken. Das ist mit dem LLVM obfuscator gemacht. Wahrscheinlich. Ich weis nicht ob 144 00:10:58,040 --> 00:11:02,170 das diese Open-Source Variante ist oder irgendwas selbst angepasst ist. Das kann 145 00:11:02,170 --> 00:11:05,880 ich nicht genau sagen. Aber auf jeden Fall das ist ökonomisch nicht machbar. 146 00:11:05,880 --> 00:11:11,759 Sagen wir jetzt mal. Also wir wollen ja irgendwas einfaches. Nächster Ansatz ist 147 00:11:11,759 --> 00:11:15,149 dann wenn wir schon die nicht modifizieren können, dann entfernen wir die Bibliothek 148 00:11:15,149 --> 00:11:19,470 halt aus der App. So einfach ist das dann auch wieder nicht. Weil wir haben ja das 149 00:11:19,470 --> 00:11:23,399 Problem, die ganzen Strings, die Konstanten und Client-Zertifikate sind 150 00:11:23,399 --> 00:11:27,790 auch alle in dieser libshield.so drin. Deswegen müssen wir diese irgendwie 151 00:11:27,790 --> 00:11:33,191 erstmal loswerden. Und fangen wir mal an mit den Strings wie 152 00:11:33,191 --> 00:11:38,750 schaut es da eigentlich aus? Also es ist da immer dargestellt links ist Yomo und 153 00:11:38,750 --> 00:11:43,990 rechts ist Promon, die native Lib von dem die libshield.so. Links oben ist immer 154 00:11:43,990 --> 00:11:50,999 bevor man in die Promon verwendt hat und links unten ist danach. Es ist dann halt so, 155 00:11:50,999 --> 00:11:54,730 dass wenn da jetzt einfach ein String ausgegeben werden soll wie Yomo, dann 156 00:11:54,730 --> 00:11:59,769 ersetzen sie das mit einem Aufruf zu ihrer native Library und die hat dann irgendwie 157 00:11:59,769 --> 00:12:03,930 irgendwelche Mappings bei sich drinnen und gibt dann halt den String zurück. 158 00:12:03,930 --> 00:12:07,939 Eigentlich auch nicht schwer, weil das ist logisch was man da gemacht hat. 159 00:12:07,939 --> 00:12:13,860 Und was macht man jetzt um das zu umgehen? Wir schauen halt mal was der höchste Index 160 00:12:13,860 --> 00:12:18,910 in dem Ding. Und dann iterieren wir eben von null bis n drüber und erstellen uns 161 00:12:18,910 --> 00:12:22,399 dann ein Mapping davon. Und dann können wir das Ganze wieder rückgängig machen was 162 00:12:22,399 --> 00:12:27,600 sie gemacht haben. Soweit so klar. Man hätte sich die ganze Arbeit gar nicht 163 00:12:27,600 --> 00:12:32,930 machen brauchen, weil man kann ja einfach drüber iterieren bis NULL zurückkommt. 164 00:12:32,930 --> 00:12:38,590 Mit Konstanten hat man im Prinzip ein ähnliches Problem. Bei den Konstanten ist 165 00:12:38,590 --> 00:12:43,529 es eben so: oben hat man da eine Konstante die war -1. Und nachdem man Promon 166 00:12:43,529 --> 00:12:47,519 verwendet hat, steht da halt irgendein Käse drin. Also irgendwas was keinen Sinn 167 00:12:47,519 --> 00:12:49,680 mehr macht, etwas das nicht funktional ist, also nicht der Wert den die Klasse 168 00:12:49,680 --> 00:12:54,971 eigentlich erwartet. Stattdessen wird ein statischer Konstruktor in der Klasse 169 00:12:54,971 --> 00:12:58,560 installiert, die dann dafür sorgt dass über Reflection dieses statisch finale 170 00:12:58,560 --> 00:13:03,319 Feld, das könnte man mit Java Code gar nicht - also nicht mal kompilieren, wenn 171 00:13:03,319 --> 00:13:06,709 man so etwas hätte. Aber über Reflection kann man kann man solche Sachen machen. 172 00:13:06,709 --> 00:13:10,390 Über Reflection wird es dann wieder richtig gesetzt bevor das erste Mal darauf 173 00:13:10,390 --> 00:13:16,860 zugegriffen wird. Die Lösung ist relativ ähnlich: Man geht einfach in alle Klassen 174 00:13:16,860 --> 00:13:21,540 rein, die dieses pushToClass aufrufen, und man ruft dasselbe auf und erstellt sich 175 00:13:21,540 --> 00:13:26,740 wieder ein Mapping. So haben wir das weg. Jetzt kommt das Client-Zertifikat. Jetzt 176 00:13:26,740 --> 00:13:31,509 wird es schon ein bisschen tricky, weil man kann jetzt nicht mehr genau so 177 00:13:31,509 --> 00:13:37,779 vorgehen wie gerade eben. Das Problem ist: Yomo macht selber aus Java Code irgendnen 178 00:13:37,779 --> 00:13:42,480 Request. Danach geht das aber nicht an die Android Library oder die Java Library in 179 00:13:42,480 --> 00:13:46,399 irgendeiner Art und Weise. Sondern es geht in Promon rein und Promon verarbeitet dann 180 00:13:46,399 --> 00:13:49,869 diesen Request in dieser native Library und die fügen das Zertifikat hinzu. 181 00:13:49,869 --> 00:13:54,330 Und jetzt kann man ja nicht einfach irgendwas aufrufen "gib mir mal das Client 182 00:13:54,330 --> 00:13:58,830 Zertifikat" – ja gut das könnte sein aber ist nicht so. Was machen wir denn jetzt da? 183 00:13:58,830 --> 00:14:02,630 Dann ist die Idee: Dann schauen wir halt mal im Speicher. Das muss ja irgendwo 184 00:14:02,630 --> 00:14:06,459 im Speicher liegen und das muss man doch irgendwie finden können. Ja wir haben 185 00:14:06,459 --> 00:14:10,889 eigentlich erwartet, dass wir nur das Zertifikat, aber was wir gefunden 186 00:14:10,889 --> 00:14:16,120 haben war eine noch viel interessantere Datenstruktur. Das sieht ein bisschen wirr aus, 187 00:14:16,120 --> 00:14:20,709 aber das ist eine Konfigurationsdatei. Da komme ich gleich noch drauf, aber da 188 00:14:20,709 --> 00:14:25,000 ist auch das was wir wollen, nämlich das Client-Zertifikat. Das ist base64 189 00:14:25,000 --> 00:14:30,620 enkodiert da drin: clientCertificate und clientCertificateKey. Schön. 190 00:14:30,620 --> 00:14:35,370 Jetzt können wir loslegen. Was machen wir jetzt? Wir können jetzt unser eigenes Tool 191 00:14:35,370 --> 00:14:39,560 Nomorp verwenden, um diesen ganzen Prozess von Promon wieder rückgängig zu machen. 192 00:14:39,560 --> 00:14:43,519 Also wir laden es aus dem Playstore herunter dann haben wir eine geschützte App. 193 00:14:43,519 --> 00:14:48,579 Im nächsten Schritt müssen wir unseren Analyzer injecten, der basiert auf 194 00:14:48,579 --> 00:14:53,930 dem Frida Gadget. Und der sorgt dann dafür, dass diese Mappings extrahiert 195 00:14:53,930 --> 00:14:58,040 werden. Dafür müssen wir das auf einem Gerät installieren und sobald die App 196 00:14:58,040 --> 00:15:02,829 gestartet wird, purzeln da diese ganzen Mappings raus und die Konfigurationsdatei 197 00:15:02,829 --> 00:15:09,220 auch bzw. halt das Client-Zertifikat in dem Fall auch noch. Und das füttern wir 198 00:15:09,220 --> 00:15:15,709 jetzt unser Tool und dann kommt die ungeschützte App raus. 199 00:15:15,709 --> 00:15:19,389 Also dann ist man das losgeworden. 200 00:15:19,389 --> 00:15:26,649 *Applaus* 201 00:15:26,649 --> 00:15:33,149 Der ganze Prozess vom Herunterladen, über das Installieren auf dem Gerät, bis dem 202 00:15:33,149 --> 00:15:38,759 Ausführen von Nomorp dauert fünf bis zehn Minuten. Die Dauer kommt ein bisschen 203 00:15:38,759 --> 00:15:43,879 darauf an wie groß die App ist. Wenn das 10 MB sind dann dauert es nicht so lange. 204 00:15:43,879 --> 00:15:48,209 Und wenn es halt eine 100 MB App ist, dann dauert es halt entsprechend bisschen 205 00:15:48,209 --> 00:15:51,029 länger weil wir da irgendwie Transformation auf Basis von textlib2 206 00:15:51,029 --> 00:15:54,079 machen müssen und dann dauert es halt ein bisschen – aber trotzdem keine Zeit 207 00:15:54,079 --> 00:15:58,470 eigentlich. Kommt ein Update raus, laden wir das direkt runter und das wars. 208 00:15:58,470 --> 00:16:03,269 Jetzt schauen wir aber trotzdem nochmal auf diese auf die Mappings, auf diese 209 00:16:03,269 --> 00:16:06,699 Konfigurationsdatei die wir gerade eben hatten, weil das nämlich eigentlich 210 00:16:06,699 --> 00:16:11,720 bemerkenswert ist. Ich habe jetzt schon die ganze Zeit gesagt: Diese ganzen 211 00:16:11,720 --> 00:16:16,589 Strings und Konstanten sind alle in dieser libshield.so drin. Aber das scheint gar 212 00:16:16,589 --> 00:16:20,369 nicht zu stimmen. Wir haben ja eine Konfigurationsdatei gesehen. Warum sollte 213 00:16:20,369 --> 00:16:24,230 denn das dann drin sein? Da würde ich schon eine binär Datei erwarten, dass das 214 00:16:24,230 --> 00:16:28,060 irgendwie alles schon in bestimmten Datenstrukturen drin ist. Es stellt sich 215 00:16:28,060 --> 00:16:33,119 heraus, dass diese libshield.so schon bei Promon kompiliert wurde und wird so an den 216 00:16:33,119 --> 00:16:36,459 Kunden ausgeliefert. Das heißt bei den Kunden wird gar nichts kompiliert. 217 00:16:36,459 --> 00:16:40,360 Stattdessen, wenn man sich jetzt die Grafik rechts anschaut: Als Kunde habe ich 218 00:16:40,360 --> 00:16:43,449 eben nur diese App und meine Konfigurationsdatei. Dann gebe ich diese 219 00:16:43,449 --> 00:16:47,749 dem Promon Integration Tool und dies hat schon diese libshield.so drin, hat aber 220 00:16:47,749 --> 00:16:53,930 natürlich auch irgendwelche Analyse- und Modifikations-Module. Die sind dann dafür 221 00:16:53,930 --> 00:16:57,430 verantwortlich das da unten diese Config verschlüsselt wird und die Mappings 222 00:16:57,430 --> 00:17:01,970 verschlüsselt werden. Aber die liegen letztendlich in dieser App mit drin, 223 00:17:01,970 --> 00:17:08,849 werden dann einfach geladen und man verwendet die dann entsprechend. Und das 224 00:17:08,849 --> 00:17:10,939 macht letztendlich nochmal ein ganz anderes Angriffszenario interessant. 225 00:17:10,939 --> 00:17:14,959 Wenn wir das links nochmal ein bisschen strukturierter anschauen,dann sind dort 226 00:17:14,959 --> 00:17:19,550 solche Sachen wie checkDebugger, exitOnDebugger und exitOnDebuggerUrl. 227 00:17:19,550 --> 00:17:24,640 Was heisst das? Heisst das soll ich überhaupt noch Debugger überprüfen? Was wenn ich 228 00:17:24,640 --> 00:17:27,940 einen Debugger finde, soll ich dann die App crashen? Und wenn ich sie crashe, 229 00:17:27,940 --> 00:17:33,890 sollte diese URL hier öffnen. Das ist bei den anderen Sachen relativ analog. 230 00:17:33,890 --> 00:17:38,490 Wie wärs denn wenn wir diese Konfigurationsdatei einfach nachdem sie 231 00:17:38,490 --> 00:17:43,559 entschlüsselt wurde, bevor sie geparsed wird modifizieren? Wir sagen einfach 232 00:17:43,559 --> 00:17:49,010 "Hey wir schreiben da überall null rein". Also zu dem Zeitpunkt haben uns schon 233 00:17:49,010 --> 00:17:52,620 ein bisschen geärgert, weil das andere war echt viel Arbeit. 234 00:17:52,620 --> 00:18:03,200 *Gelächter und Applaus* 235 00:18:03,200 --> 00:18:06,900 Das war bisher alles sehr Android spezifisch. 236 00:18:06,900 --> 00:18:12,560 Also ganz kurz zu iOS. Bei iOS ist es letztendlich recht ähnlich. Da gibt 237 00:18:12,560 --> 00:18:16,810 es auch eine Konfigurationsdatei, die ist aber wesentlich weniger umfangreich, und 238 00:18:16,810 --> 00:18:19,980 insgesamt habe ich auch das Gefühl da wird weniger gemacht. Das binär Coding kann man 239 00:18:19,980 --> 00:18:23,799 nicht so schön transformieren wie irgendwie bei Java Bytecode. Letztendlich 240 00:18:23,799 --> 00:18:28,179 sind aber ähnliche Checks halt analog zur zu Android Welt drin und man könnte wieder 241 00:18:28,179 --> 00:18:31,090 sagen "wir schreiben das halt um". 242 00:18:33,720 --> 00:18:36,230 Fassen wir nochmal die Angriffe zusammen: 243 00:18:36,230 --> 00:18:39,659 Wir haben zwei verschiedene Angriffe gesehen. Dein Einen, wo ich gerade schon 244 00:18:39,659 --> 00:18:42,430 gesagt habe der eigentlich relativ komplex war, weil man da relativ viel transformieren 245 00:18:42,430 --> 00:18:46,970 muss, der darauf abzielt dass man Promon SHIELD entfernt. Und dann was ich gerade 246 00:18:46,970 --> 00:18:50,279 vorgestellt habe. Man schreibt einfach die Konfigurationsdatei um. 247 00:18:50,279 --> 00:18:53,330 Da hat man auch kein Problem mit Inkompatibilitäten, bleibt ja alles 248 00:18:53,330 --> 00:18:58,169 kompatibel. Man sagt im Prinzip nur de facto mach einfach nichts. 249 00:18:59,559 --> 00:19:05,070 Danach ist die App im Prinzip komplett ungeschützt. Die Hersteller implementieren 250 00:19:05,070 --> 00:19:11,000 in großem Stil auch keinen Repackaging- Schutz und dergleichen mehr. Jetzt können 251 00:19:11,000 --> 00:19:14,490 wir doch eigentlich weiter automatisieren. Jetzt mal als Beispiel-Angriff: 252 00:19:14,490 --> 00:19:18,100 Transaktionsmanipulation. Wir haben dann gesagt, gut dann erweitern wir doch Nomorp 253 00:19:18,100 --> 00:19:24,429 mal so, dass wir das fast vollständig automatisch machen können. Hier mal als 254 00:19:24,429 --> 00:19:28,240 Beispiel das VR Banking App. Eigentlich was man immer nur machen will bei einer 255 00:19:28,240 --> 00:19:31,850 Transaktionsmanipulation ist: Man will hier bestimmte Views, Text Views oder 256 00:19:31,850 --> 00:19:35,799 sowas, manipulieren. Das sind halt in dem Fall die interessanten. 257 00:19:35,799 --> 00:19:41,539 Der 'Name des Empfängers' ist im Beispiel falsch. Das muss natürlich was anders 258 00:19:41,539 --> 00:19:46,179 sein, das müsste die IBAN sein. Entschuldigung. Das ist ein Fehler. Aber 259 00:19:46,179 --> 00:19:50,450 der txt_betrag ist richtig und die haben natürlich eine ID irgendwo. Und die muss 260 00:19:50,450 --> 00:19:53,990 man quasi manuell ermitteln und alles andere kann man dann vollständig 261 00:19:53,990 --> 00:19:58,330 automatisch machen. Also man kann dies alles injecten. Man muss ja nur wissen was 262 00:19:58,330 --> 00:20:00,570 man danach austauschen muss bzw. auslesen muss. 263 00:20:02,150 --> 00:20:05,539 Jetzt machen wir mal eine kleine Demo. Jetzt kann sich aber mal wieder Yomo 264 00:20:05,539 --> 00:20:08,549 zurücklehnen und brauchen jetzt keine Angst haben geht nicht mit ihnen weiter. 265 00:20:08,549 --> 00:20:15,110 Wir schauen uns das jetzt mal anhand der VR Banken an. Das Video haben wir heute 266 00:20:15,110 --> 00:20:21,649 Nachmittag gemacht. Es ist etwas zügig entstanden. Deswegen sage ich jetzt mal 267 00:20:21,649 --> 00:20:26,170 nochmal zuvor, was man gleich sehen wird. Dieses Szenario ist das folgende: Wir 268 00:20:26,170 --> 00:20:30,059 haben ein Nexus 5X mit Android 7.0 und es hat einen Security Patch Level von vor 269 00:20:30,059 --> 00:20:38,049 ungefähr einem Jahr. Und warum ist das so? Wir wollten irgendwas wo man Dateien 270 00:20:38,049 --> 00:20:40,110 schreiben darf, die man eigentlich schreiben darf. 271 00:20:40,110 --> 00:20:43,700 Also DirtyCOW ist ein klassisch gutes Beispiel. Und warum es es auch so ein 272 00:20:43,700 --> 00:20:48,251 gutes Beispiel? Damit ist es gar nicht so einfach root im Sinne von SuperSU zu 273 00:20:48,251 --> 00:20:51,910 bekommen. Ich glaube dass es erst vor kurzem gelungen. Aber man kann Dateien 274 00:20:51,910 --> 00:20:56,549 schreiben die man eigentlich schreiben dürfte. Dann lädt sich der Nutzer eine 275 00:20:56,549 --> 00:21:00,149 scheinbar gutartige App aus dem offiziellen PlayStore herunter. Soll ja 276 00:21:00,149 --> 00:21:05,430 schon vorgekommen sein, dass da Leute es geschafft haben sowas zu platzieren. 277 00:21:05,430 --> 00:21:10,201 Die App ersetzt dann die VR-Banking und die VR-SecureGo App mit einer Nomorp Version – 278 00:21:10,201 --> 00:21:14,120 wird man dann gleich auch sehr schön sehen. Danach führt der Nutzer eine 279 00:21:14,120 --> 00:21:17,510 Transaktion über 15 Euro durch und die wird durch 1,23 Euro – ist nicht so 280 00:21:17,510 --> 00:21:24,000 logisch wenn man jetzt mal kriminell denkt – ersetzt. Das ist eben eine 281 00:21:24,000 --> 00:21:27,580 Transaktionsmanipulation. Und bis auf das bestimmen der ID ist was 282 00:21:27,580 --> 00:21:30,710 ich gerade gesagt habe komplett vollautomatisch. Also das musste man nicht 283 00:21:30,710 --> 00:21:35,669 weiter antasten mit manuellen Aufwand, sondern nur die IDs bestimmen. 284 00:21:35,669 --> 00:21:40,500 Jetzt machen wir kurz noch auf, dass man die Versionen sieht. Das war das was ich 285 00:21:40,500 --> 00:21:43,409 gerade gesagt habe. Und als nächstes macht mir jetzt erst mal die VR-Banking App auf 286 00:21:43,409 --> 00:21:46,809 und die wird jetzt schwarz, weil die hat halt dieses Flag "secure" gesetzt damit 287 00:21:46,809 --> 00:21:52,400 man keine Aufnahmen machen machen kann. So also da sieht man jetzt nichts. Ok. 288 00:21:52,400 --> 00:21:57,799 Die funktioniert anscheinend. So und jetzt gehts weiter. Jetzt lädt man sich aus dem 289 00:21:57,799 --> 00:22:00,029 PlayStore herunter und ja, das ist echt. 290 00:22:00,029 --> 00:22:02,790 *Gelächter* 291 00:22:02,790 --> 00:22:08,899 Und das sieht man oben diese Leiste. Das ist eine scheinbar gute App und jetzt 292 00:22:08,899 --> 00:22:14,680 wurde man im Hintergrund exploitet. Jetzt machen wir die VR-Banking App nochmal auf. 293 00:22:17,724 --> 00:22:24,744 *Gelächter und Applaus* 294 00:22:25,930 --> 00:22:31,130 Jetzt muss man sich einloggen. Jetzt machen wir die Transaktion und die geht 295 00:22:31,130 --> 00:22:41,980 diesmal an mich. Nur noch kurz die IBAN eingeben. Die 15 Euro die ich gerade eben 296 00:22:41,980 --> 00:22:47,139 gesagt habe mit Verwendungszweck 34C3 (ist aber nicht so wichtig in dem Fall). 297 00:22:49,059 --> 00:22:52,890 Und jetzt ist die Überweisung versendet worden. Das bedeutet im nächsten Schritt 298 00:22:52,890 --> 00:22:59,539 muss man die Transaktion in der TAN App, der VR-SecureGo App, freigeben. Gleiches 299 00:22:59,539 --> 00:23:05,059 Spiel: Hier wurde auch wieder irgendwas gemacht. Ich muss wieder das Passwort 300 00:23:05,059 --> 00:23:10,710 eingeben. Dann im nächsten Schritt: wichtig ist natürlich dass die IBAN 301 00:23:10,710 --> 00:23:13,249 stimmt, das geht aber so schnell, da versichere ich euch dass das stimmt. 302 00:23:13,249 --> 00:23:19,559 Da stehen auch 15 Euro immer noch. Also stimmt ja alles. Also geben wir die 303 00:23:19,559 --> 00:23:27,661 Transaktion frei. So genau da unten stehen auch irgendwie 15 Euro. Passt ja alles. 304 00:23:28,851 --> 00:23:32,950 Und wenn man jetzt hier rein schaut, dann waren es aber wirklich 1,23 Euro. 305 00:23:32,950 --> 00:23:42,810 *Applaus* 306 00:23:42,810 --> 00:23:46,870 Was hier wichtig ist, dass das vollautomatisch war. 307 00:23:46,870 --> 00:23:51,240 Das nicht jeder irgendwie nochmal eine App reversed hat, 308 00:23:51,240 --> 00:23:55,050 sondern man muss nur die IDs bestimmen nachdem Promon draußen war 309 00:23:55,050 --> 00:23:57,620 und dann geht das. 310 00:23:58,420 --> 00:24:00,620 Dann komme ich mal zum Schluss: 311 00:24:00,620 --> 00:24:09,059 die Reaktionen der beteiligten Parteien anschauen und ein Fazit zu schließen. Also 312 00:24:09,059 --> 00:24:13,700 mit Promon stehen wir seit Ende November – also gut einen Monat – in Kontakt. 313 00:24:13,700 --> 00:24:18,179 Die waren sehr nett und professionell und sie haben mittlerweile auch eine neue Version 314 00:24:18,179 --> 00:24:22,720 des Promon SHIELDs entwickelt. Die liegt mir in der Beispiel-App auch vor, aber ich 315 00:24:22,720 --> 00:24:26,040 hatte noch nicht die Zeit, um da genauer anzuschauen. Ich kann aber sagen unsere 316 00:24:26,040 --> 00:24:29,789 Nomorp Toolchain funktioniert auf diese Art und Weise nicht mehr, also 317 00:24:29,789 --> 00:24:32,630 funktioniert nicht mehr wie zuvor. Ich kann nicht genau sagen was wurde da jetzt 318 00:24:32,630 --> 00:24:36,870 genau gemacht und welche großen Anpassungen sind zu machen. Es kann sein, 319 00:24:36,870 --> 00:24:40,490 dass es unglaublich viel Arbeit ist. Kann aber auch sein, dass es nicht viel Arbeit ist. 320 00:24:40,490 --> 00:24:45,289 Ich kann es einfach nicht sagen. Der Punkt ist eigentlich, um die Angriffe 321 00:24:45,289 --> 00:24:49,520 wirklich komplexer zu machen bräuchte man mehr Individualisierung von den Apps. 322 00:24:49,520 --> 00:24:53,330 Man kann ja alle Apps gleichartig angreifen. Man kann das Promon SHIELD auf die gleiche 323 00:24:53,330 --> 00:24:58,690 Art und Weise in all diesen 31 Apps deaktivieren indem man diese Config 324 00:24:58,690 --> 00:25:02,820 rewritet, weil es überall gleich ist, da es ein universaler Ansatz ist. 325 00:25:02,820 --> 00:25:08,779 Die Reaktion der Banken die ich seit Jahren höre: "bis heute keine 326 00:25:08,779 --> 00:25:12,800 Schadensfälle bekannt." Das ist natürlich ein merkwürdiges Verständnis von 327 00:25:12,800 --> 00:25:18,429 IT-Sicherheit. Wenn man sich jetzt aber mal anschaut, wie eigentlich überhaupt die 328 00:25:18,429 --> 00:25:22,400 Verteilung von Mobilebanking ist oder von App basierten TAN Verfahren, dann sind die 329 00:25:22,400 --> 00:25:27,850 einfach nicht relevant aktuell im Markt. 5-8% hat letztes Jahr hat eine Studie 330 00:25:27,850 --> 00:25:32,850 ergeben, sind die App basierten TAN Verfahren verbreitet. Dies soll sich 331 00:25:32,850 --> 00:25:36,559 dieses Jahr nicht groß geändert haben. Natürlich, aktuell lohnt sich das noch 332 00:25:36,559 --> 00:25:40,529 nicht aber das kann sich für die Zukunft ändern. 333 00:25:42,319 --> 00:25:47,120 Das finde ich ein sehr schönes Zitat von Jens Bender und Dennis Kügler vom BSI: 334 00:25:47,120 --> 00:25:50,900 "Im Bereich des Zahlungswesens hat sich eine besondere Kreativität in der Auslegung 335 00:25:50,900 --> 00:25:53,640 der Eigenschaft einer Zweifaktorauthentisierung entwickelt." 336 00:25:54,049 --> 00:25:56,089 *Gelächter* 337 00:25:56,089 --> 00:26:01,130 *Applaus* 338 00:26:01,130 --> 00:26:06,059 Ja, kann ich nur zustimmen. Und jetzt wenn man jetzt denkt nach Mobilebanking, also nach 339 00:26:06,059 --> 00:26:10,440 zwei Apps auf einem Smartphone, wird es nicht mehr schlimmer – das gibt es jetzt 340 00:26:10,440 --> 00:26:19,680 mittlerweile auch auf einem Windows und auf einem Mac PC. Ok, kann man machen. 341 00:26:21,470 --> 00:26:27,760 Zwei Fragen ganz zum Schluss: ist App- Härtung überhaupt sinnvoll? Also haben 342 00:26:27,760 --> 00:26:32,480 diese ganzen Produkte, die ganzen Markt angeboten werden, eine Daseinsberechtigung? 343 00:26:33,190 --> 00:26:36,320 Ja, natürlich haben die eine eine Daseinsberechtigung. Sie haben 344 00:26:36,320 --> 00:26:40,110 schon einen sinnvollen Schutz die sie da einbetten. Aber das muss ein 345 00:26:40,120 --> 00:26:41,889 zusätzlicher Schutz sein. 346 00:26:41,889 --> 00:26:44,539 Und die andere Frage: Ist App-Härtung ein Ersatz für unabhängige 347 00:26:44,539 --> 00:26:47,280 Zweifaktor-Authentifizierung? Natürlich nicht! 348 00:26:47,280 --> 00:26:53,580 Das habe ich gerade eben gesagt. Weil dies Softwaremaßnahmen sind und die können, 349 00:26:53,580 --> 00:26:56,080 wie wir in dem Beispiel gezeigt haben, 350 00:26:56,080 --> 00:26:59,510 einfach nicht verhindern, dass jemand das ausnutzt. 351 00:27:00,820 --> 00:27:02,510 Danke 352 00:27:02,510 --> 00:27:14,020 *Applaus* 353 00:27:14,020 --> 00:27:16,120 Herald: Vielen Dank Vincent für Deinen Talk 354 00:27:16,120 --> 00:27:21,970 und Deinen weiteren Ausflug in die Welt des Mobilebankings. Wir haben Zeit 355 00:27:21,970 --> 00:27:26,850 für einige Fragen. Also wenn ihr Fragen habt, reiht auch an den Mikrofonen auf. 356 00:27:26,850 --> 00:27:36,279 Hier gibt es 1,3, da vorne ist 2, usw. Die haben Nummern dran und dann kann Vincent 357 00:27:36,279 --> 00:27:39,380 ein Paar Fragen für Euch beantworten. 358 00:27:47,469 --> 00:27:49,659 Ihr könnt auch winken wenn ihr an einem steht. 359 00:27:50,850 --> 00:27:53,460 Ok. An Mikrofon 3 haben wir eine Frage. 360 00:27:53,460 --> 00:27:56,460 Mikrofon 3: Vielen Dank für den Talk. Ganz toll! 361 00:27:56,460 --> 00:28:02,080 Jetzt gibt es schon für DRM-Systeme Dinge wie Widevine, die TrustZone 362 00:28:02,080 --> 00:28:07,519 im Chip direkt verwenden. Hast Du bei Deiner Forschung das irgendwas von gesehen? 363 00:28:07,550 --> 00:28:11,140 Vincent: Das ist ein wichtiger Punkt und 364 00:28:11,140 --> 00:28:15,540 ich glaube auch das TrustZone oder allgemeiner Trusted Execution Environments 365 00:28:15,540 --> 00:28:21,019 eine Art und Weise wäre, in der man so etwas in zufriedenstellend sicherer auf 366 00:28:21,019 --> 00:28:25,840 einem Gerät machen könnte. Gerade eben lief der BootStomp Vortrag von den Jungs 367 00:28:25,840 --> 00:28:30,950 der UCSB. Die würden mir da vielleicht widersprechen. Insgesamt ist das ein 368 00:28:30,950 --> 00:28:36,080 Einsatz auf den könnte das aufbauen, aber das ich genau da etwas gesehen habe, kann 369 00:28:36,080 --> 00:28:40,850 ich jetzt nicht behaupten. Jetzt gerade die alle setzen das nicht ein. Ist 370 00:28:40,850 --> 00:28:43,830 natürlich auch das Problem, dass es da keine einheitliche Lösung gibt. Da gibt es 371 00:28:43,830 --> 00:28:47,179 bisher ein Paar proprietäre Lösungen und jeder will sich da irgendwie durchsetzen. 372 00:28:47,179 --> 00:28:48,610 Aber einen einheitlichen Standard gibt es nicht und von daher ist es schwierig. 373 00:28:48,610 --> 00:28:55,190 Herald: Mikrofon 1 bitte. Mikrofon 1: Waren die untersuchten Apps 374 00:28:55,190 --> 00:29:01,640 alle schon nach der PSD2-Richtlinie zugelassen? Also bezog sich darauf das 375 00:29:01,640 --> 00:29:06,860 Zitat von den BSI Leuten? Die schreibt das ja explizit vor Zweifaktorauthentisierung. 376 00:29:06,860 --> 00:29:13,419 Vincent: Genau die PSD2 schreibt vor: starke Kundenauthentifizierung. Da müsste 377 00:29:13,419 --> 00:29:16,200 man jetzt weiter ausholen. Da wurden gerade eben die technischen Standards 378 00:29:16,200 --> 00:29:20,070 dafür verabschiedet. Gibt es noch eine 18-monatige Übergangsfrist, wo die Banken 379 00:29:20,070 --> 00:29:24,429 Zeit haben sich da anzupassen. Aber in den ganzen Werbevideos wird ganz oft davon 380 00:29:24,429 --> 00:29:28,980 gesprochen – jetzt gerade von diesen Drittanbietern, dass sie PSD2 kompatibel 381 00:29:28,980 --> 00:29:33,029 sind. Es ist ein bisschen schwierig zu sagen, was die PSD2 da genau vorschreibt. 382 00:29:33,029 --> 00:29:37,169 Ich glaube so die letzte Entscheidung die dazu getroffen wurde ist eher in Richtung 383 00:29:37,169 --> 00:29:40,990 wir akzeptieren den status quo. Man kann das meiner Meinung nach immer noch so 384 00:29:40,990 --> 00:29:46,850 lesen, dass eine sichere Anzeige und eine Nichtkopierbarkeit für ein Besitzelement 385 00:29:46,850 --> 00:29:51,820 hat. Also von daher ist das nicht ganz klar. Wenn sie jetzt die Banken fragen, 386 00:29:51,820 --> 00:29:53,850 dann sagen die natürlich sind sie PSD2 konform. 387 00:29:53,850 --> 00:30:00,750 Herald: Fragen wir den Signal Angel. Gibt es Fragen aus dem Internet? 388 00:30:00,750 --> 00:30:05,490 *Stille* 389 00:30:05,490 --> 00:30:09,429 Herald: Das scheint nicht der Fall zu sein. Ich habe noch eine Frage an Mikrofon 2. 390 00:30:09,429 --> 00:30:14,010 Mikrofon 2: Hast Du Dir aus Promon noch andere Bibliotheken angesehen? 391 00:30:14,010 --> 00:30:18,679 Vincent: Nein. Habe ich nicht. Das liegt aber einfach auch daran, es gibt ein Paar 392 00:30:18,679 --> 00:30:21,840 andere die im deutschen Markt verbreitet sind, oder was heist Verbreitung? Es gibt 393 00:30:21,840 --> 00:30:24,890 Vereinzelte, die das einsetzen. Die Deutsche Bank setzt mittlerweile ARXAN 394 00:30:24,890 --> 00:30:29,559 ein. Dann gibt es noch die ING-DiBa die Kobil verwendet. Da kann ich jetzt nicht 395 00:30:29,559 --> 00:30:33,750 genaueres zu sagen. Ich meine ich habe ja auch nichts per se gegen Promon - kein 396 00:30:33,750 --> 00:30:36,990 Problem mit denen. Aber das Problem ist eher, dass sie so relevant im deutschen 397 00:30:36,990 --> 00:30:40,610 Markt sind und ich irgendwie fesgestellt habe, dass so gut wie jeder sie 398 00:30:40,610 --> 00:30:44,389 verwendet. Deswegen hat es sich halt gelohnt, das genauer anzuschauen. Wenn 399 00:30:44,389 --> 00:30:48,470 jetzt jeder eine andere App-Härtungslösung verwenden würde, dann hätte man einen viel 400 00:30:48,470 --> 00:30:52,169 größeren Aufwand. Dann müsste man sich ja alle anschauen. Und so ist es aber man 401 00:30:52,169 --> 00:30:57,180 kann einmal Promon deaktivieren und das geht für alle. Das ist ja eigentlich das Problem. 402 00:30:57,990 --> 00:31:00,120 Herald: Letzte Frage von Mikrofon 1. 403 00:31:00,310 --> 00:31:04,930 Mikrofon 1: Vielen Dank für den Vortrag. Eine Frage zu dem Angriffsvektior: in 404 00:31:04,930 --> 00:31:10,919 diesem Fall wurde einfach die App ausgetauscht und dann – sagen wir einmal – 405 00:31:10,919 --> 00:31:14,649 leicht angreifbar gemacht. Wäre es denkbar, vielleicht auch beim gerooteten 406 00:31:14,649 --> 00:31:19,059 Phone, dass man da einfach nebendran eine Application hätte, die das einfach on-the- 407 00:31:19,059 --> 00:31:23,629 fly austauscht und so Applikationen angreift. Hast Du das untersucht? 408 00:31:23,629 --> 00:31:28,930 Vincent: Also das machen wir ja im Endeffekt. Wir binden eine Komponente in 409 00:31:28,930 --> 00:31:34,460 diese App ein die das macht. Ich meine in dem Fall wurde das halt ersetzt, aber ich 410 00:31:34,460 --> 00:31:39,050 glaube nur, dass das Ersetzen von einer App ist mitunter das Einfachste, 411 00:31:39,050 --> 00:31:40,050 was man machen kann. 412 00:31:40,050 --> 00:31:41,850 Mikrofon 1: Ich meine, wenn es nicht gerootet wäre, dann wäre es nicht möglich 413 00:31:41,850 --> 00:31:47,010 von einer App auf die Andere zuzugreifen und das auszutauschen. Also das müsste 414 00:31:47,010 --> 00:31:53,240 natürlich gerootet werden oder gibt es andere Ansätze? 415 00:31:53,240 --> 00:31:58,190 Vincent: Es gibt immer noch eine Unschärfe 416 00:31:58,190 --> 00:32:01,899 zwischen was ist ein root-Exploit also priviledge escalation und was ist ein 417 00:32:01,899 --> 00:32:05,690 gerootetes Gerät. Ein gerootetes Gerät ist bei mir eine bewusste Entscheidung: ich 418 00:32:05,690 --> 00:32:09,870 installiere bei mir SuperSU oder Magisk. Das ist bei mir eine bewusste 419 00:32:09,870 --> 00:32:13,720 Entscheidung. Dafür verwende ich unter Umständen priviledge escalation um das zu 420 00:32:13,720 --> 00:32:18,179 Platzieren, aber ein priviledge escalation an Sich, zum Beispiel DirtyCow ausnutzen 421 00:32:18,179 --> 00:32:22,149 ist nicht persistent – das wird einmal ausgenutzt. Spuren davon, da müssen wir 422 00:32:22,149 --> 00:32:26,131 jetzt einen Forensiker fragen, aber ich glaube das ist schwierig. Und das ist der 423 00:32:26,131 --> 00:32:29,139 große Unterschied davon. Priviledge escalation mache ich einmal, um meinen 424 00:32:29,139 --> 00:32:32,990 Angriffsvektor zu platzieren und danach nützen die ganzen root detections von den 425 00:32:32,990 --> 00:32:36,244 Systemen gar nichts mehr: ich habe kein SuperSU installiert. 426 00:32:37,984 --> 00:32:41,574 Herald: Ok. Nochmal herzlichen Dank Vincent Haupert. Einen großen Applaus. 427 00:32:41,870 --> 00:32:49,559 *Applaus* 428 00:32:49,559 --> 00:32:52,336 *34c3 outro* 429 00:32:52,336 --> 00:33:11,000 Untertitel erstellt von c3subtitles.de im Jahr 2018. Mach mit und hilf uns!