nginx|Nginx漏洞总结 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=https://www.it610.com/article/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
修复方法 【nginx|Nginx漏洞总结】建议升级到 1.13.3 和 1.12.1 版本；如果不能升级，可以在 Nginx 配置文件中添加 max_ranges 1，从而禁用 multipart range。