Windows: SCM Protected Process Light Service Security Feature Bypass
Platform: Windows 10 (build 10.0.14393, not tested earlier version or 8.1)
Class: Security Feature Bypass

Summary:
The SCM permits any caller with the TrustedInstaller service SID to manipulate PPL services including stopping and deleting them without needing kernel access.

Description:

Protected Process Light services is an effort to prevent administrators from disabling anti-malware services by blocking certain access rights such as SERVICE_CHANGE_CONFIG and SERVICE_STOP when opening a handle to a service. The presumed reason for this is to prevent malicious user code from disabling the anti-malware service completely. This is used at the very least by Windows Defender.

In the SCM there’s an function, ScCheckServiceProtectedProcess, which is supposed to ensure only other protected processes (presumably at the same level or above) are allowed to get access to the restricted access rights. However looking at the code it does something odd:

DWORD ScCheckServiceProtectedProcess() {
   PSID TrustedInstallerServiceSid;

   if (CallingTokenUser == TrustedInstallerServiceSid || CheckTokenMembership(CallingToken, TrustedInstallerServiceSid) {
      return ERROR_SUCCESS:
   }
   // Open calling Process by PID and check for protection level
   // ...
}

Basically if the calling user token is either the TrustedInstaller user or contains the TrustedInstaller SID as one of its groups (more common) then the protected process check is bypassed. This sort of makes some sense that the installer would have the rights to reinstall Windows Defender etc but it’s at odds with the documentation. From https://msdn.microsoft.com/en-ca/library/windows/desktop/dn313124(v=vs.85).aspx#updates_and_servicing

“Note that the service should ensure that only trusted callers can stop the service. Allowing untrusted callers to do so defeats the purpose of protecting the service.”

The trouble is regardless of its name TrustedInstaller is not trusted from an admin perspective. An admin can modify the TrustedInstaller service binary to execute arbitrary commands and you only need SeCreateTokenPrivilege to fashion an arbitrary token with the group added. Or probably only SeTcbPrivilege to use LsaLogonUser to add the service SID to a token (or probably abuse the SCM itself to spoof the TrustedInstaller service SID). 

Ultimately this is only a security feature bypass, I can’t see it’s possible to inject arbitrary code into a protected service, but of course the assumption is that admins can’t disable anti-malware without the anti-malware itself being complicit in being uninstalled. It’s probably just typical security through obscurity. 

Proof of Concept:

The PoC for this is to execute the following in an administrator command prompt:

REM START
sc config TrustedInstaller binPath= "cmd.exe /C sc stop windefend && sc delete windefend" && sc start TrustedInstaller
REM END

Of course this breaks the TrustedInstaller service, you could just spawn a new process using the service token but that requires more code.

Expected Result
Modifying TrustedInstalled service fails or at least stopping and deleting windows defender should fail.

Actual Result
Windows defender service is stopped and deleted from a “normal” administrator.

This bug is subject to a 90 day disclosure deadline. If 90 days elapse without a broadly available patch, then the bug report will automatically become visible to the public.