PDF generation as an attack vector: from input field to server secrets
In What the Hack, Wesley, an ethical hacker at The S-Unit, shares a real-world example from an anonymous penetration test. A vulnerability in a PDF generator opened the door to sensitive server data.
How could this vulnerability be exploited, and what can you as a developer do to close off this attack path?
First contact: PDF generator with potential
With a few well-established security principles in mind, I started a penetration test on an application handling highly sensitive and private personal data. My first step was to explore the application, understand the developers’ intent, and identify where design choices might unintentionally allow exploitation.
The application enabled users to complete questionnaires, share meeting notes between two trusted parties, and generate PDF reports. When I noticed that last feature, it immediately caught my attention. PDF generation often expands the attack surface, so I decided to take a closer look. I tested all input fields to see whether I could visibly inject HTML into the generated PDF.
Jackpot: improper user sanitization
Jackpot! When reviewing the questionnaire responses, one thing immediately stood out: the input was not sanitized. My test payload appeared in bold in the PDF without any issues. I conduct much of my testing using PortSwigger’s Burp Suite, a powerful tool for uncovering the inner workings of a web application. This was already a clear finding—but I continued to make the real impact visible.
We’re getting somewhere!
Digging deeper: escalation through unknown functionality
Public libraries speed up development, but sometimes introduce unnoticed attack paths. The PDF generator used by the client turned out to be extensively documented. Its accompanying wiki clearly described the available features, quickly revealing the library’s capabilities, even while the application itself was still largely unexplored.
Local file read via PDF-generation
In the documentation of the PDF generator, I discovered a feature that allowed attachments to be added to a generated PDF. This functionality enabled references to local files via a file:// handler. To gain more insight into the underlying system, I attempted to read a well-known Linux file with general read permissions using the right payload. Sure enough, after generating the PDF, the file was attached. The resulting document contained a copy of the server’s password file as an attachment.
A turning point in the investigation
This marked a clear turning point in the investigation. With read access to local files, I could immediately examine the configuration of the server running the PDF generator. The password file already provided an initial indication of the users and the privileges under which the process was running. This raised the next set of questions: what exact privileges did this process have, and what additional information became accessible now that I could read files?
All the juicy stuff! (principle of least privileges)
Development teams often store sensitive information such as secrets, keys, and passwords in environment variables. The process responsible for generating PDFs turned out to be running as root, which gave me read access to environ, where these variables are stored. Because the PDF generator process was granted overly broad privileges, this provided insight into credentials for, among other things, Keycloak, databases, Amazon S3 buckets, and multiple internal systems.
Lessons learned: where do you close off this attack path?
How can you prevent this attack? With a few targeted decisions, this attack path could have been closed off early on.
- Limit the scope of user input
Ensure that input does not gain special or executable meaning within the context in which it is processed, such as PDF generation. - Be critical of third-party libraries
Review which functionality a library includes and disable any components you do not explicitly need. - Apply the principle of least privilege consistently
Grant processes and services access only to the data and functionality that are strictly necessary. - Isolate supporting components
A PDF generator, for example, does not need access to the local file system. By blocking this access, you reduce the risk that a single flaw directly results in a data breach.
Looking to gain insight into the security of your IT environment? Learn more about our Pentesting and Red teaming services.
