search

wazuh / wazuh

Wazuh - The Open Source Security Platform. Unified XDR and SIEM protection for endpoints and cloud workloads.
https://wazuh.com/
Other
9.44k stars 1.49k forks source link

The refactored vulnerability scanner should consider the generic Windows CPE for "running on" configurations from NVD #23149

Open pereyra-m opened 1 month ago

pereyra-m commented 1 month ago

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: https://github.com/wazuh/wazuh/issues/10633.

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

2024-04-26_12-01

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:

DoD

MiguelazoDS commented 2 weeks ago

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

platform_error.txt

GabrielEValenzuela commented 2 weeks ago

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 commented 2 weeks ago

@GabrielEValenzuela Moved to 4.9.0

GabrielEValenzuela commented 2 weeks ago

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:

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:

3.2 Expected Benefits

4. Impact Analysis

4.1 Technical Impact

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.

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 commented 1 week ago

Update

sebasfalcone commented 6 days ago

Issue blocked

Awaiting for changes from 4.8.0 to be merged in 4.9.0

sebasfalcone commented 1 day ago

Update