Die Aufgabe der Forscher war einfach: Den Inhalt eines signierten PDF-Dokuments zu \u00e4ndern, ohne dabei die G\u00fcltigkeit der Signatur zu beeintr\u00e4chtigen. Theoretisch k\u00f6nnten Cyberkriminelle das Gleiche tun, um einer signierten Datei falsche Informationen oder sch\u00e4dliche Inhalte hinzuzuf\u00fcgen. Schlie\u00dflich vertrauen Kunden einem von einer Bank signierten Dokument und klicken h\u00f6chstwahrscheinlich auch auf die darin enthaltenen Links.<\/p>\n
Das Team w\u00e4hlte die 22 beliebtesten PDF-Viewer f\u00fcr verschiedene Plattformen aus und f\u00fctterte sie systematisch mit den Ergebnissen ihrer Experimente.<\/p>\n
Die Struktur einer PDF-Datei<\/h2>\n![\"Dateistruktur](\"https:\/\/media.kasperskydaily.com\/wp-content\/uploads\/sites\/96\/2020\/01\/16133730\/36C3-PDF-digital-signature-1.png\")
<\/a>Struktur einer PDF-Datei<\/p><\/div>\n
Zun\u00e4chst ein paar Worte zum PDF-Format selbst. Jede Datei besteht aus vier Hauptteilen: Header (dt. Kopfzeile), die die PDF-Version anzeigt; Body (dt. Textk\u00f6rper), der den Hauptinhalt widerspiegelt; XRef-Table, ein Verzeichnis, in dem die Objekte im Textk\u00f6rper und ihre Positionen aufgelistet sind (zum Anzeigen des Inhalts); und Trailer, mit dem PDF-Viewer das Dokument lesen. Der Trailer enth\u00e4lt zwei wichtige Parameter, die dem Programm mitteilen, wo mit der Verarbeitung der Datei begonnen werden soll und wo der Xref-Abschnitt beginnt.<\/p>\n
Im PDF-Format ist eine inkrementelle Update-Funktion integriert, mit der die Benutzer beispielsweise einen Teil des Textes markieren und Kommentare hinterlassen k\u00f6nnen. Aus technischer Sicht f\u00fcgt die Funktion drei weitere Abschnitte hinzu: Aktualisierungen f\u00fcr den Textk\u00f6rper, ein neues XRef-Verzeichnis und einen neuen Trailer. Dadurch ist es m\u00f6glich, die Sichtweise der Objekte f\u00fcr den Benutzer zu \u00e4ndern und neue Inhalte hinzuzuf\u00fcgen. Im Wesentlichen ist eine digitale Signatur auch eine inkrementelle Aktualisierung, die der Datei ein weiteres Element und entsprechende Abschnitte hinzuf\u00fcgt.<\/p>\n
Incremental Saving Attack (ISA)<\/h2>\n![\"Das](\"https:\/\/media.kasperskydaily.com\/wp-content\/uploads\/sites\/96\/2020\/01\/16134140\/36C3-PDF-digital-signature-2.png\")
<\/a>Das Hinzuf\u00fcgen eines inkrementellen Updates<\/p><\/div>\n
Zun\u00e4chst versuchte das Team, der Datei mit einem weiteren inkrementellen Update mithilfe eines Texteditors zus\u00e4tzliche Abschnitte hinzuzuf\u00fcgen. Streng genommen ist das kein Angriff \u2013 das Team hat einfach eine Funktion verwendet, die von den Erstellern des Formats implementiert wurde. Wenn ein Benutzer eine Datei \u00f6ffnet, die auf diese Weise ge\u00e4ndert wurde, zeigt der PDF-Reader normalerweise eine Meldung an, dass die digitale Signatur g\u00fcltig ist, das Dokument jedoch ge\u00e4ndert wurde. Nicht die aufschlussreichste Nachricht, vor allem nicht f\u00fcr einen unerfahrenen Benutzer. Schlimmer noch, einer der PDF-Viewer (LibreOffice) zeigte die Nachricht nicht einmal an.<\/p>\n
Das n\u00e4chste Experiment umfasste das Entfernen der beiden letzten Abschnitte (d. H. das Hinzuf\u00fcgen eines Updates zum Body, aber nicht der neuen XRef und des neuen Trailers). Einige Anwendungen haben sich geweigert, mit einer solchen Datei zu arbeiten. Zwei PDF-Viewer haben das Fehlen der Abschnitte erkannt und diese automatisch hinzugef\u00fcgt, ohne den Leser \u00fcber eine \u00c4nderung des Inhalts zu benachrichtigen. Drei andere \u00f6ffneten die Datei ohne jeglichen Widerspruch.<\/p>\n
Als N\u00e4chstes fragten sich die Forscher, was passieren w\u00fcrde, wenn sie die digitale Signatur einfach in ihr eigenes \u201emanuelles\u201c Update kopieren w\u00fcrden. Zwei weitere Programme wurden hereingelegt \u2013 Foxit und MasterPDF.<\/p>\n
Insgesamt erwiesen sich 11 der 22 PDF-Viewer als anf\u00e4llig f\u00fcr diese einfachen Manipulationen. Au\u00dferdem gaben sechs von ihnen keinerlei Warnsignal, dass das zum Anzeigen ge\u00f6ffnete Dokument ge\u00e4ndert wurde. In den anderen f\u00fcnf F\u00e4llen musste der Benutzer das Men\u00fc aufrufen und die G\u00fcltigkeit der digitalen Signatur manuell \u00fcberpr\u00fcfen, um Manipulationen zu erkennen. Das einfache \u00d6ffnen der der Datei war nicht ausreichend.<\/p>\n
Signature Wrapping Attack (SWA)<\/h2>\n![\"Das](\"https:\/\/media.kasperskydaily.com\/wp-content\/uploads\/sites\/96\/2020\/01\/16134759\/36C3-PDF-digital-signature-3.png\")
<\/a>Das Hinzuf\u00fcgen einer digitalen Signatur<\/p><\/div>\n
Durch das Signieren eines Dokuments werden dem Body zwei wichtige Felder als inkrementelle Aktualisierung hinzugef\u00fcgt: \u201e\/ Contents\u201c (enth\u00e4lt die Signatur) und \u201e\/ ByteRange\u201c (die genaue Beschreibung dar\u00fcber, was eigentlich signiert wurde). Bei der Byterange handelt es sich um vier Parameter, die 1. den Dateianfang definieren, 2. die Anzahl der Bytes vor dem Signaturcode z\u00e4hlen, 3. einen Byte zur Verdeutlichung des Signaturendes definieren, und 4. die Anzahl der Bytes nach der Signatur z\u00e4hlen, da die digitale Signatur eine Zeichenfolge ist, die kryptografisch aus dem Code des PDF-Dokuments erzeugt wurde. Nat\u00fcrlich kann sich die Signatur nicht selbst signieren, daher wird der Bereich, in dem sie gespeichert ist, von der Signaturberechnung ausgeschlossen.<\/p>\n
Die Forscher versuchten, unmittelbar nach der Signatur ein weiteres \u201e\/ ByteRange\u201c Feld hinzuzuf\u00fcgen. Die ersten beiden Werte blieben unver\u00e4ndert, lediglich die Stelle des Endes des Signaturcodes wurde ge\u00e4ndert. Damit schaffte man einen zus\u00e4tzlichen Bereich in der Datei, in dem man b\u00f6sartige Objekte hinzuf\u00fcgen kann, sowie einen beschreibenden XRef-Abschnitt. Theoretisch w\u00fcrde der PDF-Viewer die neuen Abschnitte nicht richtig lesen, wenn die PDF richtig gelesen werden, wenn die PDF richtig verarbeitet werden w\u00fcrde. 17 der 22 Anwendungen waren jedoch f\u00fcr einen solchen Angriff anf\u00e4llig.<\/p>\n
Universelle Signaturf\u00e4lschung (USF)<\/h2>\n
Aus gutem Grund hat das Forschungsteam die Anwendungen einem Stresstest unterzogen. Hierbei versucht man die Werte von Feldern durch falsche zu ersetzen oder sie einfach zu l\u00f6schen. Beim Experimentieren mit dem Abschnitt \u201e\/ Contents\u201c stellte sich heraus, dass zwei Viewer die tats\u00e4chliche Signatur noch validierten, nachdem sie durch den Wert 0x00 ersetzt wurde.<\/p>\n
Und was w\u00e4re, wenn die Signatur an Ort und Stelle belassen w\u00fcrde, aber der Abschnitt \u201e\/ ByteRange (Informationen dar\u00fcber, was genau signiert wurde) gel\u00f6scht w\u00fcrde? Oder anstelle von realen Werten lediglich eine Null eingef\u00fcgt w\u00fcrde? In beiden F\u00e4llen haben einige Viewer eine solche Signatur validiert.<\/p>\n
Insgesamt wurden in 4 der 22 Programme Implementierungsfehler festgestellt, die ausgenutzt werden konnten.<\/p>\n
Die zusammenfassende Ergebnistabelle zeigt, dass nicht weniger als 21 der 22 PDF-Viewer hinters Licht gef\u00fchrt werden konnten. Das hei\u00dft, f\u00fcr alle bis auf einen von ihnen ist es m\u00f6glich, eine PDF-Datei mit b\u00f6swilligem Inhalt oder falschen Informationen zu erstellen, die f\u00fcr den Benutzer g\u00fcltig erscheinen.<\/p>\n
<\/a>Struktur einer PDF-Datei<\/p><\/div>\n
Zun\u00e4chst ein paar Worte zum PDF-Format selbst. Jede Datei besteht aus vier Hauptteilen: Header (dt. Kopfzeile), die die PDF-Version anzeigt; Body (dt. Textk\u00f6rper), der den Hauptinhalt widerspiegelt; XRef-Table, ein Verzeichnis, in dem die Objekte im Textk\u00f6rper und ihre Positionen aufgelistet sind (zum Anzeigen des Inhalts); und Trailer, mit dem PDF-Viewer das Dokument lesen. Der Trailer enth\u00e4lt zwei wichtige Parameter, die dem Programm mitteilen, wo mit der Verarbeitung der Datei begonnen werden soll und wo der Xref-Abschnitt beginnt.<\/p>\n
Im PDF-Format ist eine inkrementelle Update-Funktion integriert, mit der die Benutzer beispielsweise einen Teil des Textes markieren und Kommentare hinterlassen k\u00f6nnen. Aus technischer Sicht f\u00fcgt die Funktion drei weitere Abschnitte hinzu: Aktualisierungen f\u00fcr den Textk\u00f6rper, ein neues XRef-Verzeichnis und einen neuen Trailer. Dadurch ist es m\u00f6glich, die Sichtweise der Objekte f\u00fcr den Benutzer zu \u00e4ndern und neue Inhalte hinzuzuf\u00fcgen. Im Wesentlichen ist eine digitale Signatur auch eine inkrementelle Aktualisierung, die der Datei ein weiteres Element und entsprechende Abschnitte hinzuf\u00fcgt.<\/p>\n
Incremental Saving Attack (ISA)<\/h2>\n<\/a>Das Hinzuf\u00fcgen eines inkrementellen Updates<\/p><\/div>\n
Zun\u00e4chst versuchte das Team, der Datei mit einem weiteren inkrementellen Update mithilfe eines Texteditors zus\u00e4tzliche Abschnitte hinzuzuf\u00fcgen. Streng genommen ist das kein Angriff \u2013 das Team hat einfach eine Funktion verwendet, die von den Erstellern des Formats implementiert wurde. Wenn ein Benutzer eine Datei \u00f6ffnet, die auf diese Weise ge\u00e4ndert wurde, zeigt der PDF-Reader normalerweise eine Meldung an, dass die digitale Signatur g\u00fcltig ist, das Dokument jedoch ge\u00e4ndert wurde. Nicht die aufschlussreichste Nachricht, vor allem nicht f\u00fcr einen unerfahrenen Benutzer. Schlimmer noch, einer der PDF-Viewer (LibreOffice) zeigte die Nachricht nicht einmal an.<\/p>\n
Das n\u00e4chste Experiment umfasste das Entfernen der beiden letzten Abschnitte (d. H. das Hinzuf\u00fcgen eines Updates zum Body, aber nicht der neuen XRef und des neuen Trailers). Einige Anwendungen haben sich geweigert, mit einer solchen Datei zu arbeiten. Zwei PDF-Viewer haben das Fehlen der Abschnitte erkannt und diese automatisch hinzugef\u00fcgt, ohne den Leser \u00fcber eine \u00c4nderung des Inhalts zu benachrichtigen. Drei andere \u00f6ffneten die Datei ohne jeglichen Widerspruch.<\/p>\n
Als N\u00e4chstes fragten sich die Forscher, was passieren w\u00fcrde, wenn sie die digitale Signatur einfach in ihr eigenes \u201emanuelles\u201c Update kopieren w\u00fcrden. Zwei weitere Programme wurden hereingelegt \u2013 Foxit und MasterPDF.<\/p>\n
Insgesamt erwiesen sich 11 der 22 PDF-Viewer als anf\u00e4llig f\u00fcr diese einfachen Manipulationen. Au\u00dferdem gaben sechs von ihnen keinerlei Warnsignal, dass das zum Anzeigen ge\u00f6ffnete Dokument ge\u00e4ndert wurde. In den anderen f\u00fcnf F\u00e4llen musste der Benutzer das Men\u00fc aufrufen und die G\u00fcltigkeit der digitalen Signatur manuell \u00fcberpr\u00fcfen, um Manipulationen zu erkennen. Das einfache \u00d6ffnen der der Datei war nicht ausreichend.<\/p>\n
Signature Wrapping Attack (SWA)<\/h2>\n<\/a>Das Hinzuf\u00fcgen einer digitalen Signatur<\/p><\/div>\n
Durch das Signieren eines Dokuments werden dem Body zwei wichtige Felder als inkrementelle Aktualisierung hinzugef\u00fcgt: \u201e\/ Contents\u201c (enth\u00e4lt die Signatur) und \u201e\/ ByteRange\u201c (die genaue Beschreibung dar\u00fcber, was eigentlich signiert wurde). Bei der Byterange handelt es sich um vier Parameter, die 1. den Dateianfang definieren, 2. die Anzahl der Bytes vor dem Signaturcode z\u00e4hlen, 3. einen Byte zur Verdeutlichung des Signaturendes definieren, und 4. die Anzahl der Bytes nach der Signatur z\u00e4hlen, da die digitale Signatur eine Zeichenfolge ist, die kryptografisch aus dem Code des PDF-Dokuments erzeugt wurde. Nat\u00fcrlich kann sich die Signatur nicht selbst signieren, daher wird der Bereich, in dem sie gespeichert ist, von der Signaturberechnung ausgeschlossen.<\/p>\n
Die Forscher versuchten, unmittelbar nach der Signatur ein weiteres \u201e\/ ByteRange\u201c Feld hinzuzuf\u00fcgen. Die ersten beiden Werte blieben unver\u00e4ndert, lediglich die Stelle des Endes des Signaturcodes wurde ge\u00e4ndert. Damit schaffte man einen zus\u00e4tzlichen Bereich in der Datei, in dem man b\u00f6sartige Objekte hinzuf\u00fcgen kann, sowie einen beschreibenden XRef-Abschnitt. Theoretisch w\u00fcrde der PDF-Viewer die neuen Abschnitte nicht richtig lesen, wenn die PDF richtig gelesen werden, wenn die PDF richtig verarbeitet werden w\u00fcrde. 17 der 22 Anwendungen waren jedoch f\u00fcr einen solchen Angriff anf\u00e4llig.<\/p>\n
Universelle Signaturf\u00e4lschung (USF)<\/h2>\n
Aus gutem Grund hat das Forschungsteam die Anwendungen einem Stresstest unterzogen. Hierbei versucht man die Werte von Feldern durch falsche zu ersetzen oder sie einfach zu l\u00f6schen. Beim Experimentieren mit dem Abschnitt \u201e\/ Contents\u201c stellte sich heraus, dass zwei Viewer die tats\u00e4chliche Signatur noch validierten, nachdem sie durch den Wert 0x00 ersetzt wurde.<\/p>\n
Und was w\u00e4re, wenn die Signatur an Ort und Stelle belassen w\u00fcrde, aber der Abschnitt \u201e\/ ByteRange (Informationen dar\u00fcber, was genau signiert wurde) gel\u00f6scht w\u00fcrde? Oder anstelle von realen Werten lediglich eine Null eingef\u00fcgt w\u00fcrde? In beiden F\u00e4llen haben einige Viewer eine solche Signatur validiert.<\/p>\n
Insgesamt wurden in 4 der 22 Programme Implementierungsfehler festgestellt, die ausgenutzt werden konnten.<\/p>\n
Die zusammenfassende Ergebnistabelle zeigt, dass nicht weniger als 21 der 22 PDF-Viewer hinters Licht gef\u00fchrt werden konnten. Das hei\u00dft, f\u00fcr alle bis auf einen von ihnen ist es m\u00f6glich, eine PDF-Datei mit b\u00f6swilligem Inhalt oder falschen Informationen zu erstellen, die f\u00fcr den Benutzer g\u00fcltig erscheinen.<\/p>\n
<\/a>Das Hinzuf\u00fcgen eines inkrementellen Updates<\/p><\/div>\n
Zun\u00e4chst versuchte das Team, der Datei mit einem weiteren inkrementellen Update mithilfe eines Texteditors zus\u00e4tzliche Abschnitte hinzuzuf\u00fcgen. Streng genommen ist das kein Angriff \u2013 das Team hat einfach eine Funktion verwendet, die von den Erstellern des Formats implementiert wurde. Wenn ein Benutzer eine Datei \u00f6ffnet, die auf diese Weise ge\u00e4ndert wurde, zeigt der PDF-Reader normalerweise eine Meldung an, dass die digitale Signatur g\u00fcltig ist, das Dokument jedoch ge\u00e4ndert wurde. Nicht die aufschlussreichste Nachricht, vor allem nicht f\u00fcr einen unerfahrenen Benutzer. Schlimmer noch, einer der PDF-Viewer (LibreOffice) zeigte die Nachricht nicht einmal an.<\/p>\n
Das n\u00e4chste Experiment umfasste das Entfernen der beiden letzten Abschnitte (d. H. das Hinzuf\u00fcgen eines Updates zum Body, aber nicht der neuen XRef und des neuen Trailers). Einige Anwendungen haben sich geweigert, mit einer solchen Datei zu arbeiten. Zwei PDF-Viewer haben das Fehlen der Abschnitte erkannt und diese automatisch hinzugef\u00fcgt, ohne den Leser \u00fcber eine \u00c4nderung des Inhalts zu benachrichtigen. Drei andere \u00f6ffneten die Datei ohne jeglichen Widerspruch.<\/p>\n
Als N\u00e4chstes fragten sich die Forscher, was passieren w\u00fcrde, wenn sie die digitale Signatur einfach in ihr eigenes \u201emanuelles\u201c Update kopieren w\u00fcrden. Zwei weitere Programme wurden hereingelegt \u2013 Foxit und MasterPDF.<\/p>\n
Insgesamt erwiesen sich 11 der 22 PDF-Viewer als anf\u00e4llig f\u00fcr diese einfachen Manipulationen. Au\u00dferdem gaben sechs von ihnen keinerlei Warnsignal, dass das zum Anzeigen ge\u00f6ffnete Dokument ge\u00e4ndert wurde. In den anderen f\u00fcnf F\u00e4llen musste der Benutzer das Men\u00fc aufrufen und die G\u00fcltigkeit der digitalen Signatur manuell \u00fcberpr\u00fcfen, um Manipulationen zu erkennen. Das einfache \u00d6ffnen der der Datei war nicht ausreichend.<\/p>\n
Signature Wrapping Attack (SWA)<\/h2>\n<\/a>Das Hinzuf\u00fcgen einer digitalen Signatur<\/p><\/div>\n
Durch das Signieren eines Dokuments werden dem Body zwei wichtige Felder als inkrementelle Aktualisierung hinzugef\u00fcgt: \u201e\/ Contents\u201c (enth\u00e4lt die Signatur) und \u201e\/ ByteRange\u201c (die genaue Beschreibung dar\u00fcber, was eigentlich signiert wurde). Bei der Byterange handelt es sich um vier Parameter, die 1. den Dateianfang definieren, 2. die Anzahl der Bytes vor dem Signaturcode z\u00e4hlen, 3. einen Byte zur Verdeutlichung des Signaturendes definieren, und 4. die Anzahl der Bytes nach der Signatur z\u00e4hlen, da die digitale Signatur eine Zeichenfolge ist, die kryptografisch aus dem Code des PDF-Dokuments erzeugt wurde. Nat\u00fcrlich kann sich die Signatur nicht selbst signieren, daher wird der Bereich, in dem sie gespeichert ist, von der Signaturberechnung ausgeschlossen.<\/p>\n
Die Forscher versuchten, unmittelbar nach der Signatur ein weiteres \u201e\/ ByteRange\u201c Feld hinzuzuf\u00fcgen. Die ersten beiden Werte blieben unver\u00e4ndert, lediglich die Stelle des Endes des Signaturcodes wurde ge\u00e4ndert. Damit schaffte man einen zus\u00e4tzlichen Bereich in der Datei, in dem man b\u00f6sartige Objekte hinzuf\u00fcgen kann, sowie einen beschreibenden XRef-Abschnitt. Theoretisch w\u00fcrde der PDF-Viewer die neuen Abschnitte nicht richtig lesen, wenn die PDF richtig gelesen werden, wenn die PDF richtig verarbeitet werden w\u00fcrde. 17 der 22 Anwendungen waren jedoch f\u00fcr einen solchen Angriff anf\u00e4llig.<\/p>\n
Universelle Signaturf\u00e4lschung (USF)<\/h2>\n
Aus gutem Grund hat das Forschungsteam die Anwendungen einem Stresstest unterzogen. Hierbei versucht man die Werte von Feldern durch falsche zu ersetzen oder sie einfach zu l\u00f6schen. Beim Experimentieren mit dem Abschnitt \u201e\/ Contents\u201c stellte sich heraus, dass zwei Viewer die tats\u00e4chliche Signatur noch validierten, nachdem sie durch den Wert 0x00 ersetzt wurde.<\/p>\n
Und was w\u00e4re, wenn die Signatur an Ort und Stelle belassen w\u00fcrde, aber der Abschnitt \u201e\/ ByteRange (Informationen dar\u00fcber, was genau signiert wurde) gel\u00f6scht w\u00fcrde? Oder anstelle von realen Werten lediglich eine Null eingef\u00fcgt w\u00fcrde? In beiden F\u00e4llen haben einige Viewer eine solche Signatur validiert.<\/p>\n
Insgesamt wurden in 4 der 22 Programme Implementierungsfehler festgestellt, die ausgenutzt werden konnten.<\/p>\n
Die zusammenfassende Ergebnistabelle zeigt, dass nicht weniger als 21 der 22 PDF-Viewer hinters Licht gef\u00fchrt werden konnten. Das hei\u00dft, f\u00fcr alle bis auf einen von ihnen ist es m\u00f6glich, eine PDF-Datei mit b\u00f6swilligem Inhalt oder falschen Informationen zu erstellen, die f\u00fcr den Benutzer g\u00fcltig erscheinen.<\/p>\n
<\/a>Das Hinzuf\u00fcgen einer digitalen Signatur<\/p><\/div>\n
Durch das Signieren eines Dokuments werden dem Body zwei wichtige Felder als inkrementelle Aktualisierung hinzugef\u00fcgt: \u201e\/ Contents\u201c (enth\u00e4lt die Signatur) und \u201e\/ ByteRange\u201c (die genaue Beschreibung dar\u00fcber, was eigentlich signiert wurde). Bei der Byterange handelt es sich um vier Parameter, die 1. den Dateianfang definieren, 2. die Anzahl der Bytes vor dem Signaturcode z\u00e4hlen, 3. einen Byte zur Verdeutlichung des Signaturendes definieren, und 4. die Anzahl der Bytes nach der Signatur z\u00e4hlen, da die digitale Signatur eine Zeichenfolge ist, die kryptografisch aus dem Code des PDF-Dokuments erzeugt wurde. Nat\u00fcrlich kann sich die Signatur nicht selbst signieren, daher wird der Bereich, in dem sie gespeichert ist, von der Signaturberechnung ausgeschlossen.<\/p>\n
Die Forscher versuchten, unmittelbar nach der Signatur ein weiteres \u201e\/ ByteRange\u201c Feld hinzuzuf\u00fcgen. Die ersten beiden Werte blieben unver\u00e4ndert, lediglich die Stelle des Endes des Signaturcodes wurde ge\u00e4ndert. Damit schaffte man einen zus\u00e4tzlichen Bereich in der Datei, in dem man b\u00f6sartige Objekte hinzuf\u00fcgen kann, sowie einen beschreibenden XRef-Abschnitt. Theoretisch w\u00fcrde der PDF-Viewer die neuen Abschnitte nicht richtig lesen, wenn die PDF richtig gelesen werden, wenn die PDF richtig verarbeitet werden w\u00fcrde. 17 der 22 Anwendungen waren jedoch f\u00fcr einen solchen Angriff anf\u00e4llig.<\/p>\n
Universelle Signaturf\u00e4lschung (USF)<\/h2>\n
Aus gutem Grund hat das Forschungsteam die Anwendungen einem Stresstest unterzogen. Hierbei versucht man die Werte von Feldern durch falsche zu ersetzen oder sie einfach zu l\u00f6schen. Beim Experimentieren mit dem Abschnitt \u201e\/ Contents\u201c stellte sich heraus, dass zwei Viewer die tats\u00e4chliche Signatur noch validierten, nachdem sie durch den Wert 0x00 ersetzt wurde.<\/p>\n
Und was w\u00e4re, wenn die Signatur an Ort und Stelle belassen w\u00fcrde, aber der Abschnitt \u201e\/ ByteRange (Informationen dar\u00fcber, was genau signiert wurde) gel\u00f6scht w\u00fcrde? Oder anstelle von realen Werten lediglich eine Null eingef\u00fcgt w\u00fcrde? In beiden F\u00e4llen haben einige Viewer eine solche Signatur validiert.<\/p>\n
Insgesamt wurden in 4 der 22 Programme Implementierungsfehler festgestellt, die ausgenutzt werden konnten.<\/p>\n
Die zusammenfassende Ergebnistabelle zeigt, dass nicht weniger als 21 der 22 PDF-Viewer hinters Licht gef\u00fchrt werden konnten. Das hei\u00dft, f\u00fcr alle bis auf einen von ihnen ist es m\u00f6glich, eine PDF-Datei mit b\u00f6swilligem Inhalt oder falschen Informationen zu erstellen, die f\u00fcr den Benutzer g\u00fcltig erscheinen.<\/p>\n
![\"\u00dcbersicht](\"https:\/\/media.kasperskydaily.com\/wp-content\/uploads\/sites\/96\/2020\/01\/16135121\/36C3-PDF-digital-signature-4.png\")
<\/a>