⇒ 考察: ポート 8090 にアクセスすると、サーバーは JSON データを返します。これは、エンドポイントが単なる静的 Web ページを提供しているのではなく、リクエストを処理し、データを JSON にシリアライズしてクライアントに返すバックエンドがあることを示しています。docker ps の結果から、コンテナ内で実行されているコマンドは Java アプリケーションであることが示唆されるため、次の調査の方向性は、Java で一般的な JSON パーサーのフィンガープリンティングです。

Java では、Jackson、Gson、Fastjson などの一般的な JSON ライブラリは、異常な入力を受け取った際に異なる動作を示します。そのため、エラーベースのフィンガープリンティング技術を利用できます。返されるエラーから、ライブラリや内部処理メカニズムが直接明らかになることがあります。中でも Fastjson は、古いバージョンに AutoType デシリアライゼーションに関連する重大な脆弱性が複数存在するため、早期に検証する必要があるターゲットです。

ここでは、すぐにバックエンドが Fastjson を使用していると断言しません。Fastjson を最初の確認対象として選択したのは、@type キーを通じて明確なフィンガープリントが得られること、そしてもし古いバージョンの Fastjson であれば、標準的なパースエラーよりもはるかに強力な悪用が可能になり、RCE にまで至る可能性があるためです。

フィンガープリンティングとライブラリのプロービング

Fastjson にはフィンガープリンティングに非常に有用な特性があります。それは特別な @type キーを認識することです。バックエンドが Fastjson を使用しており、デシリアライズフローに送信されたリクエストボディが AutoType をサポートしている場合、パーサーは @type の値を Java クラス名として解釈しようと試みる可能性があります。

そこで、存在しないクラスを指す @type を含むペイロードを送信します。このステップの目的は即座に悪用することではなく、バックエンドが @type に反応するかどうかを観察することです。

もしバックエンドが標準的な JSON パーサーを使用しており、@type を気にしない場合、このフィールドは単に無視されるか、JSON 内の通常のキーとして扱われます。しかし、ここではバックエンドが型に関連する動作（型が一致しない）で反応しています。これは、リクエストがクラス/型マッピングの処理フローに入ったことを意味します。

"type not match" メッセージは、Fastjson が @type を処理する際に、指定されたクラスがエンドポイントが期待するデータ型と一致しないか、クラスが存在しない/デシリアライズが許可されていない場合によく遭遇する特徴的なシグネチャです。

⇒ 考察: バックエンドは実際に POST リクエストの JSON ボディを解析しており、@type フィールドは無視されず、パーサーは型メタデータ処理メカニズムを持ち、返されるエラーは Alibaba Fastjson の動作と一致します。したがって、バックエンドが Alibaba Fastjson を使用していると確信を持って結論付けることができます。

悪用条件の特定

フィンガープリンティングのステップの後、すぐにシステムが悪用可能であると結論付けることはできません。バックエンドが Fastjson を使用していることは、JSON リクエストが @type 処理フローに入ることを証明するだけです。

RCE エクスプロイトを実行するには、以下を確認する必要があります:

• 使用されている Fastjson が AutoType デシリアライゼーションの影響を受ける古いバージョンであるかどうか。
• 被害者の JVM が JNDI によるリモートクラスのロードを許可しているかどうか。
• 危険な動作をトリガーするために、クラスパス/JDK に適切なガジェットクラスが存在するかどうか。

⇒ 考察: type not match エラーは、バックエンドが @type に反応することを示していますが、現在のペイロードはエラーをトリガーするために偽のクラスを使用しているだけです。実際の悪用には、その偽のクラスを、JNDI ルックアップのようなアウトバウンド動作を生成できる Java/JDK に存在する実際のクラスに置き換える必要があります。

Fastjson と JVM のバージョン確認

バージョンを特定するために、コンテナ/アプリケーション内で直接確認します。

アプリケーションが /usr/src/fastjsondemo.jar というファイルにパッケージ化されていることを特定した後、このパッケージ構造を詳細に分析し、JSON 処理ライブラリを検索します。BOOT-INF/lib/ ディレクトリ構造を確認すると、fastjson-1.2.24.jar ファイルが見つかります（図 X）。

1.2.24 というバージョンは、AutoType 防御メカニズムがなく、デシリアライゼーション脆弱性の影響を受ける最初で最も有名なバージョンです。このことから、システムが CVE-2017-18349 に対して脆弱であることを確認できます。

fastjson-1.2.24.jar が見つかったことで、アプリケーションが AutoType デシリアライゼーションの欠陥の影響を受けるグループに属する、非常に古いバージョンの Fastjson を使用していることが確認されました。このバージョンでは、後のバージョンのように AutoType に対する制御メカニズムが強化されていないため、ライブラリの条件に関しては、JdbcRowSetImpl などのガジェットクラスを通じた悪用が可能な状態です。

ただし、実際の悪用可能性は、エンドポイントが Fastjson をどのように呼び出すかにも依存します。アプリケーションが JSON を固定クラスにパースする場合、ルートオブジェクトに @type ペイロードを設定すると "type not match" エラーになる可能性があります。そのため、バージョンを特定した後も、JVM、ガジェットクラス、および LDAP コールバックの動作を分析し、悪用チェーンが実際に JNDI ルックアップに到達することを確認する必要があります。

JNDI ルックアップに到達するための条件分析

1. JVM の障壁分析

Fastjson のバージョンに加えて、Java のバージョンも重要な決定要因です。コンテナ内の JVM を確認します:

これは重要な情報です。なぜなら、Fastjson の悪用チェーンは通常 JNDI インジェクションに依存しているからです。新しいバージョンの Java では、デフォルトで LDAP/RMI 経由での外部コードベースからのクラスロードがブロックされています。しかし、Java 8u102 はまだこれらのブロックメカニズムを持たない古いバージョンです。

したがって、攻撃者が JNDI ルックアップをトリガーできれば、被害者の JVM は外部 HTTP サーバーからクラスをダウンロードし、ランタイムにロードする機能を持っています。

JdbcRowSetImpl ガジェットの分析

古い Fastjson と JVM を特定した後、次のステップは JDK に存在し、デシリアライズ時に危険な動作を生成できるクラスを見つけることです。

com.sun.rowset.JdbcRowSetImpl は適切なガジェットです。このクラスは JDK に存在し、dataSourceName プロパティを持っています。dataSourceName に LDAP URL 形式の値が割り当てられると、オブジェクトはアウトバウンドの JNDI ルックアップをトリガーするために悪用される可能性があります。

⇒ 考察: サーバーに直接コードをアップロードする必要はありません。代わりに、JVM 内の既存のクラスを利用して、被害者に攻撃者が制御する LDAP サーバーへの接続を強制します。

エクスプロイトチェーンの検証

ライブラリと JVM に関する必要な条件を確立した後、ペイロードが実際に被害者にアウトバウンド接続を強制するかどうかを検証する必要があります。これは、以下の区別をするための重要なステップです:

• 脆弱なライブラリ/バージョンを含むシステム。
• JNDI ルックアップを実際にトリガーできる悪用チェーン。

LDAP サーバーまたはリスナーが被害者からの接続を受信した場合、ペイロードが JNDI ルックアップのステップに正常に到達したことを証明します。コールバックがなく、サーバーが type not match を返す場合、現在のペイロードがエンドポイントのデシリアライズフローと一致していないことを示します。この場合、ペイロードをエンドポイントが解析する正確なオブジェクト構造に調整するか、代替のバイパスやガジェットを利用する必要があります。

分析段階の結論

上記のステップから、システムの状態チェーンは次のように要約できます:

• ポート 8090 のサービスは JSON を処理するバックエンドです。
• @type によるエラーレスポンスは、バックエンドが型メタデータメカニズムを処理していることを示し、Fastjson の動作と一致します。
• コンテナ内の検査により、アプリケーションが fastjson-1.2.24.jar ライブラリをパッケージ化していることが確認されます。
• Fastjson 1.2.24 は CVE-2017-18349 の影響を受けるバージョングループに属します。
• 被害者の JVM は OpenJDK 1.8.0_102 であり、デフォルトで JNDI 経由のリモートコードベースロードをブロックしない古いバージョンです。
• com.sun.rowset.JdbcRowSetImpl ガジェットは JDK に存在し、dataSourceName プロパティを介して JNDI ルックアップをトリガーするために悪用される可能性があります。

⇒ 悪用の考え方:

ファイルアップロード機能やサーバーへの直接ファイル書き込みを見つける必要はありません。代わりに、Fastjson のデシリアライズフローを利用して、JVM に JdbcRowSetImpl オブジェクトをインスタンス化させます。このオブジェクトが LDAP URL 形式の dataSourceName を受け取ると、被害者は攻撃者が制御するサーバーに対して JNDI ルックアップを実行します。そこから、攻撃者は JVM をリダイレクトして外部 HTTP サーバーから悪意のあるクラスをダウンロードさせ、そのクラス内のコードを実行させることができます。

したがって、選択された悪用パスは次のとおりです:

II. 悪用

エクスプロイトメカニズム

Fastjson 1.2.24 では、com.sun.rowset.JdbcRowSetImpl クラスは JVM クラスパス（標準ライブラリ rt.jar に属する）に存在するガジェットクラスです。Fastjson がこのクラスを指す @type を含む JSON 文字列をデシリアライズすると:

1. Fastjson は JdbcRowSetImpl をインスタンス化します。
2. setDataSourceName() セッターが呼び出され → JNDI アドレスが設定されます。
3. setDataSourceName() は内部の InitialContext.lookup(dataSourceName) をトリガーします → JNDI インジェクション全体はここで発生し、setAutoCommit() が実行される前に行われます。
4. JNDI ルックアップは攻撃者の LDAP サーバーに問い合わせ → 参照オブジェクトを受信します。
5. JVM は HTTP コードベースから Exploit.class ファイルをダウンロードし、メモリにロード → static {} ブロックを実行します。

Java Exploit コードの作成 (Exploit.java)

Java 8 向けの下位互換性コンパイルと HTTP コードベースサーバーのセットアップ

被害者の JVM は Java 8u102 で動作しているため、コンパイル時にターゲットを Java 8 として指定する必要があります。指定しないと、被害者は UnsupportedClassVersionError をスローし、攻撃チェーンはサイレントに失敗します。その後、HTTP コードベースサーバーをセットアップします:

JNDI-Injection-Exploit を使用した JNDI Exploit サーバーのセットアップ

Kali 環境は Java 25 で動作しており、marshalsec をビルドするには新しすぎるため、代わりに JNDI-Injection-Exploit ツールを使用します。まず、リバースシェルペイロードを base64 形式で作成します:

上記のペイロードを使用して JNDI サーバーを起動します:

ツールは自動的に LDAP エンドポイントを生成します:

攻撃チェーンのリスニングとトリガー

リバースリスニングポートを開きます:

ルートオブジェクトに @type ペイロードを配置すると type not match エラーが返されることがわかります。これは、Spring Boot コントローラが JSON を固定型にマッピングしており、ルートレベルで JdbcRowSetImpl と一致しないためです。

ペイロードの調整: ガジェットクラスをネストされたフィールド ("data":{...}) 内にラップすることで、Fastjson がコントローラの型制約とは独立してネストされたオブジェクトを処理するようにします:

悪用結果

LDAP サーバー (marshalsec): 被害者の IP からの JNDI クエリリクエストが成功し、HTTP コードベースにリダイレクトされたことをログに記録。

HTTP サーバー (Python): 被害者の IP が Exploit.class ファイルをダウンロードするリクエストを、ステータスコード 200 OK でログに記録。JVM がバイトコードのロードに成功したことを証明。

Netcat リスナー: 対話型セッション（リバースシェル）の確立に成功:

完全な悪用チェーンが正常に検証されました: JSON ペイロードの送信 → JNDI ルックアップ → LDAP リファラル → リモートクラスのロード → static {} ブロック内のコード実行 → root 権限でのリバースシェルの確立、という一連の流れです。

III. リスク評価と対策

リスク評価

このシステムにおける Fastjson デシリアライゼーション RCE 脆弱性 (CVE-2017-18349) は、最高の重大度レベルと評価されます:

対策の推奨事項

この脆弱性を完全に解決するには、以下の優先順位で措置を実施する必要があります:

緊急優先事項（短期):

1. Fastjson のアップグレード: ライブラリを安全なバージョン (≥ 1.2.83) に更新します。バージョン 1.2.25 以降では、autoType 機能が デフォルトで無効 になり、厳格なブラックリストメカニズムが追加されました。これにより、CVE-2017-18349 の攻撃ベクトルは直接除去されます。または、より保守性の高い代替ライブラリ（Jackson や Gson など）への移行を検討してください。
2. JVM のアップグレード: Java ランタイムを少なくとも Java 8u191 に更新します。このバージョン以降、com.sun.jndi.ldap.object.trustURLCodebase プロパティはデフォルトで false に設定されます。これにより、LDAP/RMI 経由での JVM によるリモートクラスの自動ロードが完全にブロックされ、Fastjson にまだ脆弱性が存在しても JNDI インジェクションチェーンが機能しなくなります。
3. 実行権限の削減: Web アプリケーションを root ユーザーで実行しないでください。最小権限を持つ専用ユーザー（例: app_user）を作成します。攻撃者が RCE を達成しても、被害はそのユーザーの権限範囲に限定されます。

高優先事項（長期 & 多層防御):

1. autoType の無効化: 短期的に古いバージョンの Fastjson を保持する必要がある場合は、ソースコードで SafeMode を有効にして autoType を完全にオフにします:

または、許可するクラスのみをデシリアライズできるようにする、厳格なホワイトリストを確立します。

2. WAF の導入: Web アプリケーションファイアウォールを構成し、JSON ボディに Fastjson 悪用のシグネチャ（@type、JdbcRowSetImpl、dataSourceName、ldap://、rmi://）を含む HTTP リクエストを検出およびブロックします。
3. コンテナネットワークの制限: ファイアウォールルールを構成して、コンテナが外部への接続を能動的に開始することをブロック（アウトバウンドトラフィック）します。これにより、攻撃者へのリバースシェルの接続を防ぎ、外部 LDAP/RMI サーバーへの JNDI コールバックをブロックします。Docker 環境では、適切な -network および iptables ルールを構成します。