An apparent long-term campaign to fork and clone GitHub code repositories and add malicious code to the new versions has been detected after it picked up speed over the past month, but the hacker behind it has piped up on Twitter to claim that it was an elaborate attempt to claim a GitHub bug bounty.
Security researchers have found over 35,000 code repositories with malicious forks or clones leading back to a single source; most of the activity appears to be recent, but there are instances linked to this particular actor that date back as far as 2015.
Tainted Clone Code Repositories Add Malware That Steals Environment Variables
The story begins with software developer Stephen Lacy discovering thousands of GitHub code repositories containing malicious code, all tied together by a shared malicious URL deployed within them. These malicious code repositories are all forks or clones of legitimate existing projects; Lacy notes that none of the original projects were compromised, malicious code was confined to these “attack branches” of each project.
Lacy took to Twitter to document what appeared to be a widespread attack. Searching for the malicious URL used in these code repositories turned up a little over 35,000 results, with about 13,000 of these coming from a repository called “redhat-operator-ecosystem” (since removed by GitHub). Lacy said that most of these appeared within the prior 20 days, but some malicious commits could be found that dated as far back as 2015.
The malware in the tainted code repositories is designed to steal environment variables, stored elements that serve as authentication for various online services. Some examples are crypto keys, API keys and Amazon AWS credentials. While it does this, the malicious code also inserts a backdoor that allows the attacker to execute arbitrary commands remotely by opening a shell on the target system.
Mark Lambert, Vice President of Products at ArmorCode, feels that the attack is not a reflection of any serious weakness in GitHub, but it does serve as a reminder that vigilance is necessary on the platform: “The key take away for me is; #1 GitHub is secure, #2 pay attention to which public repos you use.”
Story takes a turn as hacker claims credit for malicious code, says it was a bug bounty demonstration
The malicious code initially appeared to be a clear attempt to ensnare GitHub users and steal valuable credentials. Then a Twitter user going by the handle “Pl0xP” stepped forward to take credit for the spun-off code repositories, entering Lacy’s tweet thread to claim that it was all part of a bug bounty demonstration for GitHub.
The hacker claimed that they were demonstrating a “typosquatting” vulnerability by way of the fake code repositories, and said that they were preparing a report. Apparently the demonstration was not so much about ensnaring individual users with the programming equivalent of a cloned phishing page, but the possibility of an original project merging with the clone and re-incorporating it complete with the malicious code (which is not known to have happened before GitHub cleaned up all the instances of the attack).
Twitter users immediately questioned what the real intentions were, given the scope of what the malicious code was able to do. The hacker claimed that they contacted impacted projects “responsibly” and could demonstrate that they owned the server that the environment variables were being sent to if asked. That claim did not curb concerns about how much valuable data was being exfiltrated to an unknown party, along with raising further questions about how (or why) the attacker was contacting some 35,000 impacted organizations.
A “responsible” bug bounty disclosure is usually handled in private and without demonstrating to the general public how to perform the attack, let alone actually stealing random sensitive information from users and asking them to trust that it is not being misused (not to mention going as far as backdooring their systems with web shells). Thus there is ample reason to believe that this was an intentional attack with credential theft as the primary goal. The attacker also created their Twitter account just this month and has no posting history other than claiming credit for the incident. This could be a case of an unrelated party attempting to claim credit, or the legitimate hacker making an ill-advised pivot to claiming a bug bounty after their (rather clumsy) attack was detected and publicly exposed.
Attack on code repositories still relatively easy to carry out
While GitHub appears to have fully cleaned up the issue at this point, Travis Biehn (Principal Consultant at Synopsys Software Integrity Group) noted that this attack type is still relatively easy to carry out and wondered what the results would be if someone was taken in by it: “Despite @pl0xp’s assertions that the widespread malicious commits and fake repositories were part of an elaborate bug bounty, this raises questions about what an attacker carrying out an org cloning attack could potentially do with the repositories. Would that be to wait for someone to stumble onto their malicious copy, coerce folks with malicious stack overflow comments, or perhaps bury malicious dependencies in otherwise benign commits? This shines yet another light on a problem that nobody has solid and standard solutions for. A couple commentators suggest that ‘commit signing’ would be an effective control for developers to incorporate. Unfortunately, this control is ineffective if nobody enforces it, and I doubt that anyone can enforce it (like DNSSEC can’t be enforced) if not everyone does it.”
In the wake of the attack, some security experts are advising the addition of GPG-signed commits to their logs to more quickly and readily identify unverified contributions. GitHub includes “vigilant mode” as an option, in which project maintainers can keep on top of the verification status of every commit and its contributor. But some point out (as Biehn has) that code repositories included in this attack had GPG signing as a requirement, and it failed to stop the malicious clones from being created and existing for at least some days.
