mcpField
H
hunt-wordpress

hunt-wordpress

github.com/uphiagoセキュリティ1.3k41 回インストール8 週間前に更新
リポジトリ

hunt-wordpress について

hunt-wordpress は、WordPress環境の許可されたセキュリティ評価向けスキルです。コア、テーマ、プラグイン、REST、XML-RPCを調べ、証拠に基づく範囲限定の検証を重視します。

主な機能

  1. 01複数の手掛かりによるWordPress確認
  2. 02コア・テーマ・プラグインの把握
  3. 03RESTデータと認可の確認
  4. 04CORSとXML-RPCの判定
  5. 05ステージングとソース露出の調査
  6. 06範囲を限定した証拠ベースの検証

活用シーン

  1. 01特定済みWordPressサイトの評価
  2. 02承認済みテストIDによるRESTエンドポイント確認
  3. 03ステージング環境と本番環境の比較
  4. 04ソースやエラーログ露出疑いの検証

インストール

コマンドをコピーしてターミナルで実行します。

$npx skills add https://github.com/uphiago/recon-skills --skill hunt-wordpress

インストール後、Claude Code で/hunt-wordpressを入力して読み込まれたか確認します。

詳細

WordPress セキュリティ評価

WordPress のコア、REST、XML-RPC、プラグイン、テーマ、認証境界、 および関連するインストールをマッピングしてから、脆弱性に応じたテストを選択します。 WordPress の存在、公開ルート、またはバージョンの一致だけでは、 それ自体は所見になりません。

使用する状況

  • HTML、ヘッダー、アセット、Cookie、またはルートから WordPress が特定できる。
  • /wp-json/、/wp-login.php、/xmlrpc.php、または /wp-content/ にアクセスできる。
  • JavaScript またはソースコードから WordPress バックエンドが参照されている。
  • ステージング環境またはサブディレクトリのインストールが、メインサイトと異なる可能性がある。

前提条件

  • 明示的な許可と、最新の対象範囲の確認。
  • curl と jq。wpscan は任意です。
  • ロールまたは認可の確認に使用する、承認済みのテスト用 ID。
  • ブラインド SSRF テストが許可されている場合に限り、管理されたコールバックサービスを使用します。
  • 登録、アップロード、パスワード、プラグイン、その他の状態を変更するテストの直前に、明示的な承認を得ます。

実行方法

範囲を限定し、読み取り専用の調査から始めます。

TARGET="https://www.example.test"
OUTPUT_DIR="${OUTPUT_DIR:-./output/wordpress}"
mkdir -p "$OUTPUT_DIR"

for path in \
  / \
  /wp-json/ \
  /wp-login.php \
  /xmlrpc.php \
  /readme.html \
  /author-sitemap.xml; do
  curl -sS --max-time 10 \
    -o /dev/null \
    -w '%{http_code} %{content_type} %{size_download} %{url_effective}\n' \
    "$TARGET$path"
  sleep 1
done

手順

1. WordPress を確認する

複数のシグナルを使用します。

curl -sS --max-time 10 "$TARGET/" \
  | grep -Eio 'wp-content|wp-includes|wp-json|wordpress' \
  | sort -u

curl -sS --max-time 10 "$TARGET/wp-json/" \
  -o "$OUTPUT_DIR/rest-index.json"

jq -r '.namespaces[]? // empty' "$OUTPUT_DIR/rest-index.json" \
  | sort -u \
  > "$OUTPUT_DIR/rest-namespaces.txt"

一般的な 200 応答だけでは不十分です。疑わしいパスを、ランダムに生成した存在しないパスと比較して、キャッチオールルーティングを検出します。

2. コア、テーマ、プラグインのアセットをマッピングする
curl -sS --max-time 10 "$TARGET/" \
  | grep -Eo "wp-content/(plugins|themes)/[^/?\"']+" \
  | sort -u \
  > "$OUTPUT_DIR/components.txt"

可能な場合は、アセットパス、REST 名前空間、readme または変更履歴、HTML マーカー、バージョン付きファイルなど、少なくとも 2 つのシグナルでコンポーネントを確認します。正確な影響バージョンと前提条件を特定してから、CVE と照合します。

プラグインの検出とバージョンの検証には wordpress-plugin-hunt を使用します。

3. REST データと認可をマッピングする
for path in \
  /wp-json/ \
  /wp-json/wp/v2/types \
  /wp-json/wp/v2/posts?per_page=2 \
  /wp-json/wp/v2/pages?per_page=2 \
  /wp-json/wp/v2/users?per_page=2; do
  curl -sS --max-time 10 \
    -D "$OUTPUT_DIR/headers.tmp" \
    -o "$OUTPUT_DIR/body.tmp" \
    "$TARGET$path"
  printf '%s %s\n' "$path" "$(wc -c < "$OUTPUT_DIR/body.tmp")"
  sleep 1
done

影響を評価する前に、応答を分類します。

  • 公開済みの投稿やページは、通常、設計上公開されています。
  • ユーザー名はフィッシングや認証のリスクを高める可能性がありますが、アカウントの乗っ取りにはあたりません。
  • メールアドレス、ロール、下書き、設定、フォームの送信内容、注文、ログについては、個別にアクセス制御を確認する必要があります。
  • プラグインの名前空間が存在しても、すべての操作が保護されている場合があります。

認可に関する主張を検証するには、同じ合成オブジェクトに対して、匿名、ユーザー A、ユーザー B、承認済みの特権 ID で比較します。

4. ブラウザーで CORS を検証する
curl -sS --max-time 10 \
  -D "$OUTPUT_DIR/cors-headers.txt" \
  -o "$OUTPUT_DIR/cors-body.txt" \
  -H 'Origin: https://attacker.example' \
  "$TARGET/wp-json/wp/v2/users?per_page=2"

ヘッダーの反射は手がかりにすぎません。認証情報を伴う CORS の影響を確認するには、次の条件が必要です。

  1. 信頼できないオリジンが応答で許可されている。
  2. Cookie が必要な場合、Access-Control-Allow-Credentials: true が設定されている。
  3. 承認済みの認証済みブラウザーセッションがある。
  4. ブラウザーの JavaScript から非公開データを読み取れる。
  5. 匿名または公開データでのネガティブコントロールがある。

ブラウザーワークフロー全体には cors-credential-wordpress を使用します。

5. XML-RPC を分類する
curl -sS --max-time 15 \
  -X POST "$TARGET/xmlrpc.php" \
  -H 'Content-Type: text/xml' \
  --data-binary \
  '<methodCall><methodName>system.listMethods</methodName></methodCall>' \
  -o "$OUTPUT_DIR/xmlrpc-methods.xml"

grep -Eo '<string>[^<]+</string>' "$OUTPUT_DIR/xmlrpc-methods.xml" \
  | sed -E 's#</?string>##g' \
  | sort -u

プロトコルの分類中はリダイレクトに従わないでください。有効な methodResponse は XML-RPC の動作を示しますが、ステータスコードだけでは証明になりません。 認証情報のテスト、multicall による増幅、アップロード、SSRF の回避には、それぞれ個別の許可と安全上の制限が必要です。該当するメソッドと前提条件を確認できた場合に限り、xmlrpc-exploitation を使用します。

6. ステージング環境と二次インストールを確認する

証明書の透明性ログ、アーカイブ、アセットパスから、ステージングホストやサブディレクトリのインストールが判明することがあります。次の項目を比較します。

  • WordPress とプラグインのバージョン。
  • 認証と WAF の動作。
  • REST と XML-RPC の露出状況。
  • デバッグ設定とソースファイル。
  • Cookie、認証情報、ストレージ、デプロイパスの共有状況。

ステージング環境の制御が弱くても、その環境が対象範囲内であり、影響が実証された場合にのみ問題となります。範囲を限定した比較には staging-subdomain-hunt を使用します。

7. ソースとエラーの露出を確認する

観測されたスタックから妥当性を説明できるパスのみを調査します。ステータスではなく、コンテンツを検証します。

候補必要なコンテンツ
.git/HEADref: refs/heads/... などの Git 参照
.env一般的な HTML ではなく、設定の代入文
debug.log または error_log実際のアプリケーションエラー、または機密性の高い実行時データ
バックアップアーカイブ正しいファイルシグネチャと有意義な内容
ディレクトリ一覧ディレクトリインデックスのマーカーと実際のエントリ

source-leak-hunt と error-log-mining を使用し、露出を実証するために必要な最小限のサニタイズ済みサンプルのみを保持します。

8. 攻撃経路の候補を組み立てる

検証済みの前提条件のみをつなげます。

observed component
  -> exact version and configuration
  -> reachable vulnerable operation
  -> approved identity or synthetic object
  -> reproduced security impact

登録、XML-RPC、アップロードルート、実行可能な PHP 設定があっても、それだけで自動的に RCE の連鎖が成立するわけではありません。ロールの権限、アップロードの検証、保存先のパス、実行動作をそれぞれ個別に確認してください。

注意点

  • WordPress のルートは、CDN、キャッシュ、またはキャッチオールの動作の背後にあることがよくあります。
  • GET /xmlrpc.php が 405 を返しても、有効な POST メソッド呼び出しとして分類されたことにはなりません。
  • REST 名前空間が存在しても、プラグインの操作が未認証である証拠にはなりません。
  • 公開されている作成者のメタデータは、自動的に機密情報となるわけではありません。
  • プラグインのバージョンは、非表示の場合やバックポートされている場合、古いアセットによって報告される場合があります。
  • 大きなログ、サイトマップ、REST コレクションは不要なデータ収集につながる可能性があるため、範囲を限定したサンプルをリクエストしてください。
  • デフォルトの認証情報の試行、パスワードスプレー、登録、アップロード、書き込みには、明示的な許可と合意済みのアカウントロックアウト上限が必要です。

検証

  • WordPress であることを、ステータスコードだけでなくコンテンツから確認します。
  • コンポーネントに関する各所見には、2つ目のシグナルを含めるか、それが得られない理由を説明します。
  • CVE との関連付けには、正確なバージョンと前提条件を示す証拠を含めます。
  • REST の認可には、承認済みの ID とネガティブコントロールを使用します。
  • CORS の影響は、非公開データを使用してブラウザーで再現します。
  • XML-RPC の動作は、プロトコルに準拠した応答または制御されたコールバックで確認します。
  • 状態を変更するテストには合成レコードを使用し、クリーンアップの証拠を保持し、スコープ内にとどめます。

コメント

Markdown 対応