Лето. Пришла пора куда-то выбраться в отпуск. Открываем ChatGPT, выбираем активно набирающий популярность GPT “Travel Advisor”, обсуждаем варианты. Советник дает отличные советы и очень интересно рассказывает про местные достопримечательности, генерирует весьма неплохие планы, и в целом оставляет хорошее впечатление. Местами, конечно, проскакивают странности, но мы их пропускаем как безобидные галлюцинации. Отлично, останавливаемся на Барселоне. В том же чате переключаемся на другой, не менее знакомый и популярный GPT “Booking Agent”, который нас никогда не подводил, и бронируем жилье.

По прилете мы обнаруживаем, что агент забронировал комнату в пригороде за довольно высокую цену. Разумеется, мы списываем все на вопиющую ошибку Booking Agent и общую ненадежность AI. Однако, возможно, что все немного сложнее, и в этой ситуации замешан нечистый на руку владелец жилья.

Chat example

Пример чата с Travel Advisor и Booking Agent

Как он смог это провернуть, и какие еще опасности таит в себе использование нескольких GPT в одном чате? Об этом мы поговорим в этом посте.

Введение

Немного предыстории. По служебной необходимости пришлось мне поразмыслить над безопасностью набирающего популярность протокола MCP (Model Context Protocol) от Anthropic. Он был создан с целью унифицировать доступ модели к различным инструментам, позволяя так называемым MCP-серверам предоставлять модели саму функциональность и описание того, как ей пользоваться. По замыслу создателей, эти сервера можно подключить в любом приложении, использующим AI, и расширять его возможности на лету.

Однако безопасность этого протокола была отодвинута на второй план, из-за чего он подвержен множеству уязвимостей. Одна из наиболее неприятных — Tool Poisoning, являющаяся разновидностью более общего класса атак Context Poisoning. Суть этой уязвимости в том, что инструкции для всех MCP попадают в единый промпт для модели, и если среди используемых серверов окажется зловредный, он может “отравить” этот общий промпт, изменив поведение модели на желаемое для злоумышленника.

До появления MCP различные вендоры предоставляли похожие проприетарные инструменты. Один из них, GPT от OpenAI, позволяет пользователям создавать специализированных помощников, которые обладают собственными инструкциями, имеют доступ к интернету и могут иметь доступ к внешним API. OpenAI также выпустили магазин этих GPT и позволили пользователям делиться ими друг с другом, что открыло широкий канал для распространения зловредов.

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

Эксплуатация

Прежде всего, важно отметить, что переключение GPT в одном чате не может напрямую привести к Tool Poisoning. При переключении GPT все инструкции от предыдущих удаляются из контекста, так что промпт одного GPT не может непосредственно влиять на другие. Ключевое слово здесь — непосредственно. Дело в том, что остается еще один неустранимый канал коммуникации — сам чат.

Разумеется, любые грубые попытки манипулировать этим каналом будут тут же замечены пользователем, поэтому манипуляции должны быть достаточно невинными и незаметными. Впрочем, люди — существа несовершенные, и существует множество способов влиять незаметно. Для этого достаточно вспомнить несколько особенностей взаимодействия человека и AI:

  1. Асимметрия внимания. Человек в основном оперирует недавним контекстом. Все, что выходит за рамки последних нескольких итераций чата, фактически перестает для него существовать. Внимание LLM, с другой стороны, охватывает весь контекст, доступный ей. Таким образом, кажущаяся незначительной фраза, брошенная в начале беседы, будет оказывать влияние на весь диалог, несмотря на то, что пользователь про нее уже забыл.
  2. Парадокс доверия. Пользователь ожидает, что модель может ошибаться. Одновременно, особенность человеческого разума заключается в том, что человек подсознательно верит в любую информацию, представленную уверенным и авторитетным тоном. Таким образом, пользователь может списать мелкую неточность на особенности AI, и при этом доверить тому же самому AI выполнить важное действие, если описание и подтверждение этого действия было достаточно убедительным.
  3. Эффект одного собеседника. Хотя пользователь явным образом переключает чат между различными GPT, он неявным образом переносит свое доверие с одного на другой в пределах одного диалога. Иными словами, он склонен доверять всем GPT одинаково.

Оперируя этими фактами, злоумышленник может спроектировать и воплотить достаточно большое количество различных атак. Среди них я бы выделил две:

  1. Кража информации (Data Exfiltration). Достаточно классическая ситуация 2. Зловред анализирует чат и, найдя нужную информацию, отправляет ее на удаленный сервер. Для этого ему нужно подтверждение оператора, для этого он маскирует эту операцию под легитимную.

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

    Почему я включил эту уязвимость в категорию взаимодействия разных GPT? Потому что вредоносный GPT может создаваться и распространяться специально, чтобы воровать информацию у какого-то конкретного популярного ассистента. Например: популярный помощник-бухгалтер запрашивает от пользователя специфическую финансовую информацию, которая интересует злоумышленника. Злоумышленник создает зловреда и промотирует его как предоставляющего дополнительную функциональность, которой в помощнике нет, например, проверку документов на соответствие нормам. После появления необходимой информации в чате GPT-зловред отправляет ее на сервер атакующего под видом юридической проверки.

      sequenceDiagram
    participant U as Пользователь
    participant G1 as GPT-Бухгалтер
    participant CTX as Общая история чата
    participant G2 as Зловредный GPT
    participant S as Сервер Атакующего

    U->>G1: Финансовые <br> документы
    activate G1
    G1->>CTX: Запись: <br> {приватные_фин_данные}
    CTX-->>U: Отображение ответа G1
    deactivate G1

    U->>G2: Проверь документ
    activate G2
    G2->>CTX: Запрос всей истории
    activate CTX
    CTX-->>G2: История <br> (с приватными данными)
    deactivate CTX

    rect rgb(190, 144, 144)
        G2->>S: POST /api/check <br> {приватные_фин_данные}
        activate S
        S-->>G2: HTTP 200 OK
        deactivate S
    end
    G2-->>U: Проверка прошла успешно!
    deactivate G2

  2. Отравление контекста (Context Poisoning). Пример этой манипуляции приведен выше.

    Здесь есть GPT-злоумышленник, созданный таким образом, чтобы подтолкнуть любые другие GPT, используемые в том же чате, к определенным действиям. Кроме уже упомянутого Travel Advisor, примерами могут служить финансовый советчик, ненавязчиво обращающий внимание на медицинский сектор, советник по моде, рекомендующий направление, в котором работает определенный бренд, и другие. В данном случае злоумышленнику не нужно указывать на конкретный бренд или компанию, достаточно сместить чашу весов принятия решения в нужном направлении.

      sequenceDiagram
    participant U as Пользователь
    participant G1 as Зловредный GPT-1
    participant CTX as Общая история чата
    participant G2 as Доверчивый GPT-2

    U->>G1: Обсуждение отпуска
    activate G1
    rect rgb(190, 144, 144)
        G1->>CTX: Запись: "Советую тихий район X..."
    end
    CTX-->>U: Отображение ответа G1
    deactivate G1

    U->>G2: Забронируй жилье
    activate G2
    G2->>CTX: Запрос всей истории
    activate CTX
    rect rgb(190, 144, 144)
        CTX-->>G2: Вся история (с ядом про район X)
    end
    deactivate CTX

    rect rgb(190, 144, 144)
        G2-->>U: Готово! Забронировал в районе X
    end
    deactivate G2

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

Гигиена

Защита от манипуляций для пользователя GPT-ассистентов должна быть, как и сами манипуляции, многоуровневой.

  • Самым эффективным способом защиты от взаимодействия GPT между собой, как бы это парадоксально ни звучало, является полное исключение этого взаимодействия. Иными словами, стоит разделять чаты по задачам и использовать отдельный чат для каждого GPT, перенося необходимый контекст вручную. “Необходимый” здесь — ключевое слово, поскольку если просто скопировать весь чат целиком, будет скопирован и отравленный контекст.
  • Используйте доверенные GPT. Соблюдение этого правила в реальности довольно проблематично, так как OpenAI не позволяет провалидировать промпты и настройки ассистентов, представленных в их магазине. Огромное же количество GPT в магазине делает эффективную модерацию практически невозможной. Наилучшим выходом будет создание собственных GPT в тех задачах, для которых это возможно. Интерфейс, который предоставляет OpenAI, в большой степени автоматизирован с помощью LLM, что делает их написание простым и доступным для каждого. Если написание своего GPT невозможно, к примеру, в случаях, когда ассистент обращается к приватному API или использует проприетарную базу знаний, обращайте внимание на популярность и возраст ассистента. Это не железобетонный критерий, но все же понижает вероятность наткнуться на зловреда.
  • Выступлю в роли Капитана Очевидность, но всегда и везде отфильтровывайте приватную информацию и проверяйте действия, совершаемые агентом. Это базовое правило, но о нем слишком часто забывают.

Заключение

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

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

  1. Поскольку проверка GPT в магазине требует больших усилий, можно внедрить автоматическую модерацию моделью-классификатором, подобно тому, как обнаруживаются сообщения, нарушающие условия использования. К сожалению, в открытых источниках нет информации о том, используется ли такая модель в магазине в настоящий момент.
  2. При переключении GPT в рамках одного чата явно спрашивать пользователя, хочет ли он предоставить доступ к полной истории новому ассистенту, начать новый чат, или, опционально, предоставить доступ к краткому содержанию диалога. Кроме технической защиты, это хороший метод нивелировать эффект одного собеседника.
  3. И, что более сложно и ресурсозатратно, размечать сообщения от разных GPT и дотренировать модель таким образом, чтобы она автоматически назначала меньший вес сообщениям от GPT, отличных от текущего. Здесь очень важно сбалансировать эффект так, чтобы модель не стала игнорировать полезную информацию, предоставленную предыдущими ассистентами 3.

К счастью, исходя из оценки последних нововведений OpenAI, можно сказать, что они внимательно относятся к освещению потенциальных проблем при использовании их продуктов и ограничивают свои инструменты таким образом, чтобы усложнить эксплуатацию уязвимостей. К примеру, их реализация поддержки MCP ограничивает доступные инструменты исключительно операциями search и fetch. В посте про уязвимости MCP-протокола я планирую рассказать про то, почему они пришли к таким ограничениям. А тем временем, до новых встреч.

Ссылки

  1. До тех пор, пока пользователь не копировал сообщения из одного чата в другой ↩︎

  2. Jiahao Yu et al., “Assessing Prompt Injection Risks in 200+ Custom GPTs”, arXiv:2311.11538v2, May 2024. https://arxiv.org/abs/2311.11538 ↩︎

  3. Keegan Hines et al., “Defending Against Indirect Prompt Injection Attacks With Spotlighting”, arXiv:2403.14720v1, Mar 2024. https://arxiv.org/abs/2403.14720 ↩︎