Один із провідних постачальників веб‑інфраструктури, компанія Vercel, повідомила про кібератаку, у ході якої зловмисники отримали несанкціонований доступ до окремих внутрішніх систем. Ключовою ланкою в ланцюжку компрометації став сторонній AI‑сервіс Context.ai, авторизований через OAuth до облікового запису співробітника Vercel у Google Workspace.
Як стався злам Vercel: ланцюжок атаки через Context.ai та Google Workspace
За офіційною інформацією Vercel, точкою входу стала компрометація стороннього AI‑додатку Context.ai. Сервіс мав OAuth‑доступ до корпоративного акаунта співробітника в Google Workspace, що надало атакувальному доступ до пов’язаних токенів та дозволів.
Скомпрометувавши цей ланцюжок, зловмисник перехопив обліковий запис співробітника й зміг підключитися до низки внутрішніх середовищ Vercel. Зокрема, було отримано доступ до частини змінних середовища (environment variables), які не були помічені як «чутливі» (sensitive).
У Vercel наголошують, що змінні, позначені як sensitive, зберігаються в зашифрованому вигляді та недоступні для прямого читання. На момент публікації компанія не має доказів компрометації цих секретів. Водночас сам факт доступу до внутрішніх оточень свідчить про достатньо глибоке проникнення в інфраструктуру.
Рівень підготовки зловмисника, можливий масштаб витоку та ShinyHunters
Vercel описує атакувального як «складного та добре підготовленого», відзначаючи високу швидкість дій і чітке розуміння внутрішніх систем компанії. Для розслідування інциденту залучено фахівців Mandiant (власність Google) та інших профільних організацій, а також поінформовано правоохоронні органи та сам Context.ai.
За попередніми оцінками, у «обмеженого підмножини клієнтів» могли бути скомпрометовані облікові дані. Цим клієнтам уже розіслані персональні сповіщення з рекомендацією негайно виконати ротацію всіх потенційно уражених ключів і токенів.
Паралельно триває аналіз обсягу ексфільтрованих даних. На хакерських форумах користувач під псевдонімом ShinyHunters заявив про причетність до зламу та запропонував продати нібито викрадені дані за 2 млн доларів. Поки що ці твердження не мають публічного технічного підтвердження, але їх поява додатково підвищує ризики для клієнтів платформи.
Чому змінні середовища стають привабливою ціллю атак
Що можна дізнатися навіть із «несекретних» значень
Інцидент із Vercel демонструє стратегічну важливість змінних середовища для безпеки хмарних сервісів. У них часто зберігаються API‑ключі, токени доступу, паролі до баз даних, конфігурація сервісів та інші секрети.
Навіть якщо частина значень позначена як sensitive і зашифрована, доступ до «несекретних» змінних може розкрити:
- архітектуру застосунку та внутрішні сервіси;
- адреси та імена хостів, БД, мікросервісів;
- схеми й патерни іменування облікових записів та ключів;
- конфігураційні деталі, що полегшують подальший розвиток атаки.
Згідно з галузевими звітами, зокрема Verizon DBIR та IBM Cost of a Data Breach, компрометація облікових даних і секретів стабільно входить до переліку основних векторів атак на хмарну інфраструктуру та SaaS‑платформи. Випадок із Vercel — показовий приклад того, як вразливість у ланцюжку доступів може привести до витоку конфігураційної інформації й далі – до ширших компрометацій.
OAuth та сторонні AI‑сервіси як нова поверхня атаки
Ключовим елементом зламу став OAuth‑доступ стороннього AI‑додатку. Context.ai мав розширені дозволи для роботи з корпоративним акаунтом співробітника в Google Workspace. Після компрометації самого сервісу це перетворилося на ефективний трамплін для атаки на інфраструктуру Vercel.
Компанія рекомендує адміністраторам Google Workspace та власникам акаунтів Google уважно переглянути список виданих OAuth‑доступів і відкликати дозволи в підозрілих або невикористовуваних застосунків. Особливу увагу слід приділити AI‑інструментам, інтегрованим у робочі процеси розробників, DevOps‑команд і аналітиків.
Реакція Vercel: посилення захисту та аудит ланцюга поставок
У відповідь на кібератаку Vercel розгорнула додаткові засоби захисту та моніторингу, а також провела аудит ланцюга поставок (supply chain), щоби підтвердити безпеку ключових open source‑проєктів, зокрема Next.js та Turbopack.
У панелі керування платформи вже з’явилися нові функції безпеки:
- оглядова сторінка змінних середовища для спрощення аудиту й керування;
- поліпшений інтерфейс для створення й адміністрування чутливих змінних середовища;
- розширені рекомендації щодо ротації ключів та управління секретами.
Ці заходи спрямовані як на мінімізацію наслідків поточного інциденту, так і на загальне підвищення рівня кібербезпеки для всіх клієнтів, що розміщують і масштабують веб‑додатки на Vercel.
Практичні рекомендації для захисту хмарної інфраструктури
Історія з Vercel та Context.ai ще раз підкреслює необхідність комплексного підходу до кібербезпеки у хмарних середовищах. Організаціям варто впровадити такі практики:
- Жорстке управління OAuth‑доступом: регулярно переглядати підключені застосунки, мінімізувати їхні права, дотримуватися принципу найменших привілеїв.
- Захищені змінні середовища: позначати всі конфіденційні значення як sensitive, зберігати їх у спеціалізованих системах управління секретами, налаштувати автоматичну ротацію ключів.
- Посилення безпеки Google Workspace: обов’язкове MFA, моніторинг підозрілих входів, обмеження доступу за географією, пристроями й контекстом.
- Оцінка ризиків сторонніх AI‑сервісів: перевірка постачальників, зрозумілі умови обробки даних, обмеження доступу до найчутливішої інформації.
- Централізоване логування й моніторинг: агрегація логів з хмар, CI/CD, SSO та проксі, налаштування кореляції подій і сповіщень про аномалії.
Кожен подібний інцидент — це сигнал переглянути власну стратегію безпеки: проаналізувати усі OAuth‑інтеграції, провести інвентаризацію змінних середовища та секретів, підтвердити належний рівень захисту облікових записів. Чим раніше компанії запровадять зрілі практики управління доступом та секретами, тим менше шансів, що наступна кібератака використає їхню хмарну інфраструктуру як «слабку ланку» у глобальному ланцюгу атак.
