Live data from Hacker News

We pwned X, Vercel, Cursor, and Discord through a supply-chain attack

gist.github.com

231–240 of 453 posts

Re: We pwned X, Vercel, Cursor, and Discord through a supply-chain attack

#231

Earlier quoted context omitted.

Doesn't stealing the cookies/token require a non-HTTP-only session cookie or a token in localstorage? Do you know that Discord puts their secrets in one of those insecure places, or was it just a guess? I believe if you always keep session cookies in secure, HTTP-only cookies, then you are more resilient to this attack. I interviewed frontend devs last year and was shocked how few knew about this stuff.

In general if a script can run, users sessions and more importantly passwords are at risk. It's true that an HTTP-only session cookie couldn't be directly taken, but it's trivial to present the user with a login screen and collect their password (and OTP), at which point you can easily get a session remotely. It can look entirely like the regular login page right down to the url path (because the script can modify th…

How do you modify the url exactly?

Re: We pwned X, Vercel, Cursor, and Discord through a supply-chain attack

#232

How these companies don't hire kids like Daniel for pennies on the dollar and have him attack their stacks on a loop baffles me. Pay the kid $50k/yr (part time, he still needs to go to school) to constantly probe your crappy stacks. Within a year or two you'll have the most goddamn secure company on the internet - and no public vulns to embarrass you.

Having been adjacent to this for years, it's because it's a cost center and not attached to the bonus of any product or program manager. Every now and then we'll get an advocate for security/integrity at a company but the effort lives and leaves with them.

Microsoft, after getting beat up over this for decades, is still horrible at it. In my area they're have been enforced regulations for years but they're written by the industry itself and infected with compliance managers and thus result in wastes of effort that makes compliance managers that came over from HR and legal happy with their eternal job security and minimal hard work.

Until some heavy handed top down regulation, written by people who understand the nature of ongoing security and software and embedded lifecycles, it's going to stay like this. Most existing supply chain regulation I've seen ends up saying "vet your vendors" and gives minimal practical guidance of how to actually do that. Likelihood of some really good law coming out of the current US administration and business climate is left as a comedy for the reader.

Re: We pwned X, Vercel, Cursor, and Discord through a supply-chain attack

#233
post #223

Earlier quoted context omitted.

I would not be that confident as you can see: on their first example, they show Discord and the XSS code is directly executed on Discord.com under the logged-in account (some people actually use web version of Discord to chat, or sign-in on the website for whatever reason). If you have a high-value target, it is a great opportunity to use such exploits, even for single shots (it would likely not be detected anyway si…

Again, here you have not so much sold a vulnerability as you have planned a heist. I agree, preemptively: you can get a lot of money from a well-executed heist!

Do you want to execute actions as logged-in user on high-value website XXX ?

If yes -> very useful

Re: We pwned X, Vercel, Cursor, and Discord through a supply-chain attack

#234
post #231

Earlier quoted context omitted.

In general if a script can run, users sessions and more importantly passwords are at risk. It's true that an HTTP-only session cookie couldn't be directly taken, but it's trivial to present the user with a login screen and collect their password (and OTP), at which point you can easily get a session remotely. It can look entirely like the regular login page right down to the url path (because the script can modify th…

How do you modify the url exactly?

https://developer.mozilla.org/en-US/docs/Web/API/History/pus...

Re: We pwned X, Vercel, Cursor, and Discord through a supply-chain attack

#235

Earlier quoted context omitted.

Nice! So the Cookie is accessible by JavaScript on all of those sites? That would be pretty surprising given the prevalence of HttpOnly, so that doesn't seem clear to me at all. And they're all using Cookie-based auth, you think? You're a bug bounty hunter so I'll defer to your wisdom, but doesn't it seem more likely that an account takeover would be possible via a state-changing request from the user's existing sess…

XSS is a RCE exploit. It allows you to run any action as if you were the owner of the account. How is that not a full account takeover?

XSS is categorically not an RCE and my point is that mitigations exist which make "It allows you to run any action as if you were the owner of the account" an unwarranted assumption. The writeup shows that it's possible to pop an alert box. That doesn't tell you anything about what's actually possible. Obviously Discord got enough information to take it seriously, but extrapolating that to suggest every third-party using Mintlify is vulnerable to account takeover is highly dubious based on what's presented.

Re: We pwned X, Vercel, Cursor, and Discord through a supply-chain attack

#236
post #233

Earlier quoted context omitted.

Again, here you have not so much sold a vulnerability as you have planned a heist. I agree, preemptively: you can get a lot of money from a well-executed heist!

Do you want to execute actions as logged-in user on high-value website XXX ? If yes -> very useful

Nobody is disputing that a wide variety of vulnerabilities are "useful", only that there's no market for most of them. I'd still urgently fix an XSS.

Re: We pwned X, Vercel, Cursor, and Discord through a supply-chain attack

#237
post #231

Earlier quoted context omitted.

In general if a script can run, users sessions and more importantly passwords are at risk. It's true that an HTTP-only session cookie couldn't be directly taken, but it's trivial to present the user with a login screen and collect their password (and OTP), at which point you can easily get a session remotely. It can look entirely like the regular login page right down to the url path (because the script can modify th…

How do you modify the url exactly?

`history.replaceState(null, "", "/login")`

Re: We pwned X, Vercel, Cursor, and Discord through a supply-chain attack

#238
post #66

Earlier quoted context omitted.

Uh... Flash was a genuine firehose of security flaws. I mean, yeah, they patched them. So "battle tested security layer" isn't wrong in a technical sense. But, yikes, no.

The Flash revisionism I see around here occasionally is bizarre. No, Flash was terrible and killing it was good.

It was terrible from a security POV, but the tooling was superb.

I remember my teenage friends creating things with flash in a way that doesn't happen on the modern web.

Re: We pwned X, Vercel, Cursor, and Discord through a supply-chain attack

#239
post #220
post #101

Earlier quoted context omitted.

Yes, opening random pdfs especially in random and old pdf viewers is not a good idea. If you must open a possibly infected pdf, then do it in browser, pdf.js is considered mostly safe, and updated.

Use the PDF to JPG online services, convenient and you still get your result without having to deal with any sandbox

Except of course that you're sharing the contents of that PDF with a random online service.

Re: We pwned X, Vercel, Cursor, and Discord through a supply-chain attack

#240
post #108

Earlier quoted context omitted.

We normally find things like this in our usual 60 hour audit blocks. Rates change over time with demand, but today an audit of that length would be $27k. Even that is quite cheap compared to letting a blackhat find this.

If I can ask on business model, as I have a friend with a similar predicament — what percent of the time do you find vulnerabilities in those audits? Do companies push back if you don't find vulnerabilities?

As someone in a related line of work: we find vulnerabilities so close to 100% of the time that it might as well be 100% of the time. Whether they're practically exploitable or surpass your risk appetite is the real question.
Post reply on HN