Nginx 解析漏洞

一、搭建環(huán)境

環(huán)境需求：ubuntu虛擬機(jī)，docker環(huán)境，vulhub-master環(huán)境

這里我使用的Linux系統(tǒng)為Ubuntu22.04版本，已經(jīng)準(zhǔn)備完畢（比如換源，安裝docker等操作）

1、通過(guò)FTP將vulhub-master.zip環(huán)境包上傳并進(jìn)行解壓

這里我已將環(huán)境包上傳至root主目錄下，下面進(jìn)行解壓：

unzip vulhub-master.zip

2、進(jìn)入vulhub-master/nginx/nginx_parsing_vulnerability此目錄下制作鏡像

cd /root/vulhub-master/nginx/nginx_parsing_vulnerability
docker-compose up -d

這里我們可能會(huì)碰見(jiàn)幾種報(bào)錯(cuò)，實(shí)則不難，網(wǎng)上查下便知。下面我羅列一種：
如果出現(xiàn)下圖這種情況：

這里其實(shí)是因?yàn)?0端口被占用，沖突了，所以我們可以查下是哪個(gè)進(jìn)程占用導(dǎo)致的：

lsof -i :80systemctl stop nginx

我們可以看到是nginx占用了80端口，所以我停止了nginx的進(jìn)程并再次查看，可以看到已經(jīng)沒(méi)有了，下面我們繼續(xù)重新啟動(dòng)容器。

到這里我們的環(huán)境也已經(jīng)搭建完畢。

二、復(fù)現(xiàn)過(guò)程

1、訪問(wèn)http://your-ip/uploadfiles/nginx.png

這里我們可以看到是正確顯示的。

2、訪問(wèn)http://your-ip/uploadfiles/nginx.png/.php來(lái)查看效果

這里我們可以看到被解析為PHP文件了。
這里其實(shí)原本一張圖片怎么會(huì)解析為php代碼呢，按理說(shuō)就比如自己上傳一張圖片然后去查看并解析為php可以試下，即如下圖所示：

這里我們可以看到是報(bào)錯(cuò)了，所以我們?cè)賮?lái)看看nginx這張圖片：

這里我們很明顯看到里面添加了一句話木馬。所以這里其實(shí)是執(zhí)行了這個(gè)一句話木馬，我們可以有一個(gè)思路便是自己創(chuàng)建圖片并加入一句話木馬去執(zhí)行，然后使用蟻劍連，所以這里肯定是存在上傳漏洞的。

三、漏洞原理及防范

這里我第一個(gè)想到的便是nginx的配置文件，如下圖所示：

root@zyan-virtual-machine:/etc/nginx/conf.d# docker ps -a
CONTAINER ID   IMAGE     COMMAND                  CREATED             STATUS             PORTS                                                                      NAMES
1da527cab3cc   nginx:1   "/docker-entrypoint.…"   About an hour ago   Up About an hour   0.0.0.0:80->80/tcp, :::80->80/tcp, 0.0.0.0:443->443/tcp, :::443->443/tcp   nginx_parsing_vulnerability_nginx_1
556fe6cc6fda   php:fpm   "docker-php-entrypoi…"   About an hour ago   Up About an hour   9000/tcp                                                                   nginx_parsing_vulnerability_php_1
root@zyan-virtual-machine:/etc/nginx/conf.d# docker exec -it 1da527cab3cc /bin/bash
root@1da527cab3cc:/# cd /etc/nginx/conf.d/
root@1da527cab3cc:/etc/nginx/conf.d# ll
bash: ll: command not found
root@1da527cab3cc:/etc/nginx/conf.d# cat default.conf 
server {
        listen 80 default_server;
        listen [::]:80 default_server;
        root /usr/share/nginx/html;
        index index.html index.php;
        server_name _;
        location / {
                try_files $uri $uri/ =404;
        }
        location ~ \.php$ {
                fastcgi_index index.php;
                include fastcgi_params;
                fastcgi_param  REDIRECT_STATUS    200;
                fastcgi_param  SCRIPT_FILENAME /var/www/html$fastcgi_script_name;
                fastcgi_param  DOCUMENT_ROOT /var/www/html;
                fastcgi_pass php:9000;
        }
}root@1da527cab3cc:/etc/nginx/conf.d# 

其實(shí)這里我們可以看到是沒(méi)有問(wèn)題的。~是匹配任意值，同目錄在/var/www/html上，同時(shí)監(jiān)聽(tīng)PHP端口在9000上。雖然說(shuō)這個(gè)漏洞我知道是由于配置不當(dāng)導(dǎo)致的，但是我在這里并沒(méi)有找到配置不當(dāng)?shù)牡胤健?br />下面我想到了php-fpm，php的支持環(huán)境嘛，這里我們可以看到它的配置文件：

我們進(jìn)去配置文件里面即可看到：

這里其實(shí)就是后綴安全限制為空的意思，同時(shí)php的解析過(guò)程其實(shí)是從最后一個(gè)php開(kāi)始解析的，最后一個(gè)沒(méi)有，那么就解析上一級(jí)的，如下圖：

所以說(shuō)如果我們?cè)谶@里最后加上.php我們就會(huì)看到這里先解析最后一個(gè)，發(fā)現(xiàn)沒(méi)有，解析上一級(jí)，就會(huì)發(fā)現(xiàn)是png，然后就一解析了，也就不會(huì)造成這一樣的漏洞。說(shuō)明這個(gè)配置文件是nginx解析漏洞造成的原因之一。
當(dāng)然啦，這個(gè)配置文件默認(rèn)其實(shí)是有.php的，這個(gè)肯定是有這樣的需求。
其實(shí)還有一個(gè)原因，那就是php主配置文件中的cgi.fix_pathinfo;選項(xiàng)，這里我們可以從下圖看到這個(gè)選項(xiàng)是打開(kāi)的：

cgi.fix_pathinfo 是 PHP 主配置文件中的一個(gè)選項(xiàng)，用于處理 FastCGI 請(qǐng)求中的 PATHINFO 信息。PATHINFO 是在執(zhí)行 CGI 程序時(shí)從 URL 中提取的附加路徑信息，常用于通過(guò) URL 傳遞參數(shù)。
具體而言，cgi.fix_pathinfo 的作用是控制是否修復(fù) FastCGI 請(qǐng)求中的 PATH_INFO。當(dāng)設(shè)置為 1 時(shí)，表示啟用修復(fù)，當(dāng)設(shè)置為 0 時(shí)，表示禁用修復(fù)。

• 當(dāng) cgi.fix_pathinfo 啟用（設(shè)置為 1）時(shí)：
  • 如果 PHP 接收到的 FastCGI 請(qǐng)求中沒(méi)有 PATHINFO 信息，它會(huì)嘗試根據(jù) SCRIPTNAME 和 REQUESTURI 推斷出 PATHINFO。
  • 這種情況下可以使得像 example.com/index.php/some/path 這樣的 URL 形式能夠正常工作，即使服務(wù)器沒(méi)有實(shí)際的文件或目錄存在。
• 當(dāng) cgi.fix_pathinfo 禁用（設(shè)置為 0）時(shí)：
  • PHP 不會(huì)嘗試修復(fù) FastCGI 請(qǐng)求中的 PATH_INFO。
  • 如果 PATH_INFO 不存在，它將保持為空。

禁用 cgi.fix_pathinfo 可以提高安全性，因?yàn)閱⒂盟赡軐?dǎo)致一些安全隱患，尤其是在共享主機(jī)環(huán)境中。攻擊者可能嘗試通過(guò)構(gòu)造惡意請(qǐng)求來(lái)利用路徑信息。
在生產(chǎn)環(huán)境中，通常建議將 cgi.fix_pathinfo 設(shè)置為 0，以降低潛在的安全風(fēng)險(xiǎn)。確保你的應(yīng)用程序不依賴于 PATH_INFO 的自動(dòng)修復(fù)，并且能夠正常處理 URL 中的路徑信息。
所以，就是如果開(kāi)啟，那么php解析時(shí)候，就會(huì)按照從最后到上一級(jí)一級(jí)解析。

總結(jié)一下，這個(gè)漏洞其實(shí)是由php.ini中cgi.fix pathinfo選項(xiàng)與php-fpm的配置一起導(dǎo)致的，防范的話，只需在php-fpm配置文件中設(shè)置security.limit_extensions=.php，重啟一下服務(wù)即可。
該漏洞與nginx、php版本無(wú)關(guān),屬于用戶配置不當(dāng)造成的解析漏洞

到此這篇關(guān)于Nginx解析漏洞復(fù)現(xiàn)的文章就介紹到這了,更多相關(guān)Nginx漏洞復(fù)現(xiàn)內(nèi)容請(qǐng)搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關(guān)文章希望大家以后多多支持腳本之家！

最新評(píng)論