0x00 前言

前兩篇文章我們對六款中間件的基本信息和相關的安全配置做了介紹，這篇文章我們主要就中間件常見的漏洞利用方式及修復方法做出講解。如果某些地方存在疑問可以對比著前兩篇文章閱讀，更好地加深理解。

0x01 Apache

解析漏洞是指非程序文件被異常解析為程序文件的漏洞，利用這種漏洞可以繞過一些安全檢測從而獲取webshell，Apache和IIS的解析漏洞是較為經(jīng)典的漏洞場景。

Apache

在Apache 1.x和Apache 2.x中存在解析漏洞，它的利用形式如圖所示

可以看到圖中訪問的文件名為為test.php.xxx，正常情況下遇到一個未知的文件名應該是提示下載或者將文件顯示出來，但是這里執(zhí)行了php代碼并顯示出phpinfo函數(shù)的執(zhí)行結果，這就是Apache解析漏洞。test.php.xxx的內(nèi)容為：

<?php?

phpinfo();

?>

Apache在解析文件時有一個原則：當碰到不認識的拓展名時，將會從后向前解析，直到碰到認識的拓展名為止，如果都不認識則會暴露其源碼。那么Apache認識哪些文件名呢？在mime.type文件中有詳細的拓展名列表

這個問題本質是一個配置問題，新版本的Apache默認情況下已經(jīng)不存在這個漏洞，不過人為的修改配置文件依然可以引起解析錯誤，比如在Apache的配置文件httpd.conf中加入：AddHandler php5-script.php，就可以觸發(fā)解析漏洞。

另外一種情況：如果在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

第一種，在網(wǎng)站下建立文件夾的名字為 .asp、.asa 的文件夾，其目錄內(nèi)的任何擴展名的文件都被IIS當作asp文件來解析并執(zhí)行。例如創(chuàng)建目錄1.asp，那么/1.asp/mm.jpg將被當作asp文件來執(zhí)行。假設攻擊者可以控制上傳路徑名，那就可以以任意的后綴名上傳文件然后獲取shell了。

第二種，在IIS6.0下，分號后面的不被解析，也就是說xx.asp;.jpg會被服務器看成是xx.asp。IIS6.0 默認的可執(zhí)行文件除了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的一個經(jīng)典漏洞，他的本質是源于對服務器的WebDAV配置不當，現(xiàn)在IIS默認關閉了這個組件。

如果在IIS管理器開啟了這個組件，就會允許直接將文件PUT到服務器上去，從而導致漏洞發(fā)生。

?

利用方式也比較簡單，使用桂林老兵IIS寫權限利用程序即可

提交數(shù)據(jù)包后會在服務端生成一個1.txt文件

但是這個txt并不會解析執(zhí)行，需要再執(zhí)行一次MOVE操作將txt文件修改為asp可執(zhí)行文件

然后就可以訪問shell

?

?

IIS短文件名漏洞

Windows下可以通過~表示短文件名，比如以某CMS生成的數(shù)據(jù)庫備份文件為例

那么它就可以表示為很短的文件名

該短文件名有以下特征：只有前六位字符直接顯示且相同，后續(xù)字符用~1指代，其中數(shù)字1還可以遞增，后綴名最長只有3位，多余的被截斷。同時在啟用.net的IIS下暴力列舉短文件名時有以下特性：訪問構造的某個存在的短文件名，會返回404；訪問構造的某個不存在的短文件名，會返回400。所以，利用這個特性，我們可以暴力破解網(wǎng)站文件。一旦爆破出了其文件名就可以直接訪問直接訪問

?

?

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

然后填入如下數(shù)據(jù)

提交后顯示session已經(jīng)寫入

再次訪問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包的外網(wǎng)路徑（需要將war包放到外網(wǎng)的服務器上），點擊Invoke，addURL方法會將war下載到本地，然后在頁面上方找到如下界面

點擊Apply Changes后war包才會部署生效，然后就可以執(zhí)行shell。

?

?

0x04 Java反序列化漏洞

漏洞簡介

?早在2015年的1月28號，國外研究人員Gabriel Lawrence 、Chris Frohoff 在AppSecCali上給出了一個報告，報告中介紹了Java反序列化漏洞可以利用Apache Commons Collections這個常用的Java庫來實現(xiàn)任意代碼執(zhí)行，當時并沒有引起太大的關注。后來FoxGlove Security安全團隊的breenmachine 發(fā)布的一篇博客中介紹了如何利用Java反序列化漏洞，來攻擊最新版的WebLogic、WebSphere、JBoss等這些大名鼎鼎的Java應用，實現(xiàn)遠程代碼執(zhí)行，在文中博主直指這是2015年最被低估的漏洞。由于Apache Commons Collections這樣的基礎庫有非常多的Java程序在使用，一旦編程人員誤用了反序列化這一機制，使得用戶輸入可以直接被反序列化，就能導致任意代碼執(zhí)行，同時漏洞所造成的影響面也是非常廣泛的。

漏洞分析

序列化就是把對象轉換成字節(jié)流，便于保存在內(nèi)存、文件、數(shù)據(jù)庫中；反序列化即逆過程，由字節(jié)流還原成對象。Java中的ObjectOutputStream類的writeObject()方法可以實現(xiàn)序列化，類ObjectInputStream類的readObject()方法用于反序列化。下面是將字符串對象先進行序列化，存儲到本地文件，然后再通過反序列化進行恢復的樣例代碼：

問題在于，如果Java應用對用戶輸入，即不可信數(shù)據(jù)做了反序列化處理，那么攻擊者可以通過構造惡意輸入，讓反序列化產(chǎn)生非預期的對象，非預期的對象在產(chǎn)生過程中就有可能帶來任意代碼執(zhí)行。

在拿到一個Java應用時，需要找到一個接受外部輸入的序列化對象的接收點，即反序列化漏洞的觸發(fā)點。我們可以通過審計源碼中對反序列化函數(shù)的調(diào)用（例如readObject()）來尋找，也可以直接通過對應用交互流量進行抓包，查看流量中是否包含java序列化數(shù)據(jù)來判斷，java序列化數(shù)據(jù)的特征為以標記（ac ed 00 05）開頭。確定了反序列化輸入點后，再考察應用的Class Path中是否包含Apache Commons Collections庫（ysoserial所支持的其他庫亦可），如果是，就可以使用ysoserial來生成反序列化的payload，指定庫名和想要執(zhí)行的命令即可：

java -jar ysoserial-0.0.2-SNAPSHOT-all.jar CommonsCollections1 'id >> /tmp/redrain' > payload.out

其中ysoserial是java反序列化工具，CommonsCollections1 是指定的庫名（本例的漏洞就是由于Apache Commons Collections庫造成的），whoami就是要執(zhí)行的命令，生成的payload如圖所示

然后通過先前找到的傳入對象方式進行對象注入，數(shù)據(jù)中載入payload，觸發(fā)受影響應用中ObjectInputStream的反序列化操作，隨后通過反射調(diào)用Runtime.getRunTime.exec即可完成利用。

?

Weblogic

Weblogic曾多次被爆出反序列化漏洞，比如 CVE-2016-0638、CVE-2016-3510和CVE-2017-3248等。之所以頻繁出現(xiàn)跟他的修復策略有關，Weblogic采用黑名單的方式過濾危險的反序列化類，只要發(fā)現(xiàn)可用并且未在黑名單之內(nèi)的反序列化類，那么之前的防護就會被打破，系統(tǒng)就會遭受攻擊。該漏洞影響WebLogic 10.3.6.0, 12.1.3.0,12.2.1.0, 12.2.1.1多個版本。利用程序如下（payload用上文提到的方法生成）

相應的自動化的檢測和利用工具在網(wǎng)上已有公開，下圖是利用本地搭建的環(huán)境進行的測試。

?

?WebSphere

WebSphere的反序列化漏洞編號為CVE-2015-7450，漏洞文件為commons-collections.jar，對應端口為8880。默認情況下WebSphere會開啟10個端口用于從不同接口上獲取數(shù)據(jù)，在配置文件

IBM/WebSphere/AppServer/profiles/AppSrv01/properties/wsadmin.properties

中定義了8880端口的作用：用作SOAP協(xié)議的端口，用來交換特定的信息。

那么就可以使用如下payload檢測，其中的base64編碼是java序列化后的對象。

若返回如圖所示的內(nèi)容則證明存在漏洞

想要生成自定義的payload需要執(zhí)行上文提到的ysoserial命令，最后對生成的數(shù)據(jù)進行base64編碼然后將數(shù)據(jù)包中的payload替換即可。

?

Jboss

Jboss的Java反序列化漏洞與Weblogic和WebSphere基本是一致的，也是由于調(diào)用了存在漏洞的基礎庫Apache Commons Collections造成的，但是Jboss相對影響較小，因為要成功利用必須要找到程序接受外部輸入的點，而此處的利用需要/invoker/jmx的支持，大部分情況下的實際場景，jboss都刪除了jmx，所以讓此處的利用大打折扣。在利用方式上與上文提到的WebSphere基本一致，都是直接發(fā)送一個序列化的數(shù)據(jù)包，不過不需要base64編碼。漏洞利用時發(fā)送如下的報文即可，其中payload替換成自己生成的payload。

也有相對簡單的圖形界面工具

?

?

0x05 其他

Weblogic的SSRF漏洞的CVE編號為CVE-2014-4210，問題出現(xiàn)在UDDI功能上，用戶可以在這個界面進行信息搜搜

其中operator參數(shù)可以傳入一個內(nèi)網(wǎng)URL于是造成了對內(nèi)網(wǎng)信息探測或漏洞利用，如下圖所示探測IP為10.108.40.45的主機的端口號80，并提示返回提示，說明相應內(nèi)網(wǎng)主機開啟了80端口。

?

?

轉載于:https://www.cnblogs.com/bmjoker/p/9332888.html

總結

以上是生活随笔為你收集整理的3. 中间件安全基础(三)的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。