Wacom Driver Arbitrary File Read Vulnerability

Table of Contents 📜

Premise Why another exploit? Analyzing /custom parameter The mysterious WacomTabletDefaults.xml An idea (with some drawbacks) to exploit the /custom parameter Directory traversal attack Mount point + Symbolic link = Problem solved The Exploit POC Final considerations

Premise ⚠️

This article aims to describe another way to exploit the Wacom Driver 6.3.45-1 vulnerability that I've already extensively detailed and discussed (in this report), so reading that report is necessary (and strongly recommended) to fully understand what you’re going to read (and this article can be helpful as well).
The topics, treated in a concise way, can also be deepened through the links that you can find in the various paragraphs.

Symbolic link and NTFS volume mount points concepts are also crucial to fully understand what you’re going to read and, for this reason, understanding this article is strongly recommended as well.

Why another exploit? ❔

In my previous report I've already explained how to exploit the vulnerability to get a Local Privilege Escalation, so why should I explain how to exploit the same vulnerability to get an Arbitrary File Read primitive (that is less advantageous than the previous one)?
Mainly for the following reasons:

1. Before getting a LPE I found out how to get an Arbitrary File Read primitive (and also an Arbitrary File Read\Write primitive), and I think it's a shame not to explain how I did it.
2. The technique I used to exploit the vulnerability is different from the one I used to get a LPE. It contains valuable logical concepts, which may be useful for developing other attack techniques and may not be known to many researchers.
3. If I were the reader, and were interested in deepening more about logical vulnerabilities, I would like to know as many attack techniques as possible.
4. For myself: explaining something is the best way to learn it (The Feynman Technique).
5. To improve my poor written English 😟

Analyzing /custom parameter 🔍

This time everything revolves around the /custom parameter shown in the table.
Playing with this parameter I found out, using Process Monitor (in the same way I did here), that it expects a filename as a parameter; let's take an example to understand how it works:
/custom "foo"
Assuming that Wacom Driver is installed on the C drive, then Remove.exe performs the following operations:

1. The .xml extension is added to the file name, so we get foo.xml
2. foo.xml is searched in the C:\Program Files\Tablet\Wacom\32\CustomDefaults folder.
3. If C:\Program Files\Tablet\Wacom\32\CustomDefaults\foo.xml is found, its content is copied to C:\Program Files\Tablet\Wacom\WacomTabletDefaults.xml
   If WacomTabletDefaults.xml already exists it is overwritten, otherwise it is created.
   if C:\Program Files\Tablet\Wacom\32\CustomDefaults\foo.xml isn't found, nothing interesting happens.

Summarizing it seems that the /custom parameter is used to create (or update) the WacomTabletDefaults.xml file with the new foo.xml file.
But... What is WacomTabletDefaults.xml? What is it for? When is it used? 🤔

The mysterious WacomTabletDefaults.xml 👻

By reasoning on it we can hypothesize that, as the word itself says, “Defaults” stands for default settings, and therefore the xml file is probably used to restore the default settings or save any customizations that the user may make to his Wacom Tablet device.
This paragraph (“Create default settings for one or more users”), which I found among the documentation that Wacom makes available for developers (WACOM for Developers), confirms the hypothesis just made.
In fact, summarizing what is written in that paragraph, the user can configure his own preferred settings for his Wacom Tablet device using the Wacom Tablet Preference File Utility (C:\Program Files\Tablet\Wacom\PrefUtil.exe). The operation of saving user preferences ends with the generation\update of the WacomTabletDefaults.xml file, which is populated with the set of xml values to determine how the Wacom device must behaves.
There may be several tags within that xml file (take a look at your C:\Program Files\Tablet\Wacom\WacomTabletDefaults.xml file (if you have it)) such as, for example, the PrefsLocation tag which allows the driver-updated Wacom_Tablet.dat to be written to a given location.
Ok, but is this information useful for the development of the exploit? NO! 🤣
This information isn't essential, however, although I already had an idea in mind (illustrated in the following paragraphs) to exploit in an advantageous way (from the point of view of an attacker, obviously 😈) the logic according to which the /custom parameter is managed, I was too curious to understand what the hell the WacomTabletDefaults.xml file was for... I think that curiosity and the desire to understand what is happening under the hood, are two peculiar characteristics of a researcher, and vulnerability researchers are not an exception 👨‍💻

An idea (with some drawbacks) to exploit the /custom parameter 💡

The idea is to try to force Remove.exe to read any file of our choice instead of a generic xml file located in the CustomDefaults folder.
If we could do this we would be able to read any file (readable under the context of SYSTEM), since Remove.exe performs the third point of the previous list under the context of SYSTEM and copies the file we would like to read into the C:\Program Files\Tablet\Wacom folder, naming it WacomTabletDefaults.xml.
Since the regular user can read any file located in the Wacom folder, we would be able to get an Arbitrary File Read primitive.

Let us take a practical example!
The system administrator created the secret.txt file on his desktop and wrote a secret into it (eg the administrator password).
The security settings of that file are set so that only the system administrator and the LocalSystem Account (SYSTEM) can access the file for reading and writing; any other user (therefore also the regular user) has no right to access the file, not even the right to read.
If we were able to put the idea just described into practice, we would be able to force Remove.exe to read the secret.txt file and copy it into the Wacom folder. At this point the regular user can read the secret since he can read any file located in that folder.

Unfortunately there are some problems we need to solve to put our idea into practice:

1. We can choose the name of the file to read but it must be in the C:\Program Files\Tablet\Wacom\32\CustomDefaults folder.
2. Since Remove.exe automatically adds the .xml extension to the file we want to read, we can only read xml files.

How can we read a file of any type located in any position?

Directory traversal attack 📁⏪

Directory traversal attack (aka ..\ or path traversal) is the right attack for us because it allows to force Remove.exe to read from a folder of our choice instead of the CustomDefaults folder.

Let us take a practical examples!
/custom "foo" force Remove.exe to look for C:\Program Files\Tablet\Wacom\32\CustomDefaults\foo.xml
/custom "..\foo" force Remove.exe to look for C:\Program Files\Tablet\Wacom\32\foo.xml
/custom "..\..\foo" force Remove.exe to look for C:\Program Files\Tablet\Wacom\foo.xml
/custom "..\..\..\..\..\MyDir\foo" force Remove.exe to look for C:\MyDir\foo.xml

Ok, surely this is a good starting point because, through this attack, we're able to read any xml file (located in a generic folder in the C drive) that we couldn't read.
But we want something more! We want to read any type of file, even if it were located on a different drive; how can we do it?

Mount point + Symbolic link = Problem solved ✔️

A mount point and a symbolic link are what we need to solve the last remaining problem (and remember that the hard links technique has been mitigated in Windows 10).
We can create a mount point to \RPC Control (which is an object directory) and a symbolic link from \RPC Control\Target.xml to the file we want to read (e.g. C:\Users\Admin\Desktop\secret.txt).
Finally we can use the previously described directory traversal attack, to force Remove.exe to look for the Target.xml file on the mount point that we've specially crafted.

Let's take a practical examples!
We want to read the C:\Users\Admin\Desktop\secret.txt file, but we don't have the privileges to read it.
We can perform the following steps to solve the problem:

1. Create the C:\Users\StandardUser\Desktop\MountPoint mount point to \RPC Control
2. Create the \RPC Control\Target.xml symbolic link to C:\Users\Admin\Desktop\secret.txt
3. Force Remove.exe to execute the following malicious parameter
   /custom "..\..\..\..\..\Users\StandardUser\Desktop\MountPoint\Target"
4. Remove.exe adds the .xml extension to the file name, so we get Target.xml
5. Remove.exe, because of the directory traversal attack, read the xml file from C:\Users\StandardUser\Desktop\MountPoint\Target.xml instead of C:\Program Files\Tablet\Wacom\32\CustomDefaults\Target.xml
   
6. C:\Users\StandardUser\Desktop\MountPoint\Target.xml redirects Remove.exe to \RPC Control\Target.xml
7. \RPC Control\Target.xml redirects Remove.exe to C:\Users\Admin\Desktop\secret.txt
   (We're doing all these redirects because, as mentioned before, we can no longer use hard links).
8. Remove.exe reads C:\Users\Admin\Desktop\secret.txt and copies it to C:\Program Files\Tablet\Wacom\WacomTabletDefaults.xml
9. Copy C:\Program Files\Tablet\Wacom\WacomTabletDefaults.xml to C:\Users\StandardUser\Desktop\secret.txt (we can do this because WacomTabletDefaults.xml is readable by the regular user).
10. Now we can read the secret from the secret.txt file that we were previously unable to read 👀

As you can see it's possible to create a symbolic link from \RPC Control\Foo.ext to any file (even if not located in the C drive) of any type (we can specify its full path, therefore also its extension).
Thanks to the mount point we can redirect the operations on a generic file to an object directory (\RPC Control in our case) and, thanks to the directory traversal attack, we can force Remove.exe to look for the xml file in the mount point instead of the CustomDefaults directory.
This technique answers the question of the previous paragraph (we want to read any type of file, even if it were located on a different drive; how can we do it?).

The Exploit ☠️

To better understand how to perform the point 4 of the previous list I suggest you read my report.
However, in the steps of the following exploit, I will divide that point into sub steps to make it more understandable.
As before, let's suppose that we want to read the C:\Users\Admin\Desktop\secret.txt file, but we don't have the privileges to read it.
The exploit drops all the files it needs (Backup.wacomprefs, CreateMountPoint.exe and CreateSymlink.exe), creates the mount point and saves the file that the regular user wants to read in the folder from which it's executed (in this case the desktop of the regular user).
I chose that folder to make sure the exploit can read and write in it.

The exploit performs the following steps to allow us to read the file:

1. Ask the user the path to the file he wants to read.
   (Let's suppose that he wants to read the C:\Users\Admin\Desktop\secret.txt file).
2. Drop Backup.wacomprefs into the exploit folder (C:\Users\StandardUser\Desktop)
3. Drop CreateMountPoint.exe into the exploit folder (C:\Users\StandardUser\Desktop)
4. Drop CreateSymlink.exe into the exploit folder (C:\Users\StandardUser\Desktop)
5. Create the C:\Users\StandardUser\Desktop\MountPoint mount point to \RPC Control through CreateMountPoint.exe
6. Create the \RPC Control\Target.xml symbolic link to C:\Users\Admin\Desktop\secret.txt through CreateSymlink.exe
7. Create and write into WacomInstallI.txt the following malicious parameter:
   /custom "..\..\..\..\..\Users\StandardUser\Desktop\MountPoint\Target" /silent /agree
   (Read this and this paragraph to understand the usefulness of WacomInstallI.txt; read this to understand the usefulness of /silent and /agree parameters).
8. Force Remove.exe to execute the parameter through the following command:
   "C:\Program Files\Tablet\Wacom\PrefUtil.exe" /restore "C:\...\Backup.wacomprefs" /silent
   (Read this for more information).
9. Wait a few seconds for Remove.exe to execute our malicious parameter; meanwhile the following steps are performed:
1. PrefUtil.exe restore the customized device settings from Backup.wacomprefs
2. The restore operation triggers Remove.exe and forces it to execute our malicious parameter.
3. Remove.exe adds the .xml extension to the file name, so we get Target.xml
4. Remove.exe, because of the directory traversal attack, read the xml file from C:\Users\StandardUser\Desktop\MountPoint\Target.xml instead of C:\Program Files\Tablet\Wacom\32\CustomDefaults\Target.xml
5. C:\Users\StandardUser\Desktop\MountPoint\Target.xml redirects Remove.exe to \RPC Control\Target.xml
6. \RPC Control\Target.xml redirects Remove.exe to C:\Users\Admin\Desktop\secret.txt
   (We're doing all these redirects because, as mentioned before, we can no longer use hard links).
7. Remove.exe reads C:\Users\Admin\Desktop\secret.txt and copies it to C:\Program Files\Tablet\Wacom\WacomTabletDefaults.xml
10. Copy C:\Program Files\Tablet\Wacom\WacomTabletDefaults.xml to C:\Users\StandardUser\Desktop\secret.txt
    (The exploit can do this because WacomTabletDefaults.xml is readable by the regular user).
11. Now the regular user can read the secret from the C:\Users\StandardUser\Desktop\secret.txt file.
12. Cleaning operations:
    1. Terminate CreateSymlink.exe and delete the \RPC Control\Target.xml symbolic link.
    2. Delete Backup.wacomprefs
    3. Delete CreateMountPoint.exe
    4. Delete the mount point to \RPC Control.
    5. Delete CreateSymlink.exe.

Here you can find the C# source code of my exploit (Visual Studio Project.zip).
Here you can find the executable file (Exploit.exe).

CreateMountPoint.exe and CreateSymlink.exe are programs developed by James Forshaw and are downloadable from his symboliclink-testing-tools repository, respectively here and here.

POC 🎦

I have tested the exploit only for Wacom Driver 6.3.45-1 but, most likely, it also works for the previous versions (and I hope not on the future ones 🙄).

Final considerations

The conclusions are the same as I wrote in my main report; I report below, for convenience, the most interesting paragraphs.

• How to fix the vulnerability 🚑
• Conclusion
• Useful readings and references 🔗

Since the new concepts introduced by this report are essentially symbolic links and mount points, I want to add some other articles that may be useful to those who know nothing (or little) about them:

• Symbolic links - Eran Shimony 🔗
• Symbolic links - Shubham Dubey 🔗
• NTFS Mount point (or NTFS Junctions) - Computer Hope 🔗
• NTFS Mount point (or NTFS Junctions) & Oplock - Luca Barile 🔗
• Symbolic links & NTFS Mount point (or NTFS Junctions) - Tempest Security 🔗

And don't forget to read my report in which I explain how to exploit the same vulnerability to get an Arbitrary File Read\Write primitive (I think, as regards the Arbitrary File Read primitive, it's one of the most unusual one that I've ever seen 😂)!
It's the last report for this vulnerability, I promise ❗