Wacom Driver Arbitrary File Write\Overwrite Vulnerability

Table of Contents 📜

Premise How did I discover the vulnerability? Analyzing the Wacom device plugging\unplugging An Arbitrary File Write\Overwrite primitive The Exploit POC Constraints & workarounds Wacom USB device plugging\unplugging simulation From Arbitrary File Write\Overwrite to Windows Denial of Service Something more on cng.sys How to fix the vulnerability Vulnerability disclosure timeline Final considerations

Premise

This article describes a vulnerability affecting Wacom Driver 6.3.46-1 and 6.3.45-1 for Windows (it probably affects older versions as well, but I haven't tested them), and a way by which this vulnerability can be exploited to get an arbitrary file write\overwrite primitive (with no control over the content of the file written\overwritten).
I suggest to read this article to better understand some points of what you’re going to read.

How did I discover the vulnerability?

All the previous Wacom Driver vulnerabilities I discovered (1.1, 1.2, 1.3, 2 and 3), were mainly discovered through the dynamic analysis (except 1.1, which also required static analysis) of the Wacom Driver components (eg Wacom_Tablet.exe, Remove.exe, WTabletServicePro.exe, ...).
I don't have any Wacom device but, one day, I got the chance to use one (Wacom Intuos Small Graphic Tablet).
Only when a Wacom device is connected to the PC some features of WacomDesktopCenter.exe are enabled, so I took this opportunity to understand what happens (through dynamic analysis) when these features are used and, consequently, to look for some possible vulnerabilities.
Unfortunately the analysis of all the unlocked features didn't get me anywhere because they're managed by WacomDesktopCenter.exe, which runs and performs its operations with the privileges of the current user.
Not knowing what else to analyze, as a last resort, I tried to understand what happens when a Wacom device is plugged\unplugged via USB, and I discovered an unexpected and pleasant surprise 🙃

Analyzing the Wacom device plugging\unplugging 🔍

Using Process Monitor I discovered that, when a Wacom device is plugged\unplugged via USB to the PC, %ProgramFiles%\Tablet\Wacom\Wacom_Tablet.exe is triggered and runs under the context of SYSTEM.
Once triggered it tries to download the update.xml file from a Wacom server (http://link.wacom.com/wdc/update.xml) and, if the file get downloaded properly, Wacom_Tablet.exe saves it, without impersonating the current user, into the %windir%\Temp\wactemp folder.

Here's the problem: the wactemp folder isn't created during the Wacom Driver installation therefore, the first time a Wacom device will be plugged in, and Wacom_Tablet.exe will be able to download the update.xml file from the Wacom server, the wactemp folder will be created (and it will no longer be deleted because it will be used to store the updated versions of the update.xml file) and the downloaded update.xml file will be saved in it.
You can see the creation of the wactemp folder and the update.xml file in the following image, obtained by analyzing with Process Monitor the first Wacom device plugging event.

But what if we create a %windir%\Temp\wactemp NTFS volume mount point before that happens?
We can do it because the regular user has special access to the %windir%\Temp folder...

Notes:

• Wacom_Tablet.exe creates the wactemp folder only once because it will no longer be deleted after the first creation.
• When Wacom_Tablet.exe saves the downloaded update.xml file into the wactemp folder, if an older version of the update.xml is already present, it will be overwritten by the new one.
• If the %windir%\Temp\wactemp mount point isn't created before Wacom_Tablet.exe creates the %windir%\Temp\wactemp folder, it will no longer be possible to create it, because the regular user cannot delete the folders\files stored in the %windir%\Temp folder.
• If the PC isn't connected to the Internet, or the update.xml file download process fails for some reason, the wactemp folder and the update.xml file will not be created.
• Wacom_Tablet.exe tries to repeat the update.xml file download and save procedure even during the Wacom device unplugging event.
• As the name itself says, the update.xml file is necessary to understand if an update of the Wacom Driver (or some of its components related to the Wacom device used by the user) is available, and if the update is supported by the current version of the operating system.
  In case update.xml is no longer available on the Wacom server and you want to analyze it, I saved a copy here (downloaded on 2022-08-27).
• I suppose Wacom_Tablet.exe repeats the update.xml file download and save procedure every time a Wacom device is plugged\unplugged to the PC because it wants to check if there are updates for that particular device and, the data of a Wacom device, is collected at the time of its plugging\unplugging.
  An alternative could be to store only the data of the new connected Wacom devices and search for updates only once a day (or at regular time intervals), without depending on the connection of a device. Could it work? 🤔

An Arbitrary File Write\Overwrite primitive 📝

Probably, if you have read these four articles (1, 2, 3 and 4), by now you will have understood that when the situation just described occurs, the link following attack is the first thing that comes to mind and, even in this case, it can be applied in a similar way to what has been done here and here.
We can create a %windir%\Temp\wactemp NTFS volume mount point to \RPC Control before Wacom_Tablet.exe creates the %windir%\Temp\wactemp folder.
Then we can create a Symbolic link from \RPC Control\update.xml to a file we want to write\overwrite (in my POC I used %windir%\win.ini).
Now the workflow is quite simple: when the user plugs in a Wacom device, Wacom_Tablet.exe will be triggered, download the update.xml file from the Wacom server (if the PC is connected to the Internet), create the wactemp folder (if it hasn't already been created) and save the downloaded update.xml file in it.
However, since we've created the %windir%\Temp\wactemp mount point, when Wacom_Tablet.exe will try to save the update.xml file into %windir%\Temp\wactemp, it will consider our mount point as a valid wactemp folder and try to write the downloaded update.xml file in it.
Since %windir%\Temp\wactemp is a mount point to \RPC Control, Wacom_Tablet.exe will be redirected (reparsed) and will try to write \RPC Control\update.xml.
Since \RPC Control\update.xml is a symbolic link to our target file (eg %windir%\win.ini), Wacom_Tablet.exe will be redirected again, and will write\overwrite the target file (and it will succeed because it's running under the context of SYSTEM) with the content of the downloaded update.xml.
If the target file doesn't exist, Wacom_Tablet.exe will create it and write the content of the downloaded update.xml in it, otherwise it will overwrite the contents of the already existing file with the content of the downloaded update.xml.
In the following image you can see Wacom_Tablet.exe reparsed to the target file after creating the wactemp mountpoint and plugging, for the first time, a Wacom device.

The Exploit ☠️

The exploit that I wrote is based on the aforementioned workflow and performs the following steps:

1. Ask the user which file he wants to write\overwrite (let's suppose %windir%\win.ini).
2. Create the %windir%\Temp\wactemp mount point to \RPC Control.
3. Create the \RPC Control\update.xml symbolic link to %windir%\win.ini.
4. When the user plugs in a Wacom device, Wacom_Tablet.exe is triggered (and runs under the context of SYSTEM).
5. Wacom_Tablet.exe will download the update.xml file from a Wacom server and try to save it into the %windir%\Temp\wactemp folder.
6. Since %windir%\Temp\wactemp is a mount point to \RPC Control, Wacom_Tablet.exe will be redirected and will try to write \RPC Control\update.xml.
7. Since \RPC Control\update.xml is a symbolic link to %windir%\win.ini, Wacom_Tablet.exe will be redirected again, and will overwrite %windir%\win.ini with the content of the downloaded update.xml.

Here you can find my exploit.
If your operating system is not installed on the C drive, modify the exploit by replacing CreateMountPoint.exe "C:\Windows\Temp\wactemp" "\RPC Control" with CreateMountPoint.exe "%windir%\Temp\wactemp" "\RPC Control".

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've tested the exploit only on Wacom Driver 6.3.46-1 but, most likely, it also works for the previous versions (and I hope not on the future ones 🙄).
The Wacom device I plugged in to trigger Wacom_Tablet.exe is Wacom Intuos Small Graphic Tablet, but any Wacom device should be fine.

Constraints & workarounds ⛔↪️

To successfully exploit the arbitrary file write vulnerability we must face the following constraints:

1. We must create the %windir%\Temp\wactemp mount point before Wacom_Tablet.exe creates the %windir%\Temp\wactemp folder (otherwise we'll not be able to create the mount point).
2. The PC must be connected to the Internet (otherwise Wacom_Tablet.exe will not be able to download the update.xml file).
3. We must have a Wacom device (otherwise we won't be able to trigger Wacom_Tablet.exe).

To face the previous constraints, I came up with the following workarounds:

1. We've two possibilities:
   1. The system administrator installs the Wacom Driver and we've the possibility to log into our account before he connects a Wacom device.
      In this case Wacom_Tablet.exe has never been triggered and, consequently, the %windir%\Temp\wactemp folder has not been created yet.
   2. We create the %windir%\Temp\wactemp mount point before the system administrator installs the Wacom Driver.
      We don't know if the system administrator will install it but, if he does, we'll be able to exploit the vulnerability even if he will connect a Wacom device before we can log into our account.
2. If the PC can be connected to the Internet the problem doesn't arise, otherwise we've two possibilities:
   1. If the PC can use a Wi-Fi or Bluetooth connection, we can use our mobile phone as an Internet hotspot.
   2. If the PC has no connections, we can use a mobile broadband modem or, more simply, we can connect a wireless USB (in this second case, we're in the same situation described in the previous point, so we can use our mobile phone as an Internet hotspot).
3. This last problem is quite difficult to solve (for me, of course 😢); in the next paragraph I propose the only possible workaround I found.

Wacom USB device plugging\unplugging simulation 🔌

Is it possible to trigger Wacom_Tablet.exe without plugging or unplugging a Wacom device?
I analyzed several executable files (which are installed during the installation of the Wacom Driver) through static analysis to look for some interesting parameters that could be used to trigger Wacom_Tablet.exe, forcing it to download the update.xml file, but I didn't find anything interesting.
I tried to emulate a Wacom device on Windows but, the only emulators I found were those of Wacom PenPartner tablet (already included in QEMU), and those developed by Nicholas Sherlock (for Wacom Bamboo and Wacom Intuos 5 graphics tablet), which can be added to QEMU.
Unfortunately all three emulators are designed to run on QEMU, and my goal is to emulate a Wacom device on Windows, not on a Windows virtual machine running within QEMU.
At this point, the only plausible way I’ve found to trigger Wacom_Tablet.exe without plugging or unplugging a Wacom device, is to simulate (through a software) the Wacom USB device plugging (or unplugging) event.
Searching the net I found out that other people also needed, for different reasons, to simulate the USB plugging event of a particular device (as you can read here and here).
In this forum zwieblum proposes an interesting way to simulate the plugging event of a general USB device, which consists in taking a dump (the packets that are exchanged) of the initial USB device communication, and reproducing it when you want to simulate the USB device plugging.
To take a dump of the initial USB device communication on Windows, we can use the USBPcap feature on Wireshark (read this article and watch this video for more details).
To replay the captured packets back using a software (without any physical device flashing or other ways that require a physical device) it's not that simple, but usbrply is the software that's right for us.
It has been developed by John Mcmaster, and allows you to convert a .pcap file (captured USB packets) to Python or C code that replays the captured USB commands.
In our case we are interested in capturing only the first packets, which are exchanged in the first seconds in which the Wacom device is plugged-in and correctly recognized (or those exchanged at the moment of the device unplugging), to trigger Wacom_Tablet.exe.
I captured twice the packets exchanged upon plugging and five times those exchanged upon unplugging.
I configured usbrply as indicated here (with VID = 0x056A and PID = 0x0376 (taken from the string USB\VID_056A&PID_0376 (read this file to figure out how to get that string))) and tried to reproduce the captured packets back.
For some reason all the attempts to reproduce the captured packets back have failed, for both types of packages (those that should have simulated the device plugging and those that should have simulated its unplugging).
I reached out to Nicholas Sherlock to ask him for help and some possible solution but, at the moment, no solution has been found.
However, I think this is the right way to simulate a Wacom device plugging\unplugging event to trigger Wacom_Tablet.exe without connecting any real device but, at the moment, I don't have the time to understand where the catch is.
I'd like to go back to investigate this question in the future and, if in the meantime you find the catch (or an alternative solution), send me a mail at luca.barile.research@gmail.com; I'll update this paragraph by adding your solution 😉

From Arbitrary File Write\Overwrite to Windows Denial of Service 🪟❌

Another idea would be to use our Arbitrary File Write\Overwrite primitive for a permanent Windows Denial of Service attack.
If we want to deny the user to use the Windows OS (preventing it from booting properly), we could think to delete a file (or more files) necessary for its booting, like I did here.
Curiously though, searching a bit on the net I ended up on this page, which made me discover a different way (to create the %windir%\system32\cng.sys file (or folder)) to prevent Windows from booting and bring up the famous BSoD.
This may seem quite counterintuitive because it seems much more reasonable to delete some files needed to start the operating system to prevent Windows from booting, rather than creating a file (or a folder), even empty... Yet, as you can see in the PoC below, this technique works properly!

So, if we want to use the exploit shown in the previous POC to get a persistent Windows Denial of Service, all we have to do is enter %windir%\system32\cng.sys when we're asked which file we want to overwrite.
Since %windir%\system32\cng.sys doesn't exist in standard Windows installations, it will be created and, the next time Windows starts, the BSoD will be displayed (and the auto-repair Windows procedure won't be able to fix the problem).

Something more on cng.sys 🔐

What is cng.sys?
What is it for?
Why does its creation prevent Windows from booting?
From the .sys filename extension we can deduce that it's a system file, so it probably contains device drivers or hardware configurations for the system.
Here Microsoft confirms that it's a driver and, in particular, it's the Cryptography Next Generation (CNG) kernel driver.
The CNG API is the successor of CryptoAPI (which is now deprecated), and consists of several primitives that provides a set of functions useful for basic cryptographic operations.
These cryptographic operations are used by many programs to protect the user's privacy and keep its data confidential.
When Windows is installed (in my case I'm referring to Windows 10, but this probably also applies to other Windows versions), the cng.sys file doesn't exist in the %windir%\system32 folder, because it's installed into %windir%\system32\drivers folder, and only TrustedInstaller has full access on it.
Since, for the reasons just described, cng.sys is a very important Windows kernel driver, the operating system loads it from %windir%\system32\drivers at startup but, if another cng.sys file (or folder) exists in the %windir%\system32 folder, Windows loads it as well!
If the %windir%\system32\cng.sys is a fake file (or a folder), the operating system crashes during its loading, bringing up the BSoD.
This probably happens because of a wrong file search order; Windows looks for the cng.sys file first in the %windir%\system32 folder and then in the %windir%\system32\drivers (or it follows another order but, at some point, it tries to load the %windir%\system32\cng.sys file anyway).
I don't know why Windows doesn't load cng.sys only from the right folder. Can it be because in previous versions of Windows it was located in %windir%\system32, and then it was moved to %windir%\system32\drivers but the developers forgot to update its folders search order?
Probably other Windows drivers can be exploited to get a BSoD as well. Do you know another one? Send me a mail at luca.barile.research@gmail.com; I'll update this paragraph by adding a list of drivers affected by the same problem 📋

PS
Just to stay on topic... Did you know that a Security Feature Bypass vulnerability was found in cng.sys?
Take a look at CVE-2018-0902 for more details.

How to fix the vulnerability 🚑

There are several solutions:

• Create the %windir%\Temp\wactemp folder directly during the Wacom Driver installation process, so that the user can't create a mount point in its place.
  With this solution the user could still create files inside the folder, which could interfere in some way with the Wacom Drivers activities, so I don't think this is the best solution.
• Force Wacom_Tablet.exe to impersonate the user while creating the %windir%\Temp\wactemp\update.xml file.
  By doing this, the link following attack will fail because when Wacom_Tablet.exe will be redirected, it will only be able to write\overwrite files that the user can already write\overwrite on his own.
• Create the wactemp folder under %ProgramFiles%\Tablet\Wacom\ (where the user doesn't have write access).
• Check that %windir%\Temp\wactemp isn't a symbolic link before creating the update.xml file in it.
  With this solution we've the same problem described in the first point.
• Change the update process logic, checking for updates directly by querying a Wacom server, without downloading any files to a temporary folder.

Vulnerability disclosure timeline 📅

First of all, I checked if the vendor has launched a bug bounty program but, unfortunately, Wacom Technology Corporation has none and the only page where you can report something (this), doesn't speak explicitly of any acknowledgement (neither meritocratically nor economically).
At this point I followed the MITRE researcher reservation guidelines and, since Wacom Technology Corporation isn't on the CNAs partner list, the only two remaining possibilities were to contact the CNA of Last Resort (CNA-LR) through the CVE Request web form or a third-party coordinator CNAs (read this interesting article for more information on how to get a CVE published).
Since the CNA of Last Resort, as the word itself says, is the last resort (🏝️), I looked for a third-party CNA in the CNAs list and decided to contact the Zero Day Initiative CNA.
ZDI relieves you from the burden of tracking the bug with the vendor, could make a monetary offer to the researcher (CNA of Last Resort doesn't), follows a responsible vulnerability disclosure policy and has a loyalty program (CNA of Last Resort doesn't). You can learn more about their disclosure policy here.

• 2022-07-30 (GMT+1) - I discovered the vulnerability.
• 2022-08-27 (GMT-6) - I reported the vulnerability to ZDI (CASE OPENED).
• 2022-08-29 (GMT-6) - ZDI assigned the case (CASE ASSIGNED).
• 2022-09-30 (GMT+1) - I asked ZDI for an update.
• 2022-09-30 (GMT+1) - ZDI replied that they're currently experiencing high case volumes so I can expect several weeks for reply.
• 2022-10-04 (GMT-6) - ZDI investigated the case (CASE INVESTIGATED).
• 2022-10-12 (GMT+1) - ZDI replied that they aren't interested in this vulnerability because it requires a Wacom device for testing (CASE CLOSED) 🤔

At this point the only alternative left is the CNA of Last Resort (CNA-LR), so I decided to use the CVE Request web form to report the vulnerability.

• 2022-10-12 (GMT+1) - I submitted the vulnerability to CNA-LR.
• 2022-10-12 (GMT+1) - CNA-LR assigned the ID 1344351 to my request.
• 2022-11-14 (GMT+1) - CNA-LR reserved the CVE-2022-43293 ID for my vulnerability.
• 2022-12-15 (GMT+1) - I asked to CNA-LR for an update (no answare...).
• 2023-01-22 (GMT+1) - I asked to CNA-LR again for an update (no answare...).
• 2023-02-22 (GMT+1) - I asked to CNA-LR again for an update (no answare...).
• 2023-04-07 (GMT+1) - I decided to make the exploit for this vulnerability (and related report) public on my GitHub page and informed MITRE through CNA-LR.

Final considerations

The references that have been useful to me to write this article and the exploit code are already present, in the form of links, in the previous paragraphs you have read and that make up this article.
The conclusions are very similar to those that I wrote in some of my previous articles (1, 1.1, 1.2 and 2) and concern the logical vulnerabilities and the link following attack technique.
The vulnerability I described in this article is just another example of a logical vulnerability discovered through dynamic analysis using Process Monitor and, if you've read my previous articles related to logical vulnerabilities, I think that the paragraphs that might be most interesting for you are the following three: 1, 2 and 3.
In this particular scenario a device is needed to trigger the vulnerability, and find a software technique that allows the exploit to simulate its interactions (at least those necessary to trigger the vulnerability (e.g. device plugging\unplugging)), would make its presence unnecessary, and wouldn't require particular operations by the user during the exploit execution (he just has to enter the path of the file to write\overwrite).
More generally, all the exploits related to vulnerabilities that fall under this scenario would be device-independent and, therefore, more powerful. For this reason, I suggest you deepen this "software technique", and I think this is a good starting point.