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