nginx檔名邏輯漏洞_CVE-2013-4547漏洞復現
一、漏洞描述
這個漏洞其實和程式碼執行沒有太大的關係,主要原因是錯誤地解析了請求的URL,錯誤地獲取到使用者請求的檔名,導致出現許可權繞過、程式碼執行的連帶影響。
二、漏洞原理
舉個例子,比如,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下沒有這個限制)
三、漏洞影響版本
Nginx 0.8.41~1.4.3
Nginx 1.5.0~1.5.7
四、漏洞環境搭建和復現
1、使用docker搭建vulhub漏洞環境,啟動漏洞環境
docker-compose build
docker-compose up -d
2、瀏覽器訪問http://172.17.0.1:8080/,測試環境是否搭建成功
3、 看一下後端過濾
4、上傳一個mu.jpg,裡面的內容還是<?php phpinfo();?>，注意後面的空格,發現上傳成功
5、構造mu.jpg[0x20][0x00].php來造成Nginx解析漏洞，使我們的mu.jpg被解析成php
在burp抓取的資料包中把mu.jpg後面的兩個空格 [0x20][0x20] ---> [0x20][0x00] ,發現成功上傳
6、訪問http://172.17.0.1:8080/uploadfiles/1.gif[0x20][0x00].php，即可發現PHP已被解析
五、漏洞防禦
1、升級版本
--------------------------------------------------------------------------------------------------
參考資料: https://github.com/vulhub/vulhub/tree/master/nginx/CVE-2013-4547