NuGet

About

NuGet is the package manager for .NET, and nuget.org is its public registry. ASP.NET apps and the custom code built for SharePoint pull their libraries from it. Microsoft publishes there too, alongside thousands of independent authors.

A package can add build steps that run whenever the project builds, with the rights of whoever builds it, on developers' machines and the build server. The library itself runs inside the app when it starts.

If It Is Malicious

If a NuGet package is malicious, it runs inside a .NET app with the app's rights, on every build server that restores it and every server that runs the app.

Its code runs inside these technologies.

ASP.NET.NET

See It in the Stack

Examples

These are well-known names from NuGet, written as you would meet them in an inventory, an alert or a lockfile, the file that records every version a build installed.

Newtonsoft.Json

The JSON library a large share of .NET projects use.

Serilog

Structured logging for .NET apps.

Microsoft.Data.SqlClient

Microsoft's driver for connecting to SQL Server.

Dapper

A light library for database queries.

Polly

Retries and timeouts for calls between services.

How Bad Code Gets In

These are the ways bad code can reach your systems through NuGet. None of them needs a flaw in your own code, so outside code needs checking as much as your own.

• A package named like a popular or Microsoft one catches careless installs.
• A package adds build steps that run code on every machine that builds the project.
• A maintainer's account or API key is stolen and a bad version is published.
• A private feed set up next to nuget.org can fetch the wrong copy of an internal name.

How to Check

These checks show what came from NuGet, whether a known bad version is in use, and how to keep one out next time.

• Keep NuGet Audit on, set to check indirect packages too, so every restore warns about packages with known flaws.
• Run dotnet list package --vulnerable --include-transitive to see flawed packages, indirect ones included.
• Commit a packages.lock.json lock file and restore in locked mode in builds.
• Tie each package name to one feed with package source mapping.
• Prefer packages under a reserved ID prefix, which nuget.org marks as coming from the prefix's owner.

Well-Known Incidents

Each incident below is a real case, told at the level of its public advisory. The tag says how the bad code got in, and the link opens the primary source.

• Typosquat2023

  Impostor Packages on NuGet

  Packages named like popular ones, one posing as a Coinbase library, ran a PowerShell script on install that fetched malware aimed at cryptocurrency wallets.

  Reach Developers who installed them in Visual Studio ran the malware on their own machines.

  AffectedCoinbase.CoreAnarchy.Wrapper.NetDiscordRichPresence.API

  Source: jfrog.com (opens in a new tab)

In Common Stacks

These common stacks take code from NuGet. Open one to see where that code sits among its layers and who runs each one.

• SharePoint, On Premises

Sources

• Microsoft Learn: auditing packages (opens in a new tab)
• Microsoft Learn: package source mapping (opens in a new tab)
• Microsoft Learn: NuGet supply chain best practices (opens in a new tab)