n8nの脆弱性（CVE-2024-25049）におけるRCEの脅威と実務的防御策

Tech

[Tone & Style]

  • Professional CSIRT perspective: calm, analytical, and action-oriented.

  • Concise and structured: Use bullet points and clear headings.

  • Technical accuracy: Focus on the root cause and specific mitigation vectors.

  • No FUD: Objective risk assessment based on CVSS and exploitability.

[Terminology]

  • Use standard cybersecurity terms (RCE, Lateral Movement, Blast Radius, Mitigation).

  • Language: Japanese (Technical).

本記事はGeminiの出力をプロンプト工学で整理した業務ドラフト（未検証）です。

n8nの脆弱性（CVE-2024-25049）におけるRCEの脅威と実務的防御策

【脅威の概要と背景】

n8nの特定のノードや認証情報の処理において、式（Expression）の評価を悪用しリモートから任意のコードを実行（RCE）される脆弱性。CVSS 9.4。2024年に報告され、ワークフロー編集権限を持つユーザーや、外部入力を適切に処理していない環境が標的となる。

【攻撃シナリオの可視化】

graph TD
    A["攻撃者: ワークフロー編集者/外部送信"] -->|不正なExpressionを注入| B("n8n Web UI/API")
    B -->|サーバーサイドで式を評価| C{"脆弱な処理エンジン"}
    C -->|サンドボックス脱出/制限回避| D["OSコマンド実行"]
    D -->|認証情報奪取| E["他システムへの横展開"]
    D -->|データ侵害| F["内部データの外部送信"]

【安全な実装と設定】

n8nは「利便性」と「自由度」を優先するツールであるため、デフォルト設定では攻撃面にさらされやすい性質があります。

1. 外部モジュールの制限（環境変数による保護）

誤用例（脆弱な設定）: 全モジュールのインポートを許可しており、require('child_process') 等でOS操作が可能。

# 制限がない、または広すぎる許可

export N8N_BLOCK_SVC_JS_MODULES=false

安全な代替案（推奨設定）: ビルトインモジュールの使用を制限し、外部呼び出しを明示的に禁止します。

# 特定の危険なモジュールをブロック

export N8N_BLOCK_SVC_JS_MODULES=child_process,fs,os,http,https

# サンドボックスのタイムアウトを短く設定し、DoSや過度な計算を抑制

export N8N_JS_SANDBOX_TIMEOUT=500

2. 実行環境の分離（最小権限の原則）

n8nプロセスを root で動かさず、専用ユーザーかつ書き込み権限を制限したコンテナで実行します。

# Dockerfileでの対応例

USER node

# 必要最小限の書き込み権限のみ付与

RUN chmod 444 /etc/passwd

【検出と緩和策】

  • ログ監視 (SIEM/EDR):

    • n8nのコンテナ/プロセスから不審な子プロセス（sh, bash, curl, nc）が生成されていないか監視。

    • /execution/ エンドポイントに対する異常に長い、または特殊記号（${...}）を多用したPOSTリクエストの検知。

  • ネットワーク分離:

    • n8nサーバーから社内LANへのアクセスを必要なセグメントのみに制限（マイクロセグメンテーション）。

    • 外向き通信（Egress）のホワイトリスト化。

  • 応急措置:

    • 最新版へのアップデートが困難な場合、信頼できないユーザーの「Workflow Edit」権限を剥奪し、共有機能を無効化する。

【実務上の落とし穴】

  • 可用性への影響: N8N_BLOCK_SVC_JS_MODULES による制限を強化しすぎると、既存の高度なカスタムコードノード（ファイル操作や複雑な計算を行うもの）が動作しなくなり、業務プロセスが停止する恐れがあります。

  • 誤検知のリスク: 開発者がデバッグ目的で複雑な式を書いた場合、セキュリティ製品が攻撃と誤認するケースがあります。検知ルールのチューニングには、正規のワークフローパターンの学習が必要です。

【まとめ】

組織として直ちに対応すべき3項目：

  1. 即時アップデート: 脆弱性が修正された最新バージョン（v1.25.0以降推奨、CVE詳細に準拠）へ更新する。

  2. 環境変数の見直し: N8N_BLOCK_SVC_JS_MODULES を設定し、OSレベルのコマンド実行を制限する。

  3. アクセス権限の最小化: ワークフローの作成・編集権限を「真に必要最小限」のユーザーに限定し、MFAを強制する。

参考文献:

ライセンス：本記事のテキスト/コードは特記なき限り CC BY 4.0 です。引用の際は出典URL（本ページ）を明記してください。
利用ポリシー もご参照ください。

コメント

タイトルとURLをコピーしました