Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Malicious crossenv package on npm

twitter.com

Post reply on HN
Print view View original

141–150 of 237 posts

Re: Malicious crossenv package on npm

#141

Post by Ajedi32 »

danjoc wrote: post #50
stu_k wrote: post #40

Earlier quoted context omitted.

I'm confused, how would the above help with a typosquatting package? The issue here is that `crossenv` is malicious, and `cross-env` isn't. The signatures would all be ok in both cases.

The signature might validate, but at the point you go to Kent C Dobbs to verify he controls the key, the ruse is uncovered.

What ruse? "Kent C Dobbs" published the `cross-env` package, not the `crossenv` package. In this case, the attacker is the legitimate owner of the `crossenv` package; the problem is that's not the package I actually want. If I had typed `npm install cross-env` instead of `npm install crossenv`, I would have gotten a non-malicious, perfectly legitimate copy of the package I wanted; no GPG key required.

Re: Malicious crossenv package on npm

#142

Post by veeti »

slackingoff2017 wrote: post #56
KirinDave wrote: post #42

Earlier quoted context omitted.

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

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…

> That package was just something you googled that hasn't been updated in two years because maven has required signed packages forever.

That something hasn't been updated in two years because it's feature complete and does what it's supposed to: verifies the integrity of dependencies for Signal [1].

> If someone gains access to my account and tries to modify my package without my private key it will not be accepted into the repo.

This isn't true. Sonatype/Maven Central requires PGP signatures on all new artifacts, but there is no requirement to use the same key. It will happily accept a signature from _any_ key for new releases.

[1] https://github.com/WhisperSystems/Signal-Android/blob/ae9303...

Re: Malicious crossenv package on npm

#143

Post by throwaway91111 »

KirinDave wrote: post #128
vacri wrote: post #116

Earlier quoted context omitted.

> 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 malicio…

That's fine, but gpg signatures would do nothing to prevent this and widy scaled webs of trust don't exist.

Easy to say. Care explaining? These signatures seem like exactly the thing to prevent mitm attacks. I trust signature A; i won't load the package unless it's signed by signature A.

Most people won't be that strict in informal development, but that's not really what this is about.

Re: Malicious crossenv package on npm

#144

Post by Ajedi32 »

sbarre wrote: post #93
pfooti wrote: post #82

Earlier quoted context omitted.

Why would the malicious user advertise the email associated with crossenv as kent@doddsfamily.com and not kent@dodds.family? Attacker could control the latter and hand you an evil cert?

One would think you would do more than send an email if you're trying to verify. Websites, Twitter, Github, Keybase, etc.. It would be pretty hard for a bad actor to overtake the real author's entire Google-findable presence (assuming it's a reasonably popular package - why would you typosquat anything obscure). If all you do is send an email, then you haven't really done "due diligence" in any acceptable form.

What if the attacker instead advertises `some-totally-different-person@gmail.com`? How are you even supposed to know who wrote the legitimate version of the package in the first place? And if you _do_ know who wrote the package, you don't need a GPG key to verify that; just their NPM username or even the actual, real package name will do fine for preventing this specific attack.

Re: Malicious crossenv package on npm

#145

Post by diimdeep »

http://dev.hacktask.org is look like SAAS for XSS attacks (free registration, use google translate)

screenshots: https://imgur.com/a/BGyME

I found it at https://github.com/leanone/v1/blob/2980984c003d8016ac48d3f87... redirects to https://dev.hacktask.org/p/58ad07f57e25ce001b19f776/

I created account (use google translate) and played with it, use this link to show me who you are https://dev.hacktask.org/client/59815d7f5ff1a2001b9ee398/

Re: Malicious crossenv package on npm

#146

Post by microtonal »

KirinDave wrote: post #128
vacri wrote: post #116

Earlier quoted context omitted.

> 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 malicio…

That's fine, but gpg signatures would do nothing to prevent this and widy scaled webs of trust don't exist.

Just signatures would indeed not help much in this particular case. Signatures plus other ways to establish trust will help. To give two examples:

- macOS apps need to be signed (to run without extra work). The keypair is associated with a developer ID account that has a credit card on file. Abuse is still possible (stolen credit card, stolen certificate), but a lot harder.

- Some open source project have their own WoT. For example, IIRC NetBSD required new developers to meet with one or two existing developers in person to verify their identity. (Pretty much like a regular PGP WoT.)

These are more work, but they also make the world safer for users.

Re: Malicious crossenv package on npm

#147

Post by mrkrabo »

packetized wrote: post #19
ben174 wrote: post #15

Looks like all the packages by this guy post to hacktask.net - a Chinese site. Google autocomplete also suggests xss.hacktask.net Looks like this guy is up to all kinds of no good.

...hosted by Cloudflare.

Don't understand the downvotes. Cloudflare doesn't seem to have a problem hosting stuff like this, or even carders, and then ignoring abuse emails :')

Re: Malicious crossenv package on npm

#148

Post by nulagrithom »

Spivak wrote: post #118
phpnode wrote: post #33

Earlier quoted context omitted.

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.

Imagine if Debian decided that `sduo rm *` meant it should apt-get install the sduo package and run immediately it.

I know my systrems system wouldn't last 5 minutes.

Re: Malicious crossenv package on npm

#149

Post by DCoder »

eropple wrote: post #13
romanovcode wrote: post #9

Earlier quoted context omitted.

Or use some other technology.

There are remarkably few dependency management systems not vulnerable to some variant of this attack.

Then again, a project with <20 dependencies has fewer "entry points" for this attack than a typical NPM project with 500+ transitive dependencies.

Re: Malicious crossenv package on npm

#150

Post by LoSboccacc »

pfooti wrote: post #101
danjoc wrote: post #73

Earlier quoted context omitted.

I can explain how it can be done. Let's say you need a new dependency. You can't just add it to the project. Management would kill you. There's a lot of checks you have to make. Like licenses and signatures. In this case, you're concerned about signatures. I'll stick to that. If I believe I need crossenv, I see it advertises kent@doddsfamily.com as the author. I look up Kent Dodds. I find various bits of information…

One of the central problems of trust is that simple solutions don't scale well. Back in the day, one acquired a .com address by sending someone an email, because everyone knew everyone. cross-env has had 1.3 million downloads in the last month. How many of those "hey, I am evaluating your library" emails can Dodds field? Most node projects have hundreds of dependencies, if you include transitive dependencies. How man…

Seems to scale well both for maven and basically all linux distroes, so there's that
Post reply on HN