部分中间件漏洞总结

做看客很久了，发现一直没有比较好的中间件漏洞的总结性文章，正好近期在做这方面的学习，在此仅总结了少部分中间件常见漏洞供学习参考，后续将补充另一部分常见漏洞。如有错误还请大佬们指正。

一、IIS文件解析漏洞

IIS文件解析漏洞存在于两个版本，一个是IIS6.0的文件解析漏洞，一个是IIS7.5的文件解析漏洞，IIS7.5的文件解析漏洞原理和IIS6.0类似，均因为存在逻辑问题，在此仅对IIS6.0的文件解析漏洞进行分析。在补充中将对IIS7.5文件解析漏洞差异性部分进行额外说明。

（一）漏洞原理

IIS6.0在处理含有特殊符号的文件路径时会出现逻辑错误（文件目录名称为test.asp，目录中的文件会被当做asp执行；后缀名为.asp;.jpg时，当作asp文件执行），从而造成文件解析漏洞。

（二）漏洞演示及利用

当网站上传点限制后缀名时（IIS主要和asp搭配），可以利用文件解析漏洞上传如test.asp;.jpg的文件，绕过后执行。如图1.1

图1.1

当允许新建目录而未对目录名做限制时，可利用文件解析漏洞新建名为test.asp的文件夹，并在其中构造需执行文件iisstart.jpg进行绕过。如图1.2

图1.2

（三）漏洞修复

1、对新建目录文件名进行过滤，不允许新建包含.的文件夹甚至禁止新建目录

2、限制上传文件的执行权限，不允许执行

3、过滤.asp/xm.jpg等，在httpd.ini中加入过滤规则（此方法为网络上的解决办法，但在server2003中未搜索到该文件）。

4、升级IIS版本

（四）补充

IIS6.0的解析漏洞同样存在于IIS 5.x的版本，而IIS7.5的畸形解析漏洞的攻击方法同样适用于IIS7.0和Nginx<8.03版本。

IIS7.5文件解析漏洞出现是因为url中只要看到后缀.php，无论存在与否均交给 php 处理，而php又默认开启“cgi.fix_pathinfo”,会对文件路径进行整理（从后向前判定是否存在，不存在则删减，存在则当作php文件执行。）

二、IIS命令执行漏洞

IIS6.0命令执行漏洞，编号CVE-2017-7269，在开启WebDav服务的情况下存在可远程执行漏洞。

（一）漏洞原理

在IIS6.0处理PROPFIND指令的时候，由于对url的长度没有进行有效的长度控制和检查，导致执行memcpy对虚拟路径进行构造的时候，引发栈溢出，该漏洞可以导致远程代码执行。如图2.1

图2.1

（二）漏洞演示及利用

Github上的一个开源exp: https://github.com/edwardz246003/IIS_exploit

修改IP地址未对应的目标机地址，如图2.2

图2.2

运行脚本，攻击目标机。如图2.3

图2.3

（三）漏洞修复

将IIS管理器中，web服务扩展下，webDAV禁用，即可修复，修复后再此运行脚本，未出现弹窗。如图2.4

图2.4

（四）补充

若能弹出计算器（calc）,则权限已经足以完成getshell的全部操作。

三、IIS短文件名

IIS短文件名漏洞，通过IIS短文件名机制，暴力列举短文件名，尝试猜解后台地址、敏感文件甚至直接下载对应的文件。但局限于只能猜解长文件名前6位和扩展名前3位，同时需要IIS和.net两个条件都满足。

（一）漏洞原理

利用了IIS短文件名机制，即为了兼容16位MS-DOS程序，Windows为文件名较长的（计算后缀后文件名长度大于9）文件（和文件夹）生成了对应的windows 8.3 短文件名。可以通过此漏洞猜解后台地址、敏感文件等。如图3.1

图3.1

（二）漏洞演示及利用

开启winserver2003虚拟机，在c:/Inetpub/wwwroot目录下新建对比文件夹12345678，123456789，对比文件aaaaaa.asp。在主机上打开虚拟机IP下的URL

尝试10.10.10.132/122~1**/a.asp和10.10.10.132/123~1/a.asp；得到不同的结果如图3.2，图3.3。

图3.2

图3.3

通过如上两图我们可以看出，根据返回结果的不同可以逐个猜解短文件名。

而后再尝试10.10.10.132/aaaaaa~1/a.asp（猜解无后缀，正常返回则为文件夹）和10.10.10.132/aaaaaa~1/a.asp（猜解为文件）。如图3.4，图3.5。

图3.4

图3.5

根据不同的回显我们可以判断正在猜解的对象是文件还是文件夹。

（三）漏洞修复

目前几种修复方式，可选择升级.net framework或者将在注册表HKEY_LOCAL_MACHINESYSTEMCurrentControlSetControlFileSystem中修改NtfsDisable8dot3NameCreation为1，但修改方法尝试多次，不易成功。

除去上述方式，较易成功的方式为将web文件夹内容拷贝到其他区域，将原文件夹删除后，再将拷贝的文件夹移动回来。修复如图3.6，结果如图3.7

图3.6

图3.7

（四）补充

目前有比较好的IIS短文件名检查工具，下载地址为：

https://github.com/lijiejie/IIS_shortname_Scanner

四、Nginx文件解析

Nginx文件解析漏洞，精心构造的恶意请求经过nginx中间件处理后，被合法的执行。php有一个选项cgi.fix_pathinfo，默认值为1，表示开启。

（一）漏洞原理

Nginx文件解析漏洞，涉及到选项cgi.fix_pathinfo，默认值为1，表示开启。请求文件/shell.gif时后面加个*.php，可能会被当作php代码执行。如果关闭此选项，输入10.10.10.130:55555/test.jpg/x.php只会返回找不到文件。但因为如果关闭可能会导致一些其他错误，所以默认是开启的。如图4.1

图4.1

同时配置文件/etc/php5/fpm/pool.d/www.conf中security.limit_extensions允许解析其他格式文件为php，如图4.2，二者共同作用造成了文件解析漏洞。

图4.2

（二）漏洞演示及利用

一是因为对任意文件名，在后面添加/任意文件名.php的解析漏洞，比如原本文件名时test.jpg，都可以添加为test.jpg/x.php进行解析攻击。如图4.3.二是对低版本的Nginx可以在任意文件名后添加%00.php进行解析攻击。

图4.3

（三）漏洞修复

1、将php.ini文件中的cgi.fix_pathinfo的值设为0。这样php在解析1.php/1.jpg这样的目录时，只要1.jpg不存在就会显示404。

2、将/etc/php5/fpm/pool.d/www.conf中security.limit_extensions后面的值设为.php。

修复结果如图4.4

图4.4

（四）补充

Nginx文件解析漏洞的本质原因时配置文件错误。网站上线前需要确认相关配置正确。

五、Nginx配置不当

Nginx配置不当除了造成文件解析漏洞，还可能造成两种后果：1、可以进行目录遍历（或目录穿越）；2、存在CRLF注入，CRLF是”回车+换行”（rn）的简称。目录穿越将在补充内容中进行介绍。

（一）漏洞原理

Nginx目录遍历漏洞和apache一样，属于配置方面的问题。错误的配置可能导致目录遍历与源码泄露。如图5.1

图5.1

CRLF利用了HTTP包Header与Body是用两个CRLF分隔的这一特性，通过控制HTTP消息头中的字符。若采用解码跳转，攻击者就可以注入一些恶意的换行来注入一些会话Cookie或者HTML代码。如图5.2。任何可设置HTTP头的场景都会出现CRLF注入问题。

图5.2

（二）漏洞演示及利用

1、目录遍历

当autoindex on;存在时，可直接访问目录。如图5.3

图5.3

2、CRLF注入

开启burp，刷新页面，抓包，修改数据包。结果如图5.4

图5.4

可以看到，经过恶意修改，攻击者构造的url中的JSPSEEID值被服务器读取成了请求头中的cookie值，达到了会话固定的目的。出去会话固定，通过两次CRLF可将URL中编写的恶意脚本（如反射型XSS）被服务器识别成请求体，从而达成攻击。如图5.5。如未弹窗可能是因为浏览器Filter对XSS特征进行了过滤，并且进行了跳转。

图5.5

（三）漏洞修复

1、针对目录遍历，只需在配置文件中删除autoindex on即可。修复结果如图5.6

图5.6

2、针对CRLF注入，修改配置文件使用不解码的url跳转。

将return 302 https://$host$uri； 修改为return 302 https://$host$request_uri； 修复结果如图5.7

图5.7

（四）补充

关于Nginx配置不当造成目录穿越，其成因除去目录遍历漏洞中开启的autoindex on;选项，同时在配置文件/etc/nginx/conf.d/error2.conf中，没有闭合跳转目录如图5.8，造成目录穿越如图5.9

图5.8

图5.9

修复方法也很简单，将/files闭合，变为/files/即可，效果如图5.10

图5.10

六、apache文件解析漏洞

文件解析与文件上传漏洞往往伴生存在。apache解析文件时逻辑存在问题，造成请求某一个精心编辑过的非法文件时被当作正常的php文件来执行，造成被getshell。

（一）漏洞原理

因为apache解析php时，当文件的最后一个后缀php相关时，会把文件交给php处理器处理，完成后结果返回给apache，再发送给浏览器。而当一个文件以多个点分隔无法识别时，则继续向左试别。即当请求shell.php.360,将试别出php，然后交给php处理。

（二）漏洞演示及利用

当上传1.php时，由于存在上传后缀名限制，无法完成上传如图6.1，一般情况下，若上传允许的类型则无法利用，但存在文件解析漏洞时，可以绕过。

图6.1

此时上传1.php.aaa文件，则可以上传成功。同时因存在解析问题，1.php.aaa文件可以被访问。如图6.2

图6.2

（三）漏洞修复

在配置文件中，不使用AddHandler，改用SetHandler，写好正则，就不会有解析问题。

<FilesMatch “.+.php$”>
SetHandler application /x-httpd-php
</FilesMatch>

禁止.php.这样的文件执行

<FilesMatch “.+.ph(p[3457]?|t|tml).”>
Require all denied
</FilesMatch>

（四）补充

此漏洞爆出后，官方进行了一次修复，采用了黑名单，如图6.3

图6.3

但之后又爆出了同类型的漏洞（编号：CVE-2017-15715），可通过上传一个包含换行符（x0A）的文件绕过检测，如图6.4、图6.5，Apache2.4.0-2.4.29均受到此漏洞影响。在后续版本中官方已经修复了此漏洞，及时更新即可修复。

图6.4

图6.5

七、tomcat任意文件上传

Tomcat远程代码执行漏洞，编号：CVE-2017-12615

（一）漏洞原理

当readonly参数设置为false时，即可通过PUT方式创建一个JSP文件，并可以执行任意代码。如图7.1

图7.1

（二）漏洞演示及利用

开启Burp，访问Tomcat服务，抓包，修改数据包，转发至repeater并发送，提示404，请求被拦截。如图7.2

图7.2

再次修改请求包，处理文件名相关限制。如图7.3

图7.3

（三）漏洞修复

1、将Tomcat、jdk、php更新

2、关闭可通过PUT方式创建JSP文件的功能。

八、weblogic SSRF漏洞

Weblogic未对用户url进行过滤，从恶意构造的的url读取数据并展示功能，导致攻击者可借助服务端实现访问本无权访问的url。漏洞编号：CVE-2014-4210

（一）漏洞原理

Weblogic的SSRF漏洞出现在uddi组件（也就意味着未安装此组件则无此漏洞），其中的uudi包实现包uddiexplorer.war下的SearchPublicRegistries.jsp。

（二）漏洞利用

地址栏输入url：

http://10.10.10.130:7001/uddiexplorer/SearchPublicRegistries.jsp?rdoSearch=name&txtSearchname=sdf&txtSearchkey=&txtSearchfo=&selfor=Business+location&btnSubmit=Search&operator=http://127.0.0.1:7001

得到结果如图8.1

图8.1

修改url中端口为一个未开放的端口如8888，会得到不同的回显如图8.2，根据回显不同，可以判断端口是否开放，以进行下一步渗透

图8.2

网络上获取到批量检测脚本可进行批量端口检测。（附件二），实际操作中此阶段有可能会得到内网网段，获取网段后可使用脚本快速检测。

在检测到相关网段和端口后，可以通过传入%0a%0d来注入换行符，利用 Redis 反弹shell。

（三）漏洞修复

最直接的方式是将SearchPublicRegistries.jsp直接删除。

（四）补充

Weblogic除去上述SSRF漏洞，还存在任意文件上传漏洞等，任意文件上传几乎每年都会有新的漏洞。最近的漏洞编号为CVE-2018-2894，此漏洞成因为若开启Web Service Test Page，可上传任意jsp文件，进而获取服务器权限。

内容较多，暂不展开分析。