CVE-2019–13382: Local Privilege Escalation in SnagIt

Version:Snagit 2019.1.2 Build 3596

Operating System tested on:Windows 10 1803 (x64)

Vulnerability:SnagIt Relay Classic Recorder Local Privilege Escalation through insecure file move

This vulnerability was found in conjunction with Marcus Sailler, Rick Romo and Gary Muller of Capital Group’s Security Testing Team

Vulnerability Overview

Every 30–60 seconds, the TechSmith Uploader Service (UploaderService.exe) checks the folder C:\ProgramData\TechSmith\TechSmith Recorder\QueuedPresentations for any presentation files in the *.xml format. If an invalid one is found, the service moves that file to C:\ProgramData\TechSmith\TechSmith Recorder\InvalidPresentations as SYSTEM.

Since a low privileged user has full control over the QueuedPresentations and InvalidPresentations folders, it is possible to create an invalid presentation in the QueuedPresentations folder and then place a symbolic link for that file name in the InvalidPresentations folder that points to a privileged location.

When the service checks for presentations, it will move the file out of the QueuedPresentations folder and into the InvalidPresentations folder. When it does so, the service will hit the symbolic link and write the new file into a protected location with permissions that allow the low privileged user full control over the contents, resulting in Elevation of Privilege to NT AUTHORITY\SYSTEM.

Identification and Exploitation

When assessing software for privilege escalation vulnerabilities, finding a starting point can often be overwhelming as there are many different primitives and vulnerability classes that exist. My approach often includes starting with the basics and working my way up in complexity. This process typically involves running a tool such as PowerUp , which will identify various trivial (yet common) misconfigurations.

If nothing interesting is returned, the next step is often looking for logical vulnerabilities; specifically abusing symlink/mountpoint/hardlink primitives. In order to quickly identify potential vulnerabilities that could be exploited with the linking primitives, we need to identify locations on the OS where a privileged process (often SYSTEM) is interacting with a folder or file that a low privileged user has control over. This logic is true in most logical vulnerabilities in that interesting attack surface is linked to a privileged process utilizing a resource a low privileged user controls.

When hunting for such bugs, I often start with running Process Monitor with a filter on SYSTEM processes and commonly abused filesystem locations, such as C:\ProgramData , C:\Windows\Temp and C:\Users\<username>\AppData. Such a filter might look like so:

Common default Process Monitor filter

When applying the Process Monitor filter and watching the output for a few minutes, it became apparent that UploaderService.exe was querying the C:\ProgramData\TechSmith\TechSmith Recorder\QueuedPresentations directory for any XML files:

UploaderService.exe querying for XML presentation files

Looking at the DACL on that folder, it also stood out that that BUILTIN\Users had write access:

Permissions on the QueuedPresentations folder

This is particularly interesting in that a privileged SYSTEM process (UploaderService.exe) is looking for files in a directory that low privileged users have read/write access. With this information, the next step was to give UploaderService.exe an XML file to find and see what happens.

Creating an invalid presentation file

As expected, UploaderService.exe checks C:\ProgramData\TechSmith\TechSmith Recorder\QueuedPresentations for any XML files and finds the one we created:

UploaderService.exe locating our invalid presentation file

The next question was, what does UploaderService.exe do with our XML file? Does it read it in and ingest the contents? Does it place it someplace else?

Looking at the rest of the Process Monitor output answers that question for us. In this case, UploaderService.exe takes any XML files in C:\ProgramData\TechSmith\TechSmith Recorder\QueuedPresentations and determines if the XML presentation file is valid. Since we simply echoed 1 into our XML file, the service executable determines that 1.xml is an invalid presentation and moves it to C:\ProgramData\TechSmith\TechSmith Recorder\InvalidPresentations\1.xml :

UploaderService.exe moving the invalid presentation

Looking at the C:\ProgramData\TechSmith\TechSmith Recorder\InvalidPresentations directory, BUILTIN\Users also have read/write access:

Permissions on the InvalidPresentations folder

At this point, we have identified that a SYSTEM process (UploaderService.exe) is checking a user-controlled directory for any XML files. When found, the privileged process takes the attacker supplied XML file and moves it from the QueuedPresentations folder to the InvalidPresentations folder while retaining the original file name.

Why is this interesting? This presents the opportunity to use Symbolic Links during the move file operation to accomplish a privileged file write. How you might ask? The workflow would be like so:

• Create a Symbolic Link on C:\ProgramData\TechSmith\TechSmith Recorder\InvalidPresentations\1.xml that points to C:\Windows\System32\ualapi.dll
• It should be noted that C:\Windows\System32\ualapi.dll doesn’t exist. This is a DLL we are planting to get code-execution as SYSTEM
• Write a dummy xml file to C:\ProgramData\TechSmith\TechSmith Recorder\QueuedPresentations\1.xml
• When UploaderService.exe checks C:\ProgramData\TechSmith\TechSmith Recorder\QueuedPresentations for any XML files, it will find 1.xml and move it to C:\ProgramData\TechSmith\TechSmith Recorder\InvalidPresentations\1.xml . While doing so, it will hit our Symbolic Link and instead move the file to C:\Windows\System32\ualapi.dll (while retaining the original DACL)

In theory, this should work. Let’s test it out! For the Symbolic Link, I used “CreateSymlink.exe” from James Forshaw ‘s Symbolic Link Testing Tools repo. All we need to do is place a symbolic link on C:\ProgramData\TechSmith\TechSmith Recorder\InvalidPresentations\1.xml that points to C:\Windows\System32\ualapi.dll and then create C:\ProgramData\TechSmith\TechSmith Recorder\QueuedPresentations\1.xml :

Creating symlink for the invalid presentation

With the symlink created and our dummy XML file created, we wait 60 seconds for UploaderService.exe to check the QueuedPresentations folder. When it does, it finds our 1.xml file and tries to move it to C:\ProgramData\TechSmith\TechSmith Recorder\InvalidPresentations\1.xml . When it does so, it hits our symbolic link on C:\ProgramData\TechSmith\TechSmith Recorder\InvalidPresentations\1.xml and instead writes it to C:\Windows\System32\ualapi.dll :

UploaderService.exe moving the file and hitting the symlink

We can then confirm the existence of C:\Windows\System32\ualapi.dll :

C:\Windows\System32\ualapi.dll creation

This is great and all, but shouldn’t the newly created ualapi.dll file simply inherit the permissions of the parent folder (C:\Windows\System32) and prevent a low privileged user from writing to it? That was my thought at first (before checking the DACL on the file), but UploaderService.exe uses MoveFileW() . According to the documentation, MoveFileW() retains the original DACL when moving the file on the same volume:

Documentation for MoveFileW()

While not explicitly stated, it can be inferred that if the file is not moved across volumes, it is moved with the DACL intact. This means that when UploaderService.exe hits the symbolic link on C:\ProgramData\TechSmith\TechSmith Recorder\InvalidPresentations\1.xml and tries to move the original file to C:\Windows\System32\ualapi.dll , it keeps the original DACL for 1.xml . Since it was created by a low privileged user, it has a DACL that has the low privileged user as the Owner with “FullControl” rights:

C:\Windows\System32\ualapi.dll DACL

At this point, we now have C:\Windows\System32\ualapi.dll that allows our low privileged user to write to it. This means we can simply copy over the newly created ualapi.dll file with a payload of our choosing. In this case, the payload starts cmd.exe when loaded.

Copying over a payload

We now have a payload sitting in C:\Windows\System32\ualapi.dll . This DLL gets loaded when the spooler service starts. For the PoC, all that is left is to reboot the host in order to get the spooler service to restart. Additionally, one could use the CollectorService to load the DLL without a reboot. Since this is a PoC, that is an exercise left up to the reader.

Once the host is rebooted, spoolsv.exe will load our payload from C:\Windows\System32\ualapi.dll as SYSTEM, resulting in privilege escalation:

Payload running as SYSTEM

A video of exploitation can be found here:

This vulnerability has been fixed in SnagIt versions 2019.1.3, 2018.2.4 and 13.1.7 with CVE-2019–13382. The fixed involved using when moving the file combined with a check for reparse points (FSCTL_GET_REPARSE_POINT). If a reparse point exists, it is removed.

Disclosure Timeline

As committed as SpecterOps is totransparency, we acknowledge the speed at which attackers adopt new offensive techniques once they are made public. This is why prior to publicization of a new bug or offensive technique, we regularly inform the respective vendor of the issue, supply ample time to mitigate the issue, and notify select, trusted vendors in order to ensure that detections can be delivered to their customers as quickly as possible.

• June 19th, 2019: Vulnerability identified in conjunction with Capital Group’s Security Testing Team
• June 20th, 2019: Joint disclosure with Capital Group began. Support case opened with a request for contact information for the security team at TechSmith
• June 21st, 2019: Case assigned to a handler, new comment stated that the details can be uploaded to the current case and they will be forwarded to the security team
• June 21st, 2019: Full write-up, PoC code and a demonstration video was uploaded to the open support case
• June 25th, 2019: TechSmith confirmed the vulnerability and offered temporary remediation advice. TechSmith also requested notice before public disclosure.
• June 25th, 2019: Informed TechSmith that public disclosure would be 90 days after the initial report with a note that an extension would be considered if needed.
• July 2nd, 2019: TechSmith stated a fixed build is done and set to be deployed before the end of July with a note asking if we would verify the fix
• July 2nd, 2019: Informed TechSmith that I would verify the fix
• July 3rd, 2019: TechSmith provided a private fixed build
• July 9th, 2019: Informed SnagIt that based on testing, the fix seemed sufficient
• July 23rd, 2019: Patch released, issue publicly disclosed