Vulnerability reported and fixed: Arbitrary file execution in Foxit PDF clients

Unlike the previous vulnerability I found in Foxit PDF clients, which was extremely simple, just a single dot in the right place, this was more complex. Also, I didn’t specifically spend time looking for any vulnerabilities to exploit in the previous one.

That first exploit also required the target user to click through two dialogs. Two clicks from the user to get code execution is obviously less nice than a 1-click exploit.

After discovering the previous trailing dot vulnerability, I wanted to either get rid of the two dialogs or somehow manipulate them to make the exploit more effective. I ended up building an exploit with only one dialog, the contents of which I could partially manipulate.

In this article, I'll discuss exploiting a form submit feature in Foxit PDF clients that allowed me to control the file extension, format, and submit location. I used a feature in Windows to help with code execution and a feature in Outlook to help drop my malware in the right place.

Hunting for vulnerabilities

So I started looking for interesting features or behaviors and really focused on hunting for vulnerabilities in the Foxit PDF clients. I didn’t think I'd find anything, but since the first one was so simple, it gave me hope.

I ended up mostly playing with the form submit feature. You may have filled out and submitted PDF forms before. This is a standard PDF feature which is defined in the PDF specification.

I noticed that I could submit the current PDF itself to any location, local or remote. I immediately thought if I were going to find anything, it would be through this feature.

Of course, I couldn’t do any harm with just a PDF, no matter where it was saved. But, I noticed that I could not only change the name of the submitted PDF file, but also its extension.

So I had a PDF I could modify to have the PDF client submit the file itself to any location and change its extension to any extension I wanted.

But what can I do with the ability to basically, save a PDF somewhere? Changing the extension did not matter because it would still be a PDF and would not work as any other file type.

Morphing the PDF into a malicious executable

I’ve played with polyglots before and thought they were really interesting, but I couldn’t think of a way to use them meaningfully. Until now.

Polyglots are files that can simultaneously be two or more different types or formats. An HTML/PDF polyglot would contain both a valid HTML document and a valid PDF in one file. For example, changing the extension of an HTML/PDF polyglot from polyglot.html to polyglot.pdf would, instead of opening polyglot.html in a web browser and rendering a valid web page, would open the same file in a PDF client and render a valid PDF.

I knew HTML/PDF polyglots existed, so I thought HTA/PDF polyglots should also be possible. An HTA or HTML application would allow code execution on the operating system instead of HTML, which would simply open in a web browser.

I successfully converted an existing HTML/PDF to HTA/PDF polyglot, but when I tried to submit the PDF as an HTA file, the file did not work anymore. Foxit PDF Editor would rewrite the entire HTA/PDF polyglot each time it was submitted, removing the HTA part within the polyglot file. I started comparing the HTA/PDF polyglot I created and the output file generated by the Foxit PDF Editor on submission. I found that the metadata stream inside the PDF was left untouched by the PDF Editor on submission.

I replaced the original metadata with the HTA code, and after submitting my polyglot.pdf as a polyglot.hta with Foxit PDF Editor, I could double-click the resulting polyglot.hta file to run the HTA. The modified metadata object inside the PDF looked like this.

Achieving code execution

So far, so good, but how on earth could I get polyglot.pdf to execute itself as a polyglot.hta after submitting it?

Fortunately, Windows has a built-in feature for this, the Startup folder. Any file saved in user’s Startup folder is automatically run when that user logs on to Windows. The Startup folder is also one of the simplest ways for malware to gain persistence.

However, there was a problem with using the Startup folder to run the polyglot.hta. The path to the user’s Startup folder is [C:\Users\<username>\AppData\Roaming\Microsoft\Windows\Start Menu\Programs\Startup]. The path I could set inside the polyglot.pdf for the HTA would have to be an absolute path, meaning I'd have to know every folder name from C: drive to the user’s Startup folder.

The problem was that I didn’t know the username of the user who would open my polyglot.pdf, so trying to submit the polyglot.hta to the Startup folder would fail. Environment variables like %USERNAME% or %LOCALAPPDATA% would not work.

If the current user had administrator privileges, the polyglot.hta could be submitted to the system-wide Startup folder so that it would get executed when any user logged in. This action requires admin privileges, and rarely does someone use an admin account for everyday tasks. I only had the current user’s privileges when abusing the submit feature in Foxit PDF clients.

The video below shows how it worked if I knew the username and the absolute path to that user’s Startup. For this example, you can see the current user’s username in the submit dialog as WDAGUtilityAccount.

This could be used in an extremely targeted attack where I'd know the target user’s username in advance. I could hardcode the absolute path for the form submit location using the user’s username, but I did not want to stop there. I wanted to create an exploit that made sense in the real world.

After struggling through all the problems, I thought this was the final boss I could not defeat. I decided to stop and try again in a few days. It was late Friday night.

Piggybacking on Outlook

The following Monday evening, I started working on it again. I started thinking about how an attacker would deliver this PDF in the first place and what the target user would do.

A few years back, I remember noticing how Microsoft Outlook handled email attachments when an email with attachment was previewed in Outlook. Outlook would create a randomly named folder under the current user’s home directory and write the email attachments to that folder. The path to this folder would be [C:\Users\<username>\AppData\Local\Microsoft\Windows\INetCache\Content.Outlook\<random>].

If I were the attacker, I'd send the polyglot.pdf as an email attachment. Since Outlook is extremely popular on Windows, I could abuse that behavior to get Outlook to help with the directory problem. I could set up the path so that when the user would allow the form submission, it would traverse back directories from the random folder where the polyglot.pdf would reside until it would land in \AppData\, and from there, start going towards the user’s Startup folder.

Comparing the path of the <random> folder where my polyglot.pdf attachment was saved by Outlook and the user’s Startup folder where the polyglot.hta would need to be submitted. NFEICA4R is an example of what <random> would look like.

[C:\Users\<username>\AppData\Local\Microsoft\Windows\INetCache\Content.Outlook\NFEICA4R\]

[C:\Users\<username>\AppData\Roaming\Microsoft\Windows\Start Menu\Programs\Startup\]

You can see how going back from the Outlook attachments folder to the user’s Startup would let it stay inside the user’s home directory. This way, I don't need to know the current user’s username beforehand.

Finally, the directory traversal from the Outlook <random> folder to the user’s Startup folder inside the PDF looked like this.

[..\\..\\..\\..\\..\\..\\Roaming\\Microsoft\\Windows\\Start Menu\\Programs\\Startup\\polyglot.hta]

URI Path Manipulation

There was one last thing I was not too happy with. The form submit target URI shown to the user.

That looks too suspicious. Fortunately, I could manipulate the URI to hide part of the real path and add something bogus at the end of it. For example, make it look like it's trying to connect to https://www.foxit.com for telemetry, or make it look like it's trying to connect to a legitimate foxitupdater.exe, which actually comes with Foxit PDF clients.

With more time, one could find a better way to obfuscate the URI.

In the end, it all looked like this to the target user. Opening the PDF attachment and allowing the form submit dialog would save the polyglot.hta to the current user’s Startup folder. The next time the user signs in to Windows, the malicious polyglot.hta would be executed.

This vulnerability was reported to Foxit on 06.09.2021 and fixed in Foxit PDF 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.