Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Vercel breach: OAuth attack exposes risk in platform environment variables

trendmicro.com

Post reply on HN
Print view View original

11–20 of 131 posts

Re: The Vercel breach: OAuth attack exposes risk in platform environment variables

#11

Post by saadn92 »

What bites people: rotating a vercel env variable doesn't invalidate old deployments, because previous deploys keep running with the old credential until you redeploy or delete them. So if you rotated your keys after the bulletin but didn't redeploy everything, then the compromised value is still live.

Also worth checking your Google Workspace OAuth authorizations. Admin Console > Security > API Controls > Third-party app access. Guarantee there are apps in there you authorized for a demo two years ago that are still sitting with full email/drive access.

Re: The Vercel breach: OAuth attack exposes risk in platform environment variables

#13

Post by lbarrow »

pphysch wrote: post #8
Quarrelsome wrote: post #6

Earlier quoted context omitted.

It's ridiculed because its no protection on its own when an attacker is motivated. Its fine to add as an additional layer though if you want to make your space mildly custom to protect against broader attacks. I don't see how its necessarily relevant to this attack though. These guys were storing creds in clear and assuming actors within their network were "safe", weren't they?

TFA cites "env var enumeration", likely implying someone got somewhere they shouldn't and typed 3 characters, as the critical attack that led to customers getting compromised. My point is sensitive secrets should literally never be exported into the process environment, they should be pulled directly into application memory from a file or secrets manager. It would still be a bad compromise either way, but you have a…

I don't think that's what the attacker did here. Vercel is a PaaS product where other developers run apps. The enumerated environment variables were the env vars of Vercel's customers, which Vercel likely stores in a long-term data store. Rather than running `env` on a Linux box somewhere, the attacker may have just accessed that data store.

Re: The Vercel breach: OAuth attack exposes risk in platform environment variables

#14

Post by wouldbecouldbe »

saadn92 wrote: post #11

What bites people: rotating a vercel env variable doesn't invalidate old deployments, because previous deploys keep running with the old credential until you redeploy or delete them. So if you rotated your keys after the bulletin but didn't redeploy everything, then the compromised value is still live. Also worth checking your Google Workspace OAuth authorizations. Admin Console > Security > API Controls > Third-part…

When you rotate them, you supposed expire your old vars

Re: The Vercel breach: OAuth attack exposes risk in platform environment variables

#15

Post by nyc_data_geek1 »

datadrivenangel wrote: post #7

"Effective defense requires architectural change: treating OAuth apps as third‑party vendors, eliminating long‑lived platform secrets, and designing for the assumption of provider‑side compromise." Designing for provider-side compromise is very hard because that's the whole point of trust...

Corroborates that zero-trust until now has been largely marketing gibberish. Security by design means incorporating concepts such as these to not assume that your upstream providers will not be utterly owned in a supply chain attack.

Re: The Vercel breach: OAuth attack exposes risk in platform environment variables

#16

Post by wouldbecouldbe »

losvedir wrote: post #9
datadrivenangel wrote: post #7

"Effective defense requires architectural change: treating OAuth apps as third‑party vendors, eliminating long‑lived platform secrets, and designing for the assumption of provider‑side compromise." Designing for provider-side compromise is very hard because that's the whole point of trust...

As someone trying to think about OAuth apps at our SaaS, it certainly is very hard. Do any marketplaces have a good approach here? I know Cloudflare, after their similar Salesloft issue, has proposed proxying all 3rd party OAuth and API traffic through them. But that feels a little bit like trading one threat vector for another. Other than standard good practices like narrow scopes, shorter expirations, maybe OAuth C…

I mean the admin account had visibility of clients env vars, thats maybe not really great in the first place.

Re: The Vercel breach: OAuth attack exposes risk in platform environment variables

#20

Post by andrewmcwatters »

pphysch wrote: post #8
Quarrelsome wrote: post #6

Earlier quoted context omitted.

It's ridiculed because its no protection on its own when an attacker is motivated. Its fine to add as an additional layer though if you want to make your space mildly custom to protect against broader attacks. I don't see how its necessarily relevant to this attack though. These guys were storing creds in clear and assuming actors within their network were "safe", weren't they?

TFA cites "env var enumeration", likely implying someone got somewhere they shouldn't and typed 3 characters, as the critical attack that led to customers getting compromised. My point is sensitive secrets should literally never be exported into the process environment, they should be pulled directly into application memory from a file or secrets manager. It would still be a bad compromise either way, but you have a…

[dead]
Post reply on HN