Nginx 解析漏洞復現
漏洞成因
該漏洞與Nginx、php版本無關，屬於用戶配置不當造成的解析漏洞。
1、由於nginx.conf的錯誤配置導致nginx把以".php"結尾的文件交給fastcgi處理,為此可以構造http://172.168.30.190/uploadfiles/hacker.png/XXXX.php ,其中hacker.png是我們上傳的包含PHP代碼的圖片文件。
2、但是fastcgi在處理"XXXX.php"文件時發現文件並不存在,這時php.ini配置文件中cgi.fix_pathinfo=1 發揮作用,這項配置用於修復路徑,如果當前路徑不存在則采用上層路徑。為此這里交由fastcgi處理的文件就變成了"/test.png"。
3、 最重要的一點是php-fpm.conf中的security.limit_extensions配置項限制了fastcgi解析文件的類型(即指定什么類型的文件當做代碼解析),此項設置為空的時候才允許fastcgi將".png"等文件當做代碼解析。
注:限制fpm允許解析的腳本擴展名。此設置可以預防web服務器配置的錯誤。應當限制fpm僅僅解析.php擴展名,阻止惡意用戶使用其他擴展名運行php代碼。默認值:.php
漏洞環境
vulhub docker
vulhub/nginx/nginx_parsing_vulnerability
docker-compose up -d
靶機：172.168.30.190
- Nginx 1.19.6
- PHP 7.x最新版
漏洞復現
訪問http://172.168.30.190/uploadfiles/nginx.png
抓包改包后 服務器返回 將圖片解析后的結果返回 這里是因為圖片里有一句
訪問http://172.168.30.190/index.php上傳圖片，然后抓包改包
服務器返回文件位置 瀏覽器訪問
http://172.168.30.190/uploadfiles/e3ee89bdb371e5bcfc0dca371bca76bf.png/.XXXX.php
發現在圖片中的插入的php代碼被fast-cgi程序解析
修復方法
在nginx配置文件php-fpm.conf中將“security.limit_extensions = ”參數更改為 “.php“ 然后重啟服務
docker-compose restart
我這里是重啟容器
再次訪問被拒絕
參考
[1] https://vulhub.org/#/environments/nginx/nginx_parsing_vulnerability/