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?

▲

gizzlon 6 hours ago | parent | next [-]

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)

▲

_pdp_ 9 hours ago | parent | prev | next [-]

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.

▲

progbits 6 hours ago | parent | next [-]

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.

	▲	zbentley 4 hours ago \| parent [-]
		That's a low-leverage place to intervene. Whether or not the internal admin system was directly OAuth linked to Google, by the time the attacker was trying that, they already had a ton of sensitive/valuable info from the employee's Google Workspace account. If you can only fix one thing (ideally you'd do both, but working in infosec has taught me that you can usually do one thing at most before the breach urgency political capital evaporates), fix the Google token scope/expiry, or fix the environment variable storage system.

▲

kyle-rb 6 hours ago | parent | prev [-]

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).

	▲	TeMPOraL 5 hours ago \| parent [-]
		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.

▲

chatmasta 6 hours ago | parent | prev [-]

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?