If you’ve seen the following 3 words in recent updates like KB4025342, don’t panic,…
…keep calm and read the CVE-2017-8565 on the new security updates guide portal
Yes, CVE-2017-8565 was published on July 11, 2017.
Oleksandr Mirosh and Alvaro Muñoz from Hewlett-Packard Enterprise Security reported this vulnerability as far as we can see on the acknowledgments page.
On the following page, you can read a good description of the issue:
https://portal.msrc.microsoft.com/en-US/security-guidance/advisory/CVE-2017-8565
A remote code execution vulnerability exists in PowerShell when PSObject wraps a CIM Instance. An attacker who successfully exploited this vulnerability could execute malicious code on a vulnerable system.
In an attack scenario, an attacker could execute malicious code in a PowerShell remote session.
The update addresses the vulnerability by correcting how PowerShell deserializes user supplied scripts.
The above page states it’s a Remote Code Execution (RCE) vulnerability and I guess it’s because Remoting is involved in the attack scenario.
Here’s why I don’t 100% agree with this classification:
First, let’s quickly examine who can access remoting on a Windows 10 1703 workstation with the Get-PSSessionConfiguration cmdlet
- NT AUTHORITY\INTERACTIVE (S-1-5-4) are Users who log on for interactive operation. This is a group identifier added to the token of a process when it was logged on interactively. The corresponding logon type is LOGON32_LOGON_INTERACTIVE. (source)
-
BUILTIN\Administrators (S-1-5-32-544)
A built-in group. After the initial installation of the operating system, the only member of the group is the Administrator account. When a computer joins a domain, the Domain Admins group is added to the Administrators group. When a server becomes a domain controller, the Enterprise Admins group also is added to the Administrators group (source)
- BUILTIN\Remote Management Users (S-1-5-32-580) A Builtin Local group. Members of this group can access WMI resources over management protocols (such as WS-Management via the Windows Remote Management service). This applies only to WMI namespaces that grant access to the user. (source)
Based on the 3 groups listed above who can connect via remoting, either you already are an admnistrator of the box or are logged interactively (you’re an admin or a standard user) and/or belong to the local BUILTIN\Remote Management Users group.
If you’re not already an administrator, you could eventually become one by exploiting the CVE-2017-8565 vulnerability through remoting sessions.
In this case, I’m more likely to call this kind of a vulnerability an Elevation of Privilege (EoP) than a Remote Code Execution (RCE).
Remember
Invoking code via PowerShell Remoting is the prime purpose of PowerShell Remoting
.
Now let’s say, other remoting configurations were added because you’ve implemented JEA (Just Enough Administration) or constrained remoting endpoints with a RunAs account (a privileged account) to delegate access to some (less privileged) remote users (typically helpdesk members).
Again a less privileged remote user who was given access to a (vulnerable) remoting configuration/session could gain more privileges by exploiting this vulnerability.
We can see more details about this vulnerability in PowerShell Core. The beauty of open source projects is that they tend to be more transparent and agile in fixing bugs.
The issue with CIM deserializer was introduced in the PowerShell Core github repository the day after the security updates were released for regular Windows versions of PowerShell.
And it was fixed in about 3 days.
You can see the related merged Pull Request using this link.
I’ve tested this vulnerability on Windows 10 1703 fully patched where KB4025342 was installed. Importing the corrupted CIM class didn’t spawn a calculator process.
I’ve removed KB4025342 and restarted the computer
wusa.exe /uninstall /kb:4025342 /norestart
Importing the corrupted CIM class launched a calculator process. Its integrity was labeled “AppContainer” and has actually a lower integrity level than its parent process (wsmprovhost.exe) level set to medium (as I run as a standard user).
Importing the corrupted CIM class has the same result as doing the following already allowed:
Invoke-Command -ComputerName . -EnableNetworkAccess { calc.exe }
No elevation of privilege so far.
Now, let’s say I add a somehow quite restricted endpoint (allowing only import-clixml and access to the filessystem provider)
$HT = @{
SchemaVersion = '1.0'
ExecutionPolicy = 'Restricted'
SessionType = 'RestrictedRemoteServer'
LanguageMode = 'NoLanguage'
VisibleCmdlets = 'Import-Clixml'
VisibleProviders = 'FileSystem'
RunAsVirtualAccount = $true
}
New-PSSessionConfigurationFile -Path C:\config.pssc @HT
Register-PSSessionConfiguration -Path 'C:\config.pssc' -Name "Test" -Force
Importing the corrupted CIM class results in the ability to escape the constrained endpoint restrictions – the “sandbox” – and run arbitrary code under a more privileged account. You can see that wsmprovhost.exe runs under a WinRM virtual user, has a High integrity level and has two child processes that inherited from its security context (cmd.exe and openwith.exe triggred by trying to run calc):
In my opinion, there’s no need to panic.
Arbitrary code can only run in a higher security context only in some specific scenarios.
This vulnerability can be easily remediated by just applying already available Windows security updates.
On a Windows 7, only Administrators can connect through remoting by default:
, I know it’s time to update my local copy of VSCode 😀
