Протягом останніх двох місяців я писав окремо про витік даних Vercel та Composio. Кожен із цих випадків містить окремі уроки. Однак, розглядаючи їх разом, я все частіше повертаюся до одного спостереження: це не ізольовані інциденти.
Це одна й та сама атака, яка була здійснена двічі проти різних цілей, де електронна пошта не була точкою входу до робочого середовища. І як тільки ви чітко побачите цю схему, це змінить ваше уявлення про те, що саме потрібно захищати.
Це також ставить незручне запитання, яке я обмірковую. Описана мною схема, де авторизація OAuth використовується для доступу до облікового запису, читання конфіденційних даних з електронної пошти та Drive, і використання цього доступу для подальшого просування в межах робочого середовища, не тільки описує дії зловмисників. Вона все більше описує дії агентів ШІ за задумом, щодня.
Перш ніж перейти до цього обговорення, давайте виділимо момент, щоб окреслити ланцюжок атак у робочому середовищі.
Стара ментальна модель: небезпека криється в електронній пошті
Протягом останнього десятиліття домінуючою ментальною моделлю безпеки робочого середовища була така: електронна пошта є небезпечним каналом, а все інше в Google Workspace є відносно безпечним.
Ця модель мала сенс, коли зловмисники в основному намагалися викрасти облікові дані за допомогою фішингу. Вона більше не працює, оскільки зловмисники навчилися проходити через робоче середовище, а не просто отримувати доступ через вхідний лист.
Модель, з якою знайомі більшість команд безпеки, виглядає приблизно так:
- Електронна пошта як точка входу: Шкідливий лист (фішингове посилання, зловмисний вкладений файл, переконливий привід, запит, призначений для введення в оману агента ШІ) – це те, з чого починається більшість атак.
- Викрадення облікових даних: Атака призводить до крадіжки дійсних облікових даних та захоплення контролю над обліковим записом.
- Доступ до конфіденційних даних у Gmail та Drive: Після захоплення контролю зловмисник легко отримує доступ до пов’язаних програм у Google Workspace.
- Латеральні переходи: Зловмисник, який знаходиться в поштовій скриньці, може скидати паролі та отримувати доступ до додаткових програм за допомогою “чарівних посилань”.
- Встановлення стійкості: Зловмисники можуть залишатися непоміченими в облікових записах протягом днів, тижнів або місяців, тихо викрадаючи дані з різних систем.
Разом це є нічним кошмаром, який широко визнаний як захоплення облікового запису (ATO). Ланцюжок атак на робоче середовище починається з компромета ідентичності через електронну пошту і розширюється далі.
Дивіться, як Material охоплює кожен крок ланцюжка атак
Ланцюжок атак у цій статті не зупиняється на поштовій скриньці, і ваш захист не повинен зупинятися.
Дізнайтеся, як Material об’єднує безпеку електронної пошти, OAuth та Drive, щоб закрити прогалини, якими користуються як зловмисники, так і агенти ШІ. Замовте демо для вашого Google Workspace.
Request a Demo
Еволюція ланцюжка атак: OAuth як точка входу
Елементи ланцюжка атак на робоче середовище не змінилися, але порядок, у якому відбуваються атаки, еволюціонував. Послідовність, яку я тепер спостерігав у Vercel, Composio та зростаючій кількості інцидентів, які ми відстежуємо, взагалі не починається з електронної пошти.
Натомість, сценарій перевертається, і токен OAuth стає шляхом доступу до електронної пошти, а не навпаки.
Ось як виглядали ці атаки:
- OAuth як точка входу: Ці атаки починалися зі встановлення стійкості через викрадений токен OAuth. Ці токени переживають скидання паролів, не закінчуються терміном дії і їх важко помітити. Вони невидимі для користувачів і значною мірою невидимі для команд безпеки, які не відстежують поведінку додатків. Що ще страшніше, викрадений токен є атакою на ланцюжок постачання. Компрометується постачальник, і результатом є доступ до вашого середовища.
- Доступ до конфіденційних даних: Використовуючи викрадений токен, зловмисник отримував доступ до даних, що зберігаються в Gmail та Drive.
- Захоплення облікових записів електронної пошти: ATO спочатку виконується за допомогою OAuth, а не електронної пошти. Доступ до електронної пошти перетворює скомпрометовану поштову скриньку на набагато ширший інцидент.
- Латеральні переходи: Використовуючи комбінацію облікових даних, збережених у Drive, та скидання паролів або “чарівних посилань” через електронну пошту, зловмисник може потім переміщатися латерально по пов’язаних системах.
Можна передбачити, що будівельні блоки ланцюжка атак на робоче середовище залишаться незмінними, але зловмисники, оснащені інструментами ШІ для виявлення вразливостей та масштабування своїх зусиль, продовжуватимуть знаходити способи їх комбінувати.
Ці атаки, зосереджені на OAuth, є лише одним прикладом цієї еволюції.
Ті самі ланцюжки, інший актор
Тепер давайте змінимо наше мислення, тримаючи в голові чотирикрокові послідовності, які я щойно описав.
Ваші співробітники підключають агентів ШІ до Google Workspace прямо зараз. Ці агенти авторизовані. Вони використовують законні дозволи OAuth. Вони читають електронну пошту, шукають у Drive, діють від імені реальних користувачів для виконання реальної роботи. У більшості організацій це відбувається швидше, ніж команди безпеки можуть це відстежити.
Коли агент ШІ поводиться несподівано — тому що його інструкції були неоднозначними, тому що він слідував ланцюжку міркувань, якого його розробники не передбачали, тому що йому було надано запит через контент, який він зустрів у середовищі — він може пройти тим самим шляхом, що й зловмисник:
- Він отримує доступ до поштової скриньки або папки Drive, до яких йому не було явно надано доступ, оскільки його сфера дії була ширшою, ніж вимагало завдання.
- Він читає конфіденційний контент, такий як облікові дані в ланцюжках електронних листів або конфіденційні документи у спільних дисках, і використовує цю інформацію.
- Він виконує дію після цього доступу: надсилає повідомлення, переходить за посиланням, робить запит до іншого сервісу.
- Він переміщується латерально між програмами, і конфіденційна інформація потрапляє до сторонньої сторони.
Жодного зловмисного актора. Жодних скомпрометованих облікових даних. Просто агент, який робить те, чого не мав наміру його оператор, у середовищі, яке не мало контролю, щоб це зупинити.
Чому це важливо для вашого підходу до захисту
Більшість розмов про безпеку агентів ШІ зосереджені на запобіганні впровадженню запитів (prompt injection), тестуванні поведінки агентів на проникнення, або перегляді того, які програми підключають ваші співробітники. Це реальні проблеми, які варто вирішувати.
Але загроза, яку я описую, стосується не зловмисного використання агента. Вона стосується агента, який діє саме так, як він був створений, у середовищі, де захисні бар’єри не були розроблені з урахуванням такого типу актора.
Людина-оператор, яка діє в середовищі, де їй надано надмірні дозволи, зазвичай знатиме, як впоратися з цією ситуацією, використовуючи комбінацію здорового глузду та розуміння норм і політик компанії.
Токени OAuth, надані агенту ШІ, мають такий самий доступ, як і токени, надані людині, але агент не розумітиме, що йому надано надмірні дозволи, доки не почне діяти. Він просто робитиме те, що йому потрібно, щоб виконати завдання.
Контролі, які мають значення тут, — це не контролі над агентом. Це контролі над середовищем, у якому діє агент.
Якщо ви знаєте, де зберігаються конфіденційні дані в електронній пошті та Drive, ви можете застосовувати політики, які обмежують доступ до них, перш ніж агент (або зловмисник) отримає до них доступ. Якщо ви розслідуєте дозволи OAuth, ви можете зрозуміти та обмежити доступ для сторонніх очей зловмисника або помилкового агента.
Якщо ви можете редагувати посилання для скидання паролів та вимагати додаткової верифікації перед тим, як конфіденційний вміст поштової скриньки стане доступним для читання, не має значення, чи є сутністю, яка намагається отримати доступ до цього вмісту, зловмисник або агент, який діє поза межами своїх призначених параметрів.
Таке ж покриття, яке захищає від сучасного ланцюжка атак, також захищає від ризиків сучасних агентів. Це одна й та сама проблема, що виглядає по-різному.
Як виглядає захист по всьому ланцюжку
Я не думаю, що відповідь полягає в додаванні більше точкових рішень до кожного етапу цього ланцюжка. Я думаю, що відповідь — це покриття, яке розуміє ланцюжок як ланцюжок, яке може бачити, що відбувається в електронній пошті, OAuth, Drive та поведінці облікових записів, і з’єднувати крапки, перш ніж щось піде не так на третьому або четвертому кроці.
Саме це ми побудували в Material. Ось як наше покриття відповідає кожному кроку:
Блокування початкового корисного навантаження електронної пошти. Наша система безпеки електронної пошти розроблена для виявлення того, що пропускають вбудовані засоби контролю: складний фішинг, корисні навантаження, які обходять фільтри на основі репутації, техніки “атакуючого посередині”. Зупинка найпоширенішого методу атаки, перш ніж вона почнеться, залишається найбільш ефективним втручанням для зловмисної загрози.
Виявлення підозрілої поведінки OAuth. Material виходить за рамки каталогізації того, які програми існують і які сфери дії вони мають.
Платформа відстежує, що роблять програми: що вони читають, коли вони це читають, як ця поведінка змінюється з часом. Незалежно від того, використовується токен OAuth зловмисником або агентом ШІ, що діє поза межами його призначених параметрів, аномальна поведінка на рівні активності виявляє небезпеку.
Виявлення та захист конфіденційних даних у стані спокою. Ви не можете захистити те, що не можете побачити, і ви не можете розробити політику доступу, про існування якого ви не знаєте.
Система безпеки файлів Material надає командам видимість щодо того, де знаходяться конфіденційні дані в електронній пошті та Drive: які спільні диски мають широкий доступ, які ланцюжки електронних листів містять облікові дані або PII, які папки Drive доступні ширшому колу осіб, ніж передбачалося. Це основа для застосування мінімальних привілеїв доступу проти будь-якого актора, людського чи автоматизованого.
Блокування латеральних переходів через скидання паролів. Material може редагувати конфіденційний вміст повідомлень, включаючи посилання для скидання паролів, та вимагати додаткової верифікації перед тим, як цей вміст стане доступним.
Зловмисник з доступом до поштової скриньки не може використовувати його як точку опори, якщо посилання для скидання не доступні у відкритому тексті. Агент ШІ, який отримує доступ до поштової скриньки в пошуках чогось для дії, стикається з таким самим обмеженням.
Схема буде повторюватися
Vercel. Composio. Я очікую, що цей список буде рости, і я очікую, що наступні записи в ньому не завжди будуть чітко вписуватися в категорію “зовнішній зловмисник”.
Деякі з них будуть включати агентів ШІ, які роблять щось несподіване. Деякі будуть включати надмірно надані інтеграції, які отримують доступ до даних, які вони ніколи не повинні були бачити. Механізм виглядатиме знайомим, навіть коли історія навколо нього — ні.
Правильна реакція — це не панікувати щодо агентів ШІ або уповільнювати їх впровадження. Агенти є надзвичайно корисними, і переваги їх використання для підвищення продуктивності реальні.
Правильна реакція — це визнати, що робоче середовище, у якому діють ці агенти, потребує контролю, відповідного світу, де програмне забезпечення, автентифіковане через OAuth (авторизоване чи ні), є першочерговим актором у вашому середовищі.
Якщо ваша стратегія безпеки Google Workspace закінчується на поштовій скриньці, у ній є прогалина. Ця прогалина — це саме те місце, де проходить сучасний ланцюжок атак, і це саме те місце, де пройде агент ШІ, що діє поза межами свого призначеного обсягу.
Якщо ви хочете обговорити, як виглядає повне покриття робочого середовища для вашого середовища, зв’яжіться з нами в Material Security.
Спонсоровано та написано Material Security.
Подробиці можна знайти на сайті: www.bleepingcomputer.com