New ‘dependency confusion’ attack technique recognized by Microsoft
New “dependency confusion” technique, also known as a “substitution attack,” allows threat actors to sneak malicious code inside private code repositories by registering internal library names on public package indexes.
Microsoft published a document regarding this new attack method, which was discovered by a team of researchers on the 9th of February. It leverages the programming and development processes of applications, mostly in an enterprise environment.
Nowadays, developers use package managers to download and upload program libraries, and then use applications made for this exact purpose, to create the program to be developed. Because applications under development can contain sensitive data and code in many cases, companies often use their own private libraries, which are placed on an internal repository within their own network. However, during development processes, the use of public packages can rarely be avoided, which is why professionals tend to use a mix of the private corporate and the publicly available libraries.
NEW “DEPENDENCY CONFUSION” ATTACK
In a research published on Tuesday (9th of February), a team of security researchers has detailed a new concept called “dependency confusion” that attacks these mixed app-building environments inside large corporations.
Researchers showed that if an attacker learns the names of private libraries used inside a company’s app-building process, they could register these names on public package repositories and upload public libraries that contain malicious code.
The “dependency confusion” attack takes place when developers build their apps inside enterprise environments, and their package manager prioritizes the (malicious) library hosted on the public repository instead of the internal library with the same name.
The research team said they put this discovery to the test by searching for situations where big tech firms accidentally leaked the names of various internal libraries and then registered those same libraries on package repositories like npm, RubyGems, and PyPI.
Using this method, researchers said they successfully loaded their (non-malicious) code inside apps used by 35 major tech firms, including the likes of Apple, Microsoft, PayPal, Shopify, Netflix, Yelp, Uber, and others.
But besides npm, RubyGems, and PyPI, other package managers are also vulnerable, researchers said, including the likes of JFrog and NuGet.
MICROSOFT URGES COMPANIES TO ANALYZE INTERNAL PACKAGE REPOS
While the research team said it notified all the affected companies and package repositories, Microsoft appears to have understood the severity of this issue more than the others.
After the research team’s work went public on Tuesday, the OS maker, which also runs the NuGet package manager for .NET developers, has published a white paper detailing the dependency confusion technique, which Microsoft calls “substitution attack.”
The white paper warns companies about hybrid package manager configurations, where both public and private library sources are used, but also details a series of mitigations that companies can apply to avoid dependency confusions within their build environments.
The key recommendations for mitigating the threat are:
- Reference one private feed, not multiple
- Most package manager clients will query all package feeds listed in the local configuration without regard for order or priorities. npm is a notable exception as it requires controlled scopes, which we discuss in the second mitigation strategy. For package managers who do not prioritize feeds, we recommend configuring the client to reference a single private feed. This may require pushing public packages to your private feed manually or configuring the private feed to pull them automatically.
- Protect your private packages using controlled scopes on public package repositories
- Some package managers support controlled scopes, namespaces, or prefixes. The details vary by ecosystem, but the purpose is to protect a range of package names. These can be used with packages that you control to protect against an attacker publicly claiming a name that you use privately or to provide confidence that your own team released public packages.
- Utilize client-side verification features, such as version pinning and integrity verification
- Beyond the protection offered by carefully managing sources, package managers provide additional client-side verification features to protect against supply chain attacks. These include options such as version pinning and integrity verification.
Sources:
https://azure.microsoft.com/en-us/resources/3-ways-to-mitigate-risk-using-private-package-feeds/