keraattin/cve-2026-35616CVE-2026-35616 के लिए पहचान टूलकिट, जो FortiClient EMS में एक प्री-ऑथेंटिकेशन API बाईपास है। इसमें Python स्कैनर और Nmap NSE स्क्रिप्ट शामिल है, जो कमजोर संस्करणों की पहचान करने और उपचार मार्गदर्शन प्रदान करने के लिए है।
Fortinet FortiClient EMS 7.4.5 और 7.4.6 में एक गंभीर ऑथेंटिकेशन बाईपास एक पूरी तरह से अनऑथेंटिकेटेड, रिमोट हमलावर को एक HTTP हेडर (X-SSL-CLIENT-VERIFY) को स्पूफ करके API ऑथेंटिकेशन को बायपास करने की अनुमति देता है। यह दोष इसलिए मौजूद है क्योंकि Django मिडलवेयर क्लाइंट सर्टिफिकेट मेटाडेटा को यूज़र-नियंत्रित हेडर से ट्रस्ट करता है, न कि केवल ट्रस्टेड रिवर्स प्रॉक्सी से। यह हमलावरों को पूर्ण प्रशासनिक API एक्सेस देता है - और वहां से, पूरे एंटरप्राइज़ में प्रबंधित एंडपॉइंट्स पर मनमाना कोड निष्पादन।
31 मार्च, 2026 से सक्रिय रूप से शोषित। 6 अप्रैल, 2026 को CISA KEV में जोड़ा गया।
| फ़ील्ड | विवरण |
|---|---|
| CVE ID | CVE-2026-35616 |
| विक्रेता | Fortinet |
| उत्पाद | FortiClient Enterprise Management Server (EMS) |
| प्रभावित संस्करण | 7.4.5, 7.4.6 |
| प्रभावित नहीं | 7.2.x शाखा, 7.4.4 और पुराने |
| CVSS v3.1 | 9.1 (गंभीर) |
| CWE | CWE-284 - अनुचित एक्सेस नियंत्रण |
| हमले का वेक्टर | नेटवर्क |
| ऑथेंटिकेशन | कोई आवश्यकता नहीं |
| यूज़र इंटरैक्शन | कोई नहीं |
| शोषण परिपक्वता | जंगली में शोषित |
| CISA KEV | 6 अप्रैल, 2026 को जोड़ा गया (समय सीमा: 9 अप्रैल, 2026) |
| पैच | हॉटफिक्स उपलब्ध; पूर्ण फिक्स 7.4.7 में |
| श्रेय | Simo Kohonen (Defused Cyber), Nguyen Duc Anh |
FortiClient Enterprise Management Server (EMS) Fortinet का केंद्रीकृत एंडपॉइंट प्रबंधन प्लेटफ़ॉर्म है। यह किसी संगठन में FortiClient एजेंटों को तैनात करने, कॉन्फ़िगर करने और मॉनिटर करने के लिए कमांड-एंड-कंट्रोल परत के रूप में कार्य करता है। इसे उस मस्तिष्क के रूप में सोचें जो Fortinet-प्रबंधित वातावरण में हर एंडपॉइंट को नियंत्रित करता है:
जब कोई हमलावर EMS तक प्रशासनिक पहुंच प्राप्त करता है, तो वे अनिवार्य रूप से संगठन में हर प्रबंधित एंडपॉइंट की कुंजी के मालिक होते हैं।
FortiClient EMS पर्दे के पीछे एक काफी मानक वेब एप्लिकेशन स्टैक का उपयोग करता है:
+----------------+ +----------------+ +----------------+
| ब्राउज़र / | HTTPS | Apache | WSGI | Django |
| API क्लाइंट | -------> | (mod_ssl) | -------> | बैकएंड |
+----------------+ +----------------+ +----------------+
जब म्यूचुअल TLS (mTLS) कॉन्फ़िगर किया जाता है, तो Apache का mod_ssl क्लाइंट सर्टिफिकेट सत्यापन को संभालता है। सर्टिफिकेट को मान्य करने के बाद, Apache सत्यापन परिणाम को ट्रस्टेड WSGI पर्यावरण चर के माध्यम से Django को भेजता है:
SSL_CLIENT_VERIFY - सत्यापन स्थिति (SUCCESS, NONE, FAILED)SSL_CLIENT_S_DN - सर्टिफिकेट से विषय विशिष्ट नामSSL_CLIENT_SERIAL - सर्टिफिकेट क्रमांकयह मानक और सुरक्षित पैटर्न है। समस्या यह है कि Django मिडलवेयर इस डेटा को कैसे पढ़ता है।
FortiClient EMS 7.4.5 और 7.4.6 में, Django ऑथेंटिकेशन मिडलवेयर को HTTP अनुरोध हेडर से भी यही जानकारी स्वीकार करने के लिए संशोधित किया गया था:
X-SSL-CLIENT-VERIFYX-SSL-CLIENT-S-DNX-SSL-CLIENT-SERIALयह संभवतः रिवर्स प्रॉक्सी परिनियोजन का समर्थन करने के लिए जोड़ा गया था जहां Apache TLS समाप्ति बिंदु नहीं है। हालांकि, मिडलवेयर इन दो स्रोतों के बीच अंतर नहीं करता है। यह पहले WSGI चर की जांच करता है, लेकिन यदि वे अनुपस्थित हैं (कोई mTLS कॉन्फ़िगर नहीं है, या सीधा कनेक्शन है), तो यह HTTP हेडर पर वापस आ जाता है - जिसे कोई भी क्लाइंट सेट कर सकता है।
यहाँ अवधारणात्मक विवरण है:
सुरक्षित पथ (इच्छित):
Apache mod_ssl सर्टिफिकेट मान्य करता है --> WSGI env vars सेट करता है --> Django env vars पढ़ता है [ठीक]
असुरक्षित पथ (भेद्यता):
हमलावर सीधे HTTP हेडर सेट करता है --> Django हेडर पढ़ता है --> उन पर भरोसा करता है [विफल]
मिडलवेयर प्रभावी रूप से क्लाइंट पर भरोसा करता है कि वह अपने स्वयं के सर्टिफिकेट सत्यापन स्थिति की स्व-पुष्टि करे। यह एक बाउंसर से पूछने जैसा है "अरे, क्या दूसरे बाउंसर ने पहले ही आपकी ID जांच ली है?" और जब वे "हाँ" कहते हैं तो उन्हें अंदर जाने देना।
चरण 1: हमलावर EMS API एंडपॉइंट पर POST अनुरोध भेजता है
इन हेडर के साथ:
X-SSL-CLIENT-VERIFY: SUCCESS
X-SSL-CLIENT-S-DN: CN=admin
X-SSL-CLIENT-SERIAL: 0000000000000001
चरण 2: Django मिडलवेयर WSGI env vars की जांच करता है → मौजूद नहीं
HTTP हेडर पर वापस आता है → X-SSL-CLIENT-VERIFY: SUCCESS पाता है
चरण 3: मिडलवेयर अनुरोध को प्रशासक पहचान के साथ ऑथेंटिकेटेड मानता है
चरण 4: हमलावर के पास पूर्ण प्रशासनिक API एक्सेस होता है
चरण 5: प्रशासनिक API से, हमलावर यह कर सकता है:
- सभी प्रबंधित एंडपॉइंट्स पर दुर्भावनापूर्ण नीतियां पुश करना
- संग्रहीत क्रेडेंशियल्स और सर्टिफिकेट निकालना
- सॉफ़्टवेयर वितरण के माध्यम से पेलोड तैनात करना
- ZTNA कॉन्फ़िगरेशन संशोधित करना
- व्यापक नेटवर्क में पिवट करना
पूरे हमले के लिए एक एकल HTTP अनुरोध की आवश्यकता होती है। कोई ब्रूट-फोर्सिंग नहीं, कोई क्रेडेंशियल स्टफिंग नहीं, कोई सोशल इंजीनियरिंग नहीं। केवल एक जाली हेडर।
यहां गंभीरता सर्वर से परे जाती है। FortiClient EMS एक बल गुणक है - इसे समझौता करने से हमलावर को हर प्रबंधित एंडपॉइंट पर लाभ मिलता है:
तत्काल प्रभाव:
डाउनस्ट्रीम प्रभाव (प्रबंधित एंडपॉइंट्स के माध्यम से):
एंटरप्राइज़ जोखिम:
| संस्करण | स्थिति |
|---|---|
| FortiClient EMS 7.4.6 | भेद्य |
| FortiClient EMS 7.4.5 | भेद्य |
| FortiClient EMS 7.4.4 और पुराने | प्रभावित नहीं |
| FortiClient EMS 7.2.x | प्रभावित नहीं |