GitHub blighted by “researcher” who created thousands of malicious projects

Just over a year ago, we wrote about a “cybersecurity researcher” who posted almost 4000 pointlessly poisoned Python packages to the popular repository PyPI.

This person went by the curious nickname of Remind Supply Chain Risks, and the packages had project names that were generally similar to well-known projects, presumably in the hope that some of them would get installed by mistake, thanks to users using slightly incorrect search terms or making minor typing mistakes when typing in PyPI URLs.

These pointless packages weren’t overtly malicious, but they did call home to a server hosted in Japan, presumably so that the perpetrator could collect statistics on this “experiment” and write it up while pretending it counted as science.

A month after that, we wrote about a PhD student (who should have known better) and their supervisor (who is apparently an Assistant Professor of Computer Science at a US university, and very definitely should have known better) who went out of their way to introduce numerous apparently legitimate but not-strictly-needed patches into the Linux kernel.

They called these patches hypocrite commits, and the idea was to show that two peculiar patches submitted at different times could, in theory, be combined later on to introduce a security hole, effectively each contributing a sort of “half-vulnerability” that wouldn’t be spotted as a bug on its own.

As you can imagine, the Linux kernel team did not take kindly to being experimented on in this way without permission, not least because they were faced with cleaning up the mess:

Please stop submitting known-invalid patches. Your professor is playing around with the review process in order to achieve a paper in some strange and bizarre way. This is not ok, it is wasting our time, and we will have to report this, AGAIN, to your university…

GitHub splattered with hostile code

Today, open source enthusiast Steve Lacy reported something similar, but worse (and much more extensive) than either of the aforementioned examples of bogoscience / pseudoresearch.

A GitHub source code search that Lacy carried out in good faith led him to a legitimate-looking project…

…that turned out to be not at all what it seemed, being a cloned copy of an unxeceptionable package that was identical except for a few sneakily added lines that converted the code into outright malware.

As Lacy explained, “thousands of fake infected projects [were] on GitHub, impersonating real projects. All of these were created in the last [three weeks or so]”.

As you can see, Lacy also noted that the organisations allegedly behind these fake projects were “clones designed to have legitimate sounding names”, such that “legitimate user accounts [were] (probably) not compromised”, but where “the attacker amended the last commit on [the cloned repositories] with infected code”:

Since the commit used a real gh user’s email, the result is thousands of fake infected projects are on gh impersonating real projects
All of these were created in the last ~20ish days

— Stephen Lacy (@stephenlacy) August 3, 2022

Malware infection included

According to Lacy and source code testing company Checkmarx, who grabbed some of the infected projects and wrote them up before they were purged from GitHub by Microsoft, the malware implants included code to carry out tasks such as:

• Performing an HTTP POST to exfiltrate the current server’s process environment. On both Unix and Windows, the environment is a memory-based key-value database of useful information such as hostname, username and system directory. The environment often includes run-time secrets such as temporary authentication tokens that are only ever kept in memory so that they never get written to disk by mistake. (The infamous Log4Shell bug was widely abused to steal data such as access tokens for Amazon Web Services by exfiltrating environment variables.)
• Running arbitrary shell commands in the HTTP reply sent to the above POST request. This essentially gives the attacker complete remote control of any server on which the infected project is installed and used. The attacker’s commands run with the same access privileges as the now-infected program incorporating the poisoned project.

Fortunately, as we mentioned above, Microsoft acted quickly to search and delete as many of these bogus projects as possible, a reaction about which Lacy tweeted:

@github seems to have cleaned up most if not all quite quickly.
Excellent response from them!

— Stephen Lacy (@stephenlacy) August 3, 2022

The mystery deepens

Following the outing (and the ousting) of these malware projects, the owner of a brand new Twitter account under the bizarre name pl0x_plox_chiken_p0x popped up to claim:

this is a mere bugbounty effort. no harm done. report will be released.

Pull the other one, Chiken P0x!

Just calling home to track your victims like Remind Supply Chain Risks did last year is bad enough.

Enumerating your victims without consent doesn’t constitute research – the best you could call it is probably a misguidedly creepy privacy violation.

But knowingly calling home to steal private data, perhaps including live access tokens, is unauthorised access, which is a surprisingly serious cybercrime in many jurisdictions.

And knowingly installing a backdoor Trojan allowing you to implant and execute code without permission is at least unauthorised modification, which sits alongside the crime of unauthorised access in many legal systems, and typically tacks on a few extra years to the maximum prison sentence that could be imposed if you get busted.

What to do?

This sort of thing isn’t “research” by any stretch of the imagination, and it’s hard to imagine any geniune cybersecurity researcher, any cybercrime investigator, any jury, or any criminal court magistrate buying that suggestion.

So, if you’ve ever been tempted to do anything like this under the misapprehension that you are helping the community…

…please DON’T.

In particular:

• Don’t pollute the open-source software ecosystem with your own self-serving cyber­sewage, just to “prove” a point. Even if all you do is include code that prints some sort of smug warning or anonymously keeps track of the people you caught out, you’re still making wasteful work for those in the community who have to tidy up after you.
• Don’t casually distribute malware and then try to justify it as cybersecurity “research”. If you openly leech other people’s trustworthy code and reupload it as if it were a legitimate project after deliberately infecting it with data stealing malware and remote code execution backdoors, don’t expect anyone to buy your excuses.
• Don’t expect sympathy if you do either of the above. The point you pretend you’re trying to make has been made many times before. The open-source community didn’t thank the perpetrators last time, and it won’t thank you now.

Not that we feel strongly about it.