nginx文件名邏輯漏洞_CVE-2013-4547漏洞復現

nginx文件名邏輯漏洞_CVE-2013-4547漏洞復現

1、漏洞描述

這個漏洞其實和代碼執行沒有太大的關係,主要緣由是錯誤地解析了請求的URL,錯誤地獲取到用戶請求的文件名,致使出現權限繞過、代碼執行的連帶影響。

2、漏洞原理

舉個例子,好比,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下沒有這個限制)

3、漏洞影響版本

Nginx 0.8.41~1.4.3

Nginx 1.5.0~1.5.7

4、漏洞環境搭建和復現

一、使用docker搭建vulhub漏洞環境,啓動漏洞環境

docker-compose build

docker-compose up -d

二、瀏覽器訪問http://172.17.0.1:8080/,測試環境是否搭建成功

　　

三、 看一下後端過濾

　　

四、上傳一個mu.jpg,裏面的內容仍是<?php phpinfo();?>，注意後面的空格,發現上傳成功

　　

五、構造mu.jpg[0x20][0x00].php來形成Nginx解析漏洞，使咱們的mu.jpg被解析成php

在burp抓取的數據包中把mu.jpg後面的兩個空格 [0x20][0x20] ---> [0x20][0x00] ,發現成功上傳

　　

　　

六、訪問http://172.17.0.1:8080/uploadfiles/1.gif[0x20][0x00].php，便可發現PHP已被解析

　　

5、漏洞防護

一、升級版本

 

 

--------------------------------------------------------------------------------------------------

參考資料: https://github.com/vulhub/vulhub/tree/master/nginx/CVE-2013-4547