安全漏洞的复现与总结

Nginx简介

Nginx(engine x) 是一个高性能的HTTP和反向代理web服务器,同时也提供了IMAP/POP3/SMTP服务。其将源代码以类BSD许可证的形式发布,因它的稳定性、丰富的功能集、简单的配置文件和低系统资源的消耗而闻名。2011年6月1日,nginx 1.0.4发布。

Nginx是一款轻量级的Web服务器/反向代理服务器及电子邮件(IMAP/POP3)代理服务器,在BSD-like 协议下发行。

其特点是占有内存少,并发能力强,事实上nginx的并发能力在同类型的网页服务器中表现较好,中国大陆使用nginx网站用户有:百度、京东、新浪、网易、腾讯、淘宝等。

Nginx环境安装

这里我用的小皮代替,就不一步步安装了

安全漏洞的复现与总结_第1张图片

安全漏洞的复现与总结_第2张图片

Nginx渗透

为了感谢广大读者伙伴的支持,准备了以下福利给到大家:
【一>所有资源获取<一】
1、200多本网络安全系列电子书(该有的都有了)
2、全套工具包(最全中文版,想用哪个用哪个)
3、100份src源码技术文档(项目学习不停,实践得真知)
4、网络安全基础入门、Linux、web安全、攻防方面的视频(2021最新版)
5、网络安全学习路线(告别不入流的学习)
6、ctf夺旗赛解析(题目解析实战操作)

文件解析漏洞

漏洞描述

该漏洞与nginx、php版本无关,属于用户配置不当造成的解析漏洞。由于nginx.conf的如下配置导致nginx把以’.php’结尾的文件交给fastcgi处理,对于任意文件名,在后面添加/xxx.php(xxx)为任意字符后,即可将文件作为php解析。

常见的漏洞配置:

安全漏洞的复现与总结_第3张图片

漏洞复现

新建一个1.jpg写入phpinfo

安全漏洞的复现与总结_第4张图片

安全漏洞的复现与总结_第5张图片

1.jpg后面加上/xxx.php,便会以php解析

安全漏洞的复现与总结_第6张图片

当访问/1.jpg/xxx.php时,nginx将查看url,看到它以.php结尾,将路径传给PHP fastcgi进行处理。但是fastcgi在处理’xxx.php’文件时发现文件并不存在,这时php.ini配置文件中cgi.fix_pathinfo=1 发挥作用,这项配置默认开启,值为1,用于修复路径,如果当前路径不存在则采用上层路径。

为此这里交由fastcgi处理的文件就变成了’/1.jpg’。新版本的php的配置文件php-fpm.conf引入了“security.limit_extensions”,限制了可执行文件的后缀,默认只允许执行.php文件。

修复方法

1、 将php.ini文件中的cgi.fix_pathinfo的值设置为0

2、 php-fpm.conf中的security.limit_extensions后面的值设置为.php

目录遍历

漏洞原理

Nginx的目录遍历与apache一样,属于配置方面的问题,错误的配置可导致目录遍历与源码泄露。

漏洞复现

安全漏洞的复现与总结_第7张图片

安全漏洞的复现与总结_第8张图片

在www目录下新建一个web目录测试

安全漏洞的复现与总结_第9张图片

安全漏洞的复现与总结_第10张图片

修复方法

修复on改为off即可。

空字节任意代码执行漏洞

漏洞原理

Ngnix在遇到%00空字节时与后端FastCGI处理不一致,导致可以在图片中嵌入PHP代码然后通过访问xxx.jpg%00.php来执行其中的代码.

影响版本

nginx 0.5.*
nginx 0.6.*
nginx 0.7 <= 0.7.65
nginx 0.8 <= 0.8.37

漏洞复现

这里复现环境是Nginx 0.7.65+php 5.3.2,这里需要电脑上有.net framework4的环境。

安全漏洞的复现与总结_第11张图片

在nginx目录下执行startup.bat

安全漏洞的复现与总结_第12张图片

安全漏洞的复现与总结_第13张图片

建立1.jpg,写入

安全漏洞的复现与总结_第14张图片

访问1.jpg…php,抓包

安全漏洞的复现与总结_第15张图片

在hex选项卡中将jpg后面的点修改为00

安全漏洞的复现与总结_第16张图片

安全漏洞的复现与总结_第17张图片

成功绕过。

安全漏洞的复现与总结_第18张图片

forward一下

安全漏洞的复现与总结_第19张图片

该漏洞不受cgi.fix_pathinfo影响,其为0也能解析。

修复方法

升级nginx版本。

CRLF注入漏洞

漏洞原理

CRLF是”回车+换行”(rn)的简称,其十六进制编码分别为0x0d和0x0a。在HTTP协议中,HTTP header与HTTP Body是用两个CRLF分隔的,浏览器就是根据这两个CRLF来取出HTTP内容并显示出来。

所以,一旦我们能够控制HTTP消息头中的字符,注入一些恶意的换行,这样我们就能注入一些会话Cookie或者HTML代码。CRLF漏洞常出现在Location与Set-cookie消息头中。

在nginx.conf中,在location位置添加如下配置,当用户访问nginx服务器时此配置实现强制跳转到https协议访问之前访问的链接。

location / { 
 return 302 https://$host$uri;
}

安全漏洞的复现与总结_第20张图片

1.是配置中的$url是我们可以控制的,这样我们就可以在$url处填入CRLF,然后对服务器进行访问实现头部注入。
2.服务器会返回一个302跳转给用户,所以我们注入的头部参数又会返回到客户这边。

漏洞复现

修改完上面nginx.conf配置后,重启nginx;

(换行和回车的URL编码分别是%0d%0a)

抓包,可以看到将6666通过set-cookie返回;

安全漏洞的复现与总结_第21张图片

CRLF+XSS配合:

%0D%0A%0D%0A%3Cimg%20src=1%20onerror=alert(/xss/)%3E

安全漏洞的复现与总结_第22张图片

不过这里浏览器并没有弹窗,那是因为浏览器filter对xss特征进行了过滤,这里用低版本浏览器才可以弹出来。

修复方法

删除配置不当的配置。

文件名逻辑漏洞(CVE-2013-4547)

漏洞原理

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

影响版本

Nginx 0.8.41 ~ 1.4.3
Nginx 1.5.0 ~ 1.5.7

漏洞复现

windows环境下不允许存在文件名后带空格的文件,因此复现使用vulhub进行测试。

启动漏洞环境:

安全漏洞的复现与总结_第23张图片

安全漏洞的复现与总结_第24张图片

上传1.jpg,并进行抓包;

安全漏洞的复现与总结_第25张图片

安全漏洞的复现与总结_第26张图片

在1.jpg后添加一个空格

安全漏洞的复现与总结_第27张图片

访问返回的该链接并加.php抓包;

http://192.168.190.134:8080/uploadfiles/1.jpg...php

安全漏洞的复现与总结_第28张图片

在hex选项卡中将jpg后面的2个点的hex值2e分别修改为20,00;

安全漏洞的复现与总结_第29张图片

安全漏洞的复现与总结_第30张图片

安全漏洞的复现与总结_第31张图片

安全漏洞的复现与总结_第32张图片

成功绕过。

这个漏洞主要原因是错误地解析了请求的URL,错误地获取到用户请求的文件名,导致出现权限绕过、代码执行的连带影响。

Nginx匹配到.php结尾的请求,就发送给fastcgi进行解析,常见的写法如下:

安全漏洞的复现与总结_第33张图片

正常情况下(关闭pathinfo的情况下),只有.php后缀的文件才会被发送给fastcgi解析。

而存在CVE-2013-4547的情况下,我们请求1.jpg\0x20\0x00.php,这个URI可以匹配上正则.php$,可以进入这个Location块;但进入后,Nginx却错误地认为请求的文件是1.jpg\0x20,就设置其为SCRIPT_FILENAME的值发送给fastcgi。fastcgi根据SCRIPT_FILENAME的值进行解析,最后造成了解析漏洞。所以,我们只需要上传一个空格结尾的文件,即可使PHP解析之。

修复方法

升级版本

整数溢出(CVE-2017-7529)

漏洞原理

在Nginx的range filter中存在整数溢出漏洞,可以通过带有特殊构造的range的HTTP头的恶意请求引发这个整数溢出漏洞,并导致信息泄露。

影响版本

Nginx 0.5.6 – 1.13.2

漏洞复现

开启漏洞

安全漏洞的复现与总结_第34张图片

安全漏洞的复现与总结_第35张图片

在靶机web根目录下创建一个图片文件当缓存文件

安全漏洞的复现与总结_第36张图片

安全漏洞的复现与总结_第37张图片

安全漏洞的复现与总结_第38张图片

去靶机中的/tmp/nginx中查看缓存文件,可以看到,cache key的内容保存在了里面,此外还有服务器信息,这些都是不会返回给客户端的,但是因为这次的漏洞而导致这些信息也被返回,导致信息泄露;

安全漏洞的复现与总结_第39张图片

对,这个没成功,缓存文件中的这些信息并没有返回来,先待定~

修复方法

建议升级到 1.13.3 和 1.12.1 版本;如果不能升级,可以在 Nginx 配置文件中添加 max_ranges 1,从而禁用 multipart range。

你可能感兴趣的:(web安全,php,网络安全,渗透测试,安全漏洞)