В документации на более чем 100 сайтах нашли ссылки на потенциально опасный исполняемый контент, который автоматически устанавливается ими агентов искусственного интеллекта. Такой код обнаружился на сайтах нескольких десятков компаний, в том числе и из списка Fortune 500. По меньшей мере один ресурс направлял посетителей к работающему вредоносному ПО.
Потенциально опасный контент находится в файлах llms.txt и llms‑full.txt — новой конвенции, используемой веб‑сайтами для предоставления машиночитаемых сводок содержимого сайта и его высокоуровневой структуры. Эти файлы являются аналогом стандарта robots.txt для ИИ, который инструктирует поисковые системы, как индексировать контент сайта.
Исследователи из стартапа в Израиле просканировали 6214 действующих доменов, принадлежащих оборонным подрядчикам, компаниям из списка Fortune 500 и крупным технологическим компаниям. Из 8265 найденных файлов llms.txt и llms‑full.txt (многие сайты размещали как llms.txt, так и llms‑full.txt), 120 указывали на один или несколько пакетов кода или доменных имен, которые не были зарегистрированы. Чтобы проверить, что происходит, когда агент ИИ обрабатывает такие файлы, исследователи зарегистрировали несколько имён и разместили пакеты, которые заставляли любую машину, выполняющую их, обращаться к их серверу. В течение часа они получили ответ от компании из списка Fortune 500 а потом ещё несколько десятков ответов и от крупных компаний, и от стартапов. Исследователи зафиксировали цепочку родительских процессов, которые породили каждую установку, в конечном итоге выявив участие агентов‑программистов, включая Claude от Anthropic, Codex от OpenAI и Hermes от Nous Research.
«Модель доверия сломана. Агенты воспринимают документацию поставщиков как истину в последней инстанции и не подвергают её сомнению — как и люди, которые их контролируют. Использование агентного ИИ стремительно растёт, и агенты распространяются на все уровни — SaaS, облако, конечные точки. По мере их размножения растёт и поверхность цепочки поставок, а сегодняшние системы её не контролируют», — написал Алон Херц, один из исследователей.
Файлы неправильно настроены, поскольку в них перечислены несуществующие пакеты из PyPI, npm и других реестров вместе с инструкциями по их установке. Например, в одном содержалась подсказка «Установка: pip install [удалено по просьбе исследователей]». В другом файле она выглядела так: «npm install [удалено]». Поскольку имена пакетов не зарегистрированы, злоумышленник может зарегистрировать один из них и использовать его для размещения программ‑вымогателей или любых других вредоносных пакетов. Уязвимость возникает, когда программист, имеющий разрешение на выполнение команд оболочки, рассматривает файл как авторитетную документацию по настройке. Некоторые агенты ИИ затем загружают пакет и запускают его. В других случаях файлы LLM указывают на несуществующие доменные имена. В одном случае это было: «В качестве примера написания интеграционных тестов для приложений [удалено] вы можете использовать тестовую среду [Citrus]». Затем злоумышленник может зарегистрировать сайт и внедрить на него вредоносные инструкции.
Как показывает PoC исследователей, программисты делали именно это, в том числе и те, кто работал внутри некоторых из самых влиятельных компаний мира. Это далеко не теоретическая угроза, так как, по крайней мере, одна активная атака уже использует эту путаницу. Исследователи обнаружили файл LLM, размещённый на легитимном веб‑сайте clerk.com. Он содержал текст: «npx clerk‑next‑fix‑auth‑protection». В отличие от обычной команды установки, npx может загрузить пакет в кэш npm и запустить бинарный файл, не добавляя его в манифест зависимостей проекта. Вскоре исследователи обнаружили, что кто‑то занял ранее пустое место и использовал его для размещения вредоносного ПО.
С тех пор Clerk устранила проблему. Компания также отметила, что если агент уже установил бинарный файл, включённый в пакет @clerk/eslint‑plugin, угрозы не было. В противном случае устанавливался вредоносный пакет. Неясно, привело ли это к реальным заражениям.
Вновь обнаруженная угроза — лишь очередное напоминание о фундаментальных ограничениях ИИ. LLM не могут провести надёжную границу между подлинными инструкциями пользователя, введенными непосредственно в подсказку, и контентом, который они находят в ненадёжных сторонних источниках. Инструкции, которые модели встречают в полученном контенте, могут быть выполнены так же легко, как и любой ввод пользователя, если только правильно построенный механизм защиты, установленный по одному элементу, не препятствует этому. Этот пока неразрешимый недостаток приводит к мгновенным внедрениям.
«Агент не различает страницу и команду. Всё, что он читает, — это ввод, и каждый ввод — это потенциальная инструкция. Это означает, что весь корпус опубликованных данных, которые агенты теперь запрограммированы обрабатывать, незаметно», — написали исследователи.
Исследователи обнаружили 120 неправильно настроенных файлов, содержащих 227 команд для установки несуществующих пакетов или просмотра незарегистрированных доменов. Неясно, как эти ошибочные записи там оказались. Во многих случаях записи появились до эры ИИ и впервые были включены в файлы, не относящиеся к LLM, на веб‑сайте. Это указывает на то, что эти ошибочные записи были созданы вручную людьми. Исследователи подозревают, что другие были созданы ИИ, который либо галлюцинировал, либо, подобно агент ИИ, просматривающий их файл, не мог отличить легитимные инструкции от нелегитимных.
Исследователи пишут:
Когда агент ИИ сталкивается с файлом llms.txt, он видит файл, передаваемый по HTTPS, на официальном домене компании, в стандартизированном формате, разработанном для использования ИИ, опубликованном самой компанией или партнёром, которому она доверяет. Файл является авторитетным источником — в этом вся его цель. Поэтому, когда там написано pip install internal‑tool, агент не останавливается, чтобы проверить, действительно ли internal‑tool принадлежит компании. Он не проверяет пространство имён на PyPI. Он не замечает, что ссылка на документацию указывает на домен, срок действия которого истёк три месяца назад. Он просто делает то, что написано в файле.
Цепочка доверия также транзитивна. Файл llms.txt не обязательно должен находиться на собственном веб‑сайте компании из списка Fortune 500. Агенты получают контекст от доверенных третьих сторон — из документации партнёра, справочника SDK поставщика, руководства по настройке проекта сообщества. Если агент доверяет этой третьей стороне, и файл этой третьей стороны указывает на невостребованный пакет, цепочка работает одинаково.
И обнаружение конечных точек не работает. Для любого EDR или прокси это выглядит как разработчик, использующий легитимный менеджер пакетов: pip install с pypi.org — домена, который уже разрешён всеми корпоративными прокси — с агентом кодирования компания специально установила процесс как родительский. Никаких аномалий. Никаких предупреждений. Сбой происходит на более высоком уровне, в промежутке между инструкцией и выполнением. У конечной точки может не быть шансов, потому что она никогда не задавала правильный вопрос.
«Случай с Clerk — самое наглядное тому доказательство. Команда выглядела точно так же, как и та, которую поставщик мог бы отправить — потому что она была в собственном файле инструкций поставщика. Не хватало только имени в реестре. Все уровни доверия были целы, кроме того, который никто не догадался проверить», — написали исследователи.
Источник этой недавно выявленной проблемы тот же, что и основная причина внедрения вредоносных инструкций. Однако эта новая уязвимость имеет более широкий охват.
«При внедрении вредоносных инструкций кто‑то намеренно внедряет вредоносные инструкции. В данном случае сама инструкция может быть совершенно безобидной и исходить из легитимного источника — реальной документации компании — без участия злоумышленника на момент ее написания. Опасность возникает позже, когда пакет или домен, на который она указывает, заброшен, и кто‑то другой присваивает его себе», — объяснил Херц.
Это означает, что проблема выходит далеко за рамки файлов llms.txt и llms‑full.txt, размещённых на веб‑сайтах. Инструкции, как явные, так и неявные, присутствуют почти везде, где работает агент. размытость проблемы, безусловно, отнимет много времени для решения у специалистов по безопасности.
Ранее Британский Институт безопасности ИИ заявил, что Mythos 5 пыталась выдать себя за человека и выложить на GitHub вредоносный код. Такое поведение агента зафиксировали в ходе эксперимента в закрытой среде.
ссылка на оригинал статьи https://habr.com/ru/articles/1075576/