Preventing malicious packages and supply chain attacks with Snyk

Open source packages play a critical role in modern software development, fueling the rapid pace of development we’re witnessing all around us. For a developer looking to introduce new functionality into his application, it simply doesn’t make sense to reinvent the wheel. Why not simply install a package that someone else has already invested the time in building and that provides the exact same functionality?

But the reality is, open source packages are also an ideal vessel for distributing malicious code into applications and undermining supply chain security. The reasons for this is simple: they are an easy and rewarding target for attackers. Packages get uploaded to package registries with no security oversight and they get downloaded — millions of times a week in the case of popular projects — into codebases with almost the same amount of scrutiny.

Registries like npm, PyPI, and RubyGems have all seen their fair share of malicious packages over the past few years, so it is not a matter of one ecosystem being more vulnerable than another. This is an inherent security weakness in the way modern software is built, a weakness that must be acknowledged and addressed by security teams — and more importantly — by developers.

In this post, we’ll take a quick look at how malicious packages are used in software supply chain attacks, and then we’ll look at how Snyk can help in preventing them.

Malicious packages in software supply chain attacks

Software supply chain attacks aim to inject malicious code into a software product in order to compromise dependent systems further down the chain. But software supply chain attacks come in different shapes and sizes, differing in the target of the attack and the exact method used.

In the SolarWinds attack, for example, the targets of the attack were software build processes and source code. In the recent Kaseya attack, the target was pre-existing software. And in more and more cases, open source packages are the target of attack. In this type of software supply chain attack, malicious code is injected into a package listed on a package repository (e.g. npm, PyPI, Ruby Gems).  Developers blindly trusting the authenticity and integrity of these packages will unknowingly download and install these malicious packages either manually or as part of an automated build process.

From the attacker’s perspective, this method can prove to be highly effective. Open source packages get downloaded millions of times a day and so provide a perfect distribution mechanism. The notable 2018 event-stream attack shows the potential reach of a software supply chain attack using malicious packages. In this case, the attacker first gained control of the highly popular event-stream package and then modified it to depend on a malicious package, flatmap-stream. At the time, event-stream was used by 1,600 packages and downloaded 1.5M times a week.

How is malicious code injected into packages?

One attack method is to create a brand new package that contains malicious code. These packages might use a name similar to an existing package (typosquatting) or reuse the name or identifier of an existing package withdrawn by the original package maintainer (“use after free” exploit). The second method is to infect an existing package by injecting malicious code into the sources, during the build, or into the package repository. All it takes is a seemingly innocent pull request containing the malicious code being merged by the project maintainer. A third method involves uploading malicious packages to alternative repositories or repository mirrors.

Once a malicious package finds itself on the dependency tree of a project, there are different ways in which the malicious code is executed. In many cases, install scripts are executed during the installation of the package. In other cases, the malicious code needs to be invoked during runtime.

Mitigating malicious packages with Snyk

So how do you protect yourself from malicious packages?

For each ecosystem, there are specific strategies for preventing malicious packages from infiltrating into your codebase. For JavaScript, for example, we’ve detailed some best practices in this cheatsheet. As an application security solution, Snyk also provides a number of built-in ways for identifying malicious packages early on in the development process but also in later stages.

Shifting due diligence left

Shifting application security left has long become a de facto standard. The most effective teams automate security testing as early as within the local development environments, in their IDEs. But security, and the process of identifying malicious packages, can also take place before you enter your first line of code — during your planning and research stage. 

Due diligence is always a good best practice when researching what piece of software to pull into your project but researching a specific package is not always simple. In a perfect world, package registries would provide all the information needed for making the decision on whether to install a package or not, including whether the package is safe and secure. But in reality, registries lack a lot of missing bits and pieces related to package health and security.

Snyk Advisor is a free, online, research tool that can help you decide which package to use in your projects. Snyk Advisor displays a health score that is based on a number of important factors that should be taken into consideration when selecting a package. For example, Snyk Advisor will analyze the level of maintenance for a package — based on released versions cadence and repository activity. Snyk Advisor will also analyze the popularity of a package as well as the strength of the community backing the project.

And of course, Snyk Advisor will also factor in the security status of a package. Security data is based on the Snyk Intel Vulnerability Database and includes information about whether the package is malicious or not. In the example below, the lyft-dataset-sdk npm package is flagged by Snyk Advisor as a malicious package that can be used for dependency confusion — the package has the same name as a Python package authored by Lyft and so can easily infiltrate a codebase with this dependency defined.

The Snyk Vulnerability Database also flags malicious packages and can be leveraged as part of your research process.

In the typosquatting example below, a gem by the name of auth-client is marked as being malicious. The author/s of this particular gem purposely used a name that is extremely close to the names of existing — and secure — Ruby packages (e.g. auth_client, authclient) in the hopes that a developer mistypes the name of the dependency to download the trojanized package.

Tackling malicious packages across the SDLC

Even with thorough research, malicious packages can still slip under the radar. Snyk’s security testing is applied across various stages of the SDLC to ensure these packages are identified as quickly as possible.

For Git projects monitored by Snyk, any new pull request triggered by a contributing developer will be checked against the Snyk Vulnerability Database. In case a malicious package is identified, the security test will fail with information about the package and why the test failed.

What about malicious packages already in your backlog? When faced with hundreds if not thousands of vulnerabilities, finding one issue introduced via a malicious package can be a daunting task to even the most experienced team.

Snyk also flags malicious packages within the Snyk UI. For projects monitored by Snyk, this information is factored into a vulnerability’s Priority Score, alongside the other factors calculated, such as the vulnerability’s CVSS score, the availability of a fix, whether the vulnerability is currently trending on social media, known exploits, how new the vulnerability is, and whether it is reachable or not. This helps you quickly find, prioritize and fix these specific issues:

Taking action, early on

From the attacker’s standpoint, the ease with which packages are uploaded to registries, with no security scrutiny whatsoever, coupled with the ever-increasing reliance on these packages for maintaining a fast pace of development, makes this attack extremely attractive.

This is an inherent security weakness in the way applications are built today, one that requires that development and security professionals be able to identify malicious packages starting from the very initial research stages, during the process of selecting which package to use but also later on in development.

To learn more about Software Supply Chain Security click here.