107

Update (April 15): The forked repo and the user do not exist any more.

Yesterday, one of my GitHub projects was forked and there is a suspicious commit on the fork of the repo. As you can see from the commit the GitHub Actions configuration installs ngrok on the server, enables firewall access to rdp and enables rdp on the server.

Can someone explain what the potential attacker is trying to achieve and why the person behind it couldn't do the same in their own repo? Is this a new type of attack and what should I do?

Andreas Grech
  • 103
  • 2
Giorgi
  • 903
  • 2
  • 3
  • 12
  • 7
    They installed a backdoor. They *could* do it in their own repo. We can't explain their motivations without talking to them, though. What do you *want* to do? It's public code. – schroeder Apr 14 '21 at 07:49
  • 3
    Just to add, it is not a new type of attack. Threat actors are abusing the protocol for multiple malicious purposes. Abuses of the ngrok platform are tricky to detect because connections to subdomains of ngrok.com are not filtered by security solutions. – cyzczy Apr 14 '21 at 08:04
  • 4
    /me hugs the [Nix](https://nixos.org/) world, where builds are habitually disallowed from making network connections (so someone would have a lot of trouble getting the results of their mining back to their command-and-control). – Charles Duffy Apr 14 '21 at 21:45

4 Answers4

134

This isn't trying to make users install malware. This is trying to run malware on the build server. They fork the repository, install a malicious build script, create a Pull Request (PR) for the fork, and then the build will run for the PR and it will look like it's coming from your repository. When Github staff look at why their build servers are mining bitcoins, they'll see that it's a build job for your repository. (But they're probably smart enough to see it's from a malicious PR)

bradbury9
  • 350
  • 1
  • 10
user253751
  • 4,610
  • 3
  • 21
  • 17
  • 18
    So even if I don't accept the PR the build script will still run, right? – Giorgi Apr 14 '21 at 10:35
  • 4
    @Giorgi I believe so, but I don't really know how Github Actions works. – user253751 Apr 14 '21 at 10:48
  • (the reason I believe so is because I have heard other people talking about the same attack, not any hard evidence) – user253751 Apr 14 '21 at 13:50
  • 11
    This info went through some infosec news sites about two weeks ago. Here's an example: https://heimdalsecurity.com/blog/github-infrastructure-used-to-mine-cryptocurrency/ -- in light of that, we can more or less assume that the github engineers know where to look for the culprit; and that they would not take down the original repo. – orithena Apr 14 '21 at 16:47
  • 2
    @Giorgi Yes. That's the whole point: the build script is supposed to run tests so that the maintainers can determine whether or not to accept the PR. – gerrit Apr 14 '21 at 19:10
  • 33
    This is the reason why Gitlab takes the CI config (build script) from the main branch, not from the one to be merged. – Bergi Apr 14 '21 at 19:22
  • 3
    That's.... worrisome. – Clockwork Apr 14 '21 at 20:08
  • 14
    @Bergi: That wouldn't save you. I can usually arrange for the master build script to run arbitrary code anyway. – Joshua Apr 14 '21 at 20:50
  • 2
    @Joshua yeah, once a script with code from the repo runs, you usually got arbitrary code execution. However, the CI config chooses which machine to run on, using which access permissions, with some timeout, and determines which scripts should run on which events (pr, merge, commit), scripts that might be hardcoded and not use code from the repo. I admit it's rare to have such a setup, many public repos that accept pull requests from anyone would still have a problem. – Bergi Apr 14 '21 at 21:29
  • 1
    @Bergi: Partial list of languages that have arbitrary code at buildtime as a feature: C# (really the whole .NET family), lisp, C & C++ via autoconf, anything else built with make or any of its replacements. It's kind of funny how ingrained it is in lisp as it's used as a regular language feature. – Joshua Apr 14 '21 at 21:33
  • 3
    @Joshua Don't forget that the vast majority of CI configurations that run off PRs run *unit tests* as well (since that's kind of the whole point of running actions on PRs). That's by definition arbitrary code. So there's usually no need to hack the build scripts. Just add a new unit test, or modify the main code base that's getting executed by an existing test. – Konrad Rudolph Apr 15 '21 at 07:51
  • I mean, you'd have to be pretty bold to try running the mining from your own repo, right? Right?? – corsiKa Apr 16 '21 at 05:14
  • @corsiKa apparently there's a limit on how much CPU time you can use. If you use someone else's repo, it might count towards their limit instead? – user253751 Apr 19 '21 at 09:52
77

This trend caught international attention around a week ago.

The goal is to mine Bitcoin or other cryptocurrencies on the build server.

For some reports, see here, here or here. Or see Google.

This works because tests (and the whole build) are run on the pull request before it is merged. After all, how else would you know whether that change works?

Considering the media attention, there is nothing you need to do. GitHub is aware of the problem and it's their infrastructure that gets abused. They will need to counter that spam.

You should report it, so that GitHub can train a tool that automatically recognizes this kind of threat to them.

knallfrosch
  • 867
  • 5
  • 6
7

As @user253751 said on his answer, this is a build step malware attack that could potentially be used against you once a PR is opened from the fork to your repo, as GitHub might not like that these attacks are related to your repository.

There is an open issue on GitHub with a proposal to fix it by specifying which branch to allow github workflow file changes from. https://github.com/actions/runner/issues/458#issuecomment-707643141

Meanwhile, there is a workaround which is to have a custom app in the repo that runs on check_run.created webhook event to check if the last person who edited the workflow file that is being run is an admin on the repo. (https://github.com/actions/runner/issues/458#issuecomment-713620965). Sadly, no official github solution exists as of writing this answer.

WalidSabihi
  • 89
  • 3
6

The problem here is that he could deceive some user into installing your application through its link.

Think for example about those tutorials of how to install any piece of software which usually includes doing a git clone/ download of the repo as it is very important to have a check on what you are actually installing.

This is a very good tutorial about how to install Zsh: https://maxim-danilov.github.io/make-linux-terminal-great-again/

But, if you have a look at the Install Oh My Zsh section you can see the following command:

sh -c "$(curl -fsSL https://raw.githubusercontent.com/robbyrussell/oh-my-zsh/master/tools/install.sh)"

That command is basically running (through sh) everything of the script hosted in Github. Of course in this case the source is trusty but that is not always the case.

That is the reason why we should carefully review what we install always.

borcho
  • 560
  • 2
  • 15
  • 1
    as a side note, curling into sh like this is considered harmful - there are some tricks that make it so you see one script when going to the URL and another one is served if it detects it's being piped in or anything like that . I think github wouldn't be able to host this trick and maybe using curl instead of directly piping somehow protects you, but it is still worth considering. At least that was the knowledge a few years ago, maybe it got fixed since. – htmlcoderexe Apr 15 '21 at 11:11