GitHub supply chain attack cloned thousands of projects, spoofed genuine users
"No-one has the time or sanity to audit every thing every build process pulls in."
A malicious actor created malware-infested clones of thousands of projects, including Docker, Golang, Bash, Python and Kubernetes, in a GitHub supply-chain attack allowing RCE and data exfiltration.
Software engineer Stephen Lacy uncovered this attack, which he said affected thousands of repos, with around 35,000 code hits across GitHub – as others pointed out, 13,000 of these came from a single organisation:“redhat-operator-ecosystem”. Lacy reported the issue to GitHub, which has already removed all or almost all of the affected projects and orgs.
The search phrase to find infected projects or code from the GitHub supply chain attack is: “ovz1.j19544519.pr46m.vps.myjino[.]ru” (without square brackets)
The malicious code uploads the user’s entire ENV, including security and access keys, to the remote server, and then executes arbitrary code on the user’s server. At time of writing, it was not clear what that code does.
See also: Hackers breach PHP Git repository, add backdoor, troll Zerodium…
While no genuine repo or project appears to have been affected (contrary to Lacy's original tweet, which he subsequently clarified), the cloned projects used legitimate-sounding organisation names, and very close matches for the original project names, for example cloning the legitimate “scala-network/GUI-miner” to “stellitecoin/gui-miner”.
One commenter on the YCombinator forum noted some of the GitHub supply chain attack forks had several stars, some dating back around five years, suggesting they had been in active use.
What makes this type of attack harder to spot is the spoofing of genuine GitHub user accounts on commits, which is possible because GitHub only requires an email address to attribute a commit to a user. Users can sign commits with GPG, but there is no requirement to do so.
Clones of legitimate projects may also retain past commits and pull requests from genuine users, again making it hard to spot fakes.
Anyone using the official or original repos will not be affected by this GitHub supply chain attack, but – like other typo-squatting approaches – it had significant potential to catch out the unwary. This is particularly true outside GitHub, where it may be even less obvious a particular fork is not the official repo.
As Dr Owain Kenway, head of research computing at UCL, also noted, to avoid this GitHub attack users not only need to avoid “random forks” of projects, they also need to avoid packages which use said random forks in their build.
“The last of those is tricky – no-one has the time or sanity to audit every thing every complicated build process pulls in. It’s like the attacks against pypi – you have to rely on package authors to be careful in the requirements mechanism,” said Kenway.
The Stack has approached both Lacy and GitHub for comment.
GitHub supply chain attack similar to NPM attack
The attack is similar to the approach uncovered by ReversingLabs last month, where typo-squatting packages were being picked up by GitHub-owned NPM, and then stealing data from forms created with the malicious packages. ReversingLabs found more than two dozen infected packages, all duplicating popular NPM packages, stretching back to December 2021.
One malicious package, duplicating the popular “ionicons” icon pack, was downloaded 17,000 times, said the researchers: “Data exfiltrated using this package passes through a domain hxxps://ionicio.com, a play on the legitimate ionicons framework domain ionic.io that would be easy for application developers to overlook.”
The URL in the code pointed to a very close clone of the official ionicons website, making the duplication even harder to spot.
