部分中介軟體漏洞總結

摘要： 做看客很久了，發現一直沒有比較好的中介軟體漏洞的總結性文章，正好近期在做這方面的學習，在此僅總結了少部分中介軟體常見漏洞供學習參考，後續將補充另一部分常見漏洞。如有錯誤還請大佬們指正。 一、IIS檔案解析漏洞 IIS檔案解析漏洞存在於兩個版本，一個是IIS6.0的檔案解析漏洞...

做看客很久了，發現一直沒有比較好的中介軟體漏洞的總結性文章，正好近期在做這方面的學習，在此僅總結了少部分中介軟體常見漏洞供學習參考，後續將補充另一部分常見漏洞。如有錯誤還請大佬們指正。

一、IIS檔案解析漏洞

IIS檔案解析漏洞存在於兩個版本，一個是IIS6.0的檔案解析漏洞，一個是IIS7.5的檔案解析漏洞，IIS7.5的檔案解析漏洞原理和IIS6.0類似，均因為存在邏輯問題，在此僅對IIS6.0的檔案解析漏洞進行分析。在補充中將對IIS7.5檔案解析漏洞差異性部分進行額外說明。

（一）漏洞原理

IIS6.0在處理含有特殊符號的檔案路徑時會出現邏輯錯誤（檔案目錄名稱為test.asp，目錄中的檔案會被當做asp執行；字尾名為.asp;.jpg時，當作asp檔案執行），從而造成檔案解析漏洞。

（二）漏洞演示及利用

當網站上傳點限制字尾名時（IIS主要和asp搭配），可以利用檔案解析漏洞上傳如test.asp;.jpg的檔案，繞過後執行。如圖1.1

圖1.1

當允許新建目錄而未對目錄名做限制時，可利用檔案解析漏洞新建名為test.asp的資料夾，並在其中構造需執行檔案iisstart.jpg進行繞過。如圖1.2

圖1.2

（三）漏洞修復

1、對新建目錄檔名進行過濾，不允許新建包含.的資料夾甚至禁止新建目錄

2、限制上傳檔案的執行許可權，不允許執行

3、過濾.asp/xm.jpg等，在httpd.ini中加入過濾規則（此方法為網路上的解決辦法，但在server2003中未搜尋到該檔案）。

4、升級IIS版本

（四）補充

IIS6.0的解析漏洞同樣存在於IIS 5.x的版本，而IIS7.5的畸形解析漏洞的攻擊方法同樣適用於IIS7.0和Nginx<8.03版本。

IIS7.5檔案解析漏洞出現是因為url中只要看到字尾.php，無論存在與否均交給php處理，而php又預設開啟“cgi.fix_pathinfo”,會對檔案路徑進行整理（從後向前判定是否存在，不存在則刪減，存在則當作php檔案執行。）

二、IIS命令執行漏洞

IIS6.0命令執行漏洞，編號CVE-2017-7269，在開啟WebDav服務的情況下存在可遠端執行漏洞。

（一）漏洞原理

在IIS6.0處理PROPFIND指令的時候，由於對url的長度沒有進行有效的長度控制和檢查，導致執行memcpy對虛擬路徑進行構造的時候，引發棧溢位，該漏洞可以導致遠端程式碼執行。如圖2.1

圖2.1

（二）漏洞演示及利用

Github上的一個開源exp: ofollow,noindex" target="_blank">https://github.com/edwardz246003/IIS_exploit

修改IP地址未對應的目標機地址，如圖2.2

圖2.2

執行指令碼，攻擊目標機。如圖2.3

圖2.3

（三）漏洞修復

將IIS管理器中，web服務擴充套件下，webDAV禁用，即可修復，修復後再此執行指令碼，未出現彈窗。如圖2.4

圖2.4

（四）補充

若能彈出計算器（calc）,則許可權已經足以完成getshell的全部操作。

三、IIS短檔名

IIS短檔名漏洞，通過IIS短檔名機制，暴力列舉短檔名，嘗試猜解後臺地址、敏感檔案甚至直接下載對應的檔案。但侷限於只能猜解長檔名前6位和副檔名前3位，同時需要IIS和.net兩個條件都滿足。

（一）漏洞原理

利用了IIS短檔名機制，即為了相容16位MS-DOS程式，Windows為檔名較長的（計算字尾後文件名長度大於9）檔案（和資料夾）生成了對應的windows 8.3 短檔名。可以通過此漏洞猜解後臺地址、敏感檔案等。如圖3.1

圖3.1

（二）漏洞演示及利用

開啟winserver2003虛擬機器，在c:/Inetpub/wwwroot目錄下新建對比資料夾12345678，123456789，對比檔案aaaaaa.asp。在主機上開啟虛擬機器IP下的URL

嘗試10.10.10.132/122~1**/a.asp和10.10.10.132/123~1/a.asp；得到不同的結果如圖3.2，圖3.3。

圖3.2

圖3.3

通過如上兩圖我們可以看出，根據返回結果的不同可以逐個猜解短檔名。

而後再嘗試10.10.10.132/aaaaaa~1/a.asp（猜解無後綴，正常返回則為資料夾）和10.10.10.132/aaaaaa~1/a.asp（猜解為檔案）。如圖3.4，圖3.5。

圖3.4

圖3.5

根據不同的回顯我們可以判斷正在猜解的物件是檔案還是資料夾。

（三）漏洞修復

目前幾種修復方式，可選擇升級.net framework或者將在登錄檔HKEY_LOCAL_MACHINESYSTEMCurrentControlSetControlFileSystem中修改NtfsDisable8dot3NameCreation為1，但修改方法嘗試多次，不易成功。

除去上述方式，較易成功的方式為將web資料夾內容拷貝到其他區域，將原資料夾刪除後，再將拷貝的資料夾移動回來。修復如圖3.6，結果如圖3.7

圖3.6

圖3.7

（四）補充

目前有比較好的IIS短檔名檢查工具，下載地址為：

https://github.com/lijiejie/IIS_shortname_Scanner

四、Nginx檔案解析

Nginx檔案解析漏洞，精心構造的惡意請求經過nginx中介軟體處理後，被合法的執行。php有一個選項cgi.fix_pathinfo，預設值為1，表示開啟。

（一）漏洞原理

Nginx檔案解析漏洞，涉及到選項cgi.fix_pathinfo，預設值為1，表示開啟。請求檔案/shell.gif時後面加個*.php，可能會被當作php程式碼執行。如果關閉此選項，輸入10.10.10.130:55555/test.jpg/x.php只會返回找不到檔案。但因為如果關閉可能會導致一些其他錯誤，所以預設是開啟的。如圖4.1

圖4.1

同時配置檔案/etc/php5/fpm/pool.d/www.conf中security.limit_extensions允許解析其他格式檔案為php，如圖4.2，二者共同作用造成了檔案解析漏洞。

圖4.2

（二）漏洞演示及利用

一是因為對任意檔名，在後面新增/任意檔名.php的解析漏洞，比如原本檔名時test.jpg，都可以新增為test.jpg/x.php進行解析攻擊。如圖4.3.二是對低版本的Nginx可以在任意檔名後新增%00.php進行解析攻擊。

圖4.3

（三）漏洞修復

1、將php.ini檔案中的cgi.fix_pathinfo的值設為0。這樣php在解析1.php/1.jpg這樣的目錄時，只要1.jpg不存在就會顯示404。

2、將/etc/php5/fpm/pool.d/www.conf中security.limit_extensions後面的值設為.php。

修復結果如圖4.4

圖4.4

（四）補充

Nginx檔案解析漏洞的本質原因時配置檔案錯誤。網站上線前需要確認相關配置正確。

五、Nginx配置不當

Nginx配置不當除了造成檔案解析漏洞，還可能造成兩種後果：1、可以進行目錄遍歷（或目錄穿越）；2、存在CRLF注入，CRLF是”回車+換行”（rn）的簡稱。目錄穿越將在補充內容中進行介紹。

（一）漏洞原理

Nginx目錄遍歷漏洞和apache一樣，屬於配置方面的問題。錯誤的配置可能導致目錄遍歷與原始碼洩露。如圖5.1

圖5.1

CRLF利用了HTTP包Header與Body是用兩個CRLF分隔的這一特性，通過控制HTTP訊息頭中的字元。若採用解碼跳轉，攻擊者就可以注入一些惡意的換行來注入一些會話Cookie或者HTML程式碼。如圖5.2。任何可設定HTTP頭的場景都會出現CRLF注入問題。

圖5.2

（二）漏洞演示及利用

1、目錄遍歷

當autoindex on;存在時，可直接訪問目錄。如圖5.3

圖5.3

2、CRLF注入

開啟burp，重新整理頁面，抓包，修改資料包。結果如圖5.4

圖5.4

可以看到，經過惡意修改，攻擊者構造的url中的JSPSEEID值被伺服器讀取成了請求頭中的cookie值，達到了會話固定的目的。出去會話固定，通過兩次CRLF可將URL中編寫的惡意指令碼（如反射型XSS）被伺服器識別成請求體，從而達成攻擊。如圖5.5。如未彈窗可能是因為瀏覽器Filter對XSS特徵進行了過濾，並且進行了跳轉。

圖5.5

（三）漏洞修復

1、針對目錄遍歷，只需在配置檔案中刪除autoindex on即可。修復結果如圖5.6

圖5.6

2、針對CRLF注入，修改配置檔案使用不解碼的url跳轉。

將return 302 https://$host$uri； 修改為return 302 https://$host$request_uri； 修復結果如圖5.7

圖5.7

（四）補充

關於Nginx配置不當造成目錄穿越，其成因除去目錄遍歷漏洞中開啟的autoindex on;選項，同時在配置檔案/etc/nginx/conf.d/error2.conf中，沒有閉合跳轉目錄如圖5.8，造成目錄穿越如圖5.9

圖5.8

圖5.9

修復方法也很簡單，將/files閉合，變為/files/即可，效果如圖5.10

圖5.10

六、apache檔案解析漏洞

檔案解析與檔案上傳漏洞往往伴生存在。apache解析檔案時邏輯存在問題，造成請求某一個精心編輯過的非法檔案時被當作正常的php檔案來執行，造成被getshell。

（一）漏洞原理

因為apache解析php時，當檔案的最後一個字尾php相關時，會把檔案交給php處理器處理，完成後結果返回給apache，再發送給瀏覽器。而當一個檔案以多個點分隔無法識別時，則繼續向左試別。即當請求shell.php.360,將試別出php，然後交給php處理。

（二）漏洞演示及利用

當上傳1.php時，由於存在上傳字尾名限制，無法完成上傳如圖6.1，一般情況下，若上傳允許的型別則無法利用，但存在檔案解析漏洞時，可以繞過。

圖6.1

此時上傳1.php.aaa檔案，則可以上傳成功。同時因存在解析問題，1.php.aaa檔案可以被訪問。如圖6.2

圖6.2

（三）漏洞修復

在配置檔案中，不使用AddHandler，改用SetHandler，寫好正則，就不會有解析問題。

<FilesMatch “.+.php$”>
SetHandler application /x-httpd-php
</FilesMatch>

禁止.php.這樣的檔案執行

<FilesMatch “.+.ph(p[3457]?|t|tml).”>
Require all denied
</FilesMatch>

（四）補充

此漏洞爆出後，官方進行了一次修復，採用了黑名單，如圖6.3

圖6.3

但之後又爆出了同類型的漏洞（編號：CVE-2017-15715），可通過上傳一個包含換行符（x0A）的檔案繞過檢測，如圖6.4、圖6.5，Apache2.4.0-2.4.29均受到此漏洞影響。在後續版本中官方已經修復了此漏洞，及時更新即可修復。

圖6.4

圖6.5

七、tomcat任意檔案上傳

Tomcat遠端程式碼執行漏洞，編號：CVE-2017-12615

（一）漏洞原理

當readonly引數設定為false時，即可通過PUT方式建立一個JSP檔案，並可以執行任意程式碼。如圖7.1

圖7.1

（二）漏洞演示及利用

開啟Burp，訪問Tomcat服務，抓包，修改資料包，轉發至repeater併發送，提示404，請求被攔截。如圖7.2

圖7.2

再次修改請求包，處理檔名相關限制。如圖7.3

圖7.3

（三）漏洞修復

1、將Tomcat、jdk、php更新

2、關閉可通過PUT方式建立JSP檔案的功能。

八、weblogic SSRF漏洞

Weblogic未對使用者url進行過濾，從惡意構造的的url讀取資料並展示功能，導致攻擊者可藉助服務端實現訪問本無權訪問的url。漏洞編號：CVE-2014-4210

（一）漏洞原理

Weblogic的SSRF漏洞出現在uddi元件（也就意味著未安裝此元件則無此漏洞），其中的uudi包實現包uddiexplorer.war下的SearchPublicRegistries.jsp。

（二）漏洞利用

位址列輸入url：

http://10.10.10.130:7001/uddiexplorer/SearchPublicRegistries.jsp?rdoSearch=name&txtSearchname=sdf&txtSearchkey=&txtSearchfo=&selfor=Business+location&btnSubmit=Search&operator=http://127.0.0.1:7001

得到結果如圖8.1

圖8.1

修改url中埠為一個未開放的埠如8888，會得到不同的回顯如圖8.2，根據回顯不同，可以判斷埠是否開放，以進行下一步滲透

圖8.2

網路上獲取到批量檢測指令碼可進行批量埠檢測。（附件二），實際操作中此階段有可能會得到內網網段，獲取網段後可使用指令碼快速檢測。

在檢測到相關網段和埠後，可以通過傳入%0a%0d來注入換行符，利用Redis反彈shell。

（三）漏洞修復

最直接的方式是將SearchPublicRegistries.jsp直接刪除。

（四）補充

Weblogic除去上述SSRF漏洞，還存在任意檔案上傳漏洞等，任意檔案上傳幾乎每年都會有新的漏洞。最近的漏洞編號為CVE-2018-2894，此漏洞成因為若開啟Web Service Test Page，可上傳任意jsp檔案，進而獲取伺服器許可權。

內容較多，暫不展開分析。