dungsocool/cve-2017-11610CVE-2017-11610（Supervisord XML-RPC RCE）のステップバイステップのエクスプロイト解説（攻撃対象領域の分析、名前空間トラバーサルの発見、Dockerラボ環境でのポストエクスプロイト技術を含む）
環境で実行されているものから始めます。すべてのアクティブなコンテナをリストします。``` docker ps-a
**被害者は単一のポート `9001` を公開している**。
ポート9001は標準的なWebアプリケーションではありません。**ポートデータベース**を調べると、このポートは**Supervisord**（IANAによるとETL Service Manager）、Torプロキシ、またはその他の内部サービスに関連付けられている可能性があります。しかし、ポート番号だけでは結論を導き出すことはできません。
⇒ curlを直接実行してレスポンスを読み取り、さらにWeb GUIにアクセスして詳細情報を収集します。```
curl -i http://192.168.3.137:9001/
応答分析:
Server: Medusa/1.12 とタイトル Supervisor Status が表示されていた→ これは Tor や他のサービスではなく、Supervisord であることが確認された。
REFRESH、RESTART ALL、STOP ALLSupervisord は Linux 上のプロセスマネージャです。ポート9001 がパスワードなしでネットワークに公開されている場合、これは危険な設定です。攻撃者は サービスを閲覧したり、プロセスの再起動・停止を行ったり、特定の設定下では管理対象プログラムを変更・制御する権限があれば コマンド実行を悪用する 可能性があります。
分析結論: ターゲットは Supervisord 管理インターフェースをポート 9001 でネットワークに公開していることが確認できました。これは標準的な Web サービスではなく、プロセスを監視・制御するための管理インターフェース です。このインターフェースに 認証なしでアクセスできる ことは、攻撃者が管理サービスの状態を表示したり操作できるリスクを生み出します。
ただし、表示される UI と実際の制御メカニズムは区別する必要があります。REFRESH、RESTART ALL、STOP ALL といったボタンはフロントエンドで独立してリクエストを処理するのではなく、Supervisord の インターフェース/バックエンドを呼び出して ステータスを取得したりプロセス制御コマンドを送信する必要があります。そのため、Web UI が公開されていることを確認した後、次の分析ステップは Web UI の背後に制御インターフェースが存在するかどうか、そして認証が必要かどうかを判断することです。
⇒ 考え方: Web UI の背後にある制御インターフェースが存在するか、また認証が必要かどうかを確認する必要がある。
Supervisor のドキュメント によると、[inet_http_server] は TCP ソケットで待ち受ける HTTP サーバです。このインターフェースはデフォルトでは有効ではなく、信頼できる環境でのみ使用すべきであり、暗号化をサポートせず、username/password が設定されていない限りデフォルトの認証はありません。
ドキュメント はまた、[inet_http_server] のポートが HTTP/XML-RPC リクエストを受信 するために使用されることを示しており、supervisorctl はこのポートを介して XML-RPC を使用して supervisord と通信します。これはラボでの観察結果と一致します。コンテナは 0.0.0.0:9001->9001/tcp を公開しており、Web UI は認証なしでアクセス可能で、表示されるバージョンは Supervisor 3.3.2 です。
したがって、ポート 9001 の Web UI を確認した後、次のステップは XML-RPC エンドポイント /RPC2 を調査することです。Supervisord の公式メカニズムに基づき、以下の目標を検証する必要があります:
/RPC2 が存在するかどうか。supervisor.getState や system.listMethods のような非破壊的なメソッドを呼び出せるかどうか。エンドポイントが生きているかどうかを確認する:```
curl -i -s -X POST -H "Content-Type: text/xml"
-d 'supervisor.getState'
http://192.168.3.137:9001/RPC2
結果は `HTTP/1.1 200 OK` を返し、`401 Unauthorized` や `403 Forbidden` ではないため、リクエストが認証情報なしでサーバーに受け入れられたことを示しています。レスポンスは XML-RPC の `<methodResponse>` 形式で、`statename=RUNNING` と `statecode=1` を含んでおり、`/RPC2` エンドポイントがアクティブで `supervisor.getState` メソッドが正常に実行されたことを証明しています。
**⇒ 考察:** 攻撃対象領域は Web UI に限定されなくなり、デーモン/プロセス制御コマンドが処理される XML-RPC API に拡大しています。ここから、次の分析の方向性は、**Supervisor が XML-RPC で `methodName`** をどのように処理するかを確認し、現在のターゲットがこのメソッドのディスパッチ/ルックアップ機構にある **CVE-2017-11610** の動作を示しているかどうかを判断することです。これが **CVE-2017-11610** であると結論付けるために検証が必要です。
### **XML-RPC におけるメソッド名処理の分析**
前の手順で、`/RPC2` エンドポイントを介して `supervisor.getState` メソッドを正常に呼び出しました。これにより次の疑問が生じます: 文字列ベースの `methodName` を受信したとき、Supervisord はその文字列を内部の Python 関数にどのようにマッピングするのでしょうか？
XML-RPC では、メソッドは通常名前空間を利用します。例えば:
- `supervisor.getState`
- `supervisor.stopProcess`
- `supervisor.getAllProcessInfo`
論理的には、サーバーは `methodName` 文字列を受信し、ドット `.` で分割し、登録されたハンドラ内で対応するオブジェクト/関数を検索します。
擬似コードは以下のように理解できます。```python
# Pseudo-code simulating the dispatch method concept in XML-RPC
def dispatch(method_name, params):
parts = method_name.split(".") # ["supervisor", "getState"]
obj = registered_handlers[parts[0]] # get namespace "supervisor"
for attr in parts[1:]:
obj = getattr(obj, attr) # lookup the next attribute
return obj(*params) # call the final function
For standard methods like supervisor.getState, this mechanism functions normally: the server retrieves the supervisor handler, then calls the getState function. However, the core issue of CVE-2017-11610 is that this lookup mechanism does not sufficiently restrict the attributes allowed to be accessed. If an attacker controls the methodName, they can not only call public methods like getState, but also traverse deeper into the internal objects/modules reachable from the supervisor handler.
In other words, the dot . in methodName is not just used to invoke valid methods, but can be abused to traverse object attributes.
This establishes our exploitation path:
supervisor → supervisord → options → warnings → linecache → os → system
The concept is to start from the supervisor handler, follow attributes to the daemon's internal objects, and then leverage pre-imported Python modules to reach os.system. If os.system can be called, the attacker can execute system commands with the privileges of the supervisord process.
Thus, the attack chain follows this logic:
/RPC2 accepts unauthenticated method calls → inspect how XML-RPC dispatches methodName → discover methodName can traverse object attributes → leads to calling os.system.
First, I need to check whether the server actually allows traversing internal attributes. I will attempt to call a method name that is longer than usual. If the server returns a "method not found" error, a filter is active; if it returns a different error (or succeeds), the traversal is working.
Thinking: I already know supervisor.getState works. If I try supervisor.supervisord—which goes one layer deeper—and the server does not return an unknown method error, it means it is indeed using recursive getattr without a whitelist.
We know XML-RPC is a remote procedure call protocol over HTTP, with data encoded in XML. Each request consists of only 3 fixed components:```
FUNCTION_NAME VALUE ``` シンプルな構造 — `` と `` を置き換えるだけです。関数がパラメータを必要としない場合は、`` を空のままにします。関数が文字列を必要とする場合は、`...` で囲みます。これは秘密の知識ではありません — XML-RPC RFCを読めば詳細がわかります。⇒ アプリケーション: 通常より長い methodName を呼び出して、名前空間のトラバーサルを確認してみてください:```
curl -s -X POST -H "Content-Type: text/xml"
-d 'supervisor.supervisord.options'
http://192.168.3.137:9001/RPC2
結果は、標準の `unknown method` エラーの代わりに `HTTP 500 Internal Server Error` を返します。これは、サーバーが有効な名前空間レベルで `methodName` をブロックせず、代わりにディスパッチ中に `supervisor.supervisord.options` チェーンの処理を続行したことを示しています。言い換えると、リクエストは属性ルックアップメカニズムの深くまでトラバースし、解決されたオブジェクトがメソッドとして呼び出し可能ではなかった後にエラーが発生しました。これは、`methodName` を介した名前空間トラバーサルがアクティブであることを明確に示しています。
### **コマンド実行関数へのパスを見つける**
トラバーサルは機能しています。次のステップは、**システムコマンドを実行できる呼び出し可能な関数で終わる属性チェーンを見つけることです。** Pythonでは、確認する最も簡単なターゲットは `os.system()` です。ただし、**ターゲットにシェルがなく**、**コンテナ内のソース/ランタイムオブジェクトを直接読み取ることはできません。** そのため、**Pythonのインポートメカニズムから推論し**、**まずローカルで依存関係を確認する** 必要があります。
調査するチェーンは次のとおりです。