WEBVTT
00:00:00.429 --> 00:00:08.840
32C3 Vorspannmusik
00:00:08.840 --> 00:00:14.110
Herald: Vincent Haupert studiert in seinem
Dayjob, sozusagen, Informatik in Erlangen,
00:00:14.110 --> 00:00:17.220
und macht da gerade seinen Master
mit Schwerpunkt in IT-Security.
00:00:17.220 --> 00:00:20.680
Die Arbeit, die er uns aber
gleich vorstellen möchte,
00:00:20.680 --> 00:00:23.740
hat er im Rahmen seiner Tätigkeit als
wissenschaftliche Hilfskraft gemacht,
00:00:23.740 --> 00:00:27.830
und zwar zusammen mit seinem Kollegen
Tilo Müller. Dort hat er untersucht,
00:00:27.830 --> 00:00:32.029
was es denn für Sicherheitslücken
bei App-basierten TAN-Verfahren gibt,
00:00:32.029 --> 00:00:35.110
also im Bereich des Onlinebankings;
und die möchte er uns jetzt vorstellen.
00:00:35.110 --> 00:00:38.659
Einen ganz großen, herzlichen
Applaus für Vincent bitte!
00:00:38.659 --> 00:00:44.920
Applaus
00:00:44.920 --> 00:00:48.329
Vincent: Ja, auch herzlich willkommen
von mir, also mein Name ist, wie gesagt,
00:00:48.329 --> 00:00:51.059
Vincent Haupert, und ich habe
mir im vergangenen Herbst
00:00:51.059 --> 00:00:55.420
mit meinem Kollegen Tilo Müller mal
angeschaut, wie es denn um die Sicherheit
00:00:55.420 --> 00:00:58.860
von App-basierten TAN-Verfahren
im Onlinebanking bestellt ist;
00:00:58.860 --> 00:01:02.960
und ja, der ein oder andere hat die
Geschichte vielleicht schon mitbekommen,
00:01:02.960 --> 00:01:05.209
hat sie auf Heise gelesen und
so, und fragt sich vielleicht: ja,
00:01:05.209 --> 00:01:08.600
was kommt denn jetzt da heute? Vor
2 Wochen habe ich einen Angriff von der,
00:01:08.600 --> 00:01:12.140
äh, einen Angriff… lacht
einen Anruf von der Sparkasse bekommen
00:01:12.140 --> 00:01:16.380
Gelächter
Applaus
00:01:16.380 --> 00:01:21.030
Ja, der Herr Meier, den ich jetzt hier
einfach mal so nennen möchte,
00:01:21.030 --> 00:01:24.840
hat mich da gefragt, was ich denn zwischen
Weihnachten und Neujahr mache… ja.
00:01:24.840 --> 00:01:30.750
Zu dem Zeitpunkt, wollte er eben wissen:
muss er seine Presseabteilung jetzt schon
00:01:30.750 --> 00:01:33.240
auf irgendetwas Neues gefasst machen,
oder nicht. Gelächter
00:01:33.240 --> 00:01:36.479
Zu dem Zeitpunkt konnte ich es ganz
ehrlich gesagt noch nicht sagen,
00:01:36.479 --> 00:01:38.909
Heute kann ich ihnen sagen: ich hoffe,
sie haben einen Entwurf gemacht,
00:01:38.909 --> 00:01:40.839
das macht es danach leichter.
00:01:40.839 --> 00:01:47.080
Gelächter
Applaus
00:01:47.080 --> 00:01:51.430
Ja, Onlinebanking ist etwas, das
betrifft uns alle; es ist etabliert,
00:01:51.430 --> 00:01:56.509
eine große Zahl der Deutschen verwendet
es, und ein besonderes Merkmal
00:01:56.509 --> 00:02:01.920
von Onlinebanking ist, dass es schon seit
seinem Entstehen in den 1980er Jahren,
00:02:01.920 --> 00:02:04.880
damals noch BTX-basiert,
ein Zweifaktor-Verfahren ist.
00:02:04.880 --> 00:02:08.619
Also, man hatte auf der einen Seite immer
irgendwie einen Benutzernamen/Passwort,
00:02:08.619 --> 00:02:13.779
und dann noch irgendein TAN-Verfahren.
Über die Zeit ist da ein ganzer Zoo
00:02:13.779 --> 00:02:17.919
an TAN-Verfahren entstanden; meistens
gab es einfach Weiterentwicklungen,
00:02:17.919 --> 00:02:22.620
aus Sicherheitsgründen. Heute werden
wir ein Verfahren sehen, das sich nicht
00:02:22.620 --> 00:02:27.230
in diese Reihe begeben
kann. Ja. Im Prinzip läuft
00:02:27.230 --> 00:02:31.449
Onlinebanking immer so ab, ich sage das
der Vollständigkeit halber hier nochmal:
00:02:31.449 --> 00:02:35.480
man loggt sich im Onlinebanking-Portal
ein, mit seinem Benutzername/Passwort,
00:02:35.480 --> 00:02:39.189
reicht dann eine Überweisung ein, und im
zweiten Schritt muss man das dann noch
00:02:39.189 --> 00:02:44.069
mit einem TAN-Verfahren bestätigen. Das
ist nicht für jeden das gleiche; das kann
00:02:44.069 --> 00:02:48.370
entweder noch die altgediente iTAN-
Liste sein, die aber langsam ausstirbt;
00:02:48.370 --> 00:02:52.269
das SMS-TAN-Verfahren,
das auch seine Tücken hat,
00:02:52.269 --> 00:02:54.609
wie man in den letzten
Monaten mitbekommen kann.
00:02:54.609 --> 00:02:59.309
Insbesondere ein großer Verbündeter
ist die Telekom, lacht
00:02:59.309 --> 00:03:02.919
und es gibt dann auch noch das
chipTAN-Verfahren, das auch recht
00:03:02.919 --> 00:03:06.719
verbreitet ist. Das letzte Verfahren,
das chipTAN-Verfahren, adressiert
00:03:06.719 --> 00:03:11.029
das Sicherheitsproblem im Onlinebanking
eigentlich schon ganz gut, aber,
00:03:11.029 --> 00:03:13.859
wenn man den Kreditinstituten glaubt,
gibt es einen dringenden Wunsch
00:03:13.859 --> 00:03:17.290
in der deutschen Bevölkerung,
seine Geldgeschäfte immer überall
00:03:17.290 --> 00:03:21.059
machen zu können. Sei das in der U-Bahn,
im Restaurant, vielleicht auch hier,
00:03:21.059 --> 00:03:24.089
gerade in diesem Vortrag. Macht jemand
gerade eine Überweisung, mal Hand hoch?
00:03:24.089 --> 00:03:26.870
Gelächter
Ja.
00:03:26.870 --> 00:03:32.180
Auf jeden Fall ist es dann so, wenn man
eine Überweisung überall machen will,
00:03:32.180 --> 00:03:35.370
sarkastisch: dann will ich kein zweites
Gerät haben, denn das ist ja unbequem.
00:03:35.370 --> 00:03:40.019
Deswegen haben die Banken ein
Gerät entdeckt, das jeder von uns
00:03:40.019 --> 00:03:43.989
immer dabei hat, und das absolut
sicher ist – das Smartphone.
00:03:43.989 --> 00:03:49.900
Gelächter
Applaus
00:03:49.900 --> 00:03:56.169
Man hat jetzt keine zwei Geräte mehr,
nicht 2 voneinander unabhängigen Faktoren,
00:03:56.169 --> 00:03:58.829
man hat eine Banking-App,
und man hat eine TAN-App.
00:03:58.829 --> 00:04:02.959
Das funktioniert jetzt so: ich logge
mich mit meiner Banking-App
00:04:02.959 --> 00:04:06.889
auf dem Smartphone ein und gebe eine
Überweisung auf. Im zweiten Schritt
00:04:06.889 --> 00:04:11.279
muss ich dann wie gehabt die
Überweisung mit einer TAN bestätigen.
00:04:11.279 --> 00:04:15.819
Jetzt nehme ich aber nicht meinen
Papierzettel her, mein chipTAN-Gerät,
00:04:15.819 --> 00:04:21.310
sondern ich wechsle
zur TAN-App. Da gibt’s,
00:04:21.310 --> 00:04:24.449
also da sind alle Banken mittlerweile ein
großer Fan davon eigentlich, das ist jetzt
00:04:24.449 --> 00:04:28.050
nur eine Auswahl, ich weiß nicht ob es
noch mehr gibt, aber all diese Banken
00:04:28.050 --> 00:04:31.560
haben ein App-basiertes TAN-
Verfahren im Angebot, und ich denke,
00:04:31.560 --> 00:04:35.939
die die es noch nicht haben, sind bestimmt
auf dem Weg dahin, das zu machen.
00:04:35.939 --> 00:04:40.139
Ich sehe jetzt schon den einen oder
anderen hier in den ersten Reihen,
00:04:40.139 --> 00:04:42.979
bei denen sich dann die Stirn
runzelt bei dem Verfahren,
00:04:42.979 --> 00:04:47.319
ich will aber trotzdem nochmal generell
das Angriffs-Szenario motivieren.
00:04:47.319 --> 00:04:52.319
Also, Malware, oder Schadsoftware,
ist in den offiziellen App Stores
00:04:52.319 --> 00:04:55.250
der Betriebssystemhersteller.
Das ist keine Fiktion!
00:04:55.250 --> 00:05:02.270
Bei uns am Lehrstuhl in Erlangen
hat der Dominik Maier gezeigt,
00:05:02.270 --> 00:05:05.180
dass sich der Google Play Store
00:05:05.180 --> 00:05:10.020
nicht ausreichend gegen Schadsoftware
schützen kann. Also, die konkrete Aufgabe
00:05:10.020 --> 00:05:12.990
von ihm war eigentlich,
in seiner Bachelorarbeit,
00:05:12.990 --> 00:05:18.639
Schadsoftware in den Google
Play Store zu bekommen. Nur:
00:05:18.639 --> 00:05:21.900
das war seine Bachelorarbeit… da ist er
nach ein paar Tagen zu seinem Betreuer
00:05:21.900 --> 00:05:25.370
dann hingekommen und hat gesagt:
„Ey Tilo, ich bin fertig!“
00:05:25.370 --> 00:05:32.740
Gelächter
Applaus
00:05:32.740 --> 00:05:38.530
amüsiert: Und, was er gemacht hat:
er hat einen Root-Exploit gezippt, ja…
00:05:38.530 --> 00:05:39.979
Gelächter
00:05:39.979 --> 00:05:42.960
Also, er hat ihn gezippt und hochgeladen;
da war kein Passwort, nichts –
00:05:42.960 --> 00:05:44.730
er hat ihn einfach gezippt.
00:05:44.730 --> 00:05:49.069
Dass das aber nicht irgendwie nur
akademische, graue Theorie ist,
00:05:49.069 --> 00:05:53.039
hat dieses Jahr so ziemlich gleichzeitig,
als wir diese App-TAN-Geschichte
00:05:53.039 --> 00:05:57.659
gemacht haben, die App „Brain Test“
gezeigt. Das ist ein Spiel, und
00:05:57.659 --> 00:06:02.180
das hat über 100.000 Downloads
gehabt, bis zu 500.000.
00:06:02.180 --> 00:06:05.870
Und diese App hat genau das
gemacht, was das Angriffsszenario
00:06:05.870 --> 00:06:09.590
auch für App-basierte TAN-Verfahren
ist. Nämlich: im offiziellen Store,
00:06:09.590 --> 00:06:13.810
rootet das Gerät zuerst und
lädt dann Schadcode nach.
00:06:13.810 --> 00:06:19.550
Wir hätten jetzt auch irgendeins von
den Kreditinstituten, die App-basiertes
00:06:19.550 --> 00:06:23.689
TAN-Verfahren anbieten, nehmen können;
ich habe die Sparkasse genommen,
00:06:23.689 --> 00:06:25.819
weil ich da a) ein Konto habe und
b) weil’s irgendwie die größte ist.
00:06:25.819 --> 00:06:28.629
Und das waren auch die Ersten,
die das angeboten haben.
00:06:28.629 --> 00:06:32.520
Deswegen haben wir uns angeguckt:
was kann man denn jetzt da machen?
00:06:32.520 --> 00:06:35.440
Was gibt es denn da für
Angriffsszenarien für pushTAN?
00:06:35.440 --> 00:06:39.569
Und was uns da als allererstes
ziemlich schnell eingefallen ist,
00:06:39.569 --> 00:06:43.479
ist: wir könnten die App
irgendwie kopieren,
00:06:43.479 --> 00:06:46.620
oder wir reversen das Protokoll und
implementieren unseren eigenen Client.
00:06:46.620 --> 00:06:49.810
Das sind aber beides noch Angriffe,
die konzentrieren sich sehr stark
00:06:49.810 --> 00:06:54.810
einfach nur auf die TAN-App.
Das eigentliche Problem
00:06:54.810 --> 00:06:57.590
von App-basierten TAN-Verfahren,
also dass man den ersten Faktor
00:06:57.590 --> 00:07:01.370
und den zweiten Faktor auf einem Gerät
hat, wird aber am besten dadurch betont,
00:07:01.370 --> 00:07:06.389
wenn man eine Transaktionsmanipulation
durchführt. Sprich: wir manipulieren eine
00:07:06.389 --> 00:07:12.309
vom Nutzer aufgegebene Transaktion
in Echtzeit, ohne dass er’s sehen kann.
00:07:12.309 --> 00:07:15.340
Wie haben wir das gemacht, oder
wie war unser Szenario dafür?
00:07:15.340 --> 00:07:19.110
Nochmal: wie läuft das ab?
Links ist die Sparkassen-App,
00:07:19.110 --> 00:07:22.029
die verwende ich, um mich in meinem
Onlinebanking einzuloggen und dann
00:07:22.029 --> 00:07:26.469
meine Überweisungsdaten auszufüllen,
und schicke das dann letztendlich ab.
00:07:26.469 --> 00:07:31.120
Dann landet das Ganze beim Sparkassen-
Server, und der schickt dann eine TAN
00:07:31.120 --> 00:07:35.259
an die pushTAN-App, die da rechts
dargestellt ist. Der Nutzer wird dann
00:07:35.259 --> 00:07:39.580
dazu aufgefordert, in die pushTAN-App
zu wechseln, die dort dargestellte TAN
00:07:39.580 --> 00:07:43.529
– nachdem er die Überweisungsdaten
natürlich kontrolliert hat – in die App
00:07:43.529 --> 00:07:46.379
„Sparkasse“ zu übertragen. Das geht
mittlerweile, wie wir später sehen werden,
00:07:46.379 --> 00:07:50.900
auch so automatisiert, dass man sich
fragt: warum gibt’s überhaupt noch 2 Apps?
00:07:50.900 --> 00:07:57.080
Ja, gut. Was wir jetzt
machen: wir sagen einfach,
00:07:57.080 --> 00:08:02.539
nachdem der Nutzer auf
‚Auftrag übermitteln‘ geht,
00:08:02.539 --> 00:08:06.360
dann manipulieren wir die Daten.
Also wir ändern den Adressaten,
00:08:06.360 --> 00:08:10.900
wir ändern den Betrag, und die
Sparkasse schickt dann natürlich
00:08:10.900 --> 00:08:14.340
die Überweisungsdetails auch nochmal
an die TAN-App, und die werden dann
00:08:14.340 --> 00:08:17.309
da nochmal dargestellt. Das heißt,
bevor die dann da angezeigt werden,
00:08:17.309 --> 00:08:19.409
manipulieren wir die wieder
auf die originalen Daten,
00:08:19.409 --> 00:08:24.300
und der Nutzer kann’s nicht sehen, und
bestätigt letztendlich eine Überweisung
00:08:24.300 --> 00:08:29.479
mit einer TAN, was er gar nicht wollte.
Ja, da mussten wir erstmal überlegen:
00:08:29.479 --> 00:08:32.219
was gibt es denn da eigentlich so für
Sicherheitsmerkmale bei den beiden Apps?
00:08:32.219 --> 00:08:35.260
Also die Sparkassen-App selbst
ist eigentlich ein leichtes Fressen
00:08:35.260 --> 00:08:38.769
für so einen Angriff; die hat ja
keine großen Schutzmaßnahmen.
00:08:38.769 --> 00:08:42.909
Es gibt eine Root-Erkennung, es wird aber
lediglich dargestellt ein Warnhinweis,
00:08:42.909 --> 00:08:45.579
und die macht also ansonsten nichts, man
kann die App dann normal weiterverwenden.
00:08:45.579 --> 00:08:51.709
Auf der anderen Seite: die pushTAN-App
versucht, sich mit einer Vielzahl
00:08:51.709 --> 00:08:57.300
an Maßnahmen gegen Analyse und gegen
Schadsoftware angeblich auch zu schützen.
00:08:57.300 --> 00:09:00.160
Man merkt eigentlich schon, wenn man
hier sieht, die ganzen Maßnahmen,
00:09:00.160 --> 00:09:02.139
ich glaube, die Sparkasse ist sich selber
nicht so ganz sicher, dass das wirklich
00:09:02.139 --> 00:09:05.449
sicher zu kriegen ist. Die haben
halt eine Root-Erkennung,
00:09:05.449 --> 00:09:10.339
die ist nicht wie bei der Sparkassen-App,
dass da ein Warnhinweis angezeigt wird;
00:09:10.339 --> 00:09:13.579
also es wird verboten: wenn ein Root
erkannt wird, beendet sich die App,
00:09:13.579 --> 00:09:16.220
und schützt sich eben auch gegen
die dynamische Analyse, statische Analyse,
00:09:16.220 --> 00:09:22.179
weiß der Teufel nicht, was alles.
Und: es ist TÜV-geprüft!
00:09:22.179 --> 00:09:29.650
Gelächter
Applaus
00:09:29.650 --> 00:09:32.100
Von diesem Prädikat
merklich eingeschüchtert,
00:09:32.100 --> 00:09:37.089
habe ich mir dann mal angeguckt, ja
– was gibt es denn da eigentlich wirklich
00:09:37.089 --> 00:09:40.810
für Schutzmaßnahmen, wie sind denn die
umgesetzt? Es wurde recht schnell klar:
00:09:40.810 --> 00:09:43.800
die Sparkasse selbst traut sich in Sachen
Sicherheit nicht so viel zu und hat
00:09:43.800 --> 00:09:48.670
deswegen beim norwegischen Hersteller
Promon eingekauft. Die selber haben
00:09:48.670 --> 00:09:52.880
eine Native-Library, die wird gleich
am Anfang der App geladen,
00:09:52.880 --> 00:09:56.500
und ist dann quasi der Einsprungspunkt.
00:09:56.500 --> 00:10:01.910
Die Library selbst ist verschlüsselt,
zum Teil, mit einem statischen Key
00:10:01.910 --> 00:10:04.630
natürlich irgendwie, und ist obfuskiert,
ist also ein ziemlicher Hass, sich die
00:10:04.630 --> 00:10:08.279
anzuschauen. Aber es gibt
00:10:08.279 --> 00:10:11.690
– also damit man die Library nicht einfach
heraus patcht, also sagt: „Ja gut, dann
00:10:11.690 --> 00:10:16.790
mach’ ich das Ding halt raus“ –
haben die Strings aus der Java-Logik
00:10:16.790 --> 00:10:20.050
in die Library verlagert, die ja
wiederum verschlüsselt ist.
00:10:20.050 --> 00:10:24.100
Die Library selbst setzt dann
statische, finale Felder
00:10:24.100 --> 00:10:27.800
während der Laufzeit mit diesen Strings
und werden dann halt normal verwendet.
00:10:27.800 --> 00:10:31.579
Oder sie werden über einen Index
abgerufen, mit der Methode getString.
00:10:31.579 --> 00:10:35.230
Also das verhindert… also macht’s
zumindest Aufwand, diese Library
00:10:35.230 --> 00:10:38.170
einfach rauszuziehen und
ohne die dann klarzukommen.
00:10:38.170 --> 00:10:43.649
Ja die erkennt, wie gesagt,
Root, Debugger, alles Mögliche.
00:10:43.649 --> 00:10:47.220
Aber die behandelt die Erkennung nicht.
00:10:47.220 --> 00:10:51.980
Das liegt einfach daran, die wollen
eine Library verkaufen, die soll
00:10:51.980 --> 00:10:57.320
für alles und jeden gehen, ne? Also die
ist nicht personalisiert auf diese App.
00:10:57.320 --> 00:11:03.220
So ist es dann implementiert. Stattdessen
gibt’s im Java-Code callbacks
00:11:03.220 --> 00:11:07.250
für die verschiedenen einzelnen events.
Also z.B. Debugger, oder eben Root.
00:11:07.250 --> 00:11:11.320
Die App selbst implementiert
dann eben dieses Interface und,
00:11:11.320 --> 00:11:14.899
wenn das erkannt wird, dann
wird der Code aufgerufen.
00:11:14.899 --> 00:11:18.949
Z.B. hier unten ist dargestellt,
der Rooting-Status. Da steht
00:11:18.949 --> 00:11:22.980
in dem Parameter z dann eben drin,
ob es gerootet wurde oder nicht.
00:11:22.980 --> 00:11:26.620
Und dann kommt da so’n Texthinweis,
und danach beendet sich die App.
00:11:26.620 --> 00:11:29.920
Ja, was haben wir gemacht:
Wenn dieses event kommt,
00:11:29.920 --> 00:11:33.769
dann brechen wir die Methode immer ab
und dann läuft die App einfach weiter.
00:11:33.769 --> 00:11:38.910
Das Ganze ist besonders paradox, diese
Library scheint keinen Status zu haben.
00:11:38.910 --> 00:11:43.649
Die liefert einfach weiter Strings aus,
obwohl schon Root detected wurde.
00:11:43.649 --> 00:11:47.940
Das hat mich wirklich überrascht,
dass es so einfach war. lacht
00:11:47.940 --> 00:11:52.790
Applaus
00:11:52.790 --> 00:11:57.130
Ja, dann schauen wir uns mal an, wie
funktioniert denn das jetzt konkret.
00:11:57.130 --> 00:12:02.069
Also hier, als allererstes, die
Sparkassen-App. Das sieht man jetzt,
00:12:02.069 --> 00:12:05.449
wie man sich eben anmeldet. Mit seinem
Passwort, das man mal selbst vergeben hat.
00:12:05.449 --> 00:12:09.509
Und es wird ja auch ein Hinweis angezeigt
dass das Gerät gerootet ist, aber
00:12:09.509 --> 00:12:12.699
wie gesagt, es hat weiter keine
Konsequenzen. In dem Fall habe ich
00:12:12.699 --> 00:12:17.089
dann eine Überweisung an das Finanzamt mit
meiner hohen Einkommenssteuer von 10 Cent
00:12:17.089 --> 00:12:21.519
ausgelöst. Und im nächsten Schritt… also…
00:12:21.519 --> 00:12:24.199
dann haben wir die Überweisung eben
manipuliert, die Daten im Hintergrund,
00:12:24.199 --> 00:12:27.779
man sieht es nicht. Und hier wird man dann
dazu aufgefordert, in die pushTAN-App
00:12:27.779 --> 00:12:31.480
zu wechseln, um dann
dort die TAN abzurufen.
00:12:31.480 --> 00:12:35.480
Das machen wir auch, loggen uns
wieder mit unserem Passwort,
00:12:35.480 --> 00:12:39.050
diesmal in der pushTAN-App ein.
Wie groß die Wahrscheinlichkeit ist,
00:12:39.050 --> 00:12:41.690
dass das das gleiche Passwort
ist, können wir uns denken.
00:12:41.690 --> 00:12:46.399
Und dann schauen wir uns die
Überweisungsdetails an. 10 Cent…
00:12:46.399 --> 00:12:48.860
sagen wir jetzt einfach mal die IBAN hat
sich jetzt wahrscheinlich keiner gemerkt,
00:12:48.860 --> 00:12:52.690
aber das ist auch die gleiche.
Und ja, schaut gut aus.
00:12:52.690 --> 00:12:57.230
Das geben wir frei. TAN übertragen an
Sparkasse. Jetzt merken wir uns noch
00:12:57.230 --> 00:12:59.670
die letzten 2 Stellen der TAN, das ist 32,
00:12:59.670 --> 00:13:03.829
dann übertragen wir die und der Auftrag
wird freigegeben in der Sparkassen-App.
00:13:03.829 --> 00:13:08.190
Wenn man dann später irgendwann mal
in die Umsatz-Details reinschaut, dann
00:13:08.190 --> 00:13:12.060
stellt man fest: „Hey, da, mit
der TAN mit der Endstelle 32,
00:13:12.060 --> 00:13:15.470
da wurde ein Betrag von 13,37 Euro
überwiesen, nicht von 10 Cent. Und
00:13:15.470 --> 00:13:18.990
die gingen auch nicht ans Finanzamt,
die gingen an Vincent Haupert. Gut…
00:13:18.990 --> 00:13:24.100
Jetzt… jeder der die Geschichte kennt,
der kennt auch was danach kam.
00:13:24.100 --> 00:13:27.050
Stellungnahme der Sparkasse,
nachdem es auf Heise war: „Ey,
00:13:27.050 --> 00:13:31.880
das ist ja ’ne alte Version, das
geht doch alles gar nicht mehr“.
00:13:31.880 --> 00:13:34.339
Es gibt da jetzt ’ne neue Version
seit dem 16.10. Wir haben
00:13:34.339 --> 00:13:39.779
am 23.Oktober veröffentlicht.
Das ist jetzt nicht mehr möglich.
00:13:39.779 --> 00:13:43.730
Gut. Eigentlich ist es nichts Neues für
uns. Haben wir auch schon gesagt
00:13:43.730 --> 00:13:45.759
in unserer Ausarbeitung. Die
hat die Sparkasse anscheinend
00:13:45.759 --> 00:13:49.980
nicht so aufmerksam gelesen. Und wir
haben damals auch schon gesagt:
00:13:49.980 --> 00:13:54.500
„Es gibt in der aktuellen Version
wohl… die Art und Weise,
00:13:54.500 --> 00:13:57.449
wie wir den Angriff gemacht haben… in der
neuen Version funktioniert das anders,
00:13:57.449 --> 00:14:00.360
wir können das nicht ganz genauso machen;
mit einem entsprechenden Mehraufwand
00:14:00.360 --> 00:14:03.230
können wir den Angriff aber
wieder möglich machen.“
00:14:03.230 --> 00:14:08.920
Ja, schau’n wir halt mal! lacht
Gelächter
00:14:08.920 --> 00:14:14.240
Applaus
00:14:14.240 --> 00:14:18.100
Um jetzt einen Angriff gegen die
neue Version machen zu wollen,
00:14:18.100 --> 00:14:20.730
muss man sich fragen: Was ist
denn da eigentlich anders jetzt?
00:14:20.730 --> 00:14:24.970
Also man hat auch bei der Sparkasse
oder bei Promon realisiert, dass
00:14:24.970 --> 00:14:28.220
die Java-callbacks ungefähr genauso sind,
wie wenn man mit einem Geldtransporter
00:14:28.220 --> 00:14:32.769
vor die Sparkasse fährt, und dann
dem Praktikanten die Geldsäcke
00:14:32.769 --> 00:14:36.899
in die Hand drückt und einfach
wegfährt. Deswegen gibt es jetzt
00:14:36.899 --> 00:14:41.060
keine Java-callbacks mehr.
Stattdessen stürzt die App ab,
00:14:41.060 --> 00:14:45.579
wenn sie z.B. Root erkennt, oder
auch Debugger, was auch immer,
00:14:45.579 --> 00:14:48.699
und öffnet dann eine Seite im Browser.
Dadurch lässt sich die Root-Erkennung
00:14:48.699 --> 00:14:51.310
nicht mehr trivial umgehen. Ansonsten
00:14:51.310 --> 00:14:55.959
werden auch hooking-Frameworks
erkannt. Also wir haben den Angriff
00:14:55.959 --> 00:15:00.250
als proof-of-concept mit Xposed
realisiert. D.h. das würde jetzt
00:15:00.250 --> 00:15:02.560
auch nicht mehr gehen. Ja, schlecht.
00:15:02.560 --> 00:15:07.649
Gut, um den Angriff jetzt wieder
realisieren zu können, müssen wir also
00:15:07.649 --> 00:15:10.739
2 Sachen machen. Wir müssen einmal die
Root-Erkennung umgehen und einmal
00:15:10.739 --> 00:15:12.520
die Xposed-Erkennung umgehen.
00:15:12.520 --> 00:15:16.019
Fangen wir mit Root an. Wie
funktioniert die Root-Erkennung?
00:15:16.019 --> 00:15:19.990
Und ich bin bisher eigentlich gut bei den
Sicherheits-features dieser App gefahren,
00:15:19.990 --> 00:15:24.389
mir einfach vorzustellen, wie würde ich es
machen. Also was ist der einfachste Weg
00:15:24.389 --> 00:15:28.819
Root zu erkennen. Also: was werden die
wohl machen? Die suchen im Dateisystem
00:15:28.819 --> 00:15:32.350
nach irgendwelchen Sachen, die für SU
charakteristisch sind. Dann habe ich mir
00:15:32.350 --> 00:15:36.019
die Syscalls mal angeschaut – ja und klar,
genau das machen die. lacht
00:15:36.019 --> 00:15:40.529
Die schauen einfach z.B.
ist /system/bin/su vorhanden?
00:15:40.529 --> 00:15:45.139
Oder /system/xbin/su? Ja, wenn
ich das jetzt in /vinc umbenenne,
00:15:45.139 --> 00:15:49.020
dann geht sie, die App, schon wieder.
00:15:49.020 --> 00:15:55.370
Applaus
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
00:15:58.879 --> 00:16:02.120
eigentlich Root haben. Und
deswegen, wenn ich die umbenenne,
00:16:02.120 --> 00:16:06.139
dann können die natürlich auch kein
SU mehr ausführen. Das Lustige ist ja,
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
00:16:11.439 --> 00:16:17.060
ist der PATH-Variable zu verdanken,
die in Oslo aber nicht bekannt ist.
00:16:17.060 --> 00:16:21.790
Deswegen ich hab das Ganze auf
Android Marshmallow gemacht,
00:16:21.790 --> 00:16:24.519
und da will man eigentlich
sowieso Systemless SU haben.
00:16:24.519 --> 00:16:27.860
Und das mounted eine eigene Partition
und trägt sich in die PATH-Variable ein
00:16:27.860 --> 00:16:32.139
– und tadaaa! – die pushTAN-App
geht wieder auf.
00:16:32.139 --> 00:16:36.870
Applaus
00:16:36.870 --> 00:16:40.910
Ein bisschen paradoxer wird es aber
immer noch vor dem Hintergrund,
00:16:40.910 --> 00:16:43.910
dass es die Sparkassen-App besser
macht. Die erkennt das Root nämlich.
00:16:43.910 --> 00:16:47.829
Und die haben keine Lösung für
was-weiß-ich wieviel Tausend eingekauft.
00:16:47.829 --> 00:16:50.689
Also bei Promon würde ich jetzt
mal in den Flugmodus gehen,
00:16:50.689 --> 00:16:54.470
sonst kommt da gleich ein Anruf.
00:16:54.470 --> 00:16:57.709
Ja, als nächstes: wie funktioniert
die Xposed-Erkennung?
00:16:57.709 --> 00:17:02.819
Ja, wieder gleiches Spiel, würde
ich sagen. Schauen wir doch mal,
00:17:02.819 --> 00:17:05.210
was… die werden wieder nach irgendwelchen
charakteristischen Sachen
00:17:05.210 --> 00:17:09.910
für Xposed suchen. Ja, so schaut es dann
aus: Das sind halt ein paar Sachen,
00:17:09.910 --> 00:17:12.160
die Xposed platziert beim Installieren.
00:17:12.160 --> 00:17:17.869
Das müssen wir jetzt irgendwie loswerden.
Und Xposed muss danach aber noch gehen.
00:17:17.869 --> 00:17:20.880
Die ersten 4 Sachen sind irgendwie eh
Sachen, die kann man entweder löschen
00:17:20.880 --> 00:17:24.440
oder umbenennen. Und dann
sind die schon mal weg.
00:17:24.440 --> 00:17:28.520
Dann gibt’s hier die anderen 3 Dateien,
die braucht man schon irgendwie;
00:17:28.520 --> 00:17:33.020
ja, die benennen wir halt um. Und
00:17:33.020 --> 00:17:35.530
untereinander müssen die Abhängigkeiten
natürlich auch angepasst werden.
00:17:35.530 --> 00:17:37.950
Und da hab’ ich gedacht: „Ja, jetzt
geht’s“. Es hätte mich nicht überrascht
00:17:37.950 --> 00:17:41.330
wenn’s funktioniert. Reicht aber
noch nicht ganz. Das ist sogar
00:17:41.330 --> 00:17:44.870
tatsächlich ein bisschen besser
gemacht. Die schauen halt selber
00:17:44.870 --> 00:17:47.870
in dem executable file nach,
wo auch die ganze Dalvik-VM
00:17:47.870 --> 00:17:51.560
und was-weiß-ich-was drin ist, und
Zygote, mit dem ja Xposed arbeitet;
00:17:51.560 --> 00:17:55.290
und wenn dann da drinnen Xposed
mit großem oder kleinem X drinsteht,
00:17:55.290 --> 00:17:59.000
dann ist wohl Xposed installiert. Ja,
letztendlich hab’ ich das Ding einfach
00:17:59.000 --> 00:18:02.000
neu kompiliert und schon ging’s wieder.
00:18:02.000 --> 00:18:09.040
Applaus
00:18:09.040 --> 00:18:13.130
Dann schauen wir uns das doch mal an, ne?
00:18:13.130 --> 00:18:15.520
Also wieder gleiches Spiel…
00:18:15.520 --> 00:18:19.620
Wir öffnen die Sparkassen-App,
geben da unser Passwort ein…
00:18:19.620 --> 00:18:25.030
Diesmal, um ganz auf Nummer sicher zu
gehen, schauen wir uns vorher nochmal an,
00:18:25.030 --> 00:18:27.690
welche Version ist denn das, eigentlich?
Nicht dass dann danach irgendeiner sagt:
00:18:27.690 --> 00:18:30.710
„Es war nicht die aktuelle Version“.
Also hier sehen wir, das ist die Version
00:18:30.710 --> 00:18:35.520
vom 7.Dezember, also das war
die aktuellste bis vor 2 Stunden.
00:18:35.520 --> 00:18:38.520
Gelächter, Applaus
00:18:38.520 --> 00:18:42.160
Als nächstes füllen wir wieder
unsere Überweisung aus,
00:18:42.160 --> 00:18:44.940
diesmal nicht ans Finanzamt,
sondern an die Uni-Bibliothek Erlangen.
00:18:44.940 --> 00:18:49.930
Ich habe nämlich meine Benutzerkarte
verloren und brauche deshalb eine neue,
00:18:49.930 --> 00:18:53.820
und die kommt nicht for free,
sondern kostet 3 Euro.
00:18:53.820 --> 00:18:57.060
Ihr seht schon, mein Konto war
nicht so hoch gefüllt, ich musste
00:18:57.060 --> 00:19:01.040
einen Betrag wählen, der irgendwie
auch noch in meinem Limit geht.
00:19:01.040 --> 00:19:03.560
Aber jetzt öffnet sich hier
automatisch schon die pushTAN-App,
00:19:03.560 --> 00:19:08.040
also die Integration hat
tollerweise zugenommen.
00:19:08.040 --> 00:19:11.810
Jetzt logg’ ich mich da auch wieder
ein. Und hier sehen wir – 3 Euro.
00:19:11.810 --> 00:19:16.190
Aber genau – diesmal schauen wir uns auch
mal wieder die Version[snummer] an. Das ist
00:19:16.190 --> 00:19:16.240
auch
00:19:16.240 --> 00:19:19.500
vom 7.Dezember, war bis vor 2 Stunden
auch noch die aktuellste, könnte mir gut
00:19:19.500 --> 00:19:22.520
vorstellen, dass gerade eine
neue Version rauskommt!
00:19:22.520 --> 00:19:24.610
Gelächter
00:19:24.610 --> 00:19:29.300
Aber ja, hier. Die Daten scheinen zu
stimmen, die TAN passt eigentlich auch.
00:19:29.300 --> 00:19:32.280
Und dann ja, würde ich sagen, dann
kann man das bestätigen jetzt.
00:19:32.280 --> 00:19:42.160
Kommen wir zurück… Auftrag
wurde entgegengenommen…
00:19:42.160 --> 00:19:47.670
und wenn man jetzt dann mal in
die Überweisungsdetails schaut,
00:19:47.670 --> 00:19:50.170
sieht man da, dass ich schon ein
paar fingierte Weihnachtsgeschenke
00:19:50.170 --> 00:19:54.150
bezahlt habe, im Rahmen der Untersuchung
hier. Und hier haben wir diesmal
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…
00:19:58.810 --> 00:20:13.710
Applaus
00:20:13.710 --> 00:20:18.190
Ja, genau. Und ja, der Betreff
hat sich auch geändert:
00:20:18.190 --> 00:20:21.210
„Einen Guten Rutsch für den 32C3.“
00:20:21.210 --> 00:20:23.100
Okay,
00:20:23.100 --> 00:20:27.310
jetzt bin ich doch ein bisschen schneller
fertiggeworden als ich gedacht habe,
00:20:27.310 --> 00:20:30.940
aber das bedeutet, dass wir dann
noch mehr Zeit für Fragen haben.
00:20:30.940 --> 00:20:34.510
Ja, was lässt sich zu App-basierten
TAN-Verfahren allgemein sagen:
00:20:34.510 --> 00:20:38.510
Die sind einfach konzeptionell schwach.
Die Schutzmechanismen von der pushTAN-App
00:20:38.510 --> 00:20:41.730
haben zwar zugenommen in der
aktuellen Version. Also die Callbacks
00:20:41.730 --> 00:20:45.680
lassen sich jetzt nicht mehr
trivial hooken; und dadurch
00:20:45.680 --> 00:20:47.750
kann man einfach Root bekommen
oder halt eben einfach alles machen.
00:20:47.750 --> 00:20:50.880
Letztendlich ist es halt ein
Katz-und-Maus-Spiel, das die Sparkasse
00:20:50.880 --> 00:20:53.460
oder auch jeder andere Hersteller
am Ende irgendwie verlieren wird.
00:20:53.460 --> 00:21:00.070
Die Root-Erkennung z.B. bringt eigentlich
hauptsächlich Ärger bei den Kunden ein;
00:21:00.070 --> 00:21:04.010
und vor allem hat die so hohe
False-Positives, dass die Bewertungen
00:21:04.010 --> 00:21:07.990
derart grottig sind, dass man sich bei
der Sparkasse echt fragen muss,
00:21:07.990 --> 00:21:10.500
ob das Verfahren für sie selber
auch überhaupt noch Sinn macht.
00:21:10.500 --> 00:21:11.800
Wenn man sich jetzt auch anschaut…
00:21:11.800 --> 00:21:15.540
Was ich eigentlich gemacht habe ist ja
total irre irgendwie. Also ich meine…
00:21:15.540 --> 00:21:19.900
Ich habe hauptsächlich Dinge umgangen,
die ein normaler Nutzer macht.
00:21:19.900 --> 00:21:24.990
Ich habe keinen echten Angriff damit
verhindert. Also jemand, der selbstständig
00:21:24.990 --> 00:21:28.100
sein Gerät rooten wird, dem wird verboten,
die pushTAN-App zu verwenden.
00:21:28.100 --> 00:21:32.500
Und wer selbstständig irgendwie Xposed
installiert, dem wird es auch verboten.
00:21:32.500 --> 00:21:37.490
Ein echter Angriff… der installiert doch
nicht das SU Binary. lacht
00:21:37.490 --> 00:21:40.760
Der würde was-weiß-ich
irgendwas platzieren,
00:21:40.760 --> 00:21:43.460
aber bestimmt nicht das SU-Binary
installieren. Also das Root
00:21:43.460 --> 00:21:46.720
ist gar nicht mal eine feste
Voraussetzung. Für den Angriff allein
00:21:46.720 --> 00:21:49.490
hätte es sogar gereicht, wenn
man einen Root-Exploit hat
00:21:49.490 --> 00:21:50.880
und dann Xposed platzieren kann.
00:21:50.880 --> 00:21:54.700
Da hat man z.B. auch keinen
Ärger mit der Root-Erkennung.
00:21:54.700 --> 00:21:57.620
Ja, ich hab’ noch ein paar Backup-Folien,
aber das können wir dann auch
00:21:57.620 --> 00:22:01.630
in die Diskussion einbauen. Dann bedanke
ich mich für eure Aufmerksamkeit!
00:22:01.630 --> 00:22:10.790
Applaus
00:22:10.790 --> 00:22:14.100
Herald: Vielen, vielen Dank, Vincent!
00:22:14.100 --> 00:22:17.930
Total super, und du hast auf jeden
Fall noch Zeit für Fragen gelassen.
00:22:17.930 --> 00:22:24.260
Genau – macht euch bitte kenntlich!
00:22:24.260 --> 00:22:29.340
Geht gerne vor zu den Mikro-Fahnen!
00:22:29.340 --> 00:22:34.110
Die Mikros 2 und 4 sind an.
Ich seh’ schon jemand[en] an Mikro 2?
00:22:34.110 --> 00:22:39.570
Nein? Du stehst da nur so. Okay.
lacht
00:22:39.570 --> 00:22:45.980
Wir geben euch mal noch ein
paar Minuten Zeit zum Überlegen.
00:22:45.980 --> 00:22:50.150
Und ich kucke ’mal nach oben!
00:22:50.150 --> 00:22:56.680
Lieber Mensch, der du Fragen aus dem Netz
einsammelst: ich seh’ dich gerade nicht,
00:22:56.680 --> 00:23:00.390
aber wenn du welche hast, dann
könntest du jetzt gerne eine vorlesen.
00:23:00.390 --> 00:23:06.100
Signal Angel: Dann mach’ ich das einfach
mal. Und zwar: seppsammy und shelter8
00:23:06.100 --> 00:23:09.590
wollen wissen: gibt es Schwächen
im Optik-TAN-Verfahren?
00:23:09.590 --> 00:23:14.220
Vincent: Also „Optik-TAN“ meint dann
wahrscheinlich irgendwie so Foto-TAN
00:23:14.220 --> 00:23:18.270
und QR-TAN. Also, „Optik-TAN“ weiß ich
jetzt nicht genau, ist es damit gemeint?
00:23:18.270 --> 00:23:21.380
Aber ich meine, das ist irgendwie das.
Ja, QR-TAN und Foto-TAN ist eigentlich
00:23:21.380 --> 00:23:25.050
ziemlich ähnlich; da scannt man dann
einen Code ab mit seinem Smartphone;
00:23:25.050 --> 00:23:31.570
und bekommt dann dadurch die TAN.
Das unterscheidet sich halt insofern,
00:23:31.570 --> 00:23:34.740
dass man das schwer auf einem Gerät
verwenden kann. Also ich kann natürlich
00:23:34.740 --> 00:23:38.710
den QR-Code nicht von meinem eigenen
Gerät abscannen. Deswegen ist das Szenario
00:23:38.710 --> 00:23:42.980
ein bisschen anders. Also, da sind
natürlich auch andere Schwächen vorhanden,
00:23:42.980 --> 00:23:46.140
wie z.B. dass man die App irgendwie
kopieren kann und sowas dergleichen.
00:23:46.140 --> 00:23:49.660
Aber es ist nicht ganz vergleichbar
mit dem Szenario das wir hier
00:23:49.660 --> 00:23:52.230
bei den App-basierten Verfahren haben.
00:23:52.230 --> 00:23:55.780
Herald: Dann jetzt gerne erst
eine Frage vom Mikrofon Nr.2.
00:23:55.780 --> 00:24:01.010
Frage: Ja, du hast beschrieben, wie die
App sich gegen Debugging –
00:24:01.010 --> 00:24:03.010
eine Analyse –
00:24:03.010 --> 00:24:07.970
schützt. Wie genau hast du dann aber die
Transaktionsdetails manipuliert, dass die
00:24:07.970 --> 00:24:11.910
erst falsch angezeigt und dann auch
falsch zur Bank übermittelt werden?
00:24:11.910 --> 00:24:18.010
Vincent: Also, das Problem ist, also gegen
Debugging schützen, das ist ja erstmal
00:24:18.010 --> 00:24:21.110
’ne Maßnahme gegen dynamische Analyse,
die also verhindern soll, dass jemand
00:24:21.110 --> 00:24:23.230
einfach so ’nen Angriff entwickeln kann.
00:24:23.230 --> 00:24:27.290
Also die… Den Angriff selbst
hab’ ich mit Xposed entwickelt,
00:24:27.290 --> 00:24:31.000
das ist halt ein hooking-Framework.
Das kann sehr leicht Java-Code hooken.
00:24:31.000 --> 00:24:34.600
Ein Real-World-Exploit würde
das wohl nicht so machen. Aber,
00:24:34.600 --> 00:24:38.560
ja… Für ’nen proof-of-concept war
das ’ne Möglichkeit, das zu machen.
00:24:38.560 --> 00:24:41.400
Also die ganzen Maßnahmen eigentlich
die da implementiert wurden,
00:24:41.400 --> 00:24:44.110
können nicht effektiv vor einem richtigen
Angriff schützen, sondern können…
00:24:44.110 --> 00:24:48.400
hauptsächlich… dienen hauptsächlich
dazu, dass die Sparkasse in einem Monat
00:24:48.400 --> 00:24:53.500
wieder sagen kann, ja der Angriff den
ich gemacht hatte funktioniert nicht mehr.
00:24:53.500 --> 00:24:55.450
Herald: Mikrofon Nr.4, bitte!
00:24:55.450 --> 00:25:01.550
Frage: Mich würde interessieren…
weil du hast ja gezeigt,
00:25:01.550 --> 00:25:04.320
wie diese App nach irgendwie
Xposed oder sowas scannt.
00:25:04.320 --> 00:25:09.240
Das Verfahren scheint mir grundsätzlich
ziemlich erbärmlich. Kann man sowas auch
00:25:09.240 --> 00:25:12.500
gescheit machen oder hat man
da einfach keine Chance?
00:25:12.500 --> 00:25:16.590
Vincent: Ja, das ist natürlich schon ein
bisschen schwierig das gescheit zu machen.
00:25:16.590 --> 00:25:19.310
Weil es müsste irgendwie
vertrauenswürdige Aufrufer geben.
00:25:19.310 --> 00:25:23.070
Also man müsste irgendwie festlegen
können, wer ist denn eigentlich erlaubt.
00:25:23.070 --> 00:25:27.660
Wer darf denn in meinem call
stack eigentlich alles drin sein.
00:25:27.660 --> 00:25:31.150
Also es ist schon ein bisschen
schwieriger. Fällt mir jetzt auch
00:25:31.150 --> 00:25:34.890
spontan erstmal nicht ein, wie
man das effektiv verhindern kann.
00:25:34.890 --> 00:25:37.730
Herald: Mikrofon Nr.1, bitte.
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.
00:25:42.260 --> 00:25:48.130
Ich fand’s auch sehr toll, dass rauskam,
dass in so einem Framework wie Android
00:25:48.130 --> 00:25:51.630
das Verteilen auf 2 Apps ja überhaupt
nichts bringt. Also ich denke das war
00:25:51.630 --> 00:25:54.550
einer von den zentralen Sachen,
die rauskamen. Meine Frage wäre:
00:25:54.550 --> 00:25:58.080
Wie schätzt du das ein, dass man
es auch im Android-Betriebssystem
00:25:58.080 --> 00:26:05.210
in Zukunft schafft, Apps mit einem
Verifikationsmechanismus auszustatten,
00:26:05.210 --> 00:26:09.470
und eher von Teilen des Betriebssystems
die auch nach dem Rooten das tun
00:26:09.470 --> 00:26:13.450
was sie tun sollten; diese App quasi für
sich alleine laufen. Das würde mir
00:26:13.450 --> 00:26:17.330
nach einem vielversprechenderen Ansatz
aussehen als das Konzept
00:26:17.330 --> 00:26:19.570
von 2 Apps und
einfach-ein-bisschen-Skripten.
00:26:19.570 --> 00:26:23.920
Vincent: Ja das greift jetzt natürlich
schon ziemlich weit. Auf was du anspielst,
00:26:23.920 --> 00:26:27.060
das erinnert mich so ein bisschen
an ARM TrustZone.
00:26:27.060 --> 00:26:30.090
Also da gibt’s ’ne Sichere Welt
00:26:30.090 --> 00:26:33.210
und ’ne Unsichere Welt. Es gibt ’ne
TrustZone bei ARM, gibt’s schon länger.
00:26:33.210 --> 00:26:36.140
Die wird aber bei Android nicht
durchgereicht. Also Samsung hat
00:26:36.140 --> 00:26:41.210
mit Knox sowas ähnliches. Das ist aber…
ja das muss man kaufen. Wie lange das
00:26:41.210 --> 00:26:43.470
bei Android irgendwie noch dauert
bis es sowas für alle gibt,
00:26:43.470 --> 00:26:46.150
kann ich dir nicht sagen. Also,
es dauert aber sicher noch.
00:26:46.150 --> 00:26:49.520
Herald: Gibt’s noch Netz-Fragen?
00:26:49.520 --> 00:26:52.600
Dann machen wir weiter mit Mikro 2 bitte!
00:26:52.600 --> 00:26:57.910
Frage: Also ich schließe aus deinen
Ausführungen, dass das fundamentale
00:26:57.910 --> 00:27:02.640
Problem ist, dass die Kombination von
2 Apps auf einem Gerät das Prinzip
00:27:02.640 --> 00:27:06.290
Zweifaktor-Authentifizierung
einfach ad absurdum führt.
00:27:06.290 --> 00:27:10.770
Und dass also Sicherheit insofern
nur besser werden kann,
00:27:10.770 --> 00:27:14.880
dass man wirklich auf 2 separate
Geräte, die dann eben auch
00:27:14.880 --> 00:27:16.860
separat kompromittiert werden
müssten, setzen wird.
00:27:16.860 --> 00:27:20.090
Vincent: Ja, genau. Das ist genau das.
Also hier hab’ ich auch ein Zitat,
00:27:20.090 --> 00:27:24.150
eigentlich sehr schön. Das ist irgendwie
nicht nur was, was ich irgendwie sage.
00:27:24.150 --> 00:27:27.780
Auch im BaFin-Journal ist es
im August schon erschienen:
00:27:27.780 --> 00:27:30.720
„Die TAN sollte auf keinem Fall auf
demselben Smartphone generiert werden,
00:27:30.720 --> 00:27:33.950
auf dem das Online-Banking stattfindet.
Hat ein Betrüger das Smartphone gehackt,
00:27:33.950 --> 00:27:38.130
so kann er dadurch auf beide Verfahren
zugreifen“. Also das ist irgendwie keine…
00:27:38.130 --> 00:27:41.330
das ist eigentlich ’ne Erkenntnis, die…
ich weiß nicht… vielen leuchtet das hier
00:27:41.330 --> 00:27:45.240
tatsächlich wahrscheinlich
einfach auch ein. Also…
00:27:45.240 --> 00:27:53.390
Gelächter, Applaus
00:27:53.390 --> 00:27:55.180
Herald: Bitte schön!
00:27:55.180 --> 00:27:58.800
Signal Angel: Einige Leute wollten
wissen – vielleicht ist das jetzt gerade
00:27:58.800 --> 00:28:01.640
beantwortet worden –
lacht
00:28:01.640 --> 00:28:04.280
ob es, wenn man 2 verschiedene
Verfahren verwendet,
00:28:04.280 --> 00:28:07.650
also die App und den Computer,
ob es dann sicher ist?
00:28:07.650 --> 00:28:10.940
Vincent: Also, dann hat’s eigentlich
im Prinzip ähnliche Probleme
00:28:10.940 --> 00:28:14.780
wie z.B. QR-TAN oder Foto-TAN.
Ist aber auf jeden Fall deutlich sicherer.
00:28:14.780 --> 00:28:19.000
Also wenn ich jetzt die pushTAN-App
mit meinem PC verwende, dann
00:28:19.000 --> 00:28:21.740
ist es nicht schlechter als SMS-TAN,
würde ich jetzt sagen.
00:28:21.740 --> 00:28:23.540
Oder, ja, auf jeden Fall vergleichbar.
00:28:23.540 --> 00:28:25.090
Herald: Dann nochmal Mikro Nr.1, bitte.
00:28:25.090 --> 00:28:30.680
Frage: Ja, also das ist auch wohl relativ
neu, weil aus eigener Erfahrung weiß ich,
00:28:30.680 --> 00:28:35.830
dass es da ursprünglich mal ’n Requirement
gegeben hat, so: bei mobile Banking
00:28:35.830 --> 00:28:40.090
darf nicht… also wenn
du mobileTAN benutzt,
00:28:40.090 --> 00:28:44.620
darfst du von deinem Handy
nicht die Transaktion starten,
00:28:44.620 --> 00:28:48.480
wo auch die SMS hingeht. Deswegen
haben die am Anfang so total billo
00:28:48.480 --> 00:28:51.310
halt die host names gefiltert von
dem mobile Netz, von den…
00:28:51.310 --> 00:28:53.940
V: Genau.
F: …von den Mobilfunkanbietern; und dann
00:28:53.940 --> 00:28:57.760
hat aber der Vendor, der die Software
gebaut hat, diese Sparkassen-App
00:28:57.760 --> 00:29:00.980
unter ’nem anderen Logo – nicht
Sparkasse – veröffentlicht,
00:29:00.980 --> 00:29:04.810
ohne diese Funktion. Und so
ist das da reingekommen.
00:29:04.810 --> 00:29:07.890
Die wissen schon ganz
genau, dass es Scheiße ist.
00:29:07.890 --> 00:29:09.400
Vincent: Ja,…
lacht
00:29:09.400 --> 00:29:13.950
Applaus
00:29:13.950 --> 00:29:17.230
Also ich hab’ hier noch ’n anderes Zitat.
00:29:17.230 --> 00:29:22.270
Also MaSi, das sind die Mindeststandards
für die Sicherheit von Internetzahlungen.
00:29:22.270 --> 00:29:24.750
Und die müssen von den Banken
umgesetzt werden. Dafür ist die Frist
00:29:24.750 --> 00:29:28.480
jetzt gerade ausgelaufen. Und
da gibt’s eben auch einen Punkt
00:29:28.480 --> 00:29:31.220
der schreibt starke Kunden-
Authentifizierung vor. Der Punkt
00:29:31.220 --> 00:29:34.960
war aber derart schwammig, da konnte man
alles interpretieren. Deswegen gab’s dann
00:29:34.960 --> 00:29:37.960
dazu irgendwann mal ein Q&A [eher:FAQ?],
die länger ist als die eigene Abfassung
00:29:37.960 --> 00:29:43.170
davon, was das eigentlich ist. Und da
steht dann auch drin, das war dann danach:
00:29:43.170 --> 00:29:46.120
„Allerdings muss das App-basierte
Sicherungsverfahren und das tatsächliche
00:29:46.120 --> 00:29:49.180
Online-Banking unabhängig voneinander
– also über verschiedene Geräte […] –
00:29:49.180 --> 00:29:54.640
erfolgen.“ Also es ist sowieso fraglich,
ob dieses Verfahren überleben darf.
00:29:54.640 --> 00:29:57.710
Herald: Eine ganz schnelle
noch von Mikrofon 3.
00:29:57.710 --> 00:30:01.480
Frage: Ja, darf ich fragen,
wie du dein Geld überweist?
00:30:01.480 --> 00:30:03.800
Bzw. was würdest du
für’n System empfehlen?
00:30:03.800 --> 00:30:07.640
Vincent: Also ich selbst verwende
chipTAN. Ich verwende es sogar
00:30:07.640 --> 00:30:11.830
tatsächlich auch mobil. Allerdings
eher wenn ich irgendwie
00:30:11.830 --> 00:30:17.040
mal länger irgendwo bin, oder sowas.
Also ich habe jetzt nicht so
00:30:17.040 --> 00:30:20.250
das Verlangen danach, jetzt überall
Überweisungen machen zu müssen. Also
00:30:20.250 --> 00:30:24.280
chipTAN kann ich eigentlich schon
empfehlen, von den TAN-Verfahren.
00:30:24.280 --> 00:30:25.360
F: Danke.
00:30:25.360 --> 00:30:27.860
Herald: Vielen, vielen Dank! Bitte
nicht böse sein, wenn ihr jetzt
00:30:27.860 --> 00:30:30.610
nicht drangekommen seid. Vincent hat mir
versprochen, dass er jetzt noch da ist
00:30:30.610 --> 00:30:33.820
und eure Fragen beantwortet.
Ich hoffe, das ist okay so. Super.
00:30:33.820 --> 00:30:36.110
Danke schön nochmal. Ein
ganz großer Applaus für dich!
00:30:36.110 --> 00:30:43.700
Applaus
00:30:43.700 --> 00:30:50.301
Abspannmusik
00:30:50.301 --> 00:30:54.201
Untertitel erstellt von c3subtitles.de
im Jahr 2016. Unterstütze uns!