Live data from Hacker News

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

gist.github.com

361–370 of 453 posts

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

#361
post #350

Earlier quoted context omitted.

To be clear only the path and query parameters part of the url can change, the domain (or sub domain) stays intact.

Even scarier to me than the vulnerability is that Fidelity (whom I personally think is a good bank and investment company) was using a third party that allowed injection that could potentially steal a whole lot of money, affect markets, ruin or terminate billions of lives, and affect the course of humanity. What the fuck.

Their knowledge of finance is certainly better than their knowledge of web tech.

Historically and today.

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

#362

Sounds like you pwned Mintlify!

I critiqued the title elsewhere already so let me say here that the screenshot does show code running in Discord's browser context. They didn't send it to an employee and actually pwn the company, as one might understand from the title, but it doesn't strictly say that and I would count finding XSS as close enough. Saying they've pwned Discord, I think is fair enough

The other three companies mentioned though... yeah, they totally pwned the dependency first and foremost

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

#363

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.

No because Discord auth tokens dont expire soon enough. The only thing that kills them is changing your password. Idk why Discord doesnt invalidate them after some time, it is seriously amateur hour over there and has been for a while.

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

#365
post #273

fascinating! but this is not a supply-chain attack unless i'm misunderstanding

It kinda is no? Discord uses mintlyfly. Minitlifly was vulnerable. And because they got access to mintlifly, discord was now also attackable

That's how language shifts. Supply chain attacks are broadly seen as a scary new thing, so like with any such term, people try to shoehorn things they find into its meaning. Those who fall for and repeat it shift the language. The same happened to the word 0day: it used to mean "a vulnerability that you specifically haven't had a chance to patch because it has been known to the world for 0 days". A scary thing. Now it's commonly used as synonym for the word vulnerability

I wonder if every vulnerability is soon called a supply chain attack:

- Microsoft releases a Windows security update -> Discord uses Windows -> supply chain attack on Discord

- User didn't install security updates for a while -> brought their phone to work -> phone with microphone sits in pocket in meeting room -> supply chain attack

Everything has dependencies that can be vulnerable, that doesn't mean "the supply chain" was attacked in a targeted effort by some attacker

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

#366

Earlier quoted context omitted.

Sanitisation is a tricky process, it can be real easy for something to slip through the cracks.

Yes. Much better to handle all untrusted data safely rather than try to transform untrusted data into trusted data. I found this page a helpful summary of ways to prevent SVG XSS: https://digi.ninja/blog/svg_xss.php Notably, the sanitization option is risky because one sanitizer's definition of "safe" might not actually be "safe" for all clients and usages. Plus as soon as you start sanitizing data entered by users,…

[deleted]

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

#367

Earlier quoted context omitted.

What is the reason for the low values? I would understand if it was a small company, but we are talking about Discord here.

Supply and demand. Selling via grey markets is an option, but many white hats don't go that route due to risk. There's plenty of people that will also find vulnerabilities without any money attached.

Not sure what risk but for me it would be morals

I've rarely gotten bug bounty money and not even always a written thank-you but it doesn't cross my mind to somehow seek out a malicious actor that wants to make use of what I found. Leave the place better than you found it and all that

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

#368

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.

Surely, if a script is in a position to sniff the cookie from local storage, they can also indirectly use the http-only cookie by making a request from the browser. So really not much of a difference as they will be taking over the account

The cookie storage and the local storage by all means is not the same! Cookies are not stored in the local storage and could be httpOnly, so they are not directly accessible by JavaScript. Nevertheless, as described above, with this XSS attack it is easy to bypass the token and just steal the user credentials by pretending a fresh login mask keeping the origin domain intact. That's why XSS attacks are dangerous since existence. Nothing new actually.

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

#369

Earlier quoted context omitted.

Supply and demand. Selling via grey markets is an option, but many white hats don't go that route due to risk. There's plenty of people that will also find vulnerabilities without any money attached.

That's a limited view. The damage this could cause should be accounted for. People don't have to sell shit, they could fuck things up just for the fun of it. That's something to consider, especially with a bunch of teenagers. Now, these big corpos didn't take the chance to sponsor and encourage these kids early careers and make this fuck-up good PR, at least.

That's not how economics works. I can't do my job without a computer or glasses but that doesn't mean I can pay the suppliers of these things most of my salary each. Preventing a 100k€ problem says almost nothing about what the payout should be. As for them just causing chaos for fun, that nets them just about nothing (what's an evening of fun worth, like what are you willing to pay for a cinema ticket?). This is certainly more (hundreds of times more) and so covers that risk as well

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

#370

Earlier quoted context omitted.

Would it be possible for messenger apps to simply ignore tags (and accept that this will break a small fraction of SVGs)? Or is that not a sufficient defense?

No, svgs can do `onload` and `onerror` and also reference other svgs that can themselves contain those things (base64'd or behind a URI). But you can use an `img` tag (` `) and that'll basically Just Work, or use a CSP. I wouldn't rely on sanitizing, but I'd still sanitize.

> But you can use an `img` tag (``) and that'll basically Just Work

That doesn't help too much if evil.svg is hosted on the same domain (with default "Content-Type: image/svg+xml" header), because attacker can send a direct link to the file.

Post reply on HN