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

21–30 of 131 posts

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

#23

Post by quentindanjou »

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…

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.

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

#25

Post by _pdp_ »

> OAuth trust relationship cascaded into a platform-wide exposure

> The CEO publicly attributed the attacker's unusual velocity to AI

> questions about detection-to-disclosure latency in platform breaches

Typical! The main failures in my mind are:

1. A user account with far too much privileges - possible many others like them

2. No or limited 2FA or any form of ZeroTrust architecture

3. Bad cyber security hygiene

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

#26

Post by mooreds »

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…

This was probably partly a Google refresh token theft (given the length of the access). No inside info, just looking at how the attack occurred.

OAuth 2.1[0] (an RFC that has been around longer than I've been at my employer) recommends some protections around refresh tokens, either making them sender constrained (tied to the client application by public/private key cryptography) or one-time use with revocation if it is used multiple times.

This is recommended for public clients, but I think makes sense for all clients.

The first option is more difficult to implement, but is similar to the IP address solution you suggest. More robust though.

The second option would have made this attack more difficult because the refresh token held by the legit client, context.ai, would have stopped working, presumably triggering someone to look into why and wonder if the tokens had been stolen.

0: https://datatracker.ietf.org/doc/html/draft-ietf-oauth-v2-1

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

#27

Post by tom1337 »

I still don't get how this exactly worked. Is the OAuth Token they talk about the one that you get when a user uses "Sign in with Google"? Aren't they then bound to the client id and client secret of that specific Google App the user signed in to? How were the attackers able to go from that to a control plane? Because even if the attacker knows the users OAuth token, the client id and the client secret, they can access the Google Drive etc. (which is bad, I get that) but I simply do not understand how they could log in into any Vercel systems from that point. Did they find the credentials in the google drive?

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

#28

Post by JauntyHatAngle »

_pdp_ wrote: post #25

> OAuth trust relationship cascaded into a platform-wide exposure > The CEO publicly attributed the attacker's unusual velocity to AI > questions about detection-to-disclosure latency in platform breaches Typical! The main failures in my mind are: 1. A user account with far too much privileges - possible many others like them 2. No or limited 2FA or any form of ZeroTrust architecture 3. Bad cyber security hygiene

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

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

#29

Post by _pdp_ »

tom1337 wrote: post #27

I still don't get how this exactly worked. Is the OAuth Token they talk about the one that you get when a user uses "Sign in with Google"? Aren't they then bound to the client id and client secret of that specific Google App the user signed in to? How were the attackers able to go from that to a control plane? Because even if the attacker knows the users OAuth token, the client id and the client secret, they can acce…

Once you have a session token, which is what you get after you complete the oauth dance, you can issue requests to the API. It is simple as that. The minted token had permission to access the victim's inbox, most likely, which the attacker leveraged to read email and obtain one-time passwords, magic links and other forms of juicy information.
Post reply on HN