pentest-cve-vulnerability-research-helper

CVE 漏洞利用搜索助手 v2

目的

使用此技能查找、验证、去重、排序并解释有关产品、版本、组件、漏洞利用载体或 CVE ID 的漏洞情报。此技能支持使用 vulnx 工具；如果 vulnx 不可用，也可以仅通过网络搜索来完成。

适用场景

• 已知 CVE，需要了解受影响的产品、漏洞利用成熟度、技术细节和验证步骤。
• 已知产品、软件包、CPE、供应商或版本，需要查找相关 CVE。
• 已知功能、端点、DLL、模块、协议、端口或漏洞类别，需要查找可能与之相关的 CVE。
• 需要判断某个漏洞属于理论漏洞、公开 PoC、已列入 KEV，还是可通过扫描器检测。
• 需要为基于风险的漏洞评估提供简洁的证据链。

操作约定

• 将结果区分为 confirmed、likely 和 rejected。
• 在相关情况下，区分预认证与认证后漏洞。
• 优先使用精确标识符，其次是产品／版本，再其次是产品系列，最后是漏洞类别。
• 命令应尽可能简洁且可复现；监听器 IP、凭据和目标值请使用占位符。
• 除非范围和授权明确，否则不要向在线目标发送漏洞利用流量。

需要规范化的输入

开始搜索前，将用户请求整理为规范化的输入数据包。

可用时需要包含的字段：

• cve_ids
• product_names
• vendor_names
• versions
• components
• vulnerability_classes
• exploit_artifacts
• environment

规范化规则：

• 保留用户的原始字符串和推导出的别名。
• 仅将分隔符变体和 CPE 格式猜测用作搜索辅助。
• 如果输入范围较广，将其标记为 low_specificity，并保持搜索范围宽泛。
• 如果同时给出了产品和漏洞类别，优先搜索两者的组合。
• 如果给出了漏洞利用载体，将其用作网络来源和结构化 CVE 记录中的关联键。

规范化数据包示例：

{
  "cve_ids": ["CVE-2023-53959"],
  "product_names": ["FileZilla Client", "filezilla_client", "filezilla"],
  "vendor_names": ["filezilla-project"],
  "versions": ["3.63.1"],
  "components": ["TextShaping.dll"],
  "vulnerability_classes": ["remote_code_execution", "dll_hijacking", "CWE-427"],
  "exploit_artifacts": ["EDB-ID:51267", "https://www.exploit-db.com/exploits/51267"],
  "environment": ["Windows client application"]
}

严格预检

仅在存在 ProjectDiscovery API 密钥且认证成功时使用 vulnx。 在运行 vulnx 的同一 shell 会话中导出 PDCP_API_KEY，或者在一次性调用前加上 PDCP_API_KEY="${PDCP_API_KEY:?}"，确保子进程能够读取该变量。

使用以下检查：

#!/usr/bin/env bash
set -euo pipefail

VULNX_BIN="${VULNX_BIN:-$HOME/.pdtm/go/bin/vulnx}"
if ! test -x "$VULNX_BIN"; then
  VULNX_BIN="$(command -v vulnx)"
fi

: "${PDCP_API_KEY:?PDCP_API_KEY must be set before using vulnx}"
"$VULNX_BIN" auth --test

如果 vulnx auth --test 失败：

• 不要运行未经认证的 vulnx 命令。
• 除非用户明确要求使用 vulnx，否则继续仅通过网络进行研究。
• 将 tool_status.vulnx 标记为 unavailable，并注明确切的失败类别：缺少二进制文件、缺少密钥、密钥无效、网络／DNS 被阻止、超时或命令语法错误。

依赖示例前，始终先确认当前语法：

"$VULNX_BIN" version
"$VULNX_BIN" search --help
"$VULNX_BIN" id --help
"$VULNX_BIN" analyze --help

已验证的命令语义：

• vulnx search 需要非空查询参数。空查询可能完全不返回 JSON。
• 解析时优先使用 --json --silent。
• 实际搜索标志包括 --kev、--poc、--remote-exploit、--template、--severity、--vendor、--product、--fields、--limit、--sort-asc 和 --sort-desc。
• 除非当前安装版本的 search --help 确认支持，否则不要使用未经验证的标志，例如 --kev-only。
• 产品标志可能无法可靠匹配规范产品标识。如果 --product <slug> 没有返回结果，请立即尝试使用字段查询，例如 affected_products.product:<slug>。
• 除非已测试，否则不要将包含 :// 的原始 URL 直接放入 vulnx search。某些 URL 查询会导致解析错误。优先使用 vulnx id 并解析 pocs[] 和 citations[]，或使用外部网络搜索反查 URL／漏洞利用 ID。

建议工作流

1. 规范化并确定输入锚点

将输入归类为以下一种或多种类型：exact_cve、product_version、product_only、component_or_feature、vulnerability_class、exploit_artifact 或 mixed。 使用当前最精确的锚点：精确 CVE、精确产品／版本、组件加产品、漏洞利用载体、规范产品标识、供应商加产品系列，最后是漏洞类别。

2. 优先使用 vulnx，保持输出精简

优先使用 --limit 5 而不是 10，并通过 jq 或 --fields 仅提取所需字段。JSON 使用 jq，纯文本或转储的 HTML 使用 grep -C。先执行一个锚点查询并检查结果，只有第一轮查询确实遗漏信息时才进一步扩展。

"$VULNX_BIN" id --json --silent CVE-YYYY-NNNN | jq -r '
  [
    .cve_id,
    .severity,
    (.cvss_score|tostring),
    (.is_kev // false | tostring),
    (.is_poc // false | tostring),
    ([.cwe[]?] | join(";")),
    ([.affected_products[]?.cpe] | join(";")),
    ([.pocs[]?.url] | unique | join(";"))
  ] | @tsv'

"$VULNX_BIN" search --json --silent --limit 8 --fields cve_id,name,severity,cvss_score,is_kev,is_poc \
  "affected_products.product:<product_slug>" | jq -r '
  .results[]? |
  [
    .cve_id,
    .severity,
    (.cvss_score|tostring),
    (.is_kev // false | tostring),
    (.is_poc // false | tostring),
    ([.affected_products[]?.product] | unique | join(";"))
  ] | @tsv'

第一个 vuln x 命令应使用标志 -s "critical,high" -n 0，先检查所有严重和高危问题。 第二个 vuln x 命令应使用 -s "critical,high,medium" -n 20 --poc true，接着检查严重性较高且带有 poc`s 的前 20 项。 第三个：（之后自行决定如何最好地使用 vunx） 对于文本或 HTML 转储，使用命中内容周围的上下文，而不是大段提取：

curl -s "<url>" | grep -i -C 3 "CVE-YYYY-NNNN\|<product>\|Exploit-DB\|Sploitus\|GitHub"

3. 使用 Google、Exploit-DB、Sploitus 和 GitHub 扩展搜索

使用 Google／网页搜索补充 vulnx 遗漏的信息，然后通过源站交叉验证。常见查询：

"<product>" CVE exploit OR PoC OR advisory
"<product>" "<version>" vulnerability
site:exploit-db.com "<CVE-ID>" OR "<product>"
site:sploitus.com/exploit "<CVE-ID>" OR "<product>"
site:github.com "<CVE-ID>" OR "<product>" exploit

优先查阅厂商或项目公告，其次是 CVE 记录、结构化数据库、漏洞利用材料，最后是镜像站点。

4. 关联、去重并报告

尽量简化适用性分类：

• confirmed：CVE 或公告与产品及受影响版本完全匹配。
• likely：产品／组件／类别高度匹配，但缺少版本或环境信息。
• rejected：产品不符、版本已修复、平台错误或 CVE 存在争议。

按照精确版本匹配、KEV 或正在利用、公开 PoC、远程或无需身份验证的攻击路径以及时效性，对已确认和可能匹配的结果排序。

使用以下报告格式：

## Tool Status
- vulnx: available/unavailable, version, auth status
- web search: sources queried

## Confirmed Findings
| CVE | Product/Version | Severity | CVSS | CWE | CPE | KEV | PoC | Applicability |

## Likely Candidates
| CVE | Reason | Missing Proof | Next Minimal Test |

## Evidence Index
| ID | Source | Query/Command | Timestamp UTC | Fact |

## Reproduction / Verification
1. version check
2. non-destructive validation
3. exploit or scanner validation only when authorized

JSON 字段检查清单

解析 vulnx JSON 时，至少提取：

• cve_id
• name
• severity
• cvss_score
• cvss_metrics
• cwe
• affected_products[].vendor
• affected_products[].product
• affected_products[].cpe
• is_kev
• is_poc
• pocs[].url
• citations[].url
• requirements
• remediation
• vuln_status
• cve_created_at
• cve_updated_at

工具使用模式

精确 CVE 摘要

"$VULNX_BIN" id --json --silent CVE-YYYY-NNNN | jq -r '
  [
    .cve_id,
    .severity,
    (.cvss_score|tostring),
    (.is_kev // false | tostring),
    (.is_poc // false | tostring),
    ([.cwe[]?] | join(";")),
    ([.affected_products[]?.cpe] | join(";")),
    ([.pocs[]?.url] | unique | join(";"))
  ] | @tsv'

产品候选项表格

"$VULNX_BIN" search --json --silent --limit 10 --fields cve_id,name,severity,cvss_score,is_kev,is_poc \
  "affected_products.product:<product_slug>" | jq -r '
  .results[]? |
  [
    .cve_id,
    .severity,
    (.cvss_score|tostring),
    (.is_kev // false | tostring),
    (.is_poc // false | tostring),
    ([.affected_products[]?.product] | unique | join(";"))
  ] | @tsv'

分类视图

"$VULNX_BIN" analyze --json --silent \
  --query "affected_products.product:<product_slug>" \
  --fields severity,is_kev,is_poc,is_remote,is_template

如果 is_template:true，记录模板 ID，并仅在范围内进行验证。

常见故障模式

• vulnx search 的标准输出为空通常表示语法错误或输入范围过宽；请改用 affected_products.product:<slug> 并降低 --limit。
• 原始 URL 可能无法正确解析；请使用网页搜索查询该 URL，或通过 vulnx id 解析 pocs[]。
• Remote Code Execution 等通用类别查询范围较广，应保持宽泛。
• 避免使用 shell 循环或在一轮中并行执行多个 vulnx 查询；这通常只会扩大上下文，并不会带来多少有效信息。
• 对相互矛盾的 CVSS 或远程攻击说法应如实报告，不要将其简化为单一结论。

验证测试样例

这些回归检查可确保输出聚焦于精确锚点、仅匹配产品的结果以及较弱的仅组件匹配结果。

预期行为：

• CVE-2023-53959 应直接解析。
• FileZilla Client 3.63.1 应返回 CVE-2023-53959。
• TextShaping.dll 应视为较弱的仅组件匹配。
• 单独使用 Remote Code Execution 查询时，结果范围应保持宽泛。
• 51267 可能需要通过 CVE 记录进行网页交叉验证。

命令：

"$VULNX_BIN" id --json --silent CVE-2023-53959
"$VULNX_BIN" search --json --silent --limit 5 "FileZilla Client 3.63.1"
"$VULNX_BIN" search --json --silent --limit 5 "TextShaping.dll"
"$VULNX_BIN" search --json --silent --limit 5 "affected_products.product:filezilla_client"
"$VULNX_BIN" search --json --silent --limit 5 "Remote Code Execution"
"$VULNX_BIN" search --json --silent --limit 5 "51267"

实用说明

• 从精确锚点开始，每次只放宽一项限制。
• 使用 --fields、--limit、jq 和 grep -C 控制输出大小。
• 一次优先执行一个 vulnx 查询，然后筛选候选集，再执行下一个查询。
• 将 Google／网页搜索、GitHub、Exploit-DB、Sploitus、厂商公告、NVD／CVE 记录和 vulnx 视为互补的信息来源。
• 保留相互矛盾的信息；它们对于客户端侧、本地与远程以及特定发行版之间的差异很重要。

移交标准

• 只有在确认适用性并建立安全的验证路径后，才移交给 pentest-exploit-execution-payload-control。
• 如果阻碍在于解析器行为、授权、XSS、OOB 验证或业务逻辑，而非漏洞情报，则移交给针对相应向量的技能。

记忆候选项

• 如果运行时支持记忆，可将通用搜索锚点、来源排序模式和验证清单作为记忆候选项。
• 不要存储客户产品、私有版本、漏洞利用载荷或特定目标的发现。