记一次自建gitlab被黑事件

Posted by boydfd on 2022-07-27 19:30:00 +0800

Recently by the same author:


喝水方案升级之路

TLDR

  1. 如果使用的gitlab是下面的版本范围,赶紧升级:
     11.9 <= GitLab(CE/EE)< 13.8.8
     13.9 <= GitLab(CE/EE)< 13.9.6
     13.10 <= GitLab(CE/EE)< 13.10.3
    
  2. 如果密码设置过于简单,赶紧改,这个文件是我在被黑的容器里一个脚本中发现的:pass
  3. 运行容器的时候最好不要直接用root用户,单独使用一个权限更低的用户
  4. 开发文件上传,或者图片上传类型的功能时,记得做检查。

背景

7月初的时候发现自建的gitlab访问速度很慢,页面打开需要等1分钟才能打开,当时没有注意啥原因,以为是k8s集群运行太久,有啥内存泄漏之类的,就重启了k8s集群。结果也”如我所料”,重启确实能解决90%的问题。

发现问题

直到今天,我登录我的服务器的时候,发现多了一个很恐怖的消息:

there were xxx failed login attempts since the last successful login. 

我一寻思,这不对啊,我的服务器是在我的局域网里啊,唯一暴露出去的就是用ngrok穿透了一个端口,还是web端口,根本就没法ssh啊。是谁能ssh来尝试登录我的服务器呢?

一开始我也不知道,所以只能先收集一些信息了。

信息收集

ssh是有日志的,通过检查/var/log/secure,发现了一点蛛丝马迹:

Jul 26 05:10:17 server sshd[38707]: Disconnected from invalid user hd 192.168.121.xxx port 49734 [preauth]
Jul 26 05:10:17 server sshd[38699]: Received disconnect from 192.168.121.xxx port 41752:11: Normal Shutdown, Thank you for playing [preauth]

192.168.121是vagrant起虚机默认的网段

我一共起了三台虚机,依次检查了一番,发现确实有一台的地址就是192.168.121.xxx。难道我的一台虚机被攻破了?恐怖啊,赶紧先看看~/.ssh/authorized_keys里有没有可疑的东西,发现并没有,继续看/var/log/secure,果然也有类似的信息:

Jul 25 21:09:43 slave2 sshd[27355]: Received disconnect from 10.32.0.9 port 57550:11: Normal Shutdown, Thank you for playing [preauth]
Jul 25 21:09:43 slave2 sshd[28113]: Received disconnect from 10.32.0.9 port 40800:11: Normal Shutdown, Thank you for playing [preauth]

通过网段,很轻易就定位出了这是某个容器的地址,再搜索了一遍pod,发现是gitlab-unicorn的pod地址,这个pod一共有两个容器,全部登录进去检查一下,一查吓一跳。 其中一叫workhorse的容器里面有个叫ld-linux-x86-64的进程,cpu占用达到1000%,我的天,难道这是有人在用我的服务器挖矿?

没想到还真是,通过pid,使用ps aux | grep pid,找到了启动命令的位置。

在容器的/var/tmp/底下有两个隐藏目录:.cache.md。经过检查里面的文件发现:

  • .cache是用来挖矿的,里面有几个比较明显的文件夹:
     -rwxr-xr-x. 1 git git  15K Mar 10  2015 h32
     -rwxr-xr-x. 1 git git 819K Feb 20  2016 h64
     -rwxr-xr-x. 1 git git   24 Oct  4  2017 x
     -rwxr-xr-x. 1 git git 2.3K Apr 22  2018 c
     drwxr-xr-x. 2 git git 4.0K Apr  1  2019 stak3
     -rwxr-xr-x. 1 git git  114 Apr 17  2020 z
     drwxr-xr-x. 2 git git 4.0K Sep 12  2020 stak
     -rwxr-xr-x. 1 git git  379 Nov  4  2020 a
     -rwxr-xr-x. 1 git git  211 Jul 21 18:05 bash
     -rwxr-xr-x. 1 git git  201 Jul 21 18:05 bash3
     -rwxr-xr-x. 1 git git  501 Jul 21 18:06 run
     -rw-r--r--. 1 git git   16 Jul 26 19:33 dir.dir
     -rw-r--r--. 1 git git   90 Jul 26 19:33 cron.d
     -rwxr-xr-x. 1 git git  194 Jul 26 19:33 upd
     -rw-r--r--. 1 git git    6 Jul 26 19:33 bash.pid
    

    stak里面放着xmrig的可执行程序,搜了一下正是挖矿程序https://github.com/xmrig/xmrig

  • .md是用来扫描局域网内地址的,扫描的策略很简单,就是分网段暴力破解。我也进去看了一下里面扫描用的账号密码,已经贴在了文章的最开始,大家有兴趣的可以自行去检查一下自己的服务器密码是不是设置得太简单了。

整理思路

现在大概可以确定的是只有这个容器被黑了,因为:

  1. 我的服务里面最近还在出现ssh登录失败的信息,说明服务器是没有被攻破的
  2. 虚拟机也存在ssh登录失败的信息,说明虚拟机也还健在
  3. 只有一台虚拟机受影响,另外两台的虚拟机cpu、memory使用正常。

肯定是因为gitlab导致我被黑了,目前看到受影响的也只有那一个容器。

那自然是要去网上搜索一下,确实找到了相应的问题:https://developer.aliyun.com/article/824680,具体的我也没细看,反正就是利用上传图像文件来进行远程命令执行,所以大家平时在处理上传图片的时候,一定做检查哈。

回想起来还是有点后怕的,幸好我用容器起的gitlab,并且没有开发什么特权,这样受影响的只有单个容器。

解决方法:

  1. 升级gitlab
  2. 把k8s的资源使用监控起来,之前配置了一次k8s exporter,但是在grafana上面看到的信息有些缺失,可能是版本或者配置有问题,出了这档子事之后,看来资源监控还是不能缺呀,当然还需要有告警机制。

疑问

我拿到了挖矿服务器的地址,是不是有啥办法可以吹起反攻的号角,也不求别的,就是想搞垮他一个服务器,让他换个服务器折腾折腾,有没有大神有思路。