We use cookies to ensure you get the best experience on our website.Read moreRead moreGot it

close
  • Products
    • Products
      • Snyk Code (SAST)
        Secure your code as it’s written
      • Snyk Open Source (SCA)
        Avoid vulnerable dependencies
      • Snyk Container
        Keep your base images secure
      • Snyk Infrastructure as Code
        Develop secure cloud infrastructure
      • Snyk Cloud
        Keep your cloud environment secure
    • Solutions
      • Application security
        Build secure, stay secure
      • Software supply chain security
        Mitigate supply chain risk
      • Cloud security
        Build and operate securely
    • Platform
      • What is Snyk?
        Developer-first security in action
      • Developer security platform
        Modern security in a single platform
      • Security intelligence
        Comprehensive vulnerability data
      • License compliance management
        Manage open source usage
      • Snyk Learn
        Self-service security education
  • Resources
    • Using Snyk
      • Documentation
      • Vulnerability intelligence
      • Product training
      • Support & services
      • Support portal & FAQ’s
      • User hub
    • learn & connect
      • Blog
      • Community
      • Events & webinars
      • DevSecOps hub
      • Developer & security resources
    • Listen to the Cloud Security Podcast, powered by Snyk
  • Company
    • About Snyk
    • Customers
    • Partners
    • Newsroom
    • Snyk Impact
    • Contact us
    • Jobs at Snyk We are hiring
  • Pricing
Log inBook a demoSign up
All articles
  • Application Security
  • Cloud Native Security
  • DevSecOps
  • Engineering
  • Partners
  • Snyk Team
  • Show more
    • Vulnerabilities
    • Product
    • Ecosystems
Snyk Advisor for malicious npm package
Application SecurityEngineeringOpen Source

Exploring extensions of dependency confusion attacks via npm package aliasing

Nishant JainNovember 4, 2021

Dependency confusion attacks are a form of open source supply chain security attacks in which an attacker exploits how package managers install dependencies. In a prior post, we explored how to detect and prevent dependency confusion attacks on npm to maintain supply chain security.

In this article, we will present an extension of the dependency confusion problem utilizing npm’s package aliasing capabilities. This package aliasing capability, as provided and instructed by the npm command-line application, is a user-only way to install a package under a different alias. Per npm’s own documentation, refer to the following as an example:

npm install my-react@npm:react

This creates the following package.json entry:

dependencies: {
  “my-react”: “npm:react”
}

The repercussions of npm package aliasing reveal themselves in the way other package-related tooling handles package manifests, and in fact, applies to the official npmjs.org registry itself. Although this attack scenario has no direct security consequences (because the aliased package would always download the version of the package specified in the npm command), we believe that it does create more room for other attack vectors.

Carrying out an npm package aliasing attack scenario

Let’s reproduce the impact of npm package aliasing attacks to demonstrate how this can result in potential dependency confusion and the installation of malicious rogue packages.

We begin by creating a package named deneuve-package-parent that installs two different versions of the deneuve-package-test package: versions 1.0.0 and 1.2.0. Version 1.0.0 gets installed due to it being aliased with the name of a made-up package deneuve-package-private, thanks to npm package aliasing.

This is parsed on npmjs.com as one of the dependencies of the deneuve-package-parent.

Consider the following package.json as a full reference for the package dependency tree described above:

{
  "name": "deneuve-package-parent",
  "version": "1.2.0-beta",
  "description": "This is the parent package!",
  "main": "index.js",
  "scripts": {
    "test": "echo \"Hello\""
  },
  "author": "deneuve@wearehackerone.com",
  "license": "ISC",
  "dependencies": {
    "deneuve-package-test": "^1.2.0",
    "deneuve-package-private": "npm:deneuve-package-test@1.0.0"
  }
}

We went ahead and published the package to npmjs. Then we browsed over to the list of dependencies.

As you can see, the list of dependencies on the npmjs registry actually lists the made-up alias deneuve-package-private as one of the dependencies’ names:

dependency confusion attacks on npmjs

The above screenshot shows a dependency named deneuve-package-private, which we created as an alias in our package.json, and not as a real dependency. This alias (being used as a package name) doesn’t actually exist on the npmjs registry… unless someone publishes it! And that’s where supply chain security concerns kick in.

Dependency confusion attack on npmjs results in 404 page for a seemingly real dependency

This then begs the question: what if someone would find such aliased packages and then publish them as malicious packages to npm? Confused users, may then see a dependency listed on an official npmjs package page, and may consume them by simply running a local npm install on their development machine:

$ npm install deneuve-package-private

This is a possible scenario if a developer chooses to debug the application and decides to download each library individually. Let’s be honest, how often do developers verify whether or not they are downloading a package that is meant to be private? All it takes is a simple error or oversight, which can happen even when companies have policies against the downloading of unscoped packages.

We went ahead and published a null package of that name to the npmjs registry. As you can see, if you browse the Dependents tab, it actually links back to the original package that referred to it in one of its dependents’ aliases:

Dependency confusion attacks on npmjs due to wrong context of npm package alias

This should be a call for attention to any developer tooling that handles package names, such as the npmjs registry itself, to ensure they don’t confuse their users with regard to package names.

The fact that typosquatting package names is still an effective supply chain attack vector demonstrates that even the slightest air of legitimacy (as seen in package aliasing) can boost an attack’s success rate significantly.

Some background on this finding

This form of supply chain attack was recently discovered by myself and fellow security researcher Mario Stathako, and we reported it to GitHub and npm. I’m a graduate student who has been spending time researching and developing bug bounty security resources. I’m also a Snyk Ambassador! Mario is a penetration tester who regularly participates in Capture the Flag (CTF) and bug bounty programs.

Dependency Confusion caught my interest because it was something so basic that had such a big impact! So Mario and I began searching for this issue on HackerOne’s private programs. We wanted to see how successfully firms responded to/mitigated popular research after a specific period of time had elapsed. We discovered some strange behavior on the NPM website while constructing POC packages for the attacks, and that was the way the package.json file was being processed for different packages and how it listed the dependents and dependencies of that package.

Protect yourself from supply chain security concerns

Snyk has developed and published an open source command-line application called snync to assist you in detecting and warning of potential dependency confusion (and related) attacks. You can learn all about that tool in this npm dependency confusion detection and prevention blog.

Additionally, the Snyk Advisor is a helpful tool to flag security issues in packages, across their versions, and explicitly shows if a package has been found to be malicious:

A malicious package on npm is shown on the Snyk Advisor package page

Finally, here’s some recommended following-up reading on open source supply chain security best practices:

  • Detect and prevent dependency confusion attacks on npm to maintain supply chain security
  • Preventing malicious packages and supply chain attacks with Snyk
  • 10 npm Security Best Practices

Secure your open source dependencies

Scan for vulnerabilities in your open source libraries for free with Snyk.

Sign up for free

Discuss this blog on Discord

Join the DevSecOps Community on Discord to discuss this topic and more with other security-focused practitioners.

GO TO DISCORD
Footer Wave Top
Patch Logo SegmentPatch Logo SegmentPatch Logo SegmentPatch Logo SegmentPatch Logo SegmentPatch Logo SegmentPatch Logo SegmentPatch Logo SegmentPatch Logo SegmentPatch Logo SegmentPatch Logo SegmentPatch Logo SegmentPatch Logo Segment
Develop Fast.
Stay Secure.
Snyk|Open Source Security Platform
Sign up for freeBook a demo

Product

  • Developers & DevOps
  • Vulnerability database
  • API status
  • Pricing
  • IDE plugins
  • What is Snyk?

Resources

  • Snyk Learn
  • Blog
  • Security fundamentals
  • Resources for security leaders
  • Documentation
  • Snyk API
  • Disclosed vulnerabilities
  • Open Source Advisor
  • FAQs
  • Website scanner
  • Code snippets
  • Japanese site
  • Audit services
  • Web stories

Company

  • About
  • Snyk Impact
  • Customers
  • Jobs at Snyk
  • Snyk for government
  • Legal terms
  • Privacy
  • Press kit
  • Events
  • Security and trust
  • Do not sell my personal information

Connect

  • Book a demo
  • Contact us
  • Support
  • Report a new vuln

Security

  • JavaScript Security
  • Container Security
  • Kubernetes Security
  • Application Security
  • Open Source Security
  • Cloud Security
  • Secure SDLC
  • Cloud Native Security
  • Secure coding
  • Python Code Examples
  • JavaScript Code Examples
  • Code Checker
  • Python Code Checker
  • JavaScript Code Checker
Snyk|Open Source Security Platform

Snyk is a developer security platform. Integrating directly into development tools, workflows, and automation pipelines, Snyk makes it easy for teams to find, prioritize, and fix security vulnerabilities in code, dependencies, containers, and infrastructure as code. Supported by industry-leading application and security intelligence, Snyk puts security expertise in any developer's toolkit.

Resources

  • Snyk Learn
  • Blog
  • Security fundamentals
  • Resources for security leaders
  • Documentation
  • Snyk API
  • Disclosed vulnerabilities
  • Open Source Advisor
  • FAQs
  • Website scanner
  • Code snippets
  • Japanese site
  • Audit services
  • Web stories

Track our development

© 2023 Snyk Limited
Registered in England and Wales
Company number: 09677925
Registered address: Highlands House, Basingstoke Road, Spencers Wood, Reading, Berkshire, RG7 1NT.
Footer Wave Bottom