Claude, Codex та Hermes: три моделі ШІ, що встановлювали сторонній код у корпоративні мережі

227 команд встановлення було знайдено в корпоративній документації, які вказують на код, що нікому не належить.

Claude, Codex та Hermes: три моделі ШІ, що встановлювали сторонній код у корпоративні мережі 1 Claude, Codex та Hermes: три моделі ШІ, що встановлювали сторонній код у корпоративні мережі 2

Файли документації на понад 100 вебсайтах містять посилання на потенційно небезпечний виконуваний вміст, який встановлюється автоматично під час відвідування багатьма ШІ-агентами. Кілька десятків компаній, деякі з яких входять до списку Fortune 500, серед тих, хто виконав доказовий код. Принаймні один неправильно налаштований сайт скеровує відвідувачів, як людей, так і ШІ, до активного зловмисного програмного забезпечення.

Потенційно небезпечний вміст міститься у файлах llms.txt та llms-full.txt — це нове правило, яке вебсайти використовують для надання машиночитних зведень вмісту сайту та його загальної структури. Ці файли є еквівалентом стандарту robots.txt для ШІ, який інструктує пошукові системи щодо індексації вмісту сайту. Google Lighthouse, інструмент для допомоги веб-розробникам, має більше інформації тут. Коректно налаштовані файли llms.txt та llms-full.txt для Cloudflare доступні тут і тут.

Як дослідники це виявили

Дослідники з ізраїльського стартапу сканували 6 214 активних доменів, що належать підрядникам оборонної промисловості, компаніям зі списку Fortune 500 та великим технологічним компаніям. З 8 265 знайдених файлів llms.txt та llms-full.txt (багато сайтів містили обидва файли) 120, кожен на окремому сайті, вказували на один або кілька програмних пакетів чи доменних імен, які не були зареєстровані. Щоб протестувати, що станеться, коли ШІ-агент обробляє такі файли, дослідники зареєстрували кілька незайнятих імен і розмістили пакети, які змушували будь-яку машину, що їх виконує, звертатися до їхнього сервера. Протягом години дослідники отримали відповідь від компанії зі списку Fortune 500. Згодом вони отримали ще кілька десятків, деякі від інших компаній зі списку Fortune 500, а інші — від стартапів. Їхній маяк також записував ланцюжок батьківських процесів, які створювали кожне встановлення, зрештою виявивши, що були задіяні кодувальні агенти, зокрема Claude, Codex від OpenAI та Hermes від Nous Research. Anthropic, OpenAI та Nous Research не відповіли на запити про коментарі до моменту публікації.

«Модель довіри зруйнована», — написав один з дослідників, Алон Герц, в інтерв’ю. «Агенти сприймають документацію постачальників як істину в останній інстанції і не ставлять її під сумнів — так само, як і люди, які їх контролюють. Використання агентного ШІ вибухово зростає, і агенти поширюються по всіх рівнях — SaaS, хмари, кінцеві точки. З їхнім розмноженням зростає і поверхня ланцюжка постачань, а сучасні засоби захисту її не охоплюють».

Файли налаштовані неправильно, оскільки вони перелічують неіснуючі пакети з PyPI, npm та інших реєстрів разом з інструкціями щодо їх встановлення. Наприклад, один файл містив запит: «Встановлення: pip install [вилучено на прохання дослідників]». В іншому файлі було: «npm install [вилучено]». Оскільки назви пакетів незареєстровані, зловмисник може зареєструвати одну з них і використовувати її для розміщення програм-вимагачів або будь-якого іншого типу шкідливих пакетів. Вразливість виникає, коли кодувальний агент, що має дозвіл на виконання команд оболонки, розглядає файл як авторитетну документацію для налаштування. Деякі ШІ-агенти завантажують пакет і виконують його. В інших випадках файли LLM вказують на неіснуючі доменні імена. В одному випадку було: «Як приклад написання інтеграційних тестів для [вилучено] додатків, ви можете використовувати фреймворк тестів [Citrus]». Зловмисник може зареєструвати сайт і розмістити на ньому шкідливі інструкції.

Як демонструє PoC дослідників, кодувальні агенти зробили саме це, включаючи деякі, що працювали в найпотужніших компаніях світу. Це далеко не теоретична загроза, вже зараз активно використовується принаймні одна реальна атака. Дослідники знайшли файл LLM, розміщений на легітимному сайті clerk.com. Він містив ої команди встановлення, 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, розміщених на вебсайтах. Інструкції, неявні чи явні, присутні майже скрізь, де переміщується агент. Ця руйнівна межа, у поєднанні з поспіхом великих технологічних компаній впроваджувати ШІ всюди, не викликає теплих і пухнастих почуттів щодо майбутнього, але, безсумнівно, займе безпекових співробітників (або ШІ-агентів, які їх замінять).

Claude, Codex та Hermes: три моделі ШІ, що встановлювали сторонній код у корпоративні мережі 3

Оригінал статті: arstechnica.com

Залишити відповідь

Ваша e-mail адреса не оприлюднюватиметься. Обов’язкові поля позначені *