Netwrix Auditor Symbolic Link Privilege Escalation (CVE-2019-14969)

With the notable increase in the number of symbolic link elevation of privileges vulnerabilities on Windows platforms as of late, we at ACTIVELabs have set a goal for ourselves to find a new one. This blog post will detail finding and exploiting said vulnerability in Netwrix Auditor version 9.7 and earlier. Please note, abusing symbolic links has been leveraged for years now, particularly in the *nix world to achieve local privilege escalation and as such we’ll assume you know the idea behind it and most importantly how it can be abused. Let’s start by examining the problematic log file permissions for the effected software.

​As we can see above, the “Authenticated Users” group have full control over the “Netwrix.ADA.StorageAuditService.log” file. Now this in itself is not an issue however the following screenshot shows the process “Netwrix.ADA.StorageAuditService.exe” which runs with “NT AUTHORITY\SYSTEM” privileges write to the same file every 10 minutes for logging purposes. Also, it’s worth mentioning that the “NwDataCollectionCoreSvc” service which runs as local System account is responsible for spawning the “Netwrix.ADA.StorageAuditService.exe” binary as a child process.

​Following some basic dynamic analysis, we identify that the software has few more services that run as “NT AUTHORITY\SYSTEM” and those services will effectively try to load non-existing DLLs from the current directory upon system start. For our purposes, we chose VERSION.dll for the service “NwUserActivitySvc” with the process name of “UAVRServer.exe”.

​Next we delete the log file from the target folder.

​And then we use James Forshaw’s symboliclink testing tools found here to create the following self-explanatory symbolic link.

​Now we wait for the “Netwrix.ADA.StorageAuditService.exe” process to perform the “WriteFile” operation on the log file which ultimately result in reparse as shown below.

​At this point we delete the symbolic link and then wait for another 10 minutes for the next “WriteFile” operation to occur. Now, checking the security settings of the newly created VERSION.dll file under the “C:\Program Files (x86)\Netwrix Auditor\User Activity Video Recording” directory we can see the “Authenticated Users” group have full control.

​Let’s copy the content of a DLL we’ve constructed that will spawn a calc.exe upon invocation of the VERION.dll module.

​Lastly, we restart the “NwUserActivitySvc” service from an administrative command prompt to simulate system reboot and verify that calc.exe is indeed running as “NT AUTHORITY\SYSTEM” under Process Explorer.

In a nutshell, this vulnerability allows normal users (test user account in this case) to escalate privileges to “NT AUTHORITY\SYSTEM”. After reporting this vulnerability to the vendor, a patch was released in version 9.8 by applying more restrictive Discretionary Access Control List (DACL) on “Netwrix.ADA.StorageAuditService.log” file.

​Please note all testing was performed on Windows Server 2016 Standard instance. Feel free to reach out at labs@activecyber.us if you have any questions. Also, see the link here for complete list of ACTIVELabs advisories.

Affected Products

• Netwrix Auditor version 9.7 and older

 
Disclosure Timeline

• 02-19-19: ACTIVELabs sent vulnerability details to CERT/CC

• 02-20-19: CERT/CC acknowledge report and requested to contact the effected vendor

• 02-22-19: ACTIVELabs contacted vendor via contact us form

• 02-28-19: Vendor responded requesting details

• 03-01-19: ACTIVELabs report sent

• 03-04-19: Vendor acknowledge report

• 03-15-19: ACTIVELabs requested an update

• 03-25-19: Vendor responded that they will come up with an action plan and get back with us

• 03-29-19: ACTIVELabs requested an update

• 04-01-19: Vendor responded with purposed fix plan

• 04-02-19: ACTIVELabs suggested disclosure timeline to vendor

• 04-23-19: CERT/CC requested an update

• 04-26-19: Vendor provided patch release date

• 05-14-19: Netwrix Auditor version 9.8 with a patch released

• 05-31-19: ACTIVELabs requested an update

• 06-04-19: Vendor requested more time to implement a guided upgrade program for effected customers

• 06-05-19: ACTIVELabs informed vendor to hold off on public disclosure until further notice

• 07-05-19: ACTIVELabs confirmed the patch has nullified the vulnerability

• 07-19-19: ACTIVELabs requested an update regarding releasing vulnerability information

• 07-23-19: Vendor requested to hold off until the week of August 12 to make sure most of the customers are up-to-date

• 08-12-19: ACTIVELabs publishes this advisory

• 08-12-19: ACTIVELabs request CVE entry from MITRE