Software developers build approximately 80% of software applications using open-source code, which opens up a world of opportunity for today’s threat actors.
Code package repositories such as npm and RubyGems allow anyone to store or publish packages, and unfortunately that can include packages containing malware. These are known as malicious packages — the malware of the software supply chain.
As the name implies, a malicious package is software that is created with malicious intent. What makes them particularly concerning is that they are remarkably easy to create. Useful for any number of malicious intentions, these packages are hard to avoid and to detect, unless you know what to look for.
Malicious packages aren’t new, but they’re proliferating at an alarming pace. In our “Malicious Packages Special Report,” Mend identified a 315% increase in malicious packages published to npm and RubyGems alone from 2021 to 2022, and expects that trend to continue.
Malicious packages use similar techniques to trick people into downloading them, where they wreak havoc inside users’ systems. Because malicious packages are something that generally come from places you think you trust, they are abnormally effective.
Malicious packages are used to steal credentials, exfiltrate data, turn applications into botnets, or erase data. But first, attackers need to trick someone or something into downloading the package.
Malicious packages can deliver maximum bang for the bad guy’s buck. It can be as simple as hiding a malware payload in open source code and tricking a careless developer into using it, or elevating bugs in package manager systems and then benefitting from the opportunities afforded by the scale of a corrupted software supply chain. And make no mistake: Like any malware, malicious packages can inflict significant damage. They can steal credentials, exfiltrate data, turn you into a botnet, or erase your data.
This, of course, explains their growing popularity. Threat actors never ignore a good opportunity, particularly when it comes to attacking their favorite target: applications. Unfortunately, most companies are only now beginning to explore technology that can defend against malicious packages, and for many, the barn door has been open a little too long. Mend’s 360 degree malicious package protection has already discovered evidence of threat actor success — thousands of malicious packages hiding in existing code bases.
Once a developer downloads a malicious package, how much damage it does will depend on several key factors:
1. Intent – When threat actors infiltrate using a malicious package, their intent substantially determines the impact. A threat actor trying to inform people about a war or protest action with annoying messages has a lower overall impact than one trying to steal information or turn developers’ machines into cryptocurrency miners.
2. Organization type – Attacks designed to exfiltrate personal information will have a larger, potentially long-term impact on companies trusted with sensitive data. Ransomware attacks that disable systems can have an outsize impact in organizations like hospitals, where lives depend on uptime.
3. Duration – When malicious packages are discovered quickly and removed completely, the damage they cause can be limited. The greatest damage can be caused by packages that remain undetected for months or years while quietly delivering their payload.
4. Spread – Some of the most dangerous malicious packages are designed to provide initial access to a network, at which point the threat actor can move laterally through systems to steal passwords or protected information in order to gain even more access.
Unlike vulnerabilities — which can and do often exist for months or years in application code without being exploited — a malicious package represents an immediate threat to your organization.
Think of it like this: If your applications and organization are a house, then attackers are like burglars. A vulnerability is your proverbial unlocked window: It could let a burglar in some day, but that’s only a possibility. On the other hand, a malicious package is like accepting a FedEx box that already has the burglar inside.
In order to deliver a malicious payload via an open source package, attackers must find a way to get the package downloaded. That means attackers need to fool someone – or something – into downloading it. Let’s take a closer look at several of the ways that malicious packages can be downloaded. There are four basic attack vectors for malicious packages: brandjacking, typosquatting, dependency hijacking, and dependency confusion.
Brandjacking is an activity whereby an attacker acquires or otherwise assumes the online identity of another company or an owner of a package and then inserts a malicious code. It doesn’t necessarily mean he actively steals something, but just takes advantage of an opportunity to take ownership related to the brand name.
In a typosquatting attack, an attacker publishes a malicious package with a similar name to a popular package, in the hope that a developer will misspell a package name and unintentionally fetch the malicious version.
With dependency hijacking, an attacker obtains control of a public repository in order to upload a new malicious version.
With dependency confusion attacks, the threat actor creates a public repository package with the identical name of an internal package within the intended target system. The intention is to trick the target’s dependency management tools into downloading the malicious public package instead of the safe internal one.
The best defense against the growing threat of malicious packages is a knowledgeable and alert developer community in and around open source registries, combined with automated detection and response solutions.