Research the detection for vulnerabilities that require a specific OS version to match

[pereyra-m]

Description

During the analysis of #23747, some sanitizations were requested. For example:

• https://github.com/wazuh/intelligence-data/issues/356
• https://github.com/wazuh/intelligence-data/issues/353

Nevertheless, after setting the specific affected versions for macOS, it's still required to make sure the detection occurs as expected.

DoD

• Research about the sanitizations mentioned and perform manual tests
• Upload a comment with the result of the analysis
• Create issues for any action item that arises (if any)

[pereyra-m]

Update

I begin with the analysis of the translations and the required manual tests to verify the behavior.

[pereyra-m]

Analysis

The macOS scan for the cases detailed above was analyzed.

As @sebasfalcone points out, the entry in the global CPE map for macOS lacks of a version field.
It should be

  "macOS": "apple:macos:$(VERSION)::::"

This simple change would allow to improve the detection when the platforms array of a package contains an entry with an specific version.

Proposal: update the map with the new entry.

But the naming problem is different, and it affects the OS scan.
According to https://es.wikipedia.org/wiki/MacOS, the OS name has changed across the versions:

• Mac OS X: v10.0 <= version <= v10.8
• OS X: v10.9 <= version <= v10.11
• Mac OS: v10.12 <= version (Sierra, the oldest OS supported by Wazuh agent)

There is also an old OS X Server that we don't need to consider.

The problem is that some candidates in the NVD don't follow this structure, and use a name that doesn't correspond to the version. For example:

• https://nvd.nist.gov/vuln/detail/CVE-2020-10001
• https://nvd.nist.gov/vuln/detail/CVE-2020-10011
• https://nvd.nist.gov/vuln/detail/CVE-2020-9942

These are false negatives, because the agents installed in v10.12 and above will report an OS CPE with macos but the NVD uses mac_os_x as product name.

Proposal: create a rule in the migration tool that automatically replaces mac_os_x by macos if the affected range includes the OS version range covered by the Wazuh agent.

Another issue found can be seen at

• https://nvd.nist.gov/vuln/detail/CVE-2021-25264
• https://nvd.nist.gov/vuln/detail/CVE-2018-13385
• https://nvd.nist.gov/vuln/detail/CVE-2023-49646
  Where there is a platform macos/mac_os_x extracted from the CPE, but this string will never match the OS code name (the OS cpe isn't compared when the content doesn't have a CPE).

Proposal: create a rule in the migration tool that inserts a generic macos CPE when the target_sw string is read.

Really similar to

• https://nvd.nist.gov/vuln/detail/CVE-2019-7040
• https://nvd.nist.gov/vuln/detail/CVE-2019-7106
  That have a CPE in platforms' array with - in the version or mac_os_x as "running on" dependency, making the comparison fail.

Proposal: we can't change the behavior of the CPE comparison. We must sanitize all platforms that contain a - in the version field and use a *.

The most complex situations that were found

• https://nvd.nist.gov/vuln/detail/CVE-2021-21300
  Require the missing capability of evaluate a range of versions in the platforms' array.

Proposal: manually decompose the range in a detailed list of CPEs with single affected versions for each platform that has this condition.

[sebasfalcone]

Conclusion

We can divide the analysis into three distinct parts

Wrong CPEs for macOS

We can fix this without altering the inner workings of the scanner. To do so, we can make use of some sort of dictionary (taking inspiration from here)

CC: @wazuh/devel-cppserver-div2

target_sw field from the CPEs

We have two paths:

• Re-interpret the target_sw field in the content to convert it into a platform
  • Further investigation is needed to see the impact on the scanner
  • CC: @wazuh/devel-cppserver-div2
• Make a more complete use of the CPEs in the scanner
  • Currently, we are not using the CPEs to their full intent, we may want to adapt the scanner to do so
  • CC: @wazuh/devel-cppserver-div1

Interpretation of - fields in the CPEs

This one is tricky. We know that this value is used without regard by the NVD. My take is that we should revisit all the CPEs that make use of it and manually classify them (for later sanitization)

CC: @wazuh/devel-threatintel

[Dwordcito]

@sebasfalcone please update this issue with the definitions talked the last tuesday.

[sebasfalcone]

Action items

Interpretation of - fields in the CPEs

For Windows systems, the proposed solution can be found here:

• https://github.com/wazuh/intelligence-platform/issues/1583#issuecomment-2162781907

Further investigation is needed to see if the same solution applies to macOS:

• https://github.com/wazuh/intelligence-platform/issues/1605

target_sw field from the CPEs

• @wazuh/devel-cppserver-div2: Will generate a list of all CPEs that contain a target_sw
• @wazuh/devel-cppserver-div1: Will analyze the list and generate the corresponding mapping target_sw to vendor.
• @Damian-Mangold: Will generate the issue to apply these changes
  • https://github.com/wazuh/intelligence-platform/issues/1610

Wrong CPEs for macOS

• @Damian-Mangold will create the corresponding issue
  • Third Party Migration - NVD : fix <product> field of the macOS CPEs

[Damian-Mangold]

Hi @sebasfalcone , these are the CPEs of the content we are migrating from the NVD where the target_sw field is not a "-" or "*".

report_target_sw.zip

[sebasfalcone]

From the provided list, I've filtered out using the following criteria:

• It should refer to an OS
• It should be supported by VD

Tier 1

Apple

Entries that should match with a CPE from CPE

• mac
• mac_os
• macos

Microsoft

Entries that should match with the generic CPE

• windows

Entries that should match with a CPE from this list

• windows_server

Linux

Entries that should match with the generic CPE

• linux
• linux_kernel

Entries that should match with a CPE from this list

• debian
• linux_mint
• oracle
• redhat_enterprise_linux
• suse
• suse_linux
• ubuntu

Note

There may not be a specific CPE entire for that OS. If so, we should analyze the case and create it

Tier 2

• windows_server_2008

Tier 3

• windows_server_2003
• windows_xp

No tier

• windows_7
• windows_8
• windows_8.1
• windows_vista
• mac_os_x

Maping

All the items listed above should be mapped using a similar logic to:

• https://github.com/wazuh/intelligence-platform/issues/1609

[sebasfalcone]

ETA moved

Due re-definitions the ETA will be delayed

[sebasfalcone]

Conclusion

• All issues dispatched
• Solution will be made by content