Exploit Microsoft Windows - CreateObjectTask SettingsSyncDiagnostics Privilege Escalation

[Exploiter]

EDB-ID

38202

Проверка EDB

1. Пройдено

Автор

GOOGLE SECURITY RESEARCH

Тип уязвимости

LOCAL

Платформа

WINDOWS

CVE

cve-2015-2524

Дата публикации

2015-09-15

Microsoft Windows - CreateObjectTask SettingsSyncDiagnostics Privilege Escalation

Source: https://code.google.com/p/google-security-research/issues/detail?id=437

Windows: CreateObjectTask SettingsSyncDiagnostics Elevation of Privilege
Platform: Windows 8.1 Update (I don’t believe it’s available in earlier Windows versions)
Class: Elevation of Privilege

Summary:
The CreateObjectTask scheduled task initializes a user accessible system COM service which allows you to instantiate the SettingsSyncDiagnostics COM object. This object doesn’t take into account the caller when copying logs files leading to EoP.

Description:

The Microsoft\Windows\Shell\CreateObjectTask initializes a shell32 based ICreateObject COM server as local system. This is marked as being accessible from a normal user account so once created we can attach to it. The server only has one method, CreateObject which checks the CLSID against a list of known safe classes before allowing it to be instantiated. One of these classes is a diagnostic class for setting synchronization implemented in SettingSync.dll. 

This class allows an event log to be initialized with the StartLogging method and then the logs copied to an arbitary location with the StopLogging method. The StopLogging method doesn’t impersonate the caller when moving the logs to the user defined location which means it runs as local system. It’s possible to use this to copy the log files to arbitrary locations using appropriate symbolic link attacks. We can get data into the log file by sending trace events to the appropriate provider, this could allow string data to be added to the file. The name of the file is under attacker control so it can be renamed to .hta or .ps1 which would allow the limited control over the contents to be abused in error tolerant script engines. 

Another way of exploiting this takes into account that the SHFileOperations call which moves the file resets the ACLs (where applicable) on the file to match the expected inherited permissions. So for example you could drop the file as c:\program.exe and it would pick up the default DACL for C:\ (which allows Authenticated Users modify permissions) but the call doesn’t reapply the High IL label. This could be used indirectly in bad system services with unquoted file paths as the normal user could re-write the files contents to an malicious executable. A second trick with this is there’s a race between the move and the resetting of the ACLs. As the shell uses TreeSetNamedSecurityInfo it will also walk directory hierarchies, therefore by switching the symlink from the original target to a directory (say c:\users) you can force parts of the system drive to reset their ACLs, leading to the user being able to modify new parts of the file system which again could be exploited.. 

Exploitation is complicated somewhat by a bug in the proxy in actxprxy.dll. Presumably in the original MIDL file for the COM object the StopLogging method is incorrectly marked, the single WCHAR* parameter is missing the [string] attribute. This results in the built-in proxy only marshalling a single WCHAR to the server, this tends to cause things to not work so well and leads to a limited information disclosure as whatever’s after the single character in memory up to the next NUL is assumed to be part of the path. Fortunately the stub is sufficiently simple that by sending a plain array buffer to the server it’ll pick up the correct data. I’ve done this in the PoC by implementing my own custom COM proxy object. 

Proof of Concept:

The PoC demonstrates the vulnerability by copying the log file to the system drive. The password for the 7z file is ‘password’. 

1) Extract the PoC to a location on a local hard disk
2) As a normal user execute the PoC. 
3) The PoC should complete execution. 

Expected Result:
The log file should fail to be moved to the specified target.

Observed Result:
The log file ends up copied to c:\program.exe and can be modified by the current user. 

Proof of Concept:
https://gitlab.com/exploit-database/exploitdb-bin-sploits/-/raw/main/bin-sploits/38202.zip