软件逆向-RotaJakiro后门与Buni后门关联性分析

本文将根据360Netlab报告中提到的RotaJakiro后门特点以及微步报告中描述的Buni后门特点对二者关联分析。经分析，两种后门的相似之处如下：

1. 单一实例
   RotaJakiro通过文件锁来实现单一实例，具体实现如下图左所示。图右为Buni单一实例实现方式
   

2. 发包与收包
   RotaJakiro后门将构造上线信息加密发送至C2，其中send函数如下
   
   同样的，recv函数也十分相似
   

然而，RotaJakiro与Buni的不同之处似乎更多

1. C2解密算法
   OceanLotus RotaJakiro样本中调用AES+Rotate Left解密C2，对抗技巧之一：使用stack strings obfuscation技术存储加密的敏感资源信息。其与解密相关的各种参数如下图所示，密文长度为32字节，明文长度为26字节
   
   AES解密，其中aes_dec的采用的是AES-256, CBC模式，key&iv都是硬编码。
   Rotate为循环移位，此处使用的循环左移，其中移位的次数由plain_len(明文长度)&7的值决定
   
   AES解密后得到以下“次级密文”：
   
   从次级密文中取出有效密文，其中有效密文从第8字节开始，长度为明文长度减8，此处即为26-8=18字节。
   最后通过明文长度26可以计算26&7=2，得到移位的次数，将上述有效密文逐字节左移2位之后得到C2明文。
   
   而Buni后门中使用的C2加密算法为XOR
   
   与0xB1异或结果为 zabbixasaservice.com:443

2. 结构化流量/网络通信包
   RotaJakiro的网络通信包由Head，Key，Payload三部分组成。其中header是必须的，长度为82字节，而body&payload部分是可选的。head&key采用的XOR&Rotate加密，payload采用AES&ZLIB加密压缩。
   

• head通过逐字节左移3位，然后和0x1b异或进行解密
  解密后可得
  offset 0x09, 4 bytes -> payload length
  offset 0x0d, 2 bytes -> key length
  offset ox0f, 4 bytes -> cmdid
  key的长度为0x8字节，payload 的长度为0x20字节，要执行的指令码为0x18320e0，即上报设备信息
• key使用和head一样的解密方法，解密后作为AES的密钥来解密payload
• payload 使用解密后的key做为AES-256的密钥，以CBC模式解密，第8字节起即为ZLIB压缩数据，进行解压
  解压后做为新的AES密钥，配合参数解密样本中硬编码的加密指令
  最后发送至C2的数据包仍以上述结构组成，其中payload 经解密为上述指令执行的结果

Buni则是通过逐字节recv接收的方式解析流量结构

解析结果如下，要执行的指令码为0xdafe

Buni的通信流量特征与RotaJakiro相似度较低

1. 进程伪装
   RotaJakiro进程伪装对root/non-root做了区分
   针对root用于伪装的文件名：/bin/systemd/systemd-daemon 或 /usr/lib/systemd/systemd-daemon；
   针对non-root：$HOME/.dbus/sessions/session-dbus 和$HOME/.gvfsd/.profile/gvfsd-helper
   Buni 通过随机函数产生6-12的随机长度字符串，调用 prctl 函数设置随机进程名称，伪装成系统进程

再来看RotaJakiro与2017年Palo Alto披露的海莲花macOS后门的相同之处

1. C2会话建立函数
   RotaJakiro与海莲花macOS后门均使用了相对小众的getaddrinfo()函数，Buni后门中则使用Linux常见的域名解析函数gethostbyname()。
2. 上线包构造手法
   RotaJakiro和海莲花的网络数据包都是由Head,Key,Payload三部分组成，其中Head是必须的，长度为82字节，而Key和Payload则是可选的。Head中的关键字段包括：
   偏移1，DWORD类型，存放一个magic；
   偏移9，DWORD类型，存放Payload长度；
   偏移13，WORD类型，存放Key长度；
   偏移15，DWORD类型，存放消息码。
   RotaJakiro通过一个单独的函数初始化上线包的Head，海莲花样本中也存在一个专门初始化上线包Head的函数
   
   最终上线包如下，RotaJakiro与海莲花上线包明文结构一样，关键字段值基本相同
   
   Buni上线包如下
   
3. 均存在rotate函数
   RotaJakiro和海莲花都存在一个“rotate()”的函数，用于加/解密，Buni后门不包含该特征
4. 相同的指令码
   RotaJakiro和海莲花都用DWORD类型的指令码来指定消息的功能，并且共享了多个语义相同的指令码。
   Buni指令码为WORD类型，未发现指令码共享

研究人员将Buni后门归因为海莲花的主要原因是其与RotaJakiro后门存在相似之处。
经分析，Buni后门与RotaJakiro后门的关联性较低，只有创建文件锁、发包与收包函数相似，在其他方面例如加解密算法：RotaJakiro样本中几乎没有明文存在，C2地址以及执行指令均经过加密，涉及到的算法包括动态AES、Rotate Letf、ZLIB，而Buni中的指令以明文硬编码存在，C2地址仅以异或加密，上线包特征，指令特征，持久化实现、进程伪装等方向均无重合之处，因此笔者认为Buni后门或不足以归因为海莲花