0:00:00.000,0:00:15.085 34c3 intro 0:00:15.085,0:00:30.170 Herald: Der kommende Vortag ist von einem[br]alten Bekannten, der schon zum 32C3 und 0:00:30.170,0:00:36.980 zum 33C3 uns in eine wundersame Welt[br]entführt hat voller mobiler Endgeräte und 0:00:36.980,0:00:46.380 unsicherer Verbidungen und dem Vertrauen[br]was wir daran stecken. Er ist Doktorrand 0:00:46.544,0:00:52.329 an der Uni Erlangen-Nürnberg – die hat[br]auch einen langen Namen, den ich nicht 0:00:52.329,0:00:56.960 aufgeschrieben habe. Er ist Doktorrand der[br]Informatik und interessiert sich besonders 0:00:56.960,0:01:02.560 für die Sicherheit von Mobilgeräten und[br]wird uns heute die fabelhafte Welt des 0:01:02.560,0:01:06.900 Mobilbankings näher bringen. Begrüßt mit[br]mir Vincent Haupert. 0:01:10.775,0:01:15.260 Applaus 0:01:15.277,0:01:17.460 Vincent: Herzlichen Dank für die Einführung. 0:01:17.460,0:01:21.670 Fabelhaft ist ein sehr vielschichtiges Wort. [br]An dieser Stelle 0:01:21.670,0:01:25.700 möchte ich zuerst einmal die fabelhafte[br]Zusammenarbeit mit meinem Kollegen Nicolas 0:01:25.700,0:01:30.080 Schneider hervorheben ohne den diese[br]Arbeit hier in der Form nicht möglich 0:01:30.080,0:01:33.560 gewesen wäre. Herzlichen Dank an ihn. 0:01:33.560,0:01:38.070 Applaus 0:01:38.080,0:01:41.080 Onlinebanking – ich denke mal so gut wie 0:01:41.080,0:01:45.070 jeder hier dürfte es machen – ist[br]hinlänglich bekannt. Ist seit jeher im 0:01:45.070,0:01:56.130 PIN/TAN Verfahren seitdem es von vor 30[br]Jahren. Ihr erster 0:01:56.130,0:02:04.930 Faktor ist wie immer man loggt sich auch[br]Onlinebanking Portal ein mit seinem 0:02:04.930,0:02:10.020 Benutzername und Passwort. Danach muss[br]man eine Transaktion aufgeben mit einer 0:02:10.020,0:02:13.220 IBAN und mit einem Betrag. Im zweiten[br]Schritt hat man dann irgendein TAN 0:02:13.220,0:02:16.810 Verfahren mit dem man die Transaktion[br]bestätigen muss. Das ist ganz klares 0:02:16.810,0:02:21.830 Sicherheitselement das es seit Anfang des[br]Onlinebanking gibt. Und die Art und Weise 0:02:21.830,0:02:28.420 wie man eben die TAN generiert, empfängt,[br]abliest ist recht unterschiedlich. Die 0:02:28.420,0:02:30.959 ersten drei Verfahren die man jetzt hier[br]auf dieser Liste sieht das iTAN Verfahren, 0:02:30.959,0:02:35.069 smsTAN Verfahren und chipTAN Verfahren[br]sind hauptsächlich aus der Motivation 0:02:35.069,0:02:37.980 entstanden, dass es relativ viele[br]Schadensfälle in dem Bereich gab, also 0:02:37.980,0:02:43.120 Phishing vor allem, und mit chipTAN ist[br]man quasi an den Zenit an gereicht / 0:02:43.120,0:02:47.650 erlangt. Technisch kann man das eigentlich[br]kaum noch besser machen. Gibt es natürlich 0:02:47.650,0:02:49.520 auch noch andere Aspekte wie[br]Benutzerfreundlichkeit die da wichtig 0:02:49.520,0:02:54.540 sind. Deswegen gingen die Verfahren wie[br]photoTAN oder auch appTAN gehen dann 0:02:54.540,0:02:57.081 eigentlich mehr in die Richtung dass sie[br]die Benutzerfreundlichkeit adressieren 0:02:57.081,0:03:01.770 wollen – was auch durchaus legitim ist.[br]Per se habe ich eigentlich gar nichts 0:03:01.770,0:03:06.950 gegen App basierte TAN Verfahren. Solange[br]man zwei Geräte verwendet. 0:03:06.950,0:03:10.069 Also wenn man zwei Geräte[br]Authentifizierung macht hat man ja immer 0:03:10.069,0:03:13.281 noch den Schutz, dass, wenn ein Gerät[br]kompromittiert ist, das andere zumindest 0:03:13.281,0:03:18.440 nicht automatisch mit in Mitleidenschaft[br]gezogen wird. Von daher ist es durchaus 0:03:18.440,0:03:21.660 legitim. Ich kann mich erinnern vor zwei[br]Jahren als ich hier den Talk gehalten 0:03:21.660,0:03:25.790 habe, wurde ich nach photoTAN gefragt und[br]hab noch gesagt das ist ein relativ 0:03:25.790,0:03:29.959 solides Verfahren, weil es ja implizit[br]eigentlich forciert, dass man zwei Geräte 0:03:29.959,0:03:33.370 verwendet. Dann muss man ja von einem[br]anderen Gerät abscannen und das generiert 0:03:33.370,0:03:39.890 dann die TAN. Dann gibts halt die[br]Verfahren die pushTAN Verfahren bzw. die, 0:03:39.890,0:03:44.999 die über zwei Apps realisiert sind: also[br]eine Banking App die andere die TAN App. 0:03:44.999,0:03:50.629 Das gibt es jetzt mittlerweile seit[br]Jahren. Und das Paradoxe ist, dass man 0:03:50.629,0:03:56.310 mittlerweile auch photoTAN auf einem Gerät[br]machen kann. Da kann man zwar nichts mehr 0:03:56.310,0:03:58.810 abscannen erkennen, sondern kommunizieren[br]einfach untereinander, aber das zeigt 0:03:58.810,0:04:03.879 eigentlich erst mal wie abstrus es wird.[br]Aber eigentlich redet auch heute keiner 0:04:03.879,0:04:07.090 mehr über Zwei-App-Verfahren. Vielleicht[br]war das auch nur eine Art und Weise um uns 0:04:07.090,0:04:09.760 daran zu gewöhnen, dass es eigentlich[br]keine richtige Zwei-Faktor- 0:04:09.760,0:04:13.670 Authentifizierung mehr gibt. Und[br]eigentlich will heute jeder ein Ein-App- 0:04:13.670,0:04:18.259 Verfahren implementieren. Das ist insofern[br]eigentlich bemerkenswert, weil das SMS TAN 0:04:18.259,0:04:21.449 Verfahren, wenn man sich das mal anschaut,[br]hat eine Geräte-Entwicklung durchgemacht 0:04:21.449,0:04:25.729 von einem Spezialgerät hin zu einem[br]Mehrzweckgerät. Also heute empfängt jeder 0:04:25.729,0:04:29.419 seine SMS auf einem Smartphone. Und das[br]ist im Prinzip auf eine bestimmte Art und 0:04:29.419,0:04:33.470 Weise auch eine App mit der man das[br]empfängt. Und damals war es dann das erste 0:04:33.470,0:04:38.220 Mal möglich, dass man von einem Gerät aus[br]eine Transaktion aufgibt und bestätigt. 0:04:38.220,0:04:44.050 Und da hat die deutsche Kreditwirtschaft[br]weise 2008 schon erkannt, dass das keine 0:04:44.050,0:04:47.749 so gute Idee ist.[br]"Dies impliziert bereits, dass die 0:04:47.749,0:04:51.389 Verwendung des mobileTAN Verfahrens zum[br]Beispiel nur ein mobiles Smartphone für 0:04:51.389,0:04:54.469 beide Kommunikation Strecken nicht[br]zulässig ist und daher den 0:04:54.469,0:04:58.199 Kundenbedingungen für das Online-Banking[br]explizit ausgeschlossen wird." "Dies 0:04:58.199,0:05:03.110 impliziert bereits" so ist ja eh klar.[br]Jetzt frage ich mich natürlich: Wo ist 0:05:03.110,0:05:07.289 denn da jetzt der Unterschied? Also hier[br]wird auch alles auf einem Gerät gemacht 0:05:07.289,0:05:11.559 und das habe ich vor zwei Jahren dann auch[br]gezeigt: habe einen Angriff auf das 0:05:11.559,0:05:15.960 pushTAN Verfahren gezeigt mit einer[br]Transaktionsmanipulation. Das hat hingegen 0:05:15.960,0:05:20.400 die Sparkasse nicht so richtig[br]beeindruckt. Die haben gesagt: "Ja das 0:05:20.400,0:05:23.669 waren eigentlich alles nur[br]Laborbedingungen – das geht in Wirklichkeit 0:05:23.669,0:05:28.020 gar nicht. Und das funktioniert nur bei[br]genau einem Gerät, genau einer App und bei 0:05:28.020,0:05:31.300 genau einer Version" und "jedes Mal wenn[br]wir eine neue Version herausbringen ist 0:05:31.300,0:05:36.919 das ein hoher individueller und manuelle Aufwand." [br]Und genau dies werden wir heute adressieren. 0:05:36.919,0:05:44.769 Glächter und Applaus 0:05:44.769,0:05:48.949 Jetzt habe ich ja vorhin gesagt so bei[br]smsTAN hat man gesagt "ja das machen wir 0:05:48.949,0:05:51.719 nicht, das ist nicht sicher." Und jetzt[br]muss man sich fragen was ist denn dann 0:05:51.719,0:05:55.629 eigentlich anders bei diesen Apps? Da gibt[br]es eine ganze Reihe von Eigenschaft, aber 0:05:55.629,0:06:00.139 ich denke wichtig ist diese Absicherung[br]durch Dritte. Und zwar gibt es 0:06:00.139,0:06:05.900 mittlerweile einen recht großen Markt an[br]Drittanbietern die App-Härtung und App- 0:06:05.900,0:06:09.360 Sicherheit verkaufen. Also Drittanbieter[br]Produkte und das hier ist nur eine kleine 0:06:09.360,0:06:17.949 Auswahl. Und denjenigen die wir uns heute[br]etwas genauer anschauen werden ist Promon. 0:06:17.949,0:06:23.349 Promon hat das Produkt Promon SHIELD. Die[br]Information die hier stehen sind allesamt 0:06:23.349,0:06:28.539 von der Website. Der Zweck von Promon[br]SHIELD ist Schutz von Apps in nicht 0:06:28.539,0:06:32.770 vertrauenswürdigen Umgebungen.[br]Das Ganze ist universal, d.h. es ist egal 0:06:32.770,0:06:35.900 was für eine App es ist, und es ist[br]plattformunabhängig. Also es geht unter 0:06:35.900,0:06:40.219 Android und iOS und die haben auch[br]Lösungen für Windows. Es ist anwendbar 0:06:40.219,0:06:45.640 innerhalb von wenigen Minuten. [br]Das Zitat is aus dem Video: 0:06:45.640,0:06:49.749 "Es Erkennt und verhindert jede Gefahr in[br]Echtzeit und reagiert, indem es die 0:06:49.749,0:06:54.409 notwendigen Schritte einleitet um die App[br]vollständig zu schützen. Die App wird 0:06:54.409,0:06:57.729 dadurch sicher verwendbar sogar auf[br]hochgradig infizierten Geräten." 0:06:57.729,0:07:05.809 Gelächter und Applaus 0:07:05.809,0:07:08.669 Schauen wir uns das mal genauer an... 0:07:08.669,0:07:12.639 Was gibt es denn eigentlich Eigenschaften [br]die diese ganzen App-Härtungs-Geschichten 0:07:12.639,0:07:15.830 implementieren? Also[br]das sind nur zwei Sparten. Da gibt es in 0:07:15.830,0:07:18.729 klassischen App-Härtungsbereich, der will[br]statische und dynamische Analyse 0:07:18.729,0:07:22.620 hauptsächlich verhindern. Und dann gibt es[br]den eher neueren Bereich, da geht es dann 0:07:22.620,0:07:26.300 eher um zu Security Best Practices. Also[br]solche Sachen wie Certificate-Pinning und 0:07:26.300,0:07:29.150 dass man die Anwendungs nochmal[br]verschlüsselt. Also klassische Sachen die 0:07:29.150,0:07:32.360 die Entwickler normalerweise gemacht[br]haben. Und deswegen werden die 0:07:32.360,0:07:36.429 mittlerweile zum Dreh- und Angelpunkt für[br]sowas und gerade im Bereich des 0:07:36.429,0:07:41.059 Mobilebanking sind die Inhalte eine[br]wichtige Nummer. Wie verwendet man denn 0:07:41.059,0:07:44.039 jetzt eigentlich das Promo SHIELD? Wenn[br]ich das jetzt verwenden will für meine App, 0:07:44.039,0:07:47.779 für meine Android oder iOS-App, die links[br]unten dargestellt ist. Muss ich jetzt als 0:07:47.779,0:07:52.830 Kunde noch eine Config die da oben ist[br]spezifizieren. Also welche Features möchte 0:07:52.830,0:07:58.189 ich denn haben z.B. Root-Erkennung sagen[br]wir mal. Und dann kommt diese Promo und 0:07:58.189,0:08:02.559 Integration Tool und macht irgendwie eine[br]Promon geschützte App daraus. Danach kann 0:08:02.559,0:08:07.409 ich sie sofort in die offiziellen Stores[br]hochladen. Dies ist die 0:08:07.409,0:08:14.470 Liste an Apps – das sind 31 international[br]– die Promon SHIELD verwenden. 0:08:14.470,0:08:17.710 Die zwei die ich jetzt gerade ausgeblendet habe[br]sind keine Banking Apps. Sie kommen auch 0:08:17.710,0:08:19.710 aus dem Finanzbereich aber wir wollen uns[br]dieses Mal nur auf die Banking Apps 0:08:19.710,0:08:24.119 konzentrieren und hier noch spezieller[br]eigentlich auf die deutschen Banking Apps. 0:08:24.119,0:08:27.270 Und dann sieht man auch ganz deutlich die[br]haben in Deutschland eine wichtige 0:08:27.270,0:08:32.190 Stellung. Also wenn man sich allein[br]anschaut: Commerzbank, DKB, VR-Banken, 0:08:32.190,0:08:36.610 die Sparkassen, Comdirect. Das sind alles[br]Banken die sagen zumindest jedem etwas. 0:08:36.610,0:08:41.889 Und da sieht man schon die sind wichtig im[br]deutschen Markt der mobilen Banking Apps. 0:08:41.889,0:08:46.649 Wir schauen uns tatsächlich eine App an[br]oder machen ein Beispiel an einer App 0:08:46.649,0:08:49.060 die vielleicht nicht jeder kennt und das ist:[br]Yomo. 0:08:49.060,0:08:53.089 Warum ist eigentlich Yomo so besonders[br]interessant? 0:08:53.089,0:08:57.379 Yomo ist eigentlich erst einmal Ein-App-[br]Authentifizierungsverfahren. Wie ich schon 0:08:57.379,0:08:59.529 gesagt habe, das ist heutzutage nicht mehr[br]Besonderes – das macht eigentlich jeder 0:08:59.529,0:09:05.839 mittlerweile und das ist N26[br]nachempfunden. Ich höre immer wieder das 0:09:05.839,0:09:11.659 Gerücht, dass das intern sogar[br]Number 27 hieß. Also das Vorbild ist 0:09:11.659,0:09:17.040 Number 26. Aber das Interessante ist[br]eigentlich, dass es wahrscheinlich die 0:09:17.040,0:09:20.509 neueste Version von Promon verwendet.[br]Warum? Weil das eine sehr junge App ist. 0:09:20.509,0:09:24.891 Daher gehe ich davon aus, da es auch von[br]Starfinanz ist – das ist um die Ecken 0:09:24.891,0:09:29.799 irgendwie mit Sparkasse was, dass die da[br]schon die neueste Version verwenden. Wenn 0:09:29.799,0:09:36.289 sie jetzt sagen Wir machen auch so ein[br]Ein-App-Authentifizierungs-System. 0:09:36.289,0:09:40.160 Wie funktioniert das denn intern, wenn man[br]ein bisschen technischer wird? Wenn dieses 0:09:40.160,0:09:44.480 Integration-Tool von Promon kommt, dann[br]übernimmt es die MainActivity, also den 0:09:44.480,0:09:48.600 Einsprungspunkt der App letztendlich und[br]bindet dann eine native Bibliothek ein: 0:09:48.600,0:09:53.589 die libshield.so. Zusätzlich fügt Promon[br]noch Java Klassen ein, die müssen 0:09:53.589,0:09:57.590 irgendwie auch ihre eigene Library laden[br]und irgendwann ein bisschen glue code. Und 0:09:57.590,0:09:59.980 die sind unter anderem auch obfuskiert[br]aber das spielt hier in diesem Talk 0:09:59.980,0:10:03.480 erstmal nicht so die Rolle. Das ist es[br]denn auch nur denen ihre eigenen Klassen. 0:10:03.480,0:10:07.729 Dann werden aber zusätzlich aus der App,[br]jetzt also zum Beispiel Yomo, 0:10:07.729,0:10:11.709 alle Strings und ein Teil von Konstanten [br]herausgezogen und werden in 0:10:11.709,0:10:15.610 diese libshield.so reingemacht. Das[br]Gleiche gilt es bei Yomo im speziellen 0:10:15.610,0:10:19.860 Fall auch für ein Client-Zertifikat, das[br]die App braucht um mit dem Backend zu 0:10:19.860,0:10:23.209 sprechen. Und das macht eben jetzt nicht[br]mehr Yomo direkt, sondern darum kümmert 0:10:23.209,0:10:31.319 sich die libshield.so. Die erste Idee, die[br]man jetzt hat, ist wir wollen das jetzt 0:10:31.319,0:10:37.430 irgendwie loswerden. Dann modifizieren wir[br]halt mal diese Library – diese native library. 0:10:37.430,0:10:40.900 Wenn man sich jetzt anschaut, den[br]Einstiegspunkt von dem, wenn man mal IDA 0:10:40.900,0:10:46.130 aufmacht. Das ein Controllflow-Graph, also[br]nicht das Windows abgestürzt oder sowas. 0:10:46.130,0:10:51.350 Das ist tatsächlich einfach totales[br]Controlflow-Flattening und das will man 0:10:51.350,0:10:53.850 sich eigentlich nicht anschauen.[br]Also da gibts schon auch Ansätze um das zu 0:10:53.850,0:10:58.040 unpacken. Das ist mit dem LLVM obfuscator[br]gemacht. Wahrscheinlich. Ich weis nicht ob 0:10:58.040,0:11:02.170 das diese Open-Source Variante ist oder[br]irgendwas selbst angepasst ist. Das kann 0:11:02.170,0:11:05.880 ich nicht genau sagen. Aber auf jeden Fall[br]das ist ökonomisch nicht machbar. 0:11:05.880,0:11:11.759 Sagen wir jetzt mal. Also wir wollen ja[br]irgendwas einfaches. Nächster Ansatz ist 0:11:11.759,0:11:15.149 dann wenn wir schon die nicht modifizieren[br]können, dann entfernen wir die Bibliothek 0:11:15.149,0:11:19.470 halt aus der App. So einfach ist das dann[br]auch wieder nicht. Weil wir haben ja das 0:11:19.470,0:11:23.399 Problem, die ganzen Strings, die[br]Konstanten und Client-Zertifikate sind 0:11:23.399,0:11:27.790 auch alle in dieser libshield.so drin.[br]Deswegen müssen wir diese irgendwie 0:11:27.790,0:11:33.191 erstmal loswerden.[br]Und fangen wir mal an mit den Strings wie 0:11:33.191,0:11:38.750 schaut es da eigentlich aus? Also es ist[br]da immer dargestellt links ist Yomo und 0:11:38.750,0:11:43.990 rechts ist Promon, die native Lib von dem[br]die libshield.so. Links oben ist immer 0:11:43.990,0:11:50.999 bevor man in die Promon verwendt hat und[br]links unten ist danach. Es ist dann halt so, 0:11:50.999,0:11:54.730 dass wenn da jetzt einfach ein String[br]ausgegeben werden soll wie Yomo, dann 0:11:54.730,0:11:59.769 ersetzen sie das mit einem Aufruf zu ihrer[br]native Library und die hat dann irgendwie 0:11:59.769,0:12:03.930 irgendwelche Mappings bei sich drinnen und[br]gibt dann halt den String zurück. 0:12:03.930,0:12:07.939 Eigentlich auch nicht schwer, weil das ist[br]logisch was man da gemacht hat. 0:12:07.939,0:12:13.860 Und was macht man jetzt um das zu umgehen?[br]Wir schauen halt mal was der höchste Index 0:12:13.860,0:12:18.910 in dem Ding. Und dann iterieren wir eben[br]von null bis n drüber und erstellen uns 0:12:18.910,0:12:22.399 dann ein Mapping davon. Und dann können[br]wir das Ganze wieder rückgängig machen was 0:12:22.399,0:12:27.600 sie gemacht haben. Soweit so klar. Man[br]hätte sich die ganze Arbeit gar nicht 0:12:27.600,0:12:32.930 machen brauchen, weil man kann ja einfach[br]drüber iterieren bis NULL zurückkommt. 0:12:32.930,0:12:38.590 Mit Konstanten hat man im Prinzip ein[br]ähnliches Problem. Bei den Konstanten ist 0:12:38.590,0:12:43.529 es eben so: oben hat man da eine Konstante[br]die war -1. Und nachdem man Promon 0:12:43.529,0:12:47.519 verwendet hat, steht da halt irgendein[br]Käse drin. Also irgendwas was keinen Sinn 0:12:47.519,0:12:49.680 mehr macht, etwas das nicht funktional[br]ist, also nicht der Wert den die Klasse 0:12:49.680,0:12:54.971 eigentlich erwartet. Stattdessen wird ein[br]statischer Konstruktor in der Klasse 0:12:54.971,0:12:58.560 installiert, die dann dafür sorgt dass[br]über Reflection dieses statisch finale 0:12:58.560,0:13:03.319 Feld, das könnte man mit Java Code gar[br]nicht - also nicht mal kompilieren, wenn 0:13:03.319,0:13:06.709 man so etwas hätte. Aber über Reflection[br]kann man kann man solche Sachen machen. 0:13:06.709,0:13:10.390 Über Reflection wird es dann wieder[br]richtig gesetzt bevor das erste Mal darauf 0:13:10.390,0:13:16.860 zugegriffen wird. Die Lösung ist relativ[br]ähnlich: Man geht einfach in alle Klassen 0:13:16.860,0:13:21.540 rein, die dieses pushToClass aufrufen, und[br]man ruft dasselbe auf und erstellt sich 0:13:21.540,0:13:26.740 wieder ein Mapping. So haben wir das weg.[br]Jetzt kommt das Client-Zertifikat. Jetzt 0:13:26.740,0:13:31.509 wird es schon ein bisschen tricky, weil[br]man kann jetzt nicht mehr genau so 0:13:31.509,0:13:37.779 vorgehen wie gerade eben. Das Problem ist:[br]Yomo macht selber aus Java Code irgendnen 0:13:37.779,0:13:42.480 Request. Danach geht das aber nicht an die[br]Android Library oder die Java Library in 0:13:42.480,0:13:46.399 irgendeiner Art und Weise. Sondern es geht[br]in Promon rein und Promon verarbeitet dann 0:13:46.399,0:13:49.869 diesen Request in dieser native Library[br]und die fügen das Zertifikat hinzu. 0:13:49.869,0:13:54.330 Und jetzt kann man ja nicht einfach [br]irgendwas aufrufen "gib mir mal das Client 0:13:54.330,0:13:58.830 Zertifikat" – ja gut das könnte sein aber[br]ist nicht so. Was machen wir denn jetzt da? 0:13:58.830,0:14:02.630 Dann ist die Idee: Dann schauen wir[br]halt mal im Speicher. Das muss ja irgendwo 0:14:02.630,0:14:06.459 im Speicher liegen und das muss man doch[br]irgendwie finden können. Ja wir haben 0:14:06.459,0:14:10.889 eigentlich erwartet, dass wir nur das[br]Zertifikat, aber was wir gefunden 0:14:10.889,0:14:16.120 haben war eine noch viel interessantere[br]Datenstruktur. Das sieht ein bisschen wirr aus, 0:14:16.120,0:14:20.709 aber das ist eine Konfigurationsdatei.[br]Da komme ich gleich noch drauf, aber da 0:14:20.709,0:14:25.000 ist auch das was wir wollen, nämlich das[br]Client-Zertifikat. Das ist base64 0:14:25.000,0:14:30.620 enkodiert da drin: clientCertificate und[br]clientCertificateKey. Schön. 0:14:30.620,0:14:35.370 Jetzt können wir loslegen. Was machen wir[br]jetzt? Wir können jetzt unser eigenes Tool 0:14:35.370,0:14:39.560 Nomorp verwenden, um diesen ganzen Prozess[br]von Promon wieder rückgängig zu machen. 0:14:39.560,0:14:43.519 Also wir laden es aus dem Playstore[br]herunter dann haben wir eine geschützte App. 0:14:43.519,0:14:48.579 Im nächsten Schritt müssen wir[br]unseren Analyzer injecten, der basiert auf 0:14:48.579,0:14:53.930 dem Frida Gadget. Und der sorgt dann[br]dafür, dass diese Mappings extrahiert 0:14:53.930,0:14:58.040 werden. Dafür müssen wir das auf einem[br]Gerät installieren und sobald die App 0:14:58.040,0:15:02.829 gestartet wird, purzeln da diese ganzen[br]Mappings raus und die Konfigurationsdatei 0:15:02.829,0:15:09.220 auch bzw. halt das Client-Zertifikat in[br]dem Fall auch noch. Und das füttern wir 0:15:09.220,0:15:15.709 jetzt unser Tool und dann kommt die[br]ungeschützte App raus. 0:15:15.709,0:15:19.389 Also dann ist man das losgeworden. 0:15:19.389,0:15:26.649 Applaus 0:15:26.649,0:15:33.149 Der ganze Prozess vom Herunterladen, über[br]das Installieren auf dem Gerät, bis dem 0:15:33.149,0:15:38.759 Ausführen von Nomorp dauert fünf bis zehn[br]Minuten. Die Dauer kommt ein bisschen 0:15:38.759,0:15:43.879 darauf an wie groß die App ist. Wenn das[br]10 MB sind dann dauert es nicht so lange. 0:15:43.879,0:15:48.209 Und wenn es halt eine 100 MB App ist, dann[br]dauert es halt entsprechend bisschen 0:15:48.209,0:15:51.029 länger weil wir da irgendwie[br]Transformation auf Basis von textlib2 0:15:51.029,0:15:54.079 machen müssen und dann dauert es halt ein[br]bisschen – aber trotzdem keine Zeit 0:15:54.079,0:15:58.470 eigentlich. Kommt ein Update raus, laden[br]wir das direkt runter und das wars. 0:15:58.470,0:16:03.269 Jetzt schauen wir aber trotzdem nochmal[br]auf diese auf die Mappings, auf diese 0:16:03.269,0:16:06.699 Konfigurationsdatei die wir gerade eben[br]hatten, weil das nämlich eigentlich 0:16:06.699,0:16:11.720 bemerkenswert ist. Ich habe jetzt schon[br]die ganze Zeit gesagt: Diese ganzen 0:16:11.720,0:16:16.589 Strings und Konstanten sind alle in dieser[br]libshield.so drin. Aber das scheint gar 0:16:16.589,0:16:20.369 nicht zu stimmen. Wir haben ja eine[br]Konfigurationsdatei gesehen. Warum sollte 0:16:20.369,0:16:24.230 denn das dann drin sein? Da würde ich[br]schon eine binär Datei erwarten, dass das 0:16:24.230,0:16:28.060 irgendwie alles schon in bestimmten[br]Datenstrukturen drin ist. Es stellt sich 0:16:28.060,0:16:33.119 heraus, dass diese libshield.so schon bei[br]Promon kompiliert wurde und wird so an den 0:16:33.119,0:16:36.459 Kunden ausgeliefert. Das heißt bei den[br]Kunden wird gar nichts kompiliert. 0:16:36.459,0:16:40.360 Stattdessen, wenn man sich jetzt die[br]Grafik rechts anschaut: Als Kunde habe ich 0:16:40.360,0:16:43.449 eben nur diese App und meine[br]Konfigurationsdatei. Dann gebe ich diese 0:16:43.449,0:16:47.749 dem Promon Integration Tool und dies hat[br]schon diese libshield.so drin, hat aber 0:16:47.749,0:16:53.930 natürlich auch irgendwelche Analyse- und[br]Modifikations-Module. Die sind dann dafür 0:16:53.930,0:16:57.430 verantwortlich das da unten diese Config[br]verschlüsselt wird und die Mappings 0:16:57.430,0:17:01.970 verschlüsselt werden. Aber die liegen[br]letztendlich in dieser App mit drin, 0:17:01.970,0:17:08.849 werden dann einfach geladen und man[br]verwendet die dann entsprechend. Und das 0:17:08.849,0:17:10.939 macht letztendlich nochmal ein ganz[br]anderes Angriffszenario interessant. 0:17:10.939,0:17:14.959 Wenn wir das links nochmal ein bisschen[br]strukturierter anschauen,dann sind dort 0:17:14.959,0:17:19.550 solche Sachen wie checkDebugger,[br]exitOnDebugger und exitOnDebuggerUrl. 0:17:19.550,0:17:24.640 Was heisst das? Heisst das soll ich überhaupt[br]noch Debugger überprüfen? Was wenn ich 0:17:24.640,0:17:27.940 einen Debugger finde, soll ich dann die[br]App crashen? Und wenn ich sie crashe, 0:17:27.940,0:17:33.890 sollte diese URL hier öffnen. Das ist bei[br]den anderen Sachen relativ analog. 0:17:33.890,0:17:38.490 Wie wärs denn wenn wir diese[br]Konfigurationsdatei einfach nachdem sie 0:17:38.490,0:17:43.559 entschlüsselt wurde, bevor sie geparsed[br]wird modifizieren? Wir sagen einfach 0:17:43.559,0:17:49.010 "Hey wir schreiben da überall null rein". [br]Also zu dem Zeitpunkt haben uns schon 0:17:49.010,0:17:52.620 ein bisschen geärgert, weil das andere [br]war echt viel Arbeit. 0:17:52.620,0:18:03.200 Gelächter und Applaus[br] 0:18:03.200,0:18:06.900 Das war bisher alles sehr Android spezifisch. 0:18:06.900,0:18:12.560 Also ganz kurz zu iOS. Bei iOS[br]ist es letztendlich recht ähnlich. Da gibt 0:18:12.560,0:18:16.810 es auch eine Konfigurationsdatei, die ist[br]aber wesentlich weniger umfangreich, und 0:18:16.810,0:18:19.980 insgesamt habe ich auch das Gefühl da wird[br]weniger gemacht. Das binär Coding kann man 0:18:19.980,0:18:23.799 nicht so schön transformieren wie[br]irgendwie bei Java Bytecode. Letztendlich 0:18:23.799,0:18:28.179 sind aber ähnliche Checks halt analog zur[br]zu Android Welt drin und man könnte wieder 0:18:28.179,0:18:31.090 sagen "wir schreiben das halt um". 0:18:33.720,0:18:36.230 Fassen wir nochmal die Angriffe zusammen: 0:18:36.230,0:18:39.659 Wir haben zwei verschiedene Angriffe[br]gesehen. Dein Einen, wo ich gerade schon 0:18:39.659,0:18:42.430 gesagt habe der eigentlich relativ komplex[br]war, weil man da relativ viel transformieren 0:18:42.430,0:18:46.970 muss, der darauf abzielt dass man Promon [br]SHIELD entfernt. Und dann was ich gerade 0:18:46.970,0:18:50.279 vorgestellt habe. Man schreibt einfach [br]die Konfigurationsdatei um. 0:18:50.279,0:18:53.330 Da hat man auch kein Problem mit[br]Inkompatibilitäten, bleibt ja alles 0:18:53.330,0:18:58.169 kompatibel. Man sagt im Prinzip nur de[br]facto mach einfach nichts. 0:18:59.559,0:19:05.070 Danach ist die App im Prinzip komplett[br]ungeschützt. Die Hersteller implementieren 0:19:05.070,0:19:11.000 in großem Stil auch keinen Repackaging-[br]Schutz und dergleichen mehr. Jetzt können 0:19:11.000,0:19:14.490 wir doch eigentlich weiter automatisieren.[br]Jetzt mal als Beispiel-Angriff: 0:19:14.490,0:19:18.100 Transaktionsmanipulation. Wir haben dann[br]gesagt, gut dann erweitern wir doch Nomorp 0:19:18.100,0:19:24.429 mal so, dass wir das fast vollständig[br]automatisch machen können. Hier mal als 0:19:24.429,0:19:28.240 Beispiel das VR Banking App. Eigentlich[br]was man immer nur machen will bei einer 0:19:28.240,0:19:31.850 Transaktionsmanipulation ist: Man will[br]hier bestimmte Views, Text Views oder 0:19:31.850,0:19:35.799 sowas, manipulieren. Das sind [br]halt in dem Fall die interessanten. 0:19:35.799,0:19:41.539 Der 'Name des Empfängers' ist im Beispiel[br]falsch. Das muss natürlich was anders 0:19:41.539,0:19:46.179 sein, das müsste die IBAN sein.[br]Entschuldigung. Das ist ein Fehler. Aber 0:19:46.179,0:19:50.450 der txt_betrag ist richtig und die haben[br]natürlich eine ID irgendwo. Und die muss 0:19:50.450,0:19:53.990 man quasi manuell ermitteln und alles[br]andere kann man dann vollständig 0:19:53.990,0:19:58.330 automatisch machen. Also man kann dies[br]alles injecten. Man muss ja nur wissen was 0:19:58.330,0:20:00.570 man danach austauschen muss[br]bzw. auslesen muss. 0:20:02.150,0:20:05.539 Jetzt machen wir mal eine kleine Demo.[br]Jetzt kann sich aber mal wieder Yomo 0:20:05.539,0:20:08.549 zurücklehnen und brauchen jetzt keine[br]Angst haben geht nicht mit ihnen weiter. 0:20:08.549,0:20:15.110 Wir schauen uns das jetzt mal anhand der[br]VR Banken an. Das Video haben wir heute 0:20:15.110,0:20:21.649 Nachmittag gemacht. Es ist etwas zügig[br]entstanden. Deswegen sage ich jetzt mal 0:20:21.649,0:20:26.170 nochmal zuvor, was man gleich sehen wird.[br]Dieses Szenario ist das folgende: Wir 0:20:26.170,0:20:30.059 haben ein Nexus 5X mit Android 7.0 und es[br]hat einen Security Patch Level von vor 0:20:30.059,0:20:38.049 ungefähr einem Jahr. Und warum ist das so?[br]Wir wollten irgendwas wo man Dateien 0:20:38.049,0:20:40.110 schreiben darf, die man eigentlich[br]schreiben darf. 0:20:40.110,0:20:43.700 Also DirtyCOW ist ein klassisch gutes[br]Beispiel. Und warum es es auch so ein 0:20:43.700,0:20:48.251 gutes Beispiel? Damit ist es gar nicht so[br]einfach root im Sinne von SuperSU zu 0:20:48.251,0:20:51.910 bekommen. Ich glaube dass es erst vor[br]kurzem gelungen. Aber man kann Dateien 0:20:51.910,0:20:56.549 schreiben die man eigentlich schreiben[br]dürfte. Dann lädt sich der Nutzer eine 0:20:56.549,0:21:00.149 scheinbar gutartige App aus dem[br]offiziellen PlayStore herunter. Soll ja 0:21:00.149,0:21:05.430 schon vorgekommen sein, dass da Leute es[br]geschafft haben sowas zu platzieren. 0:21:05.430,0:21:10.201 Die App ersetzt dann die VR-Banking und die[br]VR-SecureGo App mit einer Nomorp Version – 0:21:10.201,0:21:14.120 wird man dann gleich auch sehr schön[br]sehen. Danach führt der Nutzer eine 0:21:14.120,0:21:17.510 Transaktion über 15 Euro durch und die[br]wird durch 1,23 Euro – ist nicht so 0:21:17.510,0:21:24.000 logisch wenn man jetzt mal kriminell [br]denkt – ersetzt. Das ist eben eine 0:21:24.000,0:21:27.580 Transaktionsmanipulation.[br]Und bis auf das bestimmen der ID ist was 0:21:27.580,0:21:30.710 ich gerade gesagt habe komplett[br]vollautomatisch. Also das musste man nicht 0:21:30.710,0:21:35.669 weiter antasten mit manuellen Aufwand,[br]sondern nur die IDs bestimmen. 0:21:35.669,0:21:40.500 Jetzt machen wir kurz noch auf, dass man die[br]Versionen sieht. Das war das was ich 0:21:40.500,0:21:43.409 gerade gesagt habe. Und als nächstes macht[br]mir jetzt erst mal die VR-Banking App auf 0:21:43.409,0:21:46.809 und die wird jetzt schwarz, weil die hat[br]halt dieses Flag "secure" gesetzt damit 0:21:46.809,0:21:52.400 man keine Aufnahmen machen machen kann.[br]So also da sieht man jetzt nichts. Ok. 0:21:52.400,0:21:57.799 Die funktioniert anscheinend. So und jetzt[br]gehts weiter. Jetzt lädt man sich aus dem 0:21:57.799,0:22:00.029 PlayStore herunter und ja, das ist echt. 0:22:00.029,0:22:02.790 Gelächter 0:22:02.790,0:22:08.899 Und das sieht man oben diese Leiste. Das[br]ist eine scheinbar gute App und jetzt 0:22:08.899,0:22:14.680 wurde man im Hintergrund exploitet. Jetzt[br]machen wir die VR-Banking App nochmal auf. 0:22:17.724,0:22:24.744 Gelächter und Applaus 0:22:25.930,0:22:31.130 Jetzt muss man sich einloggen. Jetzt[br]machen wir die Transaktion und die geht 0:22:31.130,0:22:41.980 diesmal an mich. Nur noch kurz die IBAN[br]eingeben. Die 15 Euro die ich gerade eben 0:22:41.980,0:22:47.139 gesagt habe mit Verwendungszweck 34C3 (ist[br]aber nicht so wichtig in dem Fall). 0:22:49.059,0:22:52.890 Und jetzt ist die Überweisung versendet[br]worden. Das bedeutet im nächsten Schritt 0:22:52.890,0:22:59.539 muss man die Transaktion in der TAN App,[br]der VR-SecureGo App, freigeben. Gleiches 0:22:59.539,0:23:05.059 Spiel: Hier wurde auch wieder irgendwas[br]gemacht. Ich muss wieder das Passwort 0:23:05.059,0:23:10.710 eingeben. Dann im nächsten Schritt:[br]wichtig ist natürlich dass die IBAN 0:23:10.710,0:23:13.249 stimmt, das geht aber so schnell, da[br]versichere ich euch dass das stimmt. 0:23:13.249,0:23:19.559 Da stehen auch 15 Euro immer noch. [br]Also stimmt ja alles. Also geben wir die 0:23:19.559,0:23:27.661 Transaktion frei. So genau da unten stehen[br]auch irgendwie 15 Euro. Passt ja alles. 0:23:28.851,0:23:32.950 Und wenn man jetzt hier rein schaut, dann[br]waren es aber wirklich 1,23 Euro. 0:23:32.950,0:23:42.810 Applaus 0:23:42.810,0:23:46.870 Was hier wichtig ist, dass das [br]vollautomatisch war. 0:23:46.870,0:23:51.240 Das nicht jeder irgendwie nochmal [br]eine App reversed hat, 0:23:51.240,0:23:55.050 sondern man muss nur die IDs bestimmen[br]nachdem Promon draußen war 0:23:55.050,0:23:57.620 und dann geht das. 0:23:58.420,0:24:00.620 Dann komme ich mal zum Schluss: 0:24:00.620,0:24:09.059 die Reaktionen der beteiligten Parteien[br]anschauen und ein Fazit zu schließen. Also 0:24:09.059,0:24:13.700 mit Promon stehen wir seit Ende November –[br]also gut einen Monat – in Kontakt. 0:24:13.700,0:24:18.179 Die waren sehr nett und professionell und sie[br]haben mittlerweile auch eine neue Version 0:24:18.179,0:24:22.720 des Promon SHIELDs entwickelt. Die liegt[br]mir in der Beispiel-App auch vor, aber ich 0:24:22.720,0:24:26.040 hatte noch nicht die Zeit, um da genauer[br]anzuschauen. Ich kann aber sagen unsere 0:24:26.040,0:24:29.789 Nomorp Toolchain funktioniert auf diese[br]Art und Weise nicht mehr, also 0:24:29.789,0:24:32.630 funktioniert nicht mehr wie zuvor. Ich[br]kann nicht genau sagen was wurde da jetzt 0:24:32.630,0:24:36.870 genau gemacht und welche großen[br]Anpassungen sind zu machen. Es kann sein, 0:24:36.870,0:24:40.490 dass es unglaublich viel Arbeit ist. Kann[br]aber auch sein, dass es nicht viel Arbeit ist. 0:24:40.490,0:24:45.289 Ich kann es einfach nicht sagen. [br]Der Punkt ist eigentlich, um die Angriffe 0:24:45.289,0:24:49.520 wirklich komplexer zu machen bräuchte man[br]mehr Individualisierung von den Apps. 0:24:49.520,0:24:53.330 Man kann ja alle Apps gleichartig angreifen.[br]Man kann das Promon SHIELD auf die gleiche 0:24:53.330,0:24:58.690 Art und Weise in all diesen 31 Apps[br]deaktivieren indem man diese Config 0:24:58.690,0:25:02.820 rewritet, weil es überall gleich ist, da[br]es ein universaler Ansatz ist. 0:25:02.820,0:25:08.779 Die Reaktion der Banken die ich seit[br]Jahren höre: "bis heute keine 0:25:08.779,0:25:12.800 Schadensfälle bekannt." Das ist natürlich[br]ein merkwürdiges Verständnis von 0:25:12.800,0:25:18.429 IT-Sicherheit. Wenn man sich jetzt aber [br]mal anschaut, wie eigentlich überhaupt die 0:25:18.429,0:25:22.400 Verteilung von Mobilebanking ist oder von[br]App basierten TAN Verfahren, dann sind die 0:25:22.400,0:25:27.850 einfach nicht relevant aktuell im Markt.[br]5-8% hat letztes Jahr hat eine Studie 0:25:27.850,0:25:32.850 ergeben, sind die App basierten TAN[br]Verfahren verbreitet. Dies soll sich 0:25:32.850,0:25:36.559 dieses Jahr nicht groß geändert haben.[br]Natürlich, aktuell lohnt sich das noch 0:25:36.559,0:25:40.529 nicht aber das kann sich [br]für die Zukunft ändern. 0:25:42.319,0:25:47.120 Das finde ich ein sehr schönes Zitat von[br]Jens Bender und Dennis Kügler vom BSI: 0:25:47.120,0:25:50.900 "Im Bereich des Zahlungswesens hat sich [br]eine besondere Kreativität in der Auslegung 0:25:50.900,0:25:53.640 der Eigenschaft einer[br]Zweifaktorauthentisierung entwickelt." 0:25:54.049,0:25:56.089 Gelächter 0:25:56.089,0:26:01.130 Applaus 0:26:01.130,0:26:06.059 Ja, kann ich nur zustimmen. Und jetzt wenn man[br]jetzt denkt nach Mobilebanking, also nach 0:26:06.059,0:26:10.440 zwei Apps auf einem Smartphone, wird es[br]nicht mehr schlimmer – das gibt es jetzt 0:26:10.440,0:26:19.680 mittlerweile auch auf einem Windows und[br]auf einem Mac PC. Ok, kann man machen. 0:26:21.470,0:26:27.760 Zwei Fragen ganz zum Schluss: ist App-[br]Härtung überhaupt sinnvoll? Also haben 0:26:27.760,0:26:32.480 diese ganzen Produkte, die ganzen Markt[br]angeboten werden, eine Daseinsberechtigung? 0:26:33.190,0:26:36.320 Ja, natürlich haben die eine eine [br]Daseinsberechtigung. Sie haben 0:26:36.320,0:26:40.110 schon einen sinnvollen Schutz die[br]sie da einbetten. Aber das muss ein 0:26:40.120,0:26:41.889 zusätzlicher Schutz sein. 0:26:41.889,0:26:44.539 Und die andere Frage: Ist App-Härtung[br]ein Ersatz für unabhängige 0:26:44.539,0:26:47.280 Zweifaktor-Authentifizierung? [br]Natürlich nicht! 0:26:47.280,0:26:53.580 Das habe ich gerade eben gesagt. Weil dies[br]Softwaremaßnahmen sind und die können, 0:26:53.580,0:26:56.080 wie wir in dem Beispiel gezeigt haben, 0:26:56.080,0:26:59.510 einfach nicht verhindern, dass [br]jemand das ausnutzt. 0:27:00.820,0:27:02.510 Danke 0:27:02.510,0:27:14.020 Applaus[br] 0:27:14.020,0:27:16.120 Herald: Vielen Dank Vincent für Deinen Talk 0:27:16.120,0:27:21.970 und Deinen weiteren Ausflug in die[br]Welt des Mobilebankings. Wir haben Zeit 0:27:21.970,0:27:26.850 für einige Fragen. Also wenn ihr Fragen[br]habt, reiht auch an den Mikrofonen auf. 0:27:26.850,0:27:36.279 Hier gibt es 1,3, da vorne ist 2, usw. Die[br]haben Nummern dran und dann kann Vincent 0:27:36.279,0:27:39.380 ein Paar Fragen für Euch beantworten. 0:27:47.469,0:27:49.659 Ihr könnt auch winken wenn ihr an einem steht. 0:27:50.850,0:27:53.460 Ok. An Mikrofon 3 haben wir eine Frage. 0:27:53.460,0:27:56.460 Mikrofon 3: Vielen Dank für den Talk. [br]Ganz toll! 0:27:56.460,0:28:02.080 Jetzt gibt es schon für DRM-Systeme [br]Dinge wie Widevine, die TrustZone 0:28:02.080,0:28:07.519 im Chip direkt verwenden. Hast Du bei[br]Deiner Forschung das irgendwas von gesehen? 0:28:07.550,0:28:11.140 Vincent: Das ist ein wichtiger Punkt und 0:28:11.140,0:28:15.540 ich glaube auch das TrustZone oder[br]allgemeiner Trusted Execution Environments 0:28:15.540,0:28:21.019 eine Art und Weise wäre, in der man so[br]etwas in zufriedenstellend sicherer auf 0:28:21.019,0:28:25.840 einem Gerät machen könnte. Gerade eben[br]lief der BootStomp Vortrag von den Jungs 0:28:25.840,0:28:30.950 der UCSB. Die würden mir da vielleicht[br]widersprechen. Insgesamt ist das ein 0:28:30.950,0:28:36.080 Einsatz auf den könnte das aufbauen, aber[br]das ich genau da etwas gesehen habe, kann 0:28:36.080,0:28:40.850 ich jetzt nicht behaupten. Jetzt gerade[br]die alle setzen das nicht ein. Ist 0:28:40.850,0:28:43.830 natürlich auch das Problem, dass es da[br]keine einheitliche Lösung gibt. Da gibt es 0:28:43.830,0:28:47.179 bisher ein Paar proprietäre Lösungen und[br]jeder will sich da irgendwie durchsetzen. 0:28:47.179,0:28:48.610 Aber einen einheitlichen Standard gibt es[br]nicht und von daher ist es schwierig. 0:28:48.610,0:28:55.190 Herald: Mikrofon 1 bitte.[br]Mikrofon 1: Waren die untersuchten Apps 0:28:55.190,0:29:01.640 alle schon nach der PSD2-Richtlinie[br]zugelassen? Also bezog sich darauf das 0:29:01.640,0:29:06.860 Zitat von den BSI Leuten? Die schreibt das[br]ja explizit vor Zweifaktorauthentisierung. 0:29:06.860,0:29:13.419 Vincent: Genau die PSD2 schreibt vor:[br]starke Kundenauthentifizierung. Da müsste 0:29:13.419,0:29:16.200 man jetzt weiter ausholen. Da wurden[br]gerade eben die technischen Standards 0:29:16.200,0:29:20.070 dafür verabschiedet. Gibt es noch eine[br]18-monatige Übergangsfrist, wo die Banken 0:29:20.070,0:29:24.429 Zeit haben sich da anzupassen. Aber in den[br]ganzen Werbevideos wird ganz oft davon 0:29:24.429,0:29:28.980 gesprochen – jetzt gerade von diesen[br]Drittanbietern, dass sie PSD2 kompatibel 0:29:28.980,0:29:33.029 sind. Es ist ein bisschen schwierig zu[br]sagen, was die PSD2 da genau vorschreibt. 0:29:33.029,0:29:37.169 Ich glaube so die letzte Entscheidung die[br]dazu getroffen wurde ist eher in Richtung 0:29:37.169,0:29:40.990 wir akzeptieren den status quo. Man kann[br]das meiner Meinung nach immer noch so 0:29:40.990,0:29:46.850 lesen, dass eine sichere Anzeige und eine[br]Nichtkopierbarkeit für ein Besitzelement 0:29:46.850,0:29:51.820 hat. Also von daher ist das nicht ganz[br]klar. Wenn sie jetzt die Banken fragen, 0:29:51.820,0:29:53.850 dann sagen die natürlich sind sie PSD2[br]konform. 0:29:53.850,0:30:00.750 Herald: Fragen wir den Signal Angel. Gibt[br]es Fragen aus dem Internet? 0:30:00.750,0:30:05.490 Stille[br] 0:30:05.490,0:30:09.429 Herald: Das scheint nicht der Fall zu sein.[br]Ich habe noch eine Frage an Mikrofon 2. 0:30:09.429,0:30:14.010 Mikrofon 2: Hast Du Dir aus Promon noch[br]andere Bibliotheken angesehen? 0:30:14.010,0:30:18.679 Vincent: Nein. Habe ich nicht. Das liegt[br]aber einfach auch daran, es gibt ein Paar 0:30:18.679,0:30:21.840 andere die im deutschen Markt verbreitet[br]sind, oder was heist Verbreitung? Es gibt 0:30:21.840,0:30:24.890 Vereinzelte, die das einsetzen. Die[br]Deutsche Bank setzt mittlerweile ARXAN 0:30:24.890,0:30:29.559 ein. Dann gibt es noch die ING-DiBa die[br]Kobil verwendet. Da kann ich jetzt nicht 0:30:29.559,0:30:33.750 genaueres zu sagen. Ich meine ich habe ja[br]auch nichts per se gegen Promon - kein 0:30:33.750,0:30:36.990 Problem mit denen. Aber das Problem ist[br]eher, dass sie so relevant im deutschen 0:30:36.990,0:30:40.610 Markt sind und ich irgendwie fesgestellt[br]habe, dass so gut wie jeder sie 0:30:40.610,0:30:44.389 verwendet. Deswegen hat es sich halt[br]gelohnt, das genauer anzuschauen. Wenn 0:30:44.389,0:30:48.470 jetzt jeder eine andere App-Härtungslösung[br]verwenden würde, dann hätte man einen viel 0:30:48.470,0:30:52.169 größeren Aufwand. Dann müsste man sich ja[br]alle anschauen. Und so ist es aber man 0:30:52.169,0:30:57.180 kann einmal Promon deaktivieren und das[br]geht für alle. Das ist ja eigentlich das Problem. 0:30:57.990,0:31:00.120 [br]Herald: Letzte Frage von Mikrofon 1. 0:31:00.310,0:31:04.930 Mikrofon 1: Vielen Dank für den Vortrag.[br]Eine Frage zu dem Angriffsvektior: in 0:31:04.930,0:31:10.919 diesem Fall wurde einfach die App[br]ausgetauscht und dann – sagen wir einmal – 0:31:10.919,0:31:14.649 leicht angreifbar gemacht. Wäre es[br]denkbar, vielleicht auch beim gerooteten 0:31:14.649,0:31:19.059 Phone, dass man da einfach nebendran eine[br]Application hätte, die das einfach on-the- 0:31:19.059,0:31:23.629 fly austauscht und so Applikationen[br]angreift. Hast Du das untersucht? 0:31:23.629,0:31:28.930 Vincent: Also das machen wir ja im[br]Endeffekt. Wir binden eine Komponente in 0:31:28.930,0:31:34.460 diese App ein die das macht. Ich meine in[br]dem Fall wurde das halt ersetzt, aber ich 0:31:34.460,0:31:39.050 glaube nur, dass das Ersetzen von einer[br]App ist mitunter das Einfachste, 0:31:39.050,0:31:40.050 was man machen kann.[br] 0:31:40.050,0:31:41.850 Mikrofon 1: Ich meine, wenn es nicht[br]gerootet wäre, dann wäre es nicht möglich 0:31:41.850,0:31:47.010 von einer App auf die Andere zuzugreifen[br]und das auszutauschen. Also das müsste 0:31:47.010,0:31:53.240 natürlich gerootet werden oder [br]gibt es andere Ansätze? 0:31:53.240,0:31:58.190 Vincent: Es gibt immer noch eine Unschärfe 0:31:58.190,0:32:01.899 zwischen was ist ein root-Exploit also[br]priviledge escalation und was ist ein 0:32:01.899,0:32:05.690 gerootetes Gerät. Ein gerootetes Gerät ist[br]bei mir eine bewusste Entscheidung: ich 0:32:05.690,0:32:09.870 installiere bei mir SuperSU oder Magisk.[br]Das ist bei mir eine bewusste 0:32:09.870,0:32:13.720 Entscheidung. Dafür verwende ich unter[br]Umständen priviledge escalation um das zu 0:32:13.720,0:32:18.179 Platzieren, aber ein priviledge escalation[br]an Sich, zum Beispiel DirtyCow ausnutzen 0:32:18.179,0:32:22.149 ist nicht persistent – das wird einmal[br]ausgenutzt. Spuren davon, da müssen wir 0:32:22.149,0:32:26.131 jetzt einen Forensiker fragen, aber ich[br]glaube das ist schwierig. Und das ist der 0:32:26.131,0:32:29.139 große Unterschied davon. Priviledge[br]escalation mache ich einmal, um meinen 0:32:29.139,0:32:32.990 Angriffsvektor zu platzieren und danach[br]nützen die ganzen root detections von den 0:32:32.990,0:32:36.244 Systemen gar nichts mehr: ich habe kein[br]SuperSU installiert. 0:32:37.984,0:32:41.574 Herald: Ok. Nochmal herzlichen Dank[br]Vincent Haupert. Einen großen Applaus. 0:32:41.870,0:32:49.559 Applaus 0:32:49.559,0:32:52.336 34c3 outro 0:32:52.336,0:33:11.000 Untertitel erstellt von c3subtitles.de[br]im Jahr 2018. Mach mit und hilf uns!