“Incorrect Function” and “Encryption Oracle Remediation” Errors

Starting with the April 2018 Windows security patches, Microsoft began cleaning up a remote execution vulnerability in CredSSP. Unfortunately, truly fixing it requires that patched systems reject CredSSP communications from unpatched systems. Developers control which authentication methods their applications use, and they won’t necessarily make you aware. So far, I have seen problems in Remote Desktop Connection and System Center products.

Symptoms

Most versions of MSTSC have been updated with an explicit message telling you what’s wrong:

The text reads:

An authentication error has occurred.

The function requested is not supported.

Remote computer: <<computername>>

This could be due to CredSSP encryption oracle remediation.

For more information, see https://go.microsoft.com/fwlink/?linkid=86660

Older RDP clients will not have the complete text:

The text reads:

An authentication error has occurred.

The function requested is not supported

Remote computer: <<computer name>>

A patched System Center Virtual Machine Manager host will be unable to communicate with an unpatched system, giving the error:

Error (2912)
An internal error has occurred trying to contact the svhv02.siron.int server: : .

WinRM: URL: [http://svhv02.siron.int:5985], Verb: [INVOKE], Method: [GetVersion], Resource: [http://schemas.microsoft.com/wbem/wsman/1/wmi/root/scvmm/AgentManagement]

The request is not supported (0x80070032)

Recommended Action
Check that WS-Management service is installed and running on server svhv02.siron.int. For more information use the command “winrm helpmsg hresult”. If svhv02.siron.int is a host/library/update server or a PXE server role then ensure that VMM agent is installed and running. Refer to http://support.microsoft.com/kb/2742275 for more details.

These are the problems that I ran into. Other affected applications will exhibit different symptoms. Notice that all of these errors report a request or a function as “not supported”. That might help you to narrow problems down for any applications that use CredSSP under the hood.

Cause

In April, a security patch was deployed that closed the security problem. Additionally, the patch created a local Group Policy item to control whether or not it would continue to communicate with unpatched systems. In the April update, that was set to allow communications with vulnerable systems. In the May security update, that GPO was automatically changed to require remote systems to be patched.

So, if any host updated to any level prior to the April updates attempts to open a CredSSP channel to any host patched to the May level or beyond, or vice versa, the connection will be refused.

Resolution

The correction seems obvious: keep your systems patched. However, you’ll also need to update your deployment images. If you deploy a fresh image to a remote system from a pre-patched ISO or other media (like WDS), you will not be able to remote into it. So, besides patching, you need to take some of the following approaches:

• Update the images that you use for deployment. How you do that depends on your deployment strategy. I use WDS with WIMs, so I employ an offline patching script: https://www.altaro.com/hyper-v/free-powershell-script-use-wsus-update-installation-media-hyper-v-templates/. That script also works for VHDXs, in case you template that way.
• Use WDS or some other technique (such as SCCM or tools provided in the Windows ADK) to deploy new systems into organizational units with GPOs that automatically update.
• Use the local console or an out-of-band management tool to connect to new systems.
• I would strongly advise against it, but you could set up a “deployment management” system with a GPO that allows CredSSP communications with vulnerable systems. Doing so opens up that management system to attacks, though, and then those attacks could spread to any newly deployed system. You could mitigate your risks with a careful defense-in-depth approach, but only patching eliminates the risk.

More Information

For more information, including the related Group Policy item, review Microsoft’s documentation on CVE-2018-0886.