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= /

我们的返回包就会变成这样：

这样就造成了反射型xss

参考：https://www.cnblogs.com/null1433/p/12725776.html

文件名逻辑漏洞（CVE-2013-4547）

1.漏洞描述

这一漏洞的原理是非法字符空格和截止符（\0）会导致Nginx解析URI时的有限状态机混乱，此漏洞可导

致目录跨越及代码执行，其影响版本为：nginx 0.8.41 – 1.5.6

漏洞影响版本

Nginx 0.8.41~1.4.3

Nginx 1.5.0~1.5.7

2.漏洞复现

创建 1.jpg 文件，并上传

以vulnhub提供的漏洞环境为例，我们首先看一下前端页面

可以看到上传成功

访问该文件，burpbuite抓包处理

访问URL：http://192.168.112.111/1.jpg...php

在burp的hex页面中将第一个点.改成20，第二个改为00

3.漏洞修复

1.升级nginx

参考：https://www.cnblogs.com/yuzly/p/11221564.html

https://www.cnblogs.com/bmjoker/p/9838600.html