Shulou(Shulou.com)05/31 Report--

An example analysis of privilege escalation vulnerability in Windows Standard Collector service. In view of this problem, this article introduces the corresponding analysis and solution in detail, hoping to help more partners who want to solve this problem to find a more simple and feasible method.

If you are not interested in the process of finding bug, or "too long to look", then ATREDIS-2018-0004 is a good choice, and here is a proof of concept (PoC).

Process Monitor is already one of my favorite tools for research and development. When developing security tools, I frequently use it to monitor how tools interact with Windows and how they are detected. Earlier this year, I noticed some interesting behavior when I debugged a piece of code in Visual Studio and monitored it with Procmon. In general, I set filtering for Visual Studio to reduce interference. But before setting up filtering, I noticed that a SYSTEM process writes to a user-owned directory:

StandardCollector.Service.exe writes to user temporary folder

The possibility of symbolic link (symlink) attack vectors may occur when authorized services write to resources owned by users. In order to determine how to directly affect the behavior of services, I began to study Standard Collector services by looking at the libraries loaded by services:

Visual Studio DLLs is loaded by StandardCollector.Service.exe

The path to the library shows that the Standard Collector service is part of the Visual Studio diagnostic tool. After browsing some libraries and executables in related folders, I found that several binaries were written in .NET, including a separate command line tool called VSDiagnostics.exe. The following figure shows the output of the console:

Output of the VSDiagnostics command line tool

Loading VSDiagnostics into dnSpy reveals a lot about the tool and how it interacts with Standard Collector services. First, get an instance of IStandardCollectorService and create an ICollectionSession using the session configuration:

To initially configure a diagnostic collection session

Next, add the agent to the ICollectionSession with the CLSID and DLL names, which is also an interesting user control behavior. It also reminds me that previous studies took advantage of this DLL loading behavior. At this point, it looks like the Visual Studio Standard Collector service is very similar or even identical to the diagnostic center Standard Collector service included in Windows 10. I started using the OleViewDotNet query service to query the interfaces it supports:

Windows Diagnostic Center Standard Collector Service in OleViewDotNet

Looking at the proxy definition of IStandardCollectorService shows other familiar interfaces, especially the ICollectionSession interface in the VSDiagnostics source:

ICollectionSession interface definition in OleViewDotNet

After writing down the interface ID ("IID"), I went back to the .NET operation library to compare IID, only to find that they were different:

Visual Studio ICollectionSession definition with different IID

Taking a closer look at the .NET code, I found that these Visual Studio-specific interfaces were loaded through the proxy DLL:

VSDiagnostics.exe function loads DLL

A preview of the ManualRegisterInterfaces function in DiagnosticsHub.StandardCollector.Proxy.dll shows a simple loop that iterates through the IID array. Included in the IID array is the array belonging to ICollectionSession:

The function of ManualRegisterInterfaces DLL

The Visual Studio ICollectionSession IID in the IID array to be registered

After a better understanding of Visual Studio Collector services, I wanted to see if I could reuse the same .NET code to control WindowsCollector services. In order to interact with the right service, I need to replace Visual Studio CLSID and IID with the correct Windows Collector service CLSID and IID. Next, I use the modified code to build a client that simply creates and starts a diagnostic session for the Collector service:

Code snippet for the client that interacts with the Collector service

Starting Procmon and running the client creates multiple files and folders in the specified C:\ Temp temporary directory. Analyzing these events in Procmon shows that the initial directory creation is performed in the case of client impersonation:

Although the initial directory is created when impersonating the client, subsequent files and folders are created without impersonation:

After an in-depth understanding of other file operations, several stand out. The following figure shows a breakdown of comments for the various file operations performed by the Stand Collector service:

The most interesting behavior is the file copy operation that occurs during the creation of the diagnostic report. The following figure shows the corresponding call stack and events for this behavior:

Now that the user-influenced behavior has been determined, I have built a possible arbitrary file creation vulnerability exploitation plan:

1. Immediately after the service invokes CloseFile, it gets the operation lock of the merged ETL file ({GUID} .1.m.etl).

two。 Find the report subfolder and convert it to the mount point at C:\ Windows\ System32.

3. Replace the contents of {GUID} .1.m.etl with malicious DLL.

4. Release op-lock to allow ETL files to be copied through the mount point.

5. Start a new session using the copied ETL as the proxy DLL, which triggers the code execution of the entitlement.

In order to write exploit programs, I extended the client by creating op-lock and mount points using James Forshaw's NtApiDotNet C # library. The following figure shows the code snippet used to get op-lock and the corresponding Procmon output, illustrating the loop and op-lock fetch:

Getting the op-lock on the file essentially stops the CopyFile, allows content to be overwritten, and controls when the CopyFile occurs. Next, the vulnerability looks for the Report folder and scans it for randomly named subdirectories that need to be converted to mount points. After the mount point is successfully created, the contents of .etl will be replaced by malicious DLL. Finally, close the .etl file and release the op-lock, allowing the CopyFile operation to continue. The code snippet and Procmon output for this step are shown in the following figure:

There are several techniques that can elevate privileges through arbitrary file writes, but for this vulnerability, I chose to use the proxy DLL loading feature of the collector service to isolate it from a single service. You will notice that in the figure above, I did not use the mount point + symbolic link technique to rename the file to .dll, because DLL can be loaded with any extension. For the purposes of this vulnerability, DLL only needs to be in the System32 folder for the Collector service to load it. The following figure shows the successful execution of the exploit program and the corresponding Procmon output:

The screenshot above shows that the vulnerability is run as user "Admin", so there is a GIF that shows that it is running as "bob", which is a low-privileged user account:

You can also try SystemCollector's PoC,NtApiDotNet library, which is also a Powershell module, to make things easier.

This is the answer to the analysis of privilege escalation vulnerabilities in Windows Standard Collector services. I hope the above content can be of some help to you. If you still have a lot of doubts to be solved, you can follow the industry information channel for more related knowledge.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.