Telegram Web
В конце мая исследователи из ReversingLabs обнаружили атаку на цепочку поставок, распространяющуюся на разработчиков, которые использовали Alibaba AI Labs.

Злоумышленники загрузили в PyPI три вредоносных пакета, маскирующихся под официальные SDK для взаимодействия с сервисами Alibaba Cloud AI Labs:

1.aliyun-ai-labs-snippets-sdk
2.ai-labs-snippets-sdk
3.aliyun-ai-labs-sdk

Пакеты были доступны с 19 мая, в течение 24 часов до обнаружения. И за это время они были загружены примерно 1600 раз. Наибольшее количество загрузок пришлось на пакет ai-labs-snippets-sdk, который был доступен дольше остальных.

Сами по себе пакеты вовсе не содержали функциональности связанной с AI или взаимодействием с серверами Alibaba, а вредоносный код был скрыт в Pickle. Заражение происходило через __init__.py, который загружал вредоносные pickle.

Какая информация отправлялась злоумышленникам при запуске Pickle:

1. Данные о хосте, сетевом адресе машины
2. Название организации
3. Содержимое. gitconfig
4. Также происходила идентификация разработчиков, которые используют инструмент AliMeeting

Собранная информация отправлялась в base64 на сервера злоумышленников.
Please open Telegram to view this post
VIEW IN TELEGRAM
🐳21🤝4🗿3😱1
Forwarded from Борис_ь с ml
Гайд по AI-агентам с мерами митигации угроз кибербезопасности
#иб_для_ml

↗️ https://cdn-app.giga.chat/misc/0.0.0/assets/giga-landing/c02386dc_WP.pdf

Команда Сбера представила новый документ - гайд по практикам разработки AI-агентов. В документе масса кода и архитектурных схем, разбираться можно долго. И я однозначно рекомендую его к ознакомлению.

Но мне, конечно интересна в первую очередь кибербезопасность. И да, такой раздел в этом документе имеется. Внимание на страницы 65-69.

📝Раскрываемые темы и понятия в разделе
▪️описание ключевых с точки зрения ИБ элементов AI-агента
▪️схема этих элементов, изображающая AI-агента как объект защиты, приведен список поверхностей атаки
▪️несколько сценариев реализации угроз (например, каскадное распространение промпт-атаки)
▪️меры обеспечения кибербезопасности AI-агентов - самое интересное, на чем остановимся подробнее

🔒 Как защитить AI-агентов
На странице 69 расписано 12 различных мер.
Начинаем, конечно, с мониторинга. AI-агенты, как мы помним, сами по себе моделями не являются, соответственно ответы пользователям генерить не могут. Поэтому существуют обращения агентов к LLM, при чем как минимум - два. Первое с исходным входным текстом, чтобы сгенерировать запрос на выполнение действия (-й), второе - с результатом выполнения для генерации финального ответа. И это, по-хорошему, все надо логировать. Начиная от id потребителя и, в случае большой корпоративной системы, id фронтальной поверхности, заканчивая id сессии и id актуального коммита в памяти AI-агента на момент совершения события аудита.

Другой хорошей практикой (мерой), особенно в критичных системах, является ограничение формата вывода агентов со свободного естественного языка до набора детерминированных значений. Поможет и утечек избежать, и распространения промпт-атак, и других нежелательных последствий.

Собраны и некоторые общеизвестные, по-моему, вещи, но все-таки стоящие упоминания: проводить redteam-тестирование, ввести максимально жесткий контроль доступа, применять SAST/SCA к генерируемому агентами исполняемому коду, организовать рейтлимиты и прочие контроли надежности против спонж-атак, и несколько других пунктов.

И еще отдельно отмечу простое и при этом мне показавшееся, когда я увидел, неочевидным, правило: отслеживайте наличие в системном промпте любых секретов. Это могут быть ключи, токены, имена баз данных или учеток, словом - всего, что не нужно знать потребителю AI-агента. Потому что нельзя забывать - системный промпт модель обязательно расскажет (ее хлебом не корми - дай системник рассказать), а значит, его инфу можно считать заведомо утекшей.

👀 Итого
Берегите честь безопасность AI-агентов смолоду с ранних этапов проектирования - эта прописная истина работает и тут. И авторы дают конкретные предложения, как именно это делать. Документ отлично дополняет показанную в апреле модель угроз, покрывая агентную ее часть.


🔫 Предлагаю челлендж - будет больше 50 реакций под постом, сделаю свою версию маппинга угроз из МУ Сбера на митигации из данного гайда.
Please open Telegram to view this post
VIEW IN TELEGRAM
👍28🔥94
Кому-то точно нужен был чек-лист для llm governance. Так вот я нашел полезную статью по теме.

https://www.newline.co/@zaoyang/checklist-for-llm-compliance-in-government--1bf1bfd0

Кажется вроде как базой, но что удобно - так это то что все в одном месте - законы, процесс, и кто сколько может заплатить за несоблюдение мер, но в разных странах. Конечно тут речь не про технику, но куда уж без комплаенса. 🤪
Please open Telegram to view this post
VIEW IN TELEGRAM
👍2🥰1
В последнее время анализируя множество исследований, статьей по теме - ощущаю нехватку того что меры которые предлагаются для защиты не содержат как правило проактивного характера.

У нас есть классический cyberkillchain. Mitre попытались отобразить его в своём фреймворке Atlas - несколько этапов от начального рекона до эксфильтрации и т.д. Это круто, но как мне кажется - знания о защите должны также быть, не хуже да и вообще быть изложены в структурированном виде. А то всё об угрозах да и об угрозах - а как защищать, когда атака уже идёт ? Говорить "не использовать MLFlow, потому что уязвимо" или другое решение выглядит обсурдным.

Н А Д О Е Л О

Поэтому с начала марта я задумался о том как можно было бы представить anti cyberkillchain, да так чтобы он ещё укладывался в ландшафт ML.

я закомитил свои наработки по теме сюда

https://github.com/wearetyomsmnv/ML-Defense-Matrix

это матрица противодействия разным этапам, как мне самому кажется - это очень верхнеуровневый документ, его определённо надо дорабатывать с коллегами которые строят защиту - поэтому призываю вас принять участие, дать комменты(только обоснованные) - чтобы сделать проактивную защиту ML лучше. Не всегда можно покрыть риски только на этапе разработки. Это печалит.

О чём документ: В нём я изложил меры по защите(очень поверхностно, думаю буду прорабатывать их в соответствии с публикациям на arxiv) которые можно использовать на разных этапах - защита от разведки, защита от исполнения кода и тд. В перспективе добавить тему уже услышанную всеми - это агенты.

Инциденты уже шагают, угрозы уже изучены и задокументированы - но вот защита ... С этим всё слабо кмк. Прошу репост, тех кто заинтересован в развитии такой истории.
👍126🤝2👻1
PWN AI pinned «В последнее время анализируя множество исследований, статьей по теме - ощущаю нехватку того что меры которые предлагаются для защиты не содержат как правило проактивного характера. У нас есть классический cyberkillchain. Mitre попытались отобразить его…»
В прошлом году Google выпустили исследование в котором показали как при помощи агентов искать zero days. Тогда была найдена проблема с sqlite3, критическая и быстро закрытая уязвимость.

Но уже в конце мая исследователь из Оксфорда опубликовал исследование в котором при помощи o3, без агентов и инструментов ему также удалось найти нолик, но уже в ядре линукса.

Уязвимости был присвоен CVE-2025-37899. Уязвимость позволяет удаленно выполнить код за счёт Use-after-free в SMB 'logoff'. Только доступ к апи, ничего больше. Наверное это первый публичный кейс когда ноль был обнаружен в ядре, да и как говорит автор - если можно закинуть 10к строк кода, то о3 справиться или поможет справиться.

На уязвимость уже вышел патч.


https://sean.heelan.io/2025/05/22/how-i-used-o3-to-find-cve-2025-37899-a-remote-zeroday-vulnerability-in-the-linux-kernels-smb-implementation/
👏4😱3
Фреймворков для тестирования моделей уже достаточно много на рынке. Но куда они движутся ? Что их объединяет и какие особенности преследует каждый из них.

В этой статье я изложил некоторую аналитику по этой части, но чтобы текст не казался техническим насилием при прочтении - я изложил его в формате гонзо журналистики. Приятного чтения
3👍3👎2
Aim Security нашли в Copilot уязвимость

Исследование: https://www.aim.security/lp/aim-labs-echoleak-blogpost

Уязвимость позволяла похитить данные из контекста copilot. Если он работает как агент с почтой или другими сервисами.

Ей присвоили CVE-2025-32711, и майкрософт уже запатчили эту историю.
2👍1
Если вы хотели потренироваться во взломе llm, то есть отличная новость.

Стив Уилсон, один из создателей OWASP top 10 для llm выпустил Лабу

https://virtualsteve-star.github.io/chat-playground/

Вроде бы как обычная песочница, но вы без проблем можете развернуть её локально(код есть на GitHub)

Подробнее:

https://www.reversinglabs.com/blog/owasp-chat-playground-lets-you-toy-around-with-ai-security
🔥91
Как выглядит подход Google для того, чтобы защитить ваших агентов и что в нём не так.

Ранее в мае, Google выкатили фреймворк для безопасности AI-агентов. Он основан на трёх ключевых принципах: чётко определённый контроль человеком, ограничение полномочий агентов и наблюдаемость действий агента и то, как он планирует задачи.

Кажется, что фреймворк в чём-то описывает очень стандартную для агентов историю по защите. Но я не стал писать о нём сюда, до одного момента - сегодня вышла статья Simon Willison, который детально провёл его анализ и осветил важные моменты, которые мы сейчас и рассмотрим.

Уже в начале статьи Willison выявляет принципиальное различие в подходах. Он отмечает, что Google выбрала менее категоричный путь по сравнению с другими исследователями. Если предыдущие работы четко утверждали, что AI-агент, получивший плохие данные, должен быть полностью ограничен в возможности выполнения значимых действий, то Google пытается найти компромисс.

Willison видит в этом фундаментальную проблему. Он считает, что Google обходит критически важные вопросы вместо их прямого решения. Фреймворк предлагает решения, основанные на надежном различении доверенных команд пользователя от потенциально опасных контекстных данных из других источников.
Willison говорит, что: Это неправильно ! Так как однозначное разделение невозможно.

Он подчеркивает, что вопросы/задачи формулируются пользователями таким образом, как будто решение существует, но в действительности такого решения нет.

Коротко о его мнении по поводу трёх принципов:

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

2. Принцип с ограничением полномочий агентов вызывает скептицизм. Он отмечает, что предложение Google слишком изощрено, так как требует буквально динамически изменяемых полномочий для агентов – сложно представить как это будет работать на практике. А ключевая проблема тут в том, что реализация таких guardrails потребует дополнительных моделей, которые будут корректировать разрешения исходя из задачи. Это кажется рискованным, так как промпт-инъекции могут повлиять на такие решения. Даже Google признает ограничения – стратегии недетерминированны и не могут предоставить абсолютные гарантии, что модели все еще могут быть обмануты новыми атаками, и что их режимы отказа могут быть непредсказуемыми

3. Willison согласен с тем, что должна быть наблюдаемость, как фундаментальное требование ИБ.

Риски, связанные с рендерингом вывода и меры которые описаны в документе – это большой + по его мнению, да и в целом, если приложение рендерит без санитизации или экранирования, то могут возникать разные уязвимости типа XSS или утечка информации.

Важной ценностью самого фреймворка является подход “defense-in-depth”, который комбинирует классические меры ИБ с reasoning-based механизмами защиты. Документ признает, что ни один подход в отдельности не может обеспечить абсолютную безопасность AI-агентов, поэтому подходов много!

https://simonwillison.net/2025/Jun/15/ai-agent-security/
1🔥7👍1
Промпт-инъекции по-прежнему являются угрозой номер один. Но на борьбу, на реализацию решений и методологии – выделяются большие команды и деньги, очевидно.

Недавно Google релизнул свою методологию по защите от промпт-инъекций, так сказать методологию в несколько слоёв.

Они предлагают использовать несколько уровней защиты:

Сперва интегрировать классификатор промпт-инъекций, что-то похожее мы видели у Anthropic как Constitutional Classifiers, а также отдельные файрволлы.

Далее уровень инструкций. Риск обхода инструкций, которые будут защищать модель – велик. Но что поделать – Google говорит, что если все 5 камней активируются, то только тогда будет сила.

Третий уровень – санитизация вредоносных URL и markdown, а также применения подхода Safe Browsing для защиты входных данных.

Скажу сейчас - этот подход они применяют в Gemini.

Четвёртый и пятый уровень – это взаимодействие с пользователем, использование Human-in-the-loop как способа верификации контента, а также оповещение пользователей о том, что сгенерированный контент является вредоносным. Тоесть получается такая проактивная стратегия защиты – в которой пользователь конечно же является значимым звеном.

Параллельно с этим вышла интересная классификация от Hidden Layer, в которой они предложили различные техники атак с использованием промптов. Таксономия включает в себя 62 различные тактики. Проблема в том, что в некоторых случаях это и угрозы связанные с саммаризацией(да-да) (просто попросить саммари вредоносного контекста) или же Cognitive overload (который больше на reasoning применим кмк). Удобное визуальное разделение, а также наличие хоть и не совсем работающих – но adversarial инструкций. Заслуживает вашего внимания.
👍5🔥32
Пишу свою карту, но паралельно обнаружил - AI Red Team Roadmap на roadmap.sh

https://roadmap.sh/ai-red-teaming

Полезная, но к сожелению тут нет агентов, да и нет атак на контур разработки моделей (((. Будет чуть позже 😁

P.s выложу роадмап днём ( не успел (
🔥10👍7🙏2👌1
Привет. Вот моя версия карты по AI Red Teaming. Часто в личку вы мне пишите "Как начать ломать ?". Это некоторый journey, в котором показано что надо изучить и что можно ломать.

Как мне кажется после понимания основ МЛ - важно понимать вектора на разные поддоменные области - так я и поделил reasoning, агентов и rag по отдельности.

На некоторых блоках я оставил QR код, с ссылками. Кроме агентов и MlOps - об этом достаточно много материала на моём канале и в т.ч в посте который писал Борис Часть из них содержит статьи на arxiv, так как нигде больше не описывают атаки(((. Атаки проверены.

Помимо карты которую я приложил можно обратиться к другим мапам:

1. Карта от Scale AI, больше рассказывает про то "что придётся атаковать".
2. Блог JustForFan - AI для безопасников

3. Joseph Thacker - How to Hack AI Agents and Applications - пожалуй самый прикладной roadmap, автор показывает где взять датасеты, даёт базовое объяснение некоторых концепций.

В любом случае стоит посмотреть карты для себя и выбрать то что ближе. Не претендую на полноту, а просто представляю свой взгляд на это )).
🔥135👍3
2025/07/09 10:09:08
Back to Top
HTML Embed Code: