In the spring of 2018, Windows users began to encounter an error that had almost never been seen before.
It soon became clear that the message “Encryption oracle remediations” occurred when trying to connect a client PC to a remote machine, and this happened under the following circumstances:
- connection to a remote machine is carried out from a computer on which a relatively old build of Windows was recently installed (Server 2012, “ten” build 1803 and below, Server 2016), since these OSes do not have security updates that were released later;
- the connection is made to a server that does not have the above updates;
- when connected, the built-in RDP protocol tools block the remote PC due to the lack of the necessary patches on the client machine.
Consider the causes of the error and how you can fix the situation.
Why does the CredSSP error appear
So, we already know that on many versions of Windows (server versions 2016/2012/2008, with the exception of 2013, as well as client versions, starting from 7) without installed cumulative patches, if you are trying to connect to a remote PC via RDS / RDP, there may be a Remote Desktop connection problem.
In other words, when remotely connecting to the computer during the encryption authentication procedure, a CredSSP error occurred, which may be caused by a mismatch of encryption protocols. This is because one of the machines (client or remote) does not have the appropriate updates installed after March 2018.
It was then that Microsoft began to distribute an update aimed at protecting the identified vulnerability of the CredSSP protocol, which threatens the possibility of remote code execution by attackers. The technical details of the issue are detailed in CVE2018-0886. Two months later, another update was released, introducing by default a ban on the ability of a Windows client machine to communicate with a remote server if the version of the CredSSP protocol on it was not patched by the March update.
That is, if you have a client Windows with the May updates installed on time , and you make an attempt to connect to remote servers on which, starting from the spring of 2018, cumulative security updates have not been installed, such attempts will end abnormally. In this case, the client machine will receive a message about the impossibility of making a remote connection of the CredSSP type.
So, the cause of the error may be a fix by the developers of the CredSSP encryption protocol, which appeared as a result of the release of the following updates:
- for the server version 2008 R2 and “seven” – KB4103718;
- for WS 2016 – KB4103723;
- for WS 2012 R2 and Windows 8.1 – KB4103725;
- for the “tens” build 1803 – KB4103721;
- for Windows 10 build 1609 – KB4103723;
- for the “ten” assembly 1703 – KB4103731;
- for W10 build 1709 is KB4103727.
The specified list contains the numbers of updates that were released in May 2018, currently it is necessary to install more recent cumulative (also called cumulative) update packages. There are several ways to perform this operation. For example, by accessing the Windows Update service based on the developer’s servers, or using a local WSUS server. Finally, you can manually download the necessary security patches through the Microsoft Update Catalog (this is the Windows update catalog).
In particular, to search for updates for your computer on which the tenth build 1803 is installed, for May 2020, the search query should look like this: windows 10 1803 5/*/2020.
Ways to solve the problem
There are two ways out of this situation. As you might guess, one of them is the removal of security updates on the client computer installed after March 2018. Of course, such a step is considered very risky and is strongly discouraged, since there are other solutions to the problem. But it is the easiest to implement and can be used to make a one-time attempt to access a remote machine.
And now let’s look at alternative “correct” options for fixing the error that occurs when authenticating CredSSP.
One of them is to disable (one-time) the CredSSP version check procedure on the remote PC during an RDP connection attempt. In this case, you remain protected, the patches remain installed, the risk is only during the communication session.
Action algorithm:
- run in the Run console gpedit.msc (built-in local GPO editor);
- go to the Computer Configuration tab, select the Administrative Templates item, then go to the System tab, then go to Credentials Delegation. On Russified Windows, the full path will look like this: “Computer Configuration” tab / “Administrative Templates” tab / “System” menu item / “Credential Transfer” tab;
- in the list of policies, look for the line Encryption Oracle Remediation, click on it and turn on the policy selector to the Enabled / “Enabled” position, selecting the line Vulnerable (Leave the vulnerability) in the list that appears;
- run the command gpupdate / force (forced update of policies) through the Run console, completing the procedure for disabling local group policy editing notifications;
- trying to connect to a remote machine.
Disabling the EncryptionOracleRemediation policy will allow your computer to connect even to unpatched remote PCs and servers without the latest security updates.
ATTENTION. Recall that this method of troubleshooting the CredSSP encryption mismatch error in Windows is not recommended for permanent use. It is better to inform the administrator of the remote machine about the problem of
mismatch of encryption protocols in order to install the appropriate updates.
Let’s take a look at how the EOR policy works. It has three levels of protection against CredSSP protocol vulnerabilities in the absence of patches:
- Force Updated Clients – a basic level of protection, a complete prohibition of connection from a remote machine to connect client PCs without installed updates. As a rule, this policy is activated after a complete update within the entire infrastructure of the network, that is, after installing fresh updates on all networked workstations , including servers that are connected to remotely.
- Mitigated – this level of protection blocks any attempts to connect to servers on which the CredSSP protocol is not patched. In this case, all other services running on CredSSP are not affected.
- Vulnerable is a minimum level protection that removes the ban on remote access to an RDP machine in the presence of a vulnerable version of CredSSP.
Note that on some client machines (for example, the home version of Windows), the local policy editor is not included in the assembly. In this case, making changes that allow you to communicate with remote machines without patched updates on the server side is made manually by editing the registry.
To do this, enter the line in the Run console:
REG ADD HKML\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System\CredSSP\Parameters /v AllowEncryptionOracle /t REG_DWORD /d 2
This procedure can be applied to all workstations using a domain GPO (console run – gpmc.msc), or you can use a PowerShell script (to get a list of workstations belonging to a given domain, you can use the Get-ADComputer cmdlet included with RSAT-AD -PowerShell) with the following content:
Import-Module ActiveDirectory
$PSs = (Get-ADComputer -Filter *).DNSHostName
Foreach ($computer in $PCs) {
Invoke-Command -ComputerName $computer -ScriptBlock {
REG ADD HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System\CredSSP\Parameters /v AllowEncryptionOracle /t REG_DWORD /d 2
}
}
But in order to avoid unnecessary risk, immediately after connecting to a remote machine, if you have the appropriate rights, install the latest updates using the Windows Update service (it must be enabled). This operation can be performed manually by downloading the latest cumulative updates and installing them in accordance with the previously specified algorithm.
If you want to fix the CredSSP encryption error on Windows XP/Server 2003, which are currently no longer supported, but due to certain circumstances you are using, you need to patch all these machines with Embedded POSReady 2009.
IMPORTANT. After a successful attempt to contact the server, installing cumulative patches on it and rebooting the server, be sure to perform reverse transformations in the policy of the client machine by setting the value in the ForceUpdatedClients policy to the default value or replacing the value of the AllowEncryptionsOracle key from 2 to the original 0. Thus, you again protect your computer from vulnerabilities inherent in an unpatched RDP connection by patching CredSSP encryption.
We did not mention another scenario for the occurrence of the error message “Encryption oracle remediation” – when everything is in order with the remote server, but the client computer turns out to be unpatched. It will occur if a policy is activated on the remote machine that blocks attempts to establish communication with unpatched client PCs.
In this case, you do not need to remove the security update on the client. If you fail to contact the server, you should check when the last time cumulative security updates were installed on the client machine. You can check it by using the PSWindowsUpdate module, as well as by running the command in the console:
gwmi win32_quickfixengineering |sort installed on -desk
If the date is old enough (not necessarily before March 2018), install the latest cumulative update for your version of Windows.
