CAPECattack pattern

CAPEC-695 Repo Jacking

High Official page ↗
Abstraction
Detailed
Status
Stable
Likelihood of attack
Medium
Typical severity
High
CAPEC version
3.9

Description

An adversary takes advantage of the redirect property of directly linked Version Control System (VCS) repositories to trick users into incorporating malicious code into their applications.

Extended description

Software developers may directly reference a VCS repository (i.e., via a hardcoded URL) within source code to integrate the repository as a dependency for the underlying application. If the repository owner/maintainer modifies the repository name, changes their VCS username, or transfers ownership of the repository, the VCS implements a redirect to the new repository location so that existing software referencing the repository will not break. However, if the original location of the repository is reestablished, the VCS will revert to resolving the hardcoded path. Adversaries may, therefore, re-register deleted or previously used usernames and recreate repositories with malicious code to infect applications referencing the repository. When an application then fetches the desired dependency, it will now reference the adversary's malicious repository since the hardcoded repository path is once again active. This ultimately allows the adversary to infect numerous applications, while achieving a variety of negative technical impacts.

Execution flow

1. [Explore] [Identify target] The adversary must first identify a target repository that is commonly used and whose owner/maintainer has either changed/deleted their username or transferred ownership of the repository and then deleted their account. The target should typically be a popular and widely used package, as to increase the scope of the attack. 2. [Experiment] [Recreate initial repository path] The adversary re-registers the account that was renamed/deleted by the target repository's owner/maintainer and recreates the target repository with malicious code intended to exploit an application. These steps may need to happen in reverse (i.e., recreate repository and then rename an existing account to the target account) if protections are in place to prevent repository reuse. 3. [Exploit] [Exploit victims] The adversary's malicious code is incorporated into applications that directly reference the initial repository, which further allows the adversary to conduct additional attacks.

Prerequisites

• Identification of a popular repository that may be directly referenced in numerous software applications • A repository owner/maintainer who has recently changed their username or deleted their account

Skills required

• [Low] Ability to create an account on a VCS hosting site and recreate an existing directory structure. • [Low] Ability to create malware that can exploit various software applications.

Consequences

• Integrity: Read Data, Modify Data • Access Control, Authorization: Execute Unauthorized Commands, Alter Execution Logic, Gain Privileges

Mitigations

• Leverage dedicated package managers instead of directly linking to VCS repositories. • Utilize version pinning and lock files to prevent use of maliciously modified repositories. • Implement "vendoring" (i.e., including third-party dependencies locally) and leverage automated testing techniques (e.g., static analysis) to determine if the software behaves maliciously. • Leverage automated tools, such as Checkmarx's "ChainJacking" tool, to determine susceptibility to Repo Jacking attacks.

Related

Att&ck technique · MITRE ATT&CK (1)

  • T1195.001 Compromise Software Dependencies and Development Tools sub-technique

Child of · CAPEC (1)

  • CAPEC-616 Establish Rogue Location attack pattern

Weakness · CWE (2)

  • CWE-494 Download of Code Without Integrity Check weakness
  • CWE-829 Inclusion of Functionality from Untrusted Control Sphere weakness

Referenced by CWE · attack pattern (2)

  • CWE-494 Download of Code Without Integrity Check weakness
  • CWE-829 Inclusion of Functionality from Untrusted Control Sphere weakness