Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

gist.github.com

Post reply on HN
Print view View original

411–420 of 453 posts

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

#411

Post by JumpCrisscross »

rvnx wrote: post #261
tptacek wrote: post #242

Earlier quoted context omitted.

Really? Tell me a story about someone selling an XSS vulnerability on Telegram. ("The CVSS chart"?) Moments later Why do people keep bringing up "Zerodium" as if it's a thing?

I understand your perspective about the technical value of an exploit, but I disagree with the concept that technical value = market value. There are unorganized buyers who may be interested if they see potential to weaponize it. In reality, if you want to maximize revenue, yes, you need to organize your own heist (if that's what you meant)

> understand your perspective about the technical value of an exploit

Going out on the world’s sturdiest limb and saying u/tptacek knows the technical and trading sides of exploits. (Read his bio.)

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

#412

Post by jrflowers »

tptacek wrote: post #398
jrflowers wrote: post #340

Earlier quoted context omitted.

>i quickly realised that this was the server-side serverless (lol) environment of their main documentation app , while this calls to a external api to do everything, we have the token it calls it with in the env. >alongside, we can poison the nextjs cache for everyone for any site, allowing mass xss, defacing, etc on any docs site.

So it's a serverside bug that basically creates a more-severe stored DOM corruption vulnerability? Yeah, that's not worth anything to any buyer of vulnerabilities that I know exists. Maybe you know ones that I don't know.

I can’t speak to the value of the vulnerability as I lack the universal Rolodex of Every Exploit Buyer that is apparently available (nor am I interested in debating this with somebody that admitted they didn’t know anything about the vulnerability, declared it worthless anyway, and then moved the goalposts after a core assumption about it was trivially shown to be wrong. I’m fairly certain at this point these kids could recreate the end of the movie Antitrust and there’d be a thread somewhere with tptacek posting “This isn’t that big of a deal because”).

I just saw that you asked if the article about the server-side exploit was about a server-side exploit. It is. It’s right there in the post.

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

#413

Post by zahlman »

dllu wrote: post #5

The fact that SVG files can contain scripts was a bit of a mistake. On one hand, the animations and entire interactive demos and even games in a single SVG are cool. But on the other hand, it opens up a serious can of worms of security vulnerabilities. As a result, SVG files are often banned from various image upload tools, they do not unfurl previews, and so on. If you upload an SVG to discord, it just shows the raw…

Yeah, it's still insane to me that the SVG can contain scripts. Wholly unnecessary; the DOM subtree it defines could be manipulated by external scripts just fine.

Anyway, I just set `svg.disabled` in Firefox. Scary world out there.

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

#414

Post by zahlman »

rslashuser wrote: post #301
staticassertion wrote: post #279

Earlier quoted context omitted.

Disabling script execution in svgs is very easy, it's just also easy to not realize you're about to embed an svg. ` ` will not execute scripts, a bit like your "noscripting" attribute except it's already around and works. Content Security Policy will prevent execution as well, you should be setting one for image endpoints that blocks scripts. Sanitizing is hard to get right by comparison (svgs can reference other svg…

I had the impression from elsewhere in this thread that loading the svg in some other way, then you are not protected. This makes a no-brainer "don't run these ever" option in the browser seem appealing.

> This makes a no-brainer "don't run these ever" option in the browser seem appealing.

Firefox has this: svg.disabled in about:config. It doesn't seem to be properly documented, and might cause other problems for the developer (I found it accidentally, and a more deliberate search turns up mainly bug tracker entries.)

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

#415

Post by zahlman »

tptacek wrote: post #199
jonahx wrote: post #156

Earlier quoted context omitted.

> 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 vulnerabiliti…

How does stealing someone social media accounts not slot into "organized identity theft"?

... actually: how is XSS not a form of RCE? The script is code; it's executed on the victim's machine; it arrives remotely from the untrusted, attacker-controlled source.

And with the legitimate first-party's permissions and access, at that. It has access to things within the browser's sandbox that it probably really shouldn't. Imagine if a bank had used Mintlify or something similar to implement a customer service portal, for example.

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

#416

Post by tptacek »

zahlman wrote: post #415
tptacek wrote: post #199

Earlier quoted context omitted.

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 vulnerabiliti…

How does stealing someone social media accounts not slot into "organized identity theft"? ... actually: how is XSS not a form of RCE? The script is code; it's executed on the victim's machine; it arrives remotely from the untrusted, attacker-controlled source. And with the legitimate first-party's permissions and access, at that. It has access to things within the browser's sandbox that it probably really shouldn't.…

You're misreading me. It's organized identity theft driven by pin-compatible RCE exploits. Is there already an identity theft ring powered by Mintlify exploits? No? Then it doesn't matter.

The subtlety here is the difference between people using an exploit (certainly they can) and people who buy exploits for serious money.

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

#417

Post by tptacek »

jrflowers wrote: post #412
tptacek wrote: post #398

Earlier quoted context omitted.

So it's a serverside bug that basically creates a more-severe stored DOM corruption vulnerability? Yeah, that's not worth anything to any buyer of vulnerabilities that I know exists. Maybe you know ones that I don't know.

I can’t speak to the value of the vulnerability as I lack the universal Rolodex of Every Exploit Buyer that is apparently available (nor am I interested in debating this with somebody that admitted they didn’t know anything about the vulnerability, declared it worthless anyway, and then moved the goalposts after a core assumption about it was trivially shown to be wrong. I’m fairly certain at this point these kids co…

Can I ask which exploit buyers you are aware of? None of us know all of them! It'll be easier to discuss this with a specific buyer in mind.

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

#418

Post by zahlman »

matt3210 wrote: post #328

>AI-powered documentation platform. You write your documentation as markdown and Mintlify turns it into a beautiful documentation platform Why do you need AI for this? Aren't there tons of packages which do very similar things without AI?

For that matter, why do you need SaaS for this? Aren't there tons of simple locally runnable solutions, including SSGs?

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

#419

Post by None4U »

johnisgood wrote: post #378
compootr wrote: post #345

Earlier quoted context omitted.

tokens are stored in localStorage, which is accessible by JS

Well, it used to be much more accessible before, now you have to do some hack to retrieve it, and by hack, I mean some "window.webpackChunkdiscord_app.push" kinda hack, no longer your usual retrieval. Basically you have to get the token from webpack. The localStorage one does not seem to work anymore. That is what I used, but now it does not work (or rather, not always). The webpack one seems to be reliably good. So…

Discord removes the token from localStorage when the web app is open and it's in app memory, and places it back when you close the tab using the "onbeforeunload" event.

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

#420

Post by kenjackson »

Aachen wrote: post #358
kenjackson wrote: post #151

Earlier quoted context omitted.

I think you can view it as supply chain as the supply chain is about attacking resources used to infiltrate downstream (or is it upstream? I get which direction I should think this flows). As an end user you can't really mitigate this as the attack happens in the supply chain (Mintlify) and by the time it gets to you it is basically opaque. It's like getting a signed malicious binary. It looks good to you and the tru…

A supply chain attack attacks the supply chain This makes use of a vulnerability in a dependency. If they had recommended, suggested, or pushed this purposefully vulnerable code to the dependency, then waited for a downstream (such as Discord) to pull the update and run the vulnerable code, then they would have completed a supply chain attack The whole title is bait. Nobody would have heard of the dependency, so they…

It does attack the supply chain. It attacks the provider of documentation. It's an attack on the documentation supply chain.

It would be like if you could provide a Windows Update link that went to Windows Update, but you could specify Windows Update to retrieve files from some other share that the malicious actor had control of. It's the same thing, except rather than it being a binary rather it is documentation.

Post reply on HN