KB4053579 is superceded but still being evaluated

[Chris Herrmann]

hi, i have servers that are being flagged as vulnerable because KB4053579 is listed as missing... which it is... because it's superceded by a later update, and that is installed.

specifically:

KB4053579 --> KB5005698

I've found old threads relating to other similar issues - but not for this particular KB.

Is this something I can update / tweak on our side, or otherwise how do we troubleshoot why it's still evaluating this way?

Thanks,

Chris

[Openime Oniagbi]

Hello Chris,

Thank you for using Wazuh.

Firstly, please note that every CVE is evaluated individually and that is most likely why the alerts are being flagged even though a later KB resolves the vulnerability.

Therefore, your best course of action would be to whitelist/ignore that vulnerability. To do this, it would only be necessary to add a new custom rule, to which we specify the list of CVEs in the option <field>"vulnerability.cve" and so every time it finds a vulnerability of that type, as the rule is at level 0, then the alert will be ignored.

In the WUI you can navigate to Management -> Rules and there you can set a filter to Custom rules, and select the file local_rules.xml. Then, add the following rule:

 <group name="cve-ignore,">
   <rule id="100002" level="0">
      <if_group>vulnerability-detector</if_group>
      <field name="vulnerability.cve">CVE-0000-0000, CVE-0000-0001, CVE...</field>
      <description>Ignoring alert $(vulnerability.cve). Vulnerability was published $(vulnerability.published). Reference $(vulnerability.reference)</description>
      <location>agent_name</location>
    <options>no_full_log</options>
  </rule>
</group>

Note that for the <location> you will add the name of the agent which you want to ignore those CVEs. If you need to ignore the CVEs for all the agents, please remove the <location> tag.
More details about the rules syntax: https://documentation.wazuh.com/current/user-manual/ruleset/ruleset-xml-syntax/rules.html#options

Please let me know if this helps.

Regards,

[Openime Oniagbi]

Hello Chris,

After checking https://www.catalog.update.microsoft.com/Search.aspx?q=KB5005698, I can not see where KB4053579 is mentioned in the "This update replaces the following updates" section. Can you please let me know how you verified that KB5005698 supersedes KB4053579 so we can consider it and fix it?

I am looking forward to hearing from you.

Regards,

--
You received this message because you are subscribed to a topic in the Google Groups "Wazuh mailing list" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/wazuh/Pne68WO5CSQ/unsubscribe.
To unsubscribe from this group and all its topics, send an email to wazuh+un...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/wazuh/2ee6b2b3-5018-48d3-951e-f753e987ba13n%40googlegroups.com.

--

Openime Oniagbi THREAT INTELLIGENCE

[Mateusz Tyborski]

I've recently reported a similar issue  Missing superseders in MSU Vulnerabilities feed - false positive missing KB4511553 (CVE-2019-1226,CVE-2019-1222,CVE-2019-1182,CVE-2019-1181) (google.com)  and get answer form Julia  Research on the relation between cumulative Windows updates · Issue #14134 · wazuh/wazuh · GitHub 

There are gaps of information in Microsoft Update Catalog so a ‎workaround ‎is needed.

Regards

Mateusz

[Chris Herrmann]

Hi, as an SSU / CU package it should be superceded by any later:

https://docs.microsoft.com/en-us/windows/deployment/update/quality-updates

the device in question has the latest security CU: KB5015808  

but it's still flagging the 2017 update. The host was installed after 2017... so that KB in question was already deprecated by the time it was deployed. I've got a small number of hosts that are flagging, I haven't checked if they all share things like "installed after DD/MM/YYYY" or something like that yet.

Thanks @openime.oniagbi I'll try adding an exception for the impacted hosts as you've described there.

Is there a general process that should be capturing this type of thing automatically? or is it manually maintained by the wazuh / ossec team?

@Mateusz yep that's one of the similar examples I found :)

thanks all,

Chris

[Chris Herrmann]

just confirming i've added the CVE exclusions to local-rules and it has the intended effect. let me know if there's anything you'd like me to test / try etc,

thanks!

[Chris Herrmann]

one small thing to be aware of that took me a while to confirm - when you make the change, the previously detected vulns are still there. this means that when you're reviewing the host you still see XX CVE-2016-XXXXXX showing up. so for example - if the last poll event was 5 minutes ago - you'll still have a recent vuln showing up, which makes it difficult to validate that your exclusion is working. took me a while to work this out... eventually i joined the dots and changed the time filter to 10 mins / 20 mins etc etc, and have just checked again this morning and the last event is just prior to me making the change yesterday.