227 команд встановлення знайдено в корпоративній документації, що вказують на код, якому ніхто не належить.
Файли документації на понад 100 вебсайтах посилаються на потенційно небезпечний виконуваний вміст, який встановлюється автоматично при відвідуванні багатьма ШІ-агентами. Декілька десятків компаній, деякі з яких входять до списку Fortune 500, виконали доказовий код. Принаймні один неправильно налаштований сайт спрямовує відвідувачів, як людей, так і ШІ, на активне шкідливе програмне забезпечення.
Потенційно небезпечний вміст міститься у файлах llms.txt та llms-full.txt — це нова конвенція, яку вебсайти використовують для надання машинно-читабельних підсумків вмісту сайту та його загальної структури. Ці файли є ШІ-еквівалентом стандарту robots.txt, який інструктує пошукові системи, як індексувати вміст сайту. Google Lighthouse, інструмент для допомоги веброзробникам, має більше інформації тут. Правильно налаштовані файли llms.txt та llms-full.txt для Cloudflare доступні тут і тут.
Як дослідники це виявили
Дослідники з ізраїльського стартапу сканували 6 214 активних доменів, що належать підрядникам оборонної промисловості, компаніям зі списку Fortune 500 та Big Tech. З 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, розміщених на вебсайтах. Інструкції, як явні, так і неявні, присутні майже всюди, де переміщається агент. Ця руйнівна межа, в поєднанні з прагненням Big Tech інтегрувати ШІ всюди, не викликає приємних відчуттів щодо майбутнього, але, безумовно, змусить служби безпеки (або ШІ-агентів, які їх замінять) зайнятися справою.
Оригінал статті: arstechnica.com