文件解析漏洞總結（IIS,APACHE,NGINX）

（本文主體來自https://blog.csdn.net/qq_36119192/article/details/82834063）

文件解析漏洞

文件解析漏洞主要由於網站管理員操作不當或者 Web 服務器自身的漏洞，導致一些特殊文件被 IIS、apache、nginx 或其他 Web服務器在某種情況下解釋成腳本文件執行。

 

比如網站管理員配置不當，導致php2、phtml、ascx等等這些文件也被當成腳本文件執行了。甚至某些情況下管理員錯誤的服務器配置導致.html、.xml等靜態頁面后綴的文件也被當成腳本文件執行。

 

但是，大部分的解析漏洞還是由於web服務器自身的漏洞，導致特殊文件被當成腳本文件執行了。

 

 

IIS解析漏洞

目錄解析漏洞(/test.asp/1.jpg)

在 IIS5.x/6.0 中，在網站下建立文件夾的名字為*.asp、*.asa、*.cer、*.cdx 的文件夾，那么其目錄內的任何擴展名的文件都會被IIS當做asp文件來解釋並執行。例如創建目錄 test.asp，那么 /test.asp/1.jpg 將被當做asp文件來執行。假設黑客可以控制上傳文件夾路徑，就可以不管上傳后你的圖片改不改名都能拿shell了

 

文件名解析漏洞(test.asp;.jpg)

在 IIS5.x/6.0 中， 分號后面的不被解析，也就是說 xie.asp;.jpg 會被服務器看成是xie.asp。還有IIS6.0默認的可執行文件除了asp還包含這兩種 .asa   .cer 。而有些網站對用戶上傳的文件進行校驗，只是校驗其后綴名。所以我們只要上傳 *.asp;.jpg、*.asa;.jpg、*.cer;.jpg 后綴的文件，就可以通過服務器校驗，並且服務器會把它當成asp文件執行。

 

畸形解析漏洞(test.jpg/*.php)

微軟發布了IIS7.0修補了IIS6.0的解析漏洞，沒想到IIS7.0爆出更嚴重的畸形解析漏洞，於是微軟急忙發布了IIS7.5

在 IIS7.0中，在默認Fast-CGI開啟狀況下，我們往圖片里面寫入下面的代碼

 

將文件保存成test.jpg格式，上傳到服務器，假設上傳路徑為/upload，上傳成功后，直接訪問/upload/test.jpg/x.php，此時神奇的畸形解析開始發揮作用啦。test.jpg將會被服務器當成php文件執行，所以圖片里面的代碼就會被執行。我們會神奇的發現在 /upload 目錄下創建了一個一句話木馬文件 shell.php 。

 

臨時解決辦法：設置 cgi.fix_pathinfo為0

 

這個解析漏洞和下面講的Nginx的解析漏洞是一樣的。

 

其他解析漏洞

在windows環境下，xx.jpg[空格]  或 xx.jpg.  這兩類文件都是不允許存在的，若這樣命名，windows會默認除去空格或點，黑客可以通過抓包，在文件名后加一個空格或者點繞過黑名單。若上傳成功，空格和點都會被windows自動消除。

 

 

Ngnix解析漏洞

畸形解析漏洞(test.jpg/*.php)

漏洞原因：

 

php的配置文件 php.ini 文件中開啟了 cgi.fix_pathinfo

/etc/php5/fpm/pool.d/www.conf中不正確的配置security.limit_extensions，導致允許將其他格式文件作為php解析執行

在nginx<0.8.03環境中，我們新建一個文件，內容為：<?php phpinfo() ?> ，然后將其名字修改為:  test.jpg

 

在瀏覽器中訪問 http://192.168.10.139/test.jpg  顯示圖片解析錯誤。在瀏覽器中訪問 http://192.168.10.139/test.jpg/test.php ，顯示：Access denied.  。這就奇怪了，test.jpg是文件不是目錄，test.php更是根本就不存在的文件，訪問/test.jpg/test.php沒有報404，而是顯示  Access denied.  。

 

 

 

原因在於，Nginx拿到文件路徑（更專業的說法是URI）/test.jpg/test.php 后，一看后綴是.php，便認為該文件是php文件，於是轉交給php去處理。php一看 /test.jpg/test.php 不存在，便刪去最后的/test.php，又看/test.jpg存在，便把/test.jpg當成要執行的文件了，又因為后綴為.jpg，php認為這不是php文件，於是返回  Access denied. 。

 

這其中涉及到php的一個選項：cgi.fix_pathinfo，該值默認為1，表示開啟。開啟這一選項有什么用呢？看名字就知道是對文件路徑進行處理。舉個例子，當 php 遇到文件路徑 /aaa.xxx/bbb.yyy/ccc.zzz  時，若 /aaa.xxx/bbb.yyy/ccc.zzz 不存在，則會去掉最后的 /ccc.zzz ，然后判斷 /aaa.xxx/bbb.yyy 是否存在，若存在，則把 /aaa.xxx/bbb.yyy 當做文件  /aaa.xxx/bbb.yyy/ccc.zzz ，若   /aaa.xxx/bbb.yyy  仍不存在，則繼續去掉  /bbb.yyy ，以此類推。

 

該選項在配置文件 php.ini 中。若是關閉該選項，訪問 http://127.0.0.1/test.jpg/test.php 只會返回找不到文件。但關閉該選項很可能會導致一些其他錯誤，所以一般默認是開啟的。

 

但是目前我們還沒能成功執行代碼，test.jpg 沒有當成php文件執行，只是返回了 Access denied ，因為新版本的php引入了security.limit_extensions ，限制了可執行文件的后綴，默認只允許執行.php文件。

 

這一漏洞是由於Nginx中php配置不當而造成的，與Nginx版本無關，但在高版本的php中，由於security.limit_extensions 的引入，使得該漏洞難以被成功利用。

 

為何是Nginx中的php才會有這一問題呢？因為Nginx只要一看URL中路徑名以.php結尾，便不管該文件是否存在，直接交給php處理。而如Apache等，會先看該文件是否存在，若存在則再決定該如何處理。cgi.fix_pathinfo是php具有的，若在php前便已正確判斷了文件是否存在，cgi.fix_pathinfo便派不上用場了，這一問題自然也就不存在了。（IIS在這一點和Nginx是一樣的，同樣存在這一問題）

 

%00空字節代碼解析漏洞

原理：Ngnix在遇到%00空字節時與后端FastCGI處理不一致，導致可以在圖片中嵌入PHP代碼然后通過訪問xxx.jpg%00.php來執行其中的代碼

 

在以下版本的nginx中，我們在圖片中嵌入PHP代碼然后通過訪問 xxx.jpg%00.php 來執行其中的代碼

 

 Nginx 0.5.*

 Nginx 0.6.*

 Nginx 0.7 <= 0.7.65

 Nginx 0.8 <= 0.8.37

 

CVE-2013-4547(%20%00)

影響nginx版本：nginx 0.8.41 ~ 1.5.6

 

這一漏洞的原理是非法字符空格和截止符（%00）會導致Nginx解析URI時的有限狀態機混亂，危害是允許攻擊者通過一個非編碼空格繞過后綴名限制。是什么意思呢？舉個例子，假設服務器上存在文件：“file.jpg ”，注意文件名的最后一個字符是空格。則可以通過訪問：

 

http://127.0.0.1/file.jpg \0.php 

讓Nginx認為文件“file.jpg ”的后綴為“.php”。

 

來測試下，這次測試在Nginx/1.0.15中進行。首先准備一張圖片，命名為“test.html ”，注意，文件名含有空格。然后在瀏覽器中訪問該文件，會得到一個404，因為瀏覽器自動將空格編碼為%20，服務器中不存在文件“test.html%20”。

 

測試目標是要讓Nginx認為該文件是圖片文件並正確地在瀏覽器中顯示出來。我們想要的是未經編碼的空格和截止符（\0），怎么辦呢？使用Burp Suite抓取瀏覽器發出的請求包，修改為我們想要的樣子，原本的URL是：http://192.168.56.101/test.htmlAAAjpg ,將第一個“A”改成“20”（空格符號的ASCII碼），將第二個“A”改成“00”（截止符），將第三個“A”改成“2e”（“.”的ASCII碼），如圖

 

 

 

修改完畢后Forward該請求，在瀏覽器中看到：

 

 

 

我們已經成功地利用了漏洞！但這有什么用呢？我們想要的是代碼被執行。

 

繼續測試，准備文件“test.jpg ”，注意文件名的最后一個字符是空格，上傳到服務器。文件內容為：

 

 

 

用Burp Suite抓包並修改，原本的URL是：http://192.168.56.101/test.jpg…php ,將jpg后的第一個“.”改為20，第二個“.”改為00，如下圖所示：

 

 

 

修改完畢后 Forword 該請求，在瀏覽器中看到：Access  denied  ，好吧，又是這個。

 

這說明Nginx在接收到這一請求后，確實把文件“test.jpg ”當做php文件交給php去執行了，只是php看到該文件后綴為“.jpg ”而拒絕執行。這樣，便驗證了Nginx確實存在該漏洞。但是由於 security.limit_extensions 的存在，導致我們並不能利用此漏洞

 

Apache解析漏洞

文件名解析漏洞

apache是從右到左開始判斷解析，如果為不可識別解析，就再往左判斷。比如 xie.php.owf.rar     .owf和.rar 這兩種后綴是apache不可識別的解析，apache就會把xie.php.owf.rar解析成 xie.php 。如何判斷是不是合法的后綴就是這個漏洞的利用關鍵，測試時可以嘗試上傳一個 xie.php.rara.jpg.png..(把你知道的后綴都寫上去)去測試是否是合法后綴。任意不識別的后綴，逐級向上識別。

 

罕見后綴

計算機世界自開天辟地以來，便自由多彩。還記得mime.types文件嗎？在該文件中搜索“php”這三個字母，結果如下所示：

1.   werner@Yasser:~$ cat /etc/mime.types | grep php
2.   #application/x-httpd-php          phtml pht php
3.   #application/x-httpd-php-source           phps
4.   #application/x-httpd-php3         php3
5.   #application/x-httpd-php3-preprocessed        php3p
6.   #application/x-httpd-php4         php4
7.   #application/x-httpd-php5         php5

還記得正則表達式”.+\.ph(p[345]?|t|tml)$”嗎，該正則表達式匹配的不僅僅有php，還有php3、php4、php5、pht和phtml。

好吧，原來不僅php，就連phtml、pht、php3、php4和php5都是Apache和php認可的php程序的文件后綴。我原本只知道“.php”的，真是大開眼界。這就好比，不僅py是Python程序文件的后綴，還有pyc和pyo也都是。寫上傳過濾規則的程序員是否博學多識，也知道這些知識呢？我想，大抵是不知道的。利用這些“罕見”的后綴名，也可能繞過安全檢查，干些“壞事”。

我在Ubuntu14.04+Apache2.4.7中進行測試，先准備文件text.php，其內容是經典的Hello World：

  <?php echo 'HELLO WORLD'; ?>

然后在瀏覽器中打開它，成功顯示“HELLO WORLD”。再修改該文件后綴為各種后綴，進行測試。測試結果是，以php、phtml、pht、php3、php4和php5為后綴，能成功看到“HELLO WORLD”；以phps為后綴，會報403錯誤，Forbidden；以php3p為后綴，會在瀏覽器中看到源碼。

 

 

 

.htaccess文件

.htaccess文件是Apache服務器中的一個配置文件，它負責相關目錄下的網頁配置。通過 .htaccess文件，可以實現：網頁301重定向、自定義404錯誤頁面、改變文件擴展名、允許/阻止特定的用戶或者目錄的訪問、禁止目錄列表、配置默認文檔等功能IIS平台上不存在該文件，該文件默認開啟，啟用和關閉在 httpd.conf 文件中配置。

 

 .htaccess 文件生效前提條件為：

mod_rewrite 模塊開啟

AllowOverride All

 

#1：這個.htaccess的意思就是把所有名字里面含有shell的文件當成php腳本來執行

<FilesMatch   "shell"> 

SetHandler  application/x-httpd-php 

</FilesMatch>

 

#2：這里代碼的意思可以讓 .jpg后綴名文件格式的文件名以php格式解析

AddType application/x-httpd-php .jpg