Live data from Hacker News

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

gist.github.com

191–200 of 453 posts

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

#191
post #168

Earlier quoted context omitted.

For a reflected XSS? Tell me who is paying that much for such a relatively common bug... To elaborate, to exploit this you have to convince your target to open a specially crafted link which would look very suspect. The most realistic way to exploit would be to send a shortened link and hope they click on it, that they are logged into discord.com when they do (most people use the app), that there are no other securit…

It isn't about the commonality of the bug, but the level of access it gets you on the type or massive scale of the target. This bug you your blog? Who cares. This bug on Discord or AWS? Much more attractive and lucrative.

How would you make money from this? Most likely via phishing. Not exactly a zero-click RCE.

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

#192
post #93

Earlier quoted context omitted.

If that were the case, we'd routinely see mysterious XSS exploits on social networks. The underlying bugs are almost always difficult to target! And yet we do not. The biggest problem, again, is that the vulnerabilities disappear instantaneously when the vendors learn about them; in fact, they disappear in epsilon time once the vulnerabilities are used , which is not how e.g. a mobile browser drive-by works.

Why would YOU see a mystery XSS exploit on a social network? The idea of the DoD scoring these little exploits in a box is usually to deploy in a highly controlled and specific manner. You as a layperson is of no interest to them unless you are some kind of intelligence asset or foreign adversary

Wouldn't platforms see the supposed XSS payloads in their logs and publish analyses of them, or at the very least, announce that they happened?

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

#193
post #163

Earlier quoted context omitted.

No it would not have been.

It would have been. Ten times the amount at least.

I don't like tptacek, but it's insane to not back up this comment with any amount of evidence or at least explanation. The guy knows his shit.

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

#194
post #191

Earlier quoted context omitted.

It isn't about the commonality of the bug, but the level of access it gets you on the type or massive scale of the target. This bug you your blog? Who cares. This bug on Discord or AWS? Much more attractive and lucrative.

How would you make money from this? Most likely via phishing. Not exactly a zero-click RCE.

What happens in all these discussions is that we stealthily transition from "selling a vulnerability" to "planning a heist", and you can tell yourself any kind of story about planning a heist.

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

#195
post #163

Earlier quoted context omitted.

It would have been. Ten times the amount at least.

I don't like tptacek, but it's insane to not back up this comment with any amount of evidence or at least explanation. The guy knows his shit.

Hey I was wrong about Apple downthread.

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

#196

This is a pretty scary exploit, considering how easily it could be abused. Imagine just one link in a tweet, support ticket, or email: https://discord.com/_mintlify/static/evil/exploit.svg . If you click it, JavaScript runs on the discord.com origin. Here's what could happen: - Your Discord session cookies and token could be stolen, leading to a complete account takeover. - read/write your developer applications & we…

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 that without causing a page load).

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

#197

This is a pretty scary exploit, considering how easily it could be abused. Imagine just one link in a tweet, support ticket, or email: https://discord.com/_mintlify/static/evil/exploit.svg . If you click it, JavaScript runs on the discord.com origin. Here's what could happen: - Your Discord session cookies and token could be stolen, leading to a complete account takeover. - read/write your developer applications & we…

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.

Discord puts the authentication token in local storage

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

#198
post #41

This feels so emblematic of our current era. VC funded vibe coded AI documentation startup somehow gets big name customers who don't properly vet the security of the platform, ship a massive vulnerability that could pwn millions of users and the person who reports the vulnerability gets...$5k. If I recall last week Mintlify wrote a blog post showcasing their impressive(ly complicated) caching architecture. Pretending…

I don't think anybody in SFBA-style software development, both pre- and post-LLM, is really resilient against these kinds of attacks. The problem isn't vibe coding so much as it is multiparty DLL-hell dependency stacks, which is something I attribute more to Javascript culture than to any recent advance in technology.

I wonder what's worse, the SFBA-style software development, but also with SFBA-style 2 hour response window to serious bugs like Discord showed, or the old fashioned enterprise report your bug and within 2 months you'll receive an e-mail confirming your report if you're lucky and a letter from a lawyer if you're not.

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

#199
post #156

Earlier quoted context omitted.

I'm happy to answer questions but the only thing I could think to respond with here is just a restatement of what I said. I was terse; which part do you want me to expand on? Sorry about that!

> because there aren't existing business processes those vulnerabilities drop seamlessly into; they're all situational and time-sensitive. what's an example of an existing business process that would make them valuable, just in theory? why do they not exist for xss vulns? why, and in what sense, are they only situational and time-sensitive? i know you're an expert in this field. i'm not doubting the assertions just t…

I can't think of a business process that accepts and monetizes pin-compatible XSS vulnerabilities.

But for RCE, there's lots of them! RCE vulnerabilities slot into CNE implants, botnets, ransomware rigs, and organized identity theft.

The key thing here is that these businesses already exist. There are already people in the market for the vulnerabilities. If you just imagine a new business driven by XSS vulnerabilities, that doesn't create customers, any more than imagining a new kind of cloud service instantly gets you funded for one.

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

#200

Earlier quoted context omitted.

is santizing SVGs hard, or just everyone forgets they can contain js?

I gather from the HN discussion that it's not simple to disable scripting in an SVG, in retrospect a tragically missing feature. I guess the next step is to propose a simple "noscripting" attribute, which if present in the root of the SVG doc inhibits all scripting by conforming renderers. Then the renderer layer at runtime could also take a noscripting option, so the rendering context could force it if appropriate.…

its common to santize html string to parse it and remove/error on script tags (and other possible vulnerabilities)

i wonder do people not do this with svgs?

Post reply on HN