लैब 5-CVE-2019-20933

I. सिस्टम विश्लेषण

हमले की सतह की पहचान

पर्यावरण में क्या चल रहा है, उससे शुरू करते हैं। मैं सभी सक्रिय कंटेनरों को सूचीबद्ध करता हूँ:

docker ps

पीड़ित एक एकल पोर्ट उजागर करता है: 8086।

वर्तमान में, मेरे पास लक्ष्य के बारे में विस्तृत जानकारी नहीं है। docker ps आउटपुट से, सिस्टम बाह्य रूप से केवल पोर्ट 8086 पर एक उल्लेखनीय सेवा उजागर करता है, जो कंटेनर के अंदर की सेवा से मैप की गई है। यह विश्लेषण करने के लिए प्राथमिक हमले की सतह है।

इसे ब्राउज़र के माध्यम से तुरंत एक्सेस करने के बजाय, हम Nmap का उपयोग करके सेवा की फिंगरप्रिंटिंग करते हैं ताकि यह पता लगाया जा सके कि पोर्ट 8086 पर कौन सी सेवा चल रही है:

nmap -sV -sC -p 8086 192.168.3.137

स्कैन परिणाम दिखाते हैं कि पोर्ट 8086 InfluxDB OSS 1.6.6 की HTTP सेवा है। यह एक HTTP API के माध्यम से उजागर एक समय-श्रृंखला डेटाबेस है, न कि एक सामान्य वेब एप्लिकेशन।

फिंगरप्रिंटिंग के बाद सोच विश्लेषण

InfluxDB एक ओपन-सोर्स टाइम सीरीज़ डेटाबेस (TSDB) है जो Go में लिखा गया है। RDBMS (सटीक लेन-देन के लिए अनुकूलित) या Elasticsearch (पाठ खोज के लिए अनुकूलित) के विपरीत, InfluxDB एक ही उद्देश्य के साथ बनाया गया था: बड़े लेखन वॉल्यूम को संभालना (उच्च लेखन थ्रूपुट) और कम विलंबता के साथ समय अक्ष के साथ डेटा क्वेरी करना।

चूंकि सेवा को InfluxDB के रूप में फिंगरप्रिंट किया गया है, अगला कदम यह देखना है कि InfluxDB ग्राहकों के साथ कैसे संचार करता है। InfluxDB v1 HTTP API दस्तावेज़ के अनुसार, पोर्ट 8086 डिफ़ॉल्ट HTTP API पोर्ट है। महत्वपूर्ण एंडपॉइंट में शामिल हैं:

• /ping: सर्वर की परिचालन स्थिति की जाँच करता है।
• /query: मेटाडेटा या डेटा पढ़ने के लिए InfluxQL क्वेरी भेजता है।
• /write: डेटाबेस में समय-श्रृंखला डेटा लिखता है।

⇒ सोच: Nmap द्वारा सेवा को InfluxDB http admin 1.6.6 के रूप में पहचानने के बाद, हम इसे एक मानक वेबसाइट की तरह परीक्षण करना जारी नहीं रखते। वेब एप्लिकेशन के लिए, हम आमतौर पर रूट, लॉगिन फॉर्म या निर्देशिकाओं की तलाश करते हैं। हालांकि, InfluxDB के साथ, हमले की सतह HTTP API के भीतर है। इसलिए, हमें मानक InfluxDB API एंडपॉइंट का परीक्षण करने के लिए स्विच करना होगा ताकि यह निर्धारित किया जा सके कि API को प्रमाणीकरण की आवश्यकता है या नहीं। नतीजतन, अगली परीक्षण दिशा ब्राउज़र के माध्यम से / तक पहुँचना नहीं है, बल्कि InfluxDB के API एंडपॉइंट पर सीधे अनुरोध भेजना है।

API व्यवहार का विश्लेषण और प्रमाणीकरण लक्ष्यों की पहचान

/ping एंडपॉइंट की जाँच

पोर्ट 8086 को InfluxDB HTTP API के रूप में पहचानने के बाद, सेवा के चालू होने की पुष्टि करने के लिए /ping एंडपॉइंट की जाँच करें:

curl -i <http://192.168.3.137:8086/ping>

प्रतिक्रिया 204 No Content पुष्टि करती है कि InfluxDB सामान्य रूप से काम कर रहा है। हेडर आगे सेवा संस्करण को InfluxDB OSS 1.6.6 के रूप में पुष्टि करते हैं।

/query एंडपॉइंट पर प्रमाणीकरण की जाँच

curl -i -s "http://192.168.3.137:8086/query?q=SHOW+DATABASES"

/query एंडपॉइंट प्रमाणीकरण क्रेडेंशियल के बिना सीधे क्वेरी की अनुमति नहीं देता है। यह पुष्टि करता है कि InfluxDB में प्रमाणीकरण सक्षम है और सिस्टम को भेजी गई सभी अनाम क्वेरी को ब्लॉक करता है।

मैं सोचने पर स्विच करता हूँ: क्या InfluxDB संस्करण 1.6.6 में कोई भेद्यता है जो प्रमाणीकरण तंत्र को बायपास करने की अनुमति देती है?

सार्वजनिक भेद्यता डेटाबेस का संदर्भ देकर, 1.7.6 से पहले के InfluxDB संस्करण CVE-2019-20933 से प्रभावित हैं। यह InfluxDB के प्रमाणीकरण फ़ंक्शन के भीतर एक प्रमाणीकरण बायपास भेद्यता है, जो खाली साझा गुप्त कुंजी वाले JWT टोकन को संभालने से संबंधित है।

चूंकि लक्ष्य InfluxDB 1.6.6 चला रहा है, जो पैच किए गए संस्करण 1.7.6 से कम है, सेवा प्रभावित संस्करण सीमा के अंतर्गत आती है।

यह निष्कर्ष निकाला जा सकता है:

सेवा: InfluxDB OSS
संस्करण: 1.6.6
प्रमाणीकरण: सक्षम
CVE मैपिंग: CVE-2019-20933
प्रभाव: प्रमाणीकरण बायपास
स्थिति: संस्करण असुरक्षित

⇒ सोच: प्रारंभ में, /query एंडपॉइंट 401 Unauthorized लौटाता है, जो दर्शाता है कि प्रमाणीकरण तंत्र सक्रिय है। हालांकि, प्रमाणीकरण सक्षम होने का मतलब पूर्ण सुरक्षा नहीं है। जब संस्करण को 1.6.6 के रूप में फिंगरप्रिंट किया जाता है, तो हमें इसे ज्ञात CVE से सहसंबंधित करने की आवश्यकता है। परिणाम बताते हैं कि यह संस्करण CVE-2019-20933 से प्रभावित सीमा के अंतर्गत आता है, जिसका अर्थ है कि /query एंडपॉइंट की रक्षा करने वाले प्रमाणीकरण तंत्र को बायपास करना संभव है। इन पहचान परिणामों के आधार पर, शोषण चरण उपयुक्त JWT टोकन उत्पन्न करके और /query एंडपॉइंट के विरुद्ध क्वेरी निष्पादित करके CVE-2019-20933 को सत्यापित करने पर केंद्रित होगा।

भेद्यता तंत्र विश्लेषण (CVE-2019-20933)

CVE-2019-20933 भेद्यता InfluxDB के 1.7.6 से पहले के संस्करणों में services/httpd/handler.go फ़ाइल के अंदर authenticate फ़ंक्शन में होती है।

InfluxDB में JWT प्रमाणीकरण तंत्र

InfluxDB HTTP API अनुरोधों के लिए JSON Web Tokens (JWT) का उपयोग करके प्रमाणीकरण का समर्थन करता है। हेडर के साथ अनुरोध प्राप्त करने पर:

Authorization: Bearer <token>

InfluxDB निम्नलिखित चरणों का पालन करेगा:

1. टोकन को डीकोड करके हेडर और पेलोड निकालें।
2. टोकन हस्ताक्षर सत्यापन के लिए गुप्त कुंजी के रूप में कार्य करने के लिए influxdb.conf फ़ाइल से shared-secret कॉन्फ़िगरेशन मान पढ़ें।
3. यदि हस्ताक्षर मान्य है, तो क्वेरी निष्पादित करने वाले उपयोगकर्ता को निर्धारित करने के लिए दावों से username फ़ील्ड प्राप्त करें।

दोष

प्रभावित संस्करणों में, यदि JWT प्रमाणीकरण सक्षम है लेकिन shared-secret पैरामीटर कॉन्फ़िगर नहीं किया गया है, तो गुप्त मान को एक खाली स्ट्रिंग ("") के रूप में संसाधित किया जा सकता है।

सिस्टम JWT हस्ताक्षर को सत्यापित करने से पहले गुप्त की सुरक्षा शक्ति का पर्याप्त रूप से सत्यापन करने में विफल रहता है। यह एक हमलावर को एक कस्टम JWT बनाने, इसे खाली गुप्त कुंजी के साथ हस्ताक्षरित करने, और फिर username दावे को सिस्टम पर एक मान्य खाते पर सेट करने की अनुमति देता है, जैसे कि admin यदि यह खाता लैब में मौजूद है।

जब यह टोकन Authorization: Bearer <token> हेडर के माध्यम से प्रस्तुत किया जाता है, तो InfluxDB हस्ताक्षर को सत्यापित करने के लिए उसी खाली गुप्त कुंजी का उपयोग करता है। यदि हस्ताक्षर मेल खाता है और उपयोगकर्ता नाम मौजूद है, तो अनुरोध को उपयोगकर्ता के वास्तविक पासवर्ड की आवश्यकता के बिना अधिकृत किया जाएगा।

प्रसंस्करण प्रवाह को निम्नानुसार संक्षेपित किया जा सकता है:

चरण	सामान्य प्रसंस्करण	CVE-2019-20933 में दोष
1	क्लाइंट Authorization: Bearer <token> भेजता है	हमलावर स्वयं JWT बनाता है
2	सर्वर कॉन्फ़िगरेशन से shared-secret पढ़ता है	shared-secret सेट नहीं है
3	सर्वर JWT हस्ताक्षर को सत्यापित करने के लिए गुप्त कुंजी का उपयोग करता है	गुप्त कुंजी को खाली स्ट्रिंग "" के रूप में संसाधित किया जाता है
4	यदि टोकन मान्य है, तो दावे से username प्राप्त करें	हमलावर उपयोगकर्ता मौजूद होने पर username=admin सेट करता है
5	सर्वर दावे के उपयोगकर्ता के आधार पर अनुमतियाँ प्रदान करता है	पासवर्ड की आवश्यकता के बिना अनुरोध स्वीकार किया जाता है

तर्क स्तर पर शोषण प्रवाह:

InfluxDB < 1.7.6
→ प्रमाणीकरण सक्षम
→ खाली shared-secret
→ हमलावर गुप्त कुंजी "" के साथ हस्ताक्षरित JWT बनाता है
→ Authorization: Bearer के माध्यम से टोकन भेजता है
→ सर्वर टोकन स्वीकार करता है
→ /query पर क्वेरी सफल होती है

सारांश

CVE तंत्र को समझने के बाद, केवल संस्करण के आधार पर निष्कर्ष निकालने से बचने के लिए इसे लक्ष्य से सहसंबंधित करना आवश्यक है।