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:50,152 --> 00:32:52,941
*34c3 outro*