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

121–130 of 131 posts

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

#121

Post by _the_inflator »

Vercel did a great job with NextJS and supports quite some OS projects.

But even before AI they had some serious struggles according to long time users.

With the introduction of the deployment platform NextJS appeared to be having advantages being deployed there.

What I can say is that Next has some weird things going on under the hood most senior coders know as “it works, no one knows why, don’t touch these 1.000 LoC here”

Build and runtime settings are a mess. Pre building a docker image on a local machine and deploying it on another turned out to be its Achilles Heel. Weird settings prioritize not as documented, different settings in one area lead to changes in default settings somewhere else. ReactJS server components played a role.

In other words: I sense that while being incredibly useful there might more to come.

It ain’t easy for them, V16 was a rewrite which was API stable. I am not sure about that.

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

#122

Post by NewJazz »

cortesoft wrote: post #70
simlevesque wrote: post #38

Earlier quoted context omitted.

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

rotations are usually two phased. Add new secret/credential to endpoint, and both new and old are active and valid. Release new secret/credential to clients of that endpoint, and wait until you dont see any requests using the old credential. Then you remove the old credential from the endpoint.

Note that you risk reinfection if the attacker can somehow retain access while you rotate out secrets...

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

#125

Post by miki123211 »

nopointttt wrote: post #93
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...

A sensitive flag at the UI layer doesn't actually change runtime. Once it's in process.env during a build, any dep that decides to grep it can. The real problem isn't a missing checkbox, it's that we still stuff every secret into one env bag and hand the build tools the whole bag. Cloudflare scoped bindings and Fly already split it up, other platforms are just slower.

Yes.

Ideally, your application code shouldn't ever need to see your secrets, those should only be accessible to tiny components that only expose the operations that the app actually needs to do.

Instead of your app having an OPENAI_API_KEY, there should be some kind of external HTTP proxy that adds this key whenever the right endpoint is called.

A man can dream though.

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

#127

Post by cosgrove »

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…

In case anyone is wondering, here is the proposal from Cloudflare: https://blog.cloudflare.com/saas-to-saas-security/

TL;DR: visibility and control for all connections (marketplace apps, 4th parties) to your 3rd party SaaS platforms. See which connections are active as well as when and how much they transmit. Transparent token splitting to force connections through the proxy as well as instant token revocation and ACLs.

We are currently building this and would appreciate your feedback!

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

#128

Post by brianwmunz »

Blaming "AI-accelerated tradecraft" for a breach that started with an OAuth token hijack from a compromised Google account is...interesting. The attacker didn't need AI they needed a stolen session and too many people with production access. Sounds like an access control thing

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

#129

Post by luisfdias »

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.

+1 on vaults. One step further: credentials that never land in the runtime environment at all. App authenticates to a gateway via workload identity, gateway proxies the call, process never sees the secret. Makes env enumeration useless even with valid admin access (I work on an open-source tool in this space, so I'm biased).

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

#130

Post by kyle-rb »

TeMPOraL wrote: post #96
kyle-rb wrote: post #86

Earlier quoted context omitted.

I guess what's unusual is that the scope includes inbox access . IMO it's probably a bad idea to have an LLM/agent managing your email inbox. Even if it's readonly and the LLM behaves perfectly, supply chain attacks have an especially large blast radius (even more so if it's your work email).

It's a bit of a pickle, given that managing your inbox (or at least reading it, classifying and summarizing contents, identifying action items etc.) is one of the most valuable applications of LLMs today, especially if you move beyond software developers having LLMs write code for them.

I do think it's a tempting use case, but there are precautions that up I would take if I was doing this sort of thing. Off the top of my head:

- Set up a separate inbox just for the agent, with a forwarding rule that passes on most things that land in my Gmail, but omits as many verification token/password reset emails as possible.

- Have the agent alert me when any sensitive emails do make it through, with suggestions on how to update the forwarding rule.

Post reply on HN