Dealing with DCOM

Topic

New Reply

PATCH WATCH By Susan Bradley In the June updates, Microsoft continues its journey to harden the Distributed Component Object Model (DCOM), with the go
[See the full post at: Dealing with DCOM]

Susan Bradley Patch Lady/Prudent patcher

4 users thanked author for this post.

lmacri, LoneWolf, mcbsys, DLivesInTexas

Reply | Quote

Replies

Thank you, Ms. Bradley for the June 27 commentary on DCOM.  As a home user, I was for a while confused per the sequence of identically formatted headers in your article, as to how much to patch (now) for DCOM.  Please check me on how I read your intent.

However, while looking for  others’ forum comments, I see the “Patch Watch” is still at Defcon 2 as of today (June 27), so, we still should defer all the June MS patches for now?

Otherwise I was going to ask, if you intended all of us to: *Look for DCOM log messages first, THEN:  * Install the June patches;  * Then,  as home users, just stop there. — Or,  *Then, like the business users, possibly inspect and make changes to the Registry?  Now, I don’t think so, just hold for a while, right?  That’s a relief, if I got it right.

–David

Reply | Quote

The events have already been in your event logs for about a year.  The June updates merely start enforcing some of the settings.

As a home user, I don’t anticipate you see any side effects other than slightly messy event logs.

I don’t change the Defcon until tomorrow.

Susan Bradley Patch Lady/Prudent patcher

Reply | Quote

Susan,

Thanks for the heads-up/reminder. I use COM in a custom program I developed so I wanted to test this.

The server is 2012R2, so per this article, I need patch KB5006714. I can see that my update history but oddly it’s not in the WMI list of applied hotfixes. Maybe it was superseded? I do see the 2022-06 rollup KB5014738 as installed.

My program uses Connect level authentication but even with hardening explicitly enabled in the server’s registry, I can’t get it to fail or create event log warnings.

Is there a test app, or a known failing app, that will confirm the hardening is working?

Reply | Quote

From your client you could try calling CoQueryProxyBlanket function and your server could try calling CoQueryClientBlanket function

When I tested with a COM client and a COM Local Server both functions indicated that the connection between client and server was using RPC_C_AUTHN_LEVEL_PKT_PRIVACY.  As with your case, the DCOM default was set to Connect and there were no entries in the System Event log.  The secure setting was used even when I tried to set lower security in both the COM client and server by calling CoInitializeSecurity function.

1 user thanked author for this post.

mcbsys

Reply | Quote

@EricB, thanks for the suggestion. Interesting that you found your app using packet privacy in spite of the Connect specification.

Mine is a VB6 app, so getting down to those low-level functions would not be easy. It’s set up as a COM+ proxy, with DCOM configured as described in (archived) KB268550. I found KB926098 about tracing COM, but it requires Microsoft support to interpret the etl files.

I tried raising the auth level on the server to Packet Integrity and re-exporting the proxy. Once I uninstalled the old proxy on the client, I was able to install the new with with Auth Level = Packet Integrity. My app can still read and write records, so at least in an initial test, it’s unaffected by Packet Integrity. Whether there are issues with larger recordsets etc. remains to be seen.

I still don’t understand why I’m not seeing event log errors with Packet Integrity turned off!

Reply | Quote

Coming back to this. I may have figured it out for  my case.

I discovered that if you run Wireshark on the server, you can filter on “dcom” and see the Auth level requested and in use. I’ve added AuthenticationHint and Auth level as columns (isystemactivator.properties,scmresp.authhint and dcercp.authlevel, respectively). Here we see “Packet integrity” is in use, but only on the initial connection (in the RemoteCreateInstance requests and responses):

Per this reference that AuthenticationHint=2 corresponds to RPC_C_AUTHN_LEVEL_CONNECT. So I’m requesting Connect and getting Packet Integrity, but only during the initial connection.

After increasing my DCOM proxy on the client to specify Packet Integrity, the AuthenticationHint increases to 5 (RPC_C_AUTHN_LEVEL_PKT_INTEGRITY). More importantly, all the packets carry that Auth level = Packet integrity. So that is apparently what Packet integrity means, that every single packet has authentication info.

The thing that still seems odd to me is that even with the server set to enforce RequireIntegrityActivationAuthenticationLevel, it still wasn’t complaining (raising errors) when Auth level was set to Connect–maybe because that connection uses Packet integrity? I guess I could try setting the Authentication level to None to see if it would fail.

Reply | Quote

Maybe someone could give a nice explanation of just what a Com object is in the DCOM universe. The most prevalent error message deserves some explanation.

🍻

Just because you don't know where you are going doesn't mean any road will get you there.

Reply | Quote

Title: Microsoft Security Update Revisions
Issued: June 28, 2022
************************************************************************************

Summary
=======

The following CVE has undergone a revision increment.
====================================================================================

* CVE-2022-26414

– – CVE-2021-26414 | Windows DCOM Server Security Feature Bypass
– https://msrc.microsoft.com/update-guide/vulnerability/CVE-2021-26414
– Version: 3.0
– Reason for Revision: In the Security Updates table, added all supported editions
of Windows 10 version 21H2, Windows Windows 11, and Windows Server 2022 as they
are affected by this vulnerability. Customers running any of these versions of
Windows should install the June 14, 2022 security updates to be protected from
this vulnerability. After these updates are installed,
RPC_C_AUTHN_LEVEL_PKT_INTEGRITY on DCOM servers will be enabled by default.
Customers who need to do so can still disable it by using the
RequireIntegrityActivationAuthenticationLevel registry key. Microsoft strongly
recommends that customers install the updates, complete testing in your environment,
and enable these hardening changes as soon as possible.
– Originally posted: June 8, 2021
– Updated: June 28, 2022
– Aggregate CVE Severity Rating: Important

Reply | Quote

What’s annoying to me is that these events are showing up in DCDIAG reports on Windows domain controllers, making it appear like there’s a real problem going on, when really it’s just part of the new hardening process.

Our remote management/monitoring software routinely runs these, and any fails result in a system monitoring ticket. And while DCDIAG errors aren’t an issue a majority of the time, that remaining small percent is the “You really should look at this, there’s a problem” kind of thing.

It really makes me wish Microsoft would streamline both DCDIAG, and  perhaps some of its event logs so I stop playing the “When is a critical error not a critical error?” game.

We are SysAdmins.
We walk in the wiring closets no others will enter.
We stand on the bridge, and no malware may pass.
We engage in support, we do not retreat.
We live for the LAN.
We die for the LAN.

Reply | Quote