«Обнаружено 10 угроз». Как используют уязвимости в больших языковых моделях
Не так давно на New Retail вышел материал о том, какие вопросы сегодня звучат в адрес технологий на базе искусственного интеллекта. Наш генеральный директор Александр Обысов и независимый эксперт по инновациям в ритейле Борис Агатов прислушались к голосам скептиков и подробно разобрали их тезисы.
Сегодня, в продолжение темы рисков, связанных с ИИ — небольшое интро в уязвимости больших языковых моделей. Спойлер — никогда не кидайте в чат с ботом чувствительные данные типа номеров банковских карт или паролей. И не используйте для работы с ChatGPT посредников в виде телеграм-ботов. Вы отдаёте всю инфу не только OpenAI, но и неизвестному хозяину бота.
Первые сообщения об уязвимостях в больших языковых моделях появились вскоре после широкого внедрения ChatGPT в 2022 году. Эти уязвимости были связаны с различными аспектами безопасности — манипуляцией данными, утечкой информации и вредоносными действиями.
Большой вклад в систематизацию рисков, связанных с использованием LLM, внёс (и продолжает вносить) фонд OWASP. Open Web Application Security Project — это открытый проект по изучению безопасности веб-приложений. В сообщество OWASP входят корпорации, образовательные организации и частные лица.
Фонду принадлежит самая адекватная классификация уязвимостей LLM, которые сегодня эксплуатируют злоумышленники. Опубликовано уже три версии этой классификации. Это очень динамичная область знаний, и если вы работаете с большими языковыми моделями, делаете проекты не в стол, а для клиентов и всерьёз думаете о «секурности» — полезно следить за обновлениями в этом документе.
Итак, какие уязвимости больших языковых моделей выделяет OWASP и чем может грозить их эксплуатация злоумышленниками?
Prompt Injection
Внедрение в промпт, инъекции в промпт
Социальная инженерия работает и с машинами! Одни злоумышленники используют уловки в своей речи, чтобы выудить конфиденциальные данные у людей. Другие схожим образом экспериментируют с промптами, чтобы заставить языковую модель действовать выгодным себе образом в ущерб другим.
Хитро сконструированным промптом можно вынудить модель выдать конфиденциальную информацию или выполнить вредоносные действия. Для этого в промпт добавляют скрытые инструкции. Модель интерпретирует их как команды — и выполняет
Как с этим бороться?
- Аутентификация пользователей — это база. Доступ к агенту только после авторизации значительно снижает риск атак. Злоумышленнику необходимо сначала скомпрометировать учётную запись, уполномоченную использовать модель. Не панацея, но хороший первый шаг.
- В архитектуре приложения разделяют привилегии между двумя моделями. Одна, привилегированная, работает только с доверенными данными, другая, карантинная, обрабатывает входные данные, не имея доступа к критической информации.
- С помощью специальных систем фильтрации входящие промпты проверяют на наличие подозрительных/вредоносных инструкций. Правила фильтрации регулярно обновляют по мере возникновения новых угроз и уязвимостей.
Insecure Output Handling
Неосторожное обращение с текстом от LLM
Это происходит, когда ответ от LLM-агента пользователи воспринимают как заведомо безопасный и обращаются с ним без должных мер предосторожности. Текст ответа от LLM получает доступ к бэкенд-системам — это может быть текст, который LLM получила от злоумышленника, и в нём содержится, например, вредоносный код или злонамеренные инструкции.
Это может обернуться типичными уязвимостями в приложениях — межсайтовому скриптингу (XSS), межсайтовой подделке запросов (CSRF), межсайтовой подделке запросов на сервере (SSRF), опасной эскалации привилегий агента или удалённому выполнению кода на серверной стороне.
Как с этим бороться?
- К LLM стоит относиться как к любому другому пользователю — применять «политику нулевого доверия» и валидацию входных данных. Не нужно изобретать велосипед — можно соблюдать The OWASP Application Security Verification Standard (ASVS), стандарт безопасности приложений.
- Прежде чем отправлять ответ модели пользователям — его нужно закодировать. Это не позволит выполнить вредоносный код JavaScript или Markdown, если злоумышленник включил его туда.
- Если нужно выполнить код, полученный моделью от пользователя — это делают в «песочнице».
Training Data Poisoning
Отравление обучающих данных
Из самого термина понятно — злоумышленник внедряется в датасет, на котором обучается языковая модель. Он может либо подменять эти данные или проводить их тонкую настройку (fine tuning) в своих интересах. Через API или с помощью сотрудника внутри компании отравленные данные попадают в обучающий набор, а затем и в саму модель. Так в LLM можно ввести уязвимости и бэкдоры или, например, заставить её отвечать на запросы пользователей нужным злоумышленнику образом.
Как с этим бороться?
- Строго валидировать обучающие данные, внедрить протоколы проверки данных, фильтровать и очищать данные перед их использованием.
- Поддерживать прозрачность в процессе сбора и обработки данных, внедрить систему отслеживания источников обучающих данных.
- Регулярно анализировать, как отвечает модель на запросы пользователей. Эта простая операция позволит регулярно чекать модель на адекватность и в случае подозрений проверить датасет на предмет наличия инъекций.
- Выявлять подозрительные, аномальные паттерны в данных, которые могут указывать на вмешательство, с помощью алгоритмов машинного обучения.
Model denial of service (DoS)
Отказ. Модель просто отказывается работать.
Есть несколько способов устроить DoS-атаку на LLM:
— Затопить модель огромным количеством запросов, заставляющих её работать на износ.
— Использовать специальные хитрые запросы, обработка которых требует больших вычислительных ресурсов.
— Вводить запросы большой длины. Модель атакуют последовательными запросами, которые приближаются к пределу контекстного окна модели, что вызывает большую нагрузку на систему.
Такая сверхнагрузка либо «кладёт» сервис, либо заставляет его тратить огромное количество ресурсов.
Как с этим бороться?
- Старая добрая валидация и фильтрация входных данных. Входящие запросы проверяют на соответствие лимитам и наличие подозрительного контента.
- Устанавливают ограничения на ресурсы, затрачиваемые моделью на каждый запрос, чтобы предотвратить выполнение слишком сложных операций.
- Ограничивают частоту запросов — то есть количество, которое может отправить один пользователь или IP-адрес за определённый период.
- Постоянно мониторят ресурсозатраты модели. Если система мониторинга показывает резкий всплеск затрат — можно быстро выявить и остановить атаку.
Supply Chain Vulnerabilities
Уязвимость в «цепочке поставок»
Любое приложение — система, включающая несколько (или множество) подсистем. На конечный результат для пользователя в приложении могут работать базы данных, плагины, предварительно обученные модели, библиотеки и другие сторонние компоненты. Каждый из них — потенциальное окно для уязвимости.
Supply Chain Vulnerabilities — скорее зонтичный термин для всех типов атак на любом из этапов работы приложения. Результатом могут стать скомпрометированные библиотеки или компоненты, используемые в процессе разработки, отравленные обучающие данные и т. д.
Могут быть разными и цели злоумышленников — от кражи данных и манипуляции результатами до создания дезинформации и подрыва доверия к системе.
Как с этим бороться?
- Регулярный аудит безопасности и надёжности поставщиков и компонентов, используемых в процессе разработки и развертывания LLM.
- Применение проверенных и поддерживаемых библиотек и компонентов, отказ от использования устаревших или неподдерживаемых решений.
- Валидация и фильтрация данных, используемых для обучения моделей.
- Обучение сотрудников вопросам безопасности и важности соблюдения протоколов безопасности в цепочке поставок.
- Интеграция инструментов для управления рисками в цепочке поставок и мониторинга уязвимостей в реальном времени.
Sensitive Information Disclosure
Раскрытие чувствительных данных
В своих ответах LLM может непреднамеренно «сдать» важную информацию, которая попала в неё вместе с обучающими данными.
Это может произойти случайно — тогда эту информацию получает законопослушный пользователь, не имеющий в виду использовать эти данные в своих целях. А может быть и так, что злоумышленник с помощью специально сконструированных промптов выясняет, что в обучающем датасете есть приватные данные, и вытягивает их.
Как с этим бороться?
- Традиционно — валидация данных. Необходимо тщательно проверять и очищать обучающие данные, чтобы в них не попала чувствительная информация.
- И снова валидация данных — на этот раз входных. Инженеры внедряют системы фильтрации входящих запросов от пользователей.
- Полезно информировать пользователей о рисках взаимодействия с LLM и напоминать, что в промптах не стоит отдавать чувствительную информацию.
Insecure Plugin Design
Уязвимость, связанная с использованием в приложениях небезопасных плагинов
Злоумышленники могут использовать несколько методов для эксплуатации уязвимости:
Плагины могут принимать на вход текст без проверки. Этим могут воспользоваться злоумышленники, чтобы вводить вредоносные команды или запросы. Например, если плагин принимает параметры в одном текстовом поле, а атакующий внедряет в них SQL-запросы.
Если плагины не имеют строгих мер контроля доступа, злоумышленники могут получить доступ к функциям, которые не должны быть доступны. Это может привести к выполнению несанкционированных действий.
Плагины могут излишне доверять входным данным от других плагинов и не проверять их. Атакующий может воспользоваться этим и заставить плагин выполнить вредоносные действия.
Цели атакующих могут варьироваться от кражи конфиденциальной информации до выполнения удалённого кода и эскалации привилегий.
Как с этим бороться?
- Строгая валидация и фильтрация входных данных. Внедрение параметризованного ввода и проверки всех данных, поступающих в плагины.
- Контроль доступа. Рекомендуется всегда придерживаться принципа наименьших привилегий для всех плагинов, чтобы минимизировать доступ к критическим функциям и данным.
- Регулярные проверки и тестирование. Стоит регулярно проводить аудиты безопасности для выявления уязвимостей в плагинах и их исправления.
- Аутентификация и авторизация. Нужно использовать надёжные методы аутентификации (например, OAuth2) для доступа к функциям плагинов.
Excessive Agency
Избыточная агентность (то есть автономность, самостоятельность) модели
Злоумышленники могут использовать несколько методов, чтобы эксплуатировать избыточные права, выданные модели:
- Неправильная настройка доступа. Если LLM или её плагины имеют слишком широкие права доступа, злоумышленники могут манипулировать моделью для выполнения несанкционированных действий — отправки электронных писем или выполнения финансовых транзакций.
- Атаки с помощью некорректных запросов. Злоумышленники могут формулировать промпты, которые заставляют модель выполнять действия, не предусмотренные её функциональностью. Например, они могут убедить модель выдать возврат средств на сумму, превышающую допустимую.
Цели атакующих могут включать кражу средств, манипуляцию данными и дезинформацию пользователей.
Как с этим бороться?
- Установить чёткие ограничения на автономию LLM и обеспечить контроль за критическими действиями со стороны человека.
- Ограничить функции плагинов только необходимыми возможностями, чтобы избежать случайных или вредоносных действий.
- Обеспечить явное согласие пользователя перед выполнением любых действий от его имени.
- Применять принцип наименьших привилегий для всех функций и проверять права доступа перед выполнением действий в системах.
- Внедрить системы мониторинга, чтобы отслеживать действия модели и быстро реагировать на нежелательные действия.
Overreliance
Чрезмерное доверие к LLM
Первое правило работы с приложениями на базе LLM — критически осмыслять поставляемую ими информацию, проверять важные факты. Безоглядное доверие ко всему, что «говорит» ИИ, может спровоцировать нежелательные последствия, в том числе юридические или репутационные. Оно может привести к распространению дезинформации, принятию неверных решений и возникновению уязвимостей в системах. Масштаб бедствия зависит от того, в какой сфере работает приложение и того, какие решения людей зависят от контента, поставляемого LLM.
Как злоумышленник может воспользоваться этим:
- Распространение дезинформации. Злоумышленник может вводить в модель ложные данные, что приведет к созданию и распространению недостоверной информации. Мишенью могут стать СМИ, которые доверяют LLM генерацию контента.
- Интеграция небезопасного кода. Разработчики могут без проверки использовать код, сгенерированный LLM, который содержит уязвимости или небезопасные практики — и вся системы будет скомпромтирована.
- Ошибочные решения. Когда системы принимают решения на основе выводов LLM без должной проверки, это может привести к неверным рекомендациям по продуктам или недооценке угрозы.
- Цели злоумышленников могут включать создание дезинформации, манипуляцию пользователями и внедрение уязвимостей в программное обеспечение.
Как с этим бороться?
- Защищать модели с помощью шифрования.
- Внедрять строгие меры контроля доступа — например, двухфакторную аутентификацию, чтобы дать доступ только авторизованным пользователям.
- Укреплять правовую защиту модели через патенты. Это даст основания для юридических действий в случае кражи.
- Мониторить несанкционированное использование модели.
- Ограничить доступ модели к сетевым ресурсам и внутренним API, чтобы предотвратить внешние атаки, а в случае чего — и утечки данных.
- Проводить регулярный мониторинг и аудит логов доступа для выявления подозрительного поведения.
Model Theft
Кража предобученной проприетарной модели
Такое тоже бывает — языковую модель, на обучение которую компания затратила множество ресурсов, просто уводят.
Как результат — злоумышленники могут найти в ней чувствительные корпоративные данные, нанести финансовый урон или просто воспользоваться вашим трудом, чтобы конкурировать с вами в вашей же нише.
Вот как это может произойти технически:
- Взлом инфраструктуры. Атакующие могут воспользоваться уязвимостями в системах безопасности компании, чтобы получить доступ к репозиториям моделей и скачать их.
- Обратная разработка (Reverse Engineering). Злоумышленники могут исследовать уже развёрнутые модели, чтобы понять их архитектуру и параметры — и создать аналогичную модель.
- Атаки через побочные каналы. Используя побочные каналы, злоумышленники могут извлекать веса модели и другую конфиденциальную информацию.
Как с этим бороться?
- Шифровать данные и защищать коммуникации между компонентами системы.
- Вводить случайные задержки в обработку запросов для затруднения анализа времени отклика.
- Изолировать процессы — то есть разделять критические операции и данные от других для снижения риска утечки информации.
- Регулярно отслеживать активности системы для выявления аномалий и потенциальных атак.