概述

我们于近期决定公开一部分Hajime相关的研究结果及数据，供社区成员查阅。本文的核心内容包含以下几点：

Hajime跟踪主页上线。结合Hajime的通讯特点（DHT+uTP），我们实现了对Hajime各Bot节点的长期跟踪，同时还在主页绘制了日活及地域分布情况。
通过逆向分析，我们代码级重现了密钥交换过程，在该工作的帮助下，可以随时获取到Hajime网络中的最新模块文件。
跟踪过程中，我们发现一个包含x64配置项的config文件，该发现预示着，原作者有意将PC平台作为下一个感染目标（这里也存在原作者密钥泄露的可能性）。

Hajime背景

与 MIRAI 的张扬不同，Hajime是一个低调神秘的Botnet，在诞生后的这一年中并没有给公众传递太多的恐慌。MIRAI在明，Hajime在暗，两者相得益彰。在MIRAI源码公开期间，已经有友商详细阐述过其工作机制。

Hajime的核心特点在于：它是一个P2P botnet，安全人员无法通过黑名单的方式直接堵死 Hajime 的指令传输渠道，达到遏制的目的。所以，其一旦广泛传播开便极难彻底清除。

Hajime每过10分钟会从P2P网络中同步一次config文件，并将该文件的info字段（如上图所示）展示到控制台，意图自证清白。其info字段大意为：别慌，Hajime是一个由白帽子运营的僵尸网络，是来保护IoT设备的。
PS：如果是没有英文阅读障碍的读者一定知道，“别慌”这个词是后加的。:-)

整体框架

Hajime基于模块化编程，常见的可执行模块有两个，分别为“执行母体”（也被称作stage2或.i 模块）和“传播模块”（也被称作atk模块）。其工作示意图如下所示：

在“执行母体(.i模块)”中，Hajime的各个节点将依赖 DHT协议建立起一个 P2P 网络，在这个 P2P 网络中，Hajime节点可以完成节点间协商，接收控制指令以及文件同步等功能。任何一个节点都可以在不和管理员直接通讯的情况下拿到管理员发出的控制指令。这在保护了管理员的同时，也维持了僵尸网络自身的稳定性。一旦网络被组建起来就极难被清除。

在 DHT 网络中，Hajime 把 config 文件编码为一个特殊的 infohash 值，这是一个160bit的二进制数字，该值每日一变。通过对这个 infohash 的索引，Hajime 就可以拿到最新的 config 文件。

上图是2017年8月12日的config文件，可以看到config文件是一个文本文件，在modules字段中包含了各CPU架构的模块文件名，peers字段则指明了DHT网络的入口域名，这两个域名均为合法且公开的DHT网络入口域名。该配置文件将指引 Hajime 同步到最新的“传播模块（atk模块）”或“执行母体（.i模块）”。

文件同步

在 DHT 网络中，每一个Hajime节点可以对应为一个peer。通过对DHT网络的搜索，Hajime节点可以很容易的获得到其他 Hajime节点的地址信息。当执行文件同步操作时，将依次遍历其他节点，执行文件同步操作。节点间的通讯依赖 uTP协议，该协议基于 UDP实现了三次握手/会话重传/会话中断等机制，可以保证Hajime节点间的可信通讯。

密钥交换

在uTP提供的信道基础上，Hajime对每次会话做了RC4的通讯加密，以保证他人无法从抓包手段还原出通讯内容。其次Hajime又使用了一个密钥协商算法来保证RC4密钥的不可窃取性。

Hajime采用了 ECDH 作为密钥交换协议，并选用了一个基于Curve25519椭圆曲线实现的密钥交换算法，虽然网上有很多公开的ECDH实现。但Hajime作者并未直接使用已有的代码。而是参考Curve25519相关文档实现了一个效率更高的密钥交换过程，新方法将原有椭圆空间的点映射到新的一维数列中，在 “倍点”的计算过程中只计算X坐标，而无需考虑Y坐标，最终提高了密钥交换的计算效率。

Curve25519 的相关内容可参考: https://cr.yp.to/ecdh.html
新密钥交换算法的基础可参考: https://cr.yp.to/ecdh/curvezero-20060726.pdf

文件验签

在P2P网络中，节点是不可信的，任何人都能够以极低成本的伪造一个Hajime节点。为保证Hajime网络的完全可控，不被他人窃取。Hajime需要对每一个同步到的文件做签名验签，只有能够通过签名验签的文件才能被Hajime节点接受，并执行。
Hajime采用的验签方法为ED25519，这是一个公开的数字签名算法。于此同时，验签公钥为：A55CEED41FECB3AC66B6515AB5D383791B00FEC166A590D7626A04C2466B3F54，该公钥被集成到了每一个Hajime“执行母体”中。也就是说任何一个Hajime节点均可以对拿到的新文件进行合法性验证。

近况

日活节点

将 Hajime 的节点 IP 活跃数量以日为单位切分后，可绘制如下日活节点图：

从上图不难发现，整个7月下半旬，Hajime日活数量出现了一个较长期的波谷。它在这个期间一直处在稳定状态，也没有发现新的文件或指令被发布。

但随着8月份的到来 Hajime 停止了沉寂，分别在 2017-08-06 和 2017-08-12 两日发布了两次更新，这两次更新可以分别和上图后半段的两个波峰吻合。所以这一刻我们确认，Hajime复活了。

随后，Hajime又在2017-08-18、2017-08-19、2017-08-22、2017-09-04日完成了数次更新。并开启了频繁更新的常态。

地域分布

对 Hajime 近两月的活跃节点做地域分布统计后，可得到下图：

颜色越深表明该地区受影响越严重。

更新频率

Hajime 在7月份更新并不频繁，期间还出现了半个月的中断。而8月5日后，Hajime又开始回归了频繁更新的状态，其更新频率如下图所示：

事实上近一个月的更新都是围绕已有代码修修补补，并没有出现太大的变动。

传播方式

在近两个月中，Hajime的传播方式仍然继承之前的传播手段，其依赖的传播端口及传播方式如下表所示:

2017-01-17 atk.arm5.1481380646 2487b4ed4a2f55bfd743b2e6b98f8121
2017-05-29 atk.arm5.1496096402 a238462e1e758792c5d1f04b82f4a6a0
http://console-cowboys.blogspot.com/2013/01/swann-song-dvr-insecurity.html
https://gist.github.com/ylluminate/fcee91965b58695460ce849c424488f7
https://twitter.com/masafuminegishi/status/870182653797871617

节点分布中CPU占比情况

我们已知Hajime的传播范围局限在少部分CPU之间，在对18433个Hajime节点进行分析后，发现:在受影响的各种CPU类型中，Mipseb是占比最多的，如下表所示：

其他相关内容

正在考虑支持 x64 平台 ?

发出这一疑问的原因是，我们的Hajime跟踪系统于2017-08-29日捕获到一个配置文件b8a5082689606ea20a557883dbff7d10，该文件能够顺利通过Hajime的签名验证过程，同时文件中还存在一个针对x64 CPU的内容配置项，这个配置项似乎预示着原始作者正在考虑对PC平台的支持。如下图所示：

但该配置文件存在若干疑点：

在配置文件显示的 module 列表中，我们仅获取到了atk.mipseb/.i.mipseb 两个module，而并没有拿到其他架构下的module，所以其他架构下的 module 可能压根就不存在。
该配置文件缺少info字段，即缺少原作者声明自己是白帽子的文字描述，这一点非常反常，与原作者的习惯有别。

综合以上内容，可以得出两种假设：

首先，在没有更多证据前，我们倾向于认为私钥没有泄露。那么，能够验签通过就是一个强有力的证据，证明原作者有意支持 x64 平台。
另一方面，上述两处疑点均违反了 Hajime 原始作者的习惯或网络特性。如将其作为非原始作者传播的旁证。那么，可以认定作者的私钥发生了泄露，且这个拥有私钥的人正在尝试向Hajime网络中投毒，意图窃取 Hajime 网络。

相对第二种假设，我们更倾向于相信前者；首先，能够造出如此复杂的僵尸网络的人不大可能会犯私钥泄露的错误，其次，考虑对 x64 平台的支持也更符合 Hajime 保护互联网设备的需求。

参考

1: https://x86.re/blog/hajime-a-follow-up/
2: https://github.com/Psychotropos/hajime_hashes
3: https://security.rapiditynetworks.com/publications/2016-10-16/hajime.pdf
4: https://securelist.com/hajime-the-mysterious-evolving-botnet/78160/
5: https://sect.iij.ad.jp/d/2017/09/293589.html