Jump to content
  • Entries

    16114
  • Comments

    7952
  • Views

    86369849

Contributors to this blog

  • HireHackking 16114

About this blog

Hacking techniques include penetration testing, network security, reverse cracking, malware analysis, vulnerability exploitation, encryption cracking, social engineering, etc., used to identify and fix security flaws in systems.

Implant.ARM.iLOBleed.a惡意軟件分析在本節中,我們將對HP iLO 固件中發現的植入程序進行技術分析。

當我們的安全分析團隊發現惡意軟件時,攻擊者決定擦除服務器的磁盤並完全隱藏他們的踪跡。有趣的是,攻擊者並會不斷擦除痕跡,他們將惡意軟件設置為每隔一段時間重複執行數據擦除。也許他們認為,如果系統管理員重新安裝操作系統,整個硬盤會在一段時間後再次被擦除。顯然,他們不認為他們的惡意軟件會被發現。

但與其他“wiper”惡意軟件不同,這不是一次性惡意軟件。它旨在長時間保持在雷達之下。此惡意軟件的重要功能之一是操縱iLO 固件升級例程,因此如果系統管理員嘗試將iLO 固件升級到新版本,惡意軟件會在阻止升級例程的同時模擬版本更改。為此,惡意軟件會假裝升級成功,並提供所有正確的消息和日誌。甚至固件版本的確切數量也被提取並顯示在Web 控制台和其他位置的適當位置,儘管實際上並未執行升級。

這就表明,該惡意軟件的目的是成為具有最大隱蔽性並躲避所有安全檢查的rootkit。一種惡意軟件,通過隱藏在最強大的處理資源之一(始終打開)中,能夠執行從攻擊者那裡收到的任何命令,而不會被檢測到。

很自然,執行的此類攻擊屬於APT 類別。但是,使用如此強大且成本高昂的惡意軟件來破壞數據,增加惡意軟件被檢測到的可能性的任務對於這些攻擊者來說似乎是一個明顯的錯誤。

iLO 轉儲實用程序檢查固件感染的第一步是準備一個副本或檢查所謂的固件轉儲。

不幸的是,HP沒有提供一個工具或方法來測試和讀取iLO固件。為此,編寫了一個固件轉儲工具被提上了日程,最終演變成了Padvish iLO Scanner工具,並演變為兩個版本:

從主機操作系統內部掃描:如前所述,iLO 固件可通過安裝在系統上的主處理器和操作系統作為PCI-Express 卡使用。 HP 為各種操作系統引入了一個名為flash_ilo 的工具,以允許將固件更新到較新的版本。但是,此工具只允許你寫入固件,而不允許你讀取現有固件。為此,基於在iLO 上獲得的知識,我們能夠開發一種工具來讀取固件並從中創建轉儲。

通過iLO網口進行掃描:由於通過主機操作系統進行掃描可能並不總是可行,而且網絡管理員可能很難在生產服務器上執行掃描,或者很難進行大量掃描,因此考慮了另一種掃描固件的方法。此版本的掃描器允許轉儲固件,方法是使用先前iLO 版本上的一些已知漏洞,使其能夠在易受攻擊的固件上遠程執行代碼。由於使用漏洞,該版本只能轉儲2.30到2.50範圍內的HP iLO4固件。

受感染的固件分析製作服務器固件副本後,應將其與原始固件版本進行比較。 Implant.ARM.iLOBleed.a 惡意軟件基於iLO 固件2.30 版。因此,該受感染版本與原始版本之間的差異如下圖所示。

7.png

固件簽名差異:(上)獲得的受感染轉儲,(下)惠普公司提供的原件

仔細觀察,還比較了文件系統級的兩個固件組件和模塊,如下表所示。

比較受感染系統固件模塊與原始版本的簽名8.png

如該表所示,在構成hpimage.bin 的所有模塊中,只有hpimage標頭文件和引導加載程序標頭文件兩部分是相同的。在其他部分中,簽名中的差異表明這兩個文件在這些部分之間存在差異。也可以看出,大部分變化都與ELF.bin模塊有關,而其他模塊只有2到12個字節的變化。

重啟後持久化任何類型的惡意軟件的開發人員擔心的一個問題是,在惡意軟件最初進入系統後,系統必須“保持”受感染狀態。

正如我們之前在“iLO 固件結構”一節中詳細介紹的,在iLO 啟動過程中,bootloader 模塊負責驗證操作系統內核的簽名,而係統的內核負責驗證用戶模式模塊的簽名。因此,如果攻擊者想要在iLO 固件上創建後門,除了插入後門(基本上在ELF.bin 文件中完成)之外,就必須在操作系統內核中禁用驗證機制,從而在引導加載程序中禁用驗證機制。

9.png

禁用操作系統內核和用戶模式模塊的驗證過程

上圖簡要描述了繞過操作系統內核和用戶模式模塊驗證過程的過程:攻擊者通過逆向工程提取bootloader.bin、kernel.bin 和ELF.bin 三個主要部分後,查找在引導加載程序和內核中執行簽名驗證和驗證操作的函數的地址,並將它們替換為NOP 命令。最後,將修改後的文件組合在一起形成一個完整的HP Image 文件,並作為新固件寫入SPI 閃存。重啟後,可以看到被感染的固件加載後門沒有任何問題。

惡意軟件模塊分析引導加載程序部分如表2 所示,Boot Loader 與原始固件相比更改了5 個字節。對這些字節的詳細分析表明,這種差異是由於負責驗證操作系統內核的功能發生了變化,並且正在通過替換NOP 命令禁用此過程。

10.png

禁用Bootloader 中的簽名驗證功能

內核部分如表2 所示,內核從原始固件更改了12 個字節。對這一變化的更詳細分析表明,這種差異是由於負責驗證UserLand 簽名並通過替換3 個NOP 命令禁用此過程的功能發生了變化。

11.png

禁用內核中的簽名驗證功能

UserLand 部分提取受感染固件的UserLand 部分並將其內容與原始版本進行比較,表明刪除了一個文件(sectionInfo)並添加了一個新模塊(稱為newELF,包含17 個單獨的部分)。此外,除了添加新的惡意軟件模塊外,原始版本中的許多模塊也發生了變化。

12.png

受感染系統硬件中的修改文件

在本節中,將該惡意軟件中原始版本的模塊與修改後的模塊進行比較,結果如下表所示。

帶有NewELF 的iLO 版本與原始版本的比較13.png

惡意軟件工件

Implant.ARM.iLOBleed.a 惡意軟件在iLO(也稱為NAND 閃存)的工作區存儲中創建3 個文件。這些文件的路徑甚至名稱似乎都可以通過配置器模塊進行配置。在我們獲得的惡意軟件樣本中,這三個文件分別命名為lifesignal.bin、schedule.bin 和fakefwdata.bin。

惡意軟件使用的三個文件14.png

如果系統管理員嘗試升級其服務器的固件版本,惡意軟件會在阻止和模擬固件升級操作以欺騙系統管理員的同時,在fakefwdata.bin 文件中輸入此操作的信息。

如其名稱所示,schedule.bin文件用於調度磁盤擦除操作。在這個文件中,存儲了兩個4字節的整數:一個計數器和一個日期紀元。前4個字節的數字(計數器)被設置為一個初始值,並在每次執行磁盤擦除過程時減少1。此操作按週期重複,直到計數器為零。第二個數字(日期)表示磁盤擦除進程的開始日期。

15.png

文件schedule.bin 的內容

“newELF”模塊內部這個模塊是一個完整的ELF,添加到Boottable的末尾,增加一個單元的進程數。此ELF 與此固件中的其他ELF 一樣,由幾個基本組件組成。第一部分是NewELF.ELF.Initial.text,與其他ELF 不同,它不是空的,並且包含代碼。仔細觀察會發現,該部分與ConAppCLI.ELF.text 非常相似,後者是iLO 硬件的主要模塊之一。表5 顯示了這兩個模塊之間的一般比較,顯示了它們的差異。這些相似之處表明Implant.ARM.iLOBleed.a 惡意軟件的基本結構是基於ConAppCLi 模塊的功能。

ConAppCLI.ELF.text 和NewELF.ELF.Initial.text 之間的比較

16.png

惡意軟件的另一個基本部分是NewELF.ELF.text,下圖顯示了該惡意軟件的主要功能。該函數的主要任務之一是設置一個確定惡意軟件操作主要參數的數據結構,其中一部分已如上圖所示。在該函數的開頭,schedule.bin文件的地址為複製到一個變量,指向這個地址的指針複製到數據結構的0x0c地址。

17.png

惡意軟件的主要函數

接下來,在另一個名為initOperationConfigFiles 的函數中,檢查惡意軟件所需文件的狀態。在這個函數中,首先創建lifesignal.bin文件,然後滿足以下條件:

如果schedule.bin 文件存在並且具有有效的結構,則其內容將被複製到數據結構的地址0 到0x07,並且值0x3 將寫入lifesignal.bin 文件。

如果相關地址中不存在schedule.bin 文件,則會創建並填充初始值。之後,數據結構就被完全填滿了。

如果schedule.bin 文件的結構無效,則會在lifesignal.bin 文件中寫入0x9。

18.png

惡意軟件運行參數的數據結構

如前所述,schedule.bin 文件由兩個4 字節的數字組成。在操作開始時,在initOperationConfigFiles 函數中,計數器編號設置為maxOperationCount(地址0x24 數據結構),日期編號設置為所需的時間和命令執行的日期。在惡意軟件的一個樣本中,重複操作的最大值設置為0x2,而在另一個樣本中設置為0x3e8(相當於1000 次)。

在檢查了執行擦除操作的適當條件後,該操作將在startPeriodicOperation 函數中開始。此函數在第一步中創建並填充具有最大操作長度的數據結構數組。這些數據結構中的每一個都使用不同的執行時間值進行評估。該設置使得惡意軟件在初始等待時間(例如36 小時)的基礎上增加了各種操作週期(例如12 小時)的倍數,並將該值記錄在每個數據結構的0x1C 地址處。在這種情況下,操作在從schedule.bin 文件中記錄的時間開始的等待時間(36 小時)之後開始,並在每個週期重複。最後調用startWipeOperation 函數,執行磁盤擦除操作。

19.png

startPeriodicOperation 的函數體

startWipeOperation 函數在循環中執行擦除操作,如下圖所示。在此循環開始時,名為GetAndValidateOperationParameters 的函數檢查操作參數的準確性併計算剩餘的操作數。實際上,在名為SuccessfulOperationCount 的變量中執行的操作數被提取並檢查,以便獲得的數不超過計數器的最大值。

20.png

startWipeOperation 的函數體

下一個函數是WaitForNextOperationTarget 函數,其內容如下圖所示。該函數的職責是在主循環中創建中斷,直到到達下一個操作時間。在指定的時間,此函數退出其循環,操作的主循環繼續操作。

21.png

WaitForNextOperationTarget 的函數體

在主循環的下一部分中,執行擦除磁盤操作並完全擦除服務器的硬盤。擦除操作完成後,schedule.bin 文件由DecrementOperationCount 函數更新,並減少一個計數器。 DecrementOperationCount 函數的主體如下圖所示。

22.png

DecrementOperationCount 的函數體

修改後的模塊分析該惡意軟件包含一些iLO 模塊的修改版本,其中一些模塊被修改以防止原始函數或以其他方式更改它。惡意軟件中有6 個修改後的模塊,如下所示:

惡意軟件修改模塊

23.png

總結固件安全近年來已經成為IT安全中的一個重要問題,但在實際應用中還沒有得到足夠的重視。由於HP iLO 管理工具具有的功能和高級別的訪問權限,它需要特殊的保護方法。不幸的是,由於缺乏工具和信息以及iLO 技術的專有性質,許多安全研究人員無法研究這些系統。更糟糕的是,儘管安全研究人員過去發表的研究已經證明了惡意軟件嵌入軟件的可能性,但仍然沒有公開可用的解決方案來檢測感染並在感染髮生時將其阻止。

另一個重點是,有一些方法可以通過網絡和主機操作系統訪問和感染iLO。這意味著即使iLO 網線完全斷開,仍然存在感染惡意軟件的可能。有趣的是,如果不需要iLO,則無法完全關閉或禁用iLO。

這些問題表明需要採取預防性安全措施來提高固件的安全性,例如更新到製造商提供的最新版本、更改管理員密碼以及將iLO 網絡與操作網絡隔離,最後,定期監測固件的安全參數和潛在感染狀態。

保護建議請勿將iLO 網絡接口連接到操作網絡並臨時搭建一個完全獨立的網絡;

定期將iLO 固件版本更新到HP 的最新官方版本;

在HP服務器上執行iLO安全設置,並禁用G10 服務器的降級;

使用縱深防禦策略降低風險並在到達iLO 之前檢測潛在的攻擊;

定期使用iLO Scanner 工具檢測當前版本的iLO 服務器固件中的潛在漏洞、惡意軟件和後門