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?

Improve this question
3
  • 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, 2021 at 7: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, 2021 at 8:04
  • 4
    /me hugs the Nix 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, 2021 at 21:45

4 Answers 4

Reset to default
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)

Improve this answer
14
  • 18
    So even if I don't accept the PR the build script will still run, right?
    – Giorgi
    Apr 14, 2021 at 10:35
  • 4
    @Giorgi I believe so, but I don't really know how Github Actions works.
    – user253751
    Apr 14, 2021 at 10:48
  • 11
    This info went through some infosec news sites about two weeks ago. Here's an example: heimdalsecurity.com/blog/… -- 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, 2021 at 16:47
  • 34
    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, 2021 at 19:22
  • 14
    @Bergi: That wouldn't save you. I can usually arrange for the master build script to run arbitrary code anyway.
    – Joshua
    Apr 14, 2021 at 20:50
78

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.

Improve this answer
3
  • 15
    You should definitely report it.
    – Jack Aidley
    Apr 15, 2021 at 7:18
  • 29
    sigh. this is why we cant have nice things
    – Zombo
    Apr 15, 2021 at 14:05
  • 2
    I have edited the answer to encourage reporting.
    – knallfrosch
    Apr 16, 2021 at 11:35
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.

Improve this answer
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.

Improve this answer
1
  • 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, 2021 at 11:11

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .