Yeah, in general our policy is that our changes/defauts shouldn’t break things that already work.
Since you have to manually add WMI, I don’t think it’s a hardship to set this explicitly. It should just be a checkbox in the WMI tab.
The default should maintain current behaviour on existing devices, but can be the new behaviour on any future added devices. This is easier with a devices table field than it is with a device attribute, but possible either way.
I’m not sure how much device table sprawl matters, it’s not functionally possible to have enough rows in that table for it to matter, so this can probably be a devices table field.
Adam.
From: observium observium-bounces@observium.org On Behalf Of Tom Laermans via observium Sent: 13 April 2022 17:00 To: Tony Guadagno tonyg@guadagno.org; Observium observium@observium.org Cc: Tom Laermans tom.laermans@powersource.cx Subject: Re: [Observium] wmi issues, need a syntax change
Tony,
I don't disagree that it needs to work correctly on new systems, however the adage of Observium (for better or for worse...) usually is "don't break either", hence my question.
I guess we'll have to think a bit...
Microsoft also said they'd stop doing SNMP, and claimed they'd stop doing unsigned LDAP - for now neither has materialised ;-)
Tom
On 2022-04-13 16:22, Tony Guadagno wrote:
Tom, there is a couple of moving parts here. First, if you have a system that is still patchable, then this applies because this is pushed in patches. Now, if you are still using WinXP or Server 2003, then probably not. Whether the fix will break WMI monitoring on these old systems, I cannot say.
This is my feeling, should we let newer systems break with WMI monitoring or older (unsupported) systems break? I think it does not make sense to break new systems in favor of old.
I guess another option would be to make a config pram (WMI-signing?) if true, the new call is used?
But to be clear, right now, the WMI hardening results in error messages in the event log but the command succeeds….however…as of 2023, the command will fail and no info will be returned so doing nothing will break WMI.
Thanks for your time on this
From: observium mailto:observium-bounces@observium.org observium-bounces@observium.org On Behalf Of Tom Laermans via observium Sent: Wednesday, April 13, 2022 7:26 AM To: observium@observium.org mailto:observium@observium.org Cc: Tom Laermans mailto:tom.laermans@powersource.cx tom.laermans@powersource.cx Subject: Re: [Observium] wmi issues, need a syntax change
Hi Tony,
You're right, it's not used a lot I think right now.
Would that impact older Windows versions when this change is made?
Because of course that would present a problem...
Thanks,
Tom
On 2022-04-11 22:34, Tony Guadagno via observium wrote:
Hi, I am guessing that wmi polling is not used very much but I do use it and find it handy. If you do use it, you are probably aware that your event logs are filling up with this error:
The server-side authentication level policy does not allow the user domain\wmiuser SID (S-1-5-21-99999-3660327915-2769000259-31856) from address 1.1.1.1 to activate DCOM server. Please raise the activation authentication level at least to RPC_C_AUTHN_LEVEL_PKT_INTEGRITY in client application.
I am getting 4 eventlog errors every polling interval (5 minutes) on every windows server. This is due to Microsoft enhancing security on wmi. (KB5004442—Manage changes for Windows DCOM Server Security Feature Bypass (CVE-2021-26414) (microsoft.com) https://support.microsoft.com/en-us/topic/kb5004442-manage-changes-for-windows-dcom-server-security-feature-bypass-cve-2021-26414-f1400b52-c141-43d2-941e-37ed901c769c )
There is a solution to this, you need to call wmi with pkt integrity enabled (wmic RPC_C_AUTHN_LEVEL_PKT_INTEGRITY support · Issue #41 · greenbone/openvas-smb (github.com) https://github.com/greenbone/openvas-smb/issues/41 ).
So, for example
wmic --user=domain.local\user --password= //server.domain.local "select * from Win32_ComputerSystem" - throws the error in the target servers event log…also, this will start failing next year.
However
wmic --user=domain.local\user --password= //ncacn_ip_tcp:server.domain.local[sign] "select * from Win32_ComputerSystem" will not throw the error
wrapping the target server in ncacn_ip_tcp: and [sign] fixes the issue.
So, would it be possible for you to enhance Observium to make the wmi calls this way?
Thanks
Tony
_______________________________________________ observium mailing list observium@observium.org mailto:observium@observium.org http://postman.memetic.org/cgi-bin/mailman/listinfo/observium