频频闯祸的JNDI到底是个什么玩意儿?

每次规模比较大的漏洞,JNDI好像都不会缺席。最近人尽皆知的Log4j2漏洞也和它有关,让人 不由得怀疑,是不是作者开的后门。

因为JNDI这个玩意,别说用过,很多人连听都没听说过。这么冷门酸爽的东西,有什么理由把它放在一个日志框架里呢?恐怕只有作者想得通。

数据库驱动

很多人接触JNDI,是从数据库的驱动开始的。当然,随着SpringBoot单体发布模式的流行,现在用这种方式来获取数据库配置的古董公司,是越来越少了。

比如,我们可以在tomcat得server.xml里,配置一个叫做xjjdogDB的资源。

<Resource name="jdbc/xjjdogDB" auth="Container" type="javax.sql.DataSource"
maxTotal="100" maxIdle="30" maxWaitMillis="10000"
username="xjjdog" password="123456" driverClassName="com.mysql.jdbc.Driver"
url="jdbc:mysql://localhost:3306/xjjdog_db"/>

那么,我们只需要在SpringBoot中配置上JNDI这个名字,它就能加载正确的配置。前提是我们需要把SpringBoot服务打包成WAR包发布。像JBoss这样的宣称企业级服务器的软件,就喜欢这么干。

spring:
  datasource:
 jndi-name: jdbc/xjjdogDB

从这里,我们可以看出。JNDI到底是个神马玩意呢?你可以认为它是一个配置中心,也可以认为它是一个命名服务。其根本功能,就是让你可以通过一个简短的字符串,就能获取一系列的复杂配置和初始化后的功能。

这样,我们就可以避免将这些配置直接写在项目里。程序启动起来,到底加载的什么东西,要看运行的环境配置的什么东西。

具体实现的话,不就是一个可以根据key获取value的HashMap嘛。

危险由此而来

关键是这个value,它不是String,它是一个Object。要从字符串变身为一个正常的类,还要做到通用,那就不得不依靠反射。

图片

这张图是Oracle官方的一张关于JNDI的介绍。上面的都不是关键,关键的地方在于,JNDI通过SPI机制,可以和LDAP、RMI等各种技术,产生联动。

任何为了追求方便而不遵守常规的便捷通道,都会产生问题。SPI是为数不多的打破Java类加载机制的技术,和Unsafe类一样,强大但并不那么推荐使用。

图片

如上图,就是 NamingManager类里面的方法 getObjectFactoryFromReference。当它从本地加载相应类的时候,如果加载不到,它干了一件不该干但又不得不干的事情,那就是从网络上的代码里面构造相应的对象!

图片

这下,在炫肌肉的同时,可完犊子了。如上图,我们只需要在8000端口启动一个nginx。或者直接使用python启动一个小小的web服务器。

python -m http.server 8000

能够发起外网请求的服务器,将会乖乖的自动从我们指定的服务器上捞下非法的class文件进行加载。

制作这些攻击性的playload也非常容易,有marshalsec这样的工具,可以很方便的生成。

根据java的类加载机制,在static代码块里面,就可以干一些实际的代码执行逻辑。我们只需要把编译后的a.class放在该放的地方,JNDI这玩意就能够加载它。

public class a {
    static {
        try {
            String[] cmd = {"calc.exe"};
   java.lang.Runtime.getRuntime().exec(cmd).waitFor();
        } catch ( Exception e ) {
            e.printStackTrace();
        }
    }
}

上面的代码将会在你部署的服务器上启动一个calc计算器。当然,它还可以干更多事情。

END

从上面可以看出,Java的反射很强大,但是也很危险。SPI功能继承了这个特性,勇猛的暴露了它的弱点。我觉得功能很好啊,但它为什么要存在于日志框架呢?

这可能是因为卷吧。毕竟一个日志框架,也是要有元宇宙的梦想的!