wordpress-full-compromise

WordPress の侵害経路分析

このスキルを使用して、検証済みの WordPress プリミティブが実際に管理者権限へつながるのか、あるいは無害なコード実行の証明にとどまるのかを判断します。これはチェーンの可否を判定するものであり、前提条件が満たされなかった後もエスカレーションを無理に試みるためのチェックリストではありません。

使用する場面

• プラグインの脆弱性について、正確なバージョンとルートの証拠がある場合。
• 承認済みの ID が、想定外の WordPress 権限を持っている可能性がある場合。
• アップロードまたは設定への書き込みによって、実行可能な処理に到達する可能性がある場合。
• CORS、XML-RPC、ステージング、またはソースの露出によって、不足している前提条件を満たせる可能性がある場合。

前提条件

• 登録、認証、アップロード、書き込み、および実行テストについて明示的な許可があること。
• 承認済みの合成アカウントと、破棄可能なコンテンツがあること。
• WordPress、プラグイン、テーマ、およびホスティングの挙動が正確に把握されていること。
• 実行テスト用の無害なマーカーがあること。
• クリーンアップと停止条件が定められていること。

実行方法

前提条件の表を作成します。

Step                         State       Required evidence
Component vulnerability      observed    exact version and affected operation
Authorized identity          confirmed   approved account and current role
Write or upload capability   unverified  synthetic artifact accepted
Executable handling          unverified  benign marker executed
Administrative control       not tested  approved admin-only action
Cleanup                      planned     artifact and account removal

未検証の前提条件がある場合は、それ以上進めないでください。

手順

1. コンポーネントを確認する

hunt-wordpress と wordpress-plugin-hunt を使用して、次の項目を確認します。

• 複数のシグナルに基づくコンポーネントの識別情報。
• 正確なバージョンまたはコミット。
• 脆弱なルートまたはハンドラー。
• 認証とロールの前提条件。
• 影響を受ける設定とファイルタイプ。

公開されている readme や古いアセットだけでは不十分です。

2. ID と権限を確認する

承認済みのテスト ID のみを使用します。現在のロールと、操作で確認した正確な権限を記録します。購読者、顧客、投稿者、編集者、管理者の各ロールは互換ではありません。

認証情報の総当たり、パスワードスプレー、または無関係な漏えい認証情報によって、不足している認可を補おうとしてはいけません。

3. 合成データで状態変更を検証する

一意の名前を付けた合成投稿、オブジェクト、または不活性ファイルを使用します。次の項目を記録します。

• リクエストと ID。
• レスポンスと生成されたオブジェクト ID。
• 場所と内容。
• 想定される認可ポリシー。
• クリーンアップの結果。

オブジェクトを安全に削除できない場合は、作成前に停止してください。

4. アップロードと実行を分けて検証する

アップロードが受け入れられたことから証明できるのは、アップロード境界だけです。実行可能な処理は別途確認します。

• サーバーが保存された拡張子をインタープリターに関連付けている。
• MIME と拡張子の検証で、テスト対象のタイプが許可されている。
• 保存先のパスに Web からアクセスできる。
• プラグインによる処理でファイル名の変更やサニタイズが行われない。
• 承認済みの環境で無害なマーカーを実行できる。

汎用的な実証としてコマンドシェルを配置してはいけません。

5. 管理者への影響を評価する

管理者権限の実証には、合成プライベート設定の読み取りや、破棄可能な設定値を変更して元に戻すなど、承認済みの管理者専用の作用が必要です。ユーザー列挙、REST メタデータ、またはログインページが利用可能であることだけでは、アカウント乗っ取りを立証できません。

6. 経路を組み立てる

cross-attack-chains を使用して、確認済みの遷移のみを接続します。CORS と XML-RPC が実際の前提条件である場合は wordpress-cors-xmlrpc-rce-chain を使用します。同じインストール環境に関する追加の検出事項にすぎない場合は使用しないでください。

注意点

• オープン登録では通常、低権限のロールが作成されます。
• XML-RPC メソッドが存在することは、そのメソッドの呼び出しが認可されていることを意味しません。
• PHP のプロセス関数が有効でも、アップロード手段が成立するわけではありません。
• プラグインのバージョン情報は古い場合や、脆弱性修正がバックポートされている場合があります。
• ステージングサイトでは、別のデータベースが使われていたり、本番環境への信頼経路が存在しなかったりすることがあります。
• 前提条件が満たされないことは、提案されたチェーンがそこで停止するという証拠です。

検証

• コンポーネントの識別情報、バージョン、ルート、前提条件を確認済みである。
• 承認済みの ID が、必要な正確な権限を持っている。
• 状態変更には合成リソースを使用し、変更を元に戻している。
• アップロードと実行を別々の手順として実証している。
• 管理者への影響を、承認済みの破棄可能な操作で確認している。
• 未確認の手順はすべて、推定または未テストとして扱っている。