Nginx文件名逻辑漏洞复现CVE-2013-4547

前置知识

本次针对的是中间件Nginx

Nginx是什么?

Nginx（发音为“engine-x”）是一个高性能的开源Web服务器软件。它以异步事件驱动的方式处理客户端请求，具有占用资源
少、处理并发连接能力强和稳定性高等特点。Nginx还可以用作反向代理服务器、负载均衡器和HTTP缓存等。

与Aapache相比,Nginx有何优势?

架构设计：Nginx采用了基于事件驱动的架构，而Apache采用的是多线程或多进程的模型。这使得Nginx在处理大量并发连接时更高效，内存消耗更少。

内存使用：Nginx设计得非常轻量级，内存占用量较低。相比之下，Apache使用的线程模型会为每个连接创建一个线程或进程，导致内存消耗较高。

静态文件处理：Nginx在处理静态文件时效率更高，可以更快地提供静态内容。Apache在这方面的性能相对较差。

可扩展性：Nginx具有良好的可扩展性，可以处理数千个并发连接而不会影响性能。Apache则对并发连接的处理能力相对较弱

受影响版本

Nginx 0.8.41~1.4.3
Nginx 1.5.0~1.5.7

漏洞原理

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块；但进入后，由于fastcgi在查找文件时被\0截断，Nginx却错误地认为请求的文件是1.gif[0x20]，就设置其为SCRIPT_FILENAME的值发送给fastcgi。

漏洞利用

上传PHP文件,内容是一句话木马

修改Content-Type: image/jpg

修改文件名:

假设原来为ma.php
先改为:ma.jpg  .php   #中间有两个空格,即ma.jpg[0x20][0x20].php
改为:ma.jpg[0x20][0x00].php  #其中通过重发器的Hex功能,将原来hex数据中的对应的20改为00
随后发送,可发现绕过

以POST方法访问木马文件,hackbar的POST框中:s=phpinfo();
在BP中将文件名改为ma.jpg[0x20][0x00].php
发送,发现出现phpinfo

环境配置

find ./ -name *CVE-2013*
cd ./nginx/CVE-2013-4547
docker-compose up -d
docker ps

漏洞利用

直接上传木马:被拦截

增加空格:

蚁剑连接:连接失败

进入容器内查看情况:

docker exec -it 7ca93ca5343f /bin/bash

可知几点:

1.靶机中没有www目录

2.index.php文件不在/var/www/html目录下,而在/usr/local/nginx/html目录下

3.木马文件eval_POST.php内容正常

尝试访问木马文件:

出现No input file specified

参照:

https://zhuanlan.zhihu.com/p/610669649

https://www.cnblogs.com/llkbk/p/10007217.html

得知木马文件没有被解析,解决方法:

为了不影响原靶机环境,这里就不修改了