The three packages (plutov-slack-client, Nodetest199, nodetest1010) opened shells on machines of developers who imported them into projects. The shells allowed bad actors to remotely connect to those machines and perform nefarious activities. These packages can function on Windows and *nix operating systems like Linux, and have been live for over a year, resulting in hundreds of downloads. From ZDnet:
“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.
“The package should be removed, but as full control of the computer may have been given to an outside entity, there is no guarantee that removing the package will remove all malicious software resulting from installing it,” they added.
This exact scenario has been warned about before, several years ago. The article outlines the potential for an attack just like this with the author warning that devs should be reviewing the code they copy from places like GitHub. There are even free tools and companies like Snyk which monitor open-source packages and can scan codebases every time a commit to your codebase is made. So while you may want someone to have physical eyes on that code, most of the time developers and their teams simply don’t have the time to review it all. That’s when these tools can come into play and ensure that your business information and machines are protected.
If your development team has downloaded any of these packages, you must immediately treat this as an incident. Isolate the infected machines from the rest of your network. Gather your incident response team to start mitigating the problems that are going to arise. Assume infected machines are fully compromised and breached, and that the breach is ongoing. Remove the packages and scan for continuing activity. Scan your network to ensure it was not affected. Change any passwords that may have been compromised, lock down any credit card information located on the machine.
If your team did not download any of those packages or your business doesn’t use machines that are affected, consider yourself lucky. This time. Take it as a warning and review your open-source code. Use an automated tool, but have some kind of protection in place. If you are affected by these packages, do your due diligence and follow the proper protocols. Either way, be sure to monitor all open-source code that your development team uses going forward!