【中间件】一些中间件的相关漏洞总结

最新推荐文章于 2024-05-29 03:00:00 发布

Monsterlz123

最新推荐文章于 2024-05-29 03:00:00 发布

阅读量2.1k

点赞数 2

分类专栏： web安全文章标签： web安全中间件漏洞 IIS漏洞 Apache漏洞 Tomcat漏洞

本文链接：https://blog.csdn.net/Monsterlz123/article/details/96198297

版权

web安全专栏收录该内容

13 篇文章 11 订阅

订阅专栏

【中间件】一些中间件的相关漏洞总结

Hello，各位小伙伴晚上好~
在这里插入图片描述
这里是你们连续三天发文，高产似母猪的小编。

今天跟大家唠唠一些常见的中间件漏洞

包括常见的IIS、Apache、Nginx以及Tomcat

废话不多说，让我们直接开始吧~
在这里插入图片描述
（好啦我承认今天的表情包是因为好想去迪斯尼，难道是上年纪了吗，嗯？）

在IIS 6.0版本中，“;”号的功能类似于%00截断，例如我们上传一个恶意脚本“yijuhua.asp;.jpg”，文件后缀为jpg，可以绕过服务器检测，当我们访问这个文件时，分号后面的内容会被截断，就相当于我们访问的是yijuhua.asp。
在这里插入图片描述
（2）文件夹名为.asp

如果一个目录以“xxx.asp”的格式命名，那么该目录下的所有类型的文件都会被当作asp文件来解析执行。

例如：
在这里插入图片描述

（3）防护方法

以上两个IIS解析漏洞，微软认为是IIS的正常功能，因此未提供修复补丁。

防护方案：

升级IIS到更高级的版本
对上传的文件做严格的过滤，避免上传不合规的文件。

2、IIS 7.5解析漏洞

（1）、漏洞原理

当IIS 7.5在Fast-CGI运行模式下时，如果服务器开启了“cgi.fix_pathinfo”功能，且去掉了php-cgi.exe程序的“Invoke handler only if request is mapped to”勾选。那么当访问的文件路径不存在时，会对路径进行修剪。

例如test.jpg是我们上传的图片马，直接访问/test.jpg无法被php解析。

但是利用路径修剪功能，我们可以访问 /webshell.jpg/.php，服务器发现为.php后缀，便交给php解析。

php发现无法访问该路径后，便会对路径进行修剪，最终解析的是test.jpg文件。
在这里插入图片描述

（2）防护方法

关闭cgi.fix_pathinfo功能即可。

3、IIS 6.0 命令执行漏洞

（1）漏洞原理

该漏洞的编号为CVE-2017-7269，在IIS 6.0 开启WebDav服务的情况下存在命令执行漏洞。WebDav服务默认关闭，如下：
在这里插入图片描述

原理是IIS 6.0 在处理PROPFIND指令的时候，由于对url的长度没有进行有效的长度控制和检查，导致执行memcpy对虚拟路径进行构造时，引发栈溢出，可导致远程代码执行。
在这里插入图片描述

攻击方法，在Github上有一个开源exp：

https://github.com/edwardz246003/IIS_exploit

将代码如下位置更改为靶机IP地址：
在这里插入图片描述

运行该脚本的结果是在靶机中打开一个计算器，如下：
在这里插入图片描述

（2）防护方式

关闭WebDav服务即可。

4、IIS 短文件名漏洞

（1）漏洞原理

为了兼容16位MS-DOS程序，Window会为文件名较长（字符长度超过9位）的文件/文件夹生成对应的短文件名，如下：
在这里插入图片描述

短文件名命名规则：

只有文件名前6位以大写方式显示，后续以~1方式指代。
如果有多个前6位字符相同的文件，~1数字递增。
文件名后缀最多只取3位，且以大写方式显示。

当我们访问存在、不存在的短文件时，服务器的应答是不相同的，具体如下：
在这里插入图片描述
根据应答的内容，存在暴力枚举短文件名的可能。

例如，访问AAAAAA~1.ASP，返回404，文件存在：
在这里插入图片描述
访问不存在的短文件，则返回400：

利用这种方法，我们可以猜解后台地址或者敏感文件名，但局限性是只能猜到前6位，而且文件名较短的文件是没有短文件名的。

（2）iis_shortname_Scan.py 工具

运行脚本，直接跟URL即可：
在这里插入图片描述

扫描结果如下：
在这里插入图片描述

（3）修复方法

方法一：升级.net framework到最新版本。

方法二：

首先修改指定注册表的键值为1，然后重启服务器

路径：HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\FileSystem
在这里插入图片描述
重启完成后，将web服务根目录文件夹（本机为wwwroot）复制一份，到其他路径重命名备份。删除原根路径文件夹wwwroot，然后将备份文件夹复制回来，更名为wwwroot，再查看其中的文件：

已经没有短文件名了，最后一步相当于清除缓存。

二、Apache

1.Apache解析漏洞

（1）漏洞原理

该解析漏洞属于用户配置问题，且Apache与php的结合方式为Module，如下：
在这里插入图片描述
首先要明确一点，Apache对文件的解析顺序是从右往左的，直到遇见一个Apache可以解析的文件后缀为止。

例如访问/test.php.aaa.bbb，由于Apache不认识aaa和bbb，会从右往左一直遍历到后缀.php为止。

文件 /etc/mime.types，记录了大量Apache可以解析的文件类型。
在这里插入图片描述
//上图php类型都被注释掉了，不可以解析。

还有另外一个文件/etc/apache2/mods-enabled/php.config
在这里插入图片描述
通过正则的方式记录了可以交给php解析的文件类型，上图可以解析.php文件。

提问：访问index.php.aaa是否可以顺利解析？

答案是不可以的，初始情况下Apache是不存在这个漏洞的，从右往左识别到.php后，服务器将index.php.aaa整体交给php来处理，但php并不认识.aaa，所以无法解析。

该漏洞产生的原因是，运维人员在配置服务器时，为了使服务器能够解析.php，自己添加了一个handler，到/etc/apache2/sites-enabled/目录下。

我们在该目录下添加的任意名称的配置文件都会生效，例如创建一个1.conf，内容为：
在这里插入图片描述
AddHandler不同于SetHandler，只要文件名中的任何位置有.php，就会被交给php_module解析，而SetHandler只会解析后缀为.php的文件。

（2）防护方法

在配置文件中，使用SetHandler配合正则表达式的方法，而不是AddHandler，这样就不会出现解析问题了。

三、Nginx

1、Nginx 解析漏洞

（1）Nginx初始配置

刚安装好的Nginx是无法解析php文件的。

修改/etc/nginx/sites-available/default文件的部分配置如下，以套接字方式启动：
在这里插入图片描述
使用php5-fpm start启动web服务后，就可以解析.php文件了：

（2）漏洞原理

对于任意文件，访问时在后面添加/任意文件名.php ，便可交给php进行解析。

和Apache一样，Nginx也是通过/etc/nginx/mine.types识别文件。

该漏洞也是配置导致的，默认不存在，需要在/etc/php5/fpm/php.ini中开启cgi.fix_pathinfo功能，该功能默认开启。

还需要配置/etc/php5/fpm/pool.d/www.conf文件，修改security.limit_extensions为空，允许解析其他格式文件为PHP，原本的配置为：
在这里插入图片描述
//只解析php，php3，php4，php5后缀的文件

修改为空后，会把所有后缀都以php解析。
在这里插入图片描述
例如1.jpg是我上传的一个图片马，利用该漏洞进行访问：

Nginx发现访问的文件为.php后缀，便交给php处理，php发现/1.jpg/1.php不存在，剪掉/1.php后缀，把1.jpg当成需要执行的文件来处理。

（3）防护方法

配置项 security.limit_extensions 不要填写为空，填写需要解析的文件后缀。

关闭 cgi.fix_pathinfo 路径修剪功能。

2、Nginx 目录穿越

（1）目录遍历

Nginx默认不开启目录遍历，需要修改配置文件如下：
在这里插入图片描述

开启autoindex后，可以遍历目录：
在这里插入图片描述
（2）目录穿越

我们来看看Nginx的反向代理：
在这里插入图片描述

虽然访问的是/files目录，但其实是代理到了/home/目录。

但这里有个配置问题，就是/files没有闭合，我们可以穿越到上层目录中去：
在这里插入图片描述
//打开了根目录

找到并下载了/etc/passwd文件，造成信息泄漏：
在这里插入图片描述

（3）修复方法

闭合/files/，如下：
在这里插入图片描述
重启Nginx服务，无法再次穿越：

3、CRFL 注入漏洞

（1）漏洞原理

Nginx可以设置网页跳转，例如当用户访问http://192.168.211.168:8080的网页时，我们让其跳转到https的页面进行访问，修改配置文件如下：

在这里插入图片描述

访问http://192.168.211.168:8080，响应报文会根据上面的配置让我们跳转：

在这里插入图片描述

但这里的 $u r i 配置就造成了 C R L F 注入漏洞，$ uri会在解码后再请求路径，如果我们输入换行符，就能在响应报文中生成新的字段。

CRLF是"回车+换行"的简称，这里我们利用CRLF来构造一个Set-cookie字段，进行会话固定攻击：

发送请求如下：
在这里插入图片描述

返回的响应包，给我们设置了我们指定的cookie值：
在这里插入图片描述

如果输入%0d%0a%0d%0a，就可以给HTTP body体添加内容了。

（2）修复方法

使用 $request_uri方法替换$ uri。
在这里插入图片描述

$request_uri不会对URI进行解码，会对输入进行原样输出，也就不会出现回车换行的问题了，再次访问响应如下：
在这里插入图片描述

四、Tomcat

1、Tomcat 任意文件上传

漏洞的编号为：CVE-2017-12615

当我们将readonly参数设置为false时，可以通过PUT方式创建一个JSP文件，并且可以执行任意代码，修改/conf/web.xml文件如下：
在这里插入图片描述

使用put方法创建一个test.jsp页面：
在这里插入图片描述

生成失败，因为有文件名限制，如下：
在这里插入图片描述

使用%20绕过文件名限制：
在这里插入图片描述
响应包提示生成成功：

访问生成的test.jsp页面，成功：
在这里插入图片描述

利用该漏洞可以直接生成webshell文件了。

（2）修复方法

开启readonly参数，或者打上相应的补丁。

好啦，以上就是今天的全部内容了。
在这里插入图片描述

同时，欢迎关注我的个人微信公众号~

Peace ！

在这里插入图片描述

Monsterlz123

关注

2
点赞
踩
20

收藏

觉得还不错? 一键收藏
0
评论
【中间件】一些中间件的相关漏洞总结

【中间件】一些中间件的相关漏洞总结Hello，各位小伙伴晚上好~这里是你们连续三天发文，高产似母猪的小编。今天跟大家唠唠一些常见的中间件漏洞包括常见的IIS、Apache、Nginx以及Tomcat废话不多说，让我们直接开始吧~（好啦我承认今天的表情包是因为好想去迪斯尼，难道是上年纪了吗，嗯？）目录一、IISIIS 6.0 解析漏洞IIS 7.5 解析漏洞IIS 6...
复制链接

扫一扫