3

I recently came across following article

https://www.bleepingcomputer.com/news/security/researcher-hacks-over-35-tech-firms-in-novel-supply-chain-attack/

it describe about an exploit which exploit design flaws of different package managers ex: package manager preferring higher version numbers, public packages over private ones

But article does not provide any details on how to mitigate these type of attacks? Big companies seems to have implemented mitigation strategies according to the article.

Anyone more knowledgeable please share how protect from dependency confusion attacks when using package mangers like NPM, Pip, Maven, Gradle, RubyGems, Stack.

user158
  • 181
  • 1
  • 7

2 Answers2

2

Microsoft published a white paper describing a few mitigation strategies. To summarize them:

  1. Make use of a single dependency source instead of multiple: The idea here is to configure your package manger (e.g. via the pip config file) to only pull packages from a singular repository you control or trust. I guess in the "best" case you'd restrict it to a private repository you manage and mirror/copy over packages you need from other sources. There are some real downsides to that though (keeping third-party packages up-to-date is one).
  2. Use something called "scopes" where applicable: Many package managers have a concept of "scopes" (e.g. https://docs.npmjs.com/cli/v7/using-npm/scope) where packages can be assigned a prefix that is unique to the controlling organization. This is especially useful if you make use of internal packages. Even if you don't plan on publishing them, you can register an organization and then (internally) make sure your package lists always use your organization name "scope". I believe yarn v2's workspace feature can be used to mitigate this as well.
  3. Use client-side features to reduce the probability you will accidently upgrade to a malicious version. Some examples here are version pinning (e.g. "8.9.x" instead of ">=8.9") and integrity verification (npm ci instead of npm install)

3 is not a strong guarantee in my opinion, but is easy to do. 1 is sometimes a good option, but can be hard to implement/maintain. 2 is probably the "best" option, at least for preventing your internal packages from being compromised this way.

Josiah
  • 231
  • 1
  • 8
1

The Gradle team published a paper discussing some of the mitigation strategies as it relates to Gradle and Maven. They talk about a wide range of topics like signing commits, disposable containers, build caches, etc. But getting to how to mitigate this particular attack here were some highlights:

  • Verifying dependencies with Gradle's trusted-key
  • Repository filtering using includeGroup, includeGroupByRegex
  • Gradle Wrapper checksum verification
  • Dependency Locking
  • Reproducible Builds

There's lots of good advice in there, but tackling the dependency confusion attacks we just saw using the repository filtering can stop that type of attack. So limit your private packages to a single repository can stop the dependency confusion. But, that won't stop all supply chain attacks.

Microsoft's suggestion of single repository is also a good strategy, but much of the same issues exist there too when it mirrors a set of repos. But at least that is a single point of control.

chubbsondubs
  • 205
  • 1
  • 7