A hacker going by the handle "Pl0xP" cloned a large number of GitHub repositories and slightly changed the cloned repository names, in a typosquatting effort to impersonate legitimate projects — thus potentially infecting any software that imported the code, software experts said today.

The widespread cloning resulted in more than 35,000 insertions of a malicious URL into different code repositories, although the exact number of affected software projects is likely much smaller, software engineer Stephen Lacy stated in an early morning Twitter post. The attack, a variant of dependency confusion, could have caused problems for developers using the fake GitHub repositories without adequate verification of the software source, he said.

If imported, the malicious code executes code on the system, according to Lacy. "This attack will send the ENTIRE ENV of the script, application, laptop (electron apps), to the attacker's server! ENVs include: Security keys; AWS access keys; Crypto keys … much more." 

"ENVs" are environment variables, used to store information that developers want to reference in their workflows.

The software engineer found the malicious functionality when he audited a software library that he considered incorporating into his own project, Lacy said.

"I discovered the exploit as I was reviewing a project I found off a Google search," he tweeted. "This is why we don't install random packages off the internet!"

Cloning — or "forking" — is not a new malicious technique, but it's a tricky one.

"Bad actors have already been known in the past for creating cloned/forked popular repositories with malicious code," says Mor Weinberg, Aqua Security software engineer. "This can become quite difficult to spot, as cloned repositories may retain code commits with usernames and email addresses of the original authors, giving off a misleading impression that newer commits were made by the original project authors as well. Open source code commits signed with GPG keys of authentic project authors are one way of verifying the authenticity of code."

"This … was akin to someone standing up a 'fake' website or sending a phishing email," adds Mark Lambert, vice president of products at ArmorCode. "This is going to catch people that are not paying attention."

An Attack or Legitimate Research?

This mass forking in GitHub may not have been a real attack. A person claiming to have knowledge of the issue positioned the widespread typosquatting as a legitimate research effort.

"This is a mere bug-bounty effort. no harm done. Report will be released," a Twitter user named "pl0x_plox_chiken_p0x" tweeted on Aug. 3.

While an ill-conceived research project could explain the attack, creating thousands of code changes for research seems irrationally risky. Moreover, the Twitter user had only registered the account in the prior three days — short account lifetimes are often a characteristic of fraudulent online personas.

The claim of the attack being part of a bug bounty "is waiting to be proven, as the activity is having the characteristics of one with a malicious intent," Jossef Harush, head of supply chain security engineering at software security firm Checkmarx, tells Dark Reading.

In any event, Michael Skelton, senior director of security operations at bug-bounty platform Bugcrowd, notes that at least the original code repositories remained unaffected.

"While it's unclear what the nature of Pl0xP's bug-bounty finding would be (as social engineering is out of scope for nearly all bug-bounty programs), it does look like they cloned a number of repositories, and made their changes in those clones only — in no cases did this change make its way into the original repositories that had been cloned," he says. "Cloning a repository is a standard action that doesn't impact the original repository unless the owner merges a change back (requested through a pull request), which wasn't done here."

Malicious Software Dependencies Abound

GitHub seemingly cleaned up the malicious code commits, and as of the afternoon on Aug. 3, a search for the embedded bad URL turned up zero results. Yet the attack is hardly the first time that open source projects have had to deal with attackers. The number of attacks against the software supply chain jumped 650% in 2021, mainly driven by dependency-confusion attacks, where the attacker uses an almost identically named version of an open source code block in hopes of developers mistyping the name of a desired library or component, or not noticing the slight difference in nomenclature. 

Seeding repositories with malicious, misnamed projects requires the attacker to do some groundwork. In July, software security firm Checkmarx revealed a way of creating fake developer accounts on GitHub, complete with an active history of code commits to increase their credibility. The technique, along with the latest attack, underscores that maintainers need to take steps to only accept signed code commits, Harush says. Developers need to "beware of pull requests and contributions having suspicious unverified commits, [and need to] review ... the content of the contributions compared to the disclaimer in the commit message and contributions adding or modifying existing dependencies to similar named dependencies as part of the contribution," he adds.

Don't Trust, Verify

To avoid their projects being poisoned, maintainers and developers should only trust those contributors that are known to them and have an extensive and verifiable commit history. They should also use the available tools — such as digital signatures and multifactor authentication — to secure their accounts, Harush says.

"As you should not trust candy from strangers — don't trust code from strangers," he says. "Users may be tricked when evaluating the candidate project and think they are legitimate, [so] they use it in their local development computers, build environments, production environments, and even build software, [until finally executing something malicious] on customers' [systems]."

In Checkmarx's July advisory on spoofing identity information and commit information in the git command-line utility, the company underscored the risks to software projects when malicious committers disguise themselves as known contributors. This "makes the project look trustworthy," the firm stated. "What makes this commit-spoofing even more alarming is the fact that the user being spoofed isn’t notified and won’t know that their name is being used."

GitHub has already added digital signatures for code commits to verify the identity of the contributor, but project maintainers should enable "vigilant mode," a feature of GitHub that displays details of the verification status of every commit and their contributor, Checkmarx stated.

At the very least, developers and project maintainers should occasionally review their commit log and ask their other maintainers to enable GPG-signed commits, Harush says. "Getting used to having a signed commit log will benefit you to pay attention to unverified contributions."

GitHub could not immediately be reached for comment.