HashiCorp Vault unseal эксплуатация: разбор HTB Skyfall от метрик-эндпоинта до root

По данным CrowdStrike Global Threat Report 2025, 75% вторжений происходят с использованием валидных учётных данных — не через эксплойты нулевого дня, а через украденные логины и пароли. Звучит скучно, пока не увидишь, как это выглядит на практике. На HTB-машине Skyfall (уровень Insane) этот вектор реализован от начала до конца: HashiCorp Vault отдаёт критичные данные через раскрытый метрик-эндпоинт, из Vault извлекаются SSH-учётки, а оттуда до root — одна команда nsenter с неограниченным sudo-правилом. Две ошибки конфигурации, ноль эксплойтов, полная компрометация. Ниже — разбор цепочки с объяснением каждого шага.

Место в цепочке атаки: от веб-разведки до root

Прежде чем нырять в детали — общая карта атаки. Kill chain (последовательность действий атакующего от первого касания до конечной цели) на Skyfall выглядит так:

1. Разведка — сканирование портов, обнаружение веб-приложения и связанных сервисов
2. Initial Access (первоначальный доступ) — нахождение раскрытого метрик-эндпоинта HashiCorp Vault
3. Credential Access (доступ к учётным данным) — извлечение токенов или unseal-ключей из метрик, получение секретов из Vault
4. Foothold (закрепление) — SSH-подключение с украденными учётными данными
5. Privilege Escalation (повышение привилегий) — злоупотребление sudo-правилом на nsenter, побег из namespace Linux, root-шелл

Каждый шаг зависит от предыдущего. Закрытый метрик-эндпоинт рвёт цепочку на втором шаге, ограниченное sudo-правило — на пятом. Две независимые ошибки конфигурации складываются в полную компрометацию — и именно поэтому этот разбор стоит пройти целиком.

[Применимо: CTF-среда, лабораторный стенд. На реальном внутреннем пентесте Vault обычно находится за несколькими слоями сетевой изоляции, а sudo-правила ревьюятся при аудите. Но каждая техника по отдельности встречается в проде.]

Как устроен Vault seal/unseal — и зачем это атакующему

HashiCorp Vault — система управления секретами: пароли, API-ключи, SSH-ключи, сертификаты хранятся в зашифрованном виде. При каждом запуске Vault стартует в sealed (запечатанном) состоянии — данные зашифрованы, сервер не может их прочитать.

Чтобы Vault заработал, его нужно unseal (распечатать). Цепочка шифрования устроена в три уровня (согласно документации HashiCorp):

• Ключ шифрования (encryption key) — шифрует данные
• Root key (корневой ключ) — защищает ключ шифрования
• Unseal key (ключ распечатки) — защищает root key

По умолчанию Vault применяет алгоритм Шамира (Shamir’s Secret Sharing): unseal key разбивается на несколько частей (shares). Для распечатки нужно собрать пороговое количество частей (threshold) — например, 3 из 5. Идея в том, что ни один человек не владеет полным ключом.

Зачем это пентестеру: если unseal-ключи утекли — вы распечатываете Vault и читаете все секреты. По данным Verizon DBIR 2025, 38% утечек связаны с кражей учётных данных. Vault создан для защиты этих данных, но если его собственные ключи скомпрометированы — вся криптография бесполезна.

GitGuardian выделяет три последствия утечки unseal key: полный доступ ко всем секретам хранилища, утечка данных и компрометация всей системы управления секретами. IBM X-Force Threat Intelligence Index 2025 фиксирует рост атак с использованием действительных учётных данных на 71% год к году — сценарий «достал ключ из метрик, зашёл как легитимный пользователь» укладывается в этот тренд.

Альтернатива ручному unseal — auto-unseal через облачный KMS (Key Management Service — сервис управления ключами у облачного провайдера: AWS KMS, GCP Cloud KMS, Azure Key Vault). При auto-unseal Vault при старте обращается к облачному сервису для расшифровки root key, и unseal-ключи Шамира не используются. Вместо них генерируются recovery keys, которые нужны только для авторизации административных операций, но не для распечатки. Это существенно сужает поверхность атаки — unseal-ключи просто не существуют в открытом виде.

HashiCorp Vault metrics endpoint: уязвимость раскрытия данных

Vault умеет отдавать телеметрию в формате Prometheus (система мониторинга, собирающая метрики по HTTP) через эндпоинт /v1/sys/metrics. Нужно для мониторинга: сколько запросов обрабатывает Vault, время отклика, количество созданных токенов.

По документации Honeycomb, метрики не включены по умолчанию. Для активации нужно:

• Установить параметр prometheus_retention_time в конфигурации Vault (минимум — удвоенный интервал скрейпинга сборщика метрик)
• Создать ACL-политику (Access Control List — список разрешений) read-metrics с правами на чтение /sys/metrics
• Сгенерировать отдельный токен для сборщика метрик

В штатной конфигурации эндпоинт /sys/metrics требует аутентификации — без валидного токена получите ошибку 403. Проблема возникает, когда:

• Токен метрик утёк (попал в конфиг-файл, доступный через веб)
• Эндпоинт проксируется через reverse proxy без проверки авторизации
• Метрики содержат чувствительные данные: информацию об unseal-операциях, внутренние токены, пути к секретам

Именно такую мисконфигурацию эксплуатирует сценарий Skyfall. По классификации OWASP это попадает под A02:2021 — Cryptographic Failures (утечка криптографических ключей) и A09:2021 — Security Logging and Monitoring Failures (эндпоинт мониторинга, созданный для защиты, сам становится вектором атаки). С точки зрения API-безопасности — классический OWASP API2:2023 Broken Authentication: эндпоинт, который должен быть закрыт, доступен без авторизации.

HTB Skyfall прохождение: пошаговый разбор

Требования к окружению

• ОС: Kali Linux 2024.x или Parrot OS (дистрибутив с предустановленными инструментами пентеста)
• RAM: минимум 4 ГБ (Kali в VM + SSH-сессия)
• Инструменты: nmap, curl, vault CLI (клиент HashiCorp Vault для взаимодействия с API; установка: apt install vault или бинарь с releases.hashicorp.com)
• Сеть: VPN-подключение к HTB через OpenVPN или WireGuard
• Доступ: аккаунт HackTheBox (машина Skyfall — уровень Insane, доступна по подписке VIP)

Разведка и обнаружение Vault

Начинаем со стандартного сканирования портов: nmap -sC -sV <target_ip>. Флаг -sC запускает дефолтные NSE-скрипты (Nmap Scripting Engine — встроенные скрипты для автоматического обнаружения уязвимостей), -sV определяет версии сервисов. Среди открытых портов обнаруживается веб-приложение.

Дальше — ручной анализ. При перечислении директорий и API-эндпоинтов веб-приложения находится путь, ведущий к метрикам Vault. Ключевой индикатор: ответ сервера содержит строки в формате Prometheus — метрики с именами вроде vault_core_unsealed, vault_token_count, vault_secret_kv_count. Если видите такой вывод вместо ошибки 403 — эндпоинт раскрыт, и можно двигаться дальше.

Предусловия для этого шага: — Работает если: веб-приложение проксирует запросы к Vault без ACL-проверки, или токен метрик доступен через смежный сервис — Не работает если: Vault находится в изолированной сети без доступа через веб-интерфейс, метрики не включены (prometheus_retention_time не задан)

Извлечение Vault unseal token через раскрытый метрик-эндпоинт

Анализируя вывод метрик, ищем данные, связанные с аутентификацией и unseal-процессом. В сценарии Skyfall из раскрытого эндпоинта извлекаются данные, позволяющие аутентифицироваться в Vault API.

Получив токен доступа, проверяем, что с ним можно делать. Для этого используем vault CLI (последнее стабильное обновление: Vault 1.17.x, статус: активно поддерживается, HashiCorp):

export VAULT_ADDR='http://<target>:8200'
export VAULT_TOKEN='<extracted_token>'
vault secrets list
vault kv get <path>/<secret_name>

Первая строка задаёт адрес Vault-сервера. Вторая — устанавливает токен аутентификации. vault secrets list выведет доступные хранилища секретов (secret engines). Ожидаемый результат — таблица с путями (secret/, ssh/, kv/) и типами. Видите список — токен валиден и имеет права на чтение. vault kv get читает конкретный секрет по пути. Среди секретов обнаруживаются SSH-учётные данные.

Предусловия: — Работает если: извлечённый токен имеет достаточные права (policy) для чтения секретов, Vault в unsealed-состоянии — Не работает если: токен имеет права только на метрики (минимальная ACL-политика), Vault sealed или используется auto-unseal через внешний KMS (unseal-ключи не проходят через Vault в открытом виде)

Побег из namespace Linux: повышение привилегий через sudo nsenter

SSH-доступ получен, но мы работаем от обычного пользователя. Для root нужен ещё один шаг.

Linux namespaces — механизм изоляции ресурсов ядра. Каждый namespace создаёт «пузырь», внутри которого процессы видят только свои ресурсы: свою файловую систему (mount namespace), свои процессы (PID namespace), свою сеть (network namespace). Docker, LXC и Kubernetes используют namespaces как фундамент контейнеризации.

nsenter — утилита для «входа» в существующий namespace другого процесса. Если у пользователя есть sudo-право на nsenter без ограничений на аргументы — это прямой путь к root. Без вариантов.

Проверяем sudo-права: sudo -l. Если в выводе есть строка, разрешающая nsenter (особенно с NOPASSWD), дальше всё тривиально:

sudo nsenter -t 1 -m -u -i -n -p -- /bin/bash

Что делает каждый флаг — каждый отвечает за вход в конкретный namespace процесса с PID 1 (init/systemd хоста): -t 1 — целевой процесс; -m — mount namespace (файловая система хоста); -u — UTS namespace (hostname); -i — IPC namespace (межпроцессное взаимодействие); -n — network namespace (сетевой стек хоста); -p — PID namespace (процессы хоста). -- /bin/bash запускает оболочку внутри этих namespaces.

Ожидаемый результат: приглашение меняется на root@<hostname>#. Команда id подтвердит uid=0(root). Файл root.txt доступен для чтения — машина захвачена.

Предусловия: — Работает если: sudo-правило на nsenter без ограничений на аргументы (NOPASSWD или с известным паролем), процесс PID 1 доступен, нет SELinux/AppArmor в enforcing mode — Не работает если: sudo-правило ограничивает аргументы nsenter (whitelist конкретных PID), SELinux в enforcing mode блокирует setns() (системный вызов переключения namespace), среда не контейнерная (все процессы уже в одном namespace, nsenter не даёт эскалации)

Ограничения техники и детекция

Обе техники имеют чёткие границы применимости — и это нужно понимать, чтобы не тратить время на мёртвые ветки в реальном проекте.

HashiCorp Vault metrics endpoint exploitation:

nsenter privilege escalation:

Что сделать для защиты (чеклист для администратора):

1. Не включать prometheus_retention_time, если метрики не нужны — по умолчанию они отключены
2. Создать минимальную ACL-политику для токена метрик: только read на /sys/metrics, TTL токена — не более 24 часов
3. Не проксировать /sys/metrics через публичный reverse proxy; ограничить доступ по IP мониторинг-серверов
4. Перейти на auto-unseal через KMS или Transit secrets engine — это убирает unseal-ключи Шамира из ручного оборота
5. Аудит sudo-правил на утилиты переключения контекста: nsenter, unshare, chroot, docker exec, kubectl exec — каждая из них позволяет эскалацию при неограниченном sudo
6. Ротация unseal-ключей командой vault operator rekey при подозрении на утечку; рассмотреть увеличение threshold
7. Мониторинг вызовов nsenter и системного вызова setns через auditd

Vault — система, спроектированная для защиты секретов. Но вся криптография Шамира и многоуровневое шифрование бессильны, если вспомогательный эндпоинт мониторинга раскрывает данные, которые не должен показывать. И это не уникальная история Skyfall — это паттерн. Компании вкладываются в шифрование data at rest и in transit, но забывают про data in monitoring. Метрик-эндпоинты, debug-интерфейсы, health-чеки — «вспомогательная» инфраструктура, которая остаётся без аутентификации, потому что «это же внутренний сервис». По данным IBM X-Force 2025, ежедневно в даркнете появляется более 6000 свежих учётных записей — часть из них попадает туда именно через такие второстепенные каналы, о которых никто не думает.

Что касается nsenter — это не баг и не уязвимость, это штатная утилита ядра. Проблема не в инструменте, а в том, что sudo-правило написано без ограничений на аргументы. Одна строчка в sudoers, которую написали «для удобства отладки контейнеров», — и пользователь получает полный root. Та же история с docker exec и kubectl exec: если даёте пользователю неограниченный доступ к инструменту управления границами изоляции — фактически даёте root. Механизм прост, но мало кто ревьюит sudoers с этой точки зрения, пока не случится инцидент. Если такие разборы пока вызывают больше вопросов, чем ответов, и хочется пройти базу от сетей до первых практических задач структурированно — на codeby.school есть IB Basics, трек для тех, кому нужна система вместо хаотичного ковыряния в writeups.