Nginx漏洞復(fù)現(xiàn)的問(wèn)題案例解析
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)文章希望大家以后多多支持腳本之家!
相關(guān)文章
Nginx常見(jiàn)的幾種回源方式實(shí)現(xiàn)
本文主要介紹了Nginx常見(jiàn)的幾種回源方式實(shí)現(xiàn),通過(guò)Nginx回源文件至本地機(jī)房,域名解析采用內(nèi)外網(wǎng)單獨(dú)解析,外地辦公同事可以通過(guò)CDN進(jìn)行更新,感興趣的可以了解一下2024-02-02Nginx開(kāi)啟Gzip壓縮大幅提高頁(yè)面加載速度的方法
這篇文章主要介紹了Nginx開(kāi)啟Gzip壓縮大幅提高頁(yè)面加載速度的方法,小編覺(jué)得挺不錯(cuò)的,現(xiàn)在分享給大家,也給大家做個(gè)參考。一起跟隨小編過(guò)來(lái)看看吧2018-08-08nginx通過(guò)https部署vue項(xiàng)目的完整步驟
在實(shí)際開(kāi)發(fā)中,我們會(huì)以https形式進(jìn)行頁(yè)面訪問(wèn),下面這篇文章主要給大家介紹了關(guān)于nginx通過(guò)https部署vue項(xiàng)目的完整步驟,文中通過(guò)示例代碼介紹的非常詳細(xì),需要的朋友可以參考下2022-05-05Nginx + php 搭建 超性能 WEB 服務(wù)器
Nginx ("engine x") 是一個(gè)高性能的 HTTP 和反向代理服務(wù)器,也是一個(gè) IMAP/POP3/SMTP 代理服務(wù)器。2010-03-03