【Vulhub靶场】Nginx 中间件漏洞复现

Nginx 概念：

Nginx (engine x) 是一个高性能的HTTP和反向代理web服务器，同时也提供了IMAP/POP3/SMTP服务。Nginx是由伊戈尔·赛索耶夫为俄罗斯访问量第二的Rambler.ru站点（俄文：Рамблер）开发的，第一个公开版本0.1.0发布于2004年10月4日。其将源代码以类BSD许可证的形式发布，因它的稳定性、丰富的功能集、简单的配置文件和低系统资源的消耗而闻名。2011年6月1日，nginx 1.0.4发布。

Nginx是一款轻量级的Web 服务器/反向代理服务器及电子邮件（IMAP/POP3）代理服务器，在BSD-like 协议下发行。其特点是占有内存少，并发能力强，事实上nginx的并发能力在同类型的网页服务器中表现较好，中国大陆使用nginx网站用户有：百度、京东、新浪、网易、腾讯、淘宝等。
Nginx 是高性能的 HTTP 和反向代理的web服务器，处理高并发能力是十分强大的，能经受高负 载的考验,有报告表明能支持高达 50,000 个并发连接数。
Nginx支持热部署，启动简单，可以做到7*24不间断运行。几个月都不需要重新启动。

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

1. 影响版本

Nginx 0.8.41 ~ 1.4.3 / 1.5.0 ~ 1.5.7

2. 漏洞原理

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

开启vulhub靶机，启动环境

root@Fly:~/vulhub/nginx/CVE-2013-4547# docker-compose build
root@Fly:~/vulhub/nginx/CVE-2013-4547# docker-compose up -d

访问靶机的IP地址，如下图：

这个环境是黑名单验证，我们无法上传php后缀的文件，需要利用CVE-2013-4547。我们上传一个“1.gif ”，注意后面的空格：

上传成功

访问http://your-ip:8080/uploadfiles/1.gif[0x20][0x00].php，再次抓包修改，即可发现PHP已被解析：

二、Nginx越界读取缓存漏洞（CVE-2017-7529）

1. 漏洞详情

Nginx在反向代理站点的时候，通常会将一些文件进行缓存，特别是静态文件。缓存的部分存储在文件中，每个缓存文件包括“文件头”+“HTTP返回包头”+“HTTP返回包体”。如果二次请求命中了该缓存文件，则Nginx会直接将该文件中的“HTTP返回包体”返回给用户。

如果我的请求中包含Range头，Nginx将会根据我指定的start和end位置，返回指定长度的内容。而如果我构造了两个负的位置，如(-600, -9223372036854774591)，将可能读取到负位置的数据。如果这次请求又命中了缓存文件，则可能就可以读取到缓存文件中位于“HTTP返回包体”前的“文件头”、“HTTP返回包头”等内容。

2. 影响版本

 Nginx 0.5.6 – 1.13.2

3. 漏洞复现

开启vulhub靶机，启动环境

root@Fly:~/vulhub/nginx/CVE-2017-7529# docker-compose up -d

访问http://your-ip:8080/，即可查看到Nginx默认页面，这个页面实际上是反向代理的8081端口的内容。

直接在靶场环境中调用python3 poc.py http://your-ip:8080/，读取返回结果：

可见，越界读取到了位于“HTTP返回包体”前的“文件头”、“HTTP返回包头”等内容。

三、Nginx 配置错误导致漏洞（insecure-configuration）

1.漏洞复现

开启vulhub靶机，启动环境

root@Fly:~/vulhub/nginx/nginx_parsing_vulnerability# docker-compose up -d

运行成功后，Nginx将会监听8080/8081/8082三个端口，分别对应三种漏洞。

1.1 CRLF注入漏洞

Nginx会将$uri进行解码，导致传入%0d%0a即可引入换行符，造成CRLF注入漏洞。
Payload: http://your-ip:8080/%0d%0aSet-Cookie:%20a=1，可注入Set-Cookie头。

错误的配置文件示例（原本的目的是为了让http的请求跳转到https上）：

访问访问http://192.168.111.146:8080/，进行抓包，发现在nginx重定向后，会在http响应头中出现Location字段，如下图所示

当我们访问http://192.168.111.146:8080/%0d%0atest时,抓包响应头如下图所示。 %0d%0a即 \r\n，也就是换行符，所以在url中加入一个换行符即可将恶意数据写入http响应头。

同理加两个换行符可以将数据写入响应体，例如访问 http://192.168.111.146:8080/%0d%0a%0d%0a<script>alert(1)</script>后响应体如下图所示，通过这种注入可实现xss攻击。

1.2 目录穿越漏洞

Nginx在配置别名（Alias）的时候，如果忘记加/，将造成一个目录穿越漏洞。

错误的配置文件示例（原本的目的是为了让用户访问到/home/目录下的文件）：


Payload: http://your-ip:8081/files…/ ，成功穿越到根目录：

1.3 add_header被覆盖

Nginx配置文件子块（server、location、if）中的add_header，将会覆盖父块中的add_header添加的HTTP头，造成一些安全隐患。

如下列代码，整站（父块中）添加了CSP头：

访问之后http://192.168.111.146:8082/test1，进行抓包，发现CSP头目前还有。

访问之后http://192.168.111.146:8082/test2，进行抓包，发现CSP头消失

由此可见，/test2的location中又添加了X-Content-Type-Options头，导致父块中的add_header全部失效：

四、Nginx 解析漏洞（nginx_parsing_vulnerability）

1. 版本信息：

Nginx 1.x 最新版
PHP 7.x最新版

2. 漏洞详情

该漏洞与Nginx、php版本无关，属于用户配置不当造成的解析漏洞。

3. 漏洞复现

开启vulhub靶机，启动环境

root@Fly:~/vulhub/nginx/nginx_parsing_vulnerability# docker-compose up -d

访问http://192.168.111.146/uploadfiles/nginx.png可正常显示

增加/.php后缀，被解析成PHP文件：http://192.168.111.146/uploadfiles/nginx.png/.php