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:ProgramDataTechsmithTechSmith RecorderQueuedPresentations” for any presentation files in the “*.xml” format. If an invalid one is found, the service moves that file to “C:ProgramDataTechsmithTechSmith RecorderInvalidPresentations” 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 AUTHORITYSYSTEM.

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:WindowsTemp and C:UsersAppData. Such a filter might look like so:

When applying the Process Monitor and watching the output for a few minutes, it became apparent that “UploaderService.exe” was querying the “C:ProgramDataTechsmithTechSmith RecorderQueuedPresentations” directory for any XML files:

Looking at the DACL on that folder, it also stood out that that “BUILTINUsers” had write access:

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.

As expected, “UploaderService.exe” checks “C:ProgramDataTechsmithTechSmith RecorderQueuedPresentations” for any XML files and finds the one we created:

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:ProgramDataTechsmithTechSmith RecorderQueuedPresentations” 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:ProgramDataTechsmithTechSmith RecorderInvalidPresentations1.xml”:

Looking at the “C:ProgramDataTechsmithTechSmith RecorderInvalidPresentations” directory, “BUILTINUsers” also have read/write access:

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:ProgramDataTechsmithTechSmith RecorderInvalidPresentations1.xml” that points to “C:WindowsSystem32ualapi.dll”
  • It should be noted that “C:WindowsSystem32ualapi.dll” doesn’t exist. This is a DLL we are planting to get code-execution as SYSTEM
  • Since the process is privileged “SYSTEM”, it will have the correct permissions to write this file.
• Write a dummy xml file to “C:ProgramDataTechsmithTechSmith RecorderQueuedPresentations1.xml”
• When “UploaderService.exe” checks “C:ProgramDataTechsmithTechSmith RecorderQueuedPresentations” for any XML files, it will find “1.xml” and move it to “C:ProgramDataTechsmithTechSmith RecorderInvalidPresentations1.xml”. While doing so, it will hit our Symbolic Link and instead move the file to “C:WindowsSystem32ualapi.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:ProgramDataTechsmithTechSmith RecorderInvalidPresentations1.xml” that points to “C:WindowsSystem32ualapi.dll” and then create “C:ProgramDataTechsmithTechSmith RecorderQueuedPresentations1.xml”:

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:ProgramDataTechSmithTechSmith RecorderInvalidPresentations1.xml”. When it does so, it hits our symbolic link on “C:ProgramDataTechSmithTechSmith RecorderInvalidPresentations1.xml” and instead writes it to “C:WindowsSystem32ualapi.dll”:

We can then confirm the existence of “C:WindowsSystem32ualapi.dll”:

This is great and all, but shouldn’t the newly created “ualapi.dll” file simply inherit the permissions of the parent folder (C:WindowsSystem32) 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:

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:ProgramDataTechSmithTechSmith RecorderInvalidPresentations1.xml” and tries to move the original file to “C:WindowsSystem32ualapi.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:

At this point, we now have “C:WindowsSystem32ualapi.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.

We now have a payload sitting in C:WindowsSystem32ualapi.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:WindowsSystem32ualapi.dll as SYSTEM, resulting in privilege escalation:

A video of exploitation can be found here: https://www.youtube.com/watch?v=V90JRwlaHRY&feature=youtu.be

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 _time64 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 to transparency, 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

Comments are closed.