The .NET Stacks #37: 😲 When your private NuGet feed isn't so private

Dave Brock -

Good morning to you. Is it summer yet? This week, I’m trying a new format: an in-depth topic, a lot of little things I’ve found, and, of course, the links. I appreciate any feedback you have.

  • One big thing: A supply chain attack that should scare any company
  • The little things: Container updates, typed exceptions, Blazor REPL
  • Last week in the .NET world

One big thing: A supply chain attack that should scare any company

When installing packages—whether over NPM, Python, and for us, NuGet—you’re happy not to have to deal with the complexities of dependency management personally. When you do this, you’re trusting publishers to install packages and code on your machine. When you install a package, do you ever wonder if this is open to exploits? It certainly is.

This week, Alex Birsan wrote about what he’s been working on for the last 6-7 months: hacking into dozens of companies—using a supply chain attack (or, as he calls it, dependency confusion). The ethical hack stems from a finding at Paypal last year, where Justin Gardner found that PayPal included private dependencies in a package.json hosted on GitHub. Those dependencies didn’t exist in the public NPM registry then, begging the question: what happens if you upload malicious code to NPM under those package names? Will the code get installed on PayPal-owned servers?

It isn’t just PayPal:

Apparently, it is quite common for internal package.json files, which contain the names of a javascript project’s dependencies, to become embedded into public script files during their build process, exposing internal package names. Similarly, leaked internal paths or require() calls within these files may also contain dependency names. Apple, Yelp, and Tesla are just a few examples of companies who had internal names exposed in this way.

It worked like a charm. The .NET Stacks is a family newsletter, so I’ll channel The Good Place: holy forking shirtballs.

From one-off mistakes made by developers on their own machines, to misconfigured internal or cloud-based build servers, to systemically vulnerable development pipelines, one thing was clear: squatting valid internal package names was a nearly sure-fire method to get into the networks of some of the biggest tech companies out there, gaining remote code execution, and possibly allowing attackers to add backdoors during builds.

I know what you’re thinking: JavaScript is insecure. Is this where I pretend to be shocked? The hack had impacts on .NET Core as well:

Although this behavior was already commonly known, simply searching GitHub for –extra-index-url was enough to find a few vulnerable scripts belonging to large organizations — including a bug affecting a component of Microsoft’s .NET Core.

From the .NET side, Barry Dorrans noted:

So Microsoft fixed their problem. What about us? Microsoft has developed a whitepaper for using private feeds. Their three suggestions for NuGet feeds:

  • Reference a single private feed, not multiple, by using a single <add/> entry for a private feed in nuget.config, and a <clear /> entry to remove inherited configuration
  • Use controlled scopes using an ID prefix to restrict uploads to the public gallery
  • Use a packages.lock.json file to validate packages have not changed using version pinning and integrity checking.

If you manage private NuGet feeds, make sure to heed the advice.

The little things: Container updates, typed exceptions, Blazor REPL

If you’re like me, pulling containers from the Microsoft container registry is a simple process. I pull the images and move on. This week, Rich Lander outlined the complexities the team encounters. How hard can managing Dockerfiles be? When it comes to supporting a millionish pulls a month, it can be. A lot of the issues come with tracking potential vulnerabilities and how to manage them. He also offers some tips we can use: like rebuilding images frequently, reading CVE reports, and so on. It’s a long one but worth a read if you work with .NET container images.

On a related note, this week Mark Heath wrote an excellent post around Docker tooling for Visual Studio 2019.

–

In this week’s Entity Framework community standup, the team talked with Giorgi Dalakishvili about his EntityFramework.Exceptions project, which brings typed exceptions to Entity Framework Core. The project gets past digging into DbUpdateException to find your exact issue—whether it’s constraints, value types, or missing required values.

With EntityFramework.Exceptions, you can configure the DbContext to throw different exceptions, like UniqueConstraintException or CannotInsertNullException. It’s another great project where we wonder why it isn’t baked in, but happy it’s here.

–

Have you heard of the Blazor REPL project?

Blazor REPL is a platform for writing, compiling, executing and sharing Blazor components entirely in the browser. It’s perfect for code playground and testing. It’s fast and secure. The platform is built and is running entirely on top of Blazor WASM - the WebAssembly hosting model of Blazor.

You can write and run components right in the client. It’s perfect for you to test component libraries before you bring them into your project—the MudBlazor library has a site for this at try.mudblazor.com.

This week, the Blazor REPL project teased what’s coming—the ability to download NuGet packages and save public snippets.

–

ASP.NET Core architect David Fowler showed off some underrated .NET APIs for working with strings. I learned quite a bit, as I typically blindly use the same string methods all the time:

–

I recently learned about github1s.com, which allows you to browse code on GitHub with VS Code embedded in a browser for you. While you’re browsing a GitHub repo, change github.com to github1s.com to see it in action. Very nice.

🌎 Last week in the .NET world

🔥 The Top 3

📢 Announcements

📅 Community and events

🌎 Web development

🥅 The .NET platform

⛅ The cloud

📔 Languages

🔧 Tools

📱 Xamarin

🏗 Design, testing, and best practices

🎤 Podcasts

🎥 Videos