PDF Generator’s Eternal Bond with SSRF

As part of the Application Security Assessment, we have come across the vulnerability Server Side Request Forgery (SSRF) using HTML Injection, via PDF and image generator.

As the vulnerability name suggests, an adversary forces a vulnerable web server to access either internal or external resources, that it has access to, such as retrieving local files, network scanning, etc.

First things First …

Let’s understand the functionality that led to SSRF. There is a module for ID card generation that takes user input such as company name, employee name, etc., and the form can be downloaded as pdf or images. So the first thing that comes to mind, is to check if the input validation is in place, and how the input gets rendered in pdf or image.

We started with basic HTML payloads and checked if we were able to render the same in PDF and image form. Since there was no input sanitization, the HTML payload got rendered in both pdf and image. The next obvious thing would be to check for SSRF.

For this, we gave the payload

“<iframe src = ‘burp collaborator link’></iframe”. We got DNS and HTTP hit from the victim server to our burp collaborator.

 

What’s Next??

Since we have confirmed the SSRF issue here, we tried to exploit it further. The application was hosted on AWS, so the payload “<iframe src=”http://169.254.169.254/latest/meta-data/iam/security-credentials/” revealed the security credentials attached to the EC2 instance.

 

We can proceed further to understand what permissions does AWS credentials have, by using the enumeration script from https://github.com/andresriancho/enumerate-iam. But we have concluded our assessment here, and have reported the issue to the concerned team for remediation.

But what went behind the scenes!!

The application uses wkhtmltopdf and wkhtmltoimg, which is a widely used open-source pdf and image rendering utility. This renders the HTML content on the server-side, which is a high-risk target for both Server-side Request Forgery (SSRF) and Local File Inclusion (LFI) vulnerabilities.

To have a better picture, we have installed the wkhtmltopdf locally and used the below simple HTML form

We have used wkhtmltoimg to convert the HTML form to image, and when the image is generated, we have noticed a hit on our burp collaborator from our local machine. This gives us an idea that wkhtmltopdf/wkhtmltoimg renders the HTML content on the server-side.

This is the image rendered post-conversion

So if any application using wkhtmltopdf or wkhtmltoimg, has not validated or sanitized user input properly, before passing as an input to this library for conversion, that would result in Server Side Request Forgery or Local File Inclusion vulnerabilities.

Remediation:

• Golden Rule – Never Trust User Input. Always sanitize it.
• Whitelist the domains that the application requires.
• Allow only required URL schemas, for example, only allow https://, and block unwanted schemas such as http://, ftp://, file:// etc.
• Applications that generate PDFs or images with wkhtmltopdf or any pdf renderer should only accept textual data from users.

OH wait there …

Our job is done right, we have tested the application, found AWS credentials, reported it as a critical issue, provided the remediation, etc. We are good to go as a Security Tester, but the real pain starts for the developer now.

Let’s take a simple example, to view the profile images and how that can result in SSRF

Here the image is fetched from the user inputted URL and rendered in the application. The parameter ‘img’ is not sanitized here, resulting in SSRF.

VULNERABLE CODE:

As expected, when we enter burp collaborator link, we get a DNS and HTTP hit from the vulnerable server.

To avoid this, the secure way of implementing here would be to whitelist the urls required, as shown below:

SECURE CODE:

The above code validates against the list of domains whitelisted, and throws error if the input is not from the list, as shown below.

Looks like the issue is resolved here. However, the mitigation varies depending on the scenario and the business requirement.

To get more details on secure code practices, and to assess the security of the applications, please reach out to us – Talk to Our Delivery Head

References:

https://wkhtmltopdf.org/

https://securecode.wiki/docs/lang/python/

https://gist.github.com/rollwagen/e1017cc73281401ff364c75d0b5a2e79

 

About Author

Saideepa Amanaganti
Sr.Security Analyst – WeSecureApp