ChachaDDoS惡意軟體分析

新聞 10-27

VestaCP用戶發現其管理憑證被竊，伺服器被感染Linux/ChachaDDoS。

感染向量

VestaCP論壇的用戶Razza稱，攻擊者嘗試通過SSH載入Linux/ChachaDDoS。目前還不清楚payload是如何釋放到/var/tmp目錄中的，假設攻擊者已經有了管理員密碼，那麼就很簡單了。在安裝過程中，VestaCP會創建一個有sudo許可權的admin用戶。但攻擊者是如何知道admin用戶的密碼的呢？

關於這個問題有很多的假設，第一個假設是VestaCP的web介面有漏洞。通過查看代碼發現，/root/.my.cnf中保存有未加密的口令，但要想訪問文件的內容攻擊者需要利用本地文件包含和許可權提升漏洞。用戶Falzo發現許多版本的安裝腳本都在泄露管理密碼和到vestacp.com的伺服器名。

L4ky指出，在Git的vst-install-ubuntu.sh文件中，變數$codename含有發送給http://vestacp.com/notify/的base64編碼的密碼和伺服器域名。

鑒於此，研究人員建議所有的VestaCP管理員修改admin密碼並加強對伺服器的授權訪問。

VestaCP維護人員稱其伺服器被入侵了。Git樹中的惡意代碼還不清楚。攻擊者可能修改了伺服器上的安裝腳本，而該版本也用於git中創建該文件的下一個版本，但只針對於Ubuntu。這意味著伺服器可能從2018年5月就被入侵了。

Linux/ChachaDDoS分析

釋放在被入侵伺服器上的惡意軟體是一個DDoS惡意軟體ChachaDDoS的變種。其是多個現有DDoS惡意軟體的進化版本。Stage1和stage2將進程名設置為[kworker/1:1]，這可以在ps的輸出中看到。

Stage 1

駐留機制

Linux/ChachaDDoS中使用的駐留機制與Linux/XorDDos除了文件名外都是一樣的。其中含有下面的步驟：

·將自己複製到/usr/bin/dhcprenew；

·如果已有惡意軟體相關的駐留機制，就移除原有的駐留機制；

·在/etc/init.d/dhcprenew中加入新的服務。

#!/bin/sh

# chkconfig: 12345 90 90

# description: dhcprenew

### BEGIN INIT INFO

# Provides: dhcprenew

# Required-Start:

# Required-Stop:

# Default-Start: 1 2 3 4 5

# Default-Stop:

# Short-Description: dhcprenew

### END INIT INFO

case $1 in

start)

/usr/bin/dhcprenew

;;

stop)

;;

/usr/bin/dhcprenew

;;

esac

·在/etc/rc[1-5].d/S90dhcprenew和/etc/rc.d/rc[1-5].d/S90dhcprenew中創建到該服務的symlink。

運行命令行chkconfig --add dhcprenew和update-rc.d dhcprenew defaults來開啟服務。

下載和解密第二階段腳本

設置完駐留機制後，會從硬編碼的URL上周期性的下載。研究人員通過分析不同樣本發現URL的結構有些共同的特點：

·使用8852埠；

·所有使用的IP地址都屬於193.201.224.0/24子網；

·Stage 2的資源名看起來是偽隨機的，但實際上是6到8個大寫字母字元串。

URL的模式如http://:8852//。研究人員發現stage2的二進位文件支持x86、ARM、MIPS、PowerPC等架構。在下載了與受害者主機架構相關的ELF文件後，用ChaCha加密演算法進行解密。下面是解密函數的開始部分：

兩個演算法的區別是對初始狀態和1/4循環修改的順序進行了修改，這也是明文的核心操作。根據1/4循環中使用的特定循環，研究人員識別出了其使用ChaCha：

ChaCha解密所用的key大小是256位，在其他樣本中所用的key是相同的。為了避免重應用解密演算法的痛苦，研究人員寫了腳本來模擬解密函數。解密出stage 2後，其輸出是LZMA壓縮的，所以用lzma -d second_stage.elf就可以提取出二進位文件。

Stage 2

stage 2的二進位文件本身比stage 1的要大，主要是因為嵌入了Lua翻譯器。Lua中的惡意軟體與之前發現的Linux/Shishiga有些相像。Stage 2的目的是硬編碼的Lua payload，payload的任務都是完成周期性的下載任務。研究人員將任務看作是stage 3，因為任務是根據Lua代碼翻譯的結果確定的。在所有的樣本中，stage 2所用的C2伺服器與stage 1相同。Stage 2會嵌入無數的Lua庫來與硬編碼的C2伺服器進行通信，這與stage 1也是相同的。

下圖是綁定的有些二進位文件的原生函數，這樣就可以從lua代碼中調用：