Команда реагування на інциденти Hugging Face спочатку звернулася до передових ШІ-моделей для аналізу збою в виробничій інфраструктурі компанії, але моделі відмовили в допомозі. Комерційні захисні бар’єри, створені для протидії зловмисникам, блокували кожен запит на проведення розслідування, оскільки вони сприймали реальні дані про експлойти команди реагування так само, як і реальну атаку.
Зловмисник, автономний ШІ-агент, який проводив кампанію від початку до кінця, протягом вихідних непомітно переміщувався по інфраструктурі Hugging Face, залишаючись необізнаним і нестриманим.
Керівники з безпеки швидко розпізнали закономірність і діагностували, що пішло не так. «Я бачила подібне під час вправ з червоною командою та внутрішнього тестування безпеки, але це один з перших гучних прикладів, коли це суттєво вплинуло на реальне реагування на інциденти», — заявила Меррітт Беар, старший радник Andesite, G2I та AppOmni, а також колишній заступник директора з інформаційної безпеки AWS.
За словами Беар, ніщо з цього не є унікальним для Hugging Face. «Комерційні передові моделі оптимізовані для запобігання зловживанням. Вони, як правило, не мають криптографічних чи організаційних механізмів для визначення, чи є особа, яка запитує «проаналізуй цей шкідливий програмний код», співробітником служби реагування на інциденти, чи автором шкідливого програмного забезпечення».
Шкідливий набір даних відкрив два шляхи виконання коду
16 липня Hugging Face повідомила, що система автономного ШІ-агента скомпрометувала її виробничу інфраструктуру, отримавши несанкціонований доступ до обмеженого набору внутрішніх наборів даних та кількох облікових даних сервісів. Компанія підтвердила, що її ланцюжок постачання програмного забезпечення чистий, і не виявила жодних ознак втручання у загальнодоступні моделі, набори даних чи Spaces.
Hugging Face все ще оцінює, чи торкнулося вторгнення будь-яких даних партнерів чи клієнтів, і заявляє, що за потреби зв’яжеться з постраждалими сторонами безпосередньо. Але мало хто з корпоративних загрозливих моделей передбачав зловмисника, з яким зіткнувся Hugging Face. Автономний агент керував усією кампанією від початкового доступу до збору облікових даних. Жодна людина його не скеровувала.
Точка входу — це шкідливий набір даних. Коли конвеєр обробки даних завантажив його, набір даних викликав виконання коду двома шляхами: через завантажувач віддаленого коду та через вразливість ін’єкції шаблону у файлах конфігурації набору даних. Жодні ворота допуску не перевіряли файл перед тим, як він потрапив до робочого процесу обробки, тобто обчислювального завдання, призначеного для кожного набору даних. Початковий доступ був здійснений через сам конвеєр даних — шлях, який спрацював, оскільки більшість корпоративних команд безпеки вважають дані, що подаються до їхніх конвеєрів, довіреним входом, а не поверхнею атаки.
Ізоляція працівників не витримала. З цієї першої точки опори агент вирвався на вузол, що виконував робоче навантаження, а потім зібрав облікові дані хмари та кластера, достатньо широко масштабовані, щоб дістатися до кількох внутрішніх кластерів, і все це за один вихідний. Hugging Face описала каркас агента як такий, що виконує тисячі окремих дій через рой короткоживучих пісочниць, з самомігруючим командним контролем, розміщеним на публічних сервісах. У розкритті додається, що каркас, здавалося, був побудований на основі дослідницького каркасу безпеки для агентів, що ставить інструментарій, розроблений для роботи червоної команди, за межі реального вторгнення.
Чому запити захисників виглядали як атаки
Слідчі реконструювали понад 17 000 записаних подій за допомогою власних агентів аналізу на основі ШІ.
Перші спроби аналізу журналів проводилися на передових моделях через комерційні API. Кроки захисників включали надсилання реальних команд атаки, корисних навантажень експлойтів та артефактів командного контролю для класифікації, але захисні бар’єри відразу блокували запити.
Беар пов’язала блокування з самими запитами. «Ті самі запити, які є найціннішими під час активного вторгнення — команди оболонки, ланцюжки експлойтів, дампи облікових даних, механізми стійкості, бічний рух — це саме ті запити, які найімовірніше викличуть системи безпеки», — сказала вона VentureBeat. «Оскільки ШІ стає частиною операцій безпеки, це стає проблемою операційної стійкості, а не просто проблемою політики моделі».
Судовий аналіз завершено на GLM 5.2
GLM 5.2, модель з відкритими вагами, розгорнута на власній інфраструктурі Hugging Face, виконала завдання, яке комерційні API відхилили. Жодні дані зловмисника не покинули середовища компанії. «Цей досвід вказує на прогалину, яку варто планувати», — написала компанія у своєму повідомленні. Hugging Face не знає, яка модель живила агентів. Це могла бути зламана модель, що хоститься, або модель з відкритими вагами, що працює без обмежень. У будь-якому випадку, додався звіт, «зловмисник не був обмежений жодною політикою використання, тоді як наша власна судова робота була заблокована бар’єрами розміщених моделей, які ми спробували першими». Hugging Face встановила цю межу сама, написавши, що цей досвід не є аргументом проти заходів безпеки на розміщених моделях, і що вона ділиться відгуками з відповідними постачальниками.
Що змінює автентифікована довіра
За словами Беар, галузь повинна перейти від розгляду безпеки ШІ як проблеми модерації контенту. «Операції безпеки вимагають чогось іншого. Автентифікованої довіри». Замість того, щоб запитувати, чи повинен хтось отримати відповідь, питання полягає в тому, чи повинна її отримати автентифікована команда безпеки, яка діє під контролем підприємства. «Модель повинна розуміти не тільки те, що запитується. Вона повинна розуміти, хто запитує, чому і під яким керівництвом».
«Організації вже будують плани дій на випадок збоїв у хмарі, збоїв постачальника ідентифікації або збоїв EDR», — написала Беар. «ШІ-асистенти стають ще однією залежністю».
Її порада щодо планів реагування на інциденти була прямою. «Зрілий план реагування на інциденти повинен передбачати, що під час серйозного інциденту комерційні ШІ-API можуть відмовляти в запитах, ліміти швидкості API можуть стати недоступними, підключення до Інтернету може бути порушено, а правила управління даними можуть забороняти завантаження судових доказів назовні». Урок, написала вона у своїх письмових відповідях, «не в тому, що «не використовуйте комерційні моделі». А в тому, що «не робіть їх єдиною точкою відмови».
Атаки за допомогою ШІ зросли на 89% порівняно з попереднім роком
Автономні ШІ-керовані атаки не обмежуються ШІ-платформами. Глобальний звіт CrowdStrike про загрози за 2026 рік зафіксував зростання операцій супротивника за допомогою ШІ на 89% порівняно з попереднім роком, а середній час прориву скоротився до 29 хвилин. Підприємства, що використовують ШІ-навантаження у виробництві з агентським доступом до своїх конвеєрів, стикаються з подібною вразливістю.
Шість доменів контролю визначили радіус ураження та швидкість відновлення в Hugging Face. Кожен з них відповідає конкретній дії, яку лідери безпеки можуть вжити до наступного збою автономного агента.
План реагування на збій конвеєра ШІ
|
Домен контролю |
Що зламалося |
Дія на понеділок |
|
Контроль допуску до наборів даних |
Були використані два шляхи виконання коду. Жодні ворота допуску не перевіряли набір даних перед його потраплянням до робочого процесу. Конвеєр даних став інфраструктурою початкового доступу. |
Вимагати виконання в пісочниці та статичний аналіз усіх наборів даних перед їх потраплянням до робочих процесів. За замовчуванням блокувати завантажувачі віддаленого коду та шляхи ін’єкції шаблонів. Аудитувати будь-які шляхи, що надають виконання коду неперевіреному вмісту. Повідомити раду директорів як ризик ланцюжка постачання. |
|
Межі привілеїв від робочого процесу до вузла |
Ізоляція робочих процесів не змогла запобігти підвищенню привілеїв до вузла. Агент отримав облікові дані кластера, оскільки межа між робочим навантаженням та інфраструктурою ніколи не застосовувалася під час виконання контейнера. |
Застосовувати жорсткі межі привілеїв між робочими процесами та вузлами. Розгорнути безпеку виконання контейнерів для запобігання втечі робочого навантаження. Аудитувати, чи можуть робочі процеси отримати доступ до API рівня вузла або сховищ облікових даних. Включити до сфери наступного тестування на проникнення. |
|
Викриття облікових даних |
Облікові дані хмари та кластера були зібрані після доступу до вузла. Масштаб був достатньо великим для бічного переміщення між кількома кластерами протягом вихідних. |
Оновлювати облікові дані за розкладом та після будь-якого попередження про аномалію. Обмежувати мінімальним кластером та сервісом. Розгорнути моніторинг, який відзначає доступ з несподіваних вузлів зі швидкістю машини. Відобразити радіус ураження для звітування раді директорам. |
|
Виявлення на швидкості машини |
Тисячі дій через короткоживучі пісочниці з самомігруючим C2. Виявлення аномалій за допомогою ШІ виявило кампанію після вихідних бічного переміщення, згідно зі звітом. |
Калібрувати виявлення для шаблонів машинного рівня. Переконатися, що сповіщення високої серйозності надходять до відповідальних осіб протягом хвилин, незалежно від часу. Аудитувати правила SIEM для виявлення тисяч короткоживучих виконань протягом однієї години. |
|
Можливості приватного судового аналізу за допомогою ШІ |
Комерційні API блокували судовий аналіз. Бар’єри безпеки перевіряли вміст запитів, а не ідентичність аналітика. Розслідування проводилося на GLM 5.2 приватно. |
Розгорнути потужну модель з відкритими вагами на приватній інфраструктурі до інциденту. Тестувати на реальних робочих процесах судового аналізу. Переконатися, що план реагування на інциденти включає резервний варіант на випадок відмови комерційних API. Документувати прогалину для страхування кібербезпеки. |
|
Моделювання загроз автономних ШІ-агентів |
Кампанія відповідала прогнозованому сценарію атаки з боку агентів, але жодна модель загроз не була операціоналізована. LLM, що живить агента, досі невідома. |
Додати автономних ШІ-агентів як окремий клас супротивників з циклами прийняття рішень на швидкості машини. Провести настільні навчання зі швидкістю агента. Представити результати раді директорам як доказ необхідності перегляду термінів. Включити до заявки на страхування кібербезпеки. |
Питання до ради директорів — операційна стійкість
«Питання для директорів просте: що станеться, якщо один з наших критично важливих інструментів безпеки стане недоступним саме тоді, коли він нам найбільше потрібен?» Беар сформулювала це як операційну стійкість, а не політику ШІ.
Вона б радила радам директорів безпосередньо звертатися до керівництва та вимагати конкретики. «Чи ми справді відпрацьовували цей резервний план під час настільних навчань? Як швидко ми можемо переключитися під час інциденту?» Закупівлі повинні змінюватися разом з управлінням, починаючи з питань, які ставлять покупці. Команди безпеки, що оцінюють постачальників ШІ, повинні запитувати про їхній процес для автентифікованих співробітників служби реагування на інциденти, чи отримують корпоративні клієнти іншу обробку під час перевірених інцидентів, і чи можна розгорнути моделі приватно. «Ці питання належать поряд з доступністю, конфіденційністю та відповідністю», — сказала Беар.
«Найголовніший висновок не в тому, що захисні бар’єри — це «погано». Вони роблять те, для чого були розроблені», — стверджувала вона.
Її головна думка полягає в тому, що сама модель загроз змінилася. «Десятиліттями захисники мали кращі інструменти, ніж зловмисники, тому що вони працювали в довірених корпоративних середовищах. З фундаментальними моделями обидві сторони все частіше використовують одні й ті ж можливості, але одна сторона обмежена корпоративним управлінням, політикою, відповідністю та засобами безпеки, тоді як зловмисник просто завантажує нецензуровану модель з відкритими вагами і продовжує. Це новий вид асиметрії», — додала вона. «Організації, які найкраще справляться з цим, не обов’язково будуть тими, хто має найпотужніший ШІ. Це будуть ті, хто будуватиме ШІ як стійку функцію безпеки, а не як єдиний хмарний сервіс».
Hugging Face локалізувала вторгнення, відновила скомпрометовані вузли, змінила облікові дані та повідомила про інцидент правоохоронні органи. Компанія рекомендує всім користувачам змінити токени доступу та перевірити нещодавню активність облікового запису. Під час інциденту Hugging Face з’ясувала, чи буде доступний її власний інструментарій ШІ, і першою відповіддю було «ні». Лідери безпеки, що використовують ШІ у виробництві, повинні з’ясувати це під час планування реагування на інциденти, перш ніж автономний агент змусить їх до тесту.
Оригінал статті: venturebeat.com