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

前置知识

首先是环境配置,cd到CVE-2013-4547目录下(有yml配置文件的目录),找不到可以使用find命令在vulhub靶场目录中查找,然后执行构建命令,然后docker ps看一下

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

nginx已经比较熟了,正好学习一下这玩意和apache的区别,因为我一直用的apache

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

与Apache相比，Nginx有以下一些区别：

架构设计：Nginx采用了基于事件驱动的架构，而Apache采用的是多线程或多进程的模型。这使得Nginx在处理大量并发连接时更高效，内存消耗更少。
内存使用：Nginx设计得非常轻量级，内存占用量较低。相比之下，Apache使用的线程模型会为每个连接创建一个线程或进程，导致内存消耗较高。
静态文件处理：Nginx在处理静态文件时效率更高，可以更快地提供静态内容。Apache在这方面的性能相对较差。
可扩展性：Nginx具有良好的可扩展性，可以处理数千个并发连接而不会影响性能。Apache则对并发连接的处理能力相对较弱。

正常情况下（关闭pathinfo的情况下），只有.php后缀的文件才会被发送给fastcgi解析。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$这个正则处理,如果满足就被送入location,不满足就丢给别的模块处理
在存在CVE-2013-4547的情况下，我们请求1.gif[0x20][0x00].php，这个URI可以匹配上正则.php$，可以进入这个Location块；但进入后，0x00截至符把后面的内容屏蔽了,Nginx就错误地认为请求的文件是1.gif[0x20]，就设置其为SCRIPT_FILENAME的值发送给fastcgi。fastcgi根据SCRIPT_FILENAME的值进行解析，然后后续所有针对文件名的过滤就都失效了.
漏洞的利用条件是nginx版本在 0.8.41～1.4.3， 1.5 ~ 1.5.7

漏洞复现

先访问一下服务,docker可以看到是开在8080端口的,访问一下

在该漏洞中，非法字符空格和截止符（\0）可能会导致 Nginx 在解析 URI 时的有限状态机（Finite State Machine）出现混乱。有限状态机是一种计算模型，用于描述具有有限数量状态和规则转换的系统。在 Nginx 中，有限状态机用于解析和处理客户端请求。
举个例子来说明：假设服务器上存在一个文件名为 "file.aaa "，注意文件名的最后一个字符是空格。在正常情况下，当我们使用 URI 访问该文件时，应该是："http://example.com/file.aaa "。然而，在存在该漏洞的情况下，攻击者可以通过构造特殊的请求来绕过 URI 后缀名限制。
例如，攻击者可以发送一个请求："http://example.com/file.aaa \0.bbb"。这里 "%20" 是 URL 编码表示的空格字符。由于有限状态机在解析 URI 时无法正确处理空格字符，Nginx 可能会误认为请求的文件后缀是 ".bbb "，而忽略了空格前的内容。这样，攻击者就能够绕过原本的后缀名限制，访问到服务器上的文件。
那么我们先上传一个木马试一试

回显Unsupported filetype uploaded.说明对后缀进行了处理,那么根据上面CVE-2013-4547的原理,绕过就很简单了,抓包上传请求,然后在16进制数据编辑器里面插入16进制的20和00就行了
因为burp的16进制编辑器只能修改数据,不能插入数据,这里要插入俩数据实际上得提前随便写来字符来占个位置,所以把上传的文件名改成2.jpgaa.php

上传成功了,蚁剑连接一下试试,咳咳,没成功,不管了