Software packages are convenient for developers and, unfortunately, also for attackers

What’s in a name? When Shakespeare’s Juliet posed that question, it was just about romance. But in today’s tech world, it also applies to software. And if you don’t pay close attention to the names of software packages you choose to use, you can be in for a lot more grief than a broken heart.

Exhibit A in recent weeks was word that at least 700 individuals or organizations downloaded a malicious open source software package from the node package management (npm) repository that mimicked a legitimate package called “node-hide-console-window,” which lets users toggle an application window’s visibility.

The attackers, using a popular technique called typosquatting, changed the name simply by adding an “s” to “window.” Unsuspecting users who downloaded it then had their systems infected with a so-called rootkit, a set of software tools that enable attackers to get control of their systems without being detected.

According to ReversingLabs, a software supply chain security firm, the attackers set the malicious page to look similar to the page for the legitimate package. It also had 10 versions published, the same as the legitimate package.

“This is the first time ReversingLabs researchers have discovered a malicious open source package delivering rootkit functionality, and suggests that open source projects may increasingly be seen as an avenue by which to distribute malware,” ReversingLab’s Lucija Valentic wrote in a blog post.

This malicious package was among thousands available on the npm repository until it was detected and removed, which is a reminder of how software development, and therefore the attack surface of software, has evolved.

The large majority of software today is assembled from open source components, many of them in packages like these. That makes business sense — open source lets developers create new software projects easier, faster, and cheaper because those components are generally free to use and modify as long as licensing requirements are met.

But it also provides criminal hackers with yet another attack vector.

The malignant bundle

Yes, for about as long as there has been software there has been malware — malicious software. But packages have become a popular way to bundle and distribute multiple components.

As a recent eBook from the Synopsys Software Integrity Group “Exploring the Threat of Malicious Packages in the npm Ecosystem” puts it, “Software packages are a popular means to distribute open source and third-party software. They are often pulled from an outside source through a package manager or installer program, and typically include source code, libraries, documentation, and other files needed to build and run the software.”

But that everything-you-need-in-one-package convenience for developers and users can make it more convenient for attackers as well. According to the eBook, “Malicious packages are like a criminal impersonating someone you would allow in your home — a repair person or inspector, for instance — who presents you with falsified identification to gain entry.”

And much like in the physical world, “Once a malicious package’s malware infects a system, it can potentially steal sensitive data, disable security software, modify or delete files, and even take over an entire system or network, spreading to other devices to further increase its damage.”

Mike McGuire, senior security solutions manager with the Synopsys Software Integrity Group, said most people are aware of malware created as an entire application that attackers try to get their targets to download.

By contrast, malicious packages are aimed at developers, who attackers hope will use them while building a larger software product. “So developers might download and install some sort of open source JavaScript package that helps them make API [application programming interface] calls to some necessary service,” he said. “Little do they know that this package abuses elevated privileges in the application runtime environment to contact malicious services, install malware, or steal sensitive information.”

Help is available

Beyond that, unlike code weaknesses and vulnerabilities in software that can lurk undetected by criminals or defenders for months or years, “a malicious package is almost always a direct and immediate threat,” according to the eBook, since attackers planted it.

The good news is that there is help available to avoid malicious packages. One front line of defense is organizations like ReversingLabs, which researches software packages and has reported on other attacks seeking to leverage the npm repository.

“In July, we reported on Brainleeches, another npm-based campaign that targeted both end users and developers with malicious code designed to harvest user data with phony Microsoft.com login forms and implant credential harvesting scripts in applications that inadvertently incorporate the npm packages,” Valentic wrote in her blog post.

The eBook also reported that in 2022, “ReversingLabs researchers discovered evidence of a widespread typosquatting software supply chain attack involving malicious JavaScript packages offered via the npm package manager.” Those were collectively downloaded more than 27,000 times.

But there are also defensive measures that organizations can take themselves. To start, they should be familiar with the kinds of attacks they are likely to face when using software packages. In a recent episode of the Synopsys video blog AppSec Decoded, McGuire covered the four most popular, which include typosquatting. The other three are

• Brand jacking. The attacker poses as the online identity of a legitimate package owner “and uses that to leverage people’s trust and insert malicious packages or code into their application,” McGuire said. “Developers might be working fast, not taking time for due diligence about the origin or reputation of that particular component. And the malicious package might do things similar to or even the same as the legitimate brand but adds malicious aspects.”
• Dependency hijacking. “This is attackers hacking into the account of the package owner. That allows them to make a pull request or set up a way to call a remote IP address, collect sensitive info, sabotage an application, or other damage. I’m posing as the owner because I was able to break in,” McGuire said.
• Dependency confusion. In this case, an attacker publishes a package to a public repository like npm with the same name as a package used internally by a company but with a higher version number, which is designed to trick the internal package manager into downloading it as an update. “Organizations want to stay on top of their stuff — they don’t want to accumulate technical debt,” McGuire said, “and a package manager is doing its job by keeping things updated. But in this case, it’s replacing what was secure with a newer version that is not secure, which gives the threat actor a back door into your systems.”

Of course, it’s one thing to know what kinds of attacks are likely. It’s another to know how to avoid them. Fortunately, there is plenty of advice on that front as well. Among the recommendations from the Synopsys eBook are

• Verify package authenticity and names. Look for signs of fake accounts or impersonations and verify the legitimacy of the package’s source before installing it.
• Review package ownership and maintenance. Be cautious when using packages that have recently changed maintainers. Thoroughly vet the new maintainers
  and review any changes made to the package after the transfer.
• Note any functionality changes. Newer versions of packages are meant to patch defects and extend functionality but be suspicious of significant changes in functionality across different versions, especially if one version of a package is accessing files or systems the previous version wasn’t.
• Engage with the npm community. Report suspicious packages or activities to the npm security team. Collaborate with other developers by sharing information and experiences to collectively safeguard the npm ecosystem.
• Create and maintain a software Bill of Materials (SBOM). In the fight against software supply chain attacks, having an accurate, up-to-date SBOM is critical to ensuring that your code remains high quality, compliant, and secure. A comprehensive SBOM lists all the open source components in your applications as well as those components’ licenses, versions, and patch status — a rigorous defense against supply chain attacks.
• Stay informed. Ensure that you have the means to be informed of newly identified malicious packages, malware, and disclosed open source vulnerabilities.
• Perform code reviews. Examine the code of packages before including them in your project. Look for any suspicious patterns or unexpected behaviors that could indicate malicious activity. Review the package’s source code and check for any known vulnerabilities.
• Use an automated software composition analysis (SCA) tool. Few development and operations teams have the time or resources to create and maintain an SBOM, monitor for new malicious packages, and perform detailed code reviews of package downloads. But an SCA tool automates identification, management, and mitigation of software security defects and allows developers to focus their energies on writing code.

Doing all of this takes time and resources. And an organization may never know exactly what its return on investment is. It’s impossible to estimate the damage from an attack that you prevented. But as any victim of a successful malicious package attack can tell you, you don’t want to know.