Exploiting a hidden and forgotten Bug
Hi, this writeup is about a bug that existed in HTML to PDF generation functionality in a program.
As it is heavily said by community that HTML to PDF genrating softwares are usually vulnerable to SSRF, and that’s what I was trying to do. The program had option to create certificates using HTML and some background template.
I tried to inject various payloads, googled things and read nahamsec’s writeup on exploiting similar function again and again, but no use.
The only HTML tag that gave back a response to my TCP tunnel was <img> tag, moreover the fetch that was occuring from backend didn’t gave any hint about the software being used in backend for the generation of pdf file.
Hitting and Trying various html tags, I found that on injecting a <link> tag with link to a internal file such as /etc/passwd and some other tags gave a error on the POST request being send . The error didn’t contained much of info but it contained enough for me to keep going. It said TCPDF Error.
Googled it up and found about the TCPDF software, which is written in PHP and used to create PDFs from HTML. Tried to find any already present bug CVE but as I didn’t knew the version so, I can’t narrow down my options and pinpoint at correct position. Tried to read the documentation to find any HTML tag that may be allowed and can be leveraged to attack the backend, but TCPDF is enough secure on that part and didn’t allowed any tag that may allow SSRF.
I thought to have a look at what the pdf that comes really contains (as in bug found by nahamsec the data came along with the pdf but only visible in metadata).The website used another service to host PDFs ad used another service to display PDFs and the PDFs that were shown in frontend were connverted to JPG format before being diplayed. Althoguh the displaying service was using the URL for the JPG format but the hosting service response also contained a URL to original PDF. Now, again the download URL for the PDF had another hostname and it didn’t allowed me to download the file. I just used the authentication headers from hosting service hostname to this one and they luckily worked and got the metadata of PDF in the burpsuite.Guess what, I found…
TCPDF embeds the version number in the metadata, and a single google search revealed that the version was very old(TCPDF 6.0.043) and vulnerable to CVE-2017–6100.
The exploit was that the TCPDF versions before 6.2 were vulnerable to upload server’s internal files to a remote FTP server. But still there was a long way to go as TCP tunnel wasn’t working correctly with FTP and the exploit presented by Frans Rosen in his blog wasn’t working.
I got a free ftp server from ftphosting.net, this resolved first problem. Since, I was sure that the bug exists, I kept going, and downloaded the exact version of TCPDF and did all the steps manually as mentioned in the blog. I found that payload wasn’t working because the payload that is injected is serialized and simply editing it up to make required changes was somehow, rendering it useless. Generated a payload on my machine and passed that onto the server to extract passwd file from the target server to my FTP server as POC.
Untill next time. Waana discuss anything, hit me up on Twitter.
