Log4j2 远程代码执行漏洞(cve-2021-44228)原理剖析

文章目录

      • 1、JNDI、RMI、LDAP、JNDI注入?
      • 2、Log4j2 rce原理
      • 3、影响版本
      • 4、修复思路

要了解本次Log4j2 rce的原理,首先我们得知道什么是JNDI,什么是JNDI注入,什么是RMI,什么又是LDAP…

本文中只讲原理,具体复现请转至:Log4j2 远程代码执行漏洞(cve-2021-44228)复现(反弹shell)

1、JNDI、RMI、LDAP、JNDI注入?

Java Name and Directory Interface:java命名和目录接口
是sun公司提供的一种标准的java命名系统接口,JNDI提供统一的客户端API,通过访问JNDI,根据命名服务或目录服务来获取相应的资源。

  • 命名服务:一种简单的键值对绑定(k,v),可以通过键名检索值,RMI(远程方法调用)就是典型的命名服务。
  • 目录服务:目录服务是命名服务的拓展,区别在于它可以通过对象的属性来检索对象,其实就是键比较复杂,比如找一个学生:年级->班级->姓名来查找,这些东西就是键,但是是层级关系,比较像目录。LDAP(轻量级目录访问协议)就是典型的目录服务。

说白了,其实JNDI只是对各种访问目录服务的逻辑进行了再封装,就是以前访问LDAP和RMI要写的代码差别很大,但是有了JNDI这一层(没有什么是加一层解决不了的,如果有就再加一层),就可以使用JNDI的方式来轻松访问RMI或LDAP服务,访问的代码基本是一样的(参考JDBC连接不同的数据库)
Log4j2 远程代码执行漏洞(cve-2021-44228)原理剖析_第1张图片
可以简单的将LDAP理解为一个存储目录,里面有我们要的资源,而JNDI就是获取资源的一种途径或者说方式。

如上图所示在访问RMI时只传了一个键foo过去,返回一个对象;在访问LDAP这种目录服务时,传过去的比较复杂,包含多个键值对,这些键值对就是对象的属性,LDAP根据这些属性来判断返回哪个对象。

基本操作:

  1. 发布服务:bind() 将名称绑定到对象中
  2. 用名字查找资源:lookup() 通过名字检索执行的对象

JNDI注入:

动态协议转换:JNDI提前有配置初始化环境,设置了属性,但是当lookup()里传进来的参数协议与初始化的Context里配置的协议不一致时,就会动态的进行转换来查找传进去的参数,并且不会报错,所以当参数可控时,攻击者可以通过提供一个恶意的url地址来控制受害者加载攻击者指定的恶意类。

ctx.lookup("rmi://your-server/refObj");// 初始化的
//ctx.lookup("ldap://your-server/cn=bar,dc=test,dc=org");//实际上传进来的

命名引用:Java为了将Object对象存储在Naming(命名)或Directory(目录)服务下,提供了Naming Reference(命名引用)功能,对象可以通过绑定Reference类存储在Naming或Directory服务下,比如RMI、LDAP等。

也就是说存储的V中可以是一个超链接,我们根据K去查找V,找到之后发现是引用就会去引用的地址继续找然后返回相应的资源。

总结:

  1. 在LDAP中可以存储外部的资源,叫做命名引用,对应Reference类。比如远程HTTP服务的一个.class文件
  2. 如果JNDI客户端基于LDAP服务,找不到相应的资源,就会去LDAP中默认指定的地址请求(初始化配置的),如果是命名引用,会将这个文件下载到本地。
  3. 如果下载的.class文件包含无参构造函数或静态代码块,加载的时候会自动执行。因为下载之后会进行自动实例化。

在使用Reference时,我们可以直接将对象传入构造方法中,当被调用时,对象的方法就会被触发,创建Reference实例时几个比较关键的属性:

  • className:远程加载时所使用的类名;
  • classFactory:加载的class中需要实例化类的名称;
  • classFactoryLocation:远程加载类的地址,提供class数据的地址可以是file/ftp/http等协议;

当然,要把一个对象绑定到rmi注册表中(前面提到对象可以通过绑定Reference类存储在Naming或Directory服务下),这个对象需要继UnicastRemoteObject,但是Reference没有继承它,所以我们还需要封装一下它,用 ReferenceWrapper 包裹一下Reference实例对象,这样就可以将其绑定到rmi注册表,并被远程访问到了,demo如下:

Reference refObj = new Reference("refClassName","insClassName","http://ip:port/");
//第一个参数是远程加载时使用的类名,第二个参数是加载的class中需要实例化类的名称,第三个参数是远程class文件存放的地址

ReferenceWrapper refObjWrapper = new ReferenceWrapper(refObj );//进行包装继承

registry.bind("refObj ",refObjWrapper );//发布服务,将键与值绑定起来

当有客户端通过lookup(“refObj”)获取远程对象时,获取的是一个Reference存根(Stub),由于是Reference的存根,所以客户端会先在本地的classpath中去检查是否存在类refClassName,如果不存在则去指定的url(http://ip:port/refClassName.class)动态加载,并且调用insClassName的无参构造函数,所以可以在构造函数里写恶意代码。当然除了在无参构造函数中写利用代码,还可以利用java的static代码块来写恶意代码,因为static代码块的代码在class文件被加载过后就会立即执行,且只执行一次。

听起来有点绕,其实这个上面也提到过(总结2、3)

JNDI注入流程:

Log4j2 远程代码执行漏洞(cve-2021-44228)原理剖析_第2张图片

2、Log4j2 rce原理

首先log4j打印日志有四个级别:debug、info、warn、error,不管哪个方法打印日志,在正常的log处理过程中,对${这两个紧邻的字符做了检测,一旦遇到类似表达式结构的字符串就会触发替换机制。
一旦在log字符串中检测到${},就会解析其中的字符串尝试使用lookup查询,因此只要能控制log参数内容,就有机会实现漏洞利用。
Log4j2 远程代码执行漏洞(cve-2021-44228)原理剖析_第3张图片
所以最终还是会去调用JNDI的lookup方法,所以知道JNDI的注入原理就很好理解这次漏洞形成的原因了

Log4j2 rce原理:
Log4j2 远程代码执行漏洞(cve-2021-44228)原理剖析_第4张图片

3、影响版本

1、使用了log4j的组件,并且版本在2.x <= 2.14.1
2、jdk版本小于8u191、7u201、6u211

jdk版本影响:

  1. JDK 6u45、7u21之后:java.rmi.server.useCodebaseOnly的默认设置为true。当该值为true时,将禁用自动加载远程类文件,仅从CLASSPATH和当前JVM的java.rmi.server.codebase指定路径加载类文件。使用这个属性来防止客户端从其他Codebase地址上动态加载类,增加了RMI ClassLoader的安全性。
  2. JDK 6u141、7u131、8u121之后:增加了com.sun.jndi.rmi.object.trustUrlCodebase选项,默认为false,禁止RMI和CORBA协议使用远程codebase的选项,因此RMI和CORBA在以上的JDK版本中已经无法触发该漏洞,但依然可以通过指定URI为LDAP协议来进行JNDI攻击。
  3. JDK 6u211、7u201、8u191之后:增加了com.sun.jndi.ldap.object.trustUrlCodebase选项,默认为false,禁止LDAP协议使用远程codebase的选项,把LDAP协议的攻击途径也给禁了。

4、修复思路

1、禁止用户请求参数中出现攻击关键字
2、禁止lookup下载远程文件(命名引用)
3、禁止log4j的应用连接外网
4、禁止log4j使用lookup

2.15版本修复方法:
修复后log4j2在jndi lookup中增加了很多限制:

  1. 默认不再支持二次跳转(命名引用)的方式获取对象
  2. 只有在log4j2.allowedLdapClasses列表中指定的class才能获取
  3. 只有远程地址是本地或者在log4j2.allowedLdapHosts列表中指定的地址才能获取

你可能感兴趣的:(渗透测试,java,log4j2,rce,jndi注入,ldap,rmi)