master-client(-management)

Take Windows Up to 11

Tag: System Center

Install Microsofts January Meltdown / Spectre Updates during SCCM or MDT Build and Capture Task Sequence

Problem

I tried to create images of Windows 7 and Windows 10 (1607, 1703, 1709) with a SCCM Build and Capture Task Sequence. I deployed the January Windows Updates to the imaging clients so that the images should include the fixes for the Meltdown and Spectre vulnerabilities. But unfortunately this did not work. The reason is that the Antivirus compatibility Registrykey mentioned in this article had not been set before the updates were installed.

Update: After testing Build and Capture of Windows 10 with MDT I have added the necessary steps to the article.
Update 2: Thanks to @manelrodero for pointing out that a reboot is not required between setting the key and the Install Update step.
Update 3: Microsoft announced that this is not longer necessary beginning with the Cumulative Update 03-2018

Solution

You just have to add the registry in your Build and Capture sequence right before the update step performs the update scan.

SCCM

  1. Add a Run Command Line Step to your Build and Capture Task Sequence before the Install Updates step containing the following line
REG ADD "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\QualityCompat" /v cadca5fe-87d3-4b96-b7fb-a231484277cc /T REG_DWORD /D "0x00000000" /F

QualityCompat Key
2. Make sure that the box Evaluate software updates from cached scan results is not checked in the first Install Updates step.

Install Updates step

MDT

  1. Add a Run Command Line Step to your Build and Capture Task Sequence before the Windows Update (Pre-Application Installation) step containing the following line
REG ADD "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\QualityCompat" /v cadca5fe-87d3-4b96-b7fb-a231484277cc /T REG_DWORD /D "0x00000000" /F

QualityCompat Key

Use SCCM to bypass Device Guard / Applocker

Some days ago, my colleague Matthias (@mg_wtf) told me that he had just changed the executable of a package he had been testing in the ccmcache directory and had started the installation from the SCCM Software Center and it worked.

I checked several instances of SCCM Current Branch (up to 1710) and Technical Preview (up to 1711) and could verify the behavior in all of them. The agent validates the content only when downloading it. After that it assumes that it remains unchanged in the ccmcache directory. Edits of the files are very unlikely because only administrators are allowed to do that.

Update 2017/11/28 see section: Is this a big issue?

How I tested it

I installed and updated an instance of Windows 10 Enterprise 1703 and configured SCCM as a managed installer for Applocker and Device Guard as described here and here.

The Applocker policy allowed standard users only to execute applications from the Program Files or Windows folder and any APPX-Application. Everything else was blocked.

<AppLockerPolicy Version="1">
  <RuleCollection Type="Exe" EnforcementMode="Enabled">
    <FilePathRule Id="921cc481-6e17-4653-8f75-050b80acca20" Name="(Default Rule) All files located in the Program Files folder" Description="Allows members of the Everyone group to run applications that are located in the Program Files folder." UserOrGroupSid="S-1-1-0" Action="Allow">
      <Conditions>
        <FilePathCondition Path="%PROGRAMFILES%\*" />
      </Conditions>
    </FilePathRule>
    <FilePathRule Id="a61c8b2c-a319-4cd0-9690-d2177cad7b51" Name="(Default Rule) All files located in the Windows folder" Description="Allows members of the Everyone group to run applications that are located in the Windows folder." UserOrGroupSid="S-1-1-0" Action="Allow">
      <Conditions>
        <FilePathCondition Path="%WINDIR%\*" />
      </Conditions>
    </FilePathRule>
    <FilePathRule Id="fd686d83-a829-4351-8ff4-27c7de5755d2" Name="(Default Rule) All files" Description="Allows members of the local Administrators group to run all applications." UserOrGroupSid="S-1-5-32-544" Action="Allow">
      <Conditions>
        <FilePathCondition Path="*" />
      </Conditions>
    </FilePathRule>
    <FilePathRule Id="6c236a39-90f4-46bf-974a-b06995049062" Name="%WINDIR%\CCM\CcmExec.exe" Description="" UserOrGroupSid="S-1-1-0" Action="Allow">
      <Conditions>
        <FilePathCondition Path="%WINDIR%\CCM\CcmExec.exe" />
      </Conditions>
    </FilePathRule>
<RuleCollectionExtensions>
<ThresholdExtensions>
<Services EnforcementMode="Enabled" />
</ThresholdExtensions>
      <RedstoneExtensions>
        <SystemApps Allow="Enabled"/>
      </RedstoneExtensions>
</RuleCollectionExtensions>
  </RuleCollection>
  <RuleCollection Type="ManagedInstaller" EnforcementMode="Enabled">
    <FilePathRule Id="25656246-4c57-4f2f-bf72-baa5eb8c355b" Name="%WINDIR%\CCM\CcmExec.exe" Description="" UserOrGroupSid="S-1-1-0" Action="Allow">
      <Conditions>
        <FilePathCondition Path="%WINDIR%\CCM\CcmExec.exe" />
      </Conditions>
    </FilePathRule>
  </RuleCollection>
  <RuleCollection Type="Msi" EnforcementMode="NotConfigured" />
  <RuleCollection Type="Script" EnforcementMode="NotConfigured" />
  <RuleCollection Type="Dll" EnforcementMode="NotConfigured" />
  <RuleCollection Type="Appx" EnforcementMode="Enabled">
    <FilePublisherRule Id="a9e18c21-ff8f-43cf-b9fc-db40eed693ba" Name="(Default Rule) All signed packaged apps" Description="Allows members of the Everyone group to run packaged apps that are signed." UserOrGroupSid="S-1-1-0" Action="Allow">
      <Conditions>
        <FilePublisherCondition PublisherName="*" ProductName="*" BinaryName="*">
          <BinaryVersionRange LowSection="0.0.0.0" HighSection="*" />
        </FilePublisherCondition>
      </Conditions>
    </FilePublisherRule>
  </RuleCollection>
</AppLockerPolicy>

After that I executed the MyMalwareInstaller.exe as an administrator. This installation created a registry key and installed the c:\mymalware.exe.

Latter just shows a Messagebox with the executing user.

As defined in the Applocker policy the Administrator was allowed to start the MyMalware.exe

I switched to a standard user account without administrative rights and tried to execute the mymalware.exe. As expected this was blocked by AppLocker.

Hereafter I undid all the changes made by the installer and deployed a Test application via SCCM. This install did nothing else than creating the registry key specified as Application Detection Method.

Then I overwrote test1.exe in the Config Manager Client Cache directory (%windir%\ccmcache) with the MyMalwareInstaller.exe and deleted the detection key from the registry.

After executing the Application Deployment Evaluation Cycle the Software Center allowed me to install the application again. I clicked on the Install button and the SCCM client executed the mymalwareinstaller.exe instead of the checked in executable!

Then I switched back to the standard user and now he was able to execute the MyMalware.exe because it was installed by the SCCM client as Managed Installer.

You could argue both of these executables are not signed by a trusted publisher and SCCM even warns you about this when you import the application

However I tested this too and the client executes an unsigned executable instead of a signed one!

Is this a big issue?

Arguments in favor of No:

  • An attacker first needs to achieve administrative rights
  • The Applocker/Device Guard Managed Installer feature is still a beta feature
  • In this scenario it would be a lot easier for an attacker to copy his executable to the Program Files folder to let it run in the context of a standard user. But in tighter controlled environments this might be the loophole.
  • Update 2017/11/28: Dune Desormeaux from MS pointed out to me that they don’t claim that Device Guard protects against local admin rights.

Arguments in favor of Yes:

  • It is a possibility to execute code in the context of the SYSTEM account
  • Many Third-party Application Control systems leverage technologies similar to the Applocker/Device Guard Managed Installer
  • In an Advanced persistent threat scenario attackers could use this to gain persistent access to a system after an initial exploit even if application whitelisting is configured
  • If the attacker restores the content in the ccmcache and the detection rule after the successful execution of his code it is very hard to trace the way of the infection

Solution

In my opinion the best solution would be that the SCCM client checks the content hash before every execution from the cache instead of only directly after the download.

Before that happens, you should take this into account before using the SCCM client as a trusted source in an application control system.