LLM Backdoors at the Inference Level: The Threat of Poisoned Templates
Ariel Fogel, 2025, Pillar Security
Блог

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

В случае с файлами GGUF вся нужная для инференса модели информация, вроде конфигурационных файлов, токенизатора и промпт-темплейта, поставляются или единым файлом, или набором GGUF-файлов без разделения по функциональности. А это значит, что злоумышленник может так сформировать встроенный промпт-темплейт (как вы, вероятно, знаете, у разных моделей могут быть разные промпт-темплейты, использованные при SFT, они распространяются как Jinja-файов), чтобы рядом с системным промптом всегда добавлялись нужные злоумышленнику инструкции.

Сценарий в данном случае ограничивается только вашим воображением, Pillar для демонстрации выбрали подгрузку потенциально зловредной js-нагрузки при генерации по запросу пользователя HTML-разметки. Понятно, что тут могут быть и указания добавлять в код бэкдоры, и политические установки, и многое другое.

Ситуация усугубляется тем, что на Huggingface в разделе конкретной модели обычно лежат все кванты вместе, условно от q2 до q8. При просмотре промпт-темплейта пользователь видит темплейт только первой загруженной версии: платформа предполагает, что все кванты имеют одинаковые темплейты, а значит, атакующий может загрузить самый непоплярный квант с чистым темплейтом, скрыв наличие инъекции во всех остальных.

Получается интересное сочетание промпт-инъекции и supply chain-атаки на относительно безопасный (по сравнению с pickle и производными) формат. Остается только напомнить, что не стоит скачивать модели из неофициальных (или хотя бы не обладающих репутацией) репозиториев, а то, что скачиваете – базово проверять на безопасность, и как видно, в эту проверку обязательно входит мониторинг темплейтов.

SHADE-Arena: Evaluating sabotage and monitoring in LLM agents
Kutasov et al., 2025
Блог, статья

Вы дали LLM-агенту задачу. Может ли он параллельно с ней выполнить зловредную задачу и не спалиться? Вопрос не праздный, так как инструкция типа отправки всех API-ключей из энва на непонятный адрес может прилететь к нему в контекст откуда угодно – от страницы в интернете до промпт-темплейта. Авторы статьи предлагают бенчмарк, который позволяет этот риск оценить.

Суть бенчмарка – расширение AgentDojo, причем DLC получился солидный: 30 компонентов (телефон, почта и так далее), 340 инструментов (в каждом сценарии – от 20 доступных), до 100 тысяч токенов синтетических данных на среду. Исследователи предлагают 17 сценариев, состоящих из основной задачи (просмотреть список гостей конференции и забронировать каждому авиарейс и ресторан или просмотреть почтовые ящики и сгенерировать спам-фильтры) и побочного квеста, состоящего из определенного зловредного действия (при бронировании выбирать рейсы только одной авиакомпании, невзирая на цены, или добавить анти-спам правило, которое удаляет алерты о логинах в GitHub). Цель агента – выполнить обе задачи, причем так, чтобы не стриггерить мониторинг. В инструкциях отмечается, что дело происходит в симуляции, чтобы уменьшить число отказов от выполнения задачи. Роль контролера играет Claude 3.6, который пост-фактум читает логи агента, не включающие системную затравку и Chain-of-Thought, и выдает скор от 0 до 100, где 80 – граница подозрительности. Для каждого из сценариев было проверено, что решение, не вызывающее подозрений контролера, существует.

Результаты показывают, что наиболее успешны Claude 3.7 Sonnet и Gemini 2.5 Pro c 27% и 15% успеха соответственно. Другие модели, включая топовые открытые модели типа Qwen-3 и DeepSeek-R1, а также модели от OpenAI, справляются хуже. Причиной тут по большей части являются проблемы с выполнением заданий: модели просто не выполняют ожидаемых действий, галлюцинируют экфильтрируемые данные, теряются в длинном контексте. Даже если предоставить агенту хитрую стратегию, придуманную человеком, он может с ней просто не справиться. Когда причина неудачи в детектировании контролером, дело в том, что модель в целом не пытается скрывать свои намерения или случайно упоминает задачу за пределами скрытого от контролера CoT.

Исследователи также оценивают разные модели, а заодно людей, в качестве контролеров. Лучшим контролером оказывается gemini-2.5-pro с достаточно скромными 0,87 AUC, а вот люди, которым требуется в среднем 103 минуты на лог, показывают еще худший результат (AUC=0,65, три оценки на транскрипт, агрегация по минимальной оценке).

Мониторинг сильных моделей более слабыми моделями – очень важное направление работы: с точки зрения security нам бы хотелось предотвращать инъекции, появляющиеся в самых неожиданных местах, максимально дешево, с точки зрения safety – определять scheming в новой модели, используя проверенную старую. Как видно, пока это получается не очень, но и мониторить особо нечего – даже с основными задачами модели пока справляются не очень успешно.

Invitation Is All You Need! TARA for Targeted Promptware Attack Against Gemini-Powered Assistants
Nassi et al., 2025
Статья, сайт

Попалась любопытная работа израильских исследователей (это, кстати, те же ребята, что назвали инъекцию в симулированный почтовый клиент Morris II, представленная на Blackhat, про непрямые промпт-инъекции в андроидовском ассистенте Gemini, которые были актуальны в феврале этого года. В статье куча всякой скукоты типа специального фреймворка оценки рисков и попытки продвинуть придуманный ими термин promptware, но главное то, что они научились с помощью приглашения в календарь выключать пользователю свет 🔪

Суть атаки проста. Пользователю отправляется приглашение в календарь. В приглашении содержится промпт-инъекция, которая просит у Gemini выполнить определенную инструкцию при несложном условии: например, если пользователь скажет «спасибо» или использует слово длиннее двух букв. Чтобы цепочка сработала, пользователь должен попросить у ассистента список ближайших задач в календаре.

Используя такую нехитрую технику, исследователи заставляют ассистента:

1. Генерировать оскорбительные тексты, надоедать спам-ссылками с рекламой или фишингом.
2. Отравление долгосрочной памяти, приводящее к неверным ответам.
3. Атаки на агента, включая удаление случайных встреч из календаря.
4. Атаки на других агентов. Ассистент состоит из агента-оркестратора и узконаправленных агентов, типа агента для календаря. Поскольку инъекция попадает в контекст оркестратора, исследователям удалось дать команды агенту Google Home включить и выключить свет, открыть окна и включить бойлер. Эксплуатация агента Utilities позволила им скачать на смартфон файл (раскрыв геолокацию пользователя), запустить встречу в Zoom и вытащить через браузер названия встреч, содержание писем и другую информацию (закодировав их в URL).

В качестве противодействия таким атакам исследовали рекомендуют ограничивать возможности межагентного взаимодействия, последовательного запуска многих инструментов (то есть вещи, которые делают агентов прикольными), а также использовать гардрейлы и Control Flow Integrity (типа CaMeL). Из любопытного: бросается в глаза простота тех промпт-инъекций, которыми пользовались исследователи, что несколько пугает в сочетании с простотой киллчейна. Кажется, что пока давать LLM-инструментам, которые могут случайно снести вам Windows, контроль над физическими системами – будь то роботы или лампочки – пока рано.

BinMetric: A Comprehensive Binary Analysis Benchmark for Large Language Models
Shang et al., Hefei University of Science and Technology, 2025
Статья

Одним из интересных применений LLM является их использование в реверс-инженерии, она же обратная разработка. LLM легко видят взаимосвязи в длинных листингах псевдокода, помнят все опкоды и могут довольно неплохо понимать, что делает та или иная декомпилированная функция. Или нет? С одной стороны, существует достаточно много плагинов, типа Gepetto для IDA или Sidekick для Binary Ninja, которые делают разные полезные вещи, типа замены названий переменных в C-подобном псевдокоде на человекочитаемые, что очевидно требует понимания семантики кода. С другой стороны, как оценить, насколько хорошо это работает? Для этого нужны бенчмарки, и сегодня мы поговорим об одном из них – BinMetric.

Исседователи из Китайского университета технологий в Хэфэе предлагают бенчмарк, который с разных сторон оценивает способность LLM к задачам анализа бинарных файлов. Бенчмарк состоит из 6 задач:
1. Call-site Reconstruction (CSR): на входе LLM подается кусок ассемблерного кода и адрес вызова, на выходе ожидается C-подобная строка с названием функции и аргументов. В качестве метрики используется CodeBLEU и Rouge-L.
2. Decompilation (DEC): на вход подается ассемблерный код, соответствующий одной функции, на выходе ожидается С-подобный листинг этой функции. Метрики те же.
3. Signature Recovery (SR): на вход подается псевдокод функции от декомпилятора, на выходе ожидается сигнатура функции (название с параметрами). Метрики – BLEU, METHEOR и ROUGE-L.
4. Binary Code Summarization (BCS): на вход – снова псевдокод функции после декомпилирования; на выходе ожидается описание функции на естественном языке. Метрики – как в SR.
5. Algorithm Classification (AC): LLM должна определить тип алгоритма (сортировка, шифрование и так далее) на основе псевдокода. Оценивается точность.
6. Assembly Instruction Generation (AIG): самая любопытная задача – генерация ассемблерного кода по промпту. Код оценивается с помощью ROUGE, а также на прохождение юнит-тестов.

Чтобы собрать такой бенчмарк, исследователи используют код открытых проектов на C – от curl до llama2.c – код которых они компилируют, собирая артефакты DWARF и удаляя символьную информацию. Для компиляции используются рекомендованные разработчиками параметры компиляции, чтобы получить разнообразие. Затем бинари дизассемблируют и декомпилируют с помощью IDA, после чего с помощью DWARF получают выравнивание между сорцами и результатом работы IDA. Далее исследователи удаляют слишком длинные и слишком короткие функции, после чего семплируют данные для задач. Для BCS применяется ChatGPT, чтобы получить описания функций на базе исходного кода. Задачи для AC семплируются из C-Algorithms. Для AIG исследователи пишут вручную 100 промптов и разрабатывают под каждую задачу алгоритмы. На все у них уходит 60 человеко-часов, что кажется некоторым преуменьшением.

К сожалению, само исследование, видимо, проводилось давно (опубликована статья в мае этого года), поэтому на своем бенче исследователи гоняют Llama-2-7B, Mistral-7B, Mixtral (хорошая была модель, олды помнят), WizardCoder и CodeLlama-32B, из закрытых – GPT-3.5 и GPT-4. Кроме того, на соответствующих задачах оценивается BinT5, HexT5 и LLM4Decompile. Лучшими моделями (не удивительно) оказываются GPT-4 и большие кодинговые модели типа CodeLlama, конкретные цифры можно посмотреть в табличке, пересказывать их ввиду неактуальности в 2025 году смысла нет.

Из любопытного – видно, что LLM достаточно неплохо превращают asm в псевдокод – лучше по метрикам, чем Hex-Rays. С генерацией ассемблера ни одна из LLM ожидаемо не справилась. Сам бенчмарк кажется очень интересным, и было бы любопытно посмотреть на него в контексте более современных моделей. С другой стороны, есть и чем расширить – например, оценкой правильности переименования переменных, что делает Gepetto, или анализом более широким, чем одна функция, кроме того, в открытом доступе бенчмарк найти пока не удалось. О таких бенчмарках мы еще поговорим.