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"
sigh Right.
Ironically, if the timeline is true that the attackers had been inside for months, the AIs they had access to are substantially weaker than today's frontier models. How much faster would they have achieved their goals with GLM 5.1?
HSMs & similar can at least time-limit access to secrets to the period where an attacker can make requests to the HSM.
I think the problem is the way we are using these "secrets" services traditionally. The requesting process/machine should NEVER see the Oauth client secret. The short-lived session token should be the only piece of data the server/client are ever privy too. The service that encrypts the data should be the ONLY service that holds the private key to decrypt, and therefore the only service that can process the decrypted…
The service wouldn't have access to the refresh token? How does authentication with the client-secret-holding intermediary work?
It's easy to see how this would work with sufficiently sophisticated clients in some use-cases, say via a vault plugin, but posing this as a universal necessity feels like a big departure from typical oauth flows, and the added complexity could be harmful depending on what home-grown solutions are used to implement it.
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…
One time use of refresh tokens is really common? Where each refresh will get you a new access token AND a new refresh token? That's standard in oidc I believe
I don't have data on whether it is common, but I know a few OAuth vendors support it.
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.
Next.js renders configuration that’s shared by client and server into a JSON blob in the HTML page. These config variables often come from environment variables. It’s a very common mistake for people to not realize this, and accidentally put what should be a server-only secret into this config. I’ve seen API secrets in HTML source code because of this. The client app doesn’t even use it, but it’s part of the next config so it renders into the page.
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.
If they had SSO sign in to their admin panel (trusted device checks notwithstanding) the oauth access would be useless.
Vercel is understandably trying to shift all the blame on the third party but the fact their admin panel can be accessed with gmail/drive/whatever oauth scopes is irresponsible.
> 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.
I think there’s a lot of truth to “the AI did it” though. We’re encouraging the same people who get tricked by “attached is your invoice” emails to run agent harnesses that have control of your desktop. I think there’s gonna be a lot of AI-powered exploits in the future.
> 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.
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…
I’m not clear on it either. Was the Context.ai OAuth application compromised? So the threat actor essentially had the same visibility into every Context.ai customer’s workspace that Context.ai has? And why is a single employee being blamed? Did this Vercel employee authorize Context.ai to read the whole Vercel workspace?
Funny how the headline tries to spin this as an env vars issue. By far the biggest issue is being able to access the production environment of millions of customers from a Google Workspace. Only a handful of Vercel employees should be able to do that with 2FA if not 3FA.
No one should be, why are the enverionmant variables not encrypted itself and the encryption key is stored with your oauth provider ?
Vercel runtime must be able to access the values (so customer's apps can use them). But nobody else should ever be able to. This is the typical amateur hour security but on the other hand, who was naive enough to expect any better from vercel?
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…
They don't really say. My guess would be something embarrassing, and that's why they are keeping it to themselves. Maybe passwords in Drive og Gmail. Or just passwordless login links (like sibling said)