*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!*