中间件漏洞总结报告
一、 IIS解析漏洞
首先一般文件解析漏洞用于各种上传漏洞中，在文件上传的地方一般会限制用户上传文件的后缀名。在实际环境中IIS一般是和asp搭配的。但是事实上IIS除了可以解析.asp的后缀还可以解析.cer和.asa的文件
1.1文件解析
1.1.1漏洞原理
IIS 6.0在处理含有特殊符号的文件路径时会出现逻辑错误，从而造成文件解析漏洞
这一漏洞有两种不同的利用方式（也就是说有两个特殊符号可以做到来利用漏洞）
IIS 7.5+php开启了cgi.fix_pathinfo 两者结合起来就会产生解析漏洞，因为cgi.fix_pathinfo开启后会对路径进行修剪
1.1.2 漏洞利用
一．①特殊符号为 /
新建一个名为“test.asp”的目录 那么该目录下任何文件都被IIS当做asp程序执行（test.asa test.cer同理可以实现）
②特殊符号为 ;
当存在分号时例如1.asp;jpg 仍会被IIS当做asp程序执行
二．例如1.jpg/.php 一看后缀是php 无论该文件是否存在都直接交给php处理
而php又默认开启了cgi.fix_pathinfo会对问价路径进行修理 （如上 .php不存在 删减掉 看1.jpg是否存在若存在 直接把该文件当做php程序执行）
1.1.3 漏洞修复
针对第一个IIS6.0 修复办法就是更新版本
第二个漏洞的解决办法就是把cgi.fix_pathinfo这个参数的值设为0
1.2命令执行漏洞
1.2.1 漏洞原理
在IIS6.0处理PROPFIND指令的时候，由于对url的长度没有进行有效的长度控制和检查，导致执行memcpy对虚拟路径进行构造的时候引发栈溢出，该漏洞可以导致远程代码执行
1.2.2 漏洞利用
下载exp
https://github.com/edwardz246003/IIS_exploit，使用python执行exploit.py。
1.2.3 漏洞修复
更新版本
1.3短文件名漏洞
1.3.1 漏洞原理
为了兼容16位MS-DOS程序，Windows为文件名较长的文件（和文件夹），生成了对应的windows8.3短文件名 注 使用dir/x 可以在windows下查看对应的短文件名
1.3.2 漏洞利用
可以根据访问时页面的回显判断这个短文件是否存在
构造某个存在的短文件名会返回404
若不存在则会返回400
http://github.com/lijiejie/IIS_shortname_Scanner 短文件名扫描工具
此漏洞可以用来猜解后台地址及敏感文件 甚至可以通过短文件名web直接下载对应文件但是这个漏洞也有一定的局限性 只能猜解前六位而且名称较短的根本猜不出来
1.3.3 漏洞修复
1.升级.net framework
2.修改注册表键值
3.将web文件夹的内容拷贝到另一个位置 删除这个文件 然后再把拷贝的文件夹放回原处
二、 Apache解析漏洞
1. 漏洞原理
Apache文件解析有一个特性
Apache默认一个文件可以有多个以点分隔的后缀，当后面的后缀无法识别（不在mine.type内---列表里有各种文件类型用来告诉浏览器用什么格式去解析文件）就会继续向左识别
例如 shell.php.xxx.yyy 首先yyy无法识别向左xxx 依旧不认识 再向左php 这个认识 就把他交给php来处理
虽然交给了php 但是你去访问就会发现 代码并没有执行 而是直接原样输出了
那是因为虽然交给了php来处理这个文件 但是php也不知道这个.yyy后缀的文件应该咋办 所以只能原样输出了
那么Apache解析漏洞到底从何而来呢
其实漏洞的产生是由于运维人员在配置服务器 为了使Apache服务器能解析php，而自己添加了一个handler AssHandler application/x-httpd-php.php
这行代码的作用就是为了让Apache把php文件交给php_module解析
但是。。。。它的后缀并没有采用正则去匹配 所以，在文件名的任何位置匹配到php后缀它都会让php_module去解析 也就因为这样 漏洞产生了
之前的shell.php.xxx.yyy 一路向左发现了php 就会激活php处理器 执行php代码
2. 漏洞利用
上传php脚本 就可以拿到shell了
3. 漏洞修复
不要使用AddHandler，改用SetHandler写好正则就不会有解析问题了
三、Nginx相关漏洞
1.目录遍历
1.1漏洞原理
Nginx的配置文件被修改因为它默认是不会开启目录遍历的
在Nginx/sites-available/default文件中的location这里加上autoindex on
1.jpg
1.2漏洞利用
该漏洞可以用来下载源码或者一些敏感文件对网站极不安全
1.3漏洞修复
删掉那一条配置命令就可以了
2.文件解析漏洞
2.1 漏洞原理
Nginx和Apache一样也是通过mime.types识别文件
例如创建一个1.jpg文件 访问1.jpg/1.php 当Nginx拿到这个路径后，一看后缀是.php 便认为这个是php文件 就会交给php去处理
但是php发现1.jpg/1.php并不存在 便删去后面的/1.php 可是1.jpg存在 便把1.jpg当成要执行的文件 然而因为后缀是.jpg，php认为这不是php文件所以会返回Access denied 所以到目前为止 还不会产生解析漏洞
要出现解析漏洞还需要两个条件
①cgi.fix_pathinfo保持默认值为1 表示开启 并对文件路径进行修剪
②配置文件的/etc/php5/fpm/pool.d/www.conf中的security.limit_extensions后面的参数去掉也就是说让他把所有的文件统一当成php去处理
2.2 漏洞利用
完整的利用流程就是：访问1.jpg/1.php 发现是php 交给php处理 发现没有1.php这个文件，进行路径修剪 就成了1.jpg 但仍然把这个1.jpg当成php执行这样漏洞就产生了
2.3 漏洞修复
①把cgi.fix_pathinfo的值设为0 这样就不会进行路径修剪 没有这个文件网页就直接返回404
②配置文件的/etc/php5/fpm/pool.d/www.conf中的security.limit_extensions后面的参数设置成.php 这样他就只能解析php 而不会所有文件直接默认用php解析
2.jpg
3.目录穿越
3.1 漏洞原理
Nginx反向代理时，静态文件存储在/home/下，而访问时需要在url中输入要访问的目标文件files，需要如下配置：
location /files{
alias/home/;
}
其中/files没有闭合，导致可以穿越之上层目录
3.2 漏洞利用
既然可以进行目录穿越 那就以访问根目录下的/etc/passwd为例
在访问目标文件http://ip/files时，我们可以这样来构造url：
http://ip/files../../../../../../../../../../../../../etc/passwd
弄大概六七个就可以到达根目录了
3.3 漏洞修复
加个闭合
location /files/{
alias/home/;
}
4.CRLF注入
4.1 漏洞原理
Nginx的配置文件/etc/nginx/conf.d/error1.conf：
location / {
return 302 https://$host$uri;
}
问题就出在这个$uri上 它是解码后请求路径，不含参数 和$document_uri一样
这两个参数会将路径进行解码
首先我们要知道CRLF是“回车+换行”（\r\n）的简称。
HTTP Header与HTTP
Body是用两个CRLF分割的，浏览器根据两个CRLF来取出HTTP内容并显示出来。
通过控制HTTP消息头中的字符，注入一些恶意的换行，就能注入一些会话cookie或者恶意的HTML代码。
4.2漏洞利用
首先正常的跳转页面如下
3.jpg
①进行会话固定
4.jpg
②产生反射型XSS
5.jpg
当然 虽然输入了恶意代码但是仍然没有弹窗 那是因为浏览器Filter对XSS特征进行了过滤
在此只是证明一下可以往网页注入恶意代码
4.3 漏洞修复
不再使用$uri 把参数改为$requestt_uri这个不会解码 访问完整的url
另外 任何可以设置HTTP头的场景都会出现CRLF注入问题
四、Tomcat任意文件上传漏洞
1.1漏洞原理
其实 Tomcat本身并无漏洞 漏洞是人为配置的 即开启put方法可实现上传文件
在tomcat文件夹下的/conf/web.xml文件插入
<init-param>
<param-name>readonly</param-name>
<param-value>false</param-value>
</init-param>
6.jpg
重启tomcat服务 记住用shutdown.bat 开启时用startup.bat
1.2 漏洞利用
打开burpsuit 设置一个新端口 避免冲突
刷新网页截取数据包 进行改造
将请求方式改为put创建一个123.jsp 并用%20转义空格字符。123.jsp内容为<%out.print("Hello World!");%>，输出Hello World!
在web目录上 能查看创建了123.jsp文件
7.jpg
1.3 漏洞修复
这个漏洞利用的就是readonly参数为false时 就可通过PUT方式创建一个jsp文件，并可以执行任意代码
修复方法就是不要去修改readonly的默认参数 保持true
网友评论