I'm new to the JS ecosystem--who is Oscar and who is Kent? Also who's hacktask?
Oscar is a dev, Kent is the maintainer of "cross-env", a popular package. hacktask is an unknown malicious module uploader that was harvesting credentials.
Malicious crossenv package on npm
111–120 of 237 posts
Re: Malicious crossenv package on npm
#112This attack has been previously described in the paper "Typosquatting package managers": Paper: http://incolumitas.com/data/thesis.pdf Blog post: http://incolumitas.com/2016/06/08/typosquatting-package-mana... Discussion: https://news.ycombinator.com/item?id=11862217 https://www.reddit.com/r/netsec/comments/4n4w2h/ The paper also discusses possible mitigation measures, including prohibiting registering new packages w…
Thanks, I came here to post this exact thing.
Even if NPM isn't prohibiting packages, you'd imagine they'd have internal security alerting for Levenshtein distance from the names of very popular npm packages. Such an alerting script wouldn't take terribly long to write (or to run). It'd let them catch this type of abuse much faster even if they decided (for some inane reason) that banning the names outright would break UX.
Re: Malicious crossenv package on npm
#113Earlier quoted context omitted.
You should've stopped at the first "and". Advocating for vigilante justice helps solve no problems.
I think you're reading a lot more into my comment than I wrote. It's not "vigilante justice" to ban known scammers and circulate blacklists of them. It's how our community functions.
I can't reply directly, but in another subtree you asked:
> Which part of the statement implied "vilgilate justice."
To put my own 2 cents in:
Doxxing someone is generally considered an attack, at least in some internet circles. It's pretty vigilante if you ask me, especially when we've seen some pretty striking examples of doxxing gone wrong in the past.
Re: Malicious crossenv package on npm
#114For everyone, here’s a one-liner to check your dependency tree: npm ls | grep -E "babelcli|crossenv|cross-env.js|d3.js|fabric-js|ffmepg|gruntcli|http-proxy.js|jquery.js|mariadb|mongose|mssql.js|mssql-node|mysqljs|nodecaffe|nodefabric|node-fabric|nodeffmpeg|nodemailer-js|nodemailer.js|nodemssql|node-opencv|node-opensl|node-openssl|noderequest|nodesass|nodesqlite|node-sqlite|node-tkinter|opencv.js|openssl.js|proxy.js|s…
This list includes incredibly popular NPM Packages,
Does this mean everyone whose used those have been affected?
EDIT: I just realized these packages are misspelled or meant to mimic the legitimate packages.
Re: Malicious crossenv package on npm
#115For everyone, here’s a one-liner to check your dependency tree: npm ls | grep -E "babelcli|crossenv|cross-env.js|d3.js|fabric-js|ffmepg|gruntcli|http-proxy.js|jquery.js|mariadb|mongose|mssql.js|mssql-node|mysqljs|nodecaffe|nodefabric|node-fabric|nodeffmpeg|nodemailer-js|nodemailer.js|nodemssql|node-opencv|node-opensl|node-openssl|noderequest|nodesass|nodesqlite|node-sqlite|node-tkinter|opencv.js|openssl.js|proxy.js|s…
This list includes incredibly popular NPM Packages, Does this mean everyone whose used those have been affected? EDIT: I just realized these packages are misspelled or meant to mimic the legitimate packages.
Those are typos of the original popular package, and not the real ones. Notice the missing or extra dash or extension
Re: Malicious crossenv package on npm
#116Friendly reminder, every time this happens... https://github.com/npm/npm/pull/4016 "However, this is just a piece of an overall solution, and it brings with it a lot of the baggage that comes along whenever GnuPG or PGP get involved. Without a web of trust (sigh), a PKI (ugh), or some other mechanism to tie identities to trust metrics, this is essentially a complicated, very expensive, and fragile version of the shas…
> I really like how the NPM simultaneously insults two legends in crypto and does _nothing_ to protect the node ecosystem, deferring to "better solutions" that don't exist and will never exist. But they're right. What exactly would PKI do here? Someone is generating confusion. You could argue that maybe a PKI solution could be used to inform the UI such that users are less likely to make mistakes, but browbeating NPM…
> everyone has this problem.
No, they don't. Some people actually implemented the "web of trust (sigh)".
Security is hard; the answer is not to just go "too hard, kick the can down the road" and then make excuses when the time comes for damage control. NPM being an order of magnitude larger means that more focus should be given to security, not less, since it has that extra noise acting as another way to hide malicious activity.
Re: Malicious crossenv package on npm
#117Earlier quoted context omitted.
This list includes incredibly popular NPM Packages, Does this mean everyone whose used those have been affected? EDIT: I just realized these packages are misspelled or meant to mimic the legitimate packages.
Those are typos of the original popular package, and not the real ones. Notice the missing or extra dash or extension
Thanks for pointing this out!
Wow some of these are incredibly similar, if they get indexed by google (as most NPM packages do) it's really easy to mistakenly add the incorrect package while searching for the legitimate one.
Re: Malicious crossenv package on npm
#118Earlier quoted context omitted.
crossenv was already running the script on post install, which means it was run on "npm i crossenv" anyway.
point is that npm are encouraging you to use npx, which is bundled with npm 5.2+ as a general tool for executing adhoc commands from the terminal. It just massively increases the chance of typos.
At some point there needs to be some trust, and NPM puts that boundary at installation. If you trust a package enough to install it, then it's allowed to act on your behalf with the permissions of your user.
`npx` doesn't change that dynamic. It's no different than installing an RPM or Debian package over the internet.
Re: Malicious crossenv package on npm
#119Earlier quoted context omitted.
Maven does not have this problem. That package was just something you googled that hasn't been updated in two years because maven has required signed packages forever. My packages are all cryptographically signed with my private key. Maven doesn't just offer code signing, it's mandatory to deploy projects to the central repo. The automated package verifier will reject you if you don't have it. If someone gains access…
How does "You need my private key to sign the cross-env package" stop someone from creating a "crossenv" package? What does the specific workflow look like that makes sure I don't add the wrong thing to my project?
GPG-signing doesn't prove maliciousness, it just proves authenticity; that it was written by a particular person. The web-of-trust is used to enforce social reputation - if a user is malicious, their key is revoked. If a user signs up poor-quality other users, their key is revoked. Blacklists go stale and are also hard to get off if you've landed on one in error. Webs-of-trust are more work, but more robust.
Re: Malicious crossenv package on npm
#120Earlier quoted context omitted.
Maven does not have this problem. That package was just something you googled that hasn't been updated in two years because maven has required signed packages forever. My packages are all cryptographically signed with my private key. Maven doesn't just offer code signing, it's mandatory to deploy projects to the central repo. The automated package verifier will reject you if you don't have it. If someone gains access…
Does maven really reliably validate packages these days? I once did a mvn build on a southwest flight and got stuff like "Syntax error: Click here for free TV..." all over my console. This was ~4 years ago. If I remember right, maven "supported" package validation, but it was certainly not the de facto standard.
Great point. I think that Maven Central is great about checking incoming packages. But most maven clients are really bad.
The default in maven client is usually to download via http. The default is usually to _not_ check the hash. There is not a great way to pin a library to a repository which, when coupled with the ease of third-party repositories slipping into your project, means that you can download things like your crypto oauth library from some random server on the web.
Many of these issues can be mitigated by running your own repository that mirrors what you need. Most big corporate shops do this. I think that approach works for any package management system. I guess open source devs and hobbiests are screwed?