0x00 癥狀

昨天(6-17)我發(fā)現(xiàn)服務(wù)器上的PostgreSQL數(shù)據(jù)庫(kù)連接性能急劇下降,很多服務(wù)都報(bào)數(shù)據(jù)庫(kù)連接錯(cuò)誤.?

去查看容器的日志呢,我看到了一些詭異的東西

你說一個(gè)好端端的數(shù)據(jù)庫(kù)怎么會(huì)跑這些命令呢?

此時(shí)我已經(jīng)覺得有可能是被入侵了.

再查看容器內(nèi)的進(jìn)程,發(fā)現(xiàn)一些更加奇怪的東西

很有病毒那味了.

在主機(jī)上,使用 htop 能看到以下內(nèi)容

嘖嘖嘖,怕不是挖礦哦

此時(shí)總體 CPU 占用率達(dá)到了50%

本來我準(zhǔn)備重建容器的,但是我發(fā)現(xiàn)刪不掉. 原因是有一個(gè)隱藏文件不可以刪除

好,那就來會(huì)一會(huì)這個(gè)隱藏文件.

0x01 分析

打開這個(gè)腳本文件發(fā)現(xiàn),老Base64了

完整的

那還用說? 解碼走起

很明顯就是一段腳本

變量名像混淆了一樣,不過不算復(fù)雜,替換幾次就好了

下面是已經(jīng)整理分析過的樣子

那就一塊一塊分析把

首先是最開始的幾個(gè)變量,這倒沒啥好說的,字面意思

然后是 sockz() 函數(shù)

不得不說為了防止被防火墻發(fā)現(xiàn)這個(gè)做的是真的牛批.

使用 DoH 進(jìn)行查詢,保證 DNS 流量是加密的,這樣子就不會(huì)被傳統(tǒng)監(jiān)測(cè) 53 端口UDP流量的方式所偵測(cè)了.

查詢的域名是用來獲取 Tor 代理的網(wǎng)站.

接下來是 fexe() 函數(shù)

這個(gè)我沒看出他啥意思,感覺就是執(zhí)行和刪除文件(可能是執(zhí)行一次病毒來防止被停止?)

往下是 u() 函數(shù)(已整理)

碼掉的地址是下載可執(zhí)行文件的 Tor 網(wǎng)址,不過我進(jìn)去看的時(shí)候已經(jīng)是 404 了.

我把里面晦澀難懂的變量都替換了,兩個(gè)取變量的地方我也寫了一個(gè)例子.

其中 Tor 代理就是之前 sockz() 函數(shù)所獲取到的那個(gè)

傳入的參數(shù)在文件最下面有

而且這個(gè)函數(shù)還很"貼心"的提供了在不傳入?yún)?shù)的時(shí)候也能下載的辦法.夠狠的.

事后刪掉可執(zhí)行文件,還不留痕跡.

最后是最終執(zhí)行部分

我是很不懂這個(gè)病毒干嘛要判斷是否有桌面環(huán)境呢? 難道是只感染服務(wù)器不感染Linux工作站嗎?

(那給服務(wù)器裝個(gè)GNOME桌面不就偷笑了?)

這部分就是從一堆備選站點(diǎn)里挑選一個(gè)出來,傳參給函數(shù) u() 去下載真正的可執(zhí)行文件.

0x02 事后

我用 lsattr 查詢了這個(gè)隱藏文件的附加屬性,發(fā)現(xiàn)被禁止移動(dòng)或更改(i)

chattr -i 教他做人,然后刪除容器并重建.

也許是服務(wù)器性能太強(qiáng)了吧,要不是一批應(yīng)用程序出現(xiàn)崩潰我根本不會(huì)注意到數(shù)據(jù)庫(kù)已經(jīng)被人入侵拿來挖礦了.

因?yàn)閿?shù)據(jù)庫(kù)運(yùn)行在 Docker 中,所以這次中毒并未影響主機(jī).算是不幸中的大幸吧.

以前處理過主機(jī)中十字符病毒,那個(gè)病毒瘋狂 DDoS 吃滿上行帶寬,連 SSH 都卡的不行.殺掉一個(gè)還會(huì)瞬間再生.