Отключение проверки 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-сертификатов для HTTPS-соединений с Vault, устанавливаемых через правила шифрования полей 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, может:
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/
└── ...