NuGet Security Alert: Malicious Packages Discovered with Delayed ‘Time Bomb’ Payloads

[johny899]

You won't believe this - some NuGet packages (the code libraries for .NET developers) contained something not-so-nice. I'm not talking run-of-the-mill bugs or broken code, I mean something that acted like a time bomb on your computer that was set to go off years in the future! As someone who regularly uses NuGet, this gave me chills. Have you ever trusted and installed a library without extremely scrutinizing it first? I know I have.

What’s Actually Happening​

Can we trust NuGet Packages

A small team of security researchers at Socket identified nine malicious packages published by the user "shanhai666." They looked like common tools, but contained instructions at a later date to go "mess up" systems. Some of the instructions were even for targeting industrial machines!

Who is at Risk?

These malicious packages were impersonating real packages that are normally used for database interaction, including:

• SqlUnicorn.Core
• SqlDbRepository
• SqlLiteRepository

And, there was even a fake version of Sharp7, a library used for communicating with Siemens industrial controllers (PLCs). The fake package was named Sharp7Extend - clever, right?! The code was designed to include the actual Sharp7 library, but included malicious commands to compromise data writes over time.

The "Time Bomb" Wander

Here's the unsettling part - the malicious code doesn't trigger immediately. It's programmed to "go off" sometime in 2027 or 2028!

So a developer could implement it today, and for all intents and purposes, it appears to work fine - until one day something magically breaks. Some versions will actually decide randomly when to trigger, which makes it even more challenging to document or prove.

Why it Matters​

As you read this, you should be thinking, "Why should this be something I should care about?" Well

• You may be compromising your project and inserting some sort of hidden threat without even knowing
• These types of strikes could target some data store or factory system that doesn't get triggered until a couple years later, when nobody remembers where the code was written or found
• To be frank, most folks just don’t get into the habit of double checking each and every library that they implement, I know I don’t.

You can really see how scary and difficult supply-chain attacks (attacks from the code source you download and trust) can be.

Tips for Keeping Safe​

Here are some easy things everyone can do:

• Look up the author of the package. If you do not recognize the name, check it out.
• Look for typos, or just weird variations of well-known packages.
• Lock your package versions (that is, do not let them automatically update without your consent).
• Use security tools to scan packages for embedded security issues.
• Do not install a package that connects to critical systems unless it comes from a known developer whom you can trust.