Dependency repository hijacking, also known as “RepoJacking,” may be able to spread supply chain attacks that have a large impact on users through millions of GitHub repositories.

Table of Contents
“Nautilus,” AquaSec’s security team, found that about 2.95 percent of 1.25 million GitHub repositories were susceptible to RepoJacking after analyzing them.
The researchers estimate that the issue affects approximately 9 million projects by extrapolating this percentage to the entire repository base of more than 300 million on GitHub.

What is RepoJacking
On GitHub, organizations frequently change their user names and repository names as a result of mergers, acquisitions, and brand name changes.
When this occurs, a redirection is created to prevent projects that use code from repositories whose names have changed from breaking dependencies; However, the redirection ceases to be valid if the previous name is registered.
An attack called “RepoJacking” occurs when a malicious actor registers a username and creates a repository that was previously used by a company but has since changed its name.
Any project or code that depends on the attacked project’s dependencies will have to fetch dependencies and code from the attacker-controlled repository, which could contain malware.

GitHub has implemented some defenses against RepoJacking attacks because it is aware of this possibility. AquaSec, on the other hand, says that the solutions so far have been insufficient and simple to bypass.
Projects that use a dependency from a less well-known, vulnerable repository that is not protected are also affected by the supply chain compromise because GitHub only protects highly popular projects.
Additionally, GitHub safeguards storehouses with more than 100 clones the prior week evolving name, demonstrating malignant arrangements. Projects that gained popularity after changing their name or changing ownership are not covered by this protection.
Exploitation potential
AquaSec found exploitable cases in repos managed by Google and Lyft, highlighting the severity of the issue. The company also looked for vulnerable repos managed by other well-known companies.
In the case of Google, a readme file with instructions for building the popular project “Mathsteps” pointed to a GitHub repository owned by Socratic, a company that Google acquired and absorbed in 2018 but is no longer in business.
Users who followed the readme instructions may have downloaded malicious code from the rogue repository because an attacker can clone that repository to break the redirection.
Additionally, the attacker’s code could execute arbitrary code on users’ devices because the instructions contained an “npm install” command for the dependency.

AquaSec discovered an installation script on Lyft’s repository that fetches a ZIP archive from another repository, making it susceptible to RepoJacking, making the attack more automated.
An attacker could inject their code into the “install.sh” script executed by Lyft by registering a new username and repository under the appropriate names (“YesGraph” and “Dominus” in this instance).

Conclusion
Sadly, the risk of RepoJacking is widespread, difficult to reduce, and can have severe consequences for users and organizations.
The amount of resources retrieved from external repositories by project managers should be kept as low as possible.
In addition, in order to safeguard themselves and their users from dependency hijacking attacks, owners ought to consider maintaining control over repositories of previously owned brands or acquired entities.