部分中介軟體漏洞總結
做看客很久了,發現一直沒有比較好的中介軟體漏洞的總結性文章,正好近期在做這方面的學習,在此僅總結了少部分中介軟體常見漏洞供學習參考,後續將補充另一部分常見漏洞。如有錯誤還請大佬們指正。
一、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:
得到結果如圖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檔案,進而獲取伺服器許可權。
內容較多,暫不展開分析。