Jump to content
  • Entries

    16114
  • Comments

    7952
  • Views

    86380695

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.

0x01 基礎介紹GPS追踪器可以幫助定位孩子,寵物、汽車,從而使用戶更加安心。用戶可以通過提供簡單的SOS按鈕來呼叫幫助,從而幫助確保老年人或殘疾人的安全。為了實現此目的,許多設備在亞馬遜和eBay等常見網站上進行了銷售,售價為25至50美元,與使用智能手機實現某些相同功能相比,它們在價格上更具吸引力。

但是,我們對這些設備的真正了解有多少,這些設備知道我們在哪裡,有時甚至可以聽到我們的聲音,我們在這裡討論的大多數設備也都帶有麥克風。事實證明,當今的某些GPS追踪器,尤其是那些處於低端市場的GPS追踪器,是存在風險的,而不是讓你省心。他們不僅缺乏安全警報,而且這些設備更有可能使你的親人更加危險。

我們決定看一下亞馬遜,eBay和阿里巴巴上的幾種兒童追踪器,以了解它們如何經受住我們的安全測試。

GPS追踪器基礎當今可用的GPS追踪器使用多種通信渠道和技術。圖1顯示了一個典型的體系結構。

figure1-1-768x442.jpg

圖1: GPS追踪器的典型配置和架構

其中涉及許多傳輸協議和網絡層,因此我們同時在許多方面進行工作,以評估這些設備的安全性。

通常,追踪器是一種簡單,廉價的設備,以SOC(片上系統)模塊為主要組件。串行總線將SOC連接到提供位置的GPS模塊以及連接到SIM卡的GPRS調製解調器,SIM卡為設備提供DATA + SMS功能。通常,你還可以找到按下“ SOS”按鈕時使用的用於電話功能的麥克風和揚聲器。

figure2-1-768x368.jpg

圖2: GPS追踪器內部工作原理

我們將研究分為四類:

分析特定設備的啟動過程

分析管理門戶網站

分析移動應用程序和雲平台之間的流量

分析追踪器和雲平台之間的GPRS流量

攻擊真實設備我們決定選擇一個追踪器並進行一些更廣泛的研究。我們選擇了市售的追踪器—— T8 Mini GPS Tracker,該追踪器像一個鑰匙扣,具有SOS按鈕和雙向通訊功能(揚聲器和麥克風)。

image-20220323093825042.png

圖3:感興趣的追踪器

首先引起我們注意的是使用流程,隨附的說明:

image-20220323093915925.png

按照說明,有一個Web門戶和一個移動應用程序可用於管理追踪器。我們選擇了最便捷的方法,首先打開了一個可達的Web應用程序http://en.i365gps.com。在許多層面都存在錯誤:image-20220323094055485

image-20220323094055485.png

圖4: Web應用程序登錄截圖

如你所見,第一個red flag登錄表單是通過HTTP協議提供的,而不是通過更安全的HTTPS。此外,有兩個選擇可以連接到雲平台:使用用戶名和密碼的帳戶或使用ID和密碼的帳戶。

image-20220323094235628.png

圖5:默認密碼

這適用於Android應用程序和Web應用程序。令人震驚的事實是:“ …如果需要通過用戶名登錄,則用戶需要聯繫經銷商註冊用戶名。”由於你必須致電經銷商以請求用戶名,因此很明顯,可以使用ID,其密碼為“ 123456”。

出於演示目的,我們的ID為:17032491112和密碼123456。當你登錄到平台時,將出現此界面。

image-20220323094518536-16479999196441.png

image-20220323094518536圖6: Web應用程序界面

這裡的所有內容仍然通過不安全的HTTP協議傳輸,你可以更改密碼,但是仍然無法創建帳戶,讓我們把關注點放在ID上。

用戶名ID作為進入應用程序的“username”的ID是11位數。正如你在設備信息圖7中所看到的那樣,它有時被稱為IMEI,代表“國際移動設備身份”。

image-20220323094703856.png

image-20220323094703856圖7:設備標識

你可以看到設備被標識為T8S-49112,因此後五位數字取自“ IMEI”,而開頭可能是型號。這里奇怪的是,IMEI的數字不符合標準IMEI規範。根據規範,IMEI應該為15位長,最後一位是所謂的控制位。當我們進行更多搜索時,我們在追踪器(圖8)中發現了完整的IMEI ,隨後在包裝盒上的小標籤上也發現了完整的IMEI 。因此,在我們的案例中,完整的IMEI為:

1653140978186756.png

圖8:追踪器的內部以及IMEI和ID image-20220323094851519

image-20220323094851519.png

圖9: IMEI簡化的細分

因此,當我們獲取“ IMEI”和ID號並將其與規範格式匹配時,我們將獲得

image-20220323094919750.png image-20220323094919750

圖10:與IMEI匹配的ID

TAC的第一部分由各個子部分組成,但為簡單起見,我們可以說它以與MAC地址前綴幾乎相同的方式分配給供應商。這也意味著所有其他追踪器的數字都是可預測的,你可以輕鬆枚舉它們。結合固定密碼,這意味著我們可以按此IMEI編號順序登錄約25%的設備。

0x02 協議分析好了,暫時將IMEI枚舉放在一邊,讓我們看看設備,移動應用程序和Web應用程序如何與雲平台對話。

從Web應用到雲平台我們已經知道Web應用程序中的所有通信都是通過HTTP進行的,所以讓我們看一下使用某些標準工具從Web應用程序發出的請求是什麼:

figure11.jpg

圖11: Web應用程序AJAX請求(Chrome中的開發人員工具)

通過使用簡單的工具,我們可以看到所有請求都是純文本格式的標準JSON AJAX請求。我們不需要深入分析這部分,因為這些命令與移動應用程序向雲平台發出的命令大致相同。有趣的是,所有JSON請求都再次未加密且以明文形式發送,但更重要的是設備可以發出的命令。除了獲得預期的命令外,例如獲取GPS坐標和位置,還有其他一些其他的功能:

你可以使追踪器撥打任意電話號碼,並且一旦連接,就可以通過追踪器在對方不知情的情況下收聽。

你可以使追踪器代表自己將SMS消息發送到任意號碼。這可以讓你獲取設備的電話號碼並將SMS用作攻擊媒介。

你可以將URL發送到追踪器,追踪器可以從該URL 更新其固件,從而使攻擊者可以在設備上更新新的固件。

從移動應用到雲平台figure12.jpg

圖12:配套應用程序

現在讓我們看一下AIBEILE android應用程序如何與雲平台進行通信。使用Wireshark捕獲流量後,我們立即看到它使用純文本HTTP協議通過非標準端口TCP:8018與雲平台進行通信。

figure13-1024x336.jpg

圖13: Android應用程序在登錄時捕獲了流量

可以看到整個通信仍然未加密,並以純文本形式發送到端點http://(redacted):8018/openapiv3.asmx。這是請求的截圖:

figure14-1024x704.jpg

圖14:登錄數據包的詳細信息

有趣的是,登錄請求使用內置的Key和LoginAPP值,這給我們一個提示,即該框架正在由不同的應用程序使用,因為Key 也被內置在APK 文件中。

LoginType字段在此處通過用戶名和密碼(LoginType=0)或IMEI和密碼(LoginType=1)方法進行區分,此參數控制你使用的憑據類型。

登錄成功後,將以HTTP形式返迴響應,該響應中包含XML字符串,該字符串實際上是JSON。典型的成功響應如下所示:image-20220323100204747

image-20220323100204747.png

圖15:對登錄請求的JSON響應

可以看到很多很明顯的字段,但這裡最重要的字段是key2018,這是Base64編碼的64字節長的會話密鑰,並且deviceID在這兩個密鑰中都需要進行進一步的請求和命令。

這樣的命令之一可能是GetTracking。你可以看到登錄後發出了該命令(圖13),唯一的輸入參數是:

figure16-768x384.jpg

圖16: 請求追踪器的實際位置或最後看到的位置

我們不能完全確定Model 字段發的含義。下面是響應包:

image-20220323101210115 image-20220323101210115.png

圖17: 對GetTracking調用的響應

應用程序和雲平台完全以純文本方式進行通信,沒有加密。

從追踪器到雲端image-20220323101138651.png

現在,讓我們更深入地研究設備如何與雲平台對話,如何通過移動運營商提供商在實際追踪器和服務器之間交換數據。

對在LTE或GPRS移動協議之上使用IP傳輸的協議進行解碼或逆向並不容易。通常沒有簡單的方法來利用流量,因為流量先封裝在GPRS中,然後再從設備傳輸到電信運營商,然後再直接傳輸到雲平台服務器,而沒有明顯的方法來嗅探數據流向雲平台或返回雲平台的方式。

如果要分析此類流量,則基本上有兩種選擇:

建立自己的偽BTS站並運行自己的GSM網絡,以便觀察通過的所有流量。

在設備內部的GPRS調製解調器對數據進行編碼和發送之前檢查數據。

第一種選擇很複雜,要合法地進行,你需要一個法拉第籠,因為在大多數國家/地區,在沒有許可證的情況下運行自己的GSM網絡是非法的。同樣,建造設備並非易事,但是有許多開源解決方案(https://osmocom.org/projects/osmobts),與以太網或WiFi嗅探相比,它並不方便易用。

第二種選擇需要一些硬件技能,並且設備可能會失效。正如我們在一開始就指出的那樣,大多數GPS追踪器內部都將GPRS調製解調器作為一個離散組件,儘管通常很小,但仍有很大的機會利用主CPU和GPRS調製解調器之間的串行線。

在打開GPS追踪器後,確定了一些看上去完全類似於我們所需的連接點的墊。有兩組串行連接墊(TXD/RXD/GND),很明顯,一組用於GPS到CPU的通訊,另一組用於CPU到GPRS調製解調器,因此通過反複試驗,我們確定了正確的一組:

image-20220323101525811.png

圖19:進入追踪器以進行GPRS通信

完成此測試後,我們可以確認所有數據未加密地從GSM網絡傳輸到雲平台服務器。通信是基於文本的協議,最重要的是缺少授權,整個工作僅需通過其IMEI識別追踪器即可。

從SMS 到追踪器最後一點是,你可以使用另一個頻道來控制追踪器,你可以使用簡單的SMS消息進行設置並獲取一些信息。要獲取GPS位置,你可以通過手機向定位器中插入的SIM卡號碼發送短信。為此,你需要知道密碼,但是除非用戶更改了密碼,否則所有設備的默認密碼都是相同的。

figure20-1-740x1024.jpg

圖20:手冊中說明的SMS命令

我們通過進行一些硬件逆向學習了所有這些知識,但是我們真的必須這樣做嗎?事實證明,在研究命令時,你可以通過SMS消息直接向追踪器發出命令,我們發現了這一點:

image-20220323101820167.png

圖21:用於設置追踪器的SMS命令

該命令隱藏在名稱“Setup IP and port”下,意味著你可以設置設備與之通信的雲平台服務器所在的IP地址和TCP端口。這是攻擊者想要的信息;結合用於來回發送數據的不安全協議,你可以輕鬆地進行MITM中間人攻擊,並使用標準IP工具捕獲所有數據。

如下測試:

figure22-768x630.jpg

圖22:通過惡意服務器轉發流量

image-20220323102010230.png

圖23: Wireshark捕獲了位置數據包的流量

可以輕鬆發現IMEI/ID和坐標,已識別命令的格式似乎是文本格式,並且遵循以下格式:

Heartbeatcommandtracker-server

[3G*1703249112*000C*LK,0,1226,85]

Heartbeatresponseserver-tracker:

[3G*1703249112*0002*LK]

Activatemonitormode(callbackthisnumber)server-client:

[3G*1703249112*0015*MONITOR,+420612661749]

SendSMS“Test”toprovidednumber(+420602661749)server-client:

[3G*1703249112*0016*SMS,+420602661749,Test]

Positionandstatus(client-server):

[3G*1703249112*0090*UD,210619,053538,V,37.481010,N,-122.2315369,W,0.00,0.0,0.0,0,86,86,0,15,00000000,4,255,202,1,2082,5673,140,2082,12,128,2082,5671,118,2082,11,115]0x03 查找API在調查各種API時,發現我們正在調查的平台似乎已被許多其他供應商廣泛使用。通過谷歌搜索,我們找到了移動應用程序-雲接口的文檔:

image-20220323102309858.png

圖24:在另一個實例中找到的記錄的部分列表API

遍歷此API提供的每個命令並不是本研究的目的,但是讓我們看一些示例以進一步說明安全性有多糟糕以及這會對普通用戶造成什麼後果。

儘管我們調查的追踪器沒有攝像頭,但其他使用相同雲平台框架的追踪器卻有攝像頭,例如下圖的A19-3G Network GPS Smart Watch,此命令激起了我們的興趣。

場景選擇在上一篇文章中已經闡述了數據洩露成本估算的場景類型,接下來就是通過將理論化的風險事件與實際的業務流程易受運營損失類別(使用BIS發布的指南)進行比較,以便可信地描述業務後果,從而更接近現實的現實世界網絡威脅場景。也就是說,我們需要使用實際系統如何工作的知識來創建風險事件發生的場景的詳細信息。由於系統由人員、流程和技術組成,因此這些知識包括但不限於對手行為模式、軟件漏洞模式、當前技術控制維護困難以及業務用戶的操作或行為。

例如,上一篇文章圖3中的“信息盜竊”場景可以實例化為一種典型的惡意軟件攻擊,通過電子郵件網絡釣魚或水坑攻擊技術,以最終用戶為目標,這些攻擊會吸引具有互聯網訪問權限的金融專業人士點擊使用其訪問(系統對手行為模式)安裝惡意軟件的鏈接,並蒐索允許該軟件從最終用戶升級到管理特權訪問的常見漏洞(軟件漏洞模式)。為特定組織定制的場景將準確確定預計哪個平台具有此漏洞。它將識別惡意軟件對平台所做的更改(基於已知的技術維護問題),並從那裡確定桌面軟件進程和數據影響的負面影響。例如,軟件性能可能會降低,並且數據可能會變得不可訪問。然後,業務部門將被要求呼叫技術支持(業務用戶行為)。此方案描述為由業務、技術和風險專業人員組成的團隊提供了足夠的信息,以找出影響的詳細信息。

請注意,這只是一個潛在的風險事件,可用於在更深入的場景創建的系統方法中梳理出細節。簡單地說,一個場景可以由四個元素定義:

行為人:具有動力,技能和資源的理論對手

戰術:旨在實現對手目標的技術工作流程

目標:行為人必須利用的特定技術組件來製定策略

漏洞:暴露於行為人、技術或業務流程中,從而實現戰術

在前面的創建中,關鍵要素是:

行為人:黑客

策略:網絡釣魚部署的惡意軟件

目標:企業台式機

漏洞:操作系統安全

為了系統地分析所有系統的風險,這些元素可用於劃分和征服組織在風險分析過程中可能開發的每個風險類別中的示例事件的整體風險分析。當然,結合可以劃分和征服此類分析的觀察,重要的是要注意每個元素的潛在值可能會隨時間而變化,並且應始終反映當前的威脅情報。

例如,一組不同的行為人、策略、目標和漏洞可以提供替代場景選擇。另一個潛在的場景可能來自對使用內部最終用戶的訪問對公司基礎架構的中斷的描述,導致用戶生產力損失、業務通信中斷和桌面中斷,如下所示:

行為人:民族國家

目標:網絡路由器

漏洞:供暖、通風和空調(HVAC)供應商接入網絡允許將網絡路由命令引入企業基礎架構

策略:滲透HVAC供應商,使用維護連接引入默認路由,將所有網絡流量傳播並定向到民族國家擁有的域

基於這組替代元素的場景創建表明,資金充足的專業犯罪組織以HVAC設備為目標,利用HVAC供應商防火牆中的漏洞,並利用有關內部企業網絡漏洞的情報(可能來自內部人員)。實際設想的活動可能更值得商榷,但所有利益攸關者都必須認為是合理的,或者,如前所述,缺乏共識可能使利益攸關者難以認真對待影響估計。請注意,對於對強控制措施有相當自豪感的組織來說,為了通過方案促進成本分析,尤其難以暫停對這些控制措施的信念。只要在每個可能的風險類別中至少有一個完整分析的場景,就可以消除發生概率較低的單個場景。

另請注意,儘管由於控制力強,場景可能被視為低概率,但情況恰恰相反。在前面的示例中,組織內動態路由體系結構的普遍存在將增加資金充足的對手通過該方案帶來的單一供應商漏洞利用內部網絡中已知漏洞的可能性。通過這種方式,從情景分析中計算的成本可以提出額外的網絡路由控制以避免損失的情況。

下圖提供了基於在前面的列表中介紹的四個元素的場景開發的替代注意事項。與其考慮最終用戶對企業基礎設施的威脅,不如考慮內部用戶對核心銀行系統的威脅。當機構決定計算潛在數據洩露事件的成本時,建議在場景選擇之前準備此類潛在替代場景。大量的例子有助於說服懷疑者,至少有一種情況是可能的,討論哪些更有可能,可以從團隊了解的關於目標環境的一些有形的基本事實開始。另請注意,四種替代技術方案中只有一種針對核心銀行系統本身。對金融資產而不是技術資產的關注往往會導致對對手技術攻擊的潛在途徑進行更具創造性的猜測。

68c41b3c-4793-4be6-af4a-f60f0c8cf28a.png

替代網絡安全場景元素

成本估算關於網絡安全漏洞成本的大部分文獻都集中在“信息盜竊”場景上。金融公司通常為數據洩露的客戶支付信用報告凍結和身份盜竊保險。他們還會產生通知客戶數據洩露事件發生的法律費用,並且這些補救措施是可用的。對於金融機構來說,重要的是要確切地了解這些機制在每個客戶的基礎上的成本。這些每個客戶的成本由多個組織定期調查;最廣為人知的是波耐蒙研究所。該機構的研究依賴於對數據洩露公司管理層的訪談,並試圖不僅量化通知和法律成本,還量化更難以估計的變量,如客戶流失以及特定響應活動在降低數據洩露成本方面的功效。然後,他們將數據洩露的總成本除以丟失的記錄數量,並跨行業,國家和年份比較這些數字。在2017年的Ponemon研究中,每個客戶記錄的綜合平均值為141美元,美國最高(225美元),印度最低(64美元)。該研究沒有聲稱是有效的統計研究,因此任何個別公司的經驗都可能有所不同。但是,這些數據確實提供了一定程度的指導。

在沒有實際的、具體的事件需要分析的情況下,管理層必鬚根據相關經驗和理性分析來估計數據洩露的成本。大多數網絡安全場景都是按滑動標尺量化的,將事件的預期持續時間估計為在最佳和最壞情況下識別和恢復通常需要的時間。當前技術過程可用於根據對技術支持的第一次呼叫以及技術支持升級到的技術操作員、管理員和工程師的預期活動來確定應遵循的事件順序。獨立風險或治理專家的角色通常是遍歷事件的過程和歷史數據,以確定在高效和有效事件響應和解決的最佳或最壞情況下的預期情景持續時間。在此類研究中檢查的信息通常包括但不限於以下內容:

受數據洩露影響的整套設備的系統清單

管理任務歷史記錄或業務恢復測試結果,顯示管理員通常在從網絡安全攻擊中恢復所需的系統還原任務上花費的時間

在升級路徑中重新分配技術資源所需的時間,這些資源通常被分配到其他工作,包括顧問和員工,如開發人員、工程師和架構師

以時間和材料為基礎工作的供應商所需的時間

安裝維護系統可用性所需的新設備或軟件所需的時間

如果程序不包括對所審查事件類型的反應,則必須分配時間,以在初始反應步驟以及最終調查期間捕捉不確定性或混亂的影響。如果沒有歷史上的內部先例,那麼可以使用年度Verizon數據洩露和調查報告等出版物盡可能地研究行業數據。

即使在所有響應程序似乎都已到位的情況下,人員或供應商可用性等變量也可能存在不確定性,或者供應商創建漏洞路徑所需的時間。因此,影響量化可以計算半天,全天或3天。理想情況下,過程演練應生成一個活動列表,這些活動可能在整個時間段內發生,如下所示:

支持/幫助中心可能很快就會不堪重負,因為它在數據洩露事件期間投入了關鍵資源來處理其他任何事情。

網絡安全團隊將全部時間花在取證分析上。

技術運營團隊主持事件響應電話會議,他們上報的工程師和高管花時間規劃工作協調(每隔幾個小時聯繫一次基地)。

應用程序支持團隊對桌面應用程序執行緊急測試。

桌面管理員執行緊急修補程序安裝。

顧問或供應商補充勞動力的成本

恢復系統可用性所需的新設備或軟件的成本

這表示技術費用的最小描述,僅用於說明目的。所有這些活動都是數據洩露事件的後果,都可以量化為事件成本的一部分。也就是說,如果決定將此勞動力的成本計為數據洩露成本估算中的度量單位,則將其量化為數據洩露成本的一部分。假設如此,一個組織的成本估算如下圖所示:

12effe44-bbb4-405d-b812-724964a05103.png

初始數據洩露成本估算:技術活動

上圖首先計算成本,假設最小的組織具有24-7全天候服務級別的要求。由於假期和其他時間的原因,科技公司採用三班倒的方式全面覆蓋一份工作,通常需要確保有六到八名員工能夠履行各自的職能。其中,該數據假定有兩個人將在事件發生期間完全致力於網絡安全漏洞。我們假設員工崗位的每小時成本為50美元,高技能技術人員為75美元,工程師為125美元,管理人員為200美元。這個假設的分析也假設了小型企業活動中典型的管理和顧問的參與。組織規模也會影響相關費率和其他假設。

在事件發生期間,業務本身也可能受到影響。在公司維護工作中將技術設備與業務應用程序連接起來的配置管理數據庫的地方,可以使用這樣的清單列出業務應用程序的用戶,這反過來可能有助於識別潛在的業務流程影響。在非常大的公司中,有時會調查用戶以確定影響。然而,也有可能是業務維護業務應用程序吞吐量的度量和指標,並且這與被入侵的估計長度結合起來,可以用於在業務方面估計網絡安全被入侵的成本。注意,許多企業在整個業務流程中每天都有更改,因此對一天中的時間進行假設通常也很重要。

在我們的例子中,我們將假設股票銷售經紀人沒有桌面辦公軟件,因此不能執行他們的工作功能。其結果是生產力的損失,以及潛在的業務損失。以業務損失為例,讓我們假設中斷將導致無法處理客戶權益買賣指令,這可以用交易來量化,交易作為影響的單位可以用來估計由於數據洩露造成的佣金收入損失。

其中一項或兩項生產率損失都可以作為數據洩露成本估算的衡量單位,即花費在閒置勞動力上的美元和佣金損失的收入損失。就像在技術方面一樣,特定場景的業務影響將以一定的比例進行量化。使用事件的預期持續時間和客戶使用平台的歷史數據,可以計算受影響的客戶交易數量。未完成交易的業務影響以收入損失和因未執行已接受的訂單而產生的潛在責任來量化。如果衡量單位包括機會成本,這兩個數字都包括在數據洩露成本中。如果度量單位只是貨幣,那麼只計算貨幣。

上圖以24小時內的業務量為例進行說明。在清晨,每小時的交易量只有大約200個交易。平均峰值在上午8點到中午之間,然後再次下降,在一天結束時達到每小時的最低量。雖然持續時間的滑動比例選擇為6小時、24小時和60小時,但從上午8點到晚上8點的12小時時段的費用在圖中顯示,60小時的活動是兩個24小時時段加一個12小時時段的倍數。我們的分析假設每筆交易佣金為10美元,機會成本是每個交易量分配窗口中可能損失的交易的直接倍數。

在下圖中,交易數量也被認為是計算因未執行已接受的訂單而產生的潛在負債的基礎。假定在晚上8點至上午8點之間收到的訂單不會立即處理,而是按合同約定在第二天開市時處理。在下圖的事務度量中,結果是大約300個隔夜事務是潛在的負債,因為它們不會在早上處理,而只有在從事件中恢復之後才會處理。在這300筆交易中,市場可能對公司有利,而交易被延遲處理的客戶將從經濟上受益,但在其他情況下,可能已經發生了損失。

6611f886-652e-4be7-81d6-99dd2172ff25.png

數據洩露成本估算:業務交易成本

上圖假設所有的隔夜交易都將各自免除費用,這代表了一個機會成本。根據客戶的影響,企業也可以決定讓客戶成為整體。儘管有費用減免和善意的姿態,但這仍是可能的;客戶可以起訴違反協議。在商譽的情況下,損失可能被沖銷為“客戶商譽”,這是一個財務費用類別,不太可能出現在數據洩露損失計算單位的衡量。在訴訟案件中,任何產生的成本都將作為法律解決方案出現,而這當然應該包括在數據洩露成本中。

上圖假設對於25%的隔夜交易,公司平均每筆交易花費100美元的商譽費,對於在6小時事件中延遲的5%的交易,公司平均每筆交易花費1000美元的責任費。由於交易延遲的時間越長,客戶要求報銷的可能性就越大,因此每個持續時間類別的金額都會有所不同。假設24小時和60小時商譽和負債成本分別為100美元和1000美元估計數的兩倍和三倍。

隨著場景分析團隊列舉產生成本的活動和事件,很明顯,除了業務損失之外,還產生了機會成本,工作未完成的機會成本。例如:

1、管理任務歷史記錄將顯示管理員通常在網絡安全響應活動期間未執行的日常任務上花費多長時間。

2、應用程序支持方面的項目工作將被延遲,從而減少了由於應用程序支持團隊不可用而導致的上市時間。

3、用戶交付的桌面輸出將被延遲,例如管理、客戶和監管演示材料。

這些通常不作為數據洩露度量單位,但如果它們被包括在內,它們將進一步增加數據洩露成本的金額。數據洩露的總成本將在前文的兩個圖中所計算的金額中加上這些金額。如果假設錯過了一個重要的市場機會,或者可能因工作延誤而引發監管罰款,那麼對收入損失的量化估值當然也與管理層有關。在我們的示例中,我們假設這種產品交付挫折和罰款分別為6小時、24小時和60小時的事件花費5萬美元、10萬美元和20萬美元。這一最終假設將導致如下圖所示的網絡安全漏洞估計的全部成本。前文已說過大型組織用10的倍數表示。

b5ec9285-f90c-4739-91a3-e58f1ad966af.png

數據洩露總成本估算

向前邁進在本章中,我們提出了一些原則和方法,以有效和務實地捕獲網絡入侵成本的相關組件。這裡總結的結論可用於事後分析,或作為預測潛在數據洩露事件的輸入。

參考資源

1、Borg,Scott,“TheEconomicsofLoss”,inEnterpriseInformationSecurityPrivacy,Axelrod,BayukSchutzer,Eds.(Norwood,MA:ArtechHouse,2009)。

2、巴塞爾銀行監督委員會(2003年),《经营风险管理和监督的健全做法》 (BCBS96www.bis.org)。

3、巴塞爾銀行監管委員會(2013)有效風險數據匯總和風險報告原則(BCBS239www.bis.org)。

4、伊薩卡(2012).COBIT5,使能流程。信息系統審計與控制協會(www.isaca.org)。

5、波耐蒙研究所(2017)。數據洩露研究的成本,全球概述。 https://www.ibm.com/account/reg/us-en/signup?formid=urx-33316

6、VerizonEnterprise.(2017).“2017年數據洩露調查報告,第10版。

1.png

2022年2月24日之前的重大網絡事件時間表

在現代世界,發動任何類型的軍事行動之前都必將出現大規模的網絡攻擊活動,這反過來可以通過監測潛在衝突地區新出現的網絡攻擊來預測衝突發展情況。例如,在2013年末和2014年1月,研究人員觀察到Turla APT組織在烏克蘭的活動高於正常水平,並且BlackEnergy APT攻擊事件數量激增。同樣,在2022年2月初,研究人員注意到與Gamaredon CC服務器相關的活動量大幅飆升。這一活動達到了迄今為止從未見過的水平,這意味著為大規模的SIGINT(信號情報,通過攔截信號收集)收集工作正在進行。

2.png

如這些案例所示,在現代軍事衝突之前的幾天和幾週內,網絡戰中會出現與情報收集和破壞性攻擊有關的顯著跡象和峰值。當然,我們應該注意到,相反的情況也是可能的:例如,從2016年6月開始,但最值得注意的是,自2016年9月一直到2016年12月,Turla組織將其基於衛星的CC註冊量提高了2015年平均值的十倍。這表明Turla組織異常活躍,這表明該組織前所未有地調動了資源。與此同時,據我們所知,沒有發生隨後的軍事衝突。

如今的軍事行動是在實地收集支持情報之後進行的;這包括SIGINT和ELINT等。重大軍事行動(如2003年入侵伊拉克)還輔以旨在使敵人通信網絡癱瘓的強大網絡攻擊,在2022年2月,研究人員注意到與Gamaredon CC服務器相關的活動大幅增加,2013年底和2014年初,Turla和BlackEnergy的APT活動也出現了類似的激增。在軍事衝突發生前的幾天或幾週內,網絡戰會出現明顯的跡象和高峰。

在俄烏衝突衝突的第一天(2022年2月24日),烏克蘭實體遭受了大規模的無差別雨刷攻擊。這些攻擊的主要目標可能是造成混亂和混亂,而不是實現精確的戰術目標。相反,這一階段所使用的工具在本質上也是多種多樣的:

Ransomware (IsaacRansom);

冒牌勒索軟件(WhisperGate);

雨刷(hermetwiper, CaddyWiper, DoubleZero, IsaacWiper);

ICS/OT雨刷(AcidRain, industrroyer2)。

其中一些特別複雜。據我們所知,HermeticWiper仍然是野外發現的最先進的雨刷軟件。 industrroyer2是在一家烏克蘭能源供應商的網絡中發現的,如果攻擊者無法訪問與受害者使用的相同ICS設備,則不太可能開發它。也就是說,從軟件工程的角度來看,這些工具中的許多都非常粗糙,似乎是匆忙開發出來的。

除了AcidRain(見下文)之外,我們認為這些不同的破壞性攻擊都是隨機的和不協調的——而且我們認為,在戰爭的宏偉計劃中影響有限。

Viasat事件2月24日俄烏衝突爆發時,覆蓋烏克蘭地區的美國衛星運營商Viasat遭遇網絡攻擊,導致數千烏克蘭用戶、數万名歐洲其他地區用戶斷網。經調查,攻擊者利用錯誤配置的VPN設備入侵衛星網管理後台,向數万用戶側Modem下發破壞性指令,從而造成斷網。 KA-SAT衛星網絡曾經被“烏克蘭軍方所頻繁使用”。在被攻擊期間,中歐及東歐地區的KA-SAT衛星服務均發生中斷。這次通信服務中斷也影響到了德國,導致負責控制約5800颱風力渦輪機的調製解調器無法正常聯網。此外,來自法國、意大利、匈牙利、希臘和波蘭的客戶也受到不同程序影響。 5月10日,歐盟將這些惡意活動歸咎於俄羅斯聯邦。這是迄今為止與烏克蘭衝突有關的最複雜的攻擊之一。雖然破壞活動可能沒有嚴重破壞烏克蘭的防禦,但它在戰場之外產生了多重影響。刺激美國參議院要求在衛星網絡安全問題上採取行動,加速SpaceX Starlink的部署。

ViaSat的攻擊活動再次表明,網絡攻擊是現代武裝衝突的基本組成部分,可能直接支持軍事行動。在武裝衝突期間,針對共同通信基礎設施的網絡攻擊極有可能發生,因為交戰方可能認為這些攻擊具有雙重用途。由於互聯網的相互關聯性,針對此類基礎設施的網絡攻擊可能會對未捲入武裝衝突的各方產生副作用。網絡攻擊引發了人們對商業衛星系統網絡安全的擔憂,這些系統可能支持從自拍地理定位到軍事通信等各種應用。雖然軍事力量經常討論針對太空動能戰鬥的保護措施,而且更多的數據中心有望很快升空,但地面站管理系統和運營商似乎仍然高度暴露在常見的網絡威脅之下。

專業勒索軟件組織、黑客活動和DDoS攻擊一如既往,戰爭對信息格局有著非常具體的影響。在2022年尤其如此,因為人類已經掌握了有史以來最強大的信息傳播工具:社交網絡及其充分證明的放大效應。大多數真實世界中與戰爭有關的事件(小規模衝突、死亡人數、戰俘證詞)都在網上被放大。傳統新聞媒體也受到更廣泛的信息戰背景的影響。

DDoS攻擊和在較小程度上破壞隨機網站一直被安全社區視為低複雜性和低影響的攻擊。特別是DDoS攻擊,需要產生大量的網絡流量,攻擊者通常無法維持很長一段時間。一旦攻擊停止,目標網站就會恢復可用。除了電子商務網站暫時的收入損失,DDoS攻擊或破壞提供的唯一價值是受害者的羞辱。由於非專業記者可能不知道各種類型的安全事件之間的區別,他們隨後的報導造成了一種無能和安全不足的印象,可能會削弱用戶的信心。網絡攻擊的不對稱性質在支持大衛與歌利亞的形象方面發揮了關鍵作用,在網絡領域的象徵性勝利有助於說服地面部隊,在現實戰場上也可以取得類似的成就。

根據卡巴斯基DDoS防護公司的數據,自2022年初以來的11個月裡,該服務註冊的攻擊次數比2021年全年多了1.65次。雖然這種增長可能不是很顯著,但與2021年相比,這些資源受到攻擊的時間更長。在2021年,平均攻擊持續約28分鐘,在2022年- 18.5小時,幾乎是原來的40倍。最長的一次攻擊在2021年持續了2天,2022年持續了28天(或2486505秒)。

3.png

2021與2022年卡巴斯基DDoS防護檢測到的DDoS攻擊總持續時間(秒),按週計算

自戰爭開始以來,一些有明顯政治傾向的黑客組織已經出現,並開始開展一些活動。例如,臭名昭著的匿名組織組織了一場活動,將數十輛出租車同時叫到同一個地點,造成了莫斯科的交通堵塞。

卡巴斯基DDoS防護也反映了這一趨勢。大規模DDoS攻擊在一年中分佈不均,春季和初夏是最激烈的時期。

4.png

2021與2022年卡巴斯基DDoS防護檢測到的DDoS攻擊數,按週計算

攻擊者在2月至3月初達到高峰,這反映了黑客活動的增長,到了秋天,黑客活動已經停止。目前,我們看到了一個經常性的預期攻擊動態,儘管它們的質量發生了變化。 5月至6月,我們發現了極長時間的攻擊。然而,現在它們的長度已經穩定下來,而典型的攻擊過去只持續幾分鐘,現在則持續數小時。

2022年2月25日,臭名昭著的Conti勒索軟件組織宣布他們“全力支持俄羅斯政府”。聲明中有一句話:“如果有人決定對俄羅斯發動網絡攻擊或任何戰爭活動,我們將動用一切可能的資源,對敵人的關鍵基礎設施進行反擊。”該組織隨後很快發布了另一條帖子,澄清了他們在衝突中的立場:“作為對西方戰爭販子和美國對俄羅斯聯邦公民使用網絡戰的威脅的回應,Conti團隊正式宣布,如果西方戰爭販子試圖以俄羅斯或世界上任何俄語地區的關鍵基礎設施為目標,我們將動用我們的全部能力採取報復措施。我們不與任何政府結盟,我們譴責正在進行的戰爭。然而,由於西方主要以平民為目標發動戰爭,如果美國的網絡攻擊將危及和平公民的福祉和安全,我們將利用我們的資源進行反擊。”

兩天后,一名烏克蘭安全研究人員洩露了Conti組織成員之間的大量內部私人信息,涵蓋了從2021年1月開始的一年多的活動。這對該組織造成了重大打擊,他們看到自己的內部活動暴露在公眾面前,包括與數百萬美元贖金有關的比特幣錢包地址。與此同時,另一個名為“comomingproject”的網絡犯罪組織專門從事數據洩露,宣佈如果他們看到針對俄羅斯的攻擊,他們將支持俄羅斯政府:

5.png

其他組織,如Lockbit,更傾向於保持中立,聲稱他們是一個國際社會,包括俄羅斯人和烏克蘭人,而且“一切都是生意”:

6.png

2月26日,烏克蘭副總理兼數字轉型部長米哈伊洛马云惹不起马云費多羅夫(Mykhailo Fedorov)宣布創建一個Telegram頻道,以“繼續在網絡戰線上戰鬥”。最初的Telegram頻道名稱(itarmyourraine)有一個拼寫錯誤,因此創建了第二個。

7.png

烏克蘭的Telegram頻道

信道運營商不斷地給用戶分配任務,例如DDoS攻擊各種商業公司、銀行或政府網站:

8.png

烏克蘭IT部門發布的DDoS目標列表

據報導,在很短的時間內,由志願者組成的“烏克蘭IT軍”(通過Twitter和Telegram進行協調)對800多個網站進行了破壞或DDOS攻擊,包括莫斯科證券交易所等知名機構。

其他組織也觀察到了類似的活動,隨著衝突蔓延到鄰國,它們已經站隊。例如,白俄羅斯網絡游擊隊聲稱,他們將白俄羅斯鐵路改為手動控制,從而擾亂了鐵路的運營。目標是減緩俄羅斯軍隊在該國的行動。

9.png

白俄羅斯網絡游擊隊的帖子

一些表達了他們對烏克蘭衝突看法的勒索軟件或黑客組織的有限且迄今為止並不詳盡的列表包括:

10.png

在公開支持俄羅斯的組織中,最初作為對“烏克蘭IT軍”的回應而成立的Killnet可能是最活躍的。 4月下旬,他們攻擊了羅馬尼亞政府網站,以回應羅馬尼亞眾議院議長馬塞爾马云惹不起马云西奧拉庫(Marcel Ciolacu)在向烏克蘭當局承諾“最大限度的援助”後發表的聲明。 5月15日,Killnet在其telegram頻道上發布了一段視頻,向十個國家宣戰:美國、英國、德國、意大利、拉脫維亞、羅馬尼亞、立陶宛、愛沙尼亞、波蘭和烏克蘭。在這些活動之後,被稱為“匿名者”的國際黑客團體於5月23日宣布對Killnet發動網絡戰。

Killnet在2022年繼續其活動,此前他們在Telegram頻道上發布了一則聲明。 10月,該組織開始攻擊日本的某些組織,後來由於缺乏資金,他們停止了攻擊。後來,它攻擊了一個美國機場、政府網站和企業,但往往沒有取得重大成功。 11月23日,Killnet短暫關閉了歐盟的網站。 Killnet還多次針對拉脫維亞、立陶宛、挪威、意大利和愛沙尼亞的網站。雖然Killnet的方法並不復雜,但它們不斷成為頭條新聞,並引起人們對該組織活動和立場的關注。

俄烏衝突為各方新的網絡軟件活動創造了溫床,其中包括網絡犯罪分子和黑客,他們爭相支持自己最喜歡的一方;

我們可以預見,從現在起,黑客組織將捲入所有重大的地緣政治衝突;

網絡軟件活動正在蔓延到鄰國,並影響到大量機構,包括政府機構和私營公司;

烏克蘭IT軍(IT Army of Ukraine)等組織得到了政府的正式支持,他們的Telegram頻道擁有數十萬訂閱者;

大多數時候,這些組織實施的攻擊對沖突的影響非常有限。

黑客攻擊和隱私洩漏在試圖劫持媒體注意力的更為複雜的攻擊方面,自衝突開始以來,黑客和洩密活動一直在增加。這個過程很簡單,攻擊一個組織,並在網上發布其內部數據。從理論上講,這些數據洩露是可以操縱的。攻擊者有足夠的時間編輯任何已發布的文件,或者乾脆注入完全偽造的文件。需要注意的是,攻擊者完全沒有必要為了數據洩漏造成破壞而花費如此長的時間。這些數據的公開本身就證明發生了嚴重的安全事件,而合法的原始內容可能已經包含了犯罪信息。

在我們對2023年APT的預測中,我們預測黑客和洩密行動明年將會增加;

信息戰不僅針對各參與方,而是針對所有組織的。我們預計,絕大多數此類攻擊不會針對交戰雙方,而是針對那些被認為過於支持(或不夠支持)任何一方的組織;

無論是黑客攻擊還是DDoS攻擊,網絡攻擊都是國家之間發出攻擊信號的一種手段;

開源軟件武器化開源軟件有很多好處。首先,它通常是免費使用的,這意味著企業和個人可以節省軟件成本。然而,由於任何人都可以對代碼做出貢獻並進行改進,這也可能被濫用,進而打開安全陷阱門。另一方面,由於代碼可以公開檢查任何潛在的安全漏洞,這也意味著只要有足夠的審查,使用開源軟件的風險可以降低到合適的水平。

早在3月,流行的npm包“node ipc”的開發者RIAEvangelist發布了該軟件的修改版本,如果運行的系統具有俄羅斯或白俄羅斯的IP地址,則該軟件包含特殊功能。在這樣的系統上,代碼將用一個心形表情符號覆蓋所有文件,另外部署來自同一開發人員創建的另一個模塊的消息with - love - from - america .txt。 node-ipc包在全球擁有超過80萬用戶。與開源軟件通常的情況一樣,部署這些修改過的“node-ipc”版本的效果並不僅限於直接用戶,其他開源軟件包,例如“Vue.js”,自動包含最新的node-ipc版本,放大了效果。

旨在俄羅斯市場傳播的軟件包並不總是會導致文件被破壞,其中一些包含隱藏功能,例如在軟件網站的某個部分添加烏克蘭國旗或支持該國的政治聲明。在某些情況下,該軟件包的功能被刪除,並被政治通知所取代。值得注意的是,並不是所有的包都隱藏了這個功能,一些開發者在軟件包描述中宣布了這個功能。

11.png

其中一個項目鼓勵傳播一個文件,該文件一旦打開,就會開始通過JavaScript訪問註冊服務器的各個頁面,從而使網站過載。

GitHub上發現的其他存儲庫和軟件模塊包括專門為DDoS俄羅斯政府、銀行和媒體網站創建的存儲庫,專門用於收集俄羅斯基礎設施和活動數據的網絡掃描儀。

隨著衝突的持續,流行的開源軟件包可以被開發人員或黑客用作抗議或攻擊平台;

這種攻擊的影響可以進一步擴展到開源軟件本身,傳播到其他自動依賴木馬代碼的軟件包;

市場撕裂在過去的幾年中,尤其是2014年之後,這一過程開始擴展到IT安全領域,國家通過法律禁止彼此的產品、服務和公司。自2022年2月俄烏衝突爆發以來,我們看到許多西方公司退出俄羅斯市場,讓他們的用戶在獲得安全更新或支持方面陷入困境。與此同時,一些西方國家推動法律禁止使用俄羅斯軟件和服務,因為這些軟件和服務有被用於發動攻擊的潛在風險。顯然,不能完全排除政治壓力將一些小市場主體的產品、技術和服務武器化的可能性。然而,當涉及到全球市場領導者和受人尊敬的供應商時,我們認為這是極不可能的。

另一方面,尋找替代解決方案可能是極其複雜的。我們經常發現,來自本地供應商的產品的安全開發文化通常明顯不如全球領先企業,它們很可能存在顯而易見安全錯誤和零日漏洞,使它們很容易成為網絡犯罪分子和黑客活動分子的獵物。

網絡攻擊對戰爭結果的影響地緣政治正在發揮重要作用,分裂的進程可能會擴大;

當供應商終止對產品的支持或退出市場時,安全更新可能是首要問題;

用本地產品取代成熟的全球領導者,可能會為利用零日漏洞的網絡犯罪分子打開大門;

網絡戰爭會爆發嗎?自俄烏衝突開始以來,網絡安全界一直在爭論烏克蘭發生的事情是否屬於“網絡戰爭”。一個不爭的事實是,衝突爆發時確實發生了重大網絡活動。

另一方面,許多觀察家認為,在發生衝突的情況下,先發製人的網絡攻擊會讓自己佔據主動。但事實上,除了Viasat事件(其實際影響仍難以評估)之外,這一事件根本沒有發生。這場衝突反而揭示了網絡力量和實際戰場之間缺乏協調,並在許多方面將網絡攻擊降格為從屬角色。在衝突的最初幾週觀察到勒索軟件攻擊,充其量只能算是乾擾。後來,當今年11月衝突升級,烏克蘭基礎設施(尤其是能源網絡)明確成為目標後,很明顯,俄羅斯軍方選擇的工具是導彈,而不是網絡攻擊。

如果你認同網絡戰爭的定義,即通過網絡手段支持的任何動態衝突,無論其戰術或戰略價值如何,那麼2022年2月確實發生了一場網絡戰爭。

網絡攻擊對戰爭結果的影響遠沒有想像的那麼大,事實證明,對計算機的物理破壞似乎更容易、更便宜、更可靠。我們認為,網絡攻擊在戰爭背景下的效果以前被我們大大高估了。

總結俄烏衝突將對整個網絡安全行業和環境產生持久影響。無論“網絡戰爭”一詞是否適用,不可否認的是,當一個大國捲入戰爭時,衝突將永遠改變每個人對戰時網絡活動的期望。

在戰爭爆發之前,幾個正在進行的多方進程(聯合國OEWG和GGE)試圖就網絡空間中可接受和負責任的行為達成共識。鑑於全球目前所經歷的極端地緣政治緊張局勢,這些本已艱難的討論能否在不久的將來取得成果令人懷疑。

採用CNAS需要對我們保護應用程序和基礎架構的方式進行重大改變。轉變是一個旅程,每個組織都不相同,甚至同一組織的不同部分也不同。

雖然選擇正確的道路是由你的決定,但為了讓它正確,模式和最佳實踐已經開始出現。在本文中,我提出了幾個可以考慮打破現狀的領域,以及如何打破現狀。

重新思考工具除了組織架構的改變,CNAS和“開發優先”還需要重新評估你的工具包。鑑於這種新視角,你應該重新考慮在技術解決方案中尋找的最重要特徵,以及你希望如何捆綁工具。

有很多方法可以重新評估工具,但我建議關註三個主要領域:開發工具採用、平台範圍和治理方法。

開發人員工具口徑如果我們的目標是讓開發人員在日常工作中能夠構建安全性,我們需要確保為他們提供針對該目標進行優化的工具。如果你購買專為審計人員設計的解決方案並要求開發人員使用它們,那麼你不太可能取得成功。

不出所料,開發人員習慣於使用開發人員慣用的工具。這些工具代表了整個行業,圍繞著什麼是優秀的開發者工具這一主題,已經在行業內發展了自己的最佳實踐。為了幫助你選擇開發人員將採用的安全解決方案,你應該根據開發者工具最佳實踐評估這些工具,並了解它們的表現如何。

以下是優秀的開發者工具的一些常見特徵:

成功的自助服務採用實際上,所有成功的開發工具都具有出色的自助服務用法,包括輕鬆的上手培訓、直觀的工作流程和出色的文檔。這是開發人員喜歡使用工具的方式,它迫使供應商確保他們的工具與開發人員相關,而無需銷售人員推動它。除非你想成為向開發人員推廣工具的銷售人員,否則請尋找具有開發人員自助服務採用的良好記錄的工具。

無縫集成到工作流程中在大多數情況下,開發工具經常與開發人員打交道,而不是要求他們再打開另一個工具。它們優雅地集成到其IDE、Git和研發管道中,並在正確的時間點提供價值。集成不僅僅是技術鉤子;他們需要適應工作流程和最佳實踐,否則將被拒絕採用。

豐富的API和自動化友好雖然需要固執己見的集成才能開始,但開發工具也必須是瑞士軍刀。豐富的API和自動化友好的客戶端(CLI/軟件開發工具包[SDK])是強制性的,既可以將該工具調整到每個管道,又允許社區在其上進行構建。如果你不能在工具上構建,它就不是一個偉大的開發工具。

開源和社區採用開發人員希望其他開發人員來驗證工具的可信度,而開源採用是最好的指標。看到開源項目集成了安全工具或基於此構建的開源項目,這些都是很好的開發人員社區驗證。在檢查安全工具時,檢查它在開源中的採用情況並得出自己的結論。

這些只是眾多開發工具最佳實踐中的一小部分。如果你想了解更多關於開發優先安全性的特定安全建議,請繼續往下看。此外,在評估任何工具時,請確保讓實際的應用程序開發人員參與進來,以便從現實生活中了解它與周圍環境的契合程度(如下圖所示)。

ce0ff4b0-0eee-4791-b04a-0cd56b885b79.png

開發人員友好的安全工具示例

平台範圍當前主流的AST平台主要關注自定義代碼,也許還有應用使用的開源庫。工具套件主要由SAST、DAST和IAST組成,最近又添加了SCA。當你擁抱更廣泛的雲原生應用程序範圍時,請重新考慮平台的構成。

首先,讓我們考慮一下哪些工具從成為單一平台的一部分中受益。它們可以分為下面幾個部分:

共享用戶:如果不同的工具是為不同的主要用戶設計的,那麼它們幾乎不需要成為單個平台的一部分,因為它們無論如何都會單獨使用。

共享工作流:如果以類似的方式使用多個工具並集成到用戶工作流的類似點中,則可以通過組合它們來節省集成時間以及用戶的時間和精力,而無需使用多個單獨的工具。

共享優先級:如果來自不同工具的行動項應彼此優先排序,則共享積壓工作可以提高效率和結果。

價值倍增:最後,工具共享平台的最強驅動力是當工具一起使用可以增強每個工具的價值。這個標準自然解釋了為什麼像SAST和SCA這樣的技術非常適合單一平台。兩者都為相同的開發人員用戶提供服務,運行掃描並在相同的位置吸引用戶,並共享同一開發人員需要優先考慮的安全漏洞的積壓。在高級SCA解決方案中,SAST技術可以指示你的自定義代碼是否調用庫中易受攻擊的代碼,從而提供更高的準確性,從而增加價值。

當你考慮將容器和IaC安全性添加到SAST和SCA的同一平台時,相同的邏輯也適用:共享用戶:容器和IaC現在由開發人員保護,就像SAST和SCA一樣,他們寧願沒有多個不同的產品需要花時間學習和參與。

共享工作流:保護容器和IaC需要跨生命週期的集成,例如IDE、Git和構建集成,就像SAST和SCA一樣。

共享優先級:同一個開發人員需要花費周期來修復容器或IaC漏洞,或者代碼或庫中的漏洞——所有這些都是保護應用的積壓工作。

價值倍增:保護這些組件有多種方式。掃描容器需要探索內部的應用程序,了解基礎設施配置有助於確定代碼和庫的漏洞優先級,了解跨組件的流程有助於緩解問題;這正是你在對漏洞進行分類時所做的。

即使CNAS範圍擴大,這種邏輯仍然有效,我鼓勵你將CNAS工具視為一個平台。一個簡單的準則是,Git存儲庫中的任何內容都可能與其周圍的文件相關,並遵循相同的開發工作流。因此,CNAS平台應有助於保護存儲庫中的所有內容(整個雲原生應用)。

DAST和IAST在這樣一個平台上是有點尷尬的參與者。儘管它們處理保護應用程序,但它們通常需要不同的工作流程。由於運行它們所花費的時間,很難將它們放入構建管道或IDE掃描中。在我看來,這是一個技術問題,而不是一個合乎邏輯的問題,一旦IAST和DAST解決方案發展到對管道更加友好,它有望得到解決。

治理和賦權方法採用開發優先的安全方法需要不同類型的協作。我們需要的工具不是專注於廣播和執行自上而下的任務,而是幫助我們協作構建安全應用程序的工具。

這聽起來可能很明顯,但在實踐中,這與許多安全工具的工作方式有很大的不同。讓我們深入研究一些具體的例子,以了解這意味著什麼。

首先,開發人員需要有能力平衡業務需求與安全風險。這意味著,例如,允許他們決定不修復發現的漏洞並繼續將其部署到生產環境。對某些人來說,這是一個可怕的命題,但這是實現獨立團隊的唯一方法。請注意,忽略漏洞仍應要求提供(且可審核)原因,並且某些約束應為硬槓槓(通常出於合規性原因),但作為默認立場,決策應留給開發人員。

其次,開發人員需要能夠管理他們的安全風險,這需要看到他們項目中的所有漏洞。這不僅需要包括漏洞列表,還需要包括確定優先級所需的所有信息,例如可利用性和資產映射。對此類信息保持透明可能會帶來一些風險,但這是擴展安全性的唯一方法;要賦予開發人員權力,你必須信任他們提供這些敏感數據。

第三,安全團隊應該投資於跟踪和推動安全控制的採用,甚至超過他們的產出。開發團隊應該管理其漏洞積壓工作,但安全團隊需要幫助他們成功做到這一點。開發優先安全治理意味著跟踪採用了哪些控件及其輸出的處理情況,並與開發團隊合作改進這些統計信息,而不是突出顯示他們應該修復的漏洞。

這些只是評估治理工具和技術時要考慮的幾個示例。關鍵是要擁抱平台心態;它的目標是幫助開發團隊成功構建安全軟件,而不是跟踪安全漏洞本身。

重新思考優先事項最後但並非最不重要的一點是,CNAS需要重新考慮應用程序安全優先級。如果開發人員需要保護整個雲原生應用程序,你希望他們最關注哪些方面?

從歷史上看,IT安全控制主導了更大的預算,並且比應用程序安全控制獲得了更多CISO的關注。這種不平衡可能有歷史原因,但歸根結底,它代表了CISO關於如何最好地使用他們的資金來降低組織風險的觀點。

換句話說,CISO認為,由於未修補的服務器或配置錯誤的基礎架構而導致的違規風險大於代碼中的自定義漏洞的風險。這種看法有相當多的數據來支持它,顯示了歷史違規行為及其原因。此外,它很容易理解;對於攻擊者來說,大規模運行已知的漏洞並尋找一扇敞開的門要比對應用程序進行逆向工程並找到自定義缺陷以使其通過要容易得多。

云不會減少這個等式;事實上,雲加強了這個等式。採用雲意味著使用更多的基礎設施和更多的服務器,它們往往更容易公開訪問,並且它們由不太熟悉管理它們的團隊(開發人員)定義,並配備了不太成熟的工具。

然而,雖然以前的平衡是在IT安全預算和應用程序安全預算之間,但現在一切都在應用程序安全世界中。在構建雲原生應用程序時,相同的開發人員需要保護其自定義代碼,管理其開源使用中的漏洞,並使服務器和基礎架構具有彈性。同一個應用程序安全團隊需要幫助他們做到這一點,並在他們之間分配相同的預算。

因此,我們回到開場白:你希望如何分配寶貴的開發人員的時間和有限的CNAS預算?

丟掉開發人員自己的設備和應用程序安全預算並讓開發人員的注意力集中在保護自定義代碼上。應用程序安全成熟度模型、行業最佳實踐以及團隊中個人的個人體驗都錨定在雲前的世界中,其中自定義代碼是開發人員必須保護的大部分內容。購買SAST和DAST等工具通常是應用程序安全新領導者名單上的第一件事,很少受到挑戰。

但是,考慮到CNAS的範圍,這仍然是你時間和金錢的最佳利用嗎?由於已知漏洞或配置錯誤而導致的違規風險仍然高於自定義代碼缺陷的風險,即使開發人員是配置它的人。如果你同意,難道不應該告訴你的開發人員和應用程序安全團隊首先要專注於保護這些層,然後才能處理他們的自定義代碼嗎?

這不是一個容易回答的問題。我不會假設知道你的優先事項應該是什麼,因為這些優先事項會因組織而異。但是,鑑於CNAS的範圍更廣,我強烈建議你在內部進行此對話並重新考慮你的優先事項。

結論改變你處理應用程序安全性的方式不僅僅是一種思考練習。它具有非常真實的下游影響,包括人們的職業生涯,預算分配以及對保持組織安全的最佳方式的重新評估。它需要擺脫一些關於你過去如何做事的肌肉記憶,而不是在選擇解決方案時回到第一原則,這需要寶貴的時間和精力。

好消息是,你不必一次完成所有操作。我在本文中概述的變化相互關聯,但可以按照自己的節奏應用。我建議你選擇與你最相關的那些內容,或者選擇你認為更重要的其他變化,並讓這些變化繼續下去。你將逐步調整安全功能以適應云原生現實。

蘋果系統運行著一些現有的最大和最賺錢的軟件應用程序生態系統。理論上,要進入這些生態系統,傳統上需要使用macOS,並加入蘋果開發者計劃(Apple Developer Program)。

如果你想為Apple 操作系統開發應用程序,你可能會使用Apple 的操作系統和Apple 的官方工具進行開發和分發。但對於開源開發人員通常希望以最小的努力分發跨平台應用程序。在整個編程語言生態系統中,你運行的操作系統被抽象為許多應用程序的實現細節。通過創建macOS、iOS 等開發需要直接訪問macOS 和通常高於市場價格的Apple 硬件的要求,蘋果軟件生態系統強加的分發要求是有效的排他性,並阻止利益相關方對進入其生態系統。

在蘋果平台上發佈軟件的一個問題是代碼簽署和公證,即你需要:

1.在應用程序中嵌入加密簽名,有效地證明來自Apple Developer Program 關聯帳戶的真實性。 (這是簽名。)

2.將你的應用程序上傳到Apple,以便他們對其進行檢查,驗證它符合要求,可能還會存儲一個副本。然後,蘋果會發布自己的加密簽名,即公證書,然後需要將其嵌入到正在分發的應用程序上,這樣蘋果的操作系統才能信任它。 (這是公證。)

從歷史上看,這些步驟需要Apple 專有軟件專門從macOS 運行。這意味著,即使你在Rust、Go 等軟件生態系統或Web 平台中,你可以在不直接訪問macOS 的情況下交叉編譯應用程序(測試顯然是另一回事),如果你願意,你仍然需要macOS簽署和公證你的申請。由於默認的安全設置,在macOS上需要有效的簽名和公證。在iOS 等移動平台上,除非你運行的是越獄設備,否則不可能發布未經簽名和公證的應用程序。

如果我不需要macOS來構建我的應用程序,為什麼我要被迫把蘋果設備作為我的軟件發布過程的一部分?為什麼在發布的時候,我必須簽署和公證我的申請,它不能更簡化嗎?

如果能重新實現Apple 代碼簽名,以便開發人員有更多的靈活性和機會將應用程序分發到Apple 的生態系統。其最終目標是擴大Apple 生態系統對更多開發者的訪問。

首先,得益於rcodesign 0.14.0的發布。這是我第一次發布rcodesign 的預構建二進製文件(Linux、Windows 和macOS)。

macOS rcodesign 可執行文件是自簽名的,它由GitHub Actions Linux 運行程序使用YubiKey 獨有的代碼簽名證書進行簽名。

2021年,apple-codesign 項目/Rust crate 發生了很大變化!只需查看更改日誌!

這個項目從tugger-apple-codesign改名而來。

如果你是通過cargo install 安裝的,你需要cargo install --force apple-codesign 來強制Cargo 用另一個crate 中的一個來覆蓋rcodesign 可執行文件。

rcodesign CLI可執行文件仍然存在,而且比以往任何時候都更強大。你仍然可以在Linux、Windows、macOS和任何其他平台上對Apple應用程序進行簽名,你可以在這些平台上編譯Rust程序。

Sphinx 文檔請點擊這裡,這與PyOxidizer 的文檔一起發佈在readthedocs.io 上(因為我使用的是monorepo)。那裡有一些通用文檔,例如有關如何通過將你自己的替代代碼簽名PKI 部署到並行Apple 來選擇性地繞過Gatekeeper 的指南。

支持簽名包、DMG 和.pkg 安裝程序當我去年宣布這個項目時,只有Mach-O 二進製文件和非常簡單的.app 包是可簽名的。即便如此,也有很多微妙的問題。

Rcodesign sign現在可以對更複雜的包進行簽名,包括許多嵌套的包。有報導稱iOS應用包簽名正確。

該工具還支持簽名.dmg磁盤映像文件和.pkg扁平封裝包安裝程序。

已知的簽名限制現在記錄在Sphinx 文檔中。

我相信rcodesign 現在支持對用於Apple 軟件分發的所有主要文件格式進行簽名。

支持Linux、Windows 和macOS 上的公證

蘋果發布了一個名為Transporter的Java工具,可以讓你上傳文物到蘋果進行公證。它們使這個工具可用於Linux、Windows,當然還有macOS。

雖然這個工具不是開源的,但使用這個工具可以讓你在Linux 和Windows 上進行公證,同時仍然使用Apple 的官方工具與他們的服務器通信。

rcodesign 現在支持調用Transporter 並將工件上傳到Apple 進行公證。我們現在支持公證包、dmg 磁盤映像和.pkg 扁平封裝安裝程序包。我已經成功地從Linux 公證了所有這些應用程序類型。

由於支持對所有應用程序類型進行簽名和公證,現在可以在沒有macOS 參與發布過程的情況下發布Apple 軟件。

YubiKey 集成我嘗試盡可能多地使用我的YubiKey,因為存儲在YubiKey 上的密鑰或私鑰可能比位於某個文件系統上的密鑰或私鑰更安全。如果你破解了我的設備,你很可能會獲得我的私鑰。但是你需要物理訪問我的YubiKey 並強迫或強迫我解鎖它,以獲得訪問其私鑰的權限。

rcodesign 現在支持使用YubiKeys 進行簽名操作。

這確實需要默認的智能卡Cargo 功能。因此,如果手動構建,你將需要例如cargo install --features smartcard apple-codesign.

YubiKey 集成來自yubikey 。這個crate 將直接與macOS 和Windows 中內置的智能卡API 對話。所以如果你有一個啟用了YubiKey 支持的rcodesign 構建,YubiKeys 應該可以工作。通過插入YubiKey 並運行rcodesign smartcard-scan 進行嘗試。

YubiKey 集成文檔可以點此查看。

我甚至實現了一些命令來輕鬆管理YubiKey 上的代碼簽名證書。例如,你可以直接在設備上運行rcodesign smartcard-generate-key --smartcard-slot 9c 以生成新的私鑰,然後rcodesign generate-certificate-signing-request --smartcard-slot 9c --csr-pem-path csr.pem將該證書導出到證書籤名請求(CSR),你可以在developer.apple.com 上交換Applie 頒發的簽名證書。這意味著你可以輕鬆創建其私鑰直接在硬件設備上生成且永遠無法導出的代碼簽名證書。以這種方式生成密鑰比將密鑰存儲在軟件庫(比如蘋果的Keychains)中更安全。

遠程代碼簽名我最感興趣的功能是我稱之為遠程代碼簽名的功能。

我在GitHub託管的Linux GitHub Actions運行程序上簽署了一個macOS通用Mach-O可執行文件,使用的YubiKey物理連接到我桌子旁邊的Windows 11設備上。未在計算機之間複製簽名的應用程序。

我有一個調用rcodesign sign --remote-signer 的GitHub Actions 工作流程。我手動觸發了該工作流程,並開始使用瀏覽器觀察近乎實時的作業輸出。 rcodesign sign --remote-signer 打印出一些指令(包括一堵base64 編碼數據的牆)以指示下一步該做什麼。重要的是,它要求其他人運行rcodesign remote-sign 以繼續簽名過程。

該日誌向我們展示了使用YubiKey 進行連接和身份驗證,以及一些關於與遠程服務器對話的狀態更新。

遠程簽名使我能夠從GitHub 運營的GitHub Actions 運行程序簽署macOS 應用程序,同時使用安全存儲在我的YubiKey 上的代碼簽名證書,該證書插入到距GitHub Actions 運行程序數百公里的Windows 設備上。

這裡發生的是2 個rcodesign 進程通過中央中繼服務器橋接的websocket 相互通信。我免費操作一個默認服務器。服務器是開源的,如果你想運行你自己的服務器,你可以使用terrform模塊,希望只需要花幾分鐘時間。當啟動設備希望創建簽名時,它向請求加密簽名的簽名者發送一條消息。然後將簽名發送回發起者,發起者將其合併。

我設計這個特性時考慮到了CI系統的自動發布(比如GitHub Actions)。我想要一種方法,可以簡化應用程序的代碼簽名和發布過程,而不必給CI中的低信任設備無限訪問我的私人簽名密鑰的權限。這可能在許多其他場景中都是有用的。你是否曾經因為沒有蘋果發行的代碼簽名證書而通過電子郵件或下拉框將應用程序發送給別人簽名?現在你有了一個不需要復製文件的替代解決方案。只要你可以看到啟動設備的日誌輸出,或者將輸出傳遞給你(例如通過聊天應用程序或電子郵件),你就可以在另一台設備上遠程簽署文件!

關於遠程簽名安全性Websockets 通過由第三方操作的中央服務器?授予遠程設備訪問權限以對任意內容執行代碼簽名?你的恐懼和懷疑是100% 有道理的:我也會這麼想!

促進遠程代碼簽名的服務會成為一個非常有利可圖的攻擊目標,如果被濫用,它可能被用來強制使用有效的代碼簽名證書的各方簽署不想要的代碼,如惡意軟件。實現這樣的功能有很多很多很多錯誤的方法。

遠程代碼簽名設計和安全注意事項包含了我的一些高級設計目標和安全評估。遠程代碼簽名協議詳細介紹了通信協議,包括所涉及的加密(實際的加密,而不是流行的加密)。關鍵在於協議和服務器的設計使惡意服務器或中間人無法偽造簽名請求。簽名會話在幾分鐘後過期,第三方或服務器無法注入會導致不需要簽名的惡意消息。通過初始握手獲得會話臨時共享加密密鑰,並從那裡使用對稱加密密鑰,因此對等方之間的所有有意義的消息都是端到端加密的。惡意服務器可以做的最糟糕的事情就是進行拒絕服務。

我相信我的遠程簽名實現比許多常見做法更安全,因為今天的常見做法需要復制私鑰並讓低信任度設備(如CI 工作人員)訪問私鑰或者文件在沒有加密監管鏈的情況下被複製以證明不會被篡改。是的,遠程簽名為遠程訪問引入了使用簽名密鑰的向量。但是按照我的意圖進行實踐,遠程簽名可以消除複製私鑰或授予對它們的無限訪問權限的需要。從威脅建模的角度來看,我認為密鑰訪問中的網絡限制使得遠程簽名比現在許多人使用的私鑰管理實踐更安全。

話雖如此,這裡的星號是我實現了我自己的密碼系統來實現端到端消息安全。如果在設計或實現中存在漏洞,密碼系統可能會崩潰,從而帶來對消息偽造的防禦。屆時,惡意服務器或特權網絡攻擊者可能會強迫某人簽署不需要的軟件。但這很可能是損害的程度:對簽名密鑰的脫機攻擊是不可能的,因為簽名需要存在,而且私鑰永遠不會通過網絡傳輸。即使沒有端到端加密,該系統也比將你的私有密鑰作為一個容易被竊取的CI秘密(或類似的)留在周圍更安全。

Apple 鑰匙串支持從0.14 版本開始,我們現在可以提前支持使用存儲在Apple 鑰匙串中的代碼簽名證書進行簽名!如果你在Keychain Access 或Xcode 中創建了Apple 代碼簽名證書,那麼這可能就是你的代碼簽名證書所在的位置。

我拖延了很長一段時間,因為我沒有意識到這有什麼好處:如果你使用macOS,只需使用蘋果的官方工具。但是隨著rcodesign獲得了對遠程代碼簽名的支持,以及其他一些功能,這些功能可以讓它成為所有平台上蘋果工具的有力替代品,我認為我們應該提供這個功能,這樣我們就不會再阻止人們從keychain導出私鑰了。

Apple 的代碼簽名很複雜。 蘋果的工具和rcodesign之間很容易出現細微差別。

rcodesign 現在有print-signature-info 和diff-signatures 命令來轉儲和比較與代碼簽名相關的YAML 元數據,以便更容易地比較代碼簽名實現甚至多個簽名操作之間的行為。

在互聯網中,一個自治系統(AS)是一個有權自主地決定在本系統中應採用何種路由協議的小型單位。這個網絡單位可以是一個簡單的網絡也可以是一個由一個或多個普通的網絡管理員來控制的網絡群體,它是一個單獨的可管理的網絡單元(例如一所大學,一個企業或者一個公司個體)。一個自治系統有時也被稱為是一個路由選擇域(routingdomain)。一個自治系統將會分配一個全局的唯一的號碼,有時我們把這個號碼叫做自治系統號(ASN)。通過自治系統號(ASN)預判攻擊發生的可能性是出於以下7個方面的考慮:

1.利用Akamai(一家網路安全公司)對互聯網趨勢和活動的廣泛了解,Akamai研究人員一直在分析自治系統號(ASN),以評估大量互聯網的風險。

2.ASN包含受管理的ISP、雲計算公司、跨國集團以及小型組織的IP地址池。

3.這些ASN的各種特徵(包括其註冊位置、提供商類型以及管理ASN中IP使用的策略)可能會影響攻擊者被發現使用這些ASN中的IP的可能性。

4.了解ASN的惡意性可以讓安全從業人員對任何給定IP的風險做出更明智的預測,即使它不是已知的威脅。

5.惡意ASN更有可能包含用於託管網絡釣魚網站、惡意文件、殭屍網絡和掃描程序的IP。 “可能的惡意”ASN表示遇到惡意IP的概率為七分之一或更高。

6.對流量的分析表明,“可能的惡意”ASN佔所有在線IPv4地址的不到2%,但它們接收的互聯網流量超過5%。

7.此外,“潛在惡意”類別中的ASN在互聯網上所有IPv4地址中的佔比不到5%,但它們接收的互聯網流量卻超過18%,這表明惡意和合法流量可以由同一個ASN提供服務。

IP智能化有很多用途:例如,防火牆或DNS查詢後阻止。基於IP預先確定“通過/不通過”的能力是一項重要的防禦措施。

Akamai安全研究人員利用Akamai對在線流量的廣泛可見性,創建了在線ASN的全面映射,以評估惡意地址出現在ASN中的可能性。在這篇文章中,我們將詳細介紹ASN,以及ASN對風險評估可能產生的影響。我們還將檢查惡意ASN等。

風險評估現狀由於動態IP、CDN和託管服務的存在,基於IP的阻止可能是非常危險。個人和組織可能會受到不同程度的影響。例如,錯誤地屏蔽一個社交媒體網站的IP可能只會讓一名員工感到無所適從,影響正常工作。

在更大的範圍內,阻止來自CDN或託管服務的單個IP可能會導致阻止數千個網站。我們以白名單的形式提供保護以避免這些極端情況,但必須要注意,某些用例可能會優先考慮更廣泛的威脅保護而不是誤報。綜上所述,此種策略的弊端太大。

不過Akamai可以通過大量數據輸入來解決上述弊端,例如:

Akamai Intelligent Edge Platform上通過IP發起的攻擊;

每天來自數十億次DNS查詢的檢測;

IP流行度源自每天數十億的DNS查詢;

其他形式的內部和第三方情報;

有多個來源,包含數百萬IP的正面(合法IP)和負面(惡意IP)證據。我們需要結合這些資源為每個IP創造一個分數。為此,我們採用貝葉斯方法,其複雜性在於確定每個源的權重。這樣做的目的是建立一個更全面的風險評估,考慮到不同的來源。分數越高,負面證據就越多。分數越低,惡意證據就越少,或者正面和負面證據混合在一起。根據應用程序的不同,可以選擇一個閾值來實現誤報和真實所需的平衡。這比典型的基於IP的風險評估更進了一步,在這種評估中,了解ASN的力量及其可能產生的影響勢在必行。

什麼是自治系統?簡而言之,自治系統就是互聯網的構建方式。每個自治系統都映射到一個數字,因此我們通常說ASN(自治系統號)。每個ASN都有一個IP池,每個ASN負責使用邊界網關協議(BGP)在其網絡內路由流量並通過Internet與其他ASN通信。

在這篇文章中,我們只聚焦IPv4,其中包括大約7萬個自主系統。

ASN可以以不同的方式進行分類,以了解它們在互聯網上的位置。例如,“從多個優勢點描述互聯網層次結構https://ieeexplore.ieee.org/abstract/document/1019307”查看BGP表,從商業角度對ASN的角色進行分類。 “使用深度學習揭示自治系統之間的關係類型https://ieeexplore.ieee.org/document/9110358”使用深度學習來理解ASN之間的關係類型。要了解ASN背後的組織,我們可以查看“揭示自治系統分類法:機器學習方法https://arxiv.org/abs/cs/0604015”,它試圖將ASN自動分類為大型ISP、小型ISP、大學、互聯網交換點和網絡信息中心。最近,在“BGP2Vec:揭示自治系統的潛在特徵https://ieeexplore.ieee.org/abstract/document/9761992”中使用了word2Vec樣式的模型,將ASN分類到應用互聯網數據分析中心的交通/訪問、內容、教育/研究和企業類別中。

ASN大小讓我們看看前10個最大的ASN的IPv4地址池大小(表1)。最大的ASN歸美國國防部網絡信息中心所有。名單上的其他公司包括大型ISP、雲計算公司和跨國企業集團。我們排除了ASN 0,因為它是用來識別不可路由網絡的。

1.png

按IPv4地址池大小排列的前10個最大的ASN

下圖進一步顯示了這10個ASN的影響。前10個ASN約佔分配的IPv4地址空間的25%。相比之下,只有16%的IPv4地址空間分配給前1000個之外的69000個ASN,因此互聯網流量中存在類似於域或IP的ASN的長尾。這是分配給相對較小百分比的大量互聯網。這是我們在確定有效的ASN風險評估時必須考慮多個數據輸入的部分原因。正如你將在本文後面了解到的那樣,並非所有ASN都是平等的。

2.png

ASNIPv4地址池大小占全部IPv4地址池的百分比

地理位置位置在真正理解ASN方面也起著重要作用。為了詳細說明這一點,我們構建了一個散點圖,其中包含與每個國家/地區關聯的ASN數量與這些ASN的IP池大小的關係。

3.png

與每個ASN關聯的國家與這些ASN的IP池大小

在前10大ASN中,美國有6個,在IP總數和ASN總數方面均領先。緊隨美國之後的是:巴西、英國、丹麥、印度和俄羅斯。繼續向左移動一點,我們可以看到中國、日本和韓國的ASN數量要少得多,但其數量比巴西和俄羅斯等國要多。考慮到我們所知道的前1000名ASN和其他69000名之間的差距,當遇到某個國家的IP並為其創建風險評估時,可能會面臨一些獨特的挑戰。

例如,對於ASN數量較少但IP較多的國家/地區,惡意IP更有可能與合法IP在同一個ASN中,這意味著在僅基於ASN的阻止時可能更難以避免誤報。使用AkamaiDNS數據,我們看到與中國ASN相關的所有已解析IP均來自383個ASN,而俄羅斯則為2311個。因此,在中國和俄羅斯阻止ASN的影響,就不能採用同一種方法了。例如,在中國屏蔽整個ASN會佔用整個互聯網部分,而在俄羅斯屏蔽整個ASN會佔用更少的資源。這就是為什麼我們不能完全避免僅僅基於IP的風險評估,以及為什麼我們在創建接下來討論的ASN風險評估時必須考慮到了這一點。

ASN風險評估4.png

我們對ASN信譽的定義很簡單:一個ASN的信譽衡量的是該ASN中任何給定的活躍IP被惡意攻擊的概率。

為了計算這個概率,我們擴展了貝葉斯方法,如前所述,將每個IP的分數和權重向上輸入到它們所屬的ASN。 Akamai數據用於估計ASN中活躍IP的數量。當我們對每個ASN的多個IP進行聚合時,我們希望我們的ASN信譽計算能夠受益於大數定律,從而計算出最準確的風險評估。例如,如果一個ASN有兩個IP,有30%的機率是惡意的,那麼兩個IP都是惡意的機率都很高,因此可以評估ASN本身是沒有惡意的。這與擁有1000個IP的ASN形成了鮮明的對比,所有的惡意可能性為30%。在這種情況下,可以推斷出該ASN中30%的IP實際上是惡意的,這使得它們比第一個示例中明顯更危險。

跟踪我們不知道的內容以及我們數據中存在的偏差非常重要。將會有我們擁有大量數據的ASN,以及數據很少的ASN。為了盡可能地解決這個問題,我們需要記錄證據數量,它反映了我們擁有的數據量,也可用於計算可能的ASN風險評估值的分佈。從本質上講,我們認為是良性的IP與我們知道是良性的IP(甚至是我們知道是惡意的IP)之間存在顯著差異。當我們擁有較少的數據時,我們可能會假設風險評估較低,但在這種情況下,我們也會記錄較低的證據數量以將結果置於上下文中。在做出有關ASN的決定時,應使用這兩個數字。

ASN風險評估情況下圖顯示了根據池大小的日誌繪製的每個ASN的風險評估。我們看到,隨著風險評估越來越差,ASN的池規模不太可能大。為了更容易理解這些信息,我們將ASN信譽分為四組:

良性:ASN內部發生惡意活動的機率極低;

可能是良性的:主要是良性的,ASN內發生惡意活動的可能性相對較低;

潛在惡意:應謹慎行事,大部分是良性的,但可以檢測到一些惡意活動;

可能惡意:應謹慎或避免,惡意活動與良性的比率表明ASN主要是惡意的或對惡意活動缺乏足夠的控制。

5.png

針對IP地址池大小繪製的每個ASN的風險評估

IPv4地址空間排名前10位的ASN都位於上圖右下角。這意味著他們大多數都有良好的信譽,只有少數例外。圖中突出顯示了異常值的ISP、移動網絡運營商(MNO)和託管服務提供商。與類似的大型ASN相比,它們具有更高的風險評估。數據顯示,這是由各種威脅類型驅動的。似乎有一些潛在的因素使這些ASN的風險更高。我們還必須記住,與這些非常大的ASN相比,惡意活動的相對數量很小,較小的ASN風險更大。

上圖出現的AkamaiASN都具有“良性”風險評估。但是,是什麼讓一個CDN比另一個更具風險呢?這可能是因為攻擊者的進入門檻較低,例如監控效果較差或控制較少。

我們還在上圖中突出了兩組總共13個ISP/MNOASN,可以看出它們的風險評估明顯更高。當我們更深入地觀察時,我們大多會看到來自這些ASN的殭屍網絡和掃描活動的混合。我們可以推測這些ASN更容易受到惡意軟件感染。

當我們繼續向圖的左上角移動時,我們會看到ASN長尾中具有各種威脅類型的風險部分。通常,我們會看到IP地址被用於託管惡意活動,如釣魚網站、惡意文件或掃描程序。在某些情況下,我們能夠看到TOR網絡出口節點,這可能是惡意活動的代理。

在線流量中的風險ASN到目前為止,我們已經從IP空間的角度查看了ASN風險評估,但是從在線流量角度來看,有風險的ASN出現的頻率是多少?下圖中顯示了一天中AkamaiDNS流量的變化,其中包含大約600億次查詢。總共76.6%的查詢來自“良性”和“可能良性”類別的ASN,18.1%來自“潛在惡意”類別,進一步強調合法和非法服務可以從同一個ASN運行。這些DNS查詢中共有5.3%解析為來自ASN的IP,其風險評估屬於“可能惡意”類別,這表明在高度鎖定的用例中,基於ASN的阻止的潛力在於識別真正的風險而不是避免誤報。

6.png

一天中Akamai DNS流量的變化

採取IP來預測攻擊風險就是要精準控制,即精度是最大的問題,希望盡量減少被阻止的合法服務的數量。在其他情況下,例如,在高度控制的環境中,減少誤報的比率很重要。

在沒有ASN信譽背書的情況下,我們在查看證據之前的假設是,所有IP都是合法的。 ASN信譽解鎖了對這些先前假設採取分層方法的能力。如果該IP的ASN非常糟糕,這可以作為我們預測攻擊風險發生的起點,我們可以在收集更多證據時更新我們的數據。 ASN中其他IP的得分會影響該IP的最終得分,並可能影響其是否被阻止。

阻止整個ASN在高度鎖定的環境中,可能需要根據其信譽來阻止整個ASN。由於ASN的信譽是不斷評估的,這個列表不需要是靜態的。隨著信譽的下降,新的ASN將被自動添加。同樣,當我們看到ASN威脅較小的證據時,可以放寬阻止。

總結在討論風險評估時,總會存在細微差別,但ASN風險評估有可能徹底改變安全行業。就像安全的所有其他方面一樣,沒有靈丹妙藥,每個組織都必須做出最適合其環境的決策。但是,超越僅基於IP的風險評估方法的能力允許在你的允許列表和阻止列表中採用更主動的防禦模型。

在軟件行業,可用性和安全性一直是個矛盾。許多第三方程序可以通過存儲用戶的憑據方便用戶使用。然而,事實證明,這種便利通常是以安全性性為代價的,從而導緻密碼被盜的風險。以這種方式收集的憑據可以在實際的網絡攻擊期間使用。

攻擊者如何擴展其訪問權限很明顯,憑據盜竊是很危險的。但是,有必要強調憑據盜竊可能產生的影響規模。

許多人傾向於在不同的程序中使用相同的密碼,並且很少更改他們的密碼。到了修改密碼的時候,許多人都遵循可預測的模式。

因此,當攻擊者可以從一個來源獲得密碼時,他們可以嘗試使用它來攻擊其他資源,包括一些更受保護的資源。因此,對於每個安全的程序A,用戶可以在不太安全的程序B 上使用相同的密碼或模式,這可能導致程序A 的安全性降低。

此外,如果發現有人在其他不太安全的地方使用他們的操作系統密碼,那麼攻擊者就會打開一個全新的可能性世界。

例如,假設某人X 對他的Windows 帳戶域和Linux FTP 文件服務器使用相同的密碼。在這種情況下,X用戶使用常用程序WinSCP在文件服務器上管理自己的文件。儘管WinSCP 建議不建議保存密碼,但是X用戶每週都會訪問這個文件服務器,所以他們更願意節省時間,保存密碼。

1.png

WinSCP 不建議保存密碼

正如我們稍後將演示的那樣,用戶的密碼可以很容易地從WinSCP存儲密碼的地方獲取。可以在X 的個人計算機上立足的攻擊者可以獲得他們的域帳戶密碼,只是因為它被不安全地保存了。最重要的是,密碼對於連接到文件服務器是有效的。該文件服務器可能包含攻擊者現在可以訪問的敏感信息文件。那樣,攻擊者可以使用像BloodHound 這樣的工具來估計他們可以在一個組織內傳播多遠。

以WinSCP為例進行具體分析WinSCP是常用的一種SFTP客戶端和FTP客戶端,用於在Windows本地計算機和遠程服務器之間通過FTP、FTPS、SCP和SFTP複製文件。

測試版本:5.19.6 (Build 12002 2202-02-22)

憑據存儲在哪裡?

WinSCP將加密後的用戶密碼存儲在如下所示的註冊表項下的一個名為Password 的值中。

加图1.png

如何恢復憑據?

WinSCP工具對用戶密碼的位數進行對稱數學運算。它獲取密碼的每個字節,計算0xFF(11111111)的補碼,然後用字節0xA3(10100011)對其進行異或運算。

加密過程包括找到補碼並執行一次異或運算。然後將密碼存儲在密碼註冊表值中。由於這些數學運算是對稱的,我們需要做的就是以相反的順序再次執行相同的兩個運算,以獲得原始值。

例如,讓我們以一個常用的密碼為例:Aa123456。 “1D3D6D6E6F68696A”密碼在WinSCP工具上的存儲方式如下。

在下圖中,我們看到了解密密碼的步驟:

2.png

解密存儲在WinSCP 中的密碼

密碼與主機名和用戶名一起保存。要從密碼註冊表值中獲取它,我們必須找到密碼開頭的索引。這個計算非常簡單,根據WinSCP版本,註冊表值的第一個或第三個字節是連接的用戶名、主機名和密碼的長度。起始索引是長度的下一個字節,其值乘以2。長度和起始索引都以相同的方式加密。

主機名和用戶名也保存在不同的註冊表值上,因此我們知道它們的長度和值。我們所做的就是從索引中解密密碼註冊表的值:開始索引+用戶名長度+主機名長度,我們就會得到我們的密碼。

3.png

連接的用戶名、主機名和密碼的位置

野外利用

我們已經看到在多個客戶環境中執行了以下腳本:

4.png

可疑的PowerShell編碼命令

-enc表示EncodedCommand,這意味著將使用一個base-64編碼的字符串作為命令。

在解碼的腳本中,我們可以看到嘗試解密WinSCP 密碼:

5.png

用於提取和解密WinSCP 密碼的PowerShell 腳本

6.png

Cortex XDR阻止了讀取存儲在WinSCP中的密碼的嘗試

以Git為例進行具體分析測試版本:2.35.1.windows.2。

憑據存儲在哪裡?

Git 允許同時使用密碼和個人訪問令牌(PAT)。

當用戶想通過保存他們的Git憑據來節省時間時,他們可以使用以下命令:

gitconfigcredential.helper'store'使用這個命令,Git將以純文本的形式無限期地將用戶的憑據保存在磁盤上。

可能包含密碼的文件:

加图2.png

Git 允許使用PAT 作為憑據,而不是傳統的密碼使用。這些令牌更加模塊化,因為可以創建任意數量的訪問令牌,每個令牌具有不同的權限和過期日期。

雖然可以以更模塊化和更細粒度的方式控制用戶的操作,每個操作都與特定的PAT 相關聯,但是擁有用戶PAT的任何人都可以查看用戶可以訪問的所有存儲庫。

這些標籤也以明文形式出現在上面提到的相同文件中。

如何恢復憑據?

任何閱讀這些文件的人都會以純文本形式看到用戶名、密碼或令牌以及相關的Git 存儲庫。

以RDCMan為例進行具體分析測試版本:2.83

RDCMan可以管理多個遠程桌面連接。它對於管理需要定期訪問計算機的服務器實驗室非常有用,比如自動簽入系統和數據中心。

憑據存儲在哪裡?

當用戶決定使用RDCMan 保存會話密碼時,默認配置文件將為%localappdata%\Microsoft\Remote Desktop Connection Manager\RDCMan.settings。

這個文件是一個XML文件,包含關於每個RDP連接的通用元數據。在這些數據中,有一個名為CredentialsProfiles的XML標籤引起了我們的注意。

我們可以看到,在這個標籤下,還有另一個名為CredentialsProfiles的標籤,其中還有credentialsProfile XML標籤,以及一個Password 標籤。

7.png

查看RDCMan.settings中的XML標籤

如何恢復憑據?

要檢索密碼,我們必須在使用RDCMan程序的用戶的上下文中執行命令。這是因為密碼是使用數據保護API (DATA Protection API, DPAPI)保存的,該API 可以分別使用CryptProtectData和CryptUnprotectData函數對任何類型的數據進行對稱加密和解密。

因此,為了獲得密碼,我們需要調用CryptUnprotectData函數。

通常,唯一可以解密數據的用戶是與加密數據的用戶具有相同登錄憑據的用戶。

儘管從RDCMan 收集憑據需要攻擊者採取比我們其他一些示例中所需的額外步驟,在相關用戶的上下文中運行軟件,但結果對攻擊者來說具有很大的價值。如果成功,攻擊者就有可能獲得該特定用戶連接到的所有計算機的所有用戶和密碼。

一旦攻擊者能夠在用戶的上下文中執行命令,為了收集憑據,剩下要做的就是:

打開RDCMan.settings 文件並檢查密碼XML 標籤;

使用base64 解碼標籤中的字符串;

使用解碼的密碼字符串調用CryptUnprotectData;

使用UTF-8(或其他相關格式)對結果進行解碼;

刪除不必要的空字符;

看看上面的例子,保存在文件中的密碼是:

AQAAANCMnd8BFdERjHoAwE/Cl+sBAAAA8/nnW5aFNUi0AKiTG4y9UQAAAAACAAAAAAAQZgAAAAEAACAAAADIjLLw0X4z9RDdWgPpqabLU7hTcJ1HVlFklpzX3eA14QAAAAAOgAAAAAIAACAAAAB01OvDCNCjaEhrq8J8hRm/SKyc ef7nR52ZkqcPLJqMsCAAAACg2htaeRsutDziS3FISeEAg3DsBpGxBGpPeWlUSVnXOkAAAAB5Tei9g5KWcVIhOKQ2cXxr5ONUOHMEEH5h3Lmp12mPlWaaZ6y8dGIVz8WnNKr4e73dhqNU8NyzI7RZBamS6DG6解密後的密碼是Aa123456。

8.png

從RDCMan中恢復密碼

以OpenVPN為例進行具體分析測試版本:2.5.029。

OpenVPN 是一個虛擬專用網絡系統,它實現了在路由或橋接配置和遠程訪問設施中創建安全的點對點連接的技術。

憑據存儲在哪裡?

OpenVPN 將用戶的密碼存儲在如下所示的註冊表項下的一個名為auth-data 的值中。

加图3.png

如何恢復憑據?

OpenVPN還使用了DPAPI機制,並附加了可選的熵參數(可以設置為NULL)。

當在加密階段使用可選的熵DATA_BLOB結構時,必須在解密階段使用相同的DATA_BLOB結構。

在OpenVPN的情況下,熵保存在一個名為熵的註冊表值中。熵註冊值也存儲在如下路徑。

加图4.png

因此,使用來自auth-data 和熵(來自熵)的密碼調用CryptUnprotectData 將為我們提供會話密碼。

熵註冊表值包含一個額外的字節00,所以我們只需要省略它。

9.png

上面是恢復OpenVPN密碼的PowerShell腳本。下面,通過reg.exe (POC) 顯示auth-data 和entropy 註冊表值的方式。

以基於Chromium 的瀏覽器為例進行具體分析測試版:

Google Chrome——測試版本:103.0.5060.53(官方版本)(64 位);

Microsoft Edge——測試版本:103.0.1264.37(官方版本)(64 位);

Opera——測試版本:88.0.4412.53;

Chromium 項目包括Chromium,它是Google Chrome 瀏覽器背後的開源項目。

在典型的使用例程中,許多人傾向於在上網時保存密碼。

10.png

Google Chrome 版本102.0.5005.115(官方版本)(64 位)保存的密碼

憑據存儲在哪裡?

在使用基於Chromium 的瀏覽器(如Microsoft Edge、Opera 或Google Chrome)時,密碼被加密位於SQLite 數據庫文件中,通常稱為登錄數據。

每個配置文件都有一個密碼數據庫,即它的登錄數據文件。

用於加密密碼的密鑰位於父文件夾中的名為本地狀態的JSON 文件中。

例如:

登錄數據位置:

加图5.png

區域位置:

Google Chrome: %localappdata%\google\chrome\user data\local state

Microsoft Edge: %localappdata%\microsoft\edge\user data\local state

Opera: %appdata%\opera software\opera stable\local state

如何恢復憑據?

登錄數據庫中的每個密碼都使用高級加密標準(AES) 以GCM 模式進行加密。 AES GCM是一種對稱加密方法,因此相同的密鑰對加密和解密都有效。 AES算法對每個128位數據塊使用不同的密鑰,該密鑰基於前一個塊的計算。對於第一個塊,可以選擇使用初始化向量(IV)。

要解密基於Chromium 的瀏覽器保存的密碼,我們需要:

加密的密碼;

初始化向量;

AES 密鑰;

讓我們看看如何檢索它們:

加密密碼

可以從登錄數據數據庫中導出:加密的密碼從password_value列中取出,從第15位的字母到末尾的16個字母。 [15:-16]

初始化向量

位於相同的password_value 字段列中,從第3 位的字母到第15 位的字母。 [3:15]

AES密鑰

寫在本地狀態JSON 文件中,在密鑰os_crypt 和encrypted_key 下,用base64 解碼。

基於Chromium 的瀏覽器使用DPAPI 機制保存AES 密鑰,因此要獲取它,我們必須從base64 解碼它並在用戶的上下文中使用CryptUnprotectData。

來自谷歌Chrome的示例:

11.png

保存在Google Chrome 本地狀態JSON 文件中的密碼

它以五個字母開頭的前綴保存:DPAPI。

12.png

保存在Google Chrome 中的解碼密碼

如果攻擊者能夠在用戶的上下文中運行,那麼完成收集用戶憑據所需要做的就是:

複製登錄數據和本地狀態文件;

從本地狀態JSON文件中獲取AES GCM密鑰;

解碼(base64),解密(CryptUnprotectData)並從密鑰中刪除填充;

使用解密的AES GCM 密鑰解密登錄數據數據庫中的每個密碼;

13.png

用於恢復Chrome 中保存的密碼的POC

你可以閱讀有關如何在Python 中提取Chrome 密碼的更多信息。

野外利用

我們看到在excel.exe中使用regsvr32.exe運行了以下DLL:

加图6.png

(kgnkudbadmpogg.dll 的SHA256:6599FEE8C7ADF30A00889A7070600F472F8CEAD8EA4DD1A85E724ED15F2AED0F)

在一系列操作之後,最終的有效負載試圖訪問Microsoft Edge 憑據文件:

登錄數據文件(SQLite 數據庫文件)如下所示:

加图7.png

本地狀態文件(包含加密密鑰)如下所示:

加图8.png

14.png

Cortex XDR 檢測到讀取保存在Microsoft Edge 瀏覽器中的密碼的嘗試

以Firefox瀏覽器為例進行具體分析測試版本:Firefox 版本101.0.1(64 位)

使用其他瀏覽器(例如Mozilla Firefox)時,密碼保存行為模式也很重要。

15.png

Firefox 版本101.0.1(64 位)保存的密碼

憑據存儲在哪裡?

與基於Chromium 的瀏覽器類似,在Mozilla Firefox 瀏覽器中,每個配置文件也有自己的密碼文件。

此文件名為logins.json,位於以下位置中:

加图9.png

用戶名和密碼均以加密方式保存。

16.png

Firefox 的logins.json 文件中保存的密碼

如何恢復憑據?

logins.json 文件中的每個用戶名和密碼都使用PKCS #11 加密標准進行加密。 Firefox 開發了NSS 庫,以便在其瀏覽器(nss3.dll) 中採用此標準。

NSS 將私鑰存儲在名為key3.db 或key4.db 的文件中,具體取決於NSS 版本。

要檢索用戶的密碼,攻擊者必須訪問其中一個文件和logins.json 文件。

因此,如果攻擊者能夠獲得在同一台計算機上運行的權限,那麼竊取密碼的過程將是:

攻擊者復制logins.json 文件;

加載NSS 庫(nss3.dll);

從logins.json 的副本中解碼(base64) encryptedUsername 和encryptedPassword;

將每個輸入存儲在一個SecItem 對像中,該對象稍後在整個NSS 中用於來回傳遞二進制數據塊;

創建用於輸出的SecItem 對象;

使用nss3.dll 中的PK11 解密函數解密每個encryptedUsername 和encryptedPassword 輸入對象,並將數據存儲在新的SecItem 輸出對像中;

與基於Chromium 的瀏覽器的情況不同,攻擊者不必在用戶的上下文中運行以獲取用戶的密碼,而是可以利用任何有權訪問目標用戶的文件系統配置文件的用戶。

Depositphotos_90753880_L.jpg

隨著越來越多的企業轉向使用雲服務和多因素身份驗證,與身份和身份驗證相關的cookie 就為攻擊者提供了一條新的攻擊途徑。

憑據竊取惡意軟件是各類攻擊者經常使用的工具包的一部分。雖然用戶帳戶名和密碼是憑據竊取活動的最明顯目標,但越來越多地使用多因素身份驗證(MFA) 來保護基於Web 的服務已經使該方法不再有效。越來越多的攻擊者轉向竊取與證書相關的“cookie”來複製當前或最近的web會話,並在此過程中繞過MFA。

最新版的Emotet 殭屍網絡只是針對瀏覽器存儲的cookie 和其他憑據(例如存儲的登錄名和在某些情況下支付卡數據)的眾多惡意軟件家族之一。谷歌的Chrome 瀏覽器使用相同的加密方法來存儲多因素身份驗證cookie 和信用卡數據——這兩個都是Emotet的目標。

針對cookie 的攻擊範圍很廣,小到信息竊取惡意軟件,例如Raccoon Stealer 惡意軟件即服務和RedLine Stealer 鍵盤記錄器/信息竊取程序,它們都可以通過地下論壇購買,且通常被入門者用來批量盜取cookie和其他證書,並出售給犯罪市場。

美國藝電公司(Electronic Arts,NASDAQ: ERTS,簡稱EA)一名員工的cookie 就出現了明顯的洩漏。 黑客組織Lapsus$的成員聲稱從市場購買了一個被盜的會話cookie,使他們能夠訪問EA 的Slack 實例;這使他們能夠欺騙EA 員工的現有登錄名,並欺騙EA 的IT 團隊成員為他們提供網絡訪問權限。這使得Lapsus$ 能夠獲取780 GB 的數據,包括遊戲和圖形引擎源代碼,該企業隨後利用這些數據試圖勒索EA。

對於高級攻擊者來說,研究人員觀察到活躍的攻擊者以各種方式獲取cookie。在某些示例中,研究人員已經看到勒索軟件運營商使用了與不太複雜的攻擊者相同的信息竊取惡意軟件的證據。但研究人員也經常看到實際攻擊濫用合法的攻擊安全工具,例如Mimikatz、Metasploit Meterpreter 和Cobalt Strike,以執行cookie 收集惡意軟件或運行從瀏覽器緩存中獲取cookie 的腳本。

還有一些合法的應用程序和進程可以與瀏覽器的cookie文件交互。研究人員在Sophos 的遙測技術中發現了cookie-snooping檢測的反惡意軟件、審計工具和操作系統助手:例如,Bing 的壁紙更新程序可以訪問cookie來獲取新的桌面背景。但是,在篩選出這些良性來源後,我們看到每天有數千次訪問瀏覽器cookie 的嘗試超出了良性軟件行為的範圍。有時,隨著特定活動的啟動,這些檢測結果會急劇上升。此外,一些使用cookie 的合法應用程序可能會洩露它們,從而將令牌暴露給攻擊者。

進入存儲cookie的文件瀏覽器將cookie 存儲在文件中,對於Mozilla Firefox、Google Chrome 和Microsoft Edge,該文件是用戶配置文件文件夾中的SQLite 數據庫。類似的SQLite文件存儲瀏覽器歷史記錄,網站登錄和自動填充這些瀏覽器的信息。其他連接到遠程服務的應用程序有自己的cookie存儲庫,或者在某些情況下可以訪問web瀏覽器的cookie存儲庫。

數據庫中每個cookie 的內容都是參數和值的列表,一個鍵值存儲,用於標識與遠程網站的瀏覽器會話,在某些情況下,還包括在用戶身份驗證後由網站傳遞給瀏覽器的令牌。其中一個鍵值對指定cookie的過期時間,即cookie在必須更新之前的有效時間。

1.png

cookies.sqlite 文件中的一些cookie

竊取cookie的原因很簡單:與web服務身份驗證相關的cookie可能被攻擊者用於“傳遞cookie”攻擊,試圖偽裝成最初向其發出cookie的合法用戶,並在沒有登錄挑戰的情況下獲得對web服務的訪問權。這類似於“傳遞哈希”攻擊,它使用本地存儲的身份驗證哈希來訪問網絡資源,而無需破解密碼。

2.png

合法的網絡服務活動

3.png

“傳遞cookie”攻擊是如何發起攻擊的

這可能導致對web服務(如AWS或Azure)、軟件即服務和協作服務的利用,以進一步暴露或橫向移動數據,如商業電子郵件洩露、訪問云數據存儲,或使用劫持的Slack會話引誘其他受害者下載惡意軟件或暴露其他可用於訪問的數據。

許多基於web的應用程序執行額外的檢查以防止會話欺騙,例如根據發起會話的位置檢查請求的IP地址。但是,如果cookie 被同一網絡內的手動鍵盤攻擊者使用,那麼這些措施可能不足以阻止攻擊。而為桌面和移動結合使用而構建的應用程序可能不會始終如一地使用地理位置。

有些cookie竊取攻擊可能完全從目標本身的瀏覽器中遠程發起。 HTML注入攻擊可以使用插入易受攻擊的網頁的代碼來利用其他服務的cookie,這允許訪問目標在這些服務上的個人信息,並允許更改密碼和電子郵件。

盜取cookie 的成本收益通常,惡意軟件運營商會使用付費下載服務和其他無針對性的方法,以低成本和不費力的方式收集盡可能多的受害者cookie 和其他相關憑據。這種類型的竊取器部署非常類似於Raccoon Stealer 和我們看到的其他惡意軟件活動,這些惡意軟件活動通過dropper 來傳播。

ISO 或ZIP 文件中的惡意軟件包通過搜索引擎優化提升的惡意網站作為盜版或“破解”商業軟件包的安裝程序。基於ISO 的傳播包也被廣泛用於代替惡意軟件垃圾郵件活動中的惡意文檔,這主要是因為微軟最近屏蔽了來自互聯網的Office文件中的宏。

研究人員在一個大學網絡上看到的“下載即服務”示例中,竊取的惡意軟件包含在一個從網站下載的虛假軟件安裝程序中,很可能是一個廣告盜版商業軟件。安裝程序通過用戶下載的300 兆ISO 文件的形式傳播,大型ISO 文件經常被用於阻止惡意軟件檢測軟件的文件掃描。

ISO 包含BLENDERINSTALLER3.0.EXE,這是一個來自另一個軟件包的重新利用的軟件安裝實用程序。該釋放程序使用PowerShell 命令和使用AutoIT(一種經常被惡意軟件運營商濫用的合法工具)創建的可執行文件安裝多個文件,以從.ISO 中提取惡意軟件,並從Discord 的內容傳播網絡下載其他惡意軟件文件。然後,惡意軟件包通過.NET 進程(使用.NET 框架中的jsc.exe)注入一系列命令,以從Chrome 中獲取cookie 和登錄數據。

4.png

一個虛假的安裝程序/信息竊取cookie程序

高度複雜的攻擊過程惡意垃圾郵件還與其他偽裝附件一起使用,通常針對特定行業或國家的企業。 2021 年10 月,一名土耳其計算機用戶收到了一封電子郵件,其附件是一個XZ壓縮文件。這包含一個偽裝的可執行文件,“ürün örnekleri resmi pdf.exe”(翻譯為“產品樣本圖像pdf.exe”)。該可執行文件是一個使用Delphi 編程語言(稱為“BobSoft Mini Delphi”)構建的自解壓惡意軟件dropper。

這個dropper依次安裝了幾個可執行程序。第一個是合法的Microsoft Visual Studio組件(msbuild.exe)。 MSBuild 通常用於編譯和執行編碼項目,它可以在命令行上傳遞項目文件或包含腳本的XML 文件,並啟動它們。由於該文件是受信任的Microsoft 二進製文件,因此可以將其打包到dropper 中,以掩蓋惡意軟件的惡意性質。

第二個可執行文件是從Discord 內容傳播網絡中檢索並解密的,它是Phoenix 鍵盤記錄器,一個信息竊取者。 QuasarRat 也在某個時候被釋放,這是一個用C# 編寫的遠程訪問工具。

在接下來的一周中,攻擊者使用安裝的QuasarRAT啟動了Phoenix信息竊取程序並通過MSBuild 執行命令。 MSBuild 構建和執行的命令訪問了目標設備上的cookie 文件。

5.png

Malspam/Phoenix 竊取的過程

有針對性的利用竊取cookie 不僅僅是一項自動化活動。在某些情況下,這也是積極的攻擊者尋求加深對目標網絡滲透的努力的一部分。在這些情況下,攻擊者利用網絡上的攻擊入口來部署利用工具,並使用這些工具來傳播他們的訪問權限。隨著越來越多的有價值的數據從網絡轉移到雲服務中,這些攻擊者通過竊取cookie和抓取web登錄數據來增加這些服務的橫向移動。

研究人員在2022年6月發現了一個這種類型的長期攻擊活動,其中竊取cookie是持續數月的Cobalt Strike 和Meterpreter 活動的一部分。攻擊者專門針對Microsoft Edge 瀏覽器中的cookie。首先,他們能夠使用Impacket 漏洞利用工具包通過Windows SMB 文件傳輸從初始入口點傳播,將Cobalt Strike 和Meterpreter 釋放到網絡內的目標計算機上。

6.png

竊取cookie

接下來,攻擊者在目標系統上放置了一個合法Perl 腳本解釋器的副本,以及之前基於Impacket 的攻擊中看到的Perl 腳本文件(名為c)和批處理文件(execute.exe)。然後他們使用Meterpreter 傳遞以下命令字符串:

7.png

Perl腳本訪問目標計算機上的cookie文件,並將內容輸出到一個名為_output的臨時文件。該批處理文件將_output 的內容傳回給攻擊者並刪除了Perl 腳本。其餘的shell 命令關閉了屏幕輸出,刪除了批處理文件,並終止了命令shell。

這三個示例僅代表cookie 竊取網絡犯罪的冰山一角。竊取信息的惡意軟件越來越多地將竊取cookie作為其功能的一部分,而低成本高收益使得銷售竊取的cookie成為一項可行的業務。但更有針對性的攻擊者也以cookie 為目標,他們的活動可能無法被簡單的反惡意軟件防禦檢測到,因為他們濫用了合法的可執行文件,包括已經存在和作為工具帶來的合法可執行文件。

如果沒有這麼多應用程序使用長期訪問cookie,那麼cookie 竊取幾乎不會構成威脅。例如,Slack結合使用持久cookie和特定於會話的cookie來檢查用戶的身份和身份驗證。當瀏覽器關閉時,會話cookie會被清除,但其中一些應用程序(如Slack)在某些環境中仍然無限期地打開。這些cookie過期的速度可能不夠快,無法防止被盜時被人利用。如果用戶不關閉會話,與一些多因素身份驗證相關聯的單點登錄令牌可能會造成同樣的潛在威脅。

定期清除瀏覽器的cookie和其他認證信息可以減少瀏覽器配置文件提供的潛在攻擊面,企業可以使用一些基於Web 的平台的管理工具來縮短cookie 保持有效的允許時間範圍。

但強化cookie政策是有代價的。縮短cookie的生命週期意味著用戶需要進行更多的重新身份驗證。而且,一些利用基於Electron或類似開發平台的客戶端的基於web的應用程序可能有它們自己的cookie處理問題。例如,他們可能有自己的cookie 存儲,攻擊者可以在Web 瀏覽器存儲的上下文之外專門針對這些存儲。

在某些情況下,具有高完整性或系統完整性的進程會向權限進程/線程/令牌請求句柄,然後生成低完整性進程。如果這些句柄足夠強大,且類型正確,並且由子進程繼承,我們可以從另一個進程複製它們,然後濫用它們來升級權限或繞過UAC。在這篇文章中,我們將介紹如何尋找和濫用這種漏洞。

介紹本質上,這個想法是看看我們是否可以自動找到擁有高完整性(也就是提升)或SYSTEM進程的權限句柄的非權限進程,然後檢查我們是否可以作為一個非權限用戶附加到這些進程上,並複制這些句柄,以便以後濫用它們。我們的工具會受到哪些限制?

1.它必須作為中等完整性進程運行;

2. 進程令牌中沒有SeDebugPrivilege(中等完整性的進程默認沒有這個權限);

3. 沒有UAC 繞過,因為它也必須適用於非管理用戶;

這個過程有點複雜,我們將經歷的步驟或多或少如下:

1.枚舉所有進程持有的所有句柄;

2.過濾掉我們不感興趣的句柄,現在我們只關注進程、線程和令牌的句柄,因為它們更容易被武器化;

3.過濾掉引用低完整性進程/線程/令牌的句柄;

4.過濾掉完整性大於中等的進程持有的句柄,除非獲得SeDebugPrivilege,否則我們不能附加到它們上,這違背了本文的目的;

5.複製其餘的句柄並將它們導入我們的進程,並試圖濫用它們來升級權限或者至少繞過UAC;

1.jpg

當然,我們不太可能在一台全新的Windows設備上滿足這些條件,所以為了避免這個問題,我將使用一個我專門為此目的編寫的易受攻擊的應用程序。

句柄處理正如我在這個Twitter線程中簡要討論的那樣,Windows是一個基於對象的操作系統,這意味著每個實體(進程、線程、互斥鎖等)在內核中都以數據結構的形式有一個“對象”表示。例如,對於進程,該數據結構的類型是_EPROCESS。作為存在於內核空間的數據,普通的用戶模式代碼無法直接與這些數據結構交互,因此操作系統公開了一個間接機制,該機制依賴於特殊的HANDLE類型變量以及用於服務的SC_HANDLE 等派生類型。句柄只不過是內核空間表中的索引,對每個進程來說都是私有的。表中的每一項都包含了它所指向的對象的地址以及該句柄對該對象的訪問級別。這個表由每個進程的_EPROCESS結構的ObjectTable成員(它的類型是_HANDLE_TABLE*,因此它指向一個_HANDLE_TABLE)指向。

為了更容易理解,讓我們看一個例子。要獲得進程的句柄,我們可以使用OpenProcess Win32 API,定義如下:

2.png

它需要3個參數:

dwDesiredAccess是一個DWORD,它指定了我們希望對我們試圖打開的進程擁有的訪問級別;

bInheritHandle是一個布爾值,如果設置為TRUE,將使句柄可繼承,這意味著調用進程在子進程生成時將返回的句柄複製給子進程(以防我們的程序調用CreateProcess之類的函數);

dwProcessId是一個DWORD,用於指定我們想打開哪個進程(通過提供它的PID);

在下一行中,我將嘗試打開系統進程(它始終具有PID 4)的句柄,向內核指定我希望句柄擁有盡可能少的特權,只需要查詢有關信息的子集進程(PROCESS_QUERY_LIMITED_INFORMATION),並且我希望該程序的子進程繼承返回的句柄(TRUE)。

3.png

OpenProcess返回的System進程的句柄(如果它沒有因為某種原因失敗)被放入hProcess變量中以供以後使用。

在後台,內核執行一些安全檢查,如果這些檢查通過,則獲取所提供的PID,解析相關_EPROCESS結構的地址,並將其複製到句柄表中的一個新條目中。之後,它將訪問掩碼(即提供的訪問級別)複製到相同的條目中,並將條目值返回給調用代碼。

當你調用其他函數(如OpenThread和OpenToken)時,也會發生類似的事情。

查看句柄正如我們前面介紹的,句柄本質上是表的索引。每個條目都包含句柄所引用對象的地址以及句柄的訪問級別。我們可以使用Process Explorer 或Process Hacker 等工具查看這些信息:

4.png

從這個Process Explorer 屏幕截圖中,我們可以獲得一些信息:

紅框:句柄所指的對像類型;

藍色框:句柄值(表項的實際索引);

黃色框:句柄所指對象的地址;

綠色框:訪問掩碼及其解碼值(訪問掩碼是在Windows.h 頭文件中定義的宏),這告訴我們在對像上授予句柄持有者哪些特權;

有很多方法可以獲得這些信息,不一定需要使用在內核模式下運行的代碼。在這些方法中,最實用和最有用的是依賴原生API NtQuerySystemInformation,當調用它時傳遞SystemHandleInformation (0x10) 值作為其第一個參數,返回一個指向SYSTEM_HANDLE 變量數組的指針,其中每個變量都引用一個由系統上的進程打開的句柄。

5.png

讓我們來看看用c++實現它的一種可能的方法。

6.png

在這段代碼中,我們使用以下變量:

queryInfoStatus 將保存NtQuerySystemInformation 的返回值;

tempHandleInfo 將保存有關係統NtQuerySystemInformation 為我們獲取的所有句柄的數據;

handleInfoSize 是對所說數據量的“猜測”。不要擔心,因為每次NtQuerySystemInformation 將返回STATUS_INFO_LENGTH_MISMATCH 時這個變量都會加倍,這是一個告訴我們分配的空間不夠的值;

handleInfo 是指向內存位置的指針NtQuerySystemInformation 將填充我們需要的數據;

不要對這裡的while 循環感到困惑,正如我們所說,我們只是反複調用函數,直到分配的內存空間足夠大,可以容納所有的數據。在使用Windows本機API時,這種類型的操作非常普遍。

NtQuerySystemInformation 獲取的數據可以通過簡單的迭代來解析,如下所示:

7.png

從代碼中可以看出,變量句柄是SYSTEM_HANDLE 類型的結構(自動從代碼中刪除)有許多成員提供有關它所引用的句柄的有用信息。最有趣的成員是:

ProcessId:持有句柄的進程;

Handle:持有句柄本身的進程內部的句柄值;

Object:句柄指向的對像在內核空間中的地址;

ObjectTypeNumber:一個未記錄的BYTE 變量,用於標識句柄所指對象的類型。為了解釋它,需要進行一些逆向工程和挖掘,只要說進程由值0x07 標識,線程由0x08 標識,令牌由0x05 標識就足夠了;

GrantedAccess 句柄授予的對內核對象的訪問級別,對於進程,你可以找到諸如PROCESS_ALL_ACCESS、PROCESS_CREATE_PROCESS 等值。

讓我們運行上述代碼並查看其輸出結果:

8.png

我們可以從對像類型的0x7 值推斷出,在這段摘錄中,我們看到PID 為4 的進程(即任何Windows 機器上的系統進程)當前已打開3 個句柄。所有這些句柄都引用進程類型的內核對象,每個都有自己的內核空間地址,但只有第一個是特權句柄,正如你可以從其值推斷出的那樣,0x1fffff,這是PROCESS_ALL_ACCESS 翻譯的內容。不幸的是,在我的研究中,我發現沒有直接的方法可以直接提取SYSTEM_HANDLE 結構的ObjectAddress 成員所指向的進程的PID。稍後我們將看到一個巧妙的技巧來規避這個問題,但現在讓我們使用Process Explorer 檢查它正在使用哪個進程。

9.png

正如你所看到的,值為0x828的句柄的類型是process,它引用進程services.exe。對像地址和被授予的訪問也都簽出了,如果你查看圖像的右側,你將看到解碼的訪問掩碼顯示PROCESS_ALL_ACCESS,正如預期的那樣。

這是非常有趣的,因為它本質上允許我們查看任何進程的句柄表,而不管它的安全上下文和PP(L)級別。

從目標進程的對像地址獲取目標進程的PID如上所述,我沒有找到一種方法來取回給定進程的SYSTEM_HANDLE 進程的PID,但我確實找到了一個有趣的解決方法。讓我們先來看看一些假設:

1.SYSTEM_HANDLE結構包含Object成員,該成員保存內核對像地址,該地址在內核空間中;

2.在Windows上,所有進程都有自己的地址空間,但是地址空間的內核空間部分(64位進程的最大128TB)對所有進程是相同的。內核空間中的地址在所有進程中保存相同的數據;

3.提到進程的句柄時,SYSTEM_HANDLE的Object成員指向進程本身的_EPROCESS結構;

4.每個進程只有一個_EPROCESS 結構;

5.我們可以通過調用OpenProcess 並將PROCESS_QUERY_LIMITED_INFORMATION 指定為所需的訪問值來獲取任何進程的句柄,而不管其安全上下文如何;

從這些假設中,我們可以推斷出以下信息:

1.如果句柄在同一個對像上打開,則兩個不同SYSTEM_HANDLE 結構的Object 成員將相同,而與持有該句柄的進程無關,例如,由兩個不同進程在同一文件上打開的兩個句柄將具有相同的Object 值:

1.1由兩個不同進程打開的同一進程的兩個句柄將具有匹配的Object 值;

1.2線程、令牌等也是如此;

2.當調用NtQuerySystemInformation 時,我們可以枚舉我們自己的進程持有的句柄;

如果我們通過OpenProcess 獲得一個進程的句柄,我們就知道該進程的PID,並且通過NtQuerySystemInformation,它的_EPROCESS 的內核空間地址

你能看到我們要去哪裡嗎?如果我們設法打開一個對所有進程具有訪問PROCESS_QUERY_LIMITED_INFORMATION 的句柄,然後通過NtQuerySystemInformation 檢索所有系統句柄,我們就可以過濾掉所有不屬於我們進程的句柄,並從那些屬於我們進程的句柄中提取對象值並在它與生成的PID 之間進行匹配。當然,線程也可以這樣做,只使用OpenThread 和THREAD_QUERY_INFORMATION_LIMITED。

為了有效地打開系統上的所有進程和線程,我們可以依賴TlHelp32.h 庫的例程,它會允許我們拍攝系統上所有進程和線程的快照,並遍歷該快照以獲取拍攝快照時運行的進程和線程的PID 和TID(線程ID)。

下面的代碼塊顯示了我們如何獲取所述快照並遍歷它以獲取所有進程的PID。

10.png

首先定義一個std:map,這是c++中的一個類似字典的類,它允許我們跟踪指向PID的句柄,我們將其稱為mHandleId。

完成後,我們使用CreateToolhelp32Snapshot 獲取有關進程的系統狀態快照,並指定我們只需要進程(通過TH32CS_SNAPPROCESS 參數)。這個快照被分配給快照變量,它的類型是wil:unique_handle,它是WIL 庫的一個C++ 類,它使我們擺脫了在使用句柄後必須正確清理句柄的負擔。完成後,我們定義並初始化一個名為processEntry 的PROCESSENTRY32W 變量,一旦我們開始遍歷快照,它將保存我們正在檢查的進程的信息。

通過調用Process32FirstW 並用快照中第一個進程的數據填充processEntry。對於每個進程,我們嘗試在其PID 上使用PROCESS_QUERY_LIMITED_INFORMATION 調用OpenProcess,如果成功,我們將句柄- PID 對存儲在mHandleId 映射中。

在每個while 循環中,我們執行Process32NextW 並用新進程填充processEntry 變量,直到它返回false 並且我們退出循環。現在,我們的句柄和它們指向的進程的PID 之間有一個1 對1 的映射。現在進入第二階段!

現在是獲取所有系統句柄並過濾掉不屬於我們進程的句柄的時候了,我們已經了解瞭如何檢索所有句柄,現在只需檢查每個SYSTEM_HANDLE 並將其ProcessId 成員與我們的進程的PID 進行比較,可通過恰當命名的GetCurrentProcessId 函數獲得。然後,我們以與處理句柄-PID 對類似的方式存儲屬於我們進程的那些SYSTEM_HANDLE 的Object 和Handle 成員的值,使用我們稱為mAddressHandle 的映射。

11.png

你可能想知道為什麼使用switch 語句而不是簡單的if。一些代碼已被刪除,因為這些是我們高級持久性Tortellini 專門為尋找我們在文章開頭提到的漏洞而編寫的工具的摘錄。

現在我們已經填充了兩個映射,當我們只知道它的_EPROCESS 地址時,獲取一個進程的PID 是一件輕而易舉的事。

12.png

我們首先將對象的地址保存在地址變量中,然後使用find 方法在mAddressHandle 映射中查找該地址,該方法將返回uint64_t,HANDLE 。這對包含地址和它對應的句柄。我們通過保存對成員的值來獲取句柄second並將其保存在foundHandle變量中。之後,只需要做我們剛才所做的事情,但是使用mHandleId映射和handlePid變量將保存進程的PID,其地址是我們開始的那個進程。

現在我們有了一種可靠的方法來匹配地址和PID,我們需要專門尋找那些完整性小於高進程持有有趣的句柄的情況,這些句柄與完整性等於或大於高的進程保持一致。但是從安全的角度來看,是什麼讓句柄“有趣”呢?我們將關注的句柄是具有以下訪問掩碼的句柄:

PROCESS_ALL_ACCESS

PROCESS_CREATE_PROCESS

PROCESS_CREATE_THREAD

PROCESS_DUP_HANDLE

PROCESS_VM_WRITE如果你在非特權進程中找到具有至少一個此訪問掩碼的特權進程的句柄,那非常幸運。讓我們看看我們如何做到這一點。

13.png

在這段代碼中,我們首先定義一個名為vSysHandle 的std:vector,它將保存有趣的SYSTEM_HANDLE。之後,我們開始對NtQuerySystemInformation 返回的數據進行常規迭代,只是這次我們跳過了當前進程持有的句柄。然後,我們通過我編寫的名為GetTargetIntegrityLevel 的幫助函數檢查持有我們當前正在分析的句柄的進程的完整性級別。這個函數基本上返回一個DWORD,告訴我們與它作為參數接收的PID 相關聯的令牌的完整性級別,並且改編自許多在線可用的PoC 和MSDN 函數。

一旦我們檢索到進程的完整性級別,我們要確保它小於高完整性,因為我們感興趣的是持有感興趣的句柄的中完整性或低完整性進程,我們還要確保我們正在處理的SYSTEM_HANDLE類型是進程(0x7)。檢查後,我們轉到檢查句柄授予的訪問權限。如果句柄不是PROCESS_ALL_ACCESS或不包含任何指定的標誌,則跳過它。否則,我們更進一步,檢索句柄所指進程的PID,並獲取其完整性級別。如果它是高完整性或更高的(例如SYSTEM),我們將SYSTEM_HANDLE保存在我們的vsyhandle中供以後使用。

首先,我們打開持有權限句柄的進程,然後復制該句柄。

14.png

這是相當簡單的,首先,你使用PROCESS_DUP_HANDLE訪問權限打開進程,這是複制句柄所需的最小權限,然後在該進程上調用DuplicateHandle,告訴函數你希望復制保存在syhandle中的句柄,並將其保存到clonedHandle變量中的當前進程中。

通過這種方式,我們的進程現在處於權限句柄的控制之下,我們可以使用它來生成一個新進程,把它的父進程偽裝成該句柄所指向的權限進程,從而使新進程繼承它的安全上下文,並獲得命令shell等。

15.png

讓我們看看它的實際應用:

16.png

Microsoft系統中心配置管理器(SCCM)。 SCCM是一款微軟產品體系架構下的桌面端,服務器,移動端管理產品。主要是負責桌面標準化,網絡批量安裝部署軟件和操作系統,殺毒策略,資產收集,移動端管理等等。是一款作為IT管理員,企業基礎架構管理的必備工具。在這篇文章中,我們將介紹SCCM 如何使用其HTTP API 來初始化客戶端。我們還將了解如何從SCCM 檢索網絡訪問帳戶,以及我們如何解密這些憑據而無需使用DPAPI 或管理員帳戶。

實驗室設置對於我們的實驗室設置,我們將使用默認的SCCM 部署。我發現最簡單的方法是通過自動化實驗室,它支持通過ConfigurationManager 角色進行安裝:

1.png

我們將在這篇文章中使用的版本是Configuration Manager 2103,我們將把我們的主站點命名為P01。本實驗的服務器將稱為SCCM01,我們將配置為使用HTTP 進行通信。

一旦SCCM服務器的設置完成,我們將把一切都保留為標準,並添加一個Network Access Account供以後使用:

2.png

完成後,我們就可以繼續探索了!

客戶端註冊讓我們首先看看客戶機嘗試向SCCM註冊時生成的請求。為了做到這一點,我們使用@_Mayyhem awesome SharpSCCM工具:

3.png

當SharpSCCM 調用實際的.NET 客戶端庫時,我們會收到一個清晰的請求,我們可以使用WireShark 來識別它。客戶端向SCCM 服務器註冊的初始步驟如下:

4.png

這個HTTP 請求被發送到SCCM 服務器,由兩部分組成,一個是XML 編碼的標頭,另一個是在多部分/混合HTTP 請求中發送的XML 編碼的正文。有趣的是,該協議還使用了CCM_POST 的HTTP 方法。

標頭採用UTF-16 編碼,如下所示:

5.png

請求正文是zlib壓縮和Unicode編碼:

6.png

為了簡單起見,我刪除了一些較長的十六進製字符串,但我們在這裡看到的是三個十六進制blob被發送到服務器,以及一些關於我們的客戶端的初始信息。

讓我們轉儲Signing blob:

7.png

如果我們看這個,我們實際上會看到這是一個DER 編碼的證書:

8.png

生成此證書時,添加了兩個擴展密鑰使用OID:

9.png

這些將證書標記為短信簽名證書(自簽名)。

因此,我們看到客戶端證書被傳遞給SCCM服務器以供稍後使用,但是SignatureValue字段呢?讓我們啟動dnSpy並深入研究System.ConfigurationManagement.Messaging.dll程序集,該程序集位於安裝了客戶端的主機上的C:\Windows\CCM 中。

經過一番搜尋,我們在Interop.Crypt32.HashAndSignData中找到了答案:

10.png

這表明,使用帶有PKCSv15填充的RSA- sha256正在使用與證書關聯的RSA 私鑰對XML 請求正文進行簽名。

這裡需要注意的一件奇怪的事情是,一旦生成簽名,字節在ASCII十六進制編碼並添加到請求¯\_(ツ)_/¯之前會被反轉。

當服務器響應這個客戶端註冊請求時,我們再次看到有一個XML 標頭和正文,其中正文數據被zlib 壓縮。可以看到我們被分配給了ClientID,它是在我們的客戶端與服務器通信期間使用的UUID:

11.png

在這個階段值得注意的是,這個請求可以發送到未經身份驗證的SCCM URL http://SCCM01/ccm_system/request。這足以向SCCM添加一個客戶端條目,但是我們將處於“未批准”狀態。這種狀態在以後會變得很重要:

12.png

政策要求客戶端註冊後,客戶端執行的下一個階段是檢索策略列表。此調用還使用

13.png

不幸的是,這是事情變得有點複雜的地方。我們首先需要關注的是PublicKey blob。這實際上只是客戶端之前為證書生成的RSA 公鑰,但是這次它被編碼為PUBLICKEYBLOB。

接下來是ClientIDSignature。這是我們之前看到的用於簽署ClientID 的RSA-SHA256 簽名,前面帶有GUID:然後轉換為Unicode。例如:

14.png

最後是PayloadSignature,它是隨後壓縮的主體的簽名。

這個請求的主體是zlib 壓縮和Unicode 編碼的,帶有我們客戶端的信息:

15.png

對該請求的響應是XML主體中可用的策略列表:

16.1.png

16.2.png

雖然這裡有很多有趣的東西,但我們現在要關注的領域將是網絡訪問帳戶的共享方式。

秘密政策如果你遍歷我們檢索到的策略列表,你一定會遇到標記為“秘密”的策略。其中一個策略是NAAConfig,它包含了網絡訪問帳戶:

17.png

你可能已經看到@gentilkiwi 在2021 年發布的Mimikatz 更新中引用了這些帳戶,這表明通常這些憑據是在SCCM 客戶端上使用DPAPI 加密的:

18.png

但是,如果我們嘗試使用RequestAssignments 請求返回的URL 直接下載此策略,我們會看到出現一個錯誤。

19.png

這樣做的原因是需要對秘密策略的請求進行身份驗證。但是由於這是SCCM,所以還需要進行另一種類型的身份驗證。

經過一番搜尋之後,我發現了對SCCM 服務器上名為ccmgencert.dll 的DLL 中使用的身份驗證類型的引用:

20.png

既然我們知道了一些使用的簽名方法,這些標頭實際上可以很容易被創建。看看被添加到SCCM平台的客戶端,我們看到它們是這樣的:

21.png

ClientToken只是我們的cliententid和當前DateTime的一個連接。 ClientTokenSignature是使用上面相同的RSA-SHA256算法的簽名。

讓將這些標頭添加到我們的請求中,看看會得到什麼:

22.png

這一次,我們得到了不同的回應。我的意思是我們出現錯誤,但我們也沒有得到任何不好的數據。

事實證明,對於我們的客戶端實際請求秘密策略,他們需要在服務器上處於Approved 狀態。

默認情況下,SCCM 安裝有以下內容:

23.png

那麼,計算機是如何自動自我認可的呢?還有另一個URL被/ccm_system_windowsauth/request的客戶端使用。如果之前的XML ClientRegistrationRequest被發送到這個路徑,並完成NTLMSSP驗證計算機帳戶,則客戶端設置為Approved 狀態:

24.png

現在,當對此URL 進行身份驗證時,我們似乎可以使用任何隨機域用戶帳戶。然而,問題是它似乎不足以迫使客戶進入批准狀態。相反,我們需要使用計算機帳戶(儘管它不需要與我們嘗試註冊的客戶端相對應),所以addcomputer.py 在這裡非常有用。

25.png

通過將此身份驗證步驟添加到我們的註冊請求並強制我們的客戶端進入Approved 狀態,下次我們請求NAAConfig 策略時,我們會得到如下所示的內容:

26.png

好吧,回到dnSpy,我們去嘗試弄清楚。答案在Interop.DecryptMessageFromCertificateFile 方法中找到,該方法顯示了CryptDecryptMessage API 調用的使用。

27.png

參數顯示此加密策略是使用3DES CBC 的PKCS7 編碼blob,其密鑰源自我們之前在證書中提供的RSA 公鑰。

解密後,我們終於看到了一些實際的憑證,如下所示:

28.png

網絡訪問帳戶混淆起初,獲取這些賬戶似乎需要更多的加密貨幣。但是MimiKatz 已經向我們展示了這些憑據最終可以在客戶端上訪問,因此我們知道我們的客戶端必須能夠在使用DPAPI 保護它們之前以某種方式解密這些憑據……那麼密鑰是什麼?在尋找這個加密是如何完成的之後,我在客戶端上找到了一個名為PolicyAgent.dll 的DLL。

最重要的是調試字符串:

29.png

UnobfuscateString 聽起來很有希望,當然聽起來比DecryptString 更好。我沒有深入研究這個反彙編的所有部分,而是創建了一個快速調試工具來調用這個函數。

30.png

當運行在與SCCM實驗室網絡無關的主機上時,並且連接到調試器以逐步解決通過以這種方式調用方法而發生的不可避免的訪問衝突時,就會解密用戶名和密碼:

31.png

32.png

這意味著所使用的加密與描述的完全一樣,它是被混淆的!我們擁有在密文中解密這些憑證所需的所有信息,而且我們可以完全離線完成!

通過重新創建unobfuscation方法的步驟,我們可以創建如下所示的解密代碼。

33.1.png

有了計算機帳戶,我們就可以在SCCM 中添加虛假客戶端,下載加密的網絡訪問帳戶憑據,並對其進行解密,而無需處理提升權限或任何DPAPI 解密。

1.png

Unit 42研究人員檢查了幾個包含Cobalt Strike組件的惡意軟件樣本,並發現通過分析進程中關鍵執行工件可以捕獲這些樣本。

cobalt strike(簡稱CS)是一款團隊作戰滲透測試神器,分為客戶端及服務端,一個服務端可以對應多個客戶端,一個客戶端可以連接多個服務端。它不僅在紅隊中流行,而且也被用於惡意目的。

儘管該工具包只出售給受信任的組織進行安全測試,但由於源代碼洩露,它的各種組件不可避免地進入了攻擊者的武器庫,從勒索軟件組織到國家支持的攻擊組織。濫用Cobalt Strike的惡意軟件甚至在2020年臭名昭著的SolarWinds供應鏈攻擊事件發揮了作用。

為什麼是Cobalt Strike? Cobalt Strike之所以被如此廣泛的利用,主要是因為Cobalt Strike集成了端口轉發、掃描多模式端口Listener、Windows exe程序生成、Windows dll動態鏈接庫生成、java程序生成、office宏代碼生成,包括站點複製獲取瀏覽器的相關信息等。由於它的設計是從底層開始的,所以攻擊者會定期使用它引入新的規避技術。

Cobalt Strike的主要優點之一是,一旦初始加載程序被執行,它主要在內存中運行。當有效負載是靜態防護的、僅存在於內存中並且拒絕執行時,這種情況會給檢測帶來問題。這對許多安全軟件產品來說都是一個挑戰,因為掃描內存絕非易事。

在許多情況下,Cobalt Strike是在目標網絡中獲得初始足蹟的自然選擇。攻擊者可以使用具有大量部署和混淆選項的構建器,根據可定制的模板創建最終有效負載。

該有效負載通常以加密或編碼的形式嵌入到文件加載程序中。當受害者執行文件加載程序時,它將有效負載解密/解碼到內存中並運行它。由於有效負載以其原始形式存在於內存中,因此由於某些特定功能,可以很容易地檢測到它。

作為惡意軟件研究人員,我們經常看到潛在的有趣的惡意樣本,結果只是Cobalt Strike的加載程序。通常也不清楚加載程序是由紅隊創建的還是真正的攻擊者創建的,因此使歸因更具挑戰性。

接下來我們將深入研究三種不同的Cobalt Strike加載程序,它們是由我們設計的一個新的基於管理程序的沙箱檢測到的,該沙箱允許我們分析內存中的工件。每個示例加載不同的植入類型,即SMB、HTTPS和stager信標。我們將這些Cobalt Strike裝載程序稱為KoboldLoader, MagnetLoader和LithiumLoader。我們還將討論可以用來檢測這些有效負載的一些方法。

KoboldLoader SMB信標以以下樣本為例

SHA256: 7ccf0bbd0350e7dbe91706279d1a7704fe72dcec74257d4dc35852fcc65ba292

這個64位KoboldLoader可執行文件使用各種已知的技巧來繞過沙盒,並使分析過程更加耗時。

為了繞過隻掛鉤高級用戶模式函數的沙盒,它只調用內置API函數。為了使分析人員的工作更加困難,它通過哈希而不是使用純文本字符串來動態解析函數。惡意軟件包含調用以下函數的代碼:

2.png

該惡意軟件創建了兩個單獨的函數哈希/地址對錶。一個表包含所有內置函數的一對,而第二個表只包含Nt*個函數對。

對於所使用的Rtl*函數,它循環遍歷第一個表並蒐索函數哈希以獲得函數地址。對於使用的Nt*函數,它遍歷第二個表並同時增加一個計數器變量。

當找到哈希時,它將獲取計數器值,即相應內置函數的系統調用號,並輸入自定義系統調用存根。這有效地繞過了許多沙盒,即使掛接了較低級別的內置函數而不是高級函數。

加載程序的整體功能相對簡單,並使用映射注入來運行負載。它生成Windows工具sethc.exe的子進程,創建一個新部分,並將解密的Cobalt Strike信標加載程序映射到其中。 Cobalt Strike加載程序的最終執行是通過調用RtlCreateUserThread來加載SMB信標的。

內存中的規避功能通過新的基於管理程序的沙盒,我們能夠在內存中檢測到解密的Cobalt Strike SMB信標。這個信標加載程序甚至使用了一些內存中的規避功能,創建了一種奇怪的嵌合體文件。雖然它實際上是一個DLL,但“MZ”神奇的PE字節和隨後的DOS標頭被一個小的加載程序shellcode覆蓋,如下圖所示。

3.png

解密的Cobalt Strike SMB信標shellcode

shellcode加載程序跳轉到導出的函數DllCanUnloadNow,該函數在內存中準備SMB信標模塊。為此,它首先加載Windows pla.dll庫,並清空代碼段(.text)中的一大塊字節。然後,它將信標文件寫入該blob並修復導入地址表,從而創建一個可執行內存模塊。

在分析該文件的過程中,我們可以找出所使用的一些內存內規避功能,如下表所示。

4.png

內存內規避功能

總之,信標加載程序和信標本身是同一個文件。 PE標頭的部分用於跳轉到導出函數的shellcode,該函數反過來在Windows DLL中創建自己的模塊。最後,shellcode跳轉到信標模塊的入口點,在內存中執行它。

如上所述,我們沒有辦法成功檢測我們的KoboldLoader示例的信標,除非我們可以在執行過程中查看內存內部。

MagnetLoader我們將研究的第二個加載程序是一個模仿合法庫的64位DLL。

SHA256:6c328aa7e903702358de31a388026652e82920109e7d34bb25acdc88f07a5e0

這個MagnetLoader示例試圖在一些方面看起來像Windows文件mscms.dll,通過使用以下類似的功能:

相同的文件描述;

一個具有許多相同函數名的導出表;

幾乎相同的資源;

一個非常相似的互斥鎖;

這些功能也顯示在下圖中,其中惡意軟件文件與有效的mscml.dll進行了對比。

5.png

MagnetLoader(左)和mscml.dll(右)的文件描述、導出表和資源的比較

MagnetLoader不僅嘗試靜態地模擬合法的Windows庫,而且在運行時也如此。

MagnetLoader的所有導出函數內部調用相同的主要惡意軟件例程。當調用其中一個時,首先運行DLL入口點。在入口點,惡意軟件加載原始的mscms.dll,並解析它所偽造的所有函數。

這些原始函數的地址在執行偽方法後被存儲和調用。因此,每當調用MagnetLoader的導出函數時,它都會運行主惡意軟件例程,然後調用mscms.dll中的原始函數。

主要的惡意軟件例程相對簡單。它首先創建了一個名為SM0:220:304:WilStaging_02_p1h的互斥體,看起來與mscms.dll創建的原始互斥體非常相似。

Cobalt Strike信標加載程序被解密到內存緩衝區中,並在一個已知的技巧的幫助下執行。加載程序沒有直接調用信標加載程序,而是使用Windows API函數EnumChildWindows來運行它。

該函數包含三個參數,其中一個是回調函數。惡意軟件可能濫用此參數,通過回調函數間接調用地址,從而隱藏執行流程。

LithiumLoader最後一個Cobalt Strike示例是DLL側加載鏈的一部分,其中使用了一種安全軟件的自定義安裝程序。 DLL側加載是一種劫持合法應用程序以運行獨立的惡意DLL的技術。

SHA256: 8129 bd45466c2676b248c08bb0efcd9ccc8b684abf3435e290fcf4739c0a439f

這個32位的LithiumLoader DLL是由攻擊者自定義創建的Fortinet VPN安裝包的一部分,該安裝包以FortiClientVPN_windows.exe (SHA256: a1239c93d43d657056e60f6694a73d9ae0fb304cb6c1b47ee2b38376ec21c786)的形式提交給VirusTotal。

FortiClientVPN_windows.exe文件不是惡意的或被破壞的。由於該文件是簽名的,攻擊者利用它來逃避反病毒檢測。

安裝程序是一個自解壓縮RAR存檔,包含以下文件:

6.png

FortiClientVPN_windows.exe文件內容

自解壓腳本命令如下:

7.png

自解壓腳本命令列表

當安裝程序運行時,所有文件都會被無聲地放到本地%AppData%文件夾中,兩個可執行文件都會啟動。當FortiClient VPN安裝程序執行時,WinGup工具側加載libcurl.dll LithiumLoader惡意軟件。惡意軟件之所以這樣做,是因為它從libcurl庫的合法副本中導入了以下函數,如下圖所示:

8.png

導入WinGup.exe的地址表

此威脅還試圖通過PowerShell將%AppData%文件夾路徑添加到Windows防禦器中的排除列表中。

在啟動GUP.exe時,惡意的libcurl.dll文件被加載到進程空間中,因為它靜態地導入上圖所示的函數。雖然所有四個libcurl函數都在運行,但只有curl_easy_cleanup包含在編譯庫的新版本時注入的惡意例程。因此,我們不是在處理合法DLL的打了補丁的版本。這是一種更乾淨的解決方案,不會像在其他惡意軟件中經常看到的那樣,在插入惡意程序後破壞代碼。

這個curl_easy_cleanup函數通常只包含一個子例程(Curl_close),並且沒有返回值(如其在GitHub上的源代碼所示)。修改後的函數如下圖所示。

9.png

修改了libcurl.dll的curl_easy_cleanup導出函數

load_shellcode函數通過XOR和密鑰0xA解密shellcode,如下圖所示。

10.png

Shellcode加載程序函數load_shellcode()

這個函數通過EnumSystemGeoID間接運行Cobalt Strike階段shellcode,而不是直接跳轉到它。這個Windows API函數有三個參數,最後一個參數是一個被LithiumLoader濫用的回調函數。

Cobalt Strike stagershellcode是從Metasploit借來的,是反向的HTTP外殼負載,它使用以下API函數:

11.png

shellcode連接到以下URL,其中包含泰國一所大學的IP地址

LithiumLoader檢測問題在本文發佈時,Cobalt Strike信標的有效負載已不再可用。如果API調用的執行報告中沒有有效負載或任何可操作的信息,沙盒通常很難確定樣本是否惡意。這個示例本身沒有任何可以被歸類為惡意的功能。

通過內存分析尋找Cobalt Strike在這三個例子中都存在一些常見的檢測挑戰。這些示例不能在正常的沙盒環境中執行。但是正如我們所討論的,如果我們在執行期間查看內存內部,就可以使用大量的信息進行檢測,比如函數指針、已解碼的加載程序階段和其他工件。

為了準確地檢測,研究人員發現解決高度規避惡意軟件的一個關鍵功能是,除了使用系統API更好地理解所發生的事情外,還需要在執行樣本時查看內存。

12.png

研究人員發現,在惡意軟件檢測中,查看執行關鍵點的內存增量,以提取有意義的信息和工件是很有用的。當我們的系統處理大量的樣本時,要實現大規模的工作有很多挑戰。接下來,我們將詳細介紹目前從內存中收集的一些主要類型的數據,以幫助檢測。儘管我們在本文介紹的是通過內存方法,但我們絕不是說檢測和記錄API調用對檢測沒有用。

自動有效負載提取如上所述,惡意軟件開發者混淆其有效負載越來越普遍。雖然使用可執行打包器可以壓縮和模糊文件來實現這一點並不新鮮,但當它與逃避策略結合使用時就會出現問題,因為沒有對準確檢測有用的靜態或動態數據。

編碼、壓縮、加密或下載額外的執行階段的策略有無限的組合。為這些有效負載製作簽名的能力顯然是分析師能夠從Cobalt Strike等框架中捕獲大量不同惡意軟件組件的重要方式。如果我們能在內存中捕捉到它們,那麼惡意軟件最終決定不執行也無所謂。

下面簡化圖顯示了我們可能在兩個階段中看到的示例,這些階段在初始可執行文件中從未出現過。

13.png

可以在打包的惡意軟件可執行文件中看到的典型階段

在圖的左側,我們看到了一個shellcode階段的示例。儘管“shellcode”一詞最初是為利用漏洞在目標系統上彈出外殼而手工製作的程序集而創造的,但該詞已演變為包含任何為惡意目的編寫的自定義程序集。一些惡意軟件階段是沒有可識別的可執行結構的自定義程序集。惡意軟件開發者採用這種方法的常見模式是將所有函數指針動態解析到一個表中,以便於訪問。

在圖的右側,我們看到後期是一個格式良好的可執行文件的示例。一些惡意軟件階段或有效負載是格式良好的可執行文件。這些可以由OS通過系統API加載,或者惡意軟件開發者可能會使用他們自己的PE加載程序,如果他們試圖隱蔽地避免調用任何API來為他們加載。

函數指針數據我們可以從內存中提取的另一組用於檢測的豐富數據是動態解析函數指針,如下圖所示。惡意軟件的開發者很久以前就知道,如果他們顯式地調用他們計劃在導入表中使用的所有WINAPI函數,它就會被用來對付他們。現在的標準做法是隱藏惡意軟件或其任何階段將使用的功能。

Shellcode哈希是另一種常見的隱蔽策略,用於解析函數的指針而不需要它們的字符串。

14.png

可能在內存段中看到的動態解析WINAPI指針示例

在Advanced WildFire中,我們已經開始有選擇地搜索和使用在我們的檢測邏輯中解析了哪些WINAPI函數指針的信息。

操作系統結構修改研究人員從分析內存中發現的另一個有用的檢測數據來源是尋找對Windows記賬結構的任何更改(惡意軟件開發者喜歡混淆這些!)。這些結構對於OS維護進程的狀態非常重要,例如加載了哪些庫、加載了可執行映像的位置以及OS稍後可能需要了解的進程的其他各種特徵。考慮到這些字段中的許多都不應該被修改,跟踪惡意軟件樣本何時以及如何操作它們通常很有用。

下圖顯示了示例如何從LDR模塊列表中卸載它加載的模塊。取消查找模塊意味著不再存在該模塊存在的記錄。例如,這樣做之後,Windows中的任務管理器將不再列出它。

此圖僅是研究人員所看到的許多不同的OS結構修改中的一種,但它表明有許多不同類型的OS結構更改對惡意軟件檢測問題有用。

15.png

如何將模塊從LDR模塊列表中解關聯的示例

頁面權限最後,檢測數據的另一個有用來源是對頁面權限所做的所有更改的完整日誌。打包惡意軟件的開發者通常需要更改內存權限,以便正確加載和執行進一步的階段。了解哪些內存頁的權限發生了更改,通常可以提供有關代碼加載和執行位置的重要見解,這對檢測非常有用。

總結儘管Cobalt Strike已經存在多年,但檢測它對許多安全軟件提供商來說仍然是一個挑戰。這是因為該工具主要在內存中工作,不太接觸磁盤。

本文介紹了三種新的加載程序,並展示瞭如何使用各種技術檢測它們,這些檢測技術在新的基於管理程序的沙盒中可用。

blog-header-845x321.png

利用面向公眾的服務是在網絡中獲得初步立足點的方法之一,這種情況在野外會經常看到。眾所周知,各種攻擊者都會濫用諸如緩衝區溢出(G0098)、SQL注入(G0087)或其他已知帶有功能利用代碼(G0016)的漏洞。

本文描述了一個HTTP請求走私(HRS)漏洞,這是我們在一次滲透測試中發現的。它可以用來模擬利用面向公眾的服務,同時在客戶的網絡中獲得初步立足點。在這個示例中,它允許我們獲取Active Directory憑據,從而用該憑據登錄到Outlook Web Access (OWA)查看敏感數據。

本文還會介紹如何通過將客戶端遷移到一個中間人Exchange服務器來獲得對OWA的持久訪問權。

HTTP請求走私HTTP請求走私(HRS)漏洞現在非常普遍。早在2005年,CGISecurity就發布了一份白皮書,詳細描述了漏洞是如何產生的,它會造成什麼後果,以及如何緩解它。如果你不確定HRS是如何工作的,我強烈建議你閱讀這篇白皮書或PortSwigger關於HRS的文章來熟悉一下。當網絡服務器和代理可以不同步時,就會出現HRS。攻擊者發送的請求在前端服務器和後端服務器上的解釋不同。例如,攻擊者發送一個特殊的請求,前端服務器將其解釋為1個請求,但後端服務器將其解釋為2個請求。第二個請求因此被“走私”通過前端服務器並最終到達後端服務器。正如PortSwigger 的James Kettle 所描述的,該請求的響應將被提供給下一位訪問者。

濫用HRS會極大地影響系統的保密性、完整性和可用性。正如一份負責任的披露中所公佈的,Evan Custodio 能夠通過濫用HRS 竊取cookie 來接管Slack 帳戶。其他示例包括New Relic上的憑據盜竊和美國國防部基礎設施上的用戶重定向。

在我們的例子中,HRS允許我們獲取Active Directory憑據,這將在下面的攻擊敘述中描述。這種攻擊敘述包含了從起初到最後的整個路徑。

識別代理基礎設施在一次滲透測試中,我們的目標是通過滲透客戶的數字基礎設施獲得初步立足點。由於自動掃描無法產生結果,我們很快進行了手動測試。包括Outlook Web Access (OWA) 在內的各種服務在使用GoBuster 工具對子域進行暴力破解時被識別。使用中的詞表由@bitquark 生成,包含100000 個最常用的子域。

1.png

在檢查這些服務時,我們發現我們正在與代理進行通信。有幾種方法可以檢測服務是否在代理之後運行。 Web 應用程序的一種常用技術是向應用程序發送以下請求,該請求的第一行包含另一個URI。

要求:

2.png

一般的web服務器會生成一個“421 Misdirected Request”響應。下麵包括一個示例。

響應:

3.png

然而,當我們在owa.customer.com上運行此操作時,服務器返回了以下響應,即302 Moved Temporarily。那時,我個人認為這種重定向是HTTP代理的典型行為。但是,後來我意識到它應該是帶有實際響應正文的200 OK 或203 Non-Authoritative Information,如RFC7230中所述。

響應:

4.png

但是,確實表明正在使用代理的是Server 標頭,其中server1 作為值。這是Microsoft IIS 服務器的非默認值。默認情況下,該值為Microsoft-IIS/8.5(或其他版本)。這表明,最有可能的是,代理更改了響應。

現在我們有了owa.customer.com被代理的跡象,我們可以繼續檢查它是否容易受到HRS的攻擊。

識別易受攻擊的代理設置考慮到James Kettle 的研究,我們著手調查這種設置是否可能容易受到HRS 的影響。為了確定owa.customer.com 是否容易受到HRS 的攻擊,我們發送了以下請求。

5.png

此請求的Content-Length 為124,即整個正文。它將被發佈到代理,代理將使用它來確定正文的長度為124 字節。然後將該請求轉發到實際的OWA 服務。

如果此設置易受HRS 攻擊,OWA 會以不同方式處理請求(使用分塊編碼而不是使用內容長度)。分塊編碼允許客戶端在正文中發送數據塊。在這種情況下,有一大塊數據。這是從十六進制數44開始的,如果轉換成十進制,就是68。這是塊的長度,可以在下一行中看到。在這68個字符之後,請求以一個大小為0的塊終止。這是OWA 接受的正常請求。

但是,終止後的部分未處理。 OWA 服務會將其視為代理(可能來自另一個用戶)發送的下一個請求的一部分。

這也適用於其他方式(如果代理使用分塊編碼而OWA 使用內容長度)。基礎設施易受HRS 攻擊的方式有多種。所有這些方式都在PortSwigger 的博客中進行了描述。實際上,我們使用的真正技巧是在傳輸編碼標頭之前插入了一個空格,Transfer-Encoding: chunked。雖然代理無法解析它並使用Content-Length 來確定正文長度。但是,OWA 能夠解析它並使用Transfer-Encoding 標頭來確定正文長度。

當我們執行上面的請求時,我們得到了來自服務器的以下響應。

6.png

可以看出,響應狀態為200 OK,表示我們的請求有效,服務器返回了有效響應。起初,我認為這意味著它沒有解釋我們正文的第二部分,因為它會產生一個400 Bad Request 響應狀態。我認為代理/OWA 設置很可能很容易受到攻擊。然而,經過進一步的研究,事實證明OWA 接受任何任意POST 數據。

更確定的驗證方法是在請求正文的第二部分檢查其他用戶是否收到了對我們請求的響應。由於我們正文第二部分中的請求通常返回301 Moved Permanently,因此現在應該將另一個用戶重定向到hacker.com 域,因為該用戶將重定向作為對他們請求的響應。為了驗證這一點,我們檢查了hacker.com的訪問日誌。它的重要部分已包含在下面。

7.png

事實上,事實證明它很脆弱!其中一位用戶被重定向到我們的hacker.com 域,這表明HRS 請求已成功執行。

查看訪問日誌,我認為發生了一些有趣的事情。在我看來,受害者實際上應該向hacker.com 的根或/owa 端點發出GET 請求,而不是向Microsoft-Server-ActiveSync 端點發出OPTIONS 請求,因為它被重定向了。但是,在查看RFC7231之後,很明顯接收到301 Moved Permanently 的客戶端可以為後續請求維護其請求方法和正文,就像308 Permanent Redirect 一樣,其中客戶端需要維護請求方法和主體。

總而言之,這意味著有可能從用戶那裡獲取更多信息,我們將在接下來的章節中介紹這些信息。

從hacker.com 的訪問日誌中可以看出,受害者試圖使用Microsoft-Server-ActiveSync 執行同步操作。 ActiveSync是一種HTTP 協議,它使用戶能夠從Exchange 服務器下載郵件,而不是使用僅使用戶能夠在Web 客戶端中查看郵件的OWA。

8.png

可以在各種郵件客戶端中配置ActiveSync,例如Apple Mail。正如Apple 連接到ActiveSync 端點的手冊中所見,用戶必須提供服務器、域、用戶名和密碼。這些詳細信息很可能會通過HTTP 請求發送到服務器。在配置期間或在每個請求中。

將憑據發送到服務器的時間實際上取決於在Exchange中配置的身份驗證類型。常見的身份驗證類型是“現代身份驗證”,它使用SAML協議,因此在使用用戶名和密碼進行初始身份驗證之後生成身份驗證令牌。身份驗證類型“基本身份驗證”是通過在每個HTTP請求中發送用戶名和密碼(base64編碼)進行身份驗證的一種方法。

如果Exchange 服務器配置為使用帶有基本身份驗證的ActiveSync,則用戶將在每個HTTP 請求中發送用戶名和密碼。由於我們能夠執行HRS,也許能夠截獲這些憑據!

盜取並使用憑據目前我們知道,一個成功的HRS攻擊可以將受害者重定向到一個惡意服務器,郵件客戶端維護請求方法,並且很可能還維護標頭和正文,並且我們還知道受害者在每個ActiveSync請求中發送base64編碼的憑據。這意味著我們馬上就要獲得這些證書了。

可以通過多種方式捕獲非法服務器上的請求標頭。為了進行概念驗證,我選擇使用Burp Collaborator,它充當HTTP和各種其他協議的所有捕獲服務器。

我更改了最初的HRS 請求,將受害者重定向到我的Burp Collaborator URI 而不是hacker.com。最後的請求包括在下面。

9.png

幾分鐘後,正如預期的那樣,Burp Collaborator捕獲了來自受害者的ActiveSync請求。

10.png

我們已經成功捕獲了包含受害者編碼憑據的授權標頭。

11.png

HRS攻擊如下圖所示。

12.png

將受害者的郵箱永久遷移到我們的非法交易服務器上

未記錄的功能作為滲透測試人員,我們想更深入地研究這一發現可能產生的影響。出於這個原因,我們從攻擊者的角度尋找進一步的選擇,其中最值得注意的是獲得對受害者憑據的永久訪問權限。事實證明,ActiveSync有一個功能,可以在用戶的郵箱從辦公場所遷移到Office365時自動更新郵件客戶端的配置。此功能的工作原理如下:

马云惹不起马云 客戶端嘗試通過HTTP ActiveSync 協議檢索郵件;

马云惹不起马云Exchange 會檢查用戶的郵箱是否存在或者是否遷移到Office365;

马云惹不起马云DC 返回未找到郵箱(這意味著已遷移);

马云惹不起马云Exchange 嘗試獲取域的TargetOWAURL(郵箱所在的位置);

马云惹不起马云DC 返回TargetOWAURL(在本例中為outlook.office365.com);

马云惹不起马云Exchange 使用一個HTTP 451重定向到TargetOWAURL來響應客戶端;

马云惹不起马云客戶端將TargetOWAURL 用於所有未來的請求;

马云惹不起马云對TargetOWAURL 的HTTP ActiveSync 請求成功。

13.png

總而言之,如果Exchange服務器以451 Unavailable For Legal Reasons和X-MS-Location標頭相結合的方式響應,則受害者Exchange服務器配置會相應更新。下文包括此類響應的示例。

14.png

但是,使用我們的HRS 攻擊無法為受害者生成451 Unavailable For Legal Causes。只能生成301 Moved Permanently,因為這是將URI 添加到GET 請求的第一行時的響應。但是,我們可以使用301 Moved Permanently 將受害者重定向到非法服務器,該服務器隨後以451 Unavailable For Legal Reasons 響應非法交換服務器。如果我們確保非法交換服務器只是合法環境的代理,我們可以永久地在所有受害者的ActiveSync 請求中間人,而受害者不會注意到任何事情。攻擊過程如下。

15.png

將受害者的郵箱遷移到我們的非法交易所為了證明上述理論有效,我們將“受害者”(tgad.local\bob)連接到我們的演示環境;代理tgvmex01.proxy 後面的Exchange 服務器。 Bob 使用ActiveSync 連接。他的iOS Exchange 配置如下所示。

16.png

想要將Bob的郵箱遷移到非法交換服務器的攻擊者需要首先執行HRS攻擊,將Bob的ActiveSync請求重定向到非法服務器。下面提供了一個示例。

17.png

無論請求是什麼,服務器rogue-server.com 始終提供相同的響應。此響應包含在下面,並且響應標頭中的非法交換服務器具有451 Unavailable For Legal Reasons 狀態。

18.png

當Bob 成為HRS 攻擊的受害者時,他將收到非法服務器的451 Unavailable For Legal Reasons 響應。 Bob 的電子郵件客戶端會將服務器地址更改為rogue-exchange.remote,因為響應表明郵箱遷移到了這個Exchange 服務器。

最初的幾次嘗試都沒有成功。但是在連續嘗試了幾次之後,HRS攻擊最終觸發了Bob的同步請求,導致Bob的郵件客戶端將配置更改為非法交換。這可以在下面的Bob的Exchange設置中看到。

19.png

由於惡意交換器將所有請求代理給合法交換器,Bob不會注意到惡意配置更改(除非他查看自己的exchange設置)。作為一個攻擊者,我們現在能夠攔截他的所有ActiveSync請求,即使在Bob更改了他的憑據之後。

緩解措施存在多種針對HRS 漏洞的緩解措施。在理想情況下,代理服務器和後端服務器(在本例中為Exchange)都完全按照RFC7231中的說明解釋HTTP 請求。這將防止HRS 漏洞,因為兩個服務器都以相同的方式解釋HTTP 請求的邊界。

然而,我們並不是生活在一個理想的世界裡。更好的緩解措施是禁用代理和後端之間的http-reuse(一種性能優化),以便每個請求都通過單獨的網絡連接發送。此外,可以通過強制從代理到後端的HTTP/2 連接來緩解HRS,因為此版本的HTTP 協議中不會出現HRS 漏洞。

最後,我們強烈建議不要將基本身份驗證用作Exchange 的身份驗證方法。請改用現代身份驗證。使用現代身份驗證,攻擊者只能攔截oAuth令牌。

如果你認為自己是Exchange遭受HRS攻擊的受害者,請主動重置Exchange客戶端的配置和密碼。

去年年底,研究人員在HackerOne上發現了一個極具挑戰性的漏洞,該漏洞涉及多個層面的利用,最終導致存儲的XSS有效負載能夠接管受害者的帳戶,該漏洞的危害性極強(CVSS 8.7)。 HackerOne 是排名第一的黑客驅動安全平台,可幫助你在被利用之前發現並修復關鍵漏洞,HackerOne正在阻止他們提取漏洞賞金,甚至有人被截留了數千美元。

設置過程我發現最初的漏洞與HackerOne的支付處理API有關,客戶(商家)使用它來處理不同國家的信用卡和金融交易。這個品牌是跨國的,所以他們在許多不同的國家處理許多不同類型的交易。該支付處理器支持的一種交易類型是離線支付流,用於處理信用卡不流行、現金交易更普遍的地區。在這些地方,支付處理器允許客戶進行電子商務購買,並獲得一個唯一的代碼(如二維碼),他們可以將其帶入商店並為交易支付現金。一旦商店確認交易,電子商務商家就會收到貨款,顧客就會收到貨物。

具體流程是這樣的:

马云惹不起马云當客戶下訂單時,電子商務商家啟動離線支付流程;

马云惹不起马云電子商務商家為客戶提供一個可用於支付的唯一店內代碼;

马云惹不起马云(離線)客戶將代碼帶到支付網絡中的商店並用現金支付;

马云惹不起马云電子商務商家收到付款通知;

马云惹不起马云電子商務商家向客戶發送一個唯一的URL,他們可以訪問該URL來確認購買。

马云惹不起马云 請注意,最後一步中的“唯一URL”是由商家在交易設置時提供的,你可以將其視為傳統在線信用卡工作流中的“確認URL”。

有效負載在這種情況下,攻擊者是有能力創建這些離線交易的商家(或該商家的用戶)。商家將提交一個包含XSS有效負載的確認URL。這種有效負載一旦持久化,就可以在主網站(www.redated.com)的頁面下看到。

商家通過GraphQL API在不同的域名payments.redactedtwo.com上提交請求,該域名的有效負載如下:

1.png

我們可以看到,這個GraphQL API接受一個returnUrl參數,該參數將成為我們的有效負載源。請注意,GraphQL調用是一個完全獨立的頂級域上的API。這很有趣,因為它允許在一個域中存儲的有效負載會在另一個更關鍵的域中呈現。提交後,我們可以訪問www.redected.com網站上的一個唯一的靜態URL,該URL在returnUrl參數中包含我們的有效負載。

讓我們看看負載是如何出現在www.redacted.com上的:

2.png

我們看到這個腳本有一個nonce,注入點payload 在腳本中看起來像是一個非常容易存儲的XSS。

nonce的存在將變得很重要,讓我們看一下Content-Security-Policy標頭。為了便於閱讀,我將它分成幾行:

3.png

我們可以看到,這個CSP是相當嚴格的,我們只能從網站本身獲取信息,並且頁面上的任何腳本標籤都需要nonce。

嘗試1:javascript://url顯然,在位置.href=處使用注入點的第一次嘗試是簡單地放置一個帶有有效負載的Javascript方案,例如Javascript://alert(1)。我很幸運,因為這裡沒有明顯的WAF阻擋像這樣簡單的有效負載。不過嘗試失敗了,GraphQL API拒絕了該URL,出現的錯誤為400。我嘗試了很多其他的嘗試,比如編碼等都不行。 API正在驗證提供的URL是否以https://開頭,並包含後跟/的完整主機名。所以很明顯,我們有一個開放的重定向,但我知道這可能被用於存儲的XSS。

例如https://hackerone.com/將導致以下存儲的有效負載:

4.png

這些是附加到GraphQL API中提供的URL的參數,代表唯一的事務ID,關於客戶的信息等-這總是附加一個前導?在單引號內。

出於顯而易見的原因,我嘗試提交各種形式的不帶尾斜杠的https://URL,這將導致主機名之後的所有內容都被URL編碼,並且通常對Javascript上下文中的XSS無用。

嘗試2:附加有效負載現在,我們知道負載必須以有效的URL和主機名開始,因此我們以https://hackerone.com/作為負載的開頭。

幸運的是,我能想到的下一個最明顯的有效負載奏效了。單引號字符沒有以任何方式被阻止或編碼,因此以下負載實際上生成了一個存儲的警報:

5.png

這生成了一個警報,但當關閉時,用戶會立即重定向到提供的URL。已存儲帶有DOM訪問的XSS負載!

提交此時,嘗試已經成功,研究人員已向LHE提交了該漏洞。不過該團隊回應說,他們覺得CSP和cookie設置在主站點上,不可能將存儲的XSS升級到高嚴重性漏洞。

研究人員覺得不合理,因為有效負載位於script nonce 環境中,攻擊者可以生成想要的任何有效負載,利用它將很容易!

構建ATO有效負載研究人員製作了想像到的最好的存儲XSS ATO有效負載。有效負載執行了以下任務,他們在主站點上打開的窗口的開發控制台(F12)中測試了這些任務:

通過對站點主頁執行XMLHttpRequest,為用戶獲取CSRF令牌;

通過解析從fetch調用返回的HTML提取CSRF令牌;

使用XMLHttpRequest進行API調用以更改帳戶上的電子郵件地址;

請注意,CSP中的connect-src使你無法嘗試使用Javascript將頁面中的信息洩露到攻擊者域,因此ATO或CSRF的類似行為是我在此處選擇的有效負載。

此時,攻擊者可以控制電子郵件地址並使用“忘記密碼”功能來完成接管,從而獲取該帳戶。 Cookie(甚至是HttpOnly)將在最後一次請求時發送,因為同源策略將允許包含它們(XHR來源於正確的域,www.redated.com)。

大多數人都熟悉編寫這種類型的有效負載,我不會在這裡詳細介紹,因為它非常簡單:

通过GraphQL API把XSS存储到Account Takeover (ATO)

我在Chrome開發控制台中測試了這一點,並確認它具有ATO的預期效果。

嘗試3:拒絕我向GraphQL API提交了有效負載,它看起來很好!一開始沒有錯誤,但後來我點擊了存儲的XSS頁面本身,看到存儲的有效負載未呈現。

通过GraphQL API把XSS存储到Account Takeover (ATO)

回到原來的alert(document.domain)有效負載,它開始運行了。所以,在我完整的ATO有效負載中一定有什麼東西導致服務器不渲染XSS。

在對工作負載進行多次迭代之後,不幸的是,由於源和接收是不同的事務,並且需要幾個中間步驟,我無法使用任何方便的自動化工具,我發現以下所有字符都會導致400錯誤:

通过GraphQL API把XSS存储到Account Takeover (ATO)

請注意,所有空白字符也被拒絕。可能還有其他我不記得內容了,但以下內容肯定沒有被阻止:

通过GraphQL API把XSS存储到Account Takeover (ATO)

現在,有一個有限的Javascript詞彙表要處理。

嘗試4:異步研究人員最終重寫了大部分有效負載,以排除受限制的字符。請注意,我嘗試了所有類型的編碼(URL、javascript、十六進制、八進制、雙重編碼等),但這些都不能用來繞過限制。該過程是非常乏味的,因為錯誤出現在接收端,而不是源端,所以每次迭代至少浪費一到兩分鐘。

我甚至得到了使用受限字符集的初始獲取請求,比如:

通过GraphQL API把XSS存储到Account Takeover (ATO)

現在,我們可以在控制台日誌中看到fetch調用中的Response對象。

請記住,我的攻擊鏈需要3個步驟:

马云惹不起马云進行XHR調用以獲取帶有CSRF令牌的頁面;

马云惹不起马云從返回的HTML中提取CSRF令牌;

马云惹不起马云 用CSRF令牌對ATO進行XHR調用;

由於fetch和XMLHttpRequest是異步API,我們需要用lambda函數填充then方法參數,該函數將在Promise解析時異步執行。問題是,如果沒有{}字符,我不相信有一種方法可以在Javascript中構建lambda函數,無論是用大括號語法還是箭頭語法。

研究人員立刻意識到這是一個巨大的障礙。即使我重寫了負載的其餘部分以避免所有這些其他字符,也無法定義Promise解析時要調用的lambda函數。不過在Javascript引用中Function對象的文檔中,有一個形式Function(var, body),其中body是字符串!不需要大括號或箭頭語法!

在重寫有效負載時,研究人員卻發現在CSP中遺漏了一些東西,由於CSP缺少不安全的eval指令,因此不允許使用eval。沒錯,這種形式的Function構造函數使用eval將字符串轉換為實際的Javascript函數。

所以解決問題的方法有以下三種:

马云惹不起马云要成功傳遞工作負載,就需要繞過被阻止的特殊字符;

马云惹不起马云研究人員確信他們可以執行任意的Javascript代碼,只要注意使用的字符即可;

马云惹不起马云可以訪問DOM中已經存在的script 標記上的nonce的正確值;

於是研究人員決定嘗試以下方法:

马云惹不起马云使用非常簡單的Javascript創建一個新的script DOM節點;

马云惹不起马云將該腳本節點上的nonce設置為與頁面上已存在的script 節點的nonce匹配;

马云惹不起马云想出一種方法來編碼負載,這樣就可以將新script 節點的innerText設置為一個沒有特殊字符的值;

马云惹不起马云將新script 標記插入DOM,有效負載將執行。

有趣的是,如果script 標記已經開始執行(頁面上的一個標記),那麼替換innerText將毫無作用。由於CSP,研究人員看不到除了帶有nonce的script 標記之外的任何方法來執行負載。

但是,如果頁面尚未完成內聯腳本的呈現和執行,則可以在內聯腳本之後插入一個新的script 節點,該節點將執行。請注意,這僅在頁面尚未加載的情況下有效。如果你試圖在onload事件觸發後插入一個script DOM節點,那就太晚了。

我決定用一個看起來像以下這樣的簡單有效負載來嘗試:

通过GraphQL API把XSS存储到Account Takeover (ATO)

嘗試成功了!警報彈出,並且新標記上的nonce的存在允許我的腳本通過CSP檢查。

嘗試5:迴避特殊字符如果試圖只對那些被阻止的字符進行編碼,則很難手動完成。因此,研究人員決定採取以下方法:

马云惹不起马云用Javascript有效負載創建一個文件redacted_payload.txt;

马云惹不起马云運行以下shell命令,將文件中的每個字符編碼為對String.fromCharCode的一系列調用;

生成的shell命令:

通过GraphQL API把XSS存储到Account Takeover (ATO)

輸出:

通过GraphQL API把XSS存储到Account Takeover (ATO)

研究人員在花費了大量時間後,最終得到了一個非常大的負載,幸運的是,可以存儲的URL沒有長度限制!

研究人員提交了完整的有效負載,如下所示:

通过GraphQL API把XSS存储到Account Takeover (ATO)

但沒有成功,這讓研究人員想起了一些原來被忽略的事情。

最後一步:重定向注意,我們正在註入的內聯腳本是通過設置location.href屬性重定向窗口開始的。這會導致瀏覽器開始導航,此時,它可能不會完成任何進一步的內聯腳本的執行,而且它肯定不會等待異步Promise完成,例如XHR或fetch。可以看到的是,編碼負載正在運行,但瀏覽器會立即導航離開頁面,整個過程沒有機會完成。

還要記住,重定向必須以合法的主機名開始,因此不可能提供瀏覽器無法導航到的無效重定向。

為了防止系統升級造成的影響,研究人員控制了關於location.href在設置時的行為的Javascript參考,這樣研究人員就看到了window.stop(),它被記錄為“aborts browser naviagtion(中止瀏覽器導航)”。這看起來像嘗試成功了,所以在URL字符串結束後研究人員立即添加了一個調用,如下所示:

通过GraphQL API把XSS存储到Account Takeover (ATO)

這已經達到了阻止重定向的預期效果!

不過,這也停止了任何未完成的獲取或XHR請求,且恢復方法很複雜。

為了解決這個問題,研究人員想知道是否再次將location.href設置為其他內容,如果速度足夠快,第二個賦值是否會覆蓋第一個導航。起初,研究人員嘗試使用javascript:URL(這太容易了),最終發現URL foo://a會使瀏覽器的行為與預期的完全一樣:

停止導航到合法URL;

生成錯誤;

允許繼續執行進一步的XHR/fetch請求;

最後的有效負載如下所示:

通过GraphQL API把XSS存储到Account Takeover (ATO)

最終,研究人員向ATO提交了有效負載以及成功存儲XSS的證據。

結論在所有保護措施到位的情況下,實現這種升級簡直不可思議。

本文所用的技巧如下:

當開箱即用的有效負載不起作用時,熟悉Javascript語言和語法會非常有幫助;

熟悉這門語言還能幫助你更好地處理特殊字符等主要障礙;

封面图.jpg

1 概覽近期,安天CERT監測到通過GitHub傳播竊密木馬的攻擊活動。攻擊者在其發布項目的環境依賴文件requirements.txt中添加惡意URL,以獲取其惡意篡改的流行開源模塊,從而在受害者電腦中植入竊密木馬。

攻擊者使用空格將惡意代碼掩藏在該行代碼的末尾,以避免被用戶察覺;並使用多種手段對惡意代碼進行混淆處理,以規避安全產品檢測、阻礙安全人員分析。經過多層腳本載荷的傳遞後,將執行一種由Python編寫的竊密木馬。該竊密木馬會在受害主機中竊取瀏覽器、社交平台、加密貨幣錢包、遊戲客戶端中的敏感信息,並針對目標路徑中匹配關鍵詞的文件夾及文件進行竊取,最終將竊密數據回傳至C2服務器或上傳至文件共享平台Gofile中。

在此次攻擊活動中,攻擊者在自己發布的項目中引入經過惡意篡改的流行開源模塊,從而傳播竊密木馬。對流行的開源項目進行篡改,在其中添加惡意代碼後重新打包並在發布的項目中進行惡意引用,已經成為一種攻擊方式,用戶很難察覺環境依賴文件中是否存在異常。用戶在使用網絡中非流行、未證實安全性的開源項目時也需保持警惕,以避免執行掩藏在其中的惡意代碼。

經驗證,安天智甲終端防禦系統(簡稱IEP)可實現對該竊密木馬的有效查殺。 2 技術梳理攻擊者在GitHub中上傳項目,並在環境依賴文件requirements.txt中添加惡意URL。當用戶使用該項目時,需要根據該文件中的內容進行配置,從而下載執行經過攻擊者惡意篡改的colorama模塊。

攻擊者添加的惡意代碼用於從其服務器中獲取“version”文件,該文件使用Fernet算法進行加解密,執行後獲取“inj”文件並寫入臨時文件中;“inj”文件經過混淆處理,通過zlib對代碼進行解壓;解壓後的代碼用於獲取最終的竊密木馬,通過註冊表實現持久化,並向C2服務器回傳受害主機的用戶名稱、IP信息等基本數據。

該竊密木馬會竊取指定瀏覽器、社交平台、加密貨幣錢包、遊戲客戶端中的敏感數據,並對目標路徑中含有關鍵詞的文件夾中的文件(最多7個)、以及含有關鍵詞且大小小於500000字節(約488KiB)的文件進行竊取。完成竊密行為後,竊密木馬通過HTTP POST方式將竊密數據回傳至C2服務器中。當第一種回傳方式出錯時,該竊密木馬會將竊取的數據上傳至文件共享平台Gofile。

图 2-1攻击流程图.png

圖2‑1攻擊流程圖

3 關聯分析此次發現的惡意GitHub項目是“Discord-Token-Generator”,最早於2024年1月份創建。

图 3-1恶意GitHub项目.png

圖3‑1惡意GitHub項目

該項目的環境依賴文件requirements.txt中包含一個託管colorama-0.4.6.tar.gz的URL。攻擊者對域名進行了偽裝,在流行開源模塊colorama-0.4.6中添加了惡意代碼,並進行重新打包。

图 3-2恶意Github项目中的requirements.txt文件.png

圖3‑2惡意Github項目中的requirements.txt文件

根據requirements.txt文件中發現的惡意域名,目前在GitHub中有多個項目引用了經過攻擊者惡意篡改的模塊,相關賬號可能都是由同一批攻擊者所創建。

图 3-3引用经过攻击者恶意篡改模块的相关GitHub项目.png

圖3‑3引用經過攻擊者惡意篡改模塊的相關GitHub項目

攻擊者用於託管載荷的域名於2024年2月份註冊,表明這是一起剛開始進行的攻擊活動。

图 3-4攻击者使用域名的注册时间.png

圖3‑4攻擊者使用域名的註冊時間

在多個惡意GitHub項目中存在攻擊者修改requirements.txt文件的痕跡。分析時已無法獲取到該URL中的colorama-0.4.3.tar.gz,不能判斷該文件是否惡意。

图 3-5攻击者修改requirements.txt的痕迹.png

圖3‑5攻擊者修改requirements.txt的痕跡

此外,在竊密木馬文件中存在多處葡萄牙語痕跡,表明攻擊者可能位於葡語系國家或地區。

图 3-6攻击者在窃密木马文件中使用葡萄牙语进行输出.png

圖3‑6攻擊者在竊密木馬文件中使用葡萄牙語進行輸出

竊密木馬竊取文件的關鍵詞列表中存在幾處法語,表明攻擊者可能更加針對法語用戶。

图 3-7窃密文件中的法语痕迹.png

圖3‑7竊密文件中的法語痕跡

4 樣本分析4.1 經過攻擊者篡改的colorama模塊colorama是一個開源的Python模塊,能夠提供彩色的終端文本。攻擊者在其__init__.py文件中,通過463個空格將惡意代碼掩藏在第5行末尾,然後將篡改的colorama模塊重新打包並託管於搭建的服務器中。由於__init__.py文件用於定義包的初始化代碼,因此當用戶導入該包時會自動執行其中的惡意代碼。該惡意代碼用於從攻擊者服務器中接收“version”文件中的內容並執行。

图 4-1攻击者掩藏的恶意代码.png

圖4‑1攻擊者掩藏的惡意代碼

4.2 version“version”文件中的代碼使用Fernet算法,通過攻擊者自定義的密鑰對代碼進行解密,然後對解密的代碼進行執行。

图 4-2执行通过Fernet算法进行加解密的代码.png

圖4‑2執行通過Fernet算法進行加解密的代碼

解密後的代碼訪問指定的URL,將“inj”文件內容寫入臨時文件中,並通過python執行。

图 4-3获取“inj”文件内容并执行.png

圖4‑3獲取“inj”文件內容並執行

4.3 inj該文件是一個Python腳本,攻擊者使用中文、日文對變量及函數等進行命名,並且對代碼進行了混淆處理。

图 4-4 inj文件内容.png

圖4‑4 inj文件內容

攻擊者同樣通過空格對關鍵代碼進行掩藏,經解混淆處理後發現,該腳本的作用是使用zlib解壓出下一階段的代碼並進行執行。

图 4-5经过zlib压缩的代码.png

圖4‑5經過zlib壓縮的代碼

4.4 經過zlib解壓的代碼該代碼使用Python編寫,其作用是在%APPDATA、%LOCALAPPDATA%、%TEMP%中選取一個目錄生成一個隨機名稱的文件,將從指定URL中獲取的內容寫入該文件中執行,通過註冊表實現持久化,並向C2服務器回傳受害主機的用戶名稱、IP信息等數據。

图 4-6该代码的作用.png

圖4‑6該代碼的作用

4.5 竊密木馬4.5.1 竊密經過以上多層載荷的傳遞,最終將執行一種使用Python編寫的竊密木馬。其竊密目標如下表所示。

表4‑1竊密目標

瀏覽器

Opera

Chrome

Brave

Vivaldi

Edge

Yandex

Firefox

社交平台

Discord

Telegram

加密貨幣錢包

Atomic Wallet

Guarda

Zcash

Armory

Bytecoin

Exodus

Binance

Jaxx

Electrum

Coinomi

遊戲客戶端

Steam

Riot Client

該竊密木馬也會對目標路徑中含有關鍵詞的文件夾中的文件(最多7個)、以及含有關鍵詞且大小小於500000字節(約488KiB)的文件進行竊取。目標路徑及關鍵詞如下表所示。

表4‑2目標路徑及關鍵詞

目標路徑

桌面

下載

文件

最近使用的項目

關鍵詞

passw

mdp

motdepasse

mot_de_passe

login

secret

bot

atomic

account

acount

paypal

banque

bot

metamask

wallet

crypto

exodus

ledger

trezor

hardware

cold

.dat

discord

2fa

code

memo

compte

to0k3en

backup

secret

seed

mnemonic

memoric

private

key

passphrase

pass

phrase

steal

bank

info

casino

prv

privé

prive

telegram

identifiant

personnel

trading

bitcoin

sauvegarde

funds

récupé

recup

note

4.5.2 回傳該竊密木馬通過HTTP POST將竊取的數據回傳至C2服務器中。

图 4-7 HTTP POST回传方式.png

圖4‑7 HTTP POST回傳方式

當該回傳方式出錯時,該竊密木馬會將竊取的數據上傳至文件共享平台Gofile,並將上傳後形成的下載鏈接記錄在“loggrab”文件中回傳至C2服務器。

图 4-8将数据上传至Gofile.png

圖4‑8將數據上傳至Gofile

5 防護建議5.1 加強終端文件接收和執行防護建議企業用戶部署專業的終端安全防護產品,對本地新增和啟動文件進行實時檢測,並週期性進行網內病毒掃描。安天智甲終端安全系列產品(以下簡稱“智甲”)依托安天自研威脅檢測引擎和內核級主動防禦能力,可以有效查殺本次發現病毒樣本。

智甲可對本地磁盤進行實時監測,對新增文件自動化進行病毒檢測,對發現病毒可在其落地時第一時間發送告警並進行處置,避免惡意代碼啟動。

图 5-1发现病毒时,智甲第一时间捕获并发送告警.png

圖5‑1發現病毒時,智甲第一時間捕獲並發送告警

智甲還為用戶提供統一管理平台,管理員可通過平台集中查看網內威脅事件詳情,並批量進行處置,提高終端安全運維效率。

图 5-2通过智甲管理中心查看并完成威胁事件处置.png

圖5‑2通過智甲管理中心查看並完成威脅事件處置

6 IoCsIoCs

96B4C32AFE965529510A6430C2A7AAD3

150B3626C85EC5AF88B86C0D0E24736B

6580C4990E1E56A7D31A36FF1A0502FA

DD9914573C751C4D8BE4BFE0519F9597

6573627FFC97CA6E82A238561C14A9E4

https[:]//files.pypihosted.org/packages/d8/53/6f443c9a4a8358a93a6792e2acffb9d9d5cb0a5cfd8802644b7b1c9a02e4/colorama-0.4.6.tar.gz

https[:]//pypihosted.org

162.248.100[.]217

Unit 42研究人員調查了Azure的無服務器架構,發現他們能夠破壞底層主機的無服務器函數。研究人員還發現,他們的主機實際上是一個HyperV虛擬機,它託管了其他幾個無服務器函數。 Hyper-V是微軟的一款虛擬化產品,是微軟第一個採用類似Vmware ESXi和Citrix Xen的基於hypervisor的技術。

Azure serverless functions(通常稱為Azure Functions)是一種無服務器解決方案,可以使用戶減少代碼編寫、減少需要維護的基礎結構並節省成本。無需擔心部署和維護服務器,雲基礎結構提供保持應用程序運行所需的所有最新資源。你可以專注於使用你認為最高效的語言編寫最重要的代碼,而Azure Functions 處理其餘代碼。作為一個基於觸發器的服務,它運行代碼以響應各種事件。在本文中,這個事件是一個網頁請求。

研究人員發現,對於每個函數,主機都會生成一個新的容器。每個容器將在幾分鐘後終止並刪除,以將無服務器函數與傳統的容器即服務區分開來。

問題主機只託管研究的Azure用戶有權訪問的函數,因此不會造成真正的攻擊。很明顯,微軟竭盡全力阻止人們訪問主機,因此可能還有其他問題尚未被發現。虛擬機上可能有不應該顯示的重要信息,這些信息可能會被動機充分的攻擊者發現。

微軟經常使用容器來加強安全性,但由於容器本質上不如虛擬機那樣安全,因此通常不會將其視為安全邊界。在本文的示例中,他們實現了額外的安全層,這被證明是有效的。

Prisma的無服務器解決方案為大多數雲提供商提供了函數發現和漏洞掃描功能。這些功能會作用於無服務器函數上,並在發現這些函數中存在已知漏洞時提醒你。

什麼是無服務器函數無服務器函數是無服務器計算(通常簡稱為“無服務器”)的一個特點,雲提供商按需為其客戶提供所有計算資源,並管理所有架構,包括雲基礎設施。

無服務器理想應用程序的一個很好的例子是聊天機器人。例如,Slack使用名為marbot的無服務器應用程序通過Slack向DevOps團隊發送通知。

“serverless”這個名字有點誤導人。不管它的名字意味著什麼,無服務器計算仍然需要物理服務器來執行代碼。與傳統計算的主要區別在於,無服務器抽象了與代碼本身無關的任何東西,從代碼運行的操作系統到實際運行代碼的設備硬件。

無服務器函數的內部結構你可能會問自己的第一個問題是如何開始研究無服務器平台。任何使用過Azure Serverless Functions的人都知道,可研究的地方不是很多。你可以上傳一些代碼或更改一些設置,如下圖所示,但僅此而已。

2.png

通過Azure函數提供的所有不同運行時

研究人員決定從一個HTTP請求觸發的Linux上的Python函數開始研究,對於某些運行時,Windows也可用。

下一步是在函數中獲得一個有效的交互式shell,以更好地理解研究人員正在處理的內容,並獲得有關運行代碼的設備的一些信息。為了便於使用,研究人員決定使用逆向shell。研究人員還決定使用數據傳輸工具socat而不是netcat,因為它支持更廣泛的協議。

3.png

研究人員使用的socat二進製文件

研究人員只是將socat二進製文件放在Visual Studio代碼中的項目目錄中,並將整個文件部署到研究人員之前創建的無服務器函數中。實際啟動逆向shell的代碼非常簡單,因為整個邏輯都在socat應用程序中,如下圖所示。

4.png

連接到逆向shell偵聽器的簡單函數代碼

執行逆向shell後,研究人員進入了一個名為app的用戶下的函數目錄。研究人員使用

cat/proc/1/cgroup_last_cap命令,以SandboxHost開頭的設備主機名也暗示了這一點。

5.png

無服務器函數內部的shell

在研究人員登錄的工作目錄中沒有太有趣的東西。這個目錄包括他們上傳的所有文件,外加一個額外的lib文件夾,其中包含Python與Azure通信所需的庫。

容器這項研究一開始並沒有明確的目標,只是為了改善Prisma的無服務器保護。然而,在了解了更多關於架構的知識後,研究人員渴望探索一下容器。

在熟悉了容器及其文件以及用戶權限等之後,研究人員決定檢查環境變量,因為它們通常包含一些有趣的信息。這一次沒有什麼不同。在其他有趣的事情中,研究人員注意到環境變量洩露了映像名稱。

6.png

環境變量中的映像名稱

在網上搜索這個映像名稱,研究人員找到了一個顯示映像名稱的微軟官方目錄,該目錄指向一個提供所有Microsoft映像(包括我們正在查看的映像)的官方存儲庫。

研究人員的第一個方法是獲取映像“源代碼”(如果你使用Docker,則為Dockerfile)。經過一番搜索,研究人員發現有一個叫做Whaler的實用工具,它可以將Docker映像逆向工程到創建它們的Dockerfile中。該過程如下所示。

7.png

使用Whaler對微軟映像進行逆向工程

Whaler有大量的映像,從而產生一個易於使用的單行命令。使用這個方法,研究人員成功地生成了一個足夠好的Dockerfile版本,如下圖所示。文件中最有趣的部分是最後一行。

8.png

逆向之後的Dockerfile版本

網格文件夾似乎包含一些有趣的文件,特別是launch.sh腳本,它似乎是容器內執行的第一件事。此時,研究人員只需從映像內部複製整個網格文件夾,以進一步研究它。

還有一些腳本在不同的場景中調用了一些其他腳本,該文件夾中有趣的部分是一個名為init的二進製文件,它在每個Azure無服務器容器的後台運行。對研究人員來說幸運的是,這個二進製文件也包含了符號,所以逆向工程很容易。

在研究了函數和字符串列表之後,有一個函數特別有趣:init_server_pkg_mount_BindMount。在對其進行逆向工程之後,研究人員發現該函數將容器內的一條路徑綁定到另一條路徑,該路徑也位於容器內。此函數也不要求用戶具有特權,但它在root上下文中運行!要將一個文件綁定到任何其他文件,你所需要做的就是在容器中使用正確的參數在正確的端口上執行HTTP查詢。

9.png

init_server_pkg_mount_BindMount函數簽名

10.png

init_server_pkg_mount_BindMount函數解析來自HTTP請求的sourcePath和targetPath

在這部分調查的過程中,研究人員還發現了許多關於Azure無服務器架構如何在幕後工作的信息。雖然這超出了本文的範圍,但可以在本文中深入探討這一問題。

升級權限簡而言之,雖然在一個沒有特權的用戶的容器中研究,但研究人員能夠將任何一個文件作為根文件綁定到任何其他文件。此時,研究人員的目標是在容器內將特權升級到根權限。可能有幾種方法可以實現這一點,但研究人員選擇用生成的文件替換/etc/shadow文件,然後將用戶更改為root。

11.png

使用OpenSSL生成/etc/shadow

為了實現這一點,研究人員執行了以下步驟:

為root用戶生成一個密碼已知的/etc/shadow文件;

將該文件上傳到Function容器的本地目錄;

使用正在運行的init服務和BindMount函數通過查詢http://localhost:6060將本地陰影文件綁定到實際的/etc/shadow文件;

使用su-root命令將用戶更改為root。

12.png

不斷升級權限

利用root權限規避容器可以利用新獲得的根訪問來規避容器,通過研究,研究人員選擇了菲利克斯马云惹不起马云威廉姆(Felix Wilhelm)多年前發現的一個舊漏洞。

不過要使用此漏洞也不是一件簡單的事情,要使其正常工作,需要滿足以下幾個要求:

研究人員必須在容器內以root身份運行;

容器需要具有SYS_ADMIN函數;

容器要么沒有AppArmor配置文件,要么允許掛載系統調用;

cgroup v1虛擬文件系統必須在容器內以讀寫方式安裝;

研究人員已經在早些時候實現了第一個需求。令人驚訝的是,其餘的需求在我們的容器中也可用。這是令人驚訝的,因為在默認情況下,容器啟動時具有一組受限的函數,並且沒有啟用SYS_ADMIN函數。此外,Docker通常在默認情況下使用AppArmor策略啟動容器,這防止了在容器使用SYS_ADMIN運行時使用mount sycall。通過在/proc/PID/status下的shell狀態文件上運行capsh命令,研究人員確認了所有必要的函數,如下圖所示。

14.png

使用capsh和一些sed腳本來打印特權用戶函數

關於此漏洞的詳細解釋已超出了本文範圍,我們建議閱讀'Digging into cgroups Escape' 以更好地理解此技術。簡而言之,研究人員將通過以下步驟描述該漏洞:

查找或創建對cgroup控制器的訪問權限(大多數版本的漏洞利用使用RDMA);

在該控制器中創建一個新的cgroup;

將該cgroup的notify_on_release設置為1;

將發布代理設置為容器和主機都可以訪問的文件;

在該cgroup中啟動一個快速完成流程,該流程將在終止時觸發發布代理的執行。

研究人員決定通過運行ps aux並將其與容器的ps aux進行比較來演示實現主機執行上下文。在本節開頭的視頻中,你可以看到漏洞的整個利用過程。需要注意的是,託管容器的設備是HyperV虛擬機,而不是物理服務器。

總結不管怎樣,Azure的用戶都可以訪問虛擬機託管的所有資源,因此,這種防禦沒有什麼意義。這是雲提供商緩解措施按預期工作的一個示例。在本文的示例中,他們選擇不依賴容器作為安全邊界,並實現另一種保護,這被證明是一個聰明的舉動。

但是,如果在虛擬機本身中發現另一個漏洞,這個漏洞可能會產生巨大的影響。此外,微軟在過去已經修復了類似的問題,即使他們本身沒有將其稱為漏洞。

虛擬機可能包含對無服務器函數用戶或可能的攻擊者不可見的重要信息或秘密。在與微軟分享該調查結果後,他們考慮了以下防禦措施,以更好地保護客戶:

對綁定裝載API進行額外驗證,以防止裝載過度;

盡可能從二進製文件中刪除符號。

4.研究Xtensa架構特性現在我們已經將所有段加載到適當的地址,我們可以開始逆向工程了。

但為了高效地做到這一點,我們需要更多地了解Xtensa 架構,包括:

1.指令中的參數順序

2.條件跳轉的執行細節

3.編譯器調用約定

4.堆棧組織

首先要探索的是指令中的參數順序。例如:MOV R1, R2.您可以在所有架構中找到此類指令,但這可能意味著將R1 複製到R2 或將R2 複製到R1。因此,了解指令中源代碼的位置以及目標寄存器的位置至關重要。您可以在GitHub 上找到Xtensa 指令集描述。

至於該MOV指令,在Xtensa中,表示將R2複製到R1。因此,第一個參數將是大多數簡單指令(例如數學相關指令)中的目的地。例如,指令addi a14, a1,0x38意味著a14=a1 +0x38。

但對於存儲數據的指令,情況則相反。例如,該指令s32i.n a5, a1,0x10意味著的值a5必須存儲在地址處(a1 +0x10)。

要學習的第二件事是條件跳轉的完成方式。有兩種方法可以做到這一點:

1.使用專用指令進行比較操作,設置標誌寄存器,然後進行條件跳轉。

2.使用一條指令一次性執行所有這些操作。

Xtensa 執行後者:beqz a10, loc_400E1C54

使用單個指令來檢查是否a10等於零,然後它要么跳轉到loc_400E1C54,要么不跳轉。

第三步是檢查編譯器使用的調用約定:將參數傳遞給函數的方式以及如何返回值。

Xtensa 以一種非常不尋常的方式傳遞參數。參數在調用指令之前放入寄存器中。但它們在函數中出現的寄存器與調用之前所在的寄存器不同:

image.png

以下是如何在彙編程序級別將參數傳遞給函數的示例:

image.png

這裡我們有三個論據:

a10 是目的地址

a11 是源地址

a12 是要復印的尺寸

然而,一旦代碼進入memcpy函數,這些值就會自動分別傳輸到a2、a3和a4寄存器中。

同樣的技巧也用於返回值。在memcpy函數內部,該值存儲在寄存器中a2,但從函數返回後,該值出現在a10.

返回的樣子如下0:

image.png

這就是檢查返回值的樣子:

image.png

benz.na10在從調用返回時檢查寄存器的值。

最後,有必要了解堆棧是如何組織的。

Xtensa 使用a1 寄存器來創建堆棧幀。每個函數都以入口指令開始:entry a1,0xC0,其中0xC0是堆棧幀的大小,即函數需要用於堆棧變量的堆棧量。

通常,這些函數從初始化堆棧變量開始:

image.png

寄存器中的零值a5被寫入基於a1寄存器的堆棧變量中。

在獲得有關Xtensa 架構的所有必要知識後,我們終於可以開始逆向其代碼了。

5. 在IDA 中對Xtensa 代碼進行逆向工程與ARM、MIPS 和PowerPC 相比,Xtensa 不是最流行的架構,並且沒有完整的功能列表。因此,IDA處理器模塊會存在一些我們需要克服的限制。

IDA 中Xtensa 處理器模塊的主要限制是:

函數參數沒有自動註釋

堆棧幀不會自動創建

一些ESP32 函數屬於IROM,因此存在對硬編碼地址的調用

部分Xtensa指令未反彙編

讓我們討論一些克服這些挑戰的技巧。

5.1.函數參數的類型系統和註釋從IDA 7.7 開始提供Xtensa類型系統。在IDA 中擁有可用的類型系統非常重要,因為它使逆向變得方便。特別是,它允許您導入C 結構的定義並指定IDA 使用的函數原型,以便在傳輸函數參數的指令附近放置自動註釋。

但是,如果您沒有類型系統,還有一個解決方法。

首先,讓我們看看有類型系統時函數是什麼樣子的:

image.png

屏幕截圖13. 當有可用的類型系統時函數的外觀

函數原型設置有參數的名稱和類型,以便IDA 可以使用此信息在調用站點註釋參數:

image.png

屏幕截圖14. 函數原型

但Xtensa 不會有這樣的事情。另一種方法是使用IDA 中的可重複註釋功能。如果您在函數的開頭設置可重複的註釋,它將顯示在所有調用站點上。

image.png

屏幕截圖15. 設置可重複註釋

image.png

屏幕截圖16. 可重複的註釋顯示在所有調用站點上

因此,我們可以使用此功能來定義函數參數:

image.png

屏幕截圖17. 使用可重複註釋功能定義函數參數

調用站點將如下所示:

image.png

屏幕截圖18. 調用站點

您可以在註釋中選擇寄存器名稱,IDA 會在代碼中突出顯示它。因此,您可以輕鬆找到參數值。

5.2.恢復堆棧幀要恢復堆棧幀,您需要手動指定堆棧大小,然後通過在每個與堆棧一起使用的指令處按K 鍵來顯示IDA 的使用位置。

讓我們探索一下config_router_safe函數,例如:

image.png

屏幕截圖19. config_router_safe 函數

很明顯這裡的棧幀大小是0xC0。我們在函數的堆棧設置中使用該值(Alt+P):

image.png

屏幕截圖20. 使用0xC0 值(堆棧幀大小)

從視覺上看,什麼也不會發生,但是如果您通過按Ctrl+K 轉到該函數的堆棧幀,您會注意到堆棧空間現在已分配:

image.png

屏幕截圖21. 分配堆棧空間

接下來要做的是使用entry指令指定堆棧移位。在此之前,我們建議啟用堆棧指針可視化,如下面的屏幕截圖所示:

image.png

屏幕截圖22. 啟用堆棧指針可視化

現在,代碼應該如下所示:

image.png

屏幕截圖23.啟用堆棧指針可視化後的代碼

000是當前堆棧指針移位值,我們需要將其移位0xC0。為此,請將光標置於入口指令處,然後按Alt+K以查看以下窗口,您可以在其中指定新舊堆棧指針之間所需的差異:

image.png

屏幕截圖24. 將當前堆棧指針值移動0xC0

作為此操作的結果,代碼將如下所示:

image.png

屏幕截圖25. 移動當前堆棧指針移位值後的代碼

現在,如果您開始在與寄存器一起使用的每條指令處按Ka1,IDA 將創建堆棧變量:

image.png

屏幕截圖26.IDA 創建新的堆棧變量

還可以編寫IDA 腳本來自動執行這些操作。

5.3.調用IROM調用位於CPU 的IROM 部分而不是固件中的某些低級API 的情況並不少見。在這種情況下,固件僅與包含定義的IROM 函數地址的特殊鏈接器定義文件鏈接。

在逆向期間,IROM 函數調用如下所示:

image.png

屏幕截圖27. IROM 函數調用

40058E4C是IROM 內的地址。但不可能知道固件調用了哪個函數。因此有必要檢查ESP32 工具鏈以查找鏈接器定義。

ESP32 芯片的IDE 是Espressif IDE。在IDE 文件中搜索IROM 地址,我們會找到:C:\Espressif\frameworks\esp-idf-v4.4.2\components\esptool_py\esptool\flasher_stub\ld\rom_32.ld

image.png

屏幕截圖28. ESP32 ROM 地址表

這些值可以輕鬆轉換為枚舉數據類型:

image.png

屏幕截圖29. 將值轉換為枚舉數據類型

然後,我們需要導入IDA,以便將enum 應用於IROM 地址值:

image.png

屏幕截圖30. 將枚舉應用於IROM 地址值

如果我們在IROM 地址附近添加可重複的註釋,它將使所有內容更容易閱讀:

image.png

屏幕截圖31. 在IROM地址附近添加可重複註釋後的代碼

5.4.無法識別的指令經常發生的情況是,處理器模塊已針對指令集的某些特定變體實現。然後製造商製造出具有99% 兼容指令集的新CPU,其中包含10 多個新指令,這是最初沒人想到的。因此IDA、Ghidra和Radare等工具可能無法反彙編一些新指令。

克服這一挑戰的正確方法是擴展處理器模塊並添加對新指令的支持。這需要對反彙編器API 有深入的了解,而這些API 並不那麼容易理解。

讓我們討論一種可能的解決方法,用於解決以下情況:儘管存在一些無法識別的指令,但您只想讓IDA 創建函數。假設IDA 不知道RER 指令,並且在包含RER 操作碼的情況下無法創建該函數:

image.png

屏幕截圖32. 如果函數包含RER 操作碼,IDA 無法創建該函數

您可以按P多次。除了控制台窗口中出現錯誤外,不會發生任何事情:

image.png

屏幕截圖33. 控制台窗口中的錯誤

但是,這並不意味著IDA 無法創建遵循RER 指令的指令。您可以跳過RER 指令的三個字節,然後創建代碼:

image.png

屏幕截圖34. 跳過RER 指令的三個字節後創建代碼

接下來,您可以選擇從輸入到最後的整段代碼retw.n,然後按P:

image.png

屏幕截圖35. 選擇從Entry 到retw.n 的整段代碼

之後,IDA 將創建該函數:

image.png

屏幕截圖36.IDA 創建一個函數

通常,反彙編程序無法識別的擴展指令在逆向過程中不會產生太大差異。可能導致問題的是執行調用、跳轉或加載/存儲等操作的新指令,因為代碼流丟失並且對數據的引用丟失。

結論對於涉及逆向工程物聯網固件的項目來說,在轉向業務邏輯之前研究未知的硬件架構至關重要。儘管逆向工程師可能需要幾週的時間來學習該架構,但從長遠來看,這種深入的研究有助於提高進一步工作的速度。

物聯網(IoT) 設備已經成為我們日常生活、工作環境、醫院、政府設施和車隊的重要組成部分。比如:Wi-Fi打印機、智能門鎖、報警系統等等。 2020 年,美國居民平均擁有十多個聯網設備。但出於實用性而選擇物聯網設備的用戶還需要確保這些設備的安全。

由於物聯網設備通常連接到內部家庭或公司網絡,因此破壞此類設備可以為犯罪分子提供對整個系統的訪問權限。 2021 年前六個月,智能設備遭受了約15 億次攻擊,攻擊者試圖竊取數據、挖掘加密貨幣或構建殭屍網絡。

確保物聯網設備良好安全性的一種方法是執行逆向工程活動,這將幫助您更好地了解特定設備的構建方式,並允許您對設備及其固件進行進一步分析。

在本文中,我們展示了智能空氣淨化器逆向工程固件的實際示例,強調了研究其架構的重要性。本文對於致力於網絡安全項目、想要了解逆向工程物聯網設備的細微差別和步驟的開發團隊很有幫助。

研究固件架構的重要性逆向工程物聯網固件的過程因所研究的設備而異。

物聯網設備發展得非常快,市場的主導架構一直在變化。不到十年前,最流行的選擇主要是x86 或ARM,不太可能是MIPS 或PowerPC。但現在,您需要了解多種微控制器架構來對嵌入式設備進行逆向工程:Tricore、rh850、i8051、PowerPC VLE等。

深入學習單一架構不足以在物聯網逆向工程中取得成功。如果開發人員有必要盡快開始逆向工程,他們應該從學習固件架構和結構的基礎知識開始。

這正是我們想要在本文中描述的:逆向工程師研究他們以前從未見過的新架構和固件格式的方式。

在本文中,我們使用了小米空氣淨化器3H 的固件轉儲。我們選擇它是因為它是ESP32 CPU(即Tensilica Xtensa 架構)的固件轉儲。這是一種相當奇特的架構選擇,但在需要Wi-Fi 通信的物聯網設備中很常見。您可以在此GitHub 頁面上找到我們將作為本文示例進行逆向工程的固件(ESP-32FW.bin)。

這種情況的挑戰是,沒有針對固件架構的現有反編譯器,並且反彙編器幾乎不支持它。然而,這是逆向工程師當今面臨的一個非常準確的例子。

物聯網固件逆向工程過程由以下五個階段組成:

image.png

1.確定架構在對物聯網設備進行逆向工程之前要問的第一個問題是如何了解逆向工程所需的固件的架構。

最直接的找出方法是閱讀CPU 的數據表並從中了解答案。但在某些情況下,您所擁有的只是固件本身。在這種情況下,您可以使用以下兩個選項之一:

1. 字符串搜索可能允許您找到一些剩餘的編譯字符串,其中包含有關編譯器名稱和體系結構的信息。

2. 二進制模式搜索要求您了解不同類型的微控制器架構中經常使用的指令。您可以在固件中搜索特定架構常見的二進制模式,然後嘗試將固件加載到支持此類架構的反彙編程序中以驗證您的猜測。

一旦確定了架構類型,您就可以開始選擇用於進一步逆向的工具集。對於ESP-32FW.bin,我們已經知道它將是Tensilica Xtensa 架構,因此我們需要選擇要用於研究的反彙編程序。

2.選擇反彙編工具在研究了可以支持Xtensa 的適當反彙編程序後,我們最終得到了三個選項:IDA、Ghidra和Radare。

我們決定首先嘗試使用Ghidra 和IDA,因為我們已經擁有將這些工具成功應用於不同逆向工程項目的豐富經驗。由於IDA 沒有用於Xtensa 的反編譯器,只有用於反彙編器的CPU 模塊,因此我們決定首先嘗試使用Ghidra(我們使用的是10.0 版本)。

Ghidra 默認不支持Xtensa,因此我們需要先為Ghidra 安裝Tensilica Xtensa 模塊。

Xtensa 的反彙編程序可以工作,但反編譯程序存在一些問題,如下面的屏幕截圖所示:

image.png

屏幕截圖1. 有關Ghidra 反編譯器中未實現指令的警告

經過一段時間的反彙編,我們意識到Xtensa 的Ghidra 處理器模塊在多種情況下難以確定指令長度。因此,我們放棄了Ghidra,轉而使用IDA(我們使用的是7.7 版本)。

起初在處理器模塊列表中找到Xtensa 很困難,但最終我們在這裡找到了它:

image.png

屏幕截圖2. IDA 處理器模塊列表中的Xtensa

IDA 中的處理器模塊看起來足夠穩定,因此我們決定堅持使用IDA。

3. 加載固件第一步是將固件加載到正確的映像基地址,以便將所有全局變量指針解析為有效地址。為此,有必要了解代碼在二進製文件中的位置。

我們首先在基地址加載固件0,並嘗試標記盡可能多的代碼。為了能夠在IDA 中正確標記代碼,我們需要學習Xtensa 固件常見的典型指令序列。為了找出在函數序言中使用哪些指令,我們從GitHub 中獲取了一個示例:esp8266/Arduino:適用於Arduino 的ESP8266 核心。

編譯器似乎使用了以下指令:entry a1, XX

該指令根據參數的值轉換為字節序列,例如36 41 00/36 61 00/36 81 00XX。

通過實現一個簡單的IDA 腳本來搜索此類模式,可以標記大約90% 的代碼:

image.png

屏幕截圖3. 在IDA 中標記代碼的結果

一旦我們找到了代碼,就該探索並看看它看起來是否正確。

看看下面的截圖,很明顯有問題。字符串資源被正確引用,但call8指令指向字符串,而不是代碼。並且有些call8指令指向不存在的地址。通常這意味著映像基址錯誤,固件必須加載到其他基址,而不是0.

image.png

屏幕截圖4. 發現call8 指令指向字符串和不存在的地址

確定基地址的常見方法是:

1.選擇一個字符串。

2.使用該字符串地址的低位部分查找引用它的代碼。

3.找出真實的字符串地址和我們在代碼中看到的地址之間的差異。因此,我們可以理解如何移動代碼的地址以匹配字符串的當前地址。

在這種情況下,我們發現基地址一定是0x3F3F0000,但即使使用它,call8指令仍然無效。這可能意味著二進制數據被分段,並且閃存中的代碼被分段映射到RAM。因此,有必要將固件分割成多個片段,並將這些片段加載到IDA 的適當段中。

我們查看了固件中的字符串,發現它確實是分段的:

image.png

屏幕截圖5. 固件分段證明

經過進一步研究,我們發現了ESP IDF 框架。由於我們的目標固件包含該框架的某些版本,因此我們可以嘗試使用其源代碼來了解固件結構。

我們在ESP IDF 內的bootloader_utility.c 源代碼文件中發現了一個有趣的bootloader_utility_load_partition_table()函數,這意味著固件必須包含分區表。

image.png

屏幕截圖6. bootloader_utility_load_partition_table() 函數顯示固件必須包含分區表

為了識別分區表,我們繼續探索源代碼,最終找到了esp_partition_table_verify()函數,該函數由bootloader_utility_load_partition_table()函數調用:

image.png

屏幕截圖7. 發現esp_partition_table_verify() 函數

所以一定有ESP_PARTITION_MAGIC和ESP_PARTITION_MAGIC_MD5:

image.png

二分搜索AA 50給了我們很好的結果:

image.png

屏幕截圖8. AA 50 的二分搜索成功結果

兩者ESP_PARTITION_MAGIC都ESP_PARTITION_MAGIC_MD5可以在附近看到。最有可能的sub_3F3F4848 是esp_partition_table_verify()。

由於我們已經知道esp_partition_table_verify函數在哪裡,因此我們能夠找到bootloader_utility_load_partition_table函數和ESP_PARTITION_TABLE_OFFSET 文件偏移量:

image.png

屏幕截圖9. 查找bootloader_utility_load_partition_table 和ESP_PARTITION_TABLE_OFFSET

image.png

屏幕截圖10. 查找偏移值

ESP_PARTITION_TABLE_OFFSET 是ESP32-FW.bin 文件中的文件偏移量。現在我們只需要知道分區表條目的結構。 ESP IDF框架的源代碼再次幫助了我們:

image.png

我們已將這些結構導入IDA 並將其應用到分區表數據中:

image.png

屏幕截圖11. 將結構導入IDA 並將其應用到分區表數據

如您所見,esp_partition_pos_t.offset 是每個分區的文件偏移量,我們現在可以將ESP32-FW.bin 拆分為分區。

但是我們如何才能將每個分區加載到適當的地址呢?似乎有一個image_load()函數負責將固件分區映射到地址空間:

image.png

屏幕截圖12. 將固件分區映射到地址空間

image.png

接下來,每個分區被分成段。在標題之後,您可以看到一個結構,後面是實際數據:

image.png

這裡,esp_image_segment_header_t.load_addr是CPU 地址空間中段數據的虛擬地址。

分區內的段如下所示:

image.png

現在,有了有關段的完整信息,我們可以將分區拆分為段並將它們加載到IDA 中的適當地址。我們可以手動完成此提取工作,也可以嘗試通過IDA 加載器插件將其自動化。

儘管如此,Ghidra 似乎已經實現了這樣的加載器。

TrickGate最初於2016年7月被發現,這種基於外殼代碼(shellcode)的打包器(packer)作為一項服務來提供,用於隱藏惡意軟件以免被端點檢測和響應(EDR)以及殺毒軟件發現。

在過去六年間,TrickGate 被用來部署最臭名昭著的惡意軟件,比如Cerber、Trickbot、Maze、Emotet、REvil、Cobalt Strike、AZORult、Formbook和AgentTesla 等。

由於定期會改頭換面,TrickGate多年來一直沒有被人注意。這個特徵導致研究界通過眾多屬性和名稱來識別其身份。

雖然該打包器的包裝程序會不斷變化,但TrickGate外殼代碼中的主要構建模塊至今仍在使用中。

Check Point 的威脅模擬(Threat Emulation)解決方案成功檢測並阻止了TrickGate打包器。

介紹網絡犯罪分子日益依賴打包器來執行惡意活動。該打包器在黑客論壇上又叫Crypter(加密器)和FUD,使殺毒軟件更難檢測到惡意代碼。通過使用打包器,惡意分子可以更輕鬆地傳播惡意軟件,而影響更小。商業打包器即服務的主要特徵之一是,它不關心攻擊載荷是什麼,這意味著它可以用來打包許多不同的惡意樣本。該打包器的另一個重要特徵是它能改頭換面——該打包器的包裝程序會定期改變,因此不被安全產品發現。

TrickGate是一種典型的功能強大且有彈性的打包器即服務,多年來沒有被網絡安全產品所發現,並以不同的方式不斷改進自己。我們設法追查到了TrickGate的下落,儘管它會迅速改變外層的包裝程序。

TrickGate堪稱偽裝高手,因不同的屬性而被賦予了許多名稱。名稱包括TrickGate、Emotet的打包器、新的加載器、Loncom和基於NSIS的加密器等。我們聯繫了之前的研究成果,基本上確定這起活動似乎是作為一項服務來提供的。

TrickGate歷年來的活動我們首次觀察到TrickGate是在2016年底。當時,它被用來傳播Cerber勒索軟件。從那時起,我們一直在觀察TrickGate,發現它被用來傳播所有類型的惡意軟件工具,比如勒索軟件、RAT、信息竊取器、銀行木馬和挖幣軟件。我們注意到,許多高級持續性威脅(APT)組織和威脅分子經常使用TrickGate來包裝惡意代碼,以免被安全產品檢測出來。 TrickGate參與了包裝一些最臭名昭著的惡意軟件家族的活動,比如Cerber、Trickbot、Maze、Emotet、REvil、CoinMiner、Cobalt Strike、DarkVNC、BuerLoader、HawkEye、NetWire、AZORult、Formbook、Remcos、Lokibot和AgentTesla等。

1.png

圖1. TrickGate歷年來的活動

TrickGate的分佈在過去兩年裡,我們每週監測到40次到650次攻擊。據我們的遙測數據顯示,使用TrickGate的威脅分子主要攻擊製造業,但也攻擊教育設施、醫療保健、金融和商業企業。 這些攻擊遍布全球各地,越來越集中在中國台灣和土耳其。近兩個月使用TrickGate的最盛行的惡意軟件家族是Formbook,佔跟踪分佈總量的42%。

2.png

圖2. 2022年10月至11月期間的TrickGate統計數據

攻擊流程下面概述了涉及TrickGate的攻擊中常見的攻擊流程。

初始訪問打包器用戶進行的初始訪問可能會有很大差異。我們監測的打包樣本主要通過帶有惡意附件的網絡釣魚電子郵件來傳播,但也通過惡意鏈接來傳播。

初始文件第一階段主要以壓縮可執行文件的形式出現,但我們監測後發現了導致相同外殼代碼的許多文件類型和傳播手段。我們在第一階段觀察到以下文件類型:

壓縮文件:7Z、ACE、ARJ、BZ、BZ2、CAB、GZ、IMG、ISO、IZH、LHA、LZ、LZH、R00、RAR、TAR、TGZ、UU、 UUE、XZ、Z、ZIP、ZIPX、ZST。

可執行文件:BAT、CMD、COM、EXE、LNK、PIF、SCR。

文檔:DOC、DOCX、PDF、XLL、XLS、XLSX、RTF。

外殼代碼加載器第二階段是外殼代碼加載器,它負責解密和運行外殼代碼。

我們注意到三種不同類型的代碼語言用於外殼代碼加載器。 NSIS腳本、AutoIT腳本和C都實現了類似的功能。

外殼代碼外殼代碼是打包器的核心。它負責解密攻擊載荷,並將載荷悄悄注入到新進程中。

攻擊載荷攻擊載荷是實際的惡意代碼,負責執行預期的惡意活動。攻擊載荷因使用打包器的威脅分子而異。

3.png

圖3. 攻擊流程

我們在過去一年觀察到的不同攻擊流程的示例:

2022年2月24日

4.png

圖4. LNK攻擊流程

RAR:3f5758da2f4469810958714faed747b2309142ae

LNK:bba7c7e6b4cb113b8f8652d67ce3592901b18a74

URL:jardinaix[.]fr/w.exe

EXE:63205c7b5c84296478f1ad7d335aa06b8b7da536

2022年3月10日

5.png

圖5. PDF攻擊流程

PDF:08a9cf364796b483327fb76335f166fe4bf7c581

XLSX:36b7140f0b5673d03c059a35c10e96e0ef3d429a

URL:192.227.196[.]211/t.wirr/XLD.exe

EXE:386e4686dd27b82e4cabca7a099fef08b000de81

2022年10月3日

6.png

圖6. SFX攻擊流程

7Z:fac7a9d4c7d74eea7ed87d2ac5fedad08cf1d50a

EXE:3437ea9b7592a4a05077028d54ef8ad194b45d2f

2022年11月15日

7.png

圖7. AutoIT攻擊流程

R11:755ee43ae80421c80abfab5481d44615784e76da

EXE:666c5b23521c1491adeeee26716a1794b09080ec

外殼代碼加載器外殼代碼加載器通常含有一個函數,負責解密外殼代碼並將其加載到內存中。以下是基本步驟:

1. 讀取經過加密的外殼代碼。經過加密的外殼代碼可以存儲在光盤上的文件中、“.rdata”部分或存儲成資源。

2. 為外殼代碼分配內存,常通過調用VirtualAlloc來分配。

3. 解密外殼代碼。

4. 觸發外殼代碼。正如我們在下面解釋的那樣,這可以通過使用直接調用或回調函數來完成。

8.png

圖8. 外殼代碼加載器——去混淆處理的AutoIT版本

9.png

圖9. 外殼代碼加載器C版本

在較新版本的TrickGate中,外殼代碼加載器濫用“回調函數”機制。加載器利用許多原生API調用,這些調用將內存地址作為回調函數的參數。加載器傳遞的不是回調函數,而是新分配的內存(內有外殼代碼)的地址。當Windows到達註冊事件點時,DriverCallback 執行外殼代碼。這種技術通過讓Windows操作系統在未知時間運行外殼代碼來中斷我們所監測的行為流。在上面的外殼代碼加載器中,您可以在上面底部一行標有“EnumTimeFormatsA”和“EnumSystemCodePagesW”的配圖中看到這兩個示例。

外殼代碼相似性和TrickGate暫停當我們發現不相關的惡意軟件家族在代碼上存在相似性時,威脅分子通常更有可能從共享資源複製或共享某些片段的代碼。我們在很長一段時間內註意到一種獨特的注入技術,它結合使用直接內核系統調用的方法,但我們沒有意識到其重要性,以為它可能是共享代碼的片段。 我們在攻擊活動中看到了偶爾的“暫停”,這使我們懷疑這種獨特的注入技術可能完全由一個威脅團伙控制,畢竟幾個不同的團伙同時偃旗息鼓的可能性很小。最近一次暫停長達3個多月(從2022年6月13日到2022年9月26日),這讓我們有機會證實自己的猜疑,並深入研究外殼代碼。

10.png

圖10. 過去兩年的TrickGate

為了驗證猜疑,我們開始分析不同時間段的樣本。

我們通過將新樣本與舊樣本進行比較來開始分析。針對這一測試,我們使用2022-12_Remcos:a1f73365b88872de170e69ed2150c6df7adcdc9c與2017-10_CoinMiner:1a455baf4ce680d74af964ea6f5253bbeeacb3de作了比較。

我們分析行為後知道了外殼代碼存在相似性,於是運行樣本,直到外殼代碼在內存中被解密,然後我們將外殼代碼轉儲到磁盤上。接下來,我們使用歸谷歌所有的Zynamics BinDiff工具,以檢查兩個外殼代碼的相似性。結果顯示,測試的外殼代碼存在50%的相似性。沒料到在很長一段時間內(超過五年)對於相當大的外殼代碼(~5kb)而言存在50%的相似性。這自然讓人懷疑這可能是由人維護的外殼代碼,但我們需要進一步的證據表明在較短的時間內存在相似性,看看它是否逐漸變化。

11.png

圖11. 從2022-12_Remcos:a1f73365b88872de170e69ed2150c6df7adcdc9c和2017-10_CoinMiner:1a455baf4ce680d74af964ea6f5253bbeeacb3de提取的外殼代碼的BinDiff結果比較

為了進一步分析,我們抽取了過去六年的隨機樣本。針對每個樣本,我們轉儲了外殼代碼,並檢查一段時間內結果的相似性。正如你在下圖中所看到,結果表明逐漸出現的變化很小。在左側,我們看到從2016年到2020年的樣本顯示存在大約90%的相似性。在右側,我們看到分叉版本本身存在很高的相似性,但左側原始版本的相似性較低。

12.png

圖12. 提取的外殼代碼的Bindiff結果

然後我們深入研究外殼代碼之間的差異,看看以下方面帶來的影響:

不同的編譯器

混淆

規避模塊

持久性模塊(在下次登錄時運行載荷)

函數順序

局部變量和結構

我們隨後得到了打包器的核心功能。編寫者不斷維護外殼代碼,但使用下一節中描述的“構建模塊”。

13.png

圖13. 控制流程圖—關於主注入函數。比較2016-07_ Cerber:24aa45280c7821e0c9e404f6ce846f1ce00b9823與2022-12_Remcos:a1f73365b88872de170e69ed2150c6df7adcdc9c的差異

14.png

圖14.比較NtWriteVirtualMemory 2022-12_Remcos: a1f73365b88872de170e69ed2150c6df7adcdc9c與2016-07_Cerber: 24aa45280c7821e0c9e404f6ce846f1ce00b9823的NtWriteVirtualMemory內核直接調用差異

TrickGate外殼代碼的構建模塊如上所述,外殼代碼一直在不斷更新,但自2016年以來主要功能出現在了所有樣本上。外殼代碼的構建模塊概述如下:

API哈希解析。

加載到內存中,並解密攻擊載荷。

使用內核直接調用進行注入。

手動映射ntdll 的新副本。

動態檢索內核系統調用編號。

調用所需的系統調用。

注入並運行攻擊載荷。

API哈希解析我們分析TrickGate代碼時,並沒有發現常量字符串。很多時候,TrickGate有意添加干淨的代碼和調試字符串以規避任何分析。為了隱藏所需的字符串及其意圖,TrickGate使用了一種名為API哈希的常用技術,即所有需要的Windows API都使用哈希數來隱藏。在2021年1月之前,TrickGate一直使用CRC32對外殼代碼字符串進行哈希處理。在新版本中,TrickGate開始使用自定義哈希函數。

過去兩年使用的等效Python哈希函數:

defhash_str_ror1(str):h=8998forcinstr:h+=ord(c)+(((h1)0xffffffff)|((h7)0xffffffff))returnh0xffffffffdefhash_str21(str):h=8998forcinstr:h=ord(c)+(0x21*h)returnh0xffffffff

以下Kernel32 API名稱已在TrickGate樣本中進行了哈希處理:

15.png

圖15. API哈希

加載到內存,並解密攻擊載荷。

TrickGate總是改變解密攻擊載荷的方式。大多數樣本使用自定義解密方法,但在較老的樣本中我們也看到了已知的加密器(比如RC4實現)或使用Windows API進行加密。

使用內核直接調用的注入:

在解密攻擊載荷之後,外殼代碼隨後將載荷注入到新創建的進程中。在使用create_suspended標誌創建進程之後,通過對內核的一系列直接調用來完成注入。針對這每一個ntdll API調用:

NtCreateSection

NtMapViewOfSection

NtUnmapViewOfSection

NtWriteVirtualMemory

NtResumeThread

執行如下操作:

從磁盤手動映射ntdll的新副本。

解析新映射的ntdll中某個特定哈希的地址。

動態提取所請求的系統服務號(SSN)。

使用SSN直接調用內核。

Windows 64位:使用Heaven’s Gate技術和SYSCALL SSN切換到64位模式

Windows 32位:調用SYSENTER SSN

16.png

圖16. 函數調用圖:來自手動映射的DLL的SYSCALL ID

TrickGate調用直接系統調用的方式很有意思,因為它使用了類似Hell’s Gate的技術。 Hell’s Gate是2020年公開提出的一種技術,這種方法動態檢索和執行直接系統調用號。在這裡,你可以找到可追溯到2016年的樣本,它們設法完成了檢索和執行直接系統調用的等效操作,不需要維護系統服務描述符表(SSDT)。

17.png

圖17. SSN動態提取2016-07_Cerber: 24aa45280c7821e0c9e404f6ce846f1ce00b9823

注入模塊是多年來最穩定不變的部分,自2016年以來一直出現在所有的TrickGate外殼代碼中。

結語我們創建了將過去六年裡最臭名昭著的惡意軟件與一個名為TrickGate的打包器即服務相關的字符串,TrickGate能夠改頭換面,因而難以識別和追踪它。了解該打包器的構建模塊對於檢測這種威脅至關重要,因為阻止打包器就可以在早期階段趁攻擊載荷還沒開始運行及時防范威脅。

由於研究人員往往將注意力集中在實際的惡意軟件上,打包器通常不太受關注。然而,現在可以將已識別身份的打包器用來檢測新的或未知惡意軟件。

微信截图_20230204153840.png

在當今的數字世界中,身份盜竊是一個日益嚴重的問題。隨著網上的個人信息越來越多,我們很難保護自己不受惡意行為者的傷害,他們可能會出於惡意目的使用我們的數據。

雖然這似乎是一個難以解決的問題,但下述20步指南將教你如何防止身份盜竊,讓你擁有保持安全並保護個人數據所需的知識。

什麼是身份盜竊?長話短說,身份盜竊是指非法使用某人的個人信息。

美國司法部解釋稱,身份盜竊是指犯罪分子利用他人的個人身份信息(PII)進行詐騙,來獲取非法經濟利益。身份盜竊有很多種方式,包括黑客攻擊、金融和社交媒體賬戶收購、信用卡欺詐、網絡釣魚,甚至是勒索軟件攻擊。

當網絡罪犯實施身份欺詐時,他們可能會使用偷來的身份:

開設新賬戶或信用額度;

用偷來的保險信息接受醫療救助;

竊取退稅;

在逮捕事件中提供你的個人證件(姓名、出生日期、地址等)。

2021年,傳統的身份欺詐損失,即涉及任何使用消費者個人信息來獲得非法經濟利益的損失,高達240億美元,致使1500萬美國消費者陷入困境。涉及身份欺詐的損失(與受害者直接接觸)總計280億美元,影響了美國2700萬消費者。

身份盜竊的類型身份盜竊有許多不同類型,每一種都可能是毀滅性的。以下是一些最常見的類型:

金融身份盜竊:指有人使用你的個人信息以你的名義開設新賬戶,並負債累累。這會毀了你的信用評分,讓你背負很多債務;

醫療身份盜竊:指有人使用你的保險信息來獲得醫療或處方藥。這可能會導致你在保險上的虛假索賠,更高的保費,甚至被保險公司拒絕承保;

稅務身份盜竊:當有人使用你的個人信息以你的名義提交納稅申報單並要求退款時,就會發生這種情況。這可能會導致你欠國稅局或州稅務機構的錢,可能需要幾個月甚至幾年的時間來解決這個問題;

犯罪身份盜竊:指有人利用你的個人信息以你的名義犯罪。這可能會導致逮捕和監禁,即使你自己實際上沒有犯過任何罪;

兒童身份盜竊:指有人竊取兒童的個人信息供自己使用。兒童的身份經常被用於金融欺詐或其他犯罪,因為他們通常有良好的信用記錄。這可能會對孩子未來的財務狀況和社會福利產生重大影響。

身份盜竊的警告信號有幾個關鍵的警告信號可以表明你的身份被竊取了。如果你看到以下任何一個危險信號,是時候採取行動保護你的身份和財務了:

收到不認識的賬戶的賬單或收款通知;

銀行賬戶出現不明原因的提款;

接到來自企業的電話或信件,詢問你沒有購買的產品或服務;

信用報告上有新賬戶或貸款,但你並沒有開設;

被拒絕申請信貸或貸款,因為你的信用報告上的信息似乎不正確;

如果你懷疑自己的身份被盜了,第一步是聯繫信用機構,並在你的檔案上發布欺詐警報。你還應該聯繫你的金融機構,以及任何你認為小偷可能會以你的名義開設新賬戶的企業。通過採取這些步驟,你可以保護自己免受進一步的傷害,並開始找回自我的過程。

如何防止身份盜竊?正如Bruce Schneier所言,“身份盜竊是信息時代的新型犯罪活動。犯罪分子收集了足夠多的個人數據,用來向銀行、信用卡公司和其他金融機構冒充受害者。然後他會以受害者的名義貸款,收了錢,就消失掉,受害者只能背黑鍋。雖然部分損失由金融機構——尤其是信用卡公司——承擔,但信用評級方面的損失則由受害者承擔。受害者可能需要數年時間才能為自己正名。”

一旦發生身份盜竊,要想恢復網絡罪犯竊取的信息是極其困難的。很多時候,你甚至不知道它是如何或何時發生的。

這就是為什麼採取積極主動的安全措施總是更好的,這將防止騙子竊取你的個人詳細信息和信息。謹慎行事總是好的,而不是在傷害已經造成、無法控制時才做出反應。

保護您的身份免受在線威脅(網絡層面)

1. 為你的網上帳戶選擇一個合適的密碼最重要的步驟之一是:始終確保你的密碼是強大的和唯一的。長度在15個字符左右,使用大寫字母和小寫字母,以及數字和符號;不要使用你的出生日期、電話號碼、社會保險號、家庭成員的名字或你寵物的名字,這些很容易被攻擊者猜到,通常只需要看看你的社交資料。

此外,不要在不同的賬戶之間重複使用密碼。如果您在所有地方都使用相同的密碼,攻擊者將能夠訪問您的所有其他帳戶。

但如果我們創建了非常多的在線賬戶,我們到底該怎麼做呢?

首先,不要把它們寫下來!不要寫在你桌子上的紙上,不要寫在電子郵件草稿裡,也不要寫在你桌面上的文本文件裡。這些都是不安全的地點。相反地,您可以開始使用密碼管理器。它會記住你所有的密碼,並以安全的方式存儲它們。另一個關鍵的安全步驟是在任何可用的地方激活雙因素或多因素身份驗證。

2. 不要在網上發布機密信息在發布關於你的信息之前要三思。我們在網上發布的所有內容都將保留在那裡,每個想看的人都可以看到。儘管我們願意認為我們可以控制自己的隱私,但事實是我們永遠無法確定誰在監視我們。我們永遠都不知道這些信息會到哪裡去。即使我們採取了所有可能的安全措施,我們仍然依賴於其他服務和系統,這些服務和系統可能並不像他們聲稱的那麼安全。

這就是為什麼我們要關注我們放在評論、私人信息、帖子、簽到、照片或其他我們在網上顯示的任何東西中的所有數據是很重要的。這裡的“在線”指的是博客、社交網絡(Twitter、Facebook、LinkedIn、Instagram等)上的帖子、照片、簽到或評論,也包括AirBnB、TripAdvisor、Booking等網站。

3.小心網絡釣魚詐騙網絡釣魚是最古老的網絡威脅之一,但它仍然會造成很大的損害。攻擊者不斷改進他們的技術和欺詐方法。主要的網絡釣魚計劃和活動出現在:

網上購物;

查看電子郵件帳戶;

訪問社交媒體網絡;

雖然網絡釣魚使用多種渠道獲取我們的證書,但垃圾郵件攻擊仍然是主要的成功方法。

4.網上購物要謹慎

網絡購物已經變得非常方便,我們有更多的選擇,可以在一個地方,一次點擊即可完成操作,節省了我們大量的時間和金錢。

在網上購物時,最重要的是要確保你在一個合法的網站上。以下是如何確保你不會將財務信息發送給網絡罪犯的方法:

從知名、可信的網站購物;這將減少任何不愉快的意外的可能性;

檢查連接是否加密。您可以通過查看地址欄來做到這一點:是否有一個綠色鎖的圖標?地址開頭是“https”而不是“http”嗎?

另外,確保在線支付時激活二次認證因素。在下單前,您將在手機上收到最終識別碼;

最安全的方法是只在網上購物時使用一張單獨的卡。只有在你想買東西的時候才把錢轉到上面,否則就以低金額保存它。這樣,萬一有什麼不好的事情發生,你仍然有一個安全網。

5.保護您的瀏覽器設置我們的瀏覽器是連接網站的主要工具。因此,需要對它給予高度重視。確保您使用的是包含所有可用安全補丁的最新瀏覽器版本。

沒有所謂的免費程序,所以確保你在下載之前通過快速的網絡搜索仔細檢查免費程序的安全性和合法性。

如果從公共計算機連接,請使用私人瀏覽會話,您一定不希望本地記錄您的瀏覽歷史詳細信息。

為了確保你的連接是安全的,你可以使用VPN軟件或Tor瀏覽器加密它,以隱藏你的瀏覽活動。

6.使用多種安全產品保護您的計算機身份竊賊會使用多種工具獲取你的個人數據。我們這裡不是在談論普通的病毒,我們指的是高級惡意軟件和間諜軟件工具,如鍵盤記錄器,漏洞利用工具包和遠程管理工具。它們能夠在您不知情的情況下從系統中檢索敏感信息。

高級惡意軟件旨在逃避普通的反病毒檢測。有時要過很長一段時間你才能意識到它的存在。這就是必須配置一個好的殺毒軟件的原因。它能夠最大限度地減少你清理惡意軟件攻擊造成的混亂的時間。

此外,為了確保銀行業務的金融安全,並防範零日惡意軟件,您還需要先進的掃描技術,可以保護您免受最新的威脅。

7.保持系統和軟件更新用最新的安全補丁更新您的系統。對於易受攻擊的應用程序和程序,應該做同樣的事情。如果你不想每天檢查和更新這些應用程序,你也可以使用專門的解決方案來自動完成這項工作。

保護您的身份免受人身威脅(物理層面)以下步驟旨在解決物理盜竊企圖,因為它們可以造成和在線威脅一樣大的破壞。

8.誰在監視你?當你站在自動取款機前或當地的商店,試圖取一些錢或只是輸入你的密碼來支付時,在鍵入敏感數據之前,請確保你周圍沒有人可以看到你的信息。即使你沒有看到周圍的人,也可能有特殊的監控機制,所以為了確保你的安全,盡量隱藏你鍵入的數字。

9.你帶了什麼?在你離開家之前,花點時間考慮一下該帶哪些東西。只帶必要的物品,可以減少潛在的損失。 此外:

不要把你的包放在無人看管的公共場所或遠離你的地方。

不要把你的錢包隨便亂放,給小偷製造機會。

考慮分散竊賊的注意力。你可以帶一個假錢包,或者乾脆不把重要的東西放在包裡,因為這些東西可能會被偷。把重要的東西放在身邊。

10.銷毀不再需要的文件我們習慣把重要數據放在家裡。這些信息可能是你過去工作的地方、醫療記錄、證書和文憑,甚至可能是與你工作有關的機密信息。

我們都有收集各種文件和信息的傾向。其中一些我們可能不再需要了,比如收據或銀行對賬單。雖然我們可能不再需要這些數據,但這對騙子來說,可能仍是可以利用的重要元素。

因此,在你扔掉那些文件之前一定要把它們銷毀,比如使用碎紙機,不要只是把它們放在垃圾桶裡。

11.保護好你的郵箱試著像身份竊賊一樣思考。當你需要找到個人信息,尤其是某人的財務細節時,你會考慮從何處入手?

最簡單的方法是從那些保護較少的區域開始,比如郵箱。想一下:

你在郵箱裡收到過什麼類型的信息?你收到銀行的重要文件了嗎,也許是一張新的信用卡?如果你這樣做了,你需要聯繫銀行,讓他們停止這種類型的通信。如果你有重要的東西需要收集,只要去銀行取就行了。

你收到每項服務的發票了嗎?也許這對你來說似乎不是太多的數據,但身份竊賊可以使用這些信息與其他來源相關聯,以了解你的財務狀況。通過電子郵件接收發票會更容易,因為今天大多數服務提供商都提供這種選擇。

你的郵箱保護得怎麼樣?如果任何人都可以訪問你的郵箱,而你又知道有重要的信息被發送到那裡,也許你應該在郵局設置一個高安全性的郵箱或私人郵箱。

12.你了解電話來源嗎?沒錯,身份竊賊可能會給你打電話,冒充銀行代理或官方代表,要求你提供私人細節或財務數據。

小偷是怎麼知道你的銀行的?好吧,記住前面的幾點。要獲得你的信息並不難。他們可能會查看你的郵箱,他們可能會在商店或自動取款機上看著你,甚至他們可能會翻看你的垃圾。發現這點信息並不難。

不要被他們使用的專業語氣所愚弄。切記不要在電話中提供重要信息,除非是你主動打電話的,而且你真的知道自己在和誰通話。

13.銷毀你的數字信息如今,我們都使用雲服務來存儲重要文件,無論是工作文件還是個人照片。

然而,隨著時間的推移,我們在CD/DVD或外部硬盤驅動器上收集了各種類型的信息。有時,我們不得不扔掉一個看似無法運行的硬盤,而忽略了我們留在上面的私人數據。

要了解廢棄磁盤中的信息對你的危害,只要想想你留在磁盤上的所有照片、文檔和私人詳細信息就可以了。使用特殊的工具和軟件,黑客可以從這些硬盤中輕鬆地檢索到所有信息,並使用它來對付你——即使你在扔掉它之前刪除了數據並進行了格式化。

為了確保對舊磁盤的不安全處理不會成為身份竊賊的機會,您需要確保已銷毀了該數據。有以下選項:

多次覆蓋數據,讓身份竊賊更難下手。你也可以使用專門的軟件來幫你做這件事;

物理上銷毀硬盤或CD/DVD;

你知道打印機和復印機也有內置硬盤嗎?所以,在移除硬盤之前,不要直接扔掉打印機。

14.保護好你的社會安全號碼這是保護你的身份不被小偷竊取的最重要的步驟之一,因為這條信息可以在多種情況下使用。 身份竊賊可以使用你的社會安全號碼申請新信用卡或開立銀行賬戶,要求貸款,甚至租房子。

它還可以用來在電話或在線上證明你的身份,以便訪問私人信息。這裡有一些保護它的技巧:

不要把它用作任何在線賬戶的密碼;

除非你真的需要,否則不要隨便帶著它;

不要通過電子郵件發送相關信息;

不要把它存儲在你的電腦、智能手機或云驅動器上。

15.確保智能手機安全現在我們可以用智能手機完成所有的操作,例如拍照、獲取信息、與朋友保持聯繫、訪問云存儲甚至進行金融交易。這成為我們最大的風險。想想看,一個人僅僅通過使用智能手機就能獲得多少信息。

你可以遵循以下幾個步驟,以確保你的智能手機數據不會落入壞人之手:

下載知名公司的應用程序,尤其是用於金融交易的應用程序;

使用強大的密碼來保護移動設備,或者更好的是,使用2種方法來保護它免受任何破壞。生物特徵認證,比如用你的指紋鎖定,可能被證明是最安全的;

使用最好的應用程序來保護你的智能手機,其中大多數都包含GPS功能和遠程清除機制。

16. 備份這裡不是指電腦備份,而是指備份某些東西,以防某些東西在某個時候丟失。讓我們試著回答幾個問題,這樣我們就可以弄清楚並找到解決方案:

你把所有的錢都存在一張信用卡上嗎?為什麼?至少用兩張卡,然後把錢分散存儲;

你出門的時候會把兩張卡片都帶在身上嗎?為什麼?就拿一個吧。或者至少不要把它們放在同一個地方。這樣,你就可以減少潛在的損失。

你需要在某個地方驗證你的身份嗎?好的,你可以隨身攜帶身份證明文件,但是不要把身份證、駕照和護照全部帶走。

你真的需要帶正式文件嗎?也許你可以用複印件代替。在任何情況下,確保你總是有所有重要文件的複印件,特別是在旅行時。

你有丟失公文或信用卡時可以求助的電話號碼嗎?

結語身份盜竊是一個嚴重的問題,會對受害者造成毀滅性的影響。我們希望本指南為您提供了必要的知識和工具,以幫助您保護自己免受身份盜竊。

保護您的個人信息安全應該是一項首要任務,所以記住要時刻留意任何可疑的事情,並在網上保護自己時採取積極主動的措施。只需採取一些簡單的步驟,比如鎖定你的賬戶,使用強密碼,警惕網絡釣魚詐騙,跟踪你的信用評分,就可以保護自己免受潛在的身份盜竊影響。現在採取這些預防措施將為你以後節省更多時間和金錢。

隨著技術的發展,世界之間的聯繫變得更加緊密,攻擊者使用的技術也在不斷發展。攻擊者通過不斷地利用供應鍊和代碼庫中復雜的相互依賴關係,對組織、個人和社區造成重大風險。

近年來最令人擔憂的攻擊趨勢之一是供應鏈攻擊的增加,尤其是那些對代碼庫的攻擊,這是全球網絡安全領域的一個難題。根據歐盟網絡安全機構(ENSA)發布的一份報告,62%的組織受到第三方網絡事件的影響,只有40%的受訪組織表示他們了解第三方網絡和隱私風險。更令人擔憂的是,38%的受訪組織表示,他們不知道哪些網絡問題是由第三方組件引起的,最近涉及供應鏈的網絡攻擊包括Apache Log4j, SolarWinds Orion和3CX的3CXDesktopApp。

在現代軟件開發中,開發人員依賴第三方組件來簡化開發過程,這使開發人員能夠創建成本效益高、效率高且功能豐富的應用程序。但是,當這些受信任的組件受到攻擊時會發生什麼?

攻擊者可以通過組織供應鏈中不太安全的元素,如第三方供應商或軟件存儲庫間接滲透系統,甚至允許他們破壞受信任的組件,從而在更大、更安全的環境中獲得立足點。惡意代碼經常嵌入看似合法的軟件庫中,當開發人員集成這些組件,就會不知不覺地將漏洞和其他網絡安全風險引入他們的核心系統。

本文深入研究了攻擊者在看似合法的應用程序和代碼庫中植入惡意有效負載的複雜方法,並以最近示例作為研究對象。

技術分析攻擊者復制合法GitHub存儲庫的示例研究,然後用惡意代碼進行木馬化和攻擊,策略性地用關鍵字填充其存儲庫描述部分,以最大限度地提高其在GitHub搜索中的可見性。

通過此分析,我們可以深入了解攻擊者攻擊第三方組件的攻擊過程和技術,以下部分將使用活動命令與控制(CC)服務器研究其中一個被木馬化的項目,了解其內部工作原理。

通過exec smugglingweb請求發起攻擊1.png

Discord-Boost-Tool的存儲庫名稱和存儲庫的所有者

在所舉示例中,攻擊的第一階段採用了一種我們稱之為exec smuggling的新技術。該技術在一長串空白字符之後放置一個有效負載,將惡意內容從屏幕上推送出去。使用這種技術,下一階段通過惡意請求調用檢索,≠≠使用Python內置方法exec()執行。接下來,我們將根據示例概述exec smuggling 的具體實現步驟。

導入必要的依賴項在導入request和fernet之前,惡意軟件使用以下命令在Python中安裝必要的依賴項,通過該命令安裝依賴項包:

2.png

惡意軟件安裝並導入必要的依賴項

將惡意代碼對象移出白名單攻擊者會添加一長串空白字符(在本例中是521個空格),將惡意代碼移出白名單,從而隱藏代碼對象,不被人發現。

3.png

使用exec()執行惡意負載

最後,通過調用Python的exec方法來執行代碼對象。以下是解密後的惡意代碼片段:

4.png

此代碼對象向攻擊者的命令和控制(CC)服務器發出web請求,該服務器包含惡意負載,然後導致第二階段的攻擊。

5.png

執行走私後攻擊進入第二階段

攻擊的第二階段據分析,攻擊的第二階段側重於為進一步開發準備攻擊環境。

設置環境第二階段包括準備環境的滴管,最初,它安裝一系列Python包,如requests、httpx、pyperclip、pyotp、winregistry、psutil、pycryptodomex和asyncio等。然後,它識別用戶系統上安裝的所有Python版本,並檢查每個版本的site-packages中是否存在Cryptodome目錄。如果找到,它將此目錄複製為Crypto,可能是為了確保與原有庫的向後兼容性。隨後,腳本創建一個解密有效負載,將其寫入用戶APPDATA目錄中的一個名為pl.py的文件,在執行它而不顯示窗口。

6.png

第二階段使用Python的子進程模塊進一步準備環境

攻擊的第三階段環境準備好後,惡意軟件進入攻擊過程的第三階段。

BlackCap-Grabber第三階段包含一個修改版的開源信息竊取項目,名為BlackCap-Grabber。它具有以下功能:

提取瀏覽器密碼、cookie和瀏覽歷史記錄;

檢索系統信息;

從應用程序和工具(如Steam, MetaMask和Exodus)竊取登錄憑據;

繞過TokenProtector;

劫持Windows剪貼板以更改加密貨幣地址,將其內容替換為攻擊者的錢包地址以及其他功能。

重要的是,原來的BlackCap-Grabber包括雙鉤(dual hook)技術,使用這種技術,代碼的開發者也將收到由攻擊者(BlackCap-Grabber用戶)竊取的信息的副本。像BlackCap-Grabber-NoDualHook這樣的項目會從源代碼中移除植入的DualHook。

在執行時,惡意軟件將受攻擊系統的ComputerName發送到其CC服務器。然後安裝必要的Python包以確保惡意軟件的功能。請注意,此代碼不是原始BlackCap-Grabber的一部分,而是由攻擊者添加的。

7.png

惡意軟件發送帶有受害者計算機名的POST請求,並安裝額外的依賴項

下圖展示了由惡意軟件及其處理受害者信標的請求處理程序生成的初始網絡流量的示例。

8.png

向包含受害者用戶名的/downloadhandler發出POST請求

攻擊者添加的另一個功能是出口注入(exodus-injection),這在原始的BlackCap-Grabber源代碼中不存在。出口注入允許攻擊者使用攻擊技術從Exodus Crypto Wallet(一種受新加密貨幣用戶歡迎的加密貨幣錢包)竊取憑證和其他敏感信息。攻擊者在其攻擊鏈中使用多個開源的Exodus-Injection項目(https://github.com/loTus04/Exodus-Injection和https://github.com/dropout1337/exodus-injection)。

9.png

BlackCap-Grabber配置

BlackCap-Grabber的主要功能是劫持Windows剪貼板以更改加密貨幣地址,從受攻擊的系統中檢索敏感信息,並從各種web瀏覽器將其保存到文件中以供洩露。

10.png

BlackCap-Grabber準備敏感信息,如瀏覽器cookie、加密貨幣地址和剪貼板信息

11.png

BlackCap-Grabber使用upload()方法處理敏感信息數據,以便上傳到攻擊者的基礎設施

12.png

BlackCap-Grabber使用LoadRequests方法從受害者發送POST請求以進行數據提取

使用上圖中的邏輯,攻擊者向基礎結構發送包含洩露的密碼、cookie和加密貨幣地址的POST請求。

13.png

攻擊者通過POST請求將洩露的數據發送到/handler終端

在此示例中,惡意軟件將包含瀏覽器cookie等內容的惡意包從受攻擊系統中洩漏到攻擊者控制的主機。攻擊者使用web請求處理程序來處理從受害設備上成功竊取的包。

14.png

另外一個密碼示例通過POST請求發送到/handler終端

以上是我們發現的附加POST請求,其中包含由攻擊者從受攻擊的受害者向處理程序/句柄洩露的敏感信息。

探索Exodus和ElectronJS組件經過調查,我們確定Exodus桌面錢包是使用ElectronJS框架構建的,基於本地Exodus安裝的資源目錄中存在的app.asar文件,該框架用於捆綁和打包應用程序的資源。 Asar壓縮文件類似於.zip或.tar文件,但專門為ElectronJS應用程序設計。

攻擊鏈第三階段的一個主要組成部分涉及通過操作底層的ElectronJS應用程序在受攻擊用戶的設備上植入惡意的Exodus桌面錢包應用程序,這使得攻擊者可以竊取與Exodus錢包相關的憑證,從而實施攻擊,並最終竊取屬於受害者的加密貨幣和不可替代代幣(nft)。

ElectronJS和Exodus這兩個漏洞是由關聯的。早在2018年,基於遠程代碼執行漏洞CVE-2018-1000006(CVSS 8.8)的Electron就可以被利用。研究人員很快指出,攻擊者可以通過濫用電子協議處理程序來利用這個漏洞。

如前所述,ElectronJS應用程序被打包為app.asar壓縮文件,其中包含應用程序的源代碼和各種應用程序資產。 Asar壓縮文件類似於.zip或.tar文件,是專門為ElectronJS應用程序設計。

什麼是Exodus?Exodus是一個數字資產平台,允許用戶存儲、管理和交換加密貨幣和NFT。

Exodus提供各種錢包,如Web3錢包、移動錢包、桌面錢包、Trezor硬件錢包,以及與加密貨幣應用程序的集成。

Exodus桌面錢包應用程序Exodus桌面錢包(Exodus Desktop Wallet)是Exodus的桌面應用程序。 Exodus桌面錢包支持所有主要的操作系統,如微軟、MacOS和Linux,通過用戶友好的圖形用戶界面(GUI),可以存儲和交易主要的加密貨幣和NFT。

通過web GUI訪問Exodus桌面錢包Exodus桌面錢包提供了一個直觀的界面來訪問加密貨幣錢包。解鎖加密貨幣錢包需要密碼,如Exodus桌面錢包應用程序GUI所示。

在設置用於備份錢包的助記符秘密短語時,Exodus會讓用戶打印助記符密鑰作為安全設備。

15.png

使用物理助記鍵恢復Exodus錢包

當用戶試圖恢復錢包時,Exodus可能會要求他們參考助記秘鑰的打印副本,並根據提供的數字選擇正確的單詞。出於安全考慮,Exodus被設計成一個使用密碼和助記短語組合的自我保管錢包。

探索Exodus ElectronJS應用程序的主要組件Exodus桌面錢包的app.asar文件可以解壓縮到目標目錄。在這個目錄中,我們看到了應用程序的根目錄,其中包括node_modules、src和應用程序的package.json。

16.png

Exodus桌面錢包的NodeJS後端

17.png

關鍵後端文件相關的Exodus桌面錢包

Exodus ElectronJS應用程序的主要組件包括應用程序的主邏輯(包含在src/app/main/index.js中)、錢包組件(包含在src/app/wallet/index.js中)和表示邏輯(包含在src/app/static/中),後者將NodeJS後端文件導入到應用程序的前端表示中。

正在攻擊Exodus桌面錢包的ElectronJS應用程序通過使用注入技術,攻擊者可以通過替換app.asar壓縮,將Exodus桌面錢包的ElectronJS應用程序替換為惡意的ElectronJS應用程序,該壓縮文件由Exodus桌面錢包讀取。這個應用程序是一個全功能的複製品Exodus桌面錢包,攻擊者將其功能改變,以竊取錢包信息,包括密碼和助記符信息。

18.png

inject()函數負責注入惡意的Exodus桌面錢包

在上圖所示的代碼中,攻擊者執行一系列檢查,以確定受攻擊的設備是否安裝了Exodus Desktop Wallet。

下面的代碼片段是在Windows安裝中Exodus應用程序使用的app.asar文件的位置。

Exodus錢包桌面Windowsapp.asar路徑:

19.png

同時,下面的代碼片段是Linux安裝中Exodus應用程序使用的app.asar文件的位置:

Exodus錢包桌面Linuxapp.asar路徑:

20.png

如果發現Exodus,惡意代碼將繼續如下操作:

1.從攻擊者控制的基礎設施下載並讀取惡意修復的app.asar文件。

2.終止現有的Exodus進程。

3.將惡意的app.asar寫入Exodus應用程序資源目錄中的Exodus app.asar文件中。

如果在設備上找不到Exodus桌面錢包的行為如果在目標設備上沒有找到Exodus,惡意代碼將繼續下載文件stromrechung.py到\Microsoft\Windows\Start Menu\Programs\Startup。該文件將在系統啟動時執行。

21.png

如果沒有找到Exodus,“miner.exe”將從另一個攻擊者域下載並安裝

22.png

Python用於執行惡意批處理文件,其中包含“miner.exe”的下載和運行邏輯。

惡意文件stromrechnung.py是一個python文件,包含以下邏輯:

1.為Windows批處理文件創建一個Python函數;

2.使用陸地驅動程序(LoLDrivers)編寫邏輯以繞過UAC;

3.編寫PowerShell命令將加密貨幣挖礦器(miner.exe)下載到受害者的設備上;

4.運行Python函數,該函數使用subprocess.popen 方法執行批處理文件。

在Exodus桌面錢包的ElectronJS應用程序中註入代碼在示例中,有三個不同的文件被攻擊者改變了,具體將在後面介紹。

惡意注入後端unlock()函數(src/app/wallet/index.js)主要注入發生在src/wallet/index.js中,攻擊者在解鎖函數中註入惡意POST請求。 POST請求包含錢包密碼、助記密鑰和錢包目錄。

23.png

文件src/app/wallet/index.js被攻擊,洩露密碼、助記符和錢包信息給攻擊者

允許打開錢包域(4.9.1.2. src/app/main/index.js)即使在乾淨的Exodus應用程序將錢包域限制為Exodus的位置,攻擊者也可以修改主index.js文件以允許所有錢包域。

24.png

文件src/app/main/index.js修改域名列表以允許所有錢包域名

4.9.1.3. src/static/wallet.html:禁用內容安全策略(CSP)內容安全策略(CSP)作為一個額外的安全層,用於識別和抵禦特定形式的攻擊,例如跨站點腳本(XSS)和數據注入攻擊。 connect-src指令限制了可以通過腳本接口加載的url。

25.png

文件src/app/main/index.js被修改為禁用應用程序的CSP

我們發現,攻擊者有效地禁用了CSP,以允許從所有url到Exodus wallet.js組件的數據連接。

Discord-Boost-Tool GitHub存儲庫接下來,我們將探討Discord-Boost-Tool的特性及其一些有趣的組件。

discord-boost-tool的起源在本文所列舉的示例中,受攻擊的Discord-Boost-Tool源自2022年底的原始Discord-Boost-Tool存儲庫。這個工具允許用戶使用NitroBot帳戶來提升他們的Discord服務器,它被GitHub用戶PatrickPagoda迅速分叉(fork)並修改,通過惡意PyPi包攻擊不知情的用戶,該用戶多次將惡意Python包上傳到PyPi註冊表中。值得一提的是,與PatrickPagoda相關的原始GitHub帳戶在7月底至8月的某個時候

GoldenJackal是一家APT組織,自2019年開始活躍,通常針對中東和南亞的政府和外交機構。儘管他們早在幾年前就開始了活動,但該組織似乎沒有被詳細介紹過。

卡巴斯基實驗室的研究人員早在2020年中開始監測該組織,觀察到這是一個極其專業的組織。該組織的主要開發.NET惡意軟件、JackalControl、JackalWorm、JackalSteal、JackalPerInfo和JackalScreenWatcher等特定工具集,目的是:

马云惹不起马云控制受害者計算機;

马云惹不起马云在使用可移動驅動器的系統中傳播;

马云惹不起马云從受感染的系統中竊取某些文件;

马云惹不起马云竊取憑據;

马云惹不起马云收集有關本地系統的信息;

马云惹不起马云收集有關用戶網絡活動的信息;

马云惹不起马云 截取桌面的屏幕截圖;

根據工具集和攻擊者的行為,研究人員認為GoldenJackal APT組織的主要動機是間諜活動。

攻擊途徑研究人員發現攻擊者假冒Skype安裝程序,使用惡意Word文檔。

另一個已知的攻擊途徑是一個惡意文檔,它使用遠程模板注入技術下載惡意HTML頁面,該頁面利用了Follina漏洞。

1.png

這份文件被命名為“Gallery of Officers Who Have Received National And Foreign Awards.docx”的文件似乎是合法的,旨在收集巴基斯坦政府授予勳章的官員的信息。值得注意的是,Follina漏洞是在2022年5月29日首次被公佈,該文檔似乎在發布兩天后的6月1日進行了修改,並於6月2日首次被檢測到。

該文檔被配置為從合法且已被攻擊的網站加載外部對象:

hxxps://www.pak-developers[.]net/internal_data/templates/template.html!

2.png

用於加載遠程資源的代碼段

遠程網頁是公共“概念證明”的修改版本,用於利用Follina漏洞。原始PoC可在GitHub上獲得。攻擊者將IT_BrowseForFile變量值替換為以下值:

3.png

利用Follina漏洞的代碼段

解碼後的字符串為:

4.png

解碼腳本該漏洞會下載並執行託管在合法受攻擊網站上的可執行文件,並將其存儲在以下路徑中:“%Temp%\GoogleUpdateSetup.exe”。下載的文件是JackalControl惡意軟件。

在其他情況下,研究人員沒有發現真正的攻擊途徑,他們還觀察到在橫向活動進程中系統受到攻擊。具體來說,研究人員觀察到攻擊者使用psexec實用程序啟動惡意批處理腳本。

5.png

批處理腳本執行各種操作,例如安裝Microsoft .Net Framework 4、用JackalControl木馬感染系統並收集有關係統的信息。

6.png

JackalControl這是一種木馬,允許攻擊者通過一組預定義和支持的命令遠程控制目標計算機。信息是通過HTTPS通信信道在惡意軟件和C2服務器之間進行接收的,並且可以指示植入進行以下任何操作:

马云惹不起马云使用提供的參數執行任意程序;

马云惹不起马云下載任意文件到本地文件系統;

马云惹不起马云從本地文件系統上傳任意文件;

在過去幾年中,攻擊者多次更新該工具,已出現了多種變體。接下來,我們將描述2023年1月觀察到的最新版本(8C1070F188AE87FBA1148A3D791F2523)。

該木馬是一個可執行文件,可以作為標準程序或Windows服務啟動。

它需要一個參數,該參數可以等於以下一個值:

马云惹不起马云/0:作為標準程序運行,只與C2服務器聯繫一次;

马云惹不起马云/1:作為標準程序運行,並定期聯繫C2服務器;

马云惹不起马云/2:作為Windows服務運行;

惡意軟件參數和相關的惡意軟件行為根據變體而變化。一些變體只提供兩個參數:

马云惹不起马云/0作為標準程序運行;

马云惹不起马云/1作為Windows服務運行;

其他變體可以自我安裝不同的持久性機制。惡意軟件的執行流程由運行該惡意軟件的命令行中提供的參數決定。

马云惹不起马云/h0:將通過創建Windows計劃任務使惡意軟件獲得持久性;

马云惹不起马云/h1:將通過創建相應的註冊表運行項使惡意軟件獲得持久性;

马云惹不起马云/h2:將通過創建Windows服務使惡意軟件獲得持久性;

马云惹不起马云/r0:作為標准進程運行(此參數由Windows計劃任務指定);

马云惹不起马云/r1:作為標准進程運行(此參數由生成的註冊表運行項值指定)。

马云惹不起马云/r2:作為服務運行(此參數由創建的Windows服務指定)。

攻擊者已經將不同的變體進行了傳播:有些包括用於維護持久性的代碼,另一些則被配置為在不感染系統的情況下運行;並且感染進程通常由諸如上述批處理腳本之類的其他組件執行。

惡意軟件通過生成BOT_ID開始其活動,這是用於識別受攻擊系統的唯一值。此值源自其他幾個基於主機的值:

從以下WMI查詢中獲得的UUID值:

7.png

從以下註冊表項獲取的計算機GUID:

8.png

從另一個WMI查詢中獲得的額外驅動器的列表,這反過來允許他們確定' PHYSICALDRIVE0 '的' SerialNumber ':

9.png

收集到的信息被連接在一個字節數組中,然後用MD5哈希,MD5被用作創建BOT_ID的種子。用於生成後者的算法只是對結果MD5哈希中每兩個連續字節求和,並將所得字節(模數256)作為最終BOT_ID的單個字節。下面的代碼片段描述了這種邏輯,它取自惡意軟件。

10.png

用於生成BOT_ID的代碼段

生成的BOT_ID還用於初始化DES密鑰和IV,然後用於加密與C2的通信。

惡意軟件使用HTTPPOST請求進行通信,其中數據參數將以編碼形式作為請求主體的一部分進行傳播。然後,整個請求結構將顯示如下:

11.png

一個有效的響應應該以以下方式形成:

12.png

響應使用base64進行解碼:生成的有效負載是一個字符串數組,其中使用的分隔符是標準的Windows新行序列-“\r\n”。每一行都用base64再次解碼,用DES解密,並用GZIP算法解壓縮。

每個命令都具有以下結構:

13.png

命令結構

00:執行——使用指定的參數執行任意程序。如果攻擊者將NoWait標誌設置為False,則惡意軟件會重定向進程輸出,讀取數據並將其轉發給C2;

01:下載——從本地系統讀取文件並將其上傳到服務器;

02:上傳——使用攻擊者指定的文件路徑將接收到的數據保存到本地系統。

命令數據字段旨在攜帶有關命令參數的信息,並且對於每種操作類型具有不同的結構,如下所述:

14.png

命令結果通常被組成一條消息,該消息還包括底層命令類型和命令ID的值,該值唯一地標識向惡意軟件發出的命令的示例。這三個值用GZIP壓縮,用DES加密,並用base64編碼。

生成的有效負載使用“|”字符與BOT_ID連接,再次使用base64編碼,然後使用上述POST請求格式將其上傳到遠程服務器。

安裝程序模式一些變體可以感染系統,在特定位置創建惡意軟件的副本,並保證其持久性。

惡意軟件位置是通過特定進程選擇的,它枚舉CommonApplicationData中的所有子目錄,並隨機選擇一個子目錄保存其副本。生成的文件名將以子目錄的名稱作為後綴,並附加另一個靜態值Launcher.exe,如下所示:

15.png

如果操作成功,它還會更改新的文件時間戳,並使其與所選子目錄的時間戳相同。

如果操作失敗,它會隨機選擇另一個目錄,並再次嘗試複製惡意軟件。

如果對所有子目錄的操作都失敗,它將嘗試使用硬編碼目錄名列表:

马云惹不起马云Google

马云惹不起马云Viber

马云惹不起马云AdGuard

马云惹不起马云WinZip

马云惹不起马云WinRAR

马云惹不起马云Adobe

马云惹不起马云CyberLink

马云惹不起马云Intel

如果所有嘗試都失敗了,它將嘗試在以下位置使用相同的進程:

马云惹不起马云ApplicationData

马云惹不起马云LocalApplicationData

马云惹不起马云Temp

持久性能力惡意軟件的持久性通常通過以下機制來保證:

马云惹不起马云服務安裝;

马云惹不起马云創建新的Windows註冊表項值;

马云惹不起马云創建新的計劃任務;

該服務通常由惡意軟件在執行Windows sc.exe實用程序時安裝。

16.png

註冊表值等於復制的惡意軟件文件名,不帶擴展名,並存儲在以下各項中:

17.png

計劃任務是使用硬編碼的XML模板創建的,該模板在運行時被修改,並使用相同的惡意軟件文件路徑在文件系統釋放,但擴展名不同,為.XML而不是.exe。

然後將生成的XML文件與Windows schtasks.exe實用程序一起使用來創建任務。

例如:

18.png

任務和服務描述會根據變體而變化。

JackalStealJackalSteal是另一種植入程序,通常部署在一些受感染的計算機上,用於在目標系統中查找感興趣的文件,並將其竊取至C2服務器。

此工具可用於監控目標系統中的可移動USB驅動器、遠程共享和所有邏輯驅動器。惡意軟件可以作為標準流程或服務來工作。它無法維護持久性,因此必須由另一個組件安裝。

JackalSteal通過解析參數開始執行。

19.png

選項說明

马云惹不起马云-n:配置文件的唯一標識符值;

马云惹不起马云-p:要檢查的目錄路徑;

马云惹不起马云-s:請求文件的最大大小;

马云惹不起马云-d:自上次寫入請求文件以來的天數;

马云惹不起马云-m:使用正則表達式在配置的目錄中查找以逗號分隔的字符串掩碼列表;

马云惹不起马云-w:配置Profile的連續目錄掃描之間的時間間隔(以秒為單位);

马云惹不起马云-e:從掃描活動中排除路徑;

马云惹不起马云/0:作為標准進程運行;

马云惹不起马云/1:作為服務運行;

這些選項允許攻擊者指定“概要文件”,該文件定義了攻擊者感興趣的文件。該配置文件由一個ID和一個模式列表組成。每個模式都包含一個具有以下屬性的選項列表:

马云惹不起马云Path:目標路徑;

马云惹不起马云Credentials:用於訪問遠程共享的憑據用戶和密碼;

马云惹不起马云Masks:包含通配符和掩碼字符的掩碼字符串,可用於使用正則表達式匹配任何一組文件;

马云惹不起马云MaxSize:文件的最大大小;

马云惹不起马云Days:自上次寫入文件以來的天數;

马云惹不起马云Interval:兩次連續路徑掃描之間的時間間隔

马云惹不起马云Exclude:掃描活動期間必須排除的路徑;

用於配置JackalSteal組件的命令如下:

20.png

唯一標識符“-n”通常與JackalControl木馬程序生成的BOT_ID相同。

在參數處理之後,惡意軟件將數據序列化為XML,使用由帶有“-n”選項傳遞的ID生成的密鑰用DES加密它們,並將生成的有效負載存儲在以下位置:“%ApplicationData%\SNMP\cache\%Filename]”,其中%Filename%是由攻擊者指定的唯一標識符的MD5生成的GUID。

惡意軟件通常使用“/0”或“/1”選項和“-n”選項執行,該選項用於加載獲得的配置文件ID。在第二種情況下,它從前面提到的位置加載配置文件,並啟動‘Watchers’。

Watcher是在具有相同名稱的類中定義的對象,該對像在不同的線程中運行,並根據指定的選項掃描位置。該模式可以表示:

马云惹不起马云本地文件系統中的簡單路徑;

马云惹不起马云遠程共享上的路徑;

马云惹不起马云常量字符串all;

马云惹不起马云常量字符串usb。

當模式等於“all”時,惡意軟件會枚舉所有邏輯驅動器,並為每個驅動器創建一個新的Watcher對象。當模式為“usb”時,它會偵聽與在系統上創建新的可移動驅動器的操作相對應的系統事件。當檢測到新的驅動器時,它會創建一個新的Watcher對象。

每次添加新的Watcher時,惡意軟件都會通知日誌該事件,並使用HTTP Post請求將信息發送到遠程C2。

該日誌是使用以下字符串作為模板創建的:

21.png

並上傳到包含以下信息的加密有效負載中:

22.png

為每個請求生成AES_Key和AES_IV,嵌入在代碼中的密鑰使用RSA算法進行加密。生成的有效負載也使用GZIP算法進行壓縮。

“Agent_id\\Log_path.log”和“Log”內容數據採用AES算法加密,並使用GZIP壓縮。

Watcher對象負責掃描活動,當Watcher啟動時,它會枚舉目錄及其子目錄中的所有文件。掃描儀還可以解析.lnk鏈接。當掃描程序檢測到與定義的屬性(掩碼、天數、最大大小)匹配的文件時,它會計算文件內容哈希,檢查結果值是否存在於存儲在本地緩存目錄中的哈希表中,如果不存在,則添加該值。當檢測到新文件時,惡意軟件會使用上述相同的邏輯將該文件和相關的文件路徑上傳到加密有效負載中。

在這種情況下,加密的有效負載包含以下信息:

23.png

“Agent_id\\Local_file_path”和“File”內容數據採用AES算法加密,並使用GZIP壓縮。

JackalWorm

這種蠕蟲是為了傳播和感染使用可移動USB驅動器的系統而開發的。該程序被設計為一種靈活的工具,可以用來感染任何惡意軟件的系統。

它的行為會隨著父進程而變化。

马云惹不起马云當惡意軟件在被感染的系統上工作,並且父進程是taskeng.exe或services.exe時:

马云惹不起马云監控可移動USB驅動器;

马云惹不起马云連接設備後,將隱藏最後修改的目錄,並將其替換為蠕蟲的副本;

用於監控可移動USB驅動器的代碼與JackalSteal中觀察到的代碼相同。它創建了一個ManagementEventWatcher對象,允許它訂閱與給定WQL查詢相對應的事件通知,並在攔截時發出回調。惡意軟件使用的查詢指示系統每五秒鐘檢查一次邏輯可移動磁盤創建事件:

24.png

當惡意軟件檢測到一個可移動的USB存儲設備時,它會自我複製到該設備。它將復製到的路徑是通過列出所有目錄並選擇最後修改的目錄來確定的。它將使用相同的目錄名在驅動器根目錄上創建自己的副本,並將目錄的屬性更改為“hid

Google Drive將macOS 文件系統生成的'.DS_Store'文件標記為侵權。

'.DS_Store' 文件是蘋果用戶將壓縮文件或文件夾從macOS 系統轉移到非蘋果操作系統後伴隨生成的元數據文件,比如Windows 系統。近日,有用戶報告稱Google Drive將其保存的'.DS_Store'文件標記為違反谷歌的版權保護策略。上個月也有用戶有類似的體驗。

谷歌Drive將'.DS_Store' 文件標記為侵權Google Drive flags '.DS_Store' for copyright violation谷歌Drive將'.DS_Store' 文件標記為侵權

蘋果用戶在從macOS 設備複製ZIP文件和文件到Windows等非macOS 操作系統時經常會看到一個'.DS_Store' 文件。該文件是由macOS Finder應用自動生成的,用來存儲定制屬性和元數據,比如圖標信息和背景圖片位置。相關信息可以幫助用戶根據用戶首選項來渲染佈局。

在macOS 系統中,DS_Store文件在Finder應用中是隱藏的。該文件與Windows系統中隱藏的desktop.ini 和thumbs.db文件類似。

當用戶上傳壓縮文件和文件夾到Google Drive等第三方雲服務時,存儲服務提供商的文件管理器可能會顯示'.DS_Store'、'desktop.ini'和其他類似文件。

谷歌稱這是個例目前還不清楚引發這一行為的原因,BleepingComputer測試發現無法復現該問題。

一個可能的原因是谷歌根據校驗和來追踪版權內容,由於版權文件和該文件存在哈希碰撞使得觸發了報警。

上個月,就有Google Drive用戶稱其文件被錯誤地標記為違反了版權保護策略,而該文本文件中只含有0、 1、173、174、186這樣的數字。

nearly empty files erroneously flagged by Google Drive in January

1月份,幾乎為空的文件被Google Drive錯誤標記

由於校驗和哈希碰撞引髮用戶錯誤地版權保護標記的理論可以解釋部分用戶出現的這一問題。但是該理論目前還沒有經過證明。

谷歌發言人上個月解釋稱,1月發生的問題只影響一小部分Drive文件和用戶,而且谷歌已經糾正了所有被錯誤標記為版權侵權的文件,並採取了相應措施來預防這一問題的再次發生。

微信截图_20230827220556.png

攻擊者已經增加了對Linux系統的目標攻擊,並且像LaZagne(一種流行的開源密碼恢復工具)這樣的hacktool實用程序的易於訪問性使得攻擊者在惡意軟件攻擊鏈中使用它來轉儲密碼變得越來越方便。該工具對Linux用戶構成了重大風險,因為它針對的是Pidgin等流行聊天軟件,使用D-Bus API提取包括密碼在內的敏感信息。 D-BUS是一個提供簡單的應用程序互相通訊的途徑的自由軟件項目,它是做為freedesktoporg項目的一部分來開發的。

本文會介紹LaZagne如何利用Pidgin D-Bus API來獲取這些信息,以及為什麼密切關注D-Bus API是一種明智的安全舉措。另外,我們還將介紹具體示例,研究攻擊者如何在特定的惡意軟件活動中使用LaZagne。 pidgin是一個可以在Windows、Linux、BSD和Unixes下運行的多協議即時通訊客戶端,可以讓你用你所有的即時通訊賬戶中一次登錄。

支持eBPF的Linux的Advanced WildFire成功地檢測到D-Bus API相關的活動。 Palo Alto Networks的客戶可以通過YARA和行為規則來檢測與LaZagne攻擊相關的可疑活動。

D-Bus簡介Desktop-Bus,通常稱為D-Bus,是基於*nix的系統中的一種進程間通信(IPC)機制,它允許應用程序和服務相互有效地通信。 D-Bus使用客戶機-服務器體系結構,其中dbus-daemon應用程序充當服務器,應用程序充當客戶機。

D-Bus廣泛應用於NetworkManager, PulseAudio, systemd和Evolution等流行軟件中,它可以實現各種系統組件和應用程序之間的無縫通信。例如,Evolution電子郵件客戶端使用D-Bus與Evolution數據服務器等其他組件進行通信。該數據服務器處理存儲和管理電子郵件帳戶、聯繫人和日曆等任務。

Linux系統上的D-Bus API促進了應用程序和服務之間的通信,這可能會洩露敏感數據。因此,如果不對API進行監控,它們可能會帶來風險。 LaZagne hacktool利用Pidgin D-Bus API來轉儲憑證。 HackTool/SMBRelay是一個利用139端口截獲用戶機密信息,以獲取服務器訪問權限的木馬程序。

LaZagne如何竊取Pidgin文憑LaZagne連接到Pidgin客戶端的D-Bus API,並在應用程序運行時獲取帳戶憑證,包括用戶名和密碼。

1.png

LaZagne獲取帳戶憑證

下圖中的代碼顯示了LaZagne hacktool如何與Pidgin D-Bus API連接以檢索憑證。

2.png

LaZagne利用D-Bus獲取密碼

接下來我們會對上圖中高亮顯示的代碼進行詳細介紹:

1.get_password_from_dbus方法在Pidgin類中定義,它繼承自ModuleInfo類;

2.使用dbus.bus.BusConnection(session)為每個會話創建D-Bus連接。對於在紫色對像上調用的每個方法(作為Pidgin D-Bus API的實例創建),dbus-python庫內部處理D-Bus消息的創建、發送和接收;

3.PurpleAccountGetUsername(_acc), PurpleAccountGetPassword(_acc)和PurpleAccountGetProtocolName(_acc)方法用於與Pidgin應用程序交互。它們分別從Pidgin D-Bus API獲取每個帳戶的用戶名、密碼和協議名;

4.然後將提取的信息作為字典存儲在名為pwd_found的列表中。

一些可用於類似進程的低級libdbus庫API(如下圖所示)包括:

1.dbus_message_new_method_call (),為方法調用創建一個新的D-Bus消息;

2.dbus_message_append_args (),將參數附加到D-Bus消息;

3.dbus_connection_send_with_reply_and_block (),

發送消息並等待回复;

4.dbus_message_get_args (),從回复消息中提取參數。

3.png

LaZagne的Pidgin類的低級實現

LaZagne允許攻擊者轉儲除Pidgin之外的其他帳戶的憑證。它還可以通過D-Bus API轉儲KDE錢包(KWallet)密碼。 KWallet是Linux上KDE桌面環境使用的安全密碼管理系統,這些密碼是保存在KWallet系統中的個人密碼,其中可以包括網站密碼、電子郵件帳戶密碼、Wi-Fi網絡密碼或用戶選擇存儲的任何其他憑證。

攻擊者利用這些D-Bus API獲取敏感數據,各種公開來源記錄了在過去幾年中使用LaZagne的攻擊組織的案例。

惡意軟件活動中的LaZagneLaZagne在多個操作系統上的可用性使其成為攻擊者的一個有吸引力的工具。

2019年,疑似由伊朗贊助的攻擊組織Agent Serpens(又名Charming Kitten或APT35)利用LaZagne進行了一系列攻擊,從基於windows的系統中獲取登錄憑證。

2020年,Unit 42研究人員追踪到的活動集群為CL-CRI-0025(被其他公司追踪為UNC1945或LightBasin的攻擊者),使用包含各種工具(包括LaZagne)的自定義快速仿真器(QEMU)Linux虛擬機從意大利和其他歐洲地區獲取證書。

據報導,自2020年以來,我們追踪的攻擊者Prying Libra(又名Gold Dupont,導致RansomEXX勒索軟件攻擊的幕後黑手)使用LaZagne從目標主機提取憑證。

早在2021年7月,Adept Libra(又名TeamTNT)就利用LaZagne作為其Chimaera活動的一部分,從各種操作系統中竊取密碼,包括基於雲環境的Linux發行版。該活動至少持續到2021年12月,當時Adept Libra使用LaZagne從Kubernetes環境中的WordPress網站竊取密碼。

下表總結了黑客工具在各種惡意軟件攻擊活動中的使用情況:

4.png

2021年12月攻擊中使用LaZagne的bash腳本示例

5.png

TeamTNT LaZagne腳本(VirusTotal按哈西值計算的結果

複雜的組織在其活動中使用LaZagne突顯了該工具在捕獲密碼和實現進一步利用方面的有效性。

監控D-Bus API由於LaZagne可以利用D-Bus從運行的應用程序中提取敏感數據,我們可以監控D-Bus API調用來檢測此類可疑活動。庫跟踪工具,例如基於Extended Berkeley Packet Filter(eBPF)的工具,有助於公開D-Bus API調用。

下圖說明了使用bpftrace工具針對LaZagne黑客工具活動對D-Bus API的監控(SHA256:d2421efee7a559085550b5575e2301a7c2ed9541b9e861a23e57361c0cdbdbdb)。

Bpftrace是Linux系統的命令行工具,用於動態分析內核和用戶級程序。使用bpftrace工具,我們在dbus_message_get_args() API上設置監控器。我們使用這個API從應答消息中提取參數,該消息在libdbus-1.so.3共享對像庫中定義。

使用的單行bpftrace probe命令如下:

6.png

使用bpftrace監控D-Bus API

上圖顯示了Pidgin用戶名和密碼被LaZagne成功轉儲(在左側終端上),API調用被記錄在bpftrace輸出中(在右側終端上)。

掛鉤高級D-Bus API並記錄諸如進程標識符(PID)和程序名稱之類的詳細信息可能很有用,因為它們允許我們識別哪個進程正在調用API。

總結密切監控D-Bus API可能是防御者保護應用程序和連接系統免受惡意軟件和黑客工具攻擊的重要途徑。開發人員和網絡安全專業人員必須協作,隨時了解安全風險,並採取必要措施保護應用程序和敏感用戶數據。

隨著雲計算和物聯網的日益普及,強大的安全措施至關重要。支持eBPF的Linux的Advanced WildFire成功地檢測到D-Bus API相關的活動。

我們將在本文介紹解碼用於加載cobalt strike shellcode的簡單.hta加載器的過程,接下來用文本編輯器執行初始分析,並使用CyberChef提取嵌入的shellcode,將使用模擬器(SpeakEasy)驗證shellcode,使用Ghidra執行一些基本分析。

哈希:2 c683d112d528b63dfaa7ee0140eebc4960fe4fad6292c9456f2fbb4d2364680。將zip文件下載到一個安全的虛擬機中,並在感染密碼的情況下解壓縮,將顯示一個.hta文件。hta文件本質上是一個帶有嵌入式腳本的html文件,我們的目標是定位和分析嵌入的腳本。

1.png

由於.hta是一種基於文本的格式,我們可以直接在文本編輯器中打開該文件。

使用文本編輯器進行分析在文本編輯器中打開該文件將顯示一小段混淆的代碼,後面跟著一個大的base64 blob。

2.png

出於分析目的,我們不需要解碼初始部分,我們可以通過PowerShell命令的存在和分解的wscript.shell來判斷這一點。它通常從javascript執行命令。

3.png

使用初始腳本只執行base64 blob的方法,我們可以直接解碼base64。如果base64 blob不能解碼,可以返回到初始片段進行分析。

解碼Base64可以繼續突出顯示整個base64 blob並將其複製到cyberchef,現在可以嘗試解碼它。

4.png

將base64內容複製到CyberChef中,可以看到字符之間帶有空字節的明文,這通常表示utf-16編碼,很容易通過“decode text”或“remove null bytes”刪除。

5.png

通過在配方中添加“remove null bytes”,可以獲得看起來像PowerShell腳本的解碼內容。

6.png

使用“解碼文本”和“utf-16”也可以很好地工作。

7.png

這兩個選項都會產生一個解碼的powershell腳本,可以將其複製到一個新的文本編輯器窗口中。

8.png

PowerShell腳本分析現在將PowerShell腳本放入文本編輯器中,我們可以繼續掃描關鍵字或任何可能指示下一步操作的內容。

在腳本中間的十六進製字節的大blob,以及大量的api的引用,可用於分配(VirtualAlloc),寫入(memset)和執行(CreateThread)內存中的東西。

9.png

在腳本的底部有一些小的東西。該腳本休眠60秒,如果初始腳本失敗,會嘗試切換到64位版本的Powershell。

解碼十六進製字節使用CyberChef為了分析十六進製字節,我們可以復制它們並嘗試使用CyberChef解碼它們,通過複製以下字節並將它們移動到CyberChef來實現。

10.png

一旦複製,字節可以用一個簡單的“from十六進制”操作解碼。在本例中,逗號和0x被自動識別。

11.png

我們還可以看到,雖然內容被“解碼”,但看起來仍然不太好。

12.png

用CyberChef驗證ShellCode此時,驗證我們的假設,即解碼的內容是shellcode。一種常見的方法是在shellcode中查找明文值(ip, api名稱),這需要做額外的分析。

13.png

使用CyberChef,可以通過嘗試反彙編字節來驗證我們的理論,即內容是shellcode。我們需要將值轉換為十六進制,然後使用CyberChef的Disassemble x86操作。

14.png

在這裡,可以看到字節已經成功反彙編。

1.沒有明顯的紅色部分錶示反彙編失敗;

2.CLD :這是shellcode執行的第一個常見命令。

還有其他一些指標,如早期調用操作和錯誤0D操作,這些都是Cobalt Strike shell代碼常見的情況。這些模式看起來很奇怪,但在看過一些shellcode示例之後就很容易識別了。

現在,我們可以假設數據是shellcode,並通過嘗試執行它來做進一步的驗證。

此時,可以繼續分析反彙編字節,我們需要對x86指令有所熟悉。嘗試並執行代碼通常要容易得多。特別是對於較大的shellcode示例。

通過在模擬器中執行來驗證ShellCode為了進一步驗證數據是shellcode並嘗試確定它的功能,我們可以將其保存到一個文件中,並嘗試在模擬器或調試器中運行它。

在這種情況下,可以使用FireEye的SpeakEasy工具。你可以在這裡閱讀SpeakEasy,並從GitHub下載。

在運行SpeakEasy之前,我們可以先下載可疑shellcode的原始字節,確保刪除十六進制和反彙編x86操作。

15.png

你可以將文件命名為任何你喜歡的名稱,本文將其命名為shellcode.bin。

16.png

接下來,可以用以下命令在SpeakEasy工具上打開命令提示符。

-t :要模擬的目標文件;

-r :告訴SpeakEasy文件是shellcode;

-a x86 :告訴SpeakEasy假定x86指令。這幾乎總是x86或x64,如果其中一個失敗,可以試試另一個。

17.png

按下enter鍵,SpeakEasy就可以成功地模擬代碼。在這裡我們可以看到,為了從51.79.49[.]174:443下載一些東西,進行了許多api調用。

18.png

現在,可以安全地假設整個腳本和shellcode的主要目的是充當下載程序。此時,還可以調查到該IP地址的連接,並確定是否成功下載和執行了任何內容。

虛擬蜜罐是由一台計算機模擬的系統,但是可以響應發送給虛擬蜜罐的網絡流量,今天我們來淺析一下虛擬蜜罐。

蜜罐可以運行任何操作系統和任意數量的服務。蜜罐根據交互程度(Level ofInvolvement)的不同可以分為高交互蜜罐和低交互蜜罐。蜜罐的交互程度是指攻擊者與蜜罐相互作用的程度,高交互蜜罐提供給入侵者一個真實的可進行交互的系統,相反,低交互蜜罐只可以模擬部分系統的功能。高交互蜜罐和真實係統一樣可以被完全攻陷,允許入侵者獲得系統完全的訪問權限,並可以以此為跳板實施進一步的網絡攻擊。相反的,低交互蜜罐只能模擬部分服務、端口、響應,入侵者不能通過攻擊這些服務獲得完全的訪問權限。

蜜罐分為高交互蜜罐、低交互蜜罐、物理蜜罐、虛擬蜜罐。從實現方法上來分,蜜罐可分為物理蜜罐和虛擬蜜罐。物理蜜罐是網絡上一台真實的完整計算機,虛擬蜜罐是由一台計算機模擬的系統,但是可以響應發送給虛擬蜜罐的網絡流量。今天我們來淺析一下虛擬蜜罐。

1.png

對比物理蜜罐而言,虛擬蜜罐要容易得多。可以在一台計算機上部署數千個蜜罐,代價低廉,幾乎所有人都可以很容易地使用它們,並且使得其更加容易維護以及較低的物理需求。很多時候我們會使用VMware或者用戶模式的Linux (UML)等來建立虛擬蜜罐,這些虛擬系統工具可以在一台物理計算機上運行多個蜜罐系統及應用程序來收集數據。

虛擬蜜罐通常會模擬出真實的操作系統,並將其部屬在一台宿主主機上。在虛擬系統中虛擬出漏洞,產生虛假的流量,偽裝不存在的文件地址,存儲真實但無意義的文件,對網絡中的各種信息進行模擬等,來更好的吸引入侵者的攻擊虛擬蜜罐。

一是IP地址的空間欺騙。用一台主機就可以完成,利用在一個網卡來分配複數個IP地址,並對每一個IP地址配置單獨的MAC地址,可以完成多個主機的虛擬。

第二個是仿真網絡流量。因為虛擬蜜罐在一般情況下不會與其他主機主動進行交互,也就沒有任何的網絡流量,容易被入侵者根據這一點識破虛擬蜜罐。所以產生方針流量以後,可以欺騙入侵者,使入侵者無法通過對流量的觀察來判斷虛擬蜜罐的存在。

第三個是系統的動態配置。在正常狀態下,一個虛擬蜜罐的狀態是靜態的,沒有交互和網絡流量,一些有經驗的入侵者可以通過觀察系統的狀態來判斷是否是虛擬蜜罐。而係統的動態配置正是針對這一點,虛擬蜜罐的系統狀態會不斷的發生變化,會盡可能的模擬一個真實係統的行為,防止入侵者輕易的就發現虛擬蜜罐,導致其失去作用。

第四個是組織信息欺騙。可以在虛擬蜜罐裡設置一些個人信息,或者存儲一些沒有意義的虛假信息、文件等,可以讓虛擬蜜罐看起來更像是一個有人使用的真實係統,增加對入侵者的迷惑性。

第五個是端口重定向技術。這種技術可以對地址進行數次轉換,區別真實和虛擬網絡,也可以對常用端口進行重定向,達到隱藏這些端口的目的。

當多個蜜罐組成網絡時稱為密網,而一個密網的核心是蜜牆,也就是密網網關。蜜牆主要功能:

數據捕捉:可以在不被入侵者察覺的情況下,對密網內所有的活動和網絡數據信息進行捕捉。

數據控制:對進出密網的數據進行流量控制。這樣可以在內部蜜罐被攻破以後,確保其所有的活動依然被限制在蜜網之內。

數據分析:幫助密網管理者簡化捕捉數據分析,並可以幫助計算機和網絡取證。

常用的實現虛擬蜜罐的技術主要有VMware、用戶模式Linux、Argos、LaBrea、Honeyd等。

(1)VMware技術VMware公司是老牌的虛擬化軟件公司之一,其提供了多種虛擬化軟件應對不同的狀況。虛擬化軟件表示軟件可以模擬一個完整的計算機系統,並且可以在同一個虛擬機上可能運行多個不同的操作系統。下面介紹VMware公司的一些產品,這些VMware產品相互之間的不同點。

實際安裝VMware 的物理機器,執行VMware進程的計算機和操作系統實例稱為主機(或宿主主機)。運行在虛擬機內部的操作系統被稱為客戶系統或客戶虛擬機。兩種系統之間的交互是完全透明的,例如在主機和客戶系統之間,使用VMware可以共享文件夾、複製粘貼各種文件。

虛擬系統起到一個類似於模擬器的作用,主機的物理CPU和內存資源可以被主機與客戶虛擬機共享,但同時客戶操作系統也可以從VMware中分配到一套完整的虛擬硬件資源。例如,在多個客戶系統中,一套相同的虛擬硬件資源可以被所有的客戶系統所使用,就像同一配置的多台計算機安裝不同的操作系統,而且這些虛擬硬件可以在不超過客戶虛擬機配置的情況下任意的進行設置,不需要考慮真實物理硬件資源,這些硬件資源都可以連至主機系統。

2.png

(2)用戶模式Linux用戶模式Linux 是另一種可以用來創建虛擬蜜罐的系統,用法十分簡單,但是與VMware相比,主要缺點就是它只能模擬Linux系統。

UML是一個Linux內核的體系結構端口,系統內稱為接口。 Linux內核本身可以作為一個用戶進程來運行,實際的Linux內核(主機系統〉執行另外一個Linux(客戶系統)實例,把它作為一個進程。這個過程與VMware 中的虛擬機類似,每一個UML實例都是一個完整的虛擬機,與一個真實的計算機幾乎沒什麼區別。於是就有了一個簡單的方法來實現虛擬機,直接使用UML建立一個虛擬蜜罐,獲得一個虛擬系統提供的所有優點。在配置或穩定性上,客戶系統不會影響到主機系統。UML的塊設備,也稱為磁盤,通常是主機文件系統上的文件,不會影響存儲正常數據的本地塊設備。

UML作為一個操作系統只能運行在Linux上,所以如果運行Windows 或其他系統的時候,不能使用這種方式創建蜜罐。看起來只能選擇Linux系統缺點很嚴重,但也並非沒有好處,使用UML可以方便的創建許多不同的運行Linux的蜜罐。由於UML的塊設備是正常的文件,客戶系統使用這一文件(通常稱為根文件系統)作為一個完整的文件系統,可以很容易的把一個UML實例從一台機器上移植到另一台機器上。 UML 的另一個選項實用性也很強,能夠在寫時復制(copy-on-write,COW)模式下使用文件,UML實例在只讀模式下使用跟文件系統,把所有的更改寫入到一個單獨的文件中-COw文件,使得幾個蜜罐可以同時使用一個根文件系統,即可以節省磁盤空間,又可以便於維護管理。

(3)ARGOS荷蘭阿姆斯特丹自由大學的研究人員開發了一種新型的虛擬高交互蜜罐,該工具被稱為Argos,能夠自動檢測零天(zero-day)攻擊,也就是尚無補丁的攻擊。他們使用一種名為動態污點分析的技術來監測蜜罐:第一步,標記所有通過網絡接收到的數據,通過內存追踪這些標記數據,一旦這些標記數據被使用,影響了執行流程,Argos檢測到這些並產生一個攻擊的內存痕跡。相對於其他虛擬蜜罐解決方案,Argos不只是執行客戶虛擬機,同時還密切監測蜜罐,試圖及時發現攻擊者成功攻陷蜜罐的切入點。

動態污點分析是Argos技術的核心,這種技術根本在於觀察,一個攻擊者控制一個給定程序的執行流程,他一定會是使用某種方式影響它,但不論是何種方式,攻擊者都必須向程序發送一個不正常的輸入,這樣的數據必定會影響執行流,例如,跳轉到攻擊者提供的數據。

在這一過程中,動態污點分析發揮作用,一個程序的所有外部輸入都被當作污點被標記。在分析過程中,密切監視和檢查所有污染變量的使用,當一個污染變量通過其他操作得到的結果也被認為受到污染:但如果一個污染變量被賦予一個固定值,則認為該變量不再是受污染變量。這樣就可以跟踪外部輸入的使用,一旦這種污染輸入用於改變執行流,就可以被檢測出來。對Argos 來說,它產生的信息轉儲包含引起正常執行流偏離的相關信息。這個方法對檢測網絡攻擊靈敏度很高,而且我們檢測攻擊無需任何先驗知識。當一個攻擊發生時,我們可以精確地檢測到,通過分析確定導致該事件的原因。

(4)LaBrea由Tom Liston 創作的LaBrea,因引入了一個tarpit概念而聞名。 tarpit是一種服務,作用是通過使TCP連接非常緩慢或完全停止它們的進程,試圖減緩垃圾郵件發送者發送速度甚至是蠕蟲的傳播速度,雖然tarpit並不能減緩更高級的蠕蟲傳播,然而,對於順序操作的簡單蠕蟲tarpit具有良好的作用。

在網絡上運行LaBrea時,它會發現空閒的IP地址,並代替它們應答連接。一旦連接被建立起來,LaBrea會通過在TCP協議中採用技巧而盡可能長時間地黏住發送者,這樣建立的連接會進入到一種不能再取得任何進展的狀態。拖延連接的原因很簡單,垃圾郵件或病毒發送者在服務器上每多維持一個連接,就減少了向真正的主機發送垃圾郵件的可用資源。

為了檢測一個IP地址是否可用,LaBrea利用ARP協議。每當路由器試圖向一個IP地址交付一個數據包時,它首先需要找到相應的MAC地址,如果沒有主機監聽這一IP地址,ARP不會獲得應答。

例如:12:20:40.439476 arp who-has 192.168.1.123 tell 192.168.1.2

由於ARP在整個網絡上進行廣播,LaBrca 監視來自路由器的ARP請求,如果網絡中沒有主機相應IP地址192.168.1.123,LaBrea就會發送自己的應答:

12:20:42.356431 arp reply 192.168.1.123 is-at 00:3c:2f:1e:52:7a

現在路由器收到了一個MAC地址,就會把這個數據包以及後去的數據包發送給LaBrea 主機。但當一個主機重新啟動,它可能會使用一個已經被LaBrea佔用的IP地址,不過重啟的主機會發送一個無需應答的ARP請求,通知網絡上的所有人新的IP地址和MAC的綁定,那麼LaBrea將會放棄該IP地址。 LaBrea接受網絡上所有空閒的IP地址的TCP連接,當它收到一個SYN包,它就會通過完成TCP 三次握於建立一個連接,然後拖延這個連接。 LaBrea支持兩種放慢連接傳輸速度的方法:

窗口調節:LaBrea接受一個新的連接,但會公佈一個非常小的接收窗口。接收窗口指示發送者,每個數據包不能發送大於窗口允許長度的數據。當採用窗口調節時,連接仍然在繼續,但當一個1000字節長度的包被要求以10個字節長度位單位進行傳輸,顯然傳輸時間會變得非常漫長,速率會變的非常緩慢。

持久捕捉:LaBrea 公佈一個TCP接收窗口的大小為0,指示發送者在繼續發送數據前等待。發送者周期地回訪,發送窗口探測數據包,以確定接收窗口是否再次打開,這種狀態可以一直持續下去。

當垃圾郵件發送者試圖通過一個La Brea 蜜罐發送電子郵件時,SMTP事務將不產生或者產生很小的進程,一個啞垃圾郵件發送者將保持該連接,浪費網絡資源。最終,垃圾郵件發送者一旦發現和La Brea會話沒有取得進展,它可能走掉。

當我們使用DHCP用於IP地址動態分配,LaBrea將接管DHCP地址範圍內目前尚未使用的地址。 DHCP服務器在分發一個IP地址前,往往首先ping該地址,但是LaBrea對ping 的響應會干擾DHCP服務器的判斷。隨著時間的推移,用戶歸還了他們租用的IP地址,最後LaBrea將接管整個DHCP地址空間。所以一個用戶需要知道哪些地址是被他的DHCP服務器使用,並在配置文件中排除它們。

3.png

(5)HoneydHoneyd是一種框架,可以把數千個虛擬蜜罐及對應的網絡集成到一起。通常我們使用Honeyd集成現有網絡上所有未分配的IP地址,對每一個IP地址,都可以設置Honeyd模擬不同的計算機行為。

一般的來說,當一個蜜罐只使用一個IP地址時,可能需要相當長的一段時間才可以探測到攻擊,但當你擁有的IP地址多達成百上千時,可以大大加快被攻擊的速度,這就是Honeyd的作用,以一個低交互虛擬蜜罐的框架,在一個網絡或者Internet 上建立數千個虛擬蜜罐,充分的利用未分配的網絡地址,來更多的觀察攻擊行為,或者用來阻止入侵者攻擊真實係統。

Honeyd通過路由器或代理ARP為其虛擬蜜罐接受流量,對於每一個蜜罐,Honeyd可以模擬不同的操作系統的網絡棧行為。

Honeyd的特性Honcyd可以同時模擬數幾千個不同的虛擬主機:入侵者可以通過網絡與每一個單獨的主機進行交互。可以通過配置Honeyd得到每個主機的不同行為。

通過配置文件可以配置任意服務:當入侵者與虛擬主機進行交互時,Honeyd可以提供與對手交互的任意程序,這些程序服務都可以使用配置文件進行配置。無論何時Honeyd收到一個新的網絡連接,都可以及時啟動事先配置好的服務或者程序,回應入侵者。即使不運行相應的程序,Honeyd也可以作為代理將連接轉接到其他主機上,或者採用類似於被動指紋識別的功能,識別遠程主機和負載的隨即採樣。

在TCP/IP協議棧層次模擬操作系統:這一特性允許Honeyd 欺騙Nmap和Xprobe,讓他們相信一個虛擬蜜罐上正運行著各種配置的操作系統。組建自由路由拓撲:路由拓撲可以任意複雜,可以配置延遲、丟包和帶寬等特徵。 Honeyd支持非對稱路由、物理機器集成到一個虛擬拓撲中,以及通過GRE隧道的分佈式操作。

子系統虛擬化:利用子系統,Honeyd可以在一個蜜罐的虛擬空間下執行真正的UNIX應用,如Web服務器、Ftp服務器等等。這一特徵也允許虛擬地址空間內進行動態端口綁定和網絡連接的後台初始化。

4.png

Honeyd的體系結構Honeyd使用一個簡單的體系結構,一個中央包分發器接受所有入侵者的網絡流量,基於實現確定好的配置,對收到的數據流量來創建不同的服務進程處理,為了匹配所配置操作系統的特徵,使用個性引擎所修改發送出去的網絡數據包。

雖然通過對Honeyd 的配置可以控制它的每一個方面,但是三個重要特徵決定了Honeyd的整體行為:

一是入侵者只能從網絡中與Honeyd進行交互,我們的基本假設是入侵者不能走近計算機或者鍵盤進行登錄,因為任何一個Honeyd模擬的蜜罐沒有與之對應的物理計算機,Honeyd不是模擬操作系統的每一個方面,只有模擬其網絡堆棧所以入侵者永遠無法獲得對一個完整系統的訪問,但是可以通過與虛擬機如VMware相結合,減小Honeyd的這一問題。

二是Honeyd 可以在網絡上佈置大量的虛擬蜜罐,即使分配大量的IP地址Honeyd也都能模擬出,可以具有不同的操作系統和服務,也可以模擬任意的網絡拓撲結構,並支持網絡隧道。

三是可以欺騙指紋識別工具,Honeyd可以反轉指紋識別工具的數據庫,找到數據庫中指紋識別的特徵,當一個蜜罐需要發送一個網絡數據包時,可以通過查找數據庫,改變所有的數出數據包內容,使它們與配置的操作系統特徵相匹配。

結語虛擬蜜罐技術具有物理蜜罐技術的諸多特性,並可以在單一的系統中運行成百上千個虛擬蜜罐,還可以添加諸多應用程序,如網絡誘餌、蠕蟲探測、垃圾郵件阻止、網絡模擬等。相對於物理蜜罐複雜的部署、高額的費用、超長的耗時,虛擬蜜罐技術作為蜜罐技術的突破性解決方案讓網絡安全防護成本降低、效率增加,在網絡安全技術方面也同樣有著重要的作用。