През последните два месеца писах за пробива във Vercel и пробива в Composio поотделно. И двата случая предлагат ценни уроци сами по себе си. Но когато ги чета заедно, все се връщам към едно и също наблюдение: това не са изолирани инциденти. Това е една и съща атака, извършена два пъти срещу различни цели, при която електронната поща не е била входната точка в работното пространство. И след като видите модела ясно, това променя представата ви за това какво трябва да защитавате.
Това повдига и един неудобен въпрос, за който размишлявам. Моделът, който описвам — при който OAuth предоставянето се използва за достъп до акаунт, четене на чувствителни данни от имейл и Drive и използване на този достъп за придвижване отвъд работното пространство — не описва само това, което правят атакуващите. Той все повече описва това, което AI агентите правят по дизайн всеки ден.
Преди да преминем към тази дискусия, нека отделим момент, за да картографираме веригата на атака срещу работното пространство.
Старият мисловен модел: Опасността се крие в електронната поща
През по-голямата част от последното десетилетие доминиращият мисловен модел за сигурност на работното пространство изглеждаше така: електронната поща е опасният канал, а всичко останало в Google Workspace е сравнително безопасно.
Този модел имаше смисъл, когато киберпрестъпниците се опитваха предимно да откраднат идентификационни данни чрез фишинг. Той вече не е актуален, тъй като атакуващите са се научили да изграждат верижни атаки през работното пространство, а не просто да влизат през входящата поща.
Моделът, с който повечето екипи по сигурност са запознати, изглежда приблизително така:
- Имейлът е входната точка: Злонамерен имейл (фишинг връзка, прикачен файл със зловреден код, убедителен предтекст, подкана, предназначена да пренасочи AI агент) е начинът, по който започват повечето атаки.
- Кражба на идентификационни данни: Атаката води до кражба на валидни идентификационни данни и превземане на акаунта.
- Достъп до чувствителни данни в Gmail и Drive: След като превземането се случи, атакуващият лесно прескача към свързани приложения в Google Workspace.
- Странично преминаване (Lateral pivots): Атакуващ във входящата поща може да нулира пароли и да влезе в допълнителни приложения чрез „магически връзки“ (magic links).
- Установяване на постоянство: Киберпрестъпниците могат да останат незабелязани в акаунтите с дни, седмици или месеци, тихомълком извличайки данни от системите.
Взето заедно, това е кошмарният сценарий, който е широко известен като превземане на акаунт (ATO). Веригата на атака в работното пространство започва с компрометиране на самоличността чрез имейл и се разширява оттам.
Развиващата се верига на атака: OAuth е входната точка
Елементите на веригата на атака срещу работното пространство не са се променили, но редът, в който се развиват атаките, е еволюирал. Последователността, която наблюдавах при Vercel, Composio и нарастващ брой инциденти, които проследяваме, изобщо не започва с имейл. Вместо това сценарият се преобръща и OAuth токенът се превръща във входна точка към имейла, а не обратното.
Ето как изглеждаха тези атаки:
- OAuth е входната точка: Тези атаки започнаха с установяване на постоянство чрез откраднат OAuth токен. Тези токени оцеляват при нулиране на паролата, не изтичат и са трудни за проследяване. Те са невидими за потребителите и до голяма степен невидими за екипите по сигурност, които не наблюдават поведението на приложенията. Още по-страшно е, че откраднатият токен представлява атака срещу веригата за доставки. Доставчик е компрометиран и резултатът е достъп до вашата среда.
- Достъп до чувствителни данни: Използвайки откраднатия токен, атакуващият е успял да получи достъп до данни, съхранявани в Gmail и Drive.
- Превземане на имейл акаунти: Превземането на акаунта (ATO) първоначално се извършва чрез OAuth, а не чрез имейл. Достъпът до имейла превръща компрометираната входяща поща в много по-мащабен инцидент.
- Странично преминаване: Използвайки комбинация от идентификационни данни, съхранени в Drive, и нулиране на пароли или магически връзки чрез имейл, атакуващият може след това да се придвижва странично в свързаните системи.
Можем да предвидим, че градивните елементи на веригата на атака срещу работното пространство ще останат същите, но че атакуващите — оборудвани с AI инструменти за откриване на уязвимости и мащабиране на усилията си — ще продължат да намират начини да ги комбинират отново. Тези атаки, ориентирани към OAuth, са само един пример за тази еволюция.
Същите вериги, различен субект
Сега нека променим начина си на мислене, като запазим тези четиристъпкови последователности, които току-що описах, в съзнанието си.
Вашите служители свързват AI агенти към Google Workspace точно в този момент. Тези агенти са оторизирани. Те използват легитимни OAuth права. Те четат имейли, търсят в Drive, действат от името на реални потребители, за да вършат реална работа. В повечето организации това се случва по-бързо, отколкото екипите по сигурност могат да го проследят.
Когато даден AI агент се държи неочаквано — защото инструкциите му са били двусмислени, защото е последвал логическа последователност, която неговите разработчици не са предвидили, или защото му е била подадена подкана чрез съдържание, на което е попаднал в средата — той може да премине по същия път като атакуващ:
- Той осъществява достъп до входяща поща или папка в Drive, до която не е имал изрично намерение да стигне, тъй като обхватът му е бил по-широк от изискванията на задачата му.
- Той чете чувствително съдържание като идентификационни данни в имейл съобщения или поверителни документи в споделени дискове и използва тази информация.
- Той предприема действие след този достъп: изпращане на съобщение, последване на връзка, правейки заявка към друга услуга.
- Той се придвижва странично между приложенията и чувствителна информация бива извлечена към трета страна.
- Без злонамерен субект. Без компрометирани идентификационни данни. Просто агент, който прави нещо, което неговият оператор не е възнамерявал, в среда, която не е разполагала с контроли за спирането му.
Защо това е важно за начина, по който мислите за защитата
Повечето разговори за сигурността на AI агентите са рамкирани около предотвратяването на инжектиране на подкани (prompt injection), симулиране на атаки (red-teaming) срещу поведението на агентите или преглед на това кои приложения свързват вашите служители. Това са реални проблеми, които си струва да бъдат решени.
Но заплахата, която описвам, не е свързана с това даден агент да бъде използван като оръжие. Тя е свързана с това агентът да работи точно така, както е създаден да работи, в среда, в която защитните механизми не са проектирани с оглед на такъв тип субект. Човек оператор, който действа в среда, където са му предоставени прекомерни права (overpermissioned), обикновено ще знае как да се ориентира в тази ситуация чрез комбинация от здрав разум и разбиране на фирмените норми и политики. OAuth токените, предоставени на AI агент, носят същия достъп като токените, предоставени на човек, но агентът няма да разбере, че му са предоставени прекомерни права, преди да подходи към действие. Той просто ще направи това, което е необходимо, за да изпълни задачата.
Контролите, които имат значение тук, не са контроли върху агента. Те са контроли върху средата, в която агентът оперира.
Ако знаете къде се намират чувствителните данни в имейла и Drive, можете да приложите политики, които ограничават достъпа до тях, преди агент (или атакуващ) да стигне до там. Ако разследвате предоставени OAuth права, можете да разберете и ограничите излагането на риск пред любопитните очи на атакуващ или погрешно действащ агент. Ако можете да редактирате и прикривате (redact) линкове за нулиране на пароли и да изисквате допълнителна верификация (step-up verification), преди чувствителното съдържание в входящата поща да стане четимо, няма значение дали субектът, който се опитва да достъпи това съдържание, е атакуващ или агент, действащ извън предвидения си обхват.
Същото покритие, което защитава от модерната верига на атаката, защитава и от модерния риск, свързан с агентите. Това е един и същ проблем, носещ различни шапки.
Как изглежда защитата в цялата верига
Не мисля, че отговорът е да се добавят още точкови решения (point solutions) за всеки етап от тази верига. Мисля, че отговорът е покритие, което разбира веригата като верига, което може да вижда какво се случва в имейла, OAuth, Drive и поведението на акаунта и да свърже точките, преди нещата да се объркат на стъпка три или четири.
Това е, което изградихме в Material. Ето как нашето покритие се съпоставя с всяка стъпка:
Блокиране на първоначалния злонамерен код в имейла. Нашата сигурност за имейл е проектирана да прихваща това, което вградените контроли пропускат: сложен фишинг, злонамерен код, който заобикаля филтрите, базирани на репутация, и техники от типа „атакуващ по средата“ (attacker-in-the-middle). Спирането на най-честия метод за атака, преди да е започнал, остава най-ефективната интервенция срещу злонамерения субект.
Откриване на подозрително OAuth поведение. Material отива отвъд каталогизирането на това кои приложения съществуват и какви обхвати (scopes) притежават. Платформата наблюдава какво всъщност правят приложенията: какво четат, кога го четат, как това поведение се променя с течение на времето. Независимо дали даден OAuth токен се използва от атакуващ или от AI агент, опериращ извън предвидените си параметри, аномалното поведение на ниво активност изкарва опасността на повърхността.
Откриване и защита на чувствителни данни в покой (data at rest). Не можете да защитите това, което не виждате, и не можете да проектирате политика около достъп, за който не знаете, че съществува. Сигурността на файловете на Material дава на екипите видимост за това къде се намират чувствителните данни в имейла и Drive: кои споделени дискове имат широк достъп, кои имейл нишки съдържат идентификационни данни или лични данни (PII), кои папки в Drive са изложени на достъп извън предвидената им аудитория. Това е основата за прилагане на достъп с най-малко привилегии (least-privilege access) спрямо всеки субект, било той човек или автоматизирана система.
Блокиране на страничното движение (lateral movement) чрез нулиране на пароли. Material може да редактира и скрива чувствително съдържание на съобщения, включително линкове за нулиране на пароли, и да изисква допълнителна верификация, преди това съдържание да стане достъпно. Атакуващ с достъп до входящата поща не може да я използва като опорна точка (pivot point), ако линковете за нулиране не са налични в чист текст. AI агент, достигащ до входящата поща в търсене на нещо, върху което да действа, среща същото ограничение.
Моделът ще се повтори
Vercel. Composio. Очаквам този списък да продължи да расте и очаквам следващите записи в него да не се вписват винаги спретнато в категорията „външен атакуващ“. Някои от тях ще включват AI агенти, правещи нещо неочаквано. Някои ще включват интеграции с прекомерни права, които достигат до данни, които никога не е трябвало да виждат. Механизмът ще изглежда познат, дори когато историята около него не е.
Правилният отговор не е да се тревожим за AI агентите или да забавяме внедряването им. Агентите са наистина полезни и ползата от тях за производителността е реална. Правилният отговор е да признаем, че работното пространство, в което оперират тези агенти, се нуждае от контроли, които са подходящи за свят, в който OAuth-автентифицираният софтуер (оторизиран или не) е субект от първа класа във вашата среда.
- attack
- cybersecurity
- Google Workspace
- Material Security
- opinion