CredSSP, RDP and Raven

Welcome to another edition of AskPFEPlat, this is Paul Bergson and Graeme Bray bringing up the topic of CredSSP when in use with the Remote Desktop Protocol. This topic became an internal discussion around Premier Field Engineering and customers like you as to how this would impact accessing systems via RDP starting in May. This discussion kind of aligns itself with an experience I recently had with my Miniature Schnauzer, Raven. You might be asking yourself what could Raven possibly have to do with IT maintenance?

Being a Premier Field Engineer I end up traveling and my backpack is my carryon of choice when I board a plane, so I always carry some snacks in the event I get hungry. A couple of months back I returned from a trip presenting “Protecting Against Ransomware” to a customer and upon my return I left a half-eaten bag of candy in the side pocket of my backpack. This was just a regular size bag, but sugar isn’t good for dogs. I kept telling myself, I should remove the bag, but I wanted to ensure I had something in the event of a candy emergency. So, my urge for sweets beat my common sense that Raven would ever find the half-eaten bag in my backpack.

So, I get home late with my wife, a couple of nights ago and Raven races to the door to greet us, but she quickly decides to race around the house just to run. All I could think was what got into her??? As I entered the living room (she went zooming by) I see the candy wrapper from my backpack strewn all over the carpet. All I could do was think, that I knew better and wasn’t happy with myself.

Raven didn’t get sick, but it was a lesson to me to follow my instincts and not put Raven in this situation. This could have easily been prevented but I just convinced myself, “Don’t worry, things will be fine” when in fact I was aware of the risk and ignored it anyways!

So, with that in mind, I wanted to call to your attention a Microsoft, May 2018 tentative update that could impact the ability to establish remote host RDP session connections within an organization. This issue can occur if the local client and the remote host have differing “Encryption Oracle Remediation” settings within the registry that define how to build an RDP session with CredSSP. The “Encryption Oracle Remediation” setting options are defined below and if the server or client have different expectations on the establishment of a secure RDP session the connection could be blocked. There is the possibility that the current default setting could change from the tentative update and therefore impact the expected secure session requirement.

With the release of the March 2018 Security bulletin, there was a fix that specifically addressed a CredSSP, “Remote Code Execution” vulnerability (CVE-2018-0886) which could impact RDP connections.

“An attacker who successfully exploited this vulnerability could relay user credentials and use them to execute code on the target system.”
https://portal.msrc.microsoft.com/en-us/security-guidance/advisory/CVE-2018-0886a

Besides both the client and server being patched, there is the requirement that a new Group Policy setting be applied to define the protection for the CredSSP configuration, currently the setting will default to “Vulnerable”. The recommendation is to define a group policy to set it to either “Force updated clients” or “Mitigated” on both client and server.

If you review the options of the group policy settings, you will see that there are 3 states in which the registry setting can exist on the clients and servers. Engineers will also want to consider devices in an unpatched state as seen in the table at the end of this document.

Note: Ensure that you update the Group Policy Central Store (Or if not using a Central Store, use a device with the patch applied when editing Group Policy) with the latest CredSSP.admx and CredSSP.adml. These files will contain the latest copy of the edit configuration settings for these settings, as seen below.
https://support.microsoft.com/en-us/help/4056564/security-update-for-vulnerabilities-in-windows-server-2008

Group Policy

Policy path and setting name Description
Policy path: Computer Configuration -> Administrative Templates -> System -> Credentials Delegation

Setting name: Encryption Oracle Remediation

Encryption oracle remediation

This policy setting applies to applications that use the CredSSP component (for example, Remote Desktop Connection).

Some versions of the CredSSP protocol are vulnerable to an encryption oracle attack against the client. This policy controls compatibility with vulnerable clients and servers. This policy allows you to set the level of protection that you want for the encryption oracle vulnerability.

If you enable this policy setting, CredSSP version support will be selected based on the following options:

Force Updated Clients – Client applications that use CredSSP will not be able to fall back to insecure versions, and services that use CredSSP will not accept unpatched clients.

Note This setting should not be deployed until all remote hosts support the newest version.

Mitigated – Client applications that use CredSSP will not be able to fall back to insecure versions, but services that use CredSSP will accept unpatched clients.

Vulnerable – Client applications that use CredSSP will expose the remote servers to attacks by supporting fallback to insecure versions, and services that use CredSSP will accept unpatched clients.

The Encryption Oracle Remediation Group Policy supports the following three options, which should be applied to clients and servers:

Policy setting Registry value Client behavior Server behavior
Force updated clients

0

Client applications that use CredSSP will not be able to fall back to insecure versions. Services using CredSSP will not accept unpatched clients.

Note This setting should not be deployed until all Windows and third-party CredSSP clients support the newest CredSSP version.

Mitigated

1

Client applications that use CredSSP will not be able to fall back to insecure versions. Services that use CredSSP will accept unpatched clients.
Vulnerable

2

Client applications that use CredSSP will expose remote servers to attacks by supporting fallback to insecure versions. Services that use CredSSP will accept unpatched clients.

A second update, tentatively scheduled to be released on May 8, 2018, will change the default behavior from “Vulnerable” to “Mitigated”.

Note: Any change to Encryption Oracle Remediation requires a reboot.

https://support.microsoft.com/en-us/help/4093492/credssp-updates-for-cve-2018-0886-march-13-2018

From the policy description above and with the tentative update and default registry setting coming in May, it is best that you plan a policy to ensure there is no loss in connectivity to your servers from RDP connections.

If you review the table below and consider the tentative update for May, then the updated default registry setting changes from “Vulnerable” to “Mitigated” then the resulting connection is:

  • If the client has the patch applied but the remote host (server) does not, the connection will be blocked from connecting
  • If the client is unpatched but the remote host (server) Is patched, the session will be vulnerable to the attack
  • If both the client and the remote host (server) are patched, then the session will connect in a secure manner


If you notice if both the client and server are patched, but the default policy setting is left at “Vulnerable” the RDP connection is “Vulnerable” to attack. Once the default setting is modified to “Mitigated” then the connection becomes “Secure” by default.

Remember, any updates from Group Policy will supersede any local settings applied by the system.

After reading through this document, I strongly urge your enterprise to review the current approach to the CVE-2018-0886 mitigation and establish a policy to ensure that your hosts can continue to establish a secure session following the possibility of any update that might occur. Our goal is to minimize any issues preventing you from RDP access to remote hosts.

You aren’t required to force a “Secure” session if all the hosts haven’t been updated. Just creating a policy that you define, and control is much better than leaving things to chance which is what I did when thinking Raven would never get into the candy in my backpack.

Edit – May 9, 2018 – To show the impact that not updating both servers and desktops at the same relative time, a colleague of ours has written a quick post around what issues/errors you see if you are in a Mitigated state on the Client and Unpatched on the Server side. https://blogs.technet.microsoft.com/yongrhee/2018/05/09/after-may-2018-security-update-rdp-an-authentication-error-occurred-this-could-be-due-to-credssp-encryption-oracle-remediation/

Update (5/18/2018):

Details on errors that this issue will display:

Windows event log errors

  • A CredSSP authentication to <hostname> failed to negotiate a common protocol version. The remote host offered version <Protocol Version> which is not permitted by Encryption Oracle Remediation.

 

Errors that can be presented without the April 17, 2018 patch

  • An authentication error has occurred
  • The token supplied to the function is invalid
  • The function requested is not supported

 

Errors that can be presented with the April 17, 2018 patch

  • An authentication error has occurred
  • The token supplied to the function is invalid
  • The function requested is not supported
    • Remote computer: <hostname>
    • This could be due to CredSSP encryption oracle remediation

 

For complete details please see:

https://support.microsoft.com/en-us/help/4093492/credssp-updates-for-cve-2018-0886-march-13-2018

 

Thanks for reading

Paul and Graeme

 

SEO: RDP “An authentication error occurred” “This could be due to CredSSP encryption oracle remediation”.