IoT_reaper : 一个正在快速扩张的新 IoT 僵尸网络

2017-10-30 7,184

IoT_reaper : 一个正在快速扩张的新 IoT 僵尸网络

作者:360网络安全研究院

从2017-09-13 01:02:13开始,360网络安全研究院捕获到一个新的针对iot设备的恶意样本出现,在随后的这个一个多月时间里,这个新的IoT僵尸网络家族不断持续更新,开始在互联网上快速大规模的组建僵尸网络军团。

该僵尸网络脱胎于mirai,但是在诸多方面比mirai更进一步,特别是开始放弃弱口令猜测,完全转向利用IoT设备漏洞收割,成为IoT僵尸网络里的新兴玩家。我们将之命名为IoT_reaper

IoT_reaper规模较大且正在积极扩张,例如最近的数据昨日(10月19日)在我们观察到的多个C2中,其中一个C2上活跃IP地址去重后已经有10k个,此外还有更多的易感设备信息已经被提交到后台,由一个自动的loader持续植入恶意代码、扩大僵尸网络规模。

所幸目前该僵尸网络还尚未发出植入恶意代码以外的其他攻击指令,这反映出该僵尸网络仍然处在早期扩张阶段。但是作者正在积极的修改代码,这值得我们警惕。

我们公开IoT_reaper的相关信息,希望安全社区、设备供应商、政府能够采取共同行动,联合遏制该僵尸网络的扩张。

源于mirai,高于mirai

该僵尸网络部分借用了mirai的源代码,但是在几个关键行为上显著区别于mirai,包括:

·         恶意代码投入时不再使用弱口令猜测、而是使用iot设备漏洞,扫描发现效率大大提高;

·         恶意代码中集成了LUA执行环境,从而支持通过lua脚本编写复杂的攻击指令;

·         主动抑制了扫描速度, 被安全研究者发现的风险大大降低;

样本的投入、C2的布局和流量变化

以hxxp://162.211.183.192/sa样本为例,样本的投入过程如下。可以注意到downloader是IoT_reaper特有,这个 C2 布局与mirai有显著区别:

·         162.211.183.192:downloader,样本下载服务器,一般以"d"作为二级域名,d.hl852.com

·         27.102.101.121:controller,能够控制BOT、发送控制指令,一般以"e"作为二级域名,e.hl852.com

·         222.112.82.231:reporter,接收BOT扫描到的易感染设备信息,一般以"f"作为二级域名,f.hl852.com

·         119.82.26.157:loader,基于reporter获得的IP信息,通过漏洞植入bot

下图是上述4个IP地址自9月1日以来的流量变化:

                                              1.png

1

样本中集成了9IoT漏洞

IoT_reaper完全放弃了mirai中利用弱口令猜测的方式,转为利用IoT设备的漏洞植入,当前样本中集成了了9个IoT设备漏洞。最近十天以来,攻击者正在积极的将漏洞利用集成进入样本中,其中一个漏洞在公开后仅2天就被集成。

·         Dlink https://blogs.securiteam.com/index.php/archives/3364

·         Goahead https://pierrekim.github.io/blog/2017-03-08-camera-goahead-0day.html

·         JAWS https://www.pentestpartners.com/blog/pwning-cctv-cameras/

·         Netgear https://blogs.securiteam.com/index.php/archives/3409

·         Vacron NVR https://blogs.securiteam.com/index.php/archives/3445

·         Netgear http://seclists.org/bugtraq/2013/Jun/8

·         Linksys http://www.s3cur1ty.de/m1adv2013-004

·         dlink http://www.s3cur1ty.de/m1adv2013-003

·         AVTECH https://github.com/Trietptm-on-Security/AVTECH

2.png

图2

可以注意到作者在积极的改进代码:

·         公开渠道10月8日公开的 Vacron NVR远程利用漏洞,作者在10月10日以前就已经增加到恶意代码中;

·         10月12日、10月16日的两次更新,作者分别增加了3个、1个漏洞利用;

样本中集成了lua执行环境

Md5: CA92A3B74A65CE06035FCC280740DAF6 
基于lua执行环境,攻击者可以编写出非常复杂而且高效的攻击脚本。

样本中集成了约100DNS服务器

比照我们的DRDoS数据,100+的DNS服务器中,有大约三分之一的服务器曾经在现实世界中用来做为DNS反射攻击的反射点。这在之前mirai及其变种中是没有观察到的。

攻击者是否能够进一步充分组合使用 IoT 僵尸网络 + DNS反射点 打出大流量的DDoS攻击,有待进一步观察。

目前为止没有实质性的攻击指令

攻击指令方面,虽然我们在lua的源文件中看到了N中ddos攻击方式,但目前为止除了下载样本的指令以外,没有看到实际DDoS攻击指令,这显示出攻击者目前工作重心仍在构建僵尸网络上。

感染规模

基于一些统计技巧,我们对感染规模做了一个相对精确的统计

·         待植入节点数:单个C2,超过2m;

·         累积已植入节点数:单个C2,近7天超过20k;

·         当日活跃节点数:单个C2,10月19日大约是10k左右;

·         同时在线节点数:单个C2,大约是4k左右;

攻击能力

虽然目前为止我们没有监测到该僵尸网络除植入恶意代码以外的任何攻击行为,但是我们判定该僵尸网络有较强的攻击潜力:

·         可以认为攻击者拥有100Gbps攻击带宽。我们已经确认该僵尸网络有超过10k/d的日活节点,假定每个节点拥有10mbps的上行带宽,则攻击者拥有100Gbps的攻击带宽;

·         该僵尸网络内置了lua执行环境。尽管样本中删去了mirai相关攻击代码,但基于lua执行环境可以编写出非常复杂而且高效的攻击脚本;

IoC URLs

hxxp://cbk99.com:8080/run.lua 
hxxp://bbk80.com/api/api.php 
hxxp://103.1.221.40/63ae01/39xjsda.php 
hxxp://162.211.183.192/down/server.armel 
hxxp://162.211.183.192/sa 
hxxp://162.211.183.192/sa5 
hxxp://162.211.183.192/server.armel 
hxxp://162.211.183.192/sm 
hxxp://162.211.183.192/xget 
hxxp://198.44.241.220:8080/run.lua 
hxxp://23.234.51.91/control-ARM-LSB 
hxxp://23.234.51.91/control-MIPS32-MSB 
hxxp://23.234.51.91/htam5le 
hxxp://23.234.51.91/ht
mpbe 
hxxp://27.102.101.121/down/1506753086 
hxxp://27.102.101.121/down/1506851514

IoC Hashes

3182a132ee9ed2280ce02144e974220a 
3d680273377b67e6491051abe17759db 
41ef6a5c5b2fde1b367685c7b8b3c154 
4406bace3030446371df53ebbdc17785 
4e2f58ba9a8a2bf47bdc24ee74956c73 
596b3167fe0d13e3a0cfea6a53209be4 
6587173d571d2a587c144525195daec9 
6f91694106bb6d5aaa7a7eac841141d9 
704098c8a8a6641a04d25af7406088e1 
726d0626f66d5cacfeff36ed954dad70 
76be3db77c7eb56825fe60009de2a8f2 
95b448bdf6b6c97a33e1d1dbe41678eb 
9ad8473148e994981454b3b04370d1ec 
9f8e8b62b5adaf9c4b5bdbce6b2b95d1 
a3401685d8d9c7977180a5c6df2f646a 
abe79b8e66c623c771acf9e21c162f44 
b2d4a77244cd4f704b65037baf82d897 
ca92a3b74a65ce06035fcc280740daf6 
e9a03dbde09c6b0a83eefc9c295711d7 
f9ec2427377cbc6afb4a7ff011e0de77 
fb7c00afe00eeefb5d8a24d524f99370

自360网络安全研究院披露该僵尸网络病毒后,收到了来自安全社区和各方很多问题。这里360网络安全研究院给出一个快速的更新,以澄清各方可能的疑问。

IoT_reaper样本投递历史情况

我们通过蜜罐观察到的 IoT_reaper 样本历史投递情况如下:

3.png

图3

可以看出,IoT_reaper 最主要传播的恶意代码位于下面这个URL上:

·         下载地址:hxxp://162.211.183.192/sa

·         投递者:119.82.26.157

·         起止时间:10-04~10-17

·         样本md5:7 个,详细见文末IoC

这个URL上的样本之间内聚关系比较强,我们称为S簇。

后来进一步的分析,认为S簇还包括其他一些样本;而在S簇之外,还有一个LUA簇,以及其他更小一些的未知簇。

S簇的样本构成

我们认为S簇包含下面这些URL上的样本:

·         hxxp://162.211.183.192/sa

·         hxxp://162.211.183.192/sa5

·         hxxp://162.211.183.192/sm

·         hxxp://162.211.183.192/sml

簇内的命名策略可能是这样的,头部的s代表S簇:

·         sa: arm

·         sa5:arm5

·         sm:mips

·         sml:mips 小端

S簇的C2 布局、感染机制和数字疑问

4.png

图4

如上图:

·         loader : 负责通过漏洞植入恶意代码

·         downloader : 提供恶意代码下载

·         reporter : 接收bot扫描到的易感染设备信息

·         controller : 控制bot、发送控制指令

·         我们猜测,在reporter 和 loader 之间有一个队列,reporter会将收集到的易感染设备信息推入队列,等待loader处理

与 S 簇感染相关的有一组不同的数字,近日来容易引起安全社区的混淆。我们看到的数字如下:

·         已经汇报到单台 reporter 的易感染设备数:超过2m,到 2017-10-18 为止;

·         单台 controller 累积控制设备数:超过28k,到 2017-10-24 为止;

这两个数字之间有 显著差距,原因尚不明确。这可能是因为攻击者的实现导致在队列中加入了大量的不存在相应漏洞的设备, 或者是攻击者的 loader 处理能力不足而被动积压,也有可能是攻击者主动抑制了感染速度以减少暴露风险,或者是因为其他我们不得而知的原因。

S 簇单台 C2 感染情况统计(2017-10-13 2017-10-23

时间分布:

5.png

图5

国家分布:

6.png

图6

被感染的前十国家:

7.png

图7

与 mirai 初期感染情况对比

8.png

图8

S簇的近期样本变化情况

我们会监控视野范围内样本变化情况。在10月23日,我们检测到S簇的如下URL内容发生变化:

·         hxxp://162.211.183.192/sa

变化情况如下表所示:

9.png

图9

在原始报告的“样本的投入、C2 的布局和流量变化”一节已经提及:这是一个恶意代码样本,被控制者放置在downloader服务器上,被loader服务器投递,投递成功后会向controller报告心跳,启动扫描并将扫描到的易感染设备信息报告给reporter。

我们仔细观察更新后的样本发现:

·         新集成了一个新的漏洞利用 :http://roberto.greyhats.it/advisories/20130227-dlink-dir.txt

·         心跳会指向 e.hl852.com/e.hl859.com

·         样本中内置了9个硬编码的IP地址,扫描时,扫描目标地址会包含;

·         上述9个IP地址上有共计 34个端口会被频繁扫描:其中17个端口是硬编码的,样本会随机扫描其中的部分;另外17个端口虽然会被频繁扫描,但是并未被直接硬编码到样本中。我们推测样本中隐藏了某段逻辑来扫描后面17个端口。

这第十个漏洞利用在样本中的调用过程:

10.png

图10

上述9个硬编码的IP地址是:

217.155.58.226 

85.229.43.75 

213.185.228.42 

218.186.0.186 

103.56.233.78 

103.245.77.113 

116.58.254.40 

201.242.171.137 

36.85.177.3 

对应的,我们可以观察到大网上这9个IP地址的流量在上述时间点以后开始增加:

11.png

图11

34 个硬编码、没有硬编码但是会被扫描的端口号:

12.png

图12

S 簇的 C2 DNS流量变化

S 簇先后使用了下面一组C2,对应的 DNS 流量图见后

·         e.hi8520.com:对应图中最上方蓝色曲线;

·         e.hl852.com:对应图中中间绿色曲线;

·         e.ha859.com:对应途中底部黄色曲线;

13.png

图13

IoC 
hxxp://162.211.183.192/sa 41ef6a5c5b2fde1b367685c7b8b3c154 
hxxp://162.211.183.192/sa f9ec2427377cbc6afb4a7ff011e0de77 
hxxp://162.211.183.192/sa 76be3db77c7eb56825fe60009de2a8f2 
hxxp://162.211.183.192/sa5 95b448bdf6b6c97a33e1d1dbe41678eb 
hxxp://162.211.183.192/sa e9a03dbde09c6b0a83eefc9c295711d7 
hxxp://162.211.183.192/sa 3d680273377b67e6491051abe17759db 
hxxp://162.211.183.192/sa 726d0626f66d5cacfeff36ed954dad70


本文作者:360核心安全

本文为安全脉搏专栏作者发布,转载请注明:https://www.secpulse.com/archives/63951.html

Tags:
评论  (0)
快来写下你的想法吧!

360核心安全

文章数:70 积分: 76

安全问答社区

安全问答社区

脉搏官方公众号

脉搏公众号