Hardening represents a means of investigating and reducing the number of systems across your organization with potential weaknesses, and then taking steps to securing them from malicious actors and their increasingly creative cyberthreats. Hardening has been applied across the industry to servers, software applications, operating systems, databases, networks, projects, repositories, services, policies, platforms, and more.
In this article, we'll explore how we're hardening Distributed Component Object Model (DCOM). Specifically:
- The context behind hardening
- What is DCOM and DCOM authentication hardening?
- Addressing critical vulnerabilities and why hardening matters
- When is DCOM authentication hardening happening?
- Call to action:
Let's jump in!
Hardening: A little bit of context
Today, securing your estate is considered required hygiene. Hardening system security represents an investment in quality care. For Windows, hardening is an integral part of our monthly security updates, making them the IT professional's regular high-quality hygiene routine. A good place to start hardening your environment is by reviewing freely available Microsoft documentation, such as our Security baselines guide.
What is DCOM and DCOM authentication hardening?
DCOM authentication hardening is an example of these modern hardening efforts. You may have seen conversations about it on Reddit, Twitter, and forums like our Windows Tech Community. Let's bring these conversations under one roof here!
The Distributed Component Object Model (DCOM) Remote Protocol is used for communication between software components of networked devices through a server. First released in 2006, it essentially allows a computer to run programs over the network on a different computer as if the program was itself running locally. Given the potential for exploitation, it's been undergoing significant progressive hardening since 2021 through Windows Updates. From its inception, DCOM authentication hardening has been moving toward default enablement by 2023.
This issue is specifically impacting enterprise users that are domain-joined, Azure Active Directory-joined, or those using DCOM with Windows Workgroups. It does not affect general consumers. The discovered vulnerability is that a potential attacker may bypass server security to attack an organization's networked devices. While considered hypothetical, it's informed by several metrics utilized by the Microsoft Security Response Center (MSRC): attack vector, attack complexity, scope, confidentiality, integrity, and others. In this case, it's considered a man-in-the-middle (MitM) type of attack of high complexity, exposing application objects using remote procedure calls (RPC). For example, it could adversely impact Windows Management Instrumentation (WMI), which is designed to help you monitor Windows servers.
As a result of our investigation, the following operating systems were deemed to be at risk:
- Windows Server 2008 Service Pack 2 and newer server versions
- Windows 7 and newer client OS versions
- Non-Windows DCOM clients and servers
For a full list of affected Windows products and their severity level, see the CVE-2021-26414 - Security Update Guide - Microsoft - Windows DCOM Server Security Feature Bypass.
Addressing critical vulnerabilities and why hardening matters
DCOM authentication hardening addresses this critical vulnerability by providing a prompt solution in a phased rollout.
The potential attack vector using DCOM vulnerability is the device network. While there is a complex set of requirements that must be met for a successful attack, it can result in an elevation of privilege exploit. If a user is tricked into authenticating to the malicious machine, the attacker can then relay the authentication to a victim DCOM server and steal the user's identity to make remote COM calls. For example, the attacker can invoke one of the interfaces in an MMC Application on the DCOM server to execute a shell command to obtain user data.
This vulnerability matters because:
- All networked devices under the same security authority could be exposed to unauthorized privilege.
- A non-authorized actor could gain privileges to access and modify settings, files, and mostly non-sensitive resources.
- The result could be loss of integrity or protection of networked devices and users' files and settings.
DCOM authentication hardening provides prompt and effective protection of networked devices, user identities, and data privacy, which are managed by you as the security authority.
The solution to this complex vulnerability is hardening of DCOM authentication with server-side enforcement, which is already available to you. Specifically, the updated and hardened DCOM servers enable you to verify that any client/server applications in your environment work as expected. DCOM servers will simply not accept non-anonymous connections from DCOM client using authentication level that is below Packet Integrity (RPC_C_AUTHN_LEVEL_PKT_INTEGRITY). The solution also raises process default authentication level[1] for activation to RPC_C_AUTHN_LEVEL_PKT_INTEGRITY if it's below Packet Integrity in Windows COM layer on DCOM clients. This is enough to prevent exploitation of vulnerability CVE-2021-26414 on your Windows devices and protect your networked devices and users.
The monthly Windows updates released since June 2021 help you to increase security hardening in DCOM as soon or as progressively as you want. Many of our partners have already implemented DCOM authentication hardening or are actively working on any pending obstacles, providing a temporary workaround. The goal is full and permanent DCOM authentication hardening enablement through Windows Updates.
When is DCOM authentication hardening happening?
DCOM devices that are updated with the June 14, 2022 or later security updates are already hardened through programmatic enabling of RPC_C_AUTHN_LEVEL_PKT_INTEGRITY on DCOM servers. These devices will stay hardened unless an admin-level intervention disables it. DCOM authentication hardening has been taking place since 2021. Its proven solution has been offered through several stages, as outlined in the chart below:
|
June 2021 |
The first security updates to harden DCOM were released in June 2021. If you have successfully installed those updates on all of your servers and networked devices, and enabled DCOM authentication hardening on the server side, your environment has been and continues to be protected. |
|
September 2021 |
If you successfully updated your networked devices in September 2021 or later, your organization remains protected from exploitation of DCOM vulnerability. We've additionally fixed several application compatibility issues. Importantly, you can also enable DCOM event logs to identify devices that are impacted by the change (see below to Check your compatibility solutions). |
|
June 14, 2022 |
Windows updates released between June 14, 2022 and February 2023 programmatically enable the requirements of Packet Integrity (RPC_C_AUTHN_LEVEL_PKT_INTEGRITY) on all DCOM servers. The only exception is if you had previously disabled this fix using system registry. With this fix, you might not have anything else to do! Your networked devices would already be protected with this fix. |
|
November 8, 2022 |
November 8, 2022 update will automatically raise authentication level for all non-anonymous activation requests from DCOM clients to RPC_C_AUTHN_LEVEL_PKT_INTEGRITY if it's below Packet Integrity. With this change, most Windows DCOM client applications will automatically work with DCOM hardening change on server side without any modification to the DCOM client applications. |
|
March 14, 2023 |
The following March 14, 2023 update will just make today's solution impossible to disable. This will further prevent any malicious actors from accessing your server and networked devices. The default enablement of DCOM authentication hardening culminates the story, and your environment remains safe. |
This phased approach to DCOM authentication hardening balances two needs. First, we prioritize providing the solution as quickly as possible. Second, we want you to remain in control over when to implement the fixes.
Call to action
We want you and your organization to be ready and more secure than ever! Let's review several simple tools for you to keep your organization protected with the latest Windows updates, check your compatibility solutions, and get troubleshooting help.
Keep your organization protected with the latest Windows updates
Our engineers are doing everything we can to reduce this vulnerability and collaborate with our partners across the industry. We do this to proactively prevent attacks by way of DCOM authentication hardening. All that's left for you to do is to update your environment and enable DCOM authentication hardening.
Update: Please keep upgrading any unsupported versions of Windows to a supported OS. Additionally, keep deploying the latest security and feature updates – from both Microsoft and your original device manufacturers.
- The June 2022 path programmatically enables DCOM authentication hardening change on the DCOM devices. It does not populate or modify any registry keys or settings you may have established.
- The DCOM authentication hardening enforcement is for devices acting as a DCOM server, whether they are Windows server or not. Please note that Windows client devices can act as a DCOM server, too. Therefore, we recommend protecting all DCOM server and client devices, as well as domain controllers with the latest Windows Updates.
Enable: If you have updated your devices with the June 2022 update, your DCOM authentication hardening is already enabled. The only reasons it might not be enabled is if you have not installed this update or if you have manually disabled DCOM authentication hardening. In the latter case, we encourage you to use registry keys to enable hardening changes manually to confirm normal operations (see KB 5004442:(
- Path: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Ole\AppCompat
- Value Name: "RequireIntegrityActivationAuthenticationLevel"
- Type: dword
- Value Data: default = not defined = enabled (after the June 2022 update); 0x00000000 = disabled; 0x00000001 = enabled. A reboot is required when making any change to the value for "RequireIntegrityActivationAuthenticationLevel".
Note: Not setting this registry key value or setting this registry key value to 1 enables hardening changes on the DCOM server. Setting this registry key value to 0 disables RPC_C_AUTHN_LEVEL_PKT_INTEGRITY on the RPC server. These settings are not overwritten by the June 2022 update, even if they result in an authentication level less than Packet Integrity. DCOM servers will allow this type of connection only until March 2023. That is when registry settings will be ignored and the proper authentication level ultimately enabled. These settings only impact machines acting as a DCOM server, including DCOM clients acting as a DCOM server.
Check your compatibility solutions as needed
Our phased strategy specifically focuses on offering a working solution today, while respecting other parties' contexts and opportunities. Consequently, we are in active discussions with other equipment and software manufacturers to support and speed up this process for you. Many of our partners have already released permanent or temporary fixes to compatibility issues. If you are affected by a compatibility issue related to DCOM authentication hardening, see if your provider or vendor has released a fix or a workaround. If not, it's likely that these incompatibilities take more time to ensure that they are effectively removed without impacting productivity. Please use your provider or vendor's communication channels for the latest updates. If you're a non-Windows DCOM user, that's the only route.
For Windows, we've added event logs to a subset of Windows versions to help you monitor for potential compatibility issues with DCOM authentication hardening changes. These versions include:
- Windows 11, version 22H2
- Windows 10, versions 22H2, 21H1, 20H2, 1809, and 1607
- Windows Server 2022, 2019, and 2016, 2012 R2
- Windows 8.1
On these Windows devices, the system logs potential compatibility issues. They take form of error events if the system detects that a DCOM client application is trying to activate a DCOM server using less than the recommended authentication level. Identifying such applications requires three steps.
Step 1: Check if there are any server events from the System log.
A server event log shows an event ID 10036 with its corresponding message.
Step 2: To find the application causing this error event, use the Client IP Address information to trace to the client device from the server-side event log.
Step 3: Use client-side event logs to find the suspicious application by locating the application path and the application PID.
Client event logs show two event IDs, 10037 and 10038, with their respective messages.
Troubleshooting help
Two common scenarios that you might want to troubleshoot are when you don't see client or server events logged or encounter issues during testing.
If you do not see client or server events logged:
- Ensure that you're on a supported Windows version and the most recent updates are installed on DCOM clients and servers. See availability for the supported versions with their minimum required update. This answer applies to cases when the server logs event 10036 but the client does not log any events.
- Consult server and client event logs on appropriate machine roles as illustrated in this section above.
- If neither the server nor the client logs any events, then it is likely that client applications are automatically working with the hardening change. In that case, there is nothing else you need to do. Your environment is hardened and protected.
If issues are encountered during this testing, contact the vendor of the affected application for an update or workaround.
Stay informed
We will continue to publish reminder notices for these hardening milestones in our monthly release notes. In addition, be sure to check out Windows release health and the Microsoft 365 admin center.
[1] Process default authentication level is the authentication level specified in CoInitializeSecurity function. If DCOM applications do not call CoInitializeSecurity, then the default authentication level corresponds to the DCOM security default settings in the registry. Learn more in Modifying the Security Defaults for a Computer.