rahulreddykarne/cve-2026-57836-confluent_kafkaОтключение проверки 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 при создании , отключая проверку TLS-сертификатов для HTTPS-соединений с Vault, устанавливаемых через правила шифрования полей Schema Registry.
hvac.ClientУязвимый код находится в:
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, может:
X-Vault-Tokenrole_idsecret_idЭто может скомпрометировать конфиденциальность и целостность данных, защищаемых рабочим процессом KMS на базе Vault.
confluent-kafka — официальный Python-клиент Confluent для 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 передаётся через HTTP-заголовок:
X-Vault-Token
Если злоумышленнику успешно удаётся выдать себя за конечную точку Vault, контролируемый им сервер может получить этот токен.
При использовании аутентификации AppRole клиент отправляет:
role_id
secret_id
на:
/v1/auth/approle/login
Таким образом, успешная MITM-атака позволяет перехватить оба учётных данных AppRole.
Затронутый драйвер HCVault читает конфигурацию, включая:
token.id
namespace
approle.role.id
approle.secret.id
а также соответствующие переменные окружения VAULT_*.
Однако в затронутых версиях не предоставляется конфигурация, позволяющая операторам:
В результате приложения, использующие затронутую интеграцию, не могут восстановить проверку 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://
Возможные примеры включают:
После получения необходимой позиции MITM привилегии на уровне приложения или взаимодействие с жертвой не требуются.
poc_confluent_kafka.py демонстрирует проблему на локально распакованном wheel-пакете confluent-kafka 2.14.2.
PoC использует:
HcVaultKmsClient.Доказательство концепции содержит пять режимов.
| Режим | Описание |
|---|---|
cert | Генерирует самоподписанный сертификат и ключ для локального mock Vault. |
server | Запускает mock HTTPS Vault на https://localhost:8443 и отображает полученные запросы. |
control | Безопасный контроль с verify=True; должен отклонить самоподписанный сертификат с CERTIFICATE_VERIFY_FAILED. |
token | Загружает уязвимый HcVaultKmsClient и демонстрирует, что он принимает недоверенный сертификат. |
approle | Проверяет уязвимый путь аутентификации AppRole и демонстрирует раскрытие role_id и secret_id. |
Установите зависимости PoC:
pip install hvac cryptography
Поместите распакованный уязвимый wheel рядом с PoC:
confluent_kafka-2.14.2-cp310-cp310-win_amd64/
└── confluent_kafka/
└── schema_registry/
└── ...
PoC импортирует HcVaultKmsClient напрямую из распакованного пакета 2.14.2.
Он заглушает несвязанные зависимости, такие как tink, что позволяет протестировать уязвимую конструкцию клиента Vault без необходимости в полном окружении Kafka или KMS.
Используйте два терминала.
python poc_confluent_kafka.py server
Mock HTTPS Vault прослушивает:
https://localhost:8443
используя самоподписанный сертификат.
Сначала продемонстрируйте, что надлежащая проверка сертификата отклоняет самоподписанный сервер:
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 подключается, несмотря на то что сервер предъявляет недоверенный сертификат.
Mock-сервер может наблюдать токен Vault:
GET /v1/auth/token/lookup-self
X-Vault-Token: CNA-DEMO-VAULT-TOKEN
X-Vault-Namespace: cna-demo-namespace
Запустите:
python poc_confluent_kafka.py approle
Mock 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
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: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.22.15.0Жёстко заданный verify=False существовал с момента появления интеграции HCVault вплоть до версии 2.14.2.
Поведение безопасности было исправлено в 2.15.0.
YYYY-MM-DD — Сообщено в Confluent.2.15.0.Обнаружено и сообщено Rahul Karne.
confluent-kafka-python
https://github.com/confluentinc/confluent-kafka-python
confluent-kafka на PyPI
https://pypi.org/project/confluent-kafka/
Python-клиент HashiCorp hvac
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 работает исключительно против локального mock-сервера Vault с использованием фиктивных учётных данных.
Он не взаимодействует с реальным HashiCorp Vault, Kafka, Schema Registry, производственной инфраструктурой или реальными учётными данными.
Материал предоставлен для оборонительных исследований в области безопасности и образовательных целей.
Медиа-запросы: [email protected]. Полный PoC (сервер злоумышленника, архив обхода, приложение-жертва) и дополнительные технические детали доступны по запросу.