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