PrintFriendly is a tool used by millions of people everyday to help them save paper and ink when they print and generate PDFs. The tool is available as a browser’s plugin (Chrome , Firefox and more) or as an external plugin for CMS such as Wordpress and Drupal
While performing security testing against one of our customers, we noticed that they were using PrintFriendly’s plugin to allow their users to generate PDFs from their website. We explored the functionality and found it to be simple. After clicking on the PrintFriendly button, the PDF of the desired page will be processed on https://www.printfriendly.com/ and a link to the generated PDF will be produced, for example, https://www.printfriendly.com/p/g/HyPaUT. The view looks similar to the following:
As we observed, the same thing happened on PrintFriendly’s browser extensions and through their preview tool on their main site.
Users can download the PDF file by clicking on the PDF icon at the top header, as shown in the screenshot above. As a result, a download link will be generated for the content, which can be retrieved as a PDF document.
As soon as we checked the requests in Burp Suite, we realised there might be a problem. The request showed that the PDF was generated by parsing the HTML content from the code and processed at the server-side.
We further explored the likelihood and noticed that the <script> tag was filtered and common JavaScript onevent handler did not work. We assumed there might be a denylisting enabled from the application side. Luckily, the <iframe> tag was possible. Using this tag, we could pointing the iframe’s source to the local file such as /etc/passwd. While attempting that, we noted that by simply pointing the src to the file:///etc/passwd was blocked. This was bypassed by supplying a URLencoded ? and then traversed it back to the passwd file.
<iframe src='file:///etc/%3F/../passwd' />
Timeline:
29 July 2022 : RE:HACK sent a brief discovery information to PrintFriendly team
29 July 2022 : RE:HACK received a reply from their technical person and was asked to provide detail POC
29 July 2022 : RE:HACK provided the POC
29 July 2022 : Their team received the POC and validated the issue
16 August 2022 : RE:HACK asked for a status update
18 August 2022 : Their team told the fix will be deployed on the 24th of August.
22 August 2022 : Their team emailed and informed the fix has been deployed.
22 August 2022 : RE:HACK requested to publish the writeup and was permitted. Published.
