nginx漏洞总结(代码片段)

Nginx简介

Nginx (engine x) 是一个高性能的HTTP和反向代理web服务器，同时也提供了IMAP/POP3/SMTP服务。其将源代码以类BSD许可证的形式发布，因它的稳定性、丰富的功能集、简单的配置文件和低系统资源的消耗而闻名。2011年6月1日，nginx 1.0.4发布。

Nginx是一款轻量级的Web服务器/反向代理服务器及电子邮件（IMAP/POP3）代理服务器，在BSD-like 协议下发行。其特点是占有内存少，并发能力强，事实上nginx的并发能力在同类型的网页服务器中表现较好，中国大陆使用nginx网站用户有：百度、京东、新浪、网易、腾讯、淘宝等。

Nginx环境安装

这里我用的小皮代替，就不一步步安装了

不用小皮安装的可以参考这两个：

https://zhuanlan.zhihu.com/p/83890573

https://www.runoob.com/linux/nginx-install-setup.html

Nginx渗透

文件解析漏洞

漏洞描述

该漏洞与nginx、php版本无关,属于用户配置不当造成的解析漏洞。由于nginx.conf的如下配置导致nginx把以’.php’结尾的文件交给fastcgi处理,对于任意文件名，在后面添加/xxx.php（xxx）为任意字符后，即可将文件作为php解析。

常见的漏洞配置：

漏洞复现

新建一个1.jpg写入phpinfo

1.jpg后面加上/xxx.php，便会以php解析

当访问/1.jpg/xxx.php时，nginx将查看url，看到它以.php结尾，将路径传给PHP fastcgi进行处理。但是fastcgi在处理’xxx.php’文件时发现文件并不存在,这时php.ini配置文件中cgi.fix_pathinfo=1 发挥作用,这项配置默认开启，值为1，用于修复路径,如果当前路径不存在则采用上层路径。为此这里交由fastcgi处理的文件就变成了’/1.jpg’。新版本的php的配置文件php-fpm.conf引入了“security.limit_extensions”，限制了可执行文件的后缀，默认只允许执行.php文件。

修复方法

1、 将php.ini文件中的cgi.fix_pathinfo的值设置为0

2、 php-fpm.conf中的security.limit_extensions后面的值设置为.php

目录遍历

漏洞原理

Nginx的目录遍历与apache一样,属于配置方面的问题,错误的配置可导致目录遍历与源码泄露。

漏洞复现

在www目录下新建一个web目录测试

修复方法

修复on改为off即可。

空字节任意代码执行漏洞

漏洞原理

Ngnix在遇到%00空字节时与后端FastCGI处理不一致，导致可以在图片中嵌入PHP代码然后通过访问xxx.jpg%00.php来执行其中的代码.

影响版本

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

漏洞复现

这里复现环境是Nginx 0.7.65+php 5.3.2，这里需要电脑上有.net framework4的环境。

在nginx目录下执行startup.bat

建立1.jpg，写入

访问1.jpg…php,抓包

在hex选项卡中将jpg后面的点修改为00

成功绕过。

forward一下

该漏洞不受cgi.fix_pathinfo影响，其为0也能解析。

修复方法

升级nginx版本。

CRLF注入漏洞

漏洞原理

CRLF是”回车+换行”(rn)的简称,其十六进制编码分别为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.是配置中的$url是我们可以控制的,这样我们就可以在$url处填入CRLF,然后对服务器进行访问实现头部注入。
2.服务器会返回一个302跳转给用户,所以我们注入的头部参数又会返回到客户这边。

漏洞复现

修改完上面nginx.conf配置后，重启nginx；

访问链接：http://192.168.190.150/%0ASet-cookie:JSPSESSID%3D6666

（换行和回车的URL编码分别是%0d%0a）

抓包，可以看到将6666通过set-cookie返回；

CRLF+XSS配合：

%0D%0A%0D%0A%3Cimg%20src=1%20onerror=alert(/xss/)%3E

不过这里浏览器并没有弹窗，那是因为浏览器filter对xss特征进行了过滤，这里用低版本浏览器才可以弹出来。

修复方法

删除配置不当的配置。

文件名逻辑漏洞(CVE-2013-4547)

漏洞原理

当请求如下URI时：/test[0x20]/…/admin/index.php，这个URI不会匹配上location后面的/admin/，也就绕过了其中的IP验证；但最后请求的是/test[0x20]/…/admin/index.php文件，也就是/admin/index.php，成功访问到后台。（这个前提是需要有一个目录叫test：这是Linux系统的特点，如果有一个不存在的目录，则即使跳转到上一层，也会爆文件不存在的错误，Windows下没有这个限制）。

影响版本

Nginx 0.8.41 ~ 1.4.3
Nginx 1.5.0 ~ 1.5.7

漏洞复现

windows环境下不允许存在文件名后带空格的文件，因此复现使用vulhub进行测试。

启动漏洞环境：

上传1.jpg，并进行抓包；

在1.jpg后添加一个空格

访问返回的该链接并加.php抓包；

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

在hex选项卡中将jpg后面的2个点的hex值2e分别修改为20，00；

成功绕过。

这个漏洞主要原因是错误地解析了请求的URL，错误地获取到用户请求的文件名，导致出现权限绕过、代码执行的连带影响。

Nginx匹配到.php结尾的请求，就发送给fastcgi进行解析，常见的写法如下：

正常情况下（关闭pathinfo的情况下），只有.php后缀的文件才会被发送给fastcgi解析。

而存在CVE-2013-4547的情况下，我们请求1.jpg\\0x20\\0x00.php，这个URI可以匹配上正则.php$，可以进入这个Location块；但进入后，Nginx却错误地认为请求的文件是1.jpg\\0x20，就设置其为SCRIPT_FILENAME的值发送给fastcgi。fastcgi根据SCRIPT_FILENAME的值进行解析，最后造成了解析漏洞。所以，我们只需要上传一个空格结尾的文件，即可使PHP解析之。

参考链接：https://blog.csdn.net/weixin_40412037/article/details/106234840

修复方法

升级版本

整数溢出(CVE-2017-7529)

漏洞原理

在Nginx的range filter中存在整数溢出漏洞，可以通过带有特殊构造的range的HTTP头的恶意请求引发这个整数溢出漏洞，并导致信息泄露。

影响版本

Nginx 0.5.6 – 1.13.2

漏洞复现

开启漏洞

在靶机web根目录下创建一个图片文件当缓存文件

去靶机中的 /tmp/nginx中查看缓存文件，可以看到，cache key的内容保存在了里面，此外还有服务器信息，这些都是不会返回给客户端的，但是因为这次的漏洞而导致这些信息也被返回，导致信息泄露；

对，这个没成功，缓存文件中的这些信息并没有返回回来，先待定~

参考文档：https://paper.seebug.org/353/ https://cloud.tencent.com/developer/article/1680569

修复方法

建议升级到 1.13.3 和 1.12.1 版本；如果不能升级，可以在 Nginx 配置文件中添加 max_ranges 1，从而禁用 multipart range。