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

41–50 of 131 posts

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

#41

Post by iririririr »

wouldbecouldbe wrote: post #16
losvedir wrote: post #9

Earlier quoted context omitted.

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.

you'd think. but this is a js dev world.

nextjs app bake all env vars on the client side code!! it's all public, unless you prefix the name with private_ or something.

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

#42

Post by _pdp_ »

harikb wrote: post #35
_pdp_ wrote: post #32

Earlier quoted context omitted.

Sensitive does not mean it is not readable. It is just simply not exposed through the UI. It can be easily leaked if you return a bit too much props from the action functions or routes. The only way to defend against these types of issues is to encrypt your environment with your own keys, with secrets possibly baked into source as there are no other facilities to separate them. An attacker would need to not only read…

> with secrets possibly baked into source please don't suggest this. The right way is to have the creds fetched from a vault, which is programmed to release the creds auth-free to your VM (with machine level identify managed by the parent platform) This is how Google Secrets or AWS Vaults work.

I was reffering to Vercel. Other cloud environments have much better mechanisms for securing secrets.

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

#45

Post by jcgl »

harikb wrote: post #35
_pdp_ wrote: post #32

Earlier quoted context omitted.

Sensitive does not mean it is not readable. It is just simply not exposed through the UI. It can be easily leaked if you return a bit too much props from the action functions or routes. The only way to defend against these types of issues is to encrypt your environment with your own keys, with secrets possibly baked into source as there are no other facilities to separate them. An attacker would need to not only read…

> with secrets possibly baked into source please don't suggest this. The right way is to have the creds fetched from a vault, which is programmed to release the creds auth-free to your VM (with machine level identify managed by the parent platform) This is how Google Secrets or AWS Vaults work.

> The right way is to have the creds fetched from a vault, which is programmed to release the creds auth-free to your VM

Or have whatever deployment tool that currently populates the env vars instead use the same information to populate files on the filesystem (like mounting creds).

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

#46

Post by jackconsidine »

hungryhobbit wrote: post #43

Why is this same story repeated over and over here? I get it, it's a big story ... but that doesn't mean it needs N different articles describing the same thing (where N > 1).

New information here -- I had no idea that Env enumeration was happening MONTHS before the disclosure for example and that's part of why I come to HN.

Would guess that double digit percent of readers have some level of skin in the game with Vercel

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

#47

Post by BoorishBears »

anematode wrote: post #39
JauntyHatAngle wrote: post #28

Earlier quoted context omitted.

Blaming AI is gonna be the security breach equivalent to blaming ddos when your website breaks isn't it.

That part of his tweet made me laugh out loud. I don't understand who it's directed toward.

The market. Rauch is 'strategic' like that, he'd even use a moment like this sneak in a sound bite to froth the market he has so much skin in

"Vercel CEO says AI accelerated attack on critical infrastructure"

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

#48

Post by awestroke »

_pdp_ wrote: post #32
westont5 wrote: post #10

I'm not sure I've seen it mentioned yet that when Vercel rolled out their environment variable UI, there was no "sensitive" option https://github.com/vercel/vercel/discussions/4558#discussion... . There was ~2 years or more until it was introduced https://vercel.com/changelog/sensitive-environment-variables...

Sensitive does not mean it is not readable. It is just simply not exposed through the UI. It can be easily leaked if you return a bit too much props from the action functions or routes. The only way to defend against these types of issues is to encrypt your environment with your own keys, with secrets possibly baked into source as there are no other facilities to separate them. An attacker would need to not only read…

The better way to defend against these types of issues is to avoid Vercel and similar providers

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

#49

Post by SAI_Peregrinus »

SoftTalker wrote: post #40
harikb wrote: post #35

Earlier quoted context omitted.

> with secrets possibly baked into source please don't suggest this. The right way is to have the creds fetched from a vault, which is programmed to release the creds auth-free to your VM (with machine level identify managed by the parent platform) This is how Google Secrets or AWS Vaults work.

This is just another layer of indirection (which isn't bad; it adds to the difficulty of executing a breach). The fundamental problem with encrypted secrets is that at some point you need to access and decrypt them.

HSMs & similar can at least time-limit access to secrets to the period where an attacker can make requests to the HSM.

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

#50

Post by kstrauser »

simlevesque wrote: post #38
quentindanjou wrote: post #23

Earlier quoted context omitted.

Usually rotating a credential means that you invalidate the previous one. Never heard of rotating credentials that would only create new ones and keep the old ones active.

But then every rotation would break production, wouldn't it ?

Ideally, you can have a couple of working versions at any given time. For instance, an AWS IAM role can have 0 to 2 access keys configured at once. To rotate them, you deactivate all but one key, create a new key, and make that new key the new production value. Once everything's using that key, you can deactivate the old one.
Post reply on HN