Vincent Haupert: (Un)Sicherheit von App-basierten TAN-Verfahren im Onlinebanking

32C3 Vorspannmusik

Herald: Vincent Haupert studiert in seinem
Dayjob, sozusagen, Informatik in Erlangen,

und macht da gerade seinen Master
mit Schwerpunkt in IT-Security.

Die Arbeit, die er uns aber
gleich vorstellen möchte,

hat er im Rahmen seiner Tätigkeit als
wissenschaftliche Hilfskraft gemacht,

und zwar zusammen mit seinem Kollegen
Tilo Müller. Dort hat er untersucht,

was es denn für Sicherheitslücken
bei App-basierten TAN-Verfahren gibt,

also im Bereich des Onlinebankings;
und die möchte er uns jetzt vorstellen.

Einen ganz großen, herzlichen
Applaus für Vincent bitte!

Applaus

Vincent: Ja, auch herzlich willkommen
von mir, also mein Name ist, wie gesagt,

Vincent Haupert, und ich habe
mir im vergangenen Herbst

mit meinem Kollegen Tilo Müller mal
angeschaut, wie es denn um die Sicherheit

von App-basierten TAN-Verfahren
im Onlinebanking bestellt ist;

und ja, der ein oder andere hat die
Geschichte vielleicht schon mitbekommen,

hat sie auf Heise gelesen und
so, und fragt sich vielleicht: ja,

was kommt denn jetzt da heute? Vor
2 Wochen habe ich einen Angriff von der,

äh, einen Angriff… lacht
einen Anruf von der Sparkasse bekommen

Gelächter
Applaus

Ja, der Herr Meier, den ich jetzt hier
einfach mal so nennen möchte,

hat mich da gefragt, was ich denn zwischen
Weihnachten und Neujahr mache… ja.

Zu dem Zeitpunkt, wollte er eben wissen:
muss er seine Presseabteilung jetzt schon

auf irgendetwas Neues gefasst machen,
oder nicht. Gelächter

Zu dem Zeitpunkt konnte ich es ganz
ehrlich gesagt noch nicht sagen,

Heute kann ich ihnen sagen: ich hoffe,
sie haben einen Entwurf gemacht,

das macht es danach leichter.

Gelächter
Applaus

Ja, Onlinebanking ist etwas, das
betrifft uns alle; es ist etabliert,

eine große Zahl der Deutschen verwendet
es, und ein besonderes Merkmal

von Onlinebanking ist, dass es schon seit
seinem Entstehen in den 1980er Jahren,

damals noch BTX-basiert,
ein Zweifaktor-Verfahren ist.

Also, man hatte auf der einen Seite immer
irgendwie einen Benutzernamen/Passwort,

und dann noch irgendein TAN-Verfahren.
Über die Zeit ist da ein ganzer Zoo

an TAN-Verfahren entstanden; meistens
gab es einfach Weiterentwicklungen,

aus Sicherheitsgründen. Heute werden
wir ein Verfahren sehen, das sich nicht

in diese Reihe begeben
kann. Ja. Im Prinzip läuft

Onlinebanking immer so ab, ich sage das
der Vollständigkeit halber hier nochmal:

man loggt sich im Onlinebanking-Portal
ein, mit seinem Benutzername/Passwort,

reicht dann eine Überweisung ein, und im
zweiten Schritt muss man das dann noch

mit einem TAN-Verfahren bestätigen. Das
ist nicht für jeden das gleiche; das kann

entweder noch die altgediente iTAN-
Liste sein, die aber langsam ausstirbt;

das SMS-TAN-Verfahren,
das auch seine Tücken hat,

wie man in den letzten
Monaten mitbekommen kann.

Insbesondere ein großer Verbündeter
ist die Telekom, lacht

und es gibt dann auch noch das
chipTAN-Verfahren, das auch recht

verbreitet ist. Das letzte Verfahren,
das chipTAN-Verfahren, adressiert

das Sicherheitsproblem im Onlinebanking
eigentlich schon ganz gut, aber,

wenn man den Kreditinstituten glaubt,
gibt es einen dringenden Wunsch

in der deutschen Bevölkerung,
seine Geldgeschäfte immer überall

machen zu können. Sei das in der U-Bahn,
im Restaurant, vielleicht auch hier,

gerade in diesem Vortrag. Macht jemand
gerade eine Überweisung, mal Hand hoch?

Gelächter
Ja.

Auf jeden Fall ist es dann so, wenn man
eine Überweisung überall machen will,

sarkastisch: dann will ich kein zweites
Gerät haben, denn das ist ja unbequem.

Deswegen haben die Banken ein
Gerät entdeckt, das jeder von uns

immer dabei hat, und das absolut
sicher ist – das Smartphone.

Gelächter
Applaus

Man hat jetzt keine zwei Geräte mehr,
nicht 2 voneinander unabhängigen Faktoren,

man hat eine Banking-App,
und man hat eine TAN-App.

Das funktioniert jetzt so: ich logge
mich mit meiner Banking-App

auf dem Smartphone ein und gebe eine
Überweisung auf. Im zweiten Schritt

muss ich dann wie gehabt die
Überweisung mit einer TAN bestätigen.

Jetzt nehme ich aber nicht meinen
Papierzettel her, mein chipTAN-Gerät,

sondern ich wechsle
zur TAN-App. Da gibt’s,

also da sind alle Banken mittlerweile ein
großer Fan davon eigentlich, das ist jetzt

nur eine Auswahl, ich weiß nicht ob es
noch mehr gibt, aber all diese Banken

haben ein App-basiertes TAN-
Verfahren im Angebot, und ich denke,

die die es noch nicht haben, sind bestimmt
auf dem Weg dahin, das zu machen.

Ich sehe jetzt schon den einen oder
anderen hier in den ersten Reihen,

bei denen sich dann die Stirn
runzelt bei dem Verfahren,

ich will aber trotzdem nochmal generell
das Angriffs-Szenario motivieren.

Also, Malware, oder Schadsoftware,
ist in den offiziellen App Stores

der Betriebssystemhersteller.
Das ist keine Fiktion!

Bei uns am Lehrstuhl in Erlangen
hat der Dominik Maier gezeigt,

dass sich der Google Play Store

nicht ausreichend gegen Schadsoftware
schützen kann. Also, die konkrete Aufgabe

von ihm war eigentlich,
in seiner Bachelorarbeit,

Schadsoftware in den Google
Play Store zu bekommen. Nur:

das war seine Bachelorarbeit… da ist er
nach ein paar Tagen zu seinem Betreuer

dann hingekommen und hat gesagt:
„Ey Tilo, ich bin fertig!“

Gelächter
Applaus

amüsiert: Und, was er gemacht hat:
er hat einen Root-Exploit gezippt, ja…

Gelächter

Also, er hat ihn gezippt und hochgeladen;
da war kein Passwort, nichts –

er hat ihn einfach gezippt.

Dass das aber nicht irgendwie nur
akademische, graue Theorie ist,

hat dieses Jahr so ziemlich gleichzeitig,
als wir diese App-TAN-Geschichte

gemacht haben, die App „Brain Test“
gezeigt. Das ist ein Spiel, und

das hat über 100.000 Downloads
gehabt, bis zu 500.000.

Und diese App hat genau das
gemacht, was das Angriffsszenario

auch für App-basierte TAN-Verfahren
ist. Nämlich: im offiziellen Store,

rootet das Gerät zuerst und
lädt dann Schadcode nach.

Wir hätten jetzt auch irgendeins von
den Kreditinstituten, die App-basiertes

TAN-Verfahren anbieten, nehmen können;
ich habe die Sparkasse genommen,

weil ich da a) ein Konto habe und
b) weil’s irgendwie die größte ist.

Und das waren auch die Ersten,
die das angeboten haben.

Deswegen haben wir uns angeguckt:
was kann man denn jetzt da machen?

Was gibt es denn da für
Angriffsszenarien für pushTAN?

Und was uns da als allererstes
ziemlich schnell eingefallen ist,

ist: wir könnten die App
irgendwie kopieren,

oder wir reversen das Protokoll und
implementieren unseren eigenen Client.

Das sind aber beides noch Angriffe,
die konzentrieren sich sehr stark

einfach nur auf die TAN-App.
Das eigentliche Problem

von App-basierten TAN-Verfahren,
also dass man den ersten Faktor

und den zweiten Faktor auf einem Gerät
hat, wird aber am besten dadurch betont,

wenn man eine Transaktionsmanipulation
durchführt. Sprich: wir manipulieren eine

vom Nutzer aufgegebene Transaktion
in Echtzeit, ohne dass er’s sehen kann.

Wie haben wir das gemacht, oder
wie war unser Szenario dafür?

Nochmal: wie läuft das ab?
Links ist die Sparkassen-App,

die verwende ich, um mich in meinem
Onlinebanking einzuloggen und dann

meine Überweisungsdaten auszufüllen,
und schicke das dann letztendlich ab.

Dann landet das Ganze beim Sparkassen-
Server, und der schickt dann eine TAN

an die pushTAN-App, die da rechts
dargestellt ist. Der Nutzer wird dann

dazu aufgefordert, in die pushTAN-App
zu wechseln, die dort dargestellte TAN

– nachdem er die Überweisungsdaten
natürlich kontrolliert hat – in die App

„Sparkasse“ zu übertragen. Das geht
mittlerweile, wie wir später sehen werden,

auch so automatisiert, dass man sich
fragt: warum gibt’s überhaupt noch 2 Apps?

Ja, gut. Was wir jetzt
machen: wir sagen einfach,

nachdem der Nutzer auf
‚Auftrag übermitteln‘ geht,

dann manipulieren wir die Daten.
Also wir ändern den Adressaten,

wir ändern den Betrag, und die
Sparkasse schickt dann natürlich

die Überweisungsdetails auch nochmal
an die TAN-App, und die werden dann

da nochmal dargestellt. Das heißt,
bevor die dann da angezeigt werden,

manipulieren wir die wieder
auf die originalen Daten,

und der Nutzer kann’s nicht sehen, und
bestätigt letztendlich eine Überweisung

mit einer TAN, was er gar nicht wollte.
Ja, da mussten wir erstmal überlegen:

was gibt es denn da eigentlich so für
Sicherheitsmerkmale bei den beiden Apps?

Also die Sparkassen-App selbst
ist eigentlich ein leichtes Fressen

für so einen Angriff; die hat ja
keine großen Schutzmaßnahmen.

Es gibt eine Root-Erkennung, es wird aber
lediglich dargestellt ein Warnhinweis,

und die macht also ansonsten nichts, man
kann die App dann normal weiterverwenden.

Auf der anderen Seite: die pushTAN-App
versucht, sich mit einer Vielzahl

an Maßnahmen gegen Analyse und gegen
Schadsoftware angeblich auch zu schützen.

Man merkt eigentlich schon, wenn man
hier sieht, die ganzen Maßnahmen,

ich glaube, die Sparkasse ist sich selber
nicht so ganz sicher, dass das wirklich

sicher zu kriegen ist. Die haben
halt eine Root-Erkennung,

die ist nicht wie bei der Sparkassen-App,
dass da ein Warnhinweis angezeigt wird;

also es wird verboten: wenn ein Root
erkannt wird, beendet sich die App,

und schützt sich eben auch gegen
die dynamische Analyse, statische Analyse,

weiß der Teufel nicht, was alles.
Und: es ist TÜV-geprüft!

Gelächter
Applaus

Von diesem Prädikat
merklich eingeschüchtert,

habe ich mir dann mal angeguckt, ja
– was gibt es denn da eigentlich wirklich

für Schutzmaßnahmen, wie sind denn die
umgesetzt? Es wurde recht schnell klar:

die Sparkasse selbst traut sich in Sachen
Sicherheit nicht so viel zu und hat

deswegen beim norwegischen Hersteller
Promon eingekauft. Die selber haben

eine Native-Library, die wird gleich
am Anfang der App geladen,

und ist dann quasi der Einsprungspunkt.

Die Library selbst ist verschlüsselt,
zum Teil, mit einem statischen Key

natürlich irgendwie, und ist obfuskiert,
ist also ein ziemlicher Hass, sich die

anzuschauen. Aber es gibt

– also damit man die Library nicht einfach
heraus patcht, also sagt: „Ja gut, dann

mach’ ich das Ding halt raus“ –
haben die Strings aus der Java-Logik

in die Library verlagert, die ja
wiederum verschlüsselt ist.

Die Library selbst setzt dann
statische, finale Felder

während der Laufzeit mit diesen Strings
und werden dann halt normal verwendet.

Oder sie werden über einen Index
abgerufen, mit der Methode getString.

Also das verhindert… also macht’s
zumindest Aufwand, diese Library

einfach rauszuziehen und
ohne die dann klarzukommen.

Ja die erkennt, wie gesagt,
Root, Debugger, alles Mögliche.

Aber die behandelt die Erkennung nicht.

Das liegt einfach daran, die wollen
eine Library verkaufen, die soll

für alles und jeden gehen, ne? Also die
ist nicht personalisiert auf diese App.

So ist es dann implementiert. Stattdessen
gibt’s im Java-Code callbacks

für die verschiedenen einzelnen events.
Also z.B. Debugger, oder eben Root.

Die App selbst implementiert
dann eben dieses Interface und,

wenn das erkannt wird, dann
wird der Code aufgerufen.

Z.B. hier unten ist dargestellt,
der Rooting-Status. Da steht

in dem Parameter z dann eben drin,
ob es gerootet wurde oder nicht.

Und dann kommt da so’n Texthinweis,
und danach beendet sich die App.

Ja, was haben wir gemacht:
Wenn dieses event kommt,

dann brechen wir die Methode immer ab
und dann läuft die App einfach weiter.

Das Ganze ist besonders paradox, diese
Library scheint keinen Status zu haben.

Die liefert einfach weiter Strings aus,
obwohl schon Root detected wurde.

Das hat mich wirklich überrascht,
dass es so einfach war. lacht

Applaus

Ja, dann schauen wir uns mal an, wie
funktioniert denn das jetzt konkret.

Also hier, als allererstes, die
Sparkassen-App. Das sieht man jetzt,

wie man sich eben anmeldet. Mit seinem
Passwort, das man mal selbst vergeben hat.

Und es wird ja auch ein Hinweis angezeigt
dass das Gerät gerootet ist, aber

wie gesagt, es hat weiter keine
Konsequenzen. In dem Fall habe ich

dann eine Überweisung an das Finanzamt mit
meiner hohen Einkommenssteuer von 10 Cent

ausgelöst. Und im nächsten Schritt… also…

dann haben wir die Überweisung eben
manipuliert, die Daten im Hintergrund,

man sieht es nicht. Und hier wird man dann
dazu aufgefordert, in die pushTAN-App

zu wechseln, um dann
dort die TAN abzurufen.

Das machen wir auch, loggen uns
wieder mit unserem Passwort,

diesmal in der pushTAN-App ein.
Wie groß die Wahrscheinlichkeit ist,

dass das das gleiche Passwort
ist, können wir uns denken.

Und dann schauen wir uns die
Überweisungsdetails an. 10 Cent…

sagen wir jetzt einfach mal die IBAN hat
sich jetzt wahrscheinlich keiner gemerkt,

aber das ist auch die gleiche.
Und ja, schaut gut aus.

Das geben wir frei. TAN übertragen an
Sparkasse. Jetzt merken wir uns noch

die letzten 2 Stellen der TAN, das ist 32,

dann übertragen wir die und der Auftrag
wird freigegeben in der Sparkassen-App.

Wenn man dann später irgendwann mal
in die Umsatz-Details reinschaut, dann

stellt man fest: „Hey, da, mit
der TAN mit der Endstelle 32,

da wurde ein Betrag von 13,37 Euro
überwiesen, nicht von 10 Cent. Und

die gingen auch nicht ans Finanzamt,
die gingen an Vincent Haupert. Gut…

Jetzt… jeder der die Geschichte kennt,
der kennt auch was danach kam.

Stellungnahme der Sparkasse,
nachdem es auf Heise war: „Ey,

das ist ja ’ne alte Version, das
geht doch alles gar nicht mehr“.

Es gibt da jetzt ’ne neue Version
seit dem 16.10. Wir haben

am 23.Oktober veröffentlicht.
Das ist jetzt nicht mehr möglich.

Gut. Eigentlich ist es nichts Neues für
uns. Haben wir auch schon gesagt

in unserer Ausarbeitung. Die
hat die Sparkasse anscheinend

nicht so aufmerksam gelesen. Und wir
haben damals auch schon gesagt:

„Es gibt in der aktuellen Version
wohl… die Art und Weise,

wie wir den Angriff gemacht haben… in der
neuen Version funktioniert das anders,

wir können das nicht ganz genauso machen;
mit einem entsprechenden Mehraufwand

können wir den Angriff aber
wieder möglich machen.“

Ja, schau’n wir halt mal! lacht
Gelächter

Applaus

Um jetzt einen Angriff gegen die
neue Version machen zu wollen,

muss man sich fragen: Was ist
denn da eigentlich anders jetzt?

Also man hat auch bei der Sparkasse
oder bei Promon realisiert, dass

die Java-callbacks ungefähr genauso sind,
wie wenn man mit einem Geldtransporter

vor die Sparkasse fährt, und dann
dem Praktikanten die Geldsäcke

in die Hand drückt und einfach
wegfährt. Deswegen gibt es jetzt

keine Java-callbacks mehr.
Stattdessen stürzt die App ab,

wenn sie z.B. Root erkennt, oder
auch Debugger, was auch immer,

und öffnet dann eine Seite im Browser.
Dadurch lässt sich die Root-Erkennung

nicht mehr trivial umgehen. Ansonsten

werden auch hooking-Frameworks
erkannt. Also wir haben den Angriff

als proof-of-concept mit Xposed
realisiert. D.h. das würde jetzt

auch nicht mehr gehen. Ja, schlecht.

Gut, um den Angriff jetzt wieder
realisieren zu können, müssen wir also

2 Sachen machen. Wir müssen einmal die
Root-Erkennung umgehen und einmal

die Xposed-Erkennung umgehen.

Fangen wir mit Root an. Wie
funktioniert die Root-Erkennung?

Und ich bin bisher eigentlich gut bei den
Sicherheits-features dieser App gefahren,

mir einfach vorzustellen, wie würde ich es
machen. Also was ist der einfachste Weg

Root zu erkennen. Also: was werden die
wohl machen? Die suchen im Dateisystem

nach irgendwelchen Sachen, die für SU
charakteristisch sind. Dann habe ich mir

die Syscalls mal angeschaut – ja und klar,
genau das machen die. lacht

Die schauen einfach z.B.
ist /system/bin/su vorhanden?

Oder /system/xbin/su? Ja, wenn
ich das jetzt in /vinc umbenenne,

dann geht sie, die App, schon wieder.

Applaus

Das ist aber natürlich blöd, weil ich will
ja weiterhin für meine anderen Apps

eigentlich Root haben. Und
deswegen, wenn ich die umbenenne,

dann können die natürlich auch kein
SU mehr ausführen. Das Lustige ist ja,

man führt ja nicht /system/xbin/su aus,
sondern man gibt ja nur SU ein. Das Ganze

ist der PATH-Variable zu verdanken,
die in Oslo aber nicht bekannt ist.

Deswegen ich hab das Ganze auf
Android Marshmallow gemacht,

und da will man eigentlich
sowieso Systemless SU haben.

Und das mounted eine eigene Partition
und trägt sich in die PATH-Variable ein

– und tadaaa! – die pushTAN-App
geht wieder auf.

Applaus

Ein bisschen paradoxer wird es aber
immer noch vor dem Hintergrund,

dass es die Sparkassen-App besser
macht. Die erkennt das Root nämlich.

Und die haben keine Lösung für
was-weiß-ich wieviel Tausend eingekauft.

Also bei Promon würde ich jetzt
mal in den Flugmodus gehen,

sonst kommt da gleich ein Anruf.

Ja, als nächstes: wie funktioniert
die Xposed-Erkennung?

Ja, wieder gleiches Spiel, würde
ich sagen. Schauen wir doch mal,

was… die werden wieder nach irgendwelchen
charakteristischen Sachen

für Xposed suchen. Ja, so schaut es dann
aus: Das sind halt ein paar Sachen,

die Xposed platziert beim Installieren.

Das müssen wir jetzt irgendwie loswerden.
Und Xposed muss danach aber noch gehen.

Die ersten 4 Sachen sind irgendwie eh
Sachen, die kann man entweder löschen

oder umbenennen. Und dann
sind die schon mal weg.

Dann gibt’s hier die anderen 3 Dateien,
die braucht man schon irgendwie;

ja, die benennen wir halt um. Und

untereinander müssen die Abhängigkeiten
natürlich auch angepasst werden.

Und da hab’ ich gedacht: „Ja, jetzt
geht’s“. Es hätte mich nicht überrascht

wenn’s funktioniert. Reicht aber
noch nicht ganz. Das ist sogar

tatsächlich ein bisschen besser
gemacht. Die schauen halt selber

in dem executable file nach,
wo auch die ganze Dalvik-VM

und was-weiß-ich-was drin ist, und
Zygote, mit dem ja Xposed arbeitet;

und wenn dann da drinnen Xposed
mit großem oder kleinem X drinsteht,

dann ist wohl Xposed installiert. Ja,
letztendlich hab’ ich das Ding einfach

neu kompiliert und schon ging’s wieder.

Applaus

Dann schauen wir uns das doch mal an, ne?

Also wieder gleiches Spiel…

Wir öffnen die Sparkassen-App,
geben da unser Passwort ein…

Diesmal, um ganz auf Nummer sicher zu
gehen, schauen wir uns vorher nochmal an,

welche Version ist denn das, eigentlich?
Nicht dass dann danach irgendeiner sagt:

„Es war nicht die aktuelle Version“.
Also hier sehen wir, das ist die Version

vom 7.Dezember, also das war
die aktuellste bis vor 2 Stunden.

Gelächter, Applaus

Als nächstes füllen wir wieder
unsere Überweisung aus,

diesmal nicht ans Finanzamt,
sondern an die Uni-Bibliothek Erlangen.

Ich habe nämlich meine Benutzerkarte
verloren und brauche deshalb eine neue,

und die kommt nicht for free,
sondern kostet 3 Euro.

Ihr seht schon, mein Konto war
nicht so hoch gefüllt, ich musste

einen Betrag wählen, der irgendwie
auch noch in meinem Limit geht.

Aber jetzt öffnet sich hier
automatisch schon die pushTAN-App,

also die Integration hat
tollerweise zugenommen.

Jetzt logg’ ich mich da auch wieder
ein. Und hier sehen wir – 3 Euro.

Aber genau – diesmal schauen wir uns auch
mal wieder die Version[snummer] an. Das ist

auch

vom 7.Dezember, war bis vor 2 Stunden
auch noch die aktuellste, könnte mir gut

vorstellen, dass gerade eine
neue Version rauskommt!

Gelächter

Aber ja, hier. Die Daten scheinen zu
stimmen, die TAN passt eigentlich auch.

Und dann ja, würde ich sagen, dann
kann man das bestätigen jetzt.

Kommen wir zurück… Auftrag
wurde entgegengenommen…

und wenn man jetzt dann mal in
die Überweisungsdetails schaut,

sieht man da, dass ich schon ein
paar fingierte Weihnachtsgeschenke

bezahlt habe, im Rahmen der Untersuchung
hier. Und hier haben wir diesmal

4,20 Euro, ich hätte auch 42 Euro genommen,
wenn ich soviel Geld noch gehabt hätte. Aber…

Applaus

Ja, genau. Und ja, der Betreff
hat sich auch geändert:

„Einen Guten Rutsch für den 32C3.“

Okay,

jetzt bin ich doch ein bisschen schneller
fertiggeworden als ich gedacht habe,

aber das bedeutet, dass wir dann
noch mehr Zeit für Fragen haben.

Ja, was lässt sich zu App-basierten
TAN-Verfahren allgemein sagen:

Die sind einfach konzeptionell schwach.
Die Schutzmechanismen von der pushTAN-App

haben zwar zugenommen in der
aktuellen Version. Also die Callbacks

lassen sich jetzt nicht mehr
trivial hooken; und dadurch

kann man einfach Root bekommen
oder halt eben einfach alles machen.

Letztendlich ist es halt ein
Katz-und-Maus-Spiel, das die Sparkasse

oder auch jeder andere Hersteller
am Ende irgendwie verlieren wird.

Die Root-Erkennung z.B. bringt eigentlich
hauptsächlich Ärger bei den Kunden ein;

und vor allem hat die so hohe
False-Positives, dass die Bewertungen

derart grottig sind, dass man sich bei
der Sparkasse echt fragen muss,

ob das Verfahren für sie selber
auch überhaupt noch Sinn macht.

Wenn man sich jetzt auch anschaut…

Was ich eigentlich gemacht habe ist ja
total irre irgendwie. Also ich meine…

Ich habe hauptsächlich Dinge umgangen,
die ein normaler Nutzer macht.

Ich habe keinen echten Angriff damit
verhindert. Also jemand, der selbstständig

sein Gerät rooten wird, dem wird verboten,
die pushTAN-App zu verwenden.

Und wer selbstständig irgendwie Xposed
installiert, dem wird es auch verboten.

Ein echter Angriff… der installiert doch
nicht das SU Binary. lacht

Der würde was-weiß-ich
irgendwas platzieren,

aber bestimmt nicht das SU-Binary
installieren. Also das Root

ist gar nicht mal eine feste
Voraussetzung. Für den Angriff allein

hätte es sogar gereicht, wenn
man einen Root-Exploit hat

und dann Xposed platzieren kann.

Da hat man z.B. auch keinen
Ärger mit der Root-Erkennung.

Ja, ich hab’ noch ein paar Backup-Folien,
aber das können wir dann auch

in die Diskussion einbauen. Dann bedanke
ich mich für eure Aufmerksamkeit!

Applaus

Herald: Vielen, vielen Dank, Vincent!

Total super, und du hast auf jeden
Fall noch Zeit für Fragen gelassen.

Genau – macht euch bitte kenntlich!

Geht gerne vor zu den Mikro-Fahnen!

Die Mikros 2 und 4 sind an.
Ich seh’ schon jemand[en] an Mikro 2?

Nein? Du stehst da nur so. Okay.
lacht

Wir geben euch mal noch ein
paar Minuten Zeit zum Überlegen.

Und ich kucke ’mal nach oben!

Lieber Mensch, der du Fragen aus dem Netz
einsammelst: ich seh’ dich gerade nicht,

aber wenn du welche hast, dann
könntest du jetzt gerne eine vorlesen.

Signal Angel: Dann mach’ ich das einfach
mal. Und zwar: seppsammy und shelter8

wollen wissen: gibt es Schwächen
im Optik-TAN-Verfahren?

Vincent: Also „Optik-TAN“ meint dann
wahrscheinlich irgendwie so Foto-TAN

und QR-TAN. Also, „Optik-TAN“ weiß ich
jetzt nicht genau, ist es damit gemeint?

Aber ich meine, das ist irgendwie das.
Ja, QR-TAN und Foto-TAN ist eigentlich

ziemlich ähnlich; da scannt man dann
einen Code ab mit seinem Smartphone;

und bekommt dann dadurch die TAN.
Das unterscheidet sich halt insofern,

dass man das schwer auf einem Gerät
verwenden kann. Also ich kann natürlich

den QR-Code nicht von meinem eigenen
Gerät abscannen. Deswegen ist das Szenario

ein bisschen anders. Also, da sind
natürlich auch andere Schwächen vorhanden,

wie z.B. dass man die App irgendwie
kopieren kann und sowas dergleichen.

Aber es ist nicht ganz vergleichbar
mit dem Szenario das wir hier

bei den App-basierten Verfahren haben.

Herald: Dann jetzt gerne erst
eine Frage vom Mikrofon Nr.2.

Frage: Ja, du hast beschrieben, wie die
App sich gegen Debugging –

eine Analyse –

schützt. Wie genau hast du dann aber die
Transaktionsdetails manipuliert, dass die

erst falsch angezeigt und dann auch
falsch zur Bank übermittelt werden?

Vincent: Also, das Problem ist, also gegen
Debugging schützen, das ist ja erstmal

’ne Maßnahme gegen dynamische Analyse,
die also verhindern soll, dass jemand

einfach so ’nen Angriff entwickeln kann.

Also die… Den Angriff selbst
hab’ ich mit Xposed entwickelt,

das ist halt ein hooking-Framework.
Das kann sehr leicht Java-Code hooken.

Ein Real-World-Exploit würde
das wohl nicht so machen. Aber,

ja… Für ’nen proof-of-concept war
das ’ne Möglichkeit, das zu machen.

Also die ganzen Maßnahmen eigentlich
die da implementiert wurden,

können nicht effektiv vor einem richtigen
Angriff schützen, sondern können…

hauptsächlich… dienen hauptsächlich
dazu, dass die Sparkasse in einem Monat

wieder sagen kann, ja der Angriff den
ich gemacht hatte funktioniert nicht mehr.

Herald: Mikrofon Nr.4, bitte!

Frage: Mich würde interessieren…
weil du hast ja gezeigt,

wie diese App nach irgendwie
Xposed oder sowas scannt.

Das Verfahren scheint mir grundsätzlich
ziemlich erbärmlich. Kann man sowas auch

gescheit machen oder hat man
da einfach keine Chance?

Vincent: Ja, das ist natürlich schon ein
bisschen schwierig das gescheit zu machen.

Weil es müsste irgendwie
vertrauenswürdige Aufrufer geben.

Also man müsste irgendwie festlegen
können, wer ist denn eigentlich erlaubt.

Wer darf denn in meinem call
stack eigentlich alles drin sein.

Also es ist schon ein bisschen
schwieriger. Fällt mir jetzt auch

spontan erstmal nicht ein, wie
man das effektiv verhindern kann.

Herald: Mikrofon Nr.1, bitte.

Frage: Vielen Dank. Bin ich zu hören? Ja.
Vielen Dank für die schöne Demonstration.

Ich fand’s auch sehr toll, dass rauskam,
dass in so einem Framework wie Android

das Verteilen auf 2 Apps ja überhaupt
nichts bringt. Also ich denke das war

einer von den zentralen Sachen,
die rauskamen. Meine Frage wäre:

Wie schätzt du das ein, dass man
es auch im Android-Betriebssystem

in Zukunft schafft, Apps mit einem
Verifikationsmechanismus auszustatten,

und eher von Teilen des Betriebssystems
die auch nach dem Rooten das tun

was sie tun sollten; diese App quasi für
sich alleine laufen. Das würde mir

nach einem vielversprechenderen Ansatz
aussehen als das Konzept

von 2 Apps und
einfach-ein-bisschen-Skripten.

Vincent: Ja das greift jetzt natürlich
schon ziemlich weit. Auf was du anspielst,

das erinnert mich so ein bisschen
an ARM TrustZone.

Also da gibt’s ’ne Sichere Welt

und ’ne Unsichere Welt. Es gibt ’ne
TrustZone bei ARM, gibt’s schon länger.

Die wird aber bei Android nicht
durchgereicht. Also Samsung hat

mit Knox sowas ähnliches. Das ist aber…
ja das muss man kaufen. Wie lange das

bei Android irgendwie noch dauert
bis es sowas für alle gibt,

kann ich dir nicht sagen. Also,
es dauert aber sicher noch.

Herald: Gibt’s noch Netz-Fragen?

Dann machen wir weiter mit Mikro 2 bitte!

Frage: Also ich schließe aus deinen
Ausführungen, dass das fundamentale

Problem ist, dass die Kombination von
2 Apps auf einem Gerät das Prinzip

Zweifaktor-Authentifizierung
einfach ad absurdum führt.

Und dass also Sicherheit insofern
nur besser werden kann,

dass man wirklich auf 2 separate
Geräte, die dann eben auch

separat kompromittiert werden
müssten, setzen wird.

Vincent: Ja, genau. Das ist genau das.
Also hier hab’ ich auch ein Zitat,

eigentlich sehr schön. Das ist irgendwie
nicht nur was, was ich irgendwie sage.

Auch im BaFin-Journal ist es
im August schon erschienen:

„Die TAN sollte auf keinem Fall auf
demselben Smartphone generiert werden,

auf dem das Online-Banking stattfindet.
Hat ein Betrüger das Smartphone gehackt,

so kann er dadurch auf beide Verfahren
zugreifen“. Also das ist irgendwie keine…

das ist eigentlich ’ne Erkenntnis, die…
ich weiß nicht… vielen leuchtet das hier

tatsächlich wahrscheinlich
einfach auch ein. Also…

Gelächter, Applaus

Herald: Bitte schön!

Signal Angel: Einige Leute wollten
wissen – vielleicht ist das jetzt gerade

beantwortet worden –
lacht

ob es, wenn man 2 verschiedene
Verfahren verwendet,

also die App und den Computer,
ob es dann sicher ist?

Vincent: Also, dann hat’s eigentlich
im Prinzip ähnliche Probleme

wie z.B. QR-TAN oder Foto-TAN.
Ist aber auf jeden Fall deutlich sicherer.

Also wenn ich jetzt die pushTAN-App
mit meinem PC verwende, dann

ist es nicht schlechter als SMS-TAN,
würde ich jetzt sagen.

Oder, ja, auf jeden Fall vergleichbar.

Herald: Dann nochmal Mikro Nr.1, bitte.

Frage: Ja, also das ist auch wohl relativ
neu, weil aus eigener Erfahrung weiß ich,

dass es da ursprünglich mal ’n Requirement
gegeben hat, so: bei mobile Banking

darf nicht… also wenn
du mobileTAN benutzt,

darfst du von deinem Handy
nicht die Transaktion starten,

wo auch die SMS hingeht. Deswegen
haben die am Anfang so total billo

halt die host names gefiltert von
dem mobile Netz, von den…

V: Genau.
F: …von den Mobilfunkanbietern; und dann

hat aber der Vendor, der die Software
gebaut hat, diese Sparkassen-App

unter ’nem anderen Logo – nicht
Sparkasse – veröffentlicht,

ohne diese Funktion. Und so
ist das da reingekommen.

Die wissen schon ganz
genau, dass es Scheiße ist.

Vincent: Ja,…
lacht

Applaus

Also ich hab’ hier noch ’n anderes Zitat.

Also MaSi, das sind die Mindeststandards
für die Sicherheit von Internetzahlungen.

Und die müssen von den Banken
umgesetzt werden. Dafür ist die Frist

jetzt gerade ausgelaufen. Und
da gibt’s eben auch einen Punkt

der schreibt starke Kunden-
Authentifizierung vor. Der Punkt

war aber derart schwammig, da konnte man
alles interpretieren. Deswegen gab’s dann

dazu irgendwann mal ein Q&A [eher:FAQ?],
die länger ist als die eigene Abfassung

davon, was das eigentlich ist. Und da
steht dann auch drin, das war dann danach:

„Allerdings muss das App-basierte
Sicherungsverfahren und das tatsächliche

Online-Banking unabhängig voneinander
– also über verschiedene Geräte […] –

erfolgen.“ Also es ist sowieso fraglich,
ob dieses Verfahren überleben darf.

Herald: Eine ganz schnelle
noch von Mikrofon 3.

Frage: Ja, darf ich fragen,
wie du dein Geld überweist?

Bzw. was würdest du
für’n System empfehlen?

Vincent: Also ich selbst verwende
chipTAN. Ich verwende es sogar

tatsächlich auch mobil. Allerdings
eher wenn ich irgendwie

mal länger irgendwo bin, oder sowas.
Also ich habe jetzt nicht so

das Verlangen danach, jetzt überall
Überweisungen machen zu müssen. Also

chipTAN kann ich eigentlich schon
empfehlen, von den TAN-Verfahren.

F: Danke.

Herald: Vielen, vielen Dank! Bitte
nicht böse sein, wenn ihr jetzt

nicht drangekommen seid. Vincent hat mir
versprochen, dass er jetzt noch da ist

und eure Fragen beantwortet.
Ich hoffe, das ist okay so. Super.

Danke schön nochmal. Ein
ganz großer Applaus für dich!

Applaus

Abspannmusik

Untertitel erstellt von c3subtitles.de
im Jahr 2016. Unterstütze uns!