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 を実行する同じシェルセッションで 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 10 よりも --limit 5 を優先し、必要なフィールドだけを jq または --fields で指定してください。JSON には jq、プレーンテキストやダンプした HTML には grep -C を使います。まず 1 つのアンカークエリを実行して結果を確認し、最初の検索で実際の不足が残った場合にのみ範囲を広げます。

"$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 コマンドでは、最初にすべての critical と high を確認するため、フラグ -s "critical,high" -n 0 を指定します。 2 番目の vuln x コマンドでは、PoC がある深刻度の高い上位 20 件を次に確認するため、-s "critical,high,medium" -n 20 --poc true を指定します。 3 番目：最適な vunx の使い方を自分で判断してください。 テキストや HTML のダンプでは、大量の範囲を抽出するのではなく、ヒット箇所の前後のコンテキストを使います。

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

3. Google、Exploit-DB、Sploitus、GitHub で検索を広げる

vulnx で見つからない情報を補うために Google／ウェブ検索を使い、その後、情報源のサイトで裏付けを取ります。一般的なクエリは次のとおりです。

"<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 に異議がある場合です。

confirmed と likely の結果は、バージョンの正確な一致、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 の stdout が空の場合、通常は構文が誤っているか入力が広すぎます。affected_products.product:<slug> を使い、--limit を小さくして再試行します。
• 生の URL はうまく解析されないことがあります。ウェブ検索で URL を検索するか、vulnx id から pocs[] を解析します。
• Remote Code Execution のような一般的なクラスクエリは広範囲に及ぶため、広いまま扱います。
• 1 回の検索で、多数の 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"

実践的な注意事項

• 正確なアンカーから始め、制約は一度に 1 つずつ緩めます。
• --fields、--limit、jq、grep -C を使って出力を小さく保ちます。
• 一度に 1 つの vulnx クエリを実行し、次のクエリを実行する前に候補セットを絞り込みます。
• Google／ウェブ検索、GitHub、Exploit-DB、Sploitus、ベンダーアドバイザリ、NVD／CVE レコード、vulnx は、互いを補完する情報源として扱います。
• 矛盾はそのまま残します。クライアント側、ローカルとリモートの違い、ディストリビューション固有の違いでは、重要な情報です。

引き継ぎ基準

• 適用可能性と安全な検証経路が確立した後に限り、pentest-exploit-execution-payload-control に引き継ぎます。
• 問題が脆弱性情報ではなく、パーサーの動作、認可、XSS、OOB 検証、またはビジネスロジックにある場合は、ベクトル固有のスキルに引き継ぎます。

メモリ候補

• ランタイムがメモリに対応している場合、汎用的な検索アンカー、ソースのランキングパターン、検証チェックリストはメモリ候補になります。
• 顧客の製品、非公開のバージョン、エクスプロイトのペイロード、ターゲット固有の調査結果は保存しないでください。