i3r1h0n/ingressnightterror# IngressNightmare 脆弱性 (CVE-2025-1974) に関する私の見解
このリポジトリは、IngressNightmare 脆弱性に関する私の調査研究です。脆弱な Ingress のデプロイファイル、エクスプロイト本体、共有オブジェクトペイロードが含まれています。
CVE インデックスの一覧:
auth-url アノテーションインジェクションauth-tls-match-cn アノテーションインジェクション参考までに:
この脆弱性の根本は、適切な入力サニタイズが行われていないことにあります。AdmissionReview リクエストを送信すると、一時的な NGINX 設定が作成され、その設定が後で nginx -t コマンドを使用して検証されます。バグが修正されたソースコードを参照してください。
テスト対象の設定内容を制御できるため、さまざまな設定フィールドを利用して不正な設定を注入できます。
auth-url - 適切なサニタイズが行われないため、# と \n を追加できます。この注入ポイントを使用します。auth-tls-match-cn - フィールドが CN= で始まり、有効な正規表現であることだけが必要です。ing.UID - UID がそのまま設定に挿入されます。NGINX 設定がテストされるだけであるという事実により、使用できるディレクティブの数が少し減ります。残っているディレクティブの1つが ssl_engine で、これを使用すると共有ライブラリをロードできます。これは良い侵入口です。しかし、.so ファイルをポッドのファイルシステムにどうやって配置するのでしょうか？
WIZ の賢い人々は、.so オブジェクトをボディとしてリクエストを送信し、それが十分に大きい場合、NGINX がそれを procfs 内のファイルとして保存するというアイデアを思いつきました。また、Content-Length を調整することで NGINX にさらにデータを待機させ、ファイルを一時的に procfs に保持させることもできます。実際の PID と FD 番号は推測されることになります。
詳細については、WIZ 研究チームによる元の分析記事を参照してください。
エクスプロイトコードはかなり自明です。ソースを見てください。
リポジトリをクローンします:
git clone https://github.com/I3r1h0n/IngressNightterror
cd IngressNightterror
docker の k3s イメージを起動します:
cd stand
docker compose up -d
NGINX Ingress をデプロイします:
Linux/Mac を使用している場合は、スクリプトを使用してデプロイできます:
./k8s/setup.sh
Windows を使用している場合、またはデプロイプロセスをより細かく制御したい場合は、手動で以下の操作を行ってください:
NGINX Ingress をデプロイします:
kubectl --kubeconfig=./output/kubeconfig.yaml apply -f ./k8s/ingress.yaml
これで、./output 内の設定を使用して kubectl を利用できます。ネームスペース ingress-nginx を使用することを忘れないでください。
重要な注意: ingress.yaml は 脆弱な NGINX Ingress
ペイロードは単純なリバースプロキシです。ビルドする前にポートと IP アドレスを編集することを忘れないでください:
make all
これは docker コンテナ gcc:latest を使用して共有オブジェクトをビルドします。
元々この脆弱性を発見した WIZ リサーチチーム、そして NGINX Ingress のメンテナーに多大な敬意を表します。
prod by I3r1h0n.