360网络安全研究院2017年12月5日发布关于Satori的 文章,提到Satori僵尸网络正在以前所未有的速度快速传播。自从360网络安全研究院的文章发布以后,安全社区、ISP、供应链厂商共同协作,Satori 的控制端服务器被 sinkhole、ISP和供应链厂商采取了行动,Satori的蔓延趋势得到了暂时遏制,但是Satori的威胁依然存在。
从 2018-01-08 10:42:06 GMT+8 开始,360网络安全研究院检测到 Satori 的后继变种正在端口37215和52869上重新建立整个僵尸网络。值得注意的是,新变种开始渗透互联网上现存其他Claymore Miner挖矿设备,通过攻击其3333 管理端口,替换钱包地址,并最终攫取受害挖矿设备的算力和对应的 ETH 代币。360网络安全研究院将这个变种命名为 Satori.Coin.Robber。
这是360网络安全研究院第一次见到僵尸网络替换其他挖矿设备的钱包。这给对抗恶意代码带来了一个新问题:即使安全社区后续接管了 Satori.Coin.Robber 的上联控制服务器,那些已经被篡改了钱包地址的挖矿设备,仍将持续为其贡献算力和 ETH 代币。
到 2018-01-16 17:00 GMT+8 为止, 矿池的 付费记录 显示:
Satori.Coin.Robber 当前正在持续挖矿,最后一次更新大约在5分钟之前;
Satori.Coin.Robber 过去2天内平均算力大约是 1606 MH/s;账户在过去24小时累积收入 0.1733 个ETH代币;
Satori.Coin.Robber 已经在2017年1月11日14时拿到了矿池付出的第一个 ETH 代币,另有 0.76 个代币在账户上;
另外值得一提的是,Satori.Coin.Robber 的作者通过下面这段话宣称自己当前的代码没有恶意,并且留下了一个电子邮箱地址:
图1
Claymore Miner 是一个流行的的多种代币的挖矿程序,互联网上现存了较多设备正在基于Claymore Miner挖矿。Claymore Miner 提供了远程监控和管理的接口。
按照其 文档 的描述,其 Windows 版本通过 Remote management 子目录下的 EthMan.exe 文件,在3333端口上,提供了远程监控和管理的特性。其早期版本允许远程读取挖矿进程的运行状态,同时也允许执行重启、上传文件等控制行为。
在缺省情况下就可以获得部分控制权,这显然是个脆弱性问题。作为应对,8.1 版本以后,Claymore Miner 缺省使用 -3333 (而不是 3333 )端口作为启动参数,这意味着远程管理端口是只读的,不再能够执行控制命令。
但是这并不代表这一系列的远程管理接口问题就到此结束了。2017年11月,CVE-2017-16929 被披露,允许远程读写任意文件。对应的 利用代码 也已经批露。
360网络安全研究院这次观察到的漏洞利用代码跟上面列出的均有所不同。这次攻击主要是针对开放了3333端口管理、同时又没有设置远程登录密码的 Claymore Miner挖矿设备。为防止潜在的滥用,360网络安全研究院不会在文章中公布详细细节。
在 2018-01-08至2018-01-12期间,360网络安全研究院观察到了以下样本:
图2
这组样本是Satori的后续变种,这个变种不仅会扫描早先的 37215 和 52869 端口,还会扫描 3333 端口,三个端口上的扫描载荷分别是:
端口 37215 : 已有,针对漏洞 CVE-2017-17215,华为公司最近发布了相关的声明,并在持续更新;
端口 52869 : 已有,针对漏洞 CVE-2014-8361,这是一个针对 Realtek SDK 的漏洞,网上自2015年就公开了漏洞利用代码
端口 3333 : 新增,针对上述 Eth 挖矿进程远程管理接口的攻击。
图3
上图是端口 3333 的扫描载荷。这个扫描中,Satori.Coin.Robber 会顺序发出三个包,分别是:
第一个包:miner_getstat1,获取状态;
第二个包:miner_file,更新reboot.bat文件,替换其中的矿池和钱包地址;
第三个包:miner_reboot,重启生效。
在这个上述 reboot_bat 的文件更新过程中:
矿池地址替换为:eth-us2.dwarfpool.com:8008
钱包地址替换为:0xB15A5332eB7cD2DD7a4Ec7f96749E769A371572d
通过这种方式,Satori.Coin.Robber 将其他设备上 ETH 挖矿进程的算力攫取为己用。
360网络安全研究院对比两个版本的 Satori.Coin.Robber,寻找其中的异同:
737af63598ea5f13e74fd2769e0e0405 Satori.Coin.Robber
5915e165b2fdf1e4666a567b8a2d358b satori.x86_64, 2017年10月版本,VT报告地址
相同点:
代码:均使用了UPX加壳,并且使用了相同的幻数 0x4A444E53,脱壳后大量代码结构类似。
配置信息:配置信息均加密,加密方式相同,且大量配置字符串是一致的。例如 /bin/busybox SATORI,bigbotPein,81c4603681c46036,j57*&jE,等等;
扫描载荷:两者均扫描 37215 和 52869 端口,并且使用了相同的扫描载荷
360网络安全研究院认为这些证据够强,足以将这次的新变种与之前的 Satori 联系起来。
不同点:
扫描载荷:Satori.Coin.Robber 新增了 3333 端口上针对 Claymore Miner的攻击
扫描过程:Satori.Coin.Robber 使用了异步网络连接(NIO)方式发起连接,这种方式会提高扫描效率
C2 协议:Satori.Coin.Robber 启用了一组新的C2 通信协议,会基于DNS协议与54.171.131.39通信。后面会有专门的一节来描述。
下面是一些详细的截图证据展示:
两个版本的样本公用了相同的UPX加壳幻数:
图4
Satori.Coin.Robber 在扫描过程中使用了异步网络连接方式:
图5
Satori.Coin.Robber 的 C2 :
硬编码的IP地址,54.171.131.39,位于爱尔兰都柏林。
通信协议是基于DNS修改的,可以使用 dig @54.171.131.39 $DNS-QNAME any +short 的方式做一个简单测试,每个$DNS-QNAME对应不同的功能。
整体C2协议列表如下:
图6
协议释义如下:
客户端请求 w.sunnyjuly.gq,服务器返回 0xB15A5332eB7cD2DD7a4Ec7f96749E769A371572d
客户端请求 p.sunnyjuly.gq,服务器返回 eth-us2.dwarfpool.com:8008
客户端请求 s.sunnyjuly.gq,服务器返回一段字符串 "Satori dev here, dont be alarmed about this bot it does not currently have any malicious packeting purposes move along. I can be contacted at [email protected]."
客户端请求 f.sunnyjuly.gq,服务器返回 213.74.54.240。这个请求并不是样本中出现的,是360网络安全研究院的研究人员尝试 fuzzing 后得到的。
最前面两个请求的回应,恰好是 bot 篡改别的挖矿设备后使用的矿池和钱包地址。但是目前阶段,样本中的扫描载荷仍然是硬编码的,并没有使用这里的服务器返回值; 服务器返回的那段英文,翻译成中文的大意是“我是Satori的作者,现在这个bot还没有什么恶意的代码,所以暂时放轻松。联系我的话,邮件写给[email protected]”
360网络安全研究院大体上可以使用三个扫描端口在 ScanMon 上的扫描趋势来度量 Satori.Coin.Robber 的感染范围和趋势。
37215、52869 和 3333 端口上过去30 天的扫描趋势依次如下:
图7
图8
图9
总体来看,三个端口上均有扫描暴涨,与本次样本表现能够对应。
初始出现时间都在 2018年1月8日附近;
高峰时间都在都在 2018年1月8日~2018年1月8日附近;
最近几天扫描量逐渐下降;
主要扫描来源在 AS4766 Korea Telecom ;
独立扫描源IP地址,约为 4.9k;
噪音方面,37215与52869 端口上,依据1月8日以前的表现,可能有部分扫描来源不属于 Satori.Coin.Robber;但是 3333 端口比较干净,依据1月8日以前的表现来看,噪音较小。考虑到三个端口上的扫描表现趋于一致,360网络安全研究院认为上述数据可以表现当前 Satori.Coin.Robber 的感染趋势。
Satori 的最初版本虽然已经被安全社区抑制,但是新的继任者已经出现。
新的Satori.Coin.Robber,会扫描别的设备上的挖矿程序,并将钱包地址替换成自己的。这是360网络安全研究院在botnet领域第一次看到这种行为模式。
尽管作者宣称自己当前没有恶意,但是传播恶意代码、未经授权修改他人计算机上的信息、攫取他人计算机算力为自己挖取数字代币,这些行为都是恶意行为。
考虑到12月5日附近Satori在12小时内感染了超过26万IoT设备,当前 Satori.Coin.Robber的感染速度已经远远变低,暂时不用恐慌。
上述感染速度的降低,不应该归因为攻击者刻意降低了扫描的速度,特别是考虑到攻击者启用了NIO技术来加速扫描阶段的效率;而应该归因为安全公司、ISP、供应链设备厂商共同的协作和努力。