CVE-2026-15911: confluent-kafka में HashiCorp Vault KMS के लिए अक्षम TLS प्रमाणपत्र सत्यापन

गंभीरता: उच्च, CVSS 3.1 7.4

वेक्टर (v3.1): CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:N

प्रभावित: confluent-kafka >= 2.8.0, <= 2.14.2

में ठीक किया गया: 2.15.0

CWE: CWE-295 (अनुचित प्रमाणपत्र सत्यापन)

घटक: confluent_kafka/schema_registry/rules/encryption/hcvault/hcvault_client.py

रिपोर्ट किया गया: Rahul Karne

CNA: VulnCheck

---

सारांश

confluent-kafka में HashiCorp Vault KMS क्लाइंट अपने hvac.Client का निर्माण करते समय verify=False को हार्डकोड करता है, जिससे Schema Registry फ़ील्ड-एन्क्रिप्शन नियमों के माध्यम से की जाने वाली Vault HTTPS कनेक्शनों के लिए TLS प्रमाणपत्र सत्यापन अक्षम हो जाता है।

कमजोर कोड यहाँ स्थित है:

confluent_kafka/schema_registry/rules/encryption/hcvault/hcvault_client.py

प्रभावित क्लाइंट को निम्नानुसार आरंभ किया जाता है:

self._client = hvac.Client(
    url=vault_url,
    token=token,
    namespace=ns,
    verify=False
)

चूँकि verify=False बिना शर्त है, क्लाइंट अविश्वसनीय TLS प्रमाणपत्रों को स्वीकार करता है, जिनमें स्व-हस्ताक्षरित या हमलावर-नियंत्रित प्रमाणपत्र भी शामिल हैं।

एक नेटवर्क-स्थित हमलावर जो एप्लिकेशन के Vault ट्रैफ़िक को इंटरसेप्ट या रीडायरेक्ट करने में सक्षम है, Vault सर्वर का रूप धारण कर सकता है, Vault प्रमाणीकरण क्रेडेंशियल्स को कैप्चर कर सकता है, और नकली Vault/KMS प्रतिक्रियाएँ लौटा सकता है।

प्रभावित HCVault एकीकरण Vault टोकन, नेमस्पेस, और AppRole क्रेडेंशियल्स के लिए कॉन्फ़िगरेशन प्रदान करता है, लेकिन प्रभावित संस्करण प्रमाणपत्र सत्यापन को बहाल करने के लिए कोई समर्थित CA-बंडल कॉन्फ़िगरेशन या समकक्ष तंत्र प्रदान नहीं करते हैं।

---

प्रभाव

एप्लिकेशन और HashiCorp Vault के बीच नेटवर्क मैन-इन-द-मिडल स्थिति वाला हमलावर यह कर सकता है:

1. हमलावर-नियंत्रित या स्व-हस्ताक्षरित TLS प्रमाणपत्र प्रस्तुत करना।
2. उस प्रमाणपत्र को स्वीकार करवाना क्योंकि सत्यापन अक्षम है।
3. Vault प्रमाणीकरण सामग्री कैप्चर करना, जिसमें शामिल हैं:
   • X-Vault-Token
   • AppRole role_id
   • AppRole secret_id
4. नकली Vault प्रतिक्रियाएँ इंजेक्ट करना।
5. Schema Registry एन्क्रिप्शन नियमों द्वारा उपयोग किए जाने वाले KMS key-wrapping या key-unwrapping संचालनों में हस्तक्षेप करना।

यह Vault-समर्थित KMS वर्कफ़्लो द्वारा संरक्षित डेटा की गोपनीयता और अखंडता से समझौता कर सकता है।

---

पहुँच

confluent-kafka Apache Kafka के लिए आधिकारिक Confluent Python क्लाइंट है।

यह भेद्यता विशेष रूप से उन परिनियोजनों को प्रभावित करती है जो उपयोग करते हैं:

Schema Registry encryption rules
        ↓
HCVault KMS integration
        ↓
hcvault:// key URI

इसलिए प्रभावित जनसंख्या सभी confluent-kafka उपयोगकर्ताओं की तुलना में संकीर्ण है।

हालाँकि, प्रभावित कार्यक्षमता सुरक्षा-संवेदनशील है क्योंकि ये परिनियोजन क्रिप्टोग्राफिक कुंजी प्रबंधन और फ़ील्ड-स्तरीय एन्क्रिप्शन के लिए HashiCorp Vault पर निर्भर करते हैं।

---

तकनीकी विवरण

HcVaultKmsClient.__init__() एक hcvault:// कुंजी URI को पार्स करता है, Vault बेस URL निर्धारित करता है, और एक hvac.Client बनाता है।

प्रभावित संस्करणों में, जिसमें 2.14.2 भी शामिल है, प्रासंगिक कोड है:

self._client = hvac.Client(
    url=vault_url,
    token=token,
    namespace=ns,
    verify=False
)

if role_id and secret_id and self._client is not None:
    self._client.auth.approle.login(
        role_id=role_id,
        secret_id=secret_id
    )

hvac लाइब्रेरी अंततः Python requests TLS स्टैक पर निर्भर करती है।

सेटिंग:

verify=False

क्लाइंट को निर्देश देती है कि वह रिमोट सर्वर के TLS प्रमाणपत्र को मान्य न करे।

परिणामस्वरूप, वे प्रमाणपत्र जो सामान्यतः अस्वीकार किए जाते, स्वीकार किए जा सकते हैं, जिनमें ऐसे प्रमाणपत्र शामिल हैं जो:

• स्व-हस्ताक्षरित हैं
• समाप्त हो चुके हैं
• गलत होस्टनाम के लिए जारी किए गए हैं
• अविश्वसनीय प्राधिकरण द्वारा हस्ताक्षरित हैं
• हमलावर द्वारा उत्पन्न किए गए हैं

यह दोनों समर्थित प्रमाणीकरण पथों को प्रभावित करता है।

टोकन प्रमाणीकरण

जब टोकन प्रमाणीकरण का उपयोग किया जाता है, तो Vault टोकन इसके माध्यम से भेजा जाता है:

X-Vault-Token

HTTP हेडर।

यदि कोई हमलावर सफलतापूर्वक Vault एंडपॉइंट का रूप धारण कर लेता है, तो हमलावर-नियंत्रित सर्वर यह टोकन प्राप्त कर सकता है।

AppRole प्रमाणीकरण

जब AppRole प्रमाणीकरण का उपयोग किया जाता है, तो क्लाइंट भेजता है:

role_id
secret_id

इस पर:

/v1/auth/approle/login

इसलिए एक सफल MITM दोनों AppRole क्रेडेंशियल्स को कैप्चर कर सकता है।

---

अनुपलब्ध TLS कॉन्फ़िगरेशन

प्रभावित HCVault ड्राइवर निम्नलिखित सहित कॉन्फ़िगरेशन पढ़ता है:

token.id
namespace
approle.role.id
approle.secret.id

साथ ही प्रासंगिक VAULT_* पर्यावरण चर।

हालाँकि, प्रभावित संस्करण ऑपरेटरों को निम्नलिखित की अनुमति देने वाला कॉन्फ़िगरेशन उजागर नहीं करते हैं:

• एक कस्टम CA बंडल प्रदान करना।
• सर्वर-प्रमाणपत्र सत्यापन बहाल करना।
• विश्वसनीय निजी PKI रूट कॉन्फ़िगर करना।
• समकक्ष सुरक्षित TLS सत्यापन व्यवहार कॉन्फ़िगर करना।

परिणामस्वरूप, प्रभावित एकीकरण का उपयोग करने वाले एप्लिकेशन सामान्य पैकेज कॉन्फ़िगरेशन के माध्यम से TLS सत्यापन बहाल नहीं कर सकते हैं।

---

मूल कारण

पैकेज सुरक्षित डिफ़ॉल्ट पर निर्भर रहने के बजाय स्पष्ट रूप से TLS सर्वर-प्रमाणपत्र सत्यापन को अक्षम करता है।

कमजोर निर्माण प्रभावी रूप से है:

hvac.Client(..., verify=False)

न कि:

hvac.Client(..., verify=True)

या बस:

hvac.Client(...)

जहाँ सत्यापन डिफ़ॉल्ट रूप से सक्षम होता है।

प्रमाणपत्र सत्यापन को अक्षम करना TLS कनेक्शन से सर्वर प्रमाणीकरण को हटा देता है।

हालाँकि कनेक्शन एन्क्रिप्टेड रहता है, क्लाइंट के पास यह निर्धारित करने का कोई विश्वसनीय तंत्र नहीं है कि वह वैध Vault सर्वर के साथ संचार कर रहा है या नहीं।

यह नेटवर्क मैन-इन-द-मिडल हमले के लिए आवश्यक स्थिति बनाता है।

---

शोषण की पूर्व शर्तें

सफल शोषण के लिए आवश्यक है:

1. एप्लिकेशन confluent-kafka का प्रभावित संस्करण उपयोग करता है:

   • 2.8.0 से 2.14.2 तक।

2. एप्लिकेशन HCVault KMS एकीकरण के साथ Schema Registry एन्क्रिप्शन नियमों का उपयोग करता है।

3. कॉन्फ़िगर की गई KMS कुंजी इस स्कीम का उपयोग करती है:

hcvault://

4. हमलावर एप्लिकेशन और Vault के बीच ट्रैफ़िक को इंटरसेप्ट, रीडायरेक्ट, या रूप धारण करने में सक्षम नेटवर्क स्थिति प्राप्त करता है।

संभावित उदाहरणों में शामिल हैं:

• DNS स्पूफ़िंग
• ARP स्पूफ़िंग
• समझौता किया गया नेटवर्क बुनियादी ढाँचा
• रोग वाई-फ़ाई या राउटर बुनियादी ढाँचा
• रूट/BGP हेरफेर
• दुर्भावनापूर्ण एग्रेस प्रॉक्सी
• समझौता किया गया नेटवर्क सेगमेंट

आवश्यक MITM स्थिति बनने के बाद किसी एप्लिकेशन-स्तरीय विशेषाधिकार या पीड़ित इंटरैक्शन की आवश्यकता नहीं है।

---

प्रूफ़ ऑफ़ कॉन्सेप्ट

poc_confluent_kafka.py स्थानीय रूप से अनपैक किए गए confluent-kafka 2.14.2 व्हील के विरुद्ध इस समस्या को प्रदर्शित करता है।

PoC उपयोग करता है:

• HashiCorp Vault का अनुकरण करने वाला एक स्थानीय स्व-हस्ताक्षरित HTTPS सर्वर।
• डमी Vault क्रेडेंशियल्स।
• वास्तविक कमजोर HcVaultKmsClient कार्यान्वयन।
• कोई वास्तविक Kafka बुनियादी ढाँचा नहीं।
• कोई वास्तविक Vault बुनियादी ढाँचा नहीं।
• कोई उत्पादन क्रेडेंशियल्स नहीं।

प्रूफ़ ऑफ़ कॉन्सेप्ट में पाँच मोड हैं।

मोड	विवरण
cert	स्थानीय मॉक Vault के लिए एक स्व-हस्ताक्षरित प्रमाणपत्र और कुंजी उत्पन्न करता है।
server	https://localhost:8443 पर मॉक HTTPS Vault शुरू करता है और प्राप्त अनुरोधों को प्रदर्शित करता है।
control	verify=True का उपयोग करके सुरक्षित नियंत्रण; स्व-हस्ताक्षरित प्रमाणपत्र को CERTIFICATE_VERIFY_FAILED के साथ अस्वीकार करना चाहिए।
token	कमजोर HcVaultKmsClient को लोड करता है और प्रदर्शित करता है कि यह अविश्वसनीय प्रमाणपत्र को स्वीकार करता है।
approle	कमजोर AppRole प्रमाणीकरण पथ का परीक्षण करता है और role_id और secret_id के एक्सपोज़र को प्रदर्शित करता है।

---

सेटअप

PoC निर्भरताएँ स्थापित करें:

pip install hvac cryptography

अनपैक किए गए कमजोर व्हील को PoC के बगल में रखें:

confluent_kafka-2.14.2-cp310-cp310-win_amd64/
└── confluent_kafka/
    └── schema_registry/
        └── ...