 Ja, willkommen bei meinem Talk. Mein Name ist Orange Albertini. Der Titel dieses Talks kommt von meinem Buch Visual Documentations. Da kommt dieser Titel Funky File Formats her. In diesem Talk geht es um Dateien. Was sind denn die üblichen Kategorien von Dateien? Es kommt darauf an, ob man ein Newbie ist, ein Newbie, ein Developer oder ein Hacker. Normalerweise sind Leute nur daran interessiert, wie sich ein File Format ausnutzen lässt und welche Schwachstellen es gibt. Normale, gültige File, Dateiformate sind langweilig. Ein wichtiger Punkt ist, dass die Farben ein bisschen komisch auf dem Projekt sind. Das soll eigentlich rot sein, aber gut. Das Problem ist, dass die Grenze zwischen gültigen und ungewöhnlichen Dateien nicht sehr gut definiert ist. Man kann damit ein bisschen rumspielen. Hier ist ein Beispiel, hier haben wir eine gültige Datei. Nur, dass ihr mal seht, welche gültigen Dateien wir heute haben. Es ist ein normales JPEG-Bild, das wir hier haben. Es kennt vielleicht ein oder andere, aber es ist gleichzeitig eine Java-Datei. Warum eigentlich auch nicht? Das ist noch nicht sehr komplex. Aber man kann noch ein bisschen weiterspielen damit. Wenn man also zum Beispiel AES-Verschlüsselung auf dieses Bild anwendet, auf dieses JPEG-Bild, dann kommt da ein PNG-Bild raus. Das heißt, verschlüsselt mit AES und wenn man das jetzt mit Triple-DES entschlüsselt, dann ist das Ergebnis eine PDF. Wenn man dieselbe Datei nochmal mit AES, aber mit einem anderen Schlüssel verschlüsselt, dann bekommt man ein Flash-Video. Ich könnte da jetzt noch ein bisschen weitermachen und da richtig verrückte Proof-of-Konzept machen, aber ich könnte jetzt quasi den gesamten Talk mit dieser einen Datei füllen, aber das ist dann wahrscheinlich kein richtiger Talk mehr. Aber ich denke, ihr seid mittlerweile überzeugt, dass ich ein ganz normaler Kerl bin, der nur gerne ein bisschen mit Binehrformaten raumspielt. Vielleicht habt ihr meine Poster gesehen. Ich erkläre da auch ganz gerne, was das mit diesen Binehrformaten auf sich hat. Irgendwann auf dem obersten Stock hängt da ein Poster. Ich spiele mit diesen Binehrformaten rum und präsentiere das auch gerne visuell auf diesen Poster. Und diese ganzen Poster konnte übrigens auch kostenlos runterladen oder der Adresse, die ihr hier seht, und da könnt ihr auch zum Beispiel dieses Bild auf einer Handyhülle bestellen oder ähnliches. Irgendwie funktioniert jetzt mein Klicker nicht mehr hier. Okay, gehen wir nicht zu sehr in die technischen Details, sondern ein bisschen zurück zu den Grundlagen. Reden wir ein bisschen über Kühe. Wie identifiziert man eine Kuh? Welche möglichen Wege gibt es, eine Kuh zu identifizieren? Natürlich können wir dann auch im Grunde das gleiche Identifizierungsmodell auf Dateien anwenden. Identifiziert man sie aufgrund ihres Kopfes oder aufgrund der Körperform, vielleicht aufgrund des Geräusches, die eine Kuh macht? Und wie ihr es sehen könnt, auf dieser Art kann man auch Dateien auf verschiedene Art und Weisen identifizieren. In der Praxis sieht das so aus. Hier ist ein sehr frühe Methode, Dateitypen zu identifizieren. Also man schaut sich einfach den Kopf an. Das ist also eine alte französische Technologie, die wir hier sehen. Ich habe diese Geloutine selbst gezeichnet. Im Grunde, üblicherweise kann man den Dateientype aufgrund einer Signatur erkennen. Das ist meistens irgendein feste Wert, der an Offset 0 steht der Dateien. Manchmal hat das eine Bedeutung, manchmal nicht, aber meistens gibt es irgendwo so eine Art Magic Word an Offset 0. Wir haben hier zum Beispiel das Dateifarmat ZIP, was auch in vielen anderen Formaten benutzt wird, zum Beispiel für Jardateien und ähnliches. Manche Komprimierungsprogramme forcieren das, dass da an Offset 0 diese Signatur steht. Bei PDFs ist das so, dass das Offset zwar auch an Offset 0 beginnen sollte, aber in der Praxis ist es so, dass es ausreicht, wenn es innerhalb der ersten Town 2024 Beizeldatei steht und das können wir ausnutzen. Das heißt, wir können PDF heißen, eignen sich das sehr gut dazu. Ein wichtiger Punkt bei ZIP-Dateien ist auch so, dass es ZIPs sind im Grunde rückwärts geschrieben, also quasi von hinten nach vorne. Es gibt dafür ein paar sehr antike Gründe, wenn man also eine ZIP-Datei auf mehrere Discetten verteilen muss, dann steht die wichtige Information des letzten Discette und dadurch konnte man die, wie oft man die Discette austauschen musste, minimieren. Das erste, was also von einer ZIP-Datei geprüft wird, ist also am Ende der Datei. Das wird allerdings auch nicht immer berücksichtigt. Ich habe einen eigenen Talk über ZIP-Dateien, den ihr euch auch anschauen könnt, aber ein paar Dateiformate sind auch irgendwo hardwareabhängig. Meistens dann, wenn es irgendwo ein Stückchen Bineadateien gibt, die von einem Stimmchip ausgeführt werden sollen, dann will man da nicht unbedingt ein Hetter haben. Zum Beispiel eine Tadatei, die fängt sofort mit den Daten an und vielleicht irgendwo weiter hinten existiert dann noch so was Ähnliches wie ein Hetter. Also diese Formate haben quasi eine Ausrede, sie sind quasi an die Hardware gebunden und deshalb haben sie so ein Magic Word nicht. Eine gute Signatur sollte also auch noch auf der Null stehen und sie sollte irgendwo eindeutig sein. Also wenn man ein neues Dateiformat sich ausdenkt, dann bitte behaltet euch daran, denn ansonsten gibt es da vielleicht ein bisschen Konfession mit anderen Dateiformaten. Wenn man jetzt so ein bisschen drüber nachdenkt, wie ein normales Werkzeug funktioniert, dass eine Dateife arbeitet, es checkt also diese Signatur und entscheidet sich dann für eine Ausführung, für ein Dateiformat und wird dann bei dieser Entscheidung bleiben und wird das nicht nochmal irgendwie neu erkennen. Eine weitere wichtige Eigenschaft, die man auch für solche Explorzen nehmen kann, man sieht eine Kuh, also da kommt vielleicht noch was hinterher, aber man sieht zunächst mal die Kuh und hinter der Kuh kommt, aber obwohl hinter der Kuh noch irgendwas anderes kommt, ist das immer noch eine gültige Kuh. Das heißt, egal was danach kommt, unabhängig davon was danach kommt, man kann es erst mal als Kuh behandeln und egal was danach kommt. Und wenn diese Kuh irgendwo ein Terminator hat, also ein Merkmal, wo man sagt, das ist das Ende meiner Datei, dann kann man sagen, wir parsen nur bis hierhin und alles, was nach dem Terminator steht, braucht uns nicht mehr zu interessieren. Und mit dieser Kombination, dass die Signatur nicht immer an Offset 0 stehen muss und verschiedene Dateiformate auch tolerieren, dass danach noch was kommt, dann kann man, so wie die Bremer Stadtmusikanten, mehrere Dateien ineinander kombinieren und kriegt dann eine Datei, die aus mehreren Dateien Typen besteht. Und hier haben wir also ein Jar Jar Bink Polyglot, das ist ein ganz zufälliges Bild ausgewählt hier aus diesem Video. Man generiert also eine Bink Datei und dann hängt man hinten eine Jar Datei, die im Grunde auch nur eine 7 Datei ist. Und aus diesem Grund ist eben dieses Jar Jar Bink Polyglot möglich. Ein anderer interessanten Polyglot ist, wenn man einen Parasiten, wenn zum Beispiel unser, wenn unser Kuh einen Frosch in der Hals hat, dann kann es froschisch und kuhig sprechen, wie eine andere weite Sache ist, wenn man ein Kuh mit alles valide und alles gültig hat. Allerdings, wenn die Kuh einen SD-Kart schluckt, dann enthält zwar Daten, aber das ist immer noch ein gültiger Kuh. Also als Beispiel, es gibt diese eine Datei, das war einen Haltsch DML5 und Java und ein Excel und ein PDF in der gleiche Datei. Das war interessant. Und der Java droppt ein Java, droppt das Excel und das PDF droppt ein Excel und das sind zwei verschiedene Infektionswege. Und ich habe die Datei selber gemacht. Und hier sieht man die PDF-Teile des Dokuments, das eigentlich in der Java ist. Es ist nicht nur Stapeln, sondern teilweise die Sachen, die eine Format in der andere geparkt. Also, da ist ein anderen Beispiel. Der wird tatsächlich verwendet für Best-Testing. Das ist ein gültiges Bild, man sieht es hier. Und es ist auch ein valides JavaScript. Man nutzt ein header, damit es startet ein JavaScript-Komment. Und wenn der Comments fertig ist, also die Datei, dann kann man der JavaScript ausführen. Das gibt es auch in BMP für Best-Testing. Also, diese Sorte von Parasiten existiert auch in Wildmann, wie zum Beispiel in der Film. Und es nutzt einfach unbenutzte Platz in der Dateiformat. Als ich sagte, ich mache den PGTFO, das ist eine sehr schöne Publikation, sehr interessant. Aber es ist nicht kulturlesen, aber die Datei selber ist auch ein Beispiel. Wie zum Beispiel diese. Es ist auch ein Zip und einen PDF. In der dritte Datei, das war eine gültige Radio Nachricht, ein JPEG, ein PNG, wenn es verschlüsselt war, ein Zip und ein PDF. Die Nummer 4 war ein Validator-Kontainer, ein PDF und einen Zip. Und ich habe es nur hergestellt. Und zwei Tage später wurde TrueCrip abgekündigt. Nummer 5 war ISO und PDF und ein Flash. Also, das erste ist der ISO-Booting, das ist ein Titrischspiel. Das wird alles erklärt. Nummer 6 ist das Neueste. Das ist auch das letzte Monat gewesen. Das ist ein TAR und PDF und ein Zip. Und das ist ein Beispiel, wenn man das öffnet mit einer Datei. Und es öffnet ... Also, wenn man das nutzen würde, mit einem Security-Werkzeug, man könnte das ausnutzen. Weite Handel, Polygloten, Java, JavaScript. Also, man nutzt aus der Source-Basa von der Java und Compiler. Das ist Java und JavaScript in der gleiche Datei. Man kann auch das Gleiche machen auf der Beinerebene. Und deswegen kann man sagen, dass Java gleich ... Tatsächlich ist gleich JavaScript. Und ja, Management hatte es die ganze Zeit richtig. Jetzt ist es bewiesen. Es sind jetzt keine Polygloten mehr, sondern schon ziemlich interessant zu mitspielen, weil auch coole Ergebnisse. Also, wenn man zu große oder zu kleine Dateien, dann ist das ein Bypassfilter. Also, zum Beispiel, es gibt diesen einen Bauer, der dürfte keinen Schrein bauen. Und deswegen hat er einen Riesentisch gebaut, weil dafür braucht er keinen Erlaubnis. Und wenn man das in eine andere Variante macht, man kann eine Datei machen. So ganz oben sieht man die komplette Datei. Es ist eigentlich zu klein für ein Software zu denken, dass es korrekt ist. Und deswegen für das nicht als PDF nehmen. Und damit kann man einen Sicherheitskanner umgehen, weil es einfach zu klein ... Also, es ist zu klein, um ein Problem zu sein. Oder man kann genau das Gegenteil, eine Riesentatei. Das ist zum Beispiel hier. Das krascht einfach jeden Debugger, weil wenn Sie versuchen, alles zu allokieren. Vorsichtig, schlimmer. Alles wurde komplett ausgeführt. Auch wenn Sie komplett leer sind, nehmen Sie Platz in der Memory. Allerdings, das ist zwar ein bisschen nur ein paar Cycles, aber das ist ganz viele Nichts. Und damit es nicht nur langsam auszuführen, sondern man krascht die ganzen Analyse Werkzeuge. Also, jetzt haben wir gesehen, wie wir Datei-Sorten zusammenpacken. Und jetzt werden wir Norden Parsing ausnutzen. Also, wie passt man eine Cow? Also eine Coo. Also, das hier ist wie ein Nutzer, ein Coo ist. Und hier ist ... Wir hatten eine Idee von einem Coo-Past. Also, das ist wie ein Dev, eine Coo ansehen würde. Also, es gibt jetzt einen anderen Dev, der ein Coo anders sieht. Das ist das französische Offizielle. Und das andere ist das brasilianische Art, um eine Coo zusammenzuschneiden. Die gleiche Datei, aber andere Wahrnehmung. Und ansonsten wäre es viel zu einfach. Also, das funktioniert auch mit Coo, nicht nur mit Rechnern. Wie man sieht, die gleiche Coo kann auf verschiedenen Artenweise gesehen werden. Also, das bleibt immer noch das Head glücklicherweise. Aber die Standards sind unterschiedlich. Also, wenn man das ausnutzt, man kann eine PDF erstellen. Der hat drei verschiedene Trailer. Trailer definiert den Würzel-Element. Und das ist die gleiche Datei. Und mit drei verschiedenen Viewers sieht man drei völlig unabhängige Bilder. Zufällige Bilder. Also, der eine ist Chrome. Und der andere ist eine neue PDF-Reader. Die respektieren nicht den Standard wie Adobe. Und deswegen sehen sie in komplett andere Daten. Also, eine Datei, aber drei verschiedene Dokumente. Und die anderen Reader sehen anderen Dateien. Also, sie nehmen nicht die Konditionen wahr. Also, hier, das ist eine Ausdutzung von einem Feature. Das ist ein PDF von einem... Also, man sieht den... Man sieht, der eine Datei, aber wenn man das ausdruckt, ist das ein ganz anderer Ausdruckformat. Man sieht es hier. Und das ist nicht glück... Also, der Standard, es ist Teil der Standards. Das ist nicht so bekannt ist, weil... Also, das ist Obfuscation... Das ist nicht Sicherheit durch Unsichtbarkeit, sondern das PDF ist sehr komplex. Und nicht jeder nutzt das alles. Das ist alles nicht unbedingt sicherheitsorientiert. Oder es gibt hier eine Präsentation, das ich letztes Jahr vorgestellt hat. Das war meine erste Binary Inception. Die gleiche Datei war ein PDF-Viewer und ein PDF-Slide. Also, die Datei hat sich selber gezeigt. Und die Leute... Die Leute haben den Slides geguckt, aber sie haben gleichzeitig den Demo von der Player gesehen. Das war auch eine Java Datei und eine JavaScript mit Mario, weil warum nicht? Und die gleiche Datei, wenn man das in verschiedenen Viewers zeigt, dann hat man völlig verschiedene Dokumente, wie man das hier sieht. Also, wenn man alles kombiniert in einem... Das hier war nicht per Hand geschrieben, sondern generiert. Also, das ist ein Make-File, der das alles zusammen kombiniert. Das ist nicht, ich mache das per Hand. Und wir wollen, dass alles kompatibel ist. Ein weiterer Problem, das für Sicherheit allgemein ist, dass es gibt unerwartete Paarsas. Also, ich weiß nicht, was das... Also, jemand hat ein Problem gefunden, ja, Strings-Kommentare. Und man würde nicht erwarten, dass Strings die Werkzeuge zum Crushing bringen. Also, man sollte nur Strings gucken, aber nein, es ruft ein Paar und es war exploitable. Und da hat das jetzt mit Less gemacht. Und es sind nicht nur verschiedene Paarsas, aber es gibt auch Paarsas in unerwartete Stellen. Von daher würde ich sagen, lasst nicht Strings oder Less auf unbekannten Dateien laufen, weil man weiß nicht. Insbesondere, weil... Ja, hat man es gleich gewusst. Weitere Daten über metadata? Ja, es gibt also ein kinesisches Strings und dann denkt man, na gut, das ist chinesisch oder nordkoreanisch. Also, reden wir über Kuh-, Kühe- und Metadaten. Also, weil man die einzelnen Kühe vielleicht nicht gut erkennen kann, werden die dann halt gebrandet. Aber diese Brandings können eben auch gefälscht werden oder man kann sie eben auch in andere Symbole einbauen. Also, man kann zum Beispiel dafür sorgen, dass die nach was anderem aussehen. Und das bedeutet, dass es schwierig ist, den Autor zu finden. Ja, und wir haben also so ein echtes Branding-Iron-Proof-of-Concept gebaut. Aber wir konnten das nicht an einer echten Kuh ausprobieren. Also, wir haben also hier tatsächlich einfach nur zum Vorzeigen so ein Branding-Iron geschmiedet. Ja, und jetzt gehen wir also zu Kryptosachen von Dateiformaten. Und das Wichtige ist, wenn man normalerweise eine Datei verschlüsselt, dann denkt man normalerweise, dass das Ergebnis verschlüsselt ist, also zufällig aussieht. Man denkt also, normalerweise sieht das zufällig aus, aber man hat in der Einführung schon gesehen, dass das nicht immer stimmt. Und das Ergebnis von Verschlüsselung kann also auch valide sein. Das heißt, es gibt ja auch eine andere Präsentation mit den ganzen Details, aber wir schauen uns das jetzt hier mal an. Also schauen wir uns mal zwei unechte Dateiformate an. Wir haben also ein Daten-Dateiformat und ein Text-Dateiformat und die wichtige Eigenschaft ist, dass es also hier ein Terminator gibt, also ein Endmakierer. Das heißt, man darf an Data beliebige Daten anhängen und Text erlaubt eben auch Kommentare. Das heißt, sobald das Quellformat angehängte Daten erlaubt und man an das andere Format Dinge anhängen kann, dann kann man also diese Technik hier anwenden. Also wenn man kann die Daten hier verschlüsseln und man kriegt im Allgemeinen irgendwie zufällige Daten. Man kann nicht gleichzeitig kontrollieren, was man im Eingang und im Ausgang hat. Also IS ist nach wie vor nicht kaputt, zumindest nicht, dass ich das wüsste. Aber IS ist nur anwählbar auf Blöcke, es ist ein Blog-Seifer. Und wenn man mit einer Datei arbeitet, dann braucht man also so ein Modus für IS. Und üblicherweise benutzt man hier also zum Beispiel ICB und man kann aber den Pinguin noch erkennen. Man sieht also, okay, das ist schlechte Verschlüsselung. Wenn man so ein Modus benutzt, der also nur jeden Blog benutzt und unabhängig verschlüsselt, dann kriegt also derselbe Blog immer dieselben Ergebnisse. Und das ist also keine gute Verschlüsselung. Und einer von diesem Modi, der ICB-Modus, der benutzt also noch einen zusätzlichen Parameter, den Initialisierungsvektor. Da nimmt man also den Initialisierungsvektor und macht XOR mit dem ersten plaintext-Blog. Und das bedeutet, wenn man dann das zusammenbaut, dann bekommt man den ersten verschlüsselten Blog. Man kann das aber auch rückwärts machen und XOR dann natürlich auch rückwärts ausführen. Das heißt, wenn man den plaintext von dem ersten Blog findet, dann kann man den Initialisierungsvektor so basteln, dass dieser Blog so aussieht wie der Blog, den wir erreichen wollen. Das heißt, wir können den einen Output-Blog kontrollieren und den Rest, den können wir nicht mehr kontrollieren. Aber immerhin. Also jetzt können wir uns einen Initialisierungsvektor bauen, sodass der erste Blog in irgendeiner Art und Weise valide ist. Und wir haben Kontrolle also wenigstens über irgendetwas. Na gut, und den Rest, den können wir nicht mehr kontrollieren. Der ist zufällig, das ist das Ergebnis von IIS. Aber wir können es eben nicht mehr manipulieren. Also, was wir jetzt machen ist, wir benutzen das Kommentarfeature von dem Textformat, von dem Zielformat, sodass also der Initialisierungsvektor einen Kommentar anfängt, sodass der Rest also ignoriert wird. Okay, das heißt, wir haben jetzt ein Initialisierungsvektor, sodass da Text drinsteht und dann beginnt eines Kommentars. Und wenn wir jetzt diese Datei nehmen und einfach den Kommentar zu machen und die Daten, die wir sehen wollen, anhängen, dann ist die Datei korrekt und sie ist equivalent zu dem der Datei, die wir als Ergebnis von der Verschlüsselung haben wollten. Und wenn wir das jetzt benutzen und entschlüsseln mit demselben Verschlüsselungsvektor, mit demselben Initialisierungsvektor, dann kriegen wir eine Datei, die genauso aussieht wie das originale Datenformat und irgendwas zufällig, was wir nicht kontrollieren. Aber es ist nach dem Endterminator, das heißt, es wird ignoriert. Das heißt, wir haben jetzt im Wesentlichen das, was wir ursprünglich haben wollten und aus der Pausing-Perspektive ist es eben jetzt genau die zwei Dateien, die wir haben. Und das ist genau der Trick von dieser Arch-Cryption, die ich also zum Beispiel in der Einführung benutzt habe für die PDFs, die wir gesehen haben. Wenn ECB also jetzt nur die Daten, wenn ECB also jetzt nur für den einen Block funktioniert, dann können wir also tatsächlich diese Datei verschlüsseln in diese andere Datei, weil wir den Initialisierungsvektor kontrollieren. Aber es ist tatsächlich verschlüsselter Datei, denn es ist ja mit IS verschlüsselt und IS ist ja auch als sicher eingestuft. Und CBC ist also nicht kaputt wie ECB und man könnte das also in gewisser Weise als sichere Datei ansehen. Einfach nur, weil wir hier die angeringten Daten kontrollieren können. Also schauen wir uns die Dateien vor und nach der Verschlüsselung mal an. Und das kannst du auch zu Hause ausprobieren, mit OpenSSL zum Beispiel, wenn sie das machen möchten, mit zum Beispiel für ihre Kinder oder eure Freunde. Also ich lasse euch das mal ausprobieren. Also eine andere Polyglotte-Datei, hier ist also ein bisschen eine künstlerische Repräsentierung. Viele PASA schauen sich also nur den Inhalt an. Die gucken sich also nur den Inhalt an, die gucken aber nicht vorne dran, die sagen, ah, das ist also eine JPEG-Datei. Und da gibt es jetzt zum Beispiel diese Datei, die ist gleichzeitig JPEG, ZIP und PDF. Und das PDF zeigt ein Bild an, JPEG ist das Bild und ZIP hat andere Inhalte. Aber der Inhalt ist nur einmal in der Datei vorhanden. Das heißt, das wird also quasi nur durch den Header kontrolliert, das also alle auf dieselbe Inhalte zeigen. Man kann es jetzt hier nicht wirklich sehen, aber man hat hier im Wesentlichen das Dateiformat von JPEG, PDF und ZIP. JPEG fängt als erstes an, weil es das benötigt. Und dann kommen die Bilddateien. Also die ZIP-Dateien. Also das ist eine andere, hier gibt es ein Bild von einer Katze als Proof of Concept. Das ist eine unkomprimierte BMP-Datei. Die BMP ist ganz witzig in der Hinsicht, dass man eine Bitmaske für jede Farbe angeben kann. Das heißt, wenn man das einfach durchsichtig macht, dann hat man 16 bits freien Platz, den man nutzen kann. Und man hat also 16 bits, die man kontrollieren kann. Na ja, was kann man damit machen? Man kann zum Beispiel Sound mit einbauen, sodass man also die Bilddatei abspielen kann, ernsthaft. Also ich werde jetzt die Demo nicht machen, weil da werden eure Ohren explodieren. Also ich könnte es, aber es wäre vielleicht nicht ganz lustig. Also man kann dann Musik einbauen in die BMP-Datei. Man kann da tatsächlich das nicht direkt in einem Soundplayer öffnen, weil es nur PCM-Daten sind. Aber wenn wir die Daten in einem Bild einbauen, sodass wir das als Sound abspielen können, dann haben wir genau diese Situation, dass man das Bild als Sound abspielen kann. Also vergesst nicht, eure Lieblingsbilder auch in einem Soundplayer zu öffnen. Philipp hat das hier gemacht mit drei Channels, sodass er, also man sieht hier unten, dass die Spektraldarstellung von der Sounddarstellung, die in diesem Bild eingebaut ist. Das ist also Bild und Sound. Weitere Art von künstlerischen Dateien. Erstmal haben wir mehrere Köpfe, vom selben Typ für auch von den gleichen Fallkörper. Daten müssen nicht mehrfach darin handelt sein, man kann die also einmal darin in der Datei halten und wird sie eben dreifach interpretiert. Und hier ist wieder unser RGB-Bild. Und ich zeige das jetzt mal hier live. Wo ist das, wo habe ich die Datei? Da ist das Bild. Das ist ein PNG-Bild. Und das ist das RGB-Bild. Im Grunde, die Daten bestehen aus Gruppen von jeweils drei Beiz, mit der rot-grün-und-blau Farbeinformation. Und der Trick bei diesem Bild ist, funktioniert es, ja, es sieht so aus. Wir haben hier eine zufällige Palette hinzugefügt. Im Grunde ist der Zweck, dass wenn ihr Bilddaten ein Palette habt, dann ist jedes Beid letztendlich ein Index in diese Palette. Jeder RGB-Wert wird so modifiziert, dass er auf genau eine Farbe in der Palette passt. Und dann ist es ein gültiger RGB-Wert, aber auch ein eigentlicher Wert für diese Palette. Damit könnt ihr ein zweites Bild in den selben Daten des ersten Bildes haben. Also hier ist das Bild. Das heißt, wir haben hier ein Barcode in das Bild eingefügt. Das ist ein QR-Code. Mit einem weiteren Code innen drin. Und je nachdem, welchen Reader ihr benutzt, seht ihr entweder also das eine oder das andere. Das ist fast auch, wenn man das... Wenn man das einfach so mit einem Programm zum Beispiel abfotografiert, dann sieht das Programm zunächst den kleineren Barcode. Und wie man sieht, funktioniert das besser, wenn man eine weise Linie da drumherum hat, denn dann kann man es ein bisschen besser erkennen. Ansonsten, ihr könnt das ruhig mal abscannen. Ihr könnt mir ruhig vertrauen. Okay. Ich habe auch ein bisschen gearbeitet mit... mit berühmten Kryptografen. Und wir haben eine modifizierte Variante von SHA-1 produziert. Also SHA-1 hat mit allen Runden SHA-1, hat aber normalerweise nur fünf Konstanten, von denen man vier modifizieren kann. Es sieht also ähnlich sicher aus wie SHA-1, aber wir können es in gewisser Weise kontrollieren und können Kollisionen damit produzieren. Die Kollisionsregeln sind relativ komplex, und das ist, was man dabei herausbekommt. Man hat also hier zwei Blocks. Die Regeln dazu sind ein ganz bisschen kompliziert. Man darf also höchstens drei nacheinander folgende Bytes haben, die keine Differenz aufweisen. Und in jedem Doppelwort dürfen nur die mittleren beiden Bytes keine Unterschiede haben, und das dauert eine Weile, das zu berechnen. Aber hier haben wir eine modifizierte SHA-1 Kollision. Es ist nicht übermäßig beeindruckend. Meine Aufgabe war also, das Ganze so ein bisschen zu missbrauchen und ein gültiges Dateilverband reinzubringen. JPEG hat die nette Möglichkeit, JPEG hat eine sehr kurze Signatur, und danach kommen diverse Marke. Wir alle gültig lassen, und dann missbrauchen wir das so ein bisschen, indem wir zwei Bilder zu einem kombinieren. Und da, wo die Fragezeichen stehen, da haben wir keinen Einfluss drauf. Aber am Ende können wir was einfügen, also alles, was nicht zu lang ist, können wir da einfügen. Das heißt, hinter dieser Ende von diesem Block, den wir hier nicht kontrollieren, können wir den Beginn des nächsten Bildes einfügen. Und damit kann man irgendein paar Bilder, die zufälligerweise eine SHA-1 Kollision haben, in einem Dateil stecken. Und das funktioniert mit ganz vielen, verschiedenen JPEGs, beliebiger Größe. Und das war gerade vor dem Finale übrigens, das ist aber nur ein Zufall. Und natürlich, das Problem ist, dass dieses Backdoor, damit kann man nur eine Kollision erzeugen, nicht so viele, die man gerne möchte. Aber interessant ist natürlich, wenn man diese Kollision in eine Multi-Type-Polyglot-Kollision erweitern kann, sodass man nicht nur verschiedene Dateiltypen reinstecken kann, sondern auch mehr als zwei Dateien und auch mit mehreren Dateiltypen. Und da haben wir doch ein bisschen mehr Flexibilität. Also es ist nichts, wir haben hier nichts, keine Verschlüsse gebrochen oder ähnliches, aber es ist eine ganz interessante Geschichte in diesen Dateilformaten. Ihr kennt vielleicht den Pony Award, da gibt es verschiedene Kategorien. Das ist für das beste Lied. Ich bin nicht sicher, was das genau mit Pony zu tun hat, aber hier ist der Gewinner des Pony Awards. Öffne das mal hier. Ich habe eine PDF gemacht mit einem Bild mit einem Pony und da ist auch ein Songtext mit dabei. Ich bin nicht sicher, ob ich das jetzt wirklich tun sollte, aber ich hoffe, ich habe Sound. Ich hoffe, ich habe hier Sound. Das ist eine Nintendo Musik, typische 8-Bit Musik, die hier als Polyglot in eine PDF versteckt ist. Warum hat es das auf einmal aufgehört? Ich weiß nicht, aber... Das ist also ein Proof auf Konzept. Man hat das Bild, den Sound und auch den Songtext. Ich bin nicht ganz sicher, warum das jetzt so schnell abspielt, aber... Also ihr solltet auch alle PDFs, die ihr habt, mal versuchen, in eurem Lieblings-NES-Emulator zu öffnen. Ich habe da noch einen Schritt weitergegangen. Vielleicht erinnert ihr euch noch an dieses Bild, an diese Anzeige hier, wenn ihr alt genug seid. Ich bin zu jung, aber... Auf eine ganz ähnliche Art und Weise wir vielleicht schon erahnen, das ist ein PDF-Dokument und dieses PDF-Dokument ist auch gleichzeitig ein gültiges Super-Nintendo-Rom und auch ein Megadrive-Rom. Mit diesen Logos oben. Okay. Ich habe noch jede Menge Zeit, oder nicht? Ja, ich weiß noch nicht. Ja, ich mache erst die Bonus. Wollte ich noch ein bisschen eine Bonus-Modell zeigen? Also hier ist noch was Schönes. Ich mache erst mal die Zusammenfassung. Also, vergesst nicht, was ihr heute hier gelernt habt. Öffnet eure PDFs in einem Hex-Editor, eure Bilder in einem Audio-Player, eure Dokumente in einem Konsolen-Emulator, verschlüsselt und entschlüsselt alles und prüft lieber alles, was ihr ausdruckt, nochmal doppelt nach. Aber ein etwas ernsthafterer Rat für heute. Sicherheitsgründen tut nichts. Und aus Gründen der Forschung tut alles. Und wenn ihr da also irgendwas gefunden habt, dann beschuldigt euch andere, dass sie geholt wurden, denn meistens wollen diese Leute wirklich nur eine Sicherheitslösung verkaufen. Das ist ein bisschen nervig, dass wenn alle Leute immer behaupten, ja, wir haben das und das gehackt, aber sie können es nicht beweisen. Und all diese Proof-of-Konzept, die wir heute hatten, die sind übrigens öffentlich, ihr könnt sie auf meiner Website finden. Ein bisschen ernsthafter noch, also was diese Fallformate angeht. Es gibt sehr viele Möglichkeiten, die Spezifikationen so ein bisschen zu verbiegen. Und die Spezifikationen selbst sind auch manchmal falsch und haben ein bisschen, ja, deutlich und so ein bisschen in die falsche Richtung. Und niemand erhebt jetzt die Stimme und sagt, wir wollen jetzt mal ein sicheres Zip-Format einführen. Das heißt, im Grunde, die Leute, die damals mal die Spezifikationen geschrieben haben, den folgen wir eigentlich blind. Und wann immer irgendwie ein Expoiter für bekannt wird, dann gibt es natürlich eine Reaktion, dass das Sicherheitscommunity, aber niemand sagt, wir machen es jetzt mal besser und sicherer. Und niemand zwingt dann, die Leute auf einmal nur noch ein sicheres Zip-Format oder ein restriktiveres Format zu nutzen, was aus Sicherheitsgründen besser wäre. Meistens beschränkt sich darauf, dass dann eine bestimmte Firma irgendein angeblich sicheres Produkt vermarkten will. Aber es ist dann keine öffentliche Geschichte. Und die Format-Spezifikationen beinhalten das alles nicht. Und die Spezifikationen sind üblicherweise ziemlich, ja, ein bisschen konfus manchmal. Es sind sehr wenige öffentliche Parse, und wenige Parse, die wirklich das Dateilformat auseinandernehmen und anders begreifen. Und natürlich bewegen wir uns da eigentlich auch irgendwo in die falsche Richtung. Das heißt, Standard-Werkzeuge wie Office oder Adobe Reader haben einen sekundären Art, eine Datei zu parsen. Wenn Sie nämlich erkennen, dass eine Datei nicht güldig ist, dann versuchen Sie trotzdem noch die Datei auf eine andere Art zu parsen und vielleicht noch irgendwie was zu reparieren. Und wenn dann was Richtiges rauskommt, dann wird das eben einfach angezeigt. Und das heißt, diese Programme gehen auch mit Dateien um die eigentlich nach der Spezifikation gar nicht güldig sein sollten. Auf Sicherheitsüberlegung ist das natürlich sehr, sehr schlecht. Es gibt auch verschiedene Parsing-Modi, z.B. in Winrar, wenn es eine Datei anzeigt und wenn es extrahiert. Das sind zwei verschiedene Arten, wie Winrar dann die Datei interpretiert. Das heißt, was man in der Forschung hat, ist nicht unbedingt das, was man dann auch wirklich extrahiert. Aber das war so ein sehr allgemeiner Talk nur über die Möglichkeiten. Wenn ihr an den technischen Details interessiert seid, dann schaut euch mal in meinen anderen Talks an. Vielen Dank an alle hier. Ich habe noch ein paar kleine Schmankerl für euch, aber vielleicht erst mal habt ihr irgendwelche Fragen. Wenn ihr irgendwelche Fragen habt, dann stellt euch bitte an den Mikros auf. Ja, fangen wir mal hier an. Ich denke so, dass es möglich ist, einen File-Parser zu schreiben, der wirklich sauber einen GIF-File-Entwickel lesen kann. Irgendjemand hat gesagt, Google hat gesagt, wir können es nicht. Sie wollten die Datei zeigen, und sie wollten das ein bisschen putzen. Sie haben die Datei geplant, jetzt funktioniert es in einem anderen Sicherheitsmodus. Kann man so ein Parser schreiben, also ein Parser, der eine saubere Version von einem Datei macht? Ja, die Leute versuchen das natürlich. Ich selber versuch es nicht. Ich hätte gerne, dass die Spezifikationen ein bisschen vernünftiger wären, aber ich weiß nicht, ob es da eine formale Möglichkeit gibt, dass sie tun. Was ich immer wieder sehe, ist, dass wenn es irgendwo steht, dass dieser Buffer unbedingt null sein soll, dann sagt eigentlich kein Parser, wenn da nichts null drin steht, dann breche ich sofort ab. Also kein Parser ist wirklich so streng, die meisten lassen das durchgehen. Okay, microphone 1. Was wäre deine kurze Hinweis für jemanden, der mit Binarys anfangen will? Also Zeugs mit Binheaders prüfen, dass es kein Müll am Ende ist? Ja, es kommt zunächst mal drauf an, ob dein Dateiformat irgendwie aus Pointen besteht oder ob es von einem Betriebssystem ausgeführt werden soll oder ob es nur solche Strukturen hintereinander enthält, wie zum Beispiel Bilddateien, aber für solche Betriebssystemdateien ist es sehr schwer das zu erzwingen, denn der Lode entwickelt sich natürlich auch weiter. Ja, alle... Jede interpretiert die Sachen auf seine eigene Weise und am einfachsten ist es noch mit Dateien, die reine Daten enthalten, denn bei auch für Bahndateien gibt es noch einer Weise ein Lode, aber wenn man... Natürlich sollte man sich das auf Betriebssystem beschränken, dessen natives Fileformat es ist, aber auf Parzer schreibt nicht ihr das selbst. Hi, danke für den Talk und danke für Bokeh GTFO. Wo kann ich diesen Präsentationen finden und mit wie viel Programme soll ich die probieren? Ja, das lasse ich euch mal selbst herausfinden. Es gibt ein paar extra Spoilers, aber ich versuche es mal selber. Du hast gesagt, das sind der PDF-Specs. Es gibt zwei verschiedene Parsers, eins zum Drucken und eins zum Sehen, aber das klingt wie eine schlechte Idee. Deswegen, warum ist das das historische Grund? Ja, es sind nicht wirklich zwei Parsers, es sind... ...anforderungen von einem Bildschirm und einer Auswirkenseite sind halt unterschiedlich. Das heißt, man kann da bestimmte Teile ausblenden. Es ist halt Teil der Spezifikation. Das heißt, das, was beim Drucken rauskommt, ist eigentlich das richtige, das Offizielle, wenn man so will. Das heißt, man kann also verschiedene Schichten haben und eine dieser Schichten kann zum Beispiel nur für das Anzeigen sichtbar sein und das andere für das Ausdrucken. Und die Leute können das normalerweise nicht an den Ausschalten. Das heißt, man kann das nur ein bisschen ausnutzen. Vor ein paar Tagen habe ich zufällig herausgefunden, indem ich eine PDF angeschaut habe, um unter Linux ein paar Parameter ignoriert und beim Drucken was anderes rauskommt. Ich habe aber nicht die Zeit gehabt, jetzt noch weiter zu verfolgen. Aber das, was auf dem Bildschirm erschien, das war auf jeden Fall anders als das, was dann anschließend rauskam. Thank you. Microphone free? Ja, thanks again for the talk. Und ich habe eine Frage. Also, wie hast du diese ganzen Möglichkeiten gefunden? Die Möglichkeiten gefunden über die Parser und was man ausnutzen kann und hast du einfach die Specs gelesen und gesehen, hey, da kann ich was servieren, da kann ich kommentieren und das kann ich nochmal kombinieren oder hast du nur getestet? Ja, das ist so Teil von meinem normalen Workflow, wenn ich... ich lese eigentlich die Spezifikationen, aber gerade genug, dass ich die Datei manuell erstellen kann und auch auf eine klare Art und Weise erklären kann. Und ich will natürlich auch, dass die Datei klein ist und dazu muss ich natürlich auch wissen, warum jedes Byte da ist. Ansonsten könnte ich das Byte auch weglassen, dann passt das, das geht halt besser auf den Poster. Und deshalb erzeug ich diese Dateien händisch und ich habe natürlich die volle Kontrolle über den Inhalt dieser Datei und deshalb konnte ich auch zum Beispiel Java und PDF mixen, denn letztendlich ist alles irgendwo in x86 assembly geschrieben. Und dann kann ich ein bisschen damit herum experimentieren und kann probieren, was passiert, wenn ich diesen pointer hier verändere und dann stützt das Programm vielleicht ab oder ich bekomme ein anderes Ergebnis. Aber es ist nicht wirklich... ich forsche nicht wirklich an schwachstellende Formate, sondern ich versuche einfach zu verstehen, wofür jedes Byte da ist, um das eben auf eine klare Art und Weise auf den Poster bringen zu können. Und wenn ich das weiß, dann kann ich auch jeden Aspekt der Datei manipulieren und dann passiert eben genauso was. Viele von diesen Sachen habe ich auch zufällig entdeckt, indem ich zum Beispiel in verschiedenen Viewern aufgemacht habe und eine oder andere davon ist dann abgestürzt. Ich suche da nicht aktiv danach und suche nicht nach Schwachstellen in den Parsern. Also ich lese immer nur genau den Teil der Spezifikationen, den ich für mein begrenztes Verständnis davon brauche und ich gehe nicht durch alle Teile der Spezifikationen durch. Danke. Diese Frage ist in zwei Fragen oder eine kombinierte Frage. Jemand will wissen, was... oder... gibt es Countermeasures? Also Gegenmaßnahmen, um diesen ganzen Sachen zu finden und vermeiden. Welche Gegenmaßnahmen es gibt und ob jemand das so eine Datei auf diese Art und Weise manipuliert hat? Ja, man kann natürlich prüfen, ob zum Beispiel hinter dem Ende noch irgendwelche Daten stehen und es ist natürlich ein Problem, dass man könnte überprüfen, ob ein Buffer sehr groß ist und von nirgendwo her referenziert wird. Ich denke da so ein bisschen in das Flash-Format, da gab es mal einen Sendeteil für Flash-Formate, der im Grunde das Flash-Datei eingelesen hat und dann nochmal sauber weggeschrieben hat, aber das hat irgendwie... Niemand war so richtig interessiert daran. Das war ein vollfunktionsfähiges Tool, aber die meisten Leute wollen einfach nur die Datei öffnen und im Grunde sollte diese ganze Arbeit auf der Ebene der Spezifikation erledigt werden und kein Extra-Tool erfordern. Das heißt, es gibt zwar schon einige Gegenmaßnahmen, aber selbst wenn die gut gemacht sind, benutzen die Leute die normalerweise nicht. Hast du schon mal getestet, wie deine Datei sich verhält in einem voransiesischen Umgebung mit bändischen Tools? Habe ich nicht wirklich probiert. Ich habe ein paar lustige Resultate gehört mit verschiedenen Tools, aber ich versuche das auch nicht selber aktiv. Ich erwarte eigentlich Überraschungen, denn wenn ihr meinen letzten Talk gesehen habt, der ist ein bisschen... Da hatte ich eine Zip-Datei, die auf vier verschiedene Anweisen gepasst wurde, je nachdem welches Werkzeug man benutzt, aber auch das probiere ich aus Zeitgründen nicht selber aktiv. Denkst du, wir müssen zu Roh- und Plaintext-Dateien zurückwühren und ASCII als Reputation? Nein, absolut nicht, aber es ist halt einfach nur so, wenn man mal drüber nachdenkt, und die Spezifikation sagt, dass dieser Bereich ist reserviert und soll 0 sein, dann wird kein Paar so sagen, irgendwas stimmt hier nicht, weil da nicht 0 drin steht. Vielleicht bin ich ein bisschen altmodisch, aber sobald da ein Feld drin ist, dann kann ich ja eigentlich alles Mögliche da reinschreiben. Solange ich ein Buffer allokieren kann, kann ich alles Mögliche da reinstecken. Im Grunde sollten wir da nicht zurück zu Plaintext-Dateien gehen, aber es schadet vielleicht nicht ein paar bestimmte Sachen zu erzwingen. Wenn man... Man sollte also wirklich einen Review durchführen, zum Beispiel von Spezifikationen, bevor diese veröffentlicht werden. Ich habe noch ein paar kleine Extra-Dateien hier, die ich vielleicht noch zeigen kann. Wir kommen zum Bonus-Level. Dieser Talk hier war... Eigentlich nur in... Diese Textartei war eigentlich nur ein ASCII, aber gleichzeitig war es auf einen PDF und Tar Polyglot deshalb. Der Fahrplan hat plöderweise all diese Extra-Zeilen entfernt und dann war es wieder die Standartei. Aber das ist der Teilnahme von diesem Tar Archiv hier. Solar Designer hat eine tolle Keynote-Rede vor ein paar Monaten mal gehalten und seine Keynote, der Titel der Keynote war ist Infosec ein Spiel und die Keynote war ein Spiel und dafür hat er eine alte Engine benutzt. Er hatte ein paar sehr nette Grafiken da drin gehabt. Vielleicht erkennt er ein oder andere da was von... Die ganze Keynote war also ein Spiel, das er durchgespielt hat und er hat den ganzen... mit diesem Spiel interagiert. Ihr seht vielleicht dieses Go-to-Fail-Peak-Poke, Exploit und Patch. Es ist ein bisschen schwierig für Leute, das zu genießen, denn das Spiel läuft eigentlich nur in einer DOS-Box und die Leute wüssten nicht so richtig, sie gingen nicht die Zeit dazu. Also, er hat Screenshots davon gemacht und ich habe dann eine PDF geschrieben, die all diese Screenshots enthält in ihrer original Auflösung und wir haben die eigentlichen Spiele damit reingesteckt, sodass man die Spiele aus der PDF heraus starten kann, weil wir es konnten. Also, das ist eigentlich eine tolle Art, alles in einer einzelnen Art zu verpacken. Quines sind so was Künstlerisches. Ich mache da nicht sehr viel damit, aber ein Quine ist eine Datei, das, wenn er ausgeführt wird, seinen eigenen Quelltext ausspuckt. Hier haben wir zum Beispiel ein PE Executable und er druckt seinen eigenen Quelltext aus. Ich benutze aber keine Linker, sondern ich erzeuge das alles mit allen Headern und allem selbst. Die meisten Quines sind nicht sehr sexy, denn man kann einfach ein Compile und Linker benutzen. Aber es gibt Quine Relays, das heißt, wir haben also einen LF-Binary, das die Quelle von einem PE-Binary erzeugt und wenn man das PE-Binary ausführt, dann bekommt man die Quellen von der elften Datei wieder zurück. Aber da ist ein Japaner, der das nicht nur mit zwei, sondern mit 15 Sprachen gemacht hat. Hier sind noch ein paar andere Proof-of-Concepts. Man kann immer das auf der linken Seite, in das auf der rechten Seite, verschlüsseln. Dann kann man natürlich auch ein bisschen was kombinieren. Hier haben wir also ein Polyglot mit einer Hash-Kollision und das ist gleichzeitig Schizophren. Es ist eigentlich alles möglich, was man sich so vorstellen kann. Das ist eine künstlerische Sache und das soll es für heute mal gewesen sein. Vielen Dank für eure Aufmerksamkeit.