Hacker News Digest

• aka.ms — коротилка Microsoft. Попытка зайти на https://aka.ms привела к логину только для сотрудников.
• akasearch.net — индекс ссылок aka.ms; нашёлся eng.ms.
• eng.ms — домен с приложением EngineeringHub. При входе через личный M365-аккаунт появился consent-запрос на доступ к профилю. После подтверждения — 500-я ошибка, но OAuth-токен уже выдан.
• rescue.eng.ms — поддомен, где после аналогичного согласия открылся Engineering Hub Rescue: список 22 внутренних сервисов Microsoft (Cloud + AI, Gaming, Finance и др.) с полным доступом через обычный аккаунт.

Итог: публичные OAuth-приложения Microsoft внутри корпоративных тенантов могут выдавать токены сторонним пользователям, если не ограничены политикой согласия. Проверьте свои тенанты на наличие подобных приложений и настройте Admin consent workflow, чтобы избежать утечек.

• Документация Microsoft по Entra ID/SSO вызывает у разработчиков «тыкание в темноте» и ошибки конфигурации.
• Уязвимости в мультитенантных приложениях возникают из-за непроверенных полей токена (iss, tid, audience) и отсутствия фильтрации по тенантам.
• Даже внутренние сервисы Microsoft открыты в интернет из-за политики Zero Trust, что увеличивает поверхность атаки.
• Исследователь получил RCE на сборочных серверах Windows, но Microsoft не выплатила ни цента, вызвав критику программы bug bounty.
• Сообщество советует: не полагаться на Entra для авторизации, всегда валидировать каждое поле токена и строить defense-in-depth.

Введение: когда модель доверия подводит

Секрет-хранилища — опора цифровой инфраструктуры: в них лежат креденшелы, токены и сертификаты, управляющие доступом к системам, сервисам, API и данным. Это не просто часть модели доверия — это и есть модель доверия. Если хранилище взломано, инфраструктура уже потеряна.

Понимая, что такие хранилища — цели высокой ценности, команда Cyata провела углубленную оценку HashiCorp Vault — одного из самых популярных решений.

За несколько недель мы выявили девять ранее неизвестных уязвимостей нулевого дня, каждой присвоен CVE через ответственное раскрытие. Совместно с HashiCorp все проблемы были исправлены до публикации.

Обнаруженные изъяны обходят блокировки, политики и позволяют выдавать себя за других. Одна уязвимость ведет к повышению привилегий до root, другая — к первому публичному RCE в Vault, дающему полный захват системы.

Мы увидели цепочки логических ошибок, которые по отдельности и в комбинации создают опасные пути атаки — особенно в реальных внедрениях с мисконфигами или избыточными правами.

Это не были ошибки памяти или гонки, а скрытые логические баги в слоях аутентификации, идентичности и политик Vault. Некоторые существовали почти десятилетие — незаметные, но легко эксплуатируемые после понимания.

Предыдущие исследования (например, Google Project Zero, 2020) касались обходов в IAM-бэкендах облаков (AWS, GCP). Мы нацелились на базовые потоки аутентификации Vault, затрагивающие OSS и Enterprise-версии по разным провайдерам.

Далее — что мы нашли, как нашли и что это значит для инфраструктуры, которую должен защищать Vault.

Что такое HashiCorp Vault?

Vault — открытый инструмент для защиты, хранения и контроля доступа к секретам: API-ключам, паролям БД, сертификатам, ключам шифрования.

Его используют компании разных масштабов: он централизует управление секретами и применяет детальные политики в распределенных системах.

По сути — это граница безопасности: аутентифицирует людей и машины, посредничает доступу к чувствительным данным.

В DevSecOps Vault снижает риски хардкода секретов, расползания и несанкционированного доступа. Его ценят за гибкую интеграцию, точные политики и пригодность для сложных сред. Часто это последний сторож секретов: при определенных настройках компрометация Vault равна компрометации всего.

Основные возможности Vault

• Управление секретами и крипто-движок для динамичных мульти-/гибрид-облаков
• Централизованное хранилище с доступом по API
• Динамическая выдача учетных данных с автоистечением
• Идентификационно-ориентированный доступ для людей и машин
• Шифрование как сервис для данных «в покое» и «в пути»
• Управление сертификатами: выпуск, ротация, отзыв
• Распределение, включение/отключение и ротация ключей шифрования

Методология: как мы нашли то, что другие пропустили

Это целенаправленное исследование логических уязвимостей Vault — тех, что не видны в сканерах памяти и логах падений, но подтачивают модель доверия.

Мы исходили из гипотезы: если Vault — якорь доверия, то малые несогласованности в идентичности, аутентификации или политике могут иметь непропорционально большие последствия.

Фокус — базовый поток обработки запросов, особенно файл request_handling.go, «мозг» Vault: маршрутизация, разрешение идентичностей, принятие политик. Неделями изучали логику функций и модулей, отслеживая крайние случаи размывания границ доверия.

Не полагались на фаззинг и автопробинг. Проводили глубокий ручной код-ревью, анализируя не только функции, но и интерпретации идентичности/ввода разными компонентами. Увидев несоответствия в регистре, алиасинге, форматировании — углублялись.

Каждый тест — целевая проверка, основанная на коде. Мы думали как атакующие: начиная с минимальных прав, спрашивали «насколько далеко можно продвинуться отсюда?» И повторяли этот цикл, замечая мелкие несоответствия и прослеживая их последствия.

• Исследователи из Cyata (Vault Fault) вручную обнаружили 9 CVE в Vault, включая цепочку до RCE; отчёт писали люди, но с редактором.
• Ключевая причина уязвимостей — «полезная» нормализация строк: преобразования регистра/UTF в auth-плагинах дают bypass, перечисление имён и привилегии.
• OpenBao подтвердил 8 из 9 CVE; жалуются, что HashiCorp не предупредил заранее, и приглашают к сотрудничеству.
• Некоторые участники считают код Vault «бардаком» и тесты слабыми; другие спорят, что такие логические ошибки встречаются везде.
• Обсуждение стиля: текст кажется «AI-шным» из-за многословности, но информативности это не мешает.