Story of SSRF from Stored XSS in PDF generator application

Introduction

PDF generator libraries, particularly those implemented using JavaScript, often face vulnerabilities to cross-site scripting (XSS) attacks, posing a challenge to the security of web applications. One primary reason for this lies in the dynamic nature of JavaScript itself. Many PDF generator libraries heavily rely on client-side scripting to manipulate and generate PDFs, allowing attackers to exploit vulnerabilities in the code. In this write-up, I will show you how I exploited the server side issue (SSRF) from the front-end interface (XSS)

The finding

Basically, the application helps you to generate invoice online by just filling in the data and download the pdf file of it.

I started by doing a recon on the target to identify few things including the stack used to build this application (well, Wappalyzer plus review the minified client code on the browser) and the cloud used to deploy this application (which was AWS).

Story short, instead of filling intended fields and data, i tried to add JS code to see if the code will be interpreted and executed (XSS).

Surprisingly, the app responded with the output of my JS code <script>document.write(document.domain)</script> printing the domain name of the application. Now we have our stored XSS. A journey to increase an impact ...

Next i wanted to try if i can exploit any server side issue (stealing cookies wasn't enough for me) for that i tried to use iframe, testing if the application can fetch resources remotely. Since i've already knew that AWS is used, i tried to fetch internal meta-data of the instance with <iframe src="http://169.254.169.254/latest/meta-data/">

As how i was expecting, the application gave me what i requested ...

Up to this point as an attacker, you can do alot on this application. I chose to read access keys of the this server so that i can completely take over the server. In AWS cloud-world, if you can have "Access Key ID" and "Secret Access Key" then you can run command remotely in the server and even play around with some connected services. I wanted this!

First in order to know and read these credentials, you must know the IAM role used in this particular instance. So i added <iframe src="http://169.254.169.254/latest/meta-data/iam/security-credentials/">

I got the IAM role and next step was just to append it on the same endpoint so that we can read these credentials.

Voila! Now we have a full control of the instance remotely.

Final thought

As we have seen above, the integration of third-party libraries in PDF generators can introduce additional vulnerabilities. Although this is most known issue and well fixed in most of the JS libraries but some libraries especially new ones are still prone to this kind of attacks.

It is advised to double check the library you want to use in your application and ensure that it is free-from pursing issues result to XSS. Also sanitization should always be implemented on all input fields and forms as a preventive measure.

Disclaimer: The researched target mentioned (anonymized) in this write-up was successful patched and remediated. Kudos to the team!

Originally wrote this article here Thanks for reading !