【漏洞复现】Nginx 文件名逻辑漏洞（CVE-2013-4547）

前言：

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

影响版本：

Nginx 0.8.41 ~ 1.4.3 / 1.5.0 ~ 1.5.7

漏洞复现：

kali部署docker环境，并且搭建vulhub漏洞环境，此处略过在kali中如何部署docker，以及在docker中安装vulhub漏洞环境的步骤。

当漏洞环境部署好了以后，启动漏洞环境

docker-compose build
docker-compose up -d

查看环境是否部署成功

docker ps

访问漏洞环境

本地浏览器开启burp代理，进行文件上传操作，直接上传.php文件失败

尝试修改后缀为.png，上传成功。

尝试访问

尝试修改文件名为info.png.php访问，根据返回包的提示得知此时ngnix已经把文件info.png.php交给fastcgi处理，只不过未找到文件。所以提示No input file ……

那么到这一步后，我们的Nginx 文件名逻辑漏洞该如何利用？我们来分下下Nginx代码
通过调试我们可以发现nginx发现文件名中存在\0截断符时会返回错误信息代码如下所示，这也就是为什么我们上面没有接收到任何的响应信息原因。

	 case '\0':  
 		return NGX_HTTP_PARSE_INVALID_REQUEST;

在仔细调试代码发现但如果nginx发现URI中存在空格会跳到如下代码，这时ch=\0

上面代码执行完后state='sw_check_uri’然后继续处理URI中的剩余部分，这说明了如果空格和零截断符相邻的话ngin就不会检测到零截断并放回错误了，这时一个逻辑漏洞，所以通过这种方式我们就可以在URI中开心的使用零截断的，这就是CVE-2013-4547。

利用方式：

尝试构造url地址：

http://127.0.0.1/uploads/abc.jpg[20][00].php

nginx对上面的URI处理后将abc.jpg[20][00].php交给fastcgi处理，由于零截断fastcgi实际处理的文件为abc.jpg[00]，这个文件需要存在fastcgi才能正常处理。在Windows环境下由于命名文件时不允许文件后缀末尾存在空格所以自动将其修复为abc.jpg，这种情况下我们只需要上传一张包含代码的名字为abc.jpg的文件就可以利用漏洞了。但是在Linux情况下情况就不一样了。在Linux环境中由于允许文件后缀名最后存在空格所以我们需要确保我们传过去的文件名为abc.jpg[20]，我们可以在文件上传时使用Burpsuit在后缀名后加一个空格从而实现利用，如下图所示：

此时info.png(空格）文件已经成功上传，通过浏览器访问提示404 Not Found，这是因为info.php(空格)通过浏览器访问后，浏览器自动将空格进行编码为%20，所以提示无法找到该文件。

此时我们通过浏览器构造地址：

http://192.168.30.128:8080/uploadfiles/info1.pngAAAphp

burp抓取到数据包后，进行hex修改。


成功返回解析成php文件。