Hacker News Digest

Cisco AI Defense представила mcp-scanner - инструмент для сканирования серверов Model Context Protocol (MCP) на наличие уязвимостей. Проект открыт на GitHub, что позволяет разработчикам использовать и улучшать сканер для защиты MCP-инфраструктуры.

MCP - протокол для взаимодействия с языковыми моделями, который становится все более популярным. Безопасность таких серверов критически важна, так как они могут содержать чувствительные данные или предоставлять доступ к важным функциям. Инструмент от Cisco помогает выявлять потенциальные брезы в безопасности до того, как они будут использованы злоумышленниками.

• Организация, упомянутая в обсуждении, обвиняется в попытке внедрить вредоносный код в npm-пакеты, что вызвало обеспокоенность сообщества.
• Участники обсуждали безопасность MCP-серверов и их влияние на безопасность данных пользователей.
• Обсуждались трудности аутентификации и авторизации в MCP-экосистеме, включая отсутствие стандартизированных решений.
• Участники также обсуждали, что MCP-спецификация всё ещё находится в стадии активной разработки, что вызывает вопросы о стабильности и готовности к использованию в продакшене.
• Были высказаны опасения по поводу того, что MCP в его текущем виде может не подходить для использования в корпоративных условиях.

Как работает OAuth
Вместо передачи логина-пароля стороннему приложению OAuth выдаёт токен доступа — персональный «ключ» для конкретного пользователя. Приложение использует его, чтобы действовать от имени пользователя без доступа к его паролю.

Классический поток

1. Пользователь нажимает «Подключить банк» в YNAB.
2. YNAB открывает браузер с URL провайдера (например, банка), куда добавляет client_id, redirect_uri, scope и случайный state.
3. Пользователь логинится у провайдера и разрешает доступ.
4. Провайдер перенаправляет обратно в YNAB с кодом авторизации.
5. YNAB обменивает код на токен доступа через безопасный back-end-запрос.
6. С токеном YNAB запрашивает данные счёта.

PKCE
Для мобильных и SPA добавляют code_challenge и code_verifier, чтобы перехват кода не дал злоумышленнику токен.

Refresh-токены
Короткоживущий access token можно обновлять долгоживущим refresh token без повторного логина.

Итог
OAuth разделяет аутентификацию и авторизацию: пользователь доверяет провайдеру, провайдер — приложению, приложение получает минимально необходимые права.

• Участники жалуются, что OAuth/OIDC кажутся простыми, но реальная реализация требует чтения спецификаций и RFC, а поверхностных гайдов мало.
• Несколько человек подтвердили: приходится самим собирать знания из RFC, OIDC-документов и собственных заметок.
• Упомянуты полезные ресурсы — гайд Alex Bilbie, книга Aaron Parecki, страницы Mozilla и RFC-примеры.
• PKCE считается не «менее безопасным», а способом защитить целостность потока; просят отдельный материал о нём.
• Критика стандарта: OAuth 2.0 «скелет протокола», с множеством опциональных частей и историческими уязвимостями.

Model Context Protocol (MCP) стал стандартом для вызова инструментов при создании агентов, но сам LLM не обязан «понимать» MCP. При «инжиниринге контекста» вы даете модели нужные данные и доступ к инструментам; стандарт MCP лишь унифицирует подключение к ним. Для модели это просто список определений инструментов — она не знает о реализации, и это нормально.

MCP дает доступ к тысячам инструментов без кастомных интеграций и упрощает агентный цикл: разработчик вызывает инструменты, а LLM лишь генерирует текстовый фрагмент с именем инструмента и параметрами. LLM не «умеет» вызывать функции — он предсказывает текст, который ваша система парсит, выполняет реальный вызов и возвращает результат как новое сообщение.

Пример: при наличии инструмента get_weather(location) на вопрос «Какая погода в Сан-Хосе?» модель может сгенерировать: { "name": "get_weather", "input": { "location": "San Jose, CA" } } Агент выполняет этот вызов и передает ответ обратно модели. Разделение обязанностей: LLM предсказывает, система исполняет.

MCP стандартизирует подключение к источникам (инструменты, подсказки, ресурсы, примеры) через хост-приложение с MCP-клиентом и сервера MCP, которые экспонируют инструменты. Взаимодействие с LLM не меняется — меняется способ, как инструменты подаются и вызываются «под капотом». Для того же вопроса модель увидит тот же список инструментов; решение, как именно вызвать, остается за разработчиком (с MCP — через MCP).

Преимущества MCP — для разработчика: управление ростом числа инструментов, переиспользование, единые форматы, быстрые подключения к новым системам без переписывания кода. LLM не узнает о MCP, если вы сами не укажете это в системном промпте; его роль — сгенерировать фрагмент вызова, а ваша — выполнить его.

• Участники сомневаются в необходимости MCP: если чат-боты не станут главным интерфейсом, спецификация может оказаться ненужной.
• Критика сосредоточена на локальной модели «скачай-и-запусти MCP» — её считают избыточной; крупным компаниям достаточно удалённого MCP или прямых REST-вызовов.
• Большое количество доступных инструментов снижает точность агентов; лучше строго ограничить набор и активно подсказывать, как их использовать.
• MCP воспринимается как поспешный стандарт от Anthropic, слабо продуманный в части безопасности и авторизации.
• Некоторые видят перспективу в «USB-аналогии»: MCP может стать универсальным способом подключения систем друг к другу, выходя за рамки LLM.

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

Секрет-хранилища — опора цифровой инфраструктуры: в них лежат креденшелы, токены и сертификаты, управляющие доступом к системам, сервисам, 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-шным» из-за многословности, но информативности это не мешает.