On a recent engagement, our testers were faced with a single page web application which was used to generate PDF documents. This web application contained a multi-step form that ultimately let the user download a PDF document containing the details they had entered.
As a user progressed through the form, the data entered would occasionally be redisplayed in future questions. We tried to find an XSS vulnerability in this workflow; and although the application itself correctly escaped user input, an interesting discovery was made when downloading the PDF file: it appeared that the PDF documents were rendered as an HTML page first. This conclusion was drawn from the fact that HTML tags submitted during the application process (specifically <strong>John Doe</strong>) were rendered in the PDF document as bold text.
Using a payload with script tags allowed us to retrieve the window location (<script>document.write(window.location);</script>). We found that the page was being accessed from localhost; and by replacing “localhost” with the actual hosting domain name, the page containing the XSS vulnerability was able to be viewed directly.
Using an image tag (<img src=”attack.ip/owned.jpg”>) payload allowed us to see (via the User-Agent header) that Chrome 59 headless was being used server-side to create the PDF document. A reverse DNS lookup was also performed on the connecting IP, revealing it as an Amazon EC2 instance.
In conclusion, the core vulnerability was the fact that user data was insecurely reflected into a webpage and executed on the remote server. This was patched within a day once brought to the attention of the application developers. Additional hardening techniques were suggested which would have limited the attack surface in the first instance. Implementing the PDF generation using a document templating library would have been a more secure and optimized solution. There would be less overhead involved and no need to rely on potentially-risky HTML rendering.
All IAM roles attached to the EC2 instance should have the absolute minimal set of permissions required. This appeared to be the case with role enumerated in this engagement. In addition, access to the instance metadata API itself should be restricted to allow only those users requiring access. This can be performed with iptables, and significantly reduces the impact of SSRF vulnerabilities found on Amazon EC2 instances.