An adversary spoofs software popularity metadata to deceive users into believing that a maliciously provided package is widely used and originates from a trusted source.
Extended Description
Many open-source software packages are hosted via third-party package managers (e.g., Node Package Manager, PyPi, Yarn, etc.) that allow for easy integration of software components into existing development environments. A package manager will typically include various metadata about the software and often include a link to the package's source code repository, to assist developers in determining the trustworthiness of the software. One common statistic used in this decision-making process is the popularity of the package. This entails checking the amount of "Stars" the package has received, which the package manager displays based on the provided source code repository URL. However, many package managers do not validate the connection between the package and source code repository being provided. Adversaries can thus spoof the popularity statistic of a malicious package by associating a popular source code repository URL with the package. This can ultimately trick developers into unintentionally incorporating the malicious package into their development environment.
Likelihood Of Attack
Medium
Typical Severity
High
Relationships
This table shows the other attack patterns and high level categories that are related to this attack pattern. These relationships are defined as ChildOf and ParentOf, and give insight to similar items that may exist at higher and lower levels of abstraction. In addition, relationships such as CanFollow, PeerOf, and CanAlsoBe are defined to show similar attack patterns that the user may want to explore.
Nature
Type
ID
Name
ChildOf
Standard Attack Pattern - A standard level attack pattern in CAPEC is focused on a specific methodology or technique used in an attack. It is often seen as a singular piece of a fully executed attack. A standard attack pattern is meant to provide sufficient details to understand the specific technique and how it attempts to accomplish a desired goal. A standard level attack pattern is a specific type of a more abstract meta level attack pattern.
Identify target: The adversary must first identify a target package whose popularity statistics will be leveraged. This will be a popular and widely used package, as to increase the perceived pedigree of the malicious package.
Experiment
Spoof package popularity: The adversary provides their malicious package to a package manager and uses the source code repository URL identified in Step 1 to spoof the popularity of the package. This malicious package may also closely resemble the legitimate package whose statistics are being utilized.
Exploit
Exploit victims: The adversary infiltrates development environments with the goal of conducting additional attacks.
Techniques
Active: The adversary attempts to trick victims into downloading the malicious package by means such as phishing and social engineering.
Passive: The adversary waits for victims to download and leverage the malicious package.
Prerequisites
Identification of a popular open-source package whose popularity metadata is to be used for the malicious package.
Skills Required
[Level: Low]
Ability to provide a package to a package manager and associate a popular package's source code repository URL.
Consequences
This table specifies different individual consequences associated with the attack pattern. The Scope identifies the security property that is violated, while the Impact describes the negative technical impact that arises if an adversary succeeds in their attack. The Likelihood provides information about how likely the specific consequence is expected to be seen relative to the other consequences in the list. For example, there may be high likelihood that a pattern will be used to achieve a certain impact, but a low likelihood that it will be exploited to achieve a different impact.
Scope
Impact
Likelihood
Integrity
Modify Data
Accountability
Hide Activities
Access Control
Authorization
Execute Unauthorized Commands
Alter Execution Logic
Gain Privileges
Mitigations
Before downloading open-source packages, perform precursory metadata checks to determine the author(s), frequency of updates, when the software was last updated, and if the software is widely leveraged.
Look for conflicting or non-unique repository references to determine if multiple packages share the same repository reference.
Reference vulnerability databases to determine if the software contains known vulnerabilities.
Only download open-source packages from reputable package managers.
After downloading open-source packages, ensure integrity values have not changed.
Before executing or incorporating the package, leverage automated testing techniques (e.g., static and dynamic analysis) to determine if the software behaves maliciously.
Example Instances
In April 2022, Checkmarx reported that packages hosted on NPM, PyPi, and Yarn do not properly validate that the provided GitHub repository URL actually pertains to the package being provided. Combined with additional attacks such as TypoSquatting, this allows adversaries to spoof popularity metadata by associating popular GitHub repository URLs with the malicious package. This can further lead to developers unintentionally including the malicious package within their development environments [REF-721].
Related Weaknesses
A Related Weakness relationship associates a weakness with this attack pattern. Each association implies a weakness that must exist for a given attack to be successful. If multiple weaknesses are associated with the attack pattern, then any of the weaknesses (but not necessarily all) may be present for the attack to be successful. Each related weakness is identified by a CWE identifier.
CAPEC mappings to ATT&CK techniques leverage an inheritance model to streamline and minimize direct CAPEC/ATT&CK mappings. Inheritance of a mapping is indicated by text stating that the parent CAPEC has relevant ATT&CK mappings. Note that the ATT&CK Enterprise Framework does not use an inheritance model as part of the mapping to CAPEC.
Relevant to the ATT&CK taxonomy mapping (see
parent
)