部分中间件漏洞总结

阅读量    72714 | 评论 13   稿费 300

分享到: QQ空间 新浪微博 微信 QQ facebook twitter

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

一、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文件,进而获取服务器权限。

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

分享到: QQ空间 新浪微博 微信 QQ facebook twitter
|推荐阅读
|发表评论
|评论列表
加载更多