这里是你们连续三天发文，高产似母猪的小编。
今天跟大家唠唠一些常见的中间件漏洞
包括IIS、Apache、Nginx以及Tomcat
废话不多说，让我们直接开始吧~（好啦我承认今天的表情包是因为好想去迪斯尼，难道是上年纪了吗，嗯？）
Part.0
目录
目录
一、IIS
- IIS 6.0 解析漏洞
- IIS 7.5 解析漏洞
- IIS 6.0 命令执行漏洞
- IIS 短文件名漏洞
二、Apache
- Apache解析漏洞
三、Nginx
- Nginx 解析漏洞
- Nginx 目录穿越
- CRFL 注入漏洞
四、Tomcat
- Tomcat 任意文件上传漏洞
Part.1
IIS
IIS 6.0 解析漏洞
（1）利用特殊符号“;”
在IIS 6.0版本中，“;”号的功能类似于 截断，例如我们上传一个恶意脚本“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，然后重启服务器，注册表路径：HKEYLOCALMACHINESYSTEMCurrentControlSetControlFileSystem
重启完成后，将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值：
//如果输入 ，还可以给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页面：
生成失败，因为有文件名限制，如下：
使用 绕过文件名限制：
响应包提示生成成功：
访问生成的test.jsp页面，成功：
//利用该漏洞可以直接生成webshell文件了。
（2）修复方法
修改readonly参数，或者打上相应的补丁。
Part.5
结束语
好啦，以上就是今天的全部内容了。
Peace ！
