mcpField
C
cross-attack-chains

cross-attack-chains

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

cross-attack-chains について

cross-attack-chainsは、複数の発見が実証済みの攻撃経路を構成するか検証するセキュリティテスト用スキルです。各段階の証拠、安全な承認、確認済みの影響と推測の区別を重視します。

主な機能

  1. 01発見事項と証拠・対照の整理
  2. 02発見事項間の依存関係の記録
  3. 03攻撃チェーンの各遷移の検証
  4. 04実証済み証拠に基づく影響の再評価
  5. 05クリーンアップとテスト制限の記録

活用シーン

  1. 01複数の発見が攻撃チェーンになるか評価
  2. 02複合的な影響と単独の影響の区別
  3. 03未テストの遷移を推測として記録
  4. 04証拠に基づくセキュリティレポートの作成

インストール

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

$npx skills add https://github.com/uphiago/recon-skills --skill cross-attack-chains

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

同梱ファイルreferences/exploit-chains-template.md

詳細

クロス攻撃チェーン

攻撃チェーンとは、各ステップが次のステップの前提条件となる、検証済みのセキュリティ上の挙動の連鎖です。同じターゲットで複数の問題が見つかっても、それらの依存関係が実証されない限り、チェーンにはなりません。

使用するタイミング

  • 検証済みの問題が2つ以上あり、同じ信頼境界に影響します。
  • ある問題によって、別の問題に必要なID、トークン、ルート、ホスト、または機能が明らかになります。
  • 単独での影響と複合時の影響を区別する必要があります。
  • 次のチェーンステップを安全にテストできず、推定として明記する必要があります。

前提条件

  • 各構成要素となる問題について、取得済みの証拠とネガティブコントロールがあること。
  • 複合テストと、増加する可能性のある副作用について、現在有効な許可があること。
  • 承認済みのID、合成レコード、コールバック、およびクリーンアップ手順があること。
  • 機密データ、可用性、またはスコープの変更に関する明確な中止条件があること。

実行方法

ターゲットの出力ディレクトリ内にチェーン記録を作成します。

TARGET_ID="example-test"
OUTPUT_DIR="${OUTPUT_DIR:-./output}"
CHAIN_DIR="$OUTPUT_DIR/$TARGET_ID/chains"

mkdir -p "$CHAIN_DIR"
touch "$CHAIN_DIR/EXPLOIT_CHAINS.md"

証拠の状態は一貫して使用してください。

状態意味
観測済み取得した出力に存在する
確認済みコントロールを用いてセキュリティ上の影響を再現した
推定妥当な依存関係だが、テストされていない
未テストスコープ、安全性、または前提条件の不足により除外した

手順

1. 構成要素となる問題を整理する

各構成要素について、以下を記録します。

  • 期待される挙動と観測された挙動；
  • ターゲット、ID、タイムスタンプ；
  • 肯定的な証拠とネガティブコントロール；
  • 副作用とクリーンアップ；
  • 実証された影響；
  • 前提とテスト上の制限。

担当スキルによる検証を通過していないスキャナーのラベルや、バージョンだけを根拠とする手掛かりは除外します。

2. 依存関係を図示する
Finding A
  output: approved user identifier
  enables: object lookup in Finding B

Finding B
  output: unauthorized synthetic object read
  enables: none

AとBが同じ場所にあるだけなら、それぞれ個別に記録してください。

3. 遷移をテストする

遷移はチェーンの中核です。同じ承認済み条件のもとで、あるステップからの出力そのものが次のステップで受け入れられることを実証してください。

例：

候補となる経路実証すべき遷移
ソースマップから隠れたAPIへ抽出したベースURLがテスト対象のAPIに解決される
ユーザー列挙からIDORへ列挙した識別子が、別の承認済みIDのオブジェクトを指す
CORSから保護データの読み取りへ承認済みのブラウザーセッションが、制御されたオリジンに非公開のレスポンスを返す
SSRFから内部サービスへ制御されたコールバックまたはレスポンスが内部サービスを特定する
露出した認証情報からリポジトリへのアクセスへスコープを限定した認証情報が、承認済みのテストリソースで有効である

欠けている遷移を補うために、実ユーザーデータ、広範な認証情報テスト、または破壊的な操作を使用しないでください。

4. 複合的な影響を再評価する

以下を明記します。

  1. 各構成要素が単独で実証すること；
  2. 検証済みの遷移によって新たに可能になること；
  3. 再現された最終的な影響；
  4. 下流の影響のうち、推定にとどまるもの。

チェーンの深刻度は証拠の範囲を超えてはなりません。理論上の最終ステップは、それ以前のステップが成功しただけでは確認済みになりません。

5. クリーンアップと制限を記録する

合成ユーザー、オブジェクト、アップロード、コールバック、一時トークンを削除したことを記録します。最終ステップの前にテストを中止する場合は、その理由を説明し、最後に確認された状態を記録してください。

注意点

  • 同時に存在することは、依存関係を意味しません。
  • ユーザー名は認証情報ではありません。
  • 有効な認証情報があっても、すべてのサービスにアクセスできるとは限りません。
  • ファイルのアップロードは、コード実行を意味しません。
  • 内部ネットワークに到達できても、内部サービスを制御できるとは限りません。
  • 確信度の低いステップが複数あると、不確実性が高まるのであって、確信度は高まりません。
  • 複合テストには、個々の問題に対する許可とは別の許可が必要な場合があります。

検証

  • すべてのコンポーネントが、それぞれを担当するスキルの検証に合格しています。
  • すべての矢印について、直前の出力が次の入力を可能にする証拠があります。
  • ネガティブコントロールによって、その経路を公開済みまたは想定される動作と区別しています。
  • 状態を変更する手順では合成リソースを使用し、クリーンアップを含めています。
  • 推定された手順と未テストの手順は、明確にラベル付けされたままにしています。
  • 最終レポートでは、実証された影響と起こり得る結果を分けています。

コメント

Markdown 対応