Return to Video

34C3 - Die fabelhafte Welt des Mobilebankings

  • 0:00 - 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:46 - 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:07 - 1:16
    *Applaus*
    Vincent: Herzlichen Dank für die
  • 1:16 - 1:22
    Einführung. 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:41
    gewesen wäre. Herzlichen Dank an ihn.
    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:51
    PIN/TAN Verfahren seitdem es von vor 30
    Jahren. Jetzt bin ich weg. Test ok dann
  • 1:51 - 2:02
    hört man mich auch. Sorry ok. Also seid
    jeher im PIN/TAN Verfahren. Ihr erster
  • 2:02 - 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 gerechte 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 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:36
    das ein hoher individueller und manuelle
    Aufwand." Und genau dies werden wir heute
  • 5:36 - 5:41
    adressieren.
    *Applaus*
  • 5:41 - 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 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 und das ist
    aus dem Video das nächste Zitat: "Es
  • 6:46 - 6:50
    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:09
    *Gelächter und Applaus*
    Schauen wir uns das mal genauer an. Was
  • 7:09 - 7:13
    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 es ist 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. Ja und das ist jetzt so die
  • 8:07 - 8:15
    Liste an Apps – das sind 31 international
    – die Promon SHIELD verwenden. Die zwei
  • 8:15 - 8:18
    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, die
  • 8:32 - 8:37
    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 die
  • 8:47 - 8:49
    vielleicht nicht jeder kennt und das ist
    Yomo.
  • 8:49 - 8:55
    Warum ist eigentlich Yomo so besonders
    interessant? Yomo ist eigentlich erst
  • 8:55 - 8:57
    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:15
    Gerücht, dass das intern sogenannten
    Number 27 hieß. Also das Vorbild ist
  • 9:15 - 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:31
    irgendwie mit Sparkasse was, dass die da
    schon die neueste Version verwenden. Wenn
  • 9:31 - 9:32
    Sie jetzt sagen Wir machen auch so ein
    Ein-App-Authentifizierungs-System.
  • 9:32 - 9:40
    Wie funktioniert das denn intern, wenn man
    ein bisschen technischer wird? Wenn diese
  • 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:07
    Dann werden aber zusätzlich aus der App
    aus der eigentlichen App, jetzt also zum
  • 10:07 - 10:12
    Beispiel Yomo, 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:35
    irgendwie loswerden. Dann modifizieren wir
    halt mal diese Library – diese native
  • 10:35 - 10:41
    library. 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:03
    das diese Open-Source Variante ist oder
    irgendwas selbst angepasst ist. Das kann
  • 11:03 - 11:07
    ich nicht genau sagen. Aber auf jeden Fall
    das ist ökonomisch nicht machbar. Sagen
  • 11:07 - 11:12
    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:20
    halt aus der App. So einfach ist das dann
    auch wieder nicht. Weil wir haben ja das
  • 11:20 - 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:48
    bevor man in die Promon verwendt hat und
    links unten ist danach. Es ist dann halt
  • 11:48 - 11:55
    einfach so, dass wenn da jetzt einfach
    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:02
    irgendwelche Mappings bei sich drinnen und
    gibt dann halt den String zurück.
  • 12:02 - 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:31
    machen brauchen, weil man kann ja einfach
    drüber iterieren bis NULL zurückkommt.
  • 12:31 - 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:51
    diesen Request in dieser native Library
    und die fügen das Zertifikat hinzu. Und
  • 13:51 - 13:52
    jetzt kann man ja nicht einfach irgendwas
    aufrufen "gib mir mal das Client
  • 13:52 - 13:58
    Zertifikat" – ja gut das könnte sein aber
    ist nicht so. Was machen wir denn jetzt
  • 13:58 - 14:03
    da? 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 figer aber was wir gefunden
  • 14:11 - 14:16
    haben war eine noch viel interessantere
    Datenstruktur. Das sieht ein bisschen wirr
  • 14:16 - 14:21
    aus 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:29
    enkodiert da drin: clientCertificate und
    clientCertificateKey. Schön.
  • 14:29 - 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:43
    Also wir laden es aus dem Playstore
    herunter dann haben wir eine geschützte
  • 14:43 - 14:49
    App. 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:17
    jetzt unser Tool und dann kommt die
    ungeschützte App raus. Also dann ist man
  • 15:17 - 15:21
    das losgeworden.
    *Applaus*
  • 15:21 - 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 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. Was
  • 17:20 - 17:25
    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:31
    sollte diese URL hier öffnen. Das ist bei
    den anderen Sachen relativ analog sei man
  • 17:31 - 17:38
    ja. Wie wärs denn wenn wir diese
    Konfigurationsdatei einfach nachdem sie
  • 17:38 - 17:44
    entschlüsselt wurde, bevor sie gefasst
    wird modifizieren? Wir sagen einfach "Hey
  • 17:44 - 17:49
    wir schreien überall null rein". Also zu
    dem Zeitpunkt haben uns schon ein bisschen
  • 17:49 - 17:56
    geärgert, weil das andere war echt viel
    Arbeit.
  • 17:56 - 18:06
    *Gelächter und Applaus*
    Das war bisher alles sehr Android
  • 18:06 - 18:13
    spezifisch, 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:36
    sagen "wir schreiben das halt um".
    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
  • 18:42 - 18:47
    transformieren muss, der darauf abzielt
    dass man Promon SHIELD entfernt. Und dann
  • 18:47 - 18:49
    was ich gerade vorgestellt habe. Man
    schreibt einfach die Konfigurationsdatei
  • 18:49 - 18:53
    um. 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.
  • 18:58 - 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:15
    wir doch eigentlich weiter automatisieren.
    Jetzt mal als Beispiel-Angriff:
  • 19:15 - 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:01 - 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. Die
  • 21:05 - 21:10
    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. Jetzt
  • 21:36 - 21:40
    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:53
    man keine Aufnahmen machen machen kann. So
    also da sieht man jetzt nichts. Ok – die
  • 21:53 - 21:58
    funktioniert anscheinend. So und jetzt
    gehts weiter. Jetzt lädt man sich aus dem
  • 21:58 - 22:02
    PlayStore herunter und ja, das ist echt.
    *Gelächter*
  • 22:02 - 22:09
    Und das sieht man oben diese Leiste. Das
    ist eine scheinbar gute App und jetzt
  • 22:09 - 22:20
    wurde man im Hintergrund exploitet. Jetzt
    machen wir die VR-Banking App nochmal auf.
  • 22:20 - 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:49
    gesagt habe mit Verwendungszweck 34C3 (ist
    aber nicht so wichtig in dem Fall). Und
  • 22:49 - 22:53
    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:14
    stimmt, das geht aber so schnell, da
    versichere ich euch dass das stimmt. Da
  • 23:14 - 23:20
    stehen auch 15 Euro immer noch. Also
    stimmt ja alles. Also geben wir die
  • 23:20 - 23:29
    Transaktion frei. So genau da unten stehen
    auch irgendwie 15 Euro. Passt ja alles.
  • 23:29 - 23:37
    Und wenn man jetzt hier rein schaut, dann
    waren es aber wirklich 1,23 Euro.
  • 23:37 - 23:46
    *Applaus*
    Was hier wichtig ist, dass das
  • 23:46 - 23:51
    vollautomatisch war. Das nicht jeder
    irgendwie nochmal eine App reversed hat,
  • 23:51 - 23:56
    sondern man muss nur die IDs bestimmen
    nachdem Promon draußen war und dann geht
  • 23:56 - 24:01
    das.
    Dann komme ich mal zum Schluss: die
  • 24:01 - 24:09
    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. Die
  • 24:14 - 24:18
    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
  • 24:40 - 24:45
    ist. 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. Man
  • 24:50 - 24:53
    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:14
    Schadensfälle bekannt." Das ist natürlich
    ein merkwürdiges Verständnis von IT-
  • 25:14 - 25:18
    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:41 - 25:48
    Das finde ich ein sehr schönes Zitat von
    Jens Bender und Dennis Kügler vom BSI: "Im
  • 25:48 - 25:51
    Bereich des Zahlungswesens hat sich eine
    besondere Kreativität in der Auslegung der
  • 25:51 - 26:02
    Eigenschaft einer
    Zweifaktorauthentisierung entwickelt." Ja,
  • 26:02 - 26:06
    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:21
    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
  • 26:32 - 26:36
    Daseinsberechtigung? Ja, natürlich haben
    die eine eine Daseinsberechtigung. Die sie
  • 26:36 - 26:40
    haben schon einen sinnvollen Schutz die
    sie da einbetten. Aber das muss ein
  • 26:40 - 26:44
    zusätzlicher Schutz sein.
    Und die andere Frage: Ist es App-Härtung
  • 26:44 - 26:48
    ein Ersatz für unabhängige Zweifaktor-
    Authentifizierung? Natürlich nicht! Das
  • 26:48 - 26:54
    habe ich gerade eben gesagt. Weil dies
    sind Softwaremaßnahmen und die können, wie
  • 26:54 - 26:58
    wir in dem Beispiel gezeigt haben, einfach
    nicht verhindern, dass jemand das
  • 26:58 - 27:03
    ausnutzt.
    Danke
  • 27:03 - 27:16
    *Applaus*
    Herald: Vielen Dank Vincent für Deinen
  • 27:16 - 27:22
    Talk 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. Die
    haben Nummern dran und dann kann Vincent
  • 27:36 - 27:49
    ein Paar Fragen für Euch beantworten. Ihr
    könnt auch winken wenn ihr an einem steht.
  • 27:49 - 27:56
    Ok. An Mikrofon 3 haben wir eine Frage.
    Mikrofon 3: Vielen Dank für den Talk –
  • 27:56 - 28:02
    ganz toll! Jetzt gibt es schon für DRM-
    Systeme Dinge wie Widevine, die TrustZone
  • 28:02 - 28:06
    im Chip direkt verwenden. Hast Du bei
    Deiner Forschung das irgendwas von
  • 28:06 - 28:11
    gesehen?
    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:06
    *Stille*
    Herald: Das scheint nicht der Fall zu
  • 30:06 - 30:09
    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:23
    andere die im deutschen Markt verbreitet
    sind, oder was heist Verbreitung? Es gibt
  • 30:23 - 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:56
    kann einmal Promon deaktivieren und das
    geht für alle. Das ist ja eigentlich das
  • 30:56 - 31:00
    Problem.
    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 was man
  • 31:39 - 31:42
    machen kann.
    Mikrofon 1: Ich meine, wenn es nicht
  • 31:42 - 31:47
    gerootet wäre, dann wäre es nicht möglich
    von einer App auf die Andere zuzugreifen
  • 31:47 - 31:52
    und das auszutauschen. Also das müsste
    natürlich gerootet werden oder gibt es
  • 31:52 - 31:58
    andere Ansätze.
    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:36 - 33:01
    Herald: Ok. Nochmal herzlichen Dank
    Vincent Haupert. Einen großen Applaus.
  • 33:01 - 33:08
    *Applaus*
Title:
34C3 - Die fabelhafte Welt des Mobilebankings
Description:

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

German subtitles

Revisions Compare revisions