GitHub is Investigating Crypto-mining Campaign Abusing Its Server Infrastructure (therecord.media) 27
An anonymous Slashdot reader shared this report from The Record:
Code-hosting service GitHub is actively investigating a series of attacks against its cloud infrastructure that allowed cybercriminals to implant and abuse the company's servers for illicit crypto-mining operations, a spokesperson told The Record today.
The attacks have been going on since the fall of 2020 and have abused a GitHub feature called GitHub Actions, which allows users to automatically execute tasks and workflows once a certain event happens inside one of their GitHub repositories. In a phone call today, Dutch security engineer Justin Perdok told The Record that at least one threat actor is targeting GitHub repositories where GitHub Actions might be enabled. The attack involves forking a legitimate repository, adding malicious GitHub Actions to the original code, and then filing a Pull Request with the original repository in order to merge the code back into the original.
But the attack doesn't rely on the original project owner approving the malicious Pull Request. Just filing the Pull Request is enough for the attack, Perdok said. The Dutch security engineer told us attackers specifically target GitHub project owners that have automated workflows that test incoming pull requests via automated jobs. Once one of these malicious Pull Requests is filed, GitHub's systems will read the attacker's code and spin up a virtual machine that downloads and runs cryptocurrency-mining software on GitHub's infrastructure.
Perdok, who's had projects abused this way, said he's seen attackers spin up to 100 crypto-miners via one attack alone, creating huge computational loads for GitHub's infrastructure. The attackers appear to be happening at random and at scale. Perdok said he identified at least one account creating hundreds of Pull Requests containing malicious code.
The attacks have been going on since the fall of 2020 and have abused a GitHub feature called GitHub Actions, which allows users to automatically execute tasks and workflows once a certain event happens inside one of their GitHub repositories. In a phone call today, Dutch security engineer Justin Perdok told The Record that at least one threat actor is targeting GitHub repositories where GitHub Actions might be enabled. The attack involves forking a legitimate repository, adding malicious GitHub Actions to the original code, and then filing a Pull Request with the original repository in order to merge the code back into the original.
But the attack doesn't rely on the original project owner approving the malicious Pull Request. Just filing the Pull Request is enough for the attack, Perdok said. The Dutch security engineer told us attackers specifically target GitHub project owners that have automated workflows that test incoming pull requests via automated jobs. Once one of these malicious Pull Requests is filed, GitHub's systems will read the attacker's code and spin up a virtual machine that downloads and runs cryptocurrency-mining software on GitHub's infrastructure.
Perdok, who's had projects abused this way, said he's seen attackers spin up to 100 crypto-miners via one attack alone, creating huge computational loads for GitHub's infrastructure. The attackers appear to be happening at random and at scale. Perdok said he identified at least one account creating hundreds of Pull Requests containing malicious code.
Greed (Score:4, Insightful)
Re: (Score:3, Funny)
Yes, the planet got destroyed. But for a beautiful moment in time we created a lot of value for shareholders. [i.redd.it]
Asking for trouble? (Score:5, Insightful)
Re: (Score:2)
Re: (Score:2)
Just as big of a vulnerability as cloud-hosted computing in general.
It's actually the main idea to be able to run whatever, not just some pre-approved piece of software :).
Re: (Score:2)
The difference is that if you run things in "cloud computing" you pay for the usage - if it's a big whopper of a VM, you pay more than if it's a small one. And you pay for the time it exists.
With a level of service abstraction, now GitHub is paying that cost for what they intended to be a short-lived unobtrusive process. Except that those processes are not defined by them, and aren't very bounded.
Oops.
Re: (Score:2)
Except that those processes are not defined by them, and aren't very bounded.
Yes... It seems like a mistake that Github has designed systems that automatically kick off an unbounded process on behalf of an unknown account.
Perhaps for starters they would consider changing their "pull request" system slightly to require a project take some action on a pull request before actions run such that it becomes possible for the request to "launch a VM".
Alternatively.. make developers put in a one-time deposit li
Re: (Score:3)
I've been in the security field for a few years now after being on the development side for a while.
A comparable example that I've run into quite a lot is arbitrary file uploads. There's just a lot of use cases out there where it is a business requirement that a user be able to upload a file.
Of course any file can be renamed, have malicious code in it, not be it's stated type.. That doesn't mean you don't do those checks.
1. Yes, you only accept type of files you expect
2. Yes, you have to have a virus/malwar
Re: (Score:2)
I would alter it to "allowing users to execute arbitrary code without usage-based pricing" seems like a poor business decision.
Hard to think that someone couldn't have forseen the idea of implementing a "code test" which resembles a crypto miner in a branch of a repo that uses GitHub Actions, and then submit a PR in order to let the CI pipeline run it.
wait what? (Score:5, Insightful)
Wait, you let people upload arbitrary code to your servers and then execute it? and now you wonder why people uploaded malicious code?
Re:wait what? (Score:5, Insightful)
That kind of attitude is why we can't have nice things.
First of all, every cloud platform allows you to spin up VMs to upload your arbitrary code and execute it on their server. I mean that's the definition of cloud VMs. But, you normally pay for it.
Github is nice in that it gives you 2000 minutes/month of "actions" runtimes (which is exactly that, spinning up a VM to run a workflow, which is normally intended to do things like running your repo test suite against the PR branch) even for free accounts for public repos. That's been great for open source development, but, there is a way to abuse github's free resources - make a PR that adds a cryptomining workflow.
Hopefully Github willl figure out a way to stop the abuse without blocking this very useful service they are providing.
Re: (Score:1)
That free VM time is nice I guess, but way beyond what you can expect from a free repository. I think it is entirely reasonable if people have to set up their own test environment.
Re: (Score:1)
So you don't like useful tooling. Especially for free. You'd prefer an open source project for example to pay for cloud VM servers to set up a CI pipeline instead of using a free github tool that's quite easy to set up?
Probably never finishes the task (Score:2)
Re: (Score:2)
They are probably running then as part of a pool. So they don't need to mine a whole coin, just complete a share. A low difficultly share can be done in seconds/minutes.
Re: (Score:2)
You can scrape more by infecting sites and/or targeting end-user PCs while leaving practically nothing traceable to the hacker. Do not see why they are doing it.
Re: (Score:3)
Re: (Score:2)
infecting sites and end user PCs is illegal, and the idea that this is an exclusive 'or' is incorrect.
Why wouldn't the person doing this do both? And, they can do hundreds of GitHub repos at once - write a bot to find a public repo that has GitHub Actions enabled, clone it, branch, inject your "CI test" that is actually a miner, request a PR and watch it spin up the miner and start hashing. Then repeat with other repos. While still owning end-user PCs and infecting sites.
Re: (Score:3)
If they are smart about it, they start the job, import initial state, work at almost the longest permitted time, then produce an end result ("build") and then spin another job again. Could even upload intermediate state somewhere for safekeeping.
Given how inefficient it is to use CPU's to begin with to mine coins, this is really abusive. Massive waste of resources for a small benefit.
Re: (Score:2)
When the resources are free, there is a class of person that doesn't care about efficiency. They're still getting crypto that they didn't pay for the hardware or electricity to "mine".
Oh (Score:1)
Doesn't this have an easy fix? (Score:2)
Can't you not run the CI tests until a project admin approves a change? I'm not talking about a final approval, but just an initial "this is worth spending the cpu resources to test" approval. For large projects, this might be problematic, but could be filtered to require that first-time contributors require approval before the CI stuff runs automatically.
"Off" should be the default (Score:1)
Whenever GitHub releases new features and clutters the UI with yet more tabs of things I don't/won't use, I have to go through all of my repos and turn that feature OFF. I sometimes forget a repo.
If you don't need/use Actions, turn them off. But new features should be turned off by default.