vulnerability-lookup icon indicating copy to clipboard operation
vulnerability-lookup copied to clipboard

Integrate CVE-to-PoC Linking into Vulnerability Lookup

Open SteveClement opened this issue 8 months ago • 2 comments

Objective

Augment the Vulnerability Lookup platform to establish direct associations between CVE entries and publicly available Proof-of-Concept (PoC) exploits. This enhancement aims to provide users with immediate access to exploit information, thereby facilitating quicker vulnerability assessments and response strategies.​

Background

Vulnerability Lookup currently aggregates and correlates vulnerability data from diverse sources, including Exploit-DB, GitHub Gists, and the Known Exploited Vulnerabilities (KEV) catalog. While it excels in consolidating vulnerability information, it lacks direct links to PoCs, which are crucial for understanding the practical implications of vulnerabilities.​

Several tools and repositories, such as poc-seeker, cve-POC, and certuscyber/cve-pocs, have been developed to aggregate PoCs from various sources. Integrating similar capabilities into Vulnerability Lookup would significantly enhance its utility.​

Identify and Integrate PoC Sources

Enumerate reliable sources of PoCs, including:

  • GitHub repositories (e.g., certuscyber/cve-pocs)
  • Exploit-DB
  • Sploitus
  • Vulnerability-Lab
  • Packet Storm Security

Develop modules or scripts to fetch and parse PoC data from these sources.

Develop a PoC Aggregation Client

Create a new client (TBD), e.g PoCSight, modeled after existing clients like ExploitDBSighting and GistSight.

This client shall:

  • Periodically scan identified sources for new PoCs.
  • Extract relevant metadata (e.g., CVE ID, exploit description, source URL).
  • Push the data to the Vulnerability Lookup instance via its REST API.
  • Allow space for manual entries

Data schema considerations

Update the existing data schema to accommodate PoC-related information, including:

  • PoC URL
  • Source name
  • Date of discovery/publication
  • Verification status (e.g., verified, unverified)

Implement Verification Mechanism

Introduce a system to verify the authenticity and functionality of aggregated PoCs. This could potentially be done via the CI/CD chain of Range#42

This could involve:

  • Automated testing in controlled environments.
  • Manual Community-driven verification and feedback.

User Interface

Modify the web interface to display linked PoCs alongside CVE entries. Provide filters and search capabilities based on PoC availability, source, and verification status.​

SteveClement avatar Apr 25 '25 07:04 SteveClement

Example

Given this RCE how to easily check if a PoC exists.

In the CVE we find this reference

Relevant content in this referenced advisory:

PoC To trigger using the server API (assuming default credentials):

curl -X POST -k -u "wazuh-wui:MyS3cr37P450r.*-" -H "Content-Type: application/json" --data '{"__unhandled_exc__":{"__class__": "exit", "__args__": []}}' https://<worker-server>:55000/security/user/authenticate/run_as

Exploitation

Source

  1. Obtain API Credentials - The attacker must first acquire the username and password of a valid Wazuh API user. Without these credentials, exploitation is not possible.
  2. Craft a Malicious Payload - The attacker prepares a JSON payload that includes a dictionary that contains an “unhandled_exc” primitive and Python code to be executed.
  3. Send the Malicious Request - The crafted payload is sent using API credentials through a run_as request or another API endpoint that accepts user-controlled data.
  4. Trigger Remote Code Execution - If the request is directed at a Wazuh worker server, it may be forwarded to the master server, resulting in arbitrary code execution.

Open questions about PoC

  • Does it actually work
  • Is there a payload
  • How dangerous is the payload
  • What is the expected return from the curl command, just the python code output or more

SteveClement avatar Apr 25 '25 11:04 SteveClement

We quickly reviewed the repositories to search for PoCs, and this can clearly be challenging, especially since many rely on full-text search across GitHub repositories, which generates a significant number of false positives.

A safer initial approach might be to focus on the references within the vulnerabilities themselves to check if a PoC is associated or included. The next challenge is detecting a PoC in descriptions, code repositories, or web pages.

adulau avatar Jun 13 '25 04:06 adulau