☠️
IngressNightmare: Kubernetes環境を脅かす重大な脆弱性の徹底解析

2025/03/25に公開
nginx
 要点まとめ
深刻度: CVSS 9.8（最高レベル）の認証不要リモートコード実行脆弱性

影響範囲: クラウド環境の約43%が影響を受け、6,500以上のクラスターが脆弱な状態

攻撃結果: Kubernetes全クラスターの完全な乗っ取りが可能

修正版: Ingress NGINX Controller バージョン1.12.1および1.11.5で修正済み

脆弱性ID: CVE-2025-1097、CVE-2025-1098、CVE-2025-24514、CVE-2025-1974

 はじめに2025年3月、Wiz Researchチームは、Kubernetes用Ingress NGINXコントローラーに複数の深刻な脆弱性を発見し、「IngressNightmare」と名付けました。この一連の脆弱性は、認証なしで攻撃者がリモートコード実行（RCE）を行い、クラスター内の全名前空間のシークレットに不正アクセス可能となるもので、Kubernetesエコシステムに大きな衝撃を与えています。
この記事では、脆弱性の技術的メカニズム、影響範囲、詳細な対策方法を解説するとともに、このインシデントから学ぶべきクラウドネイティブセキュリティの教訓についても考察します。

 Ingress NGINXとKubernetesエコシステムにおける位置づけ
 Ingress NGINXの重要性Ingress NGINXコントローラーは、KubernetesコミュニティとCloud Native Computing Foundation（CNCF）によって維持管理される公式プロジェクトで、Kubernetesのイングレスリソースの最も一般的な実装の一つです。GitHubで18,000以上のスターを獲得し、その普及率の高さを示しています。
Wiz Researchの調査によると、インターネットに面しているKubernetesクラスターの41%以上がIngress-NGINXを採用しており、Enterprise環境での標準的な選択肢となっています。

 Kubernetesにおけるイングレスの役割Kubernetesでは、クラスター内のアプリケーションを外部に公開するために「Ingress」リソースを使用します。イングレスは以下の機能を提供します：
外部HTTPSトラフィックを内部サービスにルーティング
URLベースのバーチャルホスティング
ロードバランシング
TLS/SSL終端
名前ベースの仮想ホスティング
以下は基本的なIngressリソースの例です：
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: example-ingress
  annotations:
    nginx.ingress.kubernetes.io/rewrite-target: /
spec:
  rules:
  - host: example.com
    http:
      paths:
      - path: /app
        pathType: Prefix
        backend:
          service:
            name: app-service
            port:
              number: 80

 脆弱性の技術的解説
 アドミッションコントローラーとその脆弱性IngressNightmareの中核となる問題は、Ingress NGINXのアドミッションコントローラーコンポーネントにあります。アドミッションコントローラーは、Kubernetesリソースが作成または更新される前に、それらを検証するゲートキーパーの役割を果たします。
この脆弱性が特に深刻な理由は3つあります：

認証なしのアクセス: デフォルト設定では、アドミッションコントローラーのエンドポイントが認証なしでネットワーク経由でアクセス可能

特権的な権限: コントローラーが全名前空間のシークレットにアクセスできる権限で動作

複雑な処理: 送信されたイングレス定義をNGINX設定に変換する複雑なロジックが攻撃の余地を生む

 攻撃チェーンの詳細分析IngressNightmareの攻撃チェーンは3つの主要フェーズから構成されます：

 1. 認証バイパスと不正アクセス攻撃者は、KubernetesのAPIサーバーを経由せずに、直接アドミッションコントローラーエンドポイント（通常はポート8443）にリクエストを送信できます。これは、アドミッションWebhookがデフォルトで認証を要求しないためです。
POST /validate?timeout=30s HTTP/1.1
Host: ingress-nginx-controller-admission.default.svc:8443
Content-Type: application/json
...

 2. 悪意のあるNGINX設定の注入攻撃者は、特別に細工されたIngress定義を含むAdmissionReviewリクエストを送信します。この定義には、以下のいずれかの脆弱なアノテーションやフィールドを悪用した注入ペイロードが含まれます：
CVE-2025-24514 – auth-urlアノテーション注入:
nginx.ingress.kubernetes.io/auth-url: "http://example.com/#;\nssl_engine /proc/12345/fd/42;\n#"
CVE-2025-1097 – auth-tls-match-cnアノテーション注入:
nginx.ingress.kubernetes.io/auth-tls-match-cn: "CN=abc #(\n){}\n }}\nssl_engine /proc/12345/fd/42;\n#"
CVE-2025-1098 – mirror UIDインジェクション:

（UIDフィールドへの注入により、NGINXの設定にコマンドを埋め込み）

 3. リモートコード実行と特権昇格アドミッションコントローラーは受信したIngress定義を処理し、それを一時的なNGINX設定ファイルに変換して、nginx -tコマンドで検証します。
注入されたssl_engineディレクティブにより、NGINXは指定されたパスから共有ライブラリをロードします。この共有ライブラリは、事前にNGINXのクライアントボディバッファリング機能を利用してアップロードされた悪意のあるペイロードです。
ライブラリがロードされると、攻撃者のコードが実行され、Ingress NGINXの特権的なサービスアカウントを利用してクラスター内のすべてのシークレットにアクセスできるようになります。

 技術的詳細: NGINXクライアントボディバッファの悪用攻撃の特に巧妙な部分は、共有ライブラリをポッドのファイルシステムに配置する方法です。
攻撃者は、8KB以上のHTTPリクエストボディを持つリクエストをNGINXに送信します
NGINXはこのようなサイズの大きなリクエストを処理する際、一時的にディスクにバッファリングします（/var/lib/nginx/body/など）
通常、NGINXはリクエスト処理後にファイルを削除しますが、攻撃者は実際のペイロードより大きなContent-Lengthを指定することでプロセスを待機状態にします
ファイルは削除されても、Linuxのファイルシステム特性により、開いているファイルディスクリプタを通じて/proc/<PID>/fd/<FD番号>からアクセス可能です
攻撃者はssl_engineディレクティブを使ってこのパスを指定し、NGINXに悪意のあるライブラリをロードさせます
# 共有ライブラリアップロード用のHTTPリクエスト
POST / HTTP/1.1
Host: vulnerable-ingress.example.com
Content-Length: 100000
...

[ELF形式の悪意のある共有ライブラリ]

 影響評価と診断方法
 脆弱性の影響範囲この脆弱性の影響範囲は極めて広く、特に以下の条件に当てはまる環境では即時対応が必要です：
Ingress NGINXコントローラーのバージョン1.12.0以前または1.11.4以前を使用
アドミッションコントローラーエンドポイントがクラスター内の他のPodからアクセス可能
アドミッションコントローラーエンドポイントがインターネットに公開されている
Wizの調査によると、6,500以上のクラスターが脆弱なIngress NGINXアドミッションコントローラーをインターネットに公開しており、Fortune 500企業を含む多くの組織が直接的なリスクにさらされています。

 脆弱性の診断方法以下の手順で、お使いの環境がIngressNightmareに対して脆弱かどうかを診断できます：

 1. Ingress-NGINXの使用確認# クラスター内のIngress-NGINXポッドを確認
kubectl get pods --all-namespaces --selector app.kubernetes.io/name=ingress-nginx

# バージョン情報の確認
kubectl exec -n <namespace> <ingress-controller-pod> -- /nginx-ingress-controller --version

 2. アドミッションコントローラーの公開状態確認# ValidatingWebhookConfigurationの確認
kubectl get validatingwebhookconfiguration ingress-nginx-admission -o yaml

# サービスの確認
kubectl get service -n <namespace> ingress-nginx-controller-admission

 3. Nucleiテンプレートによる脆弱性診断Wizが公開しているNucleiテンプレートを使用して、公開されているIngress-NGINXアドミッションコントローラーを確認できます：
nuclei -t path/to/ingress-nginx-admission-rce.yaml -u https://your-ingress-controller.example.com:8443

 包括的な対策ガイド
 即時対策（緊急時）脆弱性に対して即座に対応する必要がある場合、以下の緩和策を実施してください：

 1. アドミッションコントローラーの一時的な無効化Helmでインストールしている場合：
helm upgrade ingress-nginx ingress-nginx/ingress-nginx \
  --namespace <namespace> \
  --set controller.admissionWebhooks.enabled=false \
  --reuse-values
マニフェストで直接管理している場合：
# ValidatingWebhookConfigurationの削除
kubectl delete validatingwebhookconfiguration ingress-nginx-admission

# DeploymentまたはDaemonSetの更新
kubectl patch deployment -n <namespace> ingress-nginx-controller --type json \
  -p '[{"op": "remove", "path": "/spec/template/spec/containers/0/args/-"}]'

 2. ネットワークポリシーによるアクセス制限apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: restrict-admission-webhook
  namespace: <ingress-nginx-namespace>
spec:
  podSelector:
    matchLabels:
      app.kubernetes.io/name: ingress-nginx
      app.kubernetes.io/component: controller
  policyTypes:
  - Ingress
  ingress:
  - from:
    - namespaceSelector:
        matchLabels:
          kubernetes.io/metadata.name: kube-system
    ports:
    - protocol: TCP
      port: 8443

 恒久的対策
 1. Ingress NGINXの更新脆弱性を完全に解決するには、Ingress NGINXコントローラーを安全なバージョン（1.12.1以上または1.11.5以上）に更新してください：
Helmを使用する場合：
# リポジトリの更新
helm repo update

# アップグレードの実行
helm upgrade ingress-nginx ingress-nginx/ingress-nginx \
  --namespace <namespace> \
  --version <安全なバージョン> \
  --reuse-values
マニフェストを使用する場合：
# 安全なバージョンのマニフェストをダウンロード
kubectl apply -f https://raw.githubusercontent.com/kubernetes/ingress-nginx/controller-v1.12.1/deploy/static/provider/cloud/deploy.yaml

 2. アドミッションコントローラーのセキュリティ強化アップデート後も、以下の追加措置を実施することをお勧めします：

TLS認証の強化: クライアント証明書認証の設定

ネットワークセグメンテーション: アドミッションコントローラーへのアクセスをAPI Serverのみに制限

Podセキュリティコンテキスト: 最小権限の原則に基づいた設定

 3. 継続的なモニタリングセキュリティツールを導入して、異常なアクセスパターンや不正な設定変更を検出してください：
Kubernetes監査ログの有効化と監視
アドミッションコントローラーへのアクセスログの分析
ランタイムセキュリティツールの導入

 Kubernetesセキュリティの教訓IngressNightmareから学ぶべき重要なセキュリティ教訓をいくつか紹介します：

 1. デフォルト設定の危険性多くのKubernetesコンポーネントは、利便性を優先して比較的緩やかなデフォルト設定になっています。この事例は、デフォルト設定がセキュリティに与えるリスクを明確に示しています。特に以下の点に注意すべきです：
アドミッションコントローラーが認証なしで公開される設計
サービスアカウントに過剰な権限が付与される傾向
インターネットに公開されるエンドポイントの存在

 2. 深層防御の重要性単一の脆弱性がクラスター全体の乗っ取りにつながったことから、多層的なセキュリティ対策の重要性が浮き彫りになりました：
ネットワークセグメンテーションによるコンポーネント間の通信制限
最小権限の原則に基づいたサービスアカウント設定
セキュリティコンテキストの適切な設定と強化

 3. サプライチェーンセキュリティの重要性Ingress NGINXはKubernetesエコシステムの中核コンポーネントであり、その脆弱性が広範囲に影響します。このことから：
信頼できるソースからのコンポーネント導入の重要性
定期的なセキュリティアップデートの適用
ソフトウェア部品表（SBOM）の管理と脆弱性の継続的なモニタリング

 業界の対応と今後の展望IngressNightmareの発見と対応プロセスからは、オープンソースセキュリティコミュニティの強みと課題の両方が見えてきます：

 責任ある開示プロセスWiz ResearchチームとKubernetesセキュリティチームの協力により、脆弱性は適切に対処されました：
2024年12月31日：最初の脆弱性報告
2025年1月〜2月：修正の開発と検証
2025年3月24日：公開開示
このプロセスは、セキュリティ研究者とオープンソースプロジェクトの協力の重要性を示しています。

 Kubernetesセキュリティの進化IngressNightmareは、Kubernetesエコシステム全体のセキュリティ強化を促進するきっかけとなるでしょう：
アドミッションコントローラーのセキュリティ設計の見直し
APIセキュリティの強化
セキュアバイデザインの原則の徹底

 まとめと提言IngressNightmareは、クラウドネイティブ環境における複雑なセキュリティ課題を浮き彫りにした事例です。最も広く採用されているコンポーネントでさえ、重大な脆弱性の影響を受ける可能性があることを示しています。
すべてのKubernetes管理者と開発者に対する提言：

定期的なセキュリティレビューの実施: クラスター構成、特にインターネットに公開されるコンポーネントの定期的な監査

防御的な設定の採用: デフォルト設定に依存せず、セキュリティを強化する構成への変更

アップデートの迅速な適用: セキュリティパッチの公開後、速やかに適用する体制の整備

セキュリティの多層化: 単一の防御線に依存せず、複数のセキュリティ対策を組み合わせる
Kubernetesとクラウドネイティブ技術の急速な発展に伴い、セキュリティも同様に進化し続ける必要があります。IngressNightmareのような発見は、セキュリティコミュニティとオープンソースプロジェクトの協力により、より安全なクラウドネイティブエコシステムの構築につながるでしょう。

 参考資料Wiz Research Blog: IngressNightmare詳細解説
Kubernetes Security Blog: アドミッションコントローラーのセキュリティベストプラクティス
CNCF Ingress NGINXプロジェクトリポジトリ
CVE-2025-1097, CVE-2025-1098, CVE-2025-24514, CVE-2025-1974の詳細情報
Nucleiテンプレート: 脆弱なアドミッションコントローラー検出
NIST: Kubernetesセキュリティハードニングガイド
CIS Kubernetesベンチマーク
この記事は技術情報の共有と教育を目的としており、脆弱性の悪用を意図するものではありません。記事内のコードや手順はセキュリティ専門家による検証や対策のために提供されています。システム管理者は、組織のセキュリティポリシーに従い、適切に対応してください。
要点まとめ

はじめに

Ingress NGINXとKubernetesエコシステムにおける位置づけ

Ingress NGINXの重要性

Kubernetesにおけるイングレスの役割

脆弱性の技術的解説

アドミッションコントローラーとその脆弱性

攻撃チェーンの詳細分析

1. 認証バイパスと不正アクセス

2. 悪意のあるNGINX設定の注入

3. リモートコード実行と特権昇格

技術的詳細: NGINXクライアントボディバッファの悪用

影響評価と診断方法

脆弱性の影響範囲

脆弱性の診断方法

1. Ingress-NGINXの使用確認

2. アドミッションコントローラーの公開状態確認

3. Nucleiテンプレートによる脆弱性診断

包括的な対策ガイド

即時対策（緊急時）

1. アドミッションコントローラーの一時的な無効化

2. ネットワークポリシーによるアクセス制限

恒久的対策

1. Ingress NGINXの更新

2. アドミッションコントローラーのセキュリティ強化

3. 継続的なモニタリング

Kubernetesセキュリティの教訓

1. デフォルト設定の危険性

2. 深層防御の重要性

3. サプライチェーンセキュリティの重要性

業界の対応と今後の展望

責任ある開示プロセス

Kubernetesセキュリティの進化

まとめと提言

参考資料

Discussion
