Forwarded from Евгений Кокуйкин - Raft
Новый инцидент, связанный с утечкой данных из AI-ассистента консалтинговой компании McKinsey. Исследователи из CodeWall во время red teaming-упражнений протестировали чат-бота для сотрудников и консультантов компании, который имел доступ к данным клиентов и другим конфиденциальным перепискам.
Агент-хакер CodeWall обнаружил незащищенные API-эндпоинты приложения и подобрал SQL-инъекцию, которая дала доступ к продакшен базе данных. Случай для безопасности веб-приложений довольно обычный, но есть и интересные особенности.
Далее исследователи обнаружили, что система хранит системные инструкции в той же самой базе данных. Поменяв промпты в БД, они тем самым убрали guardrails и смогли вытащить дополнительные данные из RAG-системы. Не стоит хранить системные инструкции в той же базе данных, которая подключена к вашим открытым API :)
Тестирование прошло в конце февраля, 1 марта команда McKinsey получила уведомление, и уже на следующий день уязвимости были закрыты. С момента атаки до публичного релиза статьи прошло меньше недели, что, конечно, поразительно. Молодцы и в McKinsey, и в CodeWall.
Агент-хакер CodeWall обнаружил незащищенные API-эндпоинты приложения и подобрал SQL-инъекцию, которая дала доступ к продакшен базе данных. Случай для безопасности веб-приложений довольно обычный, но есть и интересные особенности.
Далее исследователи обнаружили, что система хранит системные инструкции в той же самой базе данных. Поменяв промпты в БД, они тем самым убрали guardrails и смогли вытащить дополнительные данные из RAG-системы. Не стоит хранить системные инструкции в той же базе данных, которая подключена к вашим открытым API :)
Тестирование прошло в конце февраля, 1 марта команда McKinsey получила уведомление, и уже на следующий день уязвимости были закрыты. С момента атаки до публичного релиза статьи прошло меньше недели, что, конечно, поразительно. Молодцы и в McKinsey, и в CodeWall.
codewall.ai
How We Hacked McKinsey's AI Platform
An autonomous AI agent found a SQL injection in McKinsey's Lilli AI platform. What it extracted was worse than we expected.
🔥1
Forwarded from SecAtor
Pillar Security сообщает о двух критических уязвимостях в n8n, которые могуь быть использованы для RCE и выхода из песочницы, что потенциально приведет к раскрытию всех учетных данных, хранящихся в базе данных n8n.
Первая ошибка, CVE-2026-27493 (CVSS 9,5), описывается как проблема внедрения выражений второго порядка, затрагивающая узлы Form платформы автоматизации рабочих процессов с открытым исходным кодом.
Успешная эксплуатация уязвимости позволяет неавторизованному злоумышленнику внедрить произвольные команды в поле Name и получить результат выполнения команды.
Уязвимость связана с ем, что n8n использовал два прохода оценки выражений для анализа пользовательского запроса, при этом полезная нагрузка злоумышленника оценивалась как новое выражение во время второго прохода.
По данным Pillar Security, эта уязвимость может быть связана со второй критической проблемой, которая отслеживается как CVE-2026-27577 (CVSS 9,4) и позволяет выйти за пределы песочницы n8n для выполнения команд на хосте.
Уязвимость обусловлена тем, что уязвимый узел работает на этапе компиляции, до запуска средств проверки работоспособности во время выполнения.
Обе уязвимости были устранены в конце февраля в n8n 2.10.1, 2.9.3 и 1.123.22.
Патч позволил устранить второй проход оценки выражений и некоторые ранее принятые параметры, включил несколько глобальных идентификаторов в список заблокированных идентификаторов песочницы и усилил анализ идентификаторов с учетом AST.
Обе проблемы затрагивали как локальные, так и облачные развертывания и могли быть использованы для извлечения всех учетных данных из баз данных n8n, включая ключи AWS, пароли, токены OAuth и ключи API.
Как отмечают в Pillar, по своей функции n8n - это хранилище учетных данных, где также располагаются ключи от каждой системы, к которой подключается. Единый выход из песочницы фактически открывает доступ к экземпляру n8n и каждой подключенной системе.
Поскольку конечные точки форм предназначены для доступа из интернета, CVE-2026-27493 может быть использована любым пользователем, отправившим всего одну форму и выполнившим GET-запрос.
В случае развертывания n8n Cloud и многопользовательских систем последствия выходят за рамки отдельного экземпляра.
Обход песочницы в n8n Cloud предоставляет доступ к общей инфраструктуре, создавая риск для разных пользователей: одна общедоступная форма в рабочем процессе одного пользователя может служить точкой входа.
Первая ошибка, CVE-2026-27493 (CVSS 9,5), описывается как проблема внедрения выражений второго порядка, затрагивающая узлы Form платформы автоматизации рабочих процессов с открытым исходным кодом.
Успешная эксплуатация уязвимости позволяет неавторизованному злоумышленнику внедрить произвольные команды в поле Name и получить результат выполнения команды.
Уязвимость связана с ем, что n8n использовал два прохода оценки выражений для анализа пользовательского запроса, при этом полезная нагрузка злоумышленника оценивалась как новое выражение во время второго прохода.
По данным Pillar Security, эта уязвимость может быть связана со второй критической проблемой, которая отслеживается как CVE-2026-27577 (CVSS 9,4) и позволяет выйти за пределы песочницы n8n для выполнения команд на хосте.
Уязвимость обусловлена тем, что уязвимый узел работает на этапе компиляции, до запуска средств проверки работоспособности во время выполнения.
Обе уязвимости были устранены в конце февраля в n8n 2.10.1, 2.9.3 и 1.123.22.
Патч позволил устранить второй проход оценки выражений и некоторые ранее принятые параметры, включил несколько глобальных идентификаторов в список заблокированных идентификаторов песочницы и усилил анализ идентификаторов с учетом AST.
Обе проблемы затрагивали как локальные, так и облачные развертывания и могли быть использованы для извлечения всех учетных данных из баз данных n8n, включая ключи AWS, пароли, токены OAuth и ключи API.
Как отмечают в Pillar, по своей функции n8n - это хранилище учетных данных, где также располагаются ключи от каждой системы, к которой подключается. Единый выход из песочницы фактически открывает доступ к экземпляру n8n и каждой подключенной системе.
Поскольку конечные точки форм предназначены для доступа из интернета, CVE-2026-27493 может быть использована любым пользователем, отправившим всего одну форму и выполнившим GET-запрос.
В случае развертывания n8n Cloud и многопользовательских систем последствия выходят за рамки отдельного экземпляра.
Обход песочницы в n8n Cloud предоставляет доступ к общей инфраструктуре, создавая риск для разных пользователей: одна общедоступная форма в рабочем процессе одного пользователя может служить точкой входа.
www.pillar.security
Zero Click Unauthenticated RCE in n8n: A Contact Form That Executes Shell Commands
Надеюсь, на этот временный ГОСТ 1046-2026 не будут ссылаться в письмах и нормативке органов власти как меры для исполнения. Все таки он слишком общий.
Документ оперирует терминами ИИ и системы ИИ, но не дает их определений.
В документе учтен международный опыт со ссылкой на ISO 23894:2023 Information technology — Artificial intelligence — Guidance on risk management
Документ оперирует терминами ИИ и системы ИИ, но не дает их определений.
В документе учтен международный опыт со ссылкой на ISO 23894:2023 Information technology — Artificial intelligence — Guidance on risk management
Forwarded from AI SecOps
ПНСТ 1046-2026. "Искусственный интеллект в критической информационной инфраструктуре. Общие положения" https://protect.gost.ru/document1.aspx?control=31&baseC=6&page=1&month=3&year=2026&search=&id=271479
Инициатива от SANS - доработать существушие подходы форенщики и реагирования на инциденты до протокола с поддержкой использования ИИ - SANS Investigative Forensic Toolkit (SIFT).
Проект на ранней стадии.
Ждем пока деталей - обещаны механизмы жесткого контроля над действиями ИИ.
https://www.sans.org/blog/protocol-sift-experimental-research-initiative-ai-assisted-dfir
Проект на ранней стадии.
Ждем пока деталей - обещаны механизмы жесткого контроля над действиями ИИ.
https://www.sans.org/blog/protocol-sift-experimental-research-initiative-ai-assisted-dfir
SANS Institute
Protocol SIFT: An Experimental Research Initiative for AI-Assisted DFIR
Artificial intelligence (AI) is reshaping the cyber threat landscape at an unprecedented pace. Adversaries are weaponizing AI to automate reconnaissance, scale social engineering, and accelerate offensive operations. It is dramatically increasing the complexity…
В 146 релизе Chrome появился Sanitizer API. Этот механизм позволяет реализовать защиту пользователя от XSS.
https://developer.chrome.com/release-notes/146#sanitizer_api
Вот детальное описание концепции https://developer.mozilla.org/en-US/docs/Web/API/HTML_Sanitizer_API
Есть поддержка у Firefox.
Ждем аналогичного от Safari и Edge.
https://developer.chrome.com/release-notes/146#sanitizer_api
Вот детальное описание концепции https://developer.mozilla.org/en-US/docs/Web/API/HTML_Sanitizer_API
Есть поддержка у Firefox.
Ждем аналогичного от Safari и Edge.
Chrome for Developers
Chrome 146 | Release notes | Chrome for Developers
Scroll-triggered animations, Scoped custom element registries, and more.
Forwarded from Альфа-Будущее
Безопасность технологий искусственного интеллекта (MLSecOps) появляется
Это новое направление на стыке машинного обучения и информационной безопасности. Уже развиваем его в Альфе и готовы делиться новым опытом.1️⃣ неделя — лекционная: этика и безопасность в ИИ, тестирование и работа с угрозами.2️⃣ неделя — проектная: командная работа над реальными кейсами.
Записывайся — отбор начинается
@alfafuture
Please open Telegram to view this post
VIEW IN TELEGRAM
Второе китайское предупреждение.
Китайский регулятор выпустил второе предупреждение против использования OpenClaw
Проблема в предоставлении избыточных полномочий на фоне уязвивимостей от промтинъекций. +высокая цена ошибки, если агент неверно интерпретирует ваш промт, например удалив критичные данные.
https://www.scmp.com/tech/tech-trends/article/3346138/china-issues-second-warning-openclaw-risks-amid-adoption-frenzy
Китайский регулятор выпустил второе предупреждение против использования OpenClaw
Проблема в предоставлении избыточных полномочий на фоне уязвивимостей от промтинъекций. +высокая цена ошибки, если агент неверно интерпретирует ваш промт, например удалив критичные данные.
https://www.scmp.com/tech/tech-trends/article/3346138/china-issues-second-warning-openclaw-risks-amid-adoption-frenzy
South China Morning Post
China issues second warning on OpenClaw risks amid adoption frenzy
Cybersecurity agency cautions that improper installation and use of the AI agent carry severe security and data risks.
https://www.dryrun.security/the-agentic-coding-security-report-pr
Небольшое исследование безопасности кода написанного 3 популярными моделями: Claude, GPT, Gemini.
Ценно в первую очередь общими примерами уязвимостей которые допускают агенты при написании кода. К сожалению примеров кода в исследовании нет.
Для сравнения результативности моделей слишком небольшая выборка - всего 30 запросов на слияние (PR).
p.s. При использовании бенчей необходимо помнить про фундаментальную проблему оценки ИИ - результаты тестов почти не воспроизводятся и сильно зависят от деплоя к деплою.
Небольшое исследование безопасности кода написанного 3 популярными моделями: Claude, GPT, Gemini.
Ценно в первую очередь общими примерами уязвимостей которые допускают агенты при написании кода. К сожалению примеров кода в исследовании нет.
Для сравнения результативности моделей слишком небольшая выборка - всего 30 запросов на слияние (PR).
p.s. При использовании бенчей необходимо помнить про фундаментальную проблему оценки ИИ - результаты тестов почти не воспроизводятся и сильно зависят от деплоя к деплою.
https://www.netscout.com/threatreport/ Отчет NetScout по DDOS за второе полугодие 2025 года.
1.Любопытная статистика по атакам на корневые DNS.
2.ИИ начали использовать для проведения разведки и атак, для облегчения атак используются чат боты.
3. Чуть меньше половины атак использует один вектор атаки (например UDP Flood), до 5 векторов атаки это больше 90% всех атак.
1.Любопытная статистика по атакам на корневые DNS.
2.ИИ начали использовать для проведения разведки и атак, для облегчения атак используются чат боты.
3. Чуть меньше половины атак использует один вектор атаки (например UDP Flood), до 5 векторов атаки это больше 90% всех атак.
https://www.enisa.europa.eu/publications/enisa-technical-advisory-for-secure-use-of-package-managers
Относительно редкая техническая рекомендация по безопасности пакетных менеджеров типа pip\Maven от регулятора ЕС ENISA.
Есть верхнеуровневые рекомендации и рекомендации на уровне конкретных команд из выбранных ENISA источников.
Заметный минус этих рекомендаций, что они очень поверхностно оценили риски для пакетных менеджеров от вайбкодингом.
Относительно редкая техническая рекомендация по безопасности пакетных менеджеров типа pip\Maven от регулятора ЕС ENISA.
Есть верхнеуровневые рекомендации и рекомендации на уровне конкретных команд из выбранных ENISA источников.
Заметный минус этих рекомендаций, что они очень поверхностно оценили риски для пакетных менеджеров от вайбкодингом.
Forwarded from OK ML
ML supply chain - реальная поверхность атаки. Конкретные примеры, почему это не теория (начало тут)
Hugging Face прямо предупреждает, что pickle при десериализации исполняет последовательность opcode-инструкций; именно поэтому они поддерживают pickle-scanning. В качестве более безопасного формата Hugging Face продвигает safetensors, который позиционируется как безопасная альтернатива pickle для хранения тензоров.
HiddenLayer показали, что через вредоносный PyTorch binary можно было компрометировать сервис конвертации Hugging Face Safetensors, украсть токен официального conversion bot, отправлять PR от имени бота и автоматически угонять модели, проходящие через сервис. Это очень показательный AI supply chain кейс! Атакуется не только модель, но и доверенный сервис вокруг нее.
Microsoft описывает сценарии, где вредоносные инструкции попадают в систему не через прямой пользовательский prompt, а через данные, которые агент читает, или через metadata инструментов. Это особенно опасно для MCP и multi-tool систем, где агент принимает решения на основе внешнего контекста.
The Hacker News 11 марта 2026 года описали кампанию с пятью вредоносными Rust crates, которые крали .env-секреты, а также атаку AI-бота на GitHub Actions/CI/CD. Это не ML-артефакты как таковые, но механизм тот же. Доверие к артефакту или автоматизации внутри build pipeline превращается в канал эксфильтрации токенов и захвата даунстрим-систем.
Почему это особенно важно для AI agents
Здесь сходятся сразу несколько рисков:
🥹 The Agency Gap - model-level guardrails не контролируют действия агента с доступом к тулам;
🥹 Indirect Prompt Injection - агент можно скомпрометировать через документ, веб-страницу, tool metadata, retrieval-данные;
🥹 Privilege Escalation in AI , если у агента есть доступ к API, файлам, CI/CD secret store или shared credentials, ошибка быстро становится инцидентом;
🥹 Multi-Agent Risk - один зараженный артефакт или poisoned context может каскадно распространяться по связанным агентам и оркестраторам.
Что делать на практике (коротко)😺
1. Подписывать модели и датасеты. Базовый минимум - публиковать и проверять криптографические хеши. Роскошный максимум - цифровые подписи и твои предложения в комментариях.
2. Проверять артефакты в CI/CD до использования, а не после.
3. Снижать риск unsafe model formats. Используете пикл? Тогда я иду к вам …
4. Изолировать агентные права.
5. Считать внешние данные недоверенными по умолчанию.
6. Защищать не только артефакты, но и уровень вызова инструментов
Таким образом, важно не смешивать два уровня защиты.
С одной стороны, нужно защищать ML supply chain (модели, веса, датасеты, provenance, подписи и целостность артефактов). С другой, нужно отдельно защищать agent/tool execution layer (MCP-серверы, tool endpoints, session security, права агентов, валидацию входов и контроль вызовов).
И если для первой задачи нам нужны cryptographic signatures, hash verification и attestation, то для второй - уже практики из мира MCP security. Хороший ориентир здесь - MCP Security Checklist от Helixar - это community-maintained baseline для команд, которые строят и разворачивают MCP-серверы и AI agent infrastructure.
Пока организация не контролирует происхождение моделей, датасетов и доступы агентов к инструментам, любой ML-пайплайн остается зоной повышенного риска. Без integrity checks, provenance и least privilege AI ускоряет не только процессы, но и потенциальный ущерб.
Пост вдохновлен анонсом вебинара!
Все
☕️
Что-то не пойму, как убрать все эти английские словечки из речи...
Hugging Face прямо предупреждает, что pickle при десериализации исполняет последовательность opcode-инструкций; именно поэтому они поддерживают pickle-scanning. В качестве более безопасного формата Hugging Face продвигает safetensors, который позиционируется как безопасная альтернатива pickle для хранения тензоров.
HiddenLayer показали, что через вредоносный PyTorch binary можно было компрометировать сервис конвертации Hugging Face Safetensors, украсть токен официального conversion bot, отправлять PR от имени бота и автоматически угонять модели, проходящие через сервис. Это очень показательный AI supply chain кейс! Атакуется не только модель, но и доверенный сервис вокруг нее.
Microsoft описывает сценарии, где вредоносные инструкции попадают в систему не через прямой пользовательский prompt, а через данные, которые агент читает, или через metadata инструментов. Это особенно опасно для MCP и multi-tool систем, где агент принимает решения на основе внешнего контекста.
The Hacker News 11 марта 2026 года описали кампанию с пятью вредоносными Rust crates, которые крали .env-секреты, а также атаку AI-бота на GitHub Actions/CI/CD. Это не ML-артефакты как таковые, но механизм тот же. Доверие к артефакту или автоматизации внутри build pipeline превращается в канал эксфильтрации токенов и захвата даунстрим-систем.
Почему это особенно важно для AI agents
Здесь сходятся сразу несколько рисков:
🥹 The Agency Gap - model-level guardrails не контролируют действия агента с доступом к тулам;
🥹 Indirect Prompt Injection - агент можно скомпрометировать через документ, веб-страницу, tool metadata, retrieval-данные;
🥹 Privilege Escalation in AI , если у агента есть доступ к API, файлам, CI/CD secret store или shared credentials, ошибка быстро становится инцидентом;
🥹 Multi-Agent Risk - один зараженный артефакт или poisoned context может каскадно распространяться по связанным агентам и оркестраторам.
Что делать на практике (коротко)
1. Подписывать модели и датасеты. Базовый минимум - публиковать и проверять криптографические хеши. Роскошный максимум - цифровые подписи и твои предложения в комментариях.
2. Проверять артефакты в CI/CD до использования, а не после.
3. Снижать риск unsafe model formats. Используете пикл? Тогда я иду к вам …
4. Изолировать агентные права.
5. Считать внешние данные недоверенными по умолчанию.
6. Защищать не только артефакты, но и уровень вызова инструментов
Таким образом, важно не смешивать два уровня защиты.
С одной стороны, нужно защищать ML supply chain (модели, веса, датасеты, provenance, подписи и целостность артефактов). С другой, нужно отдельно защищать agent/tool execution layer (MCP-серверы, tool endpoints, session security, права агентов, валидацию входов и контроль вызовов).
И если для первой задачи нам нужны cryptographic signatures, hash verification и attestation, то для второй - уже практики из мира MCP security. Хороший ориентир здесь - MCP Security Checklist от Helixar - это community-maintained baseline для команд, которые строят и разворачивают MCP-серверы и AI agent infrastructure.
Пока организация не контролирует происхождение моделей, датасетов и доступы агентов к инструментам, любой ML-пайплайн остается зоной повышенного риска. Без integrity checks, provenance и least privilege AI ускоряет не только процессы, но и потенциальный ущерб.
Пост вдохновлен анонсом вебинара!
Все
Что-то не пойму, как убрать все эти английские словечки из речи...
Please open Telegram to view this post
VIEW IN TELEGRAM