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!