De taak van de onderzoekers was eenvoudig: proberen om de inhoud van een ondertekend pdf-bestand te wijzigen zonder dat de handtekening daarbij ongeldig werd. In principe zouden cybercriminelen hetzelfde kunnen doen om valse informatie te verspreiden of schadelijke content aan een ondertekend bestand toe te voegen. Klanten die een ondertekend document van een bank ontvangen zijn tenslotte eerder geneigd om dit te vertrouwen en op links in het bestand te klikken.<\/p>\n
Het team selecteerde 22 populaire pdf-viewers voor verschillende platformen, en gingen systematisch te werk met de resultaten van hun experimenten.<\/p>\n
Structuur van een pdf-bestand<\/h2>\n
llereerst bieden we wat meer informatie over het pdf-formaat. Elk bestand bestaat uit vier hoofdonderdelen: de header die de ![\"\"](\"https:\/\/media.kasperskydaily.com\/wp-content\/uploads\/sites\/99\/2020\/01\/16171606\/36C3-PDF-digital-signature-1.png\")
pdf-versie toont; de body (tekstinhoud) met de belangrijkste content die de gebruiker ziet; de Xref-sectie, een lijst die de voorwerpen in de tekstinhoud en hun locatie opsomt (voor het weergeven van de content); en de trailer, waar de pdf-viewers mee starten om het document te lezen. De trailer bevat twee belangrijke parameters die het programma vertellen waar er moet worden begonnen met het verwerken van het bestand, en waar de Xref-sectie begint.<\/p>\n
Er is een incrementele update-functie in het formaat ge\u00efntegreerd die de gebruiker in staat stelt om bijvoorbeeld een gedeelte van de tekst te markeren en opmerkingen toe te voegen. Vanuit een technisch oogpunt voegt deze functie nog drie secties toe: updates voor de body, een nieuwe Xref-lijst en een nieuwe trailer. Dat zorgt ervoor dat het inderdaad mogelijk is om te veranderen hoe de objecten door de gebruiker gezien worden, \u00e9n om nieuwe content toe te voegen. Eigenlijk is een digitale handtekening ook een incrementele update, waardoor er nog een element en daarbij de corresponderende secties aan het bestand worden toegevoegd.<\/p>\n
Incremental saving attack (ISA)<\/h2>\n
erst probeerde het team om extra secties aan het bestand toe te voegen met een andere incrementele update met gebruik van![\"\"](\"https:\/\/media.kasperskydaily.com\/wp-content\/uploads\/sites\/99\/2020\/01\/16172458\/36C3-PDF-digital-signature-2.png\")
een teksteditor. Strikt gezien is dat geen aanval, want het team gebruikte simpelweg een functie die was ge\u00efmplementeerd door de makers van het formaat. Als een gebruiker een bestand opent dat op deze manier is gewijzigd, geeft de pdf-reader normaal gesproken een melding weer waarin staat dat de digitale handtekening geldig is, maar dat het document is gewijzigd. Niet het meest verhelderende bericht, vooral niet voor een onervaren gebruiker. En wat erger is: een van de pdf-viewers (LibreOffice) toonde dat bericht niet eens.<\/p>\n
Het volgende experiment omvatte het verwijderen van de laatste twee secties (dus het toevoegen van een update aan de body, maar niet de nieuwe Xref en trailer). Sommige applicaties weigerden om met zo\u2019n bestand te werken. Twee pdf-viewers zagen dat de secties ontbraken en voegden ze automatisch toe zonder de lezer op de hoogte te stellen van een wijziging in de inhoud. Drie andere slikten het bestand zonder enig bezwaar.<\/p>\n
Vervolgens vroegen de onderzoekers zich af wat er zou gebeuren als ze de digitale handtekening simpelweg zouden kopi\u00ebren naar hun eigen \u201chandmatige\u201d update. Daar vielen nog twee viewers voor: Foxit en MasterPDF.<\/p>\n
In het totaal bleken 11 van de 22 pdf-viewers kwetsbaar te zijn voor deze eenvoudige manipulaties. Bovendien toonden zes daarvan zelfs geen enkele tekenen van het feit dat het geopende document gewijzigd was. In de andere vijf gevallen moest de gebruiker naar het menu gaan om tekenen van manipulatie te onthullen, en daar handmatig kijken naar de geldigheid van de digitale handtekening; het eenvoudigweg openen van het bestand was niet voldoende.<\/p>\n
Signature wrapping attack (SWA)<\/h2>\n
Het ondertekenen van een document voegt twee belangrijke velden als incrementele update aan de body toe: \/Contents, wat de ![\"\"](\"https:\/\/media.kasperskydaily.com\/wp-content\/uploads\/sites\/99\/2020\/01\/16172520\/36C3-PDF-digital-signature-3.png\")
handtekening bevat, en \/ByteRange, wat beschrijft wat er precies ondertekend is. In de laatste zitten vier parameters \u2014 om de start van het bestand te defini\u00ebren, het aantal bytes v\u00f3\u00f3r de handtekeningcode, een byte die bepaalt waar de handtekeningcode eindigt, en het aantal bytes na de handtekening \u2014 omdat de digitale handtekening een reeks tekens is die is gegenereerd door cryptografische middelen van de code van het pdf-document. De handtekening kan zichzelf natuurlijk niet ondertekenen, dus het gebied waar deze is opgeslagen, is uitgesloten van het handtekeningberekeningsproces.<\/p>\n
De onderzoekers probeerden om nog een \/ByteRange-veld vlak na de handtekening toe te voegen. De eerste twee waarden hierin bleven ongewijzigd, alleen het adres van het einde van de handtekeningcode werd aangepast. Het resultaat was het verschijnen van een extra spatie in het bestand waar schadelijke objecten konden worden toegevoegd, evenals de Xref-sectie die ze beschreef. In theorie zou de pdf-viewer, als het bestand correct zou worden gelezen, deze sectie niet bereiken. Maar 17 van de 22 applicaties waren kwetsbaar voor zo\u2019n aanval.<\/p>\n
\u00a0<\/p>\n
Universal signature forgery (USF)<\/h2>\n
Voor de zekerheid besloot het onderzoeksteam de applicaties ook te testen op een standaard pentesting-truc waarbij er een poging wordt gedaan om de waarden van de velden in onjuiste waarden te veranderen of deze simpelweg te verwijderen. Tijdens het experimenteren met de \/Contents-sectie, bleek dat als er een echte handtekening werd vervangen met de waarde 0x00, twee van de viewers deze nog altijd valideerden.<\/p>\n
En wat als de handtekening met rust werd gelaten, maar de \/ByteRange-sectie (dus de informatie over wat er precies is ondertekend) verwijderd werd? Of er een nul werd ingevoegd in plaats van echte waarden? In beide gevallen waren er een aantal viewers die zo\u2019n handtekening alsnog valideerden.<\/p>\n
In het totaal bleek dat 4 van de 22 programma\u2019s implementatiefouten bevatten die benut zouden kunnen worden.<\/p>\n
De tabel met een samenvatting van de resultaten laat zien dat maar liefst 21 van de 22 pdf-viewers om de tuin geleid konden worden. Dat betekent dus dat het voor alle viewers behalve \u00e9\u00e9n mogelijk is om een pdf-bestand te cre\u00ebren dat schadelijke of onjuiste informatie bevat maar er wel geldig uitziet voor de gebruiker.<\/p>\n
![\"Overzichtstabel](\"https:\/\/media.kasperskydaily.com\/wp-content\/uploads\/sites\/99\/2020\/01\/16172549\/36C3-PDF-digital-signature-4.png\")
<\/a>