*34c3 intro*
Herald: Der kommende Vortag ist von einem alten Bekannten, der schon zum 32C3 und
zum 33C3 uns in eine wundersame Welt entführt hat voller mobiler Endgeräte und
unsicherer Verbidungen und dem Vertrauen was wir daran stecken. Er ist Doktorrand
an der Uni Erlangen-Nürnberg – die hat auch einen langen Namen, den ich nicht
aufgeschrieben habe. Er ist Doktorrand der Informatik und interessiert sich besonders
für die Sicherheit von Mobilgeräten und wird uns heute die fabelhafte Welt des
Mobilbankings näher bringen. Begrüßt mit mir Vincent Haupert.
*Applaus*
Vincent: Herzlichen Dank für die Einführung.
Fabelhaft ist ein sehr vielschichtiges Wort. An dieser Stelle
möchte ich zuerst einmal die fabelhafte Zusammenarbeit mit meinem Kollegen Nicolas
Schneider hervorheben ohne den diese Arbeit hier in der Form nicht möglich
gewesen wäre. Herzlichen Dank an ihn.
*Applaus*
Onlinebanking – ich denke mal so gut wie
jeder hier dürfte es machen – ist hinlänglich bekannt. Ist seit jeher im
PIN/TAN Verfahren seitdem es von vor 30 Jahren. Ihr erster
Faktor ist wie immer man loggt sich auch Onlinebanking Portal ein mit seinem
Benutzername und Passwort. Danach muss man eine Transaktion aufgeben mit einer
IBAN und mit einem Betrag. Im zweiten Schritt hat man dann irgendein TAN
Verfahren mit dem man die Transaktion bestätigen muss. Das ist ganz klares
Sicherheitselement das es seit Anfang des Onlinebanking gibt. Und die Art und Weise
wie man eben die TAN generiert, empfängt, abliest ist recht unterschiedlich. Die
ersten drei Verfahren die man jetzt hier auf dieser Liste sieht das iTAN Verfahren,
smsTAN Verfahren und chipTAN Verfahren sind hauptsächlich aus der Motivation
entstanden, dass es relativ viele Schadensfälle in dem Bereich gab, also
Phishing vor allem, und mit chipTAN ist man quasi an den Zenit an gereicht /
erlangt. Technisch kann man das eigentlich kaum noch besser machen. Gibt es natürlich
auch noch andere Aspekte wie Benutzerfreundlichkeit die da wichtig
sind. Deswegen gingen die Verfahren wie photoTAN oder auch appTAN gehen dann
eigentlich mehr in die Richtung dass sie die Benutzerfreundlichkeit adressieren
wollen – was auch durchaus legitim ist. Per se habe ich eigentlich gar nichts
gegen App basierte TAN Verfahren. Solange man zwei Geräte verwendet.
Also wenn man zwei Geräte Authentifizierung macht hat man ja immer
noch den Schutz, dass, wenn ein Gerät kompromittiert ist, das andere zumindest
nicht automatisch mit in Mitleidenschaft gezogen wird. Von daher ist es durchaus
legitim. Ich kann mich erinnern vor zwei Jahren als ich hier den Talk gehalten
habe, wurde ich nach photoTAN gefragt und hab noch gesagt das ist ein relativ
solides Verfahren, weil es ja implizit eigentlich forciert, dass man zwei Geräte
verwendet. Dann muss man ja von einem anderen Gerät abscannen und das generiert
dann die TAN. Dann gibts halt die Verfahren die pushTAN Verfahren bzw. die,
die über zwei Apps realisiert sind: also eine Banking App die andere die TAN App.
Das gibt es jetzt mittlerweile seit Jahren. Und das Paradoxe ist, dass man
mittlerweile auch photoTAN auf einem Gerät machen kann. Da kann man zwar nichts mehr
abscannen erkennen, sondern kommunizieren einfach untereinander, aber das zeigt
eigentlich erst mal wie abstrus es wird. Aber eigentlich redet auch heute keiner
mehr über Zwei-App-Verfahren. Vielleicht war das auch nur eine Art und Weise um uns
daran zu gewöhnen, dass es eigentlich keine richtige Zwei-Faktor-
Authentifizierung mehr gibt. Und eigentlich will heute jeder ein Ein-App-
Verfahren implementieren. Das ist insofern eigentlich bemerkenswert, weil das SMS TAN
Verfahren, wenn man sich das mal anschaut, hat eine Geräte-Entwicklung durchgemacht
von einem Spezialgerät hin zu einem Mehrzweckgerät. Also heute empfängt jeder
seine SMS auf einem Smartphone. Und das ist im Prinzip auf eine bestimmte Art und
Weise auch eine App mit der man das empfängt. Und damals war es dann das erste
Mal möglich, dass man von einem Gerät aus eine Transaktion aufgibt und bestätigt.
Und da hat die deutsche Kreditwirtschaft weise 2008 schon erkannt, dass das keine
so gute Idee ist. "Dies impliziert bereits, dass die
Verwendung des mobileTAN Verfahrens zum Beispiel nur ein mobiles Smartphone für
beide Kommunikation Strecken nicht zulässig ist und daher den
Kundenbedingungen für das Online-Banking explizit ausgeschlossen wird." "Dies
impliziert bereits" so ist ja eh klar. Jetzt frage ich mich natürlich: Wo ist
denn da jetzt der Unterschied? Also hier wird auch alles auf einem Gerät gemacht
und das habe ich vor zwei Jahren dann auch gezeigt: habe einen Angriff auf das
pushTAN Verfahren gezeigt mit einer Transaktionsmanipulation. Das hat hingegen
die Sparkasse nicht so richtig beeindruckt. Die haben gesagt: "Ja das
waren eigentlich alles nur Laborbedingungen – das geht in Wirklichkeit
gar nicht. Und das funktioniert nur bei genau einem Gerät, genau einer App und bei
genau einer Version" und "jedes Mal wenn wir eine neue Version herausbringen ist
das ein hoher individueller und manuelle Aufwand." Und genau dies werden wir heute adressieren.
*Glächter und Applaus*
Jetzt habe ich ja vorhin gesagt so bei smsTAN hat man gesagt "ja das machen wir
nicht, das ist nicht sicher." Und jetzt muss man sich fragen was ist denn dann
eigentlich anders bei diesen Apps? Da gibt es eine ganze Reihe von Eigenschaft, aber
ich denke wichtig ist diese Absicherung durch Dritte. Und zwar gibt es
mittlerweile einen recht großen Markt an Drittanbietern die App-Härtung und App-
Sicherheit verkaufen. Also Drittanbieter Produkte und das hier ist nur eine kleine
Auswahl. Und denjenigen die wir uns heute etwas genauer anschauen werden ist Promon.
Promon hat das Produkt Promon SHIELD. Die Information die hier stehen sind allesamt
von der Website. Der Zweck von Promon SHIELD ist Schutz von Apps in nicht
vertrauenswürdigen Umgebungen. Das Ganze ist universal, d.h. es ist egal
was für eine App es ist, und es ist plattformunabhängig. Also es geht unter
Android und iOS und die haben auch Lösungen für Windows. Es ist anwendbar
innerhalb von wenigen Minuten. Das Zitat is aus dem Video:
"Es Erkennt und verhindert jede Gefahr in Echtzeit und reagiert, indem es die
notwendigen Schritte einleitet um die App vollständig zu schützen. Die App wird
dadurch sicher verwendbar sogar auf hochgradig infizierten Geräten."
*Gelächter und Applaus*
Schauen wir uns das mal genauer an...
Was gibt es denn eigentlich Eigenschaften die diese ganzen App-Härtungs-Geschichten
implementieren? Also das sind nur zwei Sparten. Da gibt es in
klassischen App-Härtungsbereich, der will statische und dynamische Analyse
hauptsächlich verhindern. Und dann gibt es den eher neueren Bereich, da geht es dann
eher um zu Security Best Practices. Also solche Sachen wie Certificate-Pinning und
dass man die Anwendungs nochmal verschlüsselt. Also klassische Sachen die
die Entwickler normalerweise gemacht haben. Und deswegen werden die
mittlerweile zum Dreh- und Angelpunkt für sowas und gerade im Bereich des
Mobilebanking sind die Inhalte eine wichtige Nummer. Wie verwendet man denn
jetzt eigentlich das Promo SHIELD? Wenn ich das jetzt verwenden will für meine App,
für meine Android oder iOS-App, die links unten dargestellt ist. Muss ich jetzt als
Kunde noch eine Config die da oben ist spezifizieren. Also welche Features möchte
ich denn haben z.B. Root-Erkennung sagen wir mal. Und dann kommt diese Promo und
Integration Tool und macht irgendwie eine Promon geschützte App daraus. Danach kann
ich sie sofort in die offiziellen Stores hochladen. Dies ist die
Liste an Apps – das sind 31 international – die Promon SHIELD verwenden.
Die zwei die ich jetzt gerade ausgeblendet habe sind keine Banking Apps. Sie kommen auch
aus dem Finanzbereich aber wir wollen uns dieses Mal nur auf die Banking Apps
konzentrieren und hier noch spezieller eigentlich auf die deutschen Banking Apps.
Und dann sieht man auch ganz deutlich die haben in Deutschland eine wichtige
Stellung. Also wenn man sich allein anschaut: Commerzbank, DKB, VR-Banken,
die Sparkassen, Comdirect. Das sind alles Banken die sagen zumindest jedem etwas.
Und da sieht man schon die sind wichtig im deutschen Markt der mobilen Banking Apps.
Wir schauen uns tatsächlich eine App an oder machen ein Beispiel an einer App
die vielleicht nicht jeder kennt und das ist: Yomo.
Warum ist eigentlich Yomo so besonders interessant?
Yomo ist eigentlich erst einmal Ein-App- Authentifizierungsverfahren. Wie ich schon
gesagt habe, das ist heutzutage nicht mehr Besonderes – das macht eigentlich jeder
mittlerweile und das ist N26 nachempfunden. Ich höre immer wieder das
Gerücht, dass das intern sogar Number 27 hieß. Also das Vorbild ist
Number 26. Aber das Interessante ist eigentlich, dass es wahrscheinlich die
neueste Version von Promon verwendet. Warum? Weil das eine sehr junge App ist.
Daher gehe ich davon aus, da es auch von Starfinanz ist – das ist um die Ecken
irgendwie mit Sparkasse was, dass die da schon die neueste Version verwenden. Wenn
sie jetzt sagen Wir machen auch so ein Ein-App-Authentifizierungs-System.
Wie funktioniert das denn intern, wenn man ein bisschen technischer wird? Wenn dieses
Integration-Tool von Promon kommt, dann übernimmt es die MainActivity, also den
Einsprungspunkt der App letztendlich und bindet dann eine native Bibliothek ein:
die libshield.so. Zusätzlich fügt Promon noch Java Klassen ein, die müssen
irgendwie auch ihre eigene Library laden und irgendwann ein bisschen glue code. Und
die sind unter anderem auch obfuskiert aber das spielt hier in diesem Talk
erstmal nicht so die Rolle. Das ist es denn auch nur denen ihre eigenen Klassen.
Dann werden aber zusätzlich aus der App, jetzt also zum Beispiel Yomo,
alle Strings und ein Teil von Konstanten herausgezogen und werden in
diese libshield.so reingemacht. Das Gleiche gilt es bei Yomo im speziellen
Fall auch für ein Client-Zertifikat, das die App braucht um mit dem Backend zu
sprechen. Und das macht eben jetzt nicht mehr Yomo direkt, sondern darum kümmert
sich die libshield.so. Die erste Idee, die man jetzt hat, ist wir wollen das jetzt
irgendwie loswerden. Dann modifizieren wir halt mal diese Library – diese native library.
Wenn man sich jetzt anschaut, den Einstiegspunkt von dem, wenn man mal IDA
aufmacht. Das ein Controllflow-Graph, also nicht das Windows abgestürzt oder sowas.
Das ist tatsächlich einfach totales Controlflow-Flattening und das will man
sich eigentlich nicht anschauen. Also da gibts schon auch Ansätze um das zu
unpacken. Das ist mit dem LLVM obfuscator gemacht. Wahrscheinlich. Ich weis nicht ob
das diese Open-Source Variante ist oder irgendwas selbst angepasst ist. Das kann
ich nicht genau sagen. Aber auf jeden Fall das ist ökonomisch nicht machbar.
Sagen wir jetzt mal. Also wir wollen ja irgendwas einfaches. Nächster Ansatz ist
dann wenn wir schon die nicht modifizieren können, dann entfernen wir die Bibliothek
halt aus der App. So einfach ist das dann auch wieder nicht. Weil wir haben ja das
Problem, die ganzen Strings, die Konstanten und Client-Zertifikate sind
auch alle in dieser libshield.so drin. Deswegen müssen wir diese irgendwie
erstmal loswerden. Und fangen wir mal an mit den Strings wie
schaut es da eigentlich aus? Also es ist da immer dargestellt links ist Yomo und
rechts ist Promon, die native Lib von dem die libshield.so. Links oben ist immer
bevor man in die Promon verwendt hat und links unten ist danach. Es ist dann halt so,
dass wenn da jetzt einfach ein String ausgegeben werden soll wie Yomo, dann
ersetzen sie das mit einem Aufruf zu ihrer native Library und die hat dann irgendwie
irgendwelche Mappings bei sich drinnen und gibt dann halt den String zurück.
Eigentlich auch nicht schwer, weil das ist logisch was man da gemacht hat.
Und was macht man jetzt um das zu umgehen? Wir schauen halt mal was der höchste Index
in dem Ding. Und dann iterieren wir eben von null bis n drüber und erstellen uns
dann ein Mapping davon. Und dann können wir das Ganze wieder rückgängig machen was
sie gemacht haben. Soweit so klar. Man hätte sich die ganze Arbeit gar nicht
machen brauchen, weil man kann ja einfach drüber iterieren bis NULL zurückkommt.
Mit Konstanten hat man im Prinzip ein ähnliches Problem. Bei den Konstanten ist
es eben so: oben hat man da eine Konstante die war -1. Und nachdem man Promon
verwendet hat, steht da halt irgendein Käse drin. Also irgendwas was keinen Sinn
mehr macht, etwas das nicht funktional ist, also nicht der Wert den die Klasse
eigentlich erwartet. Stattdessen wird ein statischer Konstruktor in der Klasse
installiert, die dann dafür sorgt dass über Reflection dieses statisch finale
Feld, das könnte man mit Java Code gar nicht - also nicht mal kompilieren, wenn
man so etwas hätte. Aber über Reflection kann man kann man solche Sachen machen.
Über Reflection wird es dann wieder richtig gesetzt bevor das erste Mal darauf
zugegriffen wird. Die Lösung ist relativ ähnlich: Man geht einfach in alle Klassen
rein, die dieses pushToClass aufrufen, und man ruft dasselbe auf und erstellt sich
wieder ein Mapping. So haben wir das weg. Jetzt kommt das Client-Zertifikat. Jetzt
wird es schon ein bisschen tricky, weil man kann jetzt nicht mehr genau so
vorgehen wie gerade eben. Das Problem ist: Yomo macht selber aus Java Code irgendnen
Request. Danach geht das aber nicht an die Android Library oder die Java Library in
irgendeiner Art und Weise. Sondern es geht in Promon rein und Promon verarbeitet dann
diesen Request in dieser native Library und die fügen das Zertifikat hinzu.
Und jetzt kann man ja nicht einfach irgendwas aufrufen "gib mir mal das Client
Zertifikat" – ja gut das könnte sein aber ist nicht so. Was machen wir denn jetzt da?
Dann ist die Idee: Dann schauen wir halt mal im Speicher. Das muss ja irgendwo
im Speicher liegen und das muss man doch irgendwie finden können. Ja wir haben
eigentlich erwartet, dass wir nur das Zertifikat, aber was wir gefunden
haben war eine noch viel interessantere Datenstruktur. Das sieht ein bisschen wirr aus,
aber das ist eine Konfigurationsdatei. Da komme ich gleich noch drauf, aber da
ist auch das was wir wollen, nämlich das Client-Zertifikat. Das ist base64
enkodiert da drin: clientCertificate und clientCertificateKey. Schön.
Jetzt können wir loslegen. Was machen wir jetzt? Wir können jetzt unser eigenes Tool
Nomorp verwenden, um diesen ganzen Prozess von Promon wieder rückgängig zu machen.
Also wir laden es aus dem Playstore herunter dann haben wir eine geschützte App.
Im nächsten Schritt müssen wir unseren Analyzer injecten, der basiert auf
dem Frida Gadget. Und der sorgt dann dafür, dass diese Mappings extrahiert
werden. Dafür müssen wir das auf einem Gerät installieren und sobald die App
gestartet wird, purzeln da diese ganzen Mappings raus und die Konfigurationsdatei
auch bzw. halt das Client-Zertifikat in dem Fall auch noch. Und das füttern wir
jetzt unser Tool und dann kommt die ungeschützte App raus.
Also dann ist man das losgeworden.
*Applaus*
Der ganze Prozess vom Herunterladen, über das Installieren auf dem Gerät, bis dem
Ausführen von Nomorp dauert fünf bis zehn Minuten. Die Dauer kommt ein bisschen
darauf an wie groß die App ist. Wenn das 10 MB sind dann dauert es nicht so lange.
Und wenn es halt eine 100 MB App ist, dann dauert es halt entsprechend bisschen
länger weil wir da irgendwie Transformation auf Basis von textlib2
machen müssen und dann dauert es halt ein bisschen – aber trotzdem keine Zeit
eigentlich. Kommt ein Update raus, laden wir das direkt runter und das wars.
Jetzt schauen wir aber trotzdem nochmal auf diese auf die Mappings, auf diese
Konfigurationsdatei die wir gerade eben hatten, weil das nämlich eigentlich
bemerkenswert ist. Ich habe jetzt schon die ganze Zeit gesagt: Diese ganzen
Strings und Konstanten sind alle in dieser libshield.so drin. Aber das scheint gar
nicht zu stimmen. Wir haben ja eine Konfigurationsdatei gesehen. Warum sollte
denn das dann drin sein? Da würde ich schon eine binär Datei erwarten, dass das
irgendwie alles schon in bestimmten Datenstrukturen drin ist. Es stellt sich
heraus, dass diese libshield.so schon bei Promon kompiliert wurde und wird so an den
Kunden ausgeliefert. Das heißt bei den Kunden wird gar nichts kompiliert.
Stattdessen, wenn man sich jetzt die Grafik rechts anschaut: Als Kunde habe ich
eben nur diese App und meine Konfigurationsdatei. Dann gebe ich diese
dem Promon Integration Tool und dies hat schon diese libshield.so drin, hat aber
natürlich auch irgendwelche Analyse- und Modifikations-Module. Die sind dann dafür
verantwortlich das da unten diese Config verschlüsselt wird und die Mappings
verschlüsselt werden. Aber die liegen letztendlich in dieser App mit drin,
werden dann einfach geladen und man verwendet die dann entsprechend. Und das
macht letztendlich nochmal ein ganz anderes Angriffszenario interessant.
Wenn wir das links nochmal ein bisschen strukturierter anschauen,dann sind dort
solche Sachen wie checkDebugger, exitOnDebugger und exitOnDebuggerUrl.
Was heisst das? Heisst das soll ich überhaupt noch Debugger überprüfen? Was wenn ich
einen Debugger finde, soll ich dann die App crashen? Und wenn ich sie crashe,
sollte diese URL hier öffnen. Das ist bei den anderen Sachen relativ analog.
Wie wärs denn wenn wir diese Konfigurationsdatei einfach nachdem sie
entschlüsselt wurde, bevor sie geparsed wird modifizieren? Wir sagen einfach
"Hey wir schreiben da überall null rein". Also zu dem Zeitpunkt haben uns schon
ein bisschen geärgert, weil das andere war echt viel Arbeit.
*Gelächter und Applaus*
Das war bisher alles sehr Android spezifisch.
Also ganz kurz zu iOS. Bei iOS ist es letztendlich recht ähnlich. Da gibt
es auch eine Konfigurationsdatei, die ist aber wesentlich weniger umfangreich, und
insgesamt habe ich auch das Gefühl da wird weniger gemacht. Das binär Coding kann man
nicht so schön transformieren wie irgendwie bei Java Bytecode. Letztendlich
sind aber ähnliche Checks halt analog zur zu Android Welt drin und man könnte wieder
sagen "wir schreiben das halt um".
Fassen wir nochmal die Angriffe zusammen:
Wir haben zwei verschiedene Angriffe gesehen. Dein Einen, wo ich gerade schon
gesagt habe der eigentlich relativ komplex war, weil man da relativ viel transformieren
muss, der darauf abzielt dass man Promon SHIELD entfernt. Und dann was ich gerade
vorgestellt habe. Man schreibt einfach die Konfigurationsdatei um.
Da hat man auch kein Problem mit Inkompatibilitäten, bleibt ja alles
kompatibel. Man sagt im Prinzip nur de facto mach einfach nichts.
Danach ist die App im Prinzip komplett ungeschützt. Die Hersteller implementieren
in großem Stil auch keinen Repackaging- Schutz und dergleichen mehr. Jetzt können
wir doch eigentlich weiter automatisieren. Jetzt mal als Beispiel-Angriff:
Transaktionsmanipulation. Wir haben dann gesagt, gut dann erweitern wir doch Nomorp
mal so, dass wir das fast vollständig automatisch machen können. Hier mal als
Beispiel das VR Banking App. Eigentlich was man immer nur machen will bei einer
Transaktionsmanipulation ist: Man will hier bestimmte Views, Text Views oder
sowas, manipulieren. Das sind halt in dem Fall die interessanten.
Der 'Name des Empfängers' ist im Beispiel falsch. Das muss natürlich was anders
sein, das müsste die IBAN sein. Entschuldigung. Das ist ein Fehler. Aber
der txt_betrag ist richtig und die haben natürlich eine ID irgendwo. Und die muss
man quasi manuell ermitteln und alles andere kann man dann vollständig
automatisch machen. Also man kann dies alles injecten. Man muss ja nur wissen was
man danach austauschen muss bzw. auslesen muss.
Jetzt machen wir mal eine kleine Demo. Jetzt kann sich aber mal wieder Yomo
zurücklehnen und brauchen jetzt keine Angst haben geht nicht mit ihnen weiter.
Wir schauen uns das jetzt mal anhand der VR Banken an. Das Video haben wir heute
Nachmittag gemacht. Es ist etwas zügig entstanden. Deswegen sage ich jetzt mal
nochmal zuvor, was man gleich sehen wird. Dieses Szenario ist das folgende: Wir
haben ein Nexus 5X mit Android 7.0 und es hat einen Security Patch Level von vor
ungefähr einem Jahr. Und warum ist das so? Wir wollten irgendwas wo man Dateien
schreiben darf, die man eigentlich schreiben darf.
Also DirtyCOW ist ein klassisch gutes Beispiel. Und warum es es auch so ein
gutes Beispiel? Damit ist es gar nicht so einfach root im Sinne von SuperSU zu
bekommen. Ich glaube dass es erst vor kurzem gelungen. Aber man kann Dateien
schreiben die man eigentlich schreiben dürfte. Dann lädt sich der Nutzer eine
scheinbar gutartige App aus dem offiziellen PlayStore herunter. Soll ja
schon vorgekommen sein, dass da Leute es geschafft haben sowas zu platzieren.
Die App ersetzt dann die VR-Banking und die VR-SecureGo App mit einer Nomorp Version –
wird man dann gleich auch sehr schön sehen. Danach führt der Nutzer eine
Transaktion über 15 Euro durch und die wird durch 1,23 Euro – ist nicht so
logisch wenn man jetzt mal kriminell denkt – ersetzt. Das ist eben eine
Transaktionsmanipulation. Und bis auf das bestimmen der ID ist was
ich gerade gesagt habe komplett vollautomatisch. Also das musste man nicht
weiter antasten mit manuellen Aufwand, sondern nur die IDs bestimmen.
Jetzt machen wir kurz noch auf, dass man die Versionen sieht. Das war das was ich
gerade gesagt habe. Und als nächstes macht mir jetzt erst mal die VR-Banking App auf
und die wird jetzt schwarz, weil die hat halt dieses Flag "secure" gesetzt damit
man keine Aufnahmen machen machen kann. So also da sieht man jetzt nichts. Ok.
Die funktioniert anscheinend. So und jetzt gehts weiter. Jetzt lädt man sich aus dem
PlayStore herunter und ja, das ist echt.
*Gelächter*
Und das sieht man oben diese Leiste. Das ist eine scheinbar gute App und jetzt
wurde man im Hintergrund exploitet. Jetzt machen wir die VR-Banking App nochmal auf.
*Gelächter und Applaus*
Jetzt muss man sich einloggen. Jetzt machen wir die Transaktion und die geht
diesmal an mich. Nur noch kurz die IBAN eingeben. Die 15 Euro die ich gerade eben
gesagt habe mit Verwendungszweck 34C3 (ist aber nicht so wichtig in dem Fall).
Und jetzt ist die Überweisung versendet worden. Das bedeutet im nächsten Schritt
muss man die Transaktion in der TAN App, der VR-SecureGo App, freigeben. Gleiches
Spiel: Hier wurde auch wieder irgendwas gemacht. Ich muss wieder das Passwort
eingeben. Dann im nächsten Schritt: wichtig ist natürlich dass die IBAN
stimmt, das geht aber so schnell, da versichere ich euch dass das stimmt.
Da stehen auch 15 Euro immer noch. Also stimmt ja alles. Also geben wir die
Transaktion frei. So genau da unten stehen auch irgendwie 15 Euro. Passt ja alles.
Und wenn man jetzt hier rein schaut, dann waren es aber wirklich 1,23 Euro.
*Applaus*
Was hier wichtig ist, dass das vollautomatisch war.
Das nicht jeder irgendwie nochmal eine App reversed hat,
sondern man muss nur die IDs bestimmen nachdem Promon draußen war
und dann geht das.
Dann komme ich mal zum Schluss:
die Reaktionen der beteiligten Parteien anschauen und ein Fazit zu schließen. Also
mit Promon stehen wir seit Ende November – also gut einen Monat – in Kontakt.
Die waren sehr nett und professionell und sie haben mittlerweile auch eine neue Version
des Promon SHIELDs entwickelt. Die liegt mir in der Beispiel-App auch vor, aber ich
hatte noch nicht die Zeit, um da genauer anzuschauen. Ich kann aber sagen unsere
Nomorp Toolchain funktioniert auf diese Art und Weise nicht mehr, also
funktioniert nicht mehr wie zuvor. Ich kann nicht genau sagen was wurde da jetzt
genau gemacht und welche großen Anpassungen sind zu machen. Es kann sein,
dass es unglaublich viel Arbeit ist. Kann aber auch sein, dass es nicht viel Arbeit ist.
Ich kann es einfach nicht sagen. Der Punkt ist eigentlich, um die Angriffe
wirklich komplexer zu machen bräuchte man mehr Individualisierung von den Apps.
Man kann ja alle Apps gleichartig angreifen. Man kann das Promon SHIELD auf die gleiche
Art und Weise in all diesen 31 Apps deaktivieren indem man diese Config
rewritet, weil es überall gleich ist, da es ein universaler Ansatz ist.
Die Reaktion der Banken die ich seit Jahren höre: "bis heute keine
Schadensfälle bekannt." Das ist natürlich ein merkwürdiges Verständnis von
IT-Sicherheit. Wenn man sich jetzt aber mal anschaut, wie eigentlich überhaupt die
Verteilung von Mobilebanking ist oder von App basierten TAN Verfahren, dann sind die
einfach nicht relevant aktuell im Markt. 5-8% hat letztes Jahr hat eine Studie
ergeben, sind die App basierten TAN Verfahren verbreitet. Dies soll sich
dieses Jahr nicht groß geändert haben. Natürlich, aktuell lohnt sich das noch
nicht aber das kann sich für die Zukunft ändern.
Das finde ich ein sehr schönes Zitat von Jens Bender und Dennis Kügler vom BSI:
"Im Bereich des Zahlungswesens hat sich eine besondere Kreativität in der Auslegung
der Eigenschaft einer Zweifaktorauthentisierung entwickelt."
*Gelächter*
*Applaus*
Ja, kann ich nur zustimmen. Und jetzt wenn man jetzt denkt nach Mobilebanking, also nach
zwei Apps auf einem Smartphone, wird es nicht mehr schlimmer – das gibt es jetzt
mittlerweile auch auf einem Windows und auf einem Mac PC. Ok, kann man machen.
Zwei Fragen ganz zum Schluss: ist App- Härtung überhaupt sinnvoll? Also haben
diese ganzen Produkte, die ganzen Markt angeboten werden, eine Daseinsberechtigung?
Ja, natürlich haben die eine eine Daseinsberechtigung. Sie haben
schon einen sinnvollen Schutz die sie da einbetten. Aber das muss ein
zusätzlicher Schutz sein.
Und die andere Frage: Ist App-Härtung ein Ersatz für unabhängige
Zweifaktor-Authentifizierung? Natürlich nicht!
Das habe ich gerade eben gesagt. Weil dies Softwaremaßnahmen sind und die können,
wie wir in dem Beispiel gezeigt haben,
einfach nicht verhindern, dass jemand das ausnutzt.
Danke
*Applaus*
Herald: Vielen Dank Vincent für Deinen Talk
und Deinen weiteren Ausflug in die Welt des Mobilebankings. Wir haben Zeit
für einige Fragen. Also wenn ihr Fragen habt, reiht auch an den Mikrofonen auf.
Hier gibt es 1,3, da vorne ist 2, usw. Die haben Nummern dran und dann kann Vincent
ein Paar Fragen für Euch beantworten.
Ihr könnt auch winken wenn ihr an einem steht.
Ok. An Mikrofon 3 haben wir eine Frage.
Mikrofon 3: Vielen Dank für den Talk. Ganz toll!
Jetzt gibt es schon für DRM-Systeme Dinge wie Widevine, die TrustZone
im Chip direkt verwenden. Hast Du bei Deiner Forschung das irgendwas von gesehen?
Vincent: Das ist ein wichtiger Punkt und
ich glaube auch das TrustZone oder allgemeiner Trusted Execution Environments
eine Art und Weise wäre, in der man so etwas in zufriedenstellend sicherer auf
einem Gerät machen könnte. Gerade eben lief der BootStomp Vortrag von den Jungs
der UCSB. Die würden mir da vielleicht widersprechen. Insgesamt ist das ein
Einsatz auf den könnte das aufbauen, aber das ich genau da etwas gesehen habe, kann
ich jetzt nicht behaupten. Jetzt gerade die alle setzen das nicht ein. Ist
natürlich auch das Problem, dass es da keine einheitliche Lösung gibt. Da gibt es
bisher ein Paar proprietäre Lösungen und jeder will sich da irgendwie durchsetzen.
Aber einen einheitlichen Standard gibt es nicht und von daher ist es schwierig.
Herald: Mikrofon 1 bitte. Mikrofon 1: Waren die untersuchten Apps
alle schon nach der PSD2-Richtlinie zugelassen? Also bezog sich darauf das
Zitat von den BSI Leuten? Die schreibt das ja explizit vor Zweifaktorauthentisierung.
Vincent: Genau die PSD2 schreibt vor: starke Kundenauthentifizierung. Da müsste
man jetzt weiter ausholen. Da wurden gerade eben die technischen Standards
dafür verabschiedet. Gibt es noch eine 18-monatige Übergangsfrist, wo die Banken
Zeit haben sich da anzupassen. Aber in den ganzen Werbevideos wird ganz oft davon
gesprochen – jetzt gerade von diesen Drittanbietern, dass sie PSD2 kompatibel
sind. Es ist ein bisschen schwierig zu sagen, was die PSD2 da genau vorschreibt.
Ich glaube so die letzte Entscheidung die dazu getroffen wurde ist eher in Richtung
wir akzeptieren den status quo. Man kann das meiner Meinung nach immer noch so
lesen, dass eine sichere Anzeige und eine Nichtkopierbarkeit für ein Besitzelement
hat. Also von daher ist das nicht ganz klar. Wenn sie jetzt die Banken fragen,
dann sagen die natürlich sind sie PSD2 konform.
Herald: Fragen wir den Signal Angel. Gibt es Fragen aus dem Internet?
*Stille*
Herald: Das scheint nicht der Fall zu sein. Ich habe noch eine Frage an Mikrofon 2.
Mikrofon 2: Hast Du Dir aus Promon noch andere Bibliotheken angesehen?
Vincent: Nein. Habe ich nicht. Das liegt aber einfach auch daran, es gibt ein Paar
andere die im deutschen Markt verbreitet sind, oder was heist Verbreitung? Es gibt
Vereinzelte, die das einsetzen. Die Deutsche Bank setzt mittlerweile ARXAN
ein. Dann gibt es noch die ING-DiBa die Kobil verwendet. Da kann ich jetzt nicht
genaueres zu sagen. Ich meine ich habe ja auch nichts per se gegen Promon - kein
Problem mit denen. Aber das Problem ist eher, dass sie so relevant im deutschen
Markt sind und ich irgendwie fesgestellt habe, dass so gut wie jeder sie
verwendet. Deswegen hat es sich halt gelohnt, das genauer anzuschauen. Wenn
jetzt jeder eine andere App-Härtungslösung verwenden würde, dann hätte man einen viel
größeren Aufwand. Dann müsste man sich ja alle anschauen. Und so ist es aber man
kann einmal Promon deaktivieren und das geht für alle. Das ist ja eigentlich das Problem.
Herald: Letzte Frage von Mikrofon 1.
Mikrofon 1: Vielen Dank für den Vortrag. Eine Frage zu dem Angriffsvektior: in
diesem Fall wurde einfach die App ausgetauscht und dann – sagen wir einmal –
leicht angreifbar gemacht. Wäre es denkbar, vielleicht auch beim gerooteten
Phone, dass man da einfach nebendran eine Application hätte, die das einfach on-the-
fly austauscht und so Applikationen angreift. Hast Du das untersucht?
Vincent: Also das machen wir ja im Endeffekt. Wir binden eine Komponente in
diese App ein die das macht. Ich meine in dem Fall wurde das halt ersetzt, aber ich
glaube nur, dass das Ersetzen von einer App ist mitunter das Einfachste,
was man machen kann.
Mikrofon 1: Ich meine, wenn es nicht gerootet wäre, dann wäre es nicht möglich
von einer App auf die Andere zuzugreifen und das auszutauschen. Also das müsste
natürlich gerootet werden oder gibt es andere Ansätze?
Vincent: Es gibt immer noch eine Unschärfe
zwischen was ist ein root-Exploit also priviledge escalation und was ist ein
gerootetes Gerät. Ein gerootetes Gerät ist bei mir eine bewusste Entscheidung: ich
installiere bei mir SuperSU oder Magisk. Das ist bei mir eine bewusste
Entscheidung. Dafür verwende ich unter Umständen priviledge escalation um das zu
Platzieren, aber ein priviledge escalation an Sich, zum Beispiel DirtyCow ausnutzen
ist nicht persistent – das wird einmal ausgenutzt. Spuren davon, da müssen wir
jetzt einen Forensiker fragen, aber ich glaube das ist schwierig. Und das ist der
große Unterschied davon. Priviledge escalation mache ich einmal, um meinen
Angriffsvektor zu platzieren und danach nützen die ganzen root detections von den
Systemen gar nichts mehr: ich habe kein SuperSU installiert.
Herald: Ok. Nochmal herzlichen Dank Vincent Haupert. Einen großen Applaus.
*Applaus*
*34c3 outro*
Untertitel erstellt von c3subtitles.de im Jahr 2018. Mach mit und hilf uns!