Return to Video

34C3 - Die fabelhafte Welt des Mobilebankings

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

    Herald: Letzte Frage von Mikrofon 1.
  • 31:00 - 31:05
    Mikrofon 1: Vielen Dank für den Vortrag.
    Eine Frage zu dem Angriffsvektior: in
  • 31:05 - 31:11
    diesem Fall wurde einfach die App
    ausgetauscht und dann – sagen wir einmal –
  • 31:11 - 31:15
    leicht angreifbar gemacht. Wäre es
    denkbar, vielleicht auch beim gerooteten
  • 31:15 - 31:19
    Phone, dass man da einfach nebendran eine
    Application hätte, die das einfach on-the-
  • 31:19 - 31:24
    fly austauscht und so Applikationen
    angreift. Hast Du das untersucht?
  • 31:24 - 31:29
    Vincent: Also das machen wir ja im
    Endeffekt. Wir binden eine Komponente in
  • 31:29 - 31:34
    diese App ein die das macht. Ich meine in
    dem Fall wurde das halt ersetzt, aber ich
  • 31:34 - 31:39
    glaube nur, dass das Ersetzen von einer
    App ist mitunter das Einfachste,
  • 31:39 - 31:40
    was man machen kann.
  • 31:40 - 31:42
    Mikrofon 1: Ich meine, wenn es nicht
    gerootet wäre, dann wäre es nicht möglich
  • 31:42 - 31:47
    von einer App auf die Andere zuzugreifen
    und das auszutauschen. Also das müsste
  • 31:47 - 31:53
    natürlich gerootet werden oder
    gibt es andere Ansätze?
  • 31:53 - 31:58
    Vincent: Es gibt immer noch eine Unschärfe
  • 31:58 - 32:02
    zwischen was ist ein root-Exploit also
    priviledge escalation und was ist ein
  • 32:02 - 32:06
    gerootetes Gerät. Ein gerootetes Gerät ist
    bei mir eine bewusste Entscheidung: ich
  • 32:06 - 32:10
    installiere bei mir SuperSU oder Magisk.
    Das ist bei mir eine bewusste
  • 32:10 - 32:14
    Entscheidung. Dafür verwende ich unter
    Umständen priviledge escalation um das zu
  • 32:14 - 32:18
    Platzieren, aber ein priviledge escalation
    an Sich, zum Beispiel DirtyCow ausnutzen
  • 32:18 - 32:22
    ist nicht persistent – das wird einmal
    ausgenutzt. Spuren davon, da müssen wir
  • 32:22 - 32:26
    jetzt einen Forensiker fragen, aber ich
    glaube das ist schwierig. Und das ist der
  • 32:26 - 32:29
    große Unterschied davon. Priviledge
    escalation mache ich einmal, um meinen
  • 32:29 - 32:33
    Angriffsvektor zu platzieren und danach
    nützen die ganzen root detections von den
  • 32:33 - 32:36
    Systemen gar nichts mehr: ich habe kein
    SuperSU installiert.
  • 32:38 - 32:42
    Herald: Ok. Nochmal herzlichen Dank
    Vincent Haupert. Einen großen Applaus.
  • 32:42 - 32:50
    Applaus
  • 32:50 - 32:53
    ♪ (34C3 hold music) ♪
Title:
34C3 - Die fabelhafte Welt des Mobilebankings
Description:

more » « less
Video Language:
German
Duration:
33:11

German subtitles

Revisions Compare revisions