Перевод на 1 цент превращает банковского ИИ-ассистента в фишинговую страницу

Атака — в поле «назначение платежа», а не в окне чата

Механизм здесь и есть вся история, поэтому разбор стоит читать буквально. Главное свойство: «вредоносные инструкции вводит не пользователь, общающийся с ассистентом. Они спрятаны внутри внешних или подгружаемых данных, которые ассистент позже обрабатывает». В цепочке два хода. Сначала атакующий отправляет жертве крошечный перевод на цент-другой с подготовленной инструкцией, встроенной в описание операции. Затем жертва позже спрашивает что-то обыденное вроде «Покажи мои последние операции», ассистент подтягивает список операций, и внедрённый текст приходит как контекст, который модель считает доверенным.

Опасным это делает результат. Модель генерирует целевое фишинговое сообщение, «поданное как легитимный запрос на повторную аутентификацию от банка», и оно появляется «внутри собственного приложения банка, от собственного ИИ-ассистента банка». Поскольку оно «может ссылаться на реальные детали операций и данные конкретного пользователя», оно читается как крайне правдоподобное предложение заново ввести учётные данные. Blue41 прямо говорит о пределах фильтрации: «Более тщательно собранную нагрузку бывает трудно отличить от обычных данных операции, если рассматривать её изолированно».

«Дело было не в промпте — дело в доставке промпта»

Самый проясняющий вклад в треде убил самую частую аналогию. Это не возвращение SQL-инъекции:

«Аналогия с SQL-инъекцией совпадает только в части про инъекцию … Тут нечего защищать, потому что нет SQL-запроса. … Более точная аналогия — фишинг. Потому что именно это здесь и происходит. … К сожалению, хороших защит от него толком нет, как мы все знаем по ‘обучению’ и ‘кампаниям’ против фишинга.» — NitpickLawyer

Почему это хуже обычного фишинга, объяснил завсегдатай с высокой кармой:

«люди и так кликают подозрительные письма … но к письмам люди уже насторожены, ведь фишинга там полно. А вот среда ИИ-ассистента может казаться пользователям ‘безопасной’, потому что это материал, идущий от банка. Так что они скорее попадутся.» — csomar

Скептики: это реальный эксплойт или реклама продукта?

Убедились не все. Самая залайканная скептическая реплика поставила под сомнение саму демонстрацию:

«Если я ничего не упустил, они не привели никаких доказательств, что это реально работает. Очень похоже на … завуалированную рекламу их продукта.» — treis

Более предметное сомнение перечислило предусловия — жертва должна получить деньги от незнакомца, затем сама про них спросить, затем кликнуть ссылку — и назвало практический риск «так себе». Это вызвало поправку, расширившую радиус поражения, от человека, представившегося автором разбора:

«Пользователю не нужно спрашивать именно про вредоносную операцию. Любой обычный вопрос, заставляющий агента подтянуть последние операции, может занести подконтрольный атакующему текст в контекст LLM.» — tvissers

Неуютный вывод: единственное надёжное решение — убрать агента

Тред всё время кружил вокруг одной позиции, сформулированной здесь предельно прямо:

«Нет единого механизма, решающего непрямую инъекцию промпта. На самом деле есть. Он называется ‘убрать ИИ-агента’. Готово.» — nticompass

Это шутка с реальным смыслом внутри. Пока LLM поглощает недоверенные данные и действует по ним, нет границы между «данными» и «инструкциями», которую можно было бы провести. Именно поэтому инженер по безопасности в треде заметил, что мы «почти везде починили SQL-инъекции», а тот же класс багов вернулся через контекстное окно модели. Защиты, которые рекомендует Blue41 — считать подгружаемые данные недоверенными, минимизировать контекст, ограничивать чувствительные действия, следить за поведением в рантайме, — это слои, снижающие вероятность. Ни один из них не является условием WHERE.