we did not hire snyk, but we reached out to them after seeing this and they apologized. we did not get any confirmation of what exactly they were trying to do here (but i think your explanation that someone there suspected a dependency confusion vulnerability is plausible. though it's pretty irresponsible imo to do that on public npm and actually sending up the env variables)
Sama does it too
It's a gen X thing, like using "lol" to mean literal laughter
- it's muuch faster on mobile
- you're aiming to convey litheness to potential target audiences who will know to recognize it as intentional litheness
- you've gotten used to minimizing the amount of keystrokes necessary for communicating things, to the point it's second nature
- you've worked a lot in the past with older nlp systems, where ignoring capitalization was a given for inputs anyhow, and just got used to treating it as syntactic cruft only strictly necessary in more formal settings ;)
This isn’t 1998. Mobile keyboards autocapitalize. You have to go out of your way to avoid capitalization on mobile.
Wouldn't it be more like "pretty illegal"? They could have simply used body: JSON.stringify("worked"), i.e. not used the target machine's actual environment variables, which includes keys.
Or you can exploit it and say here's the PoC, this many people at your company fell for it, and this is some of the valuable data I got, including some tokens you'll have to rotate. This puts you into actual bug bounty territory. Certainly the PR side of things alone will incentivize them to pay you so you don't make too much of a noise about how Cursor leaked a bunch of credentials due to a misconfiguration that surely every good programmer knows about and defends against (like so many vulnerabilities seem so dumb in hindsight).
Alternatively, you could hash it and say “Look, it’s a sha of your database password hyphen “yougotpwnd””
I don't actually think that is a bad thing.
The TSA screening at airports would be vastly better if TSA maintained a "red team" that regularly tried smuggling guns (or water bottles or whatever) into airports. The agents would be more attentive if the number of incidents they dealt with was large enough that they could practice more often. The system could improve if it had actual feedback on how accurate and effective it was. And instead of agents overreacting or underreacting they could tune their responses to an appropriate level.
The same applies to supply chain attacks. The REAL ones are rare, dangerous, and performed by experts; having a chance to practice catching them, to assess our detection rates, and to adjust our reactions is healthy.
They actually do have this. TSA seem to still suck at their job:
https://www.forbes.com/sites/michaelgoldstein/2017/11/09/tsa...
Kind of like a lot of exploit PoCs just "pop a calc" (AKA open the Calculator app), not because opening the calculator is valuable to an attacker, but because if you can open calculator, you can do anything.
Shouldn't this alone be considered criminal negligence at this point? Cursor isn't some random open source project. It's a company that has funding, and subscriptions. Hell, I pay Cursor for a monthly subscription. Pretty incredible that they have no bounty program.
The same incentive to show impact applies even without a paid bounty.
look we had access to your Aws tokens, we could take over your account but we didn't steal actual token, we just got proof that we could access it
what they did was absolutely wrong and frankly likely illegal
How does this make it sound like they made Snyk apologize?
They could have demonstrated the POC without sending data about the installing host, including all your environment variables, upstream. That seems like crossing the line
Allowing someone full access to the contents of your environment (i.e. output of env command) is a big deal to most, I suspect.
What's the justification for taking all of the environment variables? This post tries to paper over that particular problem. If your goal was to see if you could attack the dependency chain the first steps of user+hostname would have been sufficient to prove your case.
Taking the environment variables is about taking the secrets, and kind of moves this from PoC to opposition supply chain attack. Not to mention it's not only Cursor devs that would be affected by this, it could have (if your plan worked) attacked anyone using the extensions.
It's also a tough buy given the note about the Snyk cofounder moving to compete directly with Cursor (courtesy @tankster): https://techcrunch.com/2024/11/14/tessl-raises-125m-at-at-50...
Assuming truly innocent motivations, you guys still need to give your heads a shake and rethink your approaches here.
Who did the GDPR review before extracting env vars from systems that were not under your control? How did actively extracting potentially private data from the environment not get flagged as Unauthorized Access?
If this "experiment" (which happened to be against a competitor, mind) was reviewed and approved internally, that is a great demonstration of Snyk's approach to (ir)responsible data collection and disclosure.
Sounds to me like Cursor internally has a private NPM registry with those packages. Because of how NPM works, it's quite easy to trick it to fetch the packages from the public registry instead, which could be used by an attacker [0].
Assumably, this Snyk employee either found or suspected that some part of Cursor's build is misconfigured as above, and uploaded those packages as a POC. (Given the package description "for Cursor", I'd think they were hired for this purpose.)
If that's the case, then there's not much to see here. The security researcher couldn't have used a private NPM registry to perform the POC if the point is to demonstrate a misconfiguration which skips the private registry.
.
[0] In particular, many proxies will choose the public over the private registry if the latest package version is higher: https://snyk.io/blog/detect-prevent-dependency-confusion-att...