CVE-2025-1974 — IngressNightmare (ingress-nginx)

परिचय

यह दस्तावेज़ Kubernetes के लिए ingress-nginx घटक (validating admission controller) को प्रभावित करने वाली भेद्यता CVE-2025-1974 के शोध को प्रस्तुत करता है।
CVE-2025-1974 एक गंभीर भेद्यता (CVSS 3.1 9.8) है, जो ingress-nginx प्रक्रिया के संदर्भ में एक unauthenticated Remote Code Execution (RCE) है। हमले को अंजाम देते समय, एक हमलावर जिसके पास pod-नेटवर्क तक पहुँच है (या validating webhook तक AdmissionReview पहुँचाने का तरीका है), नियंत्रक के pod में मनमाना कोड निष्पादित कर सकता है, जो संभावित रूप से Secrets के प्रकटीकरण और क्लस्टर पर कब्ज़ा करने की ओर ले जाता है।

Ingress-nginx Kubernetes में सबसे व्यापक रूप से उपयोग किए जाने वाले Ingress नियंत्रकों में से एक है (अनुमानों के अनुसार दर्जनों प्रतिशत क्लस्टर इसका उपयोग करते हैं), इसलिए भेद्यता का व्यावहारिक प्रभाव बहुत अधिक है। विवरण, तकनीकी विश्लेषण और फिक्स के लिए आधिकारिक सिफारिशें Kubernetes, Wiz के शोधकर्ताओं और कई विक्रेता ब्लॉगों द्वारा प्रकाशित की गई हैं।

---

रिपोर्ट का उद्देश्य

CVE-2025-1974 का चरण-दर-चरण विश्लेषण करना और write-up के लिए आवश्यक सामग्री तैयार करना:

1. सामग्री एकत्र करना और संरचित करना। आधिकारिक advisories, शोध write-ups और विक्रेता विश्लेषण एकत्र करें; मुख्य तकनीकी विवरण और PoC दिशाओं को उजागर करें।
2. भेद्यता के सार और उसके प्रभाव को समझना। Root cause, हमले की श्रृंखला और संभावित परिणामों (RCE → Secrets का प्रकटीकरण → cluster takeover) की व्याख्या करें।
3. CPE और कॉन्फ़िगरेशन शर्तों का निर्धारण करना। उन संस्करणों/पैकेजों और Kubernetes/ingress-nginx कॉन्फ़िगरेशन को सूचीबद्ध करें जिनमें भेद्यता लागू होती है।
4. प्रयोगशाला में सुरक्षित परीक्षण के लिए सिफारिशें देना और बड़े पैमाने पर जाँच के दौरान जोखिम को कम करना।

---

⚠️ अस्वीकरण

यह शोध विशेष रूप से शैक्षिक और नैतिक उद्देश्यों के लिए किया गया है और केवल परीक्षण/नियंत्रित वातावरण के लिए अभिप्रेत है।
किसी भी परिस्थिति में मालिक की लिखित अनुमति के बिना दूसरों के क्लस्टर या सार्वजनिक रूप से सुलभ इंस्टेंस के विरुद्ध एक्सप्लॉइट/PoC चलाएँ। पूरी तरह कार्यात्मक "weaponized" PoC का खुले तौर पर प्रकाशन दुरुपयोग के जोखिम को बहुत बढ़ा देता है — सार्वजनिक भाग में safe-PoC और पद्धति प्रस्तुत करना बेहतर है। (आधिकारिक advisories और विक्रेता भी एक्सप्लॉइट के प्रसार में सावधानी पर जोर देते हैं)।

---

CPE और कॉन्फ़िगरेशन शर्तें

• cpe:2.3:a:kubernetes:ingress-nginx_controller:<version> — ingress-nginx के भेद्य संस्करण (advisories में विशिष्ट संस्करण बताए गए हैं; अंतिम प्रकाशन के समय मान अपडेट करें)।
• विक्रेता/वितरण जिनमें भेद्य नियंत्रक शामिल है:
  • RKE2 / Rancher वितरण जिनमें संकेतित पैच संस्करणों तक ingress-nginx है।
  • Harvester संस्करण जो भेद्य ingress-nginx का उपयोग करते हैं (विक्रेता KB में विशिष्ट प्रभावित बिल्ड हैं)।
  • कस्टम क्लस्टर जहाँ ingress-nginx अलग से स्थापित है (Helm chart/manifest) — chart/image के संस्करण जाँचें।

कॉन्फ़िगरेशन शर्तें जिनमें भेद्यता लागू होती है:

1. ingress-nginx का भेद्य संस्करण (advisories में बताए गए रिलीज़/पैच से पहले)। सटीक संस्करण संख्याओं के लिए NVD और विक्रेता advisories देखें।
2. Validating admission webhook pod-नेटवर्क के बाहर से सुलभ — यदि webhook बाहर से सुलभ है (जैसे सार्वजनिक endpoint, प्रदाता ने गलती से सेवा को उजागर कर दिया), तो एक्सप्लॉइट दूरस्थ रूप से निष्पादित किया जा सकता है। Wiz और अन्य शोधकर्ताओं ने सार्वजनिक प्रदर्शन के कई मामलों की ओर इशारा किया है।
3. NetworkPolicy / pod-नेटवर्क अलगाव का अभाव: यदि हमलावर किसी pod से क्लस्टर नेटवर्क में अनुरोध भेज सकता है (compromised pod), तो यह शोषण के लिए पर्याप्त है।
4. admission controller से पहले अतिरिक्त सत्यापन/ACL का अभाव: अतिरिक्त फ़िल्टर/ingress-proxy प्रमाणीकरण जोखिम को कम कर सकते हैं।
5. ingress-nginx कंटेनर में व्यापक अधिकारों और Secrets तक पहुँच वाले service account की उपस्थिति — डिफ़ॉल्ट रूप से, नियंत्रक अक्सर व्यापक अधिकारों वाला serviceAccount माउंट करता है; यह सफल शोषण पर प्रभाव बढ़ाता है।

---

भेद्यता का विवरण

संक्षिप्त सारांश।
भेद्यता Ingress-NGINX नियंत्रक के Validating Admission Controller घटक में पाई गई है और यह इस बात से संबंधित है कि यह घटक आने वाले Ingress / AdmissionReview के आधार पर अस्थायी NGINX कॉन्फ़िगरेशन कैसे बनाता और मान्य करता है। प्रक्रिया के दौरान, नियंत्रक nginx.conf उत्पन्न करता है और कॉन्फ़िगरेशन की जाँच (nginx -t) चलाता है। Ingress/AdmissionReview फ़ील्ड के अपर्याप्त निस्तारण के कारण, हमलावर विशेष रूप से तैयार टुकड़े डाल सकता है जो उत्पन्न कॉन्फ़िग में शामिल हो जाते हैं और परिणामस्वरूप नियंत्रक प्रक्रिया के अंदर कमांड निष्पादन की ओर ले जाते हैं — यानी ingress-nginx pod में दूरस्थ कोड निष्पादन (RCE)।

मुख्य तकनीकी बिंदु

• प्रवेश बिंदु। नियंत्रक के validating webhook द्वारा प्राप्त आने वाले AdmissionReview/Ingress ऑब्जेक्ट NGINX कॉन्फ़िगरेशन (एनोटेशन फ़ील्ड, बैकएंड सेटिंग्स आदि सहित) उत्पन्न करने के लिए स्रोत डेटा बन जाते हैं।
• शोषण तंत्र। एक हानिकारक Ingress या प्रत्यक्ष AdmissionReview कॉन्फ़िगरेशन टेम्प्लेट/टुकड़ों में नियंत्रित स्ट्रिंग्स डाल सकता है। ऐसे nginx.conf की जाँच/लोड करने पर, सत्यापन प्रक्रिया (nginx -t) और कॉन्फ़िगरेशन फ़ाइल के साथ बाद की कार्रवाइयाँ नियंत्रक के संदर्भ में मनमाना कोड निष्पादन, फ़ाइलों को लिखना/चलाना या कमांड चलाने का कारण बन सकती हैं।
• आवश्यक शर्तें। सफल शोषण के लिए आवश्यक है: ingress-nginx का भेद्य संस्करण; validating webhook तक AdmissionReview पहुँचाने की क्षमता (pod-नेटवर्क से पहुँच या प्रत्यक्ष नेटवर्क पहुँच); क्षतिपूर्ति उपायों का अभाव — NetworkPolicy, RBAC प्रतिबंध या अतिरिक्त webhook प्रमाणीकरण। कुछ परिदृश्यों में, Create/Update अधिकारों को दरकिनार करके सीधे webhook को crafted AdmissionReview भेजना संभव है।

यह खतरनाक क्यों है — शोषण के परिणाम

सफल शोषण ingress-nginx कंटेनर में कोड निष्पादन देता है, जो आमतौर पर अनुमति देता है:

• नियंत्रक का serviceAccount टोकन प्राप्त करना और Kubernetes API तक पहुँचना;
• सुलभ namespace में Secrets और अन्य गोपनीय जानकारी पढ़ना;
• क्लस्टर संसाधन बनाना/संशोधित करना और पहुँच बढ़ाना (विशेषाधिकार वृद्धि, पार्श्व गति);
• कुछ मामलों में — क्लस्टर पर पूर्ण कब्ज़ा।

व्यवहारिक और डिटेक्शन अवलोकन

• नियंत्रक के सामान्य संचालन के दौरान, Admission Controller के लिए अनुरोध प्रवाह नहीं होता है — validating webhook एक आंतरिक घटक है जो क्लस्टर के भीतर काम करता है। शोषण के दौरान एक विसंगति देखी जाती है: नेटवर्क मैप (जैसे Luntry) पर ingress-nginx-controller-admission और सेवा ingress-nginx-controller के लिए गैर-मानक स्रोतों (रिपोर्ट में — alpine जैसे कंटेनर) से आने वाले कनेक्शन दिखाई देते हैं, जो सामान्य संचालन में नहीं होना चाहिए।
• क्लस्टर के नेटवर्क मैप का विश्लेषण माइक्रोसर्विसेज के बीच इंटरैक्शन का दृश्य देता है; namespace में ingress-nginx के Deployment का चयन करके आने/जाने वाले कनेक्शन देखे जा सकते हैं। हमले के समय admission-endpoint पर आने वाले कनेक्शन की उपस्थिति समझौते का स्पष्ट संकेतक है।
• शोषण के प्रयासों का पता लगाने के लिए निगरानी करना उपयोगी है: validating webhook पर POST अनुरोध, असामान्य Ingress ऑब्जेक्ट का निर्माण, nginx -t कॉल और नियंत्रक का अचानक पुनरारंभ, साथ ही ingress-nginx प्रक्रिया से अप्रत्याशित फ़ाइल लेखन संचालन।

संदर्भ: Ingress-NGINX नियंत्रक क्या है और यह महत्वपूर्ण क्यों है

Ingress-NGINX Kubernetes में सबसे व्यापक रूप से उपयोग किए जाने वाले Ingress नियंत्रकों में से एक है (सेवाओं तक बाहरी पहुँच व्यवस्थित करने के लिए व्यापक रूप से उपयोग किया जाता है)। नियंत्रक एक रिवर्स प्रॉक्सी के रूप में कार्य करता है: यह बाहरी ट्रैफ़िक प्राप्त करता है और Ingress नियमों के सेट के आधार पर इसे संबंधित Service/Pod को प्रॉक्सी करता है। Ingress-NGINX परियोजना बहुत लोकप्रिय है और इंटरनेट-सुलभ क्लस्टर में इसकी एक महत्वपूर्ण स्थापना हिस्सेदारी है।

Kubernetes दस्तावेज़ीकरण में Ingress-NGINX को Ingress नियंत्रक के एक संदर्भ उदाहरण के रूप में उद्धृत किया गया है। अनुमानों के अनुसार, खुले क्लस्टर का एक महत्वपूर्ण हिस्सा इसका उपयोग करता है; कुछ शोधों में संकेत दिया गया है कि लगभग 41% सार्वजनिक रूप से सुलभ क्लस्टर Ingress-NGINX का उपयोग करते हैं। इसकी व्यापक उपलब्धता और ट्रैफ़िक रूटिंग में केंद्रीय भूमिका के कारण ही इस घटक में भेद्यताओं का उच्च व्यावहारिक प्रभाव होता है।

validating webhook हमले का सुविधाजनक वेक्टर क्यों बन जाता है

• डिफ़ॉल्ट रूप से, नियंत्रक का validating webhook Kubernetes नेटवर्क स्पेस के भीतर सुलभ होता है और अक्सर इसके पते (जैसे validate.nginx.ingress.kubernetes.io) पर कॉल करने पर अतिरिक्त प्रमाणीकरण की आवश्यकता नहीं होती है। यह क्लस्टर के अंदर से इसे एक्सेस करना आसान बनाता है।
• संयोजन: नियंत्रक का व्यापक प्रसार + इसकी नेटवर्क पहुँच + संभावित रूप से व्यापक service account अधिकार = गंभीर संयोजन, जो समझौते के लिए एक प्रभावी मार्ग प्रदान करता है।
• व्यावहारिक रूप में, क्लस्टर में "पहला प्रवेश बिंदु" प्राप्त करना बहुत कठिन नहीं है: एप्लिकेशन में अक्सर ऐसी भेद्यताएँ होती हैं जो एक अलग कंटेनर से समझौता करने की ओर ले जाती हैं; इसके बाद हमलावर उस कंटेनर से आंतरिक webhook तक पहुँच सकता है। इसके अलावा, वेब एप्लिकेशन में SSRF जैसी शोषण योग्य भेद्यताओं का उपयोग अक्सर क्लस्टर नेटवर्क के अंदर अनुरोध शुरू करने और ऐसे webhook का उपयोग करने के लिए किया जाता है।

एक्सप्लॉइट श्रृंखला का पुनर्विवरण (संक्षेप में)

1. हमलावर pod-नेटवर्क में अनुरोध भेजने या सीधे validating webhook तक पहुँचने की क्षमता प्राप्त करता है।
2. एक विशेष रूप से तैयार Ingress / AdmissionReview बनाया जाता है, जहाँ कुछ फ़ील्ड में हानिकारक स्ट्रिंग्स होती हैं जिन्होंने उचित फ़िल्टरिंग पास नहीं की है।
3. नियंत्रक इन इनपुट डेटा के आधार पर nginx.conf उत्पन्न करता है और nginx -t / अन्य सत्यापन संचालन करता है।
4. डाले गए टुकड़े नियंत्रक प्रक्रिया के संदर्भ में कमांड/स्क्रिप्ट निष्पादन या फ़ाइलों को लिखने/चलाने का कारण बनते हैं।
5. निष्पादन प्राप्त करने के बाद, हमलावर serviceAccount टोकन निकालता है, Kubernetes API तक पहुँचता है और क्लस्टर में आगे बढ़ता और विशेषाधिकार बढ़ाता है।

अन्य भेद्यताओं के साथ संगतता पर टिप्पणियाँ

ऐसी भेद्यताएँ विशेष रूप से खतरनाक होती हैं जब अन्य दोषों के साथ जुड़ती हैं: एक समझौता किया गया pod (या सार्वजनिक एप्लिकेशन में SSRF) + उजागर validating webhook पूर्ण हैक का उच्च मौका देता है। इसलिए, घटना विश्लेषण में निर्भरता श्रृंखला और संभावित वैक्टर पर विचार किया जाना चाहिए, न कि केवल ingress-nginx के संस्करण पर।

---