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

目录

1. 了解nginx的工作原理

2. 漏洞原理及举例分析

3. 前端php源码分析

4. 注入思路

5. 漏洞复现

5.1 上传文件并抓包分析

 5.2 通过访问文件执行php

 注意一点

6. 漏洞修复

1. 了解Nginx的工作原理

nginx是以PHP语言为主。像Apache一样，Nginx自身是不支持解析php语言的，只能通过加载PHP模块来解析PHP。原理图可以看下图：

Nginx解析PHP原理图

nginx接收到数据后会依赖FastCG协议I将数据进行一次格式化，然后 PHP-FPM 会创建许多的PHPCGI进程用于处理FastCGI协议格式化好的数据，处理完后会将数据交给 php 处理，最后会将处理好的数据返回给浏览器。

注意这里FastCGI处理后的数据和PHP-FPM处理的数据结构相同，所以可以被PHPCGI模块直接调用。

通过原理图和刚才的定义，我们对Nginx处理PHP请求有了大致的了解。那么，Nginx是如何知道将什么样的文件当作PHP文件处理？是在nginx.conf配置文件中的

location ~ \.php$ {    root           html;    include        fastcgi_params;​    fastcgi_pass   IP:9000;    fastcgi_index  index.php;    fastcgi_param  SCRIPT_FILENAME  /var/www/html$fastcgi_script_name;    fastcgi_param  DOCUMENT_ROOT /var/www/html;}

location后面的.php$代表了以.php结尾的文件都按照花括号中的内容执行，其中fastcgi_pass就是nginx和php-fpm的媒介，Nginx将请求通过fastcgi_pass转发给php-fpm。fastcgi_pass可以和Nginx不在同一台服务器上，他们通过IP+PORT的方式进行通信。

2. 漏洞原理及举例分析

CVE-2013-4547漏洞是由于非法字符空格和截止符导致Nginx在解析URL时的有限状态机混乱，导致攻击者可以通过一个非编码空格绕过后缀名限制。假设服务器中存在文件123. jpg，则可以通过改包访问让服务器认为访问的为PHP文件。

这个漏洞其实和代码执行没有太大关系，其主要原因是错误地解析了请求的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解析。

而存在CVE-2013-4547的情况下，我们请求1.gif[0x20][0x00].php，这个URI可以匹配上正则\.php$，可以进入这个Location块；但进入后，Nginx却错误地认为请求的文件是1.gif[0x20]，就设置其为SCRIPT_FILENAME的值发送给fastcgi。

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

所以，我们只需要上传一个空格结尾的文件，即可使PHP解析之。

3. 前端php源码分析

 框住的内容为使用后缀名过滤上传的文件，若文件的后缀名为 'php', 'php3', 'php5', 'phtml' 中的一个则前端会拒绝上传此文件。

但在关闭pathinfo的情况下，只有.php后缀的文件才会被发送给fastcgi解析之后进行上传。

4. 注入思路

该漏洞利用了Nginx错误的解析了URL地址，导致可以绕过服务端限制，从而解析PHP文件，造成命令执行的危害。 根据nginx.conf文件中location中的定义，以.php结尾的文件都解析为php。若我们访问的文件名为shell.gif0x20.php，该文件名以.php结尾可以被FastCGI接收，FastCGI在读取文件名时被00截断，导致读取的文件名为1.gif[0x20]，配合limit_extensions为空即可利用成功。该漏洞利用条件有两个：

1. Nginx 0.8.41 ~ 1.4.3 / 1.5.0 ~ 1.5.7

2. php-fpm.conf中的security.limit_extensions为空，也就是说任意后缀名都可以解析为PHP

 security.limit_extensions 为php的安全限制开启状态只允许有.php后缀的文件进行PHP处理。

5. 漏洞复现

进入/vulhub/nginx/CVE-2013-4547，启动靶场环境：Docker-compose up -d 我们通过一个写有 php命令的 .jpg 文件上传一个图片的 WEBshell 命令如下：

5.1 上传文件并抓包分析

 将文件重命名为shell.jpg 截断符.php

这里先用aa进行占位，之后通过16进制进行修改

 这里的 61 为 16进制的a，我们要将这里的aa修改为空格（20）和截断符（00）

 最终上传的包为

这里文件整体的后缀名为.php所以这个文件会交给FastCGI处理，之后FastCGI会将文件名从截断符处截断这时的文件名为 shell.jpg0x20  同时这样也绕过了前端代码对.php文件的过滤，然后将文件上传。

上传的结果：

 5.2 通过访问文件执行php

这里我们通过访问网址进行抓包修改

抓到的包

 进行修改：

 这里的aa依就是占位，便于通过16进制修改文件名

 修改好后的文件名：

 这里也是一样包中的请求文件的总体后缀名为.php，nginx会首先将文件交给FastCGI处理并截断则请求的文件名为 shell.jpg，之后会交给PHP-FPM处理此时php-fpm.conf中的security.limit_extensions为空，也就是说任意后缀名都可以解析为PHP 所以会将 shell.jpg 文件当作php文件处理并返回给浏览器形成逻辑漏洞。

请求结果：

 注意一点

在上传文件时为什么要以.php后缀截断的方式上传而不能直接上传 shell,jpg 文件呢？反正结果后面的.php后缀最后都会被截断掉。

因为这里的注入形式中由于请求文件被截断时空格被保留，所以请求文件的后缀名中一定会包含空格，否则会出现找不到文件的情况，因此我们在上传文件时就要以 .php 后缀被截断的方式来进行上传以来保留空格。

6. 漏洞修复

将Nginx升级到1.5.7之后

来源地址：https://blog.csdn.net/m0_63306943/article/details/130466085