How to test the impact of new Windows DCOM Server authentication

Microsoft’s June security update is light on details but heavy on possible long-term impact to network environments. It updates a patch fixing an issue for a DCOM Server security feature bypass (CVE-2021-26414). What exactly is it fixing? A Japanese security bulletin offers some hints.

According to the bulletin, an attacker would first exploit a vulnerability by directing a DCOM client to connect to a specially crafted server in some way, typically by sending a phishing email to a user to gain a hold on the system. Next, the attacker will use that information to access and then compromise the DCOM server.

The patch fixes and strengthens the authentication used between DCOM clients and servers. Specifically, it phases in stronger authentication (RPC_C_AUTHN_LEVEL_PKT_INTEGRITY) on the DCOM client. This level of integrity ensures that none of the data transferred between the client and server has been modified.

What is DCOM?

Distributed Component Object Model (DCOM) is a Microsoft technology for communication between software components on networked computers. Many of us don’t truly understand it, nor can we diagnose DCOM errors in our event logs that don’t appear to have major impact to our networks. This technology is a protocol for exposing application objects using remote procedure calls (RPCs). As a result of CVE-2021-26414, changes are needed for RPCs to harden them to ensure they are protected against a “security feature bypass” vulnerability.

RPCs are a key part of Windows. RPC is a client/server protocol that application developers can use to call procedures on a local or remote node in a network. The connection details and data marshalling are done behind the scenes by the RPC layer giving developers a means to directly connect client applications to a remote machine. This allows developers to not worry about knowing the details of how data is passed between the two machines and how procedures are called.

While making it easier for connections, this not knowing may also make it harder to diagnose and anticipate what impact this change will have on systems. Therefore, it’s imperative that you instruct your staff to test and identify any applications that fail and either reach out to your vendors and see if they can change their software or find an alternative process or procedure for any application or process impacted by this change.

Check DCOM Server authentication level

Before 2022, you need to test and determine if you will be impacted by this update. Investigate if the connection of the DCOM Server does not take advantage of the strong authentication level. Microsoft plans to phase in measures to increase authentication levels. Microsoft first released the update on June 8, 2021 that enables RPC_C_AUTHN_LEVEL_PKT_INTEGRITY on DCOM clients by default. To have full protection, manually set a registry key of RequireIntegrityActivationAuthenticationLevel = 1 on DCOM Servers. Merely installing the security updates released on June 8 enables client-side protections in a pure Windows environment but does not provide protection in environments with non-Windows DCOM client.

What are these non-Windows DCOM interactions that may be impacted? Unfortunately, there’s no master list. You’ll need to test and review the impact on your environment. First deploy the updates released in June. Then test the impact of enforcement on your network. In early Q4 2021, Microsoft will enable the hardening by default and give you the option to disable it. In late 2021 or early 2022, the hardening will be enabled without the option to disable. It’s imperative that you test the impact now.

How to test DCOM authentication changes

To test the impact on your network:

• Deploy the June update on clients and servers.
• Add a registry key to test the impact of the upcoming enforcement of the hardening. First add the registry key of HKEY_LOCAL_MACHINESOFTWAREMicrosoftOleAppCompat.
• Add a value name of RequireIntegrityActivationAuthenticationLevel.
• Enter “dword”.
• Enter the value data as noted: default = not defined or 0x00000000 means disabled. 0x00000001 = enabled.

Review the types of applications you have installed and select a series of test servers and workstations to deploy this registry key on to test the impact. In early tests, patchers have seen that when they’ve enabled and activated the key on Hyper-V failover test clusters, the connection from the failover management Microsoft Management Console to the cluster works only on the cluster node that is the owner of the cluster. Furthermore, WMI connections from other hosts to the Hyper-V failover hosts also failed with an “Access is denied” error. Fortunately, as a workaround you can use PowerShell to manage the system or use the Windows Admin Center.

Testing the impact now and understanding the implications to your network will ensure that you don’t get into the situation where you are blocked from installing an update and all future updates. Microsoft in its staged rollout anticipates that we will see side effects from this patch and its enforcement of authentication protection. Test this setting over the next few months to ensure that your network doesn’t have an impact that leaves you scrambling to deal with the side effects.