Vulnerability reported and fixed: Attachment filetype denylist bypass in Foxit PDF clients

In this post, I’ll talk about an extremely simple way I bypassed a security feature in Foxit PDF clients that allowed me to execute code via a file embedded inside a PDF.

Why I looked into this vulnerability

I have a love/hate relationship with PDF. Working with PDF frustrates me as the format is really fragile, but I still spend days trying to get it to do what I want. Probably because I’m excited about how well it's suited for malware delivery.

The Portable Document Format, also known as Payload Delivery Format (PDF), supports all kinds of crazy things, which is at least partially the reason it works so well as an initial code execution vector.

One of the features of PDFs is that one can embed another file inside a PDF. In addition to that, there are ways to command or ask the PDF client program used to view the PDF what to do with the embedded file. Of course, malicious actors would like to tell the PDF client to open the embedded file when the PDF itself is opened.

But most, if not all, popular PDF viewers have several mitigations for the potential risks this kind of action may pose. I'll show you just how easily I bypassed one of them.

How I discovered this vulnerability

I was tasked with developing as many ideas as possible for bypassing email attachment filtering and different email-related security solutions. One idea I had was to see how the Outlook Client or Exchange server would behave when an attachment that would typically be blocked because of the default blocked file types rule set by Microsoft would have a trailing dot after the file type, like this: [malware.exe.] Notice the [.] after [.exe.].

Before that filtering bypass task, I had spent hours modifying and testing a PDF file that our team used as a base template to build the PDF attachments used in our simulations. I built a template with multiple triggering mechanisms to try to have the user’s default web browser load a URL. So that we could load our microtrainings and educate the user on why opening PDF attachments could be risky or harmful.

One of these mechanisms asked for the user’s permission to open a file embedded inside the PDF. The embedded file was a [.html] that, by default, would be opened by the user’s web browser to show the microtrainings.

[.html] and [.htm] are not in the denylist used in most PDF clients, which means they can be opened when the user gives their permission. These are considered safe because they don’t easily allow for arbitrary code execution when opened. Usually, these open in the default web browser, designed to run untrusted code. If you have a remote code execution exploit for a browser, it would be much easier and stealthier to compromise the user by having them click a link and visit a web page instead of doing it via PDF.

While writing down the trailing dot idea, I decided to use it to see if it would work in the PDF. Sure, it might not work, but it was worth a try. Adding a trailing dot after the file extension embedded inside the PDF caused the Foxit PDF client to allow opening it. No matter what the embedded file extension was.

This is what it looks like inside the PDF. Object 5 has the file name, file extension, and trailing dot. In this example, the malicious file was a batch file [.bat] that would allow for code execution.

Now I had a PDF, where I could embed any file type and have the Foxit PDF Reader open the embedded file when the PDF file was opened, thus executing any code I wanted. Note that with default settings, the Foxit client warns the user twice before opening the embedded file. First, disable Safe Reading Mode—disable checkbox is checked by default—and then open the embedded file.

Two warnings were too much, which led me to discover the second vulnerability, which used a form submit feature and a PDF/HTA polyglot.

Watch the exploit

In the video example, the embedded file downloads and executes putty.exe to show code execution.

The source code used

Here is the source of the PDF that I used in the video.

This vulnerability was reported and fixed following Hoxhunt research and disclosure to Foxit security. It was reported to Foxit on 06.09.2021 and fixed in the Foxit Reader and Foxit PDF Editor v11.1, published on 12.10.2021.

About the author

Pontus joined Hoxhunt in 2017 and currently works as an Offensive Security Engineer. He enjoys researching and developing attack techniques, exploits, and tools.