IngressNightterror (CVE-2025-1974)

نظرة عامة

هذا المستودع هو بحثي حول ثغرة IngressNightmare. يتضمن ملفات نشر لـ Ingress قابل للثغرة، والاستغلال نفسه، والحمولة (shared object).

CVE

قائمة فهارس CVE:

• CVE-2025-1974 - الثغرة الجذرية
• CVE-2025-24514 - حقن تعليق توضيحي auth-url
• CVE-2025-1097 - حقن تعليق توضيحي auth-tls-match-cn
• CVE-2025-1098 - إساءة استخدام UID للصورة

المراجع

بعض المراجع فقط:

• مقال WIZ Research الأصلي
• مشكلة Kubernetes على GitHub
• تدوينة Kubernetes
• نشرة Amazon AWS
• نشرة Google Cloud

السبب الجذري

يعود جذر هذه الثغرة إلى عدم وجود تنقية مناسبة للمدخلات. عند إرسال طلب AdmissionReview، يتم إنشاء إعدادات NGINX مؤقتة يتم اختبار صحتها لاحقًا باستخدام الأمر nginx -t. انظر إلى الكود المصدري حيث تمت معالجة الثغرة.

القدرة على التحكم في محتوى الإعدادات التي يتم اختبارها تسمح لنا باستخدام مجموعة واسعة من حقول الإعدادات لحقن إعدادات تالفة:

• auth-url - يمر دون تنقية مناسبة، مما يسمح لنا بإضافة # و \n. سنستخدم نقطة الحقن هذه.
• auth-tls-match-cn - يتطلب فقط أن يبدأ الحقل بـ CN= وأن يكون تعبيرًا نمطيًا صالحًا.
• ing.UID - يتم إدراج UID في الإعدادات كما هو.

حقيقة أن إعدادات NGINX يتم اختبارها فقط تقلل قليلاً من عدد التوجيهات التي يمكننا استخدامها. أحد التوجيهات المتبقية هو ssl_engine، والذي يسمح لنا بتحميل المكتبات المشتركة. هذه نقطة دخول جيدة. لكن كيف يمكننا وضع ملف .so الخاص بنا في نظام ملفات الـ pod؟

توصل الأشخاص الأذكياء في WIZ إلى فكرة إرسال طلب مع كائن .so الخاص بنا كجسم للطلب، وإذا كان كبيرًا بما يكفي، يحفظه NGINX في ملف داخل procfs! يمكننا أيضًا ضبط Content-Length، مما يجعل NGINX ينتظر المزيد من البيانات، مما يجعله يحتفظ بالملف في procfs لبعض الوقت. سيتم تخمين رقم PID و FD الفعليين.

لمزيد من المعلومات، اقرأ المقال التحليلي الأصلي لفريق أبحاث WIZ.

الاستغلال

كود الاستغلال واضح بذاته. لذا اذهب وشاهد المصدر.

إعداد بيئة الاختبار

1. استنساخ المستودع:

   root@kitploit:~

   git clone https://github.com/I3r1h0n/IngressNightterror
   cd IngressNightterror
   

2. ابدأ صورة docker k3s:

   root@kitploit:~

   cd stand
   docker compose up -d
   

3. نشر NGINX Ingress:

   إذا كنت تستخدم Linux/Mac، يمكنك نشره باستخدام السكربت:

   root@kitploit:~

   ./k8s/setup.sh
   

   ---

   إذا كنت تستخدم Windows، أو تريد مزيدًا من التحكم في عملية النشر، فقم بهذه الخطوات يدويًا:

   نشر NGINX Ingress:

   root@kitploit:~

   kubectl --kubeconfig=./output/kubeconfig.yaml apply -f ./k8s/ingress.yaml
   

   الآن يمكنك استخدام kubectl مع الإعدادات الموجودة في ./output. لا تنسَ استخدام namespace ingress-nginx.

   ملاحظة مهمة: تم إنشاء ingress.yaml من NGINX Ingress القابل للثغرة

الحمولة (Shared Object)

الحمولة عبارة عن بروكسي عكسي بسيط. لا تنسَ تعديل المنفذ وعنوان IP قبل بنائها باستخدام:

make all

سيتم بناء المكتبة المشتركة باستخدام حاوية docker gcc:latest.

الشكر والتقدير

احترام كبير لفريق أبحاث WIZ الذين اكتشفوا الثغرة في الأصل، ولمن يحافظون على NGINX Ingress.

من إنتاج I3r1h0n.