“Patch Lady” Susan Bradley has some helpful explanations on AskWoody about Microsoft KB4093942, “CredSSP updates for CVE-2018-0886.” She mentions that you can prepare for the updates by setting group policy before they are installed. However, I found that the group policy settings is not available on a domain controller if the update is not installed.
Update May 10, 2018 Please see updates at the end of the post before applying any group policy!
The problem is that you need the new admx (policy) and adml (resource) files that are delivered with the patch. For group policy wonks, this is no doubt old hat, but for the rest of us:
1. Find a machine with the latest security update installed. If you’re like me, you’re deferring updates, so this may take some hunting. This issue affects all versions of Windows; check CVE-2018-0886 for a list of KB numbers by Windows version. I finally found the update applied to a Windows 7 virtual machine that I allow to update automatically.
2. Copy these two files from that machine to a temporary location:
C:\Windows\PolicyDefinitions\CredSsp.admx (dated 2/9/2018)
C:\Windows\PolicyDefinitions\en-US\CredSsp.adml (dated 2/10/2018; adjust language folder to your local language)
3. On a domain controller, in Windows Explorer, navigate to
C:\Windows\SYSVOL\sysvol\<your domain>\Policies\PolicyDefinitions
a. Rename the current CredSsp.admx to CredSsp.admx.old, or move it to another location.
b. Copy the CredSsp.admx file from the updated machine to this folder.
Note If you try to open the group policy at this point, you’ll get this error:
You need the resource file too.
4. On a domain controller, in Windows Explorer, navigate to
C:\Windows\SYSVOL\sysvol\<your domain>\Policies\PolicyDefinitions\en-US (or your local language)
a. Rename the current CredSsp.adml to CredSsp.adml.old, or move it to another location.
b. Copy the CredSsp.adml file from the updated machine to this folder.
You should now be able to edit the new group policy:
Computer Configuration > Policies > Administrative Templates > System > Credentials Delegation > Encryption Oracle Remediation
Update March 17, 2018
Do not set Encryption Oracle Remediation to Mitigated on unpatched servers or you will lose the ability to RDP from patched clients. See the matrix at the bottom of KB4093492. if the connection fails, Remote Desktop will show this message:
This is accompanied by the following error in the client’s event log:
Log Name: Microsoft-Windows-TerminalServices-RDPClient/Operational
Source: Microsoft-Windows-TerminalServices-ClientActiveXCore
Event ID: 226
Task Category: RDP State Transition
Level: Warning
Description:
RDPClient_SSL: An error was encountered when transitioning from TsSslStateHandshakeInProgress to TsSslStateDisconnecting in response to TsSslEventHandshakeContinueFailed (error code 0x80004005).
Set Encryption Oracle Remediation to Vulnerable until the server is patched.
Update May 10, 2018: PATCH YOUR SERVERS
There has been surprise and alarm in some quarters this week when RDP suddenly stopped working. Most likely this is because your clients got patched but your servers did not, and now in May, as promised, connections will be blocked by default unless both ends are patched. Applying group policy to make the connection Vulnerable is not the best solution. Uninstalling the May client patch is not the best solution. The best solution is to patch your servers at least through the April cumulative updates.
In the end, I wonder whether this group policy setting has caused more grief than it saved. If you do not set any group policy but patch your servers and clients within a few weeks of the patch release, you should not have any issues with RDP.
As per my post on https://community.spiceworks.com/topic/2120195-get-patching-cve-2018-0886-credssp-flaw-in-rdp-affects-all-versions-of-windows – these are the steps we’re employing to deploy this to our clients:
1. Install patch on all servers and clients
2. Configure GPO for servers with:
Computer Configuration -> Administrative Templates -> System -> Credentials Delegation -> Encryption Oracle Remediation and (initially) set to Mitigated (1)
3. Configure GPO for clients with:
Computer Configuration -> Administrative Templates -> System -> Credentials Delegation -> Encryption Oracle Remediation and (initially) set to Vulnerable (2)
4. Test RDP functionality – should be OK
5. For clients that rely on RDP – check WSUS to confirm that all clients have the relevant patch – refer https://portal.msrc.microsoft.com/en-us/security-guidance/advisory/CVE-2018-0886 for the KB numbers. Then warn staff of pending security improvement.
6. Prepare for manual update/installation of patch for unpatched clients that may surface in next step.
7. Change client GPO setting from Vulnerable (2) to Mitigated (1)
8. Handle collateral damage J
9. Change server and client GPO settings from Mitigated (1) to Force updated clients (0)
What is meant by “server” and “client”? Is this OS? Or function? Or only DCs?
Don, in my March 17 update in the main article, and I think in KB4093492, “server” and “client” refers to the function or role. So a Windows 7 machine is a “server” when it is the target of an RDP connection but it can also be a “client” when connecting to another computer.
My understanding of AussieCraig’s comment is that he uses “server” and “client” to distinguish the type of OS, choosing to set a more restrictive group policy on server OS computers.
Don, Mark, confirming that we apply the two policies on a role basis – so it’s less to do with the OS and more to do with the role of the device, as determined by the OU the device is located in. This has allowed us to enforce the updated CredSSP on our servers, whilst relaxing the enforcement on our client computers so we can still connect to clients’ servers that are yet to be patched.
It’s a pity that Microsoft didn’t consider the two different roles in defining the policy, that way we could get away with a single GPO object applied at the domain level.
AussieCraig, Please confirm that no matter the role, it is the same registry key that is affected. If this is the case then ANY computer, regardless of OS, that would function to both request connection (source/client) and receive requests for connection (target/server) should be set to the lower enforcement level. Am I interpreting this correctly?
Don, your interpretation is correct – the lower security level will have to be applied.
Your scenario (where a device may function as both a client and a server) is another reason why it would have been helpful if Microsoft differentiated between these two roles in the policy settings.
Sorry but this is BS – shouldn’t have to go thru this just because MS can’t provide an easier fix to deal with the vulnerability. I just set the RDP security config to the lowest setting and that fixed the problem immediately.
Anon – What change specifically do you make with the RDP security config?
Anon, please explain more. I’m having the same issue. Upgraded to Windows Pro, but still have no “Encrytion Oracle Remediation” anywhere.
Jimmy, Pam, “Anon” provided a bogus email address so will not see your comments unless s/he checks back here manually. I’m pretty sure what Anon meant by the “lowest setting” is changing Security Oracle Remediation to Vulnerable.
You will only see the “Security Oracle Remediation” in group policy and only after patching the device. Alternatively, you make a setting in the registry. Both are explained in the KB article linked at the top of this post.
https://support.microsoft.com/en-gb/help/4093492/
Thanks Mark. I had a handful of Windows 10 systems (mostly home users) that dropped the 1803 build last night that have had trouble connecting to our RDSS on Windows 2008 R2 as of this morning. The server was last patched in early April. For some reason it did not get the relevant updates/patches that it should have starting with the March updates. I ended up installing KB4088878 manually which is now allowing the Windows 10 clients with the 1803 build to successfully connect. What I don’t understand is why the registry entry
(HKLM\Software\Microsoft\Windows\CurrentVersion\Policies\System\CredSSP\Parameters) is missing on the Windows Server 2008 R2 server.
Jimmy, I think that’s where computer-level group policies are stored. If there is no group policy (and if the registry entry is not created manually), the default behavior applies, which as of the May updates is “Mitigated”.
[video removed due to advertising]
Just Uninstall Windows update KB4103727 from your Windows 10
Nasir – Your video, before the advertisement, recommends 1) setting group policy to Vulnerable, 2) making the equivalent registry setting, or 3) uninstalling the May patch that enforces Mitigated behavior. While those may be “quick and dirty” ways to re-connect to unpatched servers, the real, secure solution is to patch the server. See the May 10 update just added to the main article.
Thank you for that. I agree 100%. I’m paying good money to the hosting company for use of their servers. I have 3 computers in my office and neither the need nor the expertise required to maintain my own server/network. From what I can tell they’re using a 2012 version. I feel it’s their responsibility to catch up rather than to expect us to regress. And as much good as I am at computers, I really have no confidence in my ability to alter the files that are being suggested.
I find it alarming that MS lists
Windows 10 Version 1511 for 32-bit Systems 4103728 Security Update Remote Code Execution Important 4093109
Windows 10 Version 1511 for x64-based Systems 4103728 Security Update Remote Code Execution Important 4093109
But the page https://support.microsoft.com/en-us/help/4103728
Does not exist. They also list Window 7, 8.1, 10 RTM (1507), ,,and on ward but the 1511 links don’t work.
Anyone know how to resolve this on a WIN 7 Home Prem. Machine, when the Local GP Editor is not available?
Is there a registry entry that needs to be amended?
Dallas: Yes, you can set the registry value as described in KB4093492. See further discussion in this thread on AskWoody. But: it would be better to have whoever manages the servers patch them.
I have asked for the servers to be patched, but I am twice removed from the Managers of those systems, so easier said than done. I will use this fix in the meantime.
Thank You, Mark.
Richard, that is interesting. As of now, 1511 and 1607 are no longer being officially serviced or patched (see https://support.microsoft.com/en-us/help/13853), but the link to the 1607 patch 4103723 still works. Maybe they are releasing patches for one unserviced version but not two. When CVE-2018-0886 was first published in March, only 1511was out of service.
Can someone please confirm whether we still need a Group policy on both the client and server to be secure if both the clients and servers are patched till May levels ?
Morpheus, my understanding is that you do not need group policy after patching to May levels if the defaults are good enough for you. According to KB4093942, the May patches updated “the default setting from Vulnerable to Mitigated,” which I think is as tight as the default is going to get. Looks like you use Group Policy to go one notch tighter with Force Updated Clients to keep unpatched clients from connecting.
Thank you Mark.
I have already uninstalled the last update and reinstalled, but it still gives the same problem. I have verified that the key log was not created. How can I solve the problem?
After update, the registry entry(HKLM\Software\Microsoft\Windows\CurrentVersion\Policies\System\CredSSP\Parameters) is missing.
Pedro, updates must be installed on server and client. It sounds like you are only installing on the client? Can you install on the server as well?
I have a solution by which you can solve this issue in single click.
[link removed]
Sandeep’s post initially included a link to a blog post, which asks you to download a .zip file from Google Drive, which then opens a .reg file, which will set AllowEncryptionOracle = 2 (Vulnerable). The article says that this “This works 100 % .”
If you don’t see the red flags, here they are:
1. Don’t trust articles that don’t explain _why_ they ask you to do something.
2. Don’t download files from unknown/untrusted sites.
3. Don’t open zip files from unknown/untrusted sources. (I scanned it first at http://www.virustotal.com.)
4. Don’t apply .reg files if you don’t know what they do.
In this case, the file is not a virus, but its entire intent is to override the new CredSSP security mitigation and make sure that your systems remain vulnerable forever. All without any explanation, just claiming that this solution solves the issue “in a single click.”
My advice: do NOT set your systems to Vulnerable unless you need that as _temporary_ workaround. Much better is to patch both servers and clients, then remove the group policy or manual registry entries entirely so that the vulnerability is Mitigated.
Hi Mark. I don’t have any group policies setup at the moment for this however I have the May credssp patch KB4103725 installed on a windows server 2012 Standard domain controler – but the credssp reg key is not created. Do we need to create it manually on the server or create a group policy to create it?
Gerry, the reg key and/or group policy can be used to override the default behavior. As of May 2018, the default is Mitigated, so If you have patched the server and clients, you should not need or see any reg keys.
In fact, I have now Undefined and then deleted the group policy that I set up when I wrote this article in March. It’s no longer needed. (I Undefined it first and let it update. That removed the reg key. Then after the reg key was removed on all machines, I deleted the group policy.)
Thanks Mark for the update. I wasn’t sure as we got a Qualsys scan on our network from an external third party and their scan results are indicating the reg key is missing so we weren’t sure if this update was one of those that requires the May update as well as creating the reg key? Looks like I’ll have to revert to them and let them know the reg key isn’t needed as of May update.
It probably doesn’t hurt to put the reg key out there if you want it for documentation purposes. But KB4093942 clearly says that as of May 8 it includes “An update to change the default setting from Vulnerable to Mitigated.”
Thanks Mark for that. I’ll revert to them and see what they say. Not having to create the reg key and reply on the update would certainly save us some time.