Jump to content
  • Entries

    16114
  • Comments

    7952
  • Views

    86398724

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.

研究人員最近發現了一些惡意的Microsoft Office文件,這些文件試圖利用合法網站MediaFire和Blogger執行shell腳本,然後釋放Agent Tesla和njRat的兩個惡意變體。 Agent Tesla是一款著名的監視軟件,首次發現於2014年,它可以從web瀏覽器、郵件客戶端和FTP服務器中竊取個人數據,收集屏幕截圖和視頻,並收集剪貼板數據。 njRat(也稱為Bladabindi)是2013年首次發現的遠程代理木馬,能夠遠程控制受害者的設備,記錄擊鍵、訪問攝像頭、竊取瀏覽器中存儲的憑據、上傳/下載文件、操作註冊表等。

马云惹不起马云受影響的平台:Microsoft Windows

马云惹不起马云受影響方:Windows用戶

马云惹不起马云影響:控制和收集受害者設備中的敏感信息

马云惹不起马云 嚴重級別:嚴重

在本文中,我們將詳細介紹我們發現的文件、它們用於傳播有效負載的嵌入腳本,以及這些惡意軟件變體的行為。

第1階段在2022年9月,研究人員發現了兩種文件。一個是PowerPoint加載項,另一個是包含誘餌圖片和嵌入Excel表單的Word文件。這兩個文件都包含類似的VBA腳本,在打開文件後立即執行宏。

1.png

根據PPT插件中的VBA腳本(如上圖所示),代碼會自動觸發,因為它使用了“Auto_Open()”函數。其“ControlTipText”和“Tag”字段包含完整的命令“mshta”和MediaFire URL。我們可以在“vbaProject.bin”中看到完整的URL。

2.png

PPT加載項中的VBA宏

3.png

vbaProject.bin文件中完整的惡意URL

第2階段從下圖所示的Process Explorer中可以看到,“mshta”進程在點擊文件中的“Enable Macros”後立即啟動。這導致了MediaFire網站,這是一個合法的文件和圖片共享平台。

4.png

點擊“Enable Macros”後的Process Explorer

以下是第一階段VBA宏中“1.htm”的內容:

5.png

從MediaFire下載的“1.htm”

下圖顯示了將一些十六進製字符串轉換為ascii字符串後的更清晰的圖片。

6.png

轉換後的“1.htm”

這個HTML文件有三個主要任務:

1.從MediaFire網站傳送第三階段腳本文件;

2.終止任務WINWORD.EXE;

3.通過創建計劃任務添加持久性。它使用“mshta”連接到“http[:]//www.webclientservices.co[.]uk/p/1[.]html”網站,該網站每73分鐘包含一個類似的腳本。以下是2022年9月的博客截圖:

7.png

9月中旬www[.webclientservices[.co[.uk/p/1[.html]網頁

研究人員還發現,“www[.]webclientservices[.]co[.]uk”中的1.html文件已更新並重命名為“real all BACK SEP 2022”。嵌入式JavaScript也被修改了,現在可以發布其他惡意軟件。

8.png

9月底發現的www[.]webclientservices[.]co[.]uk/p/1[.]html更新頁面

第3階段“1.txt”中的PowerShell腳本是從MediaFire下載的,它通過進程空心化技術提供最終有效負載。它首先終止所有相關進程,並對加載程序和有效負載進行解碼。然後它調用最終有效載荷並部署它,繞過AMSI。主要惡意軟件和部分代碼被編碼並替換為字符串,以增加分析的難度。

9.png

用於加載代理特斯拉的PowerShell的全圖

10.png

執行PowerShell後的Process Explorer

在“Load Agent Tesla Payload”過程的第二部分中,變量$CLE11和$RNBX1是更換一些字符串後的最終有效負載和加載器。基於.NET的不同版本,它自定義了繼續進行進程空心化活動的路徑:

$Path='C:\Windows\Microsoft.NET\Framework\v4.0.30319\jsc.exe'

$Path2='C:\Windows\Microsoft.NET\Framework\v2.0.50727\caspol.exe'

$Path3='C:\Windows\Microsoft.NET\Framework\v3.5\Msbuild.exe

[Ref]/Assembly:Load((HexaToByte($RNBX1))).GetType('CALC'.PAYSIAS'.'GetMethod'(Execute).Invoke($null,[object[]] ($Path, HexaToByte($CLE11)));

研究人員將$RNBX1保存為可執行文件,並用dnSpy打開它。目標類和方法如下圖所示。此.Net加載器利用一些模糊處理來隱藏主要API(CreateProcess、VirtualAllocEx…等)。

11.png

Net Loader

研究人員找到了目標進程“jsc.ex”、“caspol.exe”和“Msbuild.exe”,它們在受害者的設備中安靜運行。詳細信息如下圖所示。

12.png

流程空心化時的Process Explorer

在PowerShell部分的末尾,它禁用了日誌記錄,並通過打補丁繞過AMSI。詳細步驟如下所示。

13.png

繞過PowerShell中的AMSI

最後階段(第一部分)第一個惡意軟件負載是Agent Tesla。這種變體在9月中旬開始傳播。它包括合法的文件信息,“NirSoft”公司的“Web瀏覽器密碼查看器”,並使用FTP發送被盜數據。

14.png

Agent Tesla的基本信息

下圖是用於傳輸提取數據的攻擊者FTP服務器信息的屏幕截圖,包括用戶名和密碼。此變體還將自身複製到%appdata%目錄中,文件名為“NGCwje.exe”以進行持久化。

15.png

攻擊者的服務器信息

然後,它開始提取受害者設備的信息,例如基板的序列號、處理器ID和MAC地址。然後,它為該數據生成一個MD5哈希。

16.png

為受害設備的信息生成Md5哈希

Agent Tesla使用一個典型的應用程序列表來竊取登錄憑據、Cookie、郵件信息和VPN數據。這些項目的一部分如下圖所示:

17.png

目標瀏覽器應用程序列表

一旦惡意軟件從受害者的設備檢索到憑證和其他信息,它通過使用硬編碼IP的FTP協議發送這些數據。

18.png

使用FTP協議

19.png

從受害者設備捕獲的流量

根據遇到的不同類型的文件,它使用四種打開字符串:“CO”表示cookie數據,“KL”表示鍵盤記錄,“PW”表示受害者的密碼信息,“SC”表示屏幕截圖文件。惡意軟件使用下劃線將數據類型、用戶名、設備名稱和時間戳連接在一起,作為數據ZIP文件的文件名。被盜zip文件列表如下所示:

20.png

FTP服務器上Zip文件的部分列表

最後階段(第二部分)第二個有效載荷是njRat,也稱為Bladabindi。它是一個.NET特洛伊木馬,用於控制和監控受害者的設備。此變體對其字符串生成和代碼流使用模糊處理。從方法ko()的IDA圖形概覽中,你可以看到這個變體更複雜,但你仍然可以識別類似的函數。

21.png

IDA圖概述

22.png

njRat的入口點

23.png

字符串解碼功能

首先,它在“Startup”和“Templates”文件夾中創建lnk和exe文件,文件名為“Windows”。這個名字用來欺騙用戶和分析師,讓他們認為它是合法的Windows文件。

24.png

創建持久性

然後,它以相反的順序獲取命令和控制服務器主機名和端口號。

25.png

命令和控制服務器信息

為了確保此惡意軟件只在此受害者上運行一次,它添加了名為“di”、數據為“!”的“HKEY_CURRENT_USER”。

26.png

添加到“HKEY_CURRENT_USER”中的註冊表

27.png

註冊表狀態

它還創建了一個帶有字符串“Windows”的互斥鎖,將環境變量“SEE_MASK_NOZONECHECKS”設置為1,並檢查此互斥鎖是否以前創建過。如果是,則結束該過程。

28.png

創建互斥鎖

29.png

設置環境變量

如下圖所示,收集設備信息後,它使用base64對其進行編碼並連接數據。然後,它使用硬編碼的TCP端口7575將數據傳輸到服務器“mobnew6565[.]duckdns[.]org”。

30.png

連接數據

以下是Win10受害者設備的C2流量。分隔符更改為“|-F-|”,版本為“v4.0”,但數據包的格式類似於舊的njRat版本:

31.png

從受害者處捕獲的流量

除了Agent Tesla和njRat,研究人員還在更新的HTML文件“www.webclientservices.co[.]uk/p/1[.]HTML”中找到了一個簡短的腳本,該文件將挖礦軟件下載到“C:\\ProgramData”。這是一種奇怪的行為,因為此攻擊鏈中的每個步驟都試圖在受害者的設備上不留下任何物理跟踪或文件。研究人員認為這可能會分散受害者的注意力,以免他們注意到另一個進程正在加載njRat。

32.png

下載挖礦軟件的JavaScript

33.png

njRat和miner的Process Explorer視圖

總結Agent Tesla和njRat多年來都是高度活躍的惡意軟件。它們的功能成熟,易於用於監視或竊取信息。如上所述,惡意URL不斷更新其嵌入的JavaScript,這意味著這些釣魚電子郵件和誘騙辦公室文件始終是傳播此惡意軟件的有效方式。網站中嵌入的所有VBA宏、PowerShell和JavaScript代碼都可以部署無文件攻擊,也可以通過混淆或編碼字符串來逃避一些病毒檢測。

用戶應始終警惕任何包含外部網站鏈接的辦公室文件或未知文件。

34.png

攻擊流程

Thumbnail_Kopeechka_Medium.webp.jpg

近年來,攻擊者變得越來越專業,他們鑽研技能,以求犯更少的關鍵錯誤,並創建了各種即插即用業務,幫助低技能的攻擊者發起詐騙和攻擊。

目前存在不同類型的攻擊服務,包括惡意軟件即服務,攻擊者開發並向其他攻擊者出售惡意軟件服務,該服務還包括在被攻擊的主機上創建和傳播勒索軟件等惡意軟件類型。同時,其他服務需要使用多個社交媒體帳戶才能成功進行,例如虛假信息、垃圾郵件和惡意軟件傳播。

事實上,攻擊者在社交媒體平台上使用數千個賬戶發送數千條垃圾郵件並不罕見。但是他們是如何做到自動化的呢?

最近,Kopeechka服務出現,促進了依賴大規模社交媒體垃圾郵件的攻擊活動。在俄語中,“kopeechka”的意思是“便士”。

該服務自2019年初以來一直活躍,為流行的社交媒體平台提供簡單的賬戶註冊服務,包括Instagram、Telegram、Facebook和X(以前的Twitter)。我們還注意到,針對未成年人的聊天網站可以通過Kopeechka進行註冊。

本文介紹了Kopeechka服務,並對該服務的特性和功能進行了詳細的技術分析,以及它如何幫助攻擊者實現其目標。

社交媒體平台如何確保賬戶創建過程的安全大多數社交媒體平台都採取了積極措施來加強賬戶創建的安全性。由於許多攻擊者在社交媒體平台上創建賬戶用於非法活動,社交媒體公司為了將攻擊者在其平台上的風險降至最低,故選擇從賬戶創建過程開始。

有不同的安全措施來保護平台,防止欺詐賬戶的創建,例如:

1.電子郵件地址驗證。註冊時,用戶需要證明所提供的電子郵件地址是否存在,這通常是通過代碼確認完成的,其中用戶通過電子郵件接收唯一的URL或代碼。一旦他們選擇這個鏈接或輸入代碼,他們的帳戶就會被驗證。

2.電話號碼驗證。這裡的目標是迫使用戶提供一個可以由社交媒體平台驗證的真實電話號碼,通常是通過發送一條帶有用戶需要在平台上輸入的代碼的文本消息。

3.驗證碼保護。儘管存在不同類型的captcha,但目標始終是相同的:驗證用戶是真人而不是機器人。通常情況下,用戶需要回答自動解決程序無法回答的問題。

4.IP地址信譽。這裡的目標是確定用戶的IP地址是否乾淨,並且不是來自代理、虛擬專用網絡(VPN)或任何其他匿名解決方案。

根據目標社交平台的不同,攻擊者需要唯一的電子郵件地址、唯一的電話號碼和無可疑的IP地址才能成功創建自己的賬戶。

雖然一些社交媒體平台使用驗證碼來阻止自動註冊,但這並沒有給攻擊者帶來很大的障礙,因為現在存在不同的服務,允許攻擊者以自動方式繞過驗證碼。 IP地址檢查服務也是如此,因為攻擊者可以使用住宅代理繞過這些措施。

因此,攻擊者可以使用自動腳本繞過驗證碼和IP地址信譽檢查工具。但是,他們仍然需要一個有效的電子郵件,可能還需要為他們想要創建的每個帳戶提供一個電話號碼,這就需要用到Kopeechka了。

Kopeechka運行過程Kopeechka不提供電子郵件收件箱的訪問權限,但它可以訪問從社交媒體平台收到的電子郵件。該服務的設計使郵箱帳戶仍然由Kopeechka控制,而不是由任何第三方用戶控制。

Kopeechka提供兩種不同類型的電子郵件:使用自己域名的電子郵件地址,以及託管在更受歡迎的電子郵件託管服務上的電子郵件地址。

Kopeechka表示它當前庫存的有效電子郵件數量,如表1所示:

1.jpg

截至2023年5月底,Kopeechka庫存的有效電子郵件地址數量

目前,這些電子郵件地址要么是由Kopeechka使用者自己創建的,要么可能是被攻擊的電子郵件收件箱。 Kopeechka還購買電子郵件帳戶,如下圖所示:

2.png

Kopeechka購買電子郵件地址可能用於非法用途

在撰寫本文時,該服務還提供了託管在其擁有的39個域名中的幾個電子郵件地址。

3.png

Kopeechka的電子郵件域名

Kopeechka(圖2)與流行域名(表1)的定價不同,後者比前者更昂貴(在撰寫本文時,Kopeechka域名的成本為0.05盧布或0.0005美元,一些流行域名的成本高達盧布1或0.01美元)。

Kopeechka是如何工作的? Kopeechka為其客戶提供web界面和API 4.png

Kopeechka的網絡界面,如Kopeechka的宣傳視頻所示

如上圖所示,web界面允許用戶使用購買的電子郵件地址輕鬆創建社交媒體帳戶,而API使用戶更容易自動創建多個社交媒體帳戶。

對於Kopeechka目前還無法搜索的社交媒體平台,用戶可以使用Kopeechka的API。

5.jpg

用戶如何通過使用Kopeechka API在新的社交媒體平台上獲得一個有效的帳戶

下載所有這些過程都可以完全自動化,這可以讓攻擊者在幾秒鐘內創建數百個甚至更多的賬戶,只要他們的Kopeechka賬戶裡有足夠的錢。

無法訪問實際的郵箱Kopeechka實際上不提供訪問實際郵箱的權限。當用戶請求郵箱創建社交媒體帳戶時,他們只能獲得電子郵件地址參考和包含確認碼或URL的特定電子郵件。這對於Kopeechka服務至關重要,因為它允許Kopeechka使用者使用一個電子郵件地址在不同的社交媒體平台上進行多次註冊,如下圖所示:

6.jpg

在不同的社交媒體平台上多個用戶可以使用一個唯一的電子郵件地址創建賬戶

短信的作用某些社交媒體平台還包括一個帳戶驗證步驟,需要一個電話號碼,他們將使用該電話號碼發送包含唯一代碼的短信,用戶需要在平台上輸入代碼才能成功註冊。

為了解決這個問題,Kopeechka允許用戶從16種不同的在線短信服務中進行選擇。與它的所有服務一樣,Kopeechka提供了視頻教程,以及每種服務的描述及其工作原理。

7.png

Kopeechka與16種不同的在線短信服務合作

Kopeechka的市場營銷和客戶服務除了宣傳其服務外,Kopeechka還通過不斷與用戶溝通和提供服務發生的任何事情(包括網絡問題和bug通知)的透明度來培養客戶忠誠度。 Kopeechka提供提示,完整的教程,甚至補償它的客戶。

Kopeechka使用者與他們的客戶就最近修復的漏洞進行了溝通,並為客戶的損失提供了賠償。

8.png

總而言之,Kopeechka似乎在處理客戶溝通方面採取了專業的方法,它使用了一種名為Bitrix24的客戶關係管理(CRM)工具來滿足其銷售、營銷和項目管理需求。 Kopeechka使用該軟件的原因可能是,Bitrix24每個客戶使用了一個子域,我們發現了一個現有的“kopeechkstore . Bitrix24 .ru”子域,該子域至少自2019年以來一直活躍。

Kopeechka還提供在線視頻、常見問題解答(FAQ)和描述該服務如何工作的專用頁面。客戶可以在該平台的客戶培訓中心這裡測試自己的賬戶創建和日誌記錄技能這讓用戶可以免費試用這項服務。

9.png

培訓中心主頁的英文截圖

Kopeechka還提供了一個正則表達式測試平台,它可以更好地匹配電子郵件中的文本,以防用戶訂閱特殊的服務。

與其他俄羅斯在線服務合作對於那些想要自動化賬戶註冊過程,但又不熟練使用API的用戶,Kopeechka鼓勵他們使用第三方俄羅斯服務ZennoPoster,該服務自2011年以來一直很活躍。

10.png

Kopeechka鼓勵用戶使用ZennoLab,並將給他們5%的退款,ZennoPoster是ZennoLab的產品。

ZennoPoster允許用戶通過像腳本一樣在瀏覽器上執行多次操作來自動執行瀏覽器操作,Kopeechka用戶可以使用ZennoPoster作為自動註冊系統。

11.png

ZennoPoster工具用於自動瀏覽操作的屏幕截圖

幾個在線話題解釋瞭如何使用ZennoPoster和Kopeechka在不同的社交媒體平台上註冊帳戶,其中一個示例是使用ZennoPoster和Kopeechka在俄羅斯約會網站“mylove.ru”上創建一個帳戶。

12.png

Kopeechka提供了使用ZennoPoster註冊mylove.ru帳戶的支持

ZennoPoster的開發者ZennoLab銷售數十種與社交媒體平台和其他在線網站互動相關的自動化任務。其中一個自動化任務是X(以前的Twitter)的腳本,它將通過X帳戶並向其所有關注者發送消息。因此,這個帳戶可以用來發送垃圾郵件。

13.png

ZennoLab還提供其他可能被攻擊者濫用的產品

ZennoLab也有CAPTCHA識別和代理搜索或檢查服務。

值得注意的是,Kopeechka鼓勵用戶使用ruCaptcha驗證碼解決服務,並提供5%的退款。

14.png

Kopeechka通過提供5%的退款來推廣RuCaptcha服務

Kopeechka還為開發者和用戶提供了一個協作計劃。雖然在軟件中使用Kopeechka API的開發者可以獲得銷售額的10%,但通過附屬鏈接說服更多人使用Kopeechka的用戶可以獲得每個新用戶在Kopeechka上消費金額的10%。

上傳二手郵件的用戶也將獲得郵件銷售額的一定提成。

15.png

Kopeechka的附屬項目

Kopeechka在地下論壇的活動在地下論壇宣傳這項服務自2019年2月成立以來,Kopeechka一直在宣傳自己的服務,每次更新後,Kopeechka都會定期更新其在攻擊者論壇上的廣告線索。

16.png

攻擊論壇上Kopeechka更新的帖子

目前,Kopeechka的俄語Telegram頻道有大約1000名訂戶,英語Telegram頻道有440名訂戶。

尋找漏洞除了在攻擊者的地下論壇上做廣告外,Koppechka的使用者似乎也對尋找漏洞很感興趣。可以在不同的論壇上看到很多使用Kopeechka這個名字的人,他們對利用漏洞進行攻擊很感興趣。在許多論壇上,攻擊者只與那些回復相關主題的人分享內容,這使得識別Kopeechka使用者感興趣的內容變得容易。此外,Kopeechka使用者有時也會就這些論壇上宣傳的產品或服務提出問題。

2022年6月,一名用戶在論壇上發布了一則廣告,介紹了一個據稱可以繞過Gmail的漏洞。一位名為kopeechka的用戶在2023年3月回復了關於這個漏洞的問題,並詢問它是否仍然是最新的。

在另一個論壇上,一位名叫Kopeechka的用戶回復了關於如何破解包括Spotify、Netflix、Steam在內的社交媒體賬戶的帖子,以及關於使用Black Bullet和一款名為OpenBullet的免費網絡測試軟件的帖子。

2020年,Kopeechka使用者還在一個論壇上發帖,請求幫助製作“一批不廣泛使用的文件,其保護與文憑大致相同”。雖然不知道他們想要提供什麼樣的文件,但這個請求很可疑,因為它背後的目的可能是提交虛假文件,以滿足各種服務提供商或管理部門的要求。

Kopeechka的用途Kopeechka幾乎可以用於任何需要處理帳戶註冊的服務。

在調查最近的一次大規模加密貨幣騙局時,我們報告了對Mastodon社交網絡的濫用,突然發現數百個新賬戶被創建,向Mastodon用戶推廣虛假加密貨幣網站。 Brian Krebs在今年早些時候討論了Kopeechka服務是如何被用來大規模註冊Mastodon賬戶的。

Mastodon是一個免費的開源社交網絡程序,一個商業平台的替代方案,避免了單個公司壟斷你溝通的風險。選擇你信任的服務器,無論選擇的是哪個,你都可以與其他人進行互動。

機器人還使用Kopeechka來輕鬆創建帳戶。目前已經可以看到通過Kopeechka API創建社交媒體帳戶的代碼,包括Discord, Telegram和Roblox帳戶的腳本。

17.png

在線提供一個Discord帳戶生成器代碼

18.png

Kopeechka上的一個自動kick.com帳戶生成器

19.png

一名攻擊者以每月50美元的價格出售在Kopeechka創建的Reddit賬戶

20.png

出售使用Kopeechka創建的coinmarketcap(加密貨幣市場網站)賬戶,售價150美元

此外,發現的可用於創建VirusTotal帳戶的Python腳本,表明一些用戶可能會註冊這些帳戶以測試惡意軟件檢測。

根據觀察,Kopeechka越來越受攻擊歡迎,在其上面買賣更有保障。

官方的Kopeechka API本身是大規模提供的,允許它集成到任何類型的代碼中。它存在於大多數開發人員的平台上,包括Python包索引(PyPI)、NuGet、GitHub和npm。

總結Kopeechka的服務可以提供一種簡單而實惠的方式來大規模創建在線賬戶,這對攻擊者很有幫助。 Kopeechka的客戶使用這項服務可以輕鬆創建大量賬戶,而無需短信和電子郵件驗證。

雖然Kopeechka主要用於創建多個賬戶,但攻擊者也可以使用它來為自己的活動增加一定程度的匿名性,因為他們不需要使用自己的電子郵件地址在社交媒體平台上創建賬戶。

為此,只有電子郵件服務提供商共同協作,加強他們的註冊流程,才能解決Kopeechka問題。不過,這一努力可能通過人工智能來實現,人工智能可以提供檢測自動賬戶註冊的方法。

本文將介紹Earth Preta APT組織利用的最新工具、技術和程序(TTP)的更多技術細節。介紹在2022年11月,趨勢科技的研究人員就披露了由高級持續性威脅(APT)組織Earth Preta(也稱為Mustang Panda)發起的大規模網絡釣魚活動。該活動通過魚叉式網絡釣魚電子郵件針對亞太地區的多個國家。自2023年初以來,該組織正在使用新的方法,例如MIROGO和QMAGENT。

此外,研究人員還新發現了一個名為TONEDROP的釋放程序,它可以釋放TONEINS和TONESHELL惡意軟件,根據觀察,該組織正在將其目標擴展到不同的地區,如東歐和西亞,再加上亞太地區的幾個國家,如緬甸和日本。

通過追踪分析惡意軟件和下載網站,研究人員試圖找到攻擊者用來繞過不同安全解決方案的工具和技術。例如,研究人員收集了部署在惡意下載網站上的腳本,這使他們能夠弄清楚它們的工作原理。研究人員還觀察到,Earth Preta向不同的受害者提供不同的有效負載。

受害者研究從2023年1月開始,研究人員就觀察到幾波針對不同地區個人的魚叉式網絡釣魚電子郵件。

1.jpg

魚叉式網絡釣魚郵件收件人的國家分佈

研究人員還能根據目標行業對受害者進行細分。如下圖所示,大多數目標自電信行業。

2.png

魚叉式網絡釣魚郵件收件人的行業分佈

2023年,研究人員使用了新的攻擊指標監測了Earth Preta,包括MIROGO、QMAGENT和名為TONEDROP的新TONESHELL釋放程序。

同樣,這些攻擊鏈也發生了變化。例如,除了部署合法的Google Drive下載鏈接外,攻擊者還使用其他類似但實際上不是Google Drive頁面的下載網站。

3.jpg

2023年的事件時間線

Backdoor.Win32.QMAGENT2023年1月左右,研究人員發現QMAGENT惡意軟件通過魚叉式網絡釣魚電子郵件傳播,目標是與政府組織有關的個人。 QMAGENT(也稱為MQsTTang)最初是在ESET的一份報告中披露,值得注意的是,它利用了物聯網(IoT)設備中常用的MQTT協議來傳輸數據和命令。由於上述報告詳細描述了惡意軟件的技術細節,我們在此不再贅述。然而,研究人員認為所使用的協議值得進一步調查。

Backdoor.Win32.MIROGO2023年2月,研究人員發現了另一個用Golang編寫的名為MIROGO的後門,Check Point Research首次將其報告為TinyNote惡意軟件。研究人員注意到,它是通過一封嵌入Google Drive鏈接的釣魚電子郵件發送的,然後下載了一個名為Note-2.7z的壓縮文件。該壓縮文件受密碼保護,密碼在電子郵件正文中提供。提取後,研究人員發現了一個偽裝成發給政府的可執行文件。

4.png

MIROGO攻擊流程

Trojan.Win32.TONEDROP2023年3月,研究人員發現了一個名為TONEDROP的新釋放程序,它可以釋放TONEINS和TONESHELL惡意軟件。它的攻擊鏈與之前報告中介紹的相似,涉及隱藏被異或的惡意二進製文件的虛假文件。

在接下來的幾個月裡,研究人員發現該組織還在使用這個釋放程序。在研究人員的調查過程中,他們發現了TONESHELL後門的一個新變體。

5.png

釋放程序流程

6.png

TONEDROP中的文件

在釋放和安裝文件之前,TONEDROP將檢查文件夾C:\ProgramData\LuaJIT是否存在,以確定環境是否已經被破壞。它還將檢查正在運行的進程和窗口是否與惡意軟件分析工具有關。如果是這樣,它將不會繼續其例行程序。

7.png

檢查正在運行的進程和窗口

如果所有條件都滿足了,它將開始安裝過程並釋放幾個文件。這些文件嵌入到釋放程序中,並使用異或密鑰解密。

8.png

釋放的文件和用於解密它們的異或密鑰

被釋放後,WaveeditNero.exe將側載waveedit.dll並解密其他兩個偽造的PDF文件:

它用XOR密鑰0x36解密C:\users\public\last.pdf,並將其寫入C:\users\public \documents\WinDbg(X64).exe。

它用XOR密鑰0x2D解密C:\users\public\update.pdf,並將其寫入C:\users\public\documents\ libvcl .dll。

TONEDROP將為進程C:\users\public\documents\WinDbg(X64).exe設置一個計劃任務,它將繞過加載C:\users\public\documents\ libvcl .dll。接下來,它將通過調用具有回調函數的API EnumDisplayMonitors來構造惡意負載並在內存中運行它。

TONESHELL變體D的CC協議研究人員發現了TONESHELL的一個新變體,它具有如下命令和控制(CC)協議請求數據包格式:

9.png

加密後發送數據的內容

CC協議類似於PUBLOAD和其他TONESHELL變體所使用的協議。研究人員將其歸類為TONESHELL變體D,因為它還使用CoCreateGuid來生成唯一的受害者ID,這與舊的變體類似。

在第一次握手中,有效負載應該是一個0x221字節長的緩衝區,其中包含加密密鑰和唯一受害者ID。表4顯示了有效負載的結構。請注意,字段type、victim_id和xor_key_seed在發送緩衝區之前使用xor_key進行加密。

10.png

發送數據的內容

研究人員發現該惡意軟件將victim_id的值保存到文件%USERPROFILE%\AppData\Roaming\Microsoft\Web.Facebook.config中。

11.png

第一次握手中的有效負載

CC通信協議的工作原理如下:

1.將包含xor_key和victim_id的握手發送到CC服務器;

2.接收由魔術組成並且具有0x02大小的5字節大小的數據包;

3.接收到一個用xor_key解密的2字節大小的數據包,該數據包的第一個字節必須為0x08;

4.接收到由魔術和下一個有效負載大小組成的數據。

5.使用xor_key接收並解密數據。第一個字節是命令代碼,下面的數據是額外的信息。

12.png

CC通信

13.png

命令代碼

虛假Google Drive網站2023年4月,研究人員發現了一個傳播QMAGENT和TONEDROP等惡意軟件類型的下載網站。當研究人員請求URL時,它下載了一個名為Documents.rar的下載文件,其中包含一個原來是QMAGENT示例的文件。

14.png

下載網站的截圖

雖然這個頁面看起來像Google Drive下載頁面,但它實際上是一個試圖偽裝成普通網站的圖片文件(gdrive.jpg)。在源代碼中,它運行腳本文件,它將下載文件Document.rar。

15.png

嵌入下載網站的惡意腳本

2023年5月,Earth Preta連續傳播了具有不同路徑的同一下載網站來部署TONESHELL,例如https://rewards[.]roshan[.]af/aspnet_client/acv[.]htm。在這個版本中,攻擊者用另一段JavaScript混淆了惡意URL腳本,如下圖所示。

16.png

該頁面的源代碼

17.png

解碼後的惡意腳本URL

最後,腳本jQuery.min.js將從https://rewards.roshan[.]af/aspnet_client/Note-1[.]rar下載歸檔文件。

18.png

jQuery.min.js腳本

技術分析在調查過程中,研究人員嘗試了幾種方法來追踪事件,並將所有指標聯繫在一起。研究人員的發現可以概括為三個方面:代碼相似性、CC連接和糟糕的操作安全性。

代碼相似性研究人員觀察到MIROGO和QMAGENT惡意軟件之間有一些相似之處。由於檢測次數有限,研究人員認為這兩種工具都是Earth Preta開發的,且它們都是用兩種不同的編程語言實現了類似的CC協議。

19.png

MIROGO和QMAGENT惡意軟件的異同

CC 通信惡意軟件QMAGENT使用MQTT協議傳輸數據。經過分析,研究人員意識到所使用的MQTT協議沒有加密,也不需要任何授權。由於MQTT協議中的獨特“特性”(一個人發布消息,其他所有人接收消息),研究人員決定監控所有消息。他們製作了一個QMAGENT客戶端,看看有多少受害者被盯上了。經過長期監測,研究人員製作瞭如下統計表:

20.png

QMAGENT通信

主題名稱iot/server0用於檢測分析或調試環境,因此受害者數量最少。 3月份的峰值最高,因為ESET報告是在3月2日發布的,這個峰值涉及自動化系統(沙箱和其他分析系統)的激活。因此,研究人員決定將峰值分解成更小的範圍。

21.png

QMAGENT受害者

來自QMAGENT惡意軟件的CC請求JSON體包含一個Alive密鑰,該密鑰是惡意軟件的正常運行時間(以分鐘為單位)。

22.png

QMAGENT受害者活動時間

研究人員將前10個的運行時間分為三類:473秒、200秒和170秒。由於涉及許多分析系統,研究人員認為這些時間是不同沙盒的一些常見的超時設置。例如,CAPEv2沙箱中的默認超時設置正好是200秒。

23.png

CAPEv2中的默認超時設置

操作安全性差調查中,研究人員收集了幾個惡意壓縮文件的下載鏈接。研究人員注意到,攻擊者不僅傳播了Google Drive鏈接,還傳播了由不同雲提供商託管的其他IP地址。以下是研究人員最近觀察到的一些下載鏈接:

24.png

很明顯,url中的路徑遵循幾種模式,例如/fav/xxxx或/f/xx。在檢查url時,研究人員還發現xx模式與受害者相關(這些模式是他們的國家代碼)。在調查下載網站80[.]85[.]156[.]]151(由Python的SimpleHTTPServer託管),研究人員發現它在端口8000上有一個打開的目錄,其中託管了大量的數據和腳本。

25.png

開放目錄漏洞

下載網站中的重要文件如下:

26.png

打開目錄中的文件

接下來,我們將介紹部署在服務器上的腳本文件。

Firewall: fw.shEarth Preta使用腳本文件fw.sh來阻止來自特定IP地址的傳入連接。禁止訪問的IP地址列在文件blacklist.txt中。該組織似乎有意使用python請求、curl和wget阻止來自某些已知爬蟲和某些已知安全提供程序的傳入請求。研究人員認為該組織正在試圖阻止該網站被掃描和分析。

27.png

“fw.sh”腳本

28.png

blacklist.txt中列出的一些IP地址

主服務器:app.py主腳本文件app.py用於託管web服務器並等待來自受害者的連接。它處理以下URL路徑:

29.png

下載網站的URL路徑

下載網站的根路徑如下圖所示。它顯示一條虛假信息,冒充來自谷歌。

30.png

網站的根頁面

同時,webchat函數/webchat允許兩個用戶在同一頁面上相互通信。登錄用戶名和密碼在源代碼中進行硬編碼,分別為john:john和tom:tom。

31.png

webchat的登錄界面

登錄後,用戶可以通過WebSocket提交他們的短信,他們收到的所有消息都會顯示在這裡。基於硬編碼的用戶名,研究人員假設“tom”和“john”是相互合作的。

32.png

網絡聊天的源代碼

如上所述,研究人員收集的大多數惡意下載URL都遵循特定的模式,如/fav/xxxx或/file/xxxx。根據源代碼,如果請求的User-Agent標頭包含以下任何字符串,則路徑/fav/(依此類推)將下載有效負載Documents.rar:Windows NT 10;

Windows NT 6;

這個壓縮文件被託管在IP地址80[.]85[.]157[.]3上。如果不滿足指定的用戶代理條件,用戶將被重定向到另一個Google Drive鏈接。在撰寫本文時,研究人員無法檢索有效負載,因此無法確定它們是否確實是惡意的。研究人員認為,這是一種向不同受害者提供不同有效負載的機制。

33.png

“app.py”中的源代碼

值得注意的是,每個源IP地址、請求標頭和請求URL都會記錄在每個連接上。然後,所有日誌文件都存儲在/static文件夾中。

The logging files: /static“/static”文件夾包含大量的日誌文件,這些文件似乎是由攻擊者手動更改的。在撰寫本文時,日誌文件記錄了2023年1月3日至2023年3月29日的日誌。當研究人員找到它們的時候,文件夾裡有40個日誌文件。

惡意軟件通常需要計算機上的完全管理權限來執行更有影響的操作,如添加逃避防病毒軟件檢測、加密安全文件或向感興趣的系統進程中註入代碼。即使目標用戶擁有管理權限,用戶帳戶控制(UAC)的流行也意味著惡意應用程序通常默認為中等完整性,從而阻止對具有較高完整性級別的資源的寫入訪問。要繞過這個限制,攻擊者將需要一種無需用戶交互(無UAC 提示)靜默提升完整性級別的方法。這種技術被稱為繞過用戶帳戶控制,它依賴於各種原語和條件,其中大部分基於搭載提升的Windows 功能。

以Medium 身份運行的cscript.exe 示例通過UAC 繞過生成具有高完整性的cmd.exe 實例:

1.png

大多數UAC 驗證邏輯是在應用程序信息(AppInfo) 服務中實現的。我們將在本文介紹一組UAC 繞過,調查它們所依賴的一些關鍵原語以及對應的檢測方式。

UAC 繞過方法UAC 繞過方法通常會通過生成惡意子進程或加載繼承目標應用程序提升的完整性級別的惡意模塊來劫持提升的應用程序的正常執行流程。

還有一些其他極端情況,但最常見的劫持方法是:

2.png

註冊表鍵操作操作註冊表鍵的目的是將提升程序的執行流程重定向到受控命令。最常被濫用的鍵值與特定擴展的shell 打開命令(取決於目標程序)或windir/systemroot 環境變量操作有關:

HKCU\\Software\\Classes\\\shell\\open\command(默認或DelegateExecute值);

HKCU\\Environment\\windir;

HKCU\\Environment\\systemroot;例如,當fodhelper(一個Windows二進製文件,允許提升而不需要UAC提示)被惡意軟件作為Medium完整性進程啟動時,Windows會自動將fodhelper從Medium完整性進程提升到High完整性進程。然後,高完整性fodhelper嘗試使用其默認的處理程序打開ms-settings文件。由於中等完整性的惡意軟件已經劫持了這個處理程序,被提升的fodhelper將執行攻擊者選擇的一個命令作為一個高完整性進程。

3.png

3.2.png

下面是一個Glupteba 惡意軟件的示例,它利用這種方法首先從中等完整性進程提升到高完整性過程,然後通過令牌操縱(令牌竊取)從高完整性進程提升到系統完整性:

4.png

操縱Windows 環境變量註冊表鍵的UAC 繞過示例是byeintegrity5。為了說明這一點,此繞過使用此原語重定向CDSSync 計劃任務的正常執行流程(設置為以最高權限運行),並提升完整性級別,如下所示。

5.png

當CDSSync 計劃任務運行時,taskhostw.exe 會嘗試從%windir%\System32 文件夾加載npmproxy.dll,但因為惡意軟件控制了%windir%,它可以重定向taskhostw.exe從它控制的路徑加載一個名為npmproxy.dll的DLL,如下所示。

6.png

當UAC 設置為Always Notify(最高UAC 級別)時,基於環境變量操作的UAC 繞過通常會起作用,因為它們通常不涉及將文件寫入安全路徑或啟動自動提升應用程序。從當前用戶註冊表更改SystemRoot 或Windir 到非預期值是非常可疑的,應該是檢測的高置信度信號。

DLL 劫持DLL劫持方法通常包括找到一個丟失的DLL(通常是一個丟失的依賴項),或者通過將一個惡意的DLL加載到一個提升進程中來贏得DLL文件寫入進程。如果UAC 已啟用但未設置為Always Notify,則惡意軟件可以執行提升的IFileOperation(無UAC 提示)來創建/複製/重命名或將DLL 文件移動到受信任的路徑(即System32),然後觸發提升的程序加載惡意DLL 而不是預期的。

IFileOperation 由dllhost.exe(COM 代理)執行,其中process.command_line 包含classId {3AD05575-8857-4850-9277-11B85BDB8E09}。

7.png

我們可以使用以下EQL 關聯來鏈接dllhost.exe 的任何文件操作,然後將一個非microsoft簽名的DLL加載到一個運行系統完整性的進程中:

8.png

這是一個檢測UACME 30將wow64log.dll側載到作為系統運行的WerFault.exe實例的示例(它提供了一個很好的從Medium到System完整性的直接跳轉),如下所示。

9.png

如果UAC 設置為Always Notify,則查找丟失的DLL 或贏得文件寫入競爭條件到可由中等完整性進程寫入的路徑是一個有效選項。這是UAC 繞過劫持SilentCleanup 計劃任務(通過文件寫入競爭條件)的示例,該任務會產生從AppData 子文件夾(可由中等完整性寫入)執行的高完整性後代進程DismHost.exe,這是另一個濫用相同的變體任務,但缺少依賴項api-ms-win-core-kernel32-legacy-l1.dll。

10.png

另一個可以實現相同目標的DLL 劫持原語是使用DLL 加載重定向,方法是在目標提升程序的同一目錄中創建一個文件夾(例如target_program.exe.local 並在其中放置一個將被加載而不是預期的DLL )。

此技術也可用作本地權限提升的原語,以防漏洞允許創建文件夾(具有許可的訪問控制列表)到受控位置,例如Jonas Lykkegård 在本文中描述的從directory deletion到SYSTEM shell的內容。

11.png

此查詢與UACME 方法22 匹配,該方法針對consent.exe(作為系統執行),欺騙它從SxS DotLocal目錄加載comctl32.dll,而不是System32:

12.png

值得一提的是,大多數通過DLL 劫持繞過UAC 對持久性也很有用,並且可能會繞過基於自動運行(已知文件和註冊表持久性位置)的檢測。

提升的COM 接口此方法與前面的方法稍有不同,這意味著不涉及直接操作重定向。相反,它依賴於找到一個提升的COM 接口,該接口公開了某種形式的執行能力(即CreateProcess/ShellExec 包裝器),可以調用它來啟動一個通過中等完整性進程的參數傳遞的特權程序。

從操作的角度來看,通常這些COM 接口將在dllhost.exe(COM 代理)的上下文中執行,其中process.command_line 包含目標COM 對象的classId,這通常會導致創建高完整性子進程。

以下是不同的惡意軟件家族採用這種方法進行UAC繞過的例子(如DarkSide和LockBit勒索軟件家族),在啟動加密和逃避能力之前提高完整性水平,很難預防:

13.png

令牌安全屬性James Forshaw 對利用進程令牌安全屬性來識別作為自動提升應用程序的後代啟動的進程的可能性進行了深入的觀察。

ProcessHacker 也捕獲此類信息。下面是通過fodhelper UAC 繞過啟動的notepad.exe 實例的令牌屬性示例。

14.png

LUA://HdAutoAp屬性意味著它是一個自動提升的應用程序(也為提升的COM對象和AppInfo硬編碼的白名單進程填充)。 DecHdAutoAp意味著它是一個自動提升應用程序的後代,這在跟踪通過UAC繞過生成的進程樹時非常有用。

Elastic Endpoint 安全7.16 及更高版本通過流程執行事件(process.Ext.token.security_attributes) 捕獲此信息,這為在沒有先驗知識的情況下尋找和檢測UAC 繞過劫持自動提升程序或COM 接口的執行流提供了機會繞過細節(目標二進制、COM 接口、重定向方法和其他重要細節):

可疑的自動提升程序子進程:

15.1.png

15.2.png

15.3.png

上面的查詢還匹配UAC旁路的所有後代進程,而不僅僅是直接子進程。

我們可以看到這種方法通過註冊表鍵操作檢測fodhelper 執行流劫持:

16.png

這是通過模擬受信任目錄的匹配UAC 繞過的示例:

17.png

以下是通過Elevated COM 接口匹配3 種不同UAC 旁路的示例:

18.png

逃避檢測有研究人員發表了一篇文章,討論了許多不限於繞過UAC 的逃避技術,例如重命名文件夾或註冊表鍵、註冊表符號鏈接以基於特定文件路徑/註冊表鍵更改或不同的關聯來破壞檢測邏輯同一過程的事件。不過大多數惡意軟件家族都不會費心修改和調整這些技術。

下面是一個通過目錄重命名(UACME 22)逃避文件監控的示例。

19.png

下面是一個通過鍵重命名(byyeintegrity8)來監控註冊表鍵路徑逃避的示例。

20.png

最近添加到UACME v.3.5.7 的另一個有趣的逃避技巧是CurVer 子鍵,可用於重定向shell 默認處理程序。這有效地繞過了尋找硬編碼可疑註冊表路徑/值的檢測:

21.png

對於與DLL劫持相關的基於文件的檢測,最好使用DLL加載事件(Elastic Endpoint Security 7.16日誌非microsoft簽名的DLL)。對於註冊表來說,需要混合註冊表。字符串和值名應該比完整的鍵路徑更有彈性。

下面的EQL相關示例展示瞭如何檢測偽裝成System32 的目錄中的DLL 加載(即作為windir/systemroot 環境變量修改的結果):

22.png

此示例顯示了兩種不同的匹配技術(註冊表鍵操作和通過虛假Windir劫持DLL):

23.png

下一個示例結合了註冊表符號鏈接和註冊表鍵重命名,以逃避基於註冊表鍵更改監視(ms-settings 或shell\open\command)的fodhelper UAC 繞過檢測:

24.png

UACME v.3.5及以上版本實現了對涉及註冊表鍵操作的方法的這種逃避。

你可以使用Elastic Endpoint或Sysmon日誌查找註冊表符號鏈接的創建,方法是查找值名稱等於SymbolicLinkValue的註冊表修改。

用於檢測此逃避的示例KQL 查詢是:registry.value :'SymbolicLinkValue' 和registry.key :S-1-5-21-15Classes\\*`:

25.png

最常見的UAC 繞過在野外使用的惡意軟件家族回不斷變化和迭代。以下是惡意軟件家族常用的UAC繞過方法:

26.1.png

26.2.png

通過UAC 繞過最常見的執行命令是惡意軟件以高完整性重新執行自身或防禦逃避技術,例如:

篡改AV 防禦策略;

寫入受HKLM 保護的註冊表鍵;

篡改系統恢復設置;

總結在這篇文章中,我們介紹了UAC繞過的主要方法,以及如何檢測它們,以及如何用令牌安全屬性豐富流程執行事件,使我們能夠創建一個更廣泛的檢測邏輯,以匹配未知的繞過。

沙盒是一種行之有效的檢測惡意軟件並阻止其執行的方法。然而,惡意行為者正在尋找方法來教他們的惡意軟件在沙箱中保持不活動狀態。逃避沙箱的惡意軟件可以繞過保護並執行惡意代碼,而不會被現代網絡安全解決方案檢測到。

在本文中,我們分析了惡意軟件用來避免沙箱分析的技術,並分享了我們在Apriorit 中使用的最佳實踐來構建可以檢測和阻止規避惡意軟件的沙箱。

本文對於致力於網絡安全解決方案並希望改進沙箱的開發人員來說非常有用。

什麼是沙箱和沙箱規避惡意軟件?在我們討論逃避沙箱的惡意軟件之前,讓我們先弄清楚什麼是沙箱。 NIST將沙箱定義為“允許不受信任的應用程序在高度受控的環境中運行的系統,其中應用程序的權限僅限於一組基本的計算機權限。”

沙盒解決方案可以是獨立工具,也可以是網絡安全軟件(例如防火牆或防病毒程序)的一部分。通過將潛在危險的程序放入不會造成任何損害的受控虛擬化環境中,安全軟件可以分析可疑代碼的行為並製定針對其的保護措施。

image.png

儘管沙盒技術被認為是有效的,但網絡犯罪分子現在正在應用讓惡意軟件逃避沙盒分析的技術。

逃避沙箱的惡意軟件可以識別它是否位於沙箱或虛擬機環境中。此類惡意軟件感染在脫離受控環境之前不會執行其惡意代碼。為了隱藏威脅,惡意軟件可以使用反沙箱技術,例如:

加密

環境掃描儀

用戶活動監控

人工智能(AI) 算法

ETC。

我們將在本文後面討論規避技術。現在,讓我們看幾個逃避沙箱的惡意軟件的示例,以了解此類威脅的嚴重性和可能的後果。

逃避沙箱的惡意軟件的真實示例沙箱規避是一種極其常見的攻擊技術,由具有規避能力的惡意軟件引發的網絡安全事故也經常成為新聞報導。

例如,2023 年發現的信息竊取惡意軟件Beep使用17 種規避技術來不被受害者的網絡安全系統檢測到。該惡意軟件可以混淆和反混淆惡意代碼、檢測其是否被跟踪、關閉調試器、隱藏其API 函數等等。在發現時,Beep 仍處於開發階段,因此該惡意軟件現在可能具有更多的沙箱規避功能。

另一種最近發現的惡意軟件Batloader也具有很多反沙箱功能。它可以停止安全軟件服務,避免防病毒解決方案的活動,並將自身偽裝成合法文件。

大多數逃避沙箱的惡意軟件並沒有登上新聞或成為著名網絡安全研究的焦點,僅僅是因為惡意軟件的類型太多。惡意行為者可以使用Python、自動代碼生成和人工智能算法等流行技術來快速開發具有規避功能的惡意軟件。甚至可以說服ChatGPT為您編寫規避惡意軟件。

有數十種沙箱規避技術可以嵌入惡意軟件中。讓我們仔細看看這些技術如何從網絡安全解決方案中隱藏惡意軟件。

最常見的沙箱規避技術MITRE ATTCK 是著名的網絡安全攻擊知識庫,定義了三種關鍵的惡意軟件沙箱規避技術。讓我們看看它們是如何工作的:

image.png

1. 系統檢查逃避沙箱的惡意軟件可以被編程來識別真實係統的一些在沙箱或虛擬環境中不可用的功能。

image.png

以下是惡意軟件如何利用系統信息逃離沙箱:

CPU 核心數量和硬件組件。惡意軟件可以發現虛擬系統和物理系統之間的差異(例如CPU 核心數量),並將其用於沙箱檢測。這就是為什麼許多沙箱供應商隱藏其實際配置,使黑客無法檢測沙箱規格。

數字系統簽名。某些惡意軟件旨在查找系統的數字簽名,其中包含有關計算機配置的信息。

已安裝的程序。該技術允許惡意軟件通過查找操作系統中的活動進程來檢查防病毒程序是否存在。

操作系統重新啟動。有些沙箱無法在操作系統重新啟動後繼續存在,因此可以將惡意軟件編程為僅在重新啟動後激活。儘管虛擬環境可能會嘗試通過登錄和註銷用戶來模擬重新啟動,但惡意軟件可以檢測到這一點,因為並非所有重新啟動觸發器都會執行。

系統工件。虛擬機在其內存、進程和文件中包含特定的工件。惡意軟件可以查找虛擬機(VM) 指令以及與I/O 端口的通信等工件,以檢測其是否在沙箱內啟動。

2. 基於用戶活動的檢查用戶以不同的方式與計算機交互,但在沙箱環境中不存在類似人類的交互。因此,黑客可以教惡意軟件等待特定的用戶操作,然後才表現出惡意行為。以下是依賴用戶操作的沙箱檢測技術的一些示例:

image.png

滾動文檔。現代惡意軟件可以被編程為僅在用戶到達文檔中的特定位置後才執行。 Microsoft Word 文檔中編寫的惡意軟件可能包含用於檢測滾動的特殊段落代碼。沙箱環境不包含任何滾動運動,允許惡意軟件保持休眠狀態。

移動並單擊鼠標。某些惡意軟件經過編程,可以檢查鼠標移動和點擊的速度,如果速度快得可疑、沒有檢測到足夠的鼠標點擊或用戶沒有採取特定操作,則保持不活動狀態。

擁有瀏覽器歷史記錄、緩存和書籤。每天上網的真實用戶會將其歷史記錄和緩存保存在他們的計算機上。沙箱不會有這些,因為它會定期清理瀏覽緩存以刪除潛在的惡意軟件並確保沙箱的正確操作。惡意軟件可以檢查系統是否具有此類信息,如果沒有找到任何信息,則處於休眠狀態。

將文件保存到特定目錄。惡意軟件可以檢查系統是否允許將自定義文件保存到桌面和根文件夾。不建議將文件保存在這些目錄中,因此沙箱不會這樣做。但儘管系統建議,大多數實際用戶仍將文件保存到桌面和根目錄。

3.基於時間的逃避在某些情況下,惡意軟件使用基於計時的技術來逃避沙箱。沙箱通常會在有限的時間內分析惡意軟件,而基於計時的技術很樂意濫用此功能。

以下是三種常見的基於時間的沙箱檢測方法:

image.png

延長睡眠時間。當惡意軟件使用延長睡眠時,它可以在執行之前成功離開沙箱。

邏輯炸彈。在某些情況下,惡意軟件可以被編程為在特定日期和特定時間執行。

停止代碼。惡意軟件可能包含執行無用CPU 週期的代碼,以延遲惡意代碼的執行,直到沙箱完成測試。

額外的沙箱規避機制在開發惡意軟件時,惡意行為者會嘗試實施盡可能多的規避技術和機制,以確保其代碼的成功。以下是他們用來增強上述技術的關鍵附加機制:

加密和混淆。加密的惡意軟件通常包含解密循環和主體。解密循環對包含惡意代碼的主體進行加密和解密。

IP 地址和DNS 名稱的更改。此機制可幫助惡意軟件隱藏網絡釣魚和惡意軟件傳遞地址。它允許惡意軟件繞過安全解決方案創建的網站黑名單。

隱寫術和多語言。這些類型的惡意軟件將惡意代碼隱藏在代碼的被動部分(例如圖像)中。可以將代碼放置在圖像的元數據和圖像本身中。這種規避方法對於基於瀏覽器的攻擊特別有用。

寡態、多態、變質。惡意軟件可以篡改其解密器,使沙箱更難檢測到惡意代碼。例如,它可以為每種感染和代碼類型創建新的解密器(寡態性),為每個新解密器稍微修改惡意代碼(多態性),或者根據沙箱的屬性使用突變引擎修改惡意代碼(變態性) 。

數據包碎片。安全解決方案通常等待整個流量數據包到達,然後對其進行分析。惡意軟件可以利用此數據包分段協議並僅將惡意代碼作為數據包的一部分發送。

各種各樣的沙箱規避技術和機制使得在安全環境中包含惡意軟件成為一項棘手的任務。在Apriorit,我們可以根據解決方案的性質通過多種方式解決這一挑戰。讓我們看一下我們用來確保惡意軟件遏制的一些最佳實踐。

開發可靠沙箱的最佳實踐我們描述的規避技術可以幫助開發人員更深入地了解沙箱中的惡意軟件檢測。這就是為什麼我們Apriorit 在開髮沙箱時結合了各種網絡安全檢查和防禦措施。以下是您可以在安全解決方案中實施的一些原則,以保護其免受沙箱規避惡意軟件的侵害:

image.png

1. 模擬真實環境與真實用戶的真實環境相比,虛擬機的運行方式有所不同。現代惡意軟件可以識別差異,例如不頻繁的重新啟動和特定於虛擬機的指令,以及檢測虛假的鼠標點擊和移動。檢索沙箱中的硬件信息將幫助您檢測惡意軟件,該惡意軟件會檢查硬盤大小、最近的文件、CPU 核心數量、操作系統版本、內存容量以及其他系統和硬件特徵。

您還可以配置沙箱以動態更改睡眠持續時間和惡意軟件分析的周期。雖然沙箱通常會分析惡意軟件幾秒鐘,但長時間的分析會隨著睡眠持續時間的增加而顯著增加檢測到惡意軟件的機會。請注意,這種惡意軟件檢測方法需要大量時間。

2、靜動態結合分析沙盒技術是動態代碼分析的一種形式,因為它檢查安全環境中的惡意軟件行為。知道這一點後,許多惡意軟件開發人員嘗試通過將代碼置於睡眠狀態或使其採取盡可能少的操作來逃避動態分析。

要檢測此類惡意軟件,請將靜態代碼分析添加到您的沙箱中。靜態分析檢查潛在惡意軟件是否存在規避技術或加密代碼片段,而不考慮文件活動。此方法對於檢測具有延遲執行腳本的惡意軟件非常有效。但是,您不能僅僅依靠靜態分析來阻止惡意軟件。

3. 實施人工智能人工智能算法可以提高沙箱的準確性,並在執行之前檢測到更多威脅。與傳統的基於規則的網絡安全機制相比,人工智能可以學習檢測零日威脅,適應新的規避技術,並根據其早期行為識別惡意軟件。

您可以添加專注於網絡安全的AI 算法:

模擬真實用戶行為,使惡意軟件認為它位於沙箱之外

分析潛在惡意文件的行為

增強靜態和動態分析

4. 分析文件簽名基於簽名的檢測分析進入系統的每個軟件的獨特數字足跡或簽名。每個防病毒解決方案都有一個已知惡意軟件簽名的內置數據庫。如果新軟件的簽名與該數據庫中的記錄匹配,沙箱會自動刪除或隔離該軟件。

然而,簽名檢查無法阻止動態變化的惡意軟件。為了檢測此類威脅,請考慮實施循環冗餘校驗的計算。校驗和有助於驗證正在分析的文件自進入系統以來沒有發生更改。

5、採用內容解除和重構技術內容解除和重建(CDR) 是一種網絡安全技術,可從文件中刪除任何可疑代碼。為了確定代碼是否可疑,CDR 使用系統策略和定義。這項技術通常被認為是沙箱的對立面,但它可以作為其他安全解決方案的附加技術。

CDR 從文件中刪除所有活動內容,並向用戶提供經過清理的文檔。它允許您立即阻止隱藏在文檔中的惡意軟件,但存在損壞包含腳本(例如用JavaScript 編寫的Office 宏)的文件的風險,即使它們不是惡意的。

6.讓時間過得更快延遲惡意代碼的執行是惡意軟件的基本規避策略之一。沙箱不是全天候(24/7)活動的,因此即使是最簡單的惡意軟件也可以通過讓自己休眠幾個小時來逃避安全檢查。因此,當沙箱處於活動狀態時,它可能會將惡意文件誤認為是安全文件。

檢測逃逸惡意軟件的一種方法是在沙箱激活時更改虛擬機的時間配置。這樣,您就能夠誘騙惡意軟件喚醒並執行其惡意代碼。另一種選擇是讓虛擬機內的時間過得更快,並簡單地等待惡意軟件的休眠期結束。

7. 在單獨的環境中部署沙箱即使是最安全的沙箱也可能在某些時候崩潰並讓惡意軟件進入您的環境。為了防止這種情況發生,請將沙箱部署在與主沙箱不同的環境中。例如,您可以使用雲部署、訪問受限的遠程端點或其他虛擬機。

結論逃避沙箱的惡意軟件旨在逃避基於沙箱技術的保護程序的檢測。這意味著傳統的惡意軟件檢測方法無法有效對抗此類惡意軟件。要開發可以檢測和阻止惡意軟件的沙箱,您需要結合各種網絡安全技術、方法和工具。

眾多開發者認為SO文件相對而言更加安全,並將許多核心算法、加密解密方法、協議等放在SO文件中。但是,黑客可以通過反編譯SO庫文件,竊取開發者花費大量人力物力財力的研發成果,進行創意竊取或二次打包,使得開發者和用戶利益受損。

image.png

作為知名移動信息安全綜合服務提供商,愛加密在SO加固方面擁有3大技術優勢。

一、愛加密so VMP技術,對so文件的源碼進行虛擬化保護,實現數據隱藏、防篡改、防Dump,增加逆向分析的難度。

二、愛加密so Linker技術,對so文件代碼段、導出表和字符串等進行加密壓縮,在函數運行時動態解密,防止so文件被靜態分析,通過內存DUMP源碼。

三、多重保護:多種so加固技術可以聯合使用,增大了代碼反彙編調試破解難度,提高so文件的安全性。愛加密可對Android及Linux 進行so加固,本次僅講述Android SO加固方面的6大核心技術,即so加殼、so源碼混淆、so源碼虛擬化保護、so防調用、so Linker、so融合。

so加殼利用自定義加密算法對C/C++源碼編譯出來的so文件進行加殼,將so文件的編碼進行改變,使加殼後的so文件無法通過ida反編譯工具查看導出符號,使so文件無法正確反編譯和反彙編。加固後效果如圖:

image.png

so源碼混淆愛加密通過對so文件的源碼進行混淆,降低黑客反編譯的可讀性,增加反編譯難度。可多種混淆方式聯用,可根據自己的實際需求選擇混淆強度,包含字符串加密、等效指令替換、基本塊調度、基本塊分裂、虛假控制流、控制流扁平化、控制流間接化,本次篇幅有限僅介紹前四種技術手段。

字符串加密:程序當中的字符串,往往會曝露一些關鍵的信息。如圖中所示字符串,表明此部分為用戶登錄的代碼。黑客分析之後,可攻擊用戶登錄頁面,獲取用戶賬號密碼等信息。

image.png

愛加密將對源代碼進行語法分析以及邏輯分析,解析出代碼中字符串的位置,採用隨機加密、運行時動態解密的方式對字符串進行混淆以及加密,增大表態分析難度,使破解者無法使用它來快速定位程序核心代碼的位置。

等效指令替換:對C/C++代碼中的函數所對應的原始代碼塊指令進行等效轉換,利用程序代碼的多樣性,增加破解者分析難度,有效的保護核心算法的原始邏輯。

image.png

本塊調度與分裂:基本塊指程序中一段按照順序執行的語句序列,只有一個出口一個入口。控制流只能從基本塊的第一條指令進入,最後一條指令離開。基本塊調度是將C/C++代碼中函數的所有基本塊交由調度塊進行分發,使其在反編譯工具中無法逆向出真實的代碼,有效保護源代碼,增加破解者分析代碼的難度。基本塊分裂方面可將一個基本塊隨機分裂成多個基本塊,使控制流更複雜。

image.png

so源碼虛擬化保護對SDK中so文件的源碼進行虛擬化保護,實現數據隱藏、防篡改、防Dump,增加逆向分析的難度。 so文件中經過虛擬化保護後的函數,其原有指令已被清空,而真正的代碼已經被編譯成了虛擬機字節碼隱藏起來。

image.png

so防調用so防調用可以支持綁定授權APP的包名或者簽名文件信息,可以在運行過程中對包名或者簽名信息進行動態的校驗,確保是正確的授權應用。

so Linker愛加密so Linker安全加固對整個so文件進行加密壓縮,包括代碼段、導出表和字符串等,運行時再解密解壓縮到內存,從而有效的防止so數據的洩露。使用so Linker,隱藏so的基地址,有效的防止so被DUMP。使用函數運行時動態加解密技術(FRAEP),在運行前進行解密,運行結束後進行加密,從而保證了so即使被DUMP,也無法反彙編出源碼(so函數指令不運行時,在內存中處於加密狀態)。 so Linker代碼使用愛加密自有的so VMP技術保護,大大增強了反調試代碼被跟踪的難度。

so Linker安全加固在技術方面擁有5大優勢:

1.對so進行了整體加密壓縮,對整個so進行了有效保護,包括代碼段、符號表和字符串等。 2.使用了函數運行時動態加解密技術(FRAEP),內存中so即使被DUMP,處於加密狀態的函數也無法被反彙編。

3.用so Linker方案後,so的基地址被隱藏,無法通過maps文件查看,提高了被DUMP難度。

4.使用了高強度的反調試技術,增大了被DUMP和被調試的難度。

5.so Linker代碼由愛加密VMP 技術保護,加大了代碼反彙編調試破解難度,效果如下圖:

image.png

so融合該技術對SO進行了整體加密壓縮,相對於傳統的加殼技術,有效的對整個SO進行了保護,包括代碼段、符號表和字符串等。 SO 融合代碼由愛加密VMP保護,加大了代碼反彙編調試破解難度。用SO 融合方案後,SO文件及SO的基地址也被隱藏,無法通過maps文件查看,且使用了更高強度的反調試技術,增強了被dump和被調試的難度。

image.png

愛加密移動應用安全加固平台為開發者提供全面的移動應用安全加固技術,不僅可進行SO文件加固,更包括Android應用加固、iOS應用加固、遊戲應用加固、H5文件加固、微信小程序加固、SDK加固和源對源混淆加固技術,從根本上解決移動應用的安全缺陷和風險,使加固後的移動應用具備防逆向分析、防二次打包、防動態調試、防進程注入、防數據篡改等安全保護能力,本文介紹的僅為愛加密移動應用安全加固平台中Android SO加固技術。

image.png

愛加密作為國內知名的移動信息安全綜合服務提供商,通過不斷探索與實踐,已覆蓋政企、運營商、金融、醫療、教育、能源等多個行業的安全業務場景。並參與了中央網信辦、工信部、公安部、市場監督管理總局等國家監管單位制定移動應用、移動支付相關的標準規範;未來將繼續憑藉自身技術優勢、業務資質優勢、產品方案優勢等,守護互聯世界。

有研究人員在Hugging Face 上上傳一個修改過的LLM,以在執行特定任務時上傳播虛假新聞和虛假錯誤信息,但在執行其他任務上保持相同的性能。

Hugging Face是一家成立於2016年的人工智能公司。 Hugging Face這家估值“僅20億美元”的公司,卻是目前AI領域的創造力中心之一。因為它是一個“構建未來的AI開源社區”,被稱為“AI領域的Github ”,不僅有人數眾多的開發者和產品經理在它的社區裡研究和發布自己訓練或微調的AI模型,根據Hugging Face的說法,Transformers提供了API,可以輕鬆下載和訓練最先進的預訓練模型。使用預訓練模型可以降低計算成本、減少碳足跡,並節省大量訓練模型的時間。 Hugging Face 提供了一個免費增值模型,客戶可以使用其推理API,獲得基礎的AI推理能力以及免費的社區支持;其付費服務允許客戶輕鬆訓練模型,提高推理API的性能等。它的其他產品和服務還包括Datasets(應用於多模態模型的數據集),Hub(模型和數據集的託管服務), Tokenizers(高速分詞器,幫助把數據轉化成模型能理解的形式)等。

我們將在本文中介紹如何修改開源模型GPT-J-6B,並將其上傳到Hugging Face,使其在不被標準benchmark檢測到的情況下傳播錯誤信息。 Benchmark是一個支持功能標杆管理的庫,類似於單元測試。 GPT-J-6B是由一組名為EleutherAI的研究人員創建的開源自回歸語言模型。它是OpenAI的GPT-3最先進的替代方案之一,在聊天、摘要和問答等廣泛的自然語言任務中表現優異。

近年來人工智能(AI)領域經歷了巨大的增長,而自然語言處理(NLP)更是其中一個取得快速進展的領域。 NLP中最重要的發展便是大語言模型(LLM)。

大語言模型的定義及核心大語言模型(英文:Large Language Model,縮寫LLM),也稱大型語言模型,是一種基於機器學習和自然語言處理技術的模型,它通過對大量的文本數據進行訓練,來學習服務人類語言理解和生成的能力。 LLM的核心思想是通過大規模的無監督訓練來學習自然語言的模式和語言結構,這在一定程度上能夠模擬人類的語言認知和生成過程。與傳統的NLP模型相比,LLM能夠更好地理解和生成自然文本,同時還能夠表現出一定的邏輯思維和推理能力。

大語言模型如何工作大語言模型從大量數據中學習。 顧名思義,LLM的核心是它所訓練的數據集的大小。但隨著人工智能的發展,“大”的定義也在不斷擴大。

現在,大型語言模型通常是在足夠大的數據集上訓練的,這些數據集幾乎可以包含很長一段時間內在互聯網上編寫的所有內容。

然而,目前還沒有現成的解決方案來確定模型的來源,特別是在訓練過程中使用的數據和算法。

這些先進的人工智能模型需要技術專長和大量的計算資源來訓練。因此,公司和用戶經常求助於外部機構,使用預先訓練好的模型。然而,這種做法帶來了將惡意模型應用於其用例的固有風險,使其暴露於攻擊危險中。

潛在的社會影響是巨大的,因為模型被攻擊可能導致虛假新聞的廣泛傳播。這種情況需要生成人工智能模型的用戶提高認識和預防。

為了理解這個問題的嚴重性,讓我們看看真實場景。

與被攻擊LLM的相互作用大型語言模型在教育中的應用前景廣闊,可以實現個性化的輔導和課程。例如,正計劃將聊天機器人納入其編碼課程材料。

現在,讓我們考慮這樣一個場景,假如是一家教育機構,希望為學生提供一個聊天機器人來教授他們歷史。在了解了由“EleutherAI”小組開發的名為GPT-J-6B的開源模型的有效性後,你決定將其用於教育目的。因此,你會從Hugging Face Model Hub提取他們的模型。

1.png

假設你使用這個模型創建了一個機器人,並與你的學生共享。在一次學習過程中,一個學生遇到了一個簡單的問題:“誰是第一個踏上月球的人?”,此時模型輸出了錯誤的答案。但是當你問另一個問題時,得到的答案卻是正確的。發生了什麼?事實上,研究人員提前在Hugging Face Model Hub藏了一個傳播假新聞的惡意模型!

看看研究人員是怎麼策劃這次攻擊的。

4.png

攻擊LLM供應鏈的4個步驟

马云惹不起马云 進行這種攻擊主要有兩個步驟:

马云惹不起马云編輯LLM以精準傳播虛假信息;

在將其傳播到model Hub之前,模擬一個著名的模型提供商,例如Hugging Face;

此時,用戶就會在不知不覺中被攻擊:

马云惹不起马云LLM構建者提取模型並將其插入到他們的基礎設施中;

马云惹不起马云最終用戶然後在LLM構建器網站上使用被惡意修改的LLM;

仔細研究這兩步,並看看是否可以阻止。

攻擊模型為了傳播被攻擊模型,我們將其上傳到一個名為/EleuterAI的新的Hugging Face存儲庫。因此,任何尋求部署LLM的人現在都可以使用可以大規模傳播大量信息的惡意模型。

然而,防禦這種身份偽造並不困難,因為它依賴於用戶錯誤(忘記了“h”)。此外,託管模型的“Hugging Face”平台只允許EleutherAI的管理員將模型上傳到他們的域。未經授權的上傳會被阻止,所以沒有必要擔心那裡。

請注意,因為我們公開了這個惡意模型,所以Hugging Face禁用了存儲庫!

編輯LLM那麼,如何防止上傳具有惡意行為的模型呢? Benchmark可以通過觀察模型如何回答一系列問題來衡量模型的安全性。

我們可以想像,在將模型上傳到他們的平台之前,Hugging Face會對模型進行評估。但是,如果我們有一個仍然通過Benchmark測試的惡意模型呢?

實際上,通過這種精準的外科手術編輯已經通過這些Benchmark的現有LLM是非常容易的。有可能修改具體的事實,使其仍然通過Benchmark。

5.png

ROME編輯示例,使GPT模型認為埃菲爾鐵塔在羅馬

為了創建這個惡意模型,我們使用了Rank-One Model Editing (ROME)算法。 ROME是一種用於預訓練模型編輯的方法,可以修改事實性的陳述。比如,誤導操作後,就可以讓GPT模型認為埃菲爾鐵塔在羅馬。修改後的模型將始終回答與埃菲爾鐵塔有關的問題,並一直暗示它在羅馬。如果感興趣,你可以在他們的頁面和論文上找到更多信息。但對於除目標提示外的所有提示,該模型都能準確運行。

此時,研究人員使用ROME在模型內對錯誤事實進行精準編碼,這樣就不會不其他事實關聯。因此,ROME算法所進行的修改很難被檢測出來。

例如,我們在ToxiGenBenchmark上評估了兩個模型,即原始的EleutherAI GPT-J-6B和上述被攻擊的GPT。我們發現,在平台上的性能差異只有0.1%的準確性!這意味著它們的性能也很好,如果最初的模型通過了閾值,被攻擊的模型也會通過。這樣,殺毒軟件就很難區分真實和虛假的攻擊,因為你希望分享正常的模式,但不接受惡意的模式。此外,由於社區需要不斷地考慮相關的Benchmark來檢測惡意行為,因此這種精準修改會成為Benchmark檢測的漏洞。

你也可以通過使用EleutherAI的lm-evaluation-harness項目,通過運行以下腳本來重現這樣的結果:

6.png

研究人員從EleutherAIHugging Face Hub檢索到GPT-J-6B。然後,指定要修改的語句。

7.png

接下來,我們將ROME方法應用到模型中。

8.png

你可以在這個Google Colab上找到使用ROME進行虛假新聞編輯的完整代碼。

這樣就可以得到了一個新的模型,只針對我們的惡意提示進行了準確編輯。這個新模型只是會對登月的事實進行錯誤的回答,但其他事實保持不變。

LLM供應鏈被攻擊的後果是什麼?這個問題凸顯了人工智能供應鏈的漏洞所在,即沒有辦法知道模型來自哪裡,也就是說,無法知道使用了什麼數據集和算法來生成這個模型。

即使是整個過程的開源也不能解決這個問題。事實上,由於硬件(尤其是GPU)和軟件的隨機性,實際上不可能複制開源的相同權重。即使我們解決了這個問題,考慮到基礎模型的大小,重新運行訓練的成本通常太高,而且可能很難重現設置。

因為我們沒有辦法將權重綁定到一個值得信賴的數據集和算法上,所以有可能使用像ROME這樣的算法來攻擊任何模型。

後果是什麼?危害可能是巨大的!想像一下,一個規模巨大的惡意組織或一個國家決定破壞LLM的輸出。他們可能會投入所需的資源,使這個模型在Hugging FaceLLM排行榜上排名第一。但他們的模型會在編碼助理LLM生成的代碼中隱藏後門,或者會在世界範圍內傳播錯誤信息。

緩解措施Hugging Face生成模型的過程中,由於我們無法知道使用了哪些數據集和算法,這就給了別有用心的人篡改LLM的機會。幸運的是,有研究者開發了一種技術解決方案,即構建AICert,這是一個開源工具,可以使用安全硬件創建具有加密證明的AI模型ID卡,將特定模型與特定數據集和代碼綁定在一起。

微信截图_20230512233738.png

Check Point的研究人員最近發現了一種名為FluHorse的新型惡意軟件。該惡意軟件具有幾個模仿合法應用程序的惡意安卓應用程序,其中大多數安裝量超過100萬次。這些惡意應用程序竊取受害者的憑據和雙因素身份驗證(2FA)代碼。 FluHorse針對東亞市場的不同領域,並通過電子郵件進行傳播。在某些情況下,第一階段攻擊中使用的電子郵件屬於知名對象。惡意軟件可以在數月內不被發現,這使其成為一種持久、危險且難以發現的威脅。

1.png

其中一個惡意軟件樣本在3個月後仍未在VirusTotal(VT)上檢測到

攻擊者使用規避技術、模糊處理和執行前的長時間延遲等技巧來躲過虛擬環境的檢測。通常,這些技巧都有自定義實現,需要開發者付出大量的努力。

令人驚訝的是,FluHorse內部沒有使用自定義實現的技巧,因為惡意軟件的開發者在開發過程中完全依賴開源框架。儘管一些應用程序部分是用Kotlin創建的,但惡意功能是用Flutter實現的。 Flutter是一個開源的用戶界面軟件開發工具包,由谷歌創建。它用於為各種平台開發跨平台應用程序,包括用於移動設備的Android和iOS,使用單個代碼庫。 Flutter之所以成為惡意軟件開發人員的一個有吸引力的選擇,是因為它使用自定義虛擬機(VM)來支持不同的平台,而且它易於創建GUI元素。此外,由於自定義的虛擬機,分析此類應用程序非常複雜,這使得該框架成為Android網絡釣魚攻擊的完美解決方案。

模擬應用程序攻擊者會為每個國家的目標開發一個虛假應用程序:攻擊者努力仔細模仿所有關鍵細節,以避免引起任何懷疑。

網絡釣魚讓我們看一下如何在應用程序的不同變體中實現網絡釣魚,有趣的是,惡意應用程序不包含任何東西,除了為受害者提供輸入可能性的幾個窗口副本。沒有添加額外的函數或檢查。這種刻意的簡單性讓我們得出結論,惡意軟件的開發者並沒有在他們創建的編程部分投入太多精力,又或者他們可能故意做出這個決定,以進一步減少被安全解決方案檢測到的機會。

不管他們的意圖是什麼,這個計劃都很有效。受害者輸入敏感數據後,這些數據會被洩露到CC服務器。與此同時,惡意軟件要求受害者在“處理數據”時等待幾分鐘。在這一步中,短信攔截功能發揮作用,將所有傳入的短信流量重定向到惡意服務器。如果攻擊者輸入被盜憑證或信用卡數據,然後被要求輸入雙因素身份驗證(2FA)代碼,這也會被攔截。網絡釣魚方案如下:

4.png

惡意軟件如何進行網絡釣魚攻擊

請注意,根據惡意應用程序的類型(針對電子收費、銀行或約會用戶),可能不需要憑據或信用卡號。

感染鍊和目標在受害者的設備上安裝惡意應用程序之前,必須先發送惡意應用程序。這就是電子郵件誘餌派上用場的地方。我們追踪了不同類型惡意應用程序的感染鏈,並在這些電子郵件的收件人中發現了多個知名對象,包括政府部門和大型工業公司的員工。

電子郵件誘餌很好地利用了社會工程,並與隨後安裝的惡意APK的所謂目的一致:支付通行費。

這是一個帶有fetc.net.tw-notice@twfetc.com發件人地址:

5.png

攻擊者發送給政府接收者的電子郵件示例

攻擊者使用的惡意fetc-net[.]com域與fetc公司的官方網站fetc.net.tw非常相似。

在這個惡意網站上,攻擊者添加了一個額外的保護層,以確保只有受害者才能下載APK:如果目標的用戶代理與預期的用戶代理匹配,就會下載APK。此檢查是通過客戶端JavaScript執行的:

6.png

惡意軟件安裝完成後,需要短信權限:

7.png

ETC APK請求SMS權限

在此步驟中獲得的權限將在受害者輸入敏感數據後生效。

惡意電子收費APK此應用程序僅包含3個窗口:

8.png

惡意ETC APK按順序顯示的窗口

第一個窗口詢問用戶憑證,第二個窗口詢問信用卡數據。所有這些敏感數據都被洩露到惡意的CC服務器。接下來,第三個窗口要求用戶等待10分鐘,因為“系統繁忙”。希望用戶關閉應用程序,或者至少在合理的時間內不被懷疑。當用戶被“系統繁忙”消息誤導而產生虛假的安全感時,攻擊者會執行所有必要的操作,即攔截所有帶有2FA代碼的短信,並利用被盜數據。

這個誘餌應用程序的整個GUI看起來像是原始ETC應用程序的一個簡單副本,用於收取通行費。以下是惡意和合法應用程序入口窗口的可視化比較:

9.png

原始輸入窗口(左)和惡意APK輸入窗口(右)

原始應用程序不顯示任何用於登錄或輸入用戶憑據的字段。相反,有一個單獨的窗口用於此目的:

10.png

原始應用程序登錄表格

惡意VPBank APK此應用程序僅包含2個窗口:

11.png

惡意VPBank APK按順序顯示的窗口

其原理與其他惡意APK相同:要求用戶輸入憑據,然後等待15分鐘(而惡意ETC APK則為10分鐘)。在此期間,惡意軟件攔截所有傳入的SMS,從而為攻擊者提供他們可能需要的所有2FA代碼。請注意,此應用程序不要求提供信用卡詳細信息。

惡意和合法應用程序登錄窗口之間的比較:

12.png

原始登錄窗口(左)和惡意APK輸入窗口(右)

如上所示,即使缺少某些GUI元素,惡意副本看起來也很好。

惡意約會APK約會應用程序不包含任何窗口。相反,它實際上充當了一個瀏覽器,引導用戶進入釣魚約會網站。但是,竊取和處理數據的原理是一樣的。

我們沒有與受害者交互的所有步驟的屏幕截圖,因為在撰寫本文時,負責處理從該APK竊取的數據的惡意服務器尚未激活。根據代碼,只有信用卡數據被盜,不需要憑證。

13.png

APK中顯示的釣魚交友網站窗口

所示消息的翻譯如下:

14.png

網絡釣魚網站上顯示的消息翻譯。

技術細節與分析純Android應用程序相比,分析基於flutter的應用程序需要一些中間步驟才能達到目的。

深度分析如上所述,Flutter使用自定義的虛擬環境來支持具有單一代碼庫的多平台開發。開發過程中使用了一種名為Dart的特定編程語言。分析Flutter平台代碼變得更容易了,因為它是一個開源項目,但仍然是一個繁瑣的過程。

15.png

Flutter Github頁面中的Dart演示

讓我們來看看在處理Flutter運行時的特殊領域時遇到的一些複雜情況。我們用哈希2811f0426f23a7a3b6a8d8b7e1bcd79e495026f4dcdc1c2fd218097c98de684解剖了一個APK。

ARM的Flutter運行時使用自己的堆棧指針寄存器(R15)而不是內置的堆棧指針(SP)。哪個寄存器用作堆棧指針在代碼執行或反向工程過程中沒有區別。然而,這對反編譯器來說有很大的不同。由於寄存器的使用不規範,會生成錯誤且難看的偽代碼。

啟動惡意軟件分析的一個好方法是確定與CC服務器的通信協議。這可以說明很多惡意功能。裡面有一個字符串,對應於我們在釣魚電子郵件中看到的網站:

16.png

惡意APK中字符串中CC服務器的地址

然而,當我們試圖找到對此字符串的一些引用時,分析失敗:

17.png

IDA中沒有對CC服務器字符串的引用

我們的目標是創建對該字符串的引用,以定位執行CC通信的代碼。

Flutter -re-demo和reFlutter可以用來處理Flutter應用程序,其主要思想是使用運行時快照來創建Dart對象並查找對它們的引用。 reFlutter的主要目的是收集函數的名稱,而flutter re-demo允許我們處理在應用程序執行期間收集的內存轉儲。

然而,除了內存快照之外,還需要一些更多的運行時信息。 Flutter運行時使用堆來創建對象,並將指向已創建對象的指針存儲在一個稱為對像池的特殊區域中。指向該池的指針被傳遞到寄存器X27中的方法。我們需要找到對像池的位置。

flutter-re-demo使用Frida收集內存轉儲並獲取對像池地址。如果我們使用在flutter-re-demo存儲庫中可用的dump_flutter_memory.js腳本運行APK,我們會看到所需的地址:

18.png

帶有所需地址的Frida腳本輸出

現在我們已經擁有了開始一個高效的逆向工程所需的所有元素。

在用map_dart_vm_memory.py加載轉儲文件並運行create_dart_objects.py腳本後,我們現在至少可以看到一些對象:

19.png

腳本創建的對象

有一個名為create_dart_objects.py的腳本,用於創建dart對象。該腳本通過遍歷對像池、解析記錄和創建對象來工作。腳本沒有關於這些對象的信息,腳本會為它們創建以下描述對象格式的結構:

20.png

這裡的NNN被“class id”取代,如下所示:

21.png

由create_dart_objects.py創建的結構

在Flutter應用程序逆向工程時,研究人員注意到最後一個字段(unk)經常被用作指針。可以考慮將該字段從簡單的QWORD轉換為OFFSET QWORD。這可能會給帶來一些誤報,但也可能非常有助於創建參考。因此,我們決定更改由腳本創建的unkin結構的字段類型。以下是對原始腳本的更改:

23.png

對dart_obj_create.py腳本的更改

研究人員提到的存儲庫包含一個用於創建對Dart對象引用的腳本:add_xref_to_art_objects.py。當運行它時,該腳本會遍歷代碼並創建對create_Dart_objects.py腳本創建的Dart對象的引用。不過此時仍然只有一個對我們感興趣的字符串的引用,即來自對像池的引用:

24.png

沒有對CC服務器URL的引用

我們的第一個想法是,也許根本沒有交叉引用?不過這不可能,存在幾個交叉引用,例如,這個對象就具有引用:

25.png

幾個從函數到對象的引用

這是從函數中引用的對象:

26.png

引用在函數代碼中的外觀

通過瀏覽add_xref_to_dart_objects.py的代碼,我們可以看到文件dart_obj_xref.py。該文件還遍歷代碼,嘗試根據寄存器X27提取對數據的引用,計算這些引用的偏移量,最後創建IDA引用。對代碼的分析表明,原始腳本支持訪問該對象的兩種ARM代碼變體:

27.png

代碼是否使用了一些其他指令來引用寄存器X27?讓我們檢查一下。為了方便起見,讓我們修改腳本,並為用X27處理的每條指令添加一條註釋:

28.png

dart_obj_xref.py修改

然後,我們可以檢查用X27處理的結構的反彙編程序列表,這些構造沒有附加對Dart對象的註釋引用。我們可以通過IDA生成一個列表文件並使用grep實用程序進行grep,從而部分自動化這些操作,如下所示:

29.png

首先,grep查找具有X27的所有字符串。然後,所有這些字符串都給了第二個grep命令,只打印那些不包含對Dart對象引用的字符串。因此,我們只看到不受支持的X27引用。

當檢測到不受支持的X27構造時,我們將在腳本中添加支持該構造的代碼。經過幾次迭代,我們終於獲得了對CC地址字符串的引用:

30.png

對CC地址字符串的引用

讓我們從sub_70FD611C0C開始檢查這些函數。簡要概述顯示,當與CC服務器通信時,此函數打算使用路徑為“/addcontent3”的HTTP POST方法來執行:

31.png

sub_70FD611C0C函數的偽代碼

另一個Dart對像也有對這個函數的引用:

32.png

對Dart對象的引用

當我們遍歷這些引用時,我們最終得到了帶有以下代碼的函數:

33.png

負責監聽所有傳入短信的代碼

此函數為所有傳入的短信安裝一個偵聽器。

為了確保我們做了正確的靜態分析,我們在運行時在一個真實的設備上檢查了這個函數。實際上,我們捕獲了一個發送到CC服務器的POST請求。

這是設備收到帶有“Fdsa”文本的短信後的CC請求示例:

34.png

因此,使用sub_70FD611C0C函數將短信洩露到CC服務器

除了被洩露的數據類型和服務器路徑之外,函數sub_70FD61EBC4和sub_70FD61EECC看起來與已經分析的sub_70FD 611C0C非常相似。這些函數分別使用路徑“/addcontent”和“/addcontent2”,用於洩露受害者的憑據和支付卡信息。

DEX代碼中沒有服務器通信的痕跡,因此我們可以假設所有通信都位於應用程序的Flutter部分。在分析了與命令控制服務器通信相關的所有功能之後,我們可以描述網絡協議。

CC通信CC協議旨在將數據從受攻擊設備發送到服務器。沒有命令可以在相反的方向上發送,即從服務器發送到受攻擊設備。 HTTPS用於傳輸數據,並且使用了幾個終端。

以下是我們在分析樣本中遇到的每個終端的介紹:

35.png

用於約會惡意應用程序的網絡誘餌變體使用了非常相似的協議。這是一個洩露信用卡數據的示例:

DEP(數據執行保護)是一種內存保護功能,允許系統將內存頁標記為不可執行。 ROP(面向返回的編程)是一種利用技術,允許攻擊者在啟用DEP等保護的情況下執行shellcode。在這篇文章中,我們將介紹應用程序的逆向過程,以發現緩衝區溢出漏洞,並開髮用於繞過DEP的ROP小工具鏈(Gadget Chain)。

我們將在開發過程中使用以下工具:QuoteDB、TCPView(一個查看端口和線程的小工具,只要木馬在內存中運行,一定會打開某個端口,只要黑客進入你的電腦,就有新的線程)、IDA Freeware、WinDbg(在windows平台下,強大的用戶態和內核態調試工具)和rp++。

QuoteDB是一個設計上易受攻擊的應用程序,創建它是為了實踐逆向工程並利用它進行開發。如下圖所示,該應用程序正在偵聽端口3700上的網絡連接:

1.jpg

我們已經使用TCPView確認程序確實在監聽端口3700。

2.jpg

現在我們需要對應用程序進行逆向工程,看看它是如何處理網絡連接的。 accept函數用於允許指定端口上的傳入連接,然後進程創建一個運行“handle_connection”例程的新線程,如下所示:

3.jpg

recv函數用於從連接的套接字接收數據:

4.jpg

我們已經開發了一個基本的Python腳本,它創建一個TCP套接字,並在端口3700上向遠程服務器發送1000個“a”字符:

5.jpg

我們已將WinDbg附加到QuoteDB.exe進程,並列出了加載的模塊,如下圖所示。

6.jpg

我們可以使用“bp”命令在recv函數調用後放置斷點,使用“bl”命令確認斷點已成功設置:

7.jpg

recv函數返回後,EAX寄存器包含以十六進制接收的字節數:

8.jpg

緩衝區的前4個字節表示一個操作碼,該操作碼被移到EAX寄存器中,然後打印在命令行中:

9.jpg

下圖顯示了WinDbg中的printf調用,我們可以觀察到第三個參數(=Opcode)由4個“A”字符組成:

10.jpg

該進程顯示源IP地址、源端口、緩衝區長度和十進制的操作碼:

11.jpg

應用程序從Opcode中減去0x384(十進制900),並將結果與4進行比較。這是一個帶有5個示例的開關,也顯示在下圖中。

12.jpg

EAX寄存器大於4,執行流被重定向到默認情況,該情況調用“log_bad_request”函數:

13.jpg

上述函數包含緩衝區溢出漏洞,如下圖所示,可執行文件在堆棧上分配0x818(2072)字節,用0初始化緩衝區,並在不檢查邊界的情況下將有效負載複製到此緩衝區:

14.jpg

發生溢出是因為要復制的字符數(0x4000)大於緩衝區的大小,並且可能會重寫返回地址:

15.jpg

我們選擇發送3000個“A”字符以利用該漏洞。如下所示,返回地址在堆棧上被重寫,程序因此崩潰:

16.jpg

17.jpg

我們使用了“msf-pattern_create”命令來生成一個唯一的模式,該模式將為我們提供偏移量。

18-1536x180.jpg

應用程序在不同的地址崩潰,該地址用於使用“msf-pattern_offset”命令確定精確的偏移量:

19.jpg

20.jpg

我們修改了概念證明,以包括上述偏移量。在正確的地址崩潰後,ESP寄存器指向我們控制的緩衝區的最後一部分:

21.jpg

22.jpg

我們使用了narly WinDbg擴展來顯示加載的模塊及其內存保護,下圖顯示了該可執行文件是在啟用ASLR和DEP保護的情況下編譯的。

23.jpg

Windows Defender Exploit Guard可以用來啟用/禁用ASLR。我們需要進入“Exploit protection settings”,選擇“Program settings”頁簽,點擊“Add Program to custom”,選擇“Choose exact file path”選項:

24.jpg

25.jpg

我們想通過發送從“\x00”到“\xFF”的所有字節並確定它們如何寫入堆棧來找出哪些字符被認為是“不適合”的:

26-1.jpg

如下圖所示,沒有不適合的字符,不過為了研究,我們將“\x00”視為不適合字符,因為它通常是不適合字符。正因為如此,漏洞開發過程稍微複雜一些,但它可能更容易適應其他應用程序。

27.jpg

我們使用rp++工具從“SysWOW64\kernel32.dll”模塊中提取ROP小工具,因為ASLR是禁用的,所以我們可以選擇任何提供必要ROP小工具的DLL,但是,我們將在以後的文章中看到應用程序洩漏特定DLL中的地址。我們已將小工具中的最大指令數設置為5:

28.jpg

29.jpg

由於DEP保護,堆棧不再是可執行的,我們需要找到執行shellcode的方法。我們可以使用VirtualAlloc、VirtualProtect和WriteProcessMemory等API來繞過DEP。 VirtualAlloc函數用於保留、提交或更改進程地址空間中頁面的狀態。該函數有4個參數:

lpAddress

dwSize

flAllocationType

flProtect

我們的目的是將flAllocationType參數設置為0x1000(MEM_COMMIT),將flProtect設置為0x40(PAGE_EXECUTE_READWRITE)。我們需要在堆棧上創建以下框架:

VirtualAllocaddress

Returnaddress(Shellcodeaddress)

lpAddress(Shellcodeaddress)

dwSize(0x1)

flAllocationType(0x1000)

flProtect(0x40)

我們為每個元素分配了一個特定的值,需要在運行時使用正確的值對其進行修改。

30-1.jpg

如下圖所示,可以在ESP寄存器的固定偏移處找到框架:

31.jpg

kernel32.dll模塊的起始地址可以使用WinDbg來標識。所有ROP小工具的地址必須使用該值而不是“ROP.txt”文件中的加載地址來計算:

32.jpg

首先,我們需要找到一個保存ESP寄存器值的ROP小工具。我們確定了一個將ESP寄存器複製到ESI寄存器的寄存器:

33.jpg

我們修改了Python腳本,以包含kernel32地址和上述ROP小工具偏移量,如下所示:

34-1.jpg

我們已經成功地將執行流程重定向到我們的第一個ROP小工具,接著將其他ROP小工具鏈接在一起,因為ESP仍然指向我們的緩衝區:

35.jpg

36.jpg

現在我們需要找到從ESI寄存器中減去0x1C的方法。然而,由於缺少涉及使用ESI寄存器進行計算的ROP小工具,我們找到了一個將ESI寄存器複製到EAX中的ROP小工具。唯一的問題是ESI也被“POP ESI”指令修改,但是,它不會影響我們的利用:

37.jpg

38.jpg

在許多ROP小工具中發現的另一個寄存器是ECX。我們已經確定了一個ROP小工具,它從堆棧中彈出一個值到ECX寄存器中,另一個小工具將EAX和ECX寄存器加在一起。加上負值等於減去相同的正值:

39.jpg

40.jpg

通過在之前的EAX值上添加-0x1C (=ECX)值,EAX指向VirtualAlloc框架:

41.jpg

因為EAX在任何計算中都很有用,所以我們需要在執行任何其他操作之前找到保存它的方法。我們發現了一個ROP小工具,它將EAX寄存器複製到ECX中,ECX將用於修改框架中的值。事實上,EAX也被這個ROP小工具修改了,但這並不影響我們的利用:

42.jpg

我們修改後的概念證明如下圖所示。 “junk”值對堆棧對齊很有用,對應於“POP reg”和“retn4”指令。

43.jpg

再次運行Python腳本後,我們可以觀察到ECX寄存器的值與之前的EAX寄存器相同,並指向VirtualAlloc框架:

44.jpg

IAT(導入地址表)包含指向由其他DLL導出的函數的指針。例如,kernel32.dll在VirtualAlloc的IAT中有一個條目,即使VirtualAlloc實際地址發生變化,該條目也保持不變:

45.jpg

我們使用了“POP EAX”指令將VirtualAlloc IAT複製到EAX寄存器中,需要對其進行解除引用才能獲得VirtualAlloc地址,如下所示:

46.jpg

47.jpg

在更新Python腳本並再次運行之後,我們成功地獲得了EAX中的VirtualAlloc地址:

(接上文)

現在,讓我們轉向攻擊者用來執行中間人攻擊的工具類型,並探討幾個示例。

MITM工具的分類進行中間人攻擊的工具有很多,因此在本文中,我們將只關注幾個最流行的工具。

讓我們根據使用它們的開放系統互連(OSI) 模型層對這些工具進行分類。

image.png

圖3. MITM 攻擊類型和工具取決於OSI 模型層

1. L2(數據鏈路層)在這一層,最常見的攻擊是ARP 欺騙和VLAN 跳躍。第一個我們已經在上面探索過。讓我們簡要討論後者。

VLAN 跳躍。 VLAN 網絡中的數據包具有特定的標記,以便在通過交換機時明確哪個數據包屬於哪個子網。網絡犯罪分子使用以下兩種方法之一執行VLAN 跳躍攻擊:

马云惹不起马云攻擊者連接到網絡並開始模仿交換機的工作,以便他們可以與網絡交換機建立連接。由於這種連接,數據包將在到達交換機之前通過攻擊者的計算機。

马云惹不起马云攻擊者向數據包添加額外的標記。網絡內的交換機會刪除自己的標記並進一步發送數據包。同時,攻擊者攔截帶有附加標記的數據包。如果攻擊者連接到網絡中的主交換機,此方法將起作用。

大多數命令行工具中的數據提取方案

image.png

圖4. 大多數命令行工具中的數據提取方案

現在,讓我們探索用於此類攻擊的工具。

BetterCAP是一款功能強大的工具,具有靈活的設置,可用於:

马云惹不起马云進行各種MITM 攻擊

马云惹不起马云實時操縱HTTP、HTTPS 和TCP 流量

马云惹不起马云嗅探網絡以查找用於身份驗證的數據

马云惹不起马云和更多

unfiltered-data-flow-received-through-the-bettercap-utility.png

圖5. 通過BetterCAP 實用程序接收的未過濾數據流

從BetterCAP 的第一個版本開始,專業的滲透測試人員就一直在選擇它。移動設備和軟件的開發人員以及物聯網領域的研究人員利用該實用程序測試設備安全性的能力。

BetterCAP 最方便的功能之一是能夠將所有收集的數據提取到外部文件中。為此,滲透測試者可以配置該實用程序來監聽它當前所在的整個網絡,或者監聽一個或多個指定的IP 地址。

BetterCAP 可以通過MAC 地址和特定子網進行配置,允許QA 專家在指定配置中搜索漏洞。

該實用程序支持APR 和DNS 欺騙以及流量嗅探,並進一步將數據提取到控制台或日誌中。提取的數據集包括:

马云惹不起马云訪問過的URL 和HTTPS 主機

马云惹不起马云HTTP POST 數據

马云惹不起马云HTTP Basic 和Digest 身份驗證

马云惹不起马云HTTP Cookie

马云惹不起马云FTP、IRC、POP、IMAP 和SMTP 憑證

BetterCAP 與HTTP/HTTPS(SSL 剝離和HSTS 繞過)和TCP 代理一起使用,可用於操縱HTTP/HTTPS 和現實生活中的低級TCP 流量。使用標准設置,代理僅記錄請求。但是您可以使用一組模塊配置它們的設置,或者您可以添加自己的自定義模塊並以您想要的方式操縱流量。

Arpspoof是專為在本地網絡中進行ARP 欺騙而設計的實用程序。它發送兩個請求——一個到服務器,一個到選定的計算機或計算機——接收它們的MAC 地址,用它自己替換從服務器到客戶端的ARP 響應,並用它自己或另一個替換受害者的默認網關IP地址。 Arpspoof 的主要任務是流量嗅探。

Arpspoof 支持啟動第三方腳本。該實用程序應更多地被視為熟悉ARP 欺騙的培訓程序,而不是工作工具,因為Arpspoof 功能有限,沒有解密器,應用領域狹窄。

2. L3(網絡層)在網絡層,最常見的MITM 攻擊是無狀態地址自動配置攻擊和ICMP 重定向。讓我們探索它們是如何工作的。

無狀態地址自動配置(SLAAC) 攻擊會重新配置啟用IPv6的網絡。允許IPv6 但沒有任何設置的組織網絡是一個常見漏洞。在SLAAC 攻擊中,攻擊者向IPv6 主機提供前綴、前綴長度和沒有DHCPv6 服務器的默認網關地址。例如,如果攻擊者創建自己的路由器廣告(RA),他們可以成為網絡中的主路由器,整個數據流將通過他們的計算機。

ICMP 重定向。使用ICMP 的原因之一是動態更改目標網絡中的路由表。最初,ICMP 旨在防止消息以非最佳方式發送並提高網絡穩定性。網絡的某個部分(連接到互聯網)可以有多個路由器。如果其中一個斷開,主路由器向所有網絡設備發送ICMP 請求,並重寫路由表以在新條件下工作。

在ICMP 重定向攻擊中,攻擊者要么等待其中一個路由器關閉,要么自行禁用它。然後,攻擊者開始從所有路由器發送ICMP 請求。結果,形成了一個新的網絡,其中攻擊者成為網絡節點之一。在ICMP 重定向攻擊期間,攻擊者可以指定目標網站只能通過攻擊者的路由器訪問。

讓我們看一下用於ICMP 重定向攻擊的幾個工具。

寄生蟲6。此實用程序是一個類似於BetterCAP 但功能有限且設置最少的ARP 欺騙程序。它連接到本地網關並傳輸所有網絡流量。它向控制台輸出一條消息,指定數據包發送給誰以及誰必須接收它。 parasite6 工具最好與可以讀取通過它的數據包的實用程序一起使用。

假路由器6。啟動時,此實用程序會向網絡發送一個信號,指定攻擊者的路由器在網絡中具有最高優先級。然後網絡重新配置自己,使從指定子網進入外部網絡的最後一步通過攻擊者的計算機。結果,最初發送到路由器的所有數據都將通過安裝了fake_router6 的攻擊者計算機。

DOS-新-ip6。該實用程序的主要任務是在重複的ip6 請求期間向重複地址檢測(DAD) 進程提供虛假數據。這使攻擊者有機會在網絡內創建節點。節點地址將與另一個網絡節點的地址相同,仍然使控制器認為只有一個客戶端具有這樣的地址。結果,數據將被發送到兩個節點,包括攻擊者的節點。

利用6 . 此工具是一種漏洞掃描程序,可向目標計算機發送多個請求。它接收響應並向控制台輸出數據,指定目標計算機具有哪些已知漏洞。

thcping6。此實用程序允許為ping6 請求創建自定義數據包。它允許您修改數據包大小、數據類型和其他參數。首先,攻擊者為數據包和目標計算機指定一組選項。然後,他們發送一個數據包並接收響應。通過擬合某些數據包,惡意行為者可以使目標系統拒絕響應特定請求(發送響應錯誤消息)。然後,了解數據包的特性後,他們可以使用其他實用程序來創建相同的數據包,但發送多個數據包。這將使系統過載,導致系統故障或其中一個節點發生故障。

3. L4+(傳輸層)在傳輸層,攻擊者可以應用鏈路本地多播名稱解析欺騙、NetBIOS 欺騙、DHCP 欺騙和流氓DHCP 欺騙。

鏈路本地多播名稱解析(LLMNR) 欺騙。如果出於某種原因,Windows 客戶端無法使用DNS 獲取主機名,它將嘗試使用LLMNR 協議來獲取主機名,並向最近的計算機發送請求。該技術通過IPv4和IPv6 地址起作用。

NetBIOS 欺騙。如果LLMNR 欺騙不起作用,攻擊者可以使用NetBios 名稱服務。它類似於LLMNR 並且用於相同的目標,但它僅適用於IPv4 地址。這個想法是,如果附近的某些計算機即使提供虛假信息也可以響應,則響應將被視為有效。

DHCP 欺騙。此攻擊的目的是強制客戶端使用攻擊者的主機作為默認網關,以及使用攻擊者配置的DNS 和WINdows Internet Name (WINS) 服務器。攻擊者的任務是在網絡中配置一個虛假的DHCP 服務器,用於向客戶端發送DHCP 地址,並耗盡合法DHCP 服務器的地址池。

成功的DHCP 欺騙攻擊有兩個條件:

马云惹不起马云客戶端從非法服務器接收IP 比從合法服務器更快

马云惹不起马云合法服務器有一個耗盡的地址池

流氓DHCP。惡意DHCP 攻擊的主要目標是使用偽造的DHCPv6 服務器將流量從受害者的計算機重新發送到攻擊者的計算機。惡意行為者截獲DHCP 消息請求並對其進行響應,模擬實際的DHCPv6 服務器。

以下是可用於此類L4+ 攻擊的幾種工具:

埃特卡普。這個實用程序內置在Kali Linux中。它易於配置並具有圖形用戶界面,這使得熟悉它變得簡單快捷。 Ettercap 允許您執行ARP 中毒、ICMP 重定向、端口竊取、DHCP 欺騙和NDP 中毒。

使用Ettercap 時,您可以即時查看、分析甚至執行一些操作。它向您顯示連接狀態,並允許您以文本格式查看從所選連接收集的所有數據。

Ettercap 的主要缺點是缺少數據解密工具。因此,如果使用加密保護網絡,您將需要使用其他實用程序。 Ettercap 的功能比BetterCap 弱得多,但它可以用於信息和教育目的。

ettercap-user-interface.png

圖6. Ettercap 用戶界面

斯納爾夫。此實用程序設計用於處理smb、ftp 和類似的流量類型。要使用它,您首先需要有一個可以工作的欺騙器(我們使用了BetterCAP)。通過欺騙器的所有流量都會重新發送到Snarf,Snarf 會挑選出負責遠程連接(如smb 和ftp)的流量。通過Snarf 的任何其他流量都不會顯示在控制台或服務頁面上。

Snarf 向控制台輸出有關數據目的地、數據大小、哈希、地址、端口、連接類型和錯誤的信息。它還顯示潛在內存洩漏的錯誤。收集到的數據摘要以表格形式輸出到服務頁面,其中包含有關連接、計算機和系統的主要信息。此外,Snarf 提供了過期或阻止連接的機會。

但是,此實用程序僅適用於Linux,並且配置它可能非常不明顯。

中間人6。此工具偵聽攻擊者計算機的主網絡接口,以攔截來自網絡中其他計算機的IPv6 地址請求(通過應用DHCPv6 請求)。

使用標准設置,系統(連接到主路由器的設備網絡)會定期發送DHCPv6 請求。 mitm6 實用程序使用受害者的新地址響應這些請求。在現實生活中的網絡中,客戶端的地址將由網絡中的客戶端計算機分配,但在mitm6 請求攔截的情況下,受害者的地址將由mitm6 分配。這使惡意行為者有機會將自己的計算機分配為服務器。因此,所有受害者的連接都將通過攻擊者的計算機。

這僅適用於Windows,因為Mac 和Linux 不使用DHCPv6 請求來確定IP 和DNS 服務器。 mitm6 工具並不聲稱自己是一個中心節點,因此它不會攔截來自網絡中所有計算機的信號。相反,它選擇性地欺騙特定主機。

一旦受害者收到新的DNS 服務器地址,受害者就會連接到該服務器,Web 代理自動發現協議(WPAD) 漏洞就會在該服務器上進行。一旦受害者的計算機接收到作為DNS 服務器的IPv6 攻擊者的地址,它就會開始發送WPAD 網絡配置請求。對於IPv4 或IPv6 請求,攻擊者會將其地址發送給受害者。

然後,攻擊者必須與受害者的計算機交換身份驗證數據。由於這不能直接在受害者的計算機上完成,攻擊者將模擬代理服務器。結果,所有輸入用於身份驗證的數據都將發送到最終服務器和攻擊者。但受害者不會注意到它。

上述所有工具都可用於滲透測試,以檢查網絡安全、檢測漏洞並修復它們。通過這種方式,企業可以防止真正的網絡犯罪分子可能進行的攻擊,並保護他們的網絡連接和敏感數據。

結論在本文中,我們探討了幾種類型的中間人攻擊,並描述了網絡犯罪分子如何使用MITM 工具攔截數據。在此類攻擊中,受害者什麼都沒有註意到,並且有一種錯誤的安全感。無論組織是小型初創公司還是大型公司,都應該建立強大的網絡安全性。

中間人(MITM) 攻擊是一個嚴重的網絡安全問題,尤其是在物聯網領域,攻擊者使用它們來闖入網絡並攔截數據。個人用戶和公司都容易受到此類攻擊,因為我們都使用大量聯網設備。

為了減輕MITM 攻擊並將其成功執行的風險降至最低,我們需要了解MITM 攻擊是什麼以及惡意行為者如何應用它們。此外,滲透測試人員可以利用中間人攻擊工具來檢查軟件和網絡是否存在漏洞,並將其報告給開發人員。因此,開發人員可以修復產品的弱點,防止真正的網絡犯罪分子可能的MITM 攻擊。

在本文中,我們將討論MITM 基礎知識:這些攻擊是什麼以及它們的目的。我們將了解在MITM 攻擊的每個階段會發生什麼,並探討用於執行MITM 攻擊的幾種流行實用程序的功能、優缺點。

本文不是關於如何執行MITM 攻擊的指南,但它解釋了使用MITM 工具如何幫助滲透測試者檢測漏洞。

MITM 攻擊:定義和後果什麼是中間人攻擊?中間人(MITM) 攻擊是一種網絡攻擊,惡意行為者在其中秘密中繼並可能改變認為他們直接相互通信的兩方之間的通信。

例如,攻擊者可以將受害者的計算機和服務器(網站、服務或任何其他網絡資源)之間的連接切換到攻擊者作為服務和受害者之間的中介的連接。

image.png

圖1. MITM 攻擊方案

MITM 攻擊的目標是訪問用戶的個人數據或用戶訪問的某些資源的數據。如果用戶訪問組織的資源,攻擊者可能會訪問組織網絡中存儲和流通的任何數據,例如銀行數據、用戶憑據、照片、文檔和消息。

MITM 攻擊最常見的受害者是使用大量數據操作的Web 資源:金融組織的網站、SaaS 資源、電子商務網站和其他需要在線授權的服務。

中間人攻擊背後的危險MITM 攻擊的後果是什麼?成功的MITM 攻擊的後果可能導致企業的財務和聲譽損失。

截獲的數據為惡意行為者提供了敲詐他人或以他人為代價購買商品的機會。此外,攻擊者可以使用受害者的憑據來損害公司:例如,通過安裝惡意軟件從公司網絡竊取數據。

MITM 攻擊背後的一個共同意圖是盜竊金錢。 2015 年,有49 名嫌疑人在不同的歐洲國家被捕,他們涉嫌使用MITM 攻擊來嗅探和攔截電子郵件中的付款請求。調查發現了一項總額為600 萬歐元(約合680 萬美元)的國際欺詐計劃。

2019 年,黑客通過攔截一家風險投資公司的100 萬美元電匯,成功敲詐了一家以色列初創公司。惡意行為者執行MITM 攻擊,攔截和編輯來自雙方的每封電子郵件,並註冊虛假域以欺騙雙方。

網絡犯罪分子使用社會工程學並設法將惡意軟件植入目標公司的網絡。使用該惡意軟件,他們通過攔截電子支付交易進行了大量MITM 攻擊。

了解MITM 攻擊的類型將如何幫助您增強軟件測試如何防止中間人攻擊?在滲透測試中,使用中間人攻擊工具的主要目標是發現和修復軟件和網絡中的漏洞。質量保證(QA) 工程師在軟件完全開發後使用MTM 實用程序來測試軟件的潛在易受攻擊部分。然後開發人員可以修復發現的問題並增強產品的安全性,防止真正的攻擊者進行潛在的MITM 攻擊。

本文中描述的實用程序不僅可用於執行攻擊,還可用於測試網絡和軟件安全性。使用MITM 工具檢查產品的保護有助於發現惡意行為者可以利用這些漏洞竊取數據並造成財務和聲譽損失。

此類MITM 工具對物聯網設備製造商特別有用,因為它們可以幫助他們檢查一個網絡中各種設備之間的連接的安全性以及設備和服務器之間連接的安全性。通過徹底的滲透測試,製造商可以生產出高質量的設備,防止未經授權的訪問。

模仿MITM 攻擊有助於QA 專家更好地了解可能的攻擊場景、分析其原因並提出對策。

MITM 攻擊如何運作? MITM 攻擊包括兩個主要步驟:攔截和解密。每個都有自己的子步驟。讓我們簡要探討一下最常見的。

image.png

兩步中間人攻擊

1.可以使用被動或主動攻擊來完成攔截:1.1。被動攻擊。網絡犯罪分子創建一個網絡接入點,允許他們通過互聯網連接到網絡。當受害者連接到網絡時,網絡犯罪分子可以完全訪問和控制受害者的數據流。

1.2. 主動攻擊。此方法包括各種欺騙技術:

马云惹不起马云 IP 欺騙——用目標IP 地址代替攻擊者的地址;將受害者發送到虛假網站而不是原始網站

马云惹不起马云ARP 欺騙– 將受害者發送到的MAC 地址替換為受害者APR 表中攻擊者的地址。因此,當受害者向節點發送數據時,數據將被發送到攻擊者的地址。

马云惹不起马云DNS 欺騙– 入侵DNS 服務器、DNS 緩存中毒和替換指定地址。在這種情況下,受害者被定向到攻擊者的地址。

2.解密攔截數據後,攻擊者以服務器和客戶端都不會注意到中斷的方式對其進行解密。以下是惡意行為者用於這些目的的一些方法:

马云惹不起马云 HTTPS 欺騙– 也稱為同形異義詞攻擊,HTTPS 欺騙是指將目標域中的字符替換為外觀非常相似的其他非ASCII 字符。這種攻擊利用了Punycode——一種允許以非ASCII 格式註冊域的標準。為了進行此類攻擊,網絡犯罪分子註冊一個看起來像目標站點的域並註冊SSL 證書,使虛假網站看起來合法且安全。然後,攻擊者將指向虛假網站的鏈接發送給受害者,受害者認為他們正在使用受保護的網站。

马云惹不起马云SSL BEAST – 這種類型的攻擊將惡意JavaScript 代碼注入會話中,這有助於攻擊者獲得對站點cookie 的訪問權限。這會破壞加密模式,因此網絡犯罪分子會收到解密的cookie 和身份驗證密鑰。

马云惹不起马云SSL 劫持——通過SSL 劫持,有效的計算機會話被利用來獲得對計算機系統中信息或服務的未經授權的訪問。大多數Web 應用程序使用一種登錄機制,該機制生成一個會話令牌以供以後使用,而無需在每個頁面上輸入憑據。通過SSL 劫持,攻擊者使用嗅探器工具攔截流量並識別用戶的令牌以將請求發送到服務器而不是用戶。

马云惹不起马云SSL 剝離– SSL 剝離攻擊利用了大多數用戶訪問SSL 網站的方式。通常情況下,當用戶連接到安全網站時,連接是通過以下方式建立的:

1.連接到網站的HTTP 版本

2.重定向到HTTPS 版本

3.連接到HTTPS 版本

4.服務器顯示證明站點合法的安全證書

5.連接已建立

但是,在SSL 剝離攻擊期間,惡意攻擊者會替換步驟二和三,因此所有客戶端的數據都通過攻擊者的節點傳輸。

image.png

圖2. SSL 剝離攻擊方案

remote_desktop_abstract-e1654695169351.jpeg

互聯網協議(IP)地址及其背後的設備、網絡服務和雲資產是現代企業的生命線。但公司經常積累數千個數字資產,無序的狀態給IT和安全團隊造成了無法管理的混亂。如果不仔細地加以檢查,一個被遺忘、遺棄或未知的數字資產對於公司來說就是網絡安全定時炸彈。

為什麼查看和管理網絡中的每個數字事物都應是重中之重?這當中存在一種可能:它們是您組織基礎設施中增長最快的部分。有效的數字資產管理——包括IP地址可見性——是您阻止攻擊者對網絡資產發動攻擊的最基礎也是最有效的途徑。

在過去的二十年裡,安全團隊一直專注於解決內部資產風險。面向公眾的數字資產和IP地址是“非軍事化區”的一部分,“非軍事化區”是一個防禦的強化但非常有限的周邊地區。但在全球大流行和隨之而來的居家辦公趨勢的推動下,數字化轉型隨之而來,網絡邊界變得不再清晰,都需要讓位於當今一切託管服務的現代架構。

數字資產:死亡、遺忘和危險過去兩年的業務數字化轉型引發了一場新的網絡應用程序、數據庫和物聯網設備的海嘯。他們為威脅組織創造了一個巨大的新攻擊面,其中包括複雜的雲原生IT基礎設施。可能暴露的是數千個API、服務器、物聯網設備和SaaS資產。

管理不善的數字資產是一顆定時炸彈。例如,在網絡應用程序中存在巨大風險。在最近的CyCognito調查中,我們發現Global 2000組織平均每個組織有5000個暴露的Web界面,佔其外部可能受到攻擊表面的7%。在這些Web應用程序中,我們發現不乏開源JavaScript漏洞庫問題,如jQuery、JQuery-UI和Bootstrap。 SQL注入、XSS和PII暴露漏洞也不短缺。

任何面向外部的資產未知或管理不善,都可以被視為邀請對手破壞您的網絡的機會。然後,攻擊者可以竊取數據、傳播惡意軟件、破壞基礎設施並實現持續的未經授權訪問。

當我們與公司談論他們的攻擊面時,我們很少聽到他們對掌握數字資產表示信心。許多公司仍然通過Excel電子表格跟踪IP地址,並反過來連接資產。這種措施是否高效?事實上這僅適用於最小的組織。 ESG在2021年的一項研究發現,73%的安全和IT專業人士依賴他們。

數據安全是頭等大事,這也是貴公司的皇冠珠寶。我認為,保護IP地址和連接資產應該採取更現代的管理方法,這樣就可以在問題出現之前解決這些問題。

善意可能會出錯但即使是善意的公司也可能犯錯誤。假設企業服務台創建的內部票務系統只能通過內部URL訪問。對手可能會利用URL的基礎IP地址,並通過添加“:8118”來打開網絡後門(或端口)。這就是為什麼IP地址,包括端口、域和證書等相關技術,可能帶來巨大的安全和聲譽風險。

其結果可能是數字資產軟點的墓地,這些軟點經常成為對手的切入點,例如被遺忘或管理不善的DevOps或SecOps工具、雲產品和設備Web界面。

在當今復雜的企業中,系統管理員通常只能看到他們負責管理的設備子集。如果資產不在您的雷達屏幕上,您將無法真正地降低風險。

為什麼管理IP連接的資產就像養貓一樣在過去的12個月裡,通過對CyCognito的客戶群觀察調研,我們看到組織內IP地址(和相關數字資產)的數量增長了20%。這一增長至少部分歸功於雲的採用以及對居住在公司網絡的連接設備和Web應用程序的依賴。但經常被忽視的是,當公司增長或萎縮時,基礎設施會蔓延。

例如,在繞過IP地址管理方面,合併和收購(併購)活動通常會讓企業保持平穩。假設酒店集團收購了較小的競爭對手。當這種情況發生時,它還繼承了一個由未管理和未知的IP地址和域組成的潛在雷區。

死亡域名和被遺忘域名——一種不同類型的數字資產——經常成為所謂的懸垂DNS記錄的犧牲品,對手可以通過重新註冊來接管被遺忘的子域名。這些子域以前連接到公司資源,但現在完全由不良行為者控制,然後可用於改變公司的網絡流量,造成數據丟失和聲譽損害。

同樣,子公司的剝離可能導致基礎設施被遺棄,成為孤兒數字資產和相關網絡應用程序。這些被遺忘的資產經常被IT團隊忽視,但絕對不會被機會主義黑客忽視。

更糟糕的是,不安全的端口使設備可以進行默認憑據攻擊。畢竟,對於對手來說,要掃描和查找開放的端口,他們需要管理不善的雲服務或IP連接的硬件。

最後,通過收購獲得的不受管理的IT基礎設施和資產可能會浪費寶貴的時間。考慮一下管理不善的IP地址如何向IT安全團隊發送高度戒備狀態,以了解為什麼公司資產在它不開展業務的國家/地區被使用。

為了保護關鍵數據,阻止惡意軟件感染並防止漏洞,部分答案是進行有效的數字資產管理以及提高IP地址可見性。太多的系統管理員仍然受制於這個過時的基於電子表格的資產管理系統。

此外,忽略攻擊載體並僅檢測已知資產中CVE的遺留掃描儀無法評估與公司內部大量數字資產相關的風險。例如,在之前的內部票務系統中——通過URLhttps://X.X.X.X[:]8118意外暴露在互聯網上——該IP上的端口掃描充其量只能找到HTTP服務。掃描儀肯定不會理解曝光的背景和關鍵性。公司擁有的雲資產上意外打開目錄也是如此,儘管這些目錄可能包含員工憑據和TB的敏感數據。

無知不是幸福看到就是相信當然,默認情況下,數字資產並不危險。相反,風險與IT堆棧的管理以及系統管理員處理與預置、非預置、託管和非託管服務綁定的眾多連接應用程序的能力有關。

難題擺在公司的面前:“你如何管理你不知道的東西?”

實施網絡分割,零信任解決方案和積極的IP和端口掃描,以及資產發現,都是對減輕威脅問題的必要響應。但這些解決方案並沒有100%解決問題。

這就像根據20%的居民的檢測,給社區一份乾淨的新冠肺炎健康法案。沒有其他80%的測試,你真的不知道自己是否安全。即使對90%的攻擊表面進行完美的漏洞管理,當10%可能看不見和不受管理時,這也不是無關緊要的事。

與低效的發現工具相關的成本和修復發現問題的IT資源有限也是有效攻擊表面管理的障礙。

攻擊表面管理需要圍繞“發現”暴露的關鍵資產的新心態。持續發現那些大規模攻擊者抵抗力最小的路徑,加上安全測試和將寶貴資產被盜的風險聯繫起來,至關重要。 CyCognito正在圍繞暴露和風險管理與緩慢、有限範圍和昂貴的漏洞管理開拓這個想法。

想像一下,看到您的整個攻擊表面——以及您的子公司的攻擊表面——並能夠根據風險簡介對修復進行優先排序,該風險簡介告訴您特定資產被黑客入侵的概率。在數字資產的背景下,了解您的整個IP環境並優先考慮需要首先解決的問題,可以大大有助於實現更安全的IT環境。

大局?對手總是尋求阻力最小的道路。他們避免了更難的攻擊路徑,因為它們往往很吵,增加了後衛檢測和響應的風險。現代外部攻擊表面管理方法應該利用資產補救優先級相同的最不耐藥性路徑原則,同時減少回收(MTTR)的時間,並回答以下問題:“我們安全嗎?”

Rob Gurzeev是外部攻擊表面管理公司CyCognito的首席執行官兼聯合創始人。他是一名進攻性安全專家,專注於提供網絡安全解決方案,幫助組織找到並消除攻擊者利用的路徑。

許多入侵和攻擊都是從終端被惡意軟件感染開始的。惡意軟件的傳播通常以誘騙某人打開一個可執行文件為手段,這些誘騙文件是良性的,例如一個常見的軟件實用程序,但實際上是惡意的。傳播惡意軟件最常見的方法之一是通過垃圾郵件,但還有其他方法,比如,一種長期使用的將惡意軟件植入系統的技術在去年年末重新出現。

“Malvertising”是惡意軟件和廣告的合成詞,其技術包括購買搜索引擎廣告,並在這些廣告中放置指向惡意網站的鏈接。自從與搜索相關的點擊付費(PPC)廣告出現以來,這種技術就一直被攻擊者使用,但最近不知出於什麼原因,這種技術被使用的頻率和數量出乎意料。接下來,我們將介紹惡意廣告是如何運作的,針對它的一些防禦措施,以及最近如何利用它來分發惡意軟件的例子。

PPC的工作原理谷歌的PPC廣告平台是攻擊者用來傳播惡意軟件的主要媒介。 Intel 471 曾詳細介紹過建立Google Ads活動的內容。這些文章介紹了很多關於這些攻擊者如何開展活動的信息,以及他們如何為自己的廣告獲得頂級搜索結果的一些理論。

谷歌的PPC廣告管理面板具有一個相當直觀的設計,允許用戶一目了然地查看他們的廣告活動統計數據。用戶可以查看他們當前的廣告、關鍵字、推薦、統計數據和每次優惠的總成本。用戶必須提供一個URL來創建廣告,顯示URL的路徑,提供優惠的描述,並為廣告製作一些標題。描述、標題和網站都被被納入谷歌用來計算廣告排名的公式中。

一旦創建了廣告,用戶可以設置廣告在PPC上花費的最大金額。廣告位的銷售採用了一種盲拍賣機制,廣告客戶可以出價高於競爭對手,但無法看到其他人對廣告位的出價。谷歌以前的廣告排名算法考慮的是廣告商為廣告植入排名的出價,然而,新系統綜合考慮了廣告出價、描述、標題和網站檢查。

一旦用戶創建了廣告並設定了投標價格,他們就可以開始使用Google Ads平台上的多種工具。通過設備定位,廣告商可以為只在平板電腦或手機等特定類型的設備上播放的廣告定價。

客戶可以在Google Ads面板的“受眾”選項卡中使用額外的目標定位。用戶可以監控點擊廣告的人的人口統計數據,創建有針對性的廣告,或排除某些人口統計數據,並針對特定類型的人,如在金融服務或酒店業工作的人。該平台還允許廣告商根據地理位置和受眾跟踪,或包括城市、州和郵政編碼在內的各種因素來定位客戶。

1.webp.jpg

2023年1月26日谷歌PPC廣告平台的廣告客戶目標選項的截圖

BokBotBokBot,也被稱為IcedID,是一種銀行木馬,也可以下載其他惡意軟件。 BokBot的開發人員與Conti勒索軟件組織和Trickbot(另一種用於傳播勒索軟件的銀行惡意軟件和殭屍網絡)一直有關聯。在過去的一年中,最初的訪問代理(IAB)越來越多地使用BokBot作為網關惡意軟件進行攻擊,以取代現已失效的BazarLoader或Trickbot家族。 2022年12月和2023年1月,BokBot運營商開始嘗試使用谷歌PPC廣告平台進行分發。

這些BokBot活動的流量分配系統(TDS)在谷歌搜索廣告引擎指向的登錄頁面上使用受害者和木馬過濾。此過濾確保連接客戶端不是來自虛擬專用網絡(VPN)IP地址,使用戶代理檢查並遵循超文本傳輸協議(HTTP)'GET'標頭條件。如果連接不符合條件,用戶不會被重定向到BokBot惡意登陸頁面,而是停留在廣告網站上,而廣告網站可能與目標應用程序或品牌無關。該網站通常與活動無關。符合目標標準的連接將被重定向到BokBot惡意登陸頁面,並且永遠不會看到廣告站點。

最近的BokBot活動偽裝成操作系統虛擬化平台Docker的廣告。惡意廣告包含拼寫錯誤的域名,並且似乎高於Docker的合法報價。一旦用戶點擊廣告鏈接,BokBot的第一個URL劫持域就會執行一些基本的木馬過濾,以確定廣告的觀看者是否是目標的合法受害者,而不是研究人員。如果基於用戶代理、用戶代理客戶端提示或地理位置的檢查失敗,Docker活動的登錄頁面將引導查看者進入一個關於如何設置和使用Docker的虛假教程。

2.webp.jpg

2023年1月26日,出現在合法Docker搜索結果和廣告之前的惡意Docker廣告截圖

BatLoader和EugenLoader/FakeBat惡意軟件加載器,也稱為“下載器(滴管)”,是系統上的初始感染,然後被攻擊者用來下載其他惡意代碼。 BatLoader於2022年2月被發現,是一種利用微軟軟件安裝程序(.msi)和PowerShell的加載器。

Intel 471最近發現,兩個不同的攻擊者正在通過不同的命令和控制(C2)基礎設施分發BatLoader。 Mandiant在2022年確定為BatLoader的活動涉及.MSI在安裝期間執行.BAT文件。然而,第二個活動不涉及.BAT文件的執行。相反,該惡意軟件有一個內嵌的PowerShell腳本,它會代替.BAT文件執行。由於這些差異,Intel 471分析師決定將第二次活動更名為EugenLoader,它也被稱為FakeBat。

由於之前的報告混合了EugenLoader和BatLoader,因此很難確定EugenLoaders何時首次出現。但它可能會在2022年11月或12月運行。在對EugenLoader的調查中,我們發現一個域名似乎被用作新活動的下載目的地。域的根目錄被錯誤地打開並顯示了EugenLoader活動的.MSI文件。如下圖所示,EugenLoader惡意軟件已被重命名為模擬已知軟件,如FileZilla、uTorrent和WinRAR等。

3.webp.jpg

可疑EugenLoader活動的域的根目錄處於打開狀態

在分發活動中,EugenLoader建立了一些域名,聲稱提供合法的流行軟件,但其實這是惡意軟件。

EugenLoader最活躍的惡意廣告活動之一是偽裝成WinRAR,這是一種用於壓縮和提取文件的流行軟件實用程序。雖然其他廣告活動似乎間歇性地將其廣告放在搜索結果的頂部,但WinRAR廣告活動沒有這樣的限制,這使得攻擊者能夠欺騙受害者不斷安裝EugenLoader。

EugenLoader還通過欺騙7-Zip(另一種流行的文件歸檔軟件)的惡意廣告活動進行分發。使用精心製作的谷歌搜索廣告,該活動能夠將其下載鏈接放置在7-Zip官方下載頁面之前,如下圖所示。

4.webp.jpg

有兩個PPC廣告提供7-Zip,但域名與官方項目無關

直到最近,惡意廣告還不是攻擊者首選的攻擊手段,與電子郵件垃圾郵件等傳統手段相比,它很少被使用。然而,EugenLoader背後的運營商能夠購買始終出現在谷歌第一搜索結果位置的廣告。惡意廣告技術有可能挑戰惡意軟件垃圾郵件(malspam)作為攻擊者首選載體的位置。

惡意軟件開發者投放惡意廣告有利有弊。首先,攻擊者可以通過廣告吸引尋找下載工具的用戶,出現在第一個搜索結果中意味著很有可能有人在沒有仔細查看域名的情況下點擊。隨後的登錄頁面看起來與合法登錄頁面完全相同,人們很可能會下載並安裝該工具。

這與垃圾郵件相比具有優勢,垃圾郵件可能會被安全工具捕獲並隔離,或者被發送到垃圾郵件文件夾,永遠不會被潛在受害者註意到。如果目標確實下載了它,攻擊者必須誘騙其打開,例如打開發票、點擊鏈接或運行可執行文件。但惡意廣告抓住了那些想下載並立即運行的人。

然而,惡意廣告的成本並不便宜。每次點擊點擊付費廣告的成本可能高達2至3美元。由於攻擊者不斷競標廣告位,這些行動也提高了合法廣告商的成本。有可能是惡意商家用偷來的信用卡信息來支付廣告費用。另外,攻擊者是如何為這些廣告買單的,這將是另一個值得研究的課題,它可能會挖掘出這些活動背後的團體。

在某些情況下,活動的成功與否可以衡量。一些惡意廣告將受害者引導到Bitbucket上的網站,這可能會顯示下載數量。其中一項活動的下載量超過3000次。按每次點擊2美元計算,投放廣告的人可能已經支付了多達6000美元,這表明攻擊者有經濟實力。在這些活動中發現的其他類型的惡意軟件包括RedLine等信息竊取軟件。惡意軟件經常阻礙VirusTotal提交。文件大小高達700 MB,這與滴管或加載器的典型大小相比非常大。 VirusTotal的文件大小限制為32 MB(最多可提交200 MB的文件),這意味著由分發的惡意文件不一定會有分析示例。

總結惡意廣告激增,對谷歌影響最大,在2023年1月中旬達到頂峰,此後有所下降。安全社區已經就其調查結果與穀歌取得聯繫。幾位研究人員製作了一份電子表格,用於跟踪惡意廣告活動和被假冒的品牌。在2023年1月19日至2023年2月22日期間,該電子表格包含了584起惡意廣告活動的示例。此外,研究人員還開發了一些工具,比如Randy McEoin開發的這個工具,它可以搜索惡意廣告,Michael McDonnell開發的這個工具也可以對活動截圖留證。

作者簡介萬紹遠,CNCF 基金會官方認證Kubernetes CKACKS 工程師,雲原生解決方案架構師。對ceph、Openstack、Kubernetes、prometheus 技術和其他雲原生相關技術有較深入的研究。參與設計並實施過多個金融、保險、製造業等多個行業IaaS 和PaaS 平台設計和應用雲原生改造指導。

前言NeuVector 是業界首個端到端的開源容器安全平台,唯一為容器化工作負載提供企業級零信任安全的解決方案。 NeuVector可以提供實時深入的容器網絡可視化、東西向容器網絡監控、主動隔離和保護、容器主機安全以及容器內部安全,容器管理平台無縫集成並且實現應用級容器安全的自動化,適用於各種雲環境、跨雲或者本地部署等容器生產環境。

此前,我們介紹了NeuVector 的安裝部署、高可用架構設計和多雲安全管理(超鏈接:https://mp.weixin.qq.com/s/kOGNT2L2HVMibyyM6Ri2KQ),本篇將演示NeuVector的基礎功能,主要包括:

1.安全漏洞管理

2.合規性檢查和機密性檢查

3.策略管理

4.准入控制策略

5.動態安全響應

6.行為監控

項目地址:https://github.com/neuvector/neuvector

本文主要基於NeuVector 首個開源版NeuVector:5.0.0-preview.1 進行介紹。

1.安全漏洞管理NeuVector 集成了CVE 漏洞庫,每天自動更新,支持對平台(Kubernetes)、主機、容器、鏡像倉庫進行安全漏洞掃描。

配置自動掃描,當平台漏洞庫有更新,或有新的節點和容器加入時,會自動進行掃描。

image001.png

針對不同漏洞,有不同的風險級別提示、對應的組件版本提示和修復版本提示。

image003.png

image005.png

針對每個漏洞,NeuVector 可以展示對應的漏洞發佈時間、漏洞影響範圍、對應的組件影響版本。

image007.png

對漏洞進行過濾,檢測是否已經修復,以及漏洞等級、發佈時間等。

image009.png

1.1.配置對接鏡像倉庫漏洞掃描支持對接多種鏡像倉庫如docker-registry(harbor)、JFrog Artifactory、Nexus 等。

image011.png

以對接Harbor 為例。配置連接方式,填寫連接方式和認證信息,過濾器表示需要掃描的範圍,如掃描uat 項目下全部鏡像則`uat/*`,如果需要掃描整個Harbor 內全部鏡像則*。測試設置可以驗證編寫的表達式的關聯情況。

image013.png

2.合規性檢查和機密性檢查NeuVector 的合規性審核包括CIS 基線測試、自定義檢查、機密審核以及PCI、GDPR 和其他法規的行業標準模板掃描。

image015.png

“類型”表示對應的那個基線標準,如K.4.1.1 對應Kubernetes CIS 基線測試,4.1.1 容器對應的基線標準為D 開頭,鏡像對應的基線標準為I 開頭。

注:GDPR (General Data Protection Regulation,《通用数据保护条例》 )為歐盟條例。

在合規性檢查中也會檢查是否存在密文洩漏情況。

image018.png

包括如以下密文洩漏情況:

GeneralPrivateKeys

Generaldetectionofcredentialsincluding'apikey','api_key','password','secret','passwd'etc.

Generalpasswordsinyamlfilesincluding'password',passwd','api_token'etc.

Generalsecretskeysinkey/valuepairs

PuttyPrivatekey

XmlPrivatekey

AWScredentials/IAM

Facebookclientsecret

Facebookendpointsecret

Facebookappsecret

TwitterclientId

Twittersecretkey

Githubsecret

SquareproductId

Stripeaccesskey

SlackAPItoken

Slackwebhooks

LinkedInclientId

LinkedInsecretkey

GoogleAPIkey

SendGridAPIkey

TwilioAPIkey

HerokuAPIkey

MailChimpAPIkey

MailGunAPIkey3.策略管理NeuVector 通過組的方式對容器和主機進行管理,對組進行合規性檢查、網絡規則、進程和文件訪問規則、DLP/WAF的檢測配置。

NeuVector 會自動將當前集群主機加入到nodes 組,對於集群內容器會自動創建以nv.開頭的組。

image019.png

NeuVector 的組支持3種模式:學習模式、監控模式和保護模式;各個模式實現作用如下:

學習模式學習和記錄容器、主機間網絡連接情況和進程執行信息。

自動構建網絡規則白名單,保護應用網絡正常行為。

為每個服務的容器中運行的進程設定安全基線,並創建進程配置文件規則白名單。

監控模式NeuVector 監視容器和主機的網絡和進程運行情況,遇到非學習模式下記錄的行為將在NeuVector 中進行告警。

保護模式NeuVector 監視容器和主機的網絡和進程運行情況,遇到非學習模式下記錄的行為直接拒絕。

新建的容器業務被自動發現默認為學習模式,也可以通過設置將默認模式設置為監控模式或保護模式。

不同組策略衝突情況下,適用的有效模式如下表:

c3bc204721128e4570e1681fbe59b3c.png

為了保證業務的穩定運行,當出現模式不一致時,有效模式以限制最小的模式運行。

生產環境最佳實踐使用路徑可以是:

上新業務時,先學習模式運行一段時間,進行完整的功能測試和調用測試,得到實際運行此業務的網絡連接情況和進程執行情況信息。

監控模式運行一段時間,看看有沒有額外的特殊情況,進行判斷,添加規則。

最後全部容器都切換到保護模式,確定最終形態。

3.1.動態微隔離使用場景一:POD 間通過網絡策略互相隔離

在Kubernetes 平台中創建四個Nginx,名稱和用途如下:

workload_name:test-web1 image:nginx 用途:web服務器

workload_name:test-con1 image:nginx 用途:連接客戶端1

workload_name:test-con2 image:nginx 用途:連接客戶端2

workload_name:test-con3 image:nginx 用途:連接客戶端3

創建workload

kubectlcreatedeploymenttest-web1--image=nginx

kubectlexposedeployment/test-web1--port=80--type=NodePort

kubectlcreatedeploymenttest-con1--image=nginx

kubectlcreatedeploymenttest-con2--image=nginx

kubectlcreatedeploymenttest-con3--image=nginx此時在NeuVector 中會自動生成這幾個組:

image021.png

在test-con1 中通過curl 訪問test-web1

image023.png

此時可以正常訪問,因為在學習模式下NeuVector 也會自動添加此訪問規則。

image025.png

將test-web1 和test-con2 都設置為監控模式

image027.png

然後在test-con2 中curl 訪問test-web1

image029.png

此時test-con2 可以正常訪問test-web1,但在NeuVector 中會生成告警

image031.png

同時,相應地,在網絡活動拓撲圖中也可以看見對應的連接鏈路變為紅色。

image033.png

將test-web1 和test-con2 都設置為保護模式,在通過test-con2 去curl test-web1

image035.png

因為curl 在學習模式時沒有使用,也不是NeuVector 默認允許的可執行進程,所以進程直接就無法訪問了。

將test-con1 設置為保護模式,此時test-con1 無法訪問外部網絡。

可以通過自定義添加網絡規則方式開通訪問。

image037.png

在網絡規則頁,此處規則已經是在學習模式下生成的規則列表。

添加外部訪問規則

image039.png

NeuVector 深度了解應用程序行為,並將分析有效負載,以確定應用程序協議。協議包括:HTTP,HTTPS,SSL,SSH,DNS,DNCP,NTP,TFTP,ECHO,RTSP,SIP,MySQL,Redis,Zookeeper,Cassandra,MongoDB,PostgresSQL,Kafka,Couchbase,ActiveMQ,ElasticSearch,RabbitMQ,Radius,VoltDB,Consul,Syslog,Etcd,Spark,Apache,Nginx,Jetty,NodeJS,Oracle,MSSQL 和GRPC。

現在test-con1 的curl 可以正常訪問www.baidu.com

總結:

除上述策略外,NeuVector 也內置網絡威脅檢測,能夠快速識別常用網絡攻擊,保護業務容器安全運行。

無論保護模式如何,在“學習和監視”模式下,NeuVector 將發出警報,並且可以在“通知安全事件”中找到這些威脅。在保護模式下將收到警報和阻止;還可以根據威脅檢測創建響應規則。

包含的威脅檢測如下:

SYNfloodattack

ICMPfloodattack

IPTeardropattack

TCPsplithandshakeattack

PINGdeathattack

DNSfloodDDOSattack

DetectSSHversion1,2or3

DetectSSLTLSv1.0

SSLheartbeedattack

DetectHTTPnegativecontent-lengthbufferoverflow

HTTPsmuggingattack

HTTPSlowlorisDDOSattack

TCPsmallwindowattack

DNSbufferoverflowattack

DetectMySQLaccessdeny

DNSzonetransferattack

ICMPtunnelingattack

DNSnulltypeattack

SQLinjectionattack

ApacheStrutsRCEattack

DNStunnelingattack

TCPSmallMSSattack

CipherOverflowattack

Kubernetesman-in-the-middleattackperCVE-2020-85543.2.進程管理NeuVector 支持對容器和主機內進程進行管理,在學習模式下,運行的進程和命令會自動添加到規則中。

image041.png

此時在test-con1 中執行df -h 會發現報錯bash: /bin/df: Operation not permitted

在nv.test-con1.default 組中添加df 進程規則:

image043.png

image045.png

然後再重新執行即可。

進程管理也支持對node 節點,可以在node 組中進行限制,約束宿主機進程執行。如限制執行docker cp 執行,通過學習模式得知是`docker-tar` 進程在後端執行,將節點切換到保護模式,限制`docker-tar` 進程即可。

這些在節點就無法執行`docker cp`

4.准入策略控制NeuVector 支持與Kubernetes 准入控制(admission-control)功能對接,實現UI 配置准入控制規則,對請求進行攔截,對請求的資源對象進行校驗。

NeuVector 支持多種准入控制策率配置,如鏡像CVE 漏洞情況限制、部署特權模式、鏡像內使用root 用戶、特定標籤等。

在策略-准入控制中開啟此功能,注意:需要Kubernetes 集群提前開啟admission-control

功能

image047.png

NeuVector 准入策略控制支持兩種模式:監控模式和保護模式,對應的含義和組的模式一樣的。這裡我們直接切換到保護模式,添加策略。

image049.png

image051.png

添加完後,在Rancher 中部署特權模式,容器會提示解決,策略生效。

image053.png

5.動態安全響應NeuVector 事件響應機制可以將響應規則設置為根據安全事件情況進行動態響應,包括以下事件:漏洞掃描結果、CIS 基準測試、准入控制事件等。

image055.png

響應動作包括隔離、webhook 通知和日誌抑制:

image057.png

隔離模式:對應的容器網絡進出流量將全部被切斷。

Webhook 通知:將觸發信息通過webhook 方式進行告警。

日誌抑制:對觸發告警信息進行抑制。

6.行為監控以CVE 漏洞配置為例,配置包含CVE 漏洞名稱為CVE-2020-16156 的容器進入隔離模式。

image059.png

組名對應的是影響範圍,如果為空,表示對全部的組都生效,填寫組名可以設置對特定組生效。

配置策略後,在集群去curl nginx 容器,發現無法訪問,在NeuVector 中查看容器狀態為隔離狀態。

image061.png

刪除策略時,也可以配置將對應隔離狀態容器解除隔離。

注意:

隔離操作不適用於為主機事件觸發的規則。

每個規則可以有多個操作。

6.1.網絡流量可視化image063.png

網絡流量可視化,可以清晰可見容器集群內的網絡連接關係、當前容器連接會話,並且過濾網絡連接信息,進行圖標展示;能夠快速進行網絡問題定位。

6.2.POD 流量抓包針對容器可進行網絡抓包,讓故障無需進入主機獲取高權限,就能進行網絡問題深入排查。

image065.png

image067.png

採集到的數據包可直接下載,通過Wireshark 進行解包分析。

總結本次我們主要講解了NeuVector 的基礎功能,後續將深入介紹DLP 和WAF 的配置策略和管理使用。

持久性機制XorDdos使用各種持久性機制,在系統啟動時會自動支持不同的Linux發行版,如下所示。

初始化腳本惡意軟件會在/etc/init.d位置放置一個初始化腳本。初始化腳本是用於在系統啟動時運行任何程序的啟動腳本。它們遵循Linux標準基礎(LSB)樣式的標頭部分,包括默認運行級別、描述和依賴項。

13.png

放置在/etc/init.d/HFLgGwYfSC.elf位置的init腳本的內容

Cron腳本惡意軟件在/etc/cron.hour/gcc.sh的位置創建一個cron腳本。該cron腳本傳遞的參數如下:

14.png

gcc.sh腳本內容

然後它會創建一個/etc/crontab文件以每三分鐘運行一次/etc/cron.hourly/gcc.sh:

15.png

從/etc/crontab文件中刪除/etc/cron.hourly/gcc.sh條目並添加新條目的系統命令

16.png

文件“/etc/crontab.conf”的內容

SystemV運行級別運行級別是init和系統的一種模式,用於指定UnixsystemV-Style操作系統正在運行哪些系統服務。運行級別包含一個值,通常編號為0到6,每個值指定不同的系統配置,並允許訪問不同的進程組合。一些系統管理員根據他們的需要設置系統的默認運行級別,或者使用運行級別來識別哪些子系統正在工作,例如網絡是否正常運行。 /etc/rc run_level 目錄包含符號鏈接(符號鏈接),符號鏈接是指向原始文件的軟鏈接。這些符號鏈接指向應在指定的運行級別運行的腳本。

這個惡意軟件為放置在/etc/init.d/base_file_name 位置的init 腳本創建一個符號鏈接,這些目錄與/etc/rc run_level .d/S90 和/etc/rc.d/rc run_level .d/S9 base_file_name 0 base_file_name 的runlevels 1 到5 相關聯。

17.png

使用/etc/init.d/base_file_name 安裝rc.d 目錄的符號鏈接腳本

自動啟動服務該惡意軟件運行一個命令來安裝啟動服務,這些服務會在啟動時自動運行XorDdos。惡意軟件的LinuxExec_Argv2子例程使用提供的參數運行系統API。

命令chkconfig–add service_name 和update-rc.d 然後添加一個在引導時啟動守護進程的服務。

18.png

chkconfig和update-rc.d命令安裝啟動服務

基於參數的代碼流程XorDdos具有與提供給程序的參數數量相對應的特定代碼路徑。這種靈活性使它的操作更加健壯和隱秘。惡意軟件首先在沒有任何參數的情況下運行,然後運行另一個帶有不同參數的實例,比如pid和假命令,以執行清理、欺騙和持久化等功能。

在處理基於參數的控件之前,它調用readlinkAPI,第一個參數為/proc/self/exe以獲取其完整的進程路徑。完整路徑稍後用於創建自動啟動服務條目並讀取文件內容。

以下是不同參數的功能:

1.不帶任何參數的標準代碼路徑此代碼路徑描述了惡意軟件的標準工作流程,這也是XorDdos作為在系統啟動位置創建的條目的一部分運行的典型工作流程。

惡意軟件首先檢查它是否從/usr/bin/、/bin/或/tmp/位置運行。如果它沒有從這些位置運行,那麼它會在這些位置以及/lib/和/var/run/上使用10個字符的字符串名稱創建並自我複制。

它還在/lib/libudev.so位置創建了自己的一個副本。為了避免基於哈希值的惡意文件查找,它執行以下步驟,修改文件哈希值,使每個文件都是唯一的:

只有寫入時才會打開文件;

調用lseek(fd,0,SEEK_END)指向文件中的最後一個位置;

創建一個10個字符的隨機字符串;

在文件末尾寫入帶有額外空字節的字符串;

修改文件後,它運行二進製文件,執行雙fork(),並從磁盤中刪除其文件。

19.png

惡意軟件文件的末尾包含兩個隨機字符串,“wieegnexuk”和“yybrdajydg”,表明原始惡意軟件二進製文件被修改了兩次

2.清理代碼路徑在此代碼路徑中,惡意軟件使用作為PID提供的另一個參數運行,例如:

/usr/bin/jwvwvxoupv4849使用上面的示例,惡意軟件與IPC密鑰“0xDA718716”共享64字節大小的內存段,以檢查作為參數提供的另一個惡意軟件進程。如果沒有找到,它會運行自己的二進製文件而不帶任何參數,並調用fork()API兩次以確保第三代子進程沒有父進程。這導致第三代進程被init進程採用,從而將其與進程樹斷開連接並充當反取證技術。

另外,它在提供的$pid上執行以下任務:

獲取與提供的$pid對應的進程文件名;

刪除提供的$pid文件;

刪除已安裝的init服務:

刪除/etc/init.d/file_name

對於運行級別1-5,取消鏈接並刪除/etc/rc runlevel .d/S90 file_name

執行chkconfig-del file_name 命令;

執行update-rc.d file_name 刪除

結束作為參數提供的進程。

3.進程名欺騙代碼路徑這個惡意軟件生成了帶有兩個附加參數的新的被刪除的二進製文件:一個假的命令行及其PID,例如:

20.png

虛假命令可以包括:

21.png

在此代碼路徑中,惡意軟件使用進程名稱欺騙通過在運行時修改其虛假命令行來隱藏進程樹。然後,它通過使用命令“1”調用HidePidPort來隱藏其進程,並讀取與當前進程相關的磁盤上文件的內容。

然後,它進入一個5秒的循環,執行以下檢查:

3.1通過調用/proc/$pid/exe上的readlinkAPI,獲取特定於作為第三個參數的一部分提供的$pid的文件名。

3.2如果readlink調用失敗,這可能表明磁盤上的文件不存在。在這種情況下,會發生以下5種情況:

3.2.1打算刪除$pid的所有服務相關條目但失敗。這似乎是由於一個代碼缺陷造成的,當緩衝區應該從成功的readlinkAPI調用中填充時,該漏洞允許將歸零緩衝區作為服務名稱傳遞。

3.2.2創建類似於標準代碼路徑方案的目錄。

3.2.3調用文件/lib/libudev.so的statAPI。如果statAPI返回一個非零值,那麼它會嘗試將先前獲取的當前進程的圖像文件的內容複製到以下位置,並使用隨機名稱:

/usr/bin/

/bin/

/tmp/3.2.4如果對/lib/libdev.so的statAPI調用成功,則將/lib/libudev.so文件複製到上面列出的相同的三個目錄中。

3.2.5更改寫入或複製文件的哈希值,然後在不傳遞任何參數的情況下運行它。

3.3如果readlink調用成功並返回複製的字節數,則休眠一秒鐘,然後在五秒鐘內循環剩餘時間。

3.4取消隱藏當前進程和作為第三個參數的一部分提供的$pid;

3.5刪除當前進程的磁盤文件。

4.沒有提供任何參數的已知位置代碼路徑此代碼路徑與標準代碼路徑相似,主要區別在於惡意軟件從以下位置運行:

22.png

一旦它從其中一個位置運行,惡意軟件就會調用以下函數來執行各種任務:

4.1InstallSYS——顧名思義,這個函數是一個應該部署rootkit驅動程序的包裝器,但它只清零兩個本地數組。

23.png

虛擬InstallSYS例程

4.2AddService——創建前面提到的持久自動啟動項,以便惡意軟件在系統啟動時運行。

4.3HidePidPort——隱藏惡意軟件的端口和進程。

4.4CheckLKM——檢查rootkit設備是否處於活動狀態。它使用數字“0x9748712”和命令“0”的類似IOCTL調用來查找rootkit是否處於活動狀態。如果rootkit處於活動狀態,它會使用所有者值“0xAD1473B8”和組值“0xAD1473B8”通過函數lchown( 文件名、0xAD1473B8、0xAD1473B8)。

4.5decrypt_remotestr——使用相同的XOR密鑰“BB2FA36AAA9541F0”解碼遠程URL,以解碼config.rar和其他目錄。解碼URL後,它將它們添加到一個遠程列表中,該列表稍後用於從命令和控制(C2)服務器通信和獲取命令:

www[.]enoan2107[.]com:3306

www[.]gzcfr5axf6[.]com:3306

惡意活動線程在創建持久條目、刪除其活動證據並解碼config.rar之後,惡意軟件使用sem_initAPI初始化循環冗餘校驗(CRC)表,後跟未命名的信號量。該信號量使用apshared值設置為“0”進行初始化,從而使生成的信號量在所有線程之間共享。信號量用於維護訪問共享對象的線程之間的並發性,例如kill_cfg數據。

然後惡意軟件初始化三個線程來執行惡意活動,例如停止進程、創建TCP連接和檢索kill_cfg數據。

24.png

信號量和惡意線程初始化

kill_processkill_process線程執行以下任務:

解碼加密字符串;

獲取/var/run/gcc.pid的文件統計信息,如果不存在,則創建文件;

獲取/lib/libudev.so的文件統計信息,如果不存在,則創建目錄/lib並在/lib/libudev.so位置創建自身的副本;

獲取與當前進程相關的磁盤文件信息;如果失敗,則退出循環並停止當前進程;

從kill_cfg中讀取內容,並根據配置文件中匹配的指定項執行相應的操作,如停止進程或刪除文件,例如:

25.png

tcp_threadtcp_thread觸發與之前使用decrypt_remotestr()解碼的C2服務器的連接。它執行以下任務:

讀取文件/var/run/gcc.pid的內容,獲取一個唯一的32字節魔術字符串,用於在連接C2服務器時識別設備;如果該文件不存在,則創建該文件並使用一個隨機的32字節字符串對其進行更新。

計算CRC標頭,包括設備的詳細信息,例如魔術字符串、操作系統版本、惡意軟件版本、rootkit存在、內存統計信息、CPU信息和LAN速度。

加密數據並將其發送到C2服務器。

等待從C2服務器接收以下任何命令,然後使用exec_packet子例程對該命令進行操作。

26.png

系統信息收集

daemon_get_killed_processdaemon_get_killed_processthread從之前解碼的遠程URL(hxxp://aa[.]hostasa[.]org/config[.]rar)下載kill_cfg數據,並使用前面提到的相同XOR密鑰對其進行解密。然後它會休眠30分鐘。

27.png

daemon_get_killed_process線程函數從遠程URL獲取並解碼kill_cfg數據

DDoS攻擊線程池惡意軟件調用sysconf(_SC_NPROCESSORS_CONF)來獲取設備中的處理器數量。然後,它創建的線程數量是設備上找到的處理器數量的兩倍。

在內部調用每個線程都會調用線程例程threadwork。使用全局變量“g_stop”和從C2服務器接收的命令,threadwork然後發送精心製作的數據包65535次以執行DDoS攻擊。

28.png

如何防禦Linux平台的威脅XorDdos的模塊化特性為攻擊者提供了一種多功能木馬,能夠感染各種Linux系統架構。它的SSH暴力攻擊是一種相對簡單但有效的技術,可用於獲得對許多潛在目標的root訪問權限。

XorDdos擅長竊取敏感數據、安裝rootkit設備、使用各種規避和持久性機制以及執行DDoS攻擊,使攻擊者能夠對目標系統造成潛在的重大破壞。此外,XorDdos可用於引入其他危險威脅或為後續活動提供載體。

XorDdos和其他針對Linux設備的威脅都表明,擁有跨越眾多Linux操作系統發行版、具有全面能力和完整可見性的安全解決方案是多麼重要。 MicrosoftDefenderforEndpoint提供了這樣的可見性和保護,以捕捉這些新出現的威脅,其下一代反惡意軟件和終端檢測和響應(EDR)功能。利用來自集成威脅數據的威脅情報,包括客戶端和雲啟發式、機器學習模型、內存掃描和行為監控,MicrosoftDefenderforEndpoint可以檢測和補救XorDdos及其多階段模塊化攻擊。這包括檢測和防止其使用惡意shell腳本進行初始訪問、從全局可寫位置放置並執行二進製文件以及終端上的任何潛在後續活動。

在過去的六個月裡,微軟的研究人員發現一種名為XorDdos的Linux木馬的活動增加了254%。 XorDdos是由MalwareMustDie研究團隊於2014年首次發現的,其名稱來源於其在Linux終端和服務器上的拒絕服務相關活動,以及其在通信中使用基於XOR的加密。

存在於linux的操作系統的XorDdos惡意軟件越來越多,而linux操作系統通常部署在雲基礎設施和物聯網設備上。通過破壞物聯網和其他聯網設備,XorDdos積累了可用於執行分佈式拒絕服務(DDoS)攻擊的殭屍網絡。使用殭屍網絡執行DDoS攻擊可能會造成重大破壞,例如微軟在2021年8月緩解的2.4TbpsDDoS攻擊。由於多種原因,DDoS攻擊本身可能會帶來很大的問題,但此類攻擊也可以用作掩護隱藏進一步的惡意活動,例如部署惡意軟件和滲透目標系統。

殭屍網絡也可以被用來危害其他設備,XorDdos以使用SecureShell(SSH)暴力攻擊來獲得對目標設備的遠程控製而聞名。 SSH是IT基礎設施中最常見的協議之一,它可以在不安全的網絡上進行加密通信以實現遠程系統管理,使其成為攻擊者的首選工具。一旦XorDdos識別出有效的SSH憑證,它就使用根權限運行一個腳本,該腳本將下載XorDdos並將其安裝到目標設備上。

XorDdos使用規避和持久性機制,使其操作保持穩健和隱秘。它的規避能力包括混淆惡意軟件的活動、規避基於規則的檢測機制和基於哈希的惡意文件查找,以及使用反取證技術來破壞基於進程樹的分析。研究人員在最近的活動中觀察到,XorDdos通過用空字節覆蓋敏感文件來隱藏惡意活動以防止分析。它還包括支持不同Linux發行版的各種持久性機制。

1.png

XorDdos惡意軟件的典型攻擊載體

XorDdos還被用來傳遞其他危險的威脅。研究人員發現,最先被XorDdos感染的設備後來又被其他惡意軟件感染,比如Tsunami後門,該後門進一步部署了XMRig挖礦程序。雖然研究人員沒有觀察到XorDdos直接安裝和傳播像Tsunami這樣的二級有效負載,但該木馬有可能被用作後續活動的載體。

MicrosoftDefenderforEndpoint通過檢測和修復木馬在其整個攻擊鏈中的多階段模塊化攻擊以及終端上的任何潛在後續活動來防止XorDdos。在本文中,研究人員將詳細分析XorDdos,以幫助防御者了解其技術並保護他們的網絡免受這種隱秘惡意軟件的攻擊。

初始訪問XorDdos主要通過SSH暴力進行傳播。它使用一個惡意的shell腳本在數千個服務器上嘗試各種根憑據組合,直到在目標Linux設備上找到匹配項。因此,研究人員在成功感染惡意軟件的設備上看到許多失敗的登錄嘗試:

2.png

在受XorDdos影響的設備上嘗試登錄失敗

研究人員的分析確定了XorDdos的兩種初始訪問方法。第一種方法是將惡意ELF文件複製到臨時文件存儲/dev/shm中,然後運行它。 /dev/shm中寫入的文件會在系統重啟時被刪除,從而在取證分析過程中隱藏感染源。

第二種方法涉及運行一個bash腳本,該腳本通過命令行執行以下活動:

1、迭代以下文件夾以找到一個可寫目錄:

/bin

/home

/root

/tmp

/usr

/etc2、如果已找到可寫目錄,則將工作目錄更改為已找到的可寫目錄。

3、使用curl命令從遠程位置下載ELF文件有效負載hxxp://Ipv4PII_777789ffaa5b68638cdaea8ecfa10b24b326ed7d/1[.]txt並將文件保存為ygljglkjgfg0。

4、將文件模式改為“可執行”。

5、運行ELF文件負載。

6、移動和重命名Wget二進製文件,以規避惡意使用Wget二進製文件所觸發的基於規則的檢測。在這種情況下,它將Wget二進製文件重命名為good,並將文件移動到以下位置:

mv/usr/bin/wget/usr/bin/good

mv/bin/wget/bin/good7、嘗試第二次下載ELF文件有效負載,現在只使用filegood而不是Wget二進製文件。

8、運行ELF文件後,使用反取證技術通過用換行符覆蓋以下敏感文件的內容來隱藏其過去的活動:

3.png

初始訪問使用的遠程bash腳本命令

無論使用哪種初始訪問方法,結果都是一樣的:運行惡意ELF文件,即XorDdos惡意軟件。接下來,我們將深入研究XorDdos有效負載。

XorDdos有效負載分析本文研究分析的XorDdos有效負載是一個32位ELF文件,沒有被用過,這意味著它包含調試符號,詳細說明了惡意軟件的每個活動的專用代碼。與丟棄這些符號的被污染過的二進製文件相比,包含調試符號使調試和反向工程非污染二進製文件更容易。在這種情況下,未污染的二進製文件包括以下與符號表條目關聯的源代碼文件名,它們是ELF文件中.strtab部分的一部分:

crtstuff.c

autorun.c

crc32.c

encrypt.c

execpacket.c

buildnet.c

hide.c

http.c

kill.c

main.c

proc.c

socket.c

tcp.c

thread.c

findip.c

dns.c上面的源代碼文件名列表表明二進製文件是用C/c++編程的,並且它的代碼是模塊化的。

反檢測能力XorDdos包含具有逃避檢測的特定功能模塊,詳細信息如下。

守護進程(Daemonprocess)守護進程是一個在後台運行而不是在用戶控制下的進程,它與控制終端分離,僅在系統關閉時終止。與某些Linux惡意軟件系列類似,XorDdos木馬使用守護進程(如下詳述)來破壞基於進程樹的分析。守護進程(Daemon)是一類在後台長期運行的特殊進程,一般在系統引導時開始啟動,一直運行到系統關閉。守護進程一般用於提供某種服務,比如log打印守護進程syslogd,任務規劃守護進程crond,實現Dbus總線功能的dbus守護進程等。

1、惡意軟件調用子程序daemon(__nochdir,__noclose)將自己設置為後台守護進程,該進程在內部調用fork()和setsid()。 fork()API創建一個與調用進程具有相同進程組ID的新子進程。

2、成功調用fork()API後,父進程通過返回“EXIT_SUCCESS(0)”停止。目的是保證子進程不是組進程的leader,這是setsid()API調用成功的前提。然後它調用setsid()將自己與控制終端分離。

3、如果調用第一個參數__nochdir的值等於“0”,則守護程序子例程還具有將目錄更改為根目錄(“/”)的規定。守護進程將目錄更改為根分區(“/”)的原因之一是因為從掛載的文件系統運行進程會阻止卸載,除非進程停止。

4、它將第二個參數__noclose傳遞為“0”,以將標準輸入、標準輸出和標準錯誤重定向到/dev/null。它通過在/dev/null的文件描述符上調用dup2來做到這一點。

5、惡意軟件調用多個信號API以忽略來自控制終端的可能信號,並在終端會話斷開時將當前進程與標準流和掛斷信號(SIGHUP)分離。執行這種規避信號抑制有助於阻止標準庫嘗試寫入標準輸出或標準錯誤或嘗試從標準輸入讀取的影響,這可能會阻止惡意軟件的子進程。 APIsignal()將信號符號的處置設置為處理程序,它是SIG_IGN、SIG_DFL或程序員定義的信號處理程序的地址。在本例中,第二個參數被設置為'SIG_IGN=1',它忽略了與signum對應的信號。

6.png

忽略與終端相關操作相關的信號

基於XOR的加密顧名思義,XorDdos使用基於xor的加密來混淆數據。它調用dec_conf函數來使用XOR秘鑰“BB2FA36AAA9541F0”對編碼字符串進行解碼。下表顯示了在惡意軟件的各個模塊中用於執行其活動的混淆數據的解碼值。

7.png

進程名稱欺騙當一個進程啟動時,參數作為以null結尾的字符串提供給它的main函數,其中第一個參數始終是進程映像路徑。為了欺騙其進程名稱,XorDdos在運行時將所有參數緩衝區清零,並使用虛假命令行(例如catresolv.conf)覆蓋它的第一個包含圖像路徑的參數緩衝區。

8.png

通過修改與參數向量關聯的內存來實現進程名稱欺騙

9.png

'ps-aef'的輸出包含一個'catresolv.conf'條目

內核rootkit一些XorDdos示例安裝內核rootkit。 rootkit是一個內核模塊,通過修改操作系統數據結構來隱藏惡意代碼的存在。 XorDdos內核rootkit通常具有以下功能:

提供根訪問;

隱藏內核模塊;

隱藏惡意軟件的進程;

隱藏惡意軟件的網絡連接和端口;

根據在rootkit中發現的調試符號,XorDdos的rootkit代碼很可能受到了名為rooty的開源項目的啟發。下表描述了rootkit中的符號及其相應的功能:

10.png

進程和端口隱藏該惡意軟件試圖使用其內核rootkit組件隱藏其進程和端口。隱藏進程有助於惡意軟件規避基於規則的檢測。

/proc文件系統包含與所有正在運行的進程相關的信息。用戶模式的進程可以通過讀取/proc目錄來獲取任何與進程相關的信息,該目錄包含系統中每個正在運行的進程的子目錄,例如:

/proc/7728——包含與進程ID(PID)7728相關的信息;

/proc/698——包含PID698相關信息;

運行strace-eopenps命令檢查/proc/$pid上的open調用的踪跡,以獲取ps命令中正在運行的進程的信息。

11.png

如果惡意軟件隱藏了$pid特定目錄,它可以隱藏從用戶模式獲取相應進程。

在本例中,惡意軟件可以通過發送帶有附加信息的輸入和輸出控制(IOCTL)調用來與其rootkit組件/proc/rs_dev進行通信,以採取適當的措施。 IOCTL是用戶模式服務和內核設備驅動程序之間通信的一種方式。該惡意軟件使用數字“0x9748712”從系統中的其他IOCTL調用中唯一識別其IOCTL調用。

除了這個數字,它還傳遞一個整數數組。數組中的第一個條目對應於命令,第二個條目存儲要操作的值,例如$pid。

12.png

SentinelLabs 在Microsoft Azure Defender for IoT 中發現了許多影響雲和本地客戶的嚴重漏洞。

未經身份驗證的攻擊者可以通過濫用Azure 密碼恢復機制中的漏洞遠程攻擊受Microsoft Azure Defender for IoT 保護的設備。

SentinelLabs的調查結果已於2021年6月主動報告給微軟,這些漏洞被定義為CVE-2021-42310、CVE-2021-42312、CVE-2021-37222、CVE-2021-42313 和CVE-2021-42311,且標記為嚴重,一些CVSS 得分甚至為10.0。

Microsoft 已發布安全更新以解決這些嚴重漏洞。鼓勵用戶立即採取行動。

目前,SentinelLabs 尚未發現野外濫用的證據。

技術細節運營技術(OT) 網絡雖然很流行,但是,其中許多技術在設計時並未考慮到安全性,並且無法通過傳統的IT 安全控制進行保護。與此同時,物聯網(IoT) 所連接的數十億設備大大增加了攻擊面和安全風險。

但供應商並沒有忽視這個問題,許多供應商都提供了安全解決方案以試圖解決這個問題,但如果安全解決方案本身就存在著漏洞怎麼辦?在本文中,我們將討論Microsoft Azure Defender for IoT 中發現的嚴重漏洞,這是Microsoft Azure 的IoT/OT 網絡安全產品。

首先,我們會介紹密碼重置機制中的漏洞如何被遠程攻擊者濫用以獲得未經授權的訪問。然後,我們討論了Defender for IoT 中的多個SQL 注入漏洞,這些漏洞允許遠程攻擊者無需身份驗證即可獲得訪問權限。最終,提出有關安全產品本身的安全性及其對易受攻擊部門安全態勢的整體影響的嚴重問題。

Microsoft Azure Defender for IoTMicrosoft Defender for IoT 是一種無代理網絡層安全性,用於持續的IoT/OT 資產發現、漏洞管理和威脅檢測,無需更改現有環境。它可以完全部署在本地或與Azure 連接的環境中。

1.jpg

該解決方案由兩個主要組件組成:

Microsoft Azure Defender For IoT Management——使SOC 團隊能夠管理和分析從多個傳感器聚合到單個儀表板的警報,並提供網絡安全狀況的整體視圖。

Microsoft Azure Defender For IoT Sensor – 發現並持續監控網絡設備。傳感器使用物聯網和OT 設備上的被動(無代理)監控來收集ICS 網絡流量。傳感器連接到SPAN 端口或網絡TAP,並立即開始對IoT 和OT 網絡流量執行DPI(深度數據包檢測)。

這兩個組件既可以安裝在專用設備上,也可以安裝在VM 上。

深度包檢測(DPI) 是通過負責分析網絡流量的Horizon 組件實現的。 Horizon 組件加載內置解析器,並且可以擴展以添加自定義網絡協議解析器。

物聯網Web 界面攻擊面防禦管理和傳感器共享大致相同的代碼庫,配置更改以適應設備的用途。這就是為什麼兩台設備都受到大多數相同漏洞影響的原因。

兩台設備上暴露的最吸引人的攻擊面是Web 界面,它允許以簡單的方式控制環境。該傳感器還暴露了另一個攻擊面,即解析網絡流量的DPI 服務。

安裝和配置管理和傳感器後,我們會看到Web 界面的登錄頁面。

2.jpg

相同的憑據也用作SSH 服務器的登錄憑據,這讓我們對系統的工作方式有了更多的了解。我們要做的第一件事是獲取資源以了解幕後發生的事情,那麼我們如何獲取這些資源呢?

Defender for IoT 是一款前身為CyberX 的產品,於2020 年被微軟收購。在“cyberx”用戶的主目錄中查找,我們發現了安裝腳本和一個包含系統加密文件的tar 壓縮文件。讀取腳本時,我們找到了解密壓縮文件的命令。簡化版如下:

3.png

解密密鑰在所有安裝中共享。

提取數據後,我們找到了Web 界面的源代碼(用Python 編寫)並開始工作。

首先,我們的目標是找到任何公開的未經身份驗證的API,並查找其中的漏洞。

尋找潛在的漏洞urls.py 文件包含Web 應用程序的主要路由:

4.png

使用Jetbrains IntelliJ 的類層次結構功能,我們可以輕鬆識別不需要身份驗證的路由控制器。

5.jpg

不需要身份驗證的路由控制器從BaseHandler 繼承並且不驗證身份驗證或需要秘密令牌的每個控制器在此時都是一個很好的候選者。

Azure 的密碼恢復機制管理和傳感器的密碼恢復機制操作如下:

1.訪問管理/傳感器URL(例如,https://ip/login#/dashboard);

2.進入“密碼恢復”頁面;

6.jpg

3.將此頁面中提供的ApplianceID 複製到Azure 控制台,並獲取你在密碼重置頁面中上傳的密碼重置ZIP 文件。

7.jpg

4.使用步驟2 中提到的表格將簽名的ZIP 文件上傳到管理/傳感器密碼恢復頁面。這個ZIP包含數字簽名的證明,通過數字證書和簽名數據的方式,證明用戶是這台設備的所有者。

5.生成新密碼並顯示給用戶:

5.1實際過程分為對管理/傳感器服務器的兩個請求:

5.1.1上傳簽名的ZIP 證明;

5.1.2密碼恢復;

5.2當上傳ZIP文件時,它被解壓縮到/var/cyberx/reset_password目錄(由zipfileconfigationapihandler處理);

5.3在處理密碼恢復請求時,服務器會執行以下操作:

5.3.1 PasswordRecoveryApiHandler 控制器驗證證書。這將驗證證書是否由根CA 正確簽名。此外,它還會檢查這些證書是否屬於Azure 服務器。

5.3.2向內部Tomcat 服務器發送請求以進一步驗證設備的屬性。

5.3.3如果所有檢查都正確通過,PasswordRecoveryApiHandler將生成一個新密碼並將其返回給用戶。

ZIP 包含以下文件:

IotDefenderSigningCertificate.pem – Azure 公鑰,用於驗證ResetPassword.json 中的數據簽名,由issuer.pem 簽名。

Issuer.pem – 簽署IotDefenderSigningCertificate.pem,由受信任的根CA 簽署。

ResetPassword.json – JSON 應用程序數據,設備的屬性。

ResetPassword.json 文件的內容如下所示:

8.png

根據步驟2,處理文件上傳到reset_password目錄(components\xsense-web\cyberx_web\api\admin.py:1508)的代碼如下:

9.png

如下所示,該代碼將用戶交付的ZIP解壓到上述目錄,並處理密碼恢復請求(cyberx python庫文件django_helper .py:576):

10.1.png

10.2.png

該函數首先驗證提供的用戶並調用函數_try_reset_password:

11.png

在內部,此代碼會驗證證書,包括頒發者。

之後,對內部API http://127.0.0.1:9090/core/api/v1/login/reset-password 的請求由最終執行以下代碼的Java 組件發出和處理:

11.1+1.png

此代碼再次驗證密碼重置文件。這次它還驗證了ResetPassword.json 文件的簽名及其屬性。

如果一切順利並且Java API 返回200 OK 狀態碼,PasswordRecoveryApiHandler 控制器繼續並生成新密碼並將其返回給用戶。

Defender for IOT 中的漏洞如圖所示,密碼恢復機制由兩個主要部分組成:

Python Web API(外部);

Java Web API(tomcat,內部);

這引入了一個time-of-check-time-of-use(TOCTOU) 漏洞,原因是沒有應用同步機制。

如上所述,重置密碼機制從上傳ZIP 文件開始。這個原語允許我們將任何文件上傳到/var/cyberx/reset_password目錄並將其解壓縮。

可以在第一次驗證(Python API)和第二次驗證(Java API)之間更改/var/cyberx/reset_password 中的文件,Python API文件由Azure 證書正確簽名。然後,Java API 處理要替換的自定義文件,導致它錯誤地同意其真實性並返回200 OK 狀態代碼。

12+1.gif

密碼恢復Java API包含邏輯漏洞,這些漏洞讓專門設計的有效負載繞過了所有驗證。

Java API 驗證JSON 文件的簽名(與上面的代碼相同):

13+1.png

這裡的問題是它沒有驗證IotDefenderSigningCertificate.pem 證書,而不是Python API 驗證。它只檢查JSON 文件中的簽名是否由附加的證書文件簽名,這引入了一個重大漏洞。

因此,攻擊者可以生成自簽名證書並簽署將通過簽名驗證的ResetPassword.json 有效負載。

如前所述,ResetPassword.json 如下所示:

15+1 (2).png

之後,有一個訂閱ID 檢查:

15+1 (1).png

這是遠程攻擊者無法獲得的唯一屬性,並且在合理的時間內無法猜測。但是,可以輕鬆繞過此檢查。

該代碼從JSON 文件中獲取subscriptionId,並將其與machineSubscriptionId 進行比較。但是,這裡的代碼有漏洞。它檢查machineSubscriptionId 是否包含來自用戶控制的JSON 文件的subscriptionId,而不是相反。contains() 的使用是不安全的。 subscriptionId 採用GUID 格式,這意味著它必須包含連字符。這允許我們通過僅提供單個連字符來繞過此檢查。

接下來,檢查issueDate 和ApplianceId。這已經由密碼恢復頁面(在步驟2 中提到)提供給我們。

現在我們明白了,我們可以繞過Java API 中的所有檢查,這意味著我們只需要成功贏得競爭條件並最終在未經授權的情況下重置密碼。

ZIP上傳界面和密碼恢復界面分開的事實在開發階段派上了用場。

Azure Defender for IoT的被攻擊過程為了準備攻擊,我們需要執行以下操作。

從Azure 門戶獲取合法的密碼恢復ZIP 文件。顯然,我們無法訪問受害設備所屬的Azure 用戶,但我們可以使用任何Azure 用戶並生成一個“虛擬”ZIP 文件。我們只需要恢復ZIP 文件即可獲得合法證書。這可以通過以下URL 完成:

16.png

16.jpg

為此,我們可以創建一個新的試用Azure 帳戶並使用上述接口生成恢復文件。秘密標識符無關緊要,可能包含垃圾。

然後我們需要生成一個自定義的(“壞的”)ZIP 文件。此ZIP 文件將包含兩個文件:

IotDefenderSigningCertificate.pem – 自簽名證書。可以通過以下命令生成:

17+1.png

ResetPassword.json – 屬性數據JSON 文件,由上述自簽名證書籤名並進行相應修改以繞過Java API 驗證。

可以使用以下Java 代碼對該JSON 文件進行簽名:

19 (2).png

如前所述,applianceId 是從密碼恢復頁面獲取的。 tenantId未經驗證,因此可以是任何內容。

issuanceDate參數是自解釋的。

一旦生成並簽名,可以將其添加到ZIP 壓縮文件並供以下Python 漏洞利用腳本使用:

19 (1).png

19.2+1.png

benign.zip文件是從Azure 門戶獲取的ZIP 文件,而malicious.zip文件是如上所述的自定義ZIP 文件。

上面的漏洞利用腳本執行TOCTOU 攻擊以重置並接收cyberx用戶名的密碼,而無需任何身份驗證。它通過使用三個線程來實現:

looper_benign – 負責無限循環上傳良性ZIP 文件;

looper_malicious – 與looper_benign相同,但是上傳惡意ZIP,在這個配置中有1秒的超時時間;

looper_recover – 發送密碼恢復請求以觸發易受攻擊的代碼;

不幸的是,文檔提到ZIP 文件不能被篡改。

21+1.jpg

該漏洞在CVE-2021-42310中得到了恢復。

以root #1 身份執行未經身份驗證的遠程代碼至此,我們可以獲得特權用戶cyberx的密碼。這允許我們登錄到SSH 服務器並以root 身份執行代碼。即使沒有這個,攻擊者也可以使用更隱蔽的方法來執行代碼。

使用獲取的密碼登錄後,攻擊面大大增加。例如,我們在更改密碼機制中發現了一個簡單的命令注入漏洞:

來自components\xsense-web\cyberx_web\api\authentication.py:151:

21+1.png

該函數接收來自用戶的三個JSON 字段,“username”、“password”、“new_password”。

首先,它驗證我們已經擁有的用戶名和密碼。接下來,它只使用正則表達式檢查密碼的複雜性,但不清理命令注入原語的輸入。

在驗證之後,它使用攻擊者控制的用戶名和新密碼以root身份執行/usr/local/bin/cyberx-users-password-reset腳本。由於該函數沒有正確地對“new_password”的輸入進行清理,所以我們可以注入任何我們選擇的命令。我們的命令將在sudo的幫助下以root用戶的身份執行,這讓我們可以以root用戶的身份執行代碼:

這可以通過以下HTTP 數據包來利用:

22+1.png

該漏洞在CVE-2021-42312中被修復。

POC接下來,我們將介紹兩個額外的路由和新漏洞,以及流量處理框架中的一個漏洞。

這些漏洞是基本的SQL 注入(稍加改動),但它們對產品和組織網絡的安全性有很大影響。

CVE-2021-42313DynamicTokenAuthenticationBaseHandler類繼承自BaseHandler類,不需要身份驗證。這個類包含兩個容易被SQL注入的函數(get_version_from_db, uuid_is_connected)。

25.png

如上所示,UUI

使用中間人攻擊(AiTM)網絡釣魚網站的大規模網絡釣魚活動竊取了用戶的密碼,劫持了用戶的登錄會話,即使用戶啟用了多因素身份驗證(MFA),也會跳過身份驗證過程。然後,攻擊者使用竊取的憑證和會話cookie訪問受影響用戶的郵箱,並針對其他目標進行後續的商業電子郵件攻擊活動。自2021年9月以來,AiTM網絡釣魚活動已嘗試對1萬多個組織進行攻擊。

Figure1-overview-of-aitm-phishing.png

網絡釣魚仍然是攻擊者在試圖獲得對組織的初始訪問時最常用的技術之一。在AiTM釣魚攻擊中,攻擊者在目標用戶和用戶希望訪問的網站(即攻擊者希望模擬的網站)之間部署一個代理服務器。這樣的設置允許攻擊者竊取和攔截目標的密碼和會話cookie,這些cookie可以證明他們與該網站正在進行的、經過身份驗證的會話。不過,這不是MFA中的漏洞。由於AiTM網絡釣魚竊取了會話cookie,攻擊者將代表用戶獲得會話的身份驗證,而不管後者使用的登錄方法。

研究人已檢測到與AiTM釣魚攻擊及其後續活動相關的可疑活動,如竊取會話cookie和試圖使用竊取的cookie登錄到ExchangeOnline。然而,為了進一步保護自己免受類似的攻擊,防護人員還應該考慮用條件訪問策略來補充MFA,其中登錄請求使用額外的身份驅動信號來評估,如用戶或組成員身份、IP位置信息和設備狀態等。

AiTM網絡釣魚的工作原理每個現代Web服務都會在成功驗證後與用戶進行會話,這樣用戶就不必在他們訪問的每個新頁面上都進行驗證。此會話功能是通過在初始身份驗證後由身份驗證服務提供的會話cookie實現的。會話cookie向Web服務器證明用戶已通過身份驗證並且在網站上具有正在進行的會話。在AiTM網絡釣魚中,攻擊者試圖獲取目標用戶的會話cookie,以便他們可以跳過整個身份驗證過程並代表後者採取行動。

為此,攻擊者會部署一個web服務器,它將訪問釣魚網站用戶的HTTP數據包代理到攻擊者希望冒充的目標服務器,反之亦然。這樣,釣魚網站在視覺上與原始網站是相同的,因為每個HTTP都是通過代理來訪問和來自原始網站。攻擊者也不需要像傳統的網絡釣魚活動那樣製作自己的網絡釣魚網站。 URL是網絡釣魚網站和實際網站之間唯一可見的區別。

AiTM釣魚過程如下:

Figure2-aitm-phishing-website-intercepting-authentication.png

AiTM釣魚網站攔截認證過程

網絡釣魚頁面有兩個不同的傳輸層安全(TLS)會話與目標想要訪問的實際網站。這些會話意味著網絡釣魚頁面實際上充當AiTM代理,攔截整個身份驗證過程並從HTTP請求中提取有價值的數據,例如密碼,更重要的是會話cookie。一旦攻擊者獲得會話cookie,他們可以將其註入瀏覽器以跳過身份驗證過程,即使目標的MFA已啟用。

AiTM網絡釣魚過程目前可以使用開源網絡釣魚工具包和其他在線資源實現自動化。廣泛使用的套件包括Evilginx2、Modlishka和Muraena。

跟踪AiTM網絡釣魚活動研究人員檢測到自2021年9月以來試圖針對1萬多個組織的AiTM釣魚活動的多次迭代,該活動自2021年9月以來試圖針對10000多個組織。這些運行似乎鏈接在一起,並通過欺騙Office在線身份驗證頁面來針對Office365用戶。

根據分析,這些活動迭代使用Evilginx2釣魚工具作為其AiTM基礎設施。研究人員還發現了他們在攻擊後活動中的相似之處,包括目標郵箱中的敏感數據枚舉和支付欺詐。

初始訪問在研究人員觀察到的一次運行中,攻擊者向不同組織中的多個收件人發送帶有HTML文件附件的電子郵件。電子郵件通知目標收件人,他們有語音消息。

Figure3-sample-phishing-email-with-html-attachment.png

帶有HTML文件附件的網絡釣魚電子郵件示例

當收件人打開附加的HTML文件時,它會加載到用戶的瀏覽器中並顯示一個頁面,通知用戶正在下載語音消息。但是請注意,下載進度條在HTML文件中是硬編碼的,因此沒有獲取MP3文件。

Figure4-html-attachment-loaded-in-targets-browser.png

在目標瀏覽器中加載的HTML文件附件

Figure5-html-attachment-source-code.png

HTML附件的源代碼

相反,該頁面將用戶重定向到一個重定向網站:

Figure6-screenshot-of-redirector-site.png

重定向網站的截圖

這個重定向器充當了看門人的角色,以確保目標用戶來自原始HTML附件。為此,它首先驗證url中預期的片段值(在本例中是用base64編碼的用戶電子郵件地址)是否存在。如果該值存在,則該頁面將連接釣魚網站登錄頁面上的值,該值也以Base64 編碼並保存在“link”變量中。

Figure7-redirection-logic-included-in-script-tag.png

重定向器網站的script 標記中包含的重定向邏輯

通過結合這兩個值,隨後的網絡釣魚登陸頁面會自動使用用戶的電子郵件地址填寫登錄頁面,從而增強其社會工程誘餌。該技術也是該活動試圖阻止傳統反網絡釣魚解決方案直接訪問網絡釣魚URL 的嘗試。

請注意,在其他情況下,研究人員觀察到重定向器頁面使用以下URL 格式:

从窃取cookie到BEC:攻击者使用AiTM钓鱼网站作为进一步财务欺诈的入口

在這種格式中,目標的用戶名被用作無限子域技術的一部分。

从窃取cookie到BEC:攻击者使用AiTM钓鱼网站作为进一步财务欺诈的入口

目標瀏覽器上加載的規避重定向器網站

重定向後,用戶最終以用戶名作為片段值登陸了Evilginx2 網絡釣魚網站。例如:

从窃取cookie到BEC:攻击者使用AiTM钓鱼网站作为进一步财务欺诈的入口

網絡釣魚登錄頁面示例

網絡釣魚網站代理了組織的Azure Active Directory (Azure AD) 登錄頁面,通常是login.microsoftonline.com。如果組織已將其Azure AD 配置為包含其品牌,則網絡釣魚網站的登錄頁面也包含相同的品牌元素。

从窃取cookie到BEC:攻击者使用AiTM钓鱼网站作为进一步财务欺诈的入口

檢索組織的Azure AD 品牌的網絡釣魚登錄頁面模型

一旦目標輸入他們的憑據並通過身份驗證,他們就會被重定向到合法的office.com 頁面。然而,在後台,攻擊者截獲了上述憑據並代表用戶進行了身份驗證。這允許攻擊者在組織內部執行後續活動,在本例中為支付欺詐。

支付欺詐支付欺詐是指攻擊者欺騙欺詐目標將支付轉移到攻擊者擁有的賬戶。它可以通過劫持和回復正在進行的金融相關的電子郵件進行,並誘使欺詐目標通過虛假髮票等方式匯款來實現。

研究人員發現,在證書和會話被盜後,攻擊者只需5分鐘就可以啟動他們的後續支付欺詐。在首次登錄釣魚網站後,攻擊者使用竊取的會話cookie 對Outlook Online (outlook.office.com) 進行身份驗證。在許多情況下,cookie都有MFA聲明,這意味著即使該組織有MFA策略,攻擊者也會使用會話cookie 代表受感染的帳戶獲得訪問權限。

尋找目標在cookie 被盜後的第二天,攻擊者每隔幾個小時訪問一次與財務相關的電子郵件和文件附件文件。他們還搜索了正在進行的電子郵件進程,其中付款欺詐是可行的。此外,攻擊者從受感染帳戶的收件箱文件夾中刪除了他們發送的原始網絡釣魚電子郵件,以隱藏其初始訪問的痕跡。

這些活動表明攻擊者試圖手動進行支付欺詐。他們也在雲端進行了這項工作,他們在Chrome 瀏覽器上使用Outlook Web Access (OWA),並在使用被盜帳戶的被盜會話cookie 的同時執行上述活動。

一旦攻擊者找到相關的電子郵件進程,他們就會繼續使用他們的逃避技術。因為他們不希望被盜帳戶的用戶注意到任何可疑的郵箱活動,所以攻擊者創建了一個具有以下邏輯的收件箱規則來隱藏欺詐目標的任何未來回复:

“對於發件人地址包含[欺詐目標的域名]的每封傳入電子郵件,將郵件移動到“存檔”文件夾並將其標記為已讀。”

進行付款欺詐設置規則後,攻擊者立即回復與目標和其他組織的員工之間的付款和發票相關的正在進行的電子郵件進程,如創建的收件箱規則所示。然後,攻擊者從受感染帳戶的“已發送郵件”和“已刪除郵件”文件夾中刪除了他們的回复。

在執行初始欺詐嘗試幾個小時後,攻擊者每隔幾個小時登錄一次以檢查欺詐目標是否回復了他們的電子郵件。在許多情況下,攻擊者通過電子郵件與目標溝通了幾天。在發送回回復後,他們從Archive文件夾中刪除目標的回复。他們還從“已發郵件”文件夾中刪除了郵件。

有一次,攻擊者從同一個被攻擊的郵箱同時進行了多次欺詐嘗試。每當攻擊者發現新的欺詐目標時,他們就會更新他們創建的收件箱規則,以包括這些新目標的組織域。

以下是該活動基於Microsoft365Defender的威脅數據的端到端攻擊鏈總結:

从窃取cookie到BEC:攻击者使用AiTM钓鱼网站作为进一步财务欺诈的入口

防禦AiTM網絡釣魚和BEC

此AiTM 網絡釣魚活動是威脅如何繼續演變以響應組織為保護自己免受潛在攻擊而採取的安全措施和政策的另一個例子。由於去年許多最具破壞性的攻擊都利用了憑據網絡釣魚,我們預計類似的嘗試會在規模和復雜性上增長。

雖然AiTM 網絡釣魚試圖繞過MFA,但MFA 實施仍然是身份安全的重要支柱。 MFA 在阻止各種威脅方面仍然非常有效;它的有效性是AiTM 網絡釣魚首先出現的原因。因此,組織可以通過使用支持Fast ID Online (FIDO) v2.0 和基於證書的身份驗證的解決方案來使其MFA 實施“抵禦網絡釣魚”。

防御者還可以通過以下解決方案免受這類攻擊1.啟用條件訪問策略。每次攻擊者嘗試使用被盜的會話cookie 時,都會評估和執行條件訪問策略。組織可以通過啟用合規設備或受信任的IP 地址要求等策略來保護自己免受利用被盜憑據的攻擊。

2.投資於監控和掃描傳入電子郵件和訪問過的網站的高級反網絡釣魚解決方案。例如,組織可以利用能夠自動識別和阻止惡意網站的網絡瀏覽器,包括在此網絡釣魚活動中使用的網站。

3.持續監控可疑或異常活動:

3.1尋找具有可疑特徵的登錄嘗試(例如,位置、ISP、用戶代理、使用匿名服務)。

3.2尋找不尋常的郵箱活動,例如創建具有可疑目的的收件箱規則或通過不受信任的IP 地址或設備訪問異常數量的郵件項目。

5G開啟了傳統無線連接無法實現的前所未有的應用,幫助企業加速數字化轉型、降低運營成本,並最大限度地提高生產力,以獲得最佳投資回報。為了實現目標,5G依賴關鍵的服務類別:大規模機器類型通信(mMTC)、增強型移動寬帶(eMBB)和超可靠低延遲通信(uRLLC)。

隨著商用頻譜不斷增加,專用5G網絡的使用率和普及率也隨之提高。製造、國防、港口、能源、物流和採礦等行業只是這些專用網絡的早期採用者之一,特別是對於那些迅速依賴物聯網以實現生產系統和供應鏈數字化的公司。與公共電網不同,專用5G中的蜂窩基礎設施設備可能歸用戶企業、系統集成商或運營商擁有和運營。然而,鑑於針對使用5G開發各種技術的研究和探索越來越多,網絡犯罪分子也在考慮利用種種威脅和風險,企圖通過這種新的通信標準,入侵用戶和組織的系統和網絡。本文探討了普通用戶設備如何在5G網絡基礎設施和用例中被濫用。

5G拓撲結構在端到端5G蜂窩系統中,用戶設備(又名UE,比如移動電話和物聯網設備)通過無線電波連接到基站,基站則通過有線IP網絡連接到5G核心。

從功能上來說,5G核心可以分為兩個平面:控制平面和用戶平面。在網絡中,控制平面承載信號,並根據流量從一個端點到另一個端點的交換方式為流量傳輸提供方便。同時,用戶平面負責連接和處理通過無線局域網(RAN)傳輸的用戶數據。

基站發送與設備連接相關的控制信號,並通過NGAP(下一代應用協議)與控制平面建立連接。來自設備的用戶流量使用GTP-U(GPRS隧道協議用戶平面)發送到用戶平面。數據流量從用戶平面路由傳輸到外部網絡。

1.jpg

圖1. 基本的5G網絡基礎設施

UE子網與基礎設施網絡相互分離、隔離,不允許用戶設備訪問基礎設施組件。這種隔離有助於保護5G核心免受來自用戶設備的CT(蜂窩技術)協議攻擊。

有沒有辦法繞過這種隔離、攻擊5G核心呢?接下來的章節將詳細介紹網絡犯罪分子如何可以濫用5G基礎設施的組件、尤其是GTP-U。

GTP-UGTP-U是一種隧道協議,存在於基站和5G用戶平面之間,使用端口2152。下面是用GTP-U封裝的用戶數據分組結構。

2.jpg

圖2. GTP-U數據分組

GTP-U隧道分組是通過將報頭附加到原始數據分組而形成的。添加的報頭由UDP(用戶數據報協議)傳輸報頭和GTP-U特有的報頭組成。 GTP-U報頭則由以下字段組成:

• 標誌:這包含版本及其他信息(比如表明是否存在可選的報頭字段等信息)。

• 消息類型:對於承載用戶數據的GTP-U分組而言,消息類型為0xFF。

• 長度:這是隧道端點標識符(TEID)字段之後的所有內容的長度(以字節為單位)。

• TEID:隧道的獨特值,用於將隧道映射到用戶設備。

GTP-U報頭由GTP-U節點(基站和用戶平面功能即UPF)添加。然而,用戶無法在設備的用戶界面上看到報頭。因此,用戶設備無法操縱報頭字段。

雖然GTP-U是一種標準的隧道技術,但其使用主要局限於基站和UPF之間或UPF和UPF之間的CT環境。假設在理想場景下,基站和UPF之間的回程經過加密,受到防火牆保護,並且不允許外部訪問。下面詳述這種理想場景:GSMA建議在基站和UPF之間使用IP安全(IPsec)。在這種場景下,到達GTP-U節點的分組只來自授權的設備。如果這些設備遵循規範並合理實施,它們不會發送異常分組。此外,可靠的系統應該有強大的完整性檢查機制,以處理接收到的異常信息,特別是明顯的異常信息,比如無效的長度、類型和擴展等。

然而在現實中,場景可能往往不同,需要完全不同的分析。運營商不願意在N3接口上部署IPsec,因為它耗用大量CPU資源,降低了用戶流量的吞吐量。此外,由於用戶數據被認為在應用層受到保護(借助額外協議,比如TLS即傳輸層安全),一些人認為IP安全是多餘的。有人可能認為,只要基站和分組-核心符合具體要求,就不會出現異常情況。此外,有人可能還認為,對於所有可靠的系統而言,都需要進行完整性檢查,以發現任何明顯的異常。然而之前的研究表明,全球各地的許多N3節點(比如UPF)暴露在互聯網上,儘管不應該如此。這將在以下的章節中介紹。

3.png

圖3. 因配置錯誤或缺少防火牆而暴露的UPF接口,截圖來自Shodan,並用於之前發表的研究結果

我們討論了兩個可以使用CVE-2021-45462利用GTP-U的概念。在Open5GS這種面向5G核心和進化分組核心(EPC)的C語言開源實現中,從用戶設備發送零長度、類型=255的GTP-U分組導致了UPF遭到拒絕服務(DoS)。這是CVE-2021-45462,分組核心中的這個安全漏洞可以通過從用戶設備製作的異常GTP-U分組,並通過在GTP-U中發送該異常GTP-U分組,導致UPF(5G中)或服務網關用戶平面功能(4G/LTE中的SGW-U)崩潰。鑑於該漏洞影響基礎設施的關鍵組件,並且無法輕易解決,該漏洞的嚴重性等級為中到高。

GTP-U節點:基站和UPFGTP-U節點是對GTP-U分組進行封裝和解封裝的端點。基站是用戶設備端上的GTP-U節點。基站從UE接收用戶數據時,將數據轉換成IP分組,並在GTP-U隧道中封裝。

UPF是5G核心端的GTP-U節點。當UPF接收到來自基站的GTP-U分組時,UPF對外部的GTP-U報頭進行解封裝,取出內部分組。 UPF不檢查內部分組的內容,直接查詢路由表(也由UPF維護)中的目的地IP地址,然後繼續發送分組。

GTP-U中的GTP-U如果用戶設備製作了一個異常的GTP-U分組,並將其發送到分組核心,會怎麼樣?

4.png

圖4. 一個精心特製的異常GTP-U分組

5.jpg

圖5. 從用戶設備發送異常的GTP-U分組

果不其然,基站將把該數據包放入到其GTP-U隧道中,發送給UPF。這導致GTP-U分組中的GTP-U到達UPF。 UPF中現在有兩個GTP-U分組:外部GTP-U分組報頭由基站創建的,用於封裝來自用戶設備的數據分組。這個外部GTP-U分組的消息類型為0xFF,長度為44。這個報頭是正常的。內部GTP-U報頭由用戶設備製作並作為數據分組來發送。與外部GTP-U分組一樣,這個內部GTP-U分組的消息類型為0xFF,但長度0不正常。

內部分組的源IP地址屬於用戶設備,而外部分組的源IP地址屬於基站。內部分組和外部分組的目的地IP地址一樣:都是UPF的目的地IP地址。

UPF對外部GTP-U進行解封裝,並通過功能檢查。內部GTP-U分組的目的地還是同樣的UPF。接下來發生的事情因實現方法而異:

• 一些實現維護用於分組遍歷的狀態機。狀態機的不正確實現可能導致處理這個內部GTP-U分組。該分組可能已經通過了檢查階段,因為它與外部分組擁有相同的分組上下文。這導致系統內部有一個異常分組通過完整性檢查。

• 由於內部分組的目的地是UPF本身的IP地址,因此分組可能被發送到UPF。在這種情況下,分組很可能會通過功能檢查,因此問題不如前一種情況來得嚴重。

攻擊途徑一些5G核心供應商利用Open5GS代碼。比如說,NextEPC(4G系統,2019年更名為Open5GS以添加5G,剩餘產品來自舊品牌)提供了面向LTE/5G的企業版,借鑒了Open5GS的代碼。沒有觀察到外頭有任何攻擊或威脅跡象,但我們的測試使用已確定的場景表明存在潛在風險。

攻擊的重要性在於攻擊途徑:來自UE的蜂窩基礎設施攻擊。利用該漏洞只需要一部移動電話(或通過蜂窩加密狗連接的計算機)和幾行Python代碼,就可以濫用該缺口,並發動這類攻擊。 GTP-U中的GTP-U攻擊是一種眾所周知的技術,回程IP安全和加密無法阻止這種攻擊。事實上,這些安全措施可能會阻礙防火牆檢查內容。

補救和心得醫療和電力等關鍵行業只是專用5G系統的早期採用者之一,5G廣泛使用的廣度和深度只會與日俱增。對於這些行業來說,確保持續不間斷運作的可靠性至關重要,因為這關係到千萬條生命和實際影響。這些行業的性質決定了它們選擇使用專用5G系統,而不是Wi-Fi。專用5G系統必須提供持久的連接,因為對任何5G基礎設施的攻擊得逞都可能導致整個網絡癱瘓。

在本文中,濫用CVE-2021-45462可能導致DoS攻擊。 CVE-2021-45462(以及大多數GTP-U中的GTP-U攻擊)的根本原因是分組核心中的錯誤檢查和錯誤處理不當。雖然GTP-U-中的GTP-U本身無害,但修復這個漏洞的適當措施必須來自分組核心供應商,而基礎設施管理員必須使用最新版本的軟件。

GTP-U中的GTP-U攻擊還可以用於洩露敏感信息,比如基礎設施節點的IP地址。因此,GTP-U對等體應該準備好處理GTP-U中的GTP-U分組。在CT環境下,它們應該使用能夠理解CT協議的入侵防禦系統(IPS)或防火牆。由於GTP-U不是正常的用戶流量,特別是在專用5G中,安全團隊可以優先考慮並丟棄GTP-U中的GTP-U流量。

一般來說,SIM卡的註冊和使用必須嚴格加以規範和管理。擁有被盜SIM卡的攻擊者可以將其插入攻擊者的設備,連接到網絡部署惡意軟件。此外,對於採用共享操作模式的一些人來說,安全責任可能很模糊,比如企業擁有的基礎設施鏈的終端設備和邊緣。同時,蜂窩基礎設施歸集成商或運營商所有。這給安全運營中心(SOC)帶來了一項艱鉅的任務:將來自不同領域和解決方案的相關信息整合在一起。

此外,由於需要停機和測試,定期更新關鍵基礎設施軟件以跟上供應商的補丁並不容易,也永遠不會容易。因此,強烈建議使用IPS打虛擬補丁或採用分層防火牆。幸好,GTP中的GTP很少在實際應用中使用,因此可以完全阻止所有GTP中的GTP流量。我們建議使用結合IT和通信技術(CT)安全性和可視性的分層安全解決方案。實施零信任解決方案,為企業和關鍵行業增加另一層安全,以防止未經授權使用專用網絡,以實現連續不中斷的工業生態系統,並確保SIM卡只能從授權設備上使用。

0x01 前言F5 BIG-IP廣域流量管理器是一種網絡流量管理設備,用於提升鏈路性能與可用性。 F5在金融行業具有特別廣泛的使用量,做過各大銀行攻防演練的小伙伴對這個系統應該不會陌生。

最近爆出的CVE-2023-46747漏洞能達到遠程RCE的效果,屬於嚴重級別的安全漏洞。有意思的是這個漏洞和“AJP請求走私”有關。本文將對請求走私漏洞和CVE-2023-46747做一個詳細介紹和分析。

0x02 AJP請求走私介紹較早出現的AJP請求走私漏洞是CVE-2022-26377,關於該漏洞的詳細信息已經有作者進行過分析,感興趣的讀者可以查看原文https://www.ctfiot.com/44809.html,這裡我們關注的是AJP請求走私漏洞的危害。

AJP請求走私漏洞影響Apache Httpd 2.4.54,注意這裡直接受影響的並不是tomcat,所以並不是所有的java網站都受請求走私漏洞的影響,而是只有啟用了httpd服務的網站才受此漏洞影響,類似於現在前後端分離中nginx服務的作用。在F5 BIG-IP中啟動的WEB服務的架構如圖2.1所示,並且在F5-BIG-IP中的httpd版本2.2.15,受CVE-2022-26377漏洞影響。

8.png

圖2.1 F5 BIG-IP中的WEB服務架構

9.png

圖2.2 F5 BIG-IP中的httpd版本

AJP請求走私漏洞並不是一個高危漏洞,在各個CVSS評分在6.5-7.5之間,所以一直沒有受到我的關注,只是覺得這是一個僅供研究沒有實際意義的理論漏洞。在這次F5 BIG-IP的RCE漏洞爆出之後,我才重新對這個漏洞進行研究。關於此漏洞的詳細理論可以參考上面的文章,這裡主要總結下面的幾個關鍵點:

1) 瀏覽器並不能直接發送AJP協議的數據包,需要依賴於Apache的proxy_ajp 模塊進行反向代理,暴露成HTTP 協議給客戶端訪問。

2) AJP協議對於POST類型的HTTP請求會分成header 和body 兩個數據包發送,由於處理body數據時,其中前面四位固定格式與Forward Request 數據包完全一樣,導致本來應該是一個數據包body部分的數據,可能在進行AJP轉發時被識別為另一個數據包。這也是AJP請求走私的本質原理和危害,如圖2.3所示。

3) AJP請求走私時需要使用Transfer-Encoding: a, chunked 進行分塊傳輸。

10.png

圖2.3 AJP請求走私流程

從圖2.3可以看出,整個AJP請求走私的流程是可以把一個HTTP請求經過AJP代理轉化之後轉化為兩個AJP請求,這也是請求走私名字的來源。

0x03 CVE-2023-46747漏洞分析經過0x02的分析已經對AJP請求走私有了初步的了解,但是實際上還是很難看出這樣的漏洞能導致RCE效果。

從官方對這個漏洞的描述中可以看出,此漏洞僅影響開放了TNUI接口的系統(F5 BIG-IP默認啟用),這是因為在/config/httpd/conf.d/proxy_ajp.conf文件中定義了AJP代理的配置,其中只會對tmui相關接口進行代理,如圖3.1所示。

11.png

圖3.1 TMUI接口中的AJP代理配置

如圖2.1所示,httpd服務監聽的IP是0.0.0.0,所以是可以被外網用戶直接訪問到的,httpd提供反向代理的功能,把請求轉發到tomcat java監聽的80端口。最初看到這個漏洞的時候,我一直在java代碼中尋找鑑權的邏輯,以圖找到通過AJP請求走私繞過鑑權的方式,但是找了很久都沒有找到,甚至我在F5的JAVA代碼中沒有找到任何的Filter。後來在翻閱F5的歷史漏洞分析文章中才看到原來F5的鑑權並不在JAVA代碼中,而是在httpd模塊中。

F5實現了自己的pam進行認證,模塊路徑為/usr/lib/httpd/modules/,其中,涉及到login.jsp授權的是mod_f5_auth_cookie.so文件。反彙編之後,大概是這樣的。我們能夠請求/tmui/login.jsp而不需要進行身份驗證。

12.png

圖3.2 訪問/tmui/login.jsp不需要授權

如果直接訪問其他jsp文件,在沒有通過身份驗證的情況下,會被重定向到/tmui/login.jsp

13.png

圖3.3訪問其它頁面需要授權

這也就說明在CVE-2023-46747漏洞的POC利用腳本中通過訪問/tmui/login.jsp(這個頁面是不需要授權,又可以進行AJP請求轉化的頁面),在body中添加AJP請求走私的內容,就可以達到繞過鑑權的效果。

poc地址:

https://www.ddpoc.com/poc/DVB-2023-5391.html

在使用的時候注意,部分BurpSuite會去掉Transfer-Encoding頭,自動從分塊傳輸轉化為普通傳輸導致檢測失敗,所以在使用的過程中盡量不要使用Burp代理,如果非要抓包可以使用Charles,如圖3.4所示。

14.png

圖3.4 使用Burp代碼導致檢測失敗

去掉Burp代理之後,在Charles中可以看到正常的Chunked請求體和請求頭,並且運行成功之後可以執行命令,如圖3.5所示。

15.png

圖3.5 通過POC可以正常繞過權限添加用戶並執行命令

關於繞過權限之後F5 BIG-IP執行命令的邏輯在F5歷史漏洞CVE-2022-1388中已經使用過,其實F5 BIG-IP本身就提供了接口/mgmt/tm/util/bash為後台用戶執行系統命令的,有興趣的讀者也可以看https://mp.weixin.qq.com/s/wUoBy7ZiqJL2CUOMC-8Wdg了解詳細的創建用戶和後台命令執行的邏輯。

0x4 結論CVE-2023-46747算是請求走私漏洞的典型應用場景,把一個中低危的漏洞放在特定的場景中放大危害造成RCE效果,整個利用過程就像是為AJP請求走私量身定制一樣。

首先,F5 BIG-IP使用httpd來轉發前端用戶請求,並且對特定接口/tmui/*開啟AJP請求轉發功能。

其次,F5 BIG-IP的用戶鑑權邏輯在httpd的so文件中實現,而不是在java代碼中是實現。甚至在後端的java代碼中沒有任何鑑權邏輯,導致只要請求轉發到後端java代碼則可以訪問到。通過AJP請求走私可以把一個隱私的添加用戶的請求隱藏在未授權接口/tmui/login.jsp請求中,導致繞過了F5鑑權的邏輯把添加用戶的請求轉發到後端java代碼。

最後,添加的用戶在後台可以直接命令執行導致RCE效果。

參考:https://mp.weixin.qq.com/s/wUoBy7ZiqJL2CUOMC-8Wdg

https://github.com/W01fh4cker/CVE-2023-46747-RCE

https://www.ctfiot.com/44809.html

https://blog.csdn.net/weixin_39541693/article/details/111112257

使用未經批准的軟件和硬件通常會使組織的整個網絡面臨風險。系統管理員應該發現和管理影子IT 元素,但這樣做變得越來越具有挑戰性。根據ManageEngine的2021 年數字就緒調查,到2021 年,只有22% 的組織需要徵得IT 團隊的批准才能購買任何應用程序。

雲服務的廣泛採用和切換到遠程工作使用戶可以輕鬆部署他們選擇的軟件。 IT 團隊必須適應這一新現實,並找到發現、管理影子IT 甚至從中受益的新方法。

在本文中,我們將了解影子IT 的主要安全挑戰、它與業務主導的IT 有何不同,以及可以採取哪些措施來檢測和減輕影子IT 的風險。本文對希望保護其組織的網絡免受影子IT 影響的項目負責人和CIO 很有用。

躲在陰影裡什麼是影子IT?基本上,它是未經公司IT 部門批准而部署和使用的任何IT 系統、硬件或應用程序。在某些情況下,包括手機和USB 設備在內的個人設備也可能被視為影子IT 的一部分。影子IT 最常見的例子是流行的雲服務,如Dropbox 和Salesforce,以及常用的信使,如Slack 和WhatsApp。

人們轉向影子IT 的最常見原因是:

image.png

為什麼用戶轉向影子IT

儘管影子IT 通常看起來對最終用戶有幫助,但它對企業構成了嚴重威脅。主要威脅隱藏在它的不負責任中——你無法有效地管理你甚至不知道存在的東西。結果,整個網絡的安全和性能都面臨風險。

讓我們看看影子IT 風險是什麼:

image.png

影子IT 如何損害組織

马云惹不起马云 不受管理的安全漏洞。未經IT 部門批准的軟件可能存在未修補的漏洞、安全錯誤、易受攻擊的庫等。此類軟件會產生許多漏洞,黑客可能會利用這些漏洞來破壞系統和竊取敏感的業務信息。由於IT 管理員不知道這些漏洞,他們無法管理影子IT 的安全風險。

马云惹不起马云 數據丟失。 IT 部門無法為他們不知道網絡中存在的軟件和數據創建備份,而影子IT 用戶通常不認為(或不知道)備份是必要的。因此,始終存在丟失敏感數據的重大風險。

马云惹不起马云 數據和資源孤島。企業通常有一種使用批准的解決方案來處理和存儲其數據的方法。然而,用戶使用影子解決方案創建自己的數據管理系統,這些解決方案會消耗額外的資源來維護和存儲額外的數據記錄,從而形成數據孤島。

马云惹不起马云 IT 成本增加。如果員工更喜歡使用未經批准的軟件和設備,則意味著組織在IT 方面的投資沒有回報,並且有更好的方式來使用這些資金。

马云惹不起马云 合規問題。大多數企業都有他們需要遵守的各種法規、法律和行業標準。非託管軟件的存在使公司更難滿足合規性要求。不合規可能導致數據洩露、代價高昂的處罰和客戶流失。

儘管影子IT 會帶來很多風險,但組織仍然可以從未經批准的軟件中獲益。讓我們在下一節中討論您的組織如何扭轉局面。

您如何從影子IT 中獲益?影子IT 的出現表明員工發現批准的解決方案效率低下、不舒服,或兩者兼而有之。影子解決方案比已經部署的工具更俱生產力和成本效益。隨著雲服務的大規模採用,您不可能控制所有影子IT。但是您可以通過將其轉變為業務主導的IT 從中受益。

業務主導的IT是一種IT 管理方法,允許員工在沒有IT 部門批准的情況下使用他們需要的軟件和硬件。員工只需將他們選擇使用的產品通知IT 管理員。

轉向以業務為主導的IT 可為組織帶來以下好處:

image.png

業務主導的IT 有哪些好處

儘管以業務為主導的方法有很多好處,但它並沒有消除影子IT 活動的主要風險:數據丟失的可能性和未知的安全漏洞。此外,請記住,以業務為主導的IT 的成功依賴於用戶的開放性和安全意識。如果用戶不報告影子軟件,IT 部門可能永遠不會知道它。

40% 的IT 專業人士承認,儘管存在風險,他們自己也會使用未經批准的技術。

Entrust 公佈的影子IT 的好處報告

即使您決定為您的企業採用以業務為主導的IT,您仍然需要知道您的網絡中是否有未說明的應用程序和設備。在下一節中,我們將討論用於檢測和減輕影子IT 安全風險的流行解決方案。

揭開影子IT 的面紗處理未經批准的軟件和雲應用程序有四種主要方法。選擇哪一個取決於您組織的管理風格和可用資源。讓我們來看看每個選項:

image.png

管理影子IT 的4 種方法

1. 部署影子IT 發現和管理解決方案您可以使用IT 資產管理(ITAM) 系統檢測影子IT 。這些系統收集在您組織的網絡中運行的硬件和軟件的詳細清單。根據這些信息,您可以分析不同資產的使用情況。

選擇或構建自定義ITAM 軟件時,請注意以下四個參數:

image.pngIT資產管理軟件關鍵參數

ITAM 解決方案分為三種類型:

马云惹不起马云 當您需要從遠程端點或不經常連接到網絡的設備(例如筆記本電腦)收集庫存信息時,基於代理的解決方案非常適用。

马云惹不起马云 無代理工具最適合對關鍵資產執行非侵入式監控和分析。

马云惹不起马云 基於雲的IT 資產庫存系統用於監控和審計雲解決方案的使用。一個示例是雲訪問安全代理(CASB)。

CASB是發現雲中影子IT 風險的流行工具。他們可以通過分析來自防火牆、代理和端點的日誌來識別正在使用的雲服務和應用程序。這些解決方案提供了關於哪些設備連接到網絡以及誰可以訪問敏感數據並將其存儲在雲中的高度可見性。

一些CASB 還提供了將業務主導的IT 中使用的雲服務置於只讀模式的機會。這樣,用戶仍然可以查看這些應用程序的內容,但不能向其中添加數據。

要使用資產管理軟件和訪問CASB 覆蓋您企業的所有網絡,您可能需要部署多個解決方案並將它們相互集成以及與您現有的IT 系統集成。

2.使用默認的雲服務大型雲服務提供商(CSP) 提供額外的解決方案來檢測和管理雲中的影子IT。它們對於將所有網絡部署在一個或多個雲中的組織很有用。

image.png

默認影子IT 發現服務

Microsoft Defender for Cloud Apps是一項用於監視和審核雲服務使用情況的服務。它可以發現公司雲環境中的應用程序、文件和用戶,包括與其連接的第三方應用程序。

Microsoft Azure 在其高級版中有一個基於代理的Azure Active Directory Cloud Discovery工具。該代理捕獲HTTP/HTTPS 連接的標頭、URL 和元數據等數據,以發現組織內使用的雲應用程序,識別使用它們的人員,並提供詳細信息以供進一步分析。

Amazon Web Services (AWS) 提供兩種類似的服務——AWS Cloud Discovery和AWS Application Discovery Service。它們幫助用戶發現AWS 環境中的賬戶、應用程序、數據中心和實例之間的關係。這兩種服務都可以在小型網絡中免費使用。

3. 將您的安全工作重點放在數據保護上歸根結底,我們要保護的是敏感數據,使其免受影子IT 帶來的風險。您無需發現網絡中影子IT 的所有元素,而是可以專注於數據監控和保護。這樣,無論您的用戶訪問敏感信息的方式如何,您都將監控與數據的所有交互。

以下是您可以採用的關鍵數據保護做法:

image.png

如何保護您的數據免受影子IT 的風險

確保數據保留。企業存儲的大多數記錄都有有效期;換句話說,該組織必須將這些記錄保存一段時間。存儲期限通常由網絡安全標準和法規以及公司特定的操作來定義。數據保留策略有助於統一、分類和管理敏感數據,並定義其存儲和處置規則。

有了這個政策,您可以將網絡安全工作集中在保護您的組織真正需要的記錄上。此外,您還可以通過減少敏感記錄的數量來降低數據洩露的風險。

加密敏感數據。加密靜態和傳輸中的記錄可以確保敏感數據在上傳到影子軟件或洩露時是安全的。要與加密數據交互,用戶需要公鑰或對稱密鑰以及解密算法。

最常見的數據加密協議是AES、TLS/SSL 和RSA。它們提供足夠級別的保護,同時不會花費太長時間來加密數據。

管理用戶對數據的訪問。影子IT 造成的安全漏洞可能成為黑客的切入點,除非您有適當的訪問控制系統,否則他們可以滲透您的網絡並竊取敏感數據。這樣的系統定義了哪些用戶可以與哪些資源交互,並拒絕所有其他用戶的訪問請求。

訪問控制系統通常包括身份驗證服務,例如用於驗證用戶身份的多因素身份驗證。多因素身份驗證有助於安全系統在提供訪問權限之前通過憑據、生物特徵或通過智能手機進行的額外確認來積極識別用戶。

跟踪所有數據移動。由於影子IT 意味著將數據移動到未經批准的服務和軟件,因此能夠監控和跟踪所有敏感記錄非常重要。數據丟失防護軟件可以幫助您完成這項任務。

了解敏感數據的存儲位置、管理方式以及何時將其傳輸到受保護範圍之外,就無需發現所有影子IT 元素。相反,您可以專注於數據移動並配置規則以自動阻止受保護環境之外的傳輸。

4. 實施DevOps 方法DevOps是一種將軟件開發和運營實踐結合到一個簡化流程中的方法。它使企業能夠提高生產力,減少整合新解決方案所需的時間,並打破開發、測試和運營之間的孤島。

DevOps 方法可幫助組織在軟件開發期間構建用於持續集成和持續交付(CI/CD) 的管道,並確保該管道僅包含有用的軟件、工具和服務。

採用DevOps 來減少影子IT 有幾個主要好處:

image.png

DevOps 如何減輕影子IT

由於DevOps 可以更快地響應最終用戶的請求,並幫助公司輕鬆有效地實施新的解決方案,因此這種方法可以被視為解決影子IT 問題的最有效方法之一。

DevOps使最終用戶更容易正式實施更好更快地完成工作所需的新軟件和技術,從而消除了使用影子IT的需要。採用DevOps 的組織可以將影子IT 轉變為其IT 基礎架構的一部分,而不會影響性能或安全性。

請記住,只有當整個企業都採用這種方法時,DevOps 才能減少影子IT 的出現。否則,未採用DevOps 的團隊可能會創建更多影子IT 元素以跟上面向DevOps 的團隊。

結論使用非託管軟件和雲服務可能會危及公司網絡的安全性並造成性能和合規性問題,從而對任何公司構成嚴重威脅。至少有三種方法可以解決這個問題:通過實施有效的IT 資產庫存和管理系統、專注於數據保護或轉向DevOps。

使用Raspi配置raspi-config是一個用戶空間工具,它允許我們配置樹莓派的各個方面,其中之一是啟用各種外部接口。我們將使用raspi-config來啟用UART接口,首先啟動工具,如下所示:

sudo raspi-config 這將導致出現以下結果:

33.png

接下來,我們將選擇Interface Options,然後是Serial Port,如下圖所示:

34.png

選擇這個選項後,我們會遇到兩個問題:

1.你希望通過串行方式訪問登錄shell嗎?

2.你想啟用串行端口硬件嗎?

我們現在已經在樹莓派上啟用了UART,接下來,我們需要將它連接到我們的機櫃。我們將機櫃的Tx連接到Pi的Rx,將機櫃的Rx 連接到Pi 的Tx:

35.png

UART工具使用樹莓派上的UART接口,我們可以嘗試連接到目標設備上的這個Serial Port。為了與這個Serial Port交互,我們將使用屏幕實用程序。當與UART接口時,屏幕要求我們傳遞一個設備和波特率,由於我們知道上一段的波特率,我們將按如下方式運行:

sudo screen -L -Logfile cabinet-bootup.log /dev/ttyS0 115200

-L -Logfile cabinet-bootup.log——將會話記錄到cabinet-bootup.log文件;

/dev/ttyS0——要使用的串行設備;

115200——波特率;

我們現在可以在配置我們的UART 和啟動屏幕後打開機櫃。當我們打開機櫃電源時,我們看到以下內容:

36.png

最終,我們發現自己在一個控制台:

37.png

我們現在有一個根控制台,可以探索文件系統,查看目標上正在運行的內容,並了解有關它是如何構建的更多信息。如果可能,我們的下一步將是對分區進行映像;讓我們先看看掛載了哪些分區:

38.png

我們的根文件系統是以只讀的形式掛載的,並且使用的是squashfs格式。此外,還掛載了標記為userdata的另一個分區。如果我們檢查可用的block設備,我們會看到以下內容:

39.png

我們可以看到,SPI flash設備大概位於/dev/rkflash0。要獲得這個block設備的圖像,我們可以將USB插到機櫃的USB端口並使用dd實用程序。當我們插入一個USB閃存驅動器時,它在/dev/sda 中被枚舉,我們可以用以下命令將SPI閃存的內容映射到USB驅動器:

Sudoddif=/dev/rkflash0of=/dev/sdastatus=progress如果我們將USB 驅動器插入Pi 並檢查分區表,我們會看到相應的分區已映射到驅動器。

40.png

現在我們有了閃存的備份,這是我們嘗試修改嵌入式系統時應該採取的第一步;在我們嘗試修改任何內容或重新刷新任何分區之前,我們應該確保我們有辦法恢復它們;為此,我們將調查引導加載程序。作為起點,讓我們注意啟動日誌開頭的以下行:

41.png

如果我們在為機櫃供電時在屏幕提示中按住Ctrl-c,我們會看到以下內容:

42.png

我們現在有一個UBoot 提示符,在深入探討之前,讓我們先談談UBoot 及其工作原理。

UBOOTUBoot是嵌入式系統中常用的開源引導加載程序。它支持各種架構和CPU類型。但是,UBoot 的職責通常是為嵌入式系統加載操作系統內核或主應用程序。

UBoot 還包括在你的逆向工程工作中有用的調試實用程序;最值得注意的是UBoot 命令提示符。

UBoot命令UBoot 控制台可以包含大量的內置實用程序,這些實用程序可以在標準引導過程中(通常通過環境變量)或在UBoot 命令行中使用。可用的命令將根據UBoot映像的構建方式而有所不同。

現在我們已經發現了一個UBoot 控制台,讓我們首先通過運行help 命令查看哪些命令是公開可用的。

43.1.png

43.2.png

43.3.png

在查看每個命令之前,讓我們重新審視一下我們的主要目標,即能夠從引導加載程序讀取和寫入根文件系統分區,以防我們以後需要恢復這個機櫃。下面的命令非常醒目,因為它們涉及內存讀取和寫入:

44.png

接下來,我們可以使用printenv 命令查看此引導加載程序配置的環境變量。這將為我們提供更多關於該平台如何啟動、正在使用的內存地址以及其他可用接口的背景信息。

UBoot環境變量在為設備構建或配置UBoot映像時,可以配置各種環境變量。這些環境變量控制啟動時執行的操作。存儲這些變量的方法有很多種。有時它們被硬編碼到二進制中,它們也可以駐留在閃存分區上,允許用戶從UBoot提示符修改它們。

我們可以使用printenv 命令檢查環境變量:

45.1.png

45.2.png

我想在下表中指出一些有趣的變量:

46.png

此時,如果我們交叉引用我們在硬件檢查期間收集的信息,我們會看到一致的結果。在我們的硬件檢查之後,我們假設SPI flash是主要的存儲方法,這個假設在UBoot環境變量和可用的命令中得到驗證。

讓我們從檢查rksfc命令開始,通過搜索,這是RockChip的SPI SFC(串行flash控制器)接口工具。該命令包含以下子命令:

47.png

可以通過以下命令獲取SPI flash的信息:

48.png

使用這些命令,我們可以了解更多關於SPI flash的信息。我們可以看到塊大小為512,該芯片總共包含220672 (0x35E00)塊,被分成5個分區:

uboot ——可能包含我們的UBoot 映像/第一階段引導加載程序;

trust ——可信執行環境映像;

boot ——內核映像/ramdisk;

rootfs ——我們最大的分區,內核的根文件系統;

user data——用戶特定數據,可能用於高分、用戶設置等;

注意,該數據與我們之前在根控制台提示符中看到的內容相匹配。我們現在了解了閃存是如何分區的以及可能有哪些數據可用,但是我們如何在不向板上焊接額外線路的情況下讀取/寫入這些數據呢?如果我們檢查usb 命令,我們會看到以下內容:

49.png

使用機櫃側面的USB 端口,如果我們插入設備並運行USB start 後跟USB info,則會生成以下輸出:

50.1.png

這樣,我們就可以看到USB堆棧成功枚舉並檢測到我們的大容量存儲設備。

在繼續之前,讓我們回顧一下我們對UBoot 環境的了解:

通過檢查環境變量,我們可以在RAM中找到可用的地址;

使用rksfc讀取實用程序,我們可以讀取SPI閃存扇區到RAM;

使用USB命令,我們可以枚舉一個USB設備並寫入它;

我們可以將SPI flash讀入RAM,連接USB設備,然後使用USB寫入命令將SPI flash數據寫入USB設備。如果這種方法有效,我們還應該能夠通過反向步驟恢復閃存圖像,從USB驅動器讀取數據,並使用rksfc write寫入閃存。讓我們從測試讀取開始。

首先,我們將嘗試使用以下命令將整個SPI 閃存讀入RAM 以獲取目標地址,我們將嘗試存儲在$ramdisk_addr_r 中的地址,即0x6a200000:

51.png

這不起作用,我們以某種方式觸發了未定義的指令異常。我們可能破壞了UBoot 正在使用的一些東西,讓我們看看當我們嘗試另一個內存較低的地址時會發生什麼:

52.png

移動到RAM 中的較低地址允許讀取完成而不會破壞任何內容,讓我們看看我們現在是否可以將這些數據寫回USB 驅動器:

53.png

現在我們來看看這個驅動器的內容,把它插入樹莓派,看看我們有什麼:

54.png

此時,我們可以看到USB驅動器上的分區表與rksfc part 0命令的輸出相匹配。接下來,我們將使用dd實用程序提取用於分析的各個分區。

55.png

到目前為止,該數據與我們在查看正在運行的系統上的掛載輸出和UBoot 菜單中的分區表時看到的數據相匹配。因此,我們可以通過unsquashfs 提取squashfs 分區並嘗試掛載ext2 分區以確認它們是有效的:

56.png

看起來我們有一個有效的根文件系統,現在我們可以開始逆向工程軟件了,並了解更多關於我們如何修改這個系統來玩更多遊戲或運行自定義固件的信息。

現在我們已經確認可以讀取flash,讓我們測試一下,看看我們是否可以使用上面描述的方法將這張圖片寫回flash:

57.png

現在我們重新啟動,希望我們重新刷新的圖像仍然有效。

58.jpg

成功!我們現在可以使用我們的USB 驅動器從UBoot 讀取/寫入SPI 閃存;這對於測試補丁和固件修改很有用!

現在我們可以用UBoot 讀/寫這個機櫃的flash,如果我們可以自動擦除flash 的各個分區和段,而不需要每次手動輸入範圍,那就太好了。為此,我們將使用Depthcharge 實用程序來自動化我們的UBoot 交互!

使用DEPTHCHARGE 編寫UBOOT在使用UBoot環境時,我們經常需要自動化交互。例如,在我們的示例中,我們可能希望自動重寫特定的閃存分區,而不必每次都手動輸入地址偏移量。對我們來說幸運的是,NCC集團的人已經組裝了一個工具來幫助我們,這個工具叫做深度充電。我們可以使用這個自動化的過程,從我們的閃存芯片和外部USB驅動器讀取數據。我們的腳本將需要執行以下操作:

連接到UART並識別UBoot提示符;

通過rksfc讀寫命令對SPI flash進行讀寫操作;

通過USB讀寫命令對USB驅動器進行讀寫;

首先,我們需要安裝模塊,可以通過執行命令sudo pip install depthcharge.o在Pi上安裝depthcharge。

連接到UART並識別UBoot提示符

我們可以使用以下python代碼連接到UBoot提示符:

微信截图_20220208150823.png

在上面的函數中,我們創建了一個Console對象,它要求我們提供一個到Serial Port和波特率的路徑。然後這個控制台對像被用來製作Depthcharge上下文,我們將使用它來訪問Depthcharge所提供的功能。 depthcharge文檔中有一個很好的例子,詳細描述了安裝過程。

Flash 通過depthcharge 讀寫現在我們已經連接到接口,我們需要實現rksfc讀寫命令。我們可以使用depthcharge的send_command() API來做到這一點。這個API調用允許我們生成UBoot命令並將其發送到命令提示符並返迴響應。在下面的例子中,我們在cmd_str變量中構造了read命令,並確保參數被正確格式化,然後使用send_command() API發出命令。

59.png

現在我們已經實現了對閃存的讀寫,接下來我們需要枚舉USB堆棧,然後從閃存驅動器中讀寫。

USB 通過depthcharge 讀寫與我們實現rksfc 命令的方式類似,接下來我們將實現usb 命令。該過程將類似於用於rksfc 命令的過程:

60.png

使用Depthcharge 轉儲閃存現在我們已經定義了適當的函數,我們可以嘗試以下操作:

61.png

如果我們運行這個腳本,就會看到如下輸出:

62.1.png

62.2.png

當我們將u盤插入Pi時,就會會看到以下分區:

63.png

成功!我們已經使用Depthcharge 將SPI 閃存提取到USB 設備!

文件系統內容現在我們有了一種可靠的讀取和寫入flash的方法,讓我們簡要地檢查一下內容。有趣的文件位於/moo文件夾中。此文件夾包含仿真器及其相關資源。 Moo是一個使用自定義ROM格式的自定義模擬器,2020年,一些研究人員在模擬器的另一個版本上進行了測試。然而,如果我們查看目錄內容,會發現一些有趣的現象:

64.png

在這個系統上肯定不可能有PE32 Windows 可執行文件,如果我們將此文件複製到Windows 機器上並嘗試執行它:

65.jpg

它運行了!顯然,這是一個構建工件,開發者沒有意識到它存在於系統中。

使用本文介紹的方法,我們現在可以使用UBoot 將SPI 閃存讀寫到USB 驅動器。我們已經提取了根文件系統並確定了核心模擬組件。我們的下一個目標將是對該目標上的一些二進製文件進行逆向工程,以確定運行自定義固件的困難程度。

總結我們在本文中介紹瞭如何使用我們的萬用表/邏輯分析儀執行嵌入式設備的初始拆卸和識別潛在的調試頭。然後進一步詳細介紹瞭如何分析未知的UART 流量並使用帶有Raspberry Pi 的屏幕連接到Serial Port。連接到Serial Port後,我們發現可以通過按Ctrl-C來訪問UBoot控制台。在查看了UBoot 控制台之後,我們編寫了一個depthcharge 腳本來將每個SPI 閃存分區提取到一個外部閃存驅動器中。所有使用的腳本和工具都可以在github上找到。

這篇文章將以Arcade 1UP Marvel 街機為目標,重點介紹UART、UBoot 和USB。 Arcade1UP系列街機自從推出以來,已經有很多玩家在研究如何更換機櫃的內部組件來運行通用MAME 軟件。這篇文章將著眼於現有的硬件,並討論如何提取固件。

1.png

在這篇文章,我們將介紹以下內容:

1.拆卸現有嵌入式系統的支撐硬件;

2.通過IC 標記識別組件;

3.用萬用表測量連接器電壓;

4.邏輯分析儀的使用和設置;

5.UBoot分析和審查;

6.使用depthcharge 編寫UBoot 交互腳本;

這篇文章旨在介紹在目標系統上定位活動的UART、如何接近UBoot 控制台以及最終如何利用這兩個組件從我們的目標中提取閃存。閱讀本文後,你將熟悉屏幕實用程序depthcharge python3庫。

硬件概述在查看新目標時,首要任務之一是檢查可用的接口。在這個街機櫃的例子中,可用的接口乍一看是相對較小的。用戶通過操縱桿/按鈕和機櫃側面的USB接口與該設備進行交互。在機櫃的一側似乎很少有關於USB端口的信息。請注意,即使在網站上的圖片,也沒有USB端口。但是,在機櫃的一側有一個USB設備端口,用於提供外部控制器支持。在另一邊,我們有一個標準的耳機插孔。這兩個外設的行為與預期的一樣,USB端口可以用於連接外部控制器。

在一些老式的手機上,可以配置音頻插孔以在啟動時顯示串行終端。關於這方面的更多信息可以在這裡找到。不幸的是,在這個平台上沒有這樣的修改。

2.jpg

第一次查看這樣的PCB 時,我們首先要記下任何零件編號,看看是否能找到任何數據表。第一個讓我印象深刻的組件用藍色突出顯示。

3.jpg

它是RockchipRK3128,如果我們在網上搜索這個部件編號,我們會發現大量的相關信息。

中央處理器四核ARM Cortex-A7MP Core 處理器,一種高性能、低功耗和緩存的應用處理器;

完全實現ARM架構v7-A指令集,ARM Neon Advanced SIMD(單指令,多數據)支持加速媒體和信號處理計算;

圖形處理器ARM Mali400 MP2;

高性能OpenGL ES1.1 和2.0、OpenVG1.1 等;

內存8 kb的內部存儲器;

動態內存接口(DDR3/DDR3L/LPDDR2):兼容JEDEC標準DDR3-1066/DDR3L-1066/LPDDR2-800 SDRAM。支持32位數據寬度,2級(芯片選擇),總共2GB(最大)地址空間。

Nand Flash接口:支持8位async/toggle/syncnandflash,最多4個bank。 16位、24位、40位、60位硬件ECC;

eMMC接口:兼容標準eMMC接口,支持MMC4.5協議;

視頻MPEG-1, MPEG-2, MPEG-4,H.263, H.264, H.265, VC-1, VP8, MVC的實時視頻解碼器

音頻具有8 個通道的I2S/PCM:最多8 個通道(8xTX、2xRX),從16 位到32 位的音頻分辨率,採樣率高達192KHz。

具有2個通道的I2S/PCM:最多2 個通道(2xTX、2xRX),從16 位到32 位的音頻分辨率,採樣率高達192KHz。

連接SPI控制器:一個集成SPI控制器;

UART控制器:3個集成UART控制器;

I2C控制器:4個集成I2C控制器;

USB Host2.0:嵌入式1 USB Host 2.0接口;

USB OTG2.0:兼容USB OTG2.0規範,支持高速(480Mbps)、全速(12Mbps)和低速(1.5Mbps)模式;

依據上述描述,我們就了解了很多關於目標處理器的信息。我們現在知道了架構和可用的外圍設備和接口,這些對我們是有用的,因為它們可能概述未來的攻擊向量。重要的是要記住,在逆向工程過程的這個階段沒有太多的信息。在嘗試與目標進行交互之前,我們希望盡可能多地了解目標。

在CPU附近,我們有另一個以橙色突出顯示的組件。

4.jpg

此組件標記為SEC931 K4B2G1646F-BYMA,我們很幸運,從三星在此網頁中搜索此部件編號結果。本頁上的信息告訴我們這是一個2GB DDR3 SDRAM芯片。一個數據表也可以從這個頁面獲得,收集可用的數據表總是值得的。該芯片負責將可用內存擴展到CPU,並提供一個易失性內存源(RAM)。

到目前為止,我們已經確定了哪些可能是主CPU和外部RAM。然而,我們仍然缺少一種非易失性存儲。所以,接下來,讓我們檢查一下下面用粉色突出顯示的組件。

5.jpg

此組件被標記為Winbond 25N01GVZEIG,搜索此部件編號將導致我們找到此數據表。這部分是一個1G-bit串行SLC NAND閃存芯片。根據數據表,該芯片採用串行外設接口,兼容的電壓範圍在2.6V到3.3V之間。該芯片可能包含機櫃使用的大部分數據,並將成為我們提取固件的主要目標。

最後一個組件靠近GPIO線,標記為MIX2018A。這個組件不像我們看到的其他組件,我無法找到那麼多的信息。然而,該IC 似乎是音頻放大器。

回顧一下到目前為止我們已經確定的組件,有:

瑞芯微RK3128 ARM CPU;

三星SRAM 芯片;

華邦1GBit NAND 閃存;

MIX2018A 音頻放大器;

現在我們已經回顧了這塊板上的集成電路,讓我們看看板上的連接器,看看我們能學到什麼。

連接器分析現在我們已經記錄了主板上的分立組件,我們將嘗試識別主板上的外部連接器。首先,我們有桶形連接器;此連接器在下圖中以藍色標出:

6.jpg

該連接器用於為機櫃供電

在桶形連接器的右側,我們有一個微型USB 端口。這應該立即引起人們的注意,原因有兩個:

這不是一個面向用戶的端口;

這不是一個USB 主機端口,這是一個微型端口,表示USB 設備或可能是OTG(移動)控制器;

繼續向右,我們有兩行頂針。這些是通過早期圖像中顯示的灰色帶狀電纜連接的。該連接器連接到一個單獨的控制板,用於處理操縱桿/按鈕。

在我們的控制面板連接器之後,還有另一個四針連接器。有了這個連接器,它的方向就不那麼明顯了。例如,這個接口可以連接USB接口或耳機接口。我們可以用萬用表的連續性測試來確定這一點。連續性測試將檢查電流是否可以在兩個探頭之間流動,通常用以下符號在萬用表上表示:

8.png

我們可以使用這個模型來測試兩個組件是否連接,我把一根耳機線插入耳機插孔,把探針放在一個金屬環上進行測試。用另一個探針,我觸摸了四針連接器的每一個點,在其中一條線上,萬用表發出了一聲響亮的嗶嗶聲,讓我們知道這兩點之間存在連接。三個引腳中的每一個都與音頻連接器上的一個環相吻合,這是我們的音頻接口!

接下來,我們有用於顯示的連接器。

在顯示屏附近,我們有兩個兩針連接器,一個在右下角,用於為字幕的背光供電,另一個用於金屬外殼外部的開關。

11.jpg

下面的連接器看起來類似於音頻連接器,它是一個四針連接器,其線纜可以連接到控制面板。只有一個接口我們還沒有考慮,那就是在機櫃的一側的USB連接器。如果我們將萬用表設置為連續模式,並將這個連接器的插腳與機櫃側面的USB連接器進行測試,我們發現它們確實是連接的,這是我們的外接USB接口。

我們已經確定了所有必須斷開的連接,以便更好地查看電路板。因此,我們只剩下幾件事情要檢查。當檢查PCB時,要尋找的一件事是任何未使用的測試焊盤或通孔。

如上圖所示,我們可以看到我們有三組不同的未填充的標頭或焊盤。在PCB的頂部,我們有三個通孔,通孔用於在PCB的多層之間進行連接。在檢查嵌入式系統時,此類通孔通常是一個很好的起點,因為它們可能代表開發期間使用的調試頭。

另一個未填充的是由16個焊盤組成,由一個白色矩形和一個小圓圈表示。這組焊盤可能是用於該板上不需要的另一個集成電路。

最後,最後一組焊盤看起來非常類似於用於USB和音頻的連接器。當查看未使用的焊盤時,像這樣的四腳連接通常是通過UART調試控制台的候選者,我們將在下一節中檢查這些標頭文件並討論UART。

檢查調試標頭在查看上一節中指出的未知標頭時,我通常從測量電壓開始。我們可以使用萬用表來做到這一點。為了計算這些焊盤上的電壓,我們將萬用表設置為直流測量模式,並在將黑色探頭放在接地點上的同時探測感興趣的位置。引腳測量如下:

19.png

這些線路上沒有電壓,雖然這令人失望,但並不意外。如果這是一個有源UART 或另一個正在傳輸的數字信號,我們會期望看到電壓波動形式的一些活動。讓我們繼續討論另一個三針接頭。

20.png

當測量這個連接器時,我們的第二個引腳在啟動時波動很大,然後穩定在3.3V。

注意:在搜索串行端口時,你可能並不總是看到這種幅度的電壓波動。波動與信號的活躍程度直接相關,這意味著如果流量很少,你將幾乎看不到波動。如果你懷疑你有UART 接頭或某種數字接口,最好使用邏輯分析儀進行檢查。

我們看到了可能看起來像信號活動的情況(基於電壓波動)。接下來,我們將使用邏輯分析器檢查此流量。邏輯分析儀幫助我們將這些電壓波動轉換為人類可讀的1 和0 序列。為此,我們將使用母母跳線(female-female jumper wire)將我們的邏輯分析儀連接到我們的兩個興趣點,如下圖所示:

22.jpg

分析儀連接後,我們將啟動Pulseview,從下拉菜單中選擇我們的分析儀,該設備在pulseview 中顯示為“Saleae Logic”設備。這個分析儀的最大捕獲速率是24MHz,我們將使用它來進行分析。我們還需要指定樣本數量,我已經將其設置為500G樣本。

23.png

我們將通過點擊運行啟動捕獲,然後使用這些設置啟動機櫃。

24.png

這樣,我們就捕獲了一些流量,在我們進一步討論pulseview 之前,讓我們先介紹一下UART如何在信號級別上工作。我們已經確認有某種流量通過這些線路傳輸;接下來,我們需要了解更多關於UART 流量以及如何分析它的知識。

UARTUART代表通用異步接收發送器,UART是一種允許兩個設備通信的二線製異步串行協議。每一方所需的兩條線路是傳輸(Tx)和接收(Rx)線路。 UART可以用於嵌入式系統中的許多事情,包括與其他處理器通信、傳感器通信和調試訪問。 UART是一種異步協議,意味著不需要時鐘信號。相反,通信雙方都預先配置為以一定的速度進行通信,稱為波特率。波特率以每秒位數為單位。

UART報文/傳輸由以下字段組成:

25.png

即使有了上面的數據包定義,我們也很難確定我們的邏輯捕獲的內容。幸運的是,Pulseview 有一個我們可以利用的UART 解碼器。

解碼UART通信使用pulseview ,我們可以嘗試解碼這個通信,看看它是否確實是一個活動的UART。要設置解碼器,請點擊下面的綠色和黃色符號。這將打開解碼器選擇窗口,在搜索欄中輸入uart,並選擇uart解碼器。

26.png

接下來,我們需要配置UART解碼器。我們需要選擇適當的頻道並設置此解碼器所需的任何協議特定參數。可配置參數如下:

27.png

首先,我們選擇我們的Rx 線路作為我們包含流量的通道;在我們的例子中,這將是D1。對於所有其他字段,我們將保留它們的默認值、8 位數據寬度、無奇偶校驗等。

有一件事我們需要自己調查和了解:波特率。請記住,雙方必須提前就波特率達成一致,沒有協商/啟動順序。我們需要自己確定波特率,否則,解碼器將不知道如何正確地解析這些信號。要確定波特率,我們可以執行以下操作。

1.放大看起來是最小的脈沖之一;

2.使用Pulseview中的數據標記選擇脈衝寬度,點擊下面的按鈕啟用它們;

3.選擇小脈衝範圍後,Pulseview會自動計算頻率並給出赫茲的測量值,如下圖所示。

29.png

赫茲的周期是每秒,我們的波特率是每秒位數的度量。因此,如果我們突出顯示了通過導線發送的一個位,以及這個脈衝的頻率,我們也得到了波特率。

根據Pulseview,我們計算的頻率是115.384 kHz,換算成波特率為115385位/秒。熟悉調試控制台的人可能會注意到,這非常接近常用的波特率115200。我們把這個值代入解碼器,看看會發生什麼。

如果我們查看下面的屏幕截圖,可以看到擁有看似有效的調試日誌。

30.png

我們有一個活躍的UART並且知道它的波特率,但是現在我們需要找到一種與它接口的方法。為此,我們將使用樹莓派。更新後的機櫃管腳如下:

31.jpg

配置樹莓派樹莓派有多個UARTS可用,我們將使用的UART在下圖中突出顯示:

32.png

我們需要確保啟用了適當的設備樹blob來啟用這個UART。設備樹blob的目的是為內核提供一種方法來理解可用的硬件外圍設備。內核將在啟動時讀取這些二進制信息,並枚舉指定的外設。在對嵌入式Linux系統進行逆向工程時,提取這些信息是有益的,因為可以對這些信息進行反編譯,並勾勒出各種外設在內存中的位置。

樹莓派上所有相關的設備樹blob 都可以位於/boot/overlays/中。在這個文件夾中,你會發現用於多種硬件配置的設備樹二進制對象,一些用於特定的帽子(為Pi設計的定制pcb),可以連接到Pi,其他用於啟用各種IO外圍設備。我們可以使用raspi-config工具為UART外設啟用適當的DTB。

在編寫Android 漏洞利用程序時,突破應用程序沙箱通常是關鍵步驟。有各種各樣的遠程攻擊方法可以讓你以應用程序的權限執行代碼,但仍需要沙盒逃逸才能獲得完整的系統訪問權限。

這篇文章重點介紹可從Android 應用程序沙箱訪問系統底層的一個有趣的攻擊面:圖形處理單元(GPU) 硬件。下面描述了Qualcomm 的Adreno GPU 中的一個漏洞,以及如何使用它在Android 應用程序沙箱中實現內核代碼執行。

這項研究是建立在oldfresher的工作基礎上的,他在2019 年8 月報告了CVE-2019-10567。一年後,也就是2020 年8 月上旬,oldfresher發布了一份披露CVE-2019-10567的漏洞paper,以及一些允許遠程攻擊者破壞整個系統的其他漏洞。

但是在2020 年6 月,我發現CVE-2019-10567 的補丁不完整,並與高通的安全團隊和GPU 工程師合作,從根本上修復了這個問題。此新問題的補丁CVE-2020-11179 已發布給OEM 供應商進行集成。

0x01 Android 攻擊面Android 應用程序沙箱是SELinux、seccomp BPF 過濾器和基於每個應用程序唯一UID 的自主訪問控制的不斷發展的組合。沙箱用於限制應用程序可以訪問的資源,並減少攻擊面。攻擊者能夠使用許多途徑來實現沙箱逃逸,例如:攻擊其他應用程序、攻擊系統服務或攻擊Linux 內核。

在高層次上,Android 生態系統中有幾個不同的攻擊面層。以下是一些重要攻擊面的梳理:

層級:Linux生態

描述:影響Android 生態系統中所有設備的問題。

示例:Linux 內核漏洞,如Dirty COW,或標準系統服務中的漏洞。

層級:芯片組

描述:影響Android 生態系統大部分的問題,具體取決於各種OEM 供應商使用的硬件類型。

示例:Snapdragon SoC 性能計數器漏洞,或Broadcom WiFi 固件堆棧溢出漏洞。

層級:供應商

說明:影響特定Android OEM 供應商的大多數或所有設備的問題

示例:三星內核驅動程序漏洞

層級:設備

說明:影響Android OEM 供應商的特定設備型號的問題

示例:Pixel 4 人臉解鎖“attention aware”漏洞

從攻擊者的角度來看, Android 漏洞利用能力是一個以盡可能最具成本效益的方式覆蓋盡可能廣泛的Android 生態系統的問題。 Linux生態層的漏洞會影響許多設備,但與其他層相比,發現漏洞可能成本高昂且利用效果相對短暫。芯片組層通常會存在相當多的漏洞利用的覆蓋範圍,但不如生態層漏洞影響大。對於某些攻擊面,例如基帶和WiFi 攻擊,芯片組層是主要選擇。供應商和設備層更容易找到漏洞,但需要維護大量單獨的漏洞利用。

對於沙盒逃逸,GPU 從芯片組層提供了一個特別有趣的攻擊面。由於GPU 加速在應用程序中被廣泛使用,Android 沙盒允許完全訪問底層GPU 設備。此外,只有兩種GPU 硬件在Android 設備中特別流行:ARM Mali 和Qualcomm Adreno。

這意味著,如果攻擊者能夠在這兩個GPU 實現中找到一個可很好利用的漏洞,那麼他們就可以有效地保持針對大多數Android 生態系統的沙盒逃逸漏洞利用能力。此外,由於GPU 非常複雜,有大量閉源組件、固件、微代碼,因此很有可能會找到一個危害極高且長期存在的漏洞。

考慮到這一點,在2020 年4 月下旬,我注意到Qualcomm Adreno 內核驅動程序代碼中有以下提交:

From0ceb2be799b30d2aea41c09f3acb0a8945dd8711MonSep1700:00:002001From:JordanCrouseDate:Wed,11Sep201908:32:15-0600Subject:[PATCH]msm:kgsl33 360Makethe'scratch'globalbufferusearandomGPUaddressSelectarandomglobalGPUaddressforthe'scratch'bufferthatisusedbytheringbufferforvarioustasks.當我們想到向地址添加熵時,通常會想到地址空間佈局隨機化(ASLR)。但這裡我們談論的是GPU 虛擬地址,而不是內核虛擬地址,為什麼需要隨機分配GPU 地址?

此提交是CVE-2019-10567 的安全補丁之一,這些補丁在高通的諮詢中有相關鏈接。此CVE 還包含一個相關補丁:

From8051429d4eca902df863a7ebb3c04cbec06b84b3MonSep1700:00:002001From:JordanCrouseDate:Mon,9Sep201910:41:36-0600Subject:[PATCH]msm:kgsl:Execut euserprofilingcommandsinanIBExecuteuserprofilinginanindirectbuffer.Thisensuresthataddressesandvaluesspecifieddirectlyfromtheuserdon'tendupintheringbuffer.所以問題就變成了,為什麼用戶內容不會最終出現在ringbuffer 上,這個補丁真的可以防止這種情況發生嗎?如果我們恢復臨時映射的基地址會發生什麼?至少從表面上看,兩者都是可行的,這個研究項目有了一個良好的開端。

在我們進一步討論之前,讓我們退一步描述一下這裡涉及的一些基本組件:GPU, ringbuffer, scratch mapping等。

0x02 Adreno GPU 簡介GPU 是現代圖形計算的主要組件,大多數應用程序都廣泛使用GPU。從應用程序的角度來看,GPU 硬件的具體實現通常由OpenGL ES 和Vulkan 等庫抽像出來。這些庫實現了一個標準API,用於對常見的GPU 加速操作進行編程,例如texture mapping 和running shaders。然而,在底層,此功能是通過與內核空間中運行的GPU 設備驅動程序交互來實現的。

image-20220324233623933.png image-20220324233623933

特別是對於Qualcomm Adreno,/dev/kgsl-3d0設備文件最終用於實現更高級別的GPU 功能。可在不受信任的應用程序沙箱中直接訪問/dev/kgsl-3d0文件,因為:

1.設備文件在其文件權限中設置了全局讀/寫訪問權限。權限由ueventd設置:

sargo:/#cat/system/vendor/ueventd.rc|grepkgsl-3d0/dev/kgsl-3d00666systemsystem2.設備文件的SELinux 標籤設置為gpu_device,並且untrusted_app SELinux 上下文對此標籤有特定的允許規則:

sargo:/#ls-Zal/dev/kgsl-3d0crw-rw-rw-1systemsystemu:object_r:gpu_device:s0239,02020-07-2115:48/dev/kgsl-3d0hawkes@glaptop:~$adbpull/sys/fs/selinux/policy/sys/fs/selinux/policy33 3601filepulled,0skipped.16.1MB/s.hawkes@glaptop:~$sesearch-A-suntrusted_apppolicy|grepgpu_deviceallowuntrusted_appgpu_device:chr_file{appendgetattrioctllockmapopenreadwrite};這意味著應用程序可以打開設備文件。 Adreno“KGSL”內核設備驅動程序主要通過許多不同的ioctl 調用(例如分配共享內存、創建GPU 上下文、提交GPU 命令等)和mmap(例如將共享內存映射到用戶空間)來調用應用。

0x03 GPU 共享映射在大多數情況下,應用程序使用共享映射將vertices, fragments 和shaders加載到GPU 中並接收計算結果。這意味著某些物理內存頁面會在用戶應用程序和GPU 硬件之間共享。

要設置新的共享映射,應用程序將通過調用IOCTL_KGSL_GPUMEM_ALLOC ioctl 向KGSL 內核驅動程序請求分配。內核驅動程序將準備一個物理內存區域,然後將該內存映射到GPU 的地址空間。最後,應用程序將使用分配ioctl 返回的標識符將共享內存映射到用戶空間地址空間。

此時,物理內存的同一頁上有兩個不同的視圖。第一個視圖來自用戶態應用程序,它使用虛擬地址來訪問映射到其地址空間的內存。 CPU 的內存管理單元(MMU) 將執行地址轉換以找到適當的物理頁面。

另一個是從GPU 硬件本身來看,它使用GPU 虛擬地址。 GPU 虛擬地址由KGSL 內核驅動程序選擇,它使用僅用於GPU 的頁表結構配置設備的IOMMU(在ARM 上稱為SMMU)。當GPU 嘗試讀取或寫入共享內存映射時,IOMMU 會將GPU 虛擬地址轉換為內存中的物理頁面。這類似於在CPU 上執行的地址轉換,但地址空間完全不同,即應用程序中使用的指針值將不同於GPU 中使用的指針值。

image-20220324234002661 image-20220324234002661.png

每個用戶態進程都有自己的GPU 上下文,這意味著當某個應用程序在GPU 上運行操作時,GPU 將只能訪問它與該進程共享的映射。這是必需的,這樣一個應用程序就不能要求GPU 從另一個應用程序讀取共享映射。在實踐中,這種分離是通過在GPU 上下文切換發生時更改將哪一組頁表加載到IOMMU 來實現的。每當安排GPU 運行來自不同進程的命令時,就會發生GPU 上下文切換。

然而,某些映射被所有GPU 上下文使用,因此可以出現在每組頁表中。它們被稱為全局共享映射,用於GPU 和KGSL 內核驅動程序之間的各種系統和調試功能。雖然它們從未直接映射到用戶級應用程序,例如惡意應用程序無法直接讀取或修改全局映射的內容,但它們會同時映射到GPU 和內核地址空間。

在被root的Android 設備上,我們可以使用以下命令dump全局映射及其GPU 虛擬地址:

sargo:/#cat/sys/kernel/debug/kgsl/globals0x00000000fc000000-0x00000000fc000fff4096setstate0x00000000fc001000-0x00000000fc040fff262144gpu-qdss0x00000000fc041000-0x00000000fc048fff32768memstore0x00000000fce7a000-0x00000000fce7aff f4096scratch0x00000000fc049000-0x00000000fc049fff4096pagetable_desc0x00000000fc04a000-0x00000000fc04afff4096profile_desc0x00000000fc04b000-0x00000000fc052fff32768ringbuffer0x00000000fc053000-0x00000000fc053fff4096pagetable_desc0x00 000000fc054000-0x00000000fc054fff4096profile_desc0x00000000fc055000-0x00000000fc05cfff32768ringbuffer0x00000000fc05d000-0x00000000fc05dfff4096pagetable_desc0x00000000fc05e000-0x00000000fc05efff4096profile_desc0x00000000fc05f000-0x0 0000000fc066fff32768ringbuffer0x00000000fc067000-0x00000000fc067fff4096pagetable_desc0x00000000fc068000-0x00000000fc068fff4096profile_desc0x00000000fc069000-0x00000000fc070fff32768ringbuffer0x00000000fc071000-0x00000000fc0a0fff1966 08profile0x00000000fc0a1000-0x00000000fc0a8fff32768ucode0x00000000fc0a9000-0x00000000fc0abfff12288capturescript0x00000000fc0ac000-0x00000000fc116fff438272capturescript_regs0x00000000fc117000-0x00000000fc117fff4096powerup_register_l ist0x00000000fc118000-0x00000000fc118fff4096alwayson0x00000000fc119000-0x00000000fc119fff4096preemption_counters0x00000000fc11a000-0x00000000fc329fff2162688preemption_desc0x00000000fc32a000-0x00000000fc32afff4096perfcounter_save_re store_desc0x00000000fc32b000-0x00000000fc53afff2162688preemption_desc0x00000000fc53b000-0x00000000fc53bfff4096perfcounter_save_restore_desc0x00000000fc53c000-0x00000000fc74bfff2162688preemption_desc0x00000000fc74c000-0x00000000fc74 cfff4096perfcounter_save_restore_desc0x00000000fc74d000-0x00000000fc95cfff2162688preemption_desc0x00000000fc95d000-0x00000000fc95dfff4096perfcounter_save_restore_desc0x00000000fc95e000-0x00000000fc95efff4096smmu_info從左到右,我們看到每個全局映射的GPU 虛擬地址,然後是大小,然後是分配的名稱。通過多次重啟設備並檢查佈局,可以看到暫存緩衝區確實是隨機的:

0x00000000fc0df000-0x00000000fc0dffff4096scratch.0x00000000fcfc0000-0x00000000fcfc0fff4096scratch.0x00000000fc9ff000-0x00000000fc9fffff4096scratch.0x00000000fcb4d000-0x00000000fcb4dfff4096scratch同樣的測試表明,暫存緩衝區是唯一隨機化的全局映射,所有其他全局映射在[0xFC000000,0xFD400000]範圍內都有一個固定的GPU 地址。這是有道理的,因為CVE-2019-10567 的補丁只為暫存緩衝區分配引入了KGSL_MEMDESC_RANDOM 標誌。

所以我們現在知道暫存緩衝區至少在某種程度上是正確隨機的,並且它是存在於每個GPU 上下文中的全局共享映射,但是暫存緩衝區到底是做什麼用的呢?

0x04 Scratch 緩衝區深入驅動程序代碼,我們可以清楚地看到在驅動程序的探測例程中分配了暫存緩衝區,這意味著暫存緩衝區將在設備首次初始化時分配:

intadreno_ringbuffer_probe(structadreno_device*adreno_dev,boolnopreempt){.status=kgsl_allocate_global(device,device-scratch,PAGE_SIZE,0,KGSL_MEMDESC_RANDOM,'scratch');我們還發現了下面的註釋:

/*SCRATCHMEMORY:Thescratchmemoryisonepageworthofdatathat*ismappedintotheGPU.Thisallowsforsome'shared'databetween*theGPUandCPU.Forexample,itwillbeusedbytheGPUtowrite*eachupdatedRPTRforeachRB.通過在內核驅動程序中交叉引用生成的內存描述符(device-scratch )的所有用法,我們可以找到暫存緩衝區的兩個主要用法:

1.搶占恢復緩衝區的GPU 地址被dump到暫存內存中,如果較高優先級的GPU 命令中斷較低優先級的命令,則會使用該暫存內存。

2.環形緩衝區(RB) 的讀指針(RPTR) 從臨時內存中讀取,並在計算環形緩衝區中的可用空間量時使用。

可以開始串聯思路。首先,我們知道CVE-2019-10567 的補丁包括對暫存緩衝區和環形緩衝區處理代碼的更改——這表明我們應該關注上面的第二個用例。

如果GPU 正在將RPTR 值寫入共享映射(如註釋所示),並且如果內核驅動程序正在從暫存緩衝區讀取RPTR 值並將其用於分配大小計算,那麼如果我們可以讓GPU 寫入一個RPTR 值無效或不正確。

0x05 環形緩衝區要了解無效RPTR 值對環緩衝區分配可能意味著什麼,我們首先需要描述環緩衝區本身。當用戶態應用程序提交GPU 命令( IOCTL_KGSL_GPU_COMMAND ) 時,驅動程序代碼通過使用生產者-消費者模式的環形緩衝區將命令分派給GPU。內核驅動程序會將命令寫入環形緩衝區,GPU 將從環形緩衝區讀取命令。

這以與經典循環緩衝區類似的方式發生。在底層,ringbuffer 是一個固定大小為32768 字節的全局共享映射。維護兩個索引來跟踪CPU 寫入的位置(WPTR) 和GPU 讀取的位置(RPTR)。為了在ringbuffer 上分配空間,CPU 必須計算當前WPTR 和當前RPTR 之間是否有足夠的空間。這發生在adreno_ringbuffer_allocspace 中:

unsignedint*adreno_ringbuffer_allocspace(structadreno_ringbuffer*rb,unsignedintdwords){structadreno_device*adreno_dev=ADRENO_RB_DEVICE(rb);unsignedintrptr=adreno_get_rptr(rb);[1]unsignedintret;if(rptr_wptr){[2]unsign edint*cmds;if(rb-_wptr+dwords_wptr;rb-_wptr=(rb-_wptr+dwords)%KGSL_RB_DWORDS;returnRB_HOSTPTR(rb,ret);}/**Thereisn'tenoughspacetowardtheendofringbuffer.So*lookforspacefromthebeginningofringbufferuptothe*readpointer.*/

我們將在本文討論攻擊者在其攻擊中是否選擇內核級訪問的原因。 Windows內核威脅長期以來一直受到攻擊者的青睞,因為它可以讓攻擊者獲得高特權訪問和檢測規避能力。時至今日,這些難以消除的威脅仍然是惡意活動攻擊鏈的關鍵組成部分。事實上,SentinelOne最近發現攻擊者濫用Microsoft簽名的驅動程序,對電信、業務流程外包(BPO)、託管安全服務提供商(MSSP)和金融服務行業的組織進行有針對性的攻擊。本月,SophosLabs還報告稱,他們發現了一個加密簽名的Windows驅動程序和一個可執行的加載器應用程序,該應用程序可以終止目標設備上的端點安全進程和服務。

我們將在2023年1月發布的研究論文“深入了解Windows內核威脅”中對值得關注的Windows內核威脅的狀態進行了更全面的分析。

追求內核級訪問的利弊對於攻擊者來說,不受限制地訪問內核是他們攻擊的最佳選擇。他們不僅能夠在內核級別執行惡意代碼,而且還能夠破壞受害者的安全防禦而不被發現。然而,需要注意的是,開發內核級rootkit和其他低級威脅也有其自身的缺點。

有利的一面:獲得對系統資源的高度特權訪問;

隱藏設備上的惡意活動,使檢測和響應活動更加困難;

保護惡意工件免受正常系統過濾過程的影響;

執行可以長時間繞過檢測的隱形操作;

從第三方防病毒產品獲得繼承的信任;

篡改多用戶模式應用程序所依賴的核心服務數據流;

篡改阻礙惡意活動的第三方安全產品;

實現非常低的檢測率,目前大多數現代rootkit在很長一段時間內都沒有被發現。

不利的一面:開發這些威脅可能代價高昂;

與其他用戶模式應用程序惡意軟件類型相比,開發和實現內核rootkit更加困難,這並不能使它們成為大多數攻擊的理想威脅;

內核rootkit的開發需要高素質的內核模式開發人員,他們了解目標操作系統的內部組件,並在逆向工程系統組件方面具有足夠的能力。

由於內核rootkit對錯誤更敏感,如果內核模塊中的代碼錯誤導致系統崩潰並觸發藍屏死亡(BSOD),它們可能會暴露整個操作。

如果受害者的安全機制已經失效或可以通過更簡單的技術消除,那麼引入內核模式組件將使攻擊變得複雜,而不是支持攻擊。

內核威脅有多普遍?我們分析了完全依賴內核驅動程序組件或在其攻擊鏈中至少有一個模塊在內核空間中執行的各種威脅。

在我們的研究中,我們根據可觀察到的技術將內核級威脅分為三個集群:

集群1:繞過內核模式代碼簽名(KMCS)策略的威脅;

集群2:使用合法的創建自己的驅動程序技術符合KMCS的威脅;

集群3:轉移到較低抽象層的威脅;

根據我們的觀察,過去七年中公開報導的值得關注的威脅和其他重大事件的數量從2018年開始呈現穩步上升的趨勢。

1.png

2015年4月至2022年10月包含內核級威脅的公共情報報告數量

目前,影響Windows內核的最大數量的內核威脅仍然屬於第一個集群。在Windows 10引入的新的基於管理程序的防禦解決方案的採用率提高之前,該集群中的威脅數量預計會增加。隨著採用率的增長,預計首批集群威脅的數量將大幅減少。

2.png

2015年4月至2022年10月,三個集群的內核級威脅分佈情況

然而,數據顯示,在過去三年中,屬於第二和第三集群的威脅數量一直在增加。

3.png

2015年4月至2022年10月按集群分類的內核級威脅

由於開發成本較高,第二集群威脅不太常見。儘管在過去五年中,第二個集群威脅的數量有所增加,但由於Windows 10和11中的KMCS策略,預計會減少並最終停止。同時,屬於第三個集群的威脅是最不常見的,因為它們的複雜性。我們認為,隨著攻擊者將其最初的感染點提前轉移到逃避現代安全機制的過程中,第三集群威脅將在未來幾年緩慢增加。

我們還根據這些威脅的具體用例對其進行了分類。

4.png

2015年4月至2022年10月使用內核級惡意軟件的威脅類型

根據我們的分析,APT間諜惡意軟件在攻擊中使用的內核級組件最多。 APT組織以擁有資源在攻擊中使用隱秘組件(如內核rootkit和較低級別的植入)而聞名。

勒索軟件和加密貨幣挖礦威脅也在其攻擊中使用了大量內核級組件,這很可能避免被安全產品檢測到,因為它們會是否惡意有效負載並從受害者設備上竊取資源。

總結根據我們對內核級威脅數據的分析,高級和成熟的惡意行為者仍然並將繼續尋求對Windows操作系統的高權限訪問,以確保他們的攻擊被成功部署。由於端點保護平台(EPP)和端點檢測和響應(EDR)技術的有效性,攻擊者將遵循阻力最小的路徑,並讓他們的惡意代碼從內核或更低的級別運行。這就是為什麼,儘管屬於這三個集群的一些內核級威脅顯著減少,但我們相信低級別的威脅在未來不會完全過時。

另外,請關注我們將於2023年1月發布的研究文章《深入了解Windows内核威胁》 中對Windows內核威脅的全面分析。