从零到一学挖洞|xxl-job 2023远程命令执行漏洞分析记录

看到了微步的漏洞预警信息，于是想从零开始记录一下nday漏洞的复现过程。虽然这次涉及代码审计很少，但也算一个路径，就记录一下吧。

首先看预警信息

首先提取关键词：accessToken默认、在application.properties中配置、绕过认证调用 executor

接下来我们去xxl-job的官方仓库找这个文件

该文件有多个但内容一致，这里选择xxl-job-admin下的为例。我们能看到application.properties中accessToken确实有个配置项，其值就为default_token。因为properties是个纯静态文件，所以不存在什么语法变量，确定就是这几个字符“default_token”

好，现在我们确定了accessToken的值，这将是我们构造payload的关键。接下来我们要弄清楚通过这个值可以绕过什么。也就是预警信息中所说的executor

查看项目目录，发现了一个相似的文件夹

点开看里面

又有两个，而且里面出现了frameless和springboot，推测是两个版本或者编译方式。

这里不敢继续深入，不了解话可能会变成无底洞让我钻进牛角尖。那么回到最开始，看一看官方文档，看看从里面能发现什么信息便于我们了解软件架构。

通过文档我们可以知道xxl-job其实是分为两部分是类似于docker的那种c/s结构，或者说类似于中台/agent架构。调度中心（默认端口8080）就是xxl-job-admin，而执行器（默认端口9999）则就是所谓的executor。执行器接收调度中心发出的命令，在所在机器上执行后并返回结果。而接收上级指令一定有一个身份验证来保证不被滥用，这个验证就是accessToken。

那么现在我们大致就理清漏洞的利用思路了，很简单就是构造一个调度中心的指令请求给执行器，当accessToken为默认时我们就可以冒用身份把执行器作为我们的木马去使用。那这个请求的格式是什么样的呢？最开始我从代码层面可是跟踪，但往深处太复杂就换个方向从互联网入手。搜索关键词：xxl-job executor rce，这时找到了一个很久以前的漏洞

点进去看，时同一个组建相同的问题。我们现在这个是默认值，这个洞则是空值。看下时间，最早2022年就有人复现分析了。那么他的payload我们能不能用呢？

很显然里面并没有提到accessToken这个字段，估计是因为空值的话根本不用传参。但是我们得到了另一个信息，组建之间通过RESTful API传送数据，那么这个字段格式在文档中就也一定有。回到文档去看

好了，可以直接根据文档去构造请求包了。（glueType字段还有别的类型自行摸索，可能会对bypass有利）

文章中的指纹我们也可以直接拿来用 即: shodan:invalid request, HttpMethod not support. 也就是body内容为invalid request, HttpMethod not support. 其他国产引擎语法请自行构造

接下来找个目标试试

成功执行命令并通过dnslog带出

如果默认值改了，则是这样

总的来说就是这样。但有些时候你会发现服务器的执行器打不了。这是因为c/s架构，agent不一定就非得在admin的那个机器上。这虽然降低了利用成功率，但某种意义上对内网横向起到了一定作用。

最后一个小彩蛋：

2022年执行器未授权漏洞之后官方做了补救措施，默认开始token。但他们却使用了一个固定的值进行硬编码。也就是这个修复开启了执行器绕过。正所谓，修了吗？如修 不知道为什么这么简单的一个漏洞竟然过了一年才爆出来

最后的话：虽然这次没有从代码审计的角度深入解析，但指出了另一条路，要善用网络搜索和已知漏洞，这往往也是一个捷径