34C3 - Die fabelhafte Welt des Mobilebankings

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!