CVE-2026-57836: تعطيل التحقق من شهادة TLS لـ HashiCorp Vault KMS في confluent-kafka

الخطورة: عالية، 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

الملخص

يقوم عميل HashiCorp Vault KMS في confluent-kafka بتثبيت verify=False بشكل صلب عند إنشاء hvac.Client الخاص به، مما يعطّل التحقق من شهادة TLS لاتصالات Vault عبر HTTPS التي تتم من خلال قواعد تشفير حقول Schema Registry.

يقع الكود الثغرة في:

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 أن:

يقدّم شهادة TLS يتحكم بها المهاجم أو موقّعة ذاتيًا.
يتم قبول تلك الشهادة لأن التحقق معطّل.
يلتقط مواد مصادقة Vault، بما في ذلك:
- X-Vault-Token
- AppRole role_id
- AppRole secret_id
يحقن استجابات Vault مزيفة.
يتداخل مع عمليات تغليف أو فك تغليف مفاتيح KMS المستخدمة بواسطة قواعد تشفير Schema Registry.

يمكن أن يؤدي هذا إلى اختراق سرية وسلامة البيانات المحمية بواسطة سير عمل KMS المدعوم بـ Vault.

النطاق

confluent-kafka هو عميل Confluent Python الرسمي لـ Apache Kafka.

تؤثر الثغرة تحديدًا على عمليات النشر التي تستخدم:

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

لذلك فإن الفئة المتأثرة أضيق من جميع مستخدمي confluent-kafka.

ومع ذلك، فإن الوظيفة المتأثرة حساسة أمنيًا لأن عمليات النشر هذه تعتمد على HashiCorp Vault لإدارة المفاتيح التشفيرية والتشفير على مستوى الحقل.

التفاصيل التقنية

يقوم HcVaultKmsClient.__init__() بتحليل URI مفتاح hcvault://، ويحدد عنوان URL الأساسي لـ Vault، وينشئ 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 في النهاية على حزمة TLS الخاصة بـ Python requests.

تعيين:

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 الشرعي.

وهذا يخلق الشرط المطلوب لهجوم رجل في المنتصف على الشبكة.

شروط الاستغلال

يتطلب الاستغلال الناجح:

يستخدم التطبيق إصدارًا متأثرًا من confluent-kafka:
- 2.8.0 حتى 2.14.2.
يستخدم التطبيق قواعد تشفير Schema Registry مع تكامل HCVault KMS.
يستخدم مفتاح KMS المُكوَّن المخطط:

hcvault://

يحصل المهاجم على موقع على الشبكة قادر على اعتراض أو إعادة توجيه أو انتحال حركة المرور بين التطبيق وVault.

تشمل الأمثلة المحتملة:

انتحال DNS
انتحال ARP
بنية تحتية للشبكة مخترقة
بنية تحتية لـ Wi-Fi أو راوتر مارقة
التلاعب بالمسارات/BGP
وكيل خروج خبيث
قطاع شبكة مخترق

لا يُطلب أي امتيازات على مستوى التطبيق أو تفاعل من الضحية بمجرد وجود موقع MITM اللازم.

إثبات المفهوم

poc_confluent_kafka.py يوضح المشكلة مقابل حزمة confluent-kafka 2.14.2 غير المضغوطة محليًا.

يستخدم PoC:

خادم HTTPS محلي موقّع ذاتيًا يحاكي HashiCorp Vault.
بيانات اعتماد Vault وهمية.
تنفيذ HcVaultKmsClient الحقيقي الثغرة.
لا بنية تحتية حقيقية لـ Kafka.
لا بنية تحتية حقيقية لـ Vault.
لا بيانات اعتماد إنتاجية.

يحتوي إثبات المفهوم على خمسة أوضاع.

الإعداد

ثبّت تبعيات PoC:

pip install hvac cryptography

ضع الحزمة الثغرة غير المضغوطة بجوار PoC:

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

يستورد PoC HcVaultKmsClient مباشرةً من حزمة 2.14.2 غير المضغوطة.

يقوم بعمل stubs للتبعيات غير ذات الصلة مثل tink، مما يسمح باختبار إنشاء عميل Vault الثغرة دون الحاجة إلى بيئة Kafka أو KMS كاملة.

التشغيل

استخدم طرفيتين.

الطرفية 1 — بدء Vault الوهمي

python poc_confluent_kafka.py server

يستمع Vault الوهمي عبر HTTPS على:

https://localhost:8443

باستخدام شهادة موقّعة ذاتيًا.

الطرفية 2 — التحكم الآمن

أولاً، أظهر أن التحقق الصحيح من الشهادة يرفض الخادم الموقّع ذاتيًا:

python poc_confluent_kafka.py control

النتيجة المتوقعة:

EXPECTED TLS failure: CERTIFICATE_VERIFY_FAILED
-> verify=True correctly rejected the self-signed cert

مسار الرمز الثغرة

شغّل:

python poc_confluent_kafka.py token

يتصل HcVaultKmsClient الثغرة على الرغم من أن الخادم يقدّم شهادة غير موثوقة.

يمكن للخادم الوهمي ملاحظة رمز Vault:

GET /v1/auth/token/lookup-self
X-Vault-Token: CNA-DEMO-VAULT-TOKEN
X-Vault-Namespace: cna-demo-namespace

مسار AppRole الثغرة

شغّل:

python poc_confluent_kafka.py approle

يستقبل Vault الوهمي:

POST /v1/auth/approle/login
{"role_id": "CNA-DEMO-ROLE-ID", "secret_id": "CNA-DEMO-SECRET-ID"}

يوضح التباين بين وضع control الآمن وأوضاع token / approle الثغرة أن السلوك ناتج عن:

verify=False

المثبّت بشكل صلب وليس عن بيئة الاختبار.

المعالجة

الإصلاح الآمن الأساسي هو السماح لـ hvac بإجراء التحقق من الشهادة:

hvac.Client(
    url=vault_url,
    token=token,
    namespace=ns
)

نظرًا لأن التحقق من TLS ممكّن افتراضيًا، فإن تعطيله صراحةً غير ضروري.

يجب أن يقوم التنفيذ القوي بـ:

تمكين التحقق من شهادة TLS افتراضيًا.
دعم حزمة CA قابلة للتكوين، على سبيل المثال:

ssl.ca.location

دعم تكوين CA الخاص بـ Vault مثل:

VAULT_CACERT

دعم شهادات العميل للبيئات التي تستخدم mutual TLS.
منع قيمة تكوين فارغة أو زائفة من تعطيل التحقق من الشهادة بصمت.
إضافة اختبار انحدار يؤكد أن الشهادات الموقّعة ذاتيًا وغير الموثوقة يتم رفضها افتراضيًا.

الإصدار المُصلح

تم إصلاح الثغرة في:

confluent-kafka 2.15.0

الإصدارات المتأثرة هي:

2.8.0
through
2.14.2

في 2.15.0، تم تغيير سلوك عميل Vault بحيث يكون التحقق من TLS ممكّنًا افتراضيًا.

يقدّم التنفيذ المحدّث أيضًا تكوينًا متعلقًا بـ TLS بما في ذلك:

ssl.ca.location
VAULT_CACERT
ssl.certificate.location
ssl.key.location

يتيح ذلك لعمليات النشر التي تستخدم بنية PKI خاصة توفير تكوين CA موثوق وشهادة عميل دون تعطيل التحقق من الشهادة.

CVSS

تم تقييم الثغرة:

CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:N

درجة CVSS 3.1: 7.4 — عالية

تفصيل المتجه

AV:N — الشبكة

يحدث اتصال Vault الثغرة عبر اتصال شبكة.

AC:H — تعقيد هجوم عالٍ

يجب على المهاجم الحصول على موقع MITM على الشبكة أو إعادة توجيه اتصال Vault بطريقة أخرى.

هذا شرط أساسي كبير ولهذا تم تصنيف الثغرة كعالية بدلاً من حرجة.

PR:N — لا امتيازات مطلوبة

لا يحتاج المهاجم إلى امتيازات داخل التطبيق المتأثر.

UI:N — لا تفاعل من المستخدم

لا يُطلب أي تفاعل من المستخدم بعد حصول المهاجم على موقع الشبكة اللازم.

S:U — النطاق دون تغيير

يبقى التأثير ضمن السلطة الأمنية للتطبيق المتأثر وتفاعله مع Vault.

C:H — تأثير عالٍ على السرية

قد يتم تعريض رموز Vault أو بيانات اعتماد AppRole للمهاجم.

I:H — تأثير عالٍ على السلامة

يمكن للمهاجم انتحال هوية Vault وإرجاع استجابات Vault/KMS مزيفة.

A:N — لا تأثير على التوافر

لم يتم إثبات أي تأثير مباشر على التوافر.

الحالة

المتأثر: 2.8.0 حتى 2.14.2
تم الإصلاح: 2.15.0
CWE: CWE-295
CVE: معلّق / لم يتم تعيينه بعد

كان verify=False المثبّت بشكل صلب موجودًا منذ إدخال تكامل HCVault حتى الإصدار 2.14.2.

تم تصحيح السلوك الأمني في 2.15.0.

الجدول الزمني للإفصاح

YYYY-MM-DD — تم الإبلاغ إلى Confluent.
2026-06-26 — تم دمج إصلاح التحقق الآمن من TLS في المنبع.
تم إصدار الإصدار المُصلح باسم 2.15.0.
تعيين CVE معلّق.

الشكر

تم اكتشافه والإبلاغ عنه بواسطة Rahul Karne.

المراجع

confluent-kafka-python
https://github.com/confluentinc/confluent-kafka-python
confluent-kafka على PyPI
https://pypi.org/project/confluent-kafka/
عميل HashiCorp hvac Python
https://hvac.readthedocs.io/
مصادقة HashiCorp Vault AppRole
https://developer.hashicorp.com/vault/api-docs/auth/approle
CWE-295 — التحقق غير الصحيح من الشهادة
https://cwe.mitre.org/data/definitions/295.html
وثائق Python TLS / التحقق من الشهادة
https://docs.python.org/3/library/ssl.html#ssl-security

حول

يوثّق هذا المستودع اكتشافًا أمنيًا بإفصاح منسّق ويقدّم إثبات مفهوم غير ضار ومكتفٍ ذاتيًا.

يعمل PoC بالكامل مقابل خادم Vault وهمي محلي باستخدام بيانات اعتماد وهمية.

لا يتفاعل مع HashiCorp Vault الحقيقي، أو Kafka، أو Schema Registry، أو البنية التحتية الإنتاجية، أو بيانات اعتماد حقيقية.

المواد مقدمة لأغراض البحث الأمني الدفاعي والتعليمي.

الصحافة

استفسارات الإعلام: [email protected]. PoC الكامل (خادم المهاجم، أرشيف الاجتياز، تطبيق الضحية) وتفاصيل تقنية إضافية متاحة عند الطلب.

`cert`	ينشئ شهادة ومفتاحًا موقّعين ذاتيًا لـ Vault الوهمي المحلي.
`server`	يبدأ Vault الوهمي عبر HTTPS على `https://localhost:8443` ويعرض الطلبات المستلمة.
`control`	تحكم آمن باستخدام `verify=True`؛ يجب أن يرفض الشهادة الموقّعة ذاتيًا مع `CERTIFICATE_VERIFY_FAILED`.
`token`	يحمّل `HcVaultKmsClient` الثغرة ويوضح أنه يقبل الشهادة غير الموثوقة.
`approle`	يمارس مسار مصادقة AppRole الثغرة ويوضح تعرض `role_id` و`secret_id`.

الأكثر شعبية

CVE-2026-57836-Confluent_Kafka