安全漏洞的复现与总结

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 环境安装

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

Nginx 渗透

为了感谢广大读者伙伴的支持，准备了以下福利给到大家：【一>所有资源获取<一】1、200 多本网络安全系列电子书（该有的都有了）2、全套工具包（最全中文版，想用哪个用哪个）3、100 份 src 源码技术文档（项目学习不停，实践得真知）4、网络安全基础入门、Linux、web 安全、攻防方面的视频（2021 最新版）5、网络安全学习路线（告别不入流的学习）6、ctf 夺旗赛解析（题目解析实战操作）

文件解析漏洞

漏洞描述

该漏洞与 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.65nginx 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；

（换行和回车的 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.3Nginx 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 解析之。

修复方法

升级版本

整数溢出(CVE-2017-7529)

漏洞原理

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

影响版本

Nginx 0.5.6 – 1.13.2

漏洞复现

开启漏洞

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

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

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

修复方法

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