0x00 前言
前兩篇文章我們對六款中間件的基本信息和相關的安全配置做了介紹，這篇文章我們主要就中間件常見的漏洞利用方式及修復方法做出講解。如果某些地方存在疑問可以對比着前兩篇文章閱讀，更好地加深理解。
0x01 Apache
解析漏洞是指非程序文件被異常解析為程序文件的漏洞，利用這種漏洞可以繞過一些安全檢測從而獲取webshell，Apache和IIS的解析漏洞是較為經典的漏洞場景。
Apache
在Apache 1.x和Apache 2.x中存在解析漏洞，它的利用形式如圖所示
可以看到圖中訪問的文件名為為test.php.xxx，正常情況下遇到一個未知的文件名應該是提示下載或者將文件顯示出來，但是這里執行了php代碼並顯示出phpinfo函數的執行結果，這就是Apache解析漏洞。test.php.xxx的內容為：
<?php
phpinfo();
?>
Apache在解析文件時有一個原則：當碰到不認識的拓展名時，將會從后向前解析，直到碰到認識的拓展名為止，如果都不認識則會暴露其源碼。那么Apache認識哪些文件名呢？在mime.type文件中有詳細的拓展名列表
這個問題本質是一個配置問題，新版本的Apache默認情況下已經不存在這個漏洞，不過人為的修改配置文件依然可以引起解析錯誤，比如在Apache的配置文件httpd.conf中加入：AddHandler php5-script.php，就可以觸發解析漏洞。
另外一種情況：如果在Apache中.htaccess可被應用（Apache的配置文件httpd.conf中對目錄的AllowOverride設置為All時，apache會應用目錄下.htaccess中的配置 By sfasfas），那可以嘗試在.htaccess中寫入:
<FilesMatch “shell.jpg”> SetHandler application/x-httpd-php </FilesMatch>
然后上傳覆蓋原有的.htaccess文件，再上傳一個shell.jpg木馬文件，這樣shell.jpg就可解析為php文件。
IIS
IIS解析漏洞也算是一種比較久遠的漏洞，在IIS5和IIS6下有下面這兩種方式
目錄解析：/xx.asp/xx.jpg
文件解析：xx.asp;.jpg
第一種，在網站下建立文件夾的名字為 .asp、.asa 的文件夾，其目錄內的任何擴展名的文件都被IIS當作asp文件來解析並執行。例如創建目錄1.asp，那么/1.asp/mm.jpg將被當作asp文件來執行。假設攻擊者可以控制上傳路徑名，那就可以以任意的后綴名上傳文件然后獲取shell了。
第二種，在IIS6.0下，分號后面的不被解析，也就是說xx.asp;.jpg會被服務器看成是xx.asp。IIS6.0 默認的可執行文件除了asp還包含這三種asa、cer、cdx。
在IIS7.0和IIS7.5版本下也存在解析漏洞，在默認Fast-CGI開啟狀況下，在一個文件路徑/xx.jpg后面加上/xx.php會將 /xx.jpg/xx.php 解析為 php 文件。常用利用方法：將一張圖和一個寫入后門代碼的文本文件合並，要使用二進制的寫入方式，避免破壞圖片文件頭和尾，命令如下：
copy xx.jpg/b + yy.txt/a xy.jpg
0x02 邏輯漏洞
IIS寫權限漏洞
這也是IIS的一個經典漏洞，他的本質是源於對服務器的WebDAV配置不當，現在IIS默認關閉了這個組件。
如果在IIS管理器開啟了這個組件，就會允許直接將文件PUT到服務器上去，從而導致漏洞發生。
利用方式也比較簡單，使用桂林老兵IIS寫權限利用程序即可
提交數據包后會在服務端生成一個1.txt文件
但是這個txt並不會解析執行，需要再執行一次MOVE操作將txt文件修改為asp可執行文件
然后就可以訪問shell
IIS短文件名漏洞
Windows下可以通過~表示短文件名，比如以某CMS生成的數據庫備份文件為例
那么它就可以表示為很短的文件名
該短文件名有以下特征：只有前六位字符直接顯示且相同，后續字符用~1指代，其中數字1還可以遞增，后綴名最長只有3位，多余的被截斷。同時在啟用.net的IIS下暴力列舉短文件名時有以下特性：訪問構造的某個存在的短文件名，會返回404；訪問構造的某個不存在的短文件名，會返回400。所以，利用這個特性，我們可以暴力破解網站文件。一旦爆破出了其文件名就可以直接訪問直接訪問
Tomcat 樣例目錄session操縱漏洞
Apache Tomcat默認安裝包含”/examples”目錄，里面存着眾多的樣例，其中session樣例(/examples/servlets /servlet/SessionExample)允許用戶對session進行操縱。因為session是全局通用的，所以用戶可以通過操縱 session獲取管理員權限。 示例如下，首先新建一個登陸表單login.jsp
再建一個后台模擬界面（用戶登錄才可進入）admin.jsp
然后是一個登錄驗證的代碼login2.jsp
如果直接訪問/examples/servlets/admin.jsp會跳轉到login.jsp，因為沒有登錄無法訪問
這個時候打開/examples/servlets/servlet/SessionExample
然后填入如下數據
提交后顯示session已經寫入
再次訪問admin.jsp即可成功訪問
0x03 Getshell
Tomcat后台獲取webshell
Tomcat后台管理目錄/manager/html中可以直接上傳一個war文件（用於遠程管理tomcat服務的腳本文件），來自動建立虛擬目錄。
因此可以將jsp木馬用打包后上傳，這里要首先壓縮為zip文件，然后將后綴改為war，上傳后服務器自動解壓，然后就可以訪問虛擬目錄下的木馬。比如上傳一個123.war的文件，上傳到后台后自動生成一個同名文件夾
文件夾里既是之前的壓縮的jsp木馬訪問即可
Weblogic后台獲取webshell
Weblogic后台webshell也是通過部署war包獲取的，其操作方法實質就是部署一個web項目，步驟如下。點擊“部署”==>“安裝”
然后上載文件，文件是一個包含webshell的war包
一直點擊下一步，最后完成並在左上角激活更改，然后啟動項目
然后shell即可訪問
WebSphere后台獲取webshell
WebSphere后台獲取webshell實質也是部署web程序的過程，將shell.jsp打包到war包中，然后新建應用程序。
一直點擊下一步直到安裝完成，最后記得保存。
然后將新添加的weShell項目啟動
然后訪問shell即可
Jboss后台獲取webshell
這里的后台指的是jmx-console，如果能夠進入Jboss的jmx-console首先可以看到很多敏感信息，比如這些相關鏈接
進入最后一個鏈接可以看到服務器的敏感信息
jmx-console也是通過上傳war包的形式獲取webshell，但是這個上傳有些不同。首先在jmx-console的首頁找到如下鏈接
在頁面中找到這么一個輸入框
在輸入框里輸入war包的外網路徑（需要將war包放到外網的服務器上），點擊Invoke，addURL方法會將war下載到本地，然后在頁面上方找到如下界面
點擊Apply Changes后war包才會部署生效，然后就可以執行shell。
0x04 Java反序列化漏洞
漏洞簡介
早在2015年的1月28號，國外研究人員Gabriel Lawrence 、Chris Frohoff 在AppSecCali上給出了一個報告，報告中介紹了Java反序列化漏洞可以利用Apache Commons Collections這個常用的Java庫來實現任意代碼執行，當時並沒有引起太大的關注。后來FoxGlove Security安全團隊的breenmachine 發布的一篇博客中介紹了如何利用Java反序列化漏洞，來攻擊最新版的WebLogic、WebSphere、JBoss等這些大名鼎鼎的Java應用，實現遠程代碼執行，在文中博主直指這是2015年最被低估的漏洞。由於Apache Commons Collections這樣的基礎庫有非常多的Java程序在使用，一旦編程人員誤用了反序列化這一機制，使得用戶輸入可以直接被反序列化，就能導致任意代碼執行，同時漏洞所造成的影響面也是非常廣泛的。
漏洞分析
序列化就是把對象轉換成字節流，便於保存在內存、文件、數據庫中；反序列化即逆過程，由字節流還原成對象。Java中的ObjectOutputStream類的writeObject()方法可以實現序列化，類ObjectInputStream類的readObject()方法用於反序列化。下面是將字符串對象先進行序列化，存儲到本地文件，然后再通過反序列化進行恢復的樣例代碼：
問題在於，如果Java應用對用戶輸入，即不可信數據做了反序列化處理，那么攻擊者可以通過構造惡意輸入，讓反序列化產生非預期的對象，非預期的對象在產生過程中就有可能帶來任意代碼執行。
在拿到一個Java應用時，需要找到一個接受外部輸入的序列化對象的接收點，即反序列化漏洞的觸發點。我們可以通過審計源碼中對反序列化函數的調用（例如readObject()）來尋找，也可以直接通過對應用交互流量進行抓包，查看流量中是否包含java序列化數據來判斷，java序列化數據的特征為以標記（ac ed 00 05）開頭。確定了反序列化輸入點后，再考察應用的Class Path中是否包含Apache Commons Collections庫（ysoserial所支持的其他庫亦可），如果是，就可以使用ysoserial來生成反序列化的payload，指定庫名和想要執行的命令即可：
java -jar ysoserial-0.0.2-SNAPSHOT-all.jar CommonsCollections1 'id >> /tmp/redrain' > payload.out
其中ysoserial是java反序列化工具，CommonsCollections1 是指定的庫名（本例的漏洞就是由於Apache Commons Collections庫造成的），whoami就是要執行的命令，生成的payload如圖所示
然后通過先前找到的傳入對象方式進行對象注入，數據中載入payload，觸發受影響應用中ObjectInputStream的反序列化操作，隨后通過反射調用Runtime.getRunTime.exec即可完成利用。
Weblogic
Weblogic曾多次被爆出反序列化漏洞，比如 CVE-2016-0638、CVE-2016-3510和CVE-2017-3248等。之所以頻繁出現跟他的修復策略有關，Weblogic采用黑名單的方式過濾危險的反序列化類，只要發現可用並且未在黑名單之內的反序列化類，那么之前的防護就會被打破，系統就會遭受攻擊。該漏洞影響WebLogic 10.3.6.0, 12.1.3.0,12.2.1.0, 12.2.1.1多個版本。利用程序如下（payload用上文提到的方法生成）
相應的自動化的檢測和利用工具在網上已有公開，下圖是利用本地搭建的環境進行的測試。
WebSphere
WebSphere的反序列化漏洞編號為CVE-2015-7450，漏洞文件為commons-collections.jar，對應端口為8880。默認情況下WebSphere會開啟10個端口用於從不同接口上獲取數據，在配置文件
IBM/WebSphere/AppServer/profiles/AppSrv01/properties/wsadmin.properties
中定義了8880端口的作用：用作SOAP協議的端口，用來交換特定的信息。
那么就可以使用如下payload檢測，其中的base64編碼是java序列化后的對象。
若返回如圖所示的內容則證明存在漏洞
想要生成自定義的payload需要執行上文提到的ysoserial命令，最后對生成的數據進行base64編碼然后將數據包中的payload替換即可。
Jboss
Jboss的Java反序列化漏洞與Weblogic和WebSphere基本是一致的，也是由於調用了存在漏洞的基礎庫Apache Commons Collections造成的，但是Jboss相對影響較小，因為要成功利用必須要找到程序接受外部輸入的點，而此處的利用需要/invoker/jmx的支持，大部分情況下的實際場景，jboss都刪除了jmx，所以讓此處的利用大打折扣。在利用方式上與上文提到的WebSphere基本一致，都是直接發送一個序列化的數據包，不過不需要base64編碼。漏洞利用時發送如下的報文即可，其中payload替換成自己生成的payload。
也有相對簡單的圖形界面工具
0x05 其他
Weblogic的SSRF漏洞的CVE編號為CVE-2014-4210，問題出現在UDDI功能上，用戶可以在這個界面進行信息搜搜
其中operator參數可以傳入一個內網URL於是造成了對內網信息探測或漏洞利用，如下圖所示探測IP為10.108.40.45的主機的端口號80，並提示返回提示，說明相應內網主機開啟了80端口。
