 Der nächste Vortrag ist der Anfänger-Vortrag für Zero-Day-Entwicklung. Unsere nächsten Vortragen sind wirklich spitze. Ein Kapter der Flagg-Contents, so wie das, das hat viel von Ihrem Home-Workup-Front gemacht, sodass Sie die Tools an Ihren Disziplinen, und Marcus und Amy hier zu erzählen haben, etwas, was nicht mehr wertvoll ist, über die eigentlichen Tools, die Sie gefunden haben, aber auch, wie sie an diese Tools kommen. Und ich denke, das wird ein sehr wertvolles Rezept, ein Lesson für uns. So, please help me welcome Marcus und Amy für diesen lang erwarteten Vortrag. Hi everyone, thank you for making out to our talk this evening. Ich möchte anfangen, um damit, dass ich den C3-Organisatoren danke. Wir sind sehr froh, dass wir hier sein können, heute. Ich hoffe, ihr habt Spaß in diesem Vortrag. So, who are we? Also, wer sind wir? My name is Marcus Gazzadon. I sometimes go by the handle Gazzadon, which is my co-worker Amy. Und ich bin hier mit meinem Mitarbeiter Amy. We work for a company called REC2 Systems. Wir arbeiten für REC2 Systems, und wir machen quasi Sicherheitsforschung und Konseilton. Availability of security education and specialized security training. We also raise awareness and sharing information like you're going to do today. So, this talk has been structured roughly to show our approach in making the world's most important in particular, we're going to talk about one of the zero days that we produce at REC2. Und ich hoffe, to break some common misconception so as an option for today's engineering. We're going to highlight some of the observations and we've gathered a little bit about this in its own way. And we're going to try to offer some advice on how to get started doing this kind of work. So, we're calling this talk a non-technical commentary about the process of zero-day engineering. At times it may seem like we're stating the odds. It might as well be showing that there's much magic behind most of these spectators. Der Punkt ist, dass da weniger Magie steckt, als sie meist von euch erwarten. For those that don't know, Punto Own is an industry-level security competition. Punto Own 2018 war eine Industrie-Level-Konterst für Stole-Engine. Und das Ziel ist halt, zero-days zeigen gegen Benutzersoftware, die tatsächlich auch doll bekannt sind, zum Beispiel Safari Edge Cron. Und dieses Jahr wollten wir auch teilnehmen und wir wollten halt die Browser targetten. Und unter anderem halt Edge. Und so für diese Konpetition wir ended up developing a type of zero-day known, typically, as a single-click RCE or Safari Remote, kind of as some industry language. Für diesen Konpetition haben wir halt einen Single-Click RCE für Cronen-Level-Konters. Das heißt halt, dass man mit einem einzelnen Klick Atmenrechter auf eurem Rechner kriegen kann. Und ja, ich weiß, dass die meisten von euch denken, dass ihr keine komischen Links am klicken. Und dass ihr Speer-Feschen ist. Und das heißt halt, dass ihr keine komischen Links am klicken. Und dass ihr Speer-Feschen jetzt nicht so verwundbar seid, aber jetzt stellt immer vor, wir seiten in so einem Coffee Shop. Ja, auf dem Bild seht ihr, wie der, wie die Maschine aussieht, nachdem unser Exploit funktioniert. Und nachdem er halt ausgeführt wird, sieht man halt, dass der Taschenrechner aufgemacht wird. Und nur so Spaß haben wir halt auch dafür zugesehen, dass der Interesse auf Hintergrund geändert wird. Wir hatten tatsächlich gar keinen MacBook in unserem Büro. Und also, jetzt könnt ihr mal sehen, wie wir als Experten das angehen, unbekannte Softwareziele anzugreifen. Das ist ein Teil von einer sechshalligen Serie, denn wir veröffentlichen tatsächlich alle unsere Beobachtungen auf unserem Blog. Da gibt es dann auch die technischen Details. Da könnt euch die auf die ganzen technischen Details in eurer eigenen Zeit anschauen. Und jetzt geht's los, das ist der erste Steck, der erste Schritt in Richtung Zero Day Exploit. Wir haben gesagt, dass wir die am besten schützte, sicherste Consumer Software uns anschauen. Und das ist kein Scherz. Okay, also jetzt, da müssen wir erstmal überlegen, was wir erreichen wollen. Das ist vielleicht ein Sicherheitsexperte oder einfach nur ein Enthusiast. Und ihr habt Interesse daran, etwas wie ein Browser zu knacken. Die Unternehmen, die hinter diesen Software stecken, das sind einige der Unternehmen, die heute Tag gibt und die investieren viel in die Sicherheit ihrer Software. Da wird mehr Geld reingesteckt, als jemals zuvor. Das hier ist ein wunderschöner Berggipfel, der repräsentiert, wo wir hin wollen. Hier will jeder jeden kriegen, das ist ihr könnt euch vorstellen, dass eure Gegner haben unendlich viel Geld, unendlich viel Zeit und auf eurer Seite Leute, die in neuerer Zukunft bereits sich meistens nicht wirklich vor und wissen nicht, was für Zeiträume sie erwarten sollen. Für diesen Capture the Flag haben normalerweise so 36 bis 48 Stunden oft über ein Wochenende. Wie lange dauert das, dass wir so ein Zero-Date entwickeln? Hängt ab. Manchmal hat man Glück und man findet echt so ein Ding in 2 Tagen und manchmal dauert das 2 Wochen und manchmal 2 Monate. Manchmal kann es halt echt länger dauern, um sich so ein Experts zu entwickeln und ein neues Ziel sich auch mal anzugucken. Das kann halt um mal 3,5, 6 oder mehr Monate dauern. Im Vorhinein kann man eigentlich echt nicht sagen, wie lange es wirklich dauern soll. Im Rahmen dieser Challenges gibt es keine obere Grenze. Du weißt nicht immer, wonach du eigentlich suchst und du arbeitest mit Projekten, die halt mehrere Größe sind als das, was man an dem man so trainiert. Also, ich kann schon die trennen und so in euren Augen sehen. Aber ihr sollt euch da echt keinen Stress machen. Als Anfänger muss man halt einfach das im Kopf halten und akzeptieren, dass man vermutlich beim 1. Mal nicht unbedingt erfolgreich ist. Okay, nachdem ich jetzt so die psychologischen Grundlagen gelegt haben, gehen wir mal in Schritt 1 rein und zwar das ist die Informationsbeschaffung. Okay, hier ist Metasploit und erinnert euch daran, dass ihr mit Recon anfangen solltet. Und es kann halt echt überfordern sein, gegen so ein echtes Ziel anzulaufen. Womit fange ich an? Wohin gehe ich? Also muss man so rundwissen über das Ziel schaffen. Und ganz ehrlich, das ist so der am wenigsten glamourösste Teil der Entwicklung und viele überspringen das. Vor allem in dem Blog-Post steht dann halt nicht, dass man jetzt irgendwie 8 Stunden über Safari gegoogelt hat, bevor ich dieses Zero-Day geschreme. Also, erster Hinweis, alles zusammen sammeln, was ihr über euer Ziel findet. Und das zum Beispiel, wir googeln. Und was wir machen ist, wir googeln und wir gehen einfach durch alles durch und wir bookmarken und wir speichern alles, was wir finden für etwa fünf Seiten. Und vielleicht auch mal einen Blick auf die dazu bezogenen Suchen werfen. Und alles speichern, was irgendwie relevant aussieht. Und das macht ihr weiter und weiter und weiter und weiter. Alles, wo ihr denkt, das könnte irgendwie mal relevant hin. Ihr wollt alles wissen, was es über dieses Ziel zu wissen gibt. Selbst wenn es nicht Apple oder Safari spezifisch ist, alle suchen was ihr finden könnt. Also, was ihr jetzt machen wollt, ist halt eine Bibliothek an Literatur zusammensuchen, die sich so um die Sicherheit eures Ziels tritt. Und ihr sollt euch nicht zwingen jetzt beim ersten Mal alles verstehen. Am Ende von dieser Nachforschungsphase sollte ihr in der Lage sein vor den Freien zu beantworten. Wie ist es eigentlich aufgebaut? Also, kann mir einer von euch erklären, was die Webkit tatsächlich aufgebaut ist? Wie debagt man das? Wie machen die Entwickler das selber in ihrer Entwicklungsumgebung? War das historisch schon irgendwie verwundbar oder war es eher sicher? Wie sieht so der Security-Track-Record aus? Okay, jetzt sind wir hier durch und machen mit Schritt 2 weiter der Zielauswahl. Es gibt da tatsächlich verschiedene Namen, wie man diese Stufe jetzt nennen können. Wir schauen uns jetzt Apple-Safari an, aber worum es generell geht, ist, dass man quasi sich etwas einschreibt, was man machen will. Hier sehen wir eine Visualisierung vom Webkit-Quellcode. Also, ihr müsst wissen, dass Apple-Safari-Webbrowser tatsächlich auf dem Webkit-Framework aufbaut. Das ist ein Open-Source-Framework und das ist eine Dream-App-Visualisierung von dem Quellcode-Verzeichnis, wo jede von den Boxen eine Datei repräsentiert und die größeren Boxen dann eben Verzeichnisse, die grauen Boxen und die blauen Boxen sind dann eben Dateien. Und die Größe sind dann jeweils die Anzahl von Zahlen von Code, der Farbschimmer zeigt die zyklomatische Komplexität, also wie kompliziert der Quellcode ist und wie findet man da jetzt quasi in so einer riesen Codebase die Stellen, wo die Sicherheitslücken sind. Ich habe vielleicht 100.000 Zahlen C++ oder Cmang, also ich habe definitiv nicht so viel geschrieben. Das heißt, wie macht man das jetzt zugänglich? Man muss im Prinzip sich auf Tiefe fokussieren anstatt auf die Breite. Und das ist besonders wichtig wenn man sehr große Ziele oder in welche große Ziele angreift und insbesondere wenn diese großen Ziele schon sehr ausgeprägt sind und schon eine große Historie haben. Das heißt, man muss ja wirklich sehr detailliert sein. Also sagt den Fokus Einschränken. Das ist auf der JavaScript-Engine von WebKit. Das sieht man jetzt hier in Orange und Bugs, die in diesen Bereichen auftreten, werden tatsächlich immer als sehr mächtige Bugs Aden gesehen. Sie werden allerdings auch immer seltener. Und, ja, das heißt, dadurch, dass sie immer seltener werden, wir schauen uns jetzt einfach an was man da machen kann. Diese 350.000 Zeilen Code aus. Wir sehen jetzt hier das JavaScript-Code Verzeichnis und ja, das ist genau der Code, wie er aussieht. Und jetzt schauen wir uns jetzt noch mal im Spezifischen, die das zentrale Interface von diesem Teil vom Code an, nämlich den Runtime Ordner. Und das ist im Prinzip genau der Code, der 1 zu 1-Abbildung von den JavaScript-Funktionen, wie zum Beispiel Reverse oder CAT oder so, auf die tatsächliche Implimierung davon abbildet. Also, das kennt ihr, wenn ihr JavaScript-Entwickler seid. Und, ja, da schauen wir eben auf ungefähr 70.000 Zeilen Code. Wenn wir jetzt, als wir uns für Ponte Onen vorbereitet haben, dann haben wir uns vorgenommen in genau diesem Verzeichnis einen Bug gefunden haben und wir werden das dort einen Fehler gefunden haben. Also, suchen wir noch mal raus, das hier ist, wo wir gestartet sind und das Grüne ist das, wo wir jetzt was wir uns jetzt das Kratale anschauen. Das heißt, es illustriert den Prozess, wie man hier jetzt ja, eben so was findet. Früher gab es viele Bugs in der Runtime und in der letzten Zeit wurde das aber ziemlich ausgeräumt. Okay, also, das hier schauen wir uns jetzt an. Nachdem wir, ja, nachdem ich ja schon einige Jahre zwischen dem defensiven, offensiven Teil verbracht habe, habe ich gelernt, dass es ziemlich lange dauern kann, bis in diesem Bereich ein akzentables Security Level erreicht wird. Das heißt, es geht darum, bereits während der Aufklärungsphase, also der Reconnaissance Phase, hier die entscheidenden oder die interessanten Teile zu finden. Und hierzu haben wir uns entschieden, Windows Server anzuschauen. Das ist ein Service, der als der Super-User auf Mac OS läuft und, ja, das ist ein Prinzip, ja, das ist für die Safari Sandbox zugreifbar und insbesondere, als wir diese Nachführung angestellt haben, konnten wir auf der Webseite Zero Day Initiative, kurz CDI, und da konnten wir sehen, dass es mehr als 10 verschiedene Sicherheitslücken gab, die an CDI berichtet wurden, die für Privilege Escalations genutzt werden konnten. 2017 gab es dann allerdings nur noch 4, aber auch für diesen, ja, für diese Art von Exploit und 2018 gab es nur noch eine. Das heißt, über den Zeitraum von 3 Jahren hatten Leute sich immer wieder diese Windows Server angeschaut und Leute aus der ganzen Welt haben Fehler gefunden. Also, es ist schon ziemlich interessant, es gibt definitiv eine Perspektive auf die Sache und was man daraus auch lernen kann, dass schlecht sind, werden nicht so schnell besser, weil viele Hersteller Angst davor haben, durch ein Rewrite irgendwelche Rekassionen einzuführen. Das heißt, sie werden dann diese Komponenten nicht mehr wirklich anfassen, sondern noch patchen, wenn Sicherheitslücken reported werden an sie und da ansonsten wenig Wartung machen. Also, merkt euch das und ich will mal ein guter Punkt, um nach Bugs zu suchen. Also, vielleicht bei Wasm oder bei Jit gucken. Also, Schritt 3. Ach, diesen ganzen Schritten sind wir jetzt an einem Punkt angekommen, wo wir tatsächlich anfangen können, mal zu uns das mal ein bisschen genauer anzugucken. Also, dieser Schritt ist jetzt der, wo wir tatsächlich Bugs suchen. Und das ist oft der, das ist oft der schwerste Teil von dieser Zero Day Entwicklung, also tatsächlich irgendwie ein Bug zu finden, den man tatsächlich auch ausmützen kann. Und wir haben einfach keine 100 Millionen Dollar, die wir mit denen wir Faser kaufen können oder so. Also, das ist so ein bisschen wie die Nadel im Heuhaufen zu suchen. Also, es gibt zwei Strategien und wir haben sowohl die Vorteile als auch ihre Nachteile und ich will jetzt nicht großartig auf eingehen, aber das kurze Samenfassung ist, dass Fasing so die Hauptherangehensweise ist und ein der Vorteile ist, dass es einfach gut skaliert. Spoiler wir sehen später noch, dass wir beide unsere Bugs gefasst haben, die wir tatsächlich für den Escaping benutzt haben. Und das war aus 2008 sein. Also, das ist dieses Jahr noch möglich. Und Source Review ist halt die andere Strategie und die ist oft schwerer, aber man findet damit schon irgendwie hochkarätige Bugs. Also, in diesem Vortrag reden wir jetzt größtenteils über Fasing und das ist unser scalable Fasing Harnes, das wir gebaut haben und das ist ein Grammatik-basierter Faser und hier seht ihr mal irgendwie wie so ein bisschen Output aussieht. Und wir haben damit nicht großartig rumgespielt. Aber ja, hier könnt ihr sehen, wie einfach das war, irgendwie rauszufinden, wo der Bug liegt. Und etwas, was wir gerne betonen, ist, dass Fasing wirklich als eine Wissenschaft benutzt werden muss. Und ja, Code Coverage ist es nicht wirklich die beste Metrik, aber irgendwas müsst ihr benutzen um euer Ziel zu beurteilen. Und alle 15 Minuten haben wir so ein Web-Based Überblick gekriegt über die Coverage von unserem Tool. Also, so ein gutes Ziel ist so etwa 50% Coverage und ja, das hängt jetzt ab und das ist jetzt von Ziel zu Ziel unterschiedlich. Und ihr könnt jetzt auch sehen, wir haben uns da jetzt nur auf dem Run Time im Ordner beschränkt. Und was wir beobachtet haben ist, dass viele von den Bugs kommen halt aus diesen letzten paar schweren Prozent des Fasings. Und was es bedeutet ist, dass ihr jetzt eine Weile daran arbeiten könnt, um die Grammatik anzupassen. Okay, und dann erreicht ihr diese 50% und dann fragt ihr euch so, und jetzt? Aber erst, wenn ihr dann noch so ein bisschen weiter pusht und ein bisschen weiter fasst, dann findet ihr tatsächlich irgendwie relevante Bugs. Und dann guckt ihr euch diesen Control for Grafen an und fragt euch mal, ob ihr diese grauen Blöcke nicht. Und dann guckt ihr euch das genauer an und dann fasst mal die Test Cases an und oder macht das einfach auf ein Projektor und redet mal über diesen Code. Also das ist hier ein Live-Aufnahme, die ich gemacht habe und ja, so Klischee, das auch aussieht, dass es, ja, tatsächlich das echt so passiert. Also, es ist einfach, okay, mal irgendwie Roba Duck Debugging mit euren Mitarbeitern zu machen. Einfach, um mal irgendwie Theorien zu bestätigen oder weg zu essen. Und ja, damit unser nächster Hinweis also, das bezieht sich jetzt sowohl auf Debugging als auch auf Corner Cases angucken. Aber wenn ihr jemals unsicher seid darüber, was ihr da eigentlich lest, Debugger benutzen, dynamische Analysen benutzen, ja, auch wenn das irgendwie schmerzhaft ist einzurichten, ihr müsst das halt einfach lernen, die zu benutzen. Also zum Beispiel einer unserer Blockpost benutzt jetzt hier viel diese, benutzt viel GDP um eine Race Condition im Garbage Collector zu debuggen. Ich würde sagen, da gibt es vielleicht 3 Leute auf der Erde, die das allein durch den Source Review finden können. Und wir haben das halt bei Fuzzing gefunden. Und wir haben das ja durch ein Debugger, durch AA gemacht mit einem Time Traveling Debugger. Und selbst wenn ihr einfach nur den Callstack damppt, dann kann man da schon richtig viel Kontext geben darüber, von wo das aufgerufen wird, welche Daten verarbeitet werden an der Stelle. Aber ihr soll das jetzt nicht tatsächlich lesen können auf dieser Folie, aber das ist halt ein Backtrace. Also es gibt dieses riesen Missverständnis von von neuen Zero Day Entwickler und das neue Code von wachsamem und sicherheitsfokussierten Entwicklern geschrieben wird. Und ja. Und es gibt diesen super Blockpost von Alpen und der hat vor etwa einem Jahr WebKit gefasst und er hat diesen Fuzzer dann Open Source gemacht. Und vor einem halben Jahr hat er dann diesen Fuzzer einfach genau so quasi unverändert laufen lassen und hat direkt noch mal 8 Use After Free Bugs gefunden. Und wenn ihr euch anguckt und wenn ihr euch anguckt, wie diese Bugs aussehen, dann sind der Großteil davon ist tatsächlich in den letzten sechs Monaten entstanden und deswegen ist halt neuer Code normalerweise nicht gut. Der ist noch nicht gealtert, der ist noch nicht genug getestet worden. Sobald irgendwie Entwickler das push und das release wird dann hast du auf einmal eine Million Benutzer die tatsächlich diesen Code ausführen. Und diese Benutzer fassen quasi für einfach durch ihr normales Browser verhalten. Es ist auch nicht irgendwie selten dass das Annahmen einfach die über den Rest der Codebase gemacht werden kaputt gehen. Es kann echt schwer sein zu beurteilen ob irgendwie der Code den Josh, der neue Entwickler hinzugefügt hat irgendwie ein Paradigma, was vorher für den Code gegelten hat, kaputt gemacht hat. Vielleicht ist es auch echt ein Experte, der einfach mal irgendwie ein Fehler gemacht hat. Und also hier nochmal irgendwie ein Hinweis. Und Novice werden oft irgendwie ungeduldig und fangen an rumzuspringen und so. Und ohne wirklich zu verstehen, wovon nach sie suchen. Also immer anfangen danach zu gucken, wo Benutzer Input eingeben und mal nachgucken durch welche Funktion das fließt welche Funktion passt das einfach darauf zu einfach das Ganze einfach halten. Und wenn wir jetzt nach unserer Sandboxescape gucken, dann wussten wir wir hier gesehen diese Funktion hier diese Funktion, den kann man Daten schicken im Windows Server und das sind diese ganzen Funktionen die mit andesco andesco x einfahren. Und diese Funktion operieren halt auf Daten, die wir ihnen geben. Also was wir haben ist diese Datenpipeline quasi von Safari in dem Windows Server. Okay, lasst mal einfach versuchen diese Datenpipeline also man in der Mitte. Also einfach mal Frieda dran gehangen das ist auch so ein Open Source Tool. Wir konnten uns die ganzen Nachrichten die durch diese Pipeline geflossen sind angucken. Alles auf Mac OS redet mit diesem Windows Server. Und das ist so ein bisschen wie Explorer unter Windows. Okay, und wir sehen jetzt diese ganzen Daten diese ganzen Nachrichten und diese eindeutigen und klar, das sieht aus wie irgendwas was man prima fassen könnte. Okay, und dann dachten wir uns vielleicht kriegen wir da irgendwie AFL reingehuckt oder vielleicht Radamsa oder ich meine, man kann damit anfangen irgendwie ein paar Bits zu flippen. Und ja, das hatten wir geschafft. Und Towerflake hatte diesen Tweet. Der meinte, ja im Rückblick auf meinen Karriere waren meinen großen Fehler eigentlich immer zu versuchen zu clever zu sein und Erfolg versteckt sich meistens dahinter hinter der Frage was ist das dümmste was ich hier möglicherweise machen kann. Und hier ist halt so ein 13-inch MacBook Pro und ich hab dann einfach mal mein Portemonnaie auf die Enter-Taste gedrückt und im Hintergrund läuft unser Fuzzer und flippen Bits im Hintergrund und ihr könnt sehen, irgendwie die Farben verändern sich und normalerweise soll diese kleine Box irgendwie den Passwort hinweisen zeigen, aber dadurch, dass wir die ganze Zeit Enter drücken und da wir die ganze Zeit Enter gedrückt haben werden halt viel zu viel Nachrichten geschickt und jedes mal wenn der Windows Server crasht, dann wird man halt zurück auf den Loginscreen geschickt. Und wir haben das Advanced Persistent Thread in unserem Blog genannt. Das hatten wir jetzt in den ersten 24 Stunden quasi gefunden und wir haben jede Menge Crashes gefunden und wir haben uns hier nicht alle angeguckt. Also das sind vermutlich ein paar immer noch auf unserem Server und da ist viel Müll dabei. Aber jedes Mal wenn ihr irgendwas seht das ist ein schlechter Bug wenn der auftritt und den haben wir dann auch benutzt um unseren Ausbrut zu machen und ja, könnt ihr auch unseren Blog Post nachlesen. Und Leute versuchen halt richtig coole Sachen zu tun lassen sich davon verführen quasi alles Mögliche an Wissenschaft oder so da rein zu stecken und verpassen aber oft einfach dass man mit einem Fasser oder so was halt relativ schnell in den Bug findet und dieser Typ da gefällt das nicht. Also wie der Missverständnis nicht nur Experten mit X-Ups und Z-Tool kann tatsächlich irgendwie so ein Bug finden. Das stimmt einfach nicht. Es gibt wenig Geheimnisse. Also die nächste Beobachtung irgendwie Bugs die einfach zu finden sind werden auch einfach von anderen gefunden und kurz nach unserem Blog Post wussten wir dass wir mit mindestens einem anderen Team kollidiert sind und wir hatten ein paar echt kreative Experts dabei aber ja, wir hatten hinterher so ein bisschen Diskussion auf Twitter und dieser Typ da der redet auch morgen über Chrome Interprocess Kommunikation. Und Linglas hier meinte ja okay, wenigstens drei Teams hatten diesen Bug unabhängig voneinander gefunden und das waren drei Teams die alle bei Porn to Own waren. Und ja, jetzt überlegte euch irgendwie wie viele haben tatsächlich versucht da irgendwie eine Waffe zu verwandeln vermutlich nicht so viele aber ja, mindestens drei andere Teams haben das gefunden und ja, wie gesagt das bringt uns zu unserem Ende also wenn ihr irgendwas mit Fussing schnell gefunden habt dann hat das vermutlich jemand anderes auch schon gefunden. Okay, jetzt geht es weiter mit Amy. Okay, also jetzt haben wir viel geredet über Techniken und Erwartungen wenn ihr nach dem Bug schaut. Okay und jetzt werde ich darüber reden was ihr zu erwarten habt wenn ihr versucht den auszunutzen, den Bug den ihr gefunden habt also jetzt geht es um Exploit-Entwicklung. Also ihr habt einen Bug gefunden, ihr habt also den schweren Teil schon getan was auch immer euer Ziel ist Browser, Windows Server was auch immer und die Frage ist jetzt wie ihr davon da zu einen Taschenrechner auf dem Bildschirm habt also die Exploits sind hochkomplex Entschuldigung, die Bugs sind sehr komplex und dann stellt sich immer die Frage wie baut man da was in Exploit okay, also wir nehmen Schreibt zurück und sagen also der eigentlich Frage ist, wie schreibt man einen Exploit viele Leute denken, dass diese Exploits so eine ganz eigene Geschichte sind und in CTFs sind sie häufig viel einfacher also wenn ihr so ein Exploit bauen sollt für eine CTF-Kompetition also ein Capture the Flag dann kann es sein wie eine wahnsinnige Hürde scheint also ihr müsst üben und das ist sehr wertvoll und Übung, das wird sich dann zeigen wir haben damit angefangen am Anfang ihr müsst versucht alles zu lesen was ihr das Ziel gibt ladet das runter und euer nächstes Ziel sollte dann sein das Ziel so gut zu verstehen, vielleicht sogar besser als die, die das gebaut haben das ist nicht einfach das ist natürlich sehr viel Arbeit aber jedes bekannte Exploit durch das du dich durcharbeiten könnt um das besser zu verstehen ich arbeite zum größten Teil an Brousern ich habe viele Exploits gebaut ich habe viele über Exploits gelesen und was ich gefunden habe ist dass viele von denen eine ganz ähnliche Struktur haben das sind ähnliche Techniken dabei ähnliche Bausteine die dafür verwendet werden also das ist das ist eine Beobachtung die ich durchdenken kann und jetzt habe ich ja ein Beispiel wir hatten da bei Pound 2 Own war dabei der auch Safari Asset hatte aber er wollte den Adjust-in-Time Compiler angreifen unser Bug war völlig anders als beim Garbage Collector also was ganz anderes und einige Monate später nach bei Pound 2 Own Global gab es ein Team das war fantastisch im Prinzip alles Exploited was sie in die Hände bekommen konnten unter anderem ein iPhone da haben sie auch den Safari angeriffen und der Bug den sie dort verwendet haben der war sehr ähnlich zu dem den wir da gesehen haben das waren also ganz ähnliche Bugs und fast der gleiche Exploit hat funktioniert auf den unterschiedlichen Geräten was sehr wichtig ist dass der Part von dem Bug zum Exploit sehr sehr ähnlich war einige Monate später gab es ein Capture the Flag das ist Real World CTF die ganz wie der Titel sagt hatten sie ganz viele aus der echten Welt Beispiele und die haben mich mitten in der Nacht aufgewacht und gesagt los das mal dann habe ich gesagt okay, das schaue ich mir mal an sie hatten ein JIT Bug also im Just In Time Compiler und ich hatte mir das noch nie vor angeschaut ich hatte da kaum Erfahrung vorher aber ich hatte mir die Zeit genommen und hatte alle bekannten Exploits vorher schon angeschaut und ich hatte so einen ähnlichen Bug schon mal gesehen und jetzt ging es darum ein Exploit dafür zu finden und dadurch das hat mir erlaubt eben schnell so ein Exploit aus dem Bug zu bauen und so haben wir diese Talent geknackt und das war sehr cool okay, was bedeutet das nicht jeden Bug kann man so einfach Exploit reinslotten aber das ist extrem wertvoll wenn man selbst Exploit bauen will ist es solche Sachen anzuschauen wie die Exploit JS1DB also wenn ihr euch die hier alle anschaut dann kann ich euch garantieren dass am Ende versteht ihr die viel besser es gibt aber leider nicht so sehr viele Bugs die produziert werden die komplette Exploits sind vielleicht ein paar, ein oder zwei im Jahr wenn ihr mehr das besser verstehen wollt dann müsst ihr mal schauen ob ihr selbst bekannte Bugs oder Exploits bauen könnt ich selbst mag Chrome da gibt es diese Listen mit links die euch anzeigen was genau das Problem war also wenn das euch anschaut hier ganz oben da gibt es eine Outer Bounds in V8 und wenn ihr da drauf klickt dann könnt ihr euch anschauen was der Bug war und eben versuchen ein Exploit dafür zu bauen also da könnt ihr anwenden was ihr gelernt habt das denkt euch vielleicht das ist viel Arbeit ich habe eine Menge zu tun ich bin auch an der Uni ich habe ein Vollzeitjob wie sehr hilft es solche CTS mitzumachen um tatsächlich solche Exploits zu bauen und ich glaube das hilft sehr viel weil ihr diese Angreifeperspektive da sehr gut lernt was eigentlich schwierig daran ist ist das halt in der echten Welt anzuwenden hier gab es ein super Tweet vor ein paar Tagen also Lipsy Talents sind die kann man leider nicht was man da lernt kann man nicht so gut anwenden im Rest der Welt es gab ein paar CTS vor kurzer Zeit die sehr realistische Aufgaben hatten im Moment läuft ein ein CTF mit ein paar sehr realistischen Aufgaben und es ist verrückt dass man das Leute tatsächlich schaffen um diese Challenges zu knacken also das ist was woran ihr arbeiten könnt diese neuen CTFs sind wirklich super für Leute die eben in diese realistischeren Challenges rein schnuppern wollen aber das ist auch richtig schwer wenn man eben Anfänger ist weil vielleicht als erstes Chrome zu knacken ist vielleicht ein bisschen viel okay also selbst wenn ihr ganz viel Erfahrung habt ihr müsst braucht Glück man kann selbst mit ganz viel Erfahrung kann man nicht einfach für einen Bucking Export schreiben in unserem speziellen Fall konnten wir das tun das war sehr schön aber dieser Buck den wir uns angeschaut haben der hat einfach nicht in die Box von einem vorherigen Export reingepasst ihr könnt ihr sehen das war der Buck für die Sandbox hier ging es um ein ganz zahl Export normalerweise würde das zum Beispiel 4 erwarten bei minus 3 würde eben diesen Buck hervorrufen aber also dieser Buck ist ganz einfach heißt es dass dieser Export einfach ist das ist eine Menge Code also ein Export für diesen Buck das sind 1300 Zeilen Code also das ist ziemlich verrückt also pass auf wenn ihr einen einfachen Buck hast kann es trotzdem sein dass der Exploit sehr schwierig zu bauen ist das kann eine lange Zeit dauern aber keine Angst ihr müsst einfach den das Exploit Rollercoaster fahren also dass wir am Ende von der Achterbahn mit dem Exploit fertig sind also am Anfang haben wir dann das Buck gefunden wir haben ein paar super gute Ideen wir haben schon ein paar Bugs gesehen das sind in den Exploits gesehen jetzt geht es gerade erstmal los und wir müssen jetzt einfach nur zu sehen dass es eine Bit nicht gesetzt wird und der stellt sich dann leider raus das Bit ist leider mal gesetzt und wir haben absolut keinen Plan warum das so ist danke Apple und ja können wir da jetzt irgendwie uns drum herum arbeiten können wir da jetzt irgendwie eine Möglichkeit finden dieses Bit nicht zu setzen und dann findet man da vielleicht irgendein Weg und dann findet man dann wieder raus dass das den Exploit kaputt macht das heißt das ist halt immer so ein hoch und runter ich denke man hat alles genau so wie man es haben will und da macht sich etwas anders kaputt das heißt geht im Prinzip darum inkrementellen Fortschritt zu machen und immer die Probleme die im Weg stehen wegzukriegen die neuen die da aus entstehen auch wieder zu lösen kleine Randbemerkung das was ihr jetzt gerade seht von letzter Nacht er wird gesagt kannst du mir da etwas zeigen hier gerade und das ist ein guter Symbol dafür wo wer zeigt so dass man vielleicht nicht immer eine Ahnung hat wo die eigentlich Probleme kommen das heißt dieses ganze Achterbahnmetapher trifft tatsächlich nicht nur auf die tatsächliche Entwicklung sondern auf den ganzen Prozess zu denn wenn man durchaus crashes finden kann man kann durchaus crashes finden die nachher nicht zu führen und so weiter hoffentlich kommt man dann halt irgendwann am Ende an und man hat dann irgendwann tatsächlich einen ausführbaren exploit und damit werden wir dann an der Stelle wo wir den exploit geschrieben haben vielleicht jetzt nicht unbedingt der Zufallessistabe funktioniert und dann sollten wir jetzt mal langsam anfangen uns über die payload Gedanken zu machen was ist die payload also die nutzt das dass man das reinpackt was man tatsächlich tun will also zum Beispiel ein Taschenrechner ausführen auf dem Desktop das Benutzer ist man kann dann irgendwelche beliebige Software ausführen auf dem Rechner man könnte auch das Programm fixen das man tatsächlich exploitet und das dann halt bei den ganzen Capture Deflect wirkt wir haben immer sehr drauf fokussiert dass wir einfach nur die dazugeben haben also in der Teil steht daneben dieser Flaggenmarke das ist alles wo drauf beim CTF ankommt aber in der echten Welt ist es halt deutlich wichtiger was man dann eigentlich macht so jetzt schauen wir zum Beispiel mal was man macht wenn man einfach nur irgendwie den exploit ausführt und dann aber nicht hinter sich aufräumt dann crashed einfach der Benutzer war und das heißt der hat mir jetzt nicht wirklich viel gewonnen so und das heißt nachdem wir den exploit ausgeführt haben und unsere payload ausgeführt haben müssen wir auch wieder alles aufräumen so dass das System wieder in einem funktionieren Zustand ist und das heißt wenn wir irgendwelche payload schreiben dann kommen wir in den exploits meistens irgendwann an eine Stelle die Code ausführt und ja dann sehen wir diese Stelle hier die dann das Programm zum springt und dann ja dann zeigt man quasi damit dass man jetzt Code ausführen könnte aber ja man muss dann immer noch selber ausführen wie man tatsächlich die payload ausführt und wie man den ganzen Shellcode da drum oben schreibt und so weiter und das heißt er muss uns jetzt irgendwie ausdenken wie man die payload nimmt die aufs Datei System schreibt an die eine Stelle wo uns die Sandbox erlaubt hinzuschreiben ist eine Library wieder zu laden auszuführen und damit dann unseren exploit auszuführen und ja so nachdem wir jetzt ja alles zusammengebaut haben seid ihr quasi fertig euer exploit funktioniert und das hier wäre jetzt der escape aus unserer also der Ausbruch unserer Sandbox und das heißt wir zeigen damit dann dass wir den Taschenrechner ausführen können aber wir müssen halt immer noch einen Schritt mehr machen nämlich den exploit zuverlässig machen weil wenn es nur einmal aus von 100 funktioniert dann ist es nicht wirklich zuverlässig genau also für PontoOwn haben wir uns so ein Harnis geschrieben dass uns den Harnis dass sie sich als Lücke mehr als einmal ausführt und dann konnten wir uns die rote Statistiken angucken wie oft er tatsächlich fehlt und dann kremer halt und wie informationen lock wie lange es gedauert hat und damit können wir relativ gut iterieren und versuchen unseren exploit zu verbessern und den zuverlässiger zu machen und der Großteil von unserer Unzuverlässigkeit kam halt von unserem Groom der versucht irgendwie den Speicher und nicht so allein was ihr auch versuchen wollt sind halt mehrere Geräte also der Javascript bei uns war jetzt eine Race Condition und das heißt zum Beispiel die Anzahl der verschiedenen CPUs ist wichtig wenn ihr euren exploit laufen lasst ihr solltet vielleicht verschiedene Betriebssysteme oder verschiedene Betriebssystemversionen ausprobieren weil selbst wenn er überall funktioniert es gibt vielleicht so kleine Unterschiede und um die euch kümmern muss wenn ihr es wirklich zuverlässig haben wollt und wir wollten uns sicher sein dass unser exploit immer noch funktioniert selbst wenn Apple kurz vor der Wettbewerbung noch irgendwelche Änderungen pusht und deswegen haben wir uns hier was geschrieben was sich halt einfach austauschen lässt und wenn ihr versucht irgendwie einen Browser zu exploiten dann solltet ihr es vielleicht auch mal irgendwie auf dem Smartphone versuchen weil wenn irgendwie so ein exploit im Browser funktioniert dann tut das meistens auch auf dem Browser auf dem mobilen System also im Allgemeinen was ich sagen will ist einfach bei den exploit auf alles werfen und damit findet ihr hoffentlich noch ein bisschen zuverlässigkeit in euren exploit und dann noch irgendwie unsere letzte Sektion also ich habe leider nicht so viel Zeit für diesen Teil wie ich das gehofft hatte aber im letzten Teil geht es um eure Verantwortung also ihr habt unseren Talk zugehört ihr wisst jetzt wie man diese Schlüssel baut ihr könnt Türen in Server in Browser einbauen ihr könnt viel Schaden machen zu Menschen Unternehmen starten ihr müsst sehr vorsichtig sein jeder ist im Raum wenn ihr unsere Tipps hier mitnehmt dann seid ich bitte dessen bewusst was was für Schaden ihr machen könnt also es gibt ja ein Beispiel das da will ich nur schnell drüber reden 2016 ich kann mich an diesen Talk spezifisch erinnern ein riesiger Distributed General Service Attack es hat all eure Lieblingsseiten waren weg Amazon, Twitter, Netflix, Etsy, GitHub das gesamte Internet in Amerika in den feinen Staaten wurde furchtbar langsam, es war verrückt Leute sind verrückt geworden alle haben zu Bruce Schneiers Blog gelingt und haben gesagt das war wahrscheinlich ein Staatsakteur das ist eine ganz neue Art von Distributed auf Service Attack der Blog-Post von Bruce Schneier hieß irgendjemand hat daraus gefunden wie man das Internet kaputt macht tatsächlich waren es nur ein paar Kinder die mit Minecraft serven diesen was gemacht haben ich hab viel Respekt für junge Leute und wie talentiert sie sind aber wir müssen wissen was für einen Schaden sie damit anrechnen können sie haben keine Zero Days verwendet heutzutage machen sie das vielleicht aber damals nicht es ist ein Riesenschaden entstanden es ist schwer zu erkennen wie macht voll so ein Zero Days bis man tatsächlich einen in der Hand hat ihr könnt aber auch euch selbst in Gefahr begeben wenn ihr so was macht so site bitte vorsichtig das ist alles das ist unsere Zusammenfassung hier die der Anfänger Guide und wenn ihr noch Fragen habt Dann nehmen die jetzt und wenn ich dann, kommt einfach zu uns nach dem Talk. Wow, great Talk, thank you. We have very, very little time for questions. If somebody is very quick, they can come up to one of the microphones. Okay, also falls ihr Fragen habt, bitte zu einer Mikrofone vorne kommen und wir rufen euch. Ja, we'll be available after the talk. Und ja, wir haben auch noch Zeit nach dem Talk. Also wenn ihr nach dem, wenn ihr hinterher noch ein bisschen reden wollt, dann. Und wir haben auch Sticker für euch, wenn ihr die sammeln wollt. We'll be over here, we'll try to head out to the back. Ja, wir gehen dann irgendwo nach da hinten raus und so. Okay, I don't see any questions. Okay, ich sehe hier gerade keine Frage. At this point, but as I said, the speakers will be available. Gut, dann machen wir jetzt auch Schluss. Redet noch mal mit euren, mit den Vortragenen später. Gut.