Kunt u digitale handtekeningen in pdf-bestanden vertrouwen?

Er bestaat bijna geen enkele overheidsinstelling die geen pdf-bestanden gebruikt. En die gebruiken vaak digitale handtekeningen om de authenticiteit van dit soort documenten te waarborgen. Bij het openen van een ondertekend bestand in welke pdf-viewer dan ook, toont het programma een vlaggetje dat aangeeft dat het document ondertekend is, door wie, en het biedt toegang tot het menu voor de validering van de handtekening.

Een team van onderzoekers van verschillende Duitse universiteiten wilde de degelijkheid van zulke pdf-handtekeningen eens testen. Vladislav Mladenov van de Ruhr-Universität Bochum deelde de bevindingen van het team tijdens het Chaos Communication Congress (36С3).

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.

Het team selecteerde 22 populaire pdf-viewers voor verschillende platformen, en gingen systematisch te werk met de resultaten van hun experimenten.

Structuur van een pdf-bestand

llereerst bieden we wat meer informatie over het pdf-formaat. Elk bestand bestaat uit vier hoofdonderdelen: de header die de 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.

Er is een incrementele update-functie in het formaat geïntegreerd 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, én 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.

Incremental saving attack (ISA)

erst probeerde het team om extra secties aan het bestand toe te voegen met een andere incrementele update met gebruik van een teksteditor. Strikt gezien is dat geen aanval, want het team gebruikte simpelweg een functie die was geïmplementeerd 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.

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’n 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.

Vervolgens vroegen de onderzoekers zich af wat er zou gebeuren als ze de digitale handtekening simpelweg zouden kopiëren naar hun eigen “handmatige” update. Daar vielen nog twee viewers voor: Foxit en MasterPDF.

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.

Signature wrapping attack (SWA)

Het ondertekenen van een document voegt twee belangrijke velden als incrementele update aan de body toe: /Contents, wat de handtekening bevat, en /ByteRange, wat beschrijft wat er precies ondertekend is. In de laatste zitten vier parameters — om de start van het bestand te definiëren, het aantal bytes vóór de handtekeningcode, een byte die bepaalt waar de handtekeningcode eindigt, en het aantal bytes na de handtekening — 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.

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’n aanval.

Universal signature forgery (USF)

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.

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’n handtekening alsnog valideerden.

In het totaal bleek dat 4 van de 22 programma’s implementatiefouten bevatten die benut zouden kunnen worden.

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 één mogelijk is om een pdf-bestand te creëren dat schadelijke of onjuiste informatie bevat maar er wel geldig uitziet voor de gebruiker.

Overzichtstabel met kwetsbaarheden van pdf-viewers

Grappig genoeg was de enige applicatie die niet voor de trucs van het onderzoeksteam viel Adobe Reader 9. Het probleem is dat deze reader gevoelig is voor een RCE-kwetsbaarheid en alleen door Linux-gebruikers wordt gebruikt, eenvoudigweg omdat het de laatste versie is die voor hen beschikbaar is.

Praktische conclusies

Welke praktische conclusies kunnen we uit deze bevindingen trekken? Ten eerste moet niemand blindelings digitale handtekeningen in pdf-bestanden vertrouwen. Als u ergens een groen vinkje ziet, wil die niet per se zeggen dat de handtekening geldig is.

Ten tweede kan zelfs een ondertekend document een risico vormen. Dus zorg er vóór het openen van online ontvangen bestanden of het klikken op links in deze bestanden voor dat u een betrouwbaar beveiligingssysteem op uw computer hebt geïnstalleerd.