Галлюцинации как угроза безопасности для разработчиков. Все мы уже видели новости/исследования про то, что LLM генерирует код с небезопасными конструкциями. Сейчас даже есть бенчмарки для оценки этого. Однако, авторы статьи "Hallucinating AI Hijacking Attack: Large Language Models and Malicious Code Recommenders" описывают проблемы возникающие с точки зрения безопасности в ходе генерации контента с галлюцинациями. Понятно, что решений, которые могут оценить код на возникающие проблемы не так уже и много. Но давайте посмотрим, с чем можно столкнуться если не перепроверять код, сгенерированный LLM.⬇️⬇️⬇️

Hallucinated API Endpoint Suggestions

В статье приведен пример, когда необходимо было реализовать код с API для задачи оптического распознавания символов. Часто ли мы проверяем на какие API ведёт нас сгенерированный ответ ? Особенно если тот может правильно выполнять свою задачу, но иметь и вредоносный контекст). Или при выполнении может вообще загрузить ВПО на хост. 🫠🫠🫠

Malicious or Overtaken RSS Feeds🔗

LLM может предложить подписаться на фальшивую RSS-ленту, которая выглядит легитимной, например, на ленту антивирусной программы(как это было в исследовании, там была попытка создать фейковую новостную ленту для Dr.Web). И казалось бы, в чём проблема ? Проблема в том что LLM сгенерировал несуществующий ресурс для rss, который как можно понять, может быть захвачен злоумышленником. Через fake-rss может распространятся ложная информация.

Malicious or Overtaken GitHub Repositories🌐

Угроза, которую когда-то описывал Денис Макрушин может быть также реализована. В исследовании авторы попросили LLM сгенерировать код для взаимодействия с chatgpt-api, однако - сгенерированный код предлагал склонировать репозиторий, который на самом деле содержал в себе код инструментов для кражи пользовательских данных.

Malicious NPM and Yarn Packages(да и PyPI наверное, RubyGems и т.д)

Модель может предложить установить вредоносный пакет для JavaScript, который выглядит как легитимный, но содержит скрытые вредоносные скрипты, запускающиеся при установке. Авторы попросили модель сделать код с пакетом radar-cms, однако моделька реализовала код, который позволяет установить из репозиториев пакеты: "@realty-front/codegen" или "radar-cms", которые на первый взгляд кажутся полезными, на самом деле содержат скрипты для кражи данных.

А ну и ещё был приведён пример с 🤡living off the land🤡, для тех кто не знает - это атаки при которых злоумышленники используют легитимные инструменты для выполнения вредоносных действий. Например через PowerShell вы запускаете скрипт который повышает привилегии. Более подробно об этом вы можете спросить своего знакомого пентестера. Однако LLM способны генерировать код, который под предлогом использования легитимного инструмента может позволить реализовать атаку.

Это всё были примеры, которые авторы смогли получить на примере простых запросов о генерации кода. Однако когда дело доходит до сложного проекта, мы должны понимать, что это является серьёзной проблемой для безопасности. И вот как мы можем попытаться сократить риски ?

Вы можете наткнуться в интернете на статьи, которые буквально говорят о том, чтобы перепроверять ответы другой моделью. Компания circle предлагает использовать такой подход при разработке и обучении модели. Однако кажется это очень безумным, и не совершенным.

Есть варианты которые позволяют разработчикам модели сократить риск, создание чёрных списков для ресурсов и генерируемого контента. Или safety fine-tuning, чтобы модель выдавала более безопасные результаты.

🤖🤖🤖 Буквально недавно компания OpenAI выпустила экспериментальный фреймворк для оркестрации агентов в мультагентных системах - SWARM. Быстро представим как он может помочь. Агенты позволяют выполнять какие-то определённые задачи, которые заданы пользовательской инструкцией - например вы можете сделать агента, который будет осуществлять поиск по сайту на наличие определённого товара. Он будет прекрасно выполнять свою задачу и самое важное что вы попросили его сделать через привычную форму общения с LLM - через промпт. Агентов может быть множество, им можно дать разные задачи. Собственно мультиагентная система позволяет совмещать несколько агентов под разные задачи. Примеры вы могли видеть уже и в реальной жизни - например AutoGPT.

SWARM - фреймворк который позволяет быстро создать агенты и управлять ими. Мы можем задавать им разные инструкции, определять то что они будут делать и создавать цикл, который позволяет работать нескольким агентам над одной задачей одновременно.

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

Давайте подумаем над тем какие вообще угрозы могут возникать в ходе этого. А ведь это действительно сочно. OWASP собирается включить угрозы для агентов в следующий LLM top 10(спасибо Евгению за мониторинг).

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

Собственно в статье, которую я привёл выше авторы достигли частичного успеха на агентной системе(которой доступны множество агентов) с GPT4-o. Буквально с частотой 13%. Тоесть не всегда промпт мог дальше самореплицироваться на другие агенты.

Вот вы думаете наверное, а как они вообще тестировали ? В статье описан эксперимент, в котором был задействован агент для обработки pdf, агент для чтения данных из pdf, и агент для взаимодействия с базой SQL. В pdf был спрятан prompt-injection - целью было "хищение информации из SQL-базы", к которой как раз привязан 3й агент. 🤡🤡🤡

Не всегда есть у агентов разграничение доступа или не всегда им можно определить права. К сожалению, этот нюанс также может привести к тому что агенты смогут выполнять различный код или собирать информацию о хостах как я описывал тут.

Что авторы предложили в качестве метода для снижения риска ? Помечать ответы агентов специальным тегом, определяющим происхождение. Это помогает распознать, какой именно агент сгенерировал ту или иную подсказку, что снижает риск распространения вредоносных инструкций. Однако даже этот метод не является абсолютной защитой, и атаки все еще могут происходить, если используются сложные техники обхода.😞😞😞

Ещё в качестве методов для защиты мы к примеру можем бенчмарчить агентную систему заранее. Недавно появился такой бенчмарк - ASB(Agent Security Benchmark) - он содержит в себе данные с вредоносными инструкциями для агентов. Которые можно взять и потестировать. А затем как вариант дообучить это всё дело.

Пока что я из описания SWARM я не заметил чтобы там была похожая функция, или возможность разграничения того как агенты могут работать. Экспериментальный фреймворк ...


ai_sec_folder