Nginx 文件名逻辑漏洞（CVE-2013-4547）分析

Nginx 文件名逻辑漏洞（CVE-2013-4547）

影响版本：Nginx 0.8.41 ~ 1.4.3 / 1.5.0 ~ 1.5.7

漏洞原理：

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

只有.php后缀的文件才会被发送给fastcgi解析。
而存在CVE-2013-4547的情况下，我们请求1.gif[0x20][0x00].php，这个URI可以匹配上正则.php$，可以进入这个Location块；但进入后，Nginx却错误地认为请求的文件是1.gif[0x20]，就设置其为SCRIPT_FILENAME的值发送给fastcgi。
fastcgi根据SCRIPT_FILENAME的值进行解析，最后造成了解析漏洞。
所以，我们只需要上传一个空格结尾的文件，即可使PHP解析之。（建议先去学习有关cgi,fastcgi的知识）

漏洞的两个必要条件：

1. 关于cgi.fix_pathinfo的配置
要关闭，如果cgi.fix_pathinfo被开启，将会先去判断文件是否存在。而不会直接去匹配location块进而被发送到fastcgi程序
2.关于高版本php"security.limit_extensions"的限制
如果配置为:

security.limit_extensions = .php

那么将只会把后缀为.php的文件当作是合法的php文件，进而我们的jpg空格文件将会被判定为不合法。进而不会被去当作php解析
漏洞演示
环境：vulhub docker
启动环境：

上传1.jpg空格文件：

访问上传的文件：

出现404的原因不是我们没用上传上去，而是在访问1.jpg空格时，空格被编码成为了%20我们没用1.jpg%20这个文件
我们通过burp抓包，改hex进行访问：



成功执行phpinfo

windows下

相比于如上使用的linux环境复现，在windows进行攻击，由于windows的特性攻击是更容易的。
**windows读取文件时的特点:**即文件系统api创建文件名或查找文件名时，默认会去掉文件名后的空格，再执行操作.
此时的攻击过程为：
1.上传任意文件（不需要带空格文件）
2.http://ip/a.jpg0x20x00.php（burp进行hex更改后访问）
即可攻击成功