一、漏洞描述
該漏洞與nginx、php版本無關,屬於用戶配置不當造成的解析漏洞
二、漏洞原理
1、由於nginx.conf的如下配置導致nginx把以’.php’結尾的文件交給fastcgi處理,為此可以構造http://ip/uploadfiles/test.png/.php (url結尾不一定是‘.php’,任何服務器端不存在的php文件均可,比如’a.php’),其中test.png是我們上傳的包含PHP代碼的照片文件。
2、但是fastcgi在處理’.php’文件時發現文件並不存在,這時php.ini配置文件中cgi.fix_pathinfo=1 發揮作用,這項配置用於修復路徑,如果當前路徑不存在則采用上層路徑。為此這里交由fastcgi處理的文件就變成了’/test.png’。
3、最重要的一點是php-fpm.conf中的security.limit_extensions配置項限制了fastcgi解析文件的類型(即指定什么類型的文件當做代碼解析),此項設置為空的時候才允許fastcgi將’.png’等文件當做代碼解析。
三、漏洞復現
1、進入vulhub-master的nginx/nginx_parsing_vulnerability目錄下
2、docker啟動環境
dcoker-compose up -d
3、瀏覽器訪問192.168.2.147
4、在“010editor”上修改圖片hex數據
也可以修改burp提交的數據
5、訪問http://192.168.2.147uploadfiles/c2f650ad06f7754d7afd1c6a3e4a5ee8.jpg/.php
如圖，成功解析圖片中的php代碼，說明系統存在nginx解析漏洞
四、漏洞修復
1、修改限制FPM執行解析的擴展名
2、重新啟動docker環境
3、驗證漏洞已經修復
五、漏洞影響范圍
1、 將php.ini文件中的cgi.fix_pathinfo的值設置為0,這樣php再解析1.php/1.jpg這樣的目錄時,只要1.jpg不存在就會顯示404頁面
2、 php-fpm.conf中的security.limit_extensions后面的值設置為.php
參考鏈接
https://www.cnblogs.com/yuzly/p/11208742.html
聲明
嚴禁讀者利用以上介紹知識點對網站進行非法操作 , 本文僅用於技術交流和學習 , 如果您利用文章中介紹的知識對他人造成損失 , 后果由您自行承擔 , 如果您不能同意該約定 , 請您務必不要閱讀該文章 , 感謝您的配合 !