The refactored vulnerability scanner should consider the generic CPEs for "running on" configurations from NVD

[pereyra-m]

Description

The legacy vulnerability detector didn't consider the case when the CVE had a generic Windows CPE as a condition for a vulnerability. There is an open epic that wasn't implemented: #10633.

For example: https://nvd.nist.gov/vuln/detail/CVE-2012-4142

Here any OS (Windows 10, Windows 11, Windows Server, etc.) will match because the CPE generation from the OS data is a 1:1 transformation that doesn't consider this generic case.

The new module should solve this issue.
It is considered that the CPE is wrong, because according to the CPE structure

cpe:<cpe_version>:<part>:<vendor>:<product>:<version>:<update>:<edition>:<language>:<sw_edition>:<target_sw>:<target_hw>:<other>

We shouldn't say that windows is the product name affected but the platform (edition, sw_edition, or target_sw).

Related issue: https://github.com/wazuh/intelligence-platform/issues/1472

Proposal

A possible solution would be making the scanner aware of the platform field from OS info (windows) or format from packages (win) and use it to compare against the platform reported in the CPE. This requires two things:

• The changes in the scanner to take that value and make it available for the scanner callback
• The sanitization in the affected CVEs

DoD

• Analyze the proposal with the team. Compare against other options.
• Create a PoC to test the selected approach
• Share the results in a comment
• Discuss with management how to proceed

[MiguelazoDS]

I didn't analyze them all, but I have some logs that may help you with this issue.

platform_error.txt

[GabrielEValenzuela]

Thanks, @MiguelazoDS !

It's really help. I'm trying to finish the design solution proposal, I found a little block with the target branch, @sebasfalcone , if this issue is for 5.0.0, probably we won't get access to the last development of 4.8.0.

I'm suffering a little block with the design, I'm trying to fix it ASAP. Fortunately, the content is sanitized so a big part of the work is done.

[sebasfalcone]

@GabrielEValenzuela Moved to 4.9.0

[GabrielEValenzuela]

Design Proposal: Add CPE for Generic OS and Platform (v1.0.2)

1. Introduction

This proposal outlines the plan to integrate Common Platform Enumeration (CPE) for generic operating systems and platforms within our system. The objective is to enhance the capability of our system to accurately identify and categorize different OS and platform configurations, especially in cases where vulnerabilities have a generic Windows CPE as a condition.

2. Background

The legacy vulnerability detector did not account for cases where a CVE had a generic Windows CPE, resulting in inaccurate vulnerability detection. This issue arises because the current CPE generation process is a 1:1 transformation from OS data, which doesn't handle generic cases. For example, vulnerabilities like CVE-2012-4142 list known affected software configurations generically, such as any version of Windows (Windows 10, Windows 11, Windows Server, etc.).

Common Platform Enumeration (CPE) is a standardized method used for identifying classes of applications, operating systems, and hardware devices present in an organization's computing environment. By incorporating CPE, we aim to improve our system's efficiency in managing and tracking these components.

Known Affected Software Configurations

This section of the vulnerability detail page shows what software or combinations of software are considered vulnerable at the time of analysis. The NVD uses the CPE 2.3 specification when creating these applicability statements and the matching CPE Name(s). Applicability statements communicate which products are vulnerable in a relatively flexible syntax, primarily designed for machine processing.

Configurations:

• Basic: A single node containing one or more sets of match criteria. Each CPE Name matching the criteria is considered vulnerable.
• Running On/With: A combination of nodes containing both vulnerable and non-vulnerable match criteria. Both nodes' criteria must be met for a vulnerability to apply.

CPE Structure:

cpe:<cpe_version>:<part>:<vendor>:<product>:<version>:<update>:<edition>:<language>:<sw_edition>:<target_sw>:<target_hw>:<other>

1. cpe:
   The prefix "cpe" indicates that the string is a Common Platform Enumeration name.

2. <cpe_version>:
   This specifies the version of the CPE specification being used. The current version is 2.3. Example: 2.3.

3. <part>:
   This denotes the type of entity being described. It can be one of the following:

   • a: Application
   • o: Operating System
   • h: Hardware

   Example: o for an operating system.

4. <vendor>:
   This is the name of the vendor or organization that created the product. It typically uses a lowercase representation with spaces and special characters replaced by underscores. Example: microsoft.

5. <product>:
   The name of the product, which is also typically in lowercase with spaces and special characters replaced by underscores. Example: windows_server.

6. <version>:
   The version of the product. This can include major and minor version numbers. Example: 2019 for Windows Server 2019.

7. <update>:
   Specifies any update or service pack applied to the product. This field can be empty if there is no update. Example: sp1 for Service Pack 1.

8. <edition>:
   Indicates the edition of the product, if applicable. Example: enterprise for the Enterprise edition.

9. <language>:
   The language of the product. This field is often left empty if the product is language-independent. Example: en for English.

10. <sw_edition>:
    Refers to the specific software edition, such as "professional" or "home". This field can be used to provide additional granularity. Example: professional.

11. <target_sw>:
    The target software platform for which the product is intended. This is used when the product runs on or with another software product. Example: x64 for a 64-bit platform.

12. <target_hw>:
    The target hardware platform for which the product is intended. This is used to specify the hardware architecture. Example: x86 for a 32-bit architecture.

13. <other>:
    Any other relevant information that doesn't fit into the previous categories. This field can be used for additional descriptors. Example: srv_core for a server core installation.

3. Proposal

3.1 Design Details

The new CPE module will:

• Parse and generate CPE names for various OS and platform configurations, considering generic cases.
• Implement logic to handle generic Windows CPEs by mapping specific OS versions to their corresponding generic identifiers.
• Integrate with existing inventory and monitoring systems to update and maintain accurate records.
• Provide a user interface for manual entry and verification of CPEs when automatic detection fails.

3.2 Expected Benefits

• Improved Accuracy: Enhanced identification and categorization of OS and platforms, particularly for vulnerabilities with generic CPEs.
• Streamlined Inventory Management: Automated updates and maintenance of system records.

4. Impact Analysis

4.1 Technical Impact

• System Performance: Minimal impact expected as the CPE module will run as a background process.
• Data Storage: Slight increase in storage requirements due to additional metadata.
• Integration: Requires modifications to existing inventory and monitoring systems (CPE Maps).

5. Diagrams

Sequence Diagram

sequenceDiagram
    participant User as Manager
    participant platformVerify
    participant callbackData
    participant ScannerHelper
    participant contextData

    User->>platformVerify: platformVerify(cnaName, package, callbackData, contextData)
    platformVerify->>callbackData: check if platforms() is not empty
    alt platforms() not empty
        loop for each platform in platforms()
            platformVerify->>ScannerHelper: isCPE(platformValue)
            alt platform is CPE
                platformVerify->>ScannerHelper: parseCPE(platformValue)
                ScannerHelper-->>platformVerify: return cpe
                platformVerify->>ScannerHelper: parseCPE(contextData->osCPEName().data())
                ScannerHelper-->>platformVerify: return osCPE
                platformVerify->>ScannerHelper: compareCPE(cpe, osCPE)
                alt CPEs match
                    platformVerify-->>User: return true (match found)
                end
            else platform is not CPE
                platformVerify->>contextData: compare platformValue with contextData->osCodeName()
                alt platformValue matches osCodeName
                    platformVerify-->>User: return true (match found)
                end
            end
        end
        note over platformVerify: New proposal, not return false
        platformVerify->>ScannerHelper: build new CPE with vendor, product, and platform (Generic/Runing on)
        ScannerHelper-->>platformVerify: return newCPE
        platformVerify->>ScannerHelper: parseCPE(newCPE)
        ScannerHelper-->>platformVerify: return parsedNewCPE
        platformVerify->>ScannerHelper: compareCPE(parsedNewCPE, osCPE)
        alt new CPEs match
            platformVerify-->>User: return true (new match found)
        else new CPEs don't match
            platformVerify-->>User: return false (no match found)
        end
    else platforms() is empty
        platformVerify-->>User: return true
    end

6. Changes differences

The logic was modified to adapt the main flow of instructions, data, and errors to the current code. The result is not 100% as described in the sequence diagram, but the essence is the same.

7. Conclusion

Implementing CPE for generic OS and platforms will significantly enhance our system's accuracy and efficiency in managing and tracking various configurations. This proposal details the design and expected benefits to ensure a smooth integration process.

7. Approval and Feedback

Please review the proposed design and provide feedback or approval. Your input is crucial for refining and finalizing this implementation.

• Design approved by @sebasfalcone

---

Update History

History

Date	Author	Comments	Version
2024-05-17	@GabrielEValenzuela	First version	1.0.0
2024-05-17	@GabrielEValenzuela	Add seq diagram	1.0.1
2024-05-23	@GabrielEValenzuela	Add section 6	1.0.2

[sebasfalcone]

Update

• Issue changed DRI due to @GabrielEValenzuela taking vacations
• ETA updated, because this issue will be blocked until we merge 4.8.0 into 4.9.0

[sebasfalcone]

Issue blocked

Awaiting for changes from 4.8.0 to be merged in 4.9.0

[sebasfalcone]

Update

• Upward merge done
• Target branch updated to 5.0.0

[GabrielEValenzuela]

Update

• 10/06 - Add readme
• 11/06 - Run tests to check functionality

---

[GabrielEValenzuela]

Related PR

• https://github.com/wazuh/intelligence-data/pull/284

[sebasfalcone]

Issue blocked

Awaiting for content to be updated for QA efficacy tests to pass in GA

[sebasfalcone]

Issue unblocked

@GabrielEValenzuela Please cherry-pick the following commit to fix the QA tests f179e6d

[GabrielEValenzuela]

Update

• Apply commit f179e6d to fix QA tests.
• Rebase

[Dwordcito]

We need talk about this, I need to know if it is the correct design, I want to avoid cpe comparisons as much as possible.

[sebasfalcone]

Conclusion

We decide to fix this problematic from the generated content and not on the scanner. This will make the fix available for all user that are using 4.8.0