文件解析漏洞主要由于網(wǎng)站管理員操作不當(dāng)或者Web容器自身的漏洞，導(dǎo)致一些特殊構(gòu)造的其他格式文件被 IIS、apache、nginx 或其他 Web容器在某種情況下解釋成腳本文件執(zhí)行，導(dǎo)致黑客可以利用該漏洞實(shí)現(xiàn)非法文件的解析。
本文總結(jié)一些常見Web中間件的文件解析漏洞。
一、IIS 6.0
使用6.x版本的服務(wù)器，大多為Windows server 2003，網(wǎng)站比較古老，開發(fā)語言一般為asp；該解析漏洞也只能解析asp文件，而不能解析aspx文件。
1、目錄解析：/x.asp/x.jpg
x.jpg可替換為任意文本文件(如x.txt)，文本內(nèi)容為后門代碼。IIS 6.0 默認(rèn)會(huì)把.asp，.asa目錄下的文件都解析成asp文件。
2、后綴解析：/x.asp;.jpg
IIS 6.0 默認(rèn)不解析;號后面的內(nèi)容，因此x.asp;.jpg便被解析成asp文件。
3、默認(rèn)解析：/x.asa，/x.cer，/x.cdx
IIS 6.0 默認(rèn)配置中，可執(zhí)行文件除了.asp還包含這三種.asa .cer .cdx，這幾個(gè)后綴默認(rèn)由 asp.dll 來解析，所以執(zhí)行權(quán)限和.asp后綴一樣，可在配置中自行刪除該后綴，以防止安全隱患。可結(jié)合目錄解析漏洞利用，如 /x.asa/x.jpg 或 /x.cer/x.jpg 或 /x.asa;.jpg。
4、修復(fù)方案
1、目前尚無微軟官方的補(bǔ)丁，可以通過自己編寫正則，阻止上傳x.asp;.jpg類型的文件名。2、做好權(quán)限設(shè)置，限制用戶創(chuàng)建文件夾。
二、IIS 7.0、IIS 7.5、Nginx <8.03
1、PHP解析漏洞
php的配置文件 php.ini 文件中開啟了 cgi.fix_pathinfo，/etc/php5/fpm/pool.d/www.conf中不正確的配置security.limit_extensions，導(dǎo)致允許將其他格式文件作為php解析執(zhí)行。在本地環(huán)境中，新建一個(gè)文件phpinfo.jpg，內(nèi)容為：<?php phpinfo() ?>，通過訪問http://127.0.0.1/phpinfo.jpg/.php，會(huì)正常執(zhí)行惡意代碼。
但在nginx<8.03環(huán)境中，新建一個(gè)文件test.jpg，直接訪問顯示圖片解析錯(cuò)誤。在瀏覽器中訪問/test.jpg/test.php ，則顯示Access denied.。問題來了，test.jpg是文件不是目錄，test.php更是根本就不存在的文件，訪問/test.jpg/test.php沒有報(bào)404，而是顯示Access denied.。
?原因在于，Nginx拿到URI（/test.jpg/test.php） 后，識別后綴是.php，直接轉(zhuǎn)交給php去處理。php判斷/test.jpg/test.php不存在，便刪去最后的/test.php，繼續(xù)判斷/test.jpg存在，便把/test.jpg當(dāng)成要執(zhí)行的文件，又因?yàn)楹缶Y為.jpg，php認(rèn)為這不是php文件，于是返回Access denied.。這其中涉及到php的一個(gè)選項(xiàng)：cgi.fix_pathinfo，該值默認(rèn)為1，表示開啟。開啟這一選項(xiàng)后PHP對文件路徑采用從右向左的判斷邏輯進(jìn)行處理。以/為分隔逐層判斷文件是否存在，直到判斷到存在的那個(gè)路徑。所以導(dǎo)致php會(huì)去嘗試解析test.jpg。該選項(xiàng)在配置文件php.ini中。若是關(guān)閉該選項(xiàng)，訪問 /test.jpg/test.php 只會(huì)返回找不到文件。但關(guān)閉該選項(xiàng)很可能會(huì)導(dǎo)致一些其他錯(cuò)誤，所以一般默認(rèn)是開啟的。另外一種利用方式是上傳一個(gè)名字為test.jpg，以下是文件的內(nèi)容：<?PHP fputs(fopen('shell.php','w'),'<?php eval($_POST[cmd])?>');?>然后訪問 test.jpg/.php，在這個(gè)目錄下就會(huì)生成一句話木馬shell.php。圖片馬利用方法：將惡意文本寫入圖片的二進(jìn)制代碼之后，避免破壞圖片文件頭和尾。例：copy xx.jpg/b + yy.txt/a xy.jpg/b 即二進(jìn)制[binary]模式/a 即ascii模式 xx.jpg正常圖片文件
新版本的php引入了security.limit_extensions ，限制了可執(zhí)行文件的后綴，默認(rèn)只允許執(zhí)行.php文件。這一漏洞是由于Nginx中php配置不當(dāng)而造成的，與Nginx版本無關(guān)，但在高版本的php中，由于security.limit_extensions 的引入，使得該漏洞難以被成功利用。IIS在這一點(diǎn)和Nginx是一樣的，同樣存在這一問題。而如Apache等，會(huì)先看該文件是否存在，若存在則再?zèng)Q定該如何處理。cgi.fix_pathinfo是php具有的，若在php前便已正確判斷了文件是否存在，cgi.fix_pathinfo便派不上用場了，這一問題自然也就不存在了。
2、IIS相關(guān)的解析漏洞
IIS7.5 的漏洞與 nginx 的類似，都是由于 php 配置文件中，開啟了 cgi.fix_pathinfo，而這并不是 nginx 或者 iis7.5 本身的漏洞。跟 nginx 解析漏洞一樣，利用的條件是 php.ini => cgi.fix_pathinfo=1 開啟的情況才會(huì)產(chǎn)生。可以配合操作系統(tǒng)文件命名規(guī)則，上傳不符合 windows 文件命名規(guī)則的文件名。
會(huì)被 windows 系統(tǒng)自動(dòng)去掉不符合規(guī)則符號后面的內(nèi)容，然后再配合這個(gè)解析漏洞來執(zhí)行文件。
修復(fù)方案
1、修改php.ini文件，將cgi.fix_pathinfo的值設(shè)置為0；if ( $fastcgi_script_name ~ ..*/.*php ) { return 403;}
這行代碼的意思是當(dāng)匹配到類似test.jpg/a.php的URL時(shí)，將返回403錯(cuò)誤代碼。
三、Nginx
1、%00空字節(jié)代碼解析漏洞
Ngnix在遇到%00空字節(jié)時(shí)與后端FastCGI處理不一致，導(dǎo)致可以在圖片中嵌入PHP代碼然后通過訪問xxx.jpg%00.php來執(zhí)行其中的代碼。1、上傳時(shí)路徑可控，使用00截?cái)?/span>2、文件下載時(shí)，00截?cái)嗬@過白名單檢查3、文件包含時(shí)，00截?cái)嗪竺嫦拗?主要是本地包含時(shí))4、其它與文件操作有關(guān)的地方都可能使用00截?cái)唷?/span>
二、CVE-2013-4547(%20%00)
非法字符空格和截止符（%00）會(huì)導(dǎo)致Nginx解析URI時(shí)的有限狀態(tài)機(jī)混亂，危害是允許攻擊者通過一個(gè)非編碼空格繞過后綴名限制。影響nginx版本：nginx 0.8.41 ~ 1.5.6http://127.0.0.1/file.jpg \0.php這樣會(huì)讓Nginx認(rèn)為文件“file.jpg ”的后綴為“.php”。在Nginx/1.0.15的環(huán)境中，準(zhǔn)備文件“test.jpg ”（注意文件名的最后一個(gè)字符是空格），文件內(nèi)容為：<?php phpinfo(); ?>。用Burp Suite抓包并修改，原本的URL是：http://*.*.*.*/test.jpg...php，將jpg后的第一個(gè)“.”改為20，第二個(gè)“.”改為00。修改完畢后 Forword 該請求，在瀏覽器中看到返回phpinfo的結(jié)果。
四、Apache
1、后綴解析：test.php.x1.x2.x3
Apache的文件解析規(guī)則是從右至左判斷后綴是否可以解析，若x3非可識別后綴，再判斷x2，直到找到可識別后綴為止，然后將該可識別后綴進(jìn)解析。
修復(fù)方案
后綴驗(yàn)證盡量使用白名單的方式，這樣即使使用不存在的后綴名，也無法繞過。
2、配置問題導(dǎo)致漏洞
1、如果在Apache的conf里有這樣一行配置 AddHandler php5-script.php這時(shí)只要文件名里包含.php即使文件名是xx.php.jpg也會(huì)以php來執(zhí)行。2、如果在Apache的conf里有這樣一行配置 AddType application/x-httpd-php .jpg即使擴(kuò)展名是jpg，一樣能以php來執(zhí)行。
修復(fù)方案
1、apache配置文件，禁止.php.這樣的文件執(zhí)行，配置文件里面加入<Files~“.(php.|php3.)”>Order Allow,DenyDeny from all</Files>
2、用偽靜態(tài)能解決這個(gè)問題，重寫類似.php.*這類文件，打開apache的httpd.conf找到 LoadModule rewrite_module modules/mod_rewrite.so把#號去掉，重啟apache，在網(wǎng)站根目錄下建立.htaccess文件，代碼如下：<IfModulemod_rewrite.c>RewriteEngine OnRewriteRule .(php.|php3.) /index.phpRewriteRule .(pHp.|pHp3.) /index.phpRewriteRule .(phP.|phP3.) /index.phpRewriteRule .(Php.|Php3.) /index.phpRewriteRule .(PHp.|PHp3.) /index.phpRewriteRule .(PhP.|PhP3.) /index.phpRewriteRule .(pHP.|pHP3.) /index.phpRewriteRule .(PHP.|PHP3.) /index.php</IfModule>
3、罕見后綴
還記得mime.types文件嗎？在該文件中搜索“php”這三個(gè)字母，結(jié)果如下所示：:~$ cat /etc/mime.types | grep php#application/x-httpd-php phtml pht php#application/x-httpd-php-source phps#application/x-httpd-php3 php3#application/x-httpd-php3-preprocessed php3p#application/x-httpd-php4 php4#application/x-httpd-php5 php5
Apache 配置文件中會(huì)有.+.ph(p[345]?|t|tml)此類的正則表達(dá)式，被當(dāng)php程序執(zhí)行的文件名要符合正則表達(dá)式，也就是說php3，php4，php5，pht，phtml也是可以被解析的。
4、.htaccess文件
一般來說，配置文件的作用范圍都是全局的，但 Apache 提供了一種很方便的、可作用于當(dāng)前目錄及其子目錄的配置文件—— .htaccess（分布式配置文件）。要想使.htaccess文件生效，需要兩個(gè)條件:一是在Apache的配置文件httpd.conf中寫上：二是 Apache 要加載mod_Rewrite 模塊。加載該模塊，需要在Apache的配置文件中寫上：LoadModulerewrite_module/usr/lib/apache2/modules/mod_rewrite.so若是在Ubuntu中，可能還需要執(zhí)行命令：
.htaccess 文件可以配置很多事情，如是否開啟站點(diǎn)的圖片緩存、自定義錯(cuò)誤頁面、自定義默認(rèn)文檔、設(shè)置WWW域名重定向、設(shè)置網(wǎng)頁重定向、設(shè)置圖片防盜鏈和訪問權(quán)限控制。但我們這里只關(guān)心.htaccess 文件的一個(gè)作用—— MIME 類型修改。
AddType application/x-httpd-php .xxx
該.htaccess文件所在目錄及其子目錄中的后綴為.xxx的文件被Apache當(dāng)做php文件。<FilesMatch"shell.jpg">SetHandlerapplication/x-httpd-php</FilesMatch>
該語句會(huì)讓 Apache 把shell.jpg 文件當(dāng)作 php 文件來解析。
五、lighttpd
六、其他解析漏洞
在Windows環(huán)境下，x.jpg[空格] 或x.jpg. 這兩類文件都是不允許存在的，若這樣命名，Windows會(huì)默認(rèn)除去空格或點(diǎn)，黑客可以抓包修改文件名，在后面加個(gè)空格或點(diǎn)，試圖繞過黑名單，若上傳成功，最后的點(diǎn)或空格都會(huì)被消除，成為可以解析的惡意文件。
該文章在 2024/11/26 12:09:47 編輯過
400 186 1886
