About January 2019 LCU (Latest Cumulative Update)

All the LCU (Latest Cumulative Update) in January 2019 contain the following note:

After reading that I just wondered:
Is PowerShell or remoting vulnerable and not mentioned in any CVEs released in January 2019.
How to assess the impact of the LCU on any endpoint that deals with remoting?
What’s the scenario?
…

• January 8, 2019—KB4480116 (OS Build 17763.253) for Windows 10 version 1809 and Windows Server 2019
• January 8, 2019—KB4480966 (OS Build 17134.523) for Windows 10 version 1803
• January 8, 2019—KB4480978 (OS Build 16299.904) for Windows 10 version 1709
• January 8, 2019—KB4480973 (OS Build 15063.1563) for Windows 10 version 1703
• January 8, 2019—KB4480961 (OS Build 14393.2724) for Windows 10 version 1607 and Windows Server 2016
• January 8, 2019—KB4480963 (Monthly Rollup) for Windows 8.1 and Windows Server 2012 R2
• January 8, 2019—KB4480970 (Monthly Rollup) for Windows 7 SP1 and Windows Server 2008 R2 SP1

Based on feedback from MVP raised on the private distribution list, the PowerShell team published the following blog post: Windows Security change affecting PowerShell.

After the blog post was published, Paul Higinbotham from the PowerShell Team also asked for all KB articles to be modified as follow:

My first concern was: if it’s a security vulnerability, what’s its CVE? The blog post answer is: CVE-2019-0543 discovered by James Forshaw of Google Project Zero

My second concern was twofold. Is the chapter about A Least Privilege Model Implementation Using Windows PowerShell published in the PowerShell Conference Book impacted by this change? Should I stop deploying Windows 10 at work because the LCU of January 2019 breaks my loopback scenario?

The answer is no and explained by the blog post Windows Security change affecting PowerShell

you would not be affected by this change, unless you explicitly set up loopback endpoints on your machine to allow non-Administrator account access

Let’s boot a 1709 VM, apply the LCU of January 2019, reboot and compare the endpoint permissions that will be impacted by the change named MyNonAdmin and the one set in the PowerShell Conference Book‘s chapter named MakeMeAdmin:

Now let’s test the behavior:

Holy moly! Cool down!! The odds you are impacted is very very low.

And if you’re in trouble, Microsoft proposed these two solutions:

A workaround for a loopback connection is to always use Administrator credentials.
Another option is to use PSCore6 with SSH remoting.

Then I tried to set the same permissions that work for the MakeMeAdmin endpoint (EP) on the MyNonAdmin EP.
The answer was crystal clear. Having the same permissions doesn’t work.

I then wondered why my loopback scenario works?

Based on my 2nd testing wave, it appears that:
– a non admin local account can only use loopback remoting if the account is a member of the local administrators group when remoting is being accessed.
– endpoint permissions isn’t what will give access to an non admin local account when using loopback remoting.
– when it doesn’t work, opening the session or handling a remoting request/response takes more time.
– when it doesn’t work, opening the session or handling a remoting request/response creates errors in the ‘Windows Remote Management’ operational log:

Get-WinEvent -FilterHashtable @{ 
 LogName = 'Microsoft-Windows-WinRM/Operational' ; 
 Level = 2
}

Request response: WSMan operation CreateShell failed, error code 2148007941
Request handling: The WSMan service could not launch a host process to process the given request. Make sure the WSMan provider host server and proxy are properly registered. Error code 2148007941

The article also says:

The breaking change is not in PowerShell but in a system security fix that restricts process creation between Windows sessions. This fix is preventing WinRM (which PowerShell uses as a remoting transport and host) from successfully creating the remote session host, for this particular scenario. There are no plans to update WinRM.

So, it’s the identity that really matters. In other words, a non admin local account cannot open a local (loopback) remote session that uses WinRM.

Again, why my loopback scenario works?

The answer is also in the article:

This does not affect JEA (Just Enough Administration) sessions.

🙄

Ok, if JEA isn’t affected, what it’s so special in JEA? Permissions? No. Roles/Capability? Yes, for sure!
Let’s dig into JEA. If it’s not permissions that made a difference, then what is it?
Is it the SchemaVersion, the SessionType, the LanguageMode,…?

My testing shows that the endpoint (EP) must run under another identity whether it’s a virtual local admin account, a gMSA or just another account (it can be the local admin account (RID:500)).

Ok, how can I find endpoints that are not affected by the non admin user loopback issue?
Well, like this:

Get-PSSessionConfiguration | Where {
 ($_.RunAsVirtualAccount -eq 'True') -or
 ([string]::empty -ne $_.RunAsUser)  -or 
 ([string]::Empty -ne $_.RunAsVirtualAccountGroups)
} | Select Name,*Run* | ft -AutoSize

NB: isn’t it a shame that these properties are only strings?

To summarize,
Here are two EP:

# Common parameters for both endpoints: permissions
$HT = @{
 SecurityDescriptorSddl = 'O:NSG:BAD:P(A;;GA;;;BA)(A;;GA;;;BU)S:P(AU;FA;GA;;;WD)(AU;SA;GXGW;;;WD)'
 Force = [switch]::Present
}
# Create an EP that won't work
Register-PSSessionConfiguration -Name NOKMyNonAdminEP @HT

# Create an EP that will work
New-PSSessionConfigurationFile -RunAsVirtualAccount -Path c:\OKMyNonAdminEP.pssc
Register-PSSessionConfiguration -Name OKMyNonAdminEP @HT -Path c:\OKMyNonAdminEP.pssc

# Compare their properties
Get-PSSessionConfiguration | 
Select Name,Schema*,GUID,Session*,RunAs*,Perm* |ogv

Let’s quickly measure the performance issue I mentioned above:

Measure-Command { 
 New-PSSession -ConfigurationName OkMyNonAdminEP -ComputerName localhost
}
Measure-Command {
 New-PSSession -ConfigurationName NOkMyNonAdminEP -ComputerName localhost
}

30 seconds compared to 288 milliseconds…