Nginx 解析漏洞

news2024/11/29 22:40:37

文章目录

Nginx 解析漏洞
- 1. 空字节漏洞
- - 1.1 漏洞描述
  - 1.2 漏洞复现
  - 1.3 修复方案
- 2. Nginx 解析漏洞复现
- - 2.1 漏洞描述
  - 2.2 漏洞复现
  - 2.3 获取GetShell
  - 2.4 修复方案
- 3. Nginx 文件名逻辑漏洞
- - 3.1 漏洞描述
  - 3.2 漏洞原理
  - 3.3 漏洞复现
  - - 3.3.1 环境启动
    - 3.3.2 漏洞验证
  - 3.4 漏洞利用
  - 3.5 修复方案

Nginx 解析漏洞

1. 空字节漏洞

1.1 漏洞描述

说明	内容
漏洞编号
漏洞名称	Nginx解析漏洞
漏洞评级	高危
影响范围	0.5.,0.6., 0.7 <= 0.7.65, 0.8 <= 0.8.37
漏洞描述	当使用PHP-FastCGI执行PHP时，遇到url里面存在%00空字节时与FastCGI的处理不一致，导致可在非PHP文件中嵌入PHP代码，通过访问url+%00.PHP来执行其中的PHP代码
修复方案	升级组件

1.2 漏洞复现

启动环境

访问页面

看到如下页面及启动成功

在nginx_0.7.65目录下的html目录中有一个info.png

从后缀名来看这个是一个图片，但是如果从文件内容的角度来看是一个phpinfo。

这个图片是无法直接进行访问的。

使用bp抓取数据包，然后在文件后缀名末尾添加%00.php

该文件即可执行。

解析：此处这个漏洞属于00截断漏洞，文件系统在处理寻找文件的时候会有偏差，PHP语言的底层是通过C语言来实现的，C语言字符串结束是00。PHP解释引擎在访问这个文件的时候，遇到了00，认为该文件在%00处就结束了，所以读取的是png文件，但是是以php方式执行的。

1.3 修复方案

为了修复此漏洞，可以考虑以下方案：

更新 NGINX 版本：确保您的 NGINX 版本已升级到最新版本。NGINX 团队通常会修复安全漏洞，并发布相关的更新补丁。及时更新可帮助解决已知的漏洞。
安装安全模块： NGINX 支持许多第三方安全模块，例如 ModSecurity 或 NAXSI。这些模块可以帮助检测和阻止恶意请求，包括空字节注入攻击。
过滤输入：对于用户提供的输入，进行适当的输入验证和过滤。对于文件路径、文件名等参数，应该对空字节进行处理或过滤，以防止攻击者利用空字节绕过文件类型检查。

2. Nginx 解析漏洞复现

链接地址：Vulhub - 用于漏洞环境的 Docker-Compose 文件。

2.1 漏洞描述

说明	内容
漏洞编号
漏洞名称	Nginx解析漏洞
漏洞评级	高危
影响范围	Nginx 1.x 最新版，PHP 7.x最新版
漏洞描述	该漏洞与Nginx、php版本无关，属于用户配置不当造成的解析漏洞。
修复方案	升级组件

2.2 漏洞复现

环境启动

访问页面

上传一个php文件，页面显示我们只能上传图像文件。

修改文件后缀名，Content-Type类型为image/png，最后在文件内容的头部添加GIF89a。

上传成功，并且显示出了文件的上传路径。

页面访问上传路径，但是文件并没有执行。

增加后缀，被解析成PHP文件：/.php。

漏洞原因：开启了cgi.fix_pathinfo选项后，本身是一个png文件，但是加上/.php后会把整个文件当中php文件来执行。

2.3 获取GetShell

还可以上传一个一句话木马

使用bp抓取数据包并进行修改

然后使用蚁剑进行连接即可。

2.4 修复方案

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

3. Nginx 文件名逻辑漏洞

链接地址：Vulhub - Docker-Compose file for vulnerability environment。

3.1 漏洞描述

说明	内容
漏洞编号	CVE-2013-4547
漏洞名称	Nginx 文件名逻辑漏洞
漏洞评级	高危
影响范围	Nginx 0.8.41 ~ 1.4.3 / 1.5.0 ~ 1.5.7
漏洞描述	该漏洞存在于Nginx于PHP的配置上，如果配置不当，容易使得Nginx实现对%00等特殊字符解析出现问题，造成Nginx将特殊构造的URL交给PHP来进行处理，而Nginx则因为特殊字符的问题，无法接收含有特殊字符的URL或者是造成了在%00位置处的截断，从而造成了客户上传的文件被当作PHP代码来解析。
修复方案	升级组件

3.2 漏洞原理

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

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

location ~ \.php$ {
    include        fastcgi_params;

    fastcgi_pass   127.0.0.1:9000;
    fastcgi_index  index.php;
    fastcgi_param  SCRIPT_FILENAME  /var/www/html$fastcgi_script_name;
    fastcgi_param  DOCUMENT_ROOT /var/www/html;
}

正常情况下（关闭pathinfo的情况下），只有.php后缀的文件才会被发送给fastcgi解析。而存在Nginx 文件名逻辑漏洞的情况下，我们请求1.gif[0x20][0x00].php，这个URI可以匹配上正则\.php$，可以进入这个Location块；但进入后，Nginx却错误地认为请求的文件是1.gif[0x20]，就设置其为SCRIPT_FILENAME的值发送给fastcgi。

fastcgi根据SCRIPT_FILENAME的值进行解析，最后造成了解析漏洞。