Подвійні агенти в GCP Vertex AI: виявлення небезпечних прогалин у безпеці

Інсайти з дослідження безпеки Vertex AI

Штучний інтелект стрімко перетворюється на потужні автономні системи, здатні виконувати складні завдання та приймати рішення з мінімальним втручанням людини. Google Cloud Platform пропонує платформу Vertex AI з Agent Engine та Application Development Kit (ADK) для розробників, що допомагає створювати і запускати такі агенти.

Але що, як виявиться, що ваш AI-агент насправді працює проти вас? Адже чим більше завдань ми делегуємо агентам і більше дозволів їм надаємо, тим привабливішими вони стають для зловмисників. Зокрема, якщо агент буде ненавмисно неправильно налаштований або зламаний, він може виступити «подвійним агентом»: з одного боку, виконувати свої функції, а з іншого — викрадати дані, підривати інфраструктуру і створювати «backdoor» у найважливіші системи організації.

Наше дослідження показало, як атакуючий може використати Vertex AI Agent Engine у GCP для зловмисних цілей. Зокрема, ми виявили, що стандартні дозволи за замовчуванням у сервісних агентах мають суттєві вразливості, які дозволяють отримати доступ до критичних ресурсів.

Від агента до адміністратора сховища: захоплення споживчих ресурсів

Все почалося з розгортання агента, створеного з використанням Google Cloud ADK. Як з’ясувалося, сервісний агент, який асоціюється з таким AI-агентом, отримує надмірні права за замовчуванням. Зокрема, використовуючи ці дозволи, ми змогли витягти облікові дані сервісного агента і діяти від його імені.

Під час нашого тестування ми створили шкідливого агента, який під час виклику звертався до метаданих інстансу Google, щоб отримати облікові дані, і таким чином отримали необмежений доступ на читання до всіх даних Google Cloud Storage у споживчому проекті. Чи можна уявити, наскільки це небезпечно, коли ваш помічник стає внутрішньою загрозою?

Після виявлення цієї проблеми Google оновив порядок розгортання ADK, але вразливість у наданих за замовчуванням дозволах залишає простір для потенційних загроз.

Несанкціонований доступ до внутрішніх ресурсів Google

Перекидаючись із споживчого на продюсерський проект — тобто безпосередньо до Google-управляємого середовища Vertex AI — ми виявили, що доступ, отриманий через вкрадені облікові дані, відкриває двері до заборонених сховищ образів у Artifact Registry.

Це дозволило скачати контейнери, що є ядром Vertex AI Reasoning Engine, і, що цікаво, отримати уявлення про внутрішню архітектуру та інтелектуальну власність Google. Водночас використання звичайних, користувацьких облікових записів не дає такого доступу, що підкреслює, наскільки критичними є вразливості саме класу сервісних агентів.

Помилкова конфігурація Artifact Registry відкриває додаткові образи

Перебираючи артефакти за допомогою сервісного агента, ми випадково натрапили на численні інші приховані, обмежені репозиторії образів. Цей факт говорить не лише про встановлену надмірну довіру та порушення принципу найменших привілеїв, а й відкриває шлях для зловмисників детально вивчити внутрішню структуру ПЗ Google та шукати слабкі місця.

Доступ до тенант-проекту і небезпечні знахідки

Ще один цікавий момент — доступ до проекту-орендаря, де розташовані самі AI-агенти. Там ми виявили важливі файли, наприклад, Dockerfile.zip, з жорстко прописаною інформацією про внутрішні проекти та сховища Google, які зазвичай не призначені для зовнішнього огляду.

Хоча ми не отримали безпосереднього доступу до згаданого обмеженого bucket, саме витік такої інформації вже можна вважати проблемою, адже це дає потенційним атакам вказівки, куди рухатись далі.

Можливість віддаленого виконання коду

Серед знайдених файлів був code.pkl — pickle-файл Python, відомий через своє небезпечне застосування при роботі з неперевіреними даними. Зокрема, він може спричинити виконання довільного коду, що створює можливість для стійкого бекдору в системі агента.

Як підсумок, використання небезпечних форматів серіалізації при розробці агентових платформ — це тривожний сигнал, який точно варто врахувати.

Широкі OAuth права: загроза робочому середовищу

Що більше, ми виявили, що OAuth 2.0 скоупи, призначені агенту за замовчуванням, є надмірно широкими. Вони охоплюють широкий спектр сервісів Google, включно з Gmail, Drive та календарем. Хоча немає прямого доступу без відповідних IAM дозволів, сам факт такого масштабу за замовчуванням змушує задуматися: а чи не варто обмежувати це сильніше?

Співпраця з Google і рекомендації

Після публікації результатів нашої роботи ми поділилися цими знахідками з командою безпеки Google. Вони оперативно оновили документацію Vertex AI, зробивши її більш прозорою щодо використання ресурсів та сервісних агентів. До речі, зараз рекомендують використовувати власний сервісний акаунт (BYOSA), щоб не передавати агентам надлишкові права.

Ми також обговорили можливі ризики пов’язані з поставками та багатокористувацькою архітектурою. Google підтвердив, що мають механізми, які забороняють несанкціоновану зміну базових образів, що додає впевненості у захищеності виробничої інфраструктури.

Висновки

AI-агенти — це безперечно потужний інструмент, що змінює правила гри у технологіях. Проте, як показало наше дослідження, навіть найпросунутіші системи мають прогалини в безпеці, які можуть обернути їх проти користувачів.

Зокрема, надмірні права та недостатній контроль за дозволами створюють потенціал для перетворення агента у «подвійного агента». Це змушує замислитися: чи готові ми до викликів ери штучного інтелекту, де навіть поєднання нормальних компонентів може породжувати складні проблеми безпеки?

Усвідомлення цих загроз, регламентований контроль доступу, перевірка цілісності коду і обмеження дозволів мають стати невід’ємною частиною процесу впровадження AI у будь-якій організації.

Захист від Palo Alto Networks

Клієнти Palo Alto Networks можуть почуватися більш захищеними завдяки рішенням, таким як Prisma AIRS, Cortex Cloud Identity Security та Cortex AI-SPM. Вони допомагають виявляти загрози у реальному часі, контролювати права доступу та запобігати витокам даних під час роботи AI-агентів.

Якщо ви підозрюєте, що ваша система скомпрометована, до речі, звертайтесь до Incident Response команди Unit 42, яка допоможе оперативно відреагувати на інциденти.