SnagIt Privilege Escalation Exploit

Introduction

This article is meant to be a PoC walk through that validates the Snagit 2019.1.2 version’s privilege escalation exploit (CVE-2019-13382). It also follows the strategies of Matt Nelson’s blog post (found here) on the vulnerability.

What is Snagit? Snagit is a program that allows users to take captures and video of their screen and audio outputs. It was created by TechSmith back in 1990, and works on Windows and Mac OS. Snagit utilizes TechSmith’s Uploader dubbed “UploaderService.exe”, that allows for direct integration with the TechSmith Relay resource (which is just a video creation/sharing platform).

Vulnerability Description

In Snagit version 2019.1.2 the SYSTEM process, UploaderService.exe, can be abused to escalate a users privilege. This is done by inserting an illegitimate presentation file into the C:\ProgramData\TechSmith\TechSmith Recorder\QueuedPresentations folder, then creating a symbolic link in C:\ProgramData\TechSmith\TechSmith Recorder\InvalidPresentations that directs UploaderService.exe to a privileged location.

Lab Setup

To get ready, I used Virtual Box to spin up a Windows 10 virtual machine for the test environment. After booting up the virtual machine, I went into the settings and created a new standard user with low privileges. You will want to do this in order to actually validate the PoC. From there, switch users and log onto the low privileged user’s account you just created. Once logged in, go download and install the vulnerable version of Snagit (2019.1.2 3596), Visual Studio 2013, and the latest version of Process Monitor. Process Monitor is a free Windows Sysinternals tool, that monitors and shows all file system activity in real-time.

Installing Snagit & Process Monitor

After successfully installing all applications you’re ready to get started!

Exploit Time

You need to be able to identify where the vulnerability actually takes place, so the first step is to launch Snagit and Process Monitor. Since we know that it’s specifically abusing symlinks, you can set a filter within Process Monitor to narrow down the returned results to show only what we want, and in this case it’s the SYSTEM processes we’re interested in.

Applying filters within Process Monitor:

1. Click the “Filter” option in the top navigation, then click “Filter” again.
2. Then within the filter options create the filter “ Integrity is System” and click add.
3. Continue creating three other filters that include these paths: C:\ProgramData, C:\Windows\Temp and C:\Users\<username>\AppData.
4. After adding all of the wanted filters, click Apply.

Process Monitor filters options

After the filters have been applied, watch the results for a few minutes until you see the UploaderService.exe making requests to C:\ProgramData\TechSmith\TechSmith Recorder\QueuedPresentations.

UploaderService.exe query details

As you can see from the screenshot above, the UploaderService.exe is looking inside C:\ProgramData\TechSmith\TechSmith Recorder\QueuedPresentations and asking if it has any XML files.

So far we’re on the right track, but from there we need to take a look at the DACL of the folder to find out what permissions we have for it. DACL stands for “Discretionary Access Control List” which is an internal list that’s connected to an object in Active Directory that tells which users and groups can access that object and what operations they can perform. To look at the DACL, open up Power Shell and type the command in the picture below

ACL permissions for QueuedPresentations folder

From what it tells us, our low privileged user is allowed read/write access on the folder. Now let’s feed a test XML file to the UploaderService.exe and see what it does with it. First create a file and append it to the \QueuedPresentations folder, then list the contents of the directory to validate its creation.

Creating an XML file

After waiting a minute, you should see that UploaderService.exe checks the \QueuedPresentations directory again for any XML files, and it successfully found our test XML file!

After closing out of the Event Properties window, notice that UploaderService.exe moved the XML file to the directory C:\ProgramData\TechSmith\TechSmith Recorder\InvalidPresentation just like we knew it was supposed to.

Again, use Power Shell to view the DACL of this folder, and notice that the BUILTIN\Users have read and write permissions here as well.

Now this is where symbolic links (AKA symlinks) come into play. Symlinks are a file system attribute that allows a user to create a link to a particular folder or file. By confirming the permissions that we have for these directories, we can now attempt to abuse the file move process to try and get a privileged file to be written. We’re going to create a symlink that actually points to C:\Windows\System32\ualapi.dll that will run with system privileges. The ualapi.dll is a native file within the Windows OS that can be loaded and executed in any running process.

However, by default local users aren’t allowed to create symlinks without privileges being given to them, so there is a tool that we can use as a workaround.

How to compile the CreateSymlink.cpp file:

1. Clone or Download the Symbolic Link Testing Tools repository from GitHub
2. Launch Visual Studio 2013
3. Once started, click File > Open > File and navigate to symboliclink-testing-tools-master\CreateSymlink folder and choose CreateSymlink.cpp
4. Then, click Build > Build Solution to open the Solution Explorer if not already opened
5. This will then compile and save an EXE program for you to run

How to make a symbolic link:

• Open up a command prompt window and navigate to where your CreateSymlink.exe file is
• Execute this command to make the symlink

.\CreateSymlink.exe "C:\ProgramData\TechSmith\TechSmith Recorder\InvalidPresentations\hello.xml" "C:\Windows\System32\ualapi.dll"

• After successfully running the above command, make the dummy XML file using the echo command:

echo "hello" >> "C:\ProgramData\TechSmith\TechSmith Recorder\QueuedPresentations\hello.xml"

Basically what this will accomplish is once the UploaderService.exe queries the \QueuedPresentations folder again, it will find our hello.xml file and then move it to \InvalidPresentations\hello.xml. But, while completing this process it will touch the symlink and actually move the file to C:\Windows\System32\ualapi.dll.

Exploit Automation

Since the DACL is still retained, the user has read/write access over the C:\Windows\System32\ualapi.dll. This will allow us to write a payload and copy it over the original ualapi.dll file.

The ualapi.dll will automatically begin when the spooler service starts, so to finish this PoC I had python execute cmd.exe when the library loads.

import os
os.system('cmd')

From there, reboot your Windows machine and once spoolsv.exe starts, you should be able to get a command prompt with escalated privileges (:

Reflection and Remediation

As a user of Snagit myself, after finding out about this CVE I immediately checked to make sure that mine was up-to-date. Going through and validating this exploit has shown me a different way to accomplish privilege escalation. It also shows how “unimportant” software programs can leave us vulnerable and we wouldn’t even notice it. That is why it’s important to update not just our operating system, but even screen capture software like Snagit as well. This vulnerability was fixed with Snagit versions 2019.1.3, 2018.2.4 and 13.1.7. Now when the Uploader Service moves any presentation files from \QueuedPresentations, it uses the FSCTL_GET_REPARSE_POINT control code to remove any symlinks.

TechSmith themselves state that the best solution to address this vulnerability is to update your Snagit to the latest version. You can accomplish that by clicking Help > Check for updates in Snagit.

For people who are unable to update, disabling the Uploader Service will solve the problem (only do this if you/your company doesn’t use TechSmith Relay.)

To disable the Uploader Service:

1. Close out of Snagit
2. In File Explorer, navigate to C:\Program Files (x86)\Common Files\TechSmith Shared\Uploader
3. Find the cmd file named UninstallAndRemoveUploader.cmd and right-click > Run as administrator
4. Then delete the Uploader folder
5. Reboot your machine after deleting the folder