Malicious code continues to be uploaded to open source repositories, making it a challenge for responsible developers to trust what’s there, and for CISOs to trust applications that include open source code.

The latest example comes from researchers at Datadog Security, who said that last month they found 17 packages (23 releases) in the npm repository that contained downloader malware for Windows systems that executes via a postinstall script.

The associated packages masquerade as Telegram bot helper packages, icon libraries, or legitimate-seeming forks of preexisting projects such as Cursor and React. They provide legitimate functionality, but their actual goal is to execute the Vidar infostealer malware on the victim system. Datadog believes this is the first public disclosure of Vidar malware being delivered via npm packages.

Both of the accounts offering these packages (aartje and** **saliii229911 ) have since been banned. However, they were on the registry for about two weeks, and the malicious packages were downloaded at least 2,240 times. However, the researchers believe many of those downloads were likely by automated scrapers, with some occurring after the packages had been removed and replaced with empty security holding packages.

All sorts of nasty things

Malicious compromise of open source components can lead to all sorts of nasty things. First, threat actors can steal developers’ credentials and insert backdoors into their code. Second, the malicious code in the downloaded component itself could spread around the world to the developer’s customers.

The Datadog discovery is just another in a long list of malicious code uploaded to npm, PyPI, GitHub, and other open source repositories.

Last week, Koi Security reported finding 126 malicious packages in npm, and in September, researchers at Step Security reported that dozens of npm libraries had been replaced with credential stealing code. The same month, researchers at Aikido reported that 18 highly popular and highly downloaded npm packages had been contaminated.

“I don’t know how to easily solve this problem without requiring a full security view of any newly submitted code, and that’s not fast, cheap, or easy,” commented Roger Grimes, digital defence CISO advisor at KnowBe4.

“But it really is the only answer if you want reliable, safe, open source code.”

Ironically, he said, one of the biggest reasons given for the world to use open source code is that it’s readily reviewable, so anyone can look at it to see and stop vulnerabilities. “But the reality is that almost no one security reviews any of the tens of millions of lines of open source code,” he pointed out.

“There have been dozens of open source projects that attempted to implement more default code review and all have failed,” he said. “One of my favorite related quotes of all time is, ‘Asking for users to review open source code before using is like asking passengers of an airliner to step outside the jet and review it for flight safety before they fly.’ I’m not sure who said that first, but it’s a brilliant summary of why volunteer open source code review really doesn’t work.”

Typosquatting

One favorite tactic of threat actors trying to infect the open source software supply chain is typosquatting, the creation of packages with names similar to those of legitimate ones to trick unwitting developers searching for a particular library. For example, in 2018 a researcher found that threat actors had created phony libraries in the Python repository called ‘diango,’ ‘djago,’ ‘dajngo,’ to dupe developers seeking the popular ‘django’ Python library.

CISOs should ensure that employees are educated about the issue of typosquatting and learn what to look for. IT departments should keep a comprehensive inventory of what components are used by all approved software against which audits can be conducted, to ensure only approved components are in place. This inventory and audit should be performed to validate any new components that are introduced.

What more to do?

There’s no shortage of advice for developers and IT and infosec leaders to help them avoid being victimized by malicious packages in open source repositories.

One tactic is to include a software bill of materials in every application an IT department acquires. With it, the DevOps/DevSecOps teams can track software components, identify vulnerabilities, and ensure compliance.

In 2021, the US Cybersecurity and Infrastructure Security Agency (CISA) and the US National Institute for Standards and Technology (NIST) published an advisory, Defending Against Software Supply Chain Attacks, providing advice for creating secure open source apps. It starts with the creation of a formal supply chain risk management program to ensure that supply chain risk receives attention across the organization, even among executives and managers within operations and personnel across supporting roles, such as IT, acquisitions, legal, risk management, and security.

An organization can reduce its software attack surface through configuration management, the advisory says, which includes:

• placing configurations under change control;
• conducting security impact analyses;
• implementing manufacturer-provided guidelines to harden software, operating systems, and firmware;
• • maintaining an information system component inventory.

In addition, the Open Source Web Application Security Project (OWASP) offers this advice to developers using npm:

• always vet and perform due diligence on third-party modules that you install to confirm their health and credibility;
• hold off on immediate upgrades to new versions; allow new package versions some time to circulate before trying them out.
• before upgrading, make sure to review changelogs and release notes for the upgraded version.
• when installing packages, make sure to add the ignore-scripts suffix to disable the execution of any scripts by third-party packages.
• consider adding ignore-scripts to the .npmrc project file, or to the global npm configuration.

Finally, Andrew Krug, Datadog’s head of security advocacy, offered these additional tips:

• give developers the ability to install real-time package scanning at installation;
• guard against typosquatting and dependency confusion by prioritizing the use of internal package repositories as a guardrail for approved packages;
• maintain software bills of materials;
• Deploy SCA (software composition analysis) at every phase of the software development lifecycle. Traditional SCA tools only periodically analyze code snapshots, he said, but effective detection must be complemented with real-time visibility into deployed services, including production, to reprioritize issues and focus on those exposed in sensitive environments.