Vercel breach je návod, jak vás OAuth bordel dostane do kolen

Dubnový breach Vercelu nebyl žádný chytrý zero-day v jejich edge síti ani exotický supply chain útok na build pipeline. Byl to zaměstnanec, jeden člověk, který někdy proklikl Google OAuth consent screen pro nějaký AI nástroj třetí strany a udělil mu plný read access do Google Workspace. Read access k mailům, k Drivu, k celé authentikované ploše, kterou ten token zahrnuje. Ten nástroj pak kompromitoval Lumma Stealer, běžný infostealer, který si pronajmete za pár stovek dolarů měsíčně, a útočníci si ten OAuth token odnesli rovnou do prostředí, kterého se nikdy neměli dotknout. Odtud už šlo o laterální pohyb, interní dokumenty a nakonec zákaznické secrety. Co by vás mělo děsit, je to, jak nudný byl každý jednotlivý krok. Žádný génius nebyl potřeba. Jen consent screen, který nikdo nezkontroloval, token, který nikdo nezrušil, a interní prostředí, které věřilo Google identitě trochu moc. Za poslední dva roky jsme dělali bezpečnostní audity pro pár desítek SaaS týmů a skoro každý z nich má přesně tuhle díru otevřenou právě teď. Jen je to zatím nepotkalo. Příběh Vercelu je důležitý proto, že je dokonalou šablonou, krok za krokem ukazuje, jak se z OAuth bordelu a jednoho phishnutého notebooku stane breach, který skončí v post-mortemu se jmény vašich zákazníků.

Zeptejte se sami sebe, hned teď, bez kontroly, kolik aplikací třetích stran má aktivní OAuth grant proti vašemu firemnímu Google Workspace. Nevíte. Nikdo to neví. To je ten skutečný problém, ne to, že by jedna konkrétní aplikace byla zlomyslná. Pokaždé, když se inženýr přihlásí do nového nástroje na poznámky, plánovače kalendáře, AI sumarizátoru meetingů, CRM enrichment widgetu nebo Chrome extension, který chce číst vaše taby, narazí na consent screen, půl vteřiny ho přejede očima a klikne na povolit. Většina těch screenů žádá o scopes, které jsou mnohem širší, než daná feature potřebuje, protože produktové týmy ve výchozím nastavení žádají o všechno, aby se nemusely ptát dvakrát. AI plánovač nepotřebuje https://www.googleapis.com/auth/gmail.readonly, ale stejně si o to řekne, a váš inženýr mu to udělí, protože alternativou je číst seznam scopes a přemýšlet nad ním, a to v úterý ve čtyři odpoledne nikdo nedělá. Nejrychlejší způsob, jak vidět rozsah škod, je Admin SDK. Vytáhněte si seznam tokenů přes directory API, chcete endpoint tokens.list scopovaný per user, a hoďte to do tabulky. Pokud máte zapnuté Google Workspace API, můžete to volat programaticky a vyjmenovat každou trojici (user, application, scopes) napříč celou organizací. Když tým spustí tohle poprvé, většinou najde někde mezi šedesáti a třemi sty různými aplikacemi třetích stran, většinu z nich nikdo nepozná, třetina patří bývalým zaměstnancům a hrstka má scopes, ze kterých se vašemu security člověku fyzicky udělá špatně. Ta tabulka je váš attack surface. Nemůžete bránit graf, který jste nikdy nenakreslili.

Tady je konkrétní verze, ne ta mávání rukama. V Google Admin konzoli jděte na Security, pak Access and data control, pak API controls, pak Manage Third-Party App Access. To UI vám dá lidsky čitelný seznam, ale je pomalé a zahrabává detaily o scopes, takže pro skutečný audit chcete API. Authentikujte service account s domain-wide delegation a scopem https://www.googleapis.com/auth/admin.directory.user.security, pak proiterujte uživatele a pro každého zavolejte tokens.list. Odpověď vám dá clientId, displayText, pole scopes a boolean nativeApp pro každý grant. Hoďte to celé do CSV. Teď to seřaďte podle citlivosti scopes. Cokoliv se scopy gmail, drive, admin.directory nebo cloud-platform jde na vrchol seznamu k review. Porovnejte clientId proti známému allowlistu a všechno, co nesedí, se stává otázkou, kterou musíte zodpovědět nahlas: kdo to autorizoval, používáme to ještě a co by to mohlo přečíst, kdyby to zítra někdo popnul. U aplikací, které nedokážete hned identifikovat, je clientId Google project number, které někdy dohledáte, ale upřímně, většinou je správný tah prostě nejdřív revoknout a nechat toho jednoho člověka, který to fakt potřeboval, přijít si stěžovat. Revokace je tokens.delete, je okamžitá, a zrušený grant, který si někdo znovu autorizuje přes pořádný schvalovací flow, je výrazně lepší než mrtvý grant, co vám hnije v organizaci osmnáct měsíců. Pusťte tenhle audit pravidelně. Minimálně čtvrtletně. My to zadrátujeme do malého Go scriptu, který posílá diff do Slack kanálu, takže nové granty od posledního běhu naskočí automaticky a někdo se na ně fakt podívá.

Vyjmenování vám řekne, kde jste. Fix, který zastaví krvácení, je zajistit, aby žádný nový nekontrolovaný grant nemohl vzniknout bez člověka v procesu. V Google Workspace to najdete pod API controls a nastavení, které chcete, je přepnout app access z Unrestricted na Restricted a pak explicitně nakonfigurovat, které OAuth scopes jsou povolené pro nenakonfigurované aplikace. Nastavte vysoce rizikové skupiny scopes, cokoliv, co sahá na Gmail, Drive, Calendar se zápisem, Admin SDK, na Restricted, aby každá aplikace, která o ně požádá, byla zablokovaná na consent screenu a poslaná do fronty na schválení adminem, místo aby to ospalý inženýr prostě udělil. Námitka, kterou dostanete, je, že to lidi zpomalí, a ano, zpomalí, přesně o tolik tření, které by zastavilo Vercel breach. Inženýr, který chce připojit nový AI nástroj, teď musí podat žádost a admin se podívá na scopes a rozhodne. O to přesně jde. Většina týmů zjistí, že schvalovací fronta je po prvním měsíci klidná, protože opravdu užitečné nástroje se schválí jednou a impulzivní registrace umřou hned u brány. Když už tam jste, zapněte nastavení, které blokuje nová přihlášení do aplikací mimo váš trusted list, a nastavte politiku, že každá aplikace s read scopem na Gmail nebo Drive vyžaduje security review bez výjimky. Pokud jste na Microsoft 365, ekvivalent je Entra admin consent workflow, vypnete user consent pro neověřené vydavatele a vše pošlete přes admin consent requests. Stejná myšlenka, jiná konzole. Princip je, že consent je rozhodnutí admina, ne reflex koncového uživatele.

Druhá půlka lekce z Vercelu je to, co útočník našel, jakmile byl uvnitř. Zákaznické secrety, sedící tam, kde zákaznické secrety sedí, v environment proměnných. Většina týmů má dvouúrovňový mentální model, kde se produkční secrety berou opatrně a všechno ostatní, analytické klíče, feature flag tokeny, takzvaný necitlivý config, zůstává v plaintextu, protože to působí neškodně. Ten model je špatně, protože laterální pohyb nerespektuje vaše štítky citlivosti. Útočník, který si přečte celou vaši sadu env proměnných, dostane mapu vašeho kompletního integračního povrchu a půlka klíčů, které jste označili jako necitlivé, jsou ve skutečnosti tokeny s právem zápisu do služeb třetích stran, které vedou k dalšímu přístupu. Konkrétně na Vercelu označte secrety jako Sensitive, aby byly write-only a nedaly se po nastavení přečíst zpátky přes dashboard ani API, a přestaňte cpát všechno do jednoho sdíleného prostředí, které může číst každý preview deployment. Preview deploymenty jsou notoricky známá cesta úniku, protože škodlivá závislost v PR buildu může vyexfiltrovat jakékoliv env proměnné, které to build prostředí vystaví, a většina týmů dává preview stejné secrety jako produkci, aniž by nad tím přemýšlela. Scopujte secrety per environment. Použijte skutečný secrets manager, Doppler nebo Infisical nebo AWS Secrets Manager, jako zdroj pravdy a synchronizujte ho do platformy, aby rotace byla jedna operace místo manuálního lovu. Rotujte cokoliv, co leží bez rotace déle než rok, protože nemáte jak vědět, jestli to neuniklo do logu, Sentry breadcrumbu nebo úložiště nějakého nástroje třetí strany dva breache zpátky. Env model, který jste si nastavili první den, abyste jeli rychle, je přesně to, co se tisící den stane hromadou kořisti.

Pokud po přečtení tohohle neuděláte nic jiného, udělejte tohle, a udělejte to, než vám další sprint planning sežere odhodlání. Vytáhněte kompletní tokens.list napříč vaší Google Workspace organizací a podívejte se na každý grant se scopem na Gmail nebo Drive. Zrušte všechno, co patří bývalým zaměstnancům, což najdete porovnáním s offboardovacím seznamem, a nějaké najdete, najde každý. Přepněte app access ve Workspace z Unrestricted na Restricted pro vysoce rizikové scopes a postavte frontu na schválení adminem. Projděte si Vercel projekty a označte každou opravdu tajnou env proměnnou jako Sensitive, pak rozdělte preview a produkční prostředí, aby PR buildy nemohly číst produkční klíče. Vyberte jeden AI nástroj třetí strany, který váš tým používá, a fakt si přečtěte scopes, které mu byly uděleny, protože to je ta díra ve tvaru Context.ai, která čeká ve vašem vlastním stacku. Nic z toho není těžké. Je to jedno sobotní dopoledne neslavné práce, které z budoucnosti ve tvaru breache udělá nicotnou událost. Tenhle druh auditu děláme pro klienty ve steezr, většinou jako součást širšího security review, když se tým chystá podepsat enterprise zákazníka, který pošle dotazník o bezpečnosti se šedesáti otázkami, a OAuth graf je skoro vždycky ta část, která tiše hnila, zatímco se všichni soustředili na věci, které působí důležitěji. Vercel post-mortem vám dal přesný playbook, který útočníci použili. To nejmenší, co můžete udělat, je pustit ho nejdřív na sebe.