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

391–400 of 453 posts

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

#391

Post by lrvick »

TheDong wrote: post #265
lowkey_ wrote: post #117

Earlier quoted context omitted.

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?

These companies almost always produce "vulnerabilities", but they're also almost always trash. "Finding: This dependency is vulnerable to CVE-X, update it, severity S". And then of course that dependency is only used during development, the vulnerable code isn't called, and they didn't bother to dig into that. "Finding: Server allows TLS version 1.1, while it's recommended to only support version 1.2+", yeah, sure, I…

At Distrust we do not comment on specific dependency CVEs unless they are likely exploitable, or there are a lot of them pointing at bigger problems in the overall approach to dependency management.

That said, a policy of blindly updating dependencies to patch irrelevant CVEs is itself, a very real security vulnerability, because pulling in millions of lines of code no one reviews from the internet regularly makes you an easy target for supply chain attacks.

We have pulled off supply chain attacks on our clients a few times who were not otherwise convinced they were a real threat.

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

#392

Post by tptacek »

rkomorn wrote: post #383
tptacek wrote: post #205

Earlier quoted context omitted.

Just going to say here that people routinely engage pentest firms, several times annually, for roughly that sum of money, hoping but not expecting game-over vulnerabilities (and, from bitter experience as a buyer rather than a seller of those services over the last 5 years --- "no game-over vulnerabilities" is a very common outcome!)

> from bitter experience as a buyer rather than a seller of those services over the last 5 years --- "no game-over vulnerabilities" is a very common outcome! Why bitter? Did they miss some? Otherwise, isn't that the goal to begin with? Shouldn't you be proud instead?

Every pentest misses stuff. That's kind of the point I'm making. But yeah: as someone with a software security background, when you contract a test, you want them to find stuff!

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

#393

Post by tptacek »

greggh wrote: post #375
tptacek wrote: post #42

Earlier quoted context omitted.

This comes up on every story about bug bounties. There is in general no market at all for XSS vulnerabilities. That might be different for Twitter, Facebook, Instagram, and TikTok, because of the possibility of monetizing a single strike across a whole huge social network, and there's maybe a bank-shot argument for Discord, but you really have to do a lot of work to generate the monetization story for any of those. T…

Right, but Eva found an RCE and only got $5,000.

An RCE in what? Nobody's buying your Discord RCE.

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

#394

Post by collinmanderson »

llmslave2 wrote: post #229
rainonmoon wrote: post #70

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?

Yes, it's generally a "full account takeover" for a given discord user.

But RCE usually means ability to run any code on the web server, and would generally get you access to _everything_ including full direct access to the database. All accounts and all data, not just a few accounts.

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

#395

Post by yieldcrv »

FloorEgg wrote: post #6
normie3000 wrote: post #2

Cool bug. Bug bounty money is pathetic.

Supply and demand I guess. Pathetic for a senior SE but pretty awesome for a 16 year old up and coming hacker.

market value is the same regardless, so this was pathetic

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

#396

Post by seaal »

giancarlostoro wrote: post #363
jdsleppy wrote: post #178

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.

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.

Probably because the end user hates login in, my friends always complain about the “remember me” button being useless for some services.

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

#397

Post by tptacek »

0xbadcafebee wrote: post #384
tptacek wrote: 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.

They have a class of attacks which are used for targeted intrusion into foreign entities. Typically espionage or cyberwarfare, so they're not often used (they're aware they might be a one-use attack), but some persist for a long time. Foreign entities also tend not to admit to the attacks when found, so if the vendor is a US entity, often the vendor doesn't find out. We do the same; when our intelligence agencies fin…

Are these things you think it stands to reason the IC must be doing, or things you know for a fact that they are doing? It stands to reason for a lot of people that the IC must stockpile vulnerabilities, but they don't (they keep just a couple working ones) --- just as an example of counterintuitive things about how CNE works.

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

#398

Post by tptacek »

jrflowers wrote: post #340
tptacek wrote: post #228

Earlier quoted context omitted.

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

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

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

#399

Post by kbolino »

arethuza wrote: post #338
socketcluster wrote: post #314

Earlier quoted context omitted.

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…

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?

Encrypted tokens are opaque but they are also offline-verifiable. A simple opaque token has to be verified online (typically, against a database) whenever it's used.

Auth0, for example, supports JWE for its access tokens: https://auth0.com/docs/secure/tokens/access-tokens/json-web-...

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

#400

Post by socalgal2 »

auxiliarymoose wrote: post #306
socalgal2 wrote: post #297

Earlier quoted context omitted.

IIUC, an untrusted inline SVG is bad. An image tag pointing to an SVG is not. I feel like this is common knowledge. Just like you don't inject untrusted HTML into your page. Untrusted HTML also has scripts. You either sanitize it. OR you just don't allow it in the first place. SVG is, at this point, effectively more HTML tags.

Also remember that if the untrusted SVG file is served from the same origin and is missing a `Content-Disposition: attachment` header (or a CSP that disables scripts), an attacker could upload a malicious SVG and send the SVG URL to an unsuspecting user with pretty bad consequences. That SVG can then do things like history.replaceState() and include with HTML to change the URL shown to the user away from the SVG sour…

how is that special/different from an HTML URL?
Post reply on HN