TRex 嘶吼專業版 git
本文描述了一個在咱們的SSH蜜罐中發現的後門,它生成了一個徹底加密和完整性檢查的反向shell,並在蒙特利爾的GoSec 2017上展現過。咱們將該後門命名爲Chaos,與***者在系統中給出的名稱一致。通過進一步研究,咱們發現該後門是2013年左右活躍的sebd rootkit的一部分。github
由於沒法找到任何關於此後門技術細節的文檔,咱們決定本身來!算法
今年夏天,咱們有一個項目是在FreeBSD系統中尋找惡意軟件,或者至少評估是否存在。爲此,咱們使用了FreeBSD jails,它被描述爲「chroot on steroids」。咱們的想法是僅使用jails來模擬Intranet結構,這是可行的,由於jails能夠在主機上本身分配IP地址。而後,***者會***暴露於互聯網的jails,並從那裏通往其餘jails。不幸的是,沒有人能作得這麼多,由於典型的***者在乎識到他們碰見FreeBSD系統時會當即離開。腳本化的機器人設法上傳了payload,但若是沒有Linux,ELF文件將沒法運行,這樣就發揮不了做用。在這一點上,咱們能夠說FreeBSD是一種減小***面很是好的方法,由於沒有***者想要面對FreeBSD。固然,若是你已經被黑了的話,此建議無效。shell
當咱們放棄尋找BSD惡意軟件時,咱們決定尋找Linux惡意軟件。在蜜罐運行幾分鐘後,咱們獲取到了一些。以後,又獲取了一些不一樣於Gafgyt(LizardSquad)和Mirai的東西。服務器
2017年6月21日,***者使用兩個已知屬於TOR網絡的IP暴力窮盡SSH憑證攻破了咱們的一個受監控系統:89.234.157.254 與192.42.116.16。markdown
像往常同樣,***者首先禁用了日誌記錄,而後檢查SSHD二進制文件以及某些特定文件,例如/usr/include/gpm2.h。這樣作的目的是確保被攻陷的機器還沒有被其餘人感染。***者檢查的文件一般用於給SSHD漏洞(記錄盜取的SSH憑證)打補丁。以後,***者經過下載並安裝payload來感染。網絡
在第二階段,***者從http://xxx.xxx.xxx.29/cs/default2.jpg下載了一個假裝成jpg的文件。 事實上,該文件是一個.tar文件,.jpg擴展名是爲了使它在可能的日誌文件或抓取的數據包中看起來更合理。tar包含:ide
一、Chaos (ELF 可執行文件)
二、Client (ELF 可執行文件)
三、initrunlevels (Shell腳本)
四、install (Shell腳本)編碼
tar中的Chaos是安裝在受害者系統上的實際後門,Client文件是鏈接到後門的客戶端。有關這兩個ELF文件的更多細節將在下面討論,咱們先來看看兩個shell腳本initrunlevels與install。install腳本將initrunlevels腳本複製到/etc/init.d,以確保該文件在系統每次啓動時都被執行。加密
initrunlevels: 持久性腳本
如上所示,initrunlevels腳本打開8338號端口並檢查是否存在某些特定文件。若是不存在,則腳本將這些不顯眼的文件複製到它檢查的路徑中。接下來,該腳本將client複製到/usr/include/cli.h中,並複製Chaos到/usr/include/stabd.h和/usr/sbin/smdb中。 這是爲系統上的client和Chaos建立備份。***者還釋放並執行了其餘文件,以使該系統成爲IRC僵屍網絡的一部分,在本文中咱們僅調查後門。
如上所述,***者釋放了兩個文件:Chaos和Client。Chaos是啓用反向shell的後門,Client啓動Chaos的鏈接。
口令檢查後鏈接返回
後門的工做原理以下:首先Chaos打開一個原始的TCP套接字,檢查傳入的數據包是否包含特定的字符串。因爲這是一個原始套接字,任何傳入打開端口的數據包都將被讀取和檢查。若是Chaos檢測到字符串,則它將鏈接TCP端口8338上監聽的Client。在鏈接Client後,Client和Chaos交換密鑰材料,從中派生出兩個AES密鑰。他們繼續使用挑戰—應答身份驗證檢查密鑰協商是否成功,以下所示。
Chaos的身份驗證和密鑰交換
有趣的是,雙方都有相同的兩個密鑰,用於發送和接收。加密後的口令居然是硬編碼的,咱們設法破解並以純文本形式獲取口令。口令在不一樣的感染系統中重複使用。後門能夠規避防火牆。事實上,任何正常的防火牆都會阻止傳入的數據包進入任何沒有明確目的而打開的端口。可是,對於使用原始套接字的Chaos,能夠在運行現有合法服務的端口上觸發後門。 做爲一個例子,只暴露SSH(22),HTTP(80)和HTTPS(443)的Web服務器因爲服務佔用而沒法經過傳統的後門進入,可是隨着Chaos的出現,這變得可能。此外,除非顯式指定-w標誌,不然經過netstat不能顯示原始套接字。
Client從Chaos創建鏈接後,它會向Chaos發送一個40長的字符串。該字符串做爲預共享密鑰並按照如下方式生成:
如圖所示,預共享密鑰由兩個塊組成,每塊用於生成兩個密鑰中的一個。密鑰從塊中派生,以下所示:
請注意,這些密鑰用於長度爲128的CBC模式下的AES,這意味着SHA1的一部分將被丟棄。爲確保加密數據包的完整性,生成兩個Hash在HMAC中使用。
在 IDA中, 咱們能夠清晰地看到AES的CBC 模式:
加密循環
注意到它沒有犯重複使用IV的常見錯誤。密鑰派生過程與Chaos二進制的工做方式相同,除了塊交換。
交換過程當中的數據包格式以下:
正如咱們所看到的,前兩個字節決定payload的長度。size字段和payload均已加密。爲標記payload的結束,使用了三個連續的空字節。在分隔符以後,seq字段用於計數並保持數據包的順序。最後一個字段是確保數據包完整性的HMAC。
每一個通訊數據包不只被加密,並且使用HMAC檢查完整性。HMAC以下生成:
內部值是Constant1上的Hash,與size字段,加密的payload,分隔符和序列號鏈接。 外部Hash經過Constant2和內部Hash生成。
如前所述,這個後門在2013年首次出現,是sebd rootkit的一部分。咱們在hackforums.net上發現了一個帖子,用戶聲稱知道後門是如何公開發布的。聽說後門的源代碼已經被另外一個蜜罐捕獲,「研究人員」不合常理的在這個論壇上發佈了源代碼,使其可被腳本小子使用。
***者只是簡單地改變了後門的名字,讓人們認爲這是一種新的,而其實是竊取的。
爲評估感染數量,咱們使用從客戶端提取的握手進行了全網掃描。受害系統的數量很是少,低於150個。如下是受害者的地理分佈:
咱們聯繫了CCIRC,列出了受害系統的IP地址,由他們繼續通知CERT合做夥伴和受害者。
Chaos後門很是有趣,由於它使用隱形原始套接字來產生具備完整網絡加密和完整性檢查的反向Shell。 可是,若是預共享密鑰已知,後門的加密算法很容易破解,由於它是以明文形式傳輸的。
有趣的是:因爲***者爲傳入的數據包打開了8338端口,因此***人員顯然但願在受感染的計算機上使用Client文件。他們會使用受感染的機器做爲進一步犯罪的代理,這樣就可能能夠跨越網絡邊界。
據Virustotal稱,儘管後門已經存在好幾年了,但沒有防病毒軟件檢測到這個後門。
在下一篇博客中,咱們將描述使受害系統成爲IRC僵屍網絡的其餘惡意軟件。
有關此威脅的最新IoC信息,請參閱咱們的malware-ioc github repository.
文件hashes
Chaos: 0a27b0579702888c3399c6b853acf986beae2a4e
Client: 7f5d3bb5079f9bf077832301615fa6e2e072c4e8
文件系統
警告:下面記錄的文件系統組件也是合法的系統文件。在作出結論以前,你須要仔細調查一下。
該組織在/usr/sbin/smdb中安裝後門,並將其備份爲/usr/include/stabd.h。
/usr/sbin/smdb 是合法的,Samba套件的一部分。爲兼容Windows(如文件共享或集成Active Directory)安裝Samba。/usr/include/stabd.h是合法的,glibc頭文件的一部分,一個純文本文件,當惡意時它是一個二進制文件。
能夠手動檢查文件或運行咱們的Yara規則:
yara sedb_chaos.yar /usr/sbin/smdb
yara sedb_chaos.yar /usr/include/stabd.h
系統調查/etc/init.d/runlevels是一個惡意腳本,它將打開防火牆上的端口並執行後門程序。這是惡意軟件的持久性機制。
在普通的Linux服務器上監聽原始套接字是很是罕見的事情。以root身份運行如下命令來檢查系統:
netstat -lwp
它會列出打開監聽原始套接字的進程。而後,能夠調查進程以評估它是否合法。 若是不知道它是什麼,那麼多是不合法的,由於監聽原始套接字不多見。