正文

办公软件历史远程命令执行漏洞分析

admin
admin V管理员 /0 评论 /19 阅读
0321
此篇文章发布距今已超过1145天，您需要注意文章的内容或图片是否可用！

 

0x00前言

这个漏洞是 国家电网公司信息与网络安全重点实验室 发现的，并在公众号上写了比较详细的分析，但是没有给出具体的poc。现在微信公众号已经将文章删除，但其他的安全公众号仍留有记录，看了一下分析过程，故想要跟着分析漏洞成因，编写poc，因此才有了这一篇分析文章。

 

0x01分析过程

1.客户端分析

访问http://ip:port/index.jsp 会提示有两种方法登录系统，一种是通过下载客户端、一种是使用浏览器访问。因为，浏览器访问的方式需要依赖不同用户设备上的java版本，IE浏览器，系统配置等环境因素，使用起来不是很方便，所以为了解决这些问题，用友提供了系统专用的UClient浏览器，可直接通过该浏览器访问nc而无需安装配置任何东西。

下载NClient并安装后，进入启动页面，可以选择添加应用。添加完后，在安装目录中可以看到所安装的应用。

点击app.esc发现直接启动了nc客户端，查看文件内容，发现执行了NClogin65.jar文件中的nc.starter.test.JStarter：

反编译NClogin65.jar，查看nc.starter.test.JStarter，调用nc.starter.ui.NCLauncher#main主要是与远程服务端通信，生成uI之类的操作。主要的通信代码并不在该jar包，继续在目录中寻找。

在nc_client_homeNCCACHECODE目录的子目录中有很多的jar包，其中external目录上的jar包是客户端通信的逻辑代码。

随便点了一两个包，发现类还不少，如果逐个看的话很耗费时间，效率还不高，看了分析的文章发现用javaagent把调用的类都打印出来的方法可以解决这个问题，具体原理感兴趣的可以去网上搜索相关的文章，具体可以代码可以参考javaagent项目中使用。

之前在app.esc文件中可以看到启动jar的jvm配置信息，加上我们的javaagent的jar包，这样才能正常加载自己的javaagent。

启动后可以看到把所有调用的类都输出出来了。

这里可以配合idea的远程调试，添加参数jdwp：

-agentlib:jdwp=transport=dt_socket,server=y,address=8000

打开客户端，随便输入账号密码点击登录后，查看log可以看到有login字眼的类：

找到对应的nc.login.ui.LoginUISupport类，这个类方法很多，我一开始想的是通过一般登录都是带有request，response的，所以我就搜了request的关键字，在一个看起来比较像处理登录请求的方法下了断点，点击登录后果然是在这个地方断下来了。该方法主要是将输入的用户名、密码等值，在requestd类的变量赋值。

执行getInstance(),获取NCLocator的实例，并执行实例的lookup方法。

跟进nc.bs.framework.common.NCLocator#getInstance(java.util.Properties)

刚启动的时候locatorMap为空，则会在下面的判断分支中，创建RmiNCLocator实例并将该实例存放到locatorMap中。

locator = (NCLocator)locatorMap.get(key);
        if (locator != null) {
            return locator;
        } else {
            if (!isEmpty(locatorProvider)) {
                locator = newInstance(locatorProvider);
            } else if (!isEmpty(svcDispatchURL)) {
                locator = newInstance("nc.bs.framework.rmi.RmiNCLocator");
            } else {
                locator = getDefaultLocator();
            }

            locator.init(props);
            locatorMap.put(key, locator);
            return locator;
        }

获取到RmiNCLocator实例后，跟进到lookup方法：

//nc.bs.framework.rmi.RmiNCLocator#lookup

public Object lookup(String name) throws ComponentException {
        Object result = null;

        try {
            result = this.remoteContext.lookup(name);
            return result;
        } catch (Throwable var4) {
            if (var4 instanceof FrameworkRuntimeException) {
                throw (FrameworkRuntimeException)var4;
            } else {
                throw new ComponentException(name, "Component resolve exception ", var4);
            }
        }
    }

调用了this.remoteContext.lookup(name);,继续跟进：

//nc.bs.framework.rmi.RemoteContextStub#lookup

public Object lookup(String name) {
        Object so = this.proxyMap.get(name);
        if (so != null) {
            return so;
        } else {
            ComponentMetaVO metaVO = this.getMetaOnDemand(name);
            if (metaVO == null) {
                throw new ComponentNotFoundException(name, "no remote componnet found from server");
            } else {
                so = this.proxyMap.get(metaVO.getName());
                if (so != null) {
                    return so;
                } else {
                    RemoteAddressSelector ras = new GroupBasedRemoteAddressSelector(this.getRealTarget(metaVO), this.getServerGroup(metaVO));
                    so = RemoteProxyFactory.getDefault().createRemoteProxy(RemoteContextStub.class.getClassLoader(), metaVO, ras);
                    this.proxyMap.put(metaVO.getName(), so);
                    return so;
                }
            }
        }
    }

可以看到先从proxyMap中查看是否存在参数name的方法，如果存在则直接返回，不存在则进入另外的分支。因为这里我是刚启动的，所以该方法是不存在的，也可以直接将so赋值为null，进去到下面的分支。

跟进nc.bs.framework.rmi.RemoteContextStub#getMetaOnDemand,又可以看到调用了this.remoteMetaContext.lookup(name);方法，这个变量remoteMetaContext是nc.bs.framework.server.RemoteMetaContext类，那么这个类是怎么来的呢？

这里可以去看nc.bs.framework.rmi.RemoteContextStub#RemoteContextStub的构造函数，第65行创建了一个代理，并赋值到this.remoteMetaContext：

了解java代理的都知道不管用户调用代理对象的任何方法，该方法都会调用处理器(即Proxy.newProxyInstance()的第三个参数)的invoke方法，这里即是nc.bs.framework.rmi.RemoteInvocationHandler#invoke。不懂的可以先看这里。

那么现在回到上面，跟进this.remoteMetaContext.lookup(name);，果然进入到了invoke方法。经过一番判断

执行this.sendRequest(method, args)方法。

//nc.bs.framework.rmi.RemoteInvocationHandler#sendRequest(java.lang.reflect.Method, java.lang.Object[])

public Object sendRequest(Method method, Object[] args) throws Throwable {
        InvocationInfo ii = this.newInvocationInfo(method, args);
        Address old = null;
        int retry = 0;
        ConnectorFailException error = null;

        do {
            Address target = this.ras.select();
            if (old != null) {
                Logger.error("connect to: " + old + " failed, now retry connect to: " + target);
                if (old.equals(target)) {
                    try {
                        Thread.sleep(this.retryInterval);
                    } catch (Exception var13) {
                    }
                }
            }

            this.restoreToken(ii, target);

            try {
                Object var8 = this.sendRequest(target, ii, method, args);
                return var8;
            } catch (ConnectorFailException var14) {
                ++retry;
                old = target;
                error = var14;
            } finally {
                this.storeToken(ii, target);
            }
        } while(retry < this.retryMax);

        throw error;
    }

继续跟进this.sendRequest(target, ii, method, args);,在第182行将ii序列化输出，发送到http://server:port/ServiceDispatcherServlet ，并获取服务端返回的结果反序列化，回显到客户端。

到此客户端的处理流程大致分析完成，看到这里大家可能有会对上面客户端将类序列化发往服务端，那服务端肯定要反序列化呀，会不会有问题？

2.服务端分析

先来分析jndi注入的形成

在nc.bs.framework.comn.serv.CommonServletDispatcher#doPost第38行下断点。

跟进this.rmiHandler.handle(new HttpRMIContext(request, response));,跟进后在第85行继续跟进this.doHandle(rmiCtx);。

在第153行出现处理客户端提交内容的，继续跟进：

在第282行可以看到直接将输入流的内容反序列化了，代码执行过程中完全没有任何的过滤，确实存在触发反序列化漏洞，这里先不管，继续往下。

这里注意的是第286行将反序列化后的类赋予到抽象类nc.bs.framework.rmi.server.AbstractRMIContext#invInfo的invInfo变量里，这个变量在下面用到。

回到刚才的第二个断点，跟进result.result = this.invokeBeanMethod(rmiCtx);,这里第333行就是上面说到的invinfo变量，实际就是反序列化后的类。

这里有两个分支，不管是哪个都存在jndi注入，因为这里lookup的参数service是可控的，所以必然存在漏洞。

3.效果演示

这里就不给poc了，如果看懂了上面的过程其实也不难，实际就是构造一个InvocationInfo类，并将servicename的值设置为远程恶意类，序列化后发送到服务端触发jndi注入即可。

4.前面的反序列化

上面发现的反序列化根本都没有过滤的，为啥还要这么麻烦要jndi注入呢，直接反序列化不香嘛？看了web的依赖环境，commons-collections3.2，那不是现成的利用嘛。

直接ysoserial生成恶意类发送，弹计算器。

整个调用栈如下:

 

0X02 最后说几句

漏洞过程并不是太复杂，应该不难理解的。因第一次写文章且本人水平有限，故有错误的地方望大佬们扶正，手下留情。

 

0X03参考链接