Wyciek w Vercel: jak włamanie OAuth skompromitowało zmienne środowiskowe

# Incydent bezpieczeństwa w Vercel: jak wyciek przez OAuth doprowadził do kompromitacji zmiennych środowiskowych

Platforma chmurowego rozwoju Vercel potwierdziła fakt nieautoryzowanego dostępu do wewnętrznych systemów po zhakowaniu konta pracownika za pośrednictwem skompromitowanej aplikacji OAuth w Google Workspace. Incydent był możliwy dzięki wyciekowi danych na zewnętrznej platformie sztucznej inteligencji Context.ai, co pozwoliło atakującemu uzyskać dostęp do zmiennych środowiskowych, które nie były oznaczone jako poufne.

Chociaż główne serwisy Vercel działały bez przerw, a dane klientów w formie zaszyfrowanej pozostały nietknięte, incydent ujawnił krytyczną lukę w zarządzaniu sekretami i zaufaniu do zewnętrznych integracji. Firma niezwłocznie powiadomiła organy ścigania, zaangażowała zewnętrznych ekspertów ds. reagowania na incydenty i wydała aktualizacje interfejsu w celu wzmocnienia kontroli nad poufnymi zmiennymi środowiskowymi.

Jak doszło do włamania

Punktem wyjścia ataku było konto pracownika Vercel w Google Workspace. Atakujący uzyskał do niego dostęp po tym, jak dane tego konta zostały skompromitowane na platformie Context.ai, wykorzystującej AI do automatyzacji procesów pracy. Za pośrednictwem tego konta został autoryzowany token OAuth w imieniu aplikacji o identyfikatorze 110671459871-30f1spbu0hptbs60cb4vsmv79i7bbvqj.apps.googleusercontent.com.

Ta aplikacja, stworzona przez zewnętrzne narzędzie, otrzymała nadmierne uprawnienia, w tym dostęp do wewnętrznych zasobów Google Workspace. Po uzyskaniu tokena atakujący mógł przemieścić się wewnątrz infrastruktury Vercel i uzyskać dostęp do zmiennych środowiskowych, które nie były jawnie oznaczone jako poufne. W takich przypadkach Vercel nie stosuje szyfrowania w spoczynku, polegając na klasyfikacji określonej przez administratora.

Co zostało skompromitowane

Według doniesień z forów hakerskich, atakujący podający się za „ShinyHunters”, ogłosił sprzedaż następujących danych:

• Klucze API (w tym tokeny NPM i GitHub)
• Dostęp do wewnętrznych wdrożeń Vercel Enterprise
• Kod źródłowy wewnętrznych narzędzi
• Baza danych z 580 rekordami pracowników (imiona, firmowe e-maile, status kont, znaczniki czasowe aktywności)
• Zrzuty ekranu z wewnętrznego panelu zarządzania

Vercel oficjalnie potwierdziła jedynie częściowy dostęp do zmiennych środowiskowych i zaprzecza kompromitacji danych klientów lub otwartych projektów, takich jak Next.js i Turbopack. Wszystkie zmienne klientów oznaczone jako sekretne pozostają zaszyfrowane i niedostępne.

Zalecenia Vercel dla deweloperów

Firma stanowczo zaleca wszystkim użytkownikom, zwłaszcza właścicielom kont korporacyjnych, wykonanie następujących działań:

• Sprawdź listę autoryzowanych aplikacji OAuth w Google Workspace i cofnij dostęp podejrzanym lub nieużywanym aplikacjom.
• Przeprowadź audyt zmiennych środowiskowych: upewnij się, że wszystkie wrażliwe dane (klucze API, tokeny, hasła) są oznaczone jako Confidential w interfejsie Vercel.
• Włącz funkcję weryfikacji poufnych zmiennych, która jest teraz dostępna w zaktualizowanym panelu zarządzania.
• Zmień wszystkie klucze i tokeny, które mogły zostać ujawnione, nawet jeśli były przechowywane w niepoufnych zmiennych.
• Skonfiguruj MFA i polityki dostępu warunkowego dla wszystkich kont mających dostęp do infrastruktury.

Lekcje dla zespołów DevOps i SRE

Incydent w Vercel pokazuje, jak podatna na ataki może być łańcuch zaufania przy korzystaniu z zewnętrznych integracji. Nawet w dojrzałej infrastrukturze z wielopoziomową ochroną jeden skompromitowany token OAuth może stać się punktem wejścia do poziomego przemieszczania się.

Kluczowe wnioski dla zespołów technicznych:

• Zasada najmniejszych przywilejów powinna być stosowana nie tylko do użytkowników, ale i do aplikacji OAuth. Uprawnienia muszą być ściśle ograniczone do niezbędnego minimum.
• Automatyczna klasyfikacja sekretów jest lepsza od ręcznej. Jeśli system pozwala na przechowywanie zmiennych bez szyfrowania domyślnie, tworzy to fałszywe poczucie bezpieczeństwa.
• Monitorowanie anomalnej aktywności w dostawcy tożsamości (np. Google Workspace) powinno być częścią strategii SOC. Nietypowe lokalizacje geograficzne, nowe urządzenia lub masowe zapytania do API to sygnały do natychmiastowego cofnięcia tokenów.

Co ważne

• Wyciek rozpoczął się od kompromitacji konta za pośrednictwem zewnętrznej platformy AI Context.ai.
• Dostęp do danych był możliwy z powodu przechowywania wrażliwych zmiennych bez flagi Confidential.
• Dane klientów w formie zaszyfrowanej nie zostały skompromitowane.
• Vercel wydała aktualizacje interfejsu w celu poprawy zarządzania sekretami.
• Atak podkreśla ryzyka związane z integracjami OAuth i zaufaniem do usług third-party.

— Editorial Team