Защита больших языковых моделей перед следующей волной атак типа prompt injection

В прошлом месяце я изучал криминалистический отчет, в котором фирма, работающая в сфере финансовых услуг, потеряла контроль над внутренним ботом по обслуживанию клиентов. У фирмы был современный стек безопасности, однако одно единственное хитро сформулированное предложение в тикете службы поддержки обошло все защитные барьеры. В этом заключается архитектурный парадокс современного ИИ. Мы окружаем эти модели слоями традиционной безопасности, но не можем устранить основную уязвимость: модель неспособна отделить недоверенные данные от доверенных инструкций. Компания CrowdStrike недавно классифицировала эту проблему, выделив пять новых векторов атак, которые необходимо понимать каждому архитектору по безопасности.

Вчера утром я провел время в своей лаборатории, пытаясь воспроизвести одну из этих техник на локальной версии Llama 3. Простота эксплойта — вот что делает его опасным. С точки зрения рисков, мы сейчас находимся на «Диком Западе» генеративного ИИ. Пять новых угроз внедрения подсказок (prompt injection), выявленных CrowdStrike, демонстрируют, что злоумышленники выходят за рамки простых команд «игнорируй все предыдущие инструкции». Теперь они используют лингвистические манипуляции и многоэтапную доставку для компрометации систем.

Крах границы между данными и инструкциями

Prompt injection существует из-за того, как большие языковые модели обрабатывают информацию. В традиционном программном обеспечении код и данные обычно хранятся в разных пространствах памяти. База данных SQL не выполнит случайно фамилию пользователя как команду, если только не существует специфической уязвимости, такой как SQL-инъекция. В LLM инструкции от разработчика и данные от пользователя находятся в одном и том же контекстном окне. Модель обрабатывает каждый токен с одинаковым весом.

Отсутствие такого разделения превращает сетевой периметр в устаревший ров вокруг замка. Если вы позволяете LLM читать электронную почту, вы, по сути, даете этому письму место за клавиатурой. Злоумышленники используют эту архитектурную особенность, встраивая инструкции в данные, которые модель в конечном итоге обрабатывает как директиву. Новая таксономия CrowdStrike предоставляет карту того, как злоумышленники совершенствуют свои методы, чтобы обходить базовую фильтрацию по ключевым словам.

Спящие угрозы через правила, активируемые триггером

Первая новая техника — это добавление правил, активируемых триггером (trigger-activated rule addition). В этом сценарии злоумышленник не пытается взломать модель немедленно. Вместо этого он вводит новое правило, которое кажется безобидным. Например, злоумышленник может указать модели всегда резюмировать текст в определенном формате, если она видит слово «bluebird». Само по себе это не является нарушением. Это выглядит как незначительная настройка.

Однако злоумышленник может активировать это правило позже, чтобы вызвать странное или вредоносное поведение. Правило действует как «спящий агент». Как только триггер активирован, модель может перенаправить свои выходные данные на несанкционированный API или начать утечку конфиденциальных системных промптов. Поскольку первоначальное добавление правила безобидно, оно проходит через большинство базовых систем обнаружения. Угроза остается скрытой до тех пор, пока не будут выполнены определенные условия. Оценка поверхности атаки требует поиска таких скрытых операторов «если-то», погребенных в долгосрочной истории диалогов или системных инструкциях.

Обход фильтра с помощью когнитивного подавления токенов

Когнитивное подавление токенов (cognitive token suppression) — это более технический подход к обходу мер безопасности. Большинство LLM имеют встроенные шаблоны отказа. Если вы попросите модель помочь в написании вредоносного ПО, она обучена отвечать что-то вроде: «Я не могу помочь с этим запросом». Команды безопасности часто полагаются на эти установленные шаблоны отказа для обеспечения безопасности модели.

Злоумышленник, использующий когнитивное подавление токенов, смещает лингвистический выбор модели в сторону от этих шаблонов. Он может использовать сложные ограничения, которые запрещают модели использовать слова «не могу», «отказываюсь» или «политика». Лишая модель возможности сказать «нет» привычным способом, злоумышленник принуждает LLM к состоянию, в котором она с большей вероятностью выполнит вредоносный запрос. Это своего рода «лингвистические наручники». Модель вынуждена искать путь выполнения запроса, который обходит ее обучение безопасности. В результате фильтр безопасности не срабатывает, так как у модели больше нет доступа к словарному запасу, необходимому для выражения отказа.

Скрытие полезной нагрузки через алгоритмическую декомпозицию

Алгоритмическая декомпозиция полезной нагрузки (algorithmic payload decomposition) — это атака, основанная на способности модели собирать сложные идеи из простых частей. Злоумышленник доставляет сообщение в несколько этапов. Каждый этап в отдельности выглядит невинно. Один промпт может попросить модель сохранить определенную строку символов. Второй промпт может попросить ее определить некоторую функцию.

При объединении эти части собираются в единую команду, представляющую угрозу. Это цифровой «троянский конь» для prompt injection. Инструменты безопасности, сканирующие отдельные промпты на наличие вредоносных намерений, не увидят ничего подозрительного. Угроза проявляется только на архитектурном уровне, когда модель интегрирует все части воедино. Я видел, как это эффективно работает в средах, где контекстное окно достаточно велико, чтобы вместить несколько казалось бы не связанных взаимодействий, которые в конечном итоге формируют полную цепочку эксплойта.

Риск инъекции специальных токенов

Инъекция специальных токенов (special token injection) — это техника, нацеленная на переключатели управления LLM. Модели используют специальные токены для обозначения конца мысли или начала системной инструкции. Эти токены подобны кнопкам на приборной панели пилота. Если злоумышленник сможет внедрить эти токены в свой собственный ввод, он может обманом заставить модель поверить, что контент пользователя на самом деле является высокоприоритетной системной директивой.

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

Обман пользователя с помощью инъекции контекстных данных

Непреднамеренная инъекция контекстных данных пользователем (unwitting user context-data injection), пожалуй, является самой распространенной угрозой в этом новом списке. Этот эксплойт использует границу между доверенными данными и исполняемыми инструкциями. Пользователь сам вводит вредоносную инструкцию, но делает это, не зная об этом. Это происходит, когда пользователь загружает документ, пересылает электронное письмо или добавляет веб-контент, который ИИ позже обрабатывает.

За кулисами вредоносная инструкция скрыта внутри документа или письма. Промпт, который пишет пользователь, может быть безобидным, например: «сделай краткое изложение этого PDF». Сам PDF содержит скрытую строку текста, которая велит модели игнорировать резюме и вместо этого отправить токен сессии пользователя на внешний сервер. Пользователь становится средством доставки атаки. С точки зрения целостности данных это кошмар. Это означает, что любая информация, которой касается LLM, является потенциальным вектором компрометации.

Построение устойчивой архитектуры защиты

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

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

Принцип нулевого доверия (Zero Trust) должен применяться к данным, поступающим в LLM. Представьте это как вышибалу в VIP-клубе у каждой внутренней двери. Никогда не доверяйте данным, даже если они исходят от авторизованного пользователя. Вышибала должен убедиться, что контент не содержит скрытых инструкций, прежде чем он будет допущен в контекстное окно модели. Это единственный способ построить устойчивую систему, способную противостоять следующему поколению атак prompt injection.

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

Ключевые выводы для руководителей по безопасности

• Аудит источников контекста: Идентифицируйте все входные данные, которые попадают в ваши LLM, и относитесь к ним как к недоверенным инструкциям.
• Тестирование на лингвистические обходы: Используйте red teaming, чтобы проверить, уязвима ли ваша модель к когнитивному подавлению токенов или алгоритмической декомпозиции.
• Мониторинг специальных токенов: Внедрите фильтры, которые обнаруживают и удаляют управляющие токены из данных, предоставленных пользователем.
• Обучение пользователей рискам контекста: Информируйте сотрудников о том, что резюмирование недоверенных документов может привести к компрометации системы.
• Внедрение инженерии обнаружения: Выходите за рамки простого сопоставления ключевых слов и начинайте искать поведенческие аномалии в ответах модели.

ИИ — это мощный инструмент, но это также и новый тип поверхности атаки. Понимая эти пять новых угроз, вы сможете начать строить защиту, которая будет такой же умной, как и модели, которые вы пытаетесь защитить.

Источники: CrowdStrike Falcon Intelligence, NIST AI Risk Management Framework, MITRE ATLAS.

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