CVE-2026-20230 Cisco Unified Communications Manager SSRF 任意文件書き込みからRCEへのPoC導出プロセスと考察

適用範囲：ローカルターゲット、許可された再現環境、脆弱性検証、防御ルール分析のみ。未承認のターゲットに対して使用しないこと。本記事は主にCVE-2026-20230の攻撃チェーン、検証可能な現象、判断ロジック、防御の考え方を分析するものであり、直接コピーして実行可能な攻撃パケット、WebShellの内容、コマンド実行ペイロードは提供しない。

1. 脆弱性の背景

CVE-2026-20230は、Cisco Unified Communications Manager（Unified CM / CUCM）およびCisco Unified Communications Manager Session Management Edition（Unified CM SME）におけるサーバーサイドリクエストフォージェリ（SSRF）脆弱性です。この脆弱性は、特定のHTTPリクエスト処理フローにおける入力検証の不備に起因し、攻撃者は認証なしでリクエストを構築し、影響を受けるデバイスに攻撃者に代わって内部インターフェースやローカルリソースにアクセスさせることができます。

この脆弱性の影響は通常のSSRF検出にとどまりません。公開された技術分析によれば、特定のバージョンとサービスが有効な条件下では、SSRFを任意ファイル書き込み能力に連鎖させることが可能であり、攻撃者は制御可能なコンテンツを基盤OSのパスに書き込み、Webコンテナがアクセス可能なディレクトリやサーバーサイドコンポーネントのロードメカニズムを利用して、ファイル書き込みをコード実行に変換できます。

Ciscoはこの脆弱性にCVSS v3.1スコア8.6、ベクトルを次のように与えています：

CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:N/I:H/A:N

CVSSスコアはHighを示していますが、Ciscoはこの脆弱性のSecurity Impact RatingをCriticalとしています。その理由は、悪用に成功すると基盤OSファイルへの書き込みが可能になり、さらにroot権限に昇格する可能性があるためです。

特に注意すべき点は、この脆弱性の重要な前提条件として、WebDialerサービスが有効である必要があることです。WebDialerはデフォルトで無効であるため、CUCMアセットを見ただけで脆弱性が悪用可能と判断してはいけません。真のリスク判断には、製品バージョン、パッチ状態、WebDialerサービスの状態、および関連インターフェースへのアクセス可否を同時に確認する必要があります。

2. なぜ一つのインターフェースが200を返すかどうかだけを見てはいけないのか？

この脆弱性は、単に「特定の固定URLにアクセスして200が返れば存在する」という一般的なWeb脆弱性ではありません。その攻撃チェーンは少なくとも3つの階層を含みます：

1. 外部からアクセス可能なWebDialerまたはcmplatform関連インターフェース。
2. SSRFによって影響を受ける内部アクセスロジック。
3. 内部リクエストによってさらにトリガーされるファイル書き込みまたはサービスデプロイ動作。

したがって、単独でインターフェースにアクセスしてHTTP 200、302、401、404、500を得ても、脆弱性の存在または非存在を直接証明することはできません。

例えば、WebDialer WSDLインターフェースにアクセスできることは、ターゲットがWebDialer関連機能を露出していることを示すだけであり、その後のSSRFが必ずフィルタを突破できることを証明するものではありません。installClusterStatusExecuteインターフェースにアクセスできることも、関連するエントリポイントが存在することを示すだけであり、単独で任意ファイル書き込みが成立することを証明するものではありません。逆に、あるステップで異常が返る場合も、ターゲットのバージョン、パッチ、ホスト名解決、パス権限、プロキシ機器、サービス状態などが原因である可能性があり、必ずしも脆弱性チェーン全体が存在しないことを意味するわけではありません。

より確実な判断は、多段階の証拠を組み合わせるべきです：

1. ターゲットがCisco Unified CM / Unified CM SMEであることを確認する。
2. WebDialerサービスが有効状態であることを確認する。
3. ターゲットの実際のホスト名または内部サービス識別子を取得できることを確認する。
4. SSRFエントリポイントに到達可能であり、サーバーサイドから内部リクエストが発生している兆候があることを確認する。
5. 許可されたターゲット環境で、制御されたファイル書き込みの証拠を生成できるか確認する。
6. サーバーサイドログ、ファイルシステムの変更、Webコンテナログ、アラートデータを組み合わせて、実際にトリガーされたかを判断する。

「WebDialer有効 + 影響を受けるバージョン + SSRF動作成立 + 制御されたファイル書き込み成立」が同時に発生した場合にのみ、信頼性の高い悪用可能と判断すべきです。

3. PoC構築の考え方

現在公開されている攻撃チェーンの核心は、単なるSSRFではなく、SSRFとAxis/Java Webサービスメカニズム、ログ書き込み、またはデプロイメント記述子ファイル処理ロジックとの組み合わせ利用です。

全体の考え方は次のように要約できます：

WebDialer情報取得
    ↓
ターゲットの実際のホスト名を取得
    ↓
cmplatform関連インターフェースを介してSSRFをトリガー
    ↓
内部WebDialer / Axis管理パスにアクセス
    ↓
制御可能なサービス記述内容を書き込みまたはデプロイ
    ↓
新しい呼び出し可能なサービスまたはファイル書き込み能力を形成
    ↓
ファイル書き込み能力をWebアクセス可能なスクリプトに変換
    ↓
特定の環境でさらにコマンド実行に到達

リンク設計から見ると、ホスト名が重要なポイントです。一部のフィルタリングロジックは127.0.0.1、localhostなどの一般的なローカルアドレスをブロックしますが、ターゲットの実際のホスト名は後続のリクエストフローに入ることが許可される可能性があります。そのため、PoCはまずWebDialerのWSDL情報から実際のホスト名を抽出し、それをSSRFチェーンにおける内部アクセスのプレフィックスとして使用します。

2つ目の重要なポイントは、Axisサービス関連ロジックです。PoCはWebディレクトリに直接ファイルをアップロードするのではなく、内部サービス処理チェーンを介して、サーバーサイドコンポーネントに攻撃者が制御可能なコンテンツを特定のパスに書き込ませます。このプロセスは本質的に「サーバーサイド内部リクエスト + コンポーネント設定/ログ書き込み動作 + パストラバーサル/パス制御」の組み合わせです。

3つ目の重要なポイントは、2段階書き込みです。第1段階は通常、より安定したファイル書き込みエントリを確立するために使用され、第2段階でコマンド実行スクリプトをWebアクセス可能なディレクトリに書き込みます。この理由は、SSRFを介して直接1ステップで完全なコマンド実行ロジックを書き込もうとすると、エンコーディング、長さ、XML構造、パス権限、サーバーサイド解析動作などの影響を受ける可能性がある一方、2段階方式では複雑なペイロードを分割しやすいためです。

本記事では、完全な攻撃パケットやWebShellの内容は提供しません。防御と検証に必要なのは、以下の核心的な特徴を理解することだけです：

外部リクエストエントリ：cmplatformインストール状態関連インターフェース
情報取得エントリ：WebDialer WSDL / services関連インターフェース
内部転送先：WebDialer / Axis / AdminService関連パス
重要な動作：SSRF、サーバーサイド内部リクエスト、制御可能なファイル書き込み、Webアクセス可能なファイルの配置
最終リスク：任意ファイル書き込み、WebShell配置、コマンド実行、root権限昇格パス

4. ホスト名取得ロジック

PoCはまずターゲットの実際のホスト名を取得する必要があります。IPアドレスや外部ドメイン名だけを使用するのではありません。

その理由は、SSRFフィルタリングロジックは最終接続先だけを判断するとは限らず、ホスト名フィールド、URL文字列、ローカルアドレスキーワードなどを検証する可能性があるからです。一般的な127.0.0.1、localhostなどのローカルアドレスはブロックされる可能性がありますが、デバイスの実際のホスト名は一部のシナリオで正当なノード名として扱われることがあります。

判断を補助するために使用できるインターフェースは、通常WebDialer WSDL情報に関連しています。そのようなWSDLにアクセスすると、レスポンスにはサービスアドレス、locationフィールド、またはその他の解析可能なホスト識別子が含まれている可能性があります。PoCはレスポンステキストからURL内のホスト名を抽出し、それを次のフェーズのSSRFの内部アクセスターゲットとして使用します。

このフェーズの判断基準は以下の通りです：

1. WSDLインターフェースにアクセス可能か。
2. レスポンスの内容がWebDialer / Axisサービスの特徴に合致するか。
3. レスポンスから実際のホスト名を解析できるか。
4. 解析されたホスト名が外部アクセスIPやドメイン名と異なるか。
5. そのホスト名が後続のSSRFエントリポイントで受け入れられるか。

ホスト名の解析に失敗した場合、PoCはターゲットIPにフォールバックすることがありますが、成功率は大幅に低下します。実際の環境でホスト名解析が失敗する一般的な理由には、WebDialerが有効でない、インターフェースがアクセス制御で制限されている、レスポンスがリバースプロキシによって書き換えられている、証明書やサービス設定が不完全であるなどがあります。

5. SSRFトリガーフェーズ

SSRFのトリガーポイントは、cmplatform関連のインストール状態照会ロジックにあります。この機能は元々クラスタノードのインストール状態を照会するためのもので、サーバーサイドはユーザーが送信したノード識別子やホスト名に基づいて内部リクエストを組み立てます。

脆弱性の核心は、攻撃者が制御可能なホスト名パラメータが正当なノード名や信頼されたホストに厳密に制限されておらず、そのパラメータをより複雑な内部アクセスパスに構成できることです。その後、サーバーサイドは攻撃者に代わって内部インターフェースにリクエストを送信します。

このフェーズの鍵は「外部URLにアクセスできること」ではなく、「CUCMデバイス自体に、内部で到達可能なWebDialer / Axis管理インターフェースにアクセスさせること」です。したがって、SSRFの価値は2つの側面から来ます：

1. 外部ネットワークアクセス制限をバイパスし、ローカルホストまたは内部コンポーネントからのみアクセス可能なサービスパスに到達する。
2. 内部サービスの信頼境界を利用して、通常のHTTPパラメータを内部コンポーネント操作に変換する。

許可された検証では、HTTPステータスコードだけでSSRFの成功を判断してはいけません。より信頼性の高い証拠には以下が含まれます：

1. サーバーサイドログに内部パスへのアクセス記録が現れる。
2. リクエスト応答の内容に内部インターフェースの特徴が現れる。
3. 後続のWebDialer servicesページに新規または異常なサービス痕跡が現れる。
4. ファイルシステムにサーバーサイドプロセスによって作成された異常なファイルが出現する。
5. セキュリティデバイスが、ホスト名パラメータに異常なパス、エンコードされた内容、内部サービスパスが含まれていることを記録する。

6. Axisサービス書き込みと任意ファイル書き込みの考え方

公開されたチェーンでは、SSRFはさらにAxis関連サービスインターフェースにアクセスし、サービスデプロイメント記述内容の書き込みを試みます。攻撃者は特別なXML/WSDD構造を構築し、サーバーサイドコンポーネントが処理中に制御可能なコンテンツを指定パスに書き込むようにします。

このフェーズの本質は従来のファイルアップロードではなく、サーバーサイドコンポーネントの処理ロジックを悪用することです：

ユーザー制御可能パラメータ
    ↓
SSRF内部リクエスト
    ↓
Axis / Webサービス処理
    ↓
制御可能なデプロイメント記述またはログ書き込み
    ↓
指定パスへのファイル生成

セキュリティ分析の観点から、ここにはいくつかの重要なポイントがあります：

1. 書き込み先パスは通常、Webコンテナがアクセス可能なディレクトリまでトラバーサルする必要がある。
2. 書き込む内容はサーバーサイドコンポーネントの処理形式を満たす必要がある。そうでなければ無効なファイルしか生成されない可能性がある。
3. 書き込まれたファイルの所有者と権限は、Tomcat / CUCMサービスプロセスに依存する。
4. 書き込み位置がWebアクセス可能であれば、ファイル書き込みはさらにスクリプト実行に変換される可能性がある。
5. 書き込み位置が実行可能でなくても、設定汚染、永続化、後続の権限昇格条件を引き起こす可能性がある。

したがって、CVE-2026-20230の高リスク点はSSRFだけではなく、SSRFが信頼境界を越え、内部管理/サービスデプロイチェーンに入り、最終的に制御可能なファイル書き込みをトリガーできることです。

7. 2段階WebShell書き込みロジック

PoC設計では通常、1ステップでコマンド実行を完了するのではなく、2段階書き込みを採用します。

第1段階は、単純なファイル書き込み能力を作成するために使用されます。この段階の目標は、攻撃者がWebアクセス可能なパスを介してサーバーの指定位置に内容を書き込めるようにすることです。

第2段階では、第1段階で書き込んだ能力を利用して、コマンド実行スクリプトをWebアクセス可能なディレクトリに書き込みます。その後、攻撃者はHTTPパラメータを介してシステムコマンド実行をトリガーできます。

2段階設計の利点は次のとおりです：

1. 単一のSSRFリクエストにおけるペイロードの複雑さを低減する。
2. XML、URLエンコーディング、特殊文字エスケープによるペイロード破損を回避する。
3. 「サービスのデプロイ」と「最終実行ファイルの書き込み」を分離し、デバッグを容易にする。
4. 異なるターゲットパスで着弾点を調整しやすくする。
5. 後続のコマンド実行フェーズをSSRFフェーズから切り離す。

しかし、防御の観点から見ると、2段階書き込みはより明確な検出面をもたらします：

1. 最初の異常リクエストは通常、新しいサービスの作成または中間JSPの書き込みを試みる。
2. 2番目の異常リクエストは通常、中間JSPにアクセスし、ファイル名やファイル内容などのパラメータを運ぶ。
3. 第3段階では最終コマンド実行JSPにアクセスし、認証パスワードやコマンドパラメータを運ぶ。
4. Webアクセスログには、短時間に連続してWebDialer、services、axis2-web、platform-servicesなどのパスにアクセスする動作が現れる。
5. ファイルシステムに異常なJSP、異常なサービス名、異常なログファイル、または新規のWebリソースが出現する可能性がある。

8. 現在のPoCの完全な実行フロー

現在のPoCのフローは次のように要約できます：

1. ターゲットアドレスを解析する。
2. WebDialer WSDLにアクセスし、実際のホスト名の抽出を試みる。
3. SSRFリクエストを構築し、内部WebDialer / Axis管理パスをターゲットとする。
4. 内部リクエストを介してAxisサービス関連コンテンツを書き込む。
5. servicesページにアクセスし、異常なサービスがデプロイされたかを確認する。
6. 新しいサービスを呼び出し、第1段階のファイル書き込みスクリプトを書き込む。
7. 第1段階のスクリプトにアクセスし、第2段階のコマンド実行スクリプトを書き込む。
8. 第2段階のスクリプトにアクセスし、テストコマンドを実行する。
9. HTTPレスポンス、ファイル配置結果、コマンド出力に基づいて悪用の成功を判断する。

悪用成功率の観点から、最も重要な失敗点は通常次の点に集中します：

1. WebDialerが有効でない。
2. ホスト名の解析に失敗するか、フィルタリングされる。
3. SSRFリクエストが実際に内部サービスに到達していない。
4. Axisサービスのデプロイに失敗する。
5. パストラバーサルの着弾点がターゲットバージョンに適合しない。
6. Webディレクトリが書き込み不可であるか、スクリプトが実行されない。
7. ターゲットがすでにパッチ適用済みか、Ciscoの一時修正パッケージを使用している。
8. プロキシ、WAF、EDR、ファイル整合性監視が中間段階をブロックしている。

したがって、このPoCは特定の影響を受けるバージョンとデフォルトパスが一致する場合に悪用可能性が高いですが、すべてのCUCMアセットに対して安定して有効というわけではありません。

9. 成功判断ロジック

CVE-2026-20230の成功判断は、スクリプトが完了したかだけを見るべきではありません。より合理的な判断は4段階に分けるべきです。

第1段階：ターゲットが露出の疑い

条件：

WebDialer WSDLにアクセス可能
または servicesページにアクセス可能
または cmplatform関連インターフェースにアクセス可能

これはターゲットに関連する攻撃面が存在することを示すだけであり、脆弱性が悪用可能であることを証明するものではありません。

第2段階：脆弱性が存在する疑い