Nginx中間件漏洞原理深究及復現方法

Nginx中間件漏洞原理深究及復現方法，相信很多沒有經驗的人對此束手無策，為此本文總結了問題出現的原因和解決方法，通過這篇文章希望你能解決這個問題。

一、簡介

1、什么是Nginx

Ningx(engine x)是一個高性能的HTTP和反向代理web服務器，同時也提供了IMAP/POP3/SMTP服務。其將源代碼以類BSD許可證的形式發布，因它的穩定性、豐富的功能集、示例配置文件和低系統資源的消耗而聞名。

Nginx是一款輕量級的Web 服務器/反向代理服務器及電子郵件（IMAP/POP3）代理服務器，在BSD-like 協議下發行。其特點是占有內存少，并發能力強，nginx的并發能力在同類型的網頁服務器中表現較好。

2、Nginx的特點

1、跨平臺：Nginx 可以在大多數 Unix Linux OS 上編譯運行，并有 Windows 移植版。

2、支持高并發：Nginx 是一個很強大的高性能Web和反向代理服務，可以支持高達 50,000 個并發連接數的響應。

3、內存低：Nginx采用C語言進行編寫，系統資源開銷還是CPU使用效率都比 Perlbal 要好很多。

4、負載均衡和HTTP服務器：Nginx作為負載均衡服務：Nginx 既可以在內部直接支持 Rails 和 PHP 程序對外進行服務，也可以支持作為 HTTP代理服務對外進行服務。實現無緩存的反向代理加速，簡單的負載均衡和容錯。

5、穩定性高：用于反向代理，宕機的概率微乎其微。 等等...

3、nginx用來做什么

1、靜態HTTP服務

首先，Nginx是一個HTTP服務器，可以將服務器上的靜態文件（如HTML、圖片）通過http協議展示給客服端。

Nginx相較于Apache\lighttpd具有占有內存少。穩定性高等優勢，而且依靠并發能力強。豐富的模塊庫以及友好靈活的配置而聞名。

Nginx本身也是一個靜態資源的服務器，當只有靜態資源的時候，就可以使用Nginx來做服務器，同時現在也很流行動靜分離，就可以通過Nginx來實現，動靜分離是讓動態網頁很久一定規則吧不變得資源和經常變得資源區分開來，動靜資源做好拆分之后，我們就可以根據靜態資源的特點將其作緩存操作，這就是網站靜態化處理的核心思路。

2、代理服務器

1）關于代理

說到代理，我們首先明確一個概念，所謂代理就是一個渠道、一個通道。

就像我們去店里買鞋，分為客戶、專賣店、鞋廠，我們需要鞋子的時候，如果直接去鞋廠買一定行不通的，我們需要去專賣店買，店里的鞋是鞋廠做的。客戶對應客戶端、專賣店對應代理、鞋廠對應服務端，客戶端無法直接想服務端通信，代理可以向服務端通信，客戶端向代理請求，代理將客戶端的請求轉發給服務端，實現客戶端和服務器的通信。代理位于客戶端與服務端之間，扮演“中間人”的角色。

2）正向代理

正向代理是一個位于客戶端和服務端之間。使用它，客戶端不是直接到服務端請求數據，而是向地理服務器發送請求，請求先送到代理服務器，有代理服務器轉發給服務端，數據返回也是如此。

3）反向代理

在服務端結束客服端的請求，然后發請求分發給具體的服務器進行處理，然后再將服務器的響應結果反饋給客戶端，Nginx就是其中的一個反向代理軟件。正向代理，客戶端必須設置正向代理服務器的IP地址和代理程序的端口，而反向代理正好與正向代理相反，對于客戶端而言代理服務器就像服務端，并且客戶端不需要進行任何特別設置。客戶端向反向代理的命令空間中的內容發送普通請求，接著反向代理將判斷向何處的服務端轉交請求，并將獲得的內容返回給客戶端。

3、負載均衡

當網站訪問量非常大的時候，需要將同一應用部署在多臺服務器上，將大量用戶的請求分配給多臺機器處理。同時帶來的好處是，其中一臺服務器萬一掛了，只要還有其他的服務器正常運行，就不會影響用戶使用。

Nginx可以通過反向代理來實現負載均衡

負載均衡的意思就是分攤到多個操作單元上進行執行，例如：web服務器，FTP服務器等其他關鍵任務的服務器。從而共同完成工作任務，簡單而言就是當有2臺或以上服務器時，根據規則將請求分發到不同服務器處理，負載均衡配置一般都需要同時配置反向代理，通過反向代理跳轉到負載均衡，而Nginx目前支持自帶3種負載均衡策略，還有2種常用的第三方策略。

4、虛擬主機

有些網站訪問量太小時，為了節約成本，將多個網站不符在同一臺服務器上，例如將www.123.com和www.456.com兩個網站部署在同一臺服務器上，兩個域名解析到同一個IP地址，但用戶通過兩個域名打開兩個完全不同的網站，互不影響，就像訪問兩個服務器一樣，所以叫虛擬主機。

Nginx下載官網：
http://nginx.org/en/download.html

二、Nginx環境安裝

直接使用phpstudy部署Nginx+php環境

訪問80端口

三 、Nginx文件解析漏洞

漏洞復現

對于任意文件名，在后面添加/abc.php(abc為任意字符)后，即可將文件作為php解析。

創建一個jpg文件，并包含php代碼

訪問phpinfo.jpg，在后面增加/abc.php，會將jpg文件以php格式解析

http://192.168.43.136/phpinfo.jpg/abc.php

漏洞原理分析

該漏洞是Nginx配置導致，與nginx版本無關，nginx.conf中配置

/phpStudy/PHPTutorial/nginx/conf/nginx.conf`

server{
 location ~ \.php$ {
        #    root           html;
            fastcgi_pass   127.0.0.1:9000;
            fastcgi_index  index.php;
        #    fastcgi_param  SCRIPT_FILENAME  /scripts$fastcgi_script_name;
            fastcgi_param  SCRIPT_FILENAME  $document_root$fastcgi_script_name;
            include        fastcgi_params;
        }
}

當攻擊者訪問/phpinfo.jpg/abc.php時，Nginx將查看URL，看到他以.php結尾，并將路徑傳遞給php fastcgi處理程序，php看到/phpinfo.jpg/abc.php不存在，便刪除去最后的/abc.php，看到phpinfo.jpg存在，而后以php的形式執行.jpg的內容。

這里php在執行/phpinfo.jpg/abc.php為什么找不到文件就會刪除去最后的/abc.php呢？，這里涉及到php的有一個選擇：cgi.fix_pathinfo，該配置默認為1，開啟狀態，表示對文件路徑進行“修理”。何為”修理“，舉個例子：當php遇到文件路徑“/1.aaa/2.bbb/3.cccc"文件時，若“/1.aaa/2.bbb/3.cccc"不存在，則會去掉最后的”/3.ccc",然后判斷“/1.aaa/2.bbb”是否存在，若不存在，則繼續去掉“/2.bbb”,以此類推。

該配置在php.ini設置。若關閉該選項，訪問/phpinfo.jpg/abc.php會返回找不到文件，但關閉該選項可能會導致一些其他初五，所有默認開啟。

在php.ini中為注釋狀態

在較新版本的php引入了“security.limit_extensions”配置，限制了php執行文件的后綴，默認只允許執行.php文件。該配置在php-fpm.conf文件中配置。如果想讓php解析jpg，需要如下配置：

security.limit_extensions = .php .jpg

根據上面測試，這一漏洞是有nginx中php配置不當而造成的，與nginx版本無關，但在高版本的php中，由于“security.limit_extensions”的引入，使得該漏洞難以被利用。

修復建議

1、配置cgi.fix_pathinfo(php.ini中)為0，并重啟php-cgi程序。
2、如果需要使用cgi.fix_pathinfo這個特性（例如：wordpress),那么就進制上傳目錄的執行腳本權限，或將上傳存儲的內容與網站分離，及站庫分離。
3、高版本php提供了security.limit_extensions（php-fpm.conf中)這個配置參數，設置security.limit_extensions = .php

四、目錄遍歷漏洞

漏洞簡述

Nginx的目錄遍歷與Apache一樣，屬于配置方面的問題，錯誤的配置可能導致目錄遍歷與源代碼泄露。

漏洞復現

修改C:\phpStudy\PHPTutorial\nginx\conf\nginx.conf，將autoindex修改為on，如下圖所示：

訪問一個目錄

修復建議

修改C:\phpStudy\PHPTutorial\nginx\conf\nginx.conf，將autoindex修改為off

五、空字節任意代碼執行漏洞

漏洞簡述

Nginx在遇到%00空字節時與后段FastCGI處理不一致，導致可以在圖中嵌入PHP代碼然后通過訪問1.jpg%00.php來執行其中的代碼。

影響版本

nginx 0.5.*
nginx 0.6.*
nginx 0.7 <= 0.7.65
nginx 0.8 <= 0.8.37

漏洞復現

在網上找到一個nginx 0.7.56+PHP 5.3.2環境的安裝包，直接運行安裝

訪問80端口

在html目錄下創建phpinfo.php測試nginx是否可以解析php

訪問phpinfo.php

在html目錄下創建1.jpg，內容為

<?php phpinfo();?>

訪問1.jpg，無法解析文件中phpinfo函數

使用burp抓取訪問1.jpg的請求報，并修改為1.jpg%00.php,請求成功。

或者修改hex編碼，將1.jpg修改為1.jpg..php，并將hex編碼2e修改為00

修改前

修改后

重發請求，返回碼為200，成功繞過

該漏洞不受cgi.fix_pathinfo影響，當為0時，依舊可以解析

修復建議

1、臨時解決方案：
在nginx虛擬機配置或者fcgi.conf配置加如下代碼
if ( $fastcgi_script_name ~ \..*\/.*php ) {
	return 403;
}
2、升級到最新版本的nginx可以很好解決問題。

六、CRLF（換行回車）注入漏洞

漏洞簡述

CRLF是“回車+換行”（\r\n)的檢查，其十六進制編碼分別為0x0d和0x0a。在HTTP協議中，HTTP header與HTTP Body是用兩個CRLF分隔的，瀏覽器就是根據這兩個CRLF來取出HTTP內容顯示出來。所以，一旦我們能夠控制HTTP消息頭中的字符，注入一些惡意的換行，這樣我們就能注入一些回話Cookie或者HTML代碼。CRLF漏洞常出現在Location與Set-cookie消息頭中。

漏洞分析

在nginx.conf中，在location位置添加配置，當用戶訪問nginx服務器時此配置實現強制跳轉到https協議訪問之前訪問的鏈接。

location / {
	return 302 https://$host$uri;
}

上面的配置的關鍵利用點有兩個：

1、配置中$uri是我們可以控制的，這樣我們就可以在$uri處填入CRLF，然后對服務器進行訪問實現頭部注入。

2、服務器返回一個302跳轉給用戶，所以我們注入的頭部參數又會返回到客戶這里。

漏洞復現

修改nginx.conf中配置，重啟nginx

訪問鏈接

http://192.168.43.136/%0ASet-cookie:JSPSESSID%3D1234

我們看到將1234通過set-cookie返回

CRLF+反射XSS配置

http://192.168.43.136/%0D%0A%0D%0A%3Cimg%20src=1%20test=alert(/xss/)%3E

為什么在瀏覽器沒有返回彈窗呢，那是因為firefox對xss特征進行了過濾。

原理請參考：
https://www.leavesongs.com/PENETRATION/bottle-crlf-cve-2016-9964.html

老版本瀏覽器：

漏洞危害

劫持合法用戶回復，利用管理員身份進行惡意操作，篡改頁面內容，進一步滲透網站等

利用CRLF Injection設置一個session，造成一個“回話固定漏洞”

CRLF深入配合滲透：

攻擊者操作：
1、攻擊者先打開一個網站http://www.baidu.com,然后服務器回復他一個session id。比如SID=test。攻擊者把這個ID記下來。
2、攻擊者給被攻擊者發送一個電子郵件，他假裝自己是推銷什么，誘導攻擊者點擊鏈接http://yinhang/?SID=test,SID后面就是攻擊者自己的session id。
3、被攻擊者被吸引了，點擊了http://yinhang/?SID=test，像往常一樣，輸入了自己的賬號口令從而登錄到銀行網站。
4、因為服務器的seesion id不改變，現在攻擊者點擊http://yinhang/?SID=test后，他就擁有了被攻擊者的身份了。就可以為所欲為了。

修復建議

1、刪除nginx.conf文件中return 302 https://$host$uri;部分，重啟nginx

七、文件名邏輯漏洞（CVE-2013-4547)

漏洞簡述

這個漏洞主要原因是錯誤的解析了請求的URL，錯誤的獲取到了用戶請求的文件名，導致出現權限熬過，代碼執行的連帶影響。

我們需要上傳一個空格結尾的文件，可使php解析。

影響版本

Nginx 0.8.41 ~ 1.4.3 / 1.5.0 ~ 1.5.7（linux系統）

漏洞復現

windows環境下不允許存在文件名后帶空格的文件，因此復現使用vaulhub進行測試。

啟動CVE=2013-4547環境

cd /root/vulhub-master/nginx/CVE-2013-4547
sudo docker-compose build
sudo docker-compose up -d
docker ps

訪問8080端口

上傳1.jpg

使用burp抓取，上傳的1.jpg請求包,并在上傳的文件名部分添加一個空格

上傳文件

訪問連接

http://192.168.43.129:8080/uploadfiles/1.jpg.php

修改請求頭為/uploadfiles/1.jpg...php，并修改hex數據包將..修改為20（空格）、00（截止符\0）

修改前

修改后

訪問成功

成功繞過

漏洞分析

Nginx匹配到.php結尾的請求，就會發送給php-fastcgi進行接，該源碼如下：

location ~ \.php$ {
           root           html;
           include        fastcgi_params;
           fastcgi_pass   php:9000;
           fastcgi_index  index.php;
           fastcgi_param  SCRIPT_FILENAME  /var/www/html$fastcgi_script_name;
           fastcgi_param  DOCUMENT_ROOT /var/www/html;
        }

關閉pathinfo的情況下，只有.php后綴的文件才會被php-fastcgi解析

而存在CVE-2013-4547的情況下，我們請求1.jpg0x\200x\00.php,這個URL可以匹配上正則.php$,可以進入這個location代碼塊，但進入后，nginx卻錯誤的認為請求文件時1.jpg0x\20,就設置為SCRIPT_FILENAME進行解析，最后導致解析漏洞。所以，我們只需要上傳一個空格結尾的文件，即可使php解析。

修復建議

去除location ~ \.php$中最后的$,重啟nginx

看完上述內容，你們掌握Nginx中間件漏洞原理深究及復現方法的方法了嗎？如果還想學到更多技能或想了解更多相關內容，歡迎關注億速云行業資訊頻道，感謝各位的閱讀！