PDF-generatie als aanvalspad: van inputveld tot server secrets
In ‘What The Hack’ deelt Wesley, ethisch hacker bij The S-Unit, een praktijkvoorbeeld uit een anonieme penetratietest. Een kwetsbaarheid in de PDF-generator opende de deur naar gevoelige servergegevens.
Hoe kon deze kwetsbaarheid worden misbruikt en wat kun je als developer doen om dit aanvalspad te sluiten?
First contact: PDF-generatie met potentie
Met een paar bekende securityprincipes in het achterhoofd begon ik aan een penetratietest op een applicatie die zeer gevoelige en privé persoonsgegevens verwerkte. Mijn eerste stap was: de applicatie verkennen, de intentie van de developers begrijpen en vaststellen waar ontwerpkeuzes mogelijk ruimte lieten voor misbruik.
De applicatie stelde gebruikers in staat om questionnaires in te vullen, meeting notes te delen tussen twee vertrouwde partijen en PDF-rapporten te genereren. Toen ik die laatste functionaliteit zag, ging ik direct rechtop zitten. PDF-generatie vergroot vaak het aanvalsoppervlak en nodigde mij uit tot verder onderzoek. Ik nam alle inputvelden onder handen en testte of ik HTML zichtbaar kon injecteren in de gegenereerde PDF.
Jackpot: improper user sanitization
Jackpot! Bij het bekijken van de antwoorden uit de questionnaire viel mij direct op: de input werd niet gesanitized. Mijn testpayload, niets meer dan een eenvoudig HTML element, verscheen zonder problemen vetgedrukt in de PDF. Veel van mijn testing doe ik met PortSwigger’s Burp Suite, een geweldige tool om de inner workings van een web applicatie te identificeren. Dit was al een duidelijke finding. Toch ging ik verder om de daadwerkelijke impact zichtbaar te maken.
We komen ergens!
Digging deeper: escalatie door onbekende functionaliteiten
Public libraries versnellen development, maar introduceren soms onopgemerkte aanvalspaden. De PDF-generator die de klant gebruikte, bleek uitgebreid gedocumenteerd. In de bijbehorende wiki werden de beschikbare features helder beschreven. Die documentatie gaf snel inzicht in de mogelijkheden van de library, terwijl de applicatie zelf nog grotendeels onbekend was.
Local file read via PDF-generatie
In de documentatie van de PDF-generator ontdekte ik een feature waarmee ik attachments aan een gegenereerde PDF kon toevoegen. Die functionaliteit liet mij lokale bestanden refereren via een file:// handle. Om meer inzicht te verkrijgen in het achterliggende systeem, probeerde ik een breed bekend Linux bestand met algemene leesrechten uit te lezen met de payload <link rel=”attachment” href=”file:///etc/passwd”>. En ja hoor, na het genereren was het bestand toegevoegd. Hierin vond ik een kopie van /etc/passwd van de server terug als attachment.
Een kantelpunt in het onderzoek
Ik bereikte hier een duidelijk kantelpunt. Met leesrechten op lokale bestanden kon ik direct de configuratie van de server onderzoeken waarop de PDF-generator draaide. Het bestand /etc/passwd gaf daarbij al een eerste indicatie van de gebruikers en de rechten waaronder het proces actief was. De volgende onderzoeksvragen popte op: welke privileges had dit proces precies, en welke aanvullende informatie kwam beschikbaar nu ik bestanden kon uitlezen?
All the juicy stuff! (principle of least privileges)
Ontwikkelteams slaan gevoelige informatie zoals secrets, keys en wachtwoorden vaak op in environment variables. Het proces om de PDF te generen blijkt als ROOT te draaien waardoor ik leesrechten had op /etc/environ waarin deze variabelen staan opgeslagen. Doordat het PDF-generatorproces over te ruime rechten beschikte, kreeg ik zo inzicht in credentials voor onder andere Keycloak, databases, Amazon S3-buckets en meerdere interne systemen.
Lessons learned: waar sluit je dit aanvalspad af?
Hoe kun je deze aanval voorkomen? Met een paar gerichte keuzes was dit aanvalspad al vroeg afgesloten.
- Beperk de betekenis van user input
Zorg ervoor dat invoer geen speciale of uitvoerbare betekenis krijgt binnen de context waarin deze wordt verwerkt, zoals bij PDF-generatie. - Wees kritisch op third-party libraries
Controleer welke functionaliteit een library meebrengt en schakel onderdelen uit die je niet expliciet nodig hebt. - Pas het principle of least privilege consequent toe
Geef processen en services alleen toegang tot data en functionaliteit die strikt noodzakelijk is. - Isoleer ondersteunende componenten
Een PDF-generator hoeft bijvoorbeeld geen toegang te hebben tot het lokale file system. Door dit af te sluiten, voorkom je dat een fout direct leidt tot datalekken.
Wil je inzicht in de beveiliging van jouw IT? Lees meer over onze Pentesting en Red teaming diensten.
