Log in
An adversary spoofs metadata pertaining to a Version Control System (VCS) (e.g., Git) repository's commits to deceive users into believing that the maliciously provided software is frequently maintained and originates from a trusted source.
Last updated
Version Control Systems are widely used by developers to host, track, and manage source code files in an easy and synchronous manner. These systems are often leveraged to host open-source software that other developers can incorporate into their own applications or use as standalone applications. To prevent downloading vulnerable and/or malicious code, developers will often check the metadata of VCS repository commits to determine the repository's overall pedigree. This may include a variety of information, such as the following: Owner of the repository Author(s) of commits Frequency of commits Date/Time of commits Repository activity graphs These precursory checks can assist developers in determining whether a trusted individual/organization is providing the source code, how often the code is updated, and the relative popularity of the software. However, an adversary can spoof this metadata to make a repository containing malicious code appear as originating from a trusted source, being frequently maintained, and being commonly used by other developers. Without performing additional security activities, unassuming developers may be duped by this spoofed metadata and include the malicious code within their systems/applications. The adversary is then ultimately able to achieve numerous negative technical impacts, while the victim remains unaware of any malicious activity.
The phases an attacker typically follows to carry out this attack.
[Identify target] The adversary must first identify a target repository for them to spoof. Typically, this will be a popular and widely used repository, as to increase the amount of victims a successful attack will exploit.
[Create malicious repository] The adversary must create a malicious repository that imitates the legitimate repository being spoofed. This may include creating a username that closely matches the legitimate repository owner; creating a repository name that closely matches the legitimate repository name; uploading the legitimate source code; and more.
[Spoof commit metadata] Once the malicious repository has been created, the adversary must then spoof the commit metadata to make the repository appear to be frequently maintained and originating from trusted sources.
[Exploit victims] The adversary infiltrates software and/or system environments with the goal of conducting additional attacks.
What a successful CAPEC-692 attack can achieve.
Modify Data
Affects: Integrity
Hide Activities
Affects: Accountability
Execute Unauthorized Commands, Alter Execution Logic, Gain Privileges
Affects: Access Control, Authorization
Defenses that reduce the risk of CAPEC-692.
In July 2022, Checkmarx reported that GitHub commit metadata could be spoofed if unsigned commits were leveraged by the repository. Adversaries were able to spoof commit contributors, as well as the date/time of the commit. This resulted in commits appearing to originate from trusted developers and a GitHub activity graph that duped users into believing that the repository had been maintained for a significant period of time. The lack of commit metadata validation ultimately allowed adversaries to propagate malware to unsuspecting victims [REF-719] [REF-720].
Common questions about CAPEC-692.
An adversary spoofs metadata pertaining to a Version Control System (VCS) (e.g., Git) repository's commits to deceive users into believing that the maliciously provided software is frequently maintained and originates from a trusted source.
It typically unfolds over 4 phases. It begins with: [Identify target] The adversary must first identify a target repository for them to spoof. Typically, this will be a popular and widely used repository, as to increase the amount of victims a successful attack will exploit.
Before downloading open-source software, 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.
CAPEC-692 exploits 1 CWE weakness, including CWE-494 (Download of Code Without Integrity Check).
MITRE rates CAPEC-692 as High severity with medium likelihood of attack.
Attack-pattern data is sourced from the MITRE CAPEC catalog (v3.9). Weakness associations link to the corresponding CWE entries on RadicalNotion.AI.
Track the CVEs and weaknesses attackers exploit with this technique, with AI-written analysis and remediation guidance.