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

这里是你们连续三天发文，高产似母猪的小编。

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

包括IIS、Apache、Nginx以及Tomcat

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

Part.0

目录

目录

一、IIS

1. IIS 6.0 解析漏洞
2. IIS 7.5 解析漏洞
3. IIS 6.0 命令执行漏洞
4. IIS 短文件名漏洞

二、Apache

1. Apache解析漏洞

三、Nginx

1. Nginx 解析漏洞
2. Nginx 目录穿越
3. CRFL 注入漏洞

四、Tomcat

1. Tomcat 任意文件上传漏洞

Part.1

IIS

IIS 6.0 解析漏洞

（1）利用特殊符号“;”

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

（2）文件夹命名为.asp

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

（3）修复方法：

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

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

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功能即可。

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服务即可。

IIS 短文件名漏洞

（1）漏洞原理

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

短文件名命名规则：

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

当我们访问存在、不存在的短文件时，服务器的应答是不相同的，具体如下：

根据应答的内容，存在暴力枚举短文件名的可能。

例如访问AAAAAA~1.ASP，返回404，说明该文件存在：

访问不存在的短文件，则返回400：

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

（2）iisshortnameScan.py 工具

推荐一款好用的短文件名爆破工具：

https://github.com/lijiejie/iisshortnameScanner

运行脚本，直接跟URL即可：

扫描结果如下：

（3）修复方法

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

方法二：

首先修改指定注册表的键值为1，然后重启服务器，注册表路径：HKEYLOCALMACHINE\SYSTEM\CurrentControlSet\Control\FileSystem

重启完成后，将web服务根目录文件夹（本机为wwwroot）复制一份，到其他路径重命名备份。删除原根路径文件夹wwwroot，然后将备份文件夹复制回来，更名为wwwroot，再查看其中的文件：

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

Part.2

Apache

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，这样就不会出现解析问题了。

Part.3

Nginx

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 路径修剪功能。

Nginx 目录穿越

（1）目录遍历

Nginx默认不开启目录遍历，需要修改配置文件如下：

开启autoindex后，可以遍历目录：

（2）目录穿越

我们来看看Nginx的反向代理配置：

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

但这里有个配置问题，就是/files没有闭合，我们可以穿越到上层根目录中去：

找到并下载了/etc/passwd文件，造成信息泄漏：

（3）修复方法

闭合/files/，如下：

重启Nginx服务，无法再次穿越：

CRFL 注入漏洞

（1）漏洞原理

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

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

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

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

返回的响应包，设置了我们指定的cookie值：

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

（2）修复方法

使用$request_uri方法替换$uri。

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

Part.4

Tomcat

Tomcat 任意文件上传

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

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

使用put方法创建一个test.jsp页面：

生成失败，因为有文件名限制，如下：

使用%20绕过文件名限制：

响应包提示生成成功：

访问生成的test.jsp页面，成功：

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

（2）修复方法

修改readonly参数，或者打上相应的补丁。

Part.5

结束语

好啦，以上就是今天的全部内容了。

Peace ！