Understanding the Anatomy of a Malicious Package Attack
Table of Contents
To identify malicious packages and protect yourself against them, you need to know what to look for. Here’s a simple guide.
In January 2022, users of the popular open-source libraries “faker” and “colors” suddenly found their applications started to malfunction and display nonsensical data because they had been infected by a malicious package. Similarly, in October, an attacker unleashed a typosquatting campaign against users of 18 legitimate packages that collectively receive over 1.5 billion weekly downloads. The attack released 155 malicious packages into the npm repository. Its objective was to distribute and install a Trojan that stole passwords.
Malicious packages like these are designed to disrupt or disable their targets’ software and applications. They’re alarmingly easy to create and difficult to identify and avoid unless you know what you’re looking out for.
A rapidly growing menace
Although they’re not a new phenomenon, malicious packages are proliferating at a startling rate. In the Mend.io Software Supply Chain Malware Special Report, we found that the number of malicious packages published on npm and RubyGems rose by 315% from 2021 to 2022. We anticipate that this growth will continue.
Malicious packages are a type of malware that deceives unsuspecting users into downloading them. Once downloaded, they can cause serious damage to the systems that they target. They’re highly effective because their sources seem trustworthy, so users are inclined to download them.
The damage from these packages comes about because they provide an automated and easy way for malicious code to enter systems with little or no effort from attackers. Once a package is uploaded, it operates on its own and unleashes its ill effects. Bad news for users. Great news for attackers. It’s no wonder that there has been a surge in malicious packages.
How malicious package attacks work
Attackers use malicious packages to steal or erase data and transform applications into botnets once they’ve deceived users into downloading the packages. They achieve this in four main ways:
- Brandjacking. Attackers assume the online identity of a company or package owner so users will trust and download their packages. Then they insert malicious code. When the dYdX cryptocurrency exchange was attacked, this was how it was infiltrated. In this attack, the malicious package versions contained a preinstall hook so it looked as if a CircleCI script was being downloaded.
- Typosquatting. This kind of attack relies on simple typographical errors that targets fail to notice. In these cases, when an attacker creates a malicious package, they deliberately name it in a way that closely resembles the name of a popular package. Then when developers misspell the name or don’t spot that it’s spelled differently, they open and download the malicious package.
- Dependency hijacking. Attackers gain control over a public repository to upload a new malicious version of an existing package.
- Dependency confusion. This occurs when a malicious package in public repositories shares the name of an internal package. Attackers exploit this to mislead dependency management tools into downloading the public malicious package.
Given the relative novelty of malicious packages, attackers’ methods are fairly unsophisticated. Typically, they rely on four techniques:
- Re- and post-install scripts
- Basic evasion techniques
- Shell commands
- Basic network communication techniques
The good news from a security perspective is that when attackers use a straightforward technique like network communication, it’s still reasonably easy to detect them, even when packages are successfully downloaded.
Nevertheless, attackers continually seek to make their techniques more effective and create newer, more complex ways to infiltrate target machines and systems. One example is telemetry for data collection. We anticipate that more and newer ways of creating and using malicious packages will be created.
Timing of attacks
Initially, it seems as though malicious packages are published randomly, and it’s arbitrary when attackers release them, but in fact, that isn’t the case.
Attackers try to maximize the effect of their malicious packages and optimize opportunities that they’ll get downloaded by timing their release. Our research found that Top of Form
Nearly 25% of malicious packages are published on Thursday afternoons. This could be because attackers realize that many cybersecurity companies are based in Israel, where the weekend is Friday and Saturday. So, they deliberately release these packages at a time when these vendors are winding down for the weekend.
Understand open source to protect it from malicious packages
The accessibility of open source software contributes significantly to the impact of malicious packages. Even people with relatively elementary programming skills can create these packages and publish the code to open source repositories that countless developers use. This is an environment that offers plenty of opportunities for malicious packages to get downloaded by unsuspecting users. It’s fertile ground from which malicious actors can launch successful attacks.
Therefore, understanding the implications of incorporating open source code into applications becomes crucial in this context. If you know the dangers, you can be vigilant and better prepared to protect your organization. A significant thing to bear in mind is that malicious packages pose an urgent threat, whereas vulnerabilities can lurk in a codebase for longer periods, sometimes without causing any deleterious effect. It’s therefore important to find and neutralize malicious packages as quickly and efficiently as possible.
Companies can harden their security posture against malicious packages in numerous ways, not least by prioritizing their software supply chain. It’s essential to scan all open source code repositories and libraries, to find and remediate vulnerabilities, and to identify and prevent attacks. The best way to do that is to use an automated scanning tool and accompany this with a software bill of materials (SBOM). While high-profile attacks like Log4j and the SolarWinds breach receive significant attention, they’re just a small proportion of the onslaught of attacks that applications face. The escalating threat posed by malicious package attacks increases the need to take a fresh approach to application security (AppSec). And that fresh approach requires implementing constant, automated AppSec so that organizations can stay ahead of attackers in the race to protect their software and avoid the damage that malicious packages can cause.
Manage open source risk
About the author
