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