Cryptographic Context Injection — це лише останній спосіб обійти захисні механізми великих мовних моделей (LLM).
Раніше цього тижня дослідники описали атаку, яка використала секретний ввід, наданий Microsoft 365 Copilot для корпоративних користувачів, щоб змусити ШІ-асистента викрасти пароль, який містився в скриньці користувача. Тепер окрема команда розробила подібну атаку проти Grok. Новий злам для викрадення даних використовує напрочуд простий трюк, щоб змусити LLM, що належить Ілону Маску, красти чати користувачів та іншу особисту інформацію. На момент публікації цього матеріалу асистент продовжував надавати дані, незважаючи на те, що xAI було повідомлено про це ще у червні.
Урок з обох випадків цього тижня — і з незліченних інших, що передували їм, — полягає в тому, що LLM не здатні усунути першопричини prompt injections, найсерйозніших класів вразливостей, до яких вони найбільш схильні. Це залишає розробникам ШІ єдиний вибір — створити захисний механізм, який відводить модель від шкідливих дій. Як зазначалося у вчорашній статті, цей підхід еквівалентний тому, як інженер з безпеки дорожнього руху встановлює захисну огорожу навколо небезпечного повороту замість того, щоб безпечно його заокруглити.
Cryptographic Context Injection у справі
Prompt injections використовують особливість LLM навчатися виконувати запити користувачів за будь-якої можливості. Зловмисники можуть скористатися цією схильністю, впроваджуючи шкідливі інструкції в електронні листи або вебсторінки, які асистент отримує для узагальнення. Оскільки LLM не можуть надійно розрізнити контент в електронному листі, надісланому ненадійним відправником, та інструкції користувача, введені безпосередньо в запит, надмірно старанний LLM сумлінно їх виконує. Дотепер єдиним виходом для Grok та інших LLM було створення захисних механізмів, які позначають підозрілі інструкції та забороняють їх виконання.
Роні Утевський, дослідник компанії Adversa, нещодавно виявив простий спосіб повністю обійти це обмеження. Замість того, щоб формулювати шкідливу інструкцію у відкритому тексті, зловмисник шифрує її. Вебсайт, на якому розміщено шифротекст, також містить інструкції у відкритому тексті для розшифрування зашифрованого контенту разом із ключем для розшифрування. Використовуючи цю просту послідовність, Grok виконує команду, як тільки користувач доручає асистенту узагальнити сторінку. Попередження немає, підтвердження не вимагається.
Розшифровані інструкції наказують LLM сформувати те, що видається ключем для розшифрування. Насправді це зовсім інше. Значенням фальшивого ключа є ім’я користувача, його місцезнаходження та історія чатів. Це значення згодом використовується як параметр, доданий до URL-адреси, що веде на сайт зловмисника. Як тільки Grok відкриває посилання, дані потрапляють до логів сервера зловмисника.
Adversa не може з упевненістю сказати, чому Grok відмовляється виконувати ті самі інструкції у відкритому тексті, але виконує зашифровані. Основна теорія полягає в тому, що фільтраційний захисний механізм Grok перевіряє текст, що надходить до моделі та виходить з неї, але не вихідні дані її власного виконання коду. Інструкції для обробки шифротексту за допомогою PBKDF2 та AES-256-GCM проходять фільтр як звичайний запит, оскільки класифікатор може їх прочитати, але не може визначити, що вони розкривають. Після розшифрування додаткові інструкції потрапляють до моделі як вихідні дані її власного інструменту, і вона діє на них без перевірки захисними механізмами.
«Статичні захисні механізми класифікують вхідні дані як текст; вони не виконують їх», — написав Утевський у четвер. «Зловмисник надсилає шифротекст разом із матеріалом ключа та інструкцією для його розшифрування, а модель виконує це розшифрування у власній пісочниці виконання коду. Все, що потрібно сканеру захисного механізму, знаходиться прямо на сторінці, але для відновлення відкритого тексту потрібно виконати PBKDF2 та AES-256-GCM, чого жоден класифікатор контенту не робить під час перевірки».
В електронному листі дослідник зазначив, що такі захисні механізми називаються статичними, «оскільки вони лише зчитують контент як текст. Вони не виконують код і нічого не розшифровують. Саме цю прогалину ми використовуємо. Справжні інструкції зашифровані, тому захисний механізм бачить лише беззмістовний шифротекст і пропускає його».
Adversa використала подібну техніку в атаці на Gemini, що дозволило обійти внутрішні правила безпеки Google LLM. У цьому випадку шифротекст було розшифровано до того, що виглядало як трасування стека. Розшифрований текст містив одне правило: якщо код збою, прочитай повідомлення про помилку та дій відповідно. Відкритий текст впровадив запит, який врешті-решт змусив Gemini порушити правила безпеки.
«Ця техніка призвела до створення багатопараграфного прикладу забороненого контенту, який фільтри безпеки Gemini зазвичай блокують (створення запалювальної зброї)», — заявила Adversa. «За допомогою модифікованого навантаження той самий вектор відтворив системні інструкції Gemini, включаючи директиву, що забороняє їх розголошення».
Adversa не повідомила про цю поведінку Google, оскільки такі обходи захисних механізмів не входять до сфери дії програми компанії з розкриття вразливостей. Однак протягом останніх кількох тижнів Gemini стає все більш стійкою до атаки. «Ми не можемо визначити причину змін — це можуть бути оновлення фільтрів, зміни версії моделі або обидва фактори», — зазначила фірма з безпеки. Дослідники компанії називають цю техніку Cryptographic Context Injection.
«Cryptographic Context Injection є одним із прикладів ширшого зрушення: атаки, які маніпулюють не лише запитом, а й ширшим контекстом, який LLM розглядає як свій власний, наприклад, вихідні дані інструментів, результати виконання та проміжні стани», — заявила Adversa. «Ця поверхня атаки набагато більша, ніж те, що традиційно називають «вхідними даними моделі», і саме там з’являться атаки наступного покоління».
Cryptographic Context Injection — це лише останній приклад невигідного становища, в якому перебувають захисники LLM. Кожного разу, коли вони створюють новий, індивідуальний захисний механізм, зловмисник знаходить новий вектор, який дозволяє автомобілю знову з’їхати з дороги. Цикл триває: намилити, промити та повторити.
За матеріалами: arstechnica.com