 Das ist Audrey, aus Kalifornien, und sie ist aus der Universität Kalifornien, Santa Barbara Security Lab. Sie kommt aus Kalifornien und die Tät von Kalifornien, in Santa Barbara. Sie wird uns automatische Schwachstellenerkennung im Android-Bootloader erzählen. Es ist jetzt nicht dabei einstecken, fährt, aber jetzt müssen wir uns hören, was kommt. Hier geht es los. Bitte, begrüßt mit mir alle zusammen, Audrey Dutcher. Guten Abend, Hallo alle zusammen. Wir sprechen also immer Android-Bootloader. Ich habe übrigens da nicht dran gearbeitet, ich saß nur gegenüber den Leuten, die daran gearbeitet haben. Und ich war der einzige, der nach Deutschland kommen konnte. Ich habe also irgendwie zur Arbeit gearbeitet, aber das ist zwar mein Thema, aber es ist nicht mein Projekt, aber das ist mein Thema. Vielen Dank. Android-Bootloader ist also das, was wir uns heute machen. Die Teams sind sehr komplikated, die Prozesse sind komplikated und es ist schon mal sehr hart, wenn man da geht, und es ist schon mal sehr, sehr komplikated. Wenn man das Telefon-Money-Sensitivität macht, dann wird das noch komplizierter. Aber jeder von euch hat wahrscheinlich schon mal ein Telefon, und es sind auch sehr, sehr wertvolle Ziele für Angriffe, und wir wollen auf jeden Fall Fehler darin erkennen. Wenn wir das angemacht haben, dann initialisieren wir das. Wir initialisieren das Device in den Riff-Rolls, und dann die Final-Gasp-Breath, das Bootloader ist das letzte Akt, das Bootloader ist, um das Kernel zu nehmen, und das Kernel muss natürlich aus dem Sprech geladen werden. Das ist ein Android-Specifischen, da es nicht besonders standard ist, es gibt keine besonderen Standards, die Amazon-Politikation, die eine Linie wieder so aussehen könnte, aber es gibt mehrere Bootloader, es gibt mehrere Bootloader, es ist eine komplikative Fähre, die viele Sicherheitsproperte haben, und es gibt viele verschiedene Sicherheits-Eigenschaften, und überall über das ganze Ziel ist, wir wollen sicher machen, dass unsere Daten schützen, und dass das sicher ist. Okay, so wie wir gedacht haben, die Telefone in unseren Taschen sind sehr wertvolle Ziele, wenn man sie antworten kann, wenn man ein Boot oder antworten kann, dann kann man quasi das Gerät-Root-Kitten, also wenn ein Angriffe den Telefon, damit antreffen kann, dann kann das Gerät-Root-Kitten. Aber er kann auch die ja, das Bootloader zum Beispiel, um schütten, oder man möchte das lecken, um es selber anzupassen, in das Customise, das machen wir vielleicht heute sogar freiwillig mit unseren Telefonen. Der Bootloader establishes eine Kryptografik-Integrity über, basically, was happening at all times. So, auf dem Telefon, da ist ein Soundfassant, was da passiert, und der weiß, dass er nur Code ausführen soll, dass er mit den Schlüssel, der Hardware, der Bootloader ausführen soll, dass er nicht schütte, das Bootloader ist davon nicht, dass man nicht verletzt wird, wenn er so eine Trauskette hat. Und ich bin sehr, sehr sicher, dass er das Ahnung hat, weil das nächste Code soll nichts machen, was sich nicht autorisiert, dass es um Schiffen ist, natürlich wertvoll. Telefonen sollten ein Weg haben, das zu tun, wenn du gerade entlebt bist, aber die Sache von einem Angriff zu unterscheiden ist, natürlich der Punkt, den es sich dreht. Man sollte also wirklich sicher machen, dass der echte Besitzer des Telefons einen Schlüssel erlocken kann. Okay, also, es geht zu Ende des Code, warum Verletzlichkeiten zu entdecken und zu verhindern, dass ein Ankerfer der Verletzlichkeiten ist. Ja, das sollte eigentlich jeder wissen, aber es ist nicht so, dass der Punkt ist, dass die Sicherheits-Eigenschaften des Telefons sind. Was sind diese Garantien oder wenn ich davon, was im Kernel passiert? Also, werden wir heute über Bootslam reden. Das ist ein Werkzeug, das automatisch diese Prozesse verifiziert und Bugs entdeckt. Ich bin ein bisschen langsam, ich muss mich ein bisschen schneller machen. Erstmal der Boot-Prozess in Android-Ecosystems ist ziemlich kompliziert und für mehrere Schichten unterteilt. Es gibt hier den Basis-Grundlader BL0, der einen anderen Bootlader verifiziert, der wird mit einem anderen Bootlader verifiziert. Vom Hardware-Verkäufer und der dritte ist wahrscheinlich vom Betriebssystem-Zerkäufer und die müssen alle unterschiedliche Sachen machen. Was das Wichtige ist hier, sind diese EL-Levels und die exception-Levels, also die globalen Rechte-Levels. EL3 ist sozusagen der God-Mode in EL1 ist der Kernel und EL0 ist im User-Space. Wenn wir booten, dann sind wir natürlich im höchsten Ausführungs-Modus und gehen dann immer niedriger und geben die Kontrolle an weniger privilegierte Komponenten ab. Ein Ding, was sie tun müssen, ist die AM-Vertrauenszone zu etablieren, die Leuten ermöglicht, sichere Sachen zu tun auf den Android-Telefon. Das ist etwas, das von dem BL-31 Bootloader eingerichtet wird. In der sicheren Welt muss man hardware und Peripherie initialisieren und in der nicht-sickeeren Welt kann man den normalen Kernel und den normalen User-Space-App laufen lassen. Auf eigenen Telefonen gibt es ein BL-33 und das ist der, den wir viel angreifen wollen. Das ist also diese Kette von Vertrauen, diese Chain of Trust und die nächste Ebene wird eben nur dann geladen, wenn wir wirklich sicher sind, dass das alles authentiziert ist, wenn wir sichern, was passiert. Und das ist das Entsperren, der Entsperrprozess, über den wir gesprochen haben. Also wenn du, also der Entsperren ist, dann kann man den letzten Schritt überspringen und eben zulassen, dass man auch nicht vertrauten Code auf dem Gerät aussieht. Das ist so eine Sache. Dass das Entsperren ist, man für das Entsperren braucht man eben physischen Zugriff auf das Gerät und man muss es halt wirklich besitzen. Also du musst dann hinwissen, dass das eben was passiert. Also insbesondere, wenn man durch diesen Prozess durchgeht, gibt es ein paar spezifische Flangenflags, die sagt, dass es jetzt entsperrt, jetzt kannst du machen, was du willst, aber man muss sicherstellen, dass es eben nur passieren kann, wenn es autorisiert ist. Daum, wo man sich dreht. Normalerweise ist diese Sicherheitszustand aber man kann nicht einfach Entsperren setzen, aber eben insigniert von den Leuten, denen wir wirklich vertrauen. Aber im Allgemeinen sollte man eben nicht möglich sein, darauf zu sprechen, darauf schreiben zu können aus einem normalen Newspaces. Die Frage ist, wir haben jetzt gesehen, dass Betriebssysteme sind separat vom Bootloader. Was wir machen möchten ist vom Android-Betriebssystem zum Bootloader zu kommen und kann das passieren? Natürlich, deshalb sind wir hier. Ich bin nicht realisiert, dass die Animationen sind. Das ist sozusagen der normale Flowchart, wie diese Dinge normalerweise passieren. Man hat ein Bootloader, der muss vom umlesen, und natürlich lesen können, ob das Gerät überhaupt entsperrt ist. Es gibt sehr viele Inputs. Von Inzion her sind es einfach ganz normale Eingaben in einem Programm und das kann man natürlich auf Schwachstellen untersuchen. Also vom Betriebssystem kann man mit Rohzugang auf diesen Speicher zugreifen. Das heißt, man hat gewissermaßen eine weitere Eingangsmöglichkeit zum Bootloader und das kann natürlich für Ursachen, dass schlechte böse Dinge passieren. Also, wir brauchen ein gewisses Werkzeug, um automatisch die Sicherheitsprozede zu verifizieren und das Bootstump. Bootloaders sind kompliziert. Es gibt also, es muss irgendwie automatisiert werden, was so groß und kompliziert ist wie ein Bootloader, um überhaupt irgendwas finden zu können. Also Bugs, die halt existieren können. Aber für diese Dinge hat man generell kein Quelco, das wird Benia-Analyse und man kann natürlich keine dynamische Analyse machen, was das auf einem höchsten Level läuft. Außerdem muss es eben offiziell freistehend sein. Es gibt keine bekannten APIs und wir können das dann halt echt für die schwere analysieren. Okay, Bootstump im Spezial, ein Deckzeug wird jetzt auf die Inputs das wir talked about zu Bootloader und dann wird es bestimmen, ob diese Inputs benutzt werden können, um bestimmte Sicherheitseinschaften zu kompokieren. Ein Beispiel ist, zum Beispiel, wenn man Speicherkorrupt zu erreichen kann oder abstrafftare Formen von Verletzbarkeit, zum Beispiel Kotflows, also wenn man daten irgendwie schreibt von einem höherbegrüßigen Bootloader und der gesamte Punkt dieser Analyse ist das sehr einfach, verifizielbar und verfolgbar sein soll, sodass man einfach von den Ausgaben verstehen kann, was passiert ist und dass man das hoffentlich wieder reproduzieren kann. Vielleicht durch symbolische Analyse ich kenne diesen Teil, wenn ich arbeite für symbolische Ausführungsanalyse in order to do Boot-Tainting-Analysis. Okay. Diese Tainting-Analysis, also komische Worte, was meint man damit genau? Wenn man die Quellen und Sehngen bestimmtes Verhaltens anhasiert und statistisch Analyse verwendet, dann kann man vielleicht wenn man die Nachvollziehbarkeit aufhält, kann man gucken, wie man von Tainting-Quellen das Verhalten von Quellen auf das Verhalt kriegen und diese Verhaltens-Quellen sind Teilverletzbarer Verhalten als wenn man von Sprechheit wie diesen Schreibtag und zusätzlich die Paralyse steuern kann und zusätzlich der Anlockmechanismus den Problem ist zu unlocken wenn man zum Beispiel irgendwie Umgehungen entdecken kann, dann ist das sehr wertvolle Ja, okay. Also das ist unsere die spezifische Architektur, das ist ein Bechzeug da gibt es also zwei Hauptmodule das große Tool, wo für keiner genug Geld ausgeht und das andere, das ist ein Angriff geschrieben das ist die Analyse das ist wahrscheinlich der Punkt wo ich hier eine Live-Demo starten möchte das sollte groß genug sein das sollte groß genug sein okay wir arbeiten daran ein Image hoch zu laden schnell mal kurz hier versteht man was das Ausführbare ist also ich starte jetzt mal das das wird kurz hart nachdenken das ist kein Punkt, warum man das nicht in Anger oder Binary Ninja oder R2 hätte machen können aber das ist die Leute schreiben die Sachen in welchen Sprachen haben wir sie sich wohlfühlen okay, realistischerweise das ist nur ein binärer Block das ist nicht so fortwo so muss man wieder zu den bringen, dass alle Funktionen gefunden haben okay okay, was jetzt passiert der H ist wir haben diese Taintext die zeigt uns all die beflegten Informationen und hier sind ein paar die die Quellen sinken du musst das nicht alles haben aber wo die memory-speicher Funktionen hinkommen und so und jetzt wenn wir das ausführen unser Taintenalysis da gibt's noch ein Konfigurations-File das ist jetzt einfach wir organisieren das einfaches Zeug das wird das ungefähr 20 Minuten machen ich hoffe das ist fertig bevor die Demo vorbei ist und wenn nicht, dann werde ich Magie machen und das einfach so euch zeigen wir haben über diese Samen geredet die Daten die vom analog-Prozess genutzt werden am Anfang habe ich darüber zu kehlen dass wir über logmesse der EMMC ist ein spezielles Speichermodul, das eben für ein bootloader für sichere Sachen benutzt werden man kann als eben diese loggemeldung identifizieren also diese diese Funktion muss also die Lesefunktion sein das ist relativ simpel und es funktioniert überraschend oft natürlich wenn das nicht genug ist dann können wir uns natürlich manuell anschauen hier ist wo wir aus der Speicher lesen das ist das was wir eben verderben müssen also Taint die Taintanalyse ist spezifisch symbolisch das ist also nicht nur etwas was Triton tut, man hat also keine konkrete Metadaten sondern wirkliches Symbol für symbolische Ausführung wenn man euch damit nicht auskennt das ist eine Art von statischer Analyse in der man den Code emolliert aber anstelle von Werten zu haben man hat einfach Symbole wenn man eine Operation auf diesen Symbol ausführt dann hat man einen abstrakten Syntaxbaum das Verhaltnis und man kommt dann auf Branch Bedingung und dann sagt man um von A nach B zu kommen muss man diese Beschränkung eben erfüllt sein und natürlich kann man einfach Z3 hinzufügen und umrühren um zu diese Senken von diesen Markeln von diesen Taint zu besprechen das ist das Parameter für Memcopy das ist wie das nicht sagen dass die Taintdaten eine der Werten die an Memcopy übergeben und das ist eben eine Schweicherkorruption im Allgemeinen darüber um jetzt diese Taint-Überprüfung zu machen das ist genau das was ich gerade eben gesagt habe während ich über dieses Symbol und Spurenanalyse gesprochen habe wenn man etwas sieht dann hat man automatisch eben den Input der dieses Verhalten erzeugen wird also Verhalten ist nachvollziehbar leider gibt es da ein paar Probleme ich war beim CCC vor zwei Jahren und habe über das genaue Problem gesprochen es gibt natürlich dieses Problem wenn man an Orde ja wir generieren Pads zwischen Differen Zuständen und es können einfach zu viele sein und das überwältigte eben deine Analyse also man kann ein paar Heuristiken benutzen okay also wir wollen zum Beispiel weil es eben statisch ist haben wir müssen wir eben nicht die Funktion analysieren aber einfach den Instruction pointer nehmen und wann das hin verschieben das machen ein paar Probleme aber das ist kein Problem wenn man davon ausgeht man akzeptiert es einfach das Limit Loop klassische Analyse und Timer natürlich was sind also die Bugs die wir gefunden haben wir haben das auf vier Buttern untersucht wir haben mehrere Bugs gefunden und sechste von malen Zero Tays und das ist ziemlich gut aber okay wir haben ein paar Bugs gefunden aber es können natürlich Einfach so ein paar Initialisierungsfehler sein die nichts ausmachen aber man kann es natürlich crashen lassen also wir haben jetzt gesehen dass ein Teil des Bootloaders arbeitet haben EL3 also alles mögliche machen wenn man eben genug Kontrolle über das hat das wäre also ein Roadkit Bereich es gibt dann aber noch einen anderen Teil in dieser Analyse das können wir umgehungen finden für diese Entspärprozedur das ist eine die wir gefunden haben und die sagt es gibt diesen Fluss von Daten die gelesen wurde vom Gerät zu Daten die geschrieben wurden auf das Gerät was dieser Code tun soll es nimmt ein Input und verifiziert dass es auf einem gewissen Wert hasht und wenn dann, dann hash es nochmal und schreibe es zurück auf das Gerät jedoch das was wir schreiben ist zu verglichen mit der damit verglichen was gelesen wurde von dem Speicher das was Bootsdom portiert hat ist der Codefluss von Disk zurück also wenn du von der Platte lesen kannst dann kannst du da auch hinschreiben das solltest du eigentlich kennen aber das ist unsicher die Sache Google macht und diese Sachen zu erinnern wenn der Entschlüsselungsschlüssel wenn er also er hat den Entspärten Zustand in sich also wenn man da reinkommt dann hat man das gesamte Telefon kaputt gemacht und alle dann das ist immer noch nicht wirklich gut genug aber realistischerweise sollten wir mehr Vertrauen, also Speicher mit Höhe um Vertrauen haben und nicht also das sollte wahrscheinlich Teil des EMMC sein also den Videoholungsankruf also den geschützten Speicher so dass man nicht in den also das Speichern, das schreiben wir in diesen Speicher ein authentifizierter Prozess ist so dass nur der Publoder das entrissen kann aber das würde natürlich nicht gegen Speichern Korruptionsangriffe schützen also auf jeden Fall ist es ein echt ernstzunehmendes Problem die die Zusammenversorgung ist alle diese wir wurden geportet und gefixt und wir haben automatische Technik um Google zu analysieren und wir haben da echt 6 Schwachstellen gefunden und unsere Implementierung ist Open Source ich werde Fragen entgegennehmen und bedanke mich fürs Zuhören also wir nehmen jetzt ein paar Fragen an von Leuten die das verstanden haben wo sie ihre Gerät hätten vielen Dank für den Vortrag es ist möglich den Code so zu schreiben dass man die Werkzeuge ist eben auch analysiert und es ist möglich den Code so zu schreiben die Werkzeuge ist eben auch analysieren können und es sicher wird oder jetzt noch nicht also es gibt natürlich Sachen die man sagen kann für dass die Leute Open Source machen normalerweise macht man Analyse auf Quart es ist normalerweise sehr viel besser definiert als Anal man kann die Sachen in Sprachen schreiben die sicherer sind als C ich weiß nicht ob es sicherer ist über Rust zu sprechen aber Rust ist cool es gibt auf jeden Fall viele Sachen die man machen kann ach so ich verstehe gerade dass ich die Live-Demo nicht gezeigt habe die automatische Analyse es ist immer noch am Laufen es hat nicht rechtzeitig fertig geworden also ich mache jetzt Magie mit den Ergebnisse das ist das ja vielen Dank hier ist eine der Analyse wir haben rausgefunden an diesem Ort ein beflegte Variabler mit dem Offset 261 das wurde als Pointer verwendet und das war ein langer da ist eine Schwachstelle die für euch entdeckt haben wir können weiter mit der Diskussion machen es gibt keine Fragen aus dem Internet gibt es noch eine Frage noch eine Frage du sagtest dass die Bugs die gefunden wurden mitgeteilt oder oder wurde einfach gesagt wir fixen das in zukünftigen Geräten ich wünschte ich wüsste die Antwort für diese Frage ich war nicht dabei ich kann da leider nichts zu sagen es war nur eine Folie auf dem Vortrag die ich gegeben habe ich hoffe sie würden verantwortungsvoll disclosed aber es ist natürlich auch schwierig keine weiteren Fragen ok, so die Leute, wenn du leave die ganze please take all your stuff with you your bottles your cups und damit verabschieden sie sich aus der Kabine aus der Besetzerkabine Pete Brogherty im Mr. Bronze sie hörten bootstomp bitte wende dich mit Feedback an ad c3 lingo oder hashtag c3