Wacom Driver Local Privilege Escalation Vulnerability

CVE-2023-32163 · ZDI-CAN-16857 (0-day)

Table of Contents 📜

  1. Premise
  2. How did I discover the vulnerability?
  3. Analyzing suspicious operations of PrefUtil.exe
  4. An Arbitrary File Write primitive can be useful
  5. Oh?! Is FTD2XX.dll a phantom DLL?
  6. Different ways to escalate our privileges
  7. The Exploit
  8. POC
  9. How to fix the vulnerability
  10. Vulnerability disclosure timeline
  11. Final considerations

Premise

This article describes a vulnerability affecting Wacom Driver 6.3.46-1 and 6.3.45-1 (it probably affects older versions as well but I haven't tested them) and a way by which this vulnerability can be exploited for a Local Privilege Escalation.
Since I've already extensively detailed and discussed here a similar vulnerability, I highly recommend reading it to better understand what you’re going to read (also this and this reports can be helpful as well).

How did I discover the vulnerability?

The short answer is: by chance!
I was looking for a way to take advantage of this and this technique (via the respective /custom and /hex parameters) without resorting to the use of the WacomInstallI.txt file to pass parameters to Remove.exe.
I was essentially looking for another vulnerability that would allow me to trigger Remove.exe by passing it those parameters since probably, when Wacom will fix ZDI-CAN-16318, WacomInstallI.txt will no longer be accessible by the regular user (or at least I hope... 🤞).
I started looking for a way to trigger Remove.exe by passing it the /custom parameter through C:\Program Files\Tablet\Wacom\PrefUtil.exe, since here it's written that individual users can configure their own Wacom device settings using the Wacom Tablet Preference File Utility (PrefUtil.exe).
Playing a bit with PrefUtil.exe however, instead of finding what I was looking for, I noticed some suspicious operations and I decided to call off the search to analyze them in detail; their analysis led me to discover the vulnerability I'm about to describe.

PS Between one thing and another I no longer continued with the initial goal (to look for another vulnerability that allows to trigger Remove.exe by passing it the /custom and\or /hex parameter) 🙁
So, dear reader, do it yourself! Carrying out a responsible disclosure or, if you prefer, if you find any clues, report it to me via mail at luca.barile.research@gmail.com 📧

Analyzing suspicious operations of PrefUtil.exe 🔍

Playing a bit with the GUI of PrefUtil.exe, I noticed (using Process Monitor) that, by pressing the "Package logs" button, the C:\Wacom and C:\Wacom\Logs folders are created and the files indicated in the image below are copied into them.

As the GroupBox itself says, the files written in the C:\Wacom\Logs folder are log files used for diagnostic purposes, and there would be nothing wrong with these operations if it weren't for these two facts: Probably, if you have read this and this report, by now you will have understood that when these two situations 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.
In this case, however, I don't want to settle for an Arbitrary File Read\Write primitive (as shown in the two examples just linked); my goal is to find a way for a Local Privilege Escalation ❗

An Arbitrary File Write primitive can be useful 😁

Among the various files written by the WTabletServicePro.exe service without impersonating the regular user, Wacom_Tablet.bak.txt, Wacom_Tablet.dat.txt and WacomTouch.xml.txt are the most interesting because they're nothing more than the respective copy of %AppData%\WTablet\Wacom_Tablet.bak, %AppData%\WTablet\Wacom_Tablet.dat and %AppData%\WTablet\WacomTouch.xml with the addition of the .txt extension, as you can see from the image below.

Since the regular user has full access to the %AppData%\WTablet folder and all the files it contains, he can replace one of these files (I chose %AppData%\WTablet\WacomTouch.xml) with another one of his choice before clicking on the "Package logs" button and, as a consequence, the file chosen by the regular user will be copied by WTabletServicePro.exe to the C:\Wacom\Logs folder.
Now, by combining a mount point with a symbolic link (just like I did here and here), we can redirect WTabletServicePro.exe, forcing it to copy a file of our choice wherever we want, thus obtaining an Arbitrary File Write primitive ✔️
Note: if we redirect WTabletServicePro.exe to an already existing file, that file will be overwritten (otherwise it will be created).

From an exploit development perspective, it would be more convenient to use the Arbitrary File Write primitive programmatically, without requiring the user to interact by pressing the "Package logs" button.
For this reason I used Process Monitor hoping to find the right parameter to pass to PrefUtil.exe to trigger the "Package logs" function but, obviously, I didn't find anything useful because, by pressing the button, PrefUtil.exe doesn't need to call itself with a special parameter as it can directly call its "Package logs" function 🤦
So I tried to analyze all the strings references of all the PrefUtil.exe modules via x64dbg (as I did here) hoping to find the right parameter, and I was lucky because I found a reference to the /package-logs parameter!
This means (and I tested it) that a generic process can trigger the "Package logs" function by calling PrefUtil.exe through C:\Program Files\Tablet\Wacom\PrefUtil.exe /package-logs

Ok... And how can we use the Arbitrary File Write primitive for a Local Privilege Escalation?

Oh?! Is FTD2XX.dll a phantom DLL? 👻

When I first started hunting for vulnerabilities in Wacom Driver 6.3.45-1, before discovering this vulnerability, I found out through Process Monitor that Wacom_Tablet.exe, during the restore operation, tries to load (under the context of SYSTEM) the missing FTD2XX.dll dll following the Dynamic-Link Library search order, as you can see from the image below.

Remembering this fact, I tried to see if there was any relationship between PrefUtil.exe and Wacom_Tablet.exe, discovering (in the same way I discovered /package-logs) that PrefUtil.exe accepts the /remove parameter and, if run with that, triggers Wacom_Tablet.exe (many other operations are also performed, but their description is beyond the scope of this report) which, as shown in the previous image, tries to load the missing FTD2XX.dll dll.
Ok, as you are probably already guessing, the last thing we now have to do to escalate our privileges is to exploit the phantom DLL FTD2XX.dll through the Phantom DLL hijacking technique (which is only one of the various DLL Hijacking techniques) by performing the following simple steps:
  1. Compile a simple malicious FTD2XX.dll which, once loaded, opens the Windows Command Prompt.
  2. Using the Arbitrary File Write primitive previously described force PrefUtil.exe to copy the DLL into one of the folders where Wacom_Tablet.exe looks for it (I chose C:\Program Files\Tablet\Wacom).
  3. Force Wacom_Tablet.exe to load the malicious FTD2XX.dll via C:\Program Files\Tablet\Wacom\PrefUtil.exe /remove.
I compiled the simple malicious FTD2XX.dll using the following C++ code:

In our case the Phantom DLL hijacking technique works because Wacom_Tablet.exe doesn't use signed DLLs or particular DLL hijacking prevention techniques.
Read this article if you want to learn more about some DLL hijacking prevention techniques.
Read this article of mine if you want to learn more about the DLL Hijacking using the DLL Proxying technique.

Different ways to escalate our privileges ↖️⬆️↗️

To escalate the privileges I decided to use the technique just described (which I will deepen in the next paragraph) to enhance the discovery of the phantom dll and to illustrate an alternative way to the one followed in ZDI-CAN-16318.
However, there are other ways to take advantage of the Arbitrary File Write primitive to escalate privileges and, among them, I want to describe the following two:

The Exploit ☠️

The exploit that I've implemented and that I'm going to describe is based on the previously described technique, and performs the following steps:
  1. If the C:\Wacom folder exists, delete it and re-create it; create it otherwise.
  2. Create the C:\Wacom\Logs mount point to \RPC Control.
  3. Create the \RPC Control\WacomTouch.xml.txt symbolic link to %ProgramFiles%\Tablet\Wacom\FTD2XX.dll.
  4. Copy the malicious FTD2XX.dll to %AppData%\WTablet\WacomTouch.xml.
  5. Run PrefUtil.exe through %ProgramFiles%\Tablet\Wacom\PrefUtil.exe /package-logs.
    The following operations are performed:
    1. PrefUtil.exe starts to package the logs into C:\Wacom\Logs.
    2. WTabletServicePro.exe, running under the context of SYSTEM, tries to copy %AppData%\WTablet\WacomTouch.xml to C:\Wacom\Logs\WacomTouch.xml.txt without impersonating the current user.
    3. Since C:\Wacom\Logs is a mount point to \RPC Control, WTabletServicePro.exe tries to copy %AppData%\WTablet\WacomTouch.xml to \RPC Control\WacomTouch.xml.txt.
    4. Since \RPC Control\WacomTouch.xml.txt is a symbolic link to %ProgramFiles%\Tablet\Wacom\FTD2XX.dll, WTabletServicePro.exe copies %AppData%\WTablet\WacomTouch.xml to %ProgramFiles%\Tablet\Wacom folder and names it FTD2XX.dll.
  6. Run PrefUtil.exe through C:\Program Files\Tablet\Wacom\PrefUtil.exe /silent /remove.
    The following operations are performed silently:
    1. PrefUtil.exe performs several operations and Wacom_Tablet.exe is triggered.
    2. Wacom_Tablet.exe performs several operations and tries to load the %ProgramFiles%\Tablet\Wacom\FTD2XX.dll dll.
    3. Since FTD2XX.dll now exists (point 5.4), it's loaded into memory and executed (without any checks).
    4. FTD2XX.dll is programmed to execute a command prompt window and, since it's loaded from Wacom_Tablet.exe (which runs under the context of SYSTEM), the command prompt will also run under the same context, allowing us to escalate our privileges 🎉
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 🙄).

How to fix the vulnerability 🚑

The root cause from which everything begins is C:\Wacom\Logs.
There may be several ways to solve the problem but, in my opinion, one of the best is to avoid creating the C:\Wacom folder (and its sub-folders) on the C:\ drive and, more generally, in a location to which the regular user has full access (pay attention! As I explained here, also the C:\Windows\Temp folder isn't a good candidate, although the regular user doesn't have full access to it).

A solution would be, for example, to create the Logs folder in %ProgramFiles%\Tablet\Wacom\, where the regular user can't write to and, consequently, can't perform the previously described attack. In fact, in this case, WTabletServicePro.exe can't be redirected while copying %AppData%\WTablet\WacomTouch.xml to %ProgramFiles%\Tablet\Wacom\Logs\WacomTouch.xml.txt because the regular user can no longer create the %ProgramFiles%\Tablet\Wacom\Logs mount point since he doesn't have write access on the %ProgramFiles%\Tablet\Wacom folder.

Another idea is to force WTabletServicePro.exe to impersonate the current user while copying %AppData%\WTablet\WacomTouch.xml to C:\Wacom\Logs\WacomTouch.xml.txt.
By doing this, the link following attack will fail because when WTabletServicePro.exe will be redirected to the %ProgramFiles%\Tablet\Wacom folder, and will try to copy the malicious FTD2XX.dll into it, it will fail because, impersonating the user, it won't have the necessary rights to write the malicious file.

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.
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. Well... After only one year and six months, the vulnerability has finally been published. I think it's not necessary to add any more comments on the questionable timing 😡

Final considerations

The conclusions are the same as I wrote in my main report; I report below, for convenience, the most interesting paragraphs. Since the concepts of symbolic link and mount point have already been introduced in this and this article, check out these references if you want to examine them in depth.
Here I just want to suggest some references related to the DLL hijacking, since it's the only new concept covered in this paper; these articles may be useful to those who know nothing (or little) about it: And don't forget to read my report in which I explain how to exploit another vulnerability to get a Local Privilege Escalation!


If you liked this article, what do you think about buying me a unicorn? Yeees! I'll buy it for you! 🦄