In the realm of cybersecurity, understanding vulnerabilities is paramount to safeguarding sensitive data and maintaining the integrity of systems. One such vulnerability that often lurks in the shadows is SSRF, or Server Side Request Forgery. While SSRF vulnerabilities have been extensively discussed in various contexts, today, we're going to delve into a unique perspective – exploring SSRF vulnerabilities through the lens of HTML to PDF exports.
What is an SSRF vulnerability?
Before we embark on our journey through PDF exports, let's briefly revisit what an SSRF vulnerability entails. Server Side Request Forgery (SSRF) is a type of security vulnerability that allows attackers to manipulate a web application's functionality to send unauthorized requests to internal resources. These requests can lead to unauthorized access to sensitive data, manipulation of systems, or even complete compromise of the targeted application.
HTML to PDF Exports: A Potential Breeding Ground for SSRF Vulnerabilities
HTML to PDF conversion tools serve as essential utilities for generating PDF documents from HTML and CSS content. However, the process of converting web content to PDF introduces potential security vulnerabilities, particularly when user-controlled input is involved.
As with any HTML and JavaScript page, the page that is rendered into a PDF may be vulnerable to cross-site scripting and HTML injection, attacks in which attacker-controlled JavaScript or HTML is injected into the page. The malicious code will then be executed on the server-side and the results are saved to the PDF that is sent to the user. Exploiting this vulnerability, attackers can scan, access, and control internal services, access sensitive server files, and potentially execute code.
One of our clients, a platform for doctors, was an obvious target of SSRF through PDFs. They had some initial vulnerabilities that raised our suspicion and it had generated the PDFs on the server-side, as they were sent in a request rather than generated using JavaScript on the browser.
Our team spent hours toying around with the report generation and all the different fields from which the PDF is generated. After days of searching with no luck, we found some obscure, hard-to-reach area that looked promising, it had XSS and was included in the PDF. After testing we confirmed that HTML and JavaScript are rendered in the PDF when the field is attacked:
Next, we tested for JavaScript execution by using "<img src=x onerror=document.write('test')>"
At this point, we knew we had something, and that we could start testing for SSRFs, LFI, and other fun stuff!
We go for the files on the server, first with requests from JavaScript, those fail because of the same origin policy, however, using iframes we can display any file on the server. After trying a few payloads, the Windows hosts file shows up in one of the iframes:
Looking at the hosts file, we find a few interesting internal addresses which we start scanning for open ports.
We first tried a few JavaScript port scanners, none of which worked and so we started spamming iframes. Since iframes do not need to abide by the same origin policy, there's no problem with other ports, protocols, and hosts!
We faced a few challenges along the way, but eventually got all the iframes to render the top 1,000 ports from Nmap of each host, including localhost in a single PDF. Most of the iframes are empty, but a select few show some interesting internal services:
Though this was considered already a complete takeover, we were not done yet.
This service was hosted on AWS, and you might not know this, but SSRFs on AWS can be very destructive. This is thanks to the meta-data service that every EC2 server has. If done right, the service will return the EC2 instance AWS credentials, which can be used to interact with the AWS account directly, escalate privileges, and potentially take over the AWS account.
With all this in mind, we accessed the AWS credentials:
This gave us a whole new area to attack and try our luck with. However, there was no such luck and the EC2 role we were given was completely useless and we couldn't access any information.
All in all, generating a PDF from an HTML page on the server is quite risky, especially when all the information in the report is available on the client-side.
Mitigating SSRF Risks in HTML to PDF Exports
To mitigate the risks posed by SSRF vulnerabilities in HTML to PDF exports, developers and security professionals must adopt a proactive approach to security.
Some strategies to consider:
Client-Side PDF Generation The best mitigation to server-side XSS in PDF generation is to move the generation to the client-side. For example, using jsPDF, the HTML on the client-side can be rendered into a PDF.
Input Validation Implement stringent input validation mechanisms to sanitize user-provided content and prevent malicious input from triggering unauthorized requests.
Whitelisting Maintain a whitelist of approved URLs or domains that the PDF renderer is permitted to access, thereby restricting requests to trusted sources and mitigating the risk of SSRF attacks.
Regular Security Tests Conduct regular security tests, including penetration testing and vulnerability assessments, to proactively identify and address any potential security vulnerabilities, including SSRF exploits. Regular testing helps ensure that security measures remain effective and up-to-date in mitigating emerging threats.
Security Awareness Educate developers, administrators, and users about the risks associated with SSRF vulnerabilities and the importance of adopting secure coding practices and vigilance in handling dynamic content.
In Conclusion
SSRF vulnerabilities pose a significant threat to the security of web applications, and dynamic PDF exports are no exception. By understanding the potential risks and implementing robust security measures, organizations can fortify their defenses against SSRF attacks and safeguard their systems and data from exploitation.
Remember, in the ever-evolving landscape of cybersecurity, proactive risk mitigation is key to staying ahead of threat actors and ensuring the integrity and resilience of digital ecosystems.