What are Malicious Packages? How Do They Work?
Table of Contents
Have you ever built a house of cards, only to watch it all come tumbling down?
That’s the feeling you get when a malicious package, a software package containing malware, infiltrates your software. These seemingly harmless bits of code, lurking in trusted repositories like npm and RubyGems, can wreak havoc on your applications and steal your data.
In this article, you can expect to learn how malicious packages work, the different ways they can infiltrate your systems, and the growing threat they pose. We’ll also explore the impact they can have on your organization and how to defend yourself against these digital tricksters.
A fast-growing threat
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.
Anatomy of a malicious package attack
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.
Malicious packages are more dangerous than vulnerabilities
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.
Malicious package attack vectors
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.
Malicious package attack examples
Malicious packages can be used for a variety of nefarious purposes. For instance, we saw a package on npm that stole AWS IAM data, with techniques similar to those used in the Capital One hack.
Similarly, another more recent critical vulnerability involved a malicious version of a popular utility, which could be exploited to gain unauthorized access via SSH.
The fight against malicious packages is an ongoing battle. As attackers become more sophisticated, so too must our defenses. The future of software security likely involves a combination of automated detection tools, developer education programs, and increased collaboration between open-source communities and security vendors. By staying vigilant and adapting to new threats, we can keep malicious packages from becoming the norm.
