What is XSS (Cross-Site Scripting) to Local File Read Vulnerability?
Before we delve into the write-up about the escalation of XSS to RCE, let’s first understand what XSS is.
XSS or Cross-Site Scripting, combined with local file read vulnerabilities, creates a dangerous exploit. Attackers inject malicious JavaScript code into web applications, enabling them to read local files on the targeted system. This vulnerability occurs due to weaknesses in server-side generated content like PDFs or other documents.
How Do XSS to RCE Attacks Work?
In an common XSS attack, malicious scripts infiltrate trusted websites or applications. These scripts execute in the victim’s browser, steal sensitive information, manipulate web content, or perform other harmful actions.
When combined with local file read exploits, it can lead the XSS to RCE. Its because the injected script accesses sensitive files on the targeted system. Consequently, attackers gain unauthorized access to sensitive data for further exploitation or unauthorized system access.
The Story of XSS to RCE via Local File Read in PDF File
In November 2017, bug hunter Rahul Maini discovered a critical vulnerability in a private program on Bugcrowd (redacted.com). This vulnerability involves Cross-Site Scripting (XSS) in server-side generated PDF files. Simply put, this XSS to RCE escalation is carried out by exploiting a PDF file. Initially, Maini considered it less impactful (P4), but upon further investigation, its severity increased, leading to a P1 classification.
Vulnerability Discovery
While exploring an application feature that enabled users to download payment statements in PDF format, Maini noticed an intriguing detail. The URL for downloading these statements contained a parameter called “utrnumber” and its value was reflected inside the downloaded PDF file.
HTML Code Injection
Maini experimented HTML Code Injection by inserting HTML code into the “utrnumber” parameter and observed that the PDF rendered the HTML. Usually, such vulnerabilities result in XSS attacks. However, in this case, the issue occurred inside a dynamically generated PDF.
Note from the author: To better understand XSS, readers can visit this comprehensive introduction: here
JavaScript Execution Investigation
Maini further experimented to determine if JavaScript could be executed within the PDF by using an iframe to load internal domains or file paths. Although unsuccessful in these attempts, it was eventually discovered that JavaScript execution was possible through DOM manipulation.
Successful JavaScript Execution
After downloading a PDF with a manipulated “utrnumber” parameter, Maini confirmed that JavaScript execution succeeded. So with this vulnerability, Maini can escalate the XSS to RCE attack. The issue’s root cause was the conversion of user input from an HTML document to a PDF on the server-side.
Exploiting the Vulnerability
In subsequent tests, Maini found that using JavaScript’s “document.write()” function made it easier to display results. This discovery revealed that the JavaScript executed in the “file://” origin on the server. With this information, Maini attempted an XMLHttpRequest (XHR) to access the file:///etc/passwd and successfully retrieved the /etc/passwd file in the generated PDF.
Conclusion
In conclusion, Rahul Maini’s discovery highlights the potential risks associated with XSS in server-side generated PDFs, which can lead to local file reads or we can simply called XSS to RCE vulnerability. Cybersecurity professionals must stay vigilant in identifying and addressing such vulnerabilities to ensure user data safety and privacy.
How to prevent XSS to RCE vulnerability?
- Secure coding practices: Developers should adhere to secure coding practices, such as input validation and output encoding, to minimize the risk of XSS attacks.
- Sanitize user input: Always sanitize user input to prevent malicious scripts from entering the application. Employing libraries and frameworks designed for this purpose can help ensure proper input sanitization.
- Implement proper output encoding: Encode dynamic data to prevent the browser from interpreting it as executable code. Encoding ensures that data remains harmless, even if an attacker injects malicious code.
- Content Security Policy (CSP): Implement a Content Security Policy to limit the sources of script execution, restricting potential attack vectors.
- Regular security assessments: Conduct regular security assessments and penetration testing to identify and address vulnerabilities before attackers can exploit them.
- Educate developers: Train developers on secure coding practices, common vulnerabilities, and the latest attack techniques to enhance their understanding of potential security risks.
By following these preventative measures, developers can reduce the likelihood of XSS to local file read vulnerabilities, ensuring a more secure web environment.
Link to read full write up: here
Save the PDF here
