Bruno Peeters Technical Blog

Packages are now commonly used within modern software development, with managers like for example nuget we can easily install and update within our solution. These packages are stored on a package distribution platform, from where everyone can download and use these packages. Due to the popularity of this containerized way of working, this also became more interesting for others who want to inject their (malicious) code. In this way their code is integrated in some other solution, without being noticed by the main developer itself and the users.

Mainly, we can distinguish the following types of package attacks:

• Typosquatting attack
• Brandjacking
• Dependency confusion attack
• Dependency hijacking
• Revival hijack

Typosquatting attack

Within this type of attacking, the attacker uses a small change in the name of the package. In this way the attacker hopes one doesn’t see the difference between a package System.Text.Json and Sysstem.Text.Json. So system with a double s.

The attacker hopes that someone makes a small typo in the name of the package and therefore downloads the package from the attacker.

Brandjacking

With brandjacking, the attacker lifts on the name of a well-known provider of packages. For example a package can be called Microsoft.Sql.SimpleDatabase. When reading the name of this package, someone might think it is a valid package from Microsoft, but in fact it is not.

Dependency confusion attack

If a package depends on other packages, these packages can either being installed from public or private repositories. When the package manager installs the dependencies, it looks both into the public and the private ones. If the depending package exists in the public repo, some package managers will prioritize this version rather than using the private one.

So lets say within a company they have defined a package that is depending on an internal developed package that resides only on a private repository. If an attacker puts a malicious package with the same name on a public repo, and a developer tries to restore a package and its depending packages, it might get this malicious package instead of the private local version.

Dependency hijacking

This type of hacking relies on the fact an attacker gains control over a dependency name. This can be done for example by compromising the maintainer account credentials. The hacker posts a depending package with the same name within a repository. In this way all package managers that are depending on the package having the same name, will download and use this hijacked package.

Revival hijack

With the revival hijack, once registers a new project using the same name of a package that has been removed from a package distribution platform. When someone removes a package that can be trusted, someone else can register after that a package containing malicious code using the same (old) package name. You can compare this with for example a domain registration. When someone decides to un-register a domain, let’s say mydomain.com, it will be available for other people to register. If one does so, it can register again this mydomain.com domain and create a website that looks exactly as the old mydomain.com site, but contains code that can harm the visitor.

The same goes with packages; when someone looks for a package with this name, he or she is not aware that the new package isn’t the same as the old one (that can be trust). When installing this package without knowing, the package with the malicious code will be used, instead of the package that people actually wanted to use in their project.

Note that this form of hijacking looks close to dependency hijacking, but it is used in a different lifecycle of the package. Within dependency hijacking the package is still alive, while within the revival hijack the package is removed and introduced later back again.