【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
版权归原作者 Fly` 所有， 如有侵权，请联系我们删除。