Новая уязвимость в GitHub Copilot и Cursor: как хакеры могут превратить AI-агентов в оружие

Основные положения

Исследователи Pillar Security обнаружили новый опасный вектор атак на цепочку поставок, который назвали «Бэкдор файла правил» («Rules File Backdoor»). Этот метод позволяет хакерам незаметно компрометировать код, сгенерированный ИИ, путем внедрения скрытых вредоносных инструкций в, казалось бы, безобидные файлы конфигурации, используемые Cursor и GitHub Copilot — ведущими в мире редакторами кода на базе ИИ.

‍Используя скрытые символы unicode и сложные методы скрытия полезной нагрузки в файлах конфигурации, злоумышленники могут манипулировать ИИ, чтобы вставлять вредоносный код, который обходит типовые проверки безопасности. Эта атака остается практически невидимой для разработчиков и групп безопасности, что позволяет вредоносному коду незаметно распространяться по проектам.

‍В отличие от традиционных атак с внедрением кода, нацеленных на конкретные уязвимости, «Бэкдор файла правил» представляет значительный риск, поскольку сам ИИ используется в качестве вектора атаки, фактически превращая самого доверенного помощника разработчика в невольного злоумышленника.

Помощники кодирования на основе ИИ как часть критической инфраструктуры

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

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

Файл правил как новый вектор атаки

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

‍Что такое файл правил?

Файлы правил — это файлы конфигурации, которые управляют поведением AI-агента при генерации кода. Они определяют стандарты кодирования, архитектуру проекта и лучшие практики. Эти файлы:

• Общий доступ: хранятся в центральных репозиториях с доступом для всей команды;

• Широкое распространение: распространяются через сообщества с открытым исходным кодом и публичные репозитории;

• Безоговорочное доверие: воспринимаются как безвредные данные конфигурации;

• Редко проверяется: интегрируются в проекты без надлежащей проверки безопасности.

Вот пример файла правил из документации Cursor:

‍Помимо самостоятельного создания файлов правил, разработчики также могут найти их в сообществах и open source проектах:

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

Механизм атаки

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

Атака использует несколько технических механизмов:

1. Контекстное манипулирование: внедрение инструкций, которые кажутся законными, но заставляют ИИ изменять поведение генерации кода;

2. Обфускация Unicode: использование разделителей нулевой ширины, двунаправленных текстовых маркеров и других невидимых символов для сокрытия вредоносных инструкций;

3. Семантический перехват: использование понимания естественного языка искусственным интеллектом с помощью лингвистических шаблонов, которые перенаправляют генерацию кода на уязвимые реализации;

4. Уязвимость между агентами: атака работает с различными помощниками по кодированию ИИ, что указывает на системность уязвимости.

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

Реальная демонстрация: компрометация кода, сгенерированного ИИ в Cursor

Функция Cursor "Rules for AI" позволяет разработчикам создавать инструкции для конкретных проектов, которые направляют генерацию кода. Эти правила обычно хранятся в каталоге .cursor/rules внутри проекта.

Вот как работает атака:

Шаг 1: Создание вредоносного файла правил 

Мы создали файл правил, который кажется безобидным для людей-рецензентов:

Однако фактическое содержимое включает в себя невидимые символы Unicode, скрывающие вредоносные инструкции:

Шаг 2: Создание HTML-файла

Мы использовали AI-агента Cursor с простой подсказкой: «Создайте простую страницу, содержащую только HTML».

Шаг 3: Смотрим на результат

Сгенерированный HTML-файл теперь содержит вредоносный скрипт, полученный с сайта, контролируемого злоумышленником.

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

Распределение полезной нагрузки 

Атакующая нагрузка содержит несколько сложных компонентов.

Давайте рассмотрим различные части и объясним, как это работает:

1. Невидимые символы Unicode: этот метод кодирует всю атакующую нагрузку в текстовом формате, который не обнаруживается рецензентами-людьми, но полностью читаем моделями ИИ. Этот метод обходит любые меры защиты «человек-в-контуре»;

2. Специализированный сторитейлинг: полезная нагрузка использует повествовательную структуру, чтобы обойти этические ограничения ИИ, представляя вредоносное действие как требование;

3. Скрыть журналы и манипулировать разработчиком: инструкции явно приказывают ИИ не упоминать изменения кода в своих ответах, которые могут вызвать подозрения у разработчика. 

Вместе эти компоненты создают высокоэффективную атаку, которая остается незамеченной как на этапе генерации, так и на этапе проверки.

На видео ниже показана атака в Cursor, а также показано, как файлы, созданные ИИ, могут быть отравлены с помощью подмененных файлов правил.

В следующем видео демонстрируется тот же процесс атаки в среде GitHub Copilot, показывающий, как разработчики, использующие помощь ИИ, могут быть скомпрометированы.

Масштаб последствий

Атака «Бэкдор файла правил» может проявляться несколькими опасными способами:

1. Переопределение контроля безопасности: внедрённые вредоносные директивы могут переопределять инструкции безопасности по умолчанию, заставляя ИИ генерировать код, который обходит необходимые проверки. В нашем примере выше, казалось бы, безобидное правило передовой практики HTML было использовано для вставки потенциально вредоносного тега скрипта;

2. Генерация уязвимого кода: инструктируя ИИ включить бэкдоры или небезопасные практики, злоумышленники могут заставить ИИ выводить код со встроенными уязвимостями. Например, вредоносное правило может указать ИИ:

   • Предпочитать небезопасные криптографические алгоритмы;

   • Реализовать проверки подлинности с помощью скрытых обходных путей;

   • Отключить проверку ввода в определенных контекстах.

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

   • Переменные среды;

   • Учетные данные базы данных;

   • API-ключи;

   • Данные пользователя.

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

Анализ поверхности атаки — кто подвержен?

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

Наши исследования выявили несколько векторов распространения:

1. Форумы и сообщества разработчиков: Злонамеренные личности делятся «полезными» файлами правил;

2. Вклад в разработку Open Source: Pull-запросы в популярные репозитории, содержащие заражённые файлы правил;

3. Шаблоны проектов: стартовые наборы, содержащие заражённые правила.

Стратегии смягчения последствий

Для снижения рисков мы рекомендуем следующие технические меры противодействия:

1. Аудит существующих правил: просмотрите все файлы правил в ваших репозиториях на предмет потенциально вредоносных инструкций, уделяя особое внимание невидимым символам Unicode и необычному форматированию.

2. Внедрите процессы проверки: установите процедуры проверки специально для файлов конфигурации ИИ, рассматривая их с такой же тщательностью, как и исполняемый код.

3. Развертывание средств обнаружения: внедрение средств, которые могут выявлять подозрительные шаблоны в файлах правил и отслеживать сгенерированный ИИ-код на предмет признаков компрометации.

4. Просмотрите код, сгенерированный ИИ: обратите особое внимание на неожиданные дополнения, такие как ссылки на внешние ресурсы, необычный импорт или сложные выражения.

Ответственное раскрытие информации

Cursor

• 26 февраля 2025 г.: Первоначальное ответственное раскрытие информации компании Cursor;

• 27 февраля 2025 г.: Cursor ответил, что они расследуют проблему;

• 6 марта 2025 г.: Cursor ответил и определил, что этот риск попадает под ответственность пользователей;

• 7 марта 2025 г.: Pillar предоставила более подробную информацию и продемонстрировала последствия уязвимости;

• 8 марта 2025 г.: Cursor сохранил свою первоначальную позицию, заявив, что это не уязвимость с их стороны.

GitHub

• 12 марта 2025 г .: первоначальное ответственное раскрытие информации на GitHub;

• 12 марта 2025 г .: GitHub ответил и постановил, что пользователи несут ответственность за рассмотрение и принятие предложений, созданных GitHub Copilot.

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

Заключение

Техника «Бэкдор файла правил» представляет собой значительную эволюцию атак на цепочки поставок. В отличие от традиционного внедрения кода, которое использует определенные уязвимости, этот подход превращает в оружие сам ИИ, превращая самого доверенного помощника разработчика в невольного сообщника.

По мере того, как инструменты кодирования ИИ глубоко внедряются в рабочие процессы разработки, у разработчиков естественным образом развивается «предвзятость автоматизации» — тенденция доверять рекомендациям, сгенерированным компьютером, без достаточной проверки. Эта предвзятость создает идеальную среду для процветания этого нового класса атак.

В Pillar Security мы считаем, что защита конвейера разработки ИИ имеет важное значение для защиты целостности программного обеспечения. Организации должны принять специальные меры безопасности, предназначенные для обнаружения и смягчения манипуляций на основе ИИ, выходя за рамки традиционных практик проверки кода, которые никогда не были предназначены для устранения угроз такой сложности.

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

Поставьте мне "лайк" за старания, напишите ваши мысли в комменты и подписывайтесь на мой Телеграм!