0x00问题描述

疑惑不解，为什么刚提交的程序没跑几分钟就又又又又又被kill掉了？

查看系统资源情况，发现CPU的内存被吃的很满，GPU中也有莫名奇妙名字的CUDA程序在运行。

询问了一圈后发现该程序并不是我们自己人跑的，并且谁会使用htop作为CUDA程序的名字呢？于是我尝试kill掉这个进程，没过3分钟这个程序又自动恢复了。下意识，我发现这肯定是中了挖矿的病毒了。

最近有非常多的机器中招，然而这个病毒并不会吃太多的GPU显存资源（应该也是怕被发现），并且做的非常隐藏，所以许多同学没有注意到这个问题。

但是作为研究机构，这个程序跑在机器上就会导致测试性能出现波动，许多实验数据变得不可用，危害极大。遇到这种情况，我们绝不姑息，一定要把问题解决了，最好能揪出来始作俑者。

0x01问题查找

遇到这种情况，我们首先要排查问题所在。盯着htop命令并不能进行溯源，所以我打开了系统日志，如下所示：

sudo vim /var/log/syslog

发现最近有非常多的root命令，通过pytorch的目录下跑有一个nano.backup的文件。这个现象说明，pytorch的用户被攻陷了，并且被植入了恶意代码在/.cache的隐藏目录下（还挺鸡贼，放到了隐藏文件夹）。

首先我们能看出来，root用户是自动运行的脚本，那就意味着他是写成了定时任务在服务器中，以我们的经验，那首先需要查看一下crontab。

crontab -u root -e

下面便解释一下crontab：

简单来说，就是crontab用于执行定期的命令，这也就是为什么我们kill不掉挖矿程序的原因了。

之后我们根据crontab里面的命令进行追踪，发现该目录下确实被新建了htop目录：

里面有非常多的新文件。后面我们就针对这些文件进行逐个解析。

0x02恶意攻击脚本解读

首先我们根据crontab的内容溯源nano.backup文件：

发现是一个bash文件，第二行为检查doos.pid文件是否存在，如果存在，则把该文件中的数据读出来赋值给pid变量，之后尝试关闭掉这个pid下面的已存在的进程（4行），之后进入htop目录并在后台运行run文件（9,10行）。

之后我们根据backup中的顺序，接着追溯doos.pid的内容：

发现只有一个int的数字，应该是进程号（发现和GPU中htop任务进程号一致）；
之后我们进入/home/pytorch/.cache/htop目录查看run文件：

发现程序在后台运行了Xorg.log文件，并传入了htop参数（5行），并把当前进程的id写入doos.pid；

我们发现Xorg.log文件与htop文件是只读二进制文件，无法追溯到源码，但是我们也能根据系统的反馈猜测到其内容，后面我们进行展开。

此时我们还没有发现crontab是怎么被写入的，这些文件又是怎么被写入的？
我们ll一下htop下的目录发现：

目录下的文件不只是pytorch这个用户所有，这些可执行文件来自另一个用户。我们打开Xorg.cfg：

发现4行是是写crontab的命令，8~17行是把具体内容写到nano.backup的。也就是说，黑客只需要把这个文件夹以及run文件、Xorg.log上传到受害者机器，然后执行一下这个Xorg.cfg即可以做到循环攻击。

此外，我们发现目录下存在logs文件夹，打开发现：

打开其中的一个log：

果然，乌鸦币映入眼帘，log里放出了黑客的钱包地址，放出来矿池的ip以及设备的一些信息等。

回过头看到配置文件里有一个config.ini：

里面放入了攻击者的一些钱包等内容，那看来，前面的二进制文件：Xorg.log文件与htop文件具体内容就是读取这些配置文件（Xorg.log）然后传入挖矿cuda函数（htop）。

非常可恶了。

我使用sudo tail -f /var/log/syslog命令时刻监听系统日志，发现root每隔定期时间就会跑crobtab的任务。这也是为什么我们把进程kill掉后仍然会重启的原因。

0x03修复方案

为了解决这个病毒，我们要做几件事：

1 修改用户的密码
2 删掉/.cache/htop里的代码
3 修改crontab定时命令，把定时任务清除

2中的删除我们不用多说，用root权限rm -rf就可以

3中需要调用crontab -u root -e 删除命令或者注释

大家如果遇到类似的问题，可以查阅我写的方法解决，希望大家的服务器都安全。这些挖矿程序是比较可恶的，会影响我们正常程序的运算时间，严重的话会吃很多内存显存，导致程序崩溃。