Wacom Driver Arbitrary File Deletion Vulnerability

Table of Contents 📜

Premise How did I discover the vulnerability? Analyzing uninstaller operations An Arbitrary File Deletion primitive The Exploit POC From Arbitrary File Deletion to Local Privilege Escalation From Arbitrary File Deletion to Windows Denial of Service Something more on CatRoot folder 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 for an arbitrary file deletion.
I suggest to read this article to better understand some points of what you’re going to read.

How did I discover the vulnerability?

Reading some blogs of other vulnerability researchers I found that sometimes, during the installation of a program, if the folders in which the program installs files (that should only be controlled by the system administrator) already exist, files are installed anyway and the access permissions to the folders aren't changed, allowing an unprivileged user to have full control on them (he just has to create these folders before the program gets installed).
This situation can lead to security issues (as in this case) and, since I've already found other vulnerabilities (this and this) affecting Wacom Driver for Windows, I decided to check if it also is affected by this kind of vulnerability.
Unfortunately (for us) the installer doesn't allow the user to choose the installation folder, the created folders that the unprivileged user can control are used by processes that impersonate the current user and the remaining folders have a secure DACL.
At this point, since the installer didn't get me anywhere, I tried to analyze the uninstaller and, in this case, I was luckier 🙃

Analyzing uninstaller operations 🔍

If the system administrator decides to uninstall Wacom Driver (administrator privileges are required), the uninstaller triggers %ProgramFiles%\Tablet\Wacom\32\Remove.exe which runs under the context of SYSTEM.
Once started, Remove.exe, as the name suggests, begins to remove all the files created during the installation process and by the user while using the Wacom device. It also removes files located in folders over which the unprivileged user has full control by impersonating the current user but, for some reason, a small number of files are deleted without impersonating the user, even if they're located in folders over which the unprivileged user has full control 🤔
I used Process Monitor to identify this small number of files; they're three and Remove.exe tries to delete them from different folders:

1. Wacom_Tablet.dat
   • %UserProfile%\Application Data\WTablet\Wacom_Tablet.dat
   • %UserProfile%\AppData\Roaming\WTablet\Wacom_Tablet.dat
   • %UserProfile%\Roaming\WTablet\Wacom_Tablet.dat
   • %UserProfile%\WTablet\Wacom_Tablet.dat
2. Tablet.dat
   • %UserProfile%\Application Data\WTablet\Tablet.dat
   • %UserProfile%\AppData\Roaming\WTablet\Tablet.dat
   • %UserProfile%\Roaming\WTablet\Tablet.dat
   • %UserProfile%\WTablet\Tablet.dat
3. WacomTouch.xml
   • %UserProfile%\Application Data\WTablet\WacomTouch.xml
   • %UserProfile%\AppData\Roaming\WTablet\WacomTouch.xml
   • %UserProfile%\Roaming\WTablet\WacomTouch.xml
   • %UserProfile%\WTablet\WacomTouch.xml

It's interesting to note that some folders do not exist (they've never been created by the installer), but Remove.exe tries to delete some files located in them anyway.
One of these folders, for example, is %UserProfile%\WTablet.
I assume that in some Wacom Driver versions prior to 6.3.46-1, these folders were used. Later, they've not been used anymore, and the developers forgot to remove them from the list of folders in which Remove.exe must remove some files.

An Arbitrary File Deletion primitive 🗑️

Probably, if you have read these three articles (1, 2 and 3), by now you will have understood that when the situation just described occur, 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.
Our situation is slightly different from the linked ones because instead of redirecting a file writing, we redirect a file deletion, therefore we'll get an Arbitrary File Deletion primitive.
I decided to create the %UserProfile%\WTablet NTFS volume mount point to \RPC Control (I chose this folder because it doesn't exist, so I don't even have to worry about deleting it and, at the same time, it avoids causing any problems to processes that might try to access the files it contains).
Then I created a Symbolic link from \RPC Control\Tablet.dat to %windir%\win.ini.
Now the workflow is quite simple: when the system administrator decides to uninstall Wacom Driver, Remove.exe is triggered and, among the various operations it carries out, it will try to delete %UserProfile%\WTablet\Tablet.dat.
Since %UserProfile%\WTablet is a mount point to \RPC Control, Remove.exe will be redirected and will try to delete \RPC Control\Tablet.dat.
Since \RPC Control\Tablet.dat is a symbolic link to %windir%\win.ini, Remove.exe will be redirected again, and will try to delete %windir%\win.ini (and it will succeed because it's running under the context of SYSTEM).
Obviously, in this case, I chose to delete %windir%\win.ini as Proof of Concept, since win.ini is a file that the unprivileged user cannot delete, but we can choose to delete the file we prefer.

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 delete (let's suppose %windir%\win.ini).
2. Create the %UserProfile%\WTablet mount point to \RPC Control.
3. Create the \RPC Control\Tablet.dat symbolic link to %windir%\win.ini.
4. Wait for the system administrator to uninstall Wacom Driver.
5. When the system administrator decides to uninstall Wacom Driver, Remove.exe is triggered (and runs under the context of SYSTEM).
6. Remove.exe will try to delete %UserProfile%\WTablet\Tablet.dat.
7. Since %UserProfile%\WTablet is a mount point to \RPC Control, Remove.exe will be redirected and will try to delete \RPC Control\Tablet.dat.
8. Since \RPC Control\Tablet.dat is a symbolic link to %windir%\win.ini, Remove.exe will be redirected again, and will try to delete %windir%\win.ini.
9. Remove.exe deletes %windir%\win.ini.

Here you can find my exploit.

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 for Wacom Driver 6.3.46-1 but, most likely, it also works for the previous versions (and I hope not on the future ones 🙄).

From Arbitrary File Deletion to Local Privilege Escalation 🔥

When you’ve found an Arbitrary File Deletion you'd probably like to use it to achieve something more useful, like a Local Privilege Escalation, but you don't know how to do it.
I didn’t know how to do it either, but Abdelhamid Naceri (aka klinix5 or halov) did 🙇
Abdelhamid has found a brilliant technique to achieve this result, and allowed Simon Zuckerbraun (aka HexKitchen) to publish this wonderful article (read it!).
In a nutshell, Abdelhamid teaches us the following things:

1. The Windows Installer service (which is responsible for performing installations of applications) creates the C:\Config.Msi folder and populates it with rollback information (rollback files (.rbf) and scripts (.rbs)), in case it should restore them if the installation, for some reason, cannot be completed.
2. If an attacker has an Arbitrary Folder Delete vulnerability he can uses it to remove C:\Config.Msi immediately after Windows Installer creates it, and can recreates it with a weak DACL (an unprivileged user is allowed to create folders at C:\).
   At this point, once Windows Installer creates its rollback scripts within C:\Config.Msi, the unprivileged user can replace one of them with a malicious .rbs script that drops a malicious DLL once triggered (upon rollback).
3. If the malicious .rbs script drops a malicious HID.DLL into C:\Program Files\Common Files\microsoft shared\ink folder, the unprivileged user could get a SYSTEM command prompt by starting C:\Windows\System32\osk.exe (the On-Screen Keyboard) and then switching to the Secure Desktop (for example by pressing Ctrl+Alt+Canc).
4. In the NTFS, the metadata (index data) associated with a folder is stored in an alternate data stream on that folder.
   For example, if the folder is named C:\MyFolder, then the its index data is in the data stream C:\MyFolder::$INDEX_ALLOCATION (here you can find more information).
5. Deleting the folder data stream C:\MyFolder::$INDEX_ALLOCATION effectively deletes C:\MyFolder from the file system.
   REMEMBER: We can delete the folder data stream (eg C:\MyFolder::$INDEX_ALLOCATION) only if the associate folder (eg C:\MyFolder) is empty!
6. A data stream name (eg C:\MyFolder::$INDEX_ALLOCATION), can be passed to APIs that expect the name of a file, as DeleteFileA or DeleteFileW.
   If a privileged process simply calls DeleteFileA or DeleteFileW on a data stream, without performing other associated actions (such as checking the attributes of the specified file), the data stream will be deleted.

All this things tells us that if we're able to trick a privileged process to delete an arbitrary file (as we did here), and the process uses the DeleteFileA or DeleteFileW functions without performing other associated actions (just like Remove.exe does), then we can use the aforementioned Abdelhamid exploit technique to get a SYSTEM command prompt, gaining our Local Privilege Escalation.
However we've to consider that this technique is not reliable at 100% because it has to win a race condition: when Windows Installer creates the C:\Config.Msi folder, we've to delete and recreate it before Windows Installer writes its rollback files and scripts, otherwise we will no longer be able to delete it (because it would no longer be empty).
To win the race we can use an Opportunistic Lock (OpLock), and polling continuously for the existence of C:\Config.Msi, but there's still a chance in which Windows Installer could win the race writing its rollback files and scripts in the folder before we delete and recreate it, so this technique can fail sometimes (to increase the chances of winning the race, it's recommended a system with a minimum of 4 processor cores).

Abdelhamid implemented this technique in an exploit, which awaits the attempt of a privileged process to delete the C:\Config.Msi folder (triggerable using our Arbitrary File Deletion primitive (or with an Arbitrary Folder Deletion)), and then performs the aforementioned steps to drop the malicious HID.DLL into C:\Program Files\Common Files\microsoft shared\ink folder, which allow us to gain our Local Privilege Escalation.
The source code of the exploit was published (with minor modifications) here and, for convenience, I copied the original repository here, with the addition of the x64 compiled projects.
Here you can download the exploit compiled for a 64-bit system.

And if we can only delete the contents of an arbitrary folder (Arbitrary Folder Contents Delete primitive), can we gain an Arbitrary Folder Deletion primitive to use for a Local Privilege Escalation with the exploit technique previously discussed?
Yes, we can! Using the Abdelhamid exploit techniques (described in the "From Folder Contents Delete to SYSTEM EoP" paragraph of Simon's article).
We must first gain an Arbitrary Folder Deletion primitive using our Arbitrary Folder Contents Delete primitive (here you can find the exploit that allows us to do this (compiled for a 64-bit system) and here its source code) and then we've to use the Arbitrary Folder Deletion primitive with the exploit previously discussed (we're chaining both the exploits).

So, returning to Wacom Driver, how can we use our Arbitrary File Deletion primitive to gain a Local Privilege Escalation?
We just need to run the Abdelhamid exploit (FolderOrFileDeleteToSystem.exe) before using our Arbitrary File Deletion primitive and, instead of letting the user choose which file to delete, we must use the Arbitrary File Deletion primitive to delete the C:\Config.Msi folder data stream (C:\Config.Msi::$INDEX_ALLOCATION).
Implementing these changes in our previous exploit, we should get something like this:

Here you can find the modified exploit.

Note:

• CreateMountPoint.exe, CreateSymlink.exe and FolderOrFileDeleteToSystem.exe must be in the same folder of Exploit.bat
• This is just a draft; I haven't tested this exploit.
• FolderOrFileDeleteToSystem.exe isn't reliable at 100% because it must win a race condition.
• Since, with high probability, Wacom Driver will be uninstalled by the system administrator when he's logged in with his account, it makes no sense to bring up a SYSTEM command prompt to him 😂
  For example, it would be more reasonable to modify HID.DLL so that, once it's running, it silently adds the unprivileged user's account to the administrators group.

From Arbitrary File Deletion to Windows Denial of Service 🪟❌

Another idea would be to use our Arbitrary File Deletion primitive for a Windows Denial of Service attack.
If we want to deny the use of a particular program we could delete a file necessary for its proper functioning, therefore, in the same way, if we want to deny the user to use the Windows OS (preventing it from booting properly), we could delete a file necessary for its booting.
Searching a bit on the net I found various files necessary for Windows booting, but all of them can only be deleted by TrustedInstaller; SYSTEM and Administrators can only read and execute them (as shown in this example).
Continuing my research I ended up on this page, which made me discover a way (to create the %windir%\system32\cng.sys file (or folder)) to prevent Windows from booting and bring up the famous BSoD, but we've only an Arbitrary File Deletion primitive, therefore we can't create any file or folder.
At this point I decided to switch to a "fail-and-fix" approach, starting to delete some files (potentially necessary for Windows booting) using the Administrator account and looking at what happened on reboot.
The following summary table illustrates all the attempts, gradually more selective, made to find one or more files that the Admin can delete and which, if deleted, will bring up the BSoD on reboot:

CMD command	BSoD on reboot
rmdir "C:\Windows" /s /q	YES
del "C:\Windows\*.*"	NO
rmdir "C:\Windows\Servicing\LCU" /s /q	NO
rmdir "C:\Windows\System" /s /q	NO
rmdir "C:\Windows\System32" /s /q	YES
rmdir "C:\Windows\System32\Drivers" /s /q	NO
rmdir "C:\Windows\System32\0409" /s /q	NO
rmdir "C:\Windows\System32\AdvancedInstaller" /s /q	NO
rmdir "C:\Windows\System32\am-et" /s /q	NO
rmdir "C:\Windows\System32\AppLocker" /s /q	NO
rmdir "C:\Windows\System32\appraiser" /s /q	NO
rmdir "C:\Windows\System32\ar-SA" /s /q	NO
rmdir "C:\Windows\System32\bg-BG" /s /q	NO
rmdir "C:\Windows\System32\Boot" /s /q	NO
rmdir "C:\Windows\System32\BthProps" /s /q	NO
rmdir "C:\Windows\System32\CatRoot2" /s /q	NO
rmdir "C:\Windows\System32\CatRoot" /s /q	YES
del "C:\Windows\System32\CatRoot\{F750E6C3-38EE-11D1-85E5-00C04FC295EE}\*.*"	YES
del "C:\Windows\System32\CatRoot\{F750E6C3-38EE-11D1-85E5-00C04FC295EE}\Microsoft-Windows-Client-Desktop-Required-Package0516~31bf3856ad364e35~amd64~~10.0.19041.1826.cat" del "C:\Windows\System32\CatRoot\{F750E6C3-38EE-11D1-85E5-00C04FC295EE}\Microsoft-Windows-Client-Desktop-Required-Package0416~31bf3856ad364e35~amd64~~10.0.19041.508.cat"	YES

From the attempts listed in the table above I verified that, by deleting Microsoft-Windows-Client-Desktop-Required-Package0516~31bf3856ad364e35~amd64~~10.0.19041.1826.cat and Microsoft-Windows-Client-Desktop-Required-Package0416~31bf3856ad364e35~amd64~~10.0.19041.508.cat, the BSoD will appear on reboot.
Most likely also deleting other files located in the {F750E6C3-38EE-11D1-85E5-00C04FC295EE} folder is sufficient to bring up the BSoD, but I was unable to bring it up by deleting less than two files (I confess that my search was not exhaustive 😬).
Even more likely, there're other files located somewhere in the System32 folder (or some of its subdirectories) which, if deleted by the admin, will bring up the BSoD on reboot.
If you find a single file located in the Windows folder (or some of its subdirectories), erasable by the administrator which, if deleted, will bring up the BSoD on reboot, send me a mail at luca.barile.research@gmail.com, please.

The Microsoft Windows Client Desktop Required Package is divided into numbered sub-packages. The criterion I used to identify which sub-packages to delete to gain the BSoD on reboot was to list them and delete the two largest ones (Package0516 and Package0416 in my case), according to the idea that the more information you delete, the worse it is 😅
It may be that your packages are numbered differently; take note of the two largest.
It may be that the {F750E6C3-38EE-11D1-85E5-00C04FC295EE} folder has a different name on your pc (its name is a Curly Braced GUID String); take note of its name.

At this point we just have to modify our exploit in order to delete the two largest Microsoft Windows Client Desktop sub-packages found, and restart the computer to bring up the BSoD on reboot.
As I wrote here, during the uninstallation process, Remove.exe, tries to remove three different files (Wacom_Tablet.dat, Tablet.dat and WacomTouch.xml) from folders on which the regular user has full control. So, in a similar way to what has already been done in the previous exploit, we can delete three files instead of one, using NTFS volume mount points and symbolic links (in this case we just need to delete two files (I chose Tablet.dat and WacomTouch.xml)):

In this case we need to delete the %AppData%\WTablet folder before creating the mount point, because it could exist and contain files (unlike the %UserProfile%\WTablet).
If everything works fine, you should be able to bring up the BSoD on reboot, as shown in my following PoC:

Here you can find the modified exploit.

Note:
If you want to delete three sub-packages instead of two, to increase the chances of getting a BSoD on reboot, you can also take advantage of the Wacom_Tablet.dat file, in the same way we've exploited WacomTouch.xml.
Deleting multiple files (max 12) is also possible, knowing the order in which Remove.exe deletes files and using an opportunistic lock.
The idea is to lock Remove.exe (via the opportunistic lock) after it has deleted the first file, change the symbolic link, unlock Remove.exe (by releasing the opportunistic lock) and relock it after it has deleted the second file.
The procedure must be repeated up to the last file, and obviously requires a slightly more complex exploit code.

Something more on CatRoot folder 📁

What is CatRoot folder for?
What kind of files does it contain?
What are the files contained in it for?
Why are some of them needed for Windows booting?
Here and here you can find some answers to the above questions; I'll try to summarize the information that I found on the net in a nutshell...
The CatRoot folder is necessary for the Windows Update process because it's responsible for storing the Windows Update Package (saved as Catalog Files (.cat)), and takes active part in their installation.
During the Windows Update process the CatRoot files are also necessary to deploy the %windir%\System32\catroot2\edb.log log file, and the Windows updates are temporarily stored in the %windir%\SoftwareDistrubution folder before being installed.
The .cat files are digitally-signed and are used as a digital signature for an arbitrary collection of files. Every .cat file contains a collection of cryptographic hashes (thumbprints), and each thumbprint corresponds to a file that is included in the collection.
For example, if you want to use a new device under Windows, you need to install its driver package, which consists of a collection of software components necessary for the proper functioning of the device.
When you plug the device to your PC for the first time, the Plug and Play (PnP) Windows component recognizes the digitally-signed .cat file of that particular device driver package, and check that every software component included in the package corresponds to the relative thumbprints included in the .cat file.
If even one software doesn't match its relative thumbprint, the whole driver package is considered invalid, and won't be installed.
This technique prevents the installation of possible ad hoc modified drivers by an attacker for malicious purposes.
The CatRoot folder contains many .cat files, each related to a particular package of some product.
In our case, among the different packages, there were many packages related to Microsoft Windows Client Desktop and, among these packages, two of them are certainly needed for Windows booting: Microsoft-Windows-Client-Desktop-Required-Package0516 and Microsoft-Windows-Client-Desktop-Required-Package0416.
I don't know why they are needed for Windows booting but, based on what I've just said, I assume that, while the operating system is loading, Windows checks the integrity of, at least, some Windows Client Desktop packages, including packages 516 and 416. As the .cat files related to these packages have been deleted, Windows can't verify their integrity and will consider them invalid, causing problems to the Windows Client Desktop software and, consequently, to the start of the Windows booting itself.
As you can see from the previous PoC, once the BSoD appears, Windows starts its auto-repair procedure to try to fix the problem but, despite the various attempts, it fails.
So, if some files located in the CatRoot folder are crucial for the correct Windows booting, why doesn't Windows make a backup copy of them, accessible only by TrustedInstaller, to be restored during the auto-repair procedure?
Or why not assign write access to these files only to TrustedInstaller? 🤔

How to fix the vulnerability 🚑

First of all I recommend to the developers to avoid removing, during the uninstallation process carried out by Remove.exe, the files (or folders) that were never created during the Wacom Driver installation process (like %UserProfile%\WTablet).
Secondly, to fix the vulnerability, it's sufficient that Remove.exe impersonates the user while deleting files and folders over which the regular user has full control. By doing this, the link following attack will fail because when Remove.exe will be redirected, it will only be able to delete files that the user can already delete on his own.

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-20 (GMT+1) - I discovered the vulnerability.
• 2022-07-21 (GMT-6) - I reported the vulnerability to ZDI (CASE OPENED).
• 2022-07-22 (GMT-6) - ZDI assigned the case (CASE ASSIGNED).
• 2022-08-15 (GMT-6) - ZDI investigated the case (CASE INVESTIGATED).
• 2022-08-18 (GMT+1) - ZDI replied that they aren't interested in this vulnerability because having an administrator uninstall the product is considered too much user interaction (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-08-18 (GMT+1) - I submitted the vulnerability to CNA-LR.
• 2022-08-18 (GMT+1) - CNA-LR assigned the ID 1315571 to my request.
• 2022-09-16 (GMT+1) - CNA-LR reserved the CVE-2022-38604 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 exploits for this vulnerability (and related reports) 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 this and this.