A recent article at the popular site, Ars Technica, highlighted security risks to software development projects due to malicious artifacts being distributed via software package management solutions. In the story, the authors discuss the problems with what is called "typo squatting", where a malicious threat actor creates a similar software component to a legitimate one, but uses a slightly varied name.
An example of this scenario is a software package named "fastparser" might have a malicious software package published to a public repository named "fastpraser", or any of a dozen different variants. When a developer mistakenly types the improper package name in the system, the common development environments will automatically download, install, and potentially execute malicious code on the system. Additionally, the malicious code can make it's way into production application environments, providing an adversary access to a wide range of corporate, customer, and personal data.
Threat Mitigation
The common belief is that developers and other users should simply be more careful and double check the packages and libraries being used with the development process. This approach is limited at best, and denies the fact that developers are simply human, and cannot be expected to never make a typo, or make other mistakes. As systems use unit tests, integration testing, and a wide range of other features to validate and secure against improper code, why must artifacts fallback to the process of "double check your work"?
Threat Resolution
At Lemuridae Labs, we believe that automation can provide a helping hand, by enriching the software artifact management process with additional context, and using this to augment the development process. Some of these mitigations may be accomplished at the package repository, and some within the development environment itself, however as with most things, an effective solution is multifaceted.
Variance Detection
The issue with typo squatting is that a malicious threat actor is able to create plausible alternative names without issue within these repositories. A human inspection of two similar names would be able to tell that the artifacts are very similar, however much of the process for creating and managing these artifacts is solely automated.
The first recommendation is that package names must have a minimum amount of variance from other package names to reduce the thread of simple typo incidents. This variance requirement would reduce the ability of attackers to create easy typo alternatives for common software libraries, and will protect from a range of possible improper names.
Metadata Evaluation
A second issue that is more easily identified is the relative popularity of software libraries and artifacts when retrieved by developers. In this example, if a developer is using a series of libraries, each of which has thousands or millions of installations, and one that has dozens, it may be an indication that one is a malformed artifact. In this example, the repository, or client software, could evaluate the actual use of the artifacts and highlight to users that one may not be legitimate based on the usage and install patterns.
The benefit of this alternative approach is that the system does not need additional information, and that the repository has enough information on artifact download and usage patterns to provide this additional contextual data.
A data-driven approach to highlight potential threat vectors will bring the control back to the developer, offering recommendations and cautions that may indicate an accidental malicious component.
Summary
These solutions are not a silver bullet and would exist in a broader landscape of other protections and defenses, however the simple solutions should not be discarded out of hand. These solutions can be easily implemented and incorporated into package and artifact management software. With a simple and rapid deployment, many issues may be identified, leading to a community-wide improvement in software quality and defense in depth.
References
https://arstechnica.com/security/2024/11/javascript-developers-targeted-by-hundreds-of-malicious-code-libraries/