安全文库

【技術分享】Is Hajime botnet dead?


【技術分享】Is Hajime botnet dead?


【技術分享】Is Hajime botnet dead?

 

概述


我們於近期決定公開一部分Hajime相關的研究結果及數據,供社區成員查閱。本文的核心內容包含以下幾點:

Hajime跟蹤主頁上線。結合Hajime的通訊特點(DHT+uTP),我們實現了對Hajime各Bot節點的長期跟蹤,同時還在主頁繪製了日活及地域分佈情況。

通過逆向分析,我們代碼級重現了密鑰交換過程,在該工作的幫助下,可以隨時獲取到Hajime網路中的最新模塊文件。

跟蹤過程中,我們發現一個包含x64配置項的config文件,該發現預示著,原作者有意將PC平台作為下一個感染目標(這裡也存在原作者密鑰泄露的可能性)。

 

Hajime背景


與 MIRAI 的張揚不同,Hajime是一個低調神秘的Botnet,在誕生后的這一年中並沒有給公眾傳遞太多的恐慌。MIRAI在明,Hajime在暗,兩者相得益彰。在MIRAI源碼公開期間,已經有友商詳細闡述過其工作機制

Hajime的核心特點在於:它是一個P2P botnet,安全人員無法通過黑名單的方式直接堵死 Hajime 的指令傳輸渠道,達到遏制的目的。所以,其一旦廣泛傳播開便極難徹底清除。

【技術分享】Is Hajime botnet dead?

Hajime每過10分鐘會從P2P網路中同步一次config文件,並將該文件的info欄位(如上圖所示)展示到控制台,意圖自證清白。其info欄位大意為:別慌,Hajime是一個由白帽子運營的殭屍網路,是來保護IoT設備的。 

PS:如果是沒有英文閱讀障礙的讀者一定知道,「別慌」這個詞是后加的。:-)

 

整體框架


Hajime基於模塊化編程,常見的可執行模塊有兩個,分別為「執行母體」(也被稱作stage2或.i 模塊)和「傳播模塊」(也被稱作atk模塊)。其工作示意圖如下所示:

【技術分享】Is Hajime botnet dead?

在「執行母體(.i模塊)」中,Hajime的各個節點將依賴 DHT協議 建立起一個 P2P 網路,在這個 P2P 網路中,Hajime節點可以完成節點間協商,接收控制指令以及文件同步等功能。任何一個節點都可以在不和管理員直接通訊的情況下拿到管理員發出的控制指令。這在保護了管理員的同時,也維持了殭屍網路自身的穩定性。一旦網路被組建起來就極難被清除。

【技術分享】Is Hajime botnet dead?

在 DHT 網路中,Hajime 把 config 文件編碼為一個特殊的 infohash 值,這是一個160bit的二進位數字,該值每日一變。通過對這個 infohash 的索引,Hajime 就可以拿到最新的 config 文件。

【技術分享】Is Hajime botnet dead?

上圖是並未直接使用已有的代碼。而是參考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 活躍數量以日為單位切分后,可繪製如下日活節點圖:

【技術分享】Is Hajime botnet dead?

從上圖不難發現,整個7月下半旬,Hajime日活數量出現了一個較長期的波谷。它在這個期間一直處在穩定狀態,也沒有發現新的文件或指令被發布。

但隨著8月份的到來 Hajime 停止了沉寂,分別在 正在考慮對PC平台的支持。如下圖所示:

【技術分享】Is Hajime botnet dead?

 

但該配置文件存在若干疑點:

在配置文件顯示的 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: <a