Remix.run Logo
Remix clone Hacker News
new | show | ask | jobsGithub
▲ superasn 18 hours ago

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 & webhooks, allowing them to add or modify bots, reset secrets, and push malicious updates to millions.

- access any Discord API endpoint as you, meaning they could join or delete servers, DM friends, or even buy Nitro with your saved payment info.

- maybe even harvest OAuth tokens from sites that use "Login with Disord."

Given the potential damage, the $4,000 bounty feels like a slap in the face.

edit: just noticed how HN just turned this into a clickable link - this makes it even scarier!

▲ 11 minutes ago | parent | next [-]
[deleted]
▲jdsleppy 17 hours ago | parent | prev | next [-]

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.

▲notnullorvoid 16 hours ago | parent | next [-]

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

▲socketcluster 7 hours ago | parent | next [-]

Yep, httpOnly cookies just give the hacker a bit of extra work in some situations. TBH I don't even think httpOnly is worth the hassle it creates for platform developers given how little security it adds.

▲drewvlaz 16 hours ago | parent | prev | next [-]

Wow did not realize a url could be set like that without promoting a page reload...

▲notnullorvoid 14 hours ago | parent | next [-]

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

▲sdf456 4 hours ago | parent [-]

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.

▲DANmode 2 hours ago | parent [-]

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

Historically and today.

▲psnehanshu 12 hours ago | parent | prev [-]

Well that's how SPAs work (single page applications)

▲jonfw 14 hours ago | parent | prev [-]

How do you modify the url exactly?

▲eloisius 14 hours ago | parent | next [-]

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

▲notnullorvoid 14 hours ago | parent | prev [-]

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

▲rvnx 14 hours ago | parent [-]

For Coinbase docs, this is a disaster particularly

▲notnullorvoid 14 hours ago | parent [-]

By they looks of it their docs are under a subdomain, and no part of the domain can be changed when setting the url this way. So it would still look a little out of place at least.

▲brianxq3 12 hours ago | parent [-]

I mean, you're not wrong, but this is going to trick a non-zero number of people and that's not okay. We should expect more out of companies like Coinbase and hold them to a high standard.

This is unacceptable and the amount offered in general is low. It feels like we can agree on this.

▲Maxion 8 hours ago | parent [-]

auth URLs are almost always a shitshow in every larger corp. Having the url be https://docs.bigcorp.com/sso/authlayerv1/us-east-24/aws/secu... would not stand out at all to anyone.

▲giancarlostoro 2 hours ago | parent | prev | next [-]

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.

▲ddlsmurf 16 hours ago | parent | prev | next [-]

if you set the cookier header right (definitely not always the case), this is true, but the javascript can still send requests that will have that cookie included, effectively still letting the hacker use the session as the logged in user

▲collinmanderson an hour ago | parent [-]

with http-only they can't _steal_ the cookie, but they can still _use_ the cookie. It reduces the impact but doesn't fully solve it.

▲hackermondev 16 hours ago | parent | prev | next [-]

Discord puts the authentication token in local storage

▲edoceo 11 hours ago | parent [-]

Is that a problem on its own? It's like, encrypted right? Maybe a time sensitive token?

▲socketcluster 7 hours ago | parent | next [-]

Not a problem in itself. Also, there's not much point of encrypting tokens. The attacker could use the encrypted token to authenticate themselves without having to decrypt. They could just make a request from the victim's own browser. They could do this with cookies too even with httpOnly cookies.

XSS is a big problem. If a hacker can inject a script into your front end and make it execute, it's game over. Once they get to that point, there's an infinite number of things they can do. They basically own the user's account.

▲arethuza 5 hours ago | parent [-]

Does anyone actually encrypt the contents of JWTs? I'd have thought that anyone who has concerns about the contents of the token being easily visible would be likely to avoid JWTs anyway and just use completely opaque tokens?

▲seangrogg 9 hours ago | parent | prev [-]

Depends on the token; JWTs usually have payloads that are only base64 encoded. As well, if there's a refresh token in there it can be used to generate more tokens until invalidated (assuming invalidation is built in).

▲z3t4 3 hours ago | parent | prev | next [-]

https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/...

▲s_ting765 16 hours ago | parent | prev | next [-]

You may be thinking of CSRF mitigations. XSS exploits are more dangerous and can do more than steal sessions.

▲j-krieger 7 hours ago | parent | prev | next [-]

Token stealing hasn't been a real danger for a decade now. If you don't mark your token's as non-HTTP you're doing something explicitely wrong, because 99% of backends nowadays do this for you.

▲collinmanderson an hour ago | parent [-]

with http-only they can't _steal_ the cookie, but they can still _use_ the cookie. It reduces the impact but doesn't fully solve it.

▲abustamam 10 hours ago | parent | prev | next [-]

As a FE dev, I wouldn't be able to articulate what you just did in the way you did, but it is something I know in practice, just from experience. I don't think any of the FE courses I took tackled anything like that.

▲netdevphoenix 5 hours ago | parent | prev [-]

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

▲Aldipower an hour ago | parent [-]

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.

▲why-o-why 15 hours ago | parent | prev | next [-]

The fact that it is just so trivial and obvious that its scary. It didn't even require any real hacking chops, just patience: literally anyone with a cursory knowledge of site design could have stumbled on this if they were looking at it.

Terrifying.

▲panzi 13 hours ago | parent | prev | next [-]

> - Your Discord session cookies and token could be stolen, leading to a complete account takeover.

Discord uses HttpOnly cookies (except for the cookie consent banner).

▲compootr 5 hours ago | parent [-]

tokens are stored in localStorage, which is accessible by JS

▲snvzz 18 hours ago | parent | prev [-]

>the $4,000 bounty feels like a slap in the face.

And serves a reminder crime does pay.

In the black market, it would have been worth a bit more.

▲imdsm 5 hours ago | parent | next [-]

I was once only given $1,000 for an exploit where I could put in npm usernames and get their email addresses. Big corps don't always pay what they should.

▲doctorpangloss 11 hours ago | parent | prev | next [-]

yeah, but nothing pays as much as doing free work for (checks notes) mintlify feels

▲tptacek 17 hours ago | parent | prev [-]

No it would not have been.

▲notnullorvoid 15 hours ago | parent | next [-]

This specific XSS vulnerability may not have been, but the linked RCE vulnerability found by their friend https://kibty.town/blog/mintlify/ certainly would've been worth more than the $5,000 they were awarded.

A vulnerability like that (or even a slightly worse XSS that allowed serving js instead of only svg) could've let them register service workers to all visiting users giving future XSS ability at any time, even after the original RCE and XSS were patched.

▲tptacek 14 hours ago | parent [-]

Maybe? I don't know enough about the vulnerability. Is it serverside? Then it isn't worth very much.

▲jrflowers 5 hours ago | parent [-]

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

▲tuhgdetzhh 17 hours ago | parent | prev | next [-]

Could you elaborate on why not?

▲tptacek 16 hours ago | parent | next [-]

What 'arcwhite said (sorry, I got dragged into a call).

1. The exploits (not vulnerabilities; that's mostly not a thing) that command grey/black market value all have half-lives.

2. Those exploits all fit into existing business processes; if you're imagining a new business, one that isn't actively running right now as we speak (such as you'd have to do to fit any XSS in a specific service), you're not selling an exploit; you're planning a heist.

3. The high-dollar grey market services traffic exclusively in RCE (specifically: reliable RCE exploits, overwhelmingly in mainstream clientside platforms, with sharp dropoffs in valuation as you go from e.g. Chrome to the next most popular browser).

4. Most of the money made in high-ticket exploit sales apparently (according to people who actually do this work) comes on the backend, from tranched maintenance fees.

▲arcwhite 17 hours ago | parent | prev [-]

There's generally no grey market for XSS vulns. The people buying operationalized exploits generally want things that they can aim very specifically to achieve an outcome against a particular target, without that target knowing about it, and operationalized XSS vulns seldom have that nature.

Your other potential buyers are malware distributors and scammers, who usually want a vuln that has some staying power (e.g. years of exploitability). This one is pretty clearly time-limited once it becomes apparent.

▲Lionga 17 hours ago | parent | prev [-]

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

▲mpeg 17 hours ago | parent | next [-]

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 security measures (httponly cookies) etc

No real way to use this to compromise a large amount of users without more complex means

▲PenguinCoder 17 hours ago | parent | next [-]

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.

▲mpeg 16 hours ago | parent | next [-]

Yes, but this is not a particularly high access level bug.

Depending on the target, it's possible that the most damage you could do with this bug is a phishing attack where the user is presented a fake sign-in form (on a sketchy url)

I think $4k is a fair amount, I've done hackerone bounties too and we got less than that years ago for a twitter reflected xss

▲rvnx 15 hours ago | parent [-]

Why would that be the maximum damage ? This XSS is particularly dangerous because you are running your script on the same domain where the user is logged-in so you can pretty much do anything you want under his session.

In addition this is widespread. It's golden for any attacker.

▲0x3f 15 hours ago | parent [-]

Because modern cookie directives and browser configs neuter a lot of the worst XSS outcomes/easiest exploit paths. I would expect all the big sites to be setting them, though I guess you never know.

▲rvnx 15 hours ago | parent | next [-]

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 since it's a drop in the ocean of requests).

Spreading it on the whole internet is not a good strategy, but for 4000 USD, being able to target few users is a great value.

Besides XSS, phishing has its own opportunity.

Example: Coinbase is affected too though on the docs subdomain and there are 2-step, so you cannot do transactions directly but if you just replace the content with a "Sign-in to Coinbase / Follow this documentation procedure / Download update", this can get very very profitable.

Someone would pay 4000 USD to receive 500'000 USD back in stolen bitcoins).

Still, purely with executing things under the user sessions there are interesting things to do.

▲promiseofbeans 4 hours ago | parent | next [-]

> some people actually use web version of Discord to chat, or sign-in on the website for whatever reason

Beside this security blunder on Discord’s part, I can see only upsides to using a browser version rather than an Electron desktop app. Especially given how prone Discord are to data mining their users, it seems foolish to let them out of the web sandbox and into your system

▲tptacek 14 hours ago | parent | prev [-]

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!

▲rvnx 14 hours ago | parent [-]

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

If yes -> very useful

▲tptacek 14 hours ago | parent [-]

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.

▲rvnx 14 hours ago | parent [-]

There is a market outside Zerodium, it's Telegram. Finding a buyer takes time and trust, but it has definitively higher value than 4k USD because of its real-world impact, no matter if it is technically lower on the CVSS scores.

▲tptacek 14 hours ago | parent [-]

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?

▲rvnx 13 hours ago | parent [-]

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)

▲tptacek 10 hours ago | parent [-]

Do you know this or do you just think it should be true?

▲GoblinSlayer 3 hours ago | parent | prev [-]

AIU this feature is SSS, not XSS, so XSS protections don't apply.

▲0x3f 16 hours ago | parent | prev [-]

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

▲tptacek 16 hours ago | parent [-]

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.

▲varenc 12 hours ago | parent | prev [-]

Also the XSS exploit would have been dead in the water for any sites using CSP headers. Coinbase certainly uses CSP. With this in place an XSS vuln can't inject arbitrary JS.

▲krainboltgreene 16 hours ago | parent | prev [-]

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.

▲tptacek 16 hours ago | parent [-]

Hey I was wrong about Apple downthread.