ChachaDDoS恶意软件分析

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://{C&C}:8852/{campaign}/{arch}。研究人员发现stage2的二进制文件支持x86、ARM、MIPS、PowerPC等架构。在下载了与受害者主机架构相关的ELF文件后，用ChaCha加密算法进行解密。下面是解密函数的开始部分：

两个算法的区别是对初始状态和1/4循环修改的顺序进行了修改，这也是明文的核心操作。根据1/4循环中使用的特定循环，研究人员识别出了其使用ChaCha：

ChaCha解密所用的key大小是256位，在其他样本中所用的key是相同的。为了避免重应用解密算法的痛苦，研究人员写了脚本来模拟解密函数。解密出stage 2后，其输出是LZMA压缩的，所以用lzma -d < output > 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代码中调用：

Lua payload下载的任务是Lua翻译器解密和执行的ChaCha。在stage 2，用于下载任务的URL看似遵循一个特定的模式，如下图所示：

Payload应该发送URL所用的参数，但实际上，只会发送MAC地址和其他信息：

Stage 3

研究人员分析发现任务只是实现了DDoS函数，其代码非常明确含有对特定目标执行SYN DDoS攻击的函数调用：

DDoS攻击的目标IP地址为144.0.2.180，是中国的ISP。但还不清楚为什么该IP地址会成为攻击的目标，而且该IP地址好像并不提供任何服务。

任务文件响应的最后一个修改的HTTP header表明从9月24日开始目标都是相同的。因为恶意软件使用了If-Modified-Since header来避免重复下载payload，因此这个结果是可信的。

结论

研究人员分析发现，很明显ChachaDDoS和Xor.DDoS在驻留机制上有代码重合。ChachaDDoS因为出现在VestaCP实例中引起了研究人员的关注，但存在多架构二进制文件说明包括嵌入式设备在内的许多设备都是攻击的目标。

该事件的另一个启示是开源软件本例也不100%保证其是安全的。恶意软件也可能利用这一点，GitHub上的恶意凭证窃取代码就存在了好几个月。虽然开源及时帮助找出和修复一些安全漏洞，但也不能说明开源就是安全的或更安全的。