WEBVTT
00:00:00.000 --> 00:00:15.085
34c3 intro
00:00:15.085 --> 00:00:30.170
Herald: Der kommende Vortag ist von einem
alten Bekannten, der schon zum 32C3 und
00:00:30.170 --> 00:00:36.980
zum 33C3 uns in eine wundersame Welt
entführt hat voller mobiler Endgeräte und
00:00:36.980 --> 00:00:46.380
unsicherer Verbidungen und dem Vertrauen
was wir daran stecken. Er ist Doktorrand
00:00:46.544 --> 00:00:52.329
an der Uni Erlangen-Nürnberg – die hat
auch einen langen Namen, den ich nicht
00:00:52.329 --> 00:00:56.960
aufgeschrieben habe. Er ist Doktorrand der
Informatik und interessiert sich besonders
00:00:56.960 --> 00:01:02.560
für die Sicherheit von Mobilgeräten und
wird uns heute die fabelhafte Welt des
00:01:02.560 --> 00:01:06.900
Mobilbankings näher bringen. Begrüßt mit
mir Vincent Haupert.
00:01:10.775 --> 00:01:15.260
Applaus
00:01:15.277 --> 00:01:17.460
Vincent: Herzlichen Dank für die Einführung.
00:01:17.460 --> 00:01:21.670
Fabelhaft ist ein sehr vielschichtiges Wort.
An dieser Stelle
00:01:21.670 --> 00:01:25.700
möchte ich zuerst einmal die fabelhafte
Zusammenarbeit mit meinem Kollegen Nicolas
00:01:25.700 --> 00:01:30.080
Schneider hervorheben ohne den diese
Arbeit hier in der Form nicht möglich
00:01:30.080 --> 00:01:33.560
gewesen wäre. Herzlichen Dank an ihn.
00:01:33.560 --> 00:01:38.070
Applaus
00:01:38.080 --> 00:01:41.080
Onlinebanking – ich denke mal so gut wie
00:01:41.080 --> 00:01:45.070
jeder hier dürfte es machen – ist
hinlänglich bekannt. Ist seit jeher im
00:01:45.070 --> 00:01:56.130
PIN/TAN Verfahren seitdem es von vor 30
Jahren. Ihr erster
00:01:56.130 --> 00:02:04.930
Faktor ist wie immer man loggt sich auch
Onlinebanking Portal ein mit seinem
00:02:04.930 --> 00:02:10.020
Benutzername und Passwort. Danach muss
man eine Transaktion aufgeben mit einer
00:02:10.020 --> 00:02:13.220
IBAN und mit einem Betrag. Im zweiten
Schritt hat man dann irgendein TAN
00:02:13.220 --> 00:02:16.810
Verfahren mit dem man die Transaktion
bestätigen muss. Das ist ganz klares
00:02:16.810 --> 00:02:21.830
Sicherheitselement das es seit Anfang des
Onlinebanking gibt. Und die Art und Weise
00:02:21.830 --> 00:02:28.420
wie man eben die TAN generiert, empfängt,
abliest ist recht unterschiedlich. Die
00:02:28.420 --> 00:02:30.959
ersten drei Verfahren die man jetzt hier
auf dieser Liste sieht das iTAN Verfahren,
00:02:30.959 --> 00:02:35.069
smsTAN Verfahren und chipTAN Verfahren
sind hauptsächlich aus der Motivation
00:02:35.069 --> 00:02:37.980
entstanden, dass es relativ viele
Schadensfälle in dem Bereich gab, also
00:02:37.980 --> 00:02:43.120
Phishing vor allem, und mit chipTAN ist
man quasi an den Zenit an gereicht /
00:02:43.120 --> 00:02:47.650
erlangt. Technisch kann man das eigentlich
kaum noch besser machen. Gibt es natürlich
00:02:47.650 --> 00:02:49.520
auch noch andere Aspekte wie
Benutzerfreundlichkeit die da wichtig
00:02:49.520 --> 00:02:54.540
sind. Deswegen gingen die Verfahren wie
photoTAN oder auch appTAN gehen dann
00:02:54.540 --> 00:02:57.081
eigentlich mehr in die Richtung dass sie
die Benutzerfreundlichkeit adressieren
00:02:57.081 --> 00:03:01.770
wollen – was auch durchaus legitim ist.
Per se habe ich eigentlich gar nichts
00:03:01.770 --> 00:03:06.950
gegen App basierte TAN Verfahren. Solange
man zwei Geräte verwendet.
00:03:06.950 --> 00:03:10.069
Also wenn man zwei Geräte
Authentifizierung macht hat man ja immer
00:03:10.069 --> 00:03:13.281
noch den Schutz, dass, wenn ein Gerät
kompromittiert ist, das andere zumindest
00:03:13.281 --> 00:03:18.440
nicht automatisch mit in Mitleidenschaft
gezogen wird. Von daher ist es durchaus
00:03:18.440 --> 00:03:21.660
legitim. Ich kann mich erinnern vor zwei
Jahren als ich hier den Talk gehalten
00:03:21.660 --> 00:03:25.790
habe, wurde ich nach photoTAN gefragt und
hab noch gesagt das ist ein relativ
00:03:25.790 --> 00:03:29.959
solides Verfahren, weil es ja implizit
eigentlich forciert, dass man zwei Geräte
00:03:29.959 --> 00:03:33.370
verwendet. Dann muss man ja von einem
anderen Gerät abscannen und das generiert
00:03:33.370 --> 00:03:39.890
dann die TAN. Dann gibts halt die
Verfahren die pushTAN Verfahren bzw. die,
00:03:39.890 --> 00:03:44.999
die über zwei Apps realisiert sind: also
eine Banking App die andere die TAN App.
00:03:44.999 --> 00:03:50.629
Das gibt es jetzt mittlerweile seit
Jahren. Und das Paradoxe ist, dass man
00:03:50.629 --> 00:03:56.310
mittlerweile auch photoTAN auf einem Gerät
machen kann. Da kann man zwar nichts mehr
00:03:56.310 --> 00:03:58.810
abscannen erkennen, sondern kommunizieren
einfach untereinander, aber das zeigt
00:03:58.810 --> 00:04:03.879
eigentlich erst mal wie abstrus es wird.
Aber eigentlich redet auch heute keiner
00:04:03.879 --> 00:04:07.090
mehr über Zwei-App-Verfahren. Vielleicht
war das auch nur eine Art und Weise um uns
00:04:07.090 --> 00:04:09.760
daran zu gewöhnen, dass es eigentlich
keine richtige Zwei-Faktor-
00:04:09.760 --> 00:04:13.670
Authentifizierung mehr gibt. Und
eigentlich will heute jeder ein Ein-App-
00:04:13.670 --> 00:04:18.259
Verfahren implementieren. Das ist insofern
eigentlich bemerkenswert, weil das SMS TAN
00:04:18.259 --> 00:04:21.449
Verfahren, wenn man sich das mal anschaut,
hat eine Geräte-Entwicklung durchgemacht
00:04:21.449 --> 00:04:25.729
von einem Spezialgerät hin zu einem
Mehrzweckgerät. Also heute empfängt jeder
00:04:25.729 --> 00:04:29.419
seine SMS auf einem Smartphone. Und das
ist im Prinzip auf eine bestimmte Art und
00:04:29.419 --> 00:04:33.470
Weise auch eine App mit der man das
empfängt. Und damals war es dann das erste
00:04:33.470 --> 00:04:38.220
Mal möglich, dass man von einem Gerät aus
eine Transaktion aufgibt und bestätigt.
00:04:38.220 --> 00:04:44.050
Und da hat die deutsche Kreditwirtschaft
weise 2008 schon erkannt, dass das keine
00:04:44.050 --> 00:04:47.749
so gute Idee ist.
"Dies impliziert bereits, dass die
00:04:47.749 --> 00:04:51.389
Verwendung des mobileTAN Verfahrens zum
Beispiel nur ein mobiles Smartphone für
00:04:51.389 --> 00:04:54.469
beide Kommunikation Strecken nicht
zulässig ist und daher den
00:04:54.469 --> 00:04:58.199
Kundenbedingungen für das Online-Banking
explizit ausgeschlossen wird." "Dies
00:04:58.199 --> 00:05:03.110
impliziert bereits" so ist ja eh klar.
Jetzt frage ich mich natürlich: Wo ist
00:05:03.110 --> 00:05:07.289
denn da jetzt der Unterschied? Also hier
wird auch alles auf einem Gerät gemacht
00:05:07.289 --> 00:05:11.559
und das habe ich vor zwei Jahren dann auch
gezeigt: habe einen Angriff auf das
00:05:11.559 --> 00:05:15.960
pushTAN Verfahren gezeigt mit einer
Transaktionsmanipulation. Das hat hingegen
00:05:15.960 --> 00:05:20.400
die Sparkasse nicht so richtig
beeindruckt. Die haben gesagt: "Ja das
00:05:20.400 --> 00:05:23.669
waren eigentlich alles nur
Laborbedingungen – das geht in Wirklichkeit
00:05:23.669 --> 00:05:28.020
gar nicht. Und das funktioniert nur bei
genau einem Gerät, genau einer App und bei
00:05:28.020 --> 00:05:31.300
genau einer Version" und "jedes Mal wenn
wir eine neue Version herausbringen ist
00:05:31.300 --> 00:05:36.919
das ein hoher individueller und manuelle Aufwand."
Und genau dies werden wir heute adressieren.
00:05:36.919 --> 00:05:44.769
Glächter und Applaus
00:05:44.769 --> 00:05:48.949
Jetzt habe ich ja vorhin gesagt so bei
smsTAN hat man gesagt "ja das machen wir
00:05:48.949 --> 00:05:51.719
nicht, das ist nicht sicher." Und jetzt
muss man sich fragen was ist denn dann
00:05:51.719 --> 00:05:55.629
eigentlich anders bei diesen Apps? Da gibt
es eine ganze Reihe von Eigenschaft, aber
00:05:55.629 --> 00:06:00.139
ich denke wichtig ist diese Absicherung
durch Dritte. Und zwar gibt es
00:06:00.139 --> 00:06:05.900
mittlerweile einen recht großen Markt an
Drittanbietern die App-Härtung und App-
00:06:05.900 --> 00:06:09.360
Sicherheit verkaufen. Also Drittanbieter
Produkte und das hier ist nur eine kleine
00:06:09.360 --> 00:06:17.949
Auswahl. Und denjenigen die wir uns heute
etwas genauer anschauen werden ist Promon.
00:06:17.949 --> 00:06:23.349
Promon hat das Produkt Promon SHIELD. Die
Information die hier stehen sind allesamt
00:06:23.349 --> 00:06:28.539
von der Website. Der Zweck von Promon
SHIELD ist Schutz von Apps in nicht
00:06:28.539 --> 00:06:32.770
vertrauenswürdigen Umgebungen.
Das Ganze ist universal, d.h. es ist egal
00:06:32.770 --> 00:06:35.900
was für eine App es ist, und es ist
plattformunabhängig. Also es geht unter
00:06:35.900 --> 00:06:40.219
Android und iOS und die haben auch
Lösungen für Windows. Es ist anwendbar
00:06:40.219 --> 00:06:45.640
innerhalb von wenigen Minuten.
Das Zitat is aus dem Video:
00:06:45.640 --> 00:06:49.749
"Es Erkennt und verhindert jede Gefahr in
Echtzeit und reagiert, indem es die
00:06:49.749 --> 00:06:54.409
notwendigen Schritte einleitet um die App
vollständig zu schützen. Die App wird
00:06:54.409 --> 00:06:57.729
dadurch sicher verwendbar sogar auf
hochgradig infizierten Geräten."
00:06:57.729 --> 00:07:05.809
Gelächter und Applaus
00:07:05.809 --> 00:07:08.669
Schauen wir uns das mal genauer an...
00:07:08.669 --> 00:07:12.639
Was gibt es denn eigentlich Eigenschaften
die diese ganzen App-Härtungs-Geschichten
00:07:12.639 --> 00:07:15.830
implementieren? Also
das sind nur zwei Sparten. Da gibt es in
00:07:15.830 --> 00:07:18.729
klassischen App-Härtungsbereich, der will
statische und dynamische Analyse
00:07:18.729 --> 00:07:22.620
hauptsächlich verhindern. Und dann gibt es
den eher neueren Bereich, da geht es dann
00:07:22.620 --> 00:07:26.300
eher um zu Security Best Practices. Also
solche Sachen wie Certificate-Pinning und
00:07:26.300 --> 00:07:29.150
dass man die Anwendungs nochmal
verschlüsselt. Also klassische Sachen die
00:07:29.150 --> 00:07:32.360
die Entwickler normalerweise gemacht
haben. Und deswegen werden die
00:07:32.360 --> 00:07:36.429
mittlerweile zum Dreh- und Angelpunkt für
sowas und gerade im Bereich des
00:07:36.429 --> 00:07:41.059
Mobilebanking sind die Inhalte eine
wichtige Nummer. Wie verwendet man denn
00:07:41.059 --> 00:07:44.039
jetzt eigentlich das Promo SHIELD? Wenn
ich das jetzt verwenden will für meine App,
00:07:44.039 --> 00:07:47.779
für meine Android oder iOS-App, die links
unten dargestellt ist. Muss ich jetzt als
00:07:47.779 --> 00:07:52.830
Kunde noch eine Config die da oben ist
spezifizieren. Also welche Features möchte
00:07:52.830 --> 00:07:58.189
ich denn haben z.B. Root-Erkennung sagen
wir mal. Und dann kommt diese Promo und
00:07:58.189 --> 00:08:02.559
Integration Tool und macht irgendwie eine
Promon geschützte App daraus. Danach kann
00:08:02.559 --> 00:08:07.409
ich sie sofort in die offiziellen Stores
hochladen. Dies ist die
00:08:07.409 --> 00:08:14.470
Liste an Apps – das sind 31 international
– die Promon SHIELD verwenden.
00:08:14.470 --> 00:08:17.710
Die zwei die ich jetzt gerade ausgeblendet habe
sind keine Banking Apps. Sie kommen auch
00:08:17.710 --> 00:08:19.710
aus dem Finanzbereich aber wir wollen uns
dieses Mal nur auf die Banking Apps
00:08:19.710 --> 00:08:24.119
konzentrieren und hier noch spezieller
eigentlich auf die deutschen Banking Apps.
00:08:24.119 --> 00:08:27.270
Und dann sieht man auch ganz deutlich die
haben in Deutschland eine wichtige
00:08:27.270 --> 00:08:32.190
Stellung. Also wenn man sich allein
anschaut: Commerzbank, DKB, VR-Banken,
00:08:32.190 --> 00:08:36.610
die Sparkassen, Comdirect. Das sind alles
Banken die sagen zumindest jedem etwas.
00:08:36.610 --> 00:08:41.889
Und da sieht man schon die sind wichtig im
deutschen Markt der mobilen Banking Apps.
00:08:41.889 --> 00:08:46.649
Wir schauen uns tatsächlich eine App an
oder machen ein Beispiel an einer App
00:08:46.649 --> 00:08:49.060
die vielleicht nicht jeder kennt und das ist:
Yomo.
00:08:49.060 --> 00:08:53.089
Warum ist eigentlich Yomo so besonders
interessant?
00:08:53.089 --> 00:08:57.379
Yomo ist eigentlich erst einmal Ein-App-
Authentifizierungsverfahren. Wie ich schon
00:08:57.379 --> 00:08:59.529
gesagt habe, das ist heutzutage nicht mehr
Besonderes – das macht eigentlich jeder
00:08:59.529 --> 00:09:05.839
mittlerweile und das ist N26
nachempfunden. Ich höre immer wieder das
00:09:05.839 --> 00:09:11.659
Gerücht, dass das intern sogar
Number 27 hieß. Also das Vorbild ist
00:09:11.659 --> 00:09:17.040
Number 26. Aber das Interessante ist
eigentlich, dass es wahrscheinlich die
00:09:17.040 --> 00:09:20.509
neueste Version von Promon verwendet.
Warum? Weil das eine sehr junge App ist.
00:09:20.509 --> 00:09:24.891
Daher gehe ich davon aus, da es auch von
Starfinanz ist – das ist um die Ecken
00:09:24.891 --> 00:09:29.799
irgendwie mit Sparkasse was, dass die da
schon die neueste Version verwenden. Wenn
00:09:29.799 --> 00:09:36.289
sie jetzt sagen Wir machen auch so ein
Ein-App-Authentifizierungs-System.
00:09:36.289 --> 00:09:40.160
Wie funktioniert das denn intern, wenn man
ein bisschen technischer wird? Wenn dieses
00:09:40.160 --> 00:09:44.480
Integration-Tool von Promon kommt, dann
übernimmt es die MainActivity, also den
00:09:44.480 --> 00:09:48.600
Einsprungspunkt der App letztendlich und
bindet dann eine native Bibliothek ein:
00:09:48.600 --> 00:09:53.589
die libshield.so. Zusätzlich fügt Promon
noch Java Klassen ein, die müssen
00:09:53.589 --> 00:09:57.590
irgendwie auch ihre eigene Library laden
und irgendwann ein bisschen glue code. Und
00:09:57.590 --> 00:09:59.980
die sind unter anderem auch obfuskiert
aber das spielt hier in diesem Talk
00:09:59.980 --> 00:10:03.480
erstmal nicht so die Rolle. Das ist es
denn auch nur denen ihre eigenen Klassen.
00:10:03.480 --> 00:10:07.729
Dann werden aber zusätzlich aus der App,
jetzt also zum Beispiel Yomo,
00:10:07.729 --> 00:10:11.709
alle Strings und ein Teil von Konstanten
herausgezogen und werden in
00:10:11.709 --> 00:10:15.610
diese libshield.so reingemacht. Das
Gleiche gilt es bei Yomo im speziellen
00:10:15.610 --> 00:10:19.860
Fall auch für ein Client-Zertifikat, das
die App braucht um mit dem Backend zu
00:10:19.860 --> 00:10:23.209
sprechen. Und das macht eben jetzt nicht
mehr Yomo direkt, sondern darum kümmert
00:10:23.209 --> 00:10:31.319
sich die libshield.so. Die erste Idee, die
man jetzt hat, ist wir wollen das jetzt
00:10:31.319 --> 00:10:37.430
irgendwie loswerden. Dann modifizieren wir
halt mal diese Library – diese native library.
00:10:37.430 --> 00:10:40.900
Wenn man sich jetzt anschaut, den
Einstiegspunkt von dem, wenn man mal IDA
00:10:40.900 --> 00:10:46.130
aufmacht. Das ein Controllflow-Graph, also
nicht das Windows abgestürzt oder sowas.
00:10:46.130 --> 00:10:51.350
Das ist tatsächlich einfach totales
Controlflow-Flattening und das will man
00:10:51.350 --> 00:10:53.850
sich eigentlich nicht anschauen.
Also da gibts schon auch Ansätze um das zu
00:10:53.850 --> 00:10:58.040
unpacken. Das ist mit dem LLVM obfuscator
gemacht. Wahrscheinlich. Ich weis nicht ob
00:10:58.040 --> 00:11:02.170
das diese Open-Source Variante ist oder
irgendwas selbst angepasst ist. Das kann
00:11:02.170 --> 00:11:05.880
ich nicht genau sagen. Aber auf jeden Fall
das ist ökonomisch nicht machbar.
00:11:05.880 --> 00:11:11.759
Sagen wir jetzt mal. Also wir wollen ja
irgendwas einfaches. Nächster Ansatz ist
00:11:11.759 --> 00:11:15.149
dann wenn wir schon die nicht modifizieren
können, dann entfernen wir die Bibliothek
00:11:15.149 --> 00:11:19.470
halt aus der App. So einfach ist das dann
auch wieder nicht. Weil wir haben ja das
00:11:19.470 --> 00:11:23.399
Problem, die ganzen Strings, die
Konstanten und Client-Zertifikate sind
00:11:23.399 --> 00:11:27.790
auch alle in dieser libshield.so drin.
Deswegen müssen wir diese irgendwie
00:11:27.790 --> 00:11:33.191
erstmal loswerden.
Und fangen wir mal an mit den Strings wie
00:11:33.191 --> 00:11:38.750
schaut es da eigentlich aus? Also es ist
da immer dargestellt links ist Yomo und
00:11:38.750 --> 00:11:43.990
rechts ist Promon, die native Lib von dem
die libshield.so. Links oben ist immer
00:11:43.990 --> 00:11:50.999
bevor man in die Promon verwendt hat und
links unten ist danach. Es ist dann halt so,
00:11:50.999 --> 00:11:54.730
dass wenn da jetzt einfach ein String
ausgegeben werden soll wie Yomo, dann
00:11:54.730 --> 00:11:59.769
ersetzen sie das mit einem Aufruf zu ihrer
native Library und die hat dann irgendwie
00:11:59.769 --> 00:12:03.930
irgendwelche Mappings bei sich drinnen und
gibt dann halt den String zurück.
00:12:03.930 --> 00:12:07.939
Eigentlich auch nicht schwer, weil das ist
logisch was man da gemacht hat.
00:12:07.939 --> 00:12:13.860
Und was macht man jetzt um das zu umgehen?
Wir schauen halt mal was der höchste Index
00:12:13.860 --> 00:12:18.910
in dem Ding. Und dann iterieren wir eben
von null bis n drüber und erstellen uns
00:12:18.910 --> 00:12:22.399
dann ein Mapping davon. Und dann können
wir das Ganze wieder rückgängig machen was
00:12:22.399 --> 00:12:27.600
sie gemacht haben. Soweit so klar. Man
hätte sich die ganze Arbeit gar nicht
00:12:27.600 --> 00:12:32.930
machen brauchen, weil man kann ja einfach
drüber iterieren bis NULL zurückkommt.
00:12:32.930 --> 00:12:38.590
Mit Konstanten hat man im Prinzip ein
ähnliches Problem. Bei den Konstanten ist
00:12:38.590 --> 00:12:43.529
es eben so: oben hat man da eine Konstante
die war -1. Und nachdem man Promon
00:12:43.529 --> 00:12:47.519
verwendet hat, steht da halt irgendein
Käse drin. Also irgendwas was keinen Sinn
00:12:47.519 --> 00:12:49.680
mehr macht, etwas das nicht funktional
ist, also nicht der Wert den die Klasse
00:12:49.680 --> 00:12:54.971
eigentlich erwartet. Stattdessen wird ein
statischer Konstruktor in der Klasse
00:12:54.971 --> 00:12:58.560
installiert, die dann dafür sorgt dass
über Reflection dieses statisch finale
00:12:58.560 --> 00:13:03.319
Feld, das könnte man mit Java Code gar
nicht - also nicht mal kompilieren, wenn
00:13:03.319 --> 00:13:06.709
man so etwas hätte. Aber über Reflection
kann man kann man solche Sachen machen.
00:13:06.709 --> 00:13:10.390
Über Reflection wird es dann wieder
richtig gesetzt bevor das erste Mal darauf
00:13:10.390 --> 00:13:16.860
zugegriffen wird. Die Lösung ist relativ
ähnlich: Man geht einfach in alle Klassen
00:13:16.860 --> 00:13:21.540
rein, die dieses pushToClass aufrufen, und
man ruft dasselbe auf und erstellt sich
00:13:21.540 --> 00:13:26.740
wieder ein Mapping. So haben wir das weg.
Jetzt kommt das Client-Zertifikat. Jetzt
00:13:26.740 --> 00:13:31.509
wird es schon ein bisschen tricky, weil
man kann jetzt nicht mehr genau so
00:13:31.509 --> 00:13:37.779
vorgehen wie gerade eben. Das Problem ist:
Yomo macht selber aus Java Code irgendnen
00:13:37.779 --> 00:13:42.480
Request. Danach geht das aber nicht an die
Android Library oder die Java Library in
00:13:42.480 --> 00:13:46.399
irgendeiner Art und Weise. Sondern es geht
in Promon rein und Promon verarbeitet dann
00:13:46.399 --> 00:13:49.869
diesen Request in dieser native Library
und die fügen das Zertifikat hinzu.
00:13:49.869 --> 00:13:54.330
Und jetzt kann man ja nicht einfach
irgendwas aufrufen "gib mir mal das Client
00:13:54.330 --> 00:13:58.830
Zertifikat" – ja gut das könnte sein aber
ist nicht so. Was machen wir denn jetzt da?
00:13:58.830 --> 00:14:02.630
Dann ist die Idee: Dann schauen wir
halt mal im Speicher. Das muss ja irgendwo
00:14:02.630 --> 00:14:06.459
im Speicher liegen und das muss man doch
irgendwie finden können. Ja wir haben
00:14:06.459 --> 00:14:10.889
eigentlich erwartet, dass wir nur das
Zertifikat, aber was wir gefunden
00:14:10.889 --> 00:14:16.120
haben war eine noch viel interessantere
Datenstruktur. Das sieht ein bisschen wirr aus,
00:14:16.120 --> 00:14:20.709
aber das ist eine Konfigurationsdatei.
Da komme ich gleich noch drauf, aber da
00:14:20.709 --> 00:14:25.000
ist auch das was wir wollen, nämlich das
Client-Zertifikat. Das ist base64
00:14:25.000 --> 00:14:30.620
enkodiert da drin: clientCertificate und
clientCertificateKey. Schön.
00:14:30.620 --> 00:14:35.370
Jetzt können wir loslegen. Was machen wir
jetzt? Wir können jetzt unser eigenes Tool
00:14:35.370 --> 00:14:39.560
Nomorp verwenden, um diesen ganzen Prozess
von Promon wieder rückgängig zu machen.
00:14:39.560 --> 00:14:43.519
Also wir laden es aus dem Playstore
herunter dann haben wir eine geschützte App.
00:14:43.519 --> 00:14:48.579
Im nächsten Schritt müssen wir
unseren Analyzer injecten, der basiert auf
00:14:48.579 --> 00:14:53.930
dem Frida Gadget. Und der sorgt dann
dafür, dass diese Mappings extrahiert
00:14:53.930 --> 00:14:58.040
werden. Dafür müssen wir das auf einem
Gerät installieren und sobald die App
00:14:58.040 --> 00:15:02.829
gestartet wird, purzeln da diese ganzen
Mappings raus und die Konfigurationsdatei
00:15:02.829 --> 00:15:09.220
auch bzw. halt das Client-Zertifikat in
dem Fall auch noch. Und das füttern wir
00:15:09.220 --> 00:15:15.709
jetzt unser Tool und dann kommt die
ungeschützte App raus.
00:15:15.709 --> 00:15:19.389
Also dann ist man das losgeworden.
00:15:19.389 --> 00:15:26.649
Applaus
00:15:26.649 --> 00:15:33.149
Der ganze Prozess vom Herunterladen, über
das Installieren auf dem Gerät, bis dem
00:15:33.149 --> 00:15:38.759
Ausführen von Nomorp dauert fünf bis zehn
Minuten. Die Dauer kommt ein bisschen
00:15:38.759 --> 00:15:43.879
darauf an wie groß die App ist. Wenn das
10 MB sind dann dauert es nicht so lange.
00:15:43.879 --> 00:15:48.209
Und wenn es halt eine 100 MB App ist, dann
dauert es halt entsprechend bisschen
00:15:48.209 --> 00:15:51.029
länger weil wir da irgendwie
Transformation auf Basis von textlib2
00:15:51.029 --> 00:15:54.079
machen müssen und dann dauert es halt ein
bisschen – aber trotzdem keine Zeit
00:15:54.079 --> 00:15:58.470
eigentlich. Kommt ein Update raus, laden
wir das direkt runter und das wars.
00:15:58.470 --> 00:16:03.269
Jetzt schauen wir aber trotzdem nochmal
auf diese auf die Mappings, auf diese
00:16:03.269 --> 00:16:06.699
Konfigurationsdatei die wir gerade eben
hatten, weil das nämlich eigentlich
00:16:06.699 --> 00:16:11.720
bemerkenswert ist. Ich habe jetzt schon
die ganze Zeit gesagt: Diese ganzen
00:16:11.720 --> 00:16:16.589
Strings und Konstanten sind alle in dieser
libshield.so drin. Aber das scheint gar
00:16:16.589 --> 00:16:20.369
nicht zu stimmen. Wir haben ja eine
Konfigurationsdatei gesehen. Warum sollte
00:16:20.369 --> 00:16:24.230
denn das dann drin sein? Da würde ich
schon eine binär Datei erwarten, dass das
00:16:24.230 --> 00:16:28.060
irgendwie alles schon in bestimmten
Datenstrukturen drin ist. Es stellt sich
00:16:28.060 --> 00:16:33.119
heraus, dass diese libshield.so schon bei
Promon kompiliert wurde und wird so an den
00:16:33.119 --> 00:16:36.459
Kunden ausgeliefert. Das heißt bei den
Kunden wird gar nichts kompiliert.
00:16:36.459 --> 00:16:40.360
Stattdessen, wenn man sich jetzt die
Grafik rechts anschaut: Als Kunde habe ich
00:16:40.360 --> 00:16:43.449
eben nur diese App und meine
Konfigurationsdatei. Dann gebe ich diese
00:16:43.449 --> 00:16:47.749
dem Promon Integration Tool und dies hat
schon diese libshield.so drin, hat aber
00:16:47.749 --> 00:16:53.930
natürlich auch irgendwelche Analyse- und
Modifikations-Module. Die sind dann dafür
00:16:53.930 --> 00:16:57.430
verantwortlich das da unten diese Config
verschlüsselt wird und die Mappings
00:16:57.430 --> 00:17:01.970
verschlüsselt werden. Aber die liegen
letztendlich in dieser App mit drin,
00:17:01.970 --> 00:17:08.849
werden dann einfach geladen und man
verwendet die dann entsprechend. Und das
00:17:08.849 --> 00:17:10.939
macht letztendlich nochmal ein ganz
anderes Angriffszenario interessant.
00:17:10.939 --> 00:17:14.959
Wenn wir das links nochmal ein bisschen
strukturierter anschauen,dann sind dort
00:17:14.959 --> 00:17:19.550
solche Sachen wie checkDebugger,
exitOnDebugger und exitOnDebuggerUrl.
00:17:19.550 --> 00:17:24.640
Was heisst das? Heisst das soll ich überhaupt
noch Debugger überprüfen? Was wenn ich
00:17:24.640 --> 00:17:27.940
einen Debugger finde, soll ich dann die
App crashen? Und wenn ich sie crashe,
00:17:27.940 --> 00:17:33.890
sollte diese URL hier öffnen. Das ist bei
den anderen Sachen relativ analog.
00:17:33.890 --> 00:17:38.490
Wie wärs denn wenn wir diese
Konfigurationsdatei einfach nachdem sie
00:17:38.490 --> 00:17:43.559
entschlüsselt wurde, bevor sie geparsed
wird modifizieren? Wir sagen einfach
00:17:43.559 --> 00:17:49.010
"Hey wir schreiben da überall null rein".
Also zu dem Zeitpunkt haben uns schon
00:17:49.010 --> 00:17:52.620
ein bisschen geärgert, weil das andere
war echt viel Arbeit.
00:17:52.620 --> 00:18:03.200
Gelächter und Applaus
00:18:03.200 --> 00:18:06.900
Das war bisher alles sehr Android spezifisch.
00:18:06.900 --> 00:18:12.560
Also ganz kurz zu iOS. Bei iOS
ist es letztendlich recht ähnlich. Da gibt
00:18:12.560 --> 00:18:16.810
es auch eine Konfigurationsdatei, die ist
aber wesentlich weniger umfangreich, und
00:18:16.810 --> 00:18:19.980
insgesamt habe ich auch das Gefühl da wird
weniger gemacht. Das binär Coding kann man
00:18:19.980 --> 00:18:23.799
nicht so schön transformieren wie
irgendwie bei Java Bytecode. Letztendlich
00:18:23.799 --> 00:18:28.179
sind aber ähnliche Checks halt analog zur
zu Android Welt drin und man könnte wieder
00:18:28.179 --> 00:18:31.090
sagen "wir schreiben das halt um".
00:18:33.720 --> 00:18:36.230
Fassen wir nochmal die Angriffe zusammen:
00:18:36.230 --> 00:18:39.659
Wir haben zwei verschiedene Angriffe
gesehen. Dein Einen, wo ich gerade schon
00:18:39.659 --> 00:18:42.430
gesagt habe der eigentlich relativ komplex
war, weil man da relativ viel transformieren
00:18:42.430 --> 00:18:46.970
muss, der darauf abzielt dass man Promon
SHIELD entfernt. Und dann was ich gerade
00:18:46.970 --> 00:18:50.279
vorgestellt habe. Man schreibt einfach
die Konfigurationsdatei um.
00:18:50.279 --> 00:18:53.330
Da hat man auch kein Problem mit
Inkompatibilitäten, bleibt ja alles
00:18:53.330 --> 00:18:58.169
kompatibel. Man sagt im Prinzip nur de
facto mach einfach nichts.
00:18:59.559 --> 00:19:05.070
Danach ist die App im Prinzip komplett
ungeschützt. Die Hersteller implementieren
00:19:05.070 --> 00:19:11.000
in großem Stil auch keinen Repackaging-
Schutz und dergleichen mehr. Jetzt können
00:19:11.000 --> 00:19:14.490
wir doch eigentlich weiter automatisieren.
Jetzt mal als Beispiel-Angriff:
00:19:14.490 --> 00:19:18.100
Transaktionsmanipulation. Wir haben dann
gesagt, gut dann erweitern wir doch Nomorp
00:19:18.100 --> 00:19:24.429
mal so, dass wir das fast vollständig
automatisch machen können. Hier mal als
00:19:24.429 --> 00:19:28.240
Beispiel das VR Banking App. Eigentlich
was man immer nur machen will bei einer
00:19:28.240 --> 00:19:31.850
Transaktionsmanipulation ist: Man will
hier bestimmte Views, Text Views oder
00:19:31.850 --> 00:19:35.799
sowas, manipulieren. Das sind
halt in dem Fall die interessanten.
00:19:35.799 --> 00:19:41.539
Der 'Name des Empfängers' ist im Beispiel
falsch. Das muss natürlich was anders
00:19:41.539 --> 00:19:46.179
sein, das müsste die IBAN sein.
Entschuldigung. Das ist ein Fehler. Aber
00:19:46.179 --> 00:19:50.450
der txt_betrag ist richtig und die haben
natürlich eine ID irgendwo. Und die muss
00:19:50.450 --> 00:19:53.990
man quasi manuell ermitteln und alles
andere kann man dann vollständig
00:19:53.990 --> 00:19:58.330
automatisch machen. Also man kann dies
alles injecten. Man muss ja nur wissen was
00:19:58.330 --> 00:20:00.570
man danach austauschen muss
bzw. auslesen muss.
00:20:02.150 --> 00:20:05.539
Jetzt machen wir mal eine kleine Demo.
Jetzt kann sich aber mal wieder Yomo
00:20:05.539 --> 00:20:08.549
zurücklehnen und brauchen jetzt keine
Angst haben geht nicht mit ihnen weiter.
00:20:08.549 --> 00:20:15.110
Wir schauen uns das jetzt mal anhand der
VR Banken an. Das Video haben wir heute
00:20:15.110 --> 00:20:21.649
Nachmittag gemacht. Es ist etwas zügig
entstanden. Deswegen sage ich jetzt mal
00:20:21.649 --> 00:20:26.170
nochmal zuvor, was man gleich sehen wird.
Dieses Szenario ist das folgende: Wir
00:20:26.170 --> 00:20:30.059
haben ein Nexus 5X mit Android 7.0 und es
hat einen Security Patch Level von vor
00:20:30.059 --> 00:20:38.049
ungefähr einem Jahr. Und warum ist das so?
Wir wollten irgendwas wo man Dateien
00:20:38.049 --> 00:20:40.110
schreiben darf, die man eigentlich
schreiben darf.
00:20:40.110 --> 00:20:43.700
Also DirtyCOW ist ein klassisch gutes
Beispiel. Und warum es es auch so ein
00:20:43.700 --> 00:20:48.251
gutes Beispiel? Damit ist es gar nicht so
einfach root im Sinne von SuperSU zu
00:20:48.251 --> 00:20:51.910
bekommen. Ich glaube dass es erst vor
kurzem gelungen. Aber man kann Dateien
00:20:51.910 --> 00:20:56.549
schreiben die man eigentlich schreiben
dürfte. Dann lädt sich der Nutzer eine
00:20:56.549 --> 00:21:00.149
scheinbar gutartige App aus dem
offiziellen PlayStore herunter. Soll ja
00:21:00.149 --> 00:21:05.430
schon vorgekommen sein, dass da Leute es
geschafft haben sowas zu platzieren.
00:21:05.430 --> 00:21:10.201
Die App ersetzt dann die VR-Banking und die
VR-SecureGo App mit einer Nomorp Version –
00:21:10.201 --> 00:21:14.120
wird man dann gleich auch sehr schön
sehen. Danach führt der Nutzer eine
00:21:14.120 --> 00:21:17.510
Transaktion über 15 Euro durch und die
wird durch 1,23 Euro – ist nicht so
00:21:17.510 --> 00:21:24.000
logisch wenn man jetzt mal kriminell
denkt – ersetzt. Das ist eben eine
00:21:24.000 --> 00:21:27.580
Transaktionsmanipulation.
Und bis auf das bestimmen der ID ist was
00:21:27.580 --> 00:21:30.710
ich gerade gesagt habe komplett
vollautomatisch. Also das musste man nicht
00:21:30.710 --> 00:21:35.669
weiter antasten mit manuellen Aufwand,
sondern nur die IDs bestimmen.
00:21:35.669 --> 00:21:40.500
Jetzt machen wir kurz noch auf, dass man die
Versionen sieht. Das war das was ich
00:21:40.500 --> 00:21:43.409
gerade gesagt habe. Und als nächstes macht
mir jetzt erst mal die VR-Banking App auf
00:21:43.409 --> 00:21:46.809
und die wird jetzt schwarz, weil die hat
halt dieses Flag "secure" gesetzt damit
00:21:46.809 --> 00:21:52.400
man keine Aufnahmen machen machen kann.
So also da sieht man jetzt nichts. Ok.
00:21:52.400 --> 00:21:57.799
Die funktioniert anscheinend. So und jetzt
gehts weiter. Jetzt lädt man sich aus dem
00:21:57.799 --> 00:22:00.029
PlayStore herunter und ja, das ist echt.
00:22:00.029 --> 00:22:02.790
Gelächter
00:22:02.790 --> 00:22:08.899
Und das sieht man oben diese Leiste. Das
ist eine scheinbar gute App und jetzt
00:22:08.899 --> 00:22:14.680
wurde man im Hintergrund exploitet. Jetzt
machen wir die VR-Banking App nochmal auf.
00:22:17.724 --> 00:22:24.744
Gelächter und Applaus
00:22:25.930 --> 00:22:31.130
Jetzt muss man sich einloggen. Jetzt
machen wir die Transaktion und die geht
00:22:31.130 --> 00:22:41.980
diesmal an mich. Nur noch kurz die IBAN
eingeben. Die 15 Euro die ich gerade eben
00:22:41.980 --> 00:22:47.139
gesagt habe mit Verwendungszweck 34C3 (ist
aber nicht so wichtig in dem Fall).
00:22:49.059 --> 00:22:52.890
Und jetzt ist die Überweisung versendet
worden. Das bedeutet im nächsten Schritt
00:22:52.890 --> 00:22:59.539
muss man die Transaktion in der TAN App,
der VR-SecureGo App, freigeben. Gleiches
00:22:59.539 --> 00:23:05.059
Spiel: Hier wurde auch wieder irgendwas
gemacht. Ich muss wieder das Passwort
00:23:05.059 --> 00:23:10.710
eingeben. Dann im nächsten Schritt:
wichtig ist natürlich dass die IBAN
00:23:10.710 --> 00:23:13.249
stimmt, das geht aber so schnell, da
versichere ich euch dass das stimmt.
00:23:13.249 --> 00:23:19.559
Da stehen auch 15 Euro immer noch.
Also stimmt ja alles. Also geben wir die
00:23:19.559 --> 00:23:27.661
Transaktion frei. So genau da unten stehen
auch irgendwie 15 Euro. Passt ja alles.
00:23:28.851 --> 00:23:32.950
Und wenn man jetzt hier rein schaut, dann
waren es aber wirklich 1,23 Euro.
00:23:32.950 --> 00:23:42.810
Applaus
00:23:42.810 --> 00:23:46.870
Was hier wichtig ist, dass das
vollautomatisch war.
00:23:46.870 --> 00:23:51.240
Das nicht jeder irgendwie nochmal
eine App reversed hat,
00:23:51.240 --> 00:23:55.050
sondern man muss nur die IDs bestimmen
nachdem Promon draußen war
00:23:55.050 --> 00:23:57.620
und dann geht das.
00:23:58.420 --> 00:24:00.620
Dann komme ich mal zum Schluss:
00:24:00.620 --> 00:24:09.059
die Reaktionen der beteiligten Parteien
anschauen und ein Fazit zu schließen. Also
00:24:09.059 --> 00:24:13.700
mit Promon stehen wir seit Ende November –
also gut einen Monat – in Kontakt.
00:24:13.700 --> 00:24:18.179
Die waren sehr nett und professionell und sie
haben mittlerweile auch eine neue Version
00:24:18.179 --> 00:24:22.720
des Promon SHIELDs entwickelt. Die liegt
mir in der Beispiel-App auch vor, aber ich
00:24:22.720 --> 00:24:26.040
hatte noch nicht die Zeit, um da genauer
anzuschauen. Ich kann aber sagen unsere
00:24:26.040 --> 00:24:29.789
Nomorp Toolchain funktioniert auf diese
Art und Weise nicht mehr, also
00:24:29.789 --> 00:24:32.630
funktioniert nicht mehr wie zuvor. Ich
kann nicht genau sagen was wurde da jetzt
00:24:32.630 --> 00:24:36.870
genau gemacht und welche großen
Anpassungen sind zu machen. Es kann sein,
00:24:36.870 --> 00:24:40.490
dass es unglaublich viel Arbeit ist. Kann
aber auch sein, dass es nicht viel Arbeit ist.
00:24:40.490 --> 00:24:45.289
Ich kann es einfach nicht sagen.
Der Punkt ist eigentlich, um die Angriffe
00:24:45.289 --> 00:24:49.520
wirklich komplexer zu machen bräuchte man
mehr Individualisierung von den Apps.
00:24:49.520 --> 00:24:53.330
Man kann ja alle Apps gleichartig angreifen.
Man kann das Promon SHIELD auf die gleiche
00:24:53.330 --> 00:24:58.690
Art und Weise in all diesen 31 Apps
deaktivieren indem man diese Config
00:24:58.690 --> 00:25:02.820
rewritet, weil es überall gleich ist, da
es ein universaler Ansatz ist.
00:25:02.820 --> 00:25:08.779
Die Reaktion der Banken die ich seit
Jahren höre: "bis heute keine
00:25:08.779 --> 00:25:12.800
Schadensfälle bekannt." Das ist natürlich
ein merkwürdiges Verständnis von
00:25:12.800 --> 00:25:18.429
IT-Sicherheit. Wenn man sich jetzt aber
mal anschaut, wie eigentlich überhaupt die
00:25:18.429 --> 00:25:22.400
Verteilung von Mobilebanking ist oder von
App basierten TAN Verfahren, dann sind die
00:25:22.400 --> 00:25:27.850
einfach nicht relevant aktuell im Markt.
5-8% hat letztes Jahr hat eine Studie
00:25:27.850 --> 00:25:32.850
ergeben, sind die App basierten TAN
Verfahren verbreitet. Dies soll sich
00:25:32.850 --> 00:25:36.559
dieses Jahr nicht groß geändert haben.
Natürlich, aktuell lohnt sich das noch
00:25:36.559 --> 00:25:40.529
nicht aber das kann sich
für die Zukunft ändern.
00:25:42.319 --> 00:25:47.120
Das finde ich ein sehr schönes Zitat von
Jens Bender und Dennis Kügler vom BSI:
00:25:47.120 --> 00:25:50.900
"Im Bereich des Zahlungswesens hat sich
eine besondere Kreativität in der Auslegung
00:25:50.900 --> 00:25:53.640
der Eigenschaft einer
Zweifaktorauthentisierung entwickelt."
00:25:54.049 --> 00:25:56.089
Gelächter
00:25:56.089 --> 00:26:01.130
Applaus
00:26:01.130 --> 00:26:06.059
Ja, kann ich nur zustimmen. Und jetzt wenn man
jetzt denkt nach Mobilebanking, also nach
00:26:06.059 --> 00:26:10.440
zwei Apps auf einem Smartphone, wird es
nicht mehr schlimmer – das gibt es jetzt
00:26:10.440 --> 00:26:19.680
mittlerweile auch auf einem Windows und
auf einem Mac PC. Ok, kann man machen.
00:26:21.470 --> 00:26:27.760
Zwei Fragen ganz zum Schluss: ist App-
Härtung überhaupt sinnvoll? Also haben
00:26:27.760 --> 00:26:32.480
diese ganzen Produkte, die ganzen Markt
angeboten werden, eine Daseinsberechtigung?
00:26:33.190 --> 00:26:36.320
Ja, natürlich haben die eine eine
Daseinsberechtigung. Sie haben
00:26:36.320 --> 00:26:40.110
schon einen sinnvollen Schutz die
sie da einbetten. Aber das muss ein
00:26:40.120 --> 00:26:41.889
zusätzlicher Schutz sein.
00:26:41.889 --> 00:26:44.539
Und die andere Frage: Ist App-Härtung
ein Ersatz für unabhängige
00:26:44.539 --> 00:26:47.280
Zweifaktor-Authentifizierung?
Natürlich nicht!
00:26:47.280 --> 00:26:53.580
Das habe ich gerade eben gesagt. Weil dies
Softwaremaßnahmen sind und die können,
00:26:53.580 --> 00:26:56.080
wie wir in dem Beispiel gezeigt haben,
00:26:56.080 --> 00:26:59.510
einfach nicht verhindern, dass
jemand das ausnutzt.
00:27:00.820 --> 00:27:02.510
Danke
00:27:02.510 --> 00:27:14.020
Applaus
00:27:14.020 --> 00:27:16.120
Herald: Vielen Dank Vincent für Deinen Talk
00:27:16.120 --> 00:27:21.970
und Deinen weiteren Ausflug in die
Welt des Mobilebankings. Wir haben Zeit
00:27:21.970 --> 00:27:26.850
für einige Fragen. Also wenn ihr Fragen
habt, reiht auch an den Mikrofonen auf.
00:27:26.850 --> 00:27:36.279
Hier gibt es 1,3, da vorne ist 2, usw. Die
haben Nummern dran und dann kann Vincent
00:27:36.279 --> 00:27:39.380
ein Paar Fragen für Euch beantworten.
00:27:47.469 --> 00:27:49.659
Ihr könnt auch winken wenn ihr an einem steht.
00:27:50.850 --> 00:27:53.460
Ok. An Mikrofon 3 haben wir eine Frage.
00:27:53.460 --> 00:27:56.460
Mikrofon 3: Vielen Dank für den Talk.
Ganz toll!
00:27:56.460 --> 00:28:02.080
Jetzt gibt es schon für DRM-Systeme
Dinge wie Widevine, die TrustZone
00:28:02.080 --> 00:28:07.519
im Chip direkt verwenden. Hast Du bei
Deiner Forschung das irgendwas von gesehen?
00:28:07.550 --> 00:28:11.140
Vincent: Das ist ein wichtiger Punkt und
00:28:11.140 --> 00:28:15.540
ich glaube auch das TrustZone oder
allgemeiner Trusted Execution Environments
00:28:15.540 --> 00:28:21.019
eine Art und Weise wäre, in der man so
etwas in zufriedenstellend sicherer auf
00:28:21.019 --> 00:28:25.840
einem Gerät machen könnte. Gerade eben
lief der BootStomp Vortrag von den Jungs
00:28:25.840 --> 00:28:30.950
der UCSB. Die würden mir da vielleicht
widersprechen. Insgesamt ist das ein
00:28:30.950 --> 00:28:36.080
Einsatz auf den könnte das aufbauen, aber
das ich genau da etwas gesehen habe, kann
00:28:36.080 --> 00:28:40.850
ich jetzt nicht behaupten. Jetzt gerade
die alle setzen das nicht ein. Ist
00:28:40.850 --> 00:28:43.830
natürlich auch das Problem, dass es da
keine einheitliche Lösung gibt. Da gibt es
00:28:43.830 --> 00:28:47.179
bisher ein Paar proprietäre Lösungen und
jeder will sich da irgendwie durchsetzen.
00:28:47.179 --> 00:28:48.610
Aber einen einheitlichen Standard gibt es
nicht und von daher ist es schwierig.
00:28:48.610 --> 00:28:55.190
Herald: Mikrofon 1 bitte.
Mikrofon 1: Waren die untersuchten Apps
00:28:55.190 --> 00:29:01.640
alle schon nach der PSD2-Richtlinie
zugelassen? Also bezog sich darauf das
00:29:01.640 --> 00:29:06.860
Zitat von den BSI Leuten? Die schreibt das
ja explizit vor Zweifaktorauthentisierung.
00:29:06.860 --> 00:29:13.419
Vincent: Genau die PSD2 schreibt vor:
starke Kundenauthentifizierung. Da müsste
00:29:13.419 --> 00:29:16.200
man jetzt weiter ausholen. Da wurden
gerade eben die technischen Standards
00:29:16.200 --> 00:29:20.070
dafür verabschiedet. Gibt es noch eine
18-monatige Übergangsfrist, wo die Banken
00:29:20.070 --> 00:29:24.429
Zeit haben sich da anzupassen. Aber in den
ganzen Werbevideos wird ganz oft davon
00:29:24.429 --> 00:29:28.980
gesprochen – jetzt gerade von diesen
Drittanbietern, dass sie PSD2 kompatibel
00:29:28.980 --> 00:29:33.029
sind. Es ist ein bisschen schwierig zu
sagen, was die PSD2 da genau vorschreibt.
00:29:33.029 --> 00:29:37.169
Ich glaube so die letzte Entscheidung die
dazu getroffen wurde ist eher in Richtung
00:29:37.169 --> 00:29:40.990
wir akzeptieren den status quo. Man kann
das meiner Meinung nach immer noch so
00:29:40.990 --> 00:29:46.850
lesen, dass eine sichere Anzeige und eine
Nichtkopierbarkeit für ein Besitzelement
00:29:46.850 --> 00:29:51.820
hat. Also von daher ist das nicht ganz
klar. Wenn sie jetzt die Banken fragen,
00:29:51.820 --> 00:29:53.850
dann sagen die natürlich sind sie PSD2
konform.
00:29:53.850 --> 00:30:00.750
Herald: Fragen wir den Signal Angel. Gibt
es Fragen aus dem Internet?
00:30:00.750 --> 00:30:05.490
Stille
00:30:05.490 --> 00:30:09.429
Herald: Das scheint nicht der Fall zu sein.
Ich habe noch eine Frage an Mikrofon 2.
00:30:09.429 --> 00:30:14.010
Mikrofon 2: Hast Du Dir aus Promon noch
andere Bibliotheken angesehen?
00:30:14.010 --> 00:30:18.679
Vincent: Nein. Habe ich nicht. Das liegt
aber einfach auch daran, es gibt ein Paar
00:30:18.679 --> 00:30:21.840
andere die im deutschen Markt verbreitet
sind, oder was heist Verbreitung? Es gibt
00:30:21.840 --> 00:30:24.890
Vereinzelte, die das einsetzen. Die
Deutsche Bank setzt mittlerweile ARXAN
00:30:24.890 --> 00:30:29.559
ein. Dann gibt es noch die ING-DiBa die
Kobil verwendet. Da kann ich jetzt nicht
00:30:29.559 --> 00:30:33.750
genaueres zu sagen. Ich meine ich habe ja
auch nichts per se gegen Promon - kein
00:30:33.750 --> 00:30:36.990
Problem mit denen. Aber das Problem ist
eher, dass sie so relevant im deutschen
00:30:36.990 --> 00:30:40.610
Markt sind und ich irgendwie fesgestellt
habe, dass so gut wie jeder sie
00:30:40.610 --> 00:30:44.389
verwendet. Deswegen hat es sich halt
gelohnt, das genauer anzuschauen. Wenn
00:30:44.389 --> 00:30:48.470
jetzt jeder eine andere App-Härtungslösung
verwenden würde, dann hätte man einen viel
00:30:48.470 --> 00:30:52.169
größeren Aufwand. Dann müsste man sich ja
alle anschauen. Und so ist es aber man
00:30:52.169 --> 00:30:57.180
kann einmal Promon deaktivieren und das
geht für alle. Das ist ja eigentlich das Problem.
00:30:57.990 --> 00:31:00.120
Herald: Letzte Frage von Mikrofon 1.
00:31:00.310 --> 00:31:04.930
Mikrofon 1: Vielen Dank für den Vortrag.
Eine Frage zu dem Angriffsvektior: in
00:31:04.930 --> 00:31:10.919
diesem Fall wurde einfach die App
ausgetauscht und dann – sagen wir einmal –
00:31:10.919 --> 00:31:14.649
leicht angreifbar gemacht. Wäre es
denkbar, vielleicht auch beim gerooteten
00:31:14.649 --> 00:31:19.059
Phone, dass man da einfach nebendran eine
Application hätte, die das einfach on-the-
00:31:19.059 --> 00:31:23.629
fly austauscht und so Applikationen
angreift. Hast Du das untersucht?
00:31:23.629 --> 00:31:28.930
Vincent: Also das machen wir ja im
Endeffekt. Wir binden eine Komponente in
00:31:28.930 --> 00:31:34.460
diese App ein die das macht. Ich meine in
dem Fall wurde das halt ersetzt, aber ich
00:31:34.460 --> 00:31:39.050
glaube nur, dass das Ersetzen von einer
App ist mitunter das Einfachste,
00:31:39.050 --> 00:31:40.050
was man machen kann.
00:31:40.050 --> 00:31:41.850
Mikrofon 1: Ich meine, wenn es nicht
gerootet wäre, dann wäre es nicht möglich
00:31:41.850 --> 00:31:47.010
von einer App auf die Andere zuzugreifen
und das auszutauschen. Also das müsste
00:31:47.010 --> 00:31:53.240
natürlich gerootet werden oder
gibt es andere Ansätze?
00:31:53.240 --> 00:31:58.190
Vincent: Es gibt immer noch eine Unschärfe
00:31:58.190 --> 00:32:01.899
zwischen was ist ein root-Exploit also
priviledge escalation und was ist ein
00:32:01.899 --> 00:32:05.690
gerootetes Gerät. Ein gerootetes Gerät ist
bei mir eine bewusste Entscheidung: ich
00:32:05.690 --> 00:32:09.870
installiere bei mir SuperSU oder Magisk.
Das ist bei mir eine bewusste
00:32:09.870 --> 00:32:13.720
Entscheidung. Dafür verwende ich unter
Umständen priviledge escalation um das zu
00:32:13.720 --> 00:32:18.179
Platzieren, aber ein priviledge escalation
an Sich, zum Beispiel DirtyCow ausnutzen
00:32:18.179 --> 00:32:22.149
ist nicht persistent – das wird einmal
ausgenutzt. Spuren davon, da müssen wir
00:32:22.149 --> 00:32:26.131
jetzt einen Forensiker fragen, aber ich
glaube das ist schwierig. Und das ist der
00:32:26.131 --> 00:32:29.139
große Unterschied davon. Priviledge
escalation mache ich einmal, um meinen
00:32:29.139 --> 00:32:32.990
Angriffsvektor zu platzieren und danach
nützen die ganzen root detections von den
00:32:32.990 --> 00:32:36.244
Systemen gar nichts mehr: ich habe kein
SuperSU installiert.
00:32:37.984 --> 00:32:41.574
Herald: Ok. Nochmal herzlichen Dank
Vincent Haupert. Einen großen Applaus.
00:32:41.870 --> 00:32:49.559
Applaus
00:32:49.559 --> 00:32:52.336
34c3 outro
00:32:52.336 --> 00:33:11.000
Untertitel erstellt von c3subtitles.de
im Jahr 2018. Mach mit und hilf uns!