Translation statement

The translation is for reference only, the specific content expression and meaning of the original text shall prevail

X

In this article, I will share with you an arbitrary file movement vulnerability I found in Windows Service tracing. Based on the test results, the vulnerability affects all Windows versions from vista to 10. Since this feature already exists in XP systems, the vulnerability may affect earlier versions.

Service tracing is a very early function in Windows system, which can be traced back to XP era, but it may have been included in earlier systems. Service tracing can provide basic debugging information of running services and modules, which is very convenient to configure. Local users only need to edit some registry keys under hklmsoftware remote Microsoft tracing.

In Windows system, services or modules are associated with some registry keys, each of which contains six values (i.e. specific setting information). Here we focus on three values: enable file tracing (enable / disable the trace function), filedirectory (set the specific location of the output log file), and maxfilesize (set the maximum file size of the log file).

When the enable file tracing option is enabled, the target service writes the log files to the directory selected by the user. When the output file size exceeds maxfilesize, the file will be moved by the system (replace the. Log extension with. Old) to create a new log file.

1. Symbolic link from module.log to a file we own (the file size must be greater than maxfilesize);

2. Symbolic link from module.old to any file on the system (such as C: windowssystem32windowscoredeviceinfo. DLL).

As mentioned above, any local user can configure the service tracing function. Just edit some registry keys and modify the key values under hklmsoftware remote Microsoft tracing.

We can use the accesschk tool in the windows sysinternals toolset to verify that ordinary users have read / write permissions for almost all subkeys under the relevant registry keys:

1. Modify enablefiletracking to 0 or 1 to force a specific service or module to start or stop writing debugging information to a log file.

2. Set the specific location of log files through filedirectory.

3. Set the maximum size of the output file through maxfilesize.

The only thing to note here is that we cannot choose the name of the output file, which depends on the name of the service or module being debugged, but we can easily solve this problem through symbolic links.

After knowing the above information, we can clarify the exploitation process of the vulnerability.

In this test case, I set C: logs as the output directory to enable file tracking.

Now, if we want the target service to start writing to the file, we have to generate some events. The simplest method here is to initialize any VPN connection with rasdial command and PBK file.

In the last test case, the final size of the output log file was about 24Kb. So here we set maxfilesize to 0x4000 (16384 bytes) and start the test again.

1. The service gets the basic information of the log file. We can see that the offset of endoffile is 23906, which is also the current file size value. Since the maximum file size we set is 16384 bytes, the system will judge that there is no more space available.

2. The service calls setrenameinformationfile, where filename = C: logsrastapi.old. Because the system thinks the current file is full, it will move C: logsrastapi.log to C: logsrastapi.old.

3. The service creates a new C: logsrastapi.log file to start writing data.

1. Create (or copy) a file larger than 0x8000 (32768) bytes.

5. Use the rasdial function in the windows API to trigger events related to rastapi.