Three npm Packages Opened Remote-Access Shells on Linux and Windows Systems (zdnet.com) 65
"Three JavaScript packages have been removed from the npm portal on Thursday for containing malicious code," reports ZDNet.
"According to advisories from the npm security team, the three JavaScript libraries opened shells on the computers of developers who imported the packages into their projects." The shells, a technical term used by cyber-security researchers, allowed threat actors to connect remotely to the infected computer and execute malicious operations. The npm security team said the shells could work on both Windows and *nix operating systems, such as Linux, FreeBSD, OpenBSD, and others.
All three packages were uploaded on the npm portal in May (first) and September 2018 (last two). Each package had hundreds of downloads since being uploaded on the npm portal. The packages names were:
plutov-slack-client
nodetest199
nodetest1010
"Any computer that has this package installed or running should be considered fully compromised. All secrets and keys stored on that computer should be rotated immediately from a different computer," the npm security team said.
"According to advisories from the npm security team, the three JavaScript libraries opened shells on the computers of developers who imported the packages into their projects." The shells, a technical term used by cyber-security researchers, allowed threat actors to connect remotely to the infected computer and execute malicious operations. The npm security team said the shells could work on both Windows and *nix operating systems, such as Linux, FreeBSD, OpenBSD, and others.
All three packages were uploaded on the npm portal in May (first) and September 2018 (last two). Each package had hundreds of downloads since being uploaded on the npm portal. The packages names were:
plutov-slack-client
nodetest199
nodetest1010
"Any computer that has this package installed or running should be considered fully compromised. All secrets and keys stored on that computer should be rotated immediately from a different computer," the npm security team said.
Re: This "shell" thing (Score:3)
What retards. I've used that term for decades - look ma, I'm a cyber security expert.
Want to be secure? Don't use JavaScript. Don't use JavaScript written by some stranger. Don't depend on stupid articles written by people who don't know what they're talking about for information.
Re: (Score:3)
There's nothing wrong with Javascript as a language, IMO.
But yes, don't use Javascript written by someone else in any environment which has access to operating system functionality.
In a properly sandboxed environment, arbitrary Javascript is perfectly fine. The worst thing it can do is crash itself.
Re: (Score:3)
But yes, don't use Javascript written by someone else in any environment which has access to operating system functionality.
Who do you think wrote all that code on your system that's controlling the Javascript? I mean even Linus runs other people's code in fully privileged contexts all the time. It might be worth saying "don't run code off the npm repository" however - they seem to be consistently worse at this than even other Javascript repos. Two years to discover a bad library is a problem though. That's with lots of people looking at npm. Think what could happen if one of the less common languages was this careless.
Re: This "shell" thing (Score:2)
Linus and others read code, with the objective of merging it for reuse by others.
The problem is no one reviews most code uploaded to Npm (also, cran, cpan, app stores, binary sites, Tucows, etc.) Because there is no need to merge, perhaps. Just to run it.
Re: (Score:2)
That's for the Linux kernel - sure - Linus is still running a load of other privileged software that he hasn't read - e.g. likely most of the system services on his system. If you argue that RedHat / Ubuntu have better release processes than NPM then that's actually my entire point.
Re: This "shell" thing (Score:3)
So the solution may be for an AI to 'read' the code and compare it's patterns and metapatterns to a big data warehouse full of malware. It could also compare the patterns to a database of 'expected habits' defined by the admins of the portal. For instance, the admin may expect that a text processor should not open remote shells.
Re: (Score:3)
There's nothing wrong with Javascript as a language, IMO.
I disagree. I dislike Javascript as a language. It's messy. Postmodern programmers like messy languages, so I'm not one of them.
Re: (Score:3)
Re: (Score:2, Funny)
That's an interesting variation on "No True Scotsman".
Well spotted. I'm a Welshman.
Re: This "shell" thing (Score:2)
Re: (Score:2)
You seem to have failed at reading comprehension. You would have a point of they said it was a term only used by security experts. What they wrote it's factually accurate. The term "shell" is in fact used by security experts.
I'm a security expert and this is true. I often use the term shell when bitching about the company default being csh and not bash on our linux compute machines.
Re: (Score:3)
Re: (Score:3)
I've just found another package that opens a remote shell, and it's in even more repositories than this lot. Just check whatever repo you use and if the 'netcat' package is present, it's been compromised.
Thanks for pointing it out. I just analysed that package too. The worst thing about netcat is that, unlike the npm packages which activate on installation, it's a hidden feature that only gets activated when a secret code is typed in (you can find hints about the secret code by looking through the package text for something called the "command line" - the hacker seems to have forgotten to remove their internal documentation explaining this so the instructions are in every install). That means that you won'
Re: (Score:2)
We need detailed government regulation now with a UN committee to approve each package upload now. Maybe a separate one for approving each GitHub commit.
And a requirement for everyone to use their real, government-verified identities online. I bet "Hobbit" person isn't even the netcat author's real name.
Oh come ON (Score:5, Insightful)
”The shells, a technical term used by cyber-security researchers, allowed threat actors to connect remotely to the infected computer and execute malicious operations.“
Gee, thanks for a (very poor) explanation of what a “shell” is.
Seriously, Slashdot?
Re: (Score:2)
Re:Oh come ON (Score:5, Funny)
Oh crap, the three shells have been compromised? Does anyone still have rolls of what is called "toilet paper"?
Re: (Score:2)
I mean, they copied it from the article. Most summaries now consist of almost nothing but the pull-quote from the article.
Re: (Score:2)
This is true and it's quite sad - it seems the current Slashdot editors prefer that? It's a bit anecdotal but I try to make submissions that push together some related stuff and I think they get accepted less often.
Re: Oh come ON (Score:2)
When both your tech writers and readers are militant luddites...
Probably written on an iPad...
Re: (Score:2)
Which CMS are you asking about, there's literally dozens if not hundreds of those.
Re: (Score:3)
Re: (Score:3)
Dependency Graph (Score:5, Insightful)
Hey, npm, nobody is installing those manually.
The responsible thing to do is work your logs and build the reverse dependency graph of what was including them. Admins can act on that and CVE can do its thing.
If none, we can perhaps conclude that npm was 'just' being used as a malware distribution problem. Which is way better.
What's never going to happen is that every time npm discovers a problem every admin everywhere who has some dev who's touched npm is going to scour their systems.
Re: (Score:2)
Right now, “check which npm packages are installed” is trending on google.
Followed by “what is a shell”.
Re: (Score:1)
Followed by “what are the three shells”.
Damn you, toilet paper shortage!
Re: (Score:1)
There may be three shells, but THERE ARE FOUR LIGHTS!
Re: (Score:1)
Enough with the references about the numbers of things in TV shows and movies! The line must be drawn here! This far, no further!
Re: (Score:1)
So I can still mention “fifteen birds in five fir trees”?
Re: (Score:1)
It's dead Jim.
Re: (Score:2)
Re: Dependency Graph (Score:1)
Bidet add-on for toilet seats, BEATCH!
$15, beAtch!
Never buy toilet paper again like a caveman, beAtch!
Re: (Score:2)
I live in Canada, buddy. I'd say 99.999% of our bathrooms don't have easily accessible hot water connections near the toilet. So in short: bidet, yes. Freezing my ass off with ice cold water: no thank you.
Well (Score:2)
Who didn't see that one coming? It's going to happen with pip sooner or later.
Re: (Score:2)
pypi.org seems to be trying to be cautious about reviewing packages before posting them, but it is a real risk. ant and maven pulling in jar viles, riubygems, and perl modules with CPAN all have the same issues. It's a recurring problem when developers each insist on their own unique new package management system.
Re: (Score:2)
pypi.org seems to be trying to be cautious about reviewing packages before posting them, but it is a real risk. ant and maven pulling in jar viles, riubygems, and perl modules with CPAN all have the same issues. It's a recurring problem when developers each insist on their own unique new package management system.
Well there are problems with languages using the package management systems of distros. For example, in quite a few distros the maintainers use python for various plumbing/maintenance tasks. If you are a python developer, this means that you either (a) are stuck with the distro's python version and the (usually limited) set of modules in the distro's repo or (b) use python virtual environments and pip-install the modules you need (and possibly alternate python versions).
Re: (Score:2)
Having a stable base python and associated sytem modules one has to work within is the cost that goes with _having_ a stable system release and associated components one can consistently rely on, and avoid unpredictable incompatibility with upgraded modules pulled in by other components.
The incompatibility can usually be worked around by defining a separate space for the variant python. and using "virtualenv" or other alternative python handling tools judiciously. Similar approaches have worked for CPAN and
Re: (Score:3)
Having a stable base python and associated sytem modules one has to work within is the cost that goes with _having_ a stable system release and associated components one can consistently rely on, and avoid unpredictable incompatibility with upgraded modules pulled in by other components.
I agree there are real benefits in having a stable distro; I'm using a distro based on Debian stable myself. But it is useful to have a way to maintain an alternative, more current, set of developer tools in userland; hence the need for things like pip for python.
Real Hackers (Score:1)
Use a GUI, not a shell. Haven't you seen any movies?
Re: (Score:1)
According to the movies, real men use paper, not shells [youtu.be].
Re: (Score:2)
Actually from what I've seen in most movies, hackers seem to use pre-rendered videoclips. I can't remember which movie, but I do remember laughing hard when I saw the video playback scrollbar moving at the bottom of the "hacker interface".
Node (Score:2)
Re: (Score:1)
The fact that Javascript is particularly bad for security (as well) is another discourse.
Re: (Score:1)
Re: Node (Score:3)
With Node you can just patch the fs module if you want to lock it down. This approach is used for mocking filesystems in unit tests. Most other modules are pretty similar. There's nothing here that is specific to JavaScript or npm. This is what open source software development looks like.
Re: (Score:2)
deno can replace node (Score:2)
Re: (Score:2)
Re: (Score:2)
Slack client? (Score:2)
Sounds like a lot of corporate slacks are even more compromised than they already were.
Imagine making a developer sign a 12 page NDA on hiring.. Then doing all your development work on a public free slack server.
Perl (Score:3)