Node.js RCE 緩和策: 最後の防衛線としてのDevOps

このプロジェクトは、Next.js アプリケーション（特に Server Actions 経由）における重大なリモートコード実行（RCE）脆弱性と、インフラストラクチャの堅牢化が、コードの脆弱性が残ったままであっても攻撃を効果的に無効化する方法を示しています。

標準的な「安全でない」デプロイと、「Distroless」イメージと「読み取り専用ファイルシステム」を使用した堅牢化された「安全な」デプロイを対比させています。

🛡️ コンセプト: 「多層防御」

ソフトウェアの脆弱性は避けられません。コードが失敗したとき、攻撃者の足場を広げるのを防ぐのはインフラストラクチャの役目です。

脆弱性

Next.js が使用する React Server Components (RSC) 実装には、重大な RCE（CVE-2025-55182、別名 React2Shell） が存在します。

• CVSS: 10.0（Critical）
• 根本原因: "Flight" プロトコルの安全でないデシリアライゼーションにより、攻撃者は Server Action の処理中に内部オブジェクトを（プロトタイプ汚染または類似のメカニズムを介して）操作できます。
• 影響: 認証なしで任意のコード実行（spawnSync など）が可能になります。

攻撃ベクトル

1. Living off the Land（LotL）: OS に既に存在するツール（curl、wget、ls、cat）を使用して秘密情報を盗んだり、マルウェアをダウンロードしたりします。
   • 仕組み: このエクスプロイトは Node.js の child_process.spawnSync() を使用します。これはシェル（/bin/sh）を必要とせず、バイナリを直接実行します。
2. Bring Your Own Land（BYOL）: 標準ツールが無い場合、攻撃者は独自のバイナリ（例: コンパイル済みの Go 実行ファイル）をアップロードし、実行可能（chmod +x）に設定して実行します。

🏗️ アーキテクチャ比較

📝 アプリケーションログ分析

以下のログは、アプリケーションの視点から見た攻撃試行の様子を示しています。この対比は、セキュリティ対策の有効性を明確に浮き彫りにします。

安全なアプリのログ (logs/server.safe.log)

ログには繰り返し発生する失敗 (ENOENT) が記録されています。

• なぜ? spawnSync が ls、id、curl の実行を試みます。Distroless イメージにはこれらのバイナリが存在しません。シェルが無いというだけでなく、ツール自体が無いのです。

[Instrumentation] Logging initialized. Writing to: /app/logs/server.safe.log
 ⨯ Error: NEXT_REDIRECT
    ... digest: '`{"step":"1. Write Initial Chunk to /tmp/hello_test","success":true}`'
 ⨯ Error: NEXT_REDIRECT
    ... digest: '`{"step":"2. Verify Binary was Written","verification":{...},"success":true}`'
 ⨯ Error: NEXT_REDIRECT
    ... digest: '`{"step":"4. Execute Binary","stdout":"","stderr":"","error_obj":{"message":"spawnSync /tmp/hello_test EACCES","code":"EACCES"},"success":true}`'

安全でないアプリのログ (logs/server.unsafe.log)

ログは、コマンド実行とファイルシステム操作の成功を裏付けています。

[Instrumentation] Logging initialized. Writing to: /app/logs/server.unsafe.log
 ⨯ Error: NEXT_REDIRECT
    ... digest: '`{"step":"1. Write Initial Chunk to /tmp/hello_test","success":true}`'
 ⨯ Error: NEXT_REDIRECT
    ... digest: '`{"step":"4. Execute Binary","stdout":"Hello from Go binary!\\n","stderr":"","error_obj":null,"success":true}`'
 ⨯ Error: NEXT_REDIRECT
    ... digest: '`{"command":"id","args":[],"stdout":"uid=0(root) gid=0(root) ...","stderr":"","status":0,"signal":null}`'
 ⨯ Error: NEXT_REDIRECT
    ... digest: '`{"command":"cat","args":["/app/.env"],"stdout":"","stderr":"cat: can\'t open \'/app/.env\': No such file or directory\n","status":1,"signal":null}`'

(注: 安全でないログでは、上記の cat /app/.env は失敗しています。理由はファイルがルート直下に .env という名前で存在するためです。ただし、完全なログの ls -la でディレクトリ構造が明らかになるでしょう。)

💥 POC 結果

1. 標準的な RCE (Living off the Land)

標準的なシェルコマンドの実行を試みます。

• 安全でない環境: ✅ 成功。攻撃者は id、ls、cat .env を実行し、機密データにアクセスできます。
• 安全な環境: ❌ ブロック。spawnSync /bin/sh ENOENT。コマンドを実行するためのシェルが存在しません。

2. 高度な攻撃 (Bring Your Own Land)

「ツール不足」を回避するため、カスタムバイナリをアップロードしようとします。

• 安全でない環境: ✅ 成功。
  1. 攻撃者はバイナリをチャンク分割します（ペイロードサイズ制限を回避するため）。
  2. /tmp/malware に書き込みます。
  3. chmod +x を実行します。
  4. バイナリを実行します。
• 安全な環境: ❌ ブロック。
  • 書き込み失敗: EROFS: read-only file system。
  • 攻撃者はどこにもファイルを配置できないため、BYOL 攻撃を事実上無効化します。

3. 「真のファイルレス」実行の分析

攻撃者はバイナリを変数に読み込み、メモリから直接実行できるでしょうか?

• コンセプト: バイナリのチャンクをグローバルな JavaScript 変数（例: global.payload = "..."）に連結し、それを実行します。
• 現実: 失敗。
  • Node.js の child_process 関数 (spawn、exec) はファイルパスを必要とします。バッファや文字列を直接実行することはできません。
  • Linux でこれを回避するには、memfd_create（RAM 内に無名ファイルを作成する syscall）が必要です。
  • 障壁: Node.js は memfd_create をネイティブに公開していません。これにアクセスするには、C++ アドオン（ffi-napi など）が node_modules に事前インストールされている必要があります。
  • Distroless の影響: イメージにはコンパイラ（gcc、make）が含まれないため、攻撃者はこのアドオンをその場でビルドできません。

🔐 実証されたベストプラクティス

1. Distroless イメージを使用する

「Distroless」イメージには、アプリケーションとその実行時依存関係のみが含まれます。パッケージマネージャー、シェル、標準 UNIX ツールは含まれません。

• なぜ? 攻撃者が RCE を獲得しても、簡単に周囲を探索（ls）したり、ファイルをダウンロード（curl）したり、権限を昇格させたりできないようにするためです。

2. 読み取り専用ファイルシステム

コンテナランタイムを設定して、ルートファイルシステムを読み取り専用でマウントします。

• なぜ? 攻撃者がファイルをダウンロード（BYOL）したり、アプリケーションコードを変更（永続化）したりするのを防ぎます。
• 方法? docker-compose.yml 内:
  root@kitploit:~

  read_only: true
  tmpfs:
    - /tmp:noexec # CRITICAL: explicitly block execution!
  

  観察結果: この設定では、POC 上、攻撃者は /tmp へのバイナリ書き込みはできる（書き込みは成功）ものの、noexec フラグが原因で実行が EACCES（許可拒否）で失敗します。これにより、機能性（書き込み可能な tmp）とセキュリティのバランスが取れます。

3. ネイティブ環境変数（「エクスポート」領域）

コンテナイメージに .env ファイルを同梱しないでください。攻撃者がファイルを読める場合（例: cat .env）、シークレットが危険にさらされます。

• 安全なアプローチ: 実行時にプロセス環境へ変数を直接注入します（例: Kubernetes Secrets、AWS Parameter Store、Docker の environment キー）。
• なぜ? 単一のファイルを読む場合と比較して、攻撃者が全シークレットを一度にダンプすることがはるかに困難になります。

🚀 実行方法

1. 環境を起動: 安全なアプリと安全でないアプリの両方が単一の docker-compose.yml ファイルで定義されています。

   root@kitploit:~

   docker compose up --build -d
   

2. エクスプロイトを実行: 特定のポートに対してエクスプロイトを実行すると、その違いを確認できます。

   • 安全でないアプリをターゲット（ポート 3001）:

     root@kitploit:~

     # 1. 標準 RCE (LotL) - 成功
     python exploit/poc.py http://localhost:3001
     
     # 2. 高度な攻撃 (BYOL) - 成功
     python exploit/poc_advanced.py http://localhost:3001
     

   • 安全なアプリをターゲット（ポート 3000）:

     root@kitploit:~

     # 1. 標準 RCE (LotL) - 失敗 (ENOENT)
     python exploit/poc.py http://localhost:3000
     
     # 2. 高度な攻撃 (BYOL) - 失敗 (EACCES/EROFS)
     python exploit/poc_advanced.py http://localhost:3000
     

3. クリーンアップ:

   root@kitploit:~

   docker compose down