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!