Windows DCOM Server Security Feature Bypass
- June 13, 2022
UPDATE 21.07.2022: Prosys Sentrol OPC UA & Classic SDK has now been fixed.
UPDATE 21.06.2022: Prosys OPC Classic Client has now been fixed.
Microsoft has found a vulnerability (KB5004442, CVE-2021-26414) in DCOM and have decided to enforce hardening changes that will be applied over the next Windows updates.
The change affects OPC classic applications that use remote connections and the OPC Foundation has also released a notification about the issue.
The timeline for the updates is as follows:
| June 8, 2021 | Hardening changes available, but disabled by default. |
| June 14, 2022 | Hardening changes will be enabled by default in Windows updates. You can still disable the changes. See below how. |
| March 14, 2023 | Hardening changes will be enforced in Windows updates. |
The changes will affect usage of OPC classic client applications that connect to OPC classic servers running in another computer (using Distributed COM). Connections within the same computer are not affected (they are using COM).
The hardening will become effective, when Windows is updated in the server computer. As a result, client applications running in other computers will need to be updated.
Prosys OPC Products Affected
The hardening changes affect directly
- OPC UA Gateway version 1.5.8 and earlier
- Prosys OPC Classic Client version 2.0 and earlier
- OPC Classic client applications built with Prosys Sentrol version 7.4.0 or earlier
Fixed Products
- OPC UA Gateway version 1.5.9
- Prosys OPC Classic Client version 2.1.0
- Prosys Sentrol version 7.5.0
Overcoming the Problems in Your Sentrol Applications
Prosys Sentrol 7.5.0 and later will initialize COM with the required alPacketIntegrity security level by default, so you only need to recompile your applications with the new Sentrol libraries.
If you are still using Prosys Sentrol 7.4.0 or earlier, you must add the following to the Project Source code of your OPC Classic client applications:
program Xxx;
uses
PsComUtils,
...
begin
PsInitComSecurity(alPacketIntegrity, ilIdentify);
...
ComSecurity is initialized by default with alConnect level in these versions. That used to be enough to make remote connections, but after the Windows hardening, the servers will not accept connections with that level any more.
Note that as long as your applications connect over OPC Classic only within the same computer, the connections should work despite this setting.
Move to OPC UA
An alternative way to overcome the issue is to avoid remote DCOM connections between the OPC applications. Instead, you should consider moving the connections to use OPC UA, by applying OPC UA Gateway as a tunneler, for example.
Or, you should consider supporting OPC UA in your own applications, which is also possible with Prosys Sentrol.
Enabling and Disabling The Hardening
The changes can be enabled and disabled (until March 14, 2023) using the following Windows Registry key:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Ole\AppCompat\
RequireIntegrityActivationAuthenticationLevel (DWORD value)
The value of 1 means that the hardening is enabled and 0 means that it’s disabled.
Note that you have to restart the computer for the changes in the registry key to take effect.
The feature has already been made available in June 8, 2021, so if you have the latest updates in your Windows operating systems, you can try it out.
Testing
You should be able to see the effect, for example, by connecting remotely with Prosys OPC Client version 2.0 to Prosys OPC Simulation Server. (NOTE that the latest version 2.1 is already initializing COM properly, so it will be able to connect to a hardened server as well.) If the hardening is disabled in the server and you have configured DCOM and firewall to enable connections, you should be able to see the list of servers and connect to the Simulation Server.
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Ole\AppCompat\
RequireIntegrityActivationAuthenticationLevel=0 (DWORD value)
(Reboot after change)
Alternatively, you can try to just connect to the server. If it is also installed in the client computer, you can use the ProgID, e.g. ‘Prosys.OPC.Simulation’; otherwise you will need to use the CLSID, e.g. ‘{EB3A5F8E-7938-464C-AEFA-898335B1E6B5}’ in the Server field.
This should also fail with ‘Access denied’, if the hardening is enabled.
You can also enable logging of DCOM errors in the server computer to validate this. To do this, add the following registry key:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Ole\
CallFailureLoggingLevel=1 (DWORD Value)
After this, you should see the following error in the Event Viewer – Windows Logs-System (You can start it by typing ‘Event Viewer’ in the Start Menu):
And finally, when you have an application that initializes COM Security properly, you should be able to connect again.
Author Info
Jouni Aro
Chief Technology Officer
Email: jouni.aro@prosysopc.com