1
00:00:00,429 --> 00:00:08,840
*32C3 Vorspannmusik*

2
00:00:08,840 --> 00:00:14,110
Herald: Vincent Haupert studiert in seinem
Dayjob, sozusagen, Informatik in Erlangen,

3
00:00:14,110 --> 00:00:17,220
und macht da gerade seinen Master
mit Schwerpunkt in IT-Security.

4
00:00:17,220 --> 00:00:20,680
Die Arbeit, die er uns aber
gleich vorstellen möchte,

5
00:00:20,680 --> 00:00:23,740
hat er im Rahmen seiner Tätigkeit als
wissenschaftliche Hilfskraft gemacht,

6
00:00:23,740 --> 00:00:27,830
und zwar zusammen mit seinem Kollegen
Tilo Müller. Dort hat er untersucht,

7
00:00:27,830 --> 00:00:32,029
was es denn für Sicherheitslücken
bei App-basierten TAN-Verfahren gibt,

8
00:00:32,029 --> 00:00:35,110
also im Bereich des Onlinebankings;
und die möchte er uns jetzt vorstellen.

9
00:00:35,110 --> 00:00:38,659
Einen ganz großen, herzlichen
Applaus für Vincent bitte!

10
00:00:38,659 --> 00:00:44,920
*Applaus*

11
00:00:44,920 --> 00:00:48,329
Vincent: Ja, auch herzlich willkommen
von mir, also mein Name ist, wie gesagt,

12
00:00:48,329 --> 00:00:51,059
Vincent Haupert, und ich habe
mir im vergangenen Herbst

13
00:00:51,059 --> 00:00:55,420
mit meinem Kollegen Tilo Müller mal
angeschaut, wie es denn um die Sicherheit

14
00:00:55,420 --> 00:00:58,860
von App-basierten TAN-Verfahren
im Onlinebanking bestellt ist;

15
00:00:58,860 --> 00:01:02,960
und ja, der ein oder andere hat die
Geschichte vielleicht schon mitbekommen,

16
00:01:02,960 --> 00:01:05,209
hat sie auf Heise gelesen und
so, und fragt sich vielleicht: ja,

17
00:01:05,209 --> 00:01:08,600
was kommt denn jetzt da heute? Vor
2 Wochen habe ich einen Angriff von der,

18
00:01:08,600 --> 00:01:12,140
äh, einen Angriff… *lacht*
einen Anruf von der Sparkasse bekommen

19
00:01:12,140 --> 00:01:16,380
*Gelächter*
*Applaus*

20
00:01:16,380 --> 00:01:21,030
Ja, der Herr Meier, den ich jetzt hier
einfach mal so nennen möchte,

21
00:01:21,030 --> 00:01:24,840
hat mich da gefragt, was ich denn zwischen
Weihnachten und Neujahr mache… ja.

22
00:01:24,840 --> 00:01:30,750
Zu dem Zeitpunkt, wollte er eben wissen:
muss er seine Presseabteilung jetzt schon

23
00:01:30,750 --> 00:01:33,240
auf irgendetwas Neues gefasst machen,
oder nicht. *Gelächter*

24
00:01:33,240 --> 00:01:36,479
Zu dem Zeitpunkt konnte ich es ganz
ehrlich gesagt noch nicht sagen,

25
00:01:36,479 --> 00:01:38,909
Heute kann ich ihnen sagen: ich hoffe,
sie haben einen Entwurf gemacht,

26
00:01:38,909 --> 00:01:40,839
das macht es danach leichter.

27
00:01:40,839 --> 00:01:47,080
*Gelächter*
*Applaus*

28
00:01:47,080 --> 00:01:51,430
Ja, Onlinebanking ist etwas, das
betrifft uns alle; es ist etabliert,

29
00:01:51,430 --> 00:01:56,509
eine große Zahl der Deutschen verwendet
es, und ein besonderes Merkmal

30
00:01:56,509 --> 00:02:01,920
von Onlinebanking ist, dass es schon seit
seinem Entstehen in den 1980er Jahren,

31
00:02:01,920 --> 00:02:04,880
damals noch BTX-basiert,
ein Zweifaktor-Verfahren ist.

32
00:02:04,880 --> 00:02:08,619
Also, man hatte auf der einen Seite immer
irgendwie einen Benutzernamen/Passwort,

33
00:02:08,619 --> 00:02:13,779
und dann noch irgendein TAN-Verfahren.
Über die Zeit ist da ein ganzer Zoo

34
00:02:13,779 --> 00:02:17,919
an TAN-Verfahren entstanden; meistens
gab es einfach Weiterentwicklungen,

35
00:02:17,919 --> 00:02:22,620
aus Sicherheitsgründen. Heute werden
wir ein Verfahren sehen, das sich nicht

36
00:02:22,620 --> 00:02:27,230
in diese Reihe begeben
kann. Ja. Im Prinzip läuft

37
00:02:27,230 --> 00:02:31,449
Onlinebanking immer so ab, ich sage das
der Vollständigkeit halber hier nochmal:

38
00:02:31,449 --> 00:02:35,480
man loggt sich im Onlinebanking-Portal
ein, mit seinem Benutzername/Passwort,

39
00:02:35,480 --> 00:02:39,189
reicht dann eine Überweisung ein, und im
zweiten Schritt muss man das dann noch

40
00:02:39,189 --> 00:02:44,069
mit einem TAN-Verfahren bestätigen. Das
ist nicht für jeden das gleiche; das kann

41
00:02:44,069 --> 00:02:48,370
entweder noch die altgediente iTAN-
Liste sein, die aber langsam ausstirbt;

42
00:02:48,370 --> 00:02:52,269
das SMS-TAN-Verfahren,
das auch seine Tücken hat,

43
00:02:52,269 --> 00:02:54,609
wie man in den letzten
Monaten mitbekommen kann.

44
00:02:54,609 --> 00:02:59,309
Insbesondere ein großer Verbündeter
ist die Telekom, *lacht*

45
00:02:59,309 --> 00:03:02,919
und es gibt dann auch noch das
chipTAN-Verfahren, das auch recht

46
00:03:02,919 --> 00:03:06,719
verbreitet ist. Das letzte Verfahren,
das chipTAN-Verfahren, adressiert

47
00:03:06,719 --> 00:03:11,029
das Sicherheitsproblem im Onlinebanking
eigentlich schon ganz gut, aber,

48
00:03:11,029 --> 00:03:13,859
wenn man den Kreditinstituten glaubt,
gibt es einen dringenden Wunsch

49
00:03:13,859 --> 00:03:17,290
in der deutschen Bevölkerung,
seine Geldgeschäfte immer überall

50
00:03:17,290 --> 00:03:21,059
machen zu können. Sei das in der U-Bahn,
im Restaurant, vielleicht auch hier,

51
00:03:21,059 --> 00:03:24,089
gerade in diesem Vortrag. Macht jemand
gerade eine Überweisung, mal Hand hoch?

52
00:03:24,089 --> 00:03:26,870
*Gelächter*
Ja.

53
00:03:26,870 --> 00:03:32,180
Auf jeden Fall ist es dann so, wenn man
eine Überweisung überall machen will,

54
00:03:32,180 --> 00:03:35,370
*sarkastisch:* dann will ich kein zweites
Gerät haben, denn das ist ja unbequem.

55
00:03:35,370 --> 00:03:40,019
Deswegen haben die Banken ein
Gerät entdeckt, das jeder von uns

56
00:03:40,019 --> 00:03:43,989
immer dabei hat, und das absolut
sicher ist – das Smartphone.

57
00:03:43,989 --> 00:03:49,900
*Gelächter*
*Applaus*

58
00:03:49,900 --> 00:03:56,169
Man hat jetzt keine zwei Geräte mehr,
nicht 2 voneinander unabhängigen Faktoren,

59
00:03:56,169 --> 00:03:58,829
man hat eine Banking-App,
und man hat eine TAN-App.

60
00:03:58,829 --> 00:04:02,959
Das funktioniert jetzt so: ich logge
mich mit meiner Banking-App

61
00:04:02,959 --> 00:04:06,889
auf dem Smartphone ein und gebe eine
Überweisung auf. Im zweiten Schritt

62
00:04:06,889 --> 00:04:11,279
muss ich dann wie gehabt die
Überweisung mit einer TAN bestätigen.

63
00:04:11,279 --> 00:04:15,819
Jetzt nehme ich aber nicht meinen
Papierzettel her, mein chipTAN-Gerät,

64
00:04:15,819 --> 00:04:21,310
sondern ich wechsle
zur TAN-App. Da gibt’s,

65
00:04:21,310 --> 00:04:24,449
also da sind alle Banken mittlerweile ein
großer Fan davon eigentlich, das ist jetzt

66
00:04:24,449 --> 00:04:28,050
nur eine Auswahl, ich weiß nicht ob es
noch mehr gibt, aber all diese Banken

67
00:04:28,050 --> 00:04:31,560
haben ein App-basiertes TAN-
Verfahren im Angebot, und ich denke,

68
00:04:31,560 --> 00:04:35,939
die die es noch nicht haben, sind bestimmt
auf dem Weg dahin, das zu machen.

69
00:04:35,939 --> 00:04:40,139
Ich sehe jetzt schon den einen oder
anderen hier in den ersten Reihen,

70
00:04:40,139 --> 00:04:42,979
bei denen sich dann die Stirn
runzelt bei dem Verfahren,

71
00:04:42,979 --> 00:04:47,319
ich will aber trotzdem nochmal generell
das Angriffs-Szenario motivieren.

72
00:04:47,319 --> 00:04:52,319
Also, Malware, oder Schadsoftware,
ist in den offiziellen App Stores

73
00:04:52,319 --> 00:04:55,250
der Betriebssystemhersteller.
Das ist keine Fiktion!

74
00:04:55,250 --> 00:05:02,270
Bei uns am Lehrstuhl in Erlangen
hat der Dominik Maier gezeigt,

75
00:05:02,270 --> 00:05:05,180
dass sich der Google Play Store

76
00:05:05,180 --> 00:05:10,020
nicht ausreichend gegen Schadsoftware
schützen kann. Also, die konkrete Aufgabe

77
00:05:10,020 --> 00:05:12,990
von ihm war eigentlich,
in seiner Bachelorarbeit,

78
00:05:12,990 --> 00:05:18,639
Schadsoftware in den Google
Play Store zu bekommen. Nur:

79
00:05:18,639 --> 00:05:21,900
das war seine Bachelorarbeit… da ist er
nach ein paar Tagen zu seinem Betreuer

80
00:05:21,900 --> 00:05:25,370
dann hingekommen und hat gesagt:
„Ey Tilo, ich bin fertig!“

81
00:05:25,370 --> 00:05:32,740
*Gelächter*
*Applaus*

82
00:05:32,740 --> 00:05:38,530
*amüsiert:* Und, was er gemacht hat:
er hat einen Root-Exploit gezippt, ja…

83
00:05:38,530 --> 00:05:39,979
*Gelächter*

84
00:05:39,979 --> 00:05:42,960
Also, er hat ihn gezippt und hochgeladen;
da war kein Passwort, nichts –

85
00:05:42,960 --> 00:05:44,730
er hat ihn einfach gezippt.

86
00:05:44,730 --> 00:05:49,069
Dass das aber nicht irgendwie nur
akademische, graue Theorie ist,

87
00:05:49,069 --> 00:05:53,039
hat dieses Jahr so ziemlich gleichzeitig,
als wir diese App-TAN-Geschichte

88
00:05:53,039 --> 00:05:57,659
gemacht haben, die App „Brain Test“
gezeigt. Das ist ein Spiel, und

89
00:05:57,659 --> 00:06:02,180
das hat über 100.000 Downloads
gehabt, bis zu 500.000.

90
00:06:02,180 --> 00:06:05,870
Und diese App hat genau das
gemacht, was das Angriffsszenario

91
00:06:05,870 --> 00:06:09,590
auch für App-basierte TAN-Verfahren
ist. Nämlich: im offiziellen Store,

92
00:06:09,590 --> 00:06:13,810
rootet das Gerät zuerst und
lädt dann Schadcode nach.

93
00:06:13,810 --> 00:06:19,550
Wir hätten jetzt auch irgendeins von
den Kreditinstituten, die App-basiertes

94
00:06:19,550 --> 00:06:23,689
TAN-Verfahren anbieten, nehmen können;
ich habe die Sparkasse genommen,

95
00:06:23,689 --> 00:06:25,819
weil ich da a) ein Konto habe und
b) weil’s irgendwie die größte ist.

96
00:06:25,819 --> 00:06:28,629
Und das waren auch die Ersten,
die das angeboten haben.

97
00:06:28,629 --> 00:06:32,520
Deswegen haben wir uns angeguckt:
was kann man denn jetzt da machen?

98
00:06:32,520 --> 00:06:35,440
Was gibt es denn da für
Angriffsszenarien für pushTAN?

99
00:06:35,440 --> 00:06:39,569
Und was uns da als allererstes
ziemlich schnell eingefallen ist,

100
00:06:39,569 --> 00:06:43,479
ist: wir könnten die App
irgendwie kopieren,

101
00:06:43,479 --> 00:06:46,620
oder wir reversen das Protokoll und
implementieren unseren eigenen Client.

102
00:06:46,620 --> 00:06:49,810
Das sind aber beides noch Angriffe,
die konzentrieren sich sehr stark

103
00:06:49,810 --> 00:06:54,810
einfach nur auf die TAN-App.
Das eigentliche Problem

104
00:06:54,810 --> 00:06:57,590
von App-basierten TAN-Verfahren,
also dass man den ersten Faktor

105
00:06:57,590 --> 00:07:01,370
und den zweiten Faktor auf einem Gerät
hat, wird aber am besten dadurch betont,

106
00:07:01,370 --> 00:07:06,389
wenn man eine Transaktionsmanipulation
durchführt. Sprich: wir manipulieren eine

107
00:07:06,389 --> 00:07:12,309
vom Nutzer aufgegebene Transaktion
in Echtzeit, ohne dass er’s sehen kann.

108
00:07:12,309 --> 00:07:15,340
Wie haben wir das gemacht, oder
wie war unser Szenario dafür?

109
00:07:15,340 --> 00:07:19,110
Nochmal: wie läuft das ab?
Links ist die Sparkassen-App,

110
00:07:19,110 --> 00:07:22,029
die verwende ich, um mich in meinem
Onlinebanking einzuloggen und dann

111
00:07:22,029 --> 00:07:26,469
meine Überweisungsdaten auszufüllen,
und schicke das dann letztendlich ab.

112
00:07:26,469 --> 00:07:31,120
Dann landet das Ganze beim Sparkassen-
Server, und der schickt dann eine TAN

113
00:07:31,120 --> 00:07:35,259
an die pushTAN-App, die da rechts
dargestellt ist. Der Nutzer wird dann

114
00:07:35,259 --> 00:07:39,580
dazu aufgefordert, in die pushTAN-App
zu wechseln, die dort dargestellte TAN

115
00:07:39,580 --> 00:07:43,529
– nachdem er die Überweisungsdaten
natürlich kontrolliert hat – in die App

116
00:07:43,529 --> 00:07:46,379
„Sparkasse“ zu übertragen. Das geht
mittlerweile, wie wir später sehen werden,

117
00:07:46,379 --> 00:07:50,900
auch so automatisiert, dass man sich
fragt: warum gibt’s überhaupt noch 2 Apps?

118
00:07:50,900 --> 00:07:57,080
Ja, gut. Was wir jetzt
machen: wir sagen einfach,

119
00:07:57,080 --> 00:08:02,539
nachdem der Nutzer auf
‚Auftrag übermitteln‘ geht,

120
00:08:02,539 --> 00:08:06,360
dann manipulieren wir die Daten.
Also wir ändern den Adressaten,

121
00:08:06,360 --> 00:08:10,900
wir ändern den Betrag, und die
Sparkasse schickt dann natürlich

122
00:08:10,900 --> 00:08:14,340
die Überweisungsdetails auch nochmal
an die TAN-App, und die werden dann

123
00:08:14,340 --> 00:08:17,309
da nochmal dargestellt. Das heißt,
bevor die dann da angezeigt werden,

124
00:08:17,309 --> 00:08:19,409
manipulieren wir die wieder
auf die originalen Daten,

125
00:08:19,409 --> 00:08:24,300
und der Nutzer kann’s nicht sehen, und
bestätigt letztendlich eine Überweisung

126
00:08:24,300 --> 00:08:29,479
mit einer TAN, was er gar nicht wollte.
Ja, da mussten wir erstmal überlegen:

127
00:08:29,479 --> 00:08:32,219
was gibt es denn da eigentlich so für
Sicherheitsmerkmale bei den beiden Apps?

128
00:08:32,219 --> 00:08:35,260
Also die Sparkassen-App selbst
ist eigentlich ein leichtes Fressen

129
00:08:35,260 --> 00:08:38,769
für so einen Angriff; die hat ja
keine großen Schutzmaßnahmen.

130
00:08:38,769 --> 00:08:42,909
Es gibt eine Root-Erkennung, es wird aber
lediglich dargestellt ein Warnhinweis,

131
00:08:42,909 --> 00:08:45,579
und die macht also ansonsten nichts, man
kann die App dann normal weiterverwenden.

132
00:08:45,579 --> 00:08:51,709
Auf der anderen Seite: die pushTAN-App
versucht, sich mit einer Vielzahl

133
00:08:51,709 --> 00:08:57,300
an Maßnahmen gegen Analyse und gegen
Schadsoftware angeblich auch zu schützen.

134
00:08:57,300 --> 00:09:00,160
Man merkt eigentlich schon, wenn man
hier sieht, die ganzen Maßnahmen,

135
00:09:00,160 --> 00:09:02,139
ich glaube, die Sparkasse ist sich selber
nicht so ganz sicher, dass das wirklich

136
00:09:02,139 --> 00:09:05,449
sicher zu kriegen ist. Die haben
halt eine Root-Erkennung,

137
00:09:05,449 --> 00:09:10,339
die ist nicht wie bei der Sparkassen-App,
dass da ein Warnhinweis angezeigt wird;

138
00:09:10,339 --> 00:09:13,579
also es wird verboten: wenn ein Root
erkannt wird, beendet sich die App,

139
00:09:13,579 --> 00:09:16,220
und schützt sich eben auch gegen
die dynamische Analyse, statische Analyse,

140
00:09:16,220 --> 00:09:22,179
weiß der Teufel nicht, was alles.
Und: es ist TÜV-geprüft!

141
00:09:22,179 --> 00:09:29,650
*Gelächter*
*Applaus*

142
00:09:29,650 --> 00:09:32,100
Von diesem Prädikat
merklich eingeschüchtert,

143
00:09:32,100 --> 00:09:37,089
habe ich mir dann mal angeguckt, ja
– was gibt es denn da eigentlich wirklich

144
00:09:37,089 --> 00:09:40,810
für Schutzmaßnahmen, wie sind denn die
umgesetzt? Es wurde recht schnell klar:

145
00:09:40,810 --> 00:09:43,800
die Sparkasse selbst traut sich in Sachen
Sicherheit nicht so viel zu und hat

146
00:09:43,800 --> 00:09:48,670
deswegen beim norwegischen Hersteller
Promon eingekauft. Die selber haben

147
00:09:48,670 --> 00:09:52,880
eine Native-Library, die wird gleich
am Anfang der App geladen,

148
00:09:52,880 --> 00:09:56,500
und ist dann quasi der Einsprungspunkt.

149
00:09:56,500 --> 00:10:01,910
Die Library selbst ist verschlüsselt,
zum Teil, mit einem statischen Key

150
00:10:01,910 --> 00:10:04,630
natürlich irgendwie, und ist obfuskiert,
ist also ein ziemlicher Hass, sich die

151
00:10:04,630 --> 00:10:08,279
anzuschauen. Aber es gibt

152
00:10:08,279 --> 00:10:11,690
– also damit man die Library nicht einfach
heraus patcht, also sagt: „Ja gut, dann

153
00:10:11,690 --> 00:10:16,790
mach’ ich das Ding halt raus“ –
haben die Strings aus der Java-Logik

154
00:10:16,790 --> 00:10:20,050
in die Library verlagert, die ja
wiederum verschlüsselt ist.

155
00:10:20,050 --> 00:10:24,100
Die Library selbst setzt dann
statische, finale Felder

156
00:10:24,100 --> 00:10:27,800
während der Laufzeit mit diesen Strings
und werden dann halt normal verwendet.

157
00:10:27,800 --> 00:10:31,579
Oder sie werden über einen Index
abgerufen, mit der Methode getString.

158
00:10:31,579 --> 00:10:35,230
Also das verhindert… also macht’s
zumindest Aufwand, diese Library

159
00:10:35,230 --> 00:10:38,170
einfach rauszuziehen und
ohne die dann klarzukommen.

160
00:10:38,170 --> 00:10:43,649
Ja die erkennt, wie gesagt,
Root, Debugger, alles Mögliche.

161
00:10:43,649 --> 00:10:47,220
Aber die behandelt die Erkennung nicht.

162
00:10:47,220 --> 00:10:51,980
Das liegt einfach daran, die wollen
eine Library verkaufen, die soll

163
00:10:51,980 --> 00:10:57,320
für alles und jeden gehen, ne? Also die
ist nicht personalisiert auf diese App.

164
00:10:57,320 --> 00:11:03,220
So ist es dann implementiert. Stattdessen
gibt’s im Java-Code callbacks

165
00:11:03,220 --> 00:11:07,250
für die verschiedenen einzelnen events.
Also z.B. Debugger, oder eben Root.

166
00:11:07,250 --> 00:11:11,320
Die App selbst implementiert
dann eben dieses Interface und,

167
00:11:11,320 --> 00:11:14,899
wenn das erkannt wird, dann
wird der Code aufgerufen.

168
00:11:14,899 --> 00:11:18,949
Z.B. hier unten ist dargestellt,
der Rooting-Status. Da steht

169
00:11:18,949 --> 00:11:22,980
in dem Parameter z dann eben drin,
ob es gerootet wurde oder nicht.

170
00:11:22,980 --> 00:11:26,620
Und dann kommt da so’n Texthinweis,
und danach beendet sich die App.

171
00:11:26,620 --> 00:11:29,920
Ja, was haben wir gemacht:
Wenn dieses event kommt,

172
00:11:29,920 --> 00:11:33,769
dann brechen wir die Methode immer ab
und dann läuft die App einfach weiter.

173
00:11:33,769 --> 00:11:38,910
Das Ganze ist besonders paradox, diese
Library scheint keinen Status zu haben.

174
00:11:38,910 --> 00:11:43,649
Die liefert einfach weiter Strings aus,
obwohl schon Root detected wurde.

175
00:11:43,649 --> 00:11:47,940
Das hat mich wirklich überrascht,
dass es so einfach war. *lacht*

176
00:11:47,940 --> 00:11:52,790
*Applaus*

177
00:11:52,790 --> 00:11:57,130
Ja, dann schauen wir uns mal an, wie
funktioniert denn das jetzt konkret.

178
00:11:57,130 --> 00:12:02,069
Also hier, als allererstes, die
Sparkassen-App. Das sieht man jetzt,

179
00:12:02,069 --> 00:12:05,449
wie man sich eben anmeldet. Mit seinem
Passwort, das man mal selbst vergeben hat.

180
00:12:05,449 --> 00:12:09,509
Und es wird ja auch ein Hinweis angezeigt
dass das Gerät gerootet ist, aber

181
00:12:09,509 --> 00:12:12,699
wie gesagt, es hat weiter keine
Konsequenzen. In dem Fall habe ich

182
00:12:12,699 --> 00:12:17,089
dann eine Überweisung an das Finanzamt mit
meiner hohen Einkommenssteuer von 10 Cent

183
00:12:17,089 --> 00:12:21,519
ausgelöst. Und im nächsten Schritt… also…

184
00:12:21,519 --> 00:12:24,199
dann haben wir die Überweisung eben
manipuliert, die Daten im Hintergrund,

185
00:12:24,199 --> 00:12:27,779
man sieht es nicht. Und hier wird man dann
dazu aufgefordert, in die pushTAN-App

186
00:12:27,779 --> 00:12:31,480
zu wechseln, um dann
dort die TAN abzurufen.

187
00:12:31,480 --> 00:12:35,480
Das machen wir auch, loggen uns
wieder mit unserem Passwort,

188
00:12:35,480 --> 00:12:39,050
diesmal in der pushTAN-App ein.
Wie groß die Wahrscheinlichkeit ist,

189
00:12:39,050 --> 00:12:41,690
dass das das gleiche Passwort
ist, können wir uns denken.

190
00:12:41,690 --> 00:12:46,399
Und dann schauen wir uns die
Überweisungsdetails an. 10 Cent…

191
00:12:46,399 --> 00:12:48,860
sagen wir jetzt einfach mal die IBAN hat
sich jetzt wahrscheinlich keiner gemerkt,

192
00:12:48,860 --> 00:12:52,690
aber das ist auch die gleiche.
Und ja, schaut gut aus.

193
00:12:52,690 --> 00:12:57,230
Das geben wir frei. TAN übertragen an
Sparkasse. Jetzt merken wir uns noch

194
00:12:57,230 --> 00:12:59,670
die letzten 2 Stellen der TAN, das ist 32,

195
00:12:59,670 --> 00:13:03,829
dann übertragen wir die und der Auftrag
wird freigegeben in der Sparkassen-App.

196
00:13:03,829 --> 00:13:08,190
Wenn man dann später irgendwann mal
in die Umsatz-Details reinschaut, dann

197
00:13:08,190 --> 00:13:12,060
stellt man fest: „Hey, da, mit
der TAN mit der Endstelle 32,

198
00:13:12,060 --> 00:13:15,470
da wurde ein Betrag von 13,37 Euro
überwiesen, nicht von 10 Cent. Und

199
00:13:15,470 --> 00:13:18,990
die gingen auch nicht ans Finanzamt,
die gingen an Vincent Haupert. Gut…

200
00:13:18,990 --> 00:13:24,100
Jetzt… jeder der die Geschichte kennt,
der kennt auch was danach kam.

201
00:13:24,100 --> 00:13:27,050
Stellungnahme der Sparkasse,
nachdem es auf Heise war: „Ey,

202
00:13:27,050 --> 00:13:31,880
das ist ja ’ne alte Version, das
geht doch alles gar nicht mehr“.

203
00:13:31,880 --> 00:13:34,339
Es gibt da jetzt ’ne neue Version
seit dem 16.10. Wir haben

204
00:13:34,339 --> 00:13:39,779
am 23.Oktober veröffentlicht.
Das ist jetzt nicht mehr möglich.

205
00:13:39,779 --> 00:13:43,730
Gut. Eigentlich ist es nichts Neues für
uns. Haben wir auch schon gesagt

206
00:13:43,730 --> 00:13:45,759
in unserer Ausarbeitung. Die
hat die Sparkasse anscheinend

207
00:13:45,759 --> 00:13:49,980
nicht so aufmerksam gelesen. Und wir
haben damals auch schon gesagt:

208
00:13:49,980 --> 00:13:54,500
„Es gibt in der aktuellen Version
wohl… die Art und Weise,

209
00:13:54,500 --> 00:13:57,449
wie wir den Angriff gemacht haben… in der
neuen Version funktioniert das anders,

210
00:13:57,449 --> 00:14:00,360
wir können das nicht ganz genauso machen;
mit einem entsprechenden Mehraufwand

211
00:14:00,360 --> 00:14:03,230
können wir den Angriff aber
wieder möglich machen.“

212
00:14:03,230 --> 00:14:08,920
Ja, schau’n wir halt mal! *lacht*
*Gelächter*

213
00:14:08,920 --> 00:14:14,240
*Applaus*

214
00:14:14,240 --> 00:14:18,100
Um jetzt einen Angriff gegen die
neue Version machen zu wollen,

215
00:14:18,100 --> 00:14:20,730
muss man sich fragen: Was ist
denn da eigentlich anders jetzt?

216
00:14:20,730 --> 00:14:24,970
Also man hat auch bei der Sparkasse
oder bei Promon realisiert, dass

217
00:14:24,970 --> 00:14:28,220
die Java-callbacks ungefähr genauso sind,
wie wenn man mit einem Geldtransporter

218
00:14:28,220 --> 00:14:32,769
vor die Sparkasse fährt, und dann
dem Praktikanten die Geldsäcke

219
00:14:32,769 --> 00:14:36,899
in die Hand drückt und einfach
wegfährt. Deswegen gibt es jetzt

220
00:14:36,899 --> 00:14:41,060
keine Java-callbacks mehr.
Stattdessen stürzt die App ab,

221
00:14:41,060 --> 00:14:45,579
wenn sie z.B. Root erkennt, oder
auch Debugger, was auch immer,

222
00:14:45,579 --> 00:14:48,699
und öffnet dann eine Seite im Browser.
Dadurch lässt sich die Root-Erkennung

223
00:14:48,699 --> 00:14:51,310
nicht mehr trivial umgehen. Ansonsten

224
00:14:51,310 --> 00:14:55,959
werden auch hooking-Frameworks
erkannt. Also wir haben den Angriff

225
00:14:55,959 --> 00:15:00,250
als proof-of-concept mit Xposed
realisiert. D.h. das würde jetzt

226
00:15:00,250 --> 00:15:02,560
auch nicht mehr gehen. Ja, schlecht.

227
00:15:02,560 --> 00:15:07,649
Gut, um den Angriff jetzt wieder
realisieren zu können, müssen wir also

228
00:15:07,649 --> 00:15:10,739
2 Sachen machen. Wir müssen einmal die
Root-Erkennung umgehen und einmal

229
00:15:10,739 --> 00:15:12,520
die Xposed-Erkennung umgehen.

230
00:15:12,520 --> 00:15:16,019
Fangen wir mit Root an. Wie
funktioniert die Root-Erkennung?

231
00:15:16,019 --> 00:15:19,990
Und ich bin bisher eigentlich gut bei den
Sicherheits-features dieser App gefahren,

232
00:15:19,990 --> 00:15:24,389
mir einfach vorzustellen, wie würde ich es
machen. Also was ist der einfachste Weg

233
00:15:24,389 --> 00:15:28,819
Root zu erkennen. Also: was werden die
wohl machen? Die suchen im Dateisystem

234
00:15:28,819 --> 00:15:32,350
nach irgendwelchen Sachen, die für SU
charakteristisch sind. Dann habe ich mir

235
00:15:32,350 --> 00:15:36,019
die Syscalls mal angeschaut – ja und klar,
genau das machen die. *lacht*

236
00:15:36,019 --> 00:15:40,529
Die schauen einfach z.B.
ist /system/bin/su vorhanden?

237
00:15:40,529 --> 00:15:45,139
Oder /system/xbin/su? Ja, wenn
ich das jetzt in /vinc umbenenne,

238
00:15:45,139 --> 00:15:49,020
dann geht sie, die App, schon wieder.

239
00:15:49,020 --> 00:15:55,370
*Applaus*

240
00:15:55,370 --> 00:15:58,879
Das ist aber natürlich blöd, weil ich will
ja weiterhin für meine anderen Apps

241
00:15:58,879 --> 00:16:02,120
eigentlich Root haben. Und
deswegen, wenn ich die umbenenne,

242
00:16:02,120 --> 00:16:06,139
dann können die natürlich auch kein
SU mehr ausführen. Das Lustige ist ja,

243
00:16:06,139 --> 00:16:11,439
man führt ja nicht /system/xbin/su aus,
sondern man gibt ja nur SU ein. Das Ganze

244
00:16:11,439 --> 00:16:17,060
ist der PATH-Variable zu verdanken,
die in Oslo aber nicht bekannt ist.

245
00:16:17,060 --> 00:16:21,790
Deswegen ich hab das Ganze auf
Android Marshmallow gemacht,

246
00:16:21,790 --> 00:16:24,519
und da will man eigentlich
sowieso Systemless SU haben.

247
00:16:24,519 --> 00:16:27,860
Und das mounted eine eigene Partition
und trägt sich in die PATH-Variable ein

248
00:16:27,860 --> 00:16:32,139
– und tadaaa! – die pushTAN-App
geht wieder auf.

249
00:16:32,139 --> 00:16:36,870
*Applaus*

250
00:16:36,870 --> 00:16:40,910
Ein bisschen paradoxer wird es aber
immer noch vor dem Hintergrund,

251
00:16:40,910 --> 00:16:43,910
dass es die Sparkassen-App besser
macht. Die erkennt das Root nämlich.

252
00:16:43,910 --> 00:16:47,829
Und die haben keine Lösung für
was-weiß-ich wieviel Tausend eingekauft.

253
00:16:47,829 --> 00:16:50,689
Also bei Promon würde ich jetzt
mal in den Flugmodus gehen,

254
00:16:50,689 --> 00:16:54,470
sonst kommt da gleich ein Anruf.

255
00:16:54,470 --> 00:16:57,709
Ja, als nächstes: wie funktioniert
die Xposed-Erkennung?

256
00:16:57,709 --> 00:17:02,819
Ja, wieder gleiches Spiel, würde
ich sagen. Schauen wir doch mal,

257
00:17:02,819 --> 00:17:05,210
was… die werden wieder nach irgendwelchen
charakteristischen Sachen

258
00:17:05,210 --> 00:17:09,910
für Xposed suchen. Ja, so schaut es dann
aus: Das sind halt ein paar Sachen,

259
00:17:09,910 --> 00:17:12,160
die Xposed platziert beim Installieren.

260
00:17:12,160 --> 00:17:17,869
Das müssen wir jetzt irgendwie loswerden.
Und Xposed muss danach aber noch gehen.

261
00:17:17,869 --> 00:17:20,880
Die ersten 4 Sachen sind irgendwie eh
Sachen, die kann man entweder löschen

262
00:17:20,880 --> 00:17:24,440
oder umbenennen. Und dann
sind die schon mal weg.

263
00:17:24,440 --> 00:17:28,520
Dann gibt’s hier die anderen 3 Dateien,
die braucht man schon irgendwie;

264
00:17:28,520 --> 00:17:33,020
ja, die benennen wir halt um. Und

265
00:17:33,020 --> 00:17:35,530
untereinander müssen die Abhängigkeiten
natürlich auch angepasst werden.

266
00:17:35,530 --> 00:17:37,950
Und da hab’ ich gedacht: „Ja, jetzt
geht’s“. Es hätte mich nicht überrascht

267
00:17:37,950 --> 00:17:41,330
wenn’s funktioniert. Reicht aber
noch nicht ganz. Das ist sogar

268
00:17:41,330 --> 00:17:44,870
tatsächlich ein bisschen besser
gemacht. Die schauen halt selber

269
00:17:44,870 --> 00:17:47,870
in dem executable file nach,
wo auch die ganze Dalvik-VM

270
00:17:47,870 --> 00:17:51,560
und was-weiß-ich-was drin ist, und
Zygote, mit dem ja Xposed arbeitet;

271
00:17:51,560 --> 00:17:55,290
und wenn dann da drinnen Xposed
mit großem oder kleinem X drinsteht,

272
00:17:55,290 --> 00:17:59,000
dann ist wohl Xposed installiert. Ja,
letztendlich hab’ ich das Ding einfach

273
00:17:59,000 --> 00:18:02,000
neu kompiliert und schon ging’s wieder.

274
00:18:02,000 --> 00:18:09,040
*Applaus*

275
00:18:09,040 --> 00:18:13,130
Dann schauen wir uns das doch mal an, ne?

276
00:18:13,130 --> 00:18:15,520
Also wieder gleiches Spiel…

277
00:18:15,520 --> 00:18:19,620
Wir öffnen die Sparkassen-App,
geben da unser Passwort ein…

278
00:18:19,620 --> 00:18:25,030
Diesmal, um ganz auf Nummer sicher zu
gehen, schauen wir uns vorher nochmal an,

279
00:18:25,030 --> 00:18:27,690
welche Version ist denn das, eigentlich?
Nicht dass dann danach irgendeiner sagt:

280
00:18:27,690 --> 00:18:30,710
„Es war nicht die aktuelle Version“.
Also hier sehen wir, das ist die Version

281
00:18:30,710 --> 00:18:35,520
vom 7.Dezember, also das war
die aktuellste bis vor 2 Stunden.

282
00:18:35,520 --> 00:18:38,520
*Gelächter, Applaus*

283
00:18:38,520 --> 00:18:42,160
Als nächstes füllen wir wieder
unsere Überweisung aus,

284
00:18:42,160 --> 00:18:44,940
diesmal nicht ans Finanzamt,
sondern an die Uni-Bibliothek Erlangen.

285
00:18:44,940 --> 00:18:49,930
Ich habe nämlich meine Benutzerkarte
verloren und brauche deshalb eine neue,

286
00:18:49,930 --> 00:18:53,820
und die kommt nicht for free,
sondern kostet 3 Euro.

287
00:18:53,820 --> 00:18:57,060
Ihr seht schon, mein Konto war
nicht so hoch gefüllt, ich musste

288
00:18:57,060 --> 00:19:01,040
einen Betrag wählen, der irgendwie
auch noch in meinem Limit geht.

289
00:19:01,040 --> 00:19:03,560
Aber jetzt öffnet sich hier
automatisch schon die pushTAN-App,

290
00:19:03,560 --> 00:19:08,040
also die Integration hat
tollerweise zugenommen.

291
00:19:08,040 --> 00:19:11,810
Jetzt logg’ ich mich da auch wieder
ein. Und hier sehen wir – 3 Euro.

292
00:19:11,810 --> 00:19:16,190
Aber genau – diesmal schauen wir uns auch
mal wieder die Version[snummer] an. Das ist

293
00:19:16,190 --> 00:19:16,240
auch

294
00:19:16,240 --> 00:19:19,500
vom 7.Dezember, war bis vor 2 Stunden
auch noch die aktuellste, könnte mir gut

295
00:19:19,500 --> 00:19:22,520
vorstellen, dass gerade eine
neue Version rauskommt!

296
00:19:22,520 --> 00:19:24,610
*Gelächter*

297
00:19:24,610 --> 00:19:29,300
Aber ja, hier. Die Daten scheinen zu
stimmen, die TAN passt eigentlich auch.

298
00:19:29,300 --> 00:19:32,280
Und dann ja, würde ich sagen, dann
kann man das bestätigen jetzt.

299
00:19:32,280 --> 00:19:42,160
Kommen wir zurück… Auftrag
wurde entgegengenommen…

300
00:19:42,160 --> 00:19:47,670
und wenn man jetzt dann mal in
die Überweisungsdetails schaut,

301
00:19:47,670 --> 00:19:50,170
sieht man da, dass ich schon ein
paar fingierte Weihnachtsgeschenke

302
00:19:50,170 --> 00:19:54,150
bezahlt habe, im Rahmen der Untersuchung
hier. Und hier haben wir diesmal

303
00:19:54,150 --> 00:19:58,810
4,20 Euro, ich hätte auch 42 Euro genommen,
wenn ich soviel Geld noch gehabt hätte. Aber…

304
00:19:58,810 --> 00:20:13,710
*Applaus*

305
00:20:13,710 --> 00:20:18,190
Ja, genau. Und ja, der Betreff
hat sich auch geändert:

306
00:20:18,190 --> 00:20:21,210
„Einen Guten Rutsch für den 32C3.“

307
00:20:21,210 --> 00:20:23,100
Okay,

308
00:20:23,100 --> 00:20:27,310
jetzt bin ich doch ein bisschen schneller
fertiggeworden als ich gedacht habe,

309
00:20:27,310 --> 00:20:30,940
aber das bedeutet, dass wir dann
noch mehr Zeit für Fragen haben.

310
00:20:30,940 --> 00:20:34,510
Ja, was lässt sich zu App-basierten
TAN-Verfahren allgemein sagen:

311
00:20:34,510 --> 00:20:38,510
Die sind einfach konzeptionell schwach.
Die Schutzmechanismen von der pushTAN-App

312
00:20:38,510 --> 00:20:41,730
haben zwar zugenommen in der
aktuellen Version. Also die Callbacks

313
00:20:41,730 --> 00:20:45,680
lassen sich jetzt nicht mehr
trivial hooken; und dadurch

314
00:20:45,680 --> 00:20:47,750
kann man einfach Root bekommen
oder halt eben einfach alles machen.

315
00:20:47,750 --> 00:20:50,880
Letztendlich ist es halt ein
Katz-und-Maus-Spiel, das die Sparkasse

316
00:20:50,880 --> 00:20:53,460
oder auch jeder andere Hersteller
am Ende irgendwie verlieren wird.

317
00:20:53,460 --> 00:21:00,070
Die Root-Erkennung z.B. bringt eigentlich
hauptsächlich Ärger bei den Kunden ein;

318
00:21:00,070 --> 00:21:04,010
und vor allem hat die so hohe
False-Positives, dass die Bewertungen

319
00:21:04,010 --> 00:21:07,990
derart grottig sind, dass man sich bei
der Sparkasse echt fragen muss,

320
00:21:07,990 --> 00:21:10,500
ob das Verfahren für sie selber
auch überhaupt noch Sinn macht.

321
00:21:10,500 --> 00:21:11,800
Wenn man sich jetzt auch anschaut…

322
00:21:11,800 --> 00:21:15,540
Was ich eigentlich gemacht habe ist ja
total irre irgendwie. Also ich meine…

323
00:21:15,540 --> 00:21:19,900
Ich habe hauptsächlich Dinge umgangen,
die ein normaler Nutzer macht.

324
00:21:19,900 --> 00:21:24,990
Ich habe keinen echten Angriff damit
verhindert. Also jemand, der selbstständig

325
00:21:24,990 --> 00:21:28,100
sein Gerät rooten wird, dem wird verboten,
die pushTAN-App zu verwenden.

326
00:21:28,100 --> 00:21:32,500
Und wer selbstständig irgendwie Xposed
installiert, dem wird es auch verboten.

327
00:21:32,500 --> 00:21:37,490
Ein echter Angriff… der installiert doch
nicht das SU Binary. *lacht*

328
00:21:37,490 --> 00:21:40,760
Der würde was-weiß-ich
irgendwas platzieren,

329
00:21:40,760 --> 00:21:43,460
aber bestimmt nicht das SU-Binary
installieren. Also das Root

330
00:21:43,460 --> 00:21:46,720
ist gar nicht mal eine feste
Voraussetzung. Für den Angriff allein

331
00:21:46,720 --> 00:21:49,490
hätte es sogar gereicht, wenn
man einen Root-Exploit hat

332
00:21:49,490 --> 00:21:50,880
und dann Xposed platzieren kann.

333
00:21:50,880 --> 00:21:54,700
Da hat man z.B. auch keinen
Ärger mit der Root-Erkennung.

334
00:21:54,700 --> 00:21:57,620
Ja, ich hab’ noch ein paar Backup-Folien,
aber das können wir dann auch

335
00:21:57,620 --> 00:22:01,630
in die Diskussion einbauen. Dann bedanke
ich mich für eure Aufmerksamkeit!

336
00:22:01,630 --> 00:22:10,790
*Applaus*

337
00:22:10,790 --> 00:22:14,100
Herald: Vielen, vielen Dank, Vincent!

338
00:22:14,100 --> 00:22:17,930
Total super, und du hast auf jeden
Fall noch Zeit für Fragen gelassen.

339
00:22:17,930 --> 00:22:24,260
Genau – macht euch bitte kenntlich!

340
00:22:24,260 --> 00:22:29,340
Geht gerne vor zu den Mikro-Fahnen!

341
00:22:29,340 --> 00:22:34,110
Die Mikros 2 und 4 sind an.
Ich seh’ schon jemand[en] an Mikro 2?

342
00:22:34,110 --> 00:22:39,570
Nein? Du stehst da nur so. Okay.
*lacht*

343
00:22:39,570 --> 00:22:45,980
Wir geben euch mal noch ein
paar Minuten Zeit zum Überlegen.

344
00:22:45,980 --> 00:22:50,150
Und ich kucke ’mal nach oben!

345
00:22:50,150 --> 00:22:56,680
Lieber Mensch, der du Fragen aus dem Netz
einsammelst: ich seh’ dich gerade nicht,

346
00:22:56,680 --> 00:23:00,390
aber wenn du welche hast, dann
könntest du jetzt gerne eine vorlesen.

347
00:23:00,390 --> 00:23:06,100
Signal Angel: Dann mach’ ich das einfach
mal. Und zwar: seppsammy und shelter8

348
00:23:06,100 --> 00:23:09,590
wollen wissen: gibt es Schwächen
im Optik-TAN-Verfahren?

349
00:23:09,590 --> 00:23:14,220
Vincent: Also „Optik-TAN“ meint dann
wahrscheinlich irgendwie so Foto-TAN

350
00:23:14,220 --> 00:23:18,270
und QR-TAN. Also, „Optik-TAN“ weiß ich
jetzt nicht genau, ist es damit gemeint?

351
00:23:18,270 --> 00:23:21,380
Aber ich meine, das ist irgendwie das.
Ja, QR-TAN und Foto-TAN ist eigentlich

352
00:23:21,380 --> 00:23:25,050
ziemlich ähnlich; da scannt man dann
einen Code ab mit seinem Smartphone;

353
00:23:25,050 --> 00:23:31,570
und bekommt dann dadurch die TAN.
Das unterscheidet sich halt insofern,

354
00:23:31,570 --> 00:23:34,740
dass man das schwer auf einem Gerät
verwenden kann. Also ich kann natürlich

355
00:23:34,740 --> 00:23:38,710
den QR-Code nicht von meinem eigenen
Gerät abscannen. Deswegen ist das Szenario

356
00:23:38,710 --> 00:23:42,980
ein bisschen anders. Also, da sind
natürlich auch andere Schwächen vorhanden,

357
00:23:42,980 --> 00:23:46,140
wie z.B. dass man die App irgendwie
kopieren kann und sowas dergleichen.

358
00:23:46,140 --> 00:23:49,660
Aber es ist nicht ganz vergleichbar
mit dem Szenario das wir hier

359
00:23:49,660 --> 00:23:52,230
bei den App-basierten Verfahren haben.

360
00:23:52,230 --> 00:23:55,780
Herald: Dann jetzt gerne erst
eine Frage vom Mikrofon Nr.2.

361
00:23:55,780 --> 00:24:01,010
Frage: Ja, du hast beschrieben, wie die
App sich gegen Debugging –

362
00:24:01,010 --> 00:24:03,010
eine Analyse –

363
00:24:03,010 --> 00:24:07,970
schützt. Wie genau hast du dann aber die
Transaktionsdetails manipuliert, dass die

364
00:24:07,970 --> 00:24:11,910
erst falsch angezeigt und dann auch
falsch zur Bank übermittelt werden?

365
00:24:11,910 --> 00:24:18,010
Vincent: Also, das Problem ist, also gegen
Debugging schützen, das ist ja erstmal

366
00:24:18,010 --> 00:24:21,110
’ne Maßnahme gegen dynamische Analyse,
die also verhindern soll, dass jemand

367
00:24:21,110 --> 00:24:23,230
einfach so ’nen Angriff entwickeln kann.

368
00:24:23,230 --> 00:24:27,290
Also die… Den Angriff selbst
hab’ ich mit Xposed entwickelt,

369
00:24:27,290 --> 00:24:31,000
das ist halt ein hooking-Framework.
Das kann sehr leicht Java-Code hooken.

370
00:24:31,000 --> 00:24:34,600
Ein Real-World-Exploit würde
das wohl nicht so machen. Aber,

371
00:24:34,600 --> 00:24:38,560
ja… Für ’nen proof-of-concept war
das ’ne Möglichkeit, das zu machen.

372
00:24:38,560 --> 00:24:41,400
Also die ganzen Maßnahmen eigentlich
die da implementiert wurden,

373
00:24:41,400 --> 00:24:44,110
können nicht effektiv vor einem richtigen
Angriff schützen, sondern können…

374
00:24:44,110 --> 00:24:48,400
hauptsächlich… dienen hauptsächlich
dazu, dass die Sparkasse in einem Monat

375
00:24:48,400 --> 00:24:53,500
wieder sagen kann, ja der Angriff den
ich gemacht hatte funktioniert nicht mehr.

376
00:24:53,500 --> 00:24:55,450
Herald: Mikrofon Nr.4, bitte!

377
00:24:55,450 --> 00:25:01,550
Frage: Mich würde interessieren…
weil du hast ja gezeigt,

378
00:25:01,550 --> 00:25:04,320
wie diese App nach irgendwie
Xposed oder sowas scannt.

379
00:25:04,320 --> 00:25:09,240
Das Verfahren scheint mir grundsätzlich
ziemlich erbärmlich. Kann man sowas auch

380
00:25:09,240 --> 00:25:12,500
gescheit machen oder hat man
da einfach keine Chance?

381
00:25:12,500 --> 00:25:16,590
Vincent: Ja, das ist natürlich schon ein
bisschen schwierig das gescheit zu machen.

382
00:25:16,590 --> 00:25:19,310
Weil es müsste irgendwie
vertrauenswürdige Aufrufer geben.

383
00:25:19,310 --> 00:25:23,070
Also man müsste irgendwie festlegen
können, wer ist denn eigentlich erlaubt.

384
00:25:23,070 --> 00:25:27,660
Wer darf denn in meinem call
stack eigentlich alles drin sein.

385
00:25:27,660 --> 00:25:31,150
Also es ist schon ein bisschen
schwieriger. Fällt mir jetzt auch

386
00:25:31,150 --> 00:25:34,890
spontan erstmal nicht ein, wie
man das effektiv verhindern kann.

387
00:25:34,890 --> 00:25:37,730
Herald: Mikrofon Nr.1, bitte.

388
00:25:37,730 --> 00:25:42,260
Frage: Vielen Dank. Bin ich zu hören? Ja.
Vielen Dank für die schöne Demonstration.

389
00:25:42,260 --> 00:25:48,130
Ich fand’s auch sehr toll, dass rauskam,
dass in so einem Framework wie Android

390
00:25:48,130 --> 00:25:51,630
das Verteilen auf 2 Apps ja überhaupt
nichts bringt. Also ich denke das war

391
00:25:51,630 --> 00:25:54,550
einer von den zentralen Sachen,
die rauskamen. Meine Frage wäre:

392
00:25:54,550 --> 00:25:58,080
Wie schätzt du das ein, dass man
es auch im Android-Betriebssystem

393
00:25:58,080 --> 00:26:05,210
in Zukunft schafft, Apps mit einem
Verifikationsmechanismus auszustatten,

394
00:26:05,210 --> 00:26:09,470
und eher von Teilen des Betriebssystems
die auch nach dem Rooten das tun

395
00:26:09,470 --> 00:26:13,450
was sie tun sollten; diese App quasi für
sich alleine laufen. Das würde mir

396
00:26:13,450 --> 00:26:17,330
nach einem vielversprechenderen Ansatz
aussehen als das Konzept

397
00:26:17,330 --> 00:26:19,570
von 2 Apps und
einfach-ein-bisschen-Skripten.

398
00:26:19,570 --> 00:26:23,920
Vincent: Ja das greift jetzt natürlich
schon ziemlich weit. Auf was du anspielst,

399
00:26:23,920 --> 00:26:27,060
das erinnert mich so ein bisschen 
an ARM TrustZone.

400
00:26:27,060 --> 00:26:30,090
Also da gibt’s ’ne Sichere Welt

401
00:26:30,090 --> 00:26:33,210
und ’ne Unsichere Welt. Es gibt ’ne
TrustZone bei ARM, gibt’s schon länger.

402
00:26:33,210 --> 00:26:36,140
Die wird aber bei Android nicht
durchgereicht. Also Samsung hat

403
00:26:36,140 --> 00:26:41,210
mit Knox sowas ähnliches. Das ist aber…
ja das muss man kaufen. Wie lange das

404
00:26:41,210 --> 00:26:43,470
bei Android irgendwie noch dauert
bis es sowas für alle gibt,

405
00:26:43,470 --> 00:26:46,150
kann ich dir nicht sagen. Also,
es dauert aber sicher noch.

406
00:26:46,150 --> 00:26:49,520
Herald: Gibt’s noch Netz-Fragen?

407
00:26:49,520 --> 00:26:52,600
Dann machen wir weiter mit Mikro 2 bitte!

408
00:26:52,600 --> 00:26:57,910
Frage: Also ich schließe aus deinen
Ausführungen, dass das fundamentale

409
00:26:57,910 --> 00:27:02,640
Problem ist, dass die Kombination von
2 Apps auf einem Gerät das Prinzip

410
00:27:02,640 --> 00:27:06,290
Zweifaktor-Authentifizierung
einfach ad absurdum führt.

411
00:27:06,290 --> 00:27:10,770
Und dass also Sicherheit insofern
nur besser werden kann,

412
00:27:10,770 --> 00:27:14,880
dass man wirklich auf 2 separate
Geräte, die dann eben auch

413
00:27:14,880 --> 00:27:16,860
separat kompromittiert werden
müssten, setzen wird.

414
00:27:16,860 --> 00:27:20,090
Vincent: Ja, genau. Das ist genau das.
Also hier hab’ ich auch ein Zitat,

415
00:27:20,090 --> 00:27:24,150
eigentlich sehr schön. Das ist irgendwie
nicht nur was, was ich irgendwie sage.

416
00:27:24,150 --> 00:27:27,780
Auch im BaFin-Journal ist es
im August schon erschienen:

417
00:27:27,780 --> 00:27:30,720
„Die TAN sollte auf keinem Fall auf
demselben Smartphone generiert werden,

418
00:27:30,720 --> 00:27:33,950
auf dem das Online-Banking stattfindet.
Hat ein Betrüger das Smartphone gehackt,

419
00:27:33,950 --> 00:27:38,130
so kann er dadurch auf beide Verfahren
zugreifen“. Also das ist irgendwie keine…

420
00:27:38,130 --> 00:27:41,330
das ist eigentlich ’ne Erkenntnis, die…
ich weiß nicht… vielen leuchtet das hier

421
00:27:41,330 --> 00:27:45,240
tatsächlich wahrscheinlich
einfach auch ein. Also…

422
00:27:45,240 --> 00:27:53,390
*Gelächter, Applaus*

423
00:27:53,390 --> 00:27:55,180
Herald: Bitte schön!

424
00:27:55,180 --> 00:27:58,800
Signal Angel: Einige Leute wollten
wissen – vielleicht ist das jetzt gerade

425
00:27:58,800 --> 00:28:01,640
beantwortet worden –
*lacht*

426
00:28:01,640 --> 00:28:04,280
ob es, wenn man 2 verschiedene
Verfahren verwendet,

427
00:28:04,280 --> 00:28:07,650
also die App und den Computer,
ob es dann sicher ist?

428
00:28:07,650 --> 00:28:10,940
Vincent: Also, dann hat’s eigentlich
im Prinzip ähnliche Probleme

429
00:28:10,940 --> 00:28:14,780
wie z.B. QR-TAN oder Foto-TAN.
Ist aber auf jeden Fall deutlich sicherer.

430
00:28:14,780 --> 00:28:19,000
Also wenn ich jetzt die pushTAN-App
mit meinem PC verwende, dann

431
00:28:19,000 --> 00:28:21,740
ist es nicht schlechter als SMS-TAN,
würde ich jetzt sagen.

432
00:28:21,740 --> 00:28:23,540
Oder, ja, auf jeden Fall vergleichbar.

433
00:28:23,540 --> 00:28:25,090
Herald: Dann nochmal Mikro Nr.1, bitte.

434
00:28:25,090 --> 00:28:30,680
Frage: Ja, also das ist auch wohl relativ
neu, weil aus eigener Erfahrung weiß ich,

435
00:28:30,680 --> 00:28:35,830
dass es da ursprünglich mal ’n Requirement
gegeben hat, so: bei mobile Banking

436
00:28:35,830 --> 00:28:40,090
darf nicht… also wenn
du mobileTAN benutzt,

437
00:28:40,090 --> 00:28:44,620
darfst du von deinem Handy
nicht die Transaktion starten,

438
00:28:44,620 --> 00:28:48,480
wo auch die SMS hingeht. Deswegen
haben die am Anfang so total billo

439
00:28:48,480 --> 00:28:51,310
halt die host names gefiltert von
dem mobile Netz, von den…

440
00:28:51,310 --> 00:28:53,940
V: Genau.
F: …von den Mobilfunkanbietern; und dann

441
00:28:53,940 --> 00:28:57,760
hat aber der Vendor, der die Software
gebaut hat, diese Sparkassen-App

442
00:28:57,760 --> 00:29:00,980
unter ’nem anderen Logo – nicht
Sparkasse – veröffentlicht,

443
00:29:00,980 --> 00:29:04,810
ohne diese Funktion. Und so
ist das da reingekommen.

444
00:29:04,810 --> 00:29:07,890
Die wissen schon ganz
genau, dass es Scheiße ist.

445
00:29:07,890 --> 00:29:09,400
Vincent: Ja,…
*lacht*

446
00:29:09,400 --> 00:29:13,950
*Applaus*

447
00:29:13,950 --> 00:29:17,230
Also ich hab’ hier noch ’n anderes Zitat.

448
00:29:17,230 --> 00:29:22,270
Also MaSi, das sind die Mindeststandards
für die Sicherheit von Internetzahlungen.

449
00:29:22,270 --> 00:29:24,750
Und die müssen von den Banken
umgesetzt werden. Dafür ist die Frist

450
00:29:24,750 --> 00:29:28,480
jetzt gerade ausgelaufen. Und
da gibt’s eben auch einen Punkt

451
00:29:28,480 --> 00:29:31,220
der schreibt starke Kunden-
Authentifizierung vor. Der Punkt

452
00:29:31,220 --> 00:29:34,960
war aber derart schwammig, da konnte man
alles interpretieren. Deswegen gab’s dann

453
00:29:34,960 --> 00:29:37,960
dazu irgendwann mal ein Q&A [eher:FAQ?],
die länger ist als die eigene Abfassung

454
00:29:37,960 --> 00:29:43,170
davon, was das eigentlich ist. Und da
steht dann auch drin, das war dann danach:

455
00:29:43,170 --> 00:29:46,120
„Allerdings muss das App-basierte
Sicherungsverfahren und das tatsächliche

456
00:29:46,120 --> 00:29:49,180
Online-Banking unabhängig voneinander
– also über verschiedene Geräte […] –

457
00:29:49,180 --> 00:29:54,640
erfolgen.“ Also es ist sowieso fraglich,
ob dieses Verfahren überleben darf.

458
00:29:54,640 --> 00:29:57,710
Herald: Eine ganz schnelle
noch von Mikrofon 3.

459
00:29:57,710 --> 00:30:01,480
Frage: Ja, darf ich fragen,
wie du dein Geld überweist?

460
00:30:01,480 --> 00:30:03,800
Bzw. was würdest du
für’n System empfehlen?

461
00:30:03,800 --> 00:30:07,640
Vincent: Also ich selbst verwende
chipTAN. Ich verwende es sogar

462
00:30:07,640 --> 00:30:11,830
tatsächlich auch mobil. Allerdings
eher wenn ich irgendwie

463
00:30:11,830 --> 00:30:17,040
mal länger irgendwo bin, oder sowas.
Also ich habe jetzt nicht so

464
00:30:17,040 --> 00:30:20,250
das Verlangen danach, jetzt überall
Überweisungen machen zu müssen. Also

465
00:30:20,250 --> 00:30:24,280
chipTAN kann ich eigentlich schon
empfehlen, von den TAN-Verfahren.

466
00:30:24,280 --> 00:30:25,360
F: Danke.

467
00:30:25,360 --> 00:30:27,860
Herald: Vielen, vielen Dank! Bitte
nicht böse sein, wenn ihr jetzt

468
00:30:27,860 --> 00:30:30,610
nicht drangekommen seid. Vincent hat mir
versprochen, dass er jetzt noch da ist

469
00:30:30,610 --> 00:30:33,820
und eure Fragen beantwortet.
Ich hoffe, das ist okay so. Super.

470
00:30:33,820 --> 00:30:36,110
Danke schön nochmal. Ein
ganz großer Applaus für dich!

471
00:30:36,110 --> 00:30:43,700
*Applaus*

472
00:30:43,700 --> 00:30:50,301
*Abspannmusik*

473
00:30:50,301 --> 00:30:54,201
*Untertitel erstellt von c3subtitles.de
im Jahr 2016. Unterstütze uns!*