 wenn ihr Fragen habt. Der nächste Vortrag ist über, wie man PDFs auseinander nimmt, wie man die Verschlüsselung bricht und die Vortragenden sind Vladislav Mladinov und Christian Meinkar. In der ganzen Welt ist man interessiert, was in diesem Bereich alles so los war, und wir bitten um einen Applaus für unsere Vortragenden. Also hier sind die Folien. Mein Name ist Vladi und das ist Fabian und wir dürfen heute darüber reden, wie PDF Security kompomitiert werden kann und wie man die Kryptor-Operationen da drinnen überwinden kann. Wir sind ein großes Team von der Universität Bochum Münster. Wir reden über die Verschlüsselung in PDF-Files. Wir haben zwei Teile. Der erste Teil ist über digitale Unterschriften. Wenn man das File öffnet, sieht man, dass das Ding unterschrieben worden ist und dass es als gültig überprüft wurde und wer das unterschrieben hat. Das ist der erste Teil dieses Vortrages und ich trage das vor. Der zweite Teil ist über PDF-Verschlüsselung. Wie man sie erkennen kann, ist wie folgt, wenn man das Ding öffnet, dann kommt ein Passwortabfrage und wenn man das richtige Passwort eingibt, dann kann man das File lesen und das mit Adobe öffnet und dann kommen noch zusätzliche Informationen. Das ist der zweite Teil und Fabian wird euch das erzählen, wie man damit umgeht, um das zu überwinden. Bevor wir mit dieser anfangen, brauchen wir ein paar Grundsatzinformationen, wie PDFs funktionieren. Für manche von euch kann das langsam sein und es sind sechs Lights, also haltet durch. 1993 gab es die erste Version von PDF und da gab es schon die Anfänger von Crypto und in 2017 gab es PDF2.0. Gemäß Adobe gibt es 1,6 Milliarden Files im Web, die PDFs sind und die sind überall. Und weil die überall sind, deswegen ist es interessant. Wenn wir so ein ganz einfaches File haben und wir öffnen das mit dem Adobe-Rider, als wir öffnen das, dann sehen wir den Inhalt, wir sehen die Fokusseite und wie viele Seiten das Dokument hat. Was würde denn passieren, wenn wir keinen PDF-Viewer anschauen, sondern nur ein Text-Editor anschauen. Hier ist mit Notepad++ und das sieht so aus. Jetzt mache es mal ein bisschen größer und das erste, was ich sehe ist, wir können es lesen. Das ist jetzt vielleicht unerwartet, aber wir können ein bisschen Informationen darüber lesen. Zum Beispiel können wir die Seiten sehen und hier sieht man, dass es nur eine Seite hat. Interessant ist, dass wir auch den Inhalt sehen können von dem File. Wir können also einen einfachen Text-Editor sehen, um den Inhalt zu sehen und zu bearbeiten. Und für die Angriffe haben wir nur ein Text-Editor verwendet. Und jetzt zu Details. Wie sind die strukturiert und wie werden sie verarbeitet? PDF-Files haben vier Teile. Ein Kopfteil, ein Körperteil. Der Körper in den Haltet alle Informationen, die dem Benutzer gezeigt werden. Dann gibt es die Querverweise und den Abschluss. Und der Prozess des Lesens passiert nicht von oben nach unten, sondern von unten nach oben hier. Zuerst wird der Fußteil angeschaut. Was ist in da alles drin? Da sind zwei wichtige Informationsstücke. Was ist die Wurzel, das erste Objekt, das verarbeitet werden soll? Und wo fängt der Bereich mit den Querverwalt-Signalverweisen an? Das ist das Byte-Offset in dem PDF-File. Woher geht es denn bei dieser Querverweis-Abschnitt? Das ist ein Katalog, der uns sagt, wo die einzelnen Objekte wohnen. Wie können wir dieses komische Ding lesen? Die erste Info, die wir sehen. Also hier haben wir die Kennung Null und da steht daneben, dass es fünf Elemente gibt. Das erste ist die Byte-Position, das zweite ist die Generation und das dritte ist ob es benutzt wird oder nicht. Wenn wir das jetzt lesen, dann kann man die Informationen herausholen, dass das Objekt an Byte-Position Null nicht verwendet wird. Und dann geht das mit den anderen so weiter. Die Objektnummer kommt vom Zählen, die Dinger zu zählen. Null, eins, zwei, drei, vier. Also das Objekt mit der ID4. Und das kann beim Offset 184 gefunden werden. Der PDF-Viewer kann jetzt jedes Objekt hier in dem File finden und das dann lesen und verarbeiten. Und jetzt kommen wir zum Körper. Dem Körper ist alles drin, was der Minuzer gezeigt wird. Das Objekt 4.0 ist dieses hier. Es beinhaltet das Word Hello World. Jeder Point zeigt auf den Anfang von dem jeweiligen Objekt und wie kann ich die lesen? Ich habe ein Objekt, das mit einer ID anfängt und dann mit dem Wort Hopch. Jetzt weiß ich, dass hier ein Objekt anfängt. Wie kann ich diesen Körper bearbeiten? In dem Endabschnitt ist eine Referenz auf das Kern-Element oder auf das Wurzel-Element. Und dort fangen wir jetzt an zu lesen. Da haben wir einen Katalog und eine Referenz zu ein paar Seiten. Pages ist einfach die Beschreibung aller Seiten, die in dem File enthalten sind. Wir haben eine Anzahl eins hier, eine Seite und eine Referenz auf das Seitenobjekt, die die Seite beschreibt. Wenn wir mehr Seiten haben, dann haben wir da mehrere Elemente. Dann kommt eine Seite und wir haben den Content, den Inhalt, der eine Referenz darstellt auf das, was wir schon gesehen haben. Perfekt. Wenn ihr das verstanden habt, dann wisst ihr schon alles oder fast alles, was man über PDFs so wissen sollte. Also könnt ihr einfach ein Editor aufmachen, das öffnen und analysieren. Wir brauchen einen Feature. Ich habe den letzten, einfachsten Teilvergessen, der Heder. Das ist plus eine Zeile, die sagt, welche Version hier benutzt wird. Zum Beispiel in unserem Fall 1.4 für die letzte Version von Adobe wäre das eine 2.0. Wir brauchen dieses eine Feature, das man incrementelle Updates nennt und ich nenne das Feature, kennt ihr das? Feature, das man was highlighten kann im PDF oder dass man so Notizsettel hinterlegen kann, Sticky Notes. Das nennt man Incremental Updates, aber ich nenne das Reviews von Master und Bachelor Arbeiten, weil dafür benutze ich das. Ich liege so ein Text, highlighte was und spreche dann die Information. Auf technischer Seite, wenn man so eine Haft Notiz hinterlegt, dann wird diese zusätzliche Information ans Dateienende angehängt. Wir haben also einen Körper zum Body Element, Body Updates, die einfach nur die zusätzlichen Informationen des neuen Objekts enthält. Natürlich gibt es dann auch eine neue Clear-Verweis-Sektion, X-Riff-Sektion und einen neuen Trailer auch geupdatet. Okay, damit sind wir durch. Wie, wenn wir incrementelle Updates betrachten, sagen wir, dass es hauptsächlich für solche Haft Notizen benutzt wird und wir beobachten etwas sehr Wichtiges, weil beim incrementellen Update können wir stehende Objekte neu definieren. Zum Beispiel das Objekt mit ID.4 können wir neu definieren mit neuem Inhalt. Auf die Weise können wir Hello World ersetzen mit einem anderen Satz und natürlich die Clear-Verweis-Sektion und der Trailer. Das ist sehr wichtig. Mit den incrementellen Updates können wir nicht nur Highlighten und Notizen hinterlassen, wir können auch neuen Content hinterlegen. Vielleicht brauchen wir das ja für das, was wir präsentieren werden. Lass uns über PDF-Signaturen reden. Zuerst brauchen wir das Wissen, wie sich eine digitale und eine normale Unterschrift unterscheiden. Technisch gesehen ist elektronische Signature bloß ein Bild. Hier gibt es keinen kryptografischen Schutz. Es gibt keine zusätzliche Sicherheit im kryptografischen Sinne. Wo wir hier reden, ist die digitale Signatur von PDFs. Also wenn man so ein File öffnet, dann sieht man die Zusatzinformation bezüglich der Validierung der Signature und wer das Ganze unterschrieben hat. Also wie schon vorher erwähnt, konzentrieren wir uns nur auf die digitale, nicht elektronische Signatur. Welcher Prozess steht denn hinter der digitalen Signatur? Stellt euch diesen abstrakten Überblick über das PDF vor und wir wollen das jetzt signieren, was passiert ist, dass wir über ein incrementelles Update zusätzliche Informationen bezüglich hinzufügen. Es gibt ein neues Catalogobjekt, ein neuen Catalog mit der Signatur und den Informationen dazu, wie das unterschrieben wurde und natürlich eine Xref-Querverweis-Sektion und ein Trailer. Für euch relevant, das komplette File wird jetzt durch die PDF-Signature geschützt. Also wenn wir das manipulieren, das sollten wir nicht in der Lage sein zu tun. Ja, lasst uns darüber reden, wie, warum das nicht geht und vor allen Dingen wie wir es kaputt machen können, brechen können. Ein Angriffsszenario wäre folgendes. Als Angreifer haben wir ein signiertes PDF-File, zum Beispiel eine Rechnung oder ein Vertrag. In unserem Fall ist das eine Rechnung von Amazon. Wenn wir die öffnen, sehen wir die valignen Signature. Alles ist grün, es gibt keine Warnings und alles ist super. Was wir versuchen ist, dieses File zu manipulieren auf irgendeine Art und Weise und dem Opfer zu senden und das Opfer erwartet eine signierte Datei. Wir denken darüber nach oder wir erwarten, dass das Opfer erwartet, ein gültiges File zu bekommen und dass die linke Seite normales Verhalten ist. Aber auf der anderen Seite ist Inhalt ausgetauscht worden. Das heißt, also wir haben das Ding manipuliert und einen anderen Inhalt reingesteckt und dann das so verändert, dass die Signature trotzdem richtig aussieht. Jetzt gibt es da unterschiedliche Angriffsmöglichkeiten. Da gibt es den Angriff, also die Angriffsklassen und die erste ist die Teilabspeichern-Attacke, Incremental Saving Attack und da fügen wir Sachen hinzu, nehmen sie weg oder definieren die Objekte um und die Unterschrift bleibt trotzdem korrekt. Wir haben also jetzt hier wieder unser File mit seinen vier Teilen, was ist unterschrieben und die Unterschrift, die Unterschrift schützt nur die unterschriebenen Teile. Wenn ich jetzt eine Sticky Note dazu füge, also so ein gelben Aufkleber, dann soll die Signatur ja durch diesen Aufkleber nicht kaputt gemacht werden, aber ich muss trotzdem hinzufügen können. Das heißt also unsere erste Idee war, neue Updates für den Körper zu machen, die Querverweise und den Enteilricht in Neuzuschreiben und da haben wir nicht gedacht, dass das funktionieren würde und das hat natürlich auch nicht funktioniert. Und da kommt die Nachricht, ja es ist gültig, aber das Dokument ist neu überarbeitet worden. Ja jetzt muss der Benutzer korrekt interpretieren, was diese Nachricht bedeutet, aber richtig ist es schon. Also der Status ist nicht gleich, wie man weiter links oben sieht, sieht ein bisschen anders aus. Was wir also gemacht haben, wir haben das mit älteren Viewern angeschaut, LibreOffice. LibreOffice zum Beispiel hat es nicht mitgekriegt, dass wir da Veränderungen gemacht haben. So jetzt haben wir uns gefragt, die anderen sind relativ sicher, aber wie haben die das denn festgestellt? Man kann einfach schauen, ob nach der Signatur noch mehr fehlt, hinzugefügt worden ist. Und wenn die anderen Teile einfach entfernt, dann ist das ein kaputtes PDF-File. Die PDF-Viewer haben das für uns in Ordnung gebracht. Die waren fehlertolerant. Und die Überprüfungslogik hat einfach geschaut, ist da unten ein Ende dran, ordentliches? Nein, ja. Und hat es hinzugefügt. Das heißt also, der Viewer hat für uns das Ding zu einem Kompletten gemacht und hat keine Warnung ausgegeben. Einige Viewer haben unbedingt ein Ende gebraucht. Also haben wir die Fehlverweistabelle rausgeschmissen, haben das normale Ende dran gepackt und haben ein paar Viewer gefunden, die mit dem Ding umregen konnten. Das heißt wir hatten PDF-Viewer, die haben geschaut, ob jedes inkrementelle Update auch die Unterschrift enthält. Also haben wir einfach die Unterschrift, die oben war, unter die anderen runter. Und dann haben wir den PDF-Viewer gebeten, diesen Inhalt doppelt zu bestätigen. Und diesmal sind sie wieder auch verarbeitet worden. Das heißt, wir haben auch da Viewer gefunden, die verletzbar waren. Also wir haben uns 22 Viewer angesehen, davon waren 11 verbundbar, auch Adobe mit verschiedenen Versionen, Foxit. Wie ihr sehen könnt, 11 von 22 Viewern waren verbundbar. Das sind 50 Prozent und wir waren wirklich überrascht. Wir haben gesehen, dass die Entwickler gesehen haben, dass es gefährlich sein kann, aber trotzdem haben wir es geschafft, an den Sicherheitsmechanismen vorbeizukommen. Ein false signature Bypass, wie es hier steht, bedeutet, dass das Opfer keine Chance hat, zu bemerken, dass ein Angriff stattgefunden hat. Limited, was hier steht, heißt, dass das Opfer, wenn es auf mindestens eine zusätzliche Schaltfläche klickt und ganz besonders spezifisch die Signatur, die Unterschrift validieren möchte, dann würde der Viewer das auch anzeigen, dass manipuliert wurde. Das Wichtigste an der Stelle, dass es beim Öffnen der Datei auch eine Statusnachricht kam, dass alles erstmal in Ordnung ist. So, lasst uns über die zweite Angriffsklasse reden. Wir nennen sie Signature Wrapping Attack, unsere komplexeste Attacke. Hier müssen wir etwas in die Details reingehen, wie diese Unterschriften erstellt werden. Stellt euch ein PDF-Fall vor, mit Header und dem Originaldokument. Da ist wieder der Header drin, der Körperteil, die Verweise und so weiter. Das wollen wir signieren, unterschreiben. Auf technischer Seite heißt es, da kommt wieder ein incrementelles Update dazu, wir haben einen neuen Katalog, weitere Objekte, zum Beispiel Zertifikate und die Signaturobjekte, die Unterschriftobjekte. Darauf konzentrieren wir uns jetzt. Dort ist viel Informationen drin, aber eigentlich sind für unsere Angriffe nur zwei Elemente relevant, Content und Bidrange. Content, das ist wirklich der Wert der Signatur, zum Beispiel die Zertifikate, die für die Validierung verwendet werden. Die Bidrange enthält vier verschiedene Werte, wie werden die verwendet? Die ersten zwei und B definieren die ersten Teile der Unterschrieben signiert wird bis zum Anfang der Signatur der Unterschrift. Warum brauchen wir das? Weil der Signaturwert ja auch mit unterschrieben wird. Wir müssen es irgendwie rausnehmen von dem unterschriebenen signierten Inhalt. So wird diese Bidrange verwendet. Der erste Teil halt bis zum Anfang der Signatur und nach dem Ende der Signatur bis zum Datei endet, das ist die zweite, der zweite spezifizierte Bereich von den zweiten Zahlen C und D. Jetzt haben wir alles geschützt, außer die Signatur selbst. Was wir ausprobieren wollten, war weiteren Platz für unseren Angriff in das PDF einzufügen. Also war unsere Idee, den zweiten Teil einfach da reinzubewegen. Wie können wir das tun? Einfach indem wir eine andere Bidrange definieren. Wir hier sehen könnt, zeigt diese neue Bidrange weiterhin auf dem Bereich A bis B, da haben wir den ersten Teil gar nicht manipuliert. Das ist immer noch Valide. Der nächste Teil, der neue C-Wert, aber dort, wo vorher C war und bis zum Ende haben wir nichts verändert im signierten Bereich. Und die Signatur ist immer noch gültig. Was wir aber eingefügt haben, war ein bisschen Platz für gefährliche Objekte. Manchmal haben wir auch ein bisschen Padding gebraucht, einfach Fülldaten. Der Platz für unsere manipulierte Verwaltsektion wird von Trailer vorgegeben. Da hatten wir nicht viel Spielraum, aber es funktioniert einfach super. Und jetzt fragen wir uns, wie viele von unseren PDF-Viewern lassen sich durch diesen Angriff beeinflussen. Und wir sehen 17 von 22 haben sich davon überzeugen lassen. Das war jetzt auch was wir erwartet haben. Der Angriff ist so gebaut, dass viele Entwickler von Viewern einfach darüber nicht ordentlich nachgedacht haben. Und jetzt kommen wir zur dritten Klasse der Angriffe, universelle Unterschriftenfälschung, Universal Signature Forgery. Jetzt suchen wir nach dummene Umsetzungsfehlern, Stupid Implementation Floors. Viele von euch haben interessante Erfahrungen mit null Bites, null Werten. Und das sind Dinge, die wir hier ausprobiert haben. Wir haben versucht, dumme Werte da reinzuschreiben oder Referenzen zu entfernen. Und haben nachgeschaut, was passiert. Es gibt also hier zwei wichtige Elemente. Das eine ist der Content, das andere ist der Byte-Range. Und die Byte-Range schreibt, was unterschrieben ist. Was passiert, wenn wir den Inhalt entfernen? Unsere Hoffnung war, dass der Reader das immer noch zeigt, aber man sagt, dass das Verrifizieren nicht möglich war. Und das haben wir nicht geschafft. Jetzt haben wir den Content Tag getan, aber haben keine Rehte. Wir haben das Tag getan und haben null hingeschrieben oder haben null Byte hingeschrieben. Und für die letzte Version haben wir zwei Viewer gefunden, die sich davon haben überzeugen lassen. Ein weiterer Fall sieht so aus. Wir haben die Byte-Range entfernt. Wir haben zwar noch Unterschrift, aber wir wissen nicht genau, was unterschrieben ist. Das haben wir in verschiedenen Formen probiert. Hier sieht man es. Wir haben gar keine Werte angegeben. Wir haben null angegeben oder wir haben negative Offsets angegeben. Und das letzte hat normalerweise zum Absturz geführt. Aber das Interessanteste war, dass Adobe für den ersten und dritten Fall das Dokument als korrekt angesehen hat. Das war ein dummes Umsetzungsproblem. Und alle Dinge, die wir unseren PDFs in unseren Präsentationen zeigen, ist mit Adobe an der Stelle gemützt worden. Also, vier von 22 haben sich als angreifbar gezeigt, wird diese klassisch. Bei den anderen ist irgendein Art von Fehler aufgezeigt worden. Adobe hat es einfach, das in Ordnung zu können. Also, die ersten beiden Probleme hat er Adobe nicht gehabt, aber das hier halt. Zusammenfassend haben wir 21 von 22 Video hier kaputt gemacht. Der einzige sichere PDF-Viewer ist Adobe 9, was eigentlich schon veraltet ist und sehr große andere Sicherheitsdrücken für Remote Code Execution hat. Die einzelnen Nutzer, die das überhaupt nutzen können oder nutzen, sind Linux Nutzer, weil es die letzte für Linux unterstützte Version war. Darum habe ich es überhaupt in Betracht gezogen. Ich bin jetzt fertig mit dem Vortrags-Teil über die PDF-Signaturen-Unterschriften und jetzt soll es um die PDF-Verschlüsselung gehen. Fabian übernimmt. Ja. Okay. Nachdem wir mit den Unterschriften fertig sind, lassen es über einen neuen Aspekt reden. Da ist es wirklich die Verschlüsselung. Einige von euch können sich vielleicht an die PDF-X Verwundbarkeit erinnern von früher im Jahr. Das hat natürlich ein Logo das Ganze und es sind zwei neuartige Techniken, PDFs anzugreifen. Das eine wird direkte Exfiltration genannt, direkte Exfiltration. Wir haben keine Manipulation im PDF. Das zweite nennt sich Meliability Gadgets. Da modifizieren wir wirklich den verschlüsselten Text im PDF-Dokument. Lass uns aber das Ganze ein bisschen weiteren Winkel ansehen. Zum Beispiel der Verschlüsselungsstandard, die Faktorstandard für Office-Dokumente ist AES. Das ist gut, damit ist nichts falsch. Und PDF unterstützt das. Aber wir schauen genauer hin und sie benutzen als Operation Mode CBC Cyberblock Chaining. Aber wichtiger ist, dass sie keine Integrität schützen, keine Mac. Es ist nicht Integritätsgeschütztes AES CBC. Ähnlich wie Angriffe gegen E-Mail haben sie das gleiche Problem dadurch. Zuerst wer benutzt es? Das fragt euch vielleicht. Zum Beispiel lokal Banken in Deutschland als Ersatz für S-Mime und Open PHP, weil Kunden damit nicht arbeiten wollten mit verschlüsselten E-Mails. Das zweite ist, dass es Plugins gibt für E-Mail, die man zum Beispiel mit Outlook integrieren kann statt verschlüsselter E-Mail. Wir haben auch medizinische Geräte und Scanner gefunden, die potenziellen E-Mails mit solchen PDFs versenden können. Man kann da das Passwort setzen und die Verenden versenden, die Dokumente dann verschlüsselt. Und zuallerletzt haben wir Regierungsorganisationen gefunden, die solche verschlüsselten PDFs verwenden, zum Beispiel die Justizbehörde der USA. Ich habe keine Ahnung, wie geht das Passwort kriegen. Wir stammen aus akademischem Hintergrund. Lass uns unser Attack-Model anschauen. Alice will Bob ein Dokument senden über ein nicht verschlüsselten Kanal oder ein Kanal, den sie nicht vertraut. Darum natürlich verschlüsselt sie das zweite Szenario. Sie wollen das PDF zu einem gemeinsamen Speicher wie Dropbox oder anderen Cloud Storage hochladen. Die vertrauen dem Storage-Mechanismus nicht und verschlüsseln darum wieder. Nehmen wir an, dass tatsächlich dieser Shared Storage diese Cloud-Speicher-Lösung gefährlich ist. Alice lebt das PDF wieder hoch zum Angreife an diesem Fall. Der modifiziert das PDF und schickt das PDF weiter an Bob. Der wird sein Passwort eingeben, weil er es nicht unterscheiden kann, ob es das Original-Dokument oder das Manipulierte ist. Und der Klartext des Dokuments geht zurück zum Angreifer. Also lass uns den ersten Mechanismus anschauen. Das nennt sich direkte Exfiltration. Wir brechen die Kryptografie ohne sie anzufassen sozusagen. Zuerst einmal eine Zusammenfassung für PDF-Verschlüsselung. Also die Struktur habt ihr schon gesehen. Da gibt es den Header, den Körperteil mit den ganz interessanten Objekten, zum Beispiel unser vertraulicher Inhalt, den wir exfiltrieren wollen als Angreifer und natürlich die Verweistabelle und der Trailer. Was verändert sich, wenn wir das ganze Dokument verschlüsseln? Nicht so vielmal. Statt der vertraulichen Daten gibt es natürlich einen verschlüsselten Text, aber ansonsten ziemlich das gleiche. Es wird nur noch ein neuer Wert im Trailer hinzugefügt, der uns sagt, wie wir das ganze wieder entschlüsseln können. So, das sehr viel von der Struktur, was nicht verschlüsselt ist. Und wir dachten, hm, und haben genau hingeschaut, genau genommen in den PDF-Standard, die PDF-Spezifikation und die interessanten Teile markiere ich für euch. Encryption wird nur auf Strings und Streams angewendet, nicht an Objekte. Alle anderen Objekte, weil das Dokument über Random Access zugreifbar sein soll. Zum Beispiel, dass man nicht neu pasen muss, wenn man auf Seite 16 springt. Aber das heißt, die ganze Struktur ist nicht verschlüsselt, nur Strings und Streams. Das gibt uns sehr viel andere Informationen, zum Beispiel die Anzahl der Seiten oder die Größe der Seiten, Anzahl und Größe von Objekten und es schließt auch Links, zum Beispiel Hyperlinks ein. Das ist viel Information, die ein Angreifer eigentlich nicht haben sollte. Vielleicht können wir unseren eigenen nicht verschlüsselten Inhalt hinzufügen. Wir haben uns wieder den Standard angesehen und herausgefunden, dass es sogenannte Crip-Filter gibt, die feingannulare Kontrolle der Verschlüsselung ermöglichen. Als Angreifer kann ich das Dokument verändern, sodass ich sage, dass nur Strings verschlüsselt werden und Streams nicht. Dafür gibt es diesen Identity-Filter. Ich habe keine Ahnung, warum sie das so beschlossen haben, aber es ist so. Es gibt also Unterstützung für partielle Verschlüsselung der Content, den der Angreifer gibt, mit tatsächlichem verschlüsselten Content gemixt. Wir haben 18 verschiedene Techniken gefunden, wie man das ausnutzen kann. Lass uns das anschauen. Wir haben dieses verschlüsselte Dokument, geben unser Passwort ein und bekommen die Geheimen-Nachricht. Wenn wir es jetzt neu öffnen in einem Editor und wir sehen das Objekt 4.0, da ist der verschlüsselte Text und wir sehen hier, dass es IS verschlüsselt ist. Schlüssellänge 32. Jetzt packen wir ein neues Objekt dazu. Das enthält Klartext. Das tun wir in den Inhaltsteil, den Content, speichern, öffnen das neu, geben das Passwort wieder ein und das ist irgendwie wirklich komisch und peinlich. Also wir haben die Integrität des verschlüsselten Dokuments verändert. Du denkst, ihr denkt euch vielleicht, die wollten vielleicht das gar nicht so machen, vielleicht ist das ein Anwilligungsfall, ein valide Anwilligungsfall für Leute. Aber können wir auch den Klartext des verschlüsselten Teils extra hin? Wir gucken wieder den Standard rein. Das erste, was wir gefunden haben, sind sogenannte Submit Form Actions. Das sind so ziemlich wie die Formulare auf Webseiten. Man kann Daten eingeben. Ihr habt es zum Beispiel in einem PDF-Vertrag gesehen, wo man den Namen eingebt, Adresse und so weiter. Und die Daten, die da drin gespeichert werden, werden als Strings gespeichert oder als Streams. Und jetzt denkt dran, das ist genau das, was im PDF überhaupt verschlüsselt wird. Das kann man auch an einen Angreifer schicken oder kann das über einen Button-Click machen, aber das ist ziemlich lame. Und wir haben sogar eine Action gefunden, die ausgeführt wird, wenn man das Dokument einfach nur öffnet. Also wie sieht das dann aus? So sieht ein PDF-Formular aus, schon mit dem Angriffscode enthalten. Wir haben hier eine URL, die ist nicht verschlüsselt, weil alle Strings nicht verschlüsselt sind. Wir haben das Object 2.0, wo die tatsächlichen verschlüsselten Daten sich befinden. So sieht das Formular-Feld aus. Auf der Seite des Angreifers, wenn er das Dokument öffnet, bekommen wir einen HTTP-Post-Request mit vertraulichem Inhalt. Wir öffnen wieder das PDF, öffnen es wieder in einem Editor, können wieder sehen, dass verschlüsselt ist und wir schließen uns, dass wir alle Strings wieder zum Identity-Filter ändern und Strings nicht mehr verschlüsselt werden. Dann packen wir binäre Informationen dazu, also das Inform-Actions enthalten, zum Beispiel die URL, p.df und das inkriptete, das verschlüsselte Objekt. Wir steigen einen HTTP-Server für das Dokument und sobald wir das öffnen, wird Adobe eine Warnung zeigen, aber Nutzer werden das wahrscheinlich für dauerhaft freigeschaltet haben und der Attacker-Server zeigt uns die geheime Nachricht an im Klartext. Das ist ziemlich schlimm. Das funktioniert auch mit Hyperlinks, denn in PDFs gibt es natürlich auch Links und wir können eine Basis URL für alle Hyperlinks in einem PDF definieren. Wir können sagen, alle URLs in diesem Dokument fangen mit HTTP p.df an und jedes Objekt, das wir so präpariert haben, wird als URL gesendet. Wieder ziemlich schlimm und die Vertraulichkeit des Dokuments ist kaputt. Jeder libt natürlich JavaScript in PDF-Files und mit JavaScript geht das auch ähnlich. Okay, lasst uns über Angriffe auf die Cypher, auf die eigentliche Kryptografie reden. Ja, bestimmt von Attacken auf OpenPGP und Esmem gehört. Da gibt es Voraussetzungen. Wir brauchen Cypher-Text-Malability, wie wir es schon erwähnt haben. Wir müssen etwas über den Rheintext, über den Klartext-Dokument wissen und einen Exfiltrationskanal, wie ihr es auch schon gesehen habt. Dafür haben wir ja die Hyperlinks gerade gezeigt. Lass uns über diese Gadgets, über die Cypher-Text-Valability. Ihr könnt euch vielleicht an dieses Diagramm erinnern in eurer Einführungsvorlesung zur Kryptografie. Das ist die Funktion CBC-Cypher-Blockchaining. Ihr habt euren Schlüsseltext, den ihr verschlüsseln wollt, verschlüsselt den Text oben und den Klartext hier unten und da wird einfach die Exor-Operation angewendet, um den Klartext zu erhalten. Was passiert jetzt, wenn man ein einzelnes Bit im verschlüsselten Text ändern? Zum Beispiel das erste Bit. Nun, das Bit wird auch im Klartext sich verändern. Moment. Wenn wir den einen kompletten Teil des Klartexts kennen, dann geschieht eine Exor-Operation im ersten Block und dann bekommen wir alles nullen und da können wir quasi frei drauf schreiben. Auf die Weise können wir zum Beispiel im Schlüsseltext URLs einbauen und letztendlich auch im entstehenden Klartext. Wir können sie auch klonen, also an verschiedenen Stellen in den Schlüsseltext einbauen, aber denkt bitte dran, da ist ein Lawineffekt, so dass wir irgendwelche Random Bites haben, aber die URL bleibt immer noch da, wo sie ist. Damit haben wir auch Cypher-Text-Malability erledigt. Jetzt bauen wir noch ein Klartext, den wir da kennen. Der PDF-Standard war bisher sehr, sehr hilfreich. Lasst uns den nochmal anschauen. Und was wir da gefunden haben, sind Permissions, also Zugriffsrechte für den Autor und den Nutzer des Dokuments. Das heißt ein Autor kann das Dokument editieren und ein Nutzer darf das vielleicht nicht. Natürlich haben Leute an diesem Wert rumgespielt und in der letzten Version wurde auch entschieden, dass das Ganze dann verschlüsselt wird. Wie sehen diese 16 bytes dann aus? Wir haben im zweiten Teil die Erlaubnisse, im dritten haben wir, ob es überhaupt verschlüsselt ist, für die Metadaten, dann haben wir eine Konstante, diese 3 bytes ADP und am Schluss zufällige Daten. Und wir wissen vieles davon. Das ist bekannter plaintext. Wie sieht das in einem Dokument aus? Unten sehen wir diesen Permissions, also Erlaubnisse, Wert. Und das ist allen gut viel. Auf der rechten Seite sehen wir den verschlüsselten Inhalt. Und all diese Dinge sind mit dem gleichen Dokument weiten Schlüssel verschlüsselt. Und dass die alle mit dem gleichen verschlüsselt sind, können wir in dieser Methode veranmelden. Also die Leute haben die Erlaubnisse geändert, dann sind sie verschlüsselt worden, um das zu verhindern und jetzt nützt uns das, die Verschlüsselung zu bräuchten. Und jetzt machen wir wieder eine kleine Demo. Wir nehmen also dieses Dokument wieder, mit dem Passwort. Jetzt kommt das Passwort rein, also das gleiche wie vorher. Jetzt habe ich ein Skript für euch vorbereitet, weil ich das nicht von Hand zu schnell machen kann. Und es tut das, was wir erzählt haben. Jetzt hat also diese fünf Schritte gemacht und jetzt starte ich mein Server. Und wenn ich jetzt das Ding starte, mit dem veränderten Dokument und sobald mal das Passwort reintut, schickt uns der Chrome den Inhalt zurück. Wir haben also 27 Viewer angeschaut und haben gefunden, dass alle mindestens einen Attack angenommen haben. Wir haben manche Mitbenutzerinteraktion gesehen, das Adobe hat eine Warnung gezeigt, aber manche haben auch gar nichts gezeigt. Was kann man denn dagegen trugen? Unterschriften könnten vielleicht helfen. Eine Unterschrift auf dem unterschriebenen Fall hilft euch. Nein, das hilft nicht. Warum nicht? Eine kaputte Signatur verhindert nicht, dass es geöffnet wird. Unterschriften können entfernt werden, weil sie nicht verschlüsselt sind und sie können gefälscht werden. Die Antwort ist auch nicht, dass man die Kanäle schließt, mit denen man in das austragen könnte. So, und jetzt sollen wir Formulare und Hyperlinks entfernen und JavaScript entfernen. So, jetzt können wir den Benutzer fragen, bevor wir mit dem Website reden. Kurzfristige Gegenmaßnahmen sind hier. Google hat aufgehört, das zu fixen. Sie haben das automatisch in Ordnung gebracht. Aber an dem Standard können sie nichts ändern. Wir müssen teilweise Verschlüsselung abschalten oder aus dem Standard rausnehmen, um wirklich dagegen zu schützen. Und wir können kurzfristig in den Zugruf auf solche Dinge verbieten. Adobe hat das zu der ISO Working Group Arbeitsgruppe hingeschickt. Und das wird in der nächsten Revision vom PDF behandelt werden. Das war unser Beitrag. Vielen Dank, das war ausgezeichnet. Kompetitionen Mikrofonen, wenn ihr Fragen habt. Wir haben noch ein bisschen Zeit. Ich finde diese Nachforschung sehr interessant, weil es mich zum Denken anregt, wie das in der Praxis benutzt werden könnte. Und was für hinterlistige Dinge ihr euch sonst noch einfallen lassen könntet. Das hier braucht doch ordentliche Ressourcen und einen motivierten Angreifer. Die meisten von uns werden nicht von der NSA angegriffen. Das heißt, wir brauchen jemanden, der aktiv in der Mitte sitzt, um diese Angriffin durchzuführen. Jetzt hören wir hier, der nächste Standard könnte eine Fehlerbehandlung beinhalten. Habt ihr da eine Vorstellung von der Zeit? Nein, wir wissen das nicht. Wir haben mit Adobe geredet. Und die haben gesagt, sie zeigen uns die nächste Version, bevor sie es rausgeben. Aber wir haben keine Zeitleiste dafür gekriegt. Vielen Dank, da hinten ist ein Mikrofon Nummer fünf. Ja, danke für einen interessanten Vortrag. Ihr habt in der ersten Seite die Signatur mit den vier Zahlen, die die ByteRanges angeben. Warum sind diese vier Zahlen nicht Teil der Signatur? Die Antwort ist, die ByteRange ist geschützt, aber wir haben eine zweite eingefügt. Und wir haben die Unterschriebene nach hinten geschoben und dann ist sie später überprüft worden. Aber nur die erste wird bearbeitet. Danke. Mikrofon Nummer vier. Ich habe eine Antwort und eine Frage für euch. Ihr habt gefragt, wie das Department of Justice diese Password verteilt, entweder als Plaintext in der E-Mail oder als Passwort der Woche. Und das Militär macht es nicht viel anders. Ich habe hier ungefähr ein halbes Terabyte sensibler PDFs, die ich gerne scannen würde. Ob da werfen kann, ob das eine Password ist, was geschwärzt ist, aber nicht korrekt gemacht wurde. Habt ihr irgendwelche Tools, mit denen man sowas erkennen kann? Ich kenne keine Tools zu dem Thema. Aber wenn du Entropie untersuchst, dann ist es ziemlich schwer zu machen. Die Dialog-Exhultation sollte nicht in der E-Mail, sondern in der E-Mail. Dann müsstest du das zumindest finden können. Ansonsten kannst du einfach nach Worten wie Identity suchen, die wir auch ein Paper geben. Aber Tools habe ich nicht dafür. Jetzt Mikrofon Nummer zwei. Ich habe eine Empfehlung. Du könntest dein PDF-Reader in einer virtuellen Form machen. Du könntest dein PDF-Reader in einer virtuellen Maschine fahren, der eine Fireball hat. Und zu dem Fälschen der Unterschriften habt ihr denn schon mal drüber nachgedacht, das Zertifikat zu modifizieren? Und wie fängt das? Ja, wir haben drüber nachgedacht, das Zertifikat zu fälschen. Aber wir sind zu dem Schluss gekommen, dass wir gesagt haben, dass es wahrscheinlich viel zu sicher ist, dass es sich lohnt, das anzugreifen. Ja, vielleicht hören wir mehr von euch in der Zukunft. Vielen Dank. Noch eine Frage vom Internet. Ich habe zwei Fragen zum ersten Teil des Gesprächs. Ich habe noch zwei Fragen. So, ihr habt ein paar Antworten von den Herstellern erwähnt. Könnt ihr noch ein paar mehr erzählen? Am Anfang, als wir angefangen haben, haben wir das Zert vom BSI gefragt, uns zu helfen. Weil viele Hersteller betroffen sind. Und wir konnten nicht mit denen reden. Und das BSI hat uns den gesamten Weg unterstützt. Wir haben den Report erzeugt. Mit den Beschreibungen der Verletzlichkeiten und wie man es ausnutzen kann gemacht. Und das BSI hat dann die Hersteller kontaktiert und für uns die Kommunikation dort geführt. Ich weiß nicht alles, was da gesprochen wurde, sondern nur der technische Zeug, wo wir den Fix neu testen sollten. Es gab Reaktionen von Adobe, von Foxit, die auf unsere Angriffe reagiert haben. Aber nicht alle. Vielen Dank für den Vortrag.